Re: Type-7 to Type-5 translation issue

"Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov> Tue, 17 May 2005 14:48 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 KAA02512 for <ospf-archive@LISTS.IETF.ORG>; Tue, 17 May 2005 10:48:05 -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 <9.0104AE3C@cherry.ease.lsoft.com>; Tue, 17 May 2005 10:48:01 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 71203506 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 May 2005 10:47:58 -0400
Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 17 May 2005 10:47:58 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01LOCVDOOG9C002VJL@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 May 2005 07:50:45 -0700 (PDT)
X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM
X-VMS-Cc: PMURPHY,s.esale@GMAIL.COM
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Message-ID: <01LOCVDOOH7M002VJL@omega7.wr.usgs.gov>
Date: Tue, 17 May 2005 07:50:45 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: Type-7 to Type-5 translation issue
Comments: cc: S.ESALE@GMAIL.COM
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Santosh,

I am not sure why my first post never listed, so here again are a few 
thoughts regarding, 

> 1. Prefer type 7 LSA over type-5 .
...
> 2. Prefer type-5 over type-7
...
>3. or its Implementations Specific.
 
Given that the forwarding addresses are the same and point into a newly 
created NSSA, the type-5 LSA would never install on R2. An NSSA border 
router (like R2) never chooses a forwarding path into an NSSA for a 
type-5 LSA as the NSSA's routers (some of which might be internal) 
cannot be counted on to forward packets destined for its prefix along 
the expected path. The same is true for simple stub areas.

Second, you are in complete control here regardless of implementation 
specifics. Simply stop the RIP redistribution on R1 through access-list 
control or by simply shutting down the path to the gateway router of the 
RIP learned routes. Any proper OSPF implementation on R1 should 
immediately flush its type-5 LSAs, as it is no longer a source for these 
routes. Then convert Area 1 to an NSSA. Afterwards restart the RIP 
redistribution.

Hope this helps.

Pat