Troubleshooting segment routing

EVPN L3VPN over SRv6 issues

EVPN L3VPN over SRv6 BE traffic forwarding failure

Symptom

On an EVPN L3VPN over SRv6 network shown in Figure 1, traffic forwarding failure occurs when the PEs use the SRv6 BE mode to forward the private service traffic in VPN 1 between CE 1 and CE 2.

The troubleshooting flow is the same for IPv4 and IPv6 private networks. The following information uses IPv4 for example to describe the troubleshooting procedure for EVPN L3VPN over SRv6.

Figure 1 Network diagram

‌

Table 1 shows the key network planning information for the EVPN L3VPN over SRv6 network.

Table 1 SRv6 locators and major addresses in the address plan

Device	Interface or locator	Address	Device	Interface or locator	Address
PE 1	SRv6 Locator	100:1::/64	PE 2	SRv6 Locator	300:1::/64
	Loopback0	1::1/128		Loopback0	3::3/128
CE 1	Loopback0	10.10.10.10/32	CE 2	Loopback0	20.20.20.20/32
	Loopback1	11.11.11.11/32		Loopback1	22.22.22.22/32
P	SRv6 Locator	200:1::/64
	Loopback0	2::2/128

 

Common causes

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

·     The PEs cannot learn public network routes because of the failure to establish BGP EVPN peer relationships.

·     EVPN L3VPN over SRv6 configuration is incomplete.

·     The routes for the SRv6 SIDs are unreachable.

Troubleshooting flow

Figure 2 shows the troubleshooting flowchart.

Figure 2 Flowchart for troubleshooting EVPN L3VPN over SRv6 BE traffic forwarding failure

 

Solution

1.     Ping the private IP on the remote PE from the local PE to check its connectivity. When you do that, specify the name of the VPN instance to which the private IP address belongs.

<Sysname> ping -vpn-instance vpn1 20.20.20.20

Ping 20.20.20.20 (20.20.20.20): 56 data bytes, press CTRL+C to break

56 bytes from 20.20.20.20: icmp_seq=0 ttl=254 time=2.000 ms

56 bytes from 20.20.20.20: icmp_seq=1 ttl=254 time=1.000 ms

56 bytes from 20.20.20.20: icmp_seq=2 ttl=254 time=1.000 ms

56 bytes from 20.20.20.20: icmp_seq=3 ttl=254 time=1.000 ms

56 bytes from 20.20.20.20: icmp_seq=4 ttl=254 time=2.000 ms

 

--- Ping statistics for 20.20.20.20 in VPN instance vpn1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 1.000/1.400/2.000/0.490 ms

If the ping test fails, the private network service is unavailable. Proceed to the next step.

2.     Perform the subsequent checks on both the local and remote PE devices. This document takes the local PE device for example. Execute the display ip routing-table vpn-instance command on the local PE device to check the VPN routing table for routes to the private IP addresses.

<Sysname> display ip routing-table vpn-instance vpn1

 

Destinations : 10       Routes : 10

 

Destination/Mask   Proto   Pre Cost        NextHop         Interface

10.1.1.0/24        Direct  0   0           10.1.1.2        GE2/0/1

10.1.1.2/32        Direct  0   0           127.0.0.1       GE2/0/1

10.1.1.255/32      Direct  0   0           10.1.1.2        GE2/0/1

10.10.10.10/32     BGP     255 0           10.1.1.1        GE2/0/1

11.11.11.11/32     BGP     255 0           10.1.1.1        GE2/0/1

20.1.1.0/24        BGP     255 0           3::3            GE2/0/2

20.20.20.20/32     BGP     255 0           3::3            GE2/0/2

22.22.22.22/32     BGP     255 0           3::3            GE2/0/2

127.0.0.0/8        Direct  0   0           127.0.0.1       InLoop0

255.255.255.255/32 Direct  0   0           127.0.0.1       InLoop0

If the device has VPN routes to the private IP addresses, verify that the FIB contains entries for these addresses, with a U flag in the Flag field. The U flag indicates that the private network IP address is valid.

<Sysname> display fib vpn-instance vpn1

Route destination count: 10

Directly-connected host count: 1

 

Flag:

  U:Usable   G:Gateway   H:Host   B:Blackhole   D:Dynamic   S:Static

  R:Relay     F:FRR

 

