Tags:


Notable Replies

  1. The subnets shown on the network topologies for this lesson are not correct.

  2. Hi Kamal,

    It is confusing indeed. In these two documents:

    http://www.massimilianosbaraglia.it/documenti/engineering/routing/cisco/LFA%20fast%20reroute.pdf

    They explain that high priority prefixes get programmed before low priority prefixes. A high priority prefix is a /32 prefix.

    In this document:

    They state:

    Low priority specifies that all prefixes have the same eligibility for protection. High priority specifies that only high-priority prefixes are protected.

    So, the only thing left to do is a lab it up :slight_smile:

    To see this in action, I’ll enable all OSPF LFA debugs:

    R1#debug ip ospf fast-reroute rib
    OSPF Loop-free FastReroute local RIB debugging is on
    
    R1#debug ip ospf fast-reroute spf
    OSPF Loop-free FastReroute SPF computation debugging is on
    
    R1#debug ip ospf fast-reroute ti-lfa rib
    OSPF TI-LFA Loop-free FastReroute local RIB debugging is on
    
    R1#debug ip ospf fast-reroute ti-lfa spf
    OSPF TI-LFA Loop-free FastReroute SPF computation debugging is on

    Let’s enable prefix-priority high:

    R1(config)#router ospf 1
    R1(config-router)#fast-reroute per-prefix enable area 0 prefix-priority high

    And I’ll add a new /8 prefix on a physical interface of R5:

    R5(config)#interface GigabitEthernet1 
    R5(config-if)#ip address 55.55.55.55 255.0.0.0
    
    R5(config)#router ospf 1
    R5(config-router)#network 55.0.0.0 0.255.255.255 area 0

    Let’s check R1:

    R1#show ip route 55.0.0.0   
    Routing entry for 55.0.0.0/8
      Known via "ospf 1", distance 110, metric 2, type intra area
      Last update from 192.168.15.5 on GigabitEthernet3, 00:01:36 ago
      Routing Descriptor Blocks:
      * 192.168.15.5, from 5.5.5.5, 00:01:36 ago, via GigabitEthernet3
          Route metric is 2, traffic share count is 1

    It doesn’t have a repair path. In the debug, you can see why:

    OSPF-1 FRRIB: Add to LRIB repair path 55.0.0.0/255.0.0.0 via neighbor 5.5.5.5, area 0, type Intra, D(N,D)=1, ext2 metric 0 
    OSPF-1 FRRIB:   Prefix priority is lower than cfg threshold

    So it sees the prefix but ignores it because of the threshold. I looked for a command that allows me to change the threshold but I couldn’t find anything. Let’s try another prefix:

    R5(config)#interface GigabitEthernet 1
    R5(config-if)#ip address 55.55.55.55 255.255.0.0

    Still the same error:

    OSPF-1 FRRIB: Add to LRIB repair path 55.55.0.0/255.255.0.0 via neighbor 2.2.2.2, area 0, type Intra, D(N,D)=3, ext2 metric 0 
    OSPF-1 FRRIB:   Prefix priority is lower than cfg threshold 

    Another test:

    R5(config)#interface GigabitEthernet 1
    R5(config-if)#ip address 55.55.55.55 255.255.255.0
    OSPF-1 FRRIB: Add to LRIB repair path 55.55.55.0/255.255.255.0 via neighbor 5.5.5.5, area 0, type Intra, D(N,D)=1, ext2 metric 0 
    OSPF-1 FRRIB:   Prefix priority is lower than cfg threshold 

    Same problem, let’s try a /31:

    R5(config)#interface GigabitEthernet 1
    R5(config-if)#ip address 55.55.55.55 255.255.255.254
    OSPF-1 FRRIB: Add to LRIB repair path 55.55.55.54/255.255.255.254 via neighbor 5.5.5.5, area 0, type Intra, D(N,D)=1, ext2 metric 0 
    OSPF-1 FRRIB:   Prefix priority is lower than cfg threshold 

    Same issue, I can’t configure a /32 on a Physical interface but I can on a loopback. Let’s try that /31 first:

    R5(config)#interface Loopback 1
    R5(config-if)#ip address 55.55.55.55 255.255.255.254
    R5(config-if)#ip ospf network point-to-point
    OSPF-1 FRRIB: Add to LRIB repair path 55.55.55.54/255.255.255.254 via neighbor 5.5.5.5, area 0, type Intra, D(N,D)=1, ext2 metric 0 
    OSPF-1 FRRIB:   Prefix priority is lower than cfg threshold 

    Same issue…no repair path. Last try:

    R5(config)#interface Loopback 1
    R5(config-if)#ip address 55.55.55.55 255.255.255.255

    Now we have a repair path:

    R1#show ip route 55.55.55.55
    Routing entry for 55.55.55.55/32
      Known via "ospf 1", distance 110, metric 2, type intra area
      Last update from 192.168.15.5 on GigabitEthernet3, 00:00:23 ago
      Routing Descriptor Blocks:
      * 192.168.15.5, from 5.5.5.5, 00:00:23 ago, via GigabitEthernet3
          Route metric is 2, traffic share count is 1
          Repair Path: 3.3.3.3, via MPLS-Remote-Lfa1

    So it seems that with prefix-priority high, only /32 prefixes get a repair path. The debug message tells me that we should somehow be able to set a threshold but I’m unable to do so on my router:

    R1#show version 
    Cisco IOS XE Software, Version 16.06.01
    Cisco IOS Software [Everest], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.6.1, RELEASE SOFTWARE (fc2)

    It seems that on Cisco IOS XE, it means that only /32 prefixes get a backup path since I can’t configure a threshold. On other platforms and/or IOS versions this might be different.

    Hope this helps!

    Rene

  3. Hello Staut

    Remember that OSPF is a link state routing protocol. One of the characteristics of a link state protocol is that it has a full picture of the network’s topology, including costs of particular links. This information is enough for a router, when node protection as a tie breaker is enabled, to know what the next hop of another router will be to reach a particular destination. If that next hop is the same as the primary next hop for the particular destination, then the node protection tie breaker kicks in and chooses another route as the repair route.

    I hope this has been helpful!

    Laz

  4. Many thanks! I forgot that OSPF keeps the topology table besides the routing table.

Continue the discussion forum.networklessons.com

19 more replies!

Participants