[j-nsp] OSPF LFA and LDP LSPs

Clarke Morledge chmorl at wm.edu
Tue Mar 16 10:35:30 EDT 2010


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


More information about the juniper-nsp mailing list