Troubleshooting SRv6

Time of traffic switchover caused by a link failure exceeds the limit, causing TI-LFA FRR to fail and resulting in service packet loss

Symptom

In the SRv6 backbone network shown in Figure 1, IS-IS with BFD ensures rapid fault detection and IGP convergence. BFD monitors all IGP-advertised interfaces, using a detection multiplier of 3 and a 10 ms transmit/receive interval on both ends. This configuration allows BFD to detect and notify IS-IS of link failures within 30 ms, triggering immediate IGP reconvergence. During the link failure, traffic is forwarded over the TI-LFA FRR backup path to minimize disruption.

When the link between PE 1 and P 1 fails, traffic switchover takes too long, causing significant packet loss after the failure.

Figure 1 Network diagram

 

Common causes

The following are the common causes of this type of issue:

·     IS-IS with BFD does not take effect on PE 1.

·     PE1 cannot generate a TI-LFA FRR backup path, because the network topology does not contain a valid path meeting TI-LFA FRR requirements.

·     The TI-LFA FRR configuration is incorrect.

Troubleshooting flow

Figure 2 shows the troubleshooting flowchart.

Figure 2 Flowchart for service packet loss caused traffic switchover time exceeding the limit

 

Solution

To resolve the issue:

1.     Identify whether the IS-IS with BFD session is up.

On PE 1 and P 1, execute the display bfd session command to check the BFD session status between IS-IS neighbors. XGE0/0/6XGE0/0/6 that directly connects PE 1 and P 1 should establish a BFD session, and the value for the Session state field should be Up. Take PE 1 as an example.

<PE1> display bfd session

 Total sessions: 1        Up sessions: 1        Init mode: Active

 

 IPv6 session working in control packet mode:

 

       Local discr: 33793                Remote discr: 33793

         Source IP: FE80::881E:46FF:FEB8:406

    Destination IP: FE80::881E:49FF:FE25:506

     Session state: Up                      Interface: XGE0/0/6XGE0/0/6

         Hold time: 116ms

If no BFD session is established between XGE0/0/6XGE0/0/6 on PE 1 and P 1 or the value for the Session state field is Down, the BFD session is abnormal. Execute the isis ipv6 bfd enable command on the interfaces that connect PE 1 and P1 or execute the bfd all-interfaces enable command in IS-IS IPv6 address family view of PE 1 and P1 to enable BFD on IS-IS interfaces.

Execute the display bfd session verbose command to check the BFD session parameters. The values for Min Tx interval, Min Rx interval, and Actual Tx interval are 10 ms and the value for Detection time, which represents the actual detection interval, is 30 ms.

Take PE 1 as an example.

<PE1> display bfd session verbose

 Total sessions: 1        Up sessions: 1        Init mode: Active

 

 IPv6 session working in control packet mode:

          Local discr: 33793                      Remote discr: 33793

            Source IP: FE80::881E:46FF:FEB8:406

       Destination IP: FE80::881E:49FF:FE25:506

     Destination port: 3784                      Session state: Up

            Interface: Ten-GigabitEthernet0/0/6Ten-GigabitEthernet0/0/6

      Min Tx interval: 10ms                 Actual Tx interval: 10ms

      Min Rx interval: 10ms                     Detection time: 30ms

             Rx count: 973957                         Tx count: 974426

      Connection type: Direct                      Up duration: 13:46:28

            Hold time: 140ms                         Auth mode: None

       Detection mode: Async                              Slot: 0

             Protocol: ISIS6_BR_L2

              Version: 1

            Diag info: No Diagnostic

        Template name: a

        Hardware mode: Disable

Incorrect minimum transmit (Tx) interval, minimum receive (Rx) interval, or detection interval settings on both ends might cause a too long BFD detection interval and slow IGP convergence. On PE 1 and P 1, execute the bfd min-receive-interval, bfd min-transmit-interval, and bfd detect-multiplier commands to edit BFD session parameters in the associated BFD template view.

If the BFD session is normal and the parameters are correct but the issue persists, proceed to the next step.

2.     Identify whether a TI-LFA FRR path is generated correctly.

On PE 1, execute the display isis route ipv6 verbose command to identify whether the IPv6 route to PE 3 has a TI-LFA FRR backup path. If a backup path exists, the TI-LFA field and backup path details will be displayed in the output from the command.

