headers
BingChunZhu | 1 Feb 2005 02:39

[zebra 22157] Re: LSA Sequence Numbers error

Yasuhiro Ohara,
Base on your comment, I read the zebra code and try to fix this bug. The attachment is a patch for this bug. I
don't know if this patch can work successfully. I test it in zebra 0.94. For router-LSA, it is OK.

Thanks and best regards.
Numchun

-----Original Message-----
From: Yasuhiro Ohara [mailto:yasu <at> sfc.wide.ad.jp] 
Sent: Saturday, January 29, 2005 9:31 PM
To: BingChunZhu
Cc: zebra <at> ml.zebra.org
Subject: Re: [zebra 22139] LSA Sequence Numbers error


Sorry for late response.

It seems it is a bug.

How to fix is not trivial because we need two or three action
when LS sequence number is wrapping, i.e. 1, when 0x7fffffff
the LSA should be flushed instead of (current) refreshing.
2, schedule origination of new LSA when the 0x7fffffff LSA is
being flushed. 3, execute (previously scheduled) origination of the
LSA as seqnum 0x80000001.

I will try to keep this in mind and hopefully I will fix it
after 0.95 release. (Please remind me if I seem to forget ;p)

regards,
(Continue reading)

Permalink | Reply | 5 comments |
headers
Yasuhiro Ohara | 2 Feb 2005 21:38
Picon

[zebra 22158] Re: LSA Sequence Numbers error


The patch was a reverse version :p) (you should have put the directory
in wrong order as the arguments to diff command)

I understand what you meant to do, and the patch would work only when
you receive the MAX_SEQUENCE LSA in LS Update message.

Whether you would receive self-originated LSAs in LS Update or not
depends on the DR/BDR status on the LAN, and there is the case
you will not receive your self-originated max-sequence LSA.
It means that there is a case that the code does not update
the max-sequence LSA correctly yet, even with your patch.

I am now investigating the current code further to fix the problem
appropriately ...

regards,
yasu

From: "BingChunZhu" <bczhu <at> cdc.3upsystems.com>
Subject: [zebra 22157] Re: LSA Sequence Numbers error
Date: Tue, 1 Feb 2005 09:39:57 +0800

> Yasuhiro Ohara,
> Base on your comment, I read the zebra code and try to fix this bug. The attachment is a patch for this bug. I
don't know if this patch can work successfully. I test it in zebra 0.94. For router-LSA, it is OK.
> 
> Thanks and best regards.
> Numchun
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Yasuhiro Ohara | 2 Feb 2005 23:45
Picon

[zebra 22159] Fw: mtech student ...india


Could someone answer to this ?
I couldn't find any info by google'ing ...

regards,
yasu
Favicon
From: tajik edathil <tajike <at> rediffmail.com>
Subject: Re: Re: [zebra 22102] mtech student ...india
Date: 2005-01-31 04:21:31 GMT

 
sir,

iam running zebra in redhat 9.2

how can i find the  queue length ?

is it variable ?


kindly reply
tajik 



(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Yasuhiro Ohara
 | 
2 Feb 2005 23:47






Picon





[zebra 22160] Re: Multiple routing table support



Try "./configure --enable-multipath=4" .
It may need more additional configuration in Linux
that I don't know of ...

regards,
yasu

From: 한동수 <chevron <at> future.co.kr>
Subject: [zebra 22154] Multiple routing table support
Date: Sun, 30 Jan 2005 09:50:30 +0900

> Untitled DocumentHi, 
> 
>    I'm using zebra with netlink to communicate with kernel. But i found out that the kernel does not install
> multiple routing entries with same destination/mask but different nexthops. 
>    Does anybody know how to do this?
>    Do I need a kernel patch or zebra patch? (I'm using zebra-0.93 and linux-2.5.7.)
>  
> Thanks 
_______________________________________________
Zebra mailing list
Zebra <at> ml.zebra.org
http://ml.zebra.org/mailman/listinfo/zebra






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Yasuhiro Ohara
 | 
2 Feb 2005 23:50






Picon





[zebra 22161] Re: zebra-0.95-pre3



I presume it's impossible because I suspect that windows has no
kernel interface like routing socket (RTM).

Let us know if it's working ;p)

regards,
yasu

From: Vincent Jardin <Vincent.Jardin <at> 6WIND.com>
Subject: Re: [zebra 22151] Re: zebra-0.95-pre3
Date: Sat, 29 Jan 2005 16:52:36 +0100

> Yes it is possible. I have here a Windows code of Quagga which compiles 
> quite well :)
> 
> I still have to understand how to use RTM Handler, but I did not have 
> much time to check it more deeply.
> 
> If you want to start with it and have more time, I can send to you a tgz 
> and we can chat about my current status.
> 
> Regards,
>    Vincent
> 
> Sergio K. de Figueiredo wrote:
> 
> >Zebra is written at c code, then why is it impossivel to get a win32
> >version?
> >Sergio K. de Figueiredo

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Dan Hollis
 | 
3 Feb 2005 00:19





[zebra 22162] Re: Multiple routing table support


On Thu, 3 Feb 2005, Yasuhiro Ohara wrote:
> Try "./configure --enable-multipath=4" .
> It may need more additional configuration in Linux
> that I don't know of ...

zebra doesn't support multipath with bgp.

-Dan






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Yasuhiro Ohara
 | 
3 Feb 2005 00:18






Picon





[zebra 22163] Re: LSA Sequence Numbers error



> I am now investigating the current code further to fix the problem
> appropriately ...

I've made a patch that might fix the problem.
It compiled OK for me, it is against CVS HEAD.

I haven't tested anything with this, and I'm worring about the part:

RCS file: /cvsroot/zebra/ospfd/ospf_lsa.c,v
retrieving revision 1.387
diff -u -r1.387 ospf_lsa.c
--- ospfd/ospf_lsa.c    9 Jan 2004 17:18:23 -0000       1.387
+++ ospfd/ospf_lsa.c    3 Feb 2005 00:08:50 -0000
 <at>  <at>  -2402,7 +2422,7  <at>  <at> 
     }

   /* If received LSA' ls_age is MaxAge, set LSA on MaxAge LSA list. */