Destination/Mask   Nexthop         Flag     OutInterface/Token       Label

11.11.11.11/32     10.1.1.1        UGHR     GE2/0/1                  Null

127.0.0.0/8        127.0.0.1       U        InLoop0                  Null

10.1.1.0/24        10.1.1.2        U        GE2/0/1                  Null

20.20.20.20/32     3::3            UGHR     GE2/0/2                  Null

10.1.1.2/32        127.0.0.1       UH       GE2/0/1                  Null

22.22.22.22/32     3::3            UGHR     GE2/0/2                  Null

10.1.1.255/32      10.1.1.2        UBH      GE2/0/1                  Null

255.255.255.255/32 127.0.0.1       UH       InLoop0                  Null

10.10.10.10/32     10.1.1.1        UGHR     GE2/0/1                  Null

10.1.1.1/32        10.1.1.1        UH       GE2/0/1                  Null

20.1.1.0/24        3::3            UGR      GE2/0/2                  Null

If a private IP address does not exist or is invalid in the VPN routing table or VPN FIB, proceed to check for BGP EVPN route learning issues between PEs and verify that a valid tunnel exists between them.

3.     Execute the display bgp peer l2vpn evpn command on the local PE device to verify that it has established a BGP EVPN peer relationship with the remote PE device.

¡     If the PE devices have established a BGP EVPN peer relationship successfully, the State field in the command output displays Established. Proceed to step 4.

¡     If the PE devices have not established a BGP EVPN peer relationship, see the troubleshooting procedure for BGP peer establishment issues.

<Sysname> display bgp peer l2vpn evpn

 

 BGP local router ID: 1.1.1.1

 Local AS number: 100

 Total number of peers: 1                 Peers in established state: 1

 

 * - Dynamically created peer

 Peer                    AS  MsgRcvd  MsgSent OutQ  PrefRcv Up/Down  State

 

 3::3                   100       13       10    0        2 00:00:05 Established

4.     Execute the display bgp l2vpn evpn command on the local PE device to verify that it has learned the BGP EVPN routes from the remote PE device. Pay special attention to the PrefixSID field for each route in the command output. In this field, the End.DT4 SID represents the SRv6 SID assigned by the remote PE to the VPN private IP address. When forwarding traffic to that private address in SRv6 BE mode, the local PE device uses that End.DT4 SID as the destination address in the IPv6 packets.

<Sysname> display bgp l2vpn evpn [5][0][32][20.20.20.20]/80

 

 BGP local router ID: 1.1.1.1

 Local AS number: 100

 

 

 Route distinguisher: 100:1(vpn1)

 Total number of routes: 1

 Paths:   1 available, 1 best

 

 BGP routing table information of [5][0][32][20.20.20.20]/80:

 From            : 3::3 (3.3.3.3)

 Rely nexthop    : FE80::A2C3:E2FF:FEB5:306

 Original nexthop: 3::3

 Out interface   : GigabitEthernet2/0/2

 Route age       : 00h28m51s

 OutLabel        : 3

 Ext-Community   : <RT: 100:1>

 RxPathID        : 0x0

 TxPathID        : 0x0

 PrefixSID       : End.DT4 SID <300:1::A>

  SRv6 Service TLV (37 bytes):

   Type: SRV6 L3 Service TLV (5)

   Length: 34 bytes, Reserved: 0x0

   SRv6 Service Information Sub-TLV (33 bytes):

    Type: 1 Length: 30, Rsvdl: 0x0

    SID Flags: 0x0  Endpoint behavior: 0x13 Rsvd2: 0x0

    SRv6 SID Sub-Sub-TLV:

     Type: 1 Len: 6

     BL: 64 NL: 0 FL: 64 AL: 0 TL: 0 TO: 0

 AS-path         : 300

 Origin          : incomplete

 Attribute value : MED 0, localpref 100, pref-val 0

 State           : valid, internal, best

 Source type     : local

 IP precedence   : N/A

 QoS local ID    : N/A

 Traffic index   : N/A

 EVPN route type : IP prefix advertisement route

 ESI             : 0000.0000.0000.0000.0000

 Ethernet tag ID : 0

 IP prefix       : 20.20.20.20/32

 Gateway address : 0.0.0.0

 MPLS label      : 3

 Tunnel policy   : NULL

 Rely tunnel IDs : N/A

 Re-orignination : Disable

