Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Quagga>
  3. Bugs
[Bug 374] OSPF routes from new neighbor set inactive by zebra because neighbor "inactive"
bugzilla-daemon at allevil
Jun 15, 2007, 8:15 AM
Post #1 of 7 (5365 views)
Permalink
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=374





------- Additional Comments From virginb@oslo.westerngeco.slb.com 2007-06-15 16:15 -------
ALL interfaces, including the links between routes are ethernet. No P2P links
are configured.



------- 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
[Bug 374] OSPF routes from new neighbor set inactive by zebra because neighbor "inactive" [ In reply to ]
bugzilla-daemon at allevil
Jun 20, 2007, 8:28 AM
Post #2 of 7 (5260 views)
Permalink
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=374





------- Additional Comments From paul@dishone.st 2007-06-20 16:28 -------
Could you give the output from the zebra commands you are using to diagnose the
problem, so we can follow your diagnosis?

Its not really clear what this problem looks like..



------- 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
[Bug 374] OSPF routes from new neighbor set inactive by zebra because neighbor "inactive" [ In reply to ]
bugzilla-daemon at allevil
Jun 20, 2007, 9:43 AM
Post #3 of 7 (5260 views)
Permalink
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=374





------- Additional Comments From virginb@oslo.westerngeco.slb.com 2007-06-20 17:42 -------
The zebra debugging command used on both R1 and R1 is: "debug zebra rib". I am
running ospfd and zebra from terminals so I can capture their output to
stdout(err?).

The output from R1 immediately after R2 and R3 peer is:

2007/06/20 18:33:29 OSPF: Link State Update[Type5,id(11.0.7.0),ar(11.0.2.223)]:
LS age is equal to MaxAge.
2007/06/20 18:33:29 OSPF: Link State Update[Type5,id(11.0.8.0),ar(11.0.2.223)]:
LS age is equal to MaxAge.
2007/06/20 18:33:29 OSPF: Link State Update[Type5,id(11.0.9.0),ar(11.0.2.223)]:
LS age is equal to MaxAge.
2007/06/20 18:33:29 OSPF: Link State Update[Type5,id(11.0.10.0),ar(11.0.2.223)]:
LS age is equal to MaxAge.
2007/06/20 18:33:30 ZEBRA: rib_link: rn 0x95988b8, rib 0x9598828
2007/06/20 18:33:30 ZEBRA: rib_process: Adding route, select 0x9598828
2007/06/20 18:33:30 ZEBRA: rib_link: rn 0x9598980, rib 0x95988f0
2007/06/20 18:33:30 ZEBRA: rib_process: Adding route, select 0x95988f0
2007/06/20 18:33:30 ZEBRA: rib_link: rn 0x9598a48, rib 0x95989b8
2007/06/20 18:33:30 ZEBRA: rib_process: Adding route, select 0x95989b8
2007/06/20 18:33:30 ZEBRA: rib_link: rn 0x9598b10, rib 0x9598a80
2007/06/20 18:33:30 ZEBRA: rib_process: Adding route, select 0x9598a80

In contrast, the output from R2 is:

1970/01/01 00:02:12 OSPF: Link State Update[Type5,id(11.0.10.0),ar(11.0.2.223)]:
LS age is equal to MaxAge.
1970/01/01 00:02:12 OSPF: Link State Update[Type5,id(11.0.7.0),ar(11.0.2.223)]:
LS age is equal to MaxAge.
1970/01/01 00:02:12 OSPF: Link State Update[Type5,id(11.0.8.0),ar(11.0.2.223)]:
LS age is equal to MaxAge.
1970/01/01 00:02:12 OSPF: Link State Update[Type5,id(11.0.9.0),ar(11.0.2.223)]:
LS age is equal to MaxAge.
1970/01/01 00:02:12 OSPF: Link State Update[Type5,id(11.0.10.0),ar(11.0.2.223)]:
LS age is equal to MaxAge.
1970/01/01 00:02:12 OSPF: Link State Update[Type5,id(11.0.7.0),ar(11.0.2.223)]:
LS age is equal to MaxAge.
1970/01/01 00:02:12 OSPF: Link State Update[Type5,id(11.0.8.0),ar(11.0.2.223)]:
LS age is equal to MaxAge.
1970/01/01 00:02:12 OSPF: Link State Update[Type5,id(11.0.9.0),ar(11.0.2.223)]:
LS age is equal to MaxAge.
1970/01/01 00:02:12 OSPF: Link State Update[Type5,id(11.0.10.0),ar(11.0.2.223)]:
LS age is equal to MaxAge.
1970/01/01 00:02:13 ZEBRA: rib_link: rn 0x10072350, rib 0x10071ac8
1970/01/01 00:02:14 ZEBRA: rib_link: rn 0x100723b8, rib 0x10071af8
1970/01/01 00:02:14 ZEBRA: rib_link: rn 0x10072450, rib 0x100723f0
1970/01/01 00:02:14 ZEBRA: rib_link: rn 0x100724e8, rib 0x10072488

