Neighbor state remains in exchange or loading

[Ondrej Zajicek]

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...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20091204/bc375a38/attachment-0001.asc>