If the local PE device has learned a BGP EVPN route to the remote destination address and its PrefixSID attribute is correct, execute the display bgp routing-table ipv4 vpn-instance command on the local PE device to verify that the route has been added to the BGP EVPN routing table. Verify that the route is both valid and the best. Only valid and optimal BGP routes can be learned into a VPN routing table.

<Sysname> display bgp routing-table ipv4 vpn-instance vpn1

 

 Total number of routes: 8

 

 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 10.10.10.10/32     10.1.1.1        0                     0       200?

* >e 11.11.11.11/32     10.1.1.1        0                     0       200?

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

* >i 20.20.20.20/32     3::3            0          100        0       300?

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

If the local PE device has failed to learn a valid and optimal BGP EVPN route, or if the PrefixSID attribute is missing from the BGP EVPN route, proceed to check for incomplete EVPN L3VPN over SRv6 configuration. An incomplete configuration might result in failure to allocate SRv6 SIDs or to establish an SRv6 tunnel.

5.     Verify that the configuration for EVPN L3VPN over SRv6 on both PE devices is complete. If the configuration is incomplete, add the missing configuration. If the configuration is complete, proceed to step 6.

Execute the display current-configuration command on both PE devices to check for the following configuration items. If they are missing, see EVPN L3VPN over SRv6 configuration in Segment Routing Configuration Guide to add the missing configuration items.

#

isis 1

 cost-style wide-compatible

 #

 address-family ipv6 unicast

  segment-routing ipv6 locator aaa        //Enable IS-IS to advertise the specified locator and the SRv6 SIDs in the locator.

#

#

bgp 100

 peer 3::3 as-number 100

 #

 address-family l2vpn evpn

  peer 3::3 enable

  peer 3::3 advertise encap-type srv6       //Adertise SRv6-encapsulated EVPN routes with the PrefixSID attribute to the peer or peer group.

 #

 ip vpn-instance vpn1

  #

  address-family ipv4 unicast

   segment-routing ipv6 best-effort evpn //Steer route matching traffic to an SRv6 BE tunnel.

   segment-routing ipv6 locator aaa evpn //Apply the locator to the BGP process so the device can use the locator to allocate SRv6 SIDs for the private network routes in the specified VPN instance.

#

segment-routing ipv6

 encapsulation source-address 11::11      //Specify the source address for the outer IPv6 header of SRv6 VPN packets.

 locator aaa ipv6-prefix 300:1:: 64 static 8  //Create a Locator segment.

#

If the SRv6 configuration is complete and correct, proceed to check for unreachable SRv6 SIDs on the forwarding path.

6.     Execute the display ipv6 routing-table ipv6-address command on all devices along the forwarding path to check for routes to the SRv6 SIDs on both PEs.

<Sysname> display ipv6 routing-table 300:1::A

 

Summary count : 2

 

Destination: 300:1::/64                                  Protocol  : IS_L1

NextHop    : FE80::A2C3:E2FF:FEB5:306                    Preference: 15

Interface  : GE2/0/2                                     Cost      : 20

Execute the ping ipv6 command on all devices to verify the connectivity to the SRv6 SIDs.

<Sysname> ping ipv6 300:1::A

Ping6(56 data bytes) 1001::1 --> 300:1::A, press CTRL+C to break

56 bytes from 300:1::A, icmp_seq=0 hlim=63 time=2.000 ms

56 bytes from 300:1::A, icmp_seq=1 hlim=63 time=1.000 ms

56 bytes from 300:1::A, icmp_seq=2 hlim=63 time=0.000 ms

56 bytes from 300:1::A, icmp_seq=3 hlim=63 time=1.000 ms

56 bytes from 300:1::A, icmp_seq=4 hlim=63 time=0.000 ms

 

--- Ping6 statistics for 300:1::A ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.000/0.800/2.000/0.748 ms

If a route exists to the SRv6 SID at the remote end and the ping test succeeds, proceed to step 7. If no route exists to the SRv6 SID or the ping test fails, check for the failure of IGP on the PE devices to advertise the network segment in the locator for the SID to other devices in the domain. In this situation, use Layer 3—IP Routing Troubleshooting Guide to resolve the IGP route advertisement issue.

7.     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

EVPN L3VPN over SRv6 TE traffic forwarding failure

Symptom

