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

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

Blogs and organic groups at http://www.ccie.net
Received on Tue Aug 25 2009 - 07:00:18 ART