Quagga routing software development list

headers Kenneth Holter | 3 Mar 2006 14:11 · /remote/

_______________________________________________
Zebra mailing list
Zebra <at> ml.zebra.org
http://ml.zebra.org/mailman/listinfo/zebra

Hi,

The Router-A is trying to flush the self-originate LSA.
When flooding the LSA as Max-age LSA, it should be copied
and added to the retrans-lists of neighbors.
(around ospf6_flood.c: line 331.)

So if it is the case then it will be the bug of ospf6d.
ospf6d should have had the LSA when being ack'ed.

regards,
yasu

> Why does router A remove an LSA from its database before acks for the LSA
> have been received?
> 
> I need to know if this is normal behavior, or if it is a bug. If its a bug,
> it may have been introduced by myself as I've modified some parts of the
> source code. However, I can't think of anything I've modified that should
> affect this.
> 
> So, does anybody have any thoughts on this matter?
> 
> 
> 
> 
> Regards,
> Kenneth Holter
> 
> ------=_Part_21818_11038024.1141391478841
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline
> 
> Hi.<br>
> <br>
> <br>
> <br>
> I'm running ospfv3d on two routers, router A (router id: <a href="http://4.4.4.4">4.4.4.4</a>) and
router B (router id: <a href="http://2.2.2.2">2.2.2.2</a>). <br>
> When starting up I notice something peculiar, which is described below.
> To illustrate, I'm adding output from router A's debug messages I've
> included in the source code. I've added some comments.<br>
> <br>
> &nbsp;<br>
> --------------------<br>
> 2006/03/03 13:40:05 OSPF6:&nbsp; * Installed this LSA into the database: <br>
> 2006/03/03 13:40:05 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; [Intra-Prefix Id:<a
href="http://0.0.0.0">0.0.0.0</a> Adv:<a href="http://4.4.4.4">4.4.4.4</a>]<br>
> 2006/03/03 13:40:05 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; Age:&nbsp;&nbsp;&nbsp; 0 SeqNum: 0x80000001
Cksum: 33fb Len: 44<br>
> 2006/03/03 13:40:05 OSPF6:&nbsp; <br>
> 2006/03/03 13:40:05 OSPF6:&nbsp; * Installed this LSA into the database: <br>
> 2006/03/03 13:40:05 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; [Link Id:<a
href="http://0.0.0.2">0.0.0.2</a> Adv:<a href="http://4.4.4.4">4.4.4.4</a>]<br>
> 2006/03/03 13:40:05 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; Age:&nbsp;&nbsp;&nbsp; 0 SeqNum: 0x80000001
Cksum: 0d9d Len: 56<br>
> <br>
> Installing selv-originated LSAs. <br>
> <br>
> 2006/03/03 13:40:05 OSPF6:&nbsp; <br>
> 2006/03/03 13:40:06 OSPF6: Neighbor state change 2.2.2.2%eth0: [Down]-&gt;[Init]<br>
> 2006/03/03 13:40:15 OSPF6: Neighbor state change 2.2.2.2%eth0: [Init]-&gt;[ExStart]<br>
> 2006/03/03 13:40:15 OSPF6: Neighbor state change 2.2.2.2%eth0: [ExStart]-&gt;[ExChange]<br>
> <br>
> Yay, a new neighbor - let's synchronize!<br>
> <br>
> 2006/03/03 13:40:15 OSPF6:&nbsp; * Installed this LSA into the database: <br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; [Link Id:<a
href="http://0.0.0.2">0.0.0.2</a> Adv:<a href="http://2.2.2.2">2.2.2.2</a>]<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; Age:&nbsp;&nbsp; 11 SeqNum: 0x80000001 Cksum:
52f8 Len: 56<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp; <br>
> 2006/03/03 13:40:15 OSPF6:&nbsp; * Installed this LSA into the database: <br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; [Intra-Prefix Id:<a
href="http://0.0.0.0">0.0.0.0</a> Adv:<a href="http://2.2.2.2">2.2.2.2</a>]<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; Age:&nbsp;&nbsp; 11 SeqNum: 0x80000001 Cksum:
0b34 Len: 44<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp; <br>
> 2006/03/03 13:40:15 OSPF6:&nbsp; *** Sending LSAs to <a href="http://2.2.2.2">2.2.2.2</a>: <br>
> <br>
> Sending two LSAs to neighbor <a href="http://2.2.2.2">2.2.2.2</a>: <br>
> <br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; [Link Id:<a
href="http://0.0.0.2">0.0.0.2</a> Adv:<a href="http://4.4.4.4">4.4.4.4</a>]<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; Age:&nbsp;&nbsp; 10 SeqNum: 0x80000001 Cksum:
0d9d Len: 56<br>
> <br>
> and<br>
> <br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; [Intra-Prefix Id:<a
href="http://0.0.0.0">0.0.0.0</a> Adv:<a href="http://4.4.4.4">4.4.4.4</a>]<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; Age:&nbsp;&nbsp; 10 SeqNum: 0x80000001 Cksum:
33fb Len: 44<br>
> 2006/03/03 13:40:15 OSPF6: Neighbor state change 2.2.2.2%eth0: [ExChange]-&gt;[Full]<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp; * Neighbor state change: prev or next is FULL<br>
> <br>
> Macro &quot;OSPF6_INTRA_PREFIX_LSA_SCHEDULE_STUB
> (on-&gt;ospf6_if-&gt;area);&quot; is run. The LSA(see below) is purged, as
> the following statements are true:<br>
> <br>
> &nbsp; if (route_advertise-&gt;count == 0)<br>
> &nbsp;&nbsp;&nbsp; {<br>
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (old) <br>
> &nbsp; &nbsp;&nbsp; &nbsp;&nbsp; ospf6_lsa_purge (old);<br>
> &nbsp;&nbsp;&nbsp; (...)<br>
> <br>
> Thus, the LSA is prematurely aged, and the function ospf6_lsa_expire is executed (again, see below).<br>
> <br>
> 2006/03/03 13:40:15 OSPF6:&nbsp; * Installed this LSA into the database: <br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; [Router Id:<a
href="http://0.0.0.0">0.0.0.0</a> Adv:<a href="http://4.4.4.4">4.4.4.4</a>]<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; Age:&nbsp;&nbsp;&nbsp; 0 SeqNum: 0x80000001
Cksum: 8c57 Len: 40<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp; <br>
> <br>
> The following LSA is purged (as described above). The following lines
> resides in ospf6_lsa_expire, or in functions called from it:<br>
> <br>
> 2006/03/03 13:40:15 OSPF6:&nbsp; * Flooding expired LSA<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; [Intra-Prefix Id:<a
href="http://0.0.0.0">0.0.0.0</a> Adv:<a href="http://4.4.4.4">4.4.4.4</a>]<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; Age: 3600 SeqNum: 0x80000001 Cksum: 33fb Len: 44<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp; * Reinstalling expired LSA<br>
> <br>
> The LSA is reinstalled into the database...<br>
> <br>
> 2006/03/03 13:40:15 OSPF6:&nbsp; * Installed this LSA into the database: <br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; [Intra-Prefix Id:<a
href="http://0.0.0.0">0.0.0.0</a> Adv:<a href="http://4.4.4.4">4.4.4.4</a>]<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; Age: 3600 SeqNum: 0x80000001 Cksum: 33fb Len: 44<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp; <br>
> <br>
> ..and then removed when calling &quot;ospf6_maxage_remove (ospf6);&quot;:<br>
> <br>
> 2006/03/03 13:40:15 OSPF6: ## Remove MaxAge [Intra-Prefix Id:<a href="http://0.0.0.0">0.0.0.0</a>
Adv:<a href="http://4.4.4.4">4.4.4.4</a>]<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; [Intra-Prefix Id:<a
href="http://0.0.0.0">0.0.0.0</a> Adv:<a href="http://4.4.4.4">4.4.4.4</a>]<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; Age: 3600 SeqNum: 0x80000001 Cksum: 33fb Len: 44<br>
> 2006/03/03 13:40:15 OSPF6:&nbsp;&nbsp; <br>
> <br>
> &lt;end function ospf6_lsa_expire&gt;<br>
> <br>
> Then, when router B responds with an LS Ack for the LSA, router A (the local node) doesn't have a copy of the
LSA anymore:<br>
> <br>
> 2006/03/03 13:40:18 OSPF6:&nbsp; <br>
> 2006/03/03 13:40:18 OSPF6:&nbsp; ** I'm the adv router of the following LSA, but haven't got a copy of the
LSA in my database!<br>
> <br>
> Router A have thus received an ack for an LSA it doesn't have. <br>
> <br>
> 2006/03/03 13:40:18 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; [Intra-Prefix Id:<a
href="http://0.0.0.0">0.0.0.0</a> Adv:<a href="http://4.4.4.4">4.4.4.4</a>]<br>
> 2006/03/03 13:40:18 OSPF6:&nbsp;&nbsp;&nbsp;&nbsp; Age:&nbsp;&nbsp; 15 SeqNum: 0x80000001 Cksum:
33fb Len: 44<br>
> --------------------------------<br>
> <br>
> <br>
> Why does router A remove an LSA from its database before acks for the LSA have been received?<br>
> <br>
> I need to know if this is normal behavior, or if it is a bug. If its a
> bug, it may have been introduced by myself as I've modified some parts
> of the source code. However, I can't think of anything I've modified
> that should affect this. <br>
> <br>
> So, does anybody have any thoughts on this matter? <br>
> <br>
> <br>
> <br clear="all"><br>Regards,  <br>Kenneth Holter<br><br>
> 
> ------=_Part_21818_11038024.1141391478841--
> 
> --===============0038352548==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Zebra mailing list
> Zebra <at> ml.zebra.org
> http://ml.zebra.org/mailman/listinfo/zebra
> 
> --===============0038352548==--