<PE1> display isis route ipv6 3::3 128 verbose

 

                         Route information for IS-IS(1)

                         ------------------------------

 

                         Level-2 IPv6 forwarding table

                         -----------------------------

 

 IPv6 dest   : 3::3/128

 Flag        : R/-/-                       Cost        : 20

 Admin tag   : -                           Src count   : 1

 Algorithm   : 0

 Priority    : Medium

 Nexthop     : FE80::881E:49FF:FE25:506

 NexthopFlag : -

Interface   : XGE0/0/6                    Delay Flag : N/A

 TI-LFA:

  Interface : XGE0/0/7

  BkNextHop : FE80::881E:2DFF:FE19:107

  LsIndex    : 0x80000001

  Backup label stack(top->bottom): {600:1:2:3:0:1::}

 Nib ID      : 0x24000007

 FirstFlushTime: 15h35m19s                 LatestUpdateTime: 15h35m19s

 

      Flags: D-Direct, R-Added to Rib, L-Advertised in LSPs, U-Up/Down Bit Set

If no TI-LFA FRR backup path exists, first check the network topology. Make sure at least one backup path remains between PE 1 and P 1 after a link failure. This means the topology must have one primary route and at least one backup route when no failure occurs.

If the network topology does not contain a backup path, redesign the network connections.

If the network topology has a backup path but the TI-LFA FRR backup path fails to be generated, proceed to the next step.

3.     Verify that the TI-LFA FRR configuration is correct.

On PE 1, execute the display current-configuration command to check the TI-LFA FRR configuration.

#

isis 1

 #

 address-family ipv6 unicast

  fast-reroute lfa

  fast-reroute ti-lfa

  segment-routing ipv6 locator a

#

#

segment-routing ipv6

 #

 locator a ipv6-prefix 100:1:2:3:: 64 static 16 args 16

#

¡     Before you enable TI-LFA FRR with the fast-reroute ti-lfa command in IS-IS IPv6 address family view, first enable LFA FRR by executing the fast-reroute lfa command in IS-IS IPv6 unicast address family view.

¡     Make sure the isis ipv6 fast-reroute ti-lfa disable command is not configured to prevent an IS-IS interface from participating in TI-LFA calculation on any of the interfaces on the backup path. If the command is configured, execute the undo isis ipv6 fast-reroute ti-lfa disable command to allow an IS-IS interface to participate in TI-LFA calculation.

¡     To enable TI-LFA FRR in an SRv6 network, make sure all forwarding devices support SRv6 and SRv6 locators are correctly configured and advertised via IGP. If you fail to do so, SRv6 SIDs will not be allocated to interfaces, causing TI-LFA FRR backup path calculation failure.

If the TI-LFA FRR configuration is correct but no backup path is generated, proceed to the next step.

4.     If the issue persists, collect the following information and contact Technical Support:

¡     Results of each step.

¡     The configuration file, log messages, and alarm messages.

Related alarm and log messages

Alarm messages

N/A

Log messages

·     N/A

The traffic switchover time caused by egress node failure is too long

Symptom

In an SRv6 backbone network shown in Figure 3, CE 2 is dual-homed to PE 3 and PE 4. Typically, VPN traffic is forwarded through the SRv6 TE policy or SRv6 BE between PE 1 and PE 3. If PE 3 (egress node) fails, BFD for SRv6 locators or SBFD for SRv6 locators triggers rapid traffic switchover to PE 4. The BFD or SBFD detection time multiplier is 3 and the transmit and receive intervals are both 50 ms at both ends. Therefore, the actual detection time should not exceed 150 ms. BGP FRR at the egress node must be completed quickly after being triggered by BFD or SBFD.

However, the time for BGP FRR caused by egress node failure is too long, causing significant packet loss.

Figure 3 Network diagram

 

Common causes

The following are the common causes of this type of issue:

·     BFD for SRv6 locators or SBFD for SRv6 locators does not take effect.

·     The configuration for BFD for SRv6 locators or SBFD for SRv6 locators is incorrect.

·     BGP FRR is not configured.

Troubleshooting flow

Figure 4 shows the troubleshooting flowchart.

Figure 4 Flowchart for troubleshooting significant packet loss caused by too long BGP FRR

 

Solution

1.     Verify that a BFD/SBFD session is established successfully between PE 1 and PE 3.

On PE 1, configure BFD for SRv6 locators or SBFD for SRv6 locators to check the reachability of the SRv6 locator address advertised by PE 3. This will trigger a fast BGP FRR. Either detection method works.

