Sujay, It is very easy to construct examples where a packet does not travel on the "best," i.e., shortest path. The scenario I outlined in my previous email is one such case that applies whether the local area is a transit area or not.
Specifically, R0 picks ABR1 as its exit point for prefix /p/, because ABR1 advertises a T3-summary LSA for /p/ with a cost of /x/, so that when added to the cost of /y/ from R0 to ABR1, /x/+/y/ is the smallest total cost. Now, on their way to ABR1, packets from R0 and destined for /p/ happen to traverse a router that is also an ABR, ABR2. ABR2 had advertised a cost of /z/>/x/ to /p/, so that /u/+/z/>/y/+/z/, where /u/</y/ is the cost of the shortest path from R0 to ABR2, so that ABR2 is not the "best" exit point to reach /p/. However, ABR2 will intercept all packets destined for /p/ and forward them on its own "shortest" path to /p/. You can construct other similar "fun" examples with external routes when 1583 compatibility is not turned on because of the impact of area in selecting an ASBR, and more traditionally summarization can also be responsible for lots of quirky scenarios where non shortest paths are used. The good news is that while "quirky" all these deviations are entirely predictable as they simply follow the letter of the specs (that is, if your implementation is conformant ;-)) Roch > Hi Roch, > Agree with your explanation, "optimal" definitely in this context does > not mean that > the packet should be forwarded by the VL, in fact that is the reason > why we perform > the transit area summary lsa checks to rectify the reachability thru a > better path. > > Again going with your example, as the next forwarding decision or the > path is taken by the > intermediate routers and not by the internal router R0, there should > not arise a case when a > packet forwarded by an internal router in the backbone reaching a ABR > adjacent to a transit > area will not be forwarded using the best path, which I believe was > the point of discussion in > this thread.( I am yet to read the link suggested by Pierre ) > > Regards, > Sujay > > On 5/15/07, *Roch Guerin* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > I guess this is a question of defining what "optimal" means. If > optimal means that packets should be forwarded along the VL, then > clearly there are cases where that may not happen, although as > Acee pointed out, this wont create (permanent0 routing loops since > no matter what packets are always forwarded in a manner that > consistently decreases their cost to the destination. However, > note that the cost decrease rule is not equivalent to always > selecting the shortest path. In particular, there are many cases > where actual packet forwarding follows a different path from that > the initial router computed. In some cases those paths will be > shorter than the original one (the VL case under discussion is one > such example), but not always. This is because of the many > situations where different routers have access to different > information, and the fact that there are non-cost based precedence > rules when selecting paths. > > For example, an internal router R0 could pick an ABR, say ABR1, as > its exit point from its area for a remote prefix /p/ because the > sum of its cost to ABR1 and the cost of the T3 for /p/ advertised > by ABR1 is the smallest among all possible choices. However, if > there is another ABR, say ABR2, on the (shortest) path from R0 to > ABR1, then ABR2 will hijack all the packets to /p/ and will > proceed to forward them onto its own shortest path to /p/, even > though this wont be the shortest path originally selected by R0. > And there are many other examples one can construct, where actual > packet forwarding is not along true end-to-end shortest paths and > where different routers have differing views on what paths packets > actually follow. None of these behaviors create the risk of > routing loops. > > Roch >> Hi, >> I fail to see as to how a non-optimal path will be picked up, for all >> ABR's adjoining the transit area will do a transit area summary lsa >> checking and route table modification if required. >> Noting that the only difference prior to transit area summary lsa >> checking and >> after will be the nexthop modified by the ABR to reach the same >> destination, and >> as IP is hop by hop forwarding any border router adjoining the >> transit area will pick >> up the optimum path( be it thru the VL or not). >> Am I miss something? >> Regds, >> Sujay >> >> >> On 4/30/07, *Kui Zhang* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> Hi Acee, >> >> Yes, a simple way to prevent this from happening is to >> configure a full mesh >> of virtual links between all ABRs in the transit area. >> And this makes IP FRR works well too. >> >> Thanks, >> Kui >> -----Original Message----- >> From: Acee Lindem [mailto:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>] >> Sent: Monday, April 30, 2007 8:28 PM >> To: 章魁 >> Cc: 'Anton Smirnov'; 'OSPF List'; 'Jin Wang' >> Subject: Re: [OSPF] Doubt for virtual link cost ? >> >> Hi Kui, >> Yes - there could be an ABR for the transit area that takes a >> "shortcut" across the transit area for a non-virtual link >> path. Other >> routers in the backbone will not know about this path and may >> take >> other paths.However, this is not a problem since there is no >> possibility of a routing loop. Additionally, the situation >> can easily >> be remedied by configuring a virtual link between the transit >> area >> routers across the "shortcut" path. >> >> Thanks, >> Acee >> >> On Apr 30, 2007, at 2:48 AM, 章魁 wrote: >> >> > Hi Acee, >> > I guess Jin is asking that a non-optimal path might be >> chosen when >> > other >> > routers in backbone area can't check the transit area's >> summary lsa to >> > update the intra-area route. This should be a drawback of >> virtual >> > link, I >> > think. >> > >> > Kui >> > -----Original Message----- >> > From: Acee Lindem [mailto:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>] >> > Sent: Monday, April 30, 2007 4:11 AM >> > To: Anton Smirnov >> > Cc: OSPF List; Jin Wang >> > Subject: Re: [OSPF] Doubt for virtual link cost ? >> > >> > Hi Anton, Jin, >> > I guess I don't really understand the point of controversy >> here. I >> > agree with Anton. Note that if there is not an active >> virtual link >> > then the non-backbone area is not a transit area. >> > Thanks, >> > Acee >> > On Apr 29, 2007, at 8:23 AM, Anton Smirnov wrote: >> > >> >>Jin, >> >>right. In network design where such scenario is possible you >> >> always >> >> can create VL between this ABR and ABR providing best path via >> >> transit >> >> area. This will make the best path 'visible' to other >> routers in >> >> backbone. >> >> >> >> Anton >> >> >> >> >> >> Jin Wang wrote: >> >>> >> >>> Thanks for anton's response. >> >>> But if so,only the traffic going through this ABR(determined >> >>> before 16.3 >> >>> calculating result) is forwarded by the new optimal >> path.For those >> >>> other >> >>> traffic not forwarded via this ABR(determined by 16.1 & >> 16.2) in the >> >>> backbone will not consider the new path(via ABR) even path is >> >>> shorter.right? >> >>> >> >>> >> >>> Best regards, >> >>> >> >>> Wangjin >> >>> Accton Technology China Company Ltd. >> >>> Shanghai R&D Center >> >>> TEL:+86-021-64859922*6227 >> >>> E-mail:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> >>> Web Site: www.accton.com.cn <http://www.accton.com.cn> >> >>> >> >> >> >> >> >> _______________________________________________ >> >> OSPF mailing list >> >> [email protected] <mailto:[email protected]> >> >> https://www1.ietf.org/mailman/listinfo/ospf >> > >> > >> > _______________________________________________ >> > OSPF mailing list >> > [email protected] <mailto:[email protected]> >> > https://www1.ietf.org/mailman/listinfo/ospf >> > >> > >> >> >> >> >> _______________________________________________ >> OSPF mailing list >> [email protected] <mailto:[email protected]> >> https://www1.ietf.org/mailman/listinfo/ospf >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> OSPF mailing list >> [email protected] <mailto:[email protected]> >> https://www1.ietf.org/mailman/listinfo/ospf >> > > >
begin:vcard fn:Roch Guerin n:Guerin;Roch org:University of Pennsylvania;Electrical and Systems Engineering adr:;;200 South 33rd Street;Philadelphia;PA;19104;U.S.A. title:Alfred Fitler Moore Professor of Telecommunication Networks tel;work:(215) 898-9351 tel;fax:(215) 573-2068 tel;cell:(215) 431-7396 x-mozilla-html:FALSE url:http://www.seas.upenn.edu/~guerin version:2.1 end:vcard
_______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf
