There is a (very short) paper formulating the conditions that favour the occurence of such sub-optimal paths. It is entitled "Forwarding deflection in multi-area OSPF", and is accessible from http://portal.acm.org/citation.cfm?id=1095967
Pierre. Roch Guerin 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] >> https://www1.ietf.org/mailman/listinfo/ospf >> > > _______________________________________________ > OSPF mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf
