Re: OSPF LSID with vary length masks
Acee Lindem <acee@CISCO.COM> Fri, 15 April 2005 13:33 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 JAA00097 for <ospf-archive@LISTS.IETF.ORG>; Fri, 15 Apr 2005 09:33:23 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.01015032@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 9:33:22 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66704592 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 09:33:20 -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 09:33:20 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 15 Apr 2005 09:33:21 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3FDXIRQ017183 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 15 Apr 2005 09:33:18 -0400 (EDT)
Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 09:33:17 -0400
Received: from [10.82.226.12] ([10.82.226.12]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 09:33:17 -0400
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <7A3E36B3528ED04A880178D337F30C9A044F6285@zrc2hxm1.corp.nortel.com> <3a414d026ebf930c4160d09a978134ad@juniper.net> <01d001c5419c$bd05ba60$0601a8c0@pc6>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Apr 2005 13:33:17.0585 (UTC) FILETIME=[AEB91010:01C541BF]
Message-ID: <425FC29A.8090005@cisco.com>
Date: Fri, 15 Apr 2005 09:33:14 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: OSPF LSID with vary length masks
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <01d001c5419c$bd05ba60$0601a8c0@pc6>
Precedence: list
Content-Transfer-Encoding: 7bit
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 aboved 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/28 and 10.1.1.8/29. 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/28. A more common conflict would be if you happen to also want to advertise the host route 10.1.1.15. Thanks, Acee >Tom Petch > >----- Original Message ----- >From: "Dave Katz" <dkatz@JUNIPER.NET> >To: <OSPF@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 >> >> >> >> > > >
- Zhao-Yang Dong
- Dave Katz
- Tom Petch
- OSPF LSID with vary length masks Acee Lindem
- Re: LSIDs with vary length masks Acee Lindem
- Re: OSPF LSID with vary length masks Acee Lindem
- Re: OSPF LSID with vary length masks Acee Lindem
- Re: OSPF LSID with vary length masks Acee Lindem
- Re: Overlapping Routes Dave Katz