Subject: [OSPF] Fwd: OSPFquestion

From: Mitchell Erblich <[email-masked]>
Date: Thu, 18 Jun 2009 16:30:46 -0700

Begin forwarded message:

> From: Mitchell Erblich <[email-masked]>
> Date: June 18, 2009 4:27:54 PM PDT
> To: "Hitesh N. Patel" <[email-masked]>
> Subject: Re: [OSPF] OSPFquestion
>
> Hi,
>
> 	Are you using routers from an established company because
> 	this seems like a fundamental problem?
>
> 	If you are looking on a time line and the first bad things are
> 	BadLSReq message on one device & SeqNumberMismatch
> 	on other device.
> 	
> 	then stop...
>
> 	Why the Bad Seguence Number? from rfc 2328
>
> 	
>
> 	ExStart
>             If the received packet matches one of the following cases,
>             then the neighbor state machine should be executed with  
> the
>             event NegotiationDone (causing the state to transition to
>             Exchange), the packet's Options field should be recorded  
> in
>             the neighbor structure's Neighbor Options field and the
>             packet should be accepted as next in sequence and  
> processed
>             further (see below).  Otherwise, the packet should be
>             ignored.
>
>             o   The initialize(I), more (M) and master(MS) bits are  
> set,
>                 the contents of the packet are empty, and the  
> neighbor's
>                 Router ID is larger than the router's own.  In this  
> case
>                 the router is now Slave.  Set the master/slave bit to
>                 slave, and set the neighbor data structure's DD  
> sequence
>                 number to that specified by the master.
>
>             o   The initialize(I) and master(MS) bits are off, the
>                 packet's DD sequence number equals the neighbor data
>                 structure's DD sequence number (indicating
>                 acknowledgment) and the neighbor's Router ID is  
> smaller
>                 than the router's own.  In this case the router is
>                 Master.
>
>         Exchange
>             Duplicate Database Description packets are discarded by  
> the
>             master, and cause the slave to retransmit the last  
> Database
>             Description packet that it had sent. Otherwise (the packet
>             is not a duplicate):
>
>             o   If the state of the MS-bit is inconsistent with the
>                 master/slave state of the connection, generate the
>                 neighbor event SeqNumberMismatch and stop processing  
> the
>                 packet.
>
>             o   If the initialize(I) bit is set, generate the neighbor
>                 event SeqNumberMismatch and stop processing the  
> packet.
>
> 	Mitchell Erblich
> 	=============================
>
>
>
> On Jun 18, 2009, at 3:27 PM, Hitesh N. Patel wrote:
>
>> Hi Mitchell, Vishwas,
>>
>> I have verified MTU & mtu is configured correctly. also, I am  
>> establishing OSPF v2 point to point neighborship.
>>
>> I also observed  immediately after seeing this message, both the  
>> device progress from EXCHANGE to EXSTART state, & OSPF converges  
>> quickly (within 20 seconds) from then on..however it takes about  
>> 14-15 minutes for device to detect BadLSReq & SeqNumberMismatch  
>> error, till then both the device remains busy doing LSA EXCHANGE.
>>
>> I also observed one more thing, that while I was resetting OSPF on  
>> one device by using clear ip ospf xxx process command, it takes  
>> above mentioned process to restore FULL Adjacency but if I reset  
>> OSPF by doing "shut" & "no shut" on interfaces (as OSPF  
>> neighborship is between point to point network), OSPF convergence  
>> time is  about 20 seconds.
>>
>> So, after reviewing above fact, it looks to me that, when I do  
>> "clear ip ospf", OSPF does clear the LSA database however it  
>> probably mark a delete flag for the LSAs & advertise it to neighbor  
>> before actually deleting it, so probably when both the devices are  
>> in EXCHANGE state, they do receive the "about to get deleted" LSA  
>> details & event of BadLSReq or SeqNumberMismatch error occures when  
>> neighbor receives actual LSRequest for the deleted LSA. Also, I  
>> observed that out of 2 device, other than the one of which I am  
>> executing "clear ip ospf" command is continueously sending LSA  
>> Update packets. so, I really doubt that doing a "clear ip ospf"  
>> when LSAs are being received is the right thing..as compared to  
>> "shut" & "no shut" for verifying OSPF convergence time. Do let me  
>> know your thoughts on this..
>>
>> Thanks so much for sharing this technical issue.
>>
>> Regards,
>> Hitesh
>>
>>
>>
>>
>>
>> On Thu, Jun 18, 2009 at 4:23 PM, Mitchell Erblich <[email-masked] 
>> > wrote:
>> First,
>>
>>        Turn on debuging.
>>
>>        Tell us whether you are running v2 or v3 OSPF.
>>
>>        Drop messages are due to buffer overflow or MTU mismatch or
>>        unknown LSA type or auth failure or capability not  
>> understood or
>>        a DNA (do not age LSA) not supported or LSA max age or LSA
>>        corruption or ......  etc..
>>
>>        Hopefully the debug prints out what one nbr specified in its  
>> LSDB,
>>        then what was REQuested, and then the breakdown for the BAD
>>        REQUEST.
>>
>>        Either way, the message/LSA should initially be resent when  
>> not
>>        acked.
>>
>>        I said initially because some routers will retry X number
>>        of times with a nbr and then give up. So, you may want to
>>        first take down the interface, turn on debugging, then bring
>>        back the interface.
>>
>>        FYI: All draft, experimental, and informational OSPF RFCs
>>        should be found within the www.ietf.org website.
>>
>>        Mitchell Erblich
>>        ================
>>
>>
>>
>> On Jun 18, 2009, at 12:40 PM, Vishwas Manral wrote:
>>
>> Hi Hitesh,
>>
>> The problem is in the DB Exchange process. The point is either an LSA
>> is requested for which is not in the database or an LSA is got which
>> is also on the sending neighbor link state request list. With  
>> BadLSReq
>> the neigbor state should go to Exstart (which seems to be wrong too  
>> in
>> your implementation).
>>
>> RFC2328 would be a good read for this. Maybe someone else in the OPSF
>> list has some other suggestions.
>>
>> Thanks,
>> Vishwas
>> ________________________________________
>> From: Hitesh N. Patel [mailto:[email-masked]]
>> Sent: Thursday, June 18, 2009 11:47 AM
>> To: vishwas
>> Subject: OSPFquestion
>>
>> Hi Vishwas,
>>
>> I have been working on OSPF & have observed several documents by you
>> on OSPF & thought to pose you a question..Can you suggest something  
>> to
>> resolve BadLSReq, our LSA database size is <1000 & have point to  
>> point
>> link between pair of Router, however RT1 shows FULL state while RT2
>> remains stuck in LOADING state & after 7-8 minutes it shows BadLSReq
>> message & transitions to LOADING to EXTRART state & then it quickly
>> converge from LOADING to FULL. Also, sometimes I see OSPF : Drop
>> Packet messages too frequently.
>>
>> Is there any reading that you can suggest for this OSPF behaviour?
>>
>> Thanks,
>> Hitesh Patel
>> _______________________________________________
>> OSPF mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ospf
>>
>>
>

