[quagga-dev 11560] Re: [PATCH 1/6] Buggy Unlock in ospfd/ospf_opaque.c
paul at jakma.org
Tue Oct 7 17:08:17 BST 2014
On Tue, 7 Oct 2014, olivier.dugeon at orange.com wrote:
> LSA. Quagga detects these self generated opaque LSA and signal to its
> neighbour router with LS ACK + LSA age = MAX AGE that the LSA must not
> be kept during the LSDB synchronisation phase.
Right. Either the router that gets back its LSA must refresh it (with an
age higher than what the other side has in its LSDB), or it must flush it
Opaque does its own thing a bit there. I've been afraid to touch it in the
past as I had no way to test opaque LSA handling. We really need some way
to at least black-box test opaque-LSAs (and OSPF-API, beyond the simple
client thing we have).
> The correction skip counting the self originate opaque LSA in LSDB and
> unlock opaque LSA flooding once neighbour router acknowledge the removal
> of old opaque LSA in its LSDB.
> As there is no suck mechanism for standard LSA i.e. type 1 to 7, I would
> propose to remove completely this mechanism.
Are you sure? Shouldn't ospf_process_self_originated_lsa handle receiving
self-originated LSAs? Or am I misunderstanding?
It'd be good to try make opaque LSAs use generic LSA code as much as
possible. Or otherwise at least ensure that opaque LSA handling is done
consistently with other LSAs (e.g. at the same level, following similar
E.g. ospf_ls_upd, which calls ospf_flood which calls
ospf_process_self_originated_lsa, contains some opaque LSA related
self-originated handling which I wonder should be moved down to
ospf_process_self_originated_lsa or ospf_flood?
And yes, the code paths at work here aren't the simplest (least, don't
seem simple to me ;) ).
> I test the patch with Cisco and Juniper and don't observe any problem. I
> also made some Wireshark capture and seen nothing strange. I also
> compare Quagga behaviour with Cisco and Juniper behaviour in the same
> condition, and Wireshark capture are similar.
How did you test this?
Did the first Quagga instance run long enough to refresh LSAs? Otherwise
the restarted Quagga instance might not pass the ospf_lsa_more_recent test
in ospf_ls_upd (under '(5)') that leads to ospf_flood - i.e. did it hit
the ospf_flood path? :) (I guess it must have if you're getting different
behaviour, I'd just like a more exact description of the testing
methodology :) ).
If I understand right, this patch doesn't so much fix the problem as
disable refreshing of self-origination for opaque LSAs? So it's shifting
the problem a bit? If so, why not just focus instead on trying to
sanitise, regularise and fix opaque flooding?
Thanks for diving into the opaque code btw! :)
Paul Jakma paul at jakma.org @pjakma Key ID: 64A2FF6A
It is impossible to enjoy idling thoroughly unless one has plenty of
work to do.
-- Jerome Klapka Jerome
More information about the Quagga-dev