On an EVPN L3VPN over SRv6 network shown in Figure 3, traffic forwarding failure occurs when the PEs use the SRv6 TE mode to forward the private service traffic between CE 1 and CE 2 in VPN 1 through an SRv6 TE policy.

The troubleshooting flow is the same for IPv4 and IPv6 private networks. The following information uses IPv4 for example to describe the troubleshooting procedure for EVPN L3VPN over SRv6.

Figure 3 Network diagram

‌

Table 2 shows the key network planning information for the EVPN L3VPN over SRv6 network.

Table 2 SRv6 locators and major addresses in the address plan

Device	Interface or locator	Address	Device	Interface or locator	Address
PE 1	SRv6 Locator	100:1::/64	PE 2	SRv6 Locator	300:1::/64
	Loopback0	1::1/128		Loopback0	3::3/128
CE 1	Loopback0	10.10.10.10/32	CE 2	Loopback0	20.20.20.20/32
	Loopback1	11.11.11.11/32		Loopback1	22.22.22.22/32
P	SRv6 Locator	200:1::/64
	Loopback0	2::2/128

 

Common causes

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

·     The PEs cannot learn VPN routes because of the failure to establish BGP EVPN peer relationships.

·     Recursive routing is not performed in SRv6 TE mode.

·     The SRv6 TE policy for the EVPN route is down.

·     The routes for the SRv6 SIDs are unreachable.

Troubleshooting flow

Figure 4 shows the troubleshooting flowchart.

Figure 4 Flowchart for troubleshooting EVPN L3VPN over SRv6 TE traffic forwarding failure

 

Solution

1.     Ping the private IP on the remote PE from the local PE to check its connectivity. When you do that, specify the name of the VPN instance to which the private IP address belongs.

<Sysname> ping -vpn-instance vpn1 20.20.20.20

Ping 20.20.20.20 (20.20.20.20): 56 data bytes, press CTRL+C to break

56 bytes from 20.20.20.20: icmp_seq=0 ttl=254 time=2.000 ms

56 bytes from 20.20.20.20: icmp_seq=1 ttl=254 time=1.000 ms

56 bytes from 20.20.20.20: icmp_seq=2 ttl=254 time=1.000 ms

56 bytes from 20.20.20.20: icmp_seq=3 ttl=254 time=1.000 ms

56 bytes from 20.20.20.20: icmp_seq=4 ttl=254 time=2.000 ms

 

--- Ping statistics for 20.20.20.20 in VPN instance vpn1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 1.000/1.400/2.000/0.490 ms

If the ping test fails, the private network service is unavailable. Proceed to the next step.

2.     Perform the subsequent checks on both the local and remote PE devices. This document takes the local PE device for example. Execute the display ip routing-table vpn-instance vpn1 command on the local PE device to check the VPN routing table for routes to the private IP addresses. Verify that the outgoing interface in the route to the remote private IP address is the name of the expected SRv6 TE policy.

<Sysname> display ip routing-table vpn-instance vpn1

 

Destinations : 10       Routes : 10

 

Destination/Mask   Proto   Pre Cost        NextHop         Interface

10.1.1.0/24        Direct  0   0           10.1.1.2        GE2/0/1

10.1.1.2/32        Direct  0   0           127.0.0.1       GE2/0/1

10.1.1.255/32      Direct  0   0           10.1.1.2        GE2/0/1

10.10.10.10/32     BGP     255 0           10.1.1.1        GE2/0/1

11.11.11.11/32     BGP     255 0           10.1.1.1        GE2/0/1

20.1.1.0/24        BGP     255 0           3::3            p1

20.20.20.20/32     BGP     255 0           3::3            p1

22.22.22.22/32     BGP     255 0           3::3            p1

127.0.0.0/8        Direct  0   0           127.0.0.1       InLoop0

255.255.255.255/32 Direct  0   0           127.0.0.1       InLoop0

If the device has routes to the private IP addresses in the VPN instance, verify that the FIB contains entries for these addresses, with a U flag in the Flag field. The U flag in an entry indicates that the entry for the IP address is valid. Verify that the outgoing interface/token field in the route to the remote private IP address contains the forwarding index for the expected SRv6 TE policy.

<Sysname> display fib vpn-instance vpn1

Route destination count: 10

Directly-connected host count: 1

 

Flag:

  U:Usable   G:Gateway   H:Host   B:Blackhole   D:Dynamic   S:Static

  R:Relay     F:FRR

 

