[Babel-users] atomic updates and ipv6 cache flushing issues

Thu May 16 13:11:59 UTC 2013

On Sun, May 12, 2013 at 5:50 AM, Leen Besselink <leen at consolejunkie.net>wrote:

> Hi,
>
> On Sun, May 05, 2013 at 06:53:50PM +0100, Robert Bradley wrote:
> > On 05/05/13 16:59, Juliusz Chroboczek wrote:
> > >>Robert bradley has been working on making atomic route updates work
> > >>and possibly better route cache flushing.
> > >[...]
> > >>get the patchset from: git://github.com/rb12345/babeld.git
> > >While it hasn't rained yet, I've looked at the code.
> > >
> > >1. The commit "Atomic route modification in kernel_netlink" contains
> > >both the atomic route modification code and code for flushing the
> > >routing cache.  I'd like the two to be separated.  (I can do that if
> > >you want, Robert, and leave your name as the original author of the
> > >commit.)
> >
> > Yes, that's fine.  I think that the cache-flushing part may not be
> > needed anyway.
> >
> > >4. Is the cache flushing still needed with Baptiste's patch?  I'd
> > >rather not be tweaking /proc files at runtime.
> > >
> > >-- Juliusz
> >
> > I think the cache flushing is a misunderstanding on my part.  I
> > added the cache flushing since
> > http://linux-ip.net/html/linux-ip.html and
> > http://lartc.org/howto/lartc.rpdb.html appeared to imply it might be
> > needed after local route updates.  Looking at the iproute2 manpages
> > closely though, it appears that it is only needed if source-policy
> > rules ("ip rule" equivalents) are involved.  Without source-policy
> > rules, cache flushing looks to be completely unnecessary.
> >
> > The only interaction between this and Baptiste's patch is that the
> > emptier caches mean it has fewer routes to filter out.
> >
>
> Today I had some time to play with this code and 1.4.0.
>
> In my simple/stupid/silly ? test case it performed worse.
>
> The Babel 1.4.0 running on Ubuntu 13.04 / Linux 3.8.0 generic amd64 can
> detect when 2 way communication is not possible.
>
> But the one at https://github.com/rb12345/babeld does not do this.
>
> It will just keep sending traffic to a gateway that can't receive any
> traffic.
>
> I looked if there is any other change between 1.4.0 and the other code and
> there
> was one, but it didn't improve things.
>
> ___
>
> Ignore IPv6 routing cache on linux
>
> Recent linux kernels (roughly 3.x) keep a routing cache for IPv6: each
> time a host is contacted, a temporary /128 route is added. These
> routes are visible using "ip -6 route show cache".
>
> Asking babeld to redistribute all IPv6 routes known to the host, using
> "redistribute ip ::/0", causes it to announce and de-announce these
> /128 routes frequently, leading other nodes to mark them as
> unreachable (thus preventing communication with the host described by
> the /128 route, even though less specific routes are available).
>
>
> https://github.com/jech/babeld/commit/73d8f6621425c624864e63df98c7e49893da09a3
>
> ___
>
> My test-case is:
>
> I create 2 VMs with 2 NICs eth1 and eth2 (eth0 is the 3rd NIC for SSH) and
> connect them to 2 networks.
>
> Then I run these commands:
>
> (i'm impatient so my intervals are really low)
>
> On both VMs:
>
> ifconfig eth1 up
> ifconfig eth2 up
> ./babeld - -u -d 1 -H 0.3 -C redistribute proto 4 eth1 eth2
>
> (proto 4 is static)
>
> on VM1:
> ip -6 addr add 2001:200::1/64 dev lo
> ping6 -i 0.1 -n 2001:200::2
>
> on VM2:
> ip -6 addr add 2001:200::2/64 dev lo
>
> Then with tcpdump I check on what interface traffic is coming in.
>
> If it's eth2 I drop incoming traffic on eth2:
>
> ip6tables -I INPUT -i eth2 -j DROP
>
> It detects it as a failed 2-way communication and the routes in the VMs
> change to reflect that.
>
> Then I run:
>
> iptables -F INPUT #flush all
> ip6tables -I INPUT -i eth1 -j DROP
>
> Again it detects it as a failed 2-way communication and the routes in the
> VMs change to reflect that.
>

There is a behavior I have seen multiple times, where I end up with many
routes "stuck" going to localhost. It happens very rarely, and when it
happens the box that is stuck is often hard to get to...

A recent Linux patch brute forced a fix to some localhost behavior where it
was reproducable , but I'm not sure if it addressed the full potential
extent of the issue. Gaze upon it at:

https://kernel.googlesource.com/pub/scm/linux/kernel/git/linusw/linux-pinctrl/+/25fb6ca4ed9cad72f14f61629b68dc03c0d9713f

>
> I hope this is useful to you.
>
> Have a nice weekend,
>         Leen.
>
> > --
> > Robert Bradley
> >
> >
> > _______________________________________________
> > Babel-users mailing list
> > Babel-users at lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
>

-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20130516/b368751c/attachment.html>