Re: interface metric & quagga

On Fri, Jan 26, 2007 at 06:38:53PM +0000, Bruce M. Simpson wrote:

RTM_NEWADDR contains 'metric 0' regardless of interface metric
value set with ifconfig before. quagga, since version 0.99.3,
takes metric value from RTM_NEWADDR message and this value overrides
right interface metric learned by quagga a milisecond before.
Then it passes zero interface metric to ripd that uses interface
metric as hop count increment for RIP-learned routes.
This effectively breaks RIPv2 for FreeBSD (quagga-0.99.2 and older
versions do not use metric from RTM_NEWADDR and work), perhaps RIPv1 too.

It's a mixed issue.

FreeBSD does not use the interface metric, so routing daemons shouldn't
use that field.

However, many routing implementations use a metric or distance of 0 to
indicate a directly-connected route or interface route, so it has
special meaning.

We could deal with this situation better by explicitly setting the
metric to an invalid value.

Quagga checks if metric is zero and changes zero to one for itself
in first place. Sadly, it does not perform such sanity check
in second place, when it processes RTM_NEWADDR.

If/when we implemented equal-cost multipath, or source address selection
policies, then we should use this field.
Verified with RELENG_4 and RELENG_6.
Is it kernel bug or quagga bug?

I also suggest to include next patch to the Ports tree
if no objections. It restores RIP support.

I'd rewrite the patch to wrap the assignment in #ifndef __FreeBSD__ so
that it can be taken upstream more easily. If/when we do equal-cost
multipath or source policy we can bump __FreeBSD_version.

Here is version that does not need #ifndef __FreeBSD__
Now (ifam->ifam_metric) is always zero for all FreeBSD versions.

--- zebra/kernel_socket.c.orig Fri Jan 26 10:55:03 2007
+++ zebra/kernel_socket.c Fri Jan 26 10:55:35 2007
@@ -585,6 +585,7 @@
if (ifnlen && strncmp (ifp->name, ifname, INTERFACE_NAMSIZ))
isalias = 1;

+ if (ifam->ifam_metric)
ifp->metric = ifam->ifam_metric;

/* Add connected address. */

I currently run this patch in production for relatively large RIPv2 network
of FreeBSD routers (versions 4.11 and 6.x).

Eugene Grosbein
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: OT - Quagga/CARP
    ... I haven't been able to make headway on the Quagga lists, ... I am wondering if anybody on the FreeBSD side of things ... On FreeBSD 5.4 with Quagga 0.99, if there is already a route say to ...
    (freebsd-net)
  • Re: kern/134931:[route] [fib] Route messages sent to all socket listeners regardless of setfib
    ... Subject: kern/134931:[route] [fib] Route messages sent to all socket listeners ... using routing daemons + multiple fibs in FreeBSD ... Currently quagga gets really confused if route ...
    (freebsd-net)
  • Re: OT - Quagga/CARP
    ... when an alternate route for the same prefix is in the kernel route table. ... The problem is that quagga just does a stupid RTM_DELETE/RTM_ADD combo to ... limitation in the kernel routing tables or something, ... My understanding is that restarting en ospfd daemon is bad. ...
    (freebsd-net)
  • Re: Quagga as border router
    ... question I asked regarding the viability of an ISP using Quagga under ... already have my router config pretty well done, on a flash memory card, ... Not unless you want to pull in the entire world through those bgp peers, but since you use default-originate only, this shouldn't be a problem. ... Quagga could disconnect peers just simply because the initial route "flooding" took too much time. ...
    (freebsd-net)
  • Re: My planned work on networking stack
    ... > Quagga) into FreeBSD? ... With BGP routing daemon onboard, FreeBSD will be ...
    (freebsd-net)