Re: Type-7 to Type-5 translation issue
Acee Lindem <acee@CISCO.COM> Mon, 16 May 2005 14:21 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 KAA17450 for <ospf-archive@LISTS.IETF.ORG>; Mon, 16 May 2005 10:21:06 -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 <12.010498AD@cherry.ease.lsoft.com>; Mon, 16 May 2005 10:21:05 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 71003122 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 May 2005 10:20:57 -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 16 May 2005 10:20:56 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 16 May 2005 10:20:57 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4GEKne2025049 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 16 May 2005 10:20:55 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 10:20:49 -0400
Received: from [10.82.225.188] ([10.82.225.188]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 10:20:49 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <c4bf85a2050514081066c7ef0a@mail.gmail.com> <428874E3.1020408@cisco.com> <c4bf85a20505160343ab75063@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 May 2005 14:20:49.0849 (UTC) FILETIME=[759C4290:01C55A22]
Message-ID: <4288AC41.4060309@cisco.com>
Date: Mon, 16 May 2005 10:20:49 -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: Type-7 to Type-5 translation issue
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <c4bf85a20505160343ab75063@mail.gmail.com>
Precedence: list
Content-Transfer-Encoding: 7bit
Santosh, See inline. Santosh Esale wrote: >Hi Acee, > U mean i should check whether the ASBR path is via type-5 >capable area, and if its not USE NSSA external lsa for calculation and >do the type-7 to type-5 conversion immediately. > > I'm saying that you should not use the AS-external-LSA if the path to the ASBR is not through a regular area (RFC 3101 uses the term Type-5 capable which I really don't like since we have descriptive names for the LSAs). If there is an NSSA-LSA originated by R1 it will be used by other routers in area 1 and R2 will do the translation. >I do agree with this...but we are doubling the LSP database size, how >to slove it? > > You don't :^) In your example, R1 could attempt to flush all its AS-external-LSAs prior to converting to area 1 to a regular area. However, the network administrator would have to time the conversion such that the MAXAGE'ed AS-external-LSAs get flooded to other routers in area 1 prior to conversion (since AS scoped LSAs are not flooded over NSSA interfaces). In any case, they will not be used and it may be easier to allow them to just age out. Hope this helps, Acee >Thanks >Santosh > >On 5/16/05, Acee Lindem <acee@cisco.com> wrote: > > >>Hi Santosh, >> >>Whether or not R1 purges its AS-external-LSAs prior to area 1 being >>coverted from a regular area to an NSSA is implementation specific. >>However, the >>timing of the conversion may be such that R1 is unable to purge them >>from the >>OSPF routing domain. In all cases, R1 should immediately originate >>NSSA-LSAs >>(type-7s) for redistributed routes. When R2 computes its external/NSSA >>routes >>it should not use R1's AS-external-LSA since its path to the ASBR is not >>through >>a regular area (see section 2.5 in RFC 3101). >> >>Hope this helps, >>Acee >> >>Santosh Esale wrote: >> >> >> >>>Hi guys, >>> Mine topology is as below- >>> >>>R1----Area 1 ------R2--------Backbone Area------R3 >>> >>>Initially Area 1 was type-5 capabale area and i was redistributing RIP >>>routes into area 1 on R1, so R2 and R3 have type-5 LSAs for all the >>>RIP routes.Now i changed >>>Area 1 to NSSA , So R1 is now orginating type-7 LSAs for all the RIP >>>routes into area 1 with P-bit set. >>> >>>Now mine question is should R2 - >>> >>>1. Prefer type 7 LSA over type-5 . >>>Convert type-7 LSA into type-5 LSA and flood into backbone, which >>>aleardy have type-5 LSAs for the same netwroks earlier orginated by >>>R1(not yet flushed as it will remain in backbone for MAX AGE) >>>(According to RFC 3101. section 2.5 stp 6 (e) ). >>> >>>Disadvantage: The LSP database size will be doubled till MAX AGE time. >>>Advantage : simplicity >>> >>>2. Prefer type-5 over type-7 . >>>Use type-5 LSA for calculating external routes till type-5 LSAs >>>advertised by R1 exists in backbone(MAX Age) , and once type is >>>flushed because of MAX age , USE type -7 now to calculate external >>>routes , and translate at this point from type-7 to type-5(RFC 1587 >>>3.5 step 5) >>> >>>Advantage : LSP database size is small. >>>Disadvantage: bit complex,but not much. >>> >>>3. or its Implementations Specific. >>> >>>Thanks in Advance >>> >>> >>> >>> >>> >>> > > > >
- Type-7 to Type-5 translation issue Santosh Esale
- Re: Type-7 to Type-5 translation issue sujay
- Re: Type-7 to Type-5 translation issue Acee Lindem
- Re: Type-7 to Type-5 translation issue Santosh Esale
- Re: Type-7 to Type-5 translation issue Acee Lindem
- Re: Type-7 to Type-5 translation issue Santosh Esale
- Re: Type-7 to Type-5 translation issue Pat Murphy - (650)329-4044
- OSPF : Summarization of type-7 lsa's tajay