Re: Default LSA creation

Acee Lindem <acee@REDBACK.COM> Fri, 11 October 2002 04:14 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 AAA01144 for <ospf-archive@LISTS.IETF.ORG>; Fri, 11 Oct 2002 00:14:16 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00766A9D@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 0:16:12 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 279219 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 00:16:12 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 00:16:11 -0400
Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 2D9CE18D3E6 for <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 10 Oct 2002 21:16:10 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <20021011.112101.86422822.takenaga@soft.net.fujitsu.co.jp>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <3DA65070.3060309@redback.com>
Date: Fri, 11 Oct 2002 00:15:44 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Default LSA creation
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

TAKENAGA Yoshinobu wrote:

> Hi,
>
> I have a question about creation of default lsa into stub areas.
> (This question may be a FAQ, please suggest the point)
>
> Consider this network.
>
>    area 1   :  area 0
>    (stub)   :     +--->>(AS extenal path)
>             :     |
>  |--R1--|   :  |--R4--|
>  |      |--R2--|      |
>  |          :         |
>  |      |--R3--|      |
>  |--R6--|   :  |--R5--|
>             :
>
> Here, R2 and R3 are area border router.
> R4 is AS boundary router.
> All link have same cost.
>
> In such situation, R2 and R3 will create default Type-3 LSA into area 1.
> R1 will select R2 as nexthop to the AS extenal path through R4.
>
> Now, the link state changes to this (R4 lose the link to N1).
>
>    area 1   :  area 0
>    (stub)   :     +--->>(AS Extenal path)
>             : N1  |
>  |--R1--|   :  |XXR4--|
>  |      |--R2--|      |
>  |          :         |
>  |      |--R3--|      |
>  |--R6--|   :  |--R5--|
>             :
>
> In such situation, R2 becomes a blackhole.
>
> What is the minimum requirement for R2 to create default Type-3 LSA
> into stub areas?
>   - having configuration of Area0
>   - having active interface to Area0
>   - having "Full" status neighbor in Area0
>   - other??


Hi Takenaga,

The answer is other. The minimum requirement is that the
router be an Area Border Router (ABR). Section 3.3 of RFC 2328 defines
an ABR as a router that attaches to multiple areas. In the context of
RFC 2328, area attachment requires at least one active interface in that
area. Some implementations use other definitions of what constitutes
an ABR (e.g., refer to draft-ietf-ospf-abr-alt-04.txt). However, using
a different ABR definition doesn't handle all situations. Consider R6 and
R3 in the figure below:


     area 1   :  area 0
     (stub)   :     +--->>(AS Extenal path)
              : N1  |
   |--R1--|   :  |--R4--|
   |      |--R2--|      |
   |          :         |
   |      |--R3--|      |
   |--R6--|   :  |--R5XX|


In general, a good OSPF network design will minimize the possibility
that the backbone will become partitioned.


>
> # In NSSA with Type7 LSA, same problem will take place.
>
> Regards,
>
> --
> TAKENAGA Yoshinobu, Fujitsu.
>
>


--
Acee