On 11/24/06 18:05, Torsten Luettgert wrote:
I have a problem I thought was simple first, but now I'm stuck. In a nutshell, it's about redundant uplinks at an outside location. Crude ASCII-Art follows:
It has been experience that things that seem simple seldom are. :s
Internet | | +------------+ | cisco with | | uplinks | +------------+ | | ATM interface +----------+ ... | alvarion | | | wireless | +-------+ | base | | DSL | +----------+ | modem | ||| +-------+ +------------+ | | wireless | || subscriber | / +------------+ / | /+-------------+ | small linux | | box | +-------------+ |target net
Yep, this is one of things that is not as simple as it seems.
The target net is connected via a 20 MBit wireless connection which should be the "normal" route, and a 2 MBit DSL connection as backup. Switching to the backup line should work automatically. There are link networks between the linux box and the DSL modem and between the linux box and the base (subscriber is acting as a bridge).
By "... link networks between ..." do you mean that the DSL modem and / or the subscriber unit are not directly connected to the Linux box? I.e. you can not rely on the ethernet link state. (I'll presume yes for discussion.)
We control all the equipment, including the cisco. So I thought I'd use quagga and build a small OSPF or RIP between the linux box and the cisco where the linux box announces the target net. The wireless route would have higher priority because of the higher line speed.
That seems a bit of over kill, at least on the Linux end. However, seeing as how I'm not really that proficient at Cisco, I'm not sure what choice(s) you will have.
But how do I set the "default route" on the box? I don't want to redistribute BGP into OSPF on the cisco, it knows 2x20,000 routes from two uplink peers and the linux box is really small (300 MHz Celeron with 128 MB RAM).
I would write a small daemon (Perl script) that would periodically test the link to the Cisco equipment. If the primary link is down, try the backup. Are you dealing with NATed traffic, or is your TargetNet a globally routable subnet? If TargetNet is globally routable, things are a bit easier as in you don't have to maintain NAT states. I would recommend that you not have the same subnet on the DSL and the wireless link. This way, you can set up two different routing tables, one for the DSL and one for the wireless link. Then you can have your daemon monitor / test connectivity to the targets. Have your daemon do a quick "ip rule" update and "ip route flush cache" when the links change. Something else you could try would be to have each link be a different subnet and have two different default routes, each with a different metric. The routers should use the route with the lower metric. If for some reason the lower metric does not work, the router should fall back to the higher metric. However for this to work, I think one piece of equipment would have to be the aggregation point on each end. If your equipment setup would allow this, I think this would be an easier / safer / more maintainable route to go. However if you can not do this, think along the lines of my other suggestion. If you can provide more information on your specific scenario, I'd be more than happy to refine my recommendations. Grant. . . . _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
