[j-nsp] OSPF LFA and LDP LSPs

Serge Vautour sergevautour at yahoo.ca
Tue Mar 16 08:51:39 EDT 2010


Hello,

We are testing MPLS in our lab using two MX960s with a few LS to add more routers. I'm using OSPF as the IGP and LDP for transport labels. We're on 10.0 code so I've been testing OSPF LFA. It appears to be doing something strange and I can't tell if it's per design or a bug.

Here's a PE's route to a destination PE loopback:

----------------------
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 index: 1192
                Next-hop reference count: 40
                Next hop: 10.10.81.10 via xe-0/3/0.0, selected
                State: <Active Int>
                Local AS:   855 
                Age: 2  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, selected
                Label operation: Push 299776
                State: <Active Int>
                Local AS:   855 
                Age: 2  Metric: 1 
                Task: LDP
                Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2 
                AS path: I

{master}
se36152 at PE1-STJHLab-re0> show ldp route logical-system PE10 10.10.80.2 extensive    
Destination         Next-hop intf/lsp                Next-hop address
 10.10.80.2/32      xe-0/3/0.0                       10.10.81.10
   Session ID 10.10.80.10:0--10.10.80.1:0
   Bound to outgoing label 299840, Topology entry: 0x8e69980
   Ingress route status: Active, Last modified: 00:00:10 ago

se36152 at PE1-STJHLab-re0> traceroute 10.10.80.2 logical-system PE10 no-resolve 
traceroute to 10.10.80.2 (10.10.80.2), 30 hops max, 40 byte packets
 1  10.10.81.10  0.353 ms  0.274 ms  0.279 ms
 2  10.10.80.2  0.460 ms  0.455 ms  0.437 ms

{master}
se36152 at PE1-STJHLab-re0> traceroute mpls ldp 10.10.80.2 logical-system PE10 no-resolve
  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299776  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
----------------------

Everything is normal. IP packets are following the OSPF shortest path per the costs I've set. The LDP LSP is following OSPF.

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

{master}
se36152 at PE1-STJHLab-re0> show ldp route logical-system PE10 10.10.80.2 extensive         
Destination         Next-hop intf/lsp                Next-hop address
 10.10.80.2/32      xe-0/3/0.0                       10.10.81.10
   Session ID 10.10.80.10:0--10.10.80.1:0
                    ge-1/3/3.0                       10.10.81.23
   Session ID 10.10.80.10:0--10.10.80.14:0
   Bound to outgoing label 299840, Topology entry: 0x8e69980
   Ingress route status: Active, Last modified: 00:00:09 ago

{master}
se36152 at PE1-STJHLab-re0> traceroute 10.10.80.2 logical-system PE10 no-resolve            
traceroute to 10.10.80.2 (10.10.80.2), 30 hops max, 40 byte packets
 1  10.10.81.10  0.407 ms  0.282 ms  0.283 ms
 2  10.10.80.2  0.904 ms  1.086 ms  1.066 ms

{master}
se36152 at PE1-STJHLab-re0> traceroute mpls ldp 10.10.80.2 logical-system PE10 no-resolve   
  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299776  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   299856  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  <--- Why does this get used??
-----------------------

The path via ge-1/3/3 is a backup path chosen by OSPF LFA. As expected IP packets don't use it when I do a traceroute. The "traceroute mpls ldp" however seems to use both paths?!? Does this mean that the ingress PE could dump traffic on both LSPs? I don't want this as only 1 of the 2 is the preferred path...

Any ideas?

Thanks,
Serge



      __________________________________________________________________
Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail.  Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca


More information about the juniper-nsp mailing list