Subject: Action on SeqNumberMismatch

From: Igor Miroshnik <[email-masked]>
Date: Sat, 23 Aug 2003 13:02:24 -0400

All,

RFC 2328 says:

"  State(s):  Exchange or greater

     Event:  SeqNumberMismatch

 New state:  ExStart

    Action:  The (possibly partially formed) adjacency is torn
      down, and then an attempt is made at
      reestablishment.  The neighbor state first
      transitions to ExStart.  The Link state
      retransmission list, Database summary list and Link
      state request list are cleared of LSAs.  Then the
      router increments the DD sequence number in the
      neighbor data structure, declares itself master
      (sets the master/slave bit to master), and starts
      sending Database Description Packets, with the
      initialize (I), more (M) and master (MS) bits set.
      This Database Description Packet should be otherwise
      empty (see Section 10.8)."

Questions:

1) Is the Database Description Packet sent empty?
2) If so, what is the meaning of the word "otherwise" in the end of the
quotaton?

Thanks,
Igor

---

From: Acee Lindem <[email-masked]>
Date: Sat, 23 Aug 2003 13:21:52 -0400

Hi  Igor,

>1) Is the Database Description Packet sent empty?
Yes.

>2) If so, what is the meaning of the word "otherwise" in the end of the
It means that the DD packet only contains the OSPF header and the fixed
portion of the DD
packet (i.e., interface mtu, options,  DD bits, and DD sequence number).

---

From: Parag Deshpande <[email-masked]>
Date: Fri, 29 Aug 2003 12:13:10 -0500

Hi,

I had a doubt ->

2 routers A and B have an ospf adjacency.

Router A sends an ASExt lsa for network N1/m1 with LSID = N1.
Then Router A goes down & comes up again & reoriginates
ASExt lsa for network N1/m2 with LSID = N1 and then
gets adjacent with Router B.

**where m1 != m2 & they are multiple of 8. (/8, /16..)
also assuming that all other parameters are same.

However in this case the DB Exchange will fail to
synchronize these LSAs bcoz they appear
to be similar- LSID, SeqNum, Checksums being equal**
and thus will have to wait for the LSA to get refreshed.

I was wondering whether this can be resolved faster.

Thanks
Parag

---

From: Rikki Nguyen <[email-masked]>
Date: Fri, 29 Aug 2003 10:53:20 -0700

> and thus will have to wait for the LSA to get refreshed.

The checksum is computed over the entire LSA body,
this includes the netmask.  Since the netmasks are
different, it would be difficult for the checksum
to be the same.

---

From: Parag Deshpande <[email-masked]>
Date: Fri, 29 Aug 2003 13:07:48 -0500

I ran a small program with the following values -

In this case the checksums are always the same! because
m1 & m2 are multiple of 8.
m1= 16 m2 = 24. ( also 8, 32)

CK_SUM({00, 00, 00, FF}, 4) = CK_SUM( {00,00,FF,FF}, 4)
= CK_SUM( {00,FF,FF,FF},  4) = CK_SUM( {FF,FF,FF,FF}, 4)
= 0xFFFF

(It does not matter what N1 is)

Or I am goofing up somewhere :-)

Parag

---

From: Rikki Nguyen <[email-masked]>
Date: Fri, 29 Aug 2003 15:59:57 -0700

You seem to be correct.  I missed the part about the netmasks.
The zero and negative-zero (0xff) has the same affect on
the checksum, hence they end up being the same.  I don't see
any other way of correcting this besides forcibly sending
LS-Requests for self-originated LSA's.