Mailing List Archive

[Bug 427] New: Zebra "autogenerates" ipv6 kernel routes when receiving routes from ospf6d
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=427

Summary: Zebra "autogenerates" ipv6 kernel routes when receiving
routes from ospf6d
Product: Quagga
Version: 0.99.9
Platform: PC
OS/Version: FreeBSD
Status: UNCONFIRMED
Severity: major
Priority: Medium
Component: zebra
AssignedTo: maintainers@quagga.net
ReportedBy: quagga.net@m.mat.cc


So, I have this area, with half a dozen ospf6d announcing nothing, then, I add a
new route somewhere, and zebra does strange things.

# uname -a
FreeBSD notux.gitoyen.net 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12
10:40:27 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
i386
# zebra -v
zebra version 0.99.9
Copyright 1996-2005 Kunihiro Ishiguro, et al.


Stable state, before the prefix is announced :

notux-zebra> show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3,
I - ISIS, B - BGP, * - FIB route.

O 2001:910::/64 [110/1] is directly connected, em0.11, 1d05h01m

Then, I add an ipv6 address to some other router and the prefix is announced and
received :

notux-zebra> show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3,
I - ISIS, B - BGP, * - FIB route.

O 2001:910::/64 [110/1] is directly connected, em0.11, 1d05h04m
O 2001:910:0:1::/64 [110/1] via fe80::2e0:81ff:fe5f:2972, em0.11, 00:00:01

See, it just created two routes, the O one, received from ospf6d, and a K one,
that don't exist anywhere.

>From now on, it will keep going from :

K>* 2001:910:0:1::/64 via fe80::2e0:81ff:fe5f:2972, em0.11
O 2001:910:0:1::/64 [110/1] via fe80::2e0:81ff:fe5f:2972, em0.11, 00:00:01

to :

K * 2001:910:0:1::/64 via fe80::2e0:81ff:fe5f:2972, em0.11 inactive
O>* 2001:910:0:1::/64 [110/1] via fe80::2e0:81ff:fe5f:2972, em0.11, 00:35:00

When the O route is the best, it's in the so routing table, when not, it's not.

To me, it looks as if zebra first sets the route from ospf6d, then "discovers"
that the box has a new ipv6 route in kernel (the very same it just put there),
and it removes it, then it disapears, and it goes back and forth forever.

If I ever :

# route delete -inet6 2001:910:0:1::/64
delete net 2001:910:0:1::/64

it only says :

notux-zebra> sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3,
I - ISIS, B - BGP, * - FIB route.

K>* ::/96 via ::1, lo0, rej
C>* ::1/128 is directly connected, lo0
K>* ::ffff:0.0.0.0/96 via ::1, lo0, rej
O 2001:910::/64 [110/1] is directly connected, em0.11, 1d07h22m
C>* 2001:910::/64 is directly connected, em0.11
O>* 2001:910:0:1::/64 [110/1] via fe80::2e0:81ff:fe5f:2972, em0.11, 00:00:12

and stops there, happy of having done a so good work, but the route is not there
any more and, well, that work was not so nice after all.

I'll gladly do any debug foo in zebra, but I'd need to know which debug flag to set.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-bugs