On R1 zebra reports the following:

lab258-osl.oslo.eur.slb.com> show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

K>* 0.0.0.0/0 via 134.32.79.1, eth0
O 10.0.0.0/24 [110/20] via 11.0.0.223, eth1, 00:06:58
via 11.0.6.1, eth1, 00:06:58
C>* 10.0.0.0/24 is directly connected, eth2
O 11.0.0.0/24 [110/10] is directly connected, eth1, 00:08:33
C>* 11.0.0.0/24 is directly connected, eth1
O>* 11.0.1.0/24 [110/20] via 11.0.0.223, eth1, 00:06:59
via 11.0.6.1, eth1, 00:06:59
O>* 11.0.1.1/32 [110/20] via 11.0.0.223, eth1, 00:06:59
via 11.0.6.1, eth1, 00:06:59
O>* 11.0.2.0/24 [110/20] via 11.0.0.223, eth1, 00:06:59
via 11.0.6.1, eth1, 00:06:59
O>* 11.0.2.1/32 [110/20] via 11.0.0.223, eth1, 00:06:59
via 11.0.6.1, eth1, 00:06:59
O>* 11.0.2.223/32 [110/20] via 11.0.0.223, eth1, 00:06:04
via 11.0.6.1, eth1, 00:06:04
O>* 11.0.3.0/24 [110/20] via 11.0.0.223, eth1, 00:06:59
via 11.0.6.1, eth1, 00:06:59
O>* 11.0.3.1/32 [110/20] via 11.0.0.223, eth1, 00:06:58
via 11.0.6.1, eth1, 00:06:58
O>* 11.0.4.0/24 [110/20] via 11.0.0.223, eth1, 00:06:59
via 11.0.6.1, eth1, 00:06:59
O>* 11.0.4.1/32 [110/20] via 11.0.0.223, eth1, 00:06:59
via 11.0.6.1, eth1, 00:06:59
O>* 11.0.5.0/24 [110/20] via 11.0.0.223, eth1, 00:06:59
via 11.0.6.1, eth1, 00:06:59
O>* 11.0.5.1/32 [110/20] via 11.0.0.223, eth1, 00:06:59
via 11.0.6.1, eth1, 00:06:59
O 11.0.6.0/24 [110/10] is directly connected, eth1, 00:07:02
C>* 11.0.6.0/24 is directly connected, eth1
O>* 11.0.7.0/24 [110/30] via 11.0.0.223, eth1, 00:05:55
via 11.0.6.1, eth1, 00:05:55
O>* 11.0.7.1/32 [110/20] via 11.0.0.223, eth1, 00:05:52
via 11.0.6.1, eth1, 00:05:52
O>* 11.0.8.0/24 [110/30] via 11.0.0.223, eth1, 00:05:55
via 11.0.6.1, eth1, 00:05:55
O>* 11.0.8.1/32 [110/20] via 11.0.0.223, eth1, 00:05:52
via 11.0.6.1, eth1, 00:05:52
O>* 11.0.9.0/24 [110/30] via 11.0.0.223, eth1, 00:05:55
via 11.0.6.1, eth1, 00:05:55
O>* 11.0.9.1/32 [110/20] via 11.0.0.223, eth1, 00:05:52
via 11.0.6.1, eth1, 00:05:52
O>* 11.0.10.0/24 [110/30] via 11.0.0.223, eth1, 00:05:55
via 11.0.6.1, eth1, 00:05:55
O>* 11.0.10.1/32 [110/20] via 11.0.0.223, eth1, 00:05:52
via 11.0.6.1, eth1, 00:05:52
C>* 127.0.0.0/8 is directly connected, lo
C>* 134.32.79.0/24 is directly connected, eth0
K>* 169.254.0.0/16 is directly connected, eth0
lab258-osl.oslo.eur.slb.com>

On R2 it is:

10.0.0.110> show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