¡     Execute the display bfd session command on PE 1. Verify that BFD session entries exist, the value for the Destination IP field is the SRv6 locator address for PE 3, and the value for the Session state field is Up.

[PE1] display bfd session

 Total sessions: 1        Up sessions: 1        Init mode: Active

 

 IPv6 static session working in control packet mode:

 

       Local discr: 101                  Remote discr: 102

         Source IP: 100:1::

    Destination IP: 200:1::

     Session state: Up                      Interface: N/A

         Hold time: 116ms

If no BFD for SRv6 locator session exists or the session state is down, perform the following tasks:

-     Execute the bfd static command in system view of PE 1 and PE 3 to set up static BFD sessions, and set the value for peer-ipv6 to the peer SRv6 locator address.

-     In static BFD session view, execute the discriminator command to specify the local and remote discriminators for a static BFD session. Make sure the remote discriminator on PE 1 is the same as the local discriminator on PE 3, and the remote discriminator on PE 3 is the same as the local discriminator on PE 1. The following is the configuration for PE 1:

#

bfd static aaa peer-ipv6 200:1:: source-ipv6 100:1::

 discriminator local 101

 discriminator remote 102

#

¡     Execute the display sbfd session initiator command on PE 1 . Verify that SBFD session entries exist, the value for the Destination IP field is the SRv6 locator address for PE 3, and the value for the Session state field is Up.

[PE1] display sbfd session initiator

 Total sessions: 2     Up sessions: 2

 

 SBFD Session (IPv6):

       Local discr: 33793                Remote discr: 1000002

         Source IP: 100:1::

    Destination IP: 300:1::

     Session state: Up                      Hold time: 123ms

 

       Local discr: 33794                Remote discr: 1000001

         Source IP: 100:1::

    Destination IP: 200:1::

     Session state: Up                      Hold time: 124ms

If no SBFD session entries exist, or the session state is down, perform the following tasks:

-     Execute the locator-sbfd enable command in SRv6 view of PE 1 to establish an SBFD for SRv6 locator session.

-     Execute the sbfd destination ipv6 remote-discriminator command on PE 1 to associate the destination IPv6 address of the detected path with the remote discriminator of the SBFD session for the initiator.

-     On PE 3, execute the sbfd local-discriminator command to specify the local discriminator for the reflector, making sure the discriminators on PE 1 and PE 3 are the same. The following is the configuration for PE 1:

#

segment-routing ipv6

 locator-sbfd enable template a

#

 sbfd source-ipv6 100:1::

 sbfd destination ipv6 200:1:: remote-discriminator 1000001

#

If a BFD/SBFD session is established successfully between PE 1 and PE 3 but the issue persists, proceed to the next step.

2.     Verify that the BFD/SBFD session parameters between PE 1 and PE 3 are correct.

¡     Execute the display bfd session verbose command on PE 1 and PE 3 to check the BFD session parameters. The values for Min Tx interval, Min Rx interval, and Actual Tx interval are 50 ms and the value for Detection time, which represents the actual detection interval, is 150 ms. Take PE 1 as an example.

[PE1] display bfd session verbose

 Total sessions: 1        Up sessions: 1        Init mode: Active

 

 IPv6 static session working in control packet mode:

         Session name: aaa

          Local discr: 101                        Remote discr: 102

            Source IP: 100:1::

       Destination IP: 200:1::

     Destination port: 4784                      Session state: Up

            Interface: N/A

      Min Tx interval: 50ms                 Actual Tx interval: 50ms

      Min Rx interval: 50ms                     Detection time: 150ms

             Rx count: 80068                          Tx count: 73230

      Connection type: Indirect                    Up duration: 01:01:13

            Hold time: 144ms                         Auth mode: None

       Detection mode: Async                              Slot: 0

             Protocol: STATIC_IPv6

              Version: 1

            Diag info: No Diagnostic

        Hardware mode: Disable

Incorrect minimum transmit (Tx) interval, minimum receive (Rx) interval, or detection interval settings on both ends might cause a too long BFD detection interval and slow BGP FRR. On PE 1 and PE 3, execute thebfd multi-hop min-transmit-interval, bfd multi-hop min-receive-interval, and bfd multi-hop detect-multiplier commands to edit BFD session parameters in static BFD session view.

#

