[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OSPF LSID with vary length masks



Title: RE: OSPF LSID with vary length masks

Thanks guys for the quick response, I know what I am going to do about the LSAs with the duplicate LSID.

The two LSAs that I mentioned in the example were both from the same third party device:
LSA 1: LsType= 5, LSID=203.177.61.15, mask=255.255.255.240, advRtr=10.235.62.11, seq=0x80000001.
LSA 2: LsType= 5, LSID=203.177.61.15, mask=255.255.255.255, advRtr=10.235.62.11, seq=0x80000002.

It is also observed that both Cisco and Juniper routers in that network replaced LSA 1 with LSA 2 in their database.

Thanks again,

Zhaoyang


-----Original Message-----
From: Mailing List [mailto:OSPF at PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem
Sent: Friday, April 15, 2005 9:42 AM
To: OSPF at PEACH.EASE.LSOFT.COM
Subject: Re: OSPF LSID with vary length masks

Corrected prefix lengths in example.

Tom Petch wrote:

>Agree with everything Dave saids but would stress that OSPF by design does not
>cater for overlapping prefix (from the same router) so a router MUST NOT
>originate two LSA, one a /24 and the other a /28 for the same prefix.  Other
>routing protocols are different which is an issue when redistributing from them
>into OSPF.

>
Hi Tom,
Actually the algorithm in RFC 2328 appendix E handles the situation
above quite nicely. For example, if you want to advertise 10.1.1.0/24
and 10.1.1.0/28 the LSIDs 10.1.1.0 and 10.1.1.15 will be used. The cases
it doesn't handle are the more pathological ones. For example, say
you now also want to advertise 10.1.1.8/29 and 10.1.1.8/30. You'll get
a conflict since you'll try and use the LSID 10.1.1.15 for both
10.1.1.0/28 and 10.1.1.8/30. A more common conflict would be if you
happen to also want to advertise the host route 10.1.1.15/32.

Thanks,
Acee



>Tom Petch
>
>----- Original Message -----
>From: "Dave Katz" <dkatz at JUNIPER.NET>
>To: <OSPF at PEACH.EASE.LSOFT.COM>
>Sent: Friday, April 15, 2005 7:26 AM
>
>
>On Apr 14, 2005, at 4:31 PM, Zhao-Yang Dong wrote:
>

>
>>In an OSPF link state database, each LSA is supposed to have a unique
>>Link State ID (LSID). Sometimes this is not true, especially in
>>multiple vendor devices environment.
>>   
>>
>
>The LSA ID is qualified by the originating system, so it is entirely
>reasonable to have multiple LSAs with the same LSA ID but different
>router IDs.
>
>What is *not* allowed is to have multiple LSAs with the same LSA ID
>originated by the same system.  This cannot happen according to the
>rules, and they will not be propagated if they were, also according to
>the rules.  Whether there are multiple vendors has no impact on this.
>

>
>>When originating summary and/or AS-external LSAs, how to assign unique
>>LSID for a network number who has multiple (different length of) masks
>>is described in RFC 2328 appendix E. However, I did not see any
>>discussion in RFC 2328 nor this archive how to handle/process summary
>>and/or AS-external LSAs received from other routers with the same LSID
>>but different length of masks.
>>   
>>
>
>A router can do anything it wants to guarantee LSA ID uniqueness on the
>LSAs it generates; appendix E is one way (though there are ways that
>will go further before they fail than the one outlined there.)  Note
>that RFC2328 also refers to appendix E for Summary LSAs as well;  see
>appendix A.4.5.
>
>It is not the job of a receiving router to deal with this case, because
>it cannot happen (according to the rules) and it is indistinguishable
>from the case where somebody changes the netmask on a redistributed
>static route.
>

>
>>
>>According RFC 2328, a LSA is identified by LS type, LSID and
>>advertising router. To determine which LSA of two LSA instances is
>>newer, LS sequence number, checksum and age are compared. Network mask
>>does not seem play any role while processing the received LSAs.
>>   
>>
>
>It does not, nor should it.  An LSA is identified by originating router
>ID, LSA type, and LSA ID.  Period.  Any router that attempts to
>generate two different LSAs with the same ID is broken.
>

>
>>
>>My question is, for example, if I received a LSA with LSID=A.B.C.D and
>>24 bits mask and installed in my database, and later I received the
>>same LSA (i.e. same LS type, LSID and advertising router) but with 28
>>bits mask. If the second LSA has the larger sequence number, should I
>>replace my database copy with the second LSA?
>>   
>>
>
>That's what the rules say.  This is why a broken system generating
>multiple LSAs with the same ID will not get far;  only one of them
>(with the higher sequence number) will get acknowledged, and the other
>will be retransmitted ad infinitum.
>
>
>The problem is that the Founding Fathers that spec'ed OSPF screwed up
>and overloaded the LSA ID with routing information because they were
>afraid of spending another four bytes per LSA.  One could blame it on
>classful networking, but in a purely classful environment you wouldn't
>even need masks.  Basically it was yet another mistaken optimization.
>
>It's impossible to guarantee uniqueness;  if you try hard enough you
>can generate a situation that no algorithm can work around (because the
>LSA ID space is by definition sparse due to the masking requirement,
>but the space of possible external routes is dense.)  As a practical
>matter, however, it's very unlikely that there will be an LSA ID
>collision if a reasonably good algorithm is chosen.
>
>
>BTW, the cisco IOS implementation appears to attempt to detect this
>case, though it's not clear why.  I assume it complains if it sees the
>same LSA ID and a different netmask, but that's a perfectly legal
>situation.  If anybody from cisco can explain this, I'm quite curious.
>
>--Dave
>
>

>
>>
>>Thanks,
>>
>>Zhaoyang
>>
>>
>>   
>>
>

>