Clarification in NSSA

Vivek Dubey <vivek_ospf@REDIFFMAIL.COM> Mon, 30 June 2003 05: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 BAA19390 for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 Jun 2003 01:48:59 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A3C488@cherry.ease.lsoft.com>; Mon, 30 Jun 2003 1:48:57 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47063157 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jun 2003 01:48:34 -0400
Received: from 203.199.83.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 30 Jun 2003 01:48:33 -0400
Received: (qmail 30678 invoked by uid 510); 30 Jun 2003 05:47:02 -0000
Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 30 jun 2003 05:47:02 -0000
MIME-Version: 1.0
Content-type: text/plain; format="flowed"
Content-Disposition: inline
Message-ID: <20030630054702.30677.qmail@webmail35.rediffmail.com>
Date: Mon, 30 Jun 2003 05:47:02 -0000
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vivek Dubey <vivek_ospf@REDIFFMAIL.COM>
Subject: Clarification in NSSA
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi krishna,
Section 3.2 point 2 (RFC 3101).. should help...

"If the Type-7 LSA is not contained in any explicitly
configured Type-7 address range and the calculating router has
the highest router ID amongst NSSA translators that have
originated a functionally equivalent Type-5 LSA (i.e. same
destination, cost and non-zero forwarding address) and that
are reachable over area 0 and the NSSA, then a Type-5 LSA
should be generated"


vivek


On Sat, 28 Jun 2003 Vivek Dubey wrote :
>Hi,
>The point krishna is trying to make:
>1) R3 goes down
>2) R2 gets elected as translator
>3) But R2 while translating Type 7 to Type 5
>    sees functionally equv Type 5 previously
>    translated by R3 (before being stopped).
>    Note R3 router id is higher.
>    So R2 doesn't originate Translated Type 5.
>4) So both R2 and R1 hold Type 5 generated by
>    R3 before it went down (no flushing was done
>    by R3 before going down).
>5) Consequently R1 will loose routes to those
>    Type 7 networks (calculated using Translated
>    Type 5 by R3).
>6) But R2 will hold routes as it is directly connected
>    to NSSA area and can use Type 7 for getting to those
>    networks.
>
>This can happen in real networks.
>Probably Pat can clarify how to handle such
>scenarios.
>
>thanks,
>vivek
>
>
>On Fri, 27 Jun 2003 Jeyanath Minto J - CTD, Chennai. wrote :
>>hi Krishna,
>>     R2 maintain a List of this area's Nssa border Routers and
>>ASBR.
>>Translator is Elected from this List.
>>     so , when u stopped the R3 , R2 removes the R3 from the
>>List. And R2
>>will elect itself as a Translator ( because R3 is unreachable
>>)
>>and
>>translate type 7 to Type 5.
>>
>>
>>
>>Cheers
>>Minto Mascarenhas
>>**********************************************************************
>>*  Internet IS for everyone - but it won't be unless WE make
>>it
>>so   *
>>**********************************************************************
>>
>>-----Original Message-----
>> From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM]
>>Sent: Friday, June 27, 2003 11:50 AM
>>To: OSPF@PEACH.EASE.LSOFT.COM
>>Subject: Clarification in NSSA
>>
>>
>>Hi
>>
>>I am basically testing RFC 3101 NSSA implementation. I find
>>that
>>routes are missing in the Router (not in NSSA area) but is
>>conected to the Router in NSSA area through backbone area.
>>
>>
>>Topology Used in Testing
>>========================
>>   |-------------------------------|
>>   |                               |
>>   |                               |
>>   |                               |
>>R1-------------R2---------------R3
>>                  |                |
>>                  |                |
>>                  |                |
>>             --------------------------- NSSA area 0.0.0.1
>>                         |
>>                         |
>>                         |
>>                         R4
>>                         | area 0.0.0.1
>>                         |Import External Routes.
>>                         |
>>
>>There are 2 areas in this Topology -
>>NSSA area 0.0.0.1 (R2, R3 and R4)
>>Remaining all the networks are in backbone area.
>>
>>R1 is connected to R2 and R3 through backbone area. R2 and R3
>>are
>>connected through backbone area.
>>
>>RouterID of R1 10.0.0.1
>>RouterID of R2 20.0.0.1
>>RouterID of R3 30.0.0.1
>>
>>R3 is elected as Translator. Import external routes at R4. R1
>>holds the external routes.
>>
>>Now, stop the router R3. R2 takes over as Translator.
>>
>>BUT, now R1 doesnot hold the external routes.
>>
>>I expect the R1 to hold the external routes. But as per RFC
>>3101
>>since R2 holds LSA generated by R3 which is of higher
>>RouterID,
>>R2
>>doesnot generate Type 5 LSAs. Is it correct. If this is the
>>case,
>>then R1 would never hold the external routes.
>>
>>Your response on this would be highly appreciated.
>>
>>Thanks & Regards
>>Krishna
>>
>>
>>
>>
>>
>>___________________________________________________
>>Click below to experience Sooraj Barjatya's latest offering
>>'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
>>Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com
>
>___________________________________________________
>Click below to experience Sooraj Barjatya's latest offering
>'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
>Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com

___________________________________________________
Click below to experience Sooraj Barjatya's latest offering
'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com