-  if (IS_LSA_MAXAGE (new) && !IS_LSA_SELF (new))
+  if (IS_LSA_MAXAGE (new))
     {
       if (IS_DEBUG_OSPF (lsa, LSA_FLOODING))
        zlog_info ("LSA[Type%d:%s]: Install LSA, MaxAge",

With this part, now self-originated LSA will go into ospf_lsa_maxage ()
from ospf_lsa_install (). Though I tried to check the code carefully,
(and it seems OK, but) it may cause a crash.

Please test this patch and let us know the result.
If it would crash, please show us the log with 'debug ospf lsa flooding',

(Continue reading)






Permalink
| Reply
| 3 comments  
| 



  

  

  





headers


BingChunZhu
 | 
3 Feb 2005 07:26





[zebra 22164] Re: LSA Sequence Numbers error


Thank you for your reply.
I test this patch. With your patch, ospfd can originate a LSA whose sequence number is
OSPF_INITIAL_SEQUENCE_NUMBER when it received a self-originated LSA whose sequence number is
OSPF_MAX_SEQUENCE_NUMBER. But I think that before it originates a new LSA with
OSPF_INITIAL_SEQUENCE_NUMBER, ospfd should maxage the old LSA and flush it. I can find this process even
with your patch.
The attachment is a file I capture with ethereal when I test your patch. Another is a debug file with "debug
ospf lsa flooding". I think they are helpful.
By the way, zebra never crash with your patch. It looks OK.

Thanks and best regards.
Numchun



-----Original Message-----
From: Yasuhiro Ohara [mailto:yasu <at> sfc.wide.ad.jp] 
Sent: Thursday, February 03, 2005 7:18 AM
To: BingChunZhu
Cc: zebra <at> ml.zebra.org
Subject: Re: [zebra 22158] Re: LSA Sequence Numbers error


> I am now investigating the current code further to fix the problem
> appropriately ...

I've made a patch that might fix the problem.
It compiled OK for me, it is against CVS HEAD.

I haven't tested anything with this, and I'm worring about the part:

(Continue reading)






Permalink
| Reply
| 2 comments  
| 



  

  

  





headers


Hasso Tepper
 | 
3 Feb 2005 08:21






Picon





[zebra 22165] Re: LSA Sequence Numbers error


Yasuhiro Ohara wrote:
> > I am now investigating the current code further to fix the problem
> > appropriately ...
>
> I've made a patch that might fix the problem.
> It compiled OK for me, it is against CVS HEAD.

This isn't so trivial. See RFC2328 12.1.6 page 120 for details:

***

When an attempt is made to increment the sequence number past the maximum 
value of N - 1 (0x7fffffff; also referred to as MaxSequenceNumber), the 
current instance of the LSA must first be flushed from the routing domain.  
This is done by prematurely aging the LSA (see Section 14.1) and reflooding 
it. As soon as this flood has been acknowledged by all adjacent neighbors, 
a new instance can be originated with sequence number of 
InitialSequenceNumber.

***

I tried to fix it some time ago, but couldn't get good solution for 
AS-External LSA's. Also note that situation itself can appear in case of 
serious memory problems only in real life. Even in case of constantly 
flapping links it would take 680 years to reach seq number 0x7fffffff.

--

-- 
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator

(Continue reading)






Permalink
| Reply
| 2 comments  
| 



  

  

  





headers


Yasuhiro Ohara
 | 
3 Feb 2005 11:43






Picon





[zebra 22166] Re: LSA Sequence Numbers error



> > I've made a patch that might fix the problem.
> > It compiled OK for me, it is against CVS HEAD.
> 
> This isn't so trivial. See RFC2328 12.1.6 page 120 for details:
> 
> ***
> 
> When an attempt is made to increment the sequence number past the maximum 
> value of N - 1 (0x7fffffff; also referred to as MaxSequenceNumber), the 
> current instance of the LSA must first be flushed from the routing domain.  
> This is done by prematurely aging the LSA (see Section 14.1) and reflooding 
> it. As soon as this flood has been acknowledged by all adjacent neighbors, 
> a new instance can be originated with sequence number of 
> InitialSequenceNumber.
> 
> ***

You have to tell us what is the part you don't think it's trivial,
or the part you think the patch is wrong.

I know that the patch might not wait the acknowledgement of Max-sequence
LSA. This is due to the fact that current code (seems to me that)
add the LSA to the retransmit list of neighbors in ospf_flood_through (),
and then call ospf_discard_from_db () where it immediately deletes
the previously added LSA (in the retransmit list of neighbors).

I admit the current code place which calls ospf_refresh_self_originated_lsa ()
might be wrong with respect to the spec, but it is this-like trivial,
and it is not so hard to change the calling place.

(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  

  


  





    



Gmane