Destination/Mask   Nexthop         Flag     OutInterface/Token       Label

11.11.11.11/32     10.1.1.1        UGHR     GE2/0/1                  Null

127.0.0.0/8        127.0.0.1       U        InLoop0                  Null

10.1.1.0/24        10.1.1.2        U        GE2/0/1                  Null

20.20.20.20/32     3::3            UGHR     2150629377               Null

10.1.1.2/32        127.0.0.1       UH       GE2/0/1                  Null

22.22.22.22/32     3::3            UGHR     2150629377               Null

10.1.1.255/32      10.1.1.2        UBH      GE2/0/1                  Null

255.255.255.255/32 127.0.0.1       UH       InLoop0                  Null

10.10.10.10/32     10.1.1.1        UGHR     GE2/0/1                  Null

10.1.1.1/32        10.1.1.1        UH       GE2/0/1                  Null

20.1.1.0/24        3::3            UGR      2150629377               Null

Proceed to check for BGP EVPN route learning issues between PEs and verify that a valid SRv6 TE policy exists between them in either of the following situations:
The VPN routing table or VPN FIB does not contain a valid entry for a private IP address.
The entry does not contain the expected SRv6 TE policy as the outgoing interface.

3.     Execute the display bgp peer l2vpn evpn command on the local PE device to verify that it has established a BGP EVPN peer relationship with the remote PE device.

¡     If the PE devices have established a BGP EVPN peer relationship successfully, the State field in the command output displays Established. Proceed to step 4.

¡     If the PE devices have not established a BGP EVPN peer relationship, see the troubleshooting procedure for BGP peer establishment issues.

<Sysname> display bgp peer l2vpn evpn

 

 BGP local router ID: 1.1.1.1

 Local AS number: 100

 Total number of peers: 1                 Peers in established state: 1

 

 * - Dynamically created peer

 Peer                    AS  MsgRcvd  MsgSent OutQ  PrefRcv Up/Down  State

 

 3::3                   100      145      145    0        3 01:56:37 Established

4.     Execute the display bgp l2vpn evpn command on the local PE to verify that it has learned the BGP EVPN routes from the remote PE. Pay special attention to the PrefixSID field for each route in the command output. In this field, the End.DT4 SID represents the SRv6 SID assigned by the remote PE to the VPN private IP address. When forwarding traffic to that private address in SRv6 TE mode, the local PE encapsulates that End.DT4 SID as the last SID in the SRH expansion header, along with the SID list in the SRv6 TE policy.

<Sysname> display bgp l2vpn evpn [5][0][32][20.20.20.20]/80

 

 BGP local router ID: 1.1.1.1

 Local AS number: 100

 

 

 Route distinguisher: 100:1(vpn1)

 Total number of routes: 1

 Paths:   1 available, 1 best

 

 BGP routing table information of [5][0][32][20.20.20.20]/80:

 From            : 3::3 (3.3.3.3)

 Rely nexthop    : FE80::A2C3:E2FF:FEB5:306

 Original nexthop: 3::3

 Out interface   : GigabitEthernet2/0/2

 Route age       : 00h28m51s

 OutLabel        : 3

 Ext-Community   : <RT: 100:1>

 RxPathID        : 0x0

 TxPathID        : 0x0

 PrefixSID       : End.DT4 SID <300:1::A>

  SRv6 Service TLV (37 bytes):

   Type: SRV6 L3 Service TLV (5)

   Length: 34 bytes, Reserved: 0x0

   SRv6 Service Information Sub-TLV (33 bytes):

    Type: 1 Length: 30, Rsvdl: 0x0

    SID Flags: 0x0  Endpoint behavior: 0x13 Rsvd2: 0x0

    SRv6 SID Sub-Sub-TLV:

     Type: 1 Len: 6

     BL: 64 NL: 0 FL: 64 AL: 0 TL: 0 TO: 0

 AS-path         : 300

 Origin          : incomplete

 Attribute value : MED 0, localpref 100, pref-val 0

 State           : valid, internal, best

 Source type     : local

 IP precedence   : N/A

 QoS local ID    : N/A

 Traffic index   : N/A

 EVPN route type : IP prefix advertisement route

 ESI             : 0000.0000.0000.0000.0000

 Ethernet tag ID : 0

 IP prefix       : 20.20.20.20/32

 Gateway address : 0.0.0.0

 MPLS label      : 3

 Tunnel policy   : NULL

 Rely tunnel IDs : N/A

 Re-orignination : Disable

