[j-nsp] OSPF LFA and LDP LSPs

[Serge Vautour]

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/