Licensing Requirements and Limitations for VXLAN
Involved Network Elements
Other network elements are not required.
Licensing Requirements
Static VXLAN deployment is a basic feature of a switch and is not under license control. The distributed VXLAN gateway and BGP EVPN functions are enhanced VXLAN functions under license control. To use an enhanced VXLAN function, apply for and purchase the required license from the device dealer.
The BGP EVPN-control license does not control route exchanges between devices. However, it regulates the status of the VXLAN tunnel established using BGP EVPN. If the license is not loaded or is invalid, no VXLAN tunnel can be established using BGP EVPN.
You can use the Agile Controller to deliver and activate the license for an enhanced VXLAN function. Alternatively, upload the license to the switch manually and activate the license. You can use either of the two methods. If both methods are used, no conflict occurs.
For details about how to apply for a license, see Obtaining Licenses in the S7700 and S9700 Series Switches License Usage Guide.
Feature Support in V200R019C10
Only the following switch models support VXLAN:
S7703/S7703 PoE (only the switches using MCUD main control units), S7706/S7706 PoE/S7712 (only the switches using SRUHX1, SRUHA1, SRUE, SRUH main control units)
Feature Limitations
Access-side interface: is used to connect a traditional network to a VXLAN network. The switch can provide VXLAN network access based on VLANs or traffic encapsulation types. For access based on a VLAN, the access-side interface is a member interface of the VLAN on a switch. For access based on a traffic encapsulation type, the access-side interface is the interface configured with the traffic encapsulation type.
Tunnel-side interface: forwards VXLAN packets to a VXLAN tunnel. After VXLAN encapsulation is performed on a switch, the interface performs route recursion based on the destination IP address (IP address of the remote end of the VXLAN tunnel) in the packets. For example, check the VXLAN tunnel and routing table information on the switch. The destination address of the VXLAN tunnel is 10.1.1.1, and the outbound interface of the route whose destination IP address is 10.1.1.1 is GE1/0/1. Therefore, the tunnel-side interface is GE1/0/1.
When a switch functions as a VXLAN tunnel endpoint (VTEP) on a VXLAN network, there must be a tunnel-side interface. Therefore, a card that supports tunnel-side interfaces must be installed on the switch and the tunnel-side interface must reside on the card. Only the interfaces on the X series cards can function as tunnel-side interfaces. If both access-side interfaces and tunnel-side interfaces exist, the cards providing access-side interfaces and those providing tunnel-side interfaces must meet the following mapping requirements:
Access-Side |
Tunnel-Side |
Remarks |
|---|---|---|
X series card |
X series card |
In this networking scenario, if an inter-card Eth-Trunk is deployed on the tunnel-side, all Eth-Trunk member interfaces must be able to work as tunnel interfaces. Otherwise, VXLAN packets cannot be forwarded on the Eth-Trunk functioning as a tunnel-side interface. |
EA, EA1, EC1, or EC series card |
X series card |
|
B, F, SC, EE series card of the S7700 |
X series card |
- When the encapsulation type of a VXLAN Layer 2 sub-interface is qinq or dot1q, the role of a switch in the VCMP domain cannot be client. Run the vcmp role { server | silent | transparent } command to set the switch to another role or run the vcmp disable command to disable VCMP on the interface.
The TPID value for the outer VLAN tag of QinQ packets configured on a VXLAN access-side interface does not take effect on packets entering the VXLAN network.
If the VXLAN access-side interface is a Layer 2 sub-interface and its encapsulation type is default, it can only communicate with a Layer 2 sub-interface of the encapsulation type default.
The switch does not support VXLAN over MPLS LSP tunnel. If VXLAN packets received from a peer are encapsulated by MPLS, the VTEP fails to decapsulate the packets.
The switch does not support VXLAN over GRE tunnel. If VXLAN packets received from a peer are encapsulated by GRE, the VTEP fails to decapsulate the packets.
If a VXLAN Network Identifier (VNI) has been created on the switch but not bound to VXLAN tunnels, the switch can still encapsulate and decapsulate VXLAN packets received from peers. However, the virtual tunnel end point (VTEP) access service is implemented in only one direction, but service transmission is abnormal.
The maximum transmission unit (MTU) determines the maximum number of bytes that can be sent by a device at a time. When a packet enters a VXLAN tunnel, 50 bytes are added to the packet. The switch importing traffic to a VXLAN tunnel cannot fragment packets. Instead, it normally forwards the packet even if the packet size exceeds the interface MTU.
- For the X series card as the tunnel side, the ECMP load balancing mode of VXLAN packets in the outbound direction on the tunnel side is configured using the ecmp load-balance or ecmp load-balance enhanced profile command. For the ES1D2X48SEC4 card as the tunnel side, the ECMP load balancing mode of VXLAN packets in the outbound direction on the tunnel side is controlled by the load balancing profile in Eth-Trunk enhanced mode. To configure the load balancing profile, run the load-balance-profile command.
If a card fails to deliver entries during the VXLAN tunnel establishment due to a hash conflict, the alarm ADPVXLAN_1.3.6.1.4.1.2011.5.25.227.2.1.42 hwVxlanTnlCfgFailed is triggered. To solve the problem, you are advised to adjust VNI IDs and re-configure VXLAN tunnels.
- In V200R011C10, when an inter-card Eth-Trunk interface is created, it is recommended that you do not bind different Layer 2 VXLAN sub-interfaces of the Eth-Trunk interface to the same BD. Otherwise, Layer 2 unicast services may fail to be forwarded between the Layer 2 sub-interfaces. In addition, you are not advised to configure the Eth-Trunk interface at the tunnel side and the access side simultaneously in this scenario. Otherwise, Layer 2 unicast services may fail to be forwarded between the tunnel side and the access side.
- In a distributed VXLAN gateway scenario, VXLAN Layer 2 wireless user roaming is supported if the user access VLANs and BD domains of the user access devices are consistent before and after user roaming.
- In a VXLAN scenario, the wireless service coverage area in a BD cannot contain more than 16 aggregation devices, because a mobility group supports a maximum of 16 ACs. If the coverage area contains more than 16 aggregation devices, roaming cannot be implemented and the burden on core devices increases.
- In VXLAN scenarios, do not advertise routes destined for the local VTEP address to the peer end of a VXLAN tunnel through a VBDIF interface during route configuration. Otherwise, the next hop of the remote VTEP address of the VXLAN tunnel may be the VBDIF interface on the ingress of the tunnel, causing a loop on the device.