Hi Tom,

On Thu, 16 Feb 2006, Tom Everett wrote:

> I was unable to compile 0.99.3 on OpenBSD 3.8.  Two changes were 
> required, which make it work nicely.

That's a really recent OpenBSD right?

> --- quagga-0.99.3/lib/zebra.h   Wed Jan 11 20:24:56 2006
> +++ quagga-0.99.3_tge/lib/zebra.h       Thu Feb 16 13:10:23 2006
>  <at>  <at>  -29,6 +29,11  <at>  <at> 
> #define _GNU_SOURCE
> #endif /* GNU_LINUX */
>
> +#ifdef OPEN_BSD
> +#include <inttypes.h>
> +#define UINT16_MAX 65535
> +#endif /* OPEN_BSD */

Is this not a deficiency in OpenBSD? They should provide UINT16_MAX, 
if they provide uint16_t. Ie might it be a better idea to file this 
as a bug against OBSD?

> +#ifndef OPEN_BSD
>  {RTM_OLDADD,   "RTM_OLDADD"},
>  {RTM_OLDDEL,   "RTM_OLDDEL"},
> +#endif /* OPEN_BSD */

Hmm, I wonder what platforms use those, I'll look into that. Simply 
removing them might be the better option, if there are no platforms 
we care about that use it (if there are, it should be #ifdef <that 
platform>).

