There is also an excellent NANOG presentation on the subject:
http://www.nanog.org/meetings/nanog54/presentations/Monday/Applegate.pdf
-- Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor / Managing Partner - IPexpert On Fri, Sep 27, 2013 at 11:05 AM, 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 > > > 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.netReceived on Fri Sep 27 2013 - 11:20:30 ART
This archive was generated by hypermail 2.2.0 : Tue Oct 01 2013 - 06:36:35 ART