Re: OSPF LSID with vary length masks

[Acee Lindem <[e-mail]>]

Zhao-Yang Dong wrote:

>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. 
>  
>
This is the right thing to do as per RFC 2328.

Thanks,
Acee

>Thanks again,
>
>Zhaoyang
>
>
>-----Original Message-----
>From: Mailing List [mailto:[e-mail]] On Behalf Of Acee
>Lindem
>Sent: Friday, April 15, 2005 9:42 AM
>To: [e-mail]
>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" <[e-mail]>
>>To: <[e-mail]>
>>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
>>>
>>>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>
>
>  
>