[quagga-dev 506] Re: OSPF "lost route" problem ressurected

Vladimir Ivaschenko hazard at francoudi.com
Thu Nov 27 20:05:12 GMT 2003


Vladimir Ivaschenko wrote:

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

Eventually I managed to get rid of bogus LSAs. What I had to do is to 
remove all redistribute commands from the 217.27.52.174 configuration 
and start OSPF there. Only after disabling all redistribution I 
managed to get rid of all bogus LSA entries.

I would really appreciate if somebody knowledgeable with Quagga's OSPF 
code gives me a few hints where to search for the problem.

> 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 at francoudi.com>
>  > To: quagga-users at 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)




More information about the Quagga-dev mailing list