[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quagga-users
Subject:    [quagga-users 12044] Re: ospfd nssa issue
From:       Han Coumans <hjcoumans () gmail ! com>
Date:       2011-01-05 7:47:28
Message-ID: AANLkTikR7r=v0tD+ihE7jFwUo2FUO_K80rfHGzoFK8Lr () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Dear "Wu, Yiwen" and Quagga users/devs,


This is not a final email concerning the issue as I continue to investigate.

I can confirm OP's behavior, but must also add it is intermittent and until
now I'm not able to reproduce the issue consistently.

Often, but not always the erroneous behavior shows at cold boot of the ABR,
sometimes also on the restart of zebra and ospfd (with a 40 second delay
between daemon kill and start). Until now, the issue never showed itself
during ospfd restart (with or without a 40 second sleep in between).

Roughly 60 tests were done until now.
  Breakdown:
    A few tests on the ABR with zebra and ospfd killed, 40 second sleep and
zebra started, 1 second sleep and ospfd started. The reported issue did
occur at least once.
    Around 10 tests on the ABR to kill zebra and ospfd, wait 40 second and
reboot the machine. Plm 40% of the time the issue showed.
    Around 10 tests on the ABR to kill zebra and ospfd, wait 40 seconds and
restart zebra and ospfd immediately after each other. Also a plm 40% the
issue showed.
    Around 10 tests on the ABR having the connected routers running and cold
boot the ABR. Again plm 40% score
    Around 15 tests on the ABR restarting the ospf daemon without sleep
time. Never got the issue.
    Remaining test on the ASBR or the router between the ASBR and the ABR
stopping ospfd with and without sleep time and also reboots. No statistics.

The interfaces get their IP address from zebra. I will test if it makes a
difference if Linux does the IP setting and will report back to you.


Test environment:

All machines:
# uname -a
Linux ...... 2.6.18-128.1.10.el5.xs5.5.0. 51xen #1 SMP Fri May 29 06:29:19
EDT 2009 i686 athlon i386 GNU/Linux
aka Centos 5 x86 on Citrix Xenserver 5.6.0.

ASBR (nssa), ABR, router in between (nssa):
Quagga-0.99.17 (release)

Directly connected (area 0) router to ABR:
Quagga-0.99.8 (release)

All hello and dead timers for these routers are default.


Regards and cheers,

Han

Date: Tue, 28 Dec 2010 11:42:01 -0500
From: "Wu, Yiwen" <ywu@idirect.net>
To: <quagga-users@lists.quagga.net
>
Subject: [quagga-users 12034] ospfd nssa issue
Message-ID:
       <C874DBE9D30B584587F8CD0EC34DA8BE1A27DC19@EX00.idirect.net>
Content-Type: text/plain; charset="us-ascii"

Hi all,

I got great trouble to make ospfd NSSA working. Router R6 injects two
extern routes 10.0.0.0/24 and 10.0.0.1/24 and R5 redistributes these two
routes to OSPF. I am seeing a few strange thing:

1. when doing "sh ip ospf border-router" on R2~R5, it shows that R1 is
ASBR and ABR. It didn't happen when using the same topology but no NSSA.

2. The two external routes didn't appear in R2's RIB. I turned on debug
in R1 and found the following word in the ospfd.log file for each Type 7
message R1 receives.

"OSPF: Route[External]: Can't find originating ASBR route"

Does anyone see the similar thing before?

Thanks,


Here is my network topology


++++     ++++   area 0.0.0.0   ++++
+R4+++++++R1++++++++++++++++++++R2+
++++  +  ++++                  ++++
     +
area 0.0.0.1
     +
    ++++
    +R5+
    ++++
     +
     + (external RIP)
    ++++
    +R6+
    ++++

R1 Config:
router-id 192.0.0.1
network 192.168.10.0/24 area 0.0.0.0
network 192.168.20.0/24 area 0.0.0.1
area 0.0.0.1 nssa translate-candidate

R2 config:
router-id 192.0.0.2
network 192.168.10.0/24 area 0.0.0.0

R4 config:
router-id 192.0.0.4
network 192.168.20.0/24 area 0.0.0.1
area 0.0.0.1 nssa translate-candidate

R5 Config:
router ospf
 ospf router-id 192.0.0.5
 network 192.168.20.0/24 area 0.0.0.1
 redistribute rip
 redistribute connected
 area 0.0.0.1 nssa translate-candidate
!
router rip
 version 2
 network 192.168.40.0/24

R6 Config:
router rip
 version 2
 network 192.168.40.0/24


</PRE><BR><span
style='font-size:8.0pt;font-family:"Arial","sans-serif";color:#003366'>
_____________________________________________________<BR>
This electronic message and any files transmitted with it contains<BR>
information from iDirect, which may be privileged, proprietary<BR>
and/or confidential. It is intended solely for the use of the individual<BR>
or entity to whom they are addressed. If you are not the original<BR>
recipient or the person responsible for delivering the email to the<BR>
intended recipient, be advised that you have received this email<BR>
in error, and that any use, dissemination, forwarding, printing, or<BR>
copying of this email is strictly prohibited. If you received this email<BR>
in error, please delete it and immediately notify the sender.<BR>
_____________________________________________________
</SPAN><PRE>



------------------------------

[Attachment #5 (text/html)]

Dear &quot;Wu, Yiwen&quot; and Quagga users/devs,<br><br><br>This is not a final \
email concerning the issue as I continue to investigate.<br><br>I can confirm \
OP&#39;s behavior, but must also add it is intermittent and until now I&#39;m not \
able to reproduce the issue consistently.<br> <br>Often, but not always the erroneous \
behavior shows at cold boot of the ABR, sometimes also on the restart of zebra and \
ospfd (with a 40 second delay between daemon kill and start). Until now, the issue \
never showed itself during ospfd restart (with or without a 40 second sleep in \
between).<br> <br>Roughly 60 tests were done until now.<br>  Breakdown:<br>    A few \
tests on the ABR with zebra and ospfd killed, 40 second sleep and zebra started, 1 \
second sleep and ospfd started. The reported issue did occur at least once.<br>  \
Around 10 tests on the ABR to kill zebra and ospfd, wait 40 second and reboot the \
machine. Plm 40% of the time the issue showed.<br>    Around 10 tests on the ABR to \
kill zebra and ospfd, wait 40 seconds and restart zebra and ospfd immediately after \
each other. Also a plm 40% the issue showed.<br>  Around 10 tests on the ABR having \
the connected routers running and cold boot the ABR. Again plm 40% score<br>    \
Around 15 tests on the ABR restarting the ospf daemon without sleep time. Never got \
the issue.<br>    Remaining test on the ASBR or the router between the ASBR and the \
ABR stopping ospfd with and without sleep time and also reboots. No statistics.<br> \
<br>The interfaces get their IP address from zebra. I will test if it makes a \
difference if Linux does the IP setting and will report back to you.<br><br><br>Test \
environment:<br><br>All machines:<br># uname -a<br>Linux ...... \
2.6.18-128.1.10.el5.xs5.5.0.

51xen #1 SMP Fri May 29 06:29:19 EDT 2009 i686 athlon i386 GNU/Linux<br>aka Centos 5 \
x86 on Citrix Xenserver 5.6.0.<br><br>ASBR (nssa), ABR, router in between \
(nssa):<br>Quagga-0.99.17 (release)<br><br>Directly connected (area 0) router to \
ABR:<br> Quagga-0.99.8 (release)<br><br>All hello and dead timers for these routers \
are default.<br><br><br>Regards and cheers,<br><br>Han<br><br>Date: Tue, 28 Dec 2010 \
                11:42:01 -0500<br>
From: &quot;Wu, Yiwen&quot; &lt;<a \
                href="mailto:ywu@idirect.net">ywu@idirect.net</a>&gt;<br>
To: &lt;<a href="mailto:quagga-users@lists.quagga.net">quagga-users@lists.quagga.net</a><div \
                id=":no">&gt;<br>
Subject: [quagga-users 12034] ospfd nssa issue<br>
Message-ID:<br>
        &lt;<a href="mailto:C874DBE9D30B584587F8CD0EC34DA8BE1A27DC19@EX00.idirect.net">C874DBE9D30B584587F8CD0EC34DA8BE1A27DC19@EX00.idirect.net</a>&gt;<br>
                
Content-Type: text/plain; charset=&quot;us-ascii&quot;<br>
<br>
Hi all,<br>
<br>
I got great trouble to make ospfd NSSA working. Router R6 injects two<br>
extern routes <a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a> and <a \
href="http://10.0.0.1/24" target="_blank">10.0.0.1/24</a> and R5 redistributes these \
two<br> routes to OSPF. I am seeing a few strange thing:<br>
<br>
1. when doing &quot;sh ip ospf border-router&quot; on R2~R5, it shows that R1 is<br>
ASBR and ABR. It didn&#39;t happen when using the same topology but no NSSA.<br>
<br>
2. The two external routes didn&#39;t appear in R2&#39;s RIB. I turned on debug<br>
in R1 and found the following word in the ospfd.log file for each Type 7<br>
message R1 receives.<br>
<br>
&quot;OSPF: Route[External]: Can&#39;t find originating ASBR route&quot;<br>
<br>
Does anyone see the similar thing before?<br>
<br>
Thanks,<br>
<br>
<br>
Here is my network topology<br>
<br>
<br>
++++     ++++   area 0.0.0.0   ++++<br>
+R4+++++++R1++++++++++++++++++++R2+<br>
++++  +  ++++                  ++++<br>
      +<br>
area 0.0.0.1<br>
      +<br>
     ++++<br>
     +R5+<br>
     ++++<br>
      +<br>
      + (external RIP)<br>
     ++++<br>
     +R6+<br>
     ++++<br>
<br>
R1 Config:<br>
router-id 192.0.0.1<br>
network <a href="http://192.168.10.0/24" target="_blank">192.168.10.0/24</a> area \
0.0.0.0<br> network <a href="http://192.168.20.0/24" \
target="_blank">192.168.20.0/24</a> area 0.0.0.1<br> area 0.0.0.1 nssa \
translate-candidate<br> <br>
R2 config:<br>
router-id 192.0.0.2<br>
network <a href="http://192.168.10.0/24" target="_blank">192.168.10.0/24</a> area \
0.0.0.0<br> <br>
R4 config:<br>
router-id 192.0.0.4<br>
network <a href="http://192.168.20.0/24" target="_blank">192.168.20.0/24</a> area \
0.0.0.1<br> area 0.0.0.1 nssa translate-candidate<br>
<br>
R5 Config:<br>
router ospf<br>
  ospf router-id 192.0.0.5<br>
  network <a href="http://192.168.20.0/24" target="_blank">192.168.20.0/24</a> area \
0.0.0.1<br>  redistribute rip<br>
  redistribute connected<br>
  area 0.0.0.1 nssa translate-candidate<br>
!<br>
router rip<br>
  version 2<br>
  network <a href="http://192.168.40.0/24" target="_blank">192.168.40.0/24</a><br>
<br>
R6 Config:<br>
router rip<br>
  version 2<br>
  network <a href="http://192.168.40.0/24" target="_blank">192.168.40.0/24</a><br>
<br>
<br>
&lt;/PRE&gt;&lt;BR&gt;&lt;span \
style=&#39;font-size:8.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#003366&#39;&gt;<br>
 _____________________________________________________&lt;BR&gt;<br>
This electronic message and any files transmitted with it contains&lt;BR&gt;<br>
information from iDirect, which may be privileged, proprietary&lt;BR&gt;<br>
and/or confidential. It is intended solely for the use of the \
individual&lt;BR&gt;<br> or entity to whom they are addressed. If you are not the \
original&lt;BR&gt;<br> recipient or the person responsible for delivering the email \
to  the&lt;BR&gt; intended recipient, be advised that you have received this
 email&lt;BR&gt;<br>
in error, and that any use, dissemination, forwarding, printing, 
or&lt;BR&gt; copying of this email is strictly prohibited. If you 
received this email&lt;BR&gt;<br>
in error, please delete it and immediately notify the sender.&lt;BR&gt;<br>
_____________________________________________________<br>
&lt;/SPAN&gt;&lt;PRE&gt;<br>
<br>
<br>
<br>
------------------------------<br>
</div><div style="visibility: hidden; left: -5000px; position: absolute; z-index: \
9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden; word-wrap: \
break-word; color: black; font-size: 10px; text-align: left; line-height: 130%;" \
id="avg_ls_inline_popup"> </div>



_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-users


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic