Troubleshooting VPN issues

Troubleshooting EVPN issues

Troubleshooting EVPN VPLS over SRv6 BE traffic forwarding failure

Symptom

As shown in Figure 1, EVPN VPLS uses SRv6 BE tunnels as public network tunnels, and CE 1 is multi-homed to PE 1 and PE 2. In this network, broadcast and unicast traffic forwarding fails between CE 1 and CE 2.

Figure 1 Network diagram

 

Common causes

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

·     The BGP EVPN peers are not established between the PEs.

·     The PEs have not received Type 3 routes (IMET routes).

·     The PEs have not received Type 2 routes (MAC/IP advertisement routes).

·     The PEs have not received Type 1 routes (Ethernet auto-discovery routes).

·     The Route Target attribute carried in the EVPN route does not match the locally configured Import Route Target attribute.

·     The route to the SRv6 SID does not exist on the PE.

Analysis

Figure 2 shows the troubleshooting flowchart.

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

 

Solution

To resolve the issue:

1.     Verify that the BGP EVPN peers are successfully established between the PEs.

a.     Execute the display bgp peer l2vpn evpn command to verify that all BGP EVPN peers between the PEs are in Established state. If they are in Established state, proceed to step 2. If not, resolve the BGP EVPN peer establishment issue. For more information, see the troubleshooting solution for the issue that the BGP session cannot enter the Established state.

b.     If the issue persists after the BGP peers are successfully established, proceed to step 2.

2.     Verify that the PEs have received Type 3 routes.

a.     Execute the display bgp l2vpn evpn route-type imet command to verify that the PE has received Type 3 routes from other PEs. If Type 3 routes are received, proceed to step 3. If not, troubleshoot the EVPN route synchronization issue. Possible reasons include the route reflector (RR) is not configured with the peer reflect-client command, the RR is not configured with the undo policy vpn-target command, and an incorrect routing policy is specified for the BGP peer. Please check for incorrect configuration and edit it.

b.     If the EVPN route synchronization issue persists after you perform the previous operation, proceed to step 8.

c.     If the issue persists after the EVPN route synchronization failure is resolved, proceed to the next step.

3.     Verify that the PEs have received Type 2 routes.

a.     Identify the traffic type. For broadcast traffic failure, proceed to step 4. For unicast traffic failure, proceed to the next step.

b.     Execute the display bgp l2vpn evpn route-type mac-ip command to verify that a Type 2 route matching the destination MAC address of unicast traffic exists, and the route comes from the correct BGP peer. If a Type 2 route exists and is correct, proceed to step 4. If not, resolve the Type 2 route synchronization issue as described in step 2.

c.     If the EVPN route synchronization issue persists after you perform the previous operation, proceed to step 8.

d.     If the issue persists after the EVPN route synchronization failure is resolved, proceed to the next step.

4.     Verify that the PEs have received Type 1 routes.

a.     Execute the display bgp l2vpn evpn route-type mac-ip command to view detailed Type 2 route information. If the ESI carried in the route is 0.0.0.0.0.0, proceed to step 5. If not, proceed to the next step.

b.     Execute the display bgp l2vpn evpn route-type auto-discovery command to verify that a Type 1 route matching the ESI in the Type 2 route exists. If such a route exists, proceed to step 5. If not, resolve the Type 1 route synchronization issue as described in step 2.

c.     If the EVPN route synchronization issue persists after you perform the previous operation, proceed to step 8.

d.     If the issue persists after the EVPN route synchronization failure is resolved, proceed to the next step.

5.     View the detailed route information to check for matching VPN Targets.

a.     View the detailed Type 1, 2, and 3 route information. Take Type 1 route as an example, execute the display bgp l2vpn evpn route-type auto-discovery { evpn-route route-length | evpn-prefix } command to obtain the RTs carried in the extended community attribute of the route.

b.     Enter VSI view and execute the display this command to obtain the vpn-target configured for the EVPN instance.

c.     If a minimum of one RT carried in the route is consistent with the Import RT of the EVPN instance, proceed to step 6. If not, proceed to the next step.

d.     Appropriately plan the VPN-target configuration for the EVPN instance, and modify the VPN-target configuration for the EVPN instance to ensure that the RT carried in the route matches the Import RT of the EVPN instance.

e.     If the issue persists, proceed to the next step.

6.     Verify that a route is available to the SRv6 SID.

a.     Execute the display l2vpn forwarding srv6 command to view the SRv6 SID allocated by the remote PE to the SRv6 PW, which is the value for the Out SID field.

b.     Execute the display ipv6 routing-table ipv6-address command (where ipv6-address is the Out SID field value) to verify that a route is available to the SRv6 SID allocated by the remote PE to the SRv6 PW. If such an SRv6 SID exists, proceed to step 7. If not, resolve the IGP route learning issue. For more information, see the IP routing troubleshooting guide.

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.

Troubleshooting EVPN VPLS over SRv6 TE policy traffic forwarding failure

Symptom

As shown in Figure 3, EVPN VPLS uses SRv6 TE policy tunnels as public network tunnels, and CE 1 is multi-homed to PE 1 and PE 2. In this network, broadcast and unicast traffic forwarding fails between CE 1 and CE 2.

Figure 3 Network diagram

 

Common causes

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

·     The BGP EVPN peers are not established between the PEs.

·     The PEs have not received Type 3 routes (IMET routes).

·     The PEs have not received Type 2 routes (MAC/IP advertisement routes).

·     The PEs have not received Type 1 routes (Ethernet auto-discovery routes).

