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

From: Scott M Vermillion <scott_ccie_list_at_it-ag.com>
Date: Mon, 24 Aug 2009 16:59:56 -0600

Oh, sorry, I guess I didn't read your question carefully enough at all
Hoogen. I think you've got it more or less correct that the general
restriction is in place because you *potentially could* introduce
external routes via the VL and how would the transit area know whether
or not that was the case (either at the time you established the VL or
at some later time)? I guess maybe in theory Moy could have
introduced some extra intelligence into the backbone-attached ABR
terminating the VL to look at what was being advertised out from the
discontiguous area. But then what to do even if OSPF did implement
this logic? Tear down the VL if some joker comes along and deploys an
ASBR? Block those Type 5 LSAs from going into the backbone? Neither
seem particularly attractive so I think the path of least resistance
was simply to not allow the VL to transit a stub area of any kind and
be done with it all. Ounce of prevention without a lot of complexity
being introduced into the protocol. Obviously that reflects a fair
amount of speculation and musing on my part and I honestly haven't
given VLs much thought in quite some time gone by now, so take it for
whatever it might be worth...

Hope all is well with your studies and your preparations!

Regards,

Scott

On Aug 24, 2009, at 3:51 , Hoogen wrote:

> Hi Scott,
> Thanks for the reply. I understand that , now I am only making the
> transit
> area as stub and not the area that needs to connect to the backbone
> area in
> order to be visible to others. Now I do understand if we had the
> *disconnected area to have an ASBR then the stub cannot be in place.
> But
> when the *disconnected area does not have a ASBR, I do not see any
> reason
> for worry.. Is there something else that I am missing.
>
> Prateek,
>
> Area 0 can never be a stub who are you assuming to be lol :p. Some
> Area 0
> routers can be ASBR. Can't understand what you are trying to say
> here..
> please do distinguish when you say process and area. Your reply
> makes no
> sense.
>
> -Hoogen
>
>
> On Mon, Aug 24, 2009 at 2:36 PM, prateek reddy <prateek.reddyk_at_gmail.com
> >wrote:
>
>> If Area 0 itself is the Stub! Then No need of ASBR? As no routers
>> can
>> understand LSA 5. So no point of Redistribution!
>> So, If your running a single process of OSPF, it can go upto Inter
>> area
>> routes.. but External routes cannot be done.
>>
>> There is no fun in running a single Routing protocol which doesn't
>> allow
>> us to connect else where.
>>
>>
>>
>>
>> On Tue, Aug 25, 2009 at 2:56 AM, Hoogen <hoogen82_at_gmail.com> wrote:
>>
>>> You only make the Area X as stub.. virtual link is a different
>>> configuration.
>>> -Hoogen
>>>
>>> On Mon, Aug 24, 2009 at 2:22 PM, Divin Mathew John <divinjohn_at_gmail.com
>>>> wrote:
>>>
>>>> Maybe its becoz the vurtual link is literally in area 0 . and a
>>>> link in
>>>> area 0 must carry all LSAs. Hence a virtual link thru a stub wont
>>>> be
>>> able to
>>>> carry those LSA 3,4,5 according wht type of STUB area it is.! I
>>>> could
>>> think
>>>> of this.!
>>>> but the easy answer out would be "The RFC Says So" :P
>>>>
>>>>
>>>> Sent from Cochin, KL, India
>>>> Bill Clinton <http://www.quotationspage.com/quote/31751.html> -
>>>> "When
>>> I
>>>> took office, only high energy physicists had ever heard of what is
>>> called
>>>> the Worldwi...
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> With Regards,
>> K.V.Madhu Prateek Reddy.
>
>
> 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 Mon Aug 24 2009 - 16:59:56 ART

This archive was generated by hypermail 2.2.0 : Tue Sep 01 2009 - 05:43:57 ART