Re: OSPF Path Selection

I should be a little more clear (forgive me I need more coffee and sleep
today it seems):

What I was describing in my last post was Petr's example topology. In the
RFC example topology it is essentially the same case - The reason packets
can get from network N1 back to R1 without traversing area 0 is because

- There exists a virtual-link AND
- the path through the transit area 1 is shorter than the path through the
virtual-link.

Both have to be true for capability transit and thus the rule #3 outlined
in the cert guide to be true. I am pretty sure I have a handle on this
now. Thank you all for your input!

On Fri, Sep 27, 2013 at 2:05 PM, Joe Astorino <joeastorino1982_at_gmail.com>wrote:

> Hey Brian! Thanks for the detailed response. Yes, I believe what you are
> quoting from the RFC is basically describing the situation we had in Petr's
> article correct?
>
> In the example topology, the packet can get all the way from area 2 back
> to R1 and never cross the backbone area due to the virtual-link and the
> capability transit option.
>
>
> On Fri, Sep 27, 2013 at 12:07 PM, Brian McGahan <bmcgahan_at_ine.com> wrote:
>
>> Beyond Petr's post the RFC describes in detail in which #3 on your list
>> is a valid case. In RFC 2328 "OSPF Version 2" Section 16 "Calculation of
>> the routing table" it's bullet point 4. Ignore the math-speak about the
>> algorithm and you should be able to pull out the gist when this case would
>> happen:
>>
>> <RFC 2328>
>> 16. Calculation of the routing table
>>
>> This section details the OSPF routing table calculation.
>> <snip>
>> This process can be broken into the
>> following steps:
>> <snip>
>>
>> (2) The intra-area routes are calculated by building the shortest-
>> path tree for each attached area. In particular, all routing
>> table entries whose Destination Type is "area border router" are
>> calculated in this step. This step is described in two parts.
>> At first the tree is constructed by only considering those links
>> between routers and transit networks. Then the stub networks
>> are incorporated into the tree. During the area's shortest-path
>> tree calculation, the area's TransitCapability is also
>> calculated for later use in Step 4.
>>
>> (3) The inter-area routes are calculated, through examination of
>> summary-LSAs. If the router is attached to multiple areas
>> (i.e., it is an area border router), only backbone summary-LSAs
>> are examined.
>>
>> (4) In area border routers connecting to one or more transit areas
>> (i.e, non-backbone areas whose TransitCapability is found to be
>> TRUE), the transit areas' summary-LSAs are examined to see
>> whether better paths exist using the transit areas than were
>> found in Steps 2-3 above.
>> <snip>
>> </RFC 2328>
>>
>> Basically this says to take your intra-area route, then take your
>> inter-area route, but if there is a virtual-link both of these path could
>> afterwards be trumped by a shorter path that *doesn't* go over a
>> virtual-link.
>>
>> Per 16.1.2 "TransitCapability" is set if there's a virtual-link:
>>
>>
>> <RFC 2328>
>> 16.1. Calculating the shortest-path tree for an area
>> <snip>
>> (2) Call the vertex just added to the tree vertex V. Examine
>> the LSA associated with vertex V. This is a lookup in the
>> Area A's link state database based on the Vertex ID. If
>> this is a router-LSA, and bit V of the router-LSA (see
>> Section A.4.2) is set, set Area A's TransitCapability to
>> TRUE. In any case, each link described by the LSA gives the
>> cost to an adjacent vertex. For each described link, (say
>> it joins vertex V to vertex W):
>> </RFC 2328>
>>
>> Section 16.3 "Examining transit areas' summary-LSAs" explains the
>> specific case when the non-virtual link path is shorter.
>>
>> <RFC 2328>
>> 16.3. Examining transit areas' summary-LSAs
>>
>> This step is only performed by area border routers attached to
>> one or more non-backbone areas that are capable of carrying
>> transit traffic (i.e., "transit areas", or those areas whose
>> TransitCapability parameter has been set to TRUE in Step 2 of
>> the Dijkstra algorithm (see Section 16.1).
>>
>> The purpose of the calculation below is to examine the transit
>> areas to see whether they provide any better (shorter) paths
>> than the paths previously calculated in Sections 16.1 and 16.2.
>> Any paths found that are better than or equal to previously
>> discovered paths are installed in the routing table.
>> </RFC 2328>
>>
>> In other words, only do this step IF virtual-link == TRUE, and if the
>> calculation is shorter you can trump your previously calculated intra-area
>> or inter-area path. Continuing in this same section he gives an example of
>> when this calculation ends up to be shorter to *not* go over the
>> virtual-link:
>>
>> <RFC 2328>
>> (4) Look up the routing table entry for the advertising router
>> BR associated with the Area A. If it is unreachable, examine
>> the next LSA. Otherwise, the cost to destination N is the
>> sum of the cost in BR's Area A routing table entry and the
>> cost advertised in the LSA. Call this cost IAC.
>>
>> (5) If this cost is less than the cost occurring in N's routing
>> table entry, overwrite N's list of next hops with those used
>> for BR, and set N's routing table cost to IAC. Else, if IAC
>> is the same as N's current cost, add BR's list of next hops
>> to N's list of next hops. In any case, the area associated
>> with N's routing table entry must remain the backbone area,
>> and the path type (either intra-area or inter-area) must
>> also remain the same.
>>
>> It is important to note that the above calculation never makes
>> unreachable destinations reachable, but instead just potentially
>> finds better paths to already reachable destinations. The
>> calculation installs any better cost found into the routing
>> table entry, from which it may be readvertised in summary-LSAs
>> to other areas.
>>
>> As an example of the calculation, consider the Autonomous System
>> pictured in Figure 17. There is a single non-backbone area
>> (Area 1) that physically divides the backbone into two separate
>> pieces. To maintain connectivity of the backbone, a virtual link
>> has been configured between routers RT1 and RT4. On the right
>> side of the figure, Network N1 belongs to the backbone. The
>> dotted lines indicate that there is a much shorter intra-area
>>
>> ........................
>> . Area 1 (transit) . +
>> . . |
>> . +---+1 1+---+100 |
>> . |RT2|----------|RT4|=========|
>> . 1/+---+********* +---+ |
>> . /******* . |
>> . 1/*Virtual . |
>> 1+---+/* Link . Net|work
>> =======|RT1|* . | N1
>> +---+\ . |
>> . \ . |
>> . \ . |
>> . 1\+---+1 1+---+20 |
>> . |RT3|----------|RT5|=========|
>> . +---+ +---+ |
>> . . |
>> ........................ +
>>
>> Figure 17: Routing through transit areas
>>
>> backbone path between router RT5 and Network N1 (cost 20) than
>> there is between Router RT4 and Network N1 (cost 100). Both
>> Router RT4 and Router RT5 will inject summary-LSAs for Network
>> N1 into Area 1.
>>
>> After the shortest-path tree has been calculated for the
>> backbone in Section 16.1, Router RT1 (left end of the virtual
>> link) will have calculated a path through Router RT4 for all
>> data traffic destined for Network N1. However, since Router RT5
>> is so much closer to Network N1, all routers internal to Area 1
>> (e.g., Routers RT2 and RT3) will forward their Network N1
>> traffic towards Router RT5, instead of RT4. And indeed, after
>> examining Area 1's summary-LSAs by the above calculation, Router
>> RT1 will also forward Network N1 traffic towards RT5. Note that
>> in this example the virtual link enables transit data traffic to
>> be forwarded through Area 1, but the actual path the transit
>> data traffic takes does not follow the virtual link. 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.
>> </RFC 2328>
>>
>> Basically he's saying that normally R1 would have to follow the
>> intra-area path over the virtual-link because that's step 1 of the
>> decision. However there is another ABR R5 that has the same route with a
>> lower cost as an inter-area route. Since TransitCapability == TRUE R1 can
>> follow the shorter inter-area path over the longer intra-area path over the
>> virtual-link.
>>
>>
>> Make sense?
>>
>> Brian McGahan, 4 x CCIE #8593 (R&S/SP/SC/DC), CCDE #2013::13
>> bmcgahan_at_INE.com
>>
>> Internetwork Expert, Inc.
>> http://www.INE.com
>>
>>
>> -----Original Message-----
>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>> Tony Singh
>> Sent: Friday, September 27, 2013 10:01 AM
>> To: Joe Astorino
>> Cc: daniel.dib_at_reaper.nu; <ccielab_at_groupstudy.com>
>> Subject: Re: OSPF Path Selection
>>
>> Hi Joe
>>
>> yeah that's the way i'm interpreting it, unless advised to do so ;)
>>
>> but agree really confusing as you'd think it's actually not an area 0 abr
>> it's crossing - technically it is
>>
>> --
>> BR
>>
>> Tony
>>
>>
>> On 27 September 2013 14:58, Joe Astorino <joeastorino1982_at_gmail.com>
>> wrote:
>>
>> > Hey Tony,
>> >
>> > Are you saying the example in Petr's article is demonstrating "rule #3"
>> > from the CCIE book? That is my best guess at this point. The thing
>> > is, when I read the RFC it the rules make sense. When I read Petr's
>> > article it makes perfect sense. When I read rule #3 a few nights ago
>> > I guess the way it was worded just did not resonate with me.
>> >
>> >
>> > On Fri, Sep 27, 2013 at 4:48 AM, Tony Singh <mothafungla_at_gmail.com>
>> wrote:
>> >
>> >>
>> >> Edit the intra area comment clearly a poor guess.
>> >>
>> >> Ok just read Petr's PDF too he's basically referring to what we'd not
>> >> consider #3 to actually be #3 i.e non-zero area to non-zero area by
>> >> means of a VL, essentially the requirement of a type 3 LSA is still
>> >> valid to cross areas.
>> >>
>> >> --
>> >> BR
>> >>
>> >> Tony
>> >>
>> >> Sent from my iPhone on 3
>> >>
>> >> On 27 Sep 2013, at 08:40, Tony Singh <mothafungla_at_gmail.com> wrote:
>> >>
>> >> >
>> >> > For what it's worth I totally agree as we're transiting through
>> >> > area 0
>> >> and the newly established ABR (after a VL has been established to a
>> >> genuine area 0 ABR) to exit into an say fir example O E2
>> destination.....
>> >> >
>> >> > I think by #3 they mean O intra this is my only thinking, but for
>> >> > OIA
>> >> we'd have to traverse an area 0 ABR for a non zero area to get to
>> >> another non zero area i.e it would have to receive a type 3 LSA in
>> >> the first place from the ABR.
>> >> >
>> >> > --
>> >> > BR
>> >> >
>> >> > Tony
>> >> >
>> >> > Sent from my iPhone on 3
>> >> >
>> >> > On 27 Sep 2013, at 07:43, Joe Astorino <joeastorino1982_at_gmail.com>
>> >> wrote:
>> >> >
>> >> >> With the default capability transit all you are doing is taking a
>> >> transit area to get to area 0 instead of taking a VL through the same
>> >> transit area. In both cases you still end up in area 0 then pass
>> >> through area 0 to get to the other nonbackbone area.
>> >> >>
>> >> >>
>> >> >> Sent from my iPhone
>> >> >>
>> >> >>> On Sep 27, 2013, at 2:41 AM, Joe Astorino
>> >> >>> <joeastorino1982_at_gmail.com>
>> >> wrote:
>> >> >>>
>> >> >>> In my mind no because the stated rule 3 says for "a path crossing
>> >> areas" "take the shortest path to the destination without crossing
>> area 0"
>> >> >>>
>> >> >>> With a virtual link scenario, you ride the VL which is in area 0
>> >> >>> to
>> >> an ABR. For a router in a nonzero area to reach a route in another
>> >> nonzero area, even with the virtual link you still pass through area
>> >> 0 at some stage.
>> >> >>>
>> >> >>> Say you have area3---area0---area1---area2 You would build a VL
>> >> >>> from area 2 to area 0 transmitting through area
>> >> 1. If a packet wants to get to area 3 from area 2 , it rides an area
>> >> 0 link to the backbone (the VL) first (rule 1) Then it would take the
>> >> shortest path through area 0 (rule 2)
>> >> >>>
>> >> >>> Once I to area 0 though I don't see how it would get to area 3
>> >> "without crossing area 0"
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> Sent from my iPhone
>> >> >>>
>> >> >>>> On Sep 27, 2013, at 1:59 AM, Tony Singh <mothafungla_at_gmail.com>
>> >> wrote:
>> >> >>>>
>> >> >>>>
>> >> >>>> The non-zero router becomes an ABR when it connects via a VL
>> >> >>>> into an
>> >> area 0 router.
>> >> >>>>
>> >> >>>> So technically is this really point 3?
>> >> >>>>
>> >> >>>> --
>> >> >>>> BR
>> >> >>>>
>> >> >>>> Tony
>> >> >>>>
>> >> >>>> Sent from my iPhone on 3
>> >> >>>>
>> >> >>>>> On 27 Sep 2013, at 06:26, Joe Astorino
>> >> >>>>> <joeastorino1982_at_gmail.com>
>> >> wrote:
>> >> >>>>>
>> >> >>>>> Yes of course, but as we know the VL is just a link in area 0
>> >> >>>>> so
>> >> that is not really what I'm getting at. There is also the case with
>> >> the default capability transit where you can ride a transit area INTO
>> >> the backbone instead of the VL but one way or another for inter area
>> >> traffic you end up in the backbone
>> >> >>>>>
>> >> >>>>> Sent from my iPhone
>> >> >>>>>
>> >> >>>>>> On Sep 27, 2013, at 1:03 AM, daniel.dib_at_reaper.nu wrote:
>> >> >>>>>>
>> >> >>>>>> Hi Joe!
>> >> >>>>>>
>> >> >>>>>> This could happen if you have a virtual link between ABRs
>> >> >>>>>> meaning that you have something Like Area 0 - Area 1 - Area 2.
>> >> Check
>> >> >>>>>> this INE blog post for the full info:
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> http://blog.ine.com/2009/09/14/understanding-ospf-transit-capability/
>> >> >>>>>> [4]
>> >> >>>>>>
>> >> >>>>>> Regards Daniel
>> >> >>>>>>
>> >> >>>>>> CCIE #37149
>> >> >>>>>>
>> >> >>>>>> 2013-09-27 06:17 skrev Joe
>> >> >>>>>> Astorino:
>> >> >>>>>>
>> >> >>>>>>> So this has actually been bothering me now for YEARS. In
>> >> >>>>>> the CCIE RS Exam
>> >> >>>>>>> Certification Guide, there is a paragraph that goes
>> >> >>>>>> something like this:
>> >> >>>>>>>
>> >> >>>>>>> *OSPF has specific rules for selecting a path
>> >> >>>>>> that crosses areas. *
>> >> >>>>>>>
>> >> >>>>>>> *1) Take the shortest path to area 0.
>> >> >>>>>>> 2)
>> >> >>>>>> Take the shortest path across area 0 without traversing a
>> >> >>>>>> nonzero area.
>> >> >>>>>>> 3) Take the shortest path to the destination without
>> >> >>>>>>> traversing
>> >> >>>>>> area 0.*
>> >> >>>>>>>
>> >> >>>>>>> This has always been somewhat vague and even disturbing to
>> >> >>>>>> me. It's
>> >> >>>>>>> seemingly vague and no other explanation is given about this
>> >> >>>>>> process. Rule
>> >> >>>>>>> 1, take the shortest path to area 0 makes sense. Once
>> >> >>>>>> you get to the
>> >> >>>>>>> backbone area, rule #2 even makes sense. But rule #3
>> >> >>>>>> has never and does not
>> >> >>>>>>> make sense to me
>> >> >>>>>>>
>> >> >>>>>>> So far as I recall, an
>> >> >>>>>> OSPF ABR will never accept type 3 summary LSA
>> >> >>>>>>> information from a
>> >> >>>>>> non-backbone area. In other words, If an ABR receives
>> >> >>>>>>> inter-area
>> >> >>>>>> routing information for a non-backbone area from a
>> >> >>>>>> non-backbone
>> >> >>>>>>> area
>> >> >>>>>> it is ignored. This makes sure that inter area routing
>> >> >>>>>> information
>> >> is
>> >> >>>>>> only learned from the backbone area, and is also a loop
>> >> >>>>>> prevention mechanism. Further, in my mind it guarantees that
>> >> >>>>>> all inter-area traffic
>> >> >>>>>>> must transit the backbone.
>> >> >>>>>>>
>> >> >>>>>>> With that being said, can
>> >> >>>>>> anybody think of ANY case EVER where rule #3 is
>> >> >>>>>>> even valid? How would
>> >> >>>>>> it ever be possible for inter-area traffic to get to
>> >> >>>>>>> a destination
>> >> >>>>>> without traversing area 0?
>> >> >>>>>>>
>> >> >>>>>>> --
>> >> >>>>>>> Regards,
>> >> >>>>>>>
>> >> >>>>>>> Joe Astorino
>> >> >>>>>>> CCIE
>> >> >>>>>> #24347
>> >> >>>>>>> http://astorinonetworks.com [1]
>> >> >>>>>>>
>> >> >>>>>>> "He not busy being born is
>> >> >>>>>> busy dying" - Dylan
>> >> >>>>>>>
>> >> >>>>>>> Blogs and organic groups at http://www.ccie.net
>> >> >>>>>> [2]
>> >> >>>>>>
>> >> _____________________________________________________________________
>> >> __
>> >> >>>>>> Subscription information may be found at:
>> >> >>>>>> http://www.groupstudy.com/list/CCIELab.html [3]
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> Links:
>> >> >>>>>> ------
>> >> >>>>>> [1]
>> >> >>>>>> http://astorinonetworks.com
>> >> >>>>>> [2] http://www.ccie.net
>> >> >>>>>> [3]
>> >> >>>>>> http://www.groupstudy.com/list/CCIELab.html
>> >> >>>>>> [4]
>> >> >>>>>>
>> >> http://blog.ine.com/2009/09/14/understanding-ospf-transit-capability/
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> 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
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> >
>> > Joe Astorino
>> > CCIE #24347
>> > http://astorinonetworks.com
>> >
>> > "He not busy being born is busy dying" - Dylan
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Regards,
>
> Joe Astorino
> CCIE #24347
> http://astorinonetworks.com
>
> "He not busy being born is busy dying" - Dylan
>

-- 
Regards,
Joe Astorino
CCIE #24347
http://astorinonetworks.com
"He not busy being born is busy dying" - Dylan
Blogs and organic groups at http://www.ccie.net