---

From: Santanu Paul <[email-masked]>
Date: Thu, 18 Jun 2009 23:10:32 -0700

however RT1 shows FULL state while RT2 remains stuck in LOADING state & after 7-8 minutes it shows BadLSReq message & transitions to LOADING to EXTRART state & then it quickly converge from LOADING to FULL.

[Santanu] Assuming, RT1 has around 1000 LSAs and RT2 has none, so it is expected that RT1 will go to FULL state fast, while RT2 will be in loading to synchronize database, however 7-8 minutes for <1000 LSAs seems too high, you need to do a packet capture to see what is going on. Check in the capture what LSA headers RT1 sent, and what request RT2 has sent, if any request is not corresponding to the LSA headers it has received in DBD RT1 will generate BadLSReq

I also observed  immediately after seeing this message, both the device progress from EXCHANGE to EXSTART state, & OSPF converges quickly (within 20 seconds) from then on..however it takes about 14-15 minutes for device to detect BadLSReq & SeqNumberMismatch error, till then both the device remains busy doing LSA EXCHANGE.

[Santanu] Could not understand the part "however it takes about 14-15 minutes for device to detect BadLSReq & SeqNumberMismatch error" could you elaborate, is it happening after going to FULL?

I also observed one more thing, that while I was resetting OSPF on one device by using clear ip ospf xxx process command, it takes above mentioned process to restore FULL Adjacency but if I reset OSPF by doing "shut" & "no shut" on interfaces (as OSPF neighborship is between point to point network), OSPF convergence time is  about 20 seconds.

[Santanu] Not sure what router you are using, but generally "clear process", clears LSDB but "shut and no-shut" does not, if that is the case "shut no shut" will converge quickly as you might not see LS requests at all.

