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: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
diff --git a/proto/ospf/topology.c b/proto/ospf/topology.c
index 8119cfa..7558d4a 100644
--- a/proto/ospf/topology.c
+++ b/proto/ospf/topology.c
@@ -278,7 +278,7 @@ ospf_originate_lsa(struct ospf_proto *p, struct ospf_new_lsa *lsa)
if (!SNODE_VALID(en))
s_add_tail(&p->lsal, SNODE en);
- if (en->lsa_body == NULL)
+ if (!en->nf || !en->lsa_body)
en->nf = lsa->nf;
if (en->nf != lsa->nf)
signature.asc
Description: Digital signature
