battling with babel and route changes

battling with babel and route changes

[Dave Taht]

While I am totally in love with babel as a routing protocol, at the
traffic volumes I'm regularly generating now,
it's fairly trivial for a route change to stop a tcp stream in its
tracks. [1] I'm simply not familiar enough with netlink
to fix it, or even know if it can be fixed...

0) babel keeps all the routing information in it's head. It  does not
use the kernel metrics in particular:
1) babel installs ipv4 routes with a metric of 0, ipv6 routes with a
metric of 1024
2) doing a route change via netlink seems to require  a different metric
   (or at least it did, several years ago, when the code was written)

So I've been playing with the experimental babelz from Julius's darcs
repo, which can be obtained from

darcs get http://www.pps.jussieu.fr/~jch/software/repos/babelz/

The relevant bit of code is in kernel_netlink.c, where it calls itself
recursively to handle a route change,
instead of making a route change.

    if(operation == ROUTE_MODIFY) {
        if(newmetric == metric && memcmp(newgate, gate, 16) == 0 &&
           newifindex == ifindex)
            return 0;
        /* It is better to add the new route before removing the old
           one, to avoid losing packets.  However, this only appears
           to work if the metrics are different. */
        if(newmetric != metric) {
            rc = kernel_route(ROUTE_ADD, dest, plen,
                              newgate, newifindex, newmetric,
                              NULL, 0, 0);
            if(rc < 0 && errno != EEXIST)
                return rc;
            rc = kernel_route(ROUTE_FLUSH, dest, plen,
                              gate, ifindex, metric,
                              NULL, 0, 0);
            if(rc < 0 && (errno == ENOENT || errno == ESRCH))
                rc = 1;
        } else {
            rc = kernel_route(ROUTE_FLUSH, dest, plen,
                              gate, ifindex, metric,
                              NULL, 0, 0);
            rc = kernel_route(ROUTE_ADD, dest, plen,
                              newgate, newifindex, newmetric,
                              NULL, 0, 0);
            if(rc < 0 && errno == EEXIST)
                rc = 1;
        }



--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

1: lest you think this is not relevant to bufferbloat... I am
generating saturating loads across two test networks [2], while trying
to get real work done - saving the mice packets - you know, typing,
listening to streaming radio -  and fixing bloat wherever it appears -
and I keep stumbling across problems like this one  (assuming it's
real) that aren't related to bloat but affect the tests.

I THINK, but am not prepared to discuss, that I've found a long
standing bug with dhcp, for example. Working on it...

2: Test network #1 - 8 wndr3700s and a pc at georgia tech
    Test network #2 - Linux laptop, 2 wndr3700, 3 nanostation M5s,
    1 android, 1 ipad, 1 iphone, 1 nokia 770, 1 windows XP box,
     1 vista box, and soon - 3 OLPCS.

I'm getting to where I can grant permission for others to hack on the
first network.

3: While this might be better on the babel list, I thought that
perhaps in-depth netlink knowledge was here...

Re: battling with babel and route changes

[Juliusz Chroboczek]

[Added babel-users to the CC, with permission from Dave.]

> 0) babel keeps all the routing information in it's head. It  does not
> use the kernel metrics in particular:

Yes.  That's by design.

The ``kernel metric'' is something of a misnomer: it's not a metric,
it's better understood as a priority.  It's only useful to discriminate
between routes with the same destination that are installed by different
routing protocols.  It's analogous to what Cisco call the ``Administrative
Distance''.

You can choose the kernel priority used by Babel with the -k command-line
option.  If you need finer-grained control on routing than possible
with -k alone, -t and -T together with ``ip table'' and friends are what
you need.

A patch to reflect the metric in the kernel priority has been published
on this list at some point; I'll not be merging it into Babel, since
I remain convinced that that's the wrong thing to do.

> 1) babel installs ipv4 routes with a metric of 0, ipv6 routes with a
> metric of 1024

These are apparently the kernel's defaults -- we call the kernel with
the value 0 in both cases.  You can set the priority with -k (but cannot
set it to be different between v4 and v6), and if you need any more
control, use routing tables (-t and -T).

-- Juliusz

Re: battling with babel and route changes

[Dave Taht]

On Wed, Jun 22, 2011 at 7:39 AM, Juliusz Chroboczek <jch@pps.jussieu.fr> wrote:

>
> A patch to reflect the metric in the kernel priority has been published
> on this list at some point; I'll not be merging it into Babel, since
> I remain convinced that that's the wrong thing to do.

I agree that it is the wrong thing to do. Babel's metric calculations
are decidedly different than that of other protocols.

However, to clean up the route change...

either maintaining two routes of different priority differing by 1, or
inserting the new route with priority of base+1 and moving it down
after removing the first route, seems like a workable solution, that
can save hundreds of packets at high volumes.

I'm perfectly willing to try implementing either of these approaches
(the latter being far easier than the first) my concern was that by
doing so I'd break something somewhere else, and felt the best
approach was the first, which, as I said, is harder to implement.

>> 1) babel installs ipv4 routes with a metric of 0, ipv6 routes with a
>> metric of 1024
>
> These are apparently the kernel's defaults -- we call the kernel with
> the value 0 in both cases.  You can set the priority with -k (but cannot
> set it to be different between v4 and v6), and if you need any more
> control, use routing tables (-t and -T).
>
> -- Juliusz
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com