So, after reviewing above fact, it looks to me that, when I do "clear ip ospf", OSPF does clear the LSA database however it probably mark a delete flag for the LSAs & advertise it to neighbor before actually deleting it, so probably when both the devices are in EXCHANGE state, they do receive the "about to get deleted" LSA details & event of BadLSReq or SeqNumberMismatch error occures when neighbor receives actual LSRequest for the deleted LSA. Also, I observed that out of 2 device, other than the one of which I am executing "clear ip ospf" command is continueously sending LSA Update packets. so, I really doubt that doing a "clear ip ospf" when LSAs are being received is the right thing..as compared to "shut" & "no shut" for verifying OSPF convergence time. Do let me know your thoughts on this..

[Santanu] Verify capturing the packet and router database.

Thanks and Regards,

Santanu Paul

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mitchell Erblich
Sent: Friday, June 19, 2009 5:01 AM
To: OSPF List
Subject: [OSPF] Fwd: OSPFquestion

Begin forwarded message:

From: Mitchell Erblich <[email-masked]<mailto:[email-masked]>>
Date: June 18, 2009 4:27:54 PM PDT
To: "Hitesh N. Patel" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OSPF] OSPFquestion

Hi,

            then stop...

            ExStart

            then the neighbor state machine should be executed with the

            Exchange), the packet's Options field should be recorded in

            packet should be accepted as next in sequence and processed

            ignored.

            o   The initialize(I), more (M) and master(MS) bits are set,

                the contents of the packet are empty, and the neighbor's

                Router ID is larger than the router's own.  In this case

                slave, and set the neighbor data structure's DD sequence

                acknowledgment) and the neighbor's Router ID is smaller

                Master.

        Exchange

            Duplicate Database Description packets are discarded by the

            master, and cause the slave to retransmit the last Database

            is not a duplicate):

                neighbor event SeqNumberMismatch and stop processing the

                packet.

                event SeqNumberMismatch and stop processing the packet.

          Mitchell Erblich

Hi Mitchell, Vishwas,

I have verified MTU & mtu is configured correctly. also, I am establishing OSPF v2 point to point neighborship.

I also observed  immediately after seeing this message, both the device progress from EXCHANGE to EXSTART state, & OSPF converges quickly (within 20 seconds) from then on..however it takes about 14-15 minutes for device to detect BadLSReq & SeqNumberMismatch error, till then both the device remains busy doing LSA EXCHANGE.

I also observed one more thing, that while I was resetting OSPF on one device by using clear ip ospf xxx process command, it takes above mentioned process to restore FULL Adjacency but if I reset OSPF by doing "shut" & "no shut" on interfaces (as OSPF neighborship is between point to point network), OSPF convergence time is  about 20 seconds.

So, after reviewing above fact, it looks to me that, when I do "clear ip ospf", OSPF does clear the LSA database however it probably mark a delete flag for the LSAs & advertise it to neighbor before actually deleting it, so probably when both the devices are in EXCHANGE state, they do receive the "about to get deleted" LSA details & event of BadLSReq or SeqNumberMismatch error occures when neighbor receives actual LSRequest for the deleted LSA. Also, I observed that out of 2 device, other than the one of which I am executing "clear ip ospf" command is continueously sending LSA Update packets. so, I really doubt that doing a "clear ip ospf" when LSAs are being received is the right thing..as compared to "shut" & "no shut" for verifying OSPF convergence time. Do let me know your thoughts on this..

Regards,
Hitesh

On Thu, Jun 18, 2009 at 4:23 PM, Mitchell Erblich <[email-masked]<mailto:[email-masked]>> wrote:
First,

       Turn on debuging.

       Drop messages are due to buffer overflow or MTU mismatch or
       unknown LSA type or auth failure or capability not understood or
       a DNA (do not age LSA) not supported or LSA max age or LSA
       corruption or ......  etc..

       Hopefully the debug prints out what one nbr specified in its LSDB,
       then what was REQuested, and then the breakdown for the BAD
       REQUEST.

       Either way, the message/LSA should initially be resent when not
       acked.

       FYI: All draft, experimental, and informational OSPF RFCs
       should be found within the www.ietf.org<http://www.ietf.org/> website.

       Mitchell Erblich
       ================

The problem is in the DB Exchange process. The point is either an LSA
is requested for which is not in the database or an LSA is got which
is also on the sending neighbor link state request list. With BadLSReq
the neigbor state should go to Exstart (which seems to be wrong too in
your implementation).

