From: "Taylor, Grant" <gtaylor@riverviewtech.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Fail-over uplink problem
Date: Tue, 05 Dec 2006 21:19:20 +0000 [thread overview]
Message-ID: <4575E258.7060500@riverviewtech.net> (raw)
In-Reply-To: <1164413138.13235.5.camel@elida.cbxnet.de>
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@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
prev parent reply other threads:[~2006-12-05 21:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-25 0:05 [LARTC] Fail-over uplink problem Torsten Luettgert
2006-12-05 1:36 ` Grant Taylor
2006-12-05 15:44 ` Torsten Luettgert
2006-12-05 21:19 ` Taylor, Grant [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4575E258.7060500@riverviewtech.net \
--to=gtaylor@riverviewtech.net \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.