[quagga-dev 11560] Re: [PATCH 1/6] Buggy Unlock in ospfd/ospf_opaque.c

Paul Jakma paul at jakma.org
Tue Oct 7 17:08:17 BST 2014


Hi,

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 
(maxage 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 
paths).

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! :)

regards,
-- 
Paul Jakma	paul at jakma.org	@pjakma	Key ID: 64A2FF6A
Fortune:
It is impossible to enjoy idling thoroughly unless one has plenty of
work to do.
 		-- Jerome Klapka Jerome




More information about the Quagga-dev mailing list