O 10.0.0.0/24 [110/20] via 11.0.2.223 inactive, 00:06:45
via 11.0.0.1, gb3, 00:06:45
via 11.0.6.224, gb3, 00:06:45
C>* 10.0.0.0/24 is directly connected, eth0
O 11.0.0.0/24 [110/10] is directly connected, gb3, 00:07:53
K * 11.0.0.0/24 is directly connected, gb3
C>* 11.0.0.0/24 is directly connected, gb3
O 11.0.1.0/24 [110/10] is directly connected, fe0, 00:07:53
C>* 11.0.1.0/24 is directly connected, fe0
S>* 11.0.1.1/32 [1/0] is directly connected, fe0
O 11.0.2.0/24 [110/10] is directly connected, fe1, 00:07:53
C>* 11.0.2.0/24 is directly connected, fe1
S>* 11.0.2.1/32 [1/0] is directly connected, fe1
S>* 11.0.2.223/32 [1/0] is directly connected, fe1
O 11.0.3.0/24 [110/10] is directly connected, gb0, 00:07:54
C>* 11.0.3.0/24 is directly connected, gb0
S>* 11.0.3.1/32 [1/0] is directly connected, gb0
O 11.0.4.0/24 [110/10] is directly connected, gb1, 00:07:53
C>* 11.0.4.0/24 is directly connected, gb1
S>* 11.0.4.1/32 [1/0] is directly connected, gb1
O 11.0.5.0/24 [110/10] is directly connected, gb2, 00:07:53
C>* 11.0.5.0/24 is directly connected, gb2
S>* 11.0.5.1/32 [1/0] is directly connected, gb2
O 11.0.6.0/24 [110/10] is directly connected, gb3, 00:07:53
C>* 11.0.6.0/24 is directly connected, gb3
O 11.0.7.0/24 [110/20] via 11.0.2.223 inactive, 00:06:46
O 11.0.7.1/32 [110/20] via 11.0.2.223 inactive, 00:06:43
O 11.0.8.0/24 [110/20] via 11.0.2.223 inactive, 00:06:46
O 11.0.8.1/32 [110/20] via 11.0.2.223 inactive, 00:06:42
O 11.0.9.0/24 [110/20] via 11.0.2.223 inactive, 00:06:46
O 11.0.9.1/32 [110/20] via 11.0.2.223 inactive, 00:06:42
O 11.0.10.0/24 [110/20] via 11.0.2.223 inactive, 00:06:46
O 11.0.10.1/32 [110/20] via 11.0.2.223 inactive, 00:06:42
C>* 127.0.0.0/8 is directly connected, lo
O>* 134.32.79.0/24 [110/20] via 11.0.0.1, gb3, 00:07:50
via 11.0.6.224, gb3, 00:07:50
10.0.0.110>

I tried to narrow the problem down further by adding a lot of zlog_debug()
statements to trace execution.






------- 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
[Bug 374] OSPF routes from new neighbor set inactive by zebra because neighbor "inactive" [ In reply to ]
bugzilla-daemon at allevil
Jun 20, 2007, 11:38 AM
Post #4 of 7 (5263 views)
Permalink
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=374





------- Additional Comments From paul@dishone.st 2007-06-20 19:38 -------
You have:

O 11.0.7.0/24 [110/20] via 11.0.2.223 inactive, 00:06:46
S>* 11.0.2.223/32 [1/0] is directly connected, fe1

So zebra resolves the route to a static route. For zebra to consider the route
installable, nexthops must resolve directly to a Connected route.. (For eBGP, we
allow for a second lookup, as eBGP nexthops typically are offlink and resolved
through additional routes).

You need to remove the static routes and configure the addresses on your
interfaces such that Quagga thinks OSPF nexthops resolve to connected
subnets/routes.



------- 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
[Bug 374] OSPF routes from new neighbor set inactive by zebra because neighbor "inactive" [ In reply to ]
bugzilla-daemon at allevil
Jun 21, 2007, 2:34 AM
Post #5 of 7 (5249 views)
Permalink
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=374





------- Additional Comments From virginb@oslo.westerngeco.slb.com 2007-06-21 10:33 -------
Hi

This is in fact the bug:

O 11.0.7.0/24 [110/20] via 11.0.2.223 inactive, 00:06:46
S>* 11.0.2.223/32 [1/0] is directly connected, fe1

11.0.2.223 is precisely the interface of R3 over which R2 and R3 are exchanging
databases. How can it be "inactive" then?

It really sounds like the newly received LSAs are being processed in the wrong
order, but I don't understand the code well enough to know why.



------- 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
[Bug 374] OSPF routes from new neighbor set inactive by zebra because neighbor "inactive" [ In reply to ]
bugzilla-daemon at allevil
Jun 21, 2007, 2:40 AM
Post #6 of 7 (5255 views)
Permalink
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=374





------- Additional Comments From virginb@oslo.westerngeco.slb.com 2007-06-21 10:40 -------
Sorry,

Is see in fact that the route to the nexthop is indeed static and not connected.
Is there anything in the OSPF standard mandating that nexthops must be connected
instead of static?



------- 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
[Bug 374] OSPF routes from new neighbor set inactive by zebra because neighbor "inactive" [ In reply to ]
bugzilla-daemon at allevil
Jun 21, 2007, 3:39 AM
Post #7 of 7 (5251 views)
Permalink
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=374





------- Additional Comments From virginb@oslo.westerngeco.slb.com 2007-06-21 11:39 -------
Removing the static routes isn't really an option for our application. However,
you did give me enough information to be able to patch zebra to accept static
routes as well:

zebra_rib.c:


389,390c389
< if (match->type == ZEBRA_ROUTE_CONNECT ||
< match->type == ZEBRA_ROUTE_STATIC)
---
> if (match->type == ZEBRA_ROUTE_CONNECT)


Thanks



------- 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

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal