Serge,
Do you have "track-igp-metric" configured under LDP? I am pretty sure it
does not since your OSPF and LDP metrics are different but I'd like to
confirm.
Please try to configure "track-igp-metric" for LDP and re-run MPLS
traceroute.
Rgds
Alex
----- Original Message -----
From: "Serge Vautour" <[email protected]>
To: "Clarke Morledge" <[email protected]>; <[email protected]>
Sent: Tuesday, March 16, 2010 2:54 PM
Subject: Re: [j-nsp] OSPF LFA and LDP LSPs
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
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
