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 S9300, S9300E, and S9300X Series Switches License Usage Guide.
Feature Support in V200R019C10
Only the following switch models support VXLAN:
S9303 (only the switches using MCUD main control units), S9306/S9312 (only the switches using SRUHX1, SRUHA1, SRUE, SRUH main control units), S9310, S9310X, S9300X-4, S9300X-8, S9300X-12
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 LE1D2S04SEC0, LE1D2X32SEC0, LE1D2H02QEC0, LE2D2X48SEC0, and 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 |
|---|---|---|
LE1D2S04SEC0, LE1D2X32SEC0, LE1D2H02QEC0, LE2D2X48SEC0, or X series card |
LE1D2S04SEC0, LE1D2X32SEC0, LE1D2H02QEC0, LE2D2X48SEC0, or 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, EC (except LE1D2S04SEC0, LE1D2X32SEC0, LE1D2H02QEC0, and LE2D2X48SEC0), or ED series card |
LE1D2S04SEC0, LE1D2X32SEC0, LE1D2H02QEC0, or X series card |
|
B, F, SC, or EE series card |
LE1D2S04SEC0, LE1D2X32SEC0, LE1D2H02QEC0, LE2D2X48SEC0, or X series card |
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.
In versions earlier than V200R019C00, the LE2D2X48SEC0 cards cannot forward data packets with the destination UDP port 4789 to the VXLAN tunnel.
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 LE2D2X48SEC0 card cannot reassemble or decapsulate fragmented VXLAN packets. When the LE2D2X48SEC0 card 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 LE2D2X48SEC0 card, 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 LE1D2S04SEC0, LE1D2X32SEC0, LE1D2H02QEC0, LE2D2X48SEC0, or 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 LE2D2X48SEC0 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.