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 S1720, S5700, and S6700 Series Switches License Usage Guide.

Feature Support in V200R019C10

Only the following switch models support VXLAN:

S5720-HI, S5730-HI, S6720-HI, S6730-H, S6730S-H, S6730-S, S6730S-S, S5732-H, S5731-S, S5731S-S, S5731S-H, S5731-H, S6720-EI, S6720S-EI

For details about software mappings, visit Hardware Query Tool and search for the desired product model.

Feature Limitations

On a VXLAN network, interfaces can be classified into access-side interfaces and tunnel-side interfaces based on their locations.

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 iteration 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 GE0/0/1. Therefore, the tunnel-side interface is GE0/0/1.

Be aware of the following when deploying the access-side of VXLAN on the switch:

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.
On the S6720-EI and S6720S-EI, VXLAN access-side interfaces cannot normally forward incoming multicast data.
On the S6720-EI and S6720S-EI running a version earlier than V200R019C00, data packets with the destination UDP port 4789 cannot enter the VXLAN tunnel.

Be aware of the following when deploying the tunnel-side of VXLAN on the switch:

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.
When a packet enters a VXLAN tunnel, 50 bytes are added to the packet. When the VXLAN packet is being forwarded in a tunnel, the forwarding device will fragment the packet if its size exceeds the MTU of the device. The S6720-EI and S6720S-EI cannot reassemble or decapsulate fragmented VXLAN packets. When the S6720-EI or S6720S-EI functions as a VXLAN tunnel-side device, you are advised to reduce the size of packets sent by the data sources or increase the MTU of forwarding devices to ensure that VXLAN packets are not fragmented during the forwarding process.
For the S6720-EI and S6720S-EI, if multiple VXLAN tunnels use the same tunnel-side interface and all tunnel-side interfaces are VLANIF interfaces, these VXLAN tunnels must forward packets through the same VLANIF interface. Otherwise, packet forwarding will be abnormal.
For the S6730-S, S6730S-S, S5732-H, S5731-S, S5731S-S, S5731S-H, S5720-HI, S5730-HI, S6720-HI, S6730-H, S6730S-H, or S5731-H, 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 S6720-EI or S6720S-EI, 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.

Be aware of the following when deploying VXLAN on the switch in other situations:

If a device 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-device Eth-Trunk interface is configured in a stack, 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 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.