Re: Why a transit area cannot be a stub area?

Yep, I think you've got it exactly (and I agree that it's hard to lab
something that's an impossibility due to the way the protocol was
written!). So, as I eluded to earlier, one could envision either R4
or R2 in some way introducing R5's external prefixes into the transit
area, thus allowing it to be a partial stub of sorts. Obviously at
this point the restriction against Type 5s flooding over the VL would
need to be lifted. Again, though, this would seem to call for some
new type of LSA for flag or something that would be unique to partial
stub areas supporting VLs. I tend to side with Moy's simpler
approach. Actually, I tend to side with GRE; haven't configured or
thought much about VLs since sometime just before Feb 5, 2008...

On Aug 25, 2009, at 8:24 , Bryan Bartik wrote:

> This is how I understand it, please correct me if I am missing
> something.
> It's hard to lab something that's not possible!
>
> R1---area0---R2---area1---R3---area1---R4---area2---R5
>
> Consider area 1 as a stub and a VL between R4 and R2.
> Even if type 5 LSAs were flooded (tunneled) over the VL, R3 would
> never see
> them.
> R3 would have a default route out of area 1 and packets for
> destinations
> external to R5 (and area 2 if area 1 is totally stubby) would loop
> between
> R2 and R3.
> Even with the transit capability on, R3 never sees the LSAs and could
> blackhole or loop traffic.
>
> On Tue, Aug 25, 2009 at 7:00 AM, Scott M Vermillion <
> scott_ccie_list_at_it-ag.com> wrote:
>
>> Hi Petr,
>> I knew this one was going to come up! Usually it's Narbik but you
>> beat him
>> to the punch this time. ;-) Here are what I believe to be some
>> relevant
>> passages from RFC2328 :
>>
>>
>> "TransitCapability
>>
>> This parameter indicates whether the area can carry data
>> traffic
>> that neither originates nor terminates in the area itself.
>> This
>> parameter is calculated when the area's shortest-path tree is
>> built (see Section 16.1, where TransitCapability is set to
>> TRUE
>> if and only if there are one or more fully adjacent virtual
>> links using the area as Transit area), and is used as an input
>> to a subsequent step of the routing table build process (see
>> Section 16.3). When an area's TransitCapability is set to
>> TRUE,
>> the area is said to be a "transit area"."
>>
>>
>> "If an area is capable of carrying transit traffic (i.e., its
>> TransitCapability is set to TRUE), routing information concerning
>> backbone
>> networks should not be condensed before being summarized into the
>> area. Nor
>> should the advertisement of backbone networks into transit areas be
>> suppressed. In other words, the backbone's configured ranges should
>> be
>> ignored when originating summary-LSAs into transit areas."
>>
>> "In other words, virtual links allow transit traffic to be
>> forwarded through
>> an area, but do not dictate the precise path that the traffic will
>> take."
>>
>> That last passage is from Section 16.3, which includes a great
>> example and
>> a reasonably good ASCII figure (Figure 17) to illustrate the point.
>>
>> And then from your posted link:
>>
>> "Usage Guidelines
>>
>> OSPF area capability transit is enabled by default, allowing the
>> OSPF Area
>> Border Router to install better-cost routes to the backbone area
>> through the
>> transit area instead of the virtual links. If you want to retain a
>> traffic
>> pattern through the virtual-link path, you can disable capability
>> transit by
>> entering the *no capability transit* command. If paths through the
>> transit
>> area are discovered, they are most likely to be more optimal paths,
>> or at
>> least equal to, the virtual-link path."
>>
>> Finally, since I was poking around the RFC anyway, I thought I
>> would post
>> this passage:
>>
>> "The other details concerning virtual links are as follows:
>>
>> AS-external-LSAs are NEVER flooded over virtual adjacencies.
>> This would be duplication of effort, since the same AS-
>> external-LSAs are already flooded throughout the virtual
>> link's
>> Transit area. For this same reason, AS-external-LSAs are not
>> summarized over virtual adjacencies during the Database
>> Exchange
>> process."
>>
>> So going back to Hoogen's original question and the context of
>> external
>> reachability, I guess the above part about external LSAs already
>> being
>> flooded throughout the transit area wouldn't hold true were it
>> allowed to be
>> a stub. Again, I think you can look at this and see where different
>> approaches might have been devised that would have allowed for a
>> transit
>> area to be a stub and not break the network, but it likely would have
>> introduced additional complexity (perhaps even an additional LSA
>> type or
>> another flag bit or something to handle the special case of external
>> reachability that was introduced in the isolated backbone segment)
>> vs.
>> simply decreeing that transit areas can't be stubs. And given that
>> you can
>> always whip out a GRE tunnel over a stub area if you so desire,
>> this doesn't
>> seem too arbitrary or harsh IMHO.
>>
>> Regards,
>>
>> Scott
>>
>> On Aug 24, 2009, at 11:25 , Petr Lapukhov wrote:
>>
>> Hi everyone,
>>
>> One really good OSPF question is asking what the following feature
>> does when enabled or disabled:
>> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/ospfatc.html.
>> The feature is directly related to the transit area concept and
>> causes
>> a lot of confusion sometimes :)
>>
>> --
>> Petr Lapukhov, petr_at_INE.com
>> CCIE #16379 (R&S/Security/SP/Voice)
>>
>> Internetwork Expert, Inc.
>> http://www.INE.com
>> Toll Free: 877-224-8987
>> Outside US: 775-826-4344
>>
>> 2009/8/24 Bryan Bartik <bbartik_at_ipexpert.com>:
>>
>> Stubs were also created with the option of not allowing type 3 LSAs
>> (this
>> is
>>
>> from page 133 of Moy's book "OSPF: Anatomy of an Internet Routing
>> Protocol).
>>
>> I think this would blackhole traffic heading from the backbone
>> toward the
>>
>> disconnected area because the stub would not have the type 3 LSAs
>> for the
>>
>> disconnected area, just like it would type 5 LSAs. Section 12.4.3.1
>> of RFC
>>
>> 2328 may give a little more insight regarding this "option" for
>> summary
>>
>> LSAs.
>>
>>
>> On Mon, Aug 24, 2009 at 5:34 PM, Hoogen <hoogen82_at_gmail.com> wrote:
>>
>>
>> Hi Darby,
>>
>> I was referring a transit area which connects disconnected area's.
>> Sorry
>>
>> for
>>
>> the confusion.
>>
>>
>> The question was Why can't we have the area's that have virtual-
>> links to be
>>
>> a stub area. RFC says you can't " the only reason being if the
>> disconnected
>>
>> area had ASBR's we have a problem transmitting Type 5 LSA's
>>
>>
>>
>>
>> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094aaa.shtml#virtuallinks
>>
>>
>> Please have a look @ line 3 of the first paragraph.." The transit
>> area
>>
>> cannot be a stub area". I understand it why.. like Scott pointed
>> out.. but
>>
>> I
>>
>> was hoping if we do not have asbr's in the disconnected area..
>> there should
>>
>> be a better answer. Best practice you do not configure it.. but
>> just was
>>
>> digging around for a better explanation.
>>
>>
>> -Hoogen
>>
>>
>>
>>
>> On Mon, Aug 24, 2009 at 4:13 PM, Darby Weaver <darby.weaver_at_gmail.com
>>
>> wrote:
>>
>>
>> Hmm...
>>
>>
>> I define area a transit Area as "The Transit area" aka Area 0.
>>
>>
>> Now since Area 0 is connected to every other area it seems
>> contracdictory
>>
>> to me and my viewpoint to ever declare it a stub area.
>>
>>
>> Each area attached to Area 0 sends its information to Area 0.
>>
>>
>> Virtual-links are an extension of Area 0.
>>
>>
>> So with all that said... what was the question again?
>>
>>
>> I have a pretty nice powerpoint that kinda illustrates the whole
>> picture
>>
>> and I guess if you stare at it long enough it starts to make
>> sense. :)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Aug 24, 2009 at 5:15 PM, Hoogen <hoogen82_at_gmail.com> wrote:
>>
>>
>> Hi All,
>>
>> I have been trying to look around but any more information would be
>>
>> great...
>>
>>
>> The only thing I understand it can't be done is because RFC says so..
>>
>> and
>>
>> because just in case the disconnected area has ASBR type 5 external
>>
>> lsa's
>>
>> cannot pass through.
>>
>>
>> Anyone has any more information other than this?
>>
>>
>> -Hoogen
>>
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>>
>> _______________________________________________________________________
>>
>> Subscription information may be found at:
>>
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>>
>> _______________________________________________________________________
>>
>> Subscription information may be found at:
>>
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Bryan Bartik
>>
>> CCIE #23707 (R&S), CCNP
>>
>> Sr. Support Engineer - IPexpert, Inc.
>>
>> URL: http://www.IPexpert.com
>>
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>>
>> _______________________________________________________________________
>>
>> Subscription information may be found at:
>>
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Bryan Bartik
> CCIE #23707 (R&S), CCNP
> Sr. Support Engineer - IPexpert, Inc.
> URL: http://www.IPexpert.com
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue Aug 25 2009 - 08:38:31 ART