Neighbor state remains in exchange or loading
santiago at crfreenet.org
Fri Dec 4 16:38:22 CET 2009
On Thu, Dec 03, 2009 at 08:22:34AM +0100, Vonlanthen, Elmar wrote:
> Hello all
> Could someone explain me, what is the reason a neighbor state remains in exchange or loading?
> On the neighbor himself, the state is in full.
> If I dump the traffic, I see these LS packets again and again:
> 08:11:42.636071 IP 10.254.1.10 > 10.254.10.1: OSPFv2, LS-Request, length: 36
> 08:11:42.637017 IP 10.254.10.1 > 10.254.1.10: OSPFv2, LS-Update, length: 244
> 08:11:42.640274 IP 10.254.1.10 > 10.254.10.1: OSPFv2, LS-Ack, length: 44
10.254.1.10 is the side that reports a neighbor state in exchange or loading?
Switching from loading to full should be done when side empties its LS-request
list (lsrql neighbor field). So there are three basic possibilities for problems:
1) LS-request list contains some garbage.
2) the other side sent just some subset in LS-Update.
3) the other side sent all request LSAs in LS-Update, but some are thrown away
in LSA update processing.
Perhaps the best thing would be to use debugging dumps in
ospf_lsreq_send() (lsreq.c:66, DBG("Requesting ...)
and in ospf_lsupd_receive() (lsupd.c:413, DBG("Update Type: ...)
to see what was requested and what was received.
One way to not lost in tons of debug messages it to not enable it, just replace
DBG("xxx", yyy) with log(L_WARN "xxx", yyy) for interesting debug messages.
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: Digital signature
More information about the Bird-users