·     The Route Target attribute carried in the EVPN route does not match the locally configured Import Route Target attribute.

·     The color value carried in the EVPN route does not match the color value configured for the SRv6 TE policy locally.

·     The color value of the local VSI instance does not match the color value of the local SRv6 TE policy.

·     The SRv6 TE policy to which EVPN VPLS is steered does not take effect.

Analysis

Figure 4 shows the troubleshooting flowchart.

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

 

Solution

To resolve the issue:

1.     Verify that the BGP EVPN peers are successfully established between the PEs.

a.     Execute the display bgp peer l2vpn evpn command to verify that all BGP EVPN peers between the PEs are in Established state. If they are in Established state, proceed to step 2. If not, resolve the BGP EVPN peer establishment issue. For more information, see the troubleshooting solution for the issue that the BGP session cannot enter the Established state.

b.     If the issue persists after the BGP peers are successfully established, proceed to step 2.

2.     Verify that the PEs have received Type 3 routes.

a.     Execute the display bgp l2vpn evpn route-type imet command to verify that the PE has received Type 3 routes from other PEs. If Type 3 routes are received, proceed to step 3. If not, troubleshoot the EVPN route synchronization issue. Possible reasons include the route reflector (RR) is not configured with the peer reflect-client command, the RR is not configured with the undo policy vpn-target command, and an incorrect routing policy is specified for the BGP peer. Please check for incorrect configuration and edit it.

b.     If the EVPN route synchronization issue persists after you perform the previous operation, proceed to step 8.

c.     If the issue persists after the EVPN route synchronization failure is resolved, proceed to the next step.

3.     Verify that the PEs have received Type 2 routes.

a.     Identify the traffic type. For broadcast traffic failure, proceed to step 4. For unicast traffic failure, proceed to the next step.

b.     Execute the display bgp l2vpn evpn route-type mac-ip command to verify that a Type 2 route matching the destination MAC address of unicast traffic exists, and the route comes from the correct BGP peer. If a Type 2 route exists and is correct, proceed to step 4. If not, resolve the Type 2 route synchronization issue as described in step 2.

c.     If the EVPN route synchronization issue persists after you perform the previous operation, proceed to step 8.

d.     If the issue persists after the EVPN route synchronization failure is resolved, proceed to the next step.

4.     Verify that the PEs have received Type 1 routes.

a.     Execute the display bgp l2vpn evpn route-type mac-ip command to view detailed Type 2 route information. If the ESI carried in the route is 0.0.0.0.0.0, proceed to step 5. If not, proceed to the next step.

b.     Execute the display bgp l2vpn evpn route-type auto-discovery command to verify that a Type 1 route matching the ESI in the Type 2 route exists. If such a route exists, proceed to step 5. If not, resolve the Type 1 route synchronization issue as described in step 2.

c.     If the EVPN route synchronization issue persists after you perform the previous operation, proceed to step 8.

d.     If the issue persists after the EVPN route synchronization failure is resolved, proceed to the next step.

5.     View the detailed route information to check for matching VPN Targets.

a.     View the detailed Type 1, 2, and 3 route information. Take Type 1 route as an example, execute the display bgp l2vpn evpn route-type auto-discovery { evpn-route route-length | evpn-prefix } command to obtain the RTs carried in the extended community attribute of the route.

b.     Enter VSI view and execute the display this command to obtain the vpn-target configured for the EVPN instance.

c.     If a minimum of one RT carried in the route is consistent with the Import RT of the EVPN instance, proceed to step 6. If not, proceed to the next step.

d.     Appropriately plan the VPN-target configuration for the EVPN instance, and modify the VPN-target configuration for the EVPN instance to ensure that the RT carried in the route matches the Import RT of the EVPN instance.

e.     If the issue persists, proceed to the next step.

6.     View detailed route information, and verify that the color in the route matches the color value configured locally for the SRv6 TE policy.

a.     View the detailed Type 1, 2, and 3 route information. Take Type 1 route as an example, execute the display bgp l2vpn evpn route-type auto-discovery { evpn-route route-length | evpn-prefix } command to view the color value in the route. If no color exists in the route, proceed to step 7. Otherwise, proceed to the next step.

b.     Execute the display segment-routing ipv6 te policy command to view the color value of the SRv6 TE policy to which EVPN VPLS is expected to be steered.

c.     If the color in the route is the same as the color value in the SRv6 TE policy, proceed to step 7. If they are different, you need to edit the color value of the SRv6 TE policy.

d.     If the issue persists, proceed to the next step.

7.     Verify that the color value of the local VSI instance does not match the color value of the local SRv6 TE policy.

a.     Execute the display l2vpn peer srv6 verbose command to view the default color value configured for the VSI instance, which is the value in the Color field.

b.     Execute the display segment-routing te policy command to view the color value of the SRv6 TE policy to which EVPN VPLS is expected to be steered.

c.     If the color value of the VSI instance is the same as the color value of the SRv6 TE policy, proceed to step 7. If they are different, edit the color value of the local VSI instance or the SRv6 TE policy.

d.     If the issue persists, proceed to the next step.

8.     Verify that the SRv6 TE policy is effective.

a.     Execute the display segment-routing ipv6 te policy command to check the value for the Status field. If the value is up, the SRv6 TE policy is effective, and proceed to step 8. If the value is down, the SRv6 TE policy is not effective. To more information to resolve this issue, see the SRv6 TE policy troubleshooting guide.

b.     If the issue persists, proceed to the next step.

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

¡     Results of each step.

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