> I apologize in advance if my changes are cheap hacks, or don't 
> follow existing coding standards for quagga.  I have only tested 
> this for RIP.

Fine, thanks!

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
Tom's hungry, time to eat lunch.

Hi Paul.  yes, as of today OpenBSD 3.8 is the latest release. 

There should be a new release in May, however.  
(http://www.openbsd.org/faq/faq1.html#Next)

The cvs tree for OpenBSD's stdint.h (/src/sys/sys/stdint.h) is here:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/stdint.h

I'm not knowledgeable enough to explain why the file is on the cvs tree 
for 3.9, but not on my system, unless that file was added for the 3.9 
tag.  It does seem that OpenBSD 3.9 might have the symbol UINT_16_MAX in 
stdint.h.

Paul Jakma wrote:
> Hi Tom,
>
> On Thu, 16 Feb 2006, Tom Everett wrote:
>
>> I was unable to compile 0.99.3 on OpenBSD 3.8.  Two changes were 
>> required, which make it work nicely.
>
> That's a really recent OpenBSD right?
>
>> --- quagga-0.99.3/lib/zebra.h   Wed Jan 11 20:24:56 2006
>> +++ quagga-0.99.3_tge/lib/zebra.h       Thu Feb 16 13:10:23 2006
>>  <at>  <at>  -29,6 +29,11  <at>  <at> 
>> #define _GNU_SOURCE
>> #endif /* GNU_LINUX */
>>
>> +#ifdef OPEN_BSD
>> +#include <inttypes.h>
>> +#define UINT16_MAX 65535
>> +#endif /* OPEN_BSD */
>
> Is this not a deficiency in OpenBSD? They should provide UINT16_MAX, 
> if they provide uint16_t. Ie might it be a better idea to file this as 
> a bug against OBSD?
>
>> +#ifndef OPEN_BSD
>>  {RTM_OLDADD,   "RTM_OLDADD"},
>>  {RTM_OLDDEL,   "RTM_OLDDEL"},
>> +#endif /* OPEN_BSD */
>
> Hmm, I wonder what platforms use those, I'll look into that. Simply 
> removing them might be the better option, if there are no platforms we 
> care about that use it (if there are, it should be #ifdef <that 
> platform>).
>
>> I apologize in advance if my changes are cheap hacks, or don't follow 
>> existing coding standards for quagga.  I have only tested this for RIP.
>
> Fine, thanks!
>
> regards,

Paul Jakma <paul <at> clubi.ie> wrote:
> Hi Tom,
>
> On Thu, 16 Feb 2006, Tom Everett wrote:
>
>> I was unable to compile 0.99.3 on OpenBSD 3.8.  Two changes were
>> required, which make it work nicely.
>
> That's a really recent OpenBSD right?
>
>> --- quagga-0.99.3/lib/zebra.h   Wed Jan 11 20:24:56 2006
>> +++ quagga-0.99.3_tge/lib/zebra.h       Thu Feb 16 13:10:23 2006
>>  <at>  <at>  -29,6 +29,11  <at>  <at> 
>> #define _GNU_SOURCE
>> #endif /* GNU_LINUX */
>>
>> +#ifdef OPEN_BSD
>> +#include <inttypes.h>
>> +#define UINT16_MAX 65535
>> +#endif /* OPEN_BSD */
>
> Is this not a deficiency in OpenBSD? They should provide UINT16_MAX,
> if they provide uint16_t. Ie might it be a better idea to file this
> as a bug against OBSD?
FreeBSD4 has the same deficiency, Paul - i already told you that much.
I suggest including this, certainly if its impact is larger than just 1 BSD 
family/version.
As we're closing in on 1.0 , and AFAIK lots of people still use fbsd4, it 
might not be a bad idea at all: there's no point in having users mail this 
list over and over again when they try to compile it.
Also, perhaps some FAQ should point out GCC2.95 is not supported, and 
freebsd users can easily fix that by installing the gcc3X ports and adding 
"CC=gcc3x" (x being minor version number) in front of configure & gmake 
commands.