[Babel-users] Kernel metrics/route redistribution

[Will Glynn]

On Nov 1, 2010, at 7:15 PM, Juliusz Chroboczek wrote:

>>> Ah.  You want the Babel network to be non-convex.  Ouch.
> 
>> I think a) giving each network disjoint sets of prefixes and b) making
>> sure Babel never sees re-announcements from itself simplifies the
>> problem to the point where it's workable.
> 
> The attached *completely* *untested* patch implements the two new
> features that you've asked for:
> 
> - specifying "inherit" instead of a metric in a redistribute statement
>   causes the Babel metric to be 256 times the kernel priority;
> - specifying "-k inherit" on the command line causes the kernel
>   priority of routes installed by Babel to be 1/256 of the Babel metric
>   (rounded up).

Great!

One thing I don't understand: why is the priority multiplied/divided by 256 going into and out of the kernel? RTA_PRIORITY attributes appear to be a unsigned 32-bit int for both IPv4 and IPv6, which is more than enough to contain Babel metrics unmodified.

> Once again -- it's completely untested.  Even if it works, it will most
> certainly cause transitory routing loops; and unless you're careful, it
> will cause persistent routing loops.

I think I see where you're coming from for both of these, but could you expound on the cases you had in mind?

In particular, I don't think they affect my scenario -- I believe I can accomplish my goals by redistributing Babel into OSPF, not the other way around, and not Babel <-> OSPF <-> Babel. The only loops I can think of involve cases where a prefix falls off the network entirely, but that affects all Babel networks with overlapping announcements (e.g. default routes), whether redistributed across protocols or not.

> This patch is not committed into the Babel tree.  If you confirm that
> your idea works (and manage to convince me), I'll consider making
> a cleaner version for inclusion in Babel.

I built a new image with the patched babeld and re-flashed my test Babel + OSPF device, and the babeld patch certainly appears to be working.

I'm having an issue with getting Quagga 0.99.17 to read metrics from the kernel, and I haven't yet figured out exactly what's broken. (At the moment, I believe it picks up the RTA_PRIORITY from netlink routes on boot, but not on RTM_NEWROUTE events, so new/changed routes come up with metrics of 0.) My efforts so far have been hindered by a long compile/flash/test cycle and limited debugging tools, so I plan to re-work this section of my test network to include a normal Linux machine, and use it to get this resolved.

Regardless, ospf6d announces external routes it learns from zebra as type 5 LSAs, and with a route map to set them to type 2 metrics, the Zebra route object's metric is copied into the announced cost. So, once I figure out where I'm losing metrics, we should be good.

Thanks!

--Will Glynn