Re: Default LSA creation

Mani Devarajan <mani_devarajan@NET.COM> Fri, 11 October 2002 19:23 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 PAA03062 for <ospf-archive@LISTS.IETF.ORG>; Fri, 11 Oct 2002 15:23:05 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.007684FC@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 15:25:06 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 282720 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 15:25:05 -0400
Received: from 134.56.3.132 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 15:15:05 -0400
Received: from mx02-int.net.com (mx02-int.net.com [134.56.112.14]) by mx02.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id g9BJDR504262 for <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 11 Oct 2002 12:13:27 -0700 (PDT)
Received: from west-mail.net.com (west-mail.net.com [134.56.112.40]) by mx02-int.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id g9BJBrI23094 for <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 11 Oct 2002 12:11:53 -0700 (PDT)
Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA5379 for <OSPF@DISCUSS.MICROSOFT.COM>; Fri, 11 Oct 2002 12:15:07 -0700
X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en, en-GB, fr, de
MIME-Version: 1.0
References: <20021011.112101.86422822.takenaga@soft.net.fujitsu.co.jp> <3DA65070.3060309@redback.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <3DA7233A.2BA2BD91@net.com>
Date: Fri, 11 Oct 2002 12:15:06 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Mani Devarajan <mani_devarajan@NET.COM>
Organization: N.E.T. http://www.net.com
Subject: Re: Default LSA creation
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

     ASBR
      -----     ------     -----    -------
     |     |   |      |   |     |  |       |
     | R1  |   | R2   |   |  R3 |  |  R5   |
     |     |   |      |   |     |  |       |
      -----     ------     -----    -------
       |  |I1 I2|  | |I4  I5|  |I6 I9| |
 RIP---    -----   |  ------    -----  |
           AREA1   |  AREA 0    AREA2  |
                   |I3                 |I10
                   |      -----        |
                   |   I7|     |I8     |
                    -----|  R4 |-------
                   AREA0 |     | AREA2
                          -----
        * AREA2 is NSSA.

Accee, this is question is similar to what Takenaga
asked. But still my doubt is not cleared.

So if R5 chosses the default route through R4, and
If i bring down the I3. R4 is still a NSSA ABR so
it will not flush the default-type7 LSA it generated
in NSSA-2.

Do you mean to say that it is the job of R5 to
recalculate it routes through R3 or interface I3
going down should be avoided.


-Thanks in advance,
Mani




Acee Lindem wrote:
>
> 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