Re: DB Synchronization

Acee Lindem <acee@REDBACK.COM> Tue, 02 September 2003 18:32 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24723 for <ospf-archive@LISTS.IETF.ORG>; Tue, 2 Sep 2003 14:32:58 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00B2FB02@cherry.ease.lsoft.com>; Tue, 2 Sep 2003 14:33:00 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 53548083 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 2 Sep 2003 14:32:55 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 2 Sep 2003 14:32:55 -0400
Received: from redback.com (pptp-6-157.redback.com [155.53.6.157]) by prattle.redback.com (Postfix) with ESMTP id DEC1985C000 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 2 Sep 2003 11:31:21 -0700 (PDT)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <LISTSERV%2003082313022444@PEACH.EASE.LSOFT.COM> <3F47A2B0.6020808@redback.com> <001301c36e50$d2949de0$cbc8c8c8@sdksoft.com> <3F4F9310.7000300@redback.com> <003701c36e58$747e0860$cbc8c8c8@sdksoft.com> <3F4FDAED.7020504@redback.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <3F54E1F3.9020907@redback.com>
Date: Tue, 02 Sep 2003 14:31:15 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: DB Synchronization
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <3F4FDAED.7020504@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

If the everything matches between restarts (type, LS ID, advertising
router,
initial sequence number,  and  checksum) , I  don't see  any solution in
the
base protocol specification.

However, a router performing graceful restart will initially accept it's
pre-restart
LSAs. Hence,  when graceful restart terminates the restarting router will
originate a new LSA and purge the stale one.

Rikki Nguyen wrote:

> 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.
>
> Parag Deshpande wrote:
>
>> 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
>>
>> ----- Original Message -----
>> From: Rikki Nguyen <rikki@REDBACK.COM>
>> To: <OSPF@PEACH.EASE.LSOFT.COM>
>> Sent: Friday, August 29, 2003 12:53 PM
>> Subject: Re: DB Synchronization
>>
>>
>>
>>> Parag Deshpande wrote:
>>>
>>>> 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.
>>>
>>>
>>> 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.
>>>
>>>
>>>> I was wondering whether this can be resolved faster.
>>>>
>>>> Thanks
>>>> Parag
>>>>
>>>
>>
>