[prev in list] [next in list] [prev in thread] [next in thread]
List: quagga-dev
Subject: [quagga-dev 11507] Bug in Opaque LSA flooding. Need help
From: <olivier.dugeon () orange ! com>
Date: 2014-09-18 12:06:54
Message-ID: 22425_1411042015_541ACADF_22425_1266_1_541ACADE.9050506 () orange ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
Scenario:
-----------
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:
Explication:
-------------
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)
{
if (IS_DEBUG_OSPF_EVENT)
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);
}
Solution:
----------
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)
-- {
if (IS_DEBUG_OSPF_EVENT)
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 ?
Regards
Olivier
<mailto:olivier.dugeon@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.
[Attachment #5 (text/html)]
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Ubuntu">Dear all,<br>
<br>
<font face="Ubuntu">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. </font><br>
</font>
<div class="moz-signature"><br>
Scenario:<br>
-----------<br>
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:<br>
<br>
Explication:<br>
-------------<br>
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).<br>
<br>
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.<br>
<br>
if (n == 0)<br>
{<br>
if (IS_DEBUG_OSPF_EVENT)<br>
zlog_debug ("Self-originated type-10 Opaque-LSAs:
AREA(%s): Flush completed", inet_ntoa (area->area_id));<br>
<br>
UNSET_FLAG (area->ospf->opaque,
OPAQUE_BLOCK_TYPE_10_LSA_BIT);<br>
}<br>
<br>
Solution:<br>
----------<br>
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.<br>
<br>
-- if (n == 0)<br>
-- {<br>
if (IS_DEBUG_OSPF_EVENT)<br>
zlog_debug ("Self-originated type-10 Opaque-LSAs:
AREA(%s): Flush completed", inet_ntoa (area->area_id));<br>
<br>
UNSET_FLAG (area->ospf->opaque,
OPAQUE_BLOCK_TYPE_10_LSA_BIT);<br>
-- }<br>
<br>
Remaining problem:<br>
-----------------------<br>
<br>
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.<br>
<br>
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 ?<br>
<br>
Regards<br>
<br>
Olivier<br>
<span style="margin:0px 0 20px 0;"><a style="margin:0px 0 20px
0;font-family:Arial,
sans-serif;font-size:10pt;color:#FF6600;text-decoration:none;"
href="mailto:olivier.dugeon@orange.com"></a> </span>
<p style="line-height:20px;margin:0px"> </p>
</div>
<PRE>_________________________________________________________________________________________________________________________
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.
</PRE></body>
</html>
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic