On Sun, May 12, 2013 at 5:50 AM, Leen Besselink <[email protected]>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 > > [email protected] > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users > > _______________________________________________ > Babel-users mailing list > [email protected] > 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
_______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
