LSA ID Collision help

[Ondrej Zajicek]

On Mon, Mar 21, 2016 at 09:29:29AM -0400, Jigar Mehta wrote:
> So I tried tracing down this problem and here is what I got :
> 
> (Note :
...
> 4. Due to flooding, we receive LSUPDATE packet from our DR and now since we
> have a local copy, we delete the hash entry from lsrqh hash table as per RFC
> 2328 13.3
> LSA hash 000000000069dcb8 removed ID 10.1.1.0
> 
> < So at this point, there is no hash entry for 10.1.1.0 in lsrqh but we still
> have a hash entry in the top graph tree hash table (p->gr) since we call
> ospf_disp (ospf hearbeat/ospf table calculations) every second and all of this
> is happening within same second >

Hi

Thanks for the analysis. I think i understand the problem. The hash entry
(in  p->gr) is in the 'flushing' state (regardless whether we are waiting
for implicit ACK by LSUPDATE or whether we already received that and just
waiting for periodic cleanup) but because it was not originally created
by ospf_originate_lsa() but by ospf_advance_lsa()/ospf_install_lsa() then
en->nf is unset for the first hash entry (in p->gr).

The check for LSA ID collision is probably just overzealous, in this
case the new LSA should be properly propagated. I think the attached
patch should fix the problem.

If you could try it and report log messages (with debug events for OSPF)
related to that LSA origination without and with the patch.


> Also, is there a good way to announce from the custom protocol every X
> seconds to sync up route tables with other protocols (send its routes
> to other protocols).

You could announce (by rte_update()) routes periodically every X seconds,
but if they are the same as ones already in the routing table, then the
updates are ignored as nothing changes. You definitely should not
propagate routes directly from one protocol to another (i.e. call
rte_announce() from one protocol to another).

You could call periodically proto_request_feeding() for the destination
protocol, but i doubt there is a good reason for that.

-- 
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: ospf-lsa-collision.patch
Type: text/x-diff
Size: 409 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20160321/9cf10651/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20160321/9cf10651/attachment.asc>