Some more info:
Apparently an external link state entry does not get flushed from the
OSPF database, even if I stop OSPF completely on the router announcing it.
The biggest problem is that currently I'm in a situation where all
routers redistribute this LSA between each other and I cannot get rid
of it, looks like the only option is to stop all OSPF processes at the
same time, and I'd really like not to do that :-(
Below is an example. The first entry is a bogus one. What I noticed is
that all bogus entries have LS Seq Number below or equal to 80000005.
Any ideas?
LS age: 2905
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
LS Type: AS-external-LSA
Link State ID: 217.27.35.80 (External Network Number)
Advertising Router: 217.27.52.174
LS Seq Number: 80000005
Checksum: 0xdcd4
Length: 36
Network Mask: /29
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 217.27.52.166
External Route Tag: 0
LS age: 823
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
LS Type: AS-external-LSA
Link State ID: 217.27.35.80 (External Network Number)
Advertising Router: 217.27.52.205
LS Seq Number: 80001a90
Checksum: 0xf1e4
Length: 36
Network Mask: /29
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 217.27.52.188
External Route Tag: 0
Vladimir Ivaschenko wrote:
> Reposting into quagga-dev since now I reliaze that this is a more
> appropriate list.
>
> -------- Original Message --------
> Subject: OSPF "lost route" problem ressurected
> Date: Mon, 24 Nov 2003 10:55:35 +0200
> From: Vladimir Ivaschenko <hazard@francoudi.com>
> To: quagga-users@lists.quagga.net
>
> Hi All,
>
> A mutation of OSPF "lost route" problem appeared again in my network a
> few times, and now I have a really hard time understanding it. I'm
> running Quagga 0.96.4 on Linux.
>
> ROUTER A <---> ROUTER B
>
> Let's assume we have an external network C. This network is
> redistributed from RIPv2 by a router many neighbor hops away from both
> ROUTER A and ROUTER B. Entire OSPF network is rather big with three
> areas (backbone and two others) and about 70 routers.
>
> What I get is that for some reason the routing entry for network C in
> OSPF and kernel routing tables is pointing to ROUTER B; however ROUTER
> B shows that it doesn't have any information about it *at all*. This
> network is not mentioned anywhere in "show ip ospf route" output of
> ROUTER B, and does not exist in the kernel tables. Both ROUTER A and
> ROUTER B redistribute the route to their OSPF neighbors, causing
> entire network to think that network C is somewhere "between" ROUTER A
> and ROUTER B.
>
> Now, the weird thing is that if I restart Zebra on ROUTER A or ROUTER
> B, the situation does not disappear. Apparently only if I restart
> Zebra on both of them at the same time the problem is gone.
>
> Can anyone with knowledge of OSPF code hint me on where I need to
> investigate?
>
> Unfortunately I couldn't get any valuable debugging info, as ospfd
> process got stuck after I turned on various debugging and "term mon" -
> most probably console buffer was overfilled, as routing to my
> workstation was temporarily lost due to neighbor reload; I had to kill
> the ospfd process with SIGKILL, as it wasn't responding to SIGINT
at all.
>
--
Best Regards,
Vladimir Ivaschenko
Thunderworx - Senior Systems Engineer (RHCE)
Apparently an external link state entry does not get flushed from the
OSPF database, even if I stop OSPF completely on the router announcing it.
The biggest problem is that currently I'm in a situation where all
routers redistribute this LSA between each other and I cannot get rid
of it, looks like the only option is to stop all OSPF processes at the
same time, and I'd really like not to do that :-(
Below is an example. The first entry is a bogus one. What I noticed is
that all bogus entries have LS Seq Number below or equal to 80000005.
Any ideas?
LS age: 2905
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
LS Type: AS-external-LSA
Link State ID: 217.27.35.80 (External Network Number)
Advertising Router: 217.27.52.174
LS Seq Number: 80000005
Checksum: 0xdcd4
Length: 36
Network Mask: /29
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 217.27.52.166
External Route Tag: 0
LS age: 823
Options: 0x2 : *|-|-|-|-|-|E|*
LS Flags: 0x6
LS Type: AS-external-LSA
Link State ID: 217.27.35.80 (External Network Number)
Advertising Router: 217.27.52.205
LS Seq Number: 80001a90
Checksum: 0xf1e4
Length: 36
Network Mask: /29
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 217.27.52.188
External Route Tag: 0
Vladimir Ivaschenko wrote:
> Reposting into quagga-dev since now I reliaze that this is a more
> appropriate list.
>
> -------- Original Message --------
> Subject: OSPF "lost route" problem ressurected
> Date: Mon, 24 Nov 2003 10:55:35 +0200
> From: Vladimir Ivaschenko <hazard@francoudi.com>
> To: quagga-users@lists.quagga.net
>
> Hi All,
>
> A mutation of OSPF "lost route" problem appeared again in my network a
> few times, and now I have a really hard time understanding it. I'm
> running Quagga 0.96.4 on Linux.
>
> ROUTER A <---> ROUTER B
>
> Let's assume we have an external network C. This network is
> redistributed from RIPv2 by a router many neighbor hops away from both
> ROUTER A and ROUTER B. Entire OSPF network is rather big with three
> areas (backbone and two others) and about 70 routers.
>
> What I get is that for some reason the routing entry for network C in
> OSPF and kernel routing tables is pointing to ROUTER B; however ROUTER
> B shows that it doesn't have any information about it *at all*. This
> network is not mentioned anywhere in "show ip ospf route" output of
> ROUTER B, and does not exist in the kernel tables. Both ROUTER A and
> ROUTER B redistribute the route to their OSPF neighbors, causing
> entire network to think that network C is somewhere "between" ROUTER A
> and ROUTER B.
>
> Now, the weird thing is that if I restart Zebra on ROUTER A or ROUTER
> B, the situation does not disappear. Apparently only if I restart
> Zebra on both of them at the same time the problem is gone.
>
> Can anyone with knowledge of OSPF code hint me on where I need to
> investigate?
>
> Unfortunately I couldn't get any valuable debugging info, as ospfd
> process got stuck after I turned on various debugging and "term mon" -
> most probably console buffer was overfilled, as routing to my
> workstation was temporarily lost due to neighbor reload; I had to kill
> the ospfd process with SIGKILL, as it wasn't responding to SIGINT
at all.
>
--
Best Regards,
Vladimir Ivaschenko
Thunderworx - Senior Systems Engineer (RHCE)