Re: interface metric & quagga



Eugene Grosbein 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.
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.

Regards,
BMS
_______________________________________________
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