[j-nsp] OSPF LFA and LDP LSPs
Serge Vautour
sergevautour at yahoo.ca
Mon May 31 12:23:28 EDT 2010
Hello,
An update on this thread for anyone who might find it in the future. It appears the problem (or design) is with the "traceroute mpls ldp" command. It will test both the primary and backup LSP paths setup by OSPF LFA. Per JTAC, I simulated customer traffic over my lab network and the backup LSP path was never used. As a resolution to the case JTAC has agreed to update the traceroute command documentation.
Serge
----- Original Message ----
From: Serge Vautour <sergevautour at yahoo.ca>
To: Alex <alex.arseniev at gmail.com>; juniper-nsp at puck.nether.net
Sent: Tue, March 16, 2010 3:25:38 PM
Subject: Re: [j-nsp] OSPF LFA and LDP LSPs
Hello,
Well that command explains a few things. Thanks! I do want the LDP LSPs to follow the OSPF shortest path. I had never really noticed that the inet.3 table entries had a different metric than my inet.0 entries. That helped make the metrics match however I still have the same problem.
Note the matching metrics:
---------------------
se36152 at 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
State: <Active Int>
Local AS: 855
Age: 8:04 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 300064
Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000
Label operation: Push 300000
State: <Active Int>
Local AS: 855
Age: 8:04 Metric: 2 <------- Matches inet.0
Task: LDP
Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2
AS path: I
---------------------
The same problem exists:
--------------------
se36152 at PE1-STJHLab-re0> show ldp route 10.10.80.2 logical-system PE10
Destination Next-hop intf/lsp Next-hop address
10.10.80.2/32 xe-0/3/0.0 10.10.81.10
ge-1/3/3.0 10.10.81.23
se36152 at PE1-STJHLab-re0> traceroute 10.10.80.2 no-resolve logical-system PE10
traceroute to 10.10.80.2 (10.10.80.2), 30 hops max, 40 byte packets
1 10.10.81.10 0.347 ms 0.268 ms 0.279 ms
2 10.10.80.2 36.471 ms 0.480 ms 0.436 ms
se36152 at PE1-STJHLab-re0> traceroute mpls ldp 10.10.80.2 no-resolve logical-system PE10
Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16
ttl Label Protocol Address Previous Hop Probe Status
1 300064 LDP 10.10.81.10 (null) Success
2 3 LDP 10.10.81.1 10.10.81.10 Egress
Path 1 via xe-0/3/0.0 destination 127.0.0.64
ttl Label Protocol Address Previous Hop Probe Status
1 300000 LDP 10.10.81.23 (null) Success
2 3 LDP 10.10.81.20 10.10.81.23 Egress
Path 2 via ge-1/3/3.0 destination 127.0.1.64
-------------------------
Note that the LDP LSP is still taking both paths?!?
Thanks,
Serge
----- Original Message ----
From: Alex <alex.arseniev at gmail.com>
To: Serge Vautour <serge at nbnet.nb.ca>; juniper-nsp at puck.nether.net
Sent: Tue, March 16, 2010 1:44:13 PM
Subject: Re: [j-nsp] OSPF LFA and LDP LSPs
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" <sergevautour at yahoo.ca>
To: "Clarke Morledge" <chmorl at wm.edu>; <juniper-nsp at puck.nether.net>
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 <chmorl at wm.edu>
> To: juniper-nsp at puck.nether.net
> Cc: Serge Vautour <sergevautour at yahoo.ca>
> 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:
>>
>> -----------------------
>> se36152 at 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 juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
__________________________________________________________________
Get a sneak peak at messages with a handy reading pane with All new Yahoo! Mail: http://ca.promos.yahoo.com/newmail/overview2/
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list