RE: OSPF Path Selection

From: Brian McGahan <bmcgahan_at_ine.com>
Date: Fri, 27 Sep 2013 11:07:53 -0500

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
Received on Fri Sep 27 2013 - 11:07:53 ART

This archive was generated by hypermail 2.2.0 : Tue Oct 01 2013 - 06:36:35 ART