On Mo, 2006-12-04 at 19:36 -0600, Grant Taylor wrote: > On 11/24/06 18:05, Torsten Luettgert wrote: > 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.) They are indeed directly connected, but I still don't want to rely on the link state. I meant there are two /30 networks just for the linux box and modem/subscriber. > > 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. It actually worked except for one showstopper on the cisco :-( The solution was "default-information originate always", btw., just for the archives. This command is identical in Cisco IOS and quagga. The problem: my cisco only accepts direct neighbours for OSPF, so I built GRE tunnels and everything was fine... except the default route (of course) pointed into the tunnel, and I'm not keen on sending 20 MBit through GRE, what with all the MTU, fragmentation and router CPU load problems. > 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. That's what I'm doing now. I didn't want to originally: I can easily make the linux box send packets upstream via the backup route, but I would need my script log in on the cisco and change routes. Gives me a bad taste. > 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. No NAT there :-) > 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. That sounds good for the linux side. > 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. How would it "know" the line is down? In my experience, in most cases the interface stays up just fine, but packets vanish because of radio problems or something. Thanks for your suggestions, Torsten _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
