Subject: Re: SeqNumberMismatch problem

From: "Mollin, Arvind - LiqwidKrystal" <[email-masked]>
Date: Wed, 17 Nov 2004 18:55:23 -0800

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: Erblichs <[email-masked]>
Date: Wed, 17 Nov 2004 21:00:25 -0800

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

---

From: Razvan Bruma <[email-masked]>
Date: Thu, 18 Nov 2004 13:53:37 +0200

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

> > 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.