bfd static aaa peer-ipv6 200:1:: source-ipv6 100:1::

 discriminator local 101

 discriminator remote 102

 bfd multi-hop min-transmit-interval 50

 bfd multi-hop min-receive-interval 50

 bfd multi-hop detect-multiplier 3

#

¡     Execute the display sbfd session initiator verbose command to check the SBFD session parameters. The values for Min Tx interval, Min Rx interval, and Actual Tx interval are 50 ms and the value for Detection time, which represents the actual detection interval, is 150 ms. Take PE 1 as an example.

[PE1] display sbfd session initiator verbose

 Total sessions: 2     Up sessions: 2

 

 SBFD Session (IPv6):

          Local discr: 33793                      Remote discr: 1000002

            Source IP: 100:1::

       Destination IP: 300:1::

        Session state: Up                            Hold time: 110ms

      Min Tx interval: 50ms                 Actual Tx interval: 50ms

       Detection time: 150ms                       Up duration: 00:36:13

             Rx count: 45661                          Tx count: 46210

                 Slot: 0

             Protocol: IPFRR/BGP4+

            Diag info: No Diagnostic

        Template name: a

        Hardware mode: Disable

 

          Local discr: 33794                      Remote discr: 1000001

            Source IP: 100:1::

       Destination IP: 200:1::

        Session state: Up                            Hold time: 123ms

      Min Tx interval: 50ms                 Actual Tx interval: 50ms

       Detection time: 150ms                       Up duration: 00:36:13

             Rx count: 49346                          Tx count: 49357

                 Slot: 0

             Protocol: IPFRR/BGP4+

            Diag info: No Diagnostic

        Template name: a

        Hardware mode: Disable

Incorrect minimum transmit (Tx) (Rx) interval, or detection interval settings on both ends might cause a too long SBFD detection interval and slow BGP FRR. On PE 1, execute the locator-sbfd enable [ template template-name ] command to edit BFD session parameters.

#

segment-routing ipv6

 locator-sbfd enable template a

#

#

bfd template a

 bfd min-transmit-interval 50

 bfd min-receive-interval 50

 bfd detect-multiplier 3

#

If the BFD/ SBFD parameters are correct but the issue persists, proceed to the next step.

3.     Identify whether BGP FRR is enabled on PE 1 and FRR backup routes are generated correctly.

On PE 1, execute the display bgp routing-table ipv4 vpn-instance command to verify that private network VPN route 22.22.22.22/32 advertised by PE 3 is received correctly. The output from the command should display two valid VPN routes, 22.22.22.22/32 marked with * (valid), and the other marked with > (optimal). The optimal and valid VPN route is advertised by PE 3, with PE 3 as the next hop. The valid but non-optimal route is a BGP FRR backup route advertised by PE 4, with PE 4 as the next hop.

[PE1] display bgp routing-table ipv4 vpn-instance vpn1

 

 Total number of routes: 10

 

 BGP local router ID is 1.1.1.1

 Status codes: * - valid, > - best, d - dampened, h - history,

               s - suppressed, S - stale, i - internal, e - external

               a - additional-path

       Origin: i - IGP, e - EGP, ? - incomplete

 

     Network            NextHop         MED        LocPrf     PrefVal Path/Ogn

 

* >  10.1.1.0/24        10.1.1.2        0                     32768   ?

*  e                    10.1.1.1        0                     0       200?

* >  10.1.1.2/32        127.0.0.1       0                     32768   ?

* >e 11.11.11.11/32     10.1.1.1        0                     0       200?

* >i 20.1.1.0/24        2::2            0          100        0       ?

*  i                    3::3            0          100        0       300?

* >i 22.22.22.22/32     2::2            0          100        0       300?

*  i                    3::3            0          100        0       300?

* >i 30.1.1.0/24        3::3            0          100        0       ?

*  i                    2::2            0          100        0       300?

If no BGP FRR backup route exists, identify whether BGP FRR is enabled. If it is not enabled, execute the pic command in BGP-VPN IPv4 unicast address family view to enable BGP FRR.

#

bgp 100

 #

 ip vpn-instance vpn1

  #

  address-family ipv4 unicast

   pic

#

If VPN FRR is enabled on PE 1 and FRR backup routes are generated correctly, but the issue persists, collect the following information and contact Technical Support:

¡     Results of each step.

¡     The configuration file, log messages, and alarm messages.

Related alarm and log messages

Alarm messages

N/A

Log messages

N/A