Ok, well being this is Thailand, Im pretty sure they wouldnt know what i needed. or had the capabilities to provide<br>BSD or RIP, ideally static ips and leased lines, but Ive got to work with whats available at the moment so. Now<br>
seems babel-pinger has some logic, maybe it could also be extended, ill go through it. get a feel for it. Not many<br>options for dynamic routing these days when dealing with multiple gateways i guess.<br><br>Or, I guess basically run babel on the gateway devices that do the pppoe, so when ppp drops the route then babel should <br>
also update that the route has gone away, and would essentially update when the ppp route comes back correct ?? which<br>it would then redistribute it to the lan connected APs and out into the mesh. <br><br><div class="gmail_quote">
On Sun, May 3, 2009 at 3:46 AM, Juliusz Chroboczek <span dir="ltr"><<a href="mailto:jch@pps.jussieu.fr">jch@pps.jussieu.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">> 4 gateways broadcasting 0.0.0.0 as default routes<br>
><br>
> 36 nodes choose their default best gateway route<br>
<br>
</div>Cool.<br>
<div class="im"><br>
> 1 gateway looses DSL, am i correct in assuming that babel should then<br>
> stop broadcasting it is a default 0.0.0.0 route as it has now lost<br>
> internet connectivity or is it possible that even though it has<br>
> a default route of 192.168.1.1 being the DSL modem, which had lost its<br>
> connection, itll still try to forward traffic through it<br>
<br>
</div>It depends.<br>
<br>
When you redistribute the default route into Babel, using something like<br>
<br>
redistribute ip 0.0.0.0 eq 0 metric 128<br>
<br>
then Babel periodically checks with the kernel whether it has a route<br>
that meets the specification. If the kernel does have such a route,<br>
then Babel will redistribute it into the Babel domain. If the kernel<br>
has no such route, it will use a default route to a different gateway.<br>
<br>
There are two things that can go wrong:<br>
<br>
(i) if your default route is configured statically or through DHCP, then<br>
your node will continue sending packets to its upstream gateway even<br>
after connectivity has been lost.<br>
(ii) if your node loses the route that Babel is redistributing but has<br>
a different default route, then Babel will advertise a route to<br>
a gateway, but your node will continue routing packets through the<br>
down interface.<br>
<br>
(ii) is somewhat exotic, but it does happen sometimes. (i) is probably<br>
the issue that you're concerned about.<br>
<br>
There are two ways of avoiding this kind of brittleness: speak a proper<br>
routing protocol with your upstream, or use a simple reachability<br>
detection protocol.<br>
<br>
<br>
1. The proper way -- speak RIP or BGP with your upstream<br>
********************************************************<br>
<br>
Your gateway is speaking to your upstream provider. If your upstream is<br>
cool, you might be able to get him to send you updates using a proper<br>
routing protocol. For example, if you work out an arrangement with your<br>
upstream to get a default route using RIP, you'd run a RIP routing<br>
daemon on your gateway, and resitribute the RIP route into Babel.<br>
<br>
Suppose you're using quagga, that you use eth0 to speak to your<br>
upstream, and that your mesh network has the prefix <a href="http://1.2.3.0/24" target="_blank">1.2.3.0/24</a>. Then<br>
your zebra.conf would look like this:<br>
<br>
hostname whatever<br>
ip route <a href="http://1.2.3.0/24" target="_blank">1.2.3.0/24</a> lo<br>
<br>
interface eth0<br>
multicast<br>
<br>
Note the static loopback route, which ensures that packets destined to<br>
the mesh don't follow the static route.<br>
<br>
Your ripd.conf would look like this:<br>
<br>
router rip<br>
network eth0<br>
redistribute static<br>
<br>
and your babel.conf like this:<br>
<br>
redistribute proto 11 metric 128<br>
<br>
You'll probably want to put some ACLs in your quagga conf, just to make<br>
sure routes get filtered out if somebody does something stupid. Oh, and<br>
all of the above is untested, so it may very well be broken.<br>
<br>
<br>
2. The hackish way -- using an ad-hoc reachability protocol<br>
***********************************************************<br>
<br>
If you cannot get your upstream to speak RIP to you, you'll need to hack<br>
your own reachability protocol. The official, IETF-mandated way is BFD,<br>
but it's quite okay to use ICMP ping, or UDP echo, or even DNS or NTP as<br>
a reachability protocol.<br>
<br>
I've written a quick hack to do that, it's called ``babel-pinger'' and<br>
you'll find it in my download area. Babel-pinger can use any of UDP<br>
echo, DNS and NTP.<br>
<br>
You'll first want to ensure that packets destined to the mesh don't<br>
follow the default route, so say<br>
<br>
ip route add unreachable <a href="http://1.2.3.0/24" target="_blank">1.2.3.0/24</a> proto static<br>
<br>
In order to use babel-pinger, you need to arrange to filter away routes<br>
to other Babel gateways, to ensure there's no confusion between upstream<br>
routes and other Babel routes. You'll also want to ensure that your<br>
gateways communicate with babel-pinger, so your babel.conf will look<br>
like this:<br>
<br>
in ip 0.0.0.0 eq 0 deny<br>
redistribute 0.0.0.0 eq 0 proto 43 metric 128<br>
<br>
Assuming S is a DNS server, you'll want to arrange to run<br>
<br>
babel-pinger -P dns -i eth0 S<br>
<br>
Hope this helps,<br>
<font color="#888888"><br>
Juliusz<br>
</font></blockquote></div><br>