Re: [OSPF] Functionally equivalent as-external lsa
"Pat Murphy - (650)329-4044" <pmurphy@noc.usgs.net> Sat, 15 July 2006 11:35 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1iQz-0006Qo-Au; Sat, 15 Jul 2006 07:35:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1iQy-0006Qe-95 for OSPF@IETF.ORG; Sat, 15 Jul 2006 07:35:44 -0400
Received: from omega7.wr.usgs.gov ([130.118.4.3] helo=ns0.wr.usgs.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1iQx-0005lN-SZ for OSPF@IETF.ORG; Sat, 15 Jul 2006 07:35:44 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01M4T00K5RKG002SH3@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Sat, 15 Jul 2006 04:31:54 -0700 (PDT)
Date: Sat, 15 Jul 2006 04:31:54 -0700
From: "Pat Murphy - (650)329-4044" <pmurphy@noc.usgs.net>
Subject: Re: [OSPF] Functionally equivalent as-external lsa
To: OSPF@IETF.ORG
Message-id: <01M4T00K5SIA002SH3@omega7.wr.usgs.gov>
X-VMS-To: ospf@ietf.org
X-VMS-Cc: pmurphy,Chitra_Namadevan@infosys.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc: CHITRA_NAMADEVAN@INFOSYS.COM
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org
Chitra, W.r.t. dummy dummy SW(*) SW(*) | | +-----+ | | +-----+ | | | | | | | +---+ +---+ | | | | | |PSS9 +------ X ------|PSS11| +-----+ +-----+ 10.81.156.72 10.81.156.74 3.3.3.0/24 (*)dummy SW: only for up the Link of PSS9/PSS11. PSS9 and PSS11 both originate a functionally equivalent external LSA for 3.3.3.0/24. in summary neither PSS9 or PSS11's external LSA for prefix 3.3.3.0/24 is installed in PSS11's OSPF routing table. A path external to OSPF, e.g. a static route or BGP advertisement, controls the forwarding of packets destined to the prefix 3.3.3.0/24. Whenever PSS11 is originating its LSA, PSS9 should flush its LSA and install PSS11's LSA as long as PSS11 is reachable. When PSS9 and PSS11 are no longer reachable from one another, PSS9 should remove PSS11's LSA from the OSPF routing table and originate its own functionally equivalent external LSA for the prefix 3.3.3.0/24, provided it still has an imported path for it. PSS11's LSA may continue to live in PSS9's LSDB until it age's out normally; but again, as with PS11, neither LSA should be installed in the OSPF routing table until PSS11 becomes reachable again. That's it. Read on for a more detailed explanation. >From RFC 2328 Section 12.4.4.1 ...if two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its LSA. PSS9 should flush its 3.3.3.0/24 LSA. However, as Vishwas has pointed out, this was intended as an optimization feature. But an implementation that chooses not to do this could cause a subtle anomaly. See below. Regardless the following text from RFC 2328 Section 14.1 still applies A router may only prematurely age its own self-originated LSAs. The router may not prematurely age LSAs that have been originated by other routers. An LSA is considered self-originated when either 1) the LSA's Advertising Router is equal to the router's own Router ID. 2) the LSA is a network-LSA and its Link State ID is equal to one of the router's own IP interface addresses. Hence PSS11 and PSS9 retain each other's 3.3.3.0/24 LSAs until they are flushed by the originating router or they age out normally. Regarding the text, If there is already a database copy, and if the database copy was received via flooding and installed less than MinLSArrival seconds ago, discard the new LSA (without acknowledging it) and examine the next LSA (if any) listed in the Link State Update packet. I don't believe this applies to your example. The two LSAs are different because they have different Advertising Routers. They are only functionally equivalent. Hope this clarifies Problem 1. Regarding Problem 2, self originated external LSAs are never installed in the OSPF routing table. RFC 2328 Section 16.4 Step (2) states (2) If the LSA was originated by the calculating router itself, examine the next LSA. The reason for this is that a path to 3.3.3.0/24 exists in the IP routing tables of PSS9 and PSS11 (versus their OSPF routing tables) that is external to OSPF, e.g. a static route or BGP learned path. It is this path that is imported into OSPF and causes the LSA's origination. Since PSS11's 3.3.3.0/24 external LSA is the more preferred LSA, PSS9's LSA must never be installed in PSS11's OSPF routing table while this imported path exist, as the OSPF path could potentially be more preferred than the imported static route, BGP path, etc... in the IP routing table. This would happen when OSPF's administrative metric is preferred over the imported route's administrative metric. The result could be an endless loop of self-originations and flushings. Note based on this discussion it seems clear to me that some handling of functionally equivalent LSAs is mandatory. HTH. Pat _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf
- [OSPF] Functionally equivalent as-external lsa Chitra Lakshmi Namadevan
- Re: [OSPF] Functionally equivalent as-external lsa Vishwas Manral
- Re: [OSPF] Functionally equivalent as-external lsa Pat Murphy - (650)329-4044
- RE: [OSPF] Functionally equivalent as-external lsa Chitra Lakshmi Namadevan
- RE: [OSPF] Functionally equivalent as-external lsa Chitra Lakshmi Namadevan