Torsten Luettgert wrote:
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.
*nod*
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.
Ok, maybe I'm not understanding why your router is not seen as a direct neighbor. Or is this like a Cisco CDP thing where a piece of layer 3 equipment will see a layer 2 switch as a neighbor verses the other piece of layer 3 equipment on the other side of the layer 2 switch? Indeed. Nor would I relish sending that much traffic through any sort of tunnel.
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.
*nod*
No NAT there :-)
Good.
That sounds good for the linux side.
*nod*
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.
Don't hold me to this, but I think it has something to do with ARP caching. If your Cisco knows that it needs to send the packets to a gateway that is in it's broadcast domain it will ARP for the gateways MAC so that it can send the packets to it. If for some reason the ARP requests fail, the Cisco will know that the gateway's IP is unreachable and thus that it needs to use an alternant route. Sorry, I can not get any more specific than that. I'm not even really sure that what I said is entirely accurate, that is just the understanding that I have had based on my experiences. Grant. . . . _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