Thanks,
Vishwas
________________________________________
From: Hitesh N. Patel [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, June 18, 2009 11:47 AM
To: vishwas
Subject: OSPFquestion

Hi Vishwas,

I have been working on OSPF & have observed several documents by you
on OSPF & thought to pose you a question..Can you suggest something to
resolve BadLSReq, our LSA database size is <1000 & have point to point
link between pair of Router, however RT1 shows FULL state while RT2
remains stuck in LOADING state & after 7-8 minutes it shows BadLSReq
message & transitions to LOADING to EXTRART state & then it quickly
converge from LOADING to FULL. Also, sometimes I see OSPF : Drop
Packet messages too frequently.

Thanks,
Hitesh Patel
_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

---

From: "Hitesh N. Patel" <[email-masked]>
Date: Fri, 19 Jun 2009 11:52:15 -0400

Hi Santanu,

Thanks for the reply.

Revised LSA database size that I am seeing is about 26K, however
observations suggest that convergence time doesn't improve even with small
LSA database size.
Convergence time is about 18 minutes & if I do packet capture, it does show
that RT2 is continueously sending LS Update packets & RT1 keeps sending LS
Ack packets, while sometimes I do observe "Receive same LSA" messages. Also,
as you mentioned, "shut" & "no shut" is not clearing a OSPF LSA database.

I am wondering if high convergence time has anything to do with LSRefresh
time (30 minutes) when Bad LSA gets cleared on either RT1/RT2 & beyond then
convergence happen quickly.
Thanks,
Hitesh

On Fri, Jun 19, 2009 at 2:10 AM, Santanu Paul <[email-masked]> wrote:

>   however RT1 shows FULL state while RT2 remains stuck in LOADING state &
> after 7-8 minutes it shows BadLSReq message & transitions to LOADING to
> EXTRART state & then it quickly converge from LOADING to FULL.
>
>
>
> [Santanu] Assuming, RT1 has around 1000 LSAs and RT2 has none, so it is
> expected that RT1 will go to FULL state fast, while RT2 will be in loading
> to synchronize database, however 7-8 minutes for <1000 LSAs seems too high,
> you need to do a packet capture to see what is going on. Check in the
> capture what LSA headers RT1 sent, and what request RT2 has sent, if any
> request is not corresponding to the LSA headers it has received in DBD RT1
> will generate BadLSReq
>
>
>
>
>
> I also observed  immediately after seeing this message, both the device
> progress from EXCHANGE to EXSTART state, & OSPF converges quickly (within 20
> seconds) from then on..however it takes about 14-15 minutes for device to
> detect BadLSReq & SeqNumberMismatch error, till then both the device remains
> busy doing LSA EXCHANGE.
>
>
>
> [Santanu] Could not understand the part “however it takes about 14-15
> minutes for device to detect BadLSReq & SeqNumberMismatch error” could you
> elaborate, is it happening after going to FULL?
>
>
>
> I also observed one more thing, that while I was resetting OSPF on one
> device by using clear ip ospf xxx process command, it takes above mentioned
> process to restore FULL Adjacency but if I reset OSPF by doing "shut" & "no
> shut" on interfaces (as OSPF neighborship is between point to point
> network), OSPF convergence time is  about 20 seconds.
>
>
>
> [Santanu] Not sure what router you are using, but generally “clear
> process”, clears LSDB but “shut and no-shut” does not, if that is the case
> “shut no shut” will converge quickly as you might not see LS requests at
> all.
>
>
>
> So, after reviewing above fact, it looks to me that, when I do "clear ip
> ospf", OSPF does clear the LSA database however it probably mark a delete
> flag for the LSAs & advertise it to neighbor before actually deleting it, so
> probably when both the devices are in EXCHANGE state, they do receive the
> "about to get deleted" LSA details & event of BadLSReq or SeqNumberMismatch
> error occures when neighbor receives actual LSRequest for the deleted LSA.
> Also, I observed that out of 2 device, other than the one of which I am
> executing "clear ip ospf" command is continueously sending LSA Update
> packets. so, I really doubt that doing a "clear ip ospf" when LSAs are being
> received is the right thing..as compared to "shut" & "no shut" for verifying
> OSPF convergence time. Do let me know your thoughts on this..
>
>
>
> *Santanu Paul*
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Mitchell Erblich
> *Sent:* Friday, June 19, 2009 5:01 AM
> *To:* OSPF List
> *Subject:* [OSPF] Fwd: OSPFquestion
>
>
>
>
>
>
>
> Begin forwarded message:
>
>
>
>  *From: *Mitchell Erblich <[email-masked]>
>
> *Date: *June 18, 2009 4:27:54 PM PDT
>
> *To: *"Hitesh N. Patel" <[email-masked]>
>
> *Subject: **Re: [OSPF] OSPFquestion*
>
>
>
> Hi,
>
>
>
> I also observed  immediately after seeing this message, both the device
> progress from EXCHANGE to EXSTART state, & OSPF converges quickly (within 20
> seconds) from then on..however it takes about 14-15 minutes for device to
> detect BadLSReq & SeqNumberMismatch error, till then both the device remains
> busy doing LSA EXCHANGE.
>
>
>
> I also observed one more thing, that while I was resetting OSPF on one
> device by using clear ip ospf xxx process command, it takes above mentioned
> process to restore FULL Adjacency but if I reset OSPF by doing "shut" & "no
> shut" on interfaces (as OSPF neighborship is between point to point
> network), OSPF convergence time is  about 20 seconds.
>
>
>
> So, after reviewing above fact, it looks to me that, when I do "clear ip
> ospf", OSPF does clear the LSA database however it probably mark a delete
> flag for the LSAs & advertise it to neighbor before actually deleting it, so
> probably when both the devices are in EXCHANGE state, they do receive the
> "about to get deleted" LSA details & event of BadLSReq or SeqNumberMismatch
> error occures when neighbor receives actual LSRequest for the deleted LSA.
> Also, I observed that out of 2 device, other than the one of which I am
> executing "clear ip ospf" command is continueously sending LSA Update
> packets. so, I really doubt that doing a "clear ip ospf" when LSAs are being
> received is the right thing..as compared to "shut" & "no shut" for verifying
> OSPF convergence time. Do let me know your thoughts on this..
>
>
>
> On Thu, Jun 18, 2009 at 4:23 PM, Mitchell Erblich <[email-masked]>
> wrote:
>
> First,
>
>        Turn on debuging.
>

