Hello, Thanks for your comments. I agree with your theory. It's my understanding as well. What I don't get is why the "traceroute mpls ldp" command uses both paths and yet "traceroute ip" uses 1 path. It's like the backup path is being used by the LDP LSP when it shouldn't be...
Serge ----- Original Message ---- From: Clarke Morledge <[email protected]> To: [email protected] Cc: Serge Vautour <[email protected]> Sent: Tue, March 16, 2010 11:35:30 AM Subject: RE: [j-nsp] OSPF LFA and LDP LSPs Serge, Part of what you wrote included this: > Now I turn on OSPF LFA "link-protection" on the links and re-run the same > tests: > > ----------------------- > se36...@pe1-stjhlab-re0> show route 10.10.80.2 logical-system PE10 detail > > inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden) > 10.10.80.2/32 (1 entry, 1 announced) > *OSPF Preference: 10 > Next hop type: Router > Next-hop reference count: 26 > Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected > Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000 > <--------- Huh??? > State: <Active Int> > Local AS: 855 > Age: 4 Metric: 2 > Area: 0.0.0.0 > Task: OSPF > Announcement bits (3): 2-LDP 3-KRT 5-Resolve tree 2 > AS path: I > > inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) > > 10.10.80.2/32 (1 entry, 1 announced) > State: <FlashAll> > *LDP Preference: 9 > Next hop type: Router > Next-hop reference count: 3 > Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected > Label operation: Push 299776 > Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000 <--------- > Huh??? > Label operation: Push 299856 > State: <Active Int> > Local AS: 855 > Age: 4 Metric: 1 > Task: LDP > Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2 > AS path: I I can not speak to your traceroute issue, but my understanding is that the next-hop 10.10.81.23 references are the alternate paths that get put in your routing table by the LFA algorithm. These routes exist but only in "stand-by" mode. So if the 10.10.81.10 next-hop ever goes away, traffic can immediately use this "stand-by" routing entry to forward the traffic while OSPF is recalculating new routes under the covers. This is loosely analogous to how Detours work in RSVP/MPLS Fast ReRoute -- though, admittedly, Fast ReRoute is much more involved. Then, once the OSPF recalculations are done in LFA, the routing table is updated with a new primary routing entry and another "stand-by" entry. Therefore, LFA effectively doubles the size of your routing table to accommodate all of the "stand-by" routes. Unless, I'm missing something, that is at least my understanding of how LFA actually works --- or at least how it is supposed to work. In other words, per your routing table it is working as designed. However, this does not necessarily mean that OSPF LFA currently solves all of the problems with microloops in some topologies. If someone has a better explanation, I'd like to know, too. Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
