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:
---------------------
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
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:
--------------------
se36...@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
se36...@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
se36...@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 <[email protected]>
To: Serge Vautour <[email protected]>; [email protected]
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" <[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
__________________________________________________________________
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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
