Thanks Joe for bringing this up.
Thanks Brian for posting a great snippet of the RFC, nicely explained in the
end.
Thanks Marko nice PDF clearly engineering level and the level we need to be
at!
OSPF the most complicated out of the protocols for me! Same complexity as the
pim register process :/
-- BR Tony Sent from my iPad On 27 Sep 2013, at 19:15, Joe Astorino <joeastorino1982_at_gmail.com> wrote: > 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.netReceived on Fri Sep 27 2013 - 22:19:09 ART
This archive was generated by hypermail 2.2.0 : Tue Oct 01 2013 - 06:36:35 ART