---

From: Dave Katz <[email-masked]>
Date: Fri, 19 Jun 2009 11:19:09 -0500

Please take this off the list and take it up with your vendor.  There  
is a bug here.

(If you're the vendor, go back and read the spec carefully...)

--Dave

On Jun 19, 2009, at 10:52 AM, Hitesh N. Patel wrote:

> observations suggest that convergence time doesn't improve even with  
> small LSA database size.
> Convergence time is about 18 minutes & if I do packet capture, it  
> does show that RT2 is continueously sending LS Update packets & RT1  
> keeps sending LS Ack packets, while sometimes I do observe "Receive  
> same LSA" messages. Also, as you mentioned, "shut" & "no shut" is  
> not clearing a OSPF LSA database.
>
> I am wondering if high convergence time has anything to do with  
> LSRefresh time (30 minutes) when Bad LSA gets cleared on either RT1/ 
> RT2 & beyond then convergence happen quickly.
> Thanks,
> Hitesh
>
> however RT1 shows FULL state while RT2 remains stuck in LOADING  
> state & after 7-8 minutes it shows BadLSReq message & transitions to  
> LOADING to EXTRART state & then it quickly converge from LOADING to  
> FULL.
>
>
> [Santanu] Assuming, RT1 has around 1000 LSAs and RT2 has none, so it  
> is expected that RT1 will go to FULL state fast, while RT2 will be  
> in loading to synchronize database, however 7-8 minutes for <1000  
> LSAs seems too high, you need to do a packet capture to see what is  
> going on. Check in the capture what LSA headers RT1 sent, and what  
> request RT2 has sent, if any request is not corresponding to the LSA  
> headers it has received in DBD RT1 will generate BadLSReq
>
>
>
> [Santanu] Could not understand the part “however it takes about  
> error” could you elaborate, is it happening after going to FULL?
>
>
> OSPF by doing "shut" & "no shut" on interfaces (as OSPF neighborship  
> is between point to point network), OSPF convergence time is  about  
> 20 seconds.
>
>
> process”, clears LSDB but “shut and no-shut” does not, if that is  
> the case “shut no shut” will converge quickly as you might not see  
> LS requests at all.
>
>
> Update packets. so, I really doubt that doing a "clear ip ospf" when  
> LSAs are being received is the right thing..as compared to "shut" &  
> "no shut" for verifying OSPF convergence time. Do let me know your  
> thoughts on this..
>
>
> OSPF by doing "shut" & "no shut" on interfaces (as OSPF neighborship  
> is between point to point network), OSPF convergence time is  about  
> 20 seconds.
>
>
> Update packets. so, I really doubt that doing a "clear ip ospf" when  
> LSAs are being received is the right thing..as compared to "shut" &  
> "no shut" for verifying OSPF convergence time. Do let me know your  
> thoughts on this..
>
>