[Babel-users] quagga-babel and blackholes

[Dave Taht]

On Tue, Mar 27, 2012 at 3:25 PM, Juliusz Chroboczek <jch at pps.jussieu.fr>wrote:

> > I recently had a chance to catch up with the quagga-babel implementation,
> > and set it up as a leaf node on my laptop and connected it to bloatlab
> #1,
>
> Cool.
>
> > 1) when connectivity to a destination is lost, babeld puts an
> 'unreachable'
> > route in place, zebra puts a 'blackhole' route in place. I can see
> defenses
> > of both methods, is there a way to switch this behavior?
>
> That's the implementation of the hold time described in RFC 6126
> Section 3.5.5.  The RFC merely states that in this particular situation,
> "packets for that prefix MUST NOT be forwarded".  (It's one of Babel's
> loop-avoidance mechanisms, and the least satisfactory one in my opinion --
> but I see no better solution to that particular edge-case that doesn't
> require global synchronisation of seqnos, as in AODV.)
>
> The difference is that standalone babeld will cause the kernel to send
> destination unreachable ICMP packets, while Quagga will not.  With dest
> unreach, the sender might fallback to IPv4 when IPv6 has been retracted
> in a more timely manner; without it, it will retry longer.
>
> There's currently no way to tune the behaviour.  What are you trying to do?
>
>
1) This was mostly just a note as to the difference in behavior

2) Unreach, as it give instant feedback, and is the same as the original
behavior, is preferable to me. It might not be to others.


> > 2) the routing tables are identical, except that zebra does not put a p2p
> > route in on the local lan segment.
>
> Yep.  I'll be hacking on Quagga's "zebra" daemon when I have some time
> to make it more suitable for pure meshes.
>

I am keeping up to date with quagga-re in my ceropackages repo, so if
anyone else wants to build it for openwrt, feel free to pull from that
feed. I just pulled from commit  quagga-re
4282415a7c0076721e6de96b66063b5a0e59c758)

After the leaf node test above went so well I later setup a quagga instance
on a more central wndr3700v2 node, which was also connected solely by mesh
links. It ended up with no ipv4 routes sent to the kernel, although
quagga's internal tools internally said it had.

Sorry, I did not capture the quagga show babel database as I assumed this
is a reflection of the same problem you refer to, only on a larger scale.

Should we try to track bugs over on quagga-re?

I will start leaving quagga + bgp + ra + babel + ospf up on a cerowrt leaf
node fairly soon.

I should note that my own purposes in tracking babel's integration into
quagga are varied:

1) The ietf homenet working group wants to specify some variant of ospf as
'the' routing protocol for home networks.

My own preference is for a bakeoff of some sort, where 'running code'
trumps 'rough consensus'.

http://tools.ietf.org/wg/homenet/charters

http://www.potaroo.net/ietf/ids/draft-acee-ospf-ospfv3-autoconfig-01.txt

2) I'm glad there's ra support and dnssl support now in quagga (it's also
now in dnsmasq along with slaac-to-dns support)

3) I love the notion of one configuration syntax for routing stuff

4) Being able to do failover and EGP<->IGP integration easily


>
> ("When I have some time" might not happen immediately, since I'm trying to
> write up Babel-Z.  And the weather is so lovely in Paris... it almost feels
> like May.)
>

I so wish I had some lovely weather here, or could return to Paris. I do
look forward to reading your writeup of babelz, I'm hoping you're doing
that from the comfort of a cafe under a rainless sky.



-- Juliusz
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20120401/22f6baa7/attachment.html>