If the local PE has learned a BGP EVPN route to the remote destination address and its PrefixSID attribute is correct, execute the display bgp routing-table ipv4 vpn-instance command on the local PE to verify that the route has been added to the BGP VPN routing table. Verify that the route is both valid and the best. Only valid and optimal BGP routes can be learned into a VPN routing table.

<Sysname> display bgp routing-table ipv4 vpn-instance vpn1  20.20.20.20

 

 BGP local router ID: 1.1.1.1

 Local AS number: 100

 

 Paths:   1 available, 1 best

 

 BGP routing table information of 20.20.20.20/32:

 From            : 3::3 (3.3.3.3)

 Rely nexthop    : FE80::A2C3:E2FF:FEB5:306

 Original nexthop: 3::3

 Out interface   : GigabitEthernet2/0/2

 Route age       : 02h03m22s

 OutLabel        : 3

 Ext-Community   : <RT: 100:1>

 RxPathID        : 0x0

 TxPathID        : 0x0

 PrefixSID       : End.DT4 SID <300:1::A>

  SRv6 Service TLV (37 bytes):

   Type: SRV6 L3 Service TLV (5)

   Length: 34 bytes, Reserved: 0x0

   SRv6 Service Information Sub-TLV (33 bytes):

    Type: 1 Length: 30, Rsvdl: 0x0

    SID Flags: 0x0  Endpoint behavior: 0x13 Rsvd2: 0x0

    SRv6 SID Sub-Sub-TLV:

     Type: 1 Len: 6

     BL: 64 NL: 0 FL: 64 AL: 0 TL: 0 TO: 0

 AS-path         : 300

 Origin          : incomplete

 Attribute value : MED 0, localpref 100, pref-val 0

 State           : valid, internal, best, remoteredist

 Source type     : evpn remote-import

 IP precedence   : N/A

 QoS local ID    : N/A

 Traffic index   : N/A

 Tunnel policy   : a

 Rely tunnel IDs : 2150629377

If the local PE has failed to learn a valid and optimal BGP EVPN route, or if the PrefixSID attribute is missing from the route, proceed to check for the following issues:
Incorrect recursive routing configuration for EVPN L3VPN over SRv6.
SRv6 TE policy issues.

5.     In BGP-VPN IPv4 unicast address family view, execute the display this command to verify that the current configuration includes the segment-routing ipv6 traffic-engineering evpn or segment-routing ipv6 traffic-engineering best-effort evpn command. If neither of the commands is present, add the configuration. If either command is present, proceed to step 6.

<Sysname> system-view

[Sysname] bgp 100

[Sysname-bgp-default] ip vpn-instance vpn1

[Sysname-bgp-default-vpn1] address-family ipv4 unicast

[Sysname-bgp-default-ipv4-vpn1] display this

#

 segment-routing ipv6 locator aaa evpn

 segment-routing ipv6 traffic-engineering evpn

#

If the above recursive routing configuration is correct, see the SRv6 TE policy configuration in the segment routing configuration guide for the product to verify that the basic SRv6 configuration and the configuration for steering traffic to SRv6 TE policies are correct. If all settings are correct, proceed to the next step.

6.     On each PE device, verify that the SRv6 TE policy in the route to the remote destination IP address is valid. Execute the display segment-routing ipv6 te policy command on each PE device. Identify the SRv6 TE policy that has a forwarding index value that is the same as the rely tunnel IDs value in the route to the destination IP address displayed by executing the display bgp routing-table command. Examine the Status field for the SRv6 TE policy to verify that it is up. If the policy is up, proceed to the next step. If the policy is down, see the SRv6 TE policy down issue troubleshooting procedure to resolve the issue.

<Sysname> display segment-routing ipv6 te policy

 

