Huawei S Series Campus Switches Troubleshooting Guide(V100 and V200)
Troubleshooting Guidelines for VXLAN
A Layer 2 Tunnel Cannot Be Established in a Distributed VXLAN Gateway Scenario
Context
In a distributed VXLAN gateway scenario, VXLAN tunnels are dynamically established using BGP EVPN. Whether a tunnel can be successfully established depends on whether the corresponding VPN or EVPN instances can receive routes. VTEPs establish a Layer 2 VXLAN tunnel based on the Inclusive Multicast (Type 3) routes received from each other. A route advertised by a VTEP carries export VPN targets (specified by export-extcommunity) of the local EVPN instance. If the export VPN targets match any of the import VPN targets (specified by import-extcommunity) of the EVPN instance on the remote VTEP, the route is accepted by the remote VTEP. A Layer 2 tunnel can be established between two VTEPs if they both accept the route advertised by each other. If the VPN targets do not match, the route is discarded, causing the failure to set up the Layer 2 tunnel.
Symptom
A Layer 2 VXLAN tunnel cannot be established between VTEP2 and VTEP3 on the network using distributed VXLAN gateways, as shown in Figure 20-128.
Troubleshooting Procedure
Figure 20-129 shows the troubleshooting procedure.
- Check whether the BGP EVPN peer relationship is successfully established, and troubleshoot the fault if the BGP EVPN peer relationship fails to be established.
Run the display bgp evpn peer command to check the BGP EVPN peer status.
BGP local router ID : 10.3.3.3 Local AS number : 100 Total number of peers : 2 Peers in established state : 2 Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv 10.1.1.1 4 100 4010 4016 0 0066h46m Established 1 10.2.2.2 4 100 4009 4010 0 0066h40m Established 4
If the BGP EVPN peer state is Established, the BGP EVPN peer relationship is established. In this case, go to 2. If the BGP EVPN peer relationship fails to be established, perform the following steps to troubleshoot the fault:
- Check whether the IP addresses used to establish a TCP session between the BGP peers on the VTEPs are reachable. Specifically, use the source address used by the local BGP peer to establish a TCP session to ping the source address used by the remote end to establish a TCP session.
# Check the source IP address used by BGP to establish a TCP session on the local device. Run the display current-configuration configuration bgp command in the BGP view to check the source interface used to set up a TCP session with its BGP peer, and then run the display interface command to check the IP address of the source interface.
<VTEP2> display current-configuration configuration bgp # bgp 100 router-id 10.2.2.2 peer 10.1.1.1 as-number 100 peer 10.1.1.1 connect-interface LoopBack1 peer 10.3.3.3 as-number 100 peer 10.3.3.3 connect-interface LoopBack1 # ipv4-family unicast undo synchronization peer 10.1.1.1 enable peer 10.3.3.3 enable # l2vpn-family evpn policy vpn-target peer 10.1.1.1 enable peer 10.1.1.1 advertise irb peer 10.3.3.3 enable peer 10.3.3.3 advertise irb # ipv4-family vpn-instance vpn1 import-route direct advertise l2vpn evpn # return <VTEP2>display interface loopback 1 LoopBack1 current state : UP Line protocol current state : UP (spoofing) Description: Route Port,The Maximum Transmit Unit is 1500 Internet Address is 10.2.2.2/32 Physical is Loopback Current system time: 2020-07-31 18:45:11+08:00 Last 300 seconds input rate 0 bits/sec, 0 packets/sec Last 300 seconds output rate 0 bits/sec, 0 packets/sec Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec Input: 0 packets,0 bytes 0 unicast,0 broadcast,0 multicast 0 errors,0 unknownprotocol Output:0 packets,0 bytes 0 unicast,0 broadcast,0 multicast 0 errors Input bandwidth utilization : 0% Output bandwidth utilization : 0%# Check the source IP address used by BGP to establish a TCP session on the remote device. Run the display current-configuration configuration bgp command in the BGP view to check the source interface used to set up a TCP session with its BGP peer, and then run the display interface command to check the IP address of the source interface.
<VTEP3> display current-configuration configuration bgp 100 # bgp 100 router-id 10.3.3.3 peer 10.1.1.1 as-number 100 peer 10.1.1.1 connect-interface LoopBack1 peer 10.2.2.2 as-number 100 peer 10.2.2.2 connect-interface LoopBack1 # ipv4-family unicast undo synchronization peer 10.1.1.1 enable peer 10.2.2.2 enable # l2vpn-family evpn policy vpn-target peer 10.1.1.1 enable peer 10.1.1.1 advertise irb peer 10.2.2.2 enable peer 10.2.2.2 advertise irb # ipv4-family vpn-instance vpn1 import-route direct advertise l2vpn evpn # return <VTEP3>display interface loopback 1 LoopBack1 current state : UP Line protocol current state : UP (spoofing) Description: Route Port,The Maximum Transmit Unit is 1500 Internet Address is 10.3.3.3/32 Physical is Loopback Current system time: 2020-07-31 10:28:55 Last 300 seconds input rate 0 bits/sec, 0 packets/sec Last 300 seconds output rate 0 bits/sec, 0 packets/sec Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec Input: 0 packets,0 bytes 0 unicast,0 broadcast,0 multicast 0 errors,0 unknownprotocol Output:0 packets,0 bytes 0 unicast,0 broadcast,0 multicast 0 errors Input bandwidth utilization : 0% Output bandwidth utilization : 0%# On the local device, ping the source IP address used by the remote device to establish a TCP session by specifying the local source IP address. This is to check whether the source IP address used by the BGP peer to establish the TCP session is reachable.
<VTEP2> ping -a 10.2.2.2 10.3.3.3 Pinging 10.3.3.3 with 32 bytes of data: Reply from 10.3.3.3: bytes=32 time=1ms TTL=126 Reply from 10.3.3.3: bytes=32 time=1ms TTL=126 Reply from 10.3.3.3: bytes=32 time=1ms TTL=126 Reply from 10.3.3.3: bytes=32 time=1ms TTL=126 Ping statistics for 10.3.3.3: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 1ms, Average = 1msIf the IP addresses for establishing the TCP session are reachable, go to 1.b. Otherwise, check whether the IGP routes between the devices are correctly configured.
- Check whether the status of the TCP session established between BGP peers is correct.
# Run the display tcp status command to check TCP session status.
<VTEP2> display tcp status TCPCB Tid/Soid Local Add:port Foreign Add:port VPNID State 4bb714f4 65 /2 0.0.0.0:80 0.0.0.0:0 -1 Listening 49f33cdc 262/1 0.0.0.0:179 10.1.1.1:0 0 Listening 49f33e50 262/4 0.0.0.0:179 10.3.3.3:0 0 Listening 4bb71380 65 /1 0.0.0.0:443 0.0.0.0:0 -1 Listening 49f3370c 262/8 10.2.2.2:53342 10.3.3.3:179 0 Established 49f339f4 262/7 10.2.2.2:55160 10.1.1.1:179 0 Established
If the TCP status is correct, the BGP EVPN peer relationship can be established successfully. If the TCP status is incorrect, check whether TCP packets are discarded on the devices and the link between them. You can locate the point of packet drops by checking the CPCAR value and collecting traffic statistics, and then rectify the fault accordingly.
- Check whether the IP addresses used to establish a TCP session between the BGP peers on the VTEPs are reachable. Specifically, use the source address used by the local BGP peer to establish a TCP session to ping the source address used by the remote end to establish a TCP session.
- Check whether the BGP EVPN inclusive routes are correctly learned.
# Run the display bgp evpn all routing-table inclusive-route inclusive-route command to check whether inclusive routes are correctly generated on the local device and whether the local device has learned inclusive routes from the remote device. In the command, the inclusive route specified by inclusive-route is in the format of M:L:X.X.X.X, where M is 0, L is the mask length of the source address of the device that generates the route, and X.X.X.X is the source address of the NVE interface on the device that generates the route. You can run the display current-configuration interface nve 1 command to view the source IP address and run the display ip interface brief command to view the mask.
# Check whether an inclusive route is correctly generated on the local device.
<VTEP2> display current-configuration interface nve 1 # interface Nve1 source 10.2.2.2 vni 10 head-end peer-list protocol bgp vni 20 head-end peer-list protocol bgp # return <VTEP2> display ip interface brief GigabitEthernet0/0/17 192.168.1.1/24 up up LoopBack1 10.2.2.2/32 up up(s) MEth0/0/1 unassigned up down NULL0 unassigned up up(s) Nve1 unassigned up up Vbdif10 192.168.10.1/24 up up Vbdif20 192.168.20.1/24 up up Vlanif1 unassigned up down <VTEP2> display bgp evpn all routing-table inclusive-route 0:32:10.2.2.2 BGP local router ID : 10.2.2.2 Local AS number : 100 Total routes of Route Distinguisher(1:10): 1 BGP routing table entry information of 0:32:10.2.2.2: Imported route. Label information (Received/Applied): 10/NULL From: 0.0.0.0 (0.0.0.0) Route Duration: 3d03h49m13s Direct Out-interface: Original nexthop: 10.2.2.2 Qos information : 0x0 Ext-Community:RT <1 : 100>, RT <10 : 1>, Tunnel Type <VxLan(8)> AS-path Nil, origin incomplete, pref-val 0, valid, local, best, select, pre 0 PMSI: Flags 0, Ingress Replication, Label 0:0:10(10), Tunnel Identifier: 10.2.2.2 Route Type: 3 (Inclusive Multicast Route) Ethernet Tag ID: 0, Originator IP: 10.2.2.2/32 Advertised to such 2 peers: 10.3.3.3 10.1.1.1Use the same method to check whether the inclusive route is learned on the remote device. If the route can be learned by the remote device, the tunnel can be established successfully. If the route cannot be correctly learned, go to 3.
# Use the same method to check whether the inclusive route generated by the remote device is correctly learned by the local device.
- Check whether the VPN targets of the EVPN instances on both devices match.
# Run the display bgp evpn all routing-table inclusive-route inclusive-route command to check the export VPN targets (specified by export-extcommunity) of the learned inclusive route.
<VTEP2> display bgp evpn all routing-table inclusive-route 0:32:10.3.3.3 BGP local router ID : 10.2.2.2 Local AS number : 100 Total routes of Route Distinguisher(2:10): 1 BGP routing table entry information of 0:32:10.3.3.3: Label information (Received/Applied): 10/NULL From: 10.3.3.3 (10.3.3.3) Route Duration: 3d03h19m30s Relay IP Nexthop: 192.168.1.2 Relay IP Out-Interface: GigabitEthernet0/0/17 Original nexthop: 10.3.3.3 Qos information : 0x0 Ext-Community:RT <1 : 100>, RT <10 : 1>, Tunnel Type <VxLan(8)> AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255, IGP cost 2 PMSI: Flags 0, Ingress Replication, Label 0:0:10(10), Tunnel Identifier: 10.3.3.3 Route Type: 3 (Inclusive Multicast Route) Ethernet Tag ID: 0, Originator IP: 10.3.3.3/32 Not advertised to any peer yet# Run the display current-configuration configuration evpn-instance evpn-instance-name command to check the import VPN targets (specified by import-extcommunity) of the local EVPN instance.
<VTEP2> display current-configuration configuration evpn-instance evpn10 # evpn vpn-instance evpn10 bd-mode route-distinguisher 1:10 vpn-target 1:100 10:1 export-extcommunity vpn-target 10:1 import-extcommunity # return
If the import VPN targets (specified by import-extcommunity) of the local EVPN instance match the export VPN targets (specified by export-extcommunity) carried in the received inclusive route, the route can be added to the routing table of the local EVPN instance and the tunnel can be established successfully. Otherwise, the import-extcommunity attribute of the local EVPN instance needs to be adjusted, so that the import VPN targets match the export VPN targets carried in the received inclusive route.
Layer 3 Tunnels Cannot Be Established in a Distributed VXLAN Gateway Scenario (IP Prefix Routes Are Advertised)
Context
In a distributed VXLAN gateway scenario, VXLAN tunnels are dynamically established using BGP EVPN. Whether a tunnel can be successfully established depends on whether the corresponding VPN or EVPN instances can receive routes. VTEPs establish Layer 3 VXLAN tunnels by sending IP prefix routes or integrated routing and bridging (IRB) routes. A route advertised by a VTEP carries the export VPN targets (specified by export-extcommunity evpn) of the local VPN instance. If the export VPN targets match any of the import VPN targets on the remote VTEP, the route is accepted by the remote VTEP. A Layer 3 tunnel can be established if both VTEPs accept the routes advertised by each other. If the VPN targets do not match, the route is discarded, causing the failure to establish the Layer 3 tunnel.
Symptom
In a distributed VXLAN gateway scenario, a Layer 3 VXLAN tunnel cannot be established. Figure 20-130 shows the network diagram.
Troubleshooting Procedure
Figure 20-131 shows the troubleshooting procedure.
- Check whether the BGP EVPN peer relationship is successfully established, and troubleshoot the fault if the BGP EVPN peer relationship fails to be established.
Run the display bgp evpn peer command to check the BGP EVPN peer status.
BGP local router ID : 10.3.3.3 Local AS number : 100 Total number of peers : 2 Peers in established state : 2 Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv 10.1.1.1 4 100 4010 4016 0 0066h46m Established 1 10.2.2.2 4 100 4009 4010 0 0066h40m Established 4
If the BGP EVPN peer state is Established, the BGP EVPN peer relationship is established. In this case, go to 2. If the BGP EVPN peer relationship fails to be established, perform the following steps to troubleshoot the fault:
- Check whether the IP addresses used to establish a TCP session between the BGP peers on the VTEPs are reachable. Specifically, use the source address used by the local BGP peer to establish a TCP session to ping the source address used by the remote end to establish a TCP session.
# Check the source IP address used by BGP to establish a TCP session on the local device. Run the display current-configuration configuration bgp command in the BGP view to check the source interface used to set up a TCP session with its BGP peer, and then run the display interface command to check the IP address of the source interface.
<VTEP2> display current-configuration configuration bgp # bgp 100 router-id 10.2.2.2 peer 10.1.1.1 as-number 100 peer 10.1.1.1 connect-interface LoopBack1 peer 10.3.3.3 as-number 100 peer 10.3.3.3 connect-interface LoopBack1 # ipv4-family unicast undo synchronization peer 10.1.1.1 enable peer 10.3.3.3 enable # l2vpn-family evpn policy vpn-target peer 10.1.1.1 enable peer 10.1.1.1 advertise irb peer 10.3.3.3 enable peer 10.3.3.3 advertise irb # ipv4-family vpn-instance vpn1 import-route direct advertise l2vpn evpn # return <VTEP2>display interface loopback 1 LoopBack1 current state : UP Line protocol current state : UP (spoofing) Description: Route Port,The Maximum Transmit Unit is 1500 Internet Address is 10.2.2.2/32 Physical is Loopback Current system time: 2020-07-31 18:45:11+08:00 Last 300 seconds input rate 0 bits/sec, 0 packets/sec Last 300 seconds output rate 0 bits/sec, 0 packets/sec Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec Input: 0 packets,0 bytes 0 unicast,0 broadcast,0 multicast 0 errors,0 unknownprotocol Output:0 packets,0 bytes 0 unicast,0 broadcast,0 multicast 0 errors Input bandwidth utilization : 0% Output bandwidth utilization : 0%# Check the source IP address used by BGP to establish a TCP session on the remote device. Run the display current-configuration configuration bgp command in the BGP view to check the source interface used to set up a TCP session with its BGP peer, and then run the display interface command to check the IP address of the source interface.
<VTEP3> display current-configuration configuration bgp 100 # bgp 100 router-id 10.3.3.3 peer 10.1.1.1 as-number 100 peer 10.1.1.1 connect-interface LoopBack1 peer 10.2.2.2 as-number 100 peer 10.2.2.2 connect-interface LoopBack1 # ipv4-family unicast undo synchronization peer 10.1.1.1 enable peer 10.2.2.2 enable # l2vpn-family evpn policy vpn-target peer 10.1.1.1 enable peer 10.1.1.1 advertise irb peer 10.2.2.2 enable peer 10.2.2.2 advertise irb # ipv4-family vpn-instance vpn1 import-route direct advertise l2vpn evpn # return <VTEP3>display interface loopback 1 LoopBack1 current state : UP Line protocol current state : UP (spoofing) Description: Route Port,The Maximum Transmit Unit is 1500 Internet Address is 10.3.3.3/32 Physical is Loopback Current system time: 2020-07-31 10:28:55 Last 300 seconds input rate 0 bits/sec, 0 packets/sec Last 300 seconds output rate 0 bits/sec, 0 packets/sec Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec Input: 0 packets,0 bytes 0 unicast,0 broadcast,0 multicast 0 errors,0 unknownprotocol Output:0 packets,0 bytes 0 unicast,0 broadcast,0 multicast 0 errors Input bandwidth utilization : 0% Output bandwidth utilization : 0%# On the local device, ping the source IP address used by the remote device to establish a TCP session by specifying the local source IP address. This is to check whether the source IP address used by the BGP peer to establish the TCP session is reachable.
<VTEP2> ping -a 10.2.2.2 10.3.3.3 Pinging 10.3.3.3 with 32 bytes of data: Reply from 10.3.3.3: bytes=32 time=1ms TTL=126 Reply from 10.3.3.3: bytes=32 time=1ms TTL=126 Reply from 10.3.3.3: bytes=32 time=1ms TTL=126 Reply from 10.3.3.3: bytes=32 time=1ms TTL=126 Ping statistics for 10.3.3.3: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 1ms, Average = 1msIf the IP addresses for establishing the TCP session are reachable, go to 1.b. Otherwise, check whether the IGP routes between the devices are correctly configured.
- Check whether the status of the TCP session established between BGP peers is correct.
# Run the display tcp status command to check TCP session status.
<VTEP2> display tcp status TCPCB Tid/Soid Local Add:port Foreign Add:port VPNID State 4bb714f4 65 /2 0.0.0.0:80 0.0.0.0:0 -1 Listening 49f33cdc 262/1 0.0.0.0:179 10.1.1.1:0 0 Listening 49f33e50 262/4 0.0.0.0:179 10.3.3.3:0 0 Listening 4bb71380 65 /1 0.0.0.0:443 0.0.0.0:0 -1 Listening 49f3370c 262/8 10.2.2.2:53342 10.3.3.3:179 0 Established 49f339f4 262/7 10.2.2.2:55160 10.1.1.1:179 0 Established
If the TCP status is correct, the BGP EVPN peer relationship can be established successfully. If the TCP status is incorrect, check whether TCP packets are discarded on the devices and the link between them. You can locate the point of packet drops by checking the CPCAR value and collecting traffic statistics, and then rectify the fault accordingly.
- Check whether the IP addresses used to establish a TCP session between the BGP peers on the VTEPs are reachable. Specifically, use the source address used by the local BGP peer to establish a TCP session to ping the source address used by the remote end to establish a TCP session.
- Check whether BGP EVPN IP prefix routes are correctly learned.
# Run the display bgp evpn all routing-table prefix-route prefix-route command to check whether the local device has generated an IP prefix route. In the command, the IP prefix route specified by prefix-route is in the format of L:X.X.X.X:M, where L is 0, M is the mask length of the destination IP address of the route, and X.X.X.X is the destination IP address of the route. Run the display interface vbdif command to check the gateway address and mask. (The local device generates an IP prefix route based on the VXLAN gateway address and sends the route to the remote device.)
<VTEP2> display current-configuration interface vbdif 10 # interface Vbdif10 mac-address 0000-5e00-0101 ip binding vpn-instance vpn1 arp collect host enable arp distribute-gateway enable ip address 192.168.10.1 255.255.255.0 # return <VTEP2> display bgp evpnallrouting-table prefix-route 0:24:192.168.10.1 BGP local router ID : 10.2.2.2 Local AS number : 100 Total routes of Route Distinguisher(3:100): 1 BGP routing table entry information of 0:192.168.20.0:24: Label information (Received/Applied): 100/NULL From: 10.3.3.3 (10.3.3.3) Route Duration: 3d04h07m33s Relay IP Nexthop: 192.168.1.2 Relay IP Out-Interface: GigabitEthernet0/0/17 Original nexthop: 10.3.3.3 Qos information : 0x0 Ext-Community:RT <1 : 100>, Tunnel Type <VxLan(8)>, Router's MAC <2cab-0098-15b0> AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, pre 255, IGP cost 2 Route Type: 5 (Ip Prefix Route) Ethernet Tag ID:0, IP Prefix/Len: 192.168.20.0/24, ESI: 0000.0000.0000.0000.0000, GW IP Address: 0.0.0.0 Not advertised to any peer yet VPN-Instance vpn1, Router ID 10.2.2.2: Total Number of Routes: 1 BGP routing table entry information of 192.168.20.0/24: Label information (Received/Applied): 100/NULL From: 10.3.3.3 (10.3.3.3) Route Duration: 3d04h07m33s Relay Tunnel Out-Interface: VXLAN Relay token: 0x1 Original nexthop: 10.3.3.3 Qos information : 0x0 Ext-Community:RT <1 : 100>, Tunnel Type <VxLan(8)>, Router's MAC <2cab-0098-15b0> AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255 Not advertised to any peer yetUse the same method to check whether the IP prefix route is learned on the remote device. If the route can be learned by the remote device, the tunnel can be established successfully. If the route cannot be correctly learned, go to 3.
# Use the same method to check whether the IP prefix route generated by the remote device is correctly learned by the local device.
- Check whether the VPN targets of the EVPN instances on both devices match.
# Run the display bgp evpn all routing-table prefix-route prefix-route command to check the export VPN targets (specified by export-extcommunity) of the learned IP prefix route.
<VTEP2> display bgp evpn all routing-table prefix-route 0:24:192.168.20.0 BGP local router ID : 10.2.2.2 Local AS number : 100 Total routes of Route Distinguisher(3:100): 1 BGP routing table entry information of 0:192.168.20.0:24: Label information (Received/Applied): 100/NULL From: 10.3.3.3 (10.3.3.3) Route Duration: 3d04h07m33s Relay IP Nexthop: 192.168.1.2 Relay IP Out-Interface: GigabitEthernet0/0/17 Original nexthop: 10.3.3.3 Qos information : 0x0 Ext-Community:RT <1 : 100>, Tunnel Type <VxLan(8)>, Router's MAC <2cab-0098-15b0> AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, pre 255, IGP cost 2 Route Type: 5 (Ip Prefix Route) Ethernet Tag ID:0, IP Prefix/Len: 192.168.20.0/24, ESI: 0000.0000.0000.0000.0000, GW IP Address: 0.0.0.0 Not advertised to any peer yet VPN-Instance vpn1, Router ID 10.2.2.2: Total Number of Routes: 1 BGP routing table entry information of 192.168.20.0/24: Label information (Received/Applied): 100/NULL From: 10.3.3.3 (10.3.3.3) Route Duration: 3d04h07m33s Relay Tunnel Out-Interface: VXLAN Relay token: 0x1 Original nexthop: 10.3.3.3 Qos information : 0x0 Ext-Community:RT <1 : 100>, Tunnel Type <VxLan(8)>, Router's MAC <2cab-0098-15b0> AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255 Not advertised to any peer yet# Run the display current-configuration configuration vpn-instance vpn-instance-name command to check the import VPN targets (specified by import-extcommunity evpn) of the local VPN instance.
<VTEP2> display current-configuration configuration vpn-instance vpn1 # ip vpn-instance vpn1 ipv4-family route-distinguisher 2:100 vpn-target 1:100 export-extcommunity evpn vpn-target 1:100 import-extcommunity evpn vxlan vni 100 # return
If the import VPN targets (specified by import-extcommunity evpn) of the local VPN instance match the export VPN targets (specified by export-extcommunity evpn) carried in the received IP prefix route, the route can be added to the routing table of the local VPN instance and the tunnel can be established successfully. Otherwise, the import-extcommunity evpn attribute of the local EVPN instance needs to be adjusted, so that the import VPN targets match the export VPN targets carried in the received IP prefix route.