[quagga-dev 11507] Bug in Opaque LSA flooding. Need help

olivier.dugeon at orange.com olivier.dugeon at orange.com
Thu Sep 18 13:06:54 BST 2014

Dear all,

After doing some tests to validate my next version of Traffic 
Engineering patch, I discover an old bug in Opaque LSA floding 
management that seems very difficult to solve.

The bug is quiet simple to reproduce. Setup 2 OSPF router (at least one 
quagga and, in my case a Cisco one) and activate Traffic Engineering. 
Let the 2 routers fire up adjacency and verify that in neighbour router 
you got the TE LSA from the quagga. Shut down the quagga router (kill 
-15 or CTRL-C if you launch it in foreground) and you'll discover that 
the Cisco will never get the TE LSA. The reason is as follow:

The neighbour router once the quagga stop keep trace of LSA in its 
database. A "sh ip ospf database" on the Cisco show that LSA still exist 
and that its age continue to increase. When you restart the quagga 
router, once the adjacency is setup, the Cisco send the contain of its 
LSDB including the original TE LSA coming from the quagga router. In 
such situation (i.e. receiving a self-originate LSA by a neighbour), the 
quagga router send an LS ACK message with LSA AGE = 3600 (maxage) to 
advertise its neighbour to flush it. And the Cisco router do it 
normally. But, the quagga router also manage some blocking bits, e.g. 
OPAQUE_BLOCK_TYPE_10_LSA_BIT for type 10 (see opsfd.h line 135-142) and 
activate it in such situation (see function 
ospf_opaque_self_originated_lsa_received() in ospf_opaque.c) that 
prevent to send the self-originate LSA before the LSDB synchro is 
finish. Normally, the blocking bit is reset in 
ospf_opaque_type10_lsa_rxmt_nbr_check() function (always in opaque.c 
file) but, this does not work properly. The bit remains always set and 
Opaque LSA is never send. Note, that this problem does not occur with 
other LSA (Type 1,3,5).

In fact, this is due to the test done on the number of self-originate 
LSA remaining in the LSDB done in function 
ospf_opaque_type10_lsa_rxmt_nbr_check(). Before resetting the blocking 
bit, the function verify that there is no more self originate LSA, but, 
as the configuration file ask to generate such LSA, and because the LSA 
has been previously originate, it is keep in the LSDB and the result 
will be never equal to 0.

   if (n == 0)
         zlog_debug ("Self-originated type-10 Opaque-LSAs: AREA(%s): 
Flush completed", inet_ntoa (area->area_id));

       UNSET_FLAG (area->ospf->opaque, OPAQUE_BLOCK_TYPE_10_LSA_BIT);

I would propose a small patch to remove this verification and reset the 
blocking bit OPAQUE_BLOCK_TYPE_10_LSA_BIT in all case. But, I'm not sure 
that it is pertinent and safe.

--   if (n == 0)
--    {
         zlog_debug ("Self-originated type-10 Opaque-LSAs: AREA(%s): 
Flush completed", inet_ntoa (area->area_id));

       UNSET_FLAG (area->ospf->opaque, OPAQUE_BLOCK_TYPE_10_LSA_BIT);
--    }

Remaining problem:

The same phenomena occurs when you shut down and re-activate and 
interface (conf t, interface eth1, shutdown, no shutdown). And in this 
case, the patch does not help any more.

Is there somebody aware about this bug ? Have you some ideas to help me 
solving it ? Or at least, pointing me how it is manage for LSA type 
1,3,5 in order to reproduce the same behaviour and not the one 
implemented for Opaque LSA ?


<mailto:olivier.dugeon at orange.com>


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20140918/75e8d5d1/attachment-0001.html>

More information about the Quagga-dev mailing list