Subject: Re: SeqNumberMismatch problem

From: "Mollin, Arvind - LiqwidKrystal" <[email-masked]>
Date: Thu, 18 Nov 2004 04:38:52 -0800

pls see ospf debugs in other router. I am sure that router is not misses hello and reintiates neighborship and adjacency. Other than this I don have any clue.
 
Thanks
Arvind

________________________________

From: Mailing List on behalf of Razvan Bruma
Sent: Thu 11/18/2004 3:53 AM
To: [email-masked]
Subject: Re: SeqNumberMismatch problem

Hello,

1. No, I am not implementing any MANET extensions, I'm not sure even if the
router supports them. The link is mainly a wireless bridge between the two
routers.

2. There's no key to 1 hour. The link comes down for no apparent reason
every (roughly) one hour, but this is not a definitive rule. It happens that
everything is ok for 6 hours, let's say, and then I got ten
SeqNumberMismatches in the following 30 minutes.

From what I can see from the various debug outputs that I could get,
something like this happens:

a. Normal hellos are received every 10 sec:

*Mar  4 13:00:50.289: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129
      aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1
*Mar  4 13:01:00.289: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129
      aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1
*Mar  4 13:01:10.289: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129
      aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1

b. Suddenly I have a DD packet that resets the whole damn thing:

*Mar  4 13:01:15.173: OSPF: rcv. v:2 t:2 l:32 rid:172.16.1.129
      aid:0.0.0.0 chk:EA06 aut:0 auk: from Ethernet0/1
*Mar  4 13:01:15.173: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on
Ethernet0/1 from FULL to EXSTART, SeqNumberMismatch
*Mar  4 13:01:15.185: OSPF: rcv. v:2 t:2 l:1432 rid:172.16.1.129
      aid:0.0.0.0 chk:8DFF aut:0 auk: from Ethernet0/1
*Mar  4 13:01:15.185: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on
Ethernet0/1 from EXSTART to EXCHANGE, Negotiation Done
*Mar  4 13:01:15.201: OSPF: rcv. v:2 t:2 l:32 rid:172.16.1.129
      aid:0.0.0.0 chk:783 aut:0 auk: from Ethernet0/1
*Mar  4 13:01:15.205: OSPF: rcv. v:2 t:2 l:32 rid:172.16.1.129
      aid:0.0.0.0 chk:782 aut:0 auk: from Ethernet0/1
*Mar  4 13:01:15.209: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on
Ethernet0/1 from EXCHANGE to LOADING, Exchange Done
*Mar  4 13:01:15.209: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on
Ethernet0/1 from LOADING to FULL, Loading Done

c. Then the process continues normally, until the next DD packet will cause
an error:

*Mar  4 13:01:20.290: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129
      aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1
*Mar  4 13:01:30.287: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129
      aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1

I cannot use a protocol analyzer to see the exact content of each packet and
determine where is the mismatch, because I am in a remote location and I
have to figure out what's happening from here.

There is no MTU mismatch and the neighbors (there's only one neighbor,
actually) are always in FULL. The loading is minimal.

Do I miss anything?

Razvan

----- Original Message -----
From: "Erblichs" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 18, 2004 7:00 AM
Subject: Re: SeqNumberMismatch problem

> Group,
>
>         First are you implimenting the MANET extensions???
>
>         What is the key to 1 hour? Are you doing something
>         verifying that the link is up every hour via the
>         RFC1793 Demand Circuit,  DNA LSAs, and probing?
>
>         Wireless ethernet... Is it possible that multiple
>         nbr hellos are being sent basicly the same time?
>         Are they becoming synchronized? Do you send out
>         your first hellos when you see a hello pkt to get
>         to 2-way quickly? What happens if two nbrs send
>         hellos at the same time in your implimentation?
>
>         Other than the above, I vote for the 2nd...
>
>         Only a reseting of the adj would force repeated
>         initial database syncs.
>
>         A MTU size mismatch would not force the adj to
>         reset. It would prevent a FULL adj from forming
>         in the first place during the initial database
>         exchange or hang depending on the config params.
>
>         So, either a large number of hellos are being dropped
>         which is unlikely, because 1 should get thru in router
>         dead interval timeframe OR a hello is being sent that
>         removes a nbr that WAS Fully adjacent. This is more than
>         likely reseting the adj.
>
>         Either way check the hellos router dead interval
>         timeframe prior to the EXCHANGE state.
>
>         Mitchell Erblich
>         ------------------------
>
>
>
> However, if a hello was sent
>
> "Mollin, Arvind - LiqwidKrystal" wrote:
> >
> > IMHO, One of the reason may be MTU size mismatch. Pls check that you
have configured same MTU size on the both interfaces.
> > Second thing may be that one of the router is missing hellos ( say
router with lesser routerid misses the hello), but the router which is
having higher routerid recieves hellos and assumes that the peer is okay.
Then the router with lesser id tries to go on adjacency after recieving a
hello, that time it sends itself as master, due to this router with higher
routerid throws seq mismatch.
> >
> > Quick Check : See that both routers are always on FULL state ..
> >
> > Arvind
> >
> > ________________________________
> >
> > From: Mailing List on behalf of Razvan Bruma
> > Sent: Wed 11/17/2004 7:54 AM
> > To: [email-masked]
> > Subject: SeqNumberMismatch problem
> >
> > Hello all,
> >
> > I have two cisco 2611 routers connected via a wireless ethernet link.
Every
> > hour (more or less) one SeqNumberMismatch is recorded into the logging
> > buffer, with all the consequences: back to EXCHANGE, bring up the backup
> > line, etc.
> >
> > I know (theoretically) what causes this event. Any ideas on what
> > (practically) can happen? What errors of transmission or otherwise can
> > produce the mismatch ?
> >
> > Thanks
> >
> > Razvan
>

---

From: Acee Lindem <[email-masked]>
Date: Thu, 18 Nov 2004 12:09:59 -0500

>pls see ospf debugs in other router. I am sure that router is not misses hello and reintiates neighborship and adjacency. Other than this I don have any clue.

I think you are on the right track. My suspicion is that the other
router is experiencing
some event (probably an interface flap) which causes it to lose the
adjacency. It then
receives a hello with it's own router ID before sending one of its own.
It goes to
ExchangeStart state and sends an initial DD packet causing the SeqNumber
Mismatch.
In any case debugging on the other router is necessary.

Hope this helps,
Acee