[Babel-users] Gateway failure handling

[Outback Dingo]

Ok, well being this is Thailand, Im pretty sure they wouldnt know what i
needed. or had the capabilities to provide
BSD or RIP, ideally static ips and leased lines, but Ive got to work with
whats available at the moment so. Now
seems babel-pinger has some logic, maybe it could also be extended, ill go
through it. get a feel for it. Not many
options for dynamic routing these days when dealing with multiple gateways i
guess.

Or, I guess basically run babel on the gateway devices that do the pppoe, so
when ppp drops the route then babel should
also update that the route has gone away, and would essentially update when
the ppp route comes back correct ?? which
it would then redistribute it to the lan connected APs and out into the
mesh.

On Sun, May 3, 2009 at 3:46 AM, Juliusz Chroboczek <jch at pps.jussieu.fr>wrote:

> > 4 gateways broadcasting 0.0.0.0 as default routes
> >
> > 36 nodes choose their default best gateway route
>
> Cool.
>
> > 1 gateway looses DSL, am i correct in assuming that babel should then
> > stop broadcasting it is a default 0.0.0.0 route as it has now lost
> > internet connectivity or is it possible that even though it has
> > a default route of 192.168.1.1 being the DSL modem, which had lost its
> > connection, itll still try to forward traffic through it
>
> It depends.
>
> When you redistribute the default route into Babel, using something like
>
>  redistribute ip 0.0.0.0 eq 0 metric 128
>
> then Babel periodically checks with the kernel whether it has a route
> that meets the specification.  If the kernel does have such a route,
> then Babel will redistribute it into the Babel domain.  If the kernel
> has no such route, it will use a default route to a different gateway.
>
> There are two things that can go wrong:
>
> (i)  if your default route is configured statically or through DHCP, then
>     your node will continue sending packets to its upstream gateway even
>     after connectivity has been lost.
> (ii) if your node loses the route that Babel is redistributing but has
>     a different default route, then Babel will advertise a route to
>     a gateway, but your node will continue routing packets through the
>     down interface.
>
> (ii) is somewhat exotic, but it does happen sometimes.  (i) is probably
> the issue that you're concerned about.
>
> There are two ways of avoiding this kind of brittleness: speak a proper
> routing protocol with your upstream, or use a simple reachability
> detection protocol.
>
>
> 1. The proper way -- speak RIP or BGP with your upstream
> ********************************************************
>
> Your gateway is speaking to your upstream provider.  If your upstream is
> cool, you might be able to get him to send you updates using a proper
> routing protocol.  For example, if you work out an arrangement with your
> upstream to get a default route using RIP, you'd run a RIP routing
> daemon on your gateway, and resitribute the RIP route into Babel.
>
> Suppose you're using quagga, that you use eth0 to speak to your
> upstream, and that your mesh network has the prefix 1.2.3.0/24.  Then
> your zebra.conf would look like this:
>
>  hostname whatever
>  ip route 1.2.3.0/24 lo
>
>  interface eth0
>    multicast
>
> Note the static loopback route, which ensures that packets destined to
> the mesh don't follow the static route.
>
> Your ripd.conf would look like this:
>
>  router rip
>    network eth0
>    redistribute static
>
> and your babel.conf like this:
>
>  redistribute proto 11 metric 128
>
> You'll probably want to put some ACLs in your quagga conf, just to make
> sure routes get filtered out if somebody does something stupid.  Oh, and
> all of the above is untested, so it may very well be broken.
>
>
> 2. The hackish way -- using an ad-hoc reachability protocol
> ***********************************************************
>
> If you cannot get your upstream to speak RIP to you, you'll need to hack
> your own reachability protocol.  The official, IETF-mandated way is BFD,
> but it's quite okay to use ICMP ping, or UDP echo, or even DNS or NTP as
> a reachability protocol.
>
> I've written a quick hack to do that, it's called ``babel-pinger'' and
> you'll find it in my download area.  Babel-pinger can use any of UDP
> echo, DNS and NTP.
>
> You'll first want to ensure that packets destined to the mesh don't
> follow the default route, so say
>
>  ip route add unreachable 1.2.3.0/24 proto static
>
> In order to use babel-pinger, you need to arrange to filter away routes
> to other Babel gateways, to ensure there's no confusion between upstream
> routes and other Babel routes.  You'll also want to ensure that your
> gateways communicate with babel-pinger, so your babel.conf will look
> like this:
>
>  in ip 0.0.0.0 eq 0 deny
>  redistribute 0.0.0.0 eq 0 proto 43 metric 128
>
> Assuming S is a DNS server, you'll want to arrange to run
>
>  babel-pinger -P dns -i eth0 S
>
> Hope this helps,
>
>                                        Juliusz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20090503/0589d833/attachment.htm>