Name/ID: p1/0

 Color: 10

 Endpoint: 1000::1

 Name from BGP:

 BSID:

  Mode: Dynamic              Type: Type 2              Request state: Succeeded

  Current BSID: 8000::1      Explicit BSID: -          Dynamic BSID: 8000::1

 Reference counts: 3

 Flags: A/BS/NC

 Status: Up

 AdminStatus: Up

 Up time: 2020-03-09 16:09:40

 Down time: 2020-03-09 16:09:13

 Hot backup: Enabled

 Statistics: Enabled

  Statistics by service class: Enabled

 Path verification: Enabled

 Drop-upon-invalid: Enabled

 BFD trigger path-down: Enabled

 SBFD: Enabled

  Remote: 1000

  SBFD template name: abc

  SBFD backup template name: -

  OAM SID: -

 BFD Echo: Disabled

 Forwarding index: 2150629377

…

Execute the ping srv6-te policy command to verify that the SRv6 TE policy has a valid path to reach the destination IP address. If BFD or SBFD is not configured to monitor the connectivity of the SRv6 TE policy, the up state of the policy only indicates that the first hop of the policy is reachable. To verify that all SIDs in the forwarding path are unreachable, you must perform this step.

<Sysname> ping srv6-te policy policy-name p1

Ping SRv6-TE policy (56 data bytes) , press CTRL+C to break

  Segment list ID: 1

    Preference=10, Path Type=Main, Protocol origin=Local, Originator=0,0.0.0.0, Discriminator=10, End.OP=none

56 bytes from 300:1::1, icmp_seq=0 ttl=63 time=2.000 ms

56 bytes from 300:1::1, icmp_seq=1 ttl=63 time=1.000 ms

56 bytes from 300:1::1, icmp_seq=2 ttl=63 time=0.000 ms

56 bytes from 300:1::1, icmp_seq=3 ttl=63 time=0.000 ms

56 bytes from 300:1::1, icmp_seq=4 ttl=63 time=0.000 ms

 

--- Ping6 SRv6-TE Policy statistics ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.000/0.600/2.000/0.800 ms

If the ping srv6-te policy command output shows that the SRv6 TE policy is not reachable, proceed to the next step.

7.     Execute the display segment-routing ipv6 te segment-list command to identify the SIDs in the SID list of the best candidate path in the SRv6 TE policy.

<Sysname> display segment-routing ipv6 te segment-list

 

Total Segment lists: 2

 

Name/ID: s1/1

 Origin: CLI

 Status: Up

 Nodes : 2

 Flags: None

 Local BSID: -

 Reverse BSID: -

 Reference counts: 0

 

  Index                 : 10                            SID: 200:1::1

  Status                : Up                     TopoStatus: Nonexistent

  Type                  : Type_2                      Flags: None

  Coc Type              : -            Common prefix length: 0

  Function length       : 0                     Args length: 0

  Endpoint Behavior     : -

 

  Index                 : 20                            SID: 300:1::1

  Status                : -                      TopoStatus: -

  Type                  : Type_2                      Flags: None

  Coc Type              : -            Common prefix length: 0

  Function length       : 0                     Args length: 0

  Endpoint Behavior     : -

Execute the display ipv6 routing-table ipv6-address command on each device in the forwarding path to verify that they have a valid route to each SRv6 SID, including the End.DT4 SID.

<Sysname> display ipv6 routing-table 300:1::A

 

Summary count : 2

 

Destination: 300:1::/64                                  Protocol  : IS_L1

NextHop    : FE80::A2C3:E2FF:FEB5:306                    Preference: 15

Interface  : GE2/0/2                                     Cost      : 20

Execute the ping ipv6 command on each device in the forwarding path to verify the connectivity to the SRv6 SID.

<Sysname> ping ipv6 300:1::A

Ping6(56 data bytes) 1001::1 --> 300:1::A, press CTRL+C to break

56 bytes from 300:1::A, icmp_seq=0 hlim=63 time=2.000 ms

56 bytes from 300:1::A, icmp_seq=1 hlim=63 time=1.000 ms

56 bytes from 300:1::A, icmp_seq=2 hlim=63 time=0.000 ms

56 bytes from 300:1::A, icmp_seq=3 hlim=63 time=1.000 ms

56 bytes from 300:1::A, icmp_seq=4 hlim=63 time=0.000 ms

 

--- Ping6 statistics for 300:1::A ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.000/0.800/2.000/0.748 ms

If the route to a SID is unreachable, check the SID list configuration for the SRv6 TE policy on the source node for SID list orchestration errors. If the SID list is correct, check the IGP for failure to advertise the locators that contain the SIDs to other devices. For more information about troubleshooting IGP, see the IP routing troubleshooting procedures.

8.     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