Tom Petch <nwnetworks@DIAL.PIPEX.COM> Fri, 15 April 2005 10:26 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 GAA14582 for <ospf-archive@LISTS.IETF.ORG>; Fri, 15 Apr 2005 06:26:42 -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 <23.01014C47@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 6:26:41 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66680461 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 06:26:40 -0400
Received: from 62.241.162.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 06:26:39 -0400
Received: from pc6 (1Cust73.tnt108.lnd4.gbr.da.uu.net [62.188.170.73]) by ranger.systems.pipex.net (Postfix) with SMTP id 4CE51E000220 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 15 Apr 2005 11:26:37 +0100 (BST)
References: <7A3E36B3528ED04A880178D337F30C9A044F6285@zrc2hxm1.corp.nortel.com> <3a414d026ebf930c4160d09a978134ad@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Message-ID: <01d001c5419c$bd05ba60$0601a8c0@pc6>
Date: Fri, 15 Apr 2005 11:22:57 +0200
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Tom Petch <nwnetworks@DIAL.PIPEX.COM>
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit
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. 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