After VTEPs establish VXLAN tunnels through IP prefix routes, run the advertise l2vpn evpn command to enable a VTEP to advertise host routes from a VPN instance to its EVPN instance. The VTEP then sends host routes to the remote VTEP through the BGP EVPN peer relationship.

By default, the VPN instance local cross-route is not sent to the EVPN instance. To solve the problem of mutual access between different VRFs, you can enable the VPN instance to publish the local cross-connect function to the EVPN instance, and send the local cross-route collected by the VPN instance To the EVPN instance, and then send it to the remote device through the BGP EVPN peer relationship.

In BGP VPN multi-instance scenarios, routes cannot be locally leaked between BGP VPN instances. For example, if VRF1 is a common BGP VPN instance and VRF2 is a BGP VPN multi-instance, routes imported or remotely leaked to VRF1 cannot be locally leaked to VRF2.

After VTEPs establish VXLAN tunnels through IP prefix routes, run the advertise l2vpn evpn command to enable a VTEP to advertise host routes from a VPN instance to its EVPN instance. The VTEP then sends host routes to the remote VTEP through the BGP EVPN peer relationship.

By default, the device advertises all routes in the BGP VPN routing table to the BGP EVPN routing table including invalid routes. To prevent advertising the invalid routes, you need to specify valid-routes parameter. If you want only optimal BGP VPN routes to be advertised to BGP EVPN routing table, specify best-route parameter.

To implement even load balancing, run the advertise l2vpn evpn command with the import-route-multipath parameter specified. This configuration allows the VPN instance to advertise all the routes with the same destination address to the EVPN instance.

By default, the VPN instance local cross-route is not sent to the EVPN instance. To solve the problem of mutual access between different VPN instances, you can enable the VPN instance to publish the local cross-connect function to the EVPN instance, and send the local cross-route collected by the VPN instance To the EVPN instance, and then send it to the remote device through the BGP EVPN peer relationship.

In BGP VPN multi-instance scenarios, routes cannot be locally leaked between BGP VPN instances. For example, if VRF1 is a common BGP VPN instance and VRF2 is a BGP VPN multi-instance, routes imported or remotely leaked to VRF1 cannot be locally leaked to VRF2.

Usage Scenario

When a distributed VXLAN gateway is deployed, EVPN serves as the control plan to deliver routes. As more and more hosts access the gateway, routes stored on the control plane increase greatly, consuming a lot of memory resources. To better monitor the impact of an increase in route quantity on memory and prevent device restart caused by memory insufficiency, run the alarm-threshold route command to set a threshold for the number of routes. When the number of routes exceeds the threshold, a user log will be generated. When the number of routes equals the log recovery percentage, a recovery log will be generated.

When a device encapsulates the outer header of a VXLAN packet, the UDP source port number is the value calculated using the hash algorithm for the inner packet. The source port number can be used for load balancing on the network. If load balancing based on the UDP source port number is not ideal, you are advised to run this command to set the calculation mode of the UDP source port number to extension mode to improve the load balancing effect on the entire network.

Usage Scenario

Precautions

Multiple bridge domains can be created on a device. Bridge domains are irrelevant to VLAN tags carried in packets.

Usage Scenario

Before a created bridge domain can forward service packets, a sub-interface must be added to the bridge domain using the bridge-domain command in a specific EVC Layer 2 sub-interface view.

Prerequisites

Before running the bridge-domain command in the EVC Layer 2 sub-interface view, complete the following tasks:

1. Run the bridge-domain <bd-id> command in the system view to create a bridge domain.
2. Run the interface <interface-type> <interface-number.subnum> mode l2 command in the system view to create an EVC Layer 2 sub-interface.

You can run the bridge-domain bd-id command to configure multiple bridge domains to transmit various services. To describe each bridge domain, run the description command in a specific BD view. The description helps rapidly understand the bridge domain's function, which facilitates service management.

To use the DHCP Option 82 function in a BD for security reasons, run the description command to configure different descriptions for different VXLAN tunnels. The descriptions carried in the Option 82 fields of DHCP packets help you determine through which VXLAN tunnel each user goes online.

After BDs are configured on a device, to view BD information, run the display bridge-domain command. The command output contains bridge domain configurations. The command output helps verify the configuration and analyze faults.

Usage Scenario

To check traffic statistics of a BD when monitoring it, run the display bridge-domain statistics command. The command output helps locate faults.

Prerequisites

Usage Scenario

You can run the display fwm vxlan { l2subif | bridge-domain | tunnel | evpn } statistics [ all ] slot <slotid> command to check the delivery of each sub-service of the VXLAN module. This command displays statistics in a list. Each line indicates a piece of statistics.

Usage Scenario

If you want to check the VNI and source and destination IP address in an ingress replication list after a VXLAN is configured, run the display vxlan peer command. The command output helps you determine whether the VXLAN is correctly configured.

Precautions

Before running the display vxlan peer command, ensure that the specified VNI exists. Otherwise, the information obtained will be inapplicable.

Usage Scenario

After you run the vxlan statistics enable command to enable VXLAN packet statistics collection in the NVE interface view, you can run the display vxlan statistics command to view packet statistics by VNI and VXLAN tunnel.

Precautions

Only traffic statistics collection for VNIs in interworking mode is supported.

If a VXLAN tunnel goes Down or fails to be dynamically created, run the display vxlan troubleshooting command to check causes for fault locating.

This command can display causes for the recent five VXLAN tunnel Down events and dynamic VXLAN tunnel establishment failures at most.

After VXLAN tunnels are established, run the display vxlan tunnel command to check tunnel information. The command output helps verify configurations and locate faults.

Usage Scenario

After a VXLAN is configured, to check the VNI status and BD to which the VNI is mapped, run the display vxlan vni command. The command output helps you determine whether the VXLAN is correctly configured.

Precautions

• Before running the display vxlan vni command, ensure that the VNI exists on the device.
• If both ingress replication and other replication modes are configured for the same VNI, the BUM packet forwarding mode in the command output is displayed as other replication modes.

Usage Scenario

A Layer 2 Ethernet can transmit untagged, single-tagged, and double-tagged packets. To enable an EVC Layer 2 sub-interface to transmit different types of packets, run the flow-encapsulation command to configure an encapsulation type for the EVC Layer 2 sub-interface. The encapsulation default command configures a Layer 2 sub-interface to receive packets with any encapsulation type by default. When packets cannot meet the requirements of other sub-interfaces, the packets are sent to the Layer 2 sub-interface.

Precautions

• Each EVC Layer 2 sub-interface can be configured with only one encapsulation type. If traffic encapsulation has been configured on an EVC Layer 2 sub-interface and you want to change the encapsulation type, run the undo encapsulation command to delete the original encapsulation type.
• After the encapsulation default command is run, the VLAN configured for the main interface does not take effect. To make the VLAN configuration take effect on an EVC Layer 2 sub-interface, clear the encapsulation configuration on the EVC Layer 2 sub-interface.

Usage Scenario

A Layer 2 Ethernet can transmit untagged, single-tagged, and double-tagged packets. To enable an EVC Layer 2 sub-interface to transmit different types of packets, run the flow-encapsulation command to configure an encapsulation type for the EVC Layer 2 sub-interface. The encapsulation dot1q vid command configures a Layer 2 sub-interface to receive VLAN-encapsulated packets by default.

Precautions

Only a single encapsulation type can be specified on each EVC Layer 2 sub-interface. Before changing an encapsulation type, run the undo encapsulation command to delete the existing encapsulation type and run the encapsulation to specify an encapsulation type.

In a data transparent transmission scenario, dot1q or QinQ encapsulation is configured on an EVC Layer 2 sub-interface, and a range of VLAN IDs is specified for VLAN tags carried in packets. In this situation, traffic may be returned or dropped if the undo encapsulation dot1q vid low-pe-vid or undo encapsulation qinq vid pe-vid ce-vid low-ce-vid command is run to delete the existing encapsulation type with the smallest VLAN ID specified. To prevent problems, perform the following operations:

1.Run the shutdown command on the EVC Layer 2 sub-interface.

2.Run the undo encapsulation dot1q vid command to delete the minimum VLAN.

3.Run the undo shutdown command on the EVC Layer 2 sub-interface.

Usage Scenario

On a Layer 2 Ethernet network, packets may not carry VLAN Tags or carry one or two VLAN Tags. To enable different packets to be forwarded through different EVC Layer 2 sub-interfaces, run this command to configure different encapsulation modes for Layer 2 sub-interfaces of the EVC Layer 2 sub-interface. When two VLAN TAGs are carried, the packets can enter this interface if the preceding configurations are met.

Precautions

Only a single encapsulation type can be specified on each EVC Layer 2 sub-interface. Before changing an encapsulation type, run the undo encapsulation command to delete the existing encapsulation type and run the encapsulation to specify an encapsulation type.

In a data transparent transmission scenario, dot1q or QinQ encapsulation is configured on an EVC Layer 2 sub-interface, and a range of VLAN IDs is specified for VLAN tags carried in packets. In this situation, traffic may be returned or dropped if the undo encapsulation dot1q vid low-pe-vid or undo encapsulation qinq vid pe-vid ce-vid low-ce-vid command is run to delete the existing encapsulation type with the smallest VLAN ID specified. To prevent problems, perform the following operations:

1.Run the shutdown command on the EVC Layer 2 sub-interface.

2.Run the undo encapsulation qinq vid command to delete the minimum VLAN.

3.Run the undo shutdown command on the EVC Layer 2 sub-interface.

Usage Scenario

To add packets that do not carry VLAN TAG, run the encapsulation untag command on the sub-interface. Each Layer 2 sub-interface can be configured with only one encapsulation type. If flow encapsulation has been configured on a Layer 2 sub-interface, you must run the undo encapsulation command to delete the original encapsulation type before changing the encapsulation type.

Configuration Impact

After the encapsulation untag command is run, the main interface cannot forward packets without VLAN tags.

After the encapsulation untag configuration is deleted, if VLAN-related configurations exist on the main interface, you need to re-perform the VLAN-related configurations on the main interface to make the configurations take effect.

Usage Scenario

On a VXLAN network, users connected to the same BD can directly communicate with each other. If access-side user isolation is configured using the isolate enable command in the BD view, to allow users connected to the BD through a VLAN or Layer 2 sub-interface to communicate with other users in the BD, run this command in the VLAN or Layer 2 sub-interface view to set the access-side mode to hub.

On a VXLAN network, users in the same BD can directly communicate with each other. If unidirectional isolation from the access side to the tunnel side is configured in a BD using the isolate remote enable command in the BD view, to allow users connected to the BD through a VLAN or Layer 2 sub-interface to communicate with the tunnel side, run this command in the VLAN or Layer 2 sub-interface view to set the access-side mode to hub.

Prerequisites

If the VLAN access mode is set to hub, the VLAN has been bound to a BD using the l2 binding vlan command.

Usage Scenario

By default, after the route regeneration function is enabled, IRB/IRBv6 routes can be regenerated as ARP/ND routes only. To allow IRB/IRBv6 routes to be regenerated as IP prefix routes for Layer 3 forwarding, run the irb-reoriginate irb2ip enable command.

Usage Scenario

In a scenario where segment VXLAN is used for DCI, if DC edge devices (border leaf nodes) do not support BDs, the devices without BD configuration can re-generate IRB routes by default to establish an inter-DC VXLAN tunnel. If edge devices support BDs, to prevent repeat IRB route re-generation, run the evpn command in the system view to display the global EVPN view and then run the irb-reoriginated without-bridge-domain disable command to disable the default IRB route re-generation function when BDs are not configured.

Usage Scenario

In scenarios where segment VXLAN tunnels are used to implement DC interconnections, to prevent forwarding BUM traffic from causing a loop during Layer 2 interconnection, BGP EVPN peer-based SHG is introduced. If no BGP EVPN peer-based SHGs are specified (using the peer split-group command) on transit leaf nodes (edge devices interconnecting DCs), all BGP EVPN peers belong to the default system SHG. In this case, after a transit leaf node re-originates IRB routes received from an intra-DC device, the transit leaf node cannot advertise the re-originated IRB routes to the peer DC's transit leaf node because the transit leaf nodes both belong to the default system SHG. As a result, Layer 3 traffic forwarding is affected.

To prevent this problem, a device advertises re-originated IRB routes without being restricted by an SHG by default. If SHGs are specified for all BGP EVPN peers on transit leaf nodes, to disable the function to advertise re-originated IRB routes without being restricted by an SHG, run the irb-reoriginated without-split-group disable command.

In a VXLAN, users connected to the same BD can communicate. To isolate users connected to a BD, you can run the isolate enable command.

On a VXLAN network, users in the same BD can directly communicate with each other. To isolate unidirectional traffic from the access side to the tunnel side in a BD, run this command in the BD view.

Usage Scenario

On the VXLAN network, you need to configure VXLAN service access points on a VXLAN network edge node. After you run the l2 binding vlan command to bind a VLAN to a BD. The interfaces added to the VLAN become VXLAN service access points.

Prerequisites

The VLAN to be bound to the BD has been created.

The default VLAN, MAC-VLAN, IP-VLAN, protocol-VLAN, and management-VLAN cannot be bound to a BD.

Precautions

After a VLAN is bound to a BD, you cannot create a VLANIF interface for the VLAN either.

Enable Layer 2 proxy ARP is exclusive with Binding a VLAN to a BD. After a VLAN is configured as a VXLAN service access point, do not configure ARP Layer 2 proxy.

After a VLAN is bound to a BD, the BD becomes the broadcast domain. Therefore, other service configurations in the VLAN become invalid.

Usage Scenario

In a VXLAN Layer 3 gateway scenario, if Layer 2 unicast traffic forwarding is not involved, run the mac rib-only command to disable a device from delivering a MAC entry to its local MAC address table after it receives a VNI-based MAC route from the EVPN peer. This configuration saves forwarding entry resources.

When BGP EVPN is deployed between distributed VXLAN gateways, you need to configure the same VTEP MAC address for the two devices that provide dual-active VXLAN access. In this way, gateways on the VXLAN network can forward traffic properly.

After the source NVE on a VXLAN tunnel receives broadcast, unknown unicast, and multicast (BUM) packets, the local VTEP sends a copy of the BUM packets to every VTEP in the ingress replication list with the same VNI. To reduce the volume of broadcast traffic, run the mac-address static vni command to configure a static MAC entry for forwarding traffic. This configuration also prevents unauthorized data access, enhancing network security.

Usage Scenario

To set attributes for a specified peer VNI in the VNI peer view, run the peer command to create and display the VNI peer view.

Follow-up Procedure

Run the description command to configure a description for a peer VXLAN tunnel.

Usage Scenario

In a segment VXLAN scenario for DCI, to allow VMs in different DCs to communicate with each other, run the peer advertise route-reoriginated command on a DC edge device connecting to a carrier backbone network. The edge device then re-encapsulates the EVPN routes received from one DC and sends them to BGP EVPN peers in another DC.

After receiving an EVPN route from a DC, an edge leaf node re-encapsulates the EVPN route as follows: Modifies the next hop address of the EVPN route as its own VTEP address, replaces the source MAC address (functioning as the gateway MAC address) of the host route contained in the EVPN route with its own MAC address, and replaces the L3VNI in the EVPN route with the L3VNI in the edge leaf's L3VPN instance.

Prerequisites

The device has been enabled to add a regeneration flag to the routes received from BGP EVPN peers using the peer ipv4-address import reoriginate command.

Usage Scenario

In a segment VXLAN scenario for DCI, to allow VMs in different DCs to communicate with each other, run the peer advertise route-reoriginated command on a DC edge device connecting to a carrier backbone network. The edge device then re-encapsulates the EVPN routes received from one DC and sends them to BGP EVPN peers in another DC.

After receiving an EVPN route from a DC, an edge leaf node re-encapsulates the EVPN route as follows: Modifies the next hop address of the EVPN route as its own VTEP address, replaces the source MAC address (functioning as the gateway MAC address) of the host route contained in the EVPN route with its own MAC address, and replaces the L3VNI in the EVPN route with the L3VNI in the edge leaf's L3VPN instance.

Prerequisites

The device has been enabled to add a regeneration flag to the routes received from BGP EVPN peers using the peer group-name import reoriginate command.

DCI enables inter-DC VM communication. It uses technologies, such as VXLAN and BGP EVPN, to securely and reliably transmit packets from DCs over carrier networks.

In a segment VXLAN scenario for DCI, an edge node that connects to a carrier network does not re-encapsulate the routes received from BGP EVPN peers, causing the EVPN routes to be terminated on the edge node. As a result, the EVPN routes from one DC cannot be advertised to the BGP EVPN peers of another DC. To address this problem, run the peer import reoriginate command to enable the edge node to add a regeneration flag to the routes received from BGP EVPN peers. The edge node then re-encapsulates the EVPN routes received from one DC before sending them to another DC for inter-DC VM communication.

Usage Scenario

DCI enables inter-DC VM communication. It uses technologies, such as VXLAN and BGP EVPN, to securely and reliably transmit packets from DCs over carrier networks.

In a segment VXLAN scenario for DCI, an edge node that connects to a carrier network does not re-encapsulate the routes received from BGP EVPN peers, causing the EVPN routes to be terminated on the edge node. As a result, the EVPN routes from one DC cannot be advertised to the BGP EVPN peers of another DC. To address this problem, run the peer import reoriginate command to enable the edge node to add a regeneration flag to the routes received from BGP EVPN peers. The edge node then re-encapsulates the EVPN routes received from one DC before sending them to another DC for inter-DC VM communication.

In a VXLAN scenario with M-LAG configured, if one user-side link fails, service traffic is transmitted through the peer-link between the M-LAG devices. In this scenario, the pip-source peer bypass command must berun on M-LAG devices to create a static bypass VXLAN tunnel to divert traffic to the peer-link.

By default, when a packet enters a VXLAN tunnel, the 802.1p or DSCP priority of the original packet is mapped to the internal priority. When VXLAN encapsulation is performed, the outer DSCP priority is 0. When the mapping of PHBs to DSCP priorities is enabled for outgoing packets on an Ethernet interface, the internal priority is mapped to the outer DSCP priority. In this case, the outer DSCP priority of the encapsulated packet may be different from the DSCP priority of the original packet.

If the outer DSCP priority of the VXLAN packet needs to be the same as the DSCP priority of the original packet after VXLAN encapsulation is performed, you can disable the mapping of the inner priority to the outer DSCP priority of VXLAN packets. In this way, the DSCP priority of the original packet is copied as the outer DSCP priority of the VXLAN packet during VXLAN encapsulation, ensuring that the two DSCP priorities are the same.

In a scenario where a server is dual-homed to a VXLAN network through an M-LAG, a static bypass VXLAN tunnel must be configured between the M-LAG member devices to divert service traffic to the peer-link.

If the **consistency-check enable mode ** command is run on M-LAG member devices to enable M-LAG configuration consistency check, the VLANIF interfaces configurations on the peer-link interfaces of the master and backup M-LAG member devices are checked. If the configurations are inconsistent, an alarm is reported.

If you run this command to specify the IPV4 address of the VLANIF interface for a peer-link interface to be used only by the bypass VXLAN tunnel, the check criteria for VLANIF interface configuration consistency change accordingly. Specifically, if the IPV4 address and MAC address of the corresponding VLANIF interfaces on the M-LAG master and backup devices are the same, an alarm is reported.

Usage Scenario

Before you collect traffic statistics within a specified period for a BD, run the reset bridge-domain statistics command to clear existing statistics so that traffic statistics can be collected again, ensuring that the statistics are correct.

Prerequisites

A bridge domain has been created using the bridge-domain command.

Precautions

Traffic statistics of a BD are cleared and cannot be restored. Exercise caution when running the reset bridge-domain statistics command.

You can run the reset fwm vxlan statistics command to clear statistics about each subservice of the VXLAN module on <slotid>.

Usage Scenario

In cloud VPN scenarios, cloud GWs support VXLAN packet statistics collection. To clear VXLAN packet statistics, run the reset vxlan statistics command.

Precautions

After the reset vxlan statistics command is run, VXLAN packet statistics on a device are cleared and cannot be restored. Exercise caution when you run this command.

Usage Scenario

If a Layer 2 sub-interface with the encapsulation type being QinQ is configured as a VXLAN service access point on a VXLAN, to enable the sub-interface to remove double VLAN tags from received packets, run the rewrite pop double command.

If a Layer 2 sub-interface with the encapsulation type being Dot1q is configured as a VXLAN service access point on a VXLAN, to enable the sub-interface to remove single VLAN tags from received packets, run the rewrite pop single command.

Prerequisites

The following conditions have been met:

The Layer 2 sub-interface is not added to a bridge domain

Configuration Impact

Precautions

Only one traffic behavior can be configured on each EVC Layer 2 sub-interface. If a traffic behavior has been configured on an EVC Layer 2 sub-interface and you want to change it, perform the following operations on the EVC Layer 2 sub-interface:

• Run the undo rewrite command to delete the original traffic behavior.
• Run the undo bridge-domain command to exit the BD.

If a VLAN range is specified in this command, broadcast, unknown unicast, and multicast (BUM) traffic is replicated in all VLANs in that VLAN range. Excessive traffic replication will overburden the board, potentially interrupting services. To ensure that the board is not overburdened by many redundant VLANs, you are advised to plan VLANs appropriately during service deployment.

Usage Scenario

When a service access point is configured in the EVC model, if a Layer 2 sub-interface is selected and the encapsulation mode of the Layer 2 sub-interface is Dot1q, the sub-interface removes VLAN tags from received packets by default. To enable a Layer 2 sub-interface to transparently transmit single-tagged data packets, run the rewrite no-action command.

Prerequisites

• The dot1q Layer 2 sub-interface has not been added to a BD.
• A VLAN ID or VLAN ID range of packets that the dot1q Layer 2 sub-interface permits has been configured using the encapsulation dot1q vid command.

Precautions

This command applies only to dot1q Layer 2 sub-interfaces.

If a dot1q Layer 2 sub-interface is bound to a BD after the rewrite no-action command is run for the sub-interface, the BD does not support VBDIF interfaces and ARP broadcast packet suppression.

Usage Scenario

After creating an EVPN instance in a BD view, run the route-distinguisher command to configure an RD for the BD EVPN instance.

Different EVPN instances may have the same route prefix. To allow a peer PE to determine to which EVPN instance a received route belongs, run the route-distinguisher command to configure an RD for the EVPN instance on the local PE. The local PE then adds the RD to the route prefix to be sent to the peer PE, and the route prefix becomes a globally unique EVPN route.

Prerequisites

An EVPN instance has been created using the evpn command in the BD view.

Precautions

Running the undo route-distinguisher command in the BD-EVPN instance view causes EVPN-related configurations to be deleted.

Usage Scenario

The device supports 4096 BDs by default. If you want more than 4096 BDs, run the set bridge-domain resource super-mode command to set the super bridge-domain resource mode. After this command is configured, the device supports 16000 BDs.

Usage Scenario

A VTEP is a VXLAN tunnel endpoint that encapsulates or decapsulates VXLAN packets. It is represented by a network virtualization edge (NVE).

To configure an IP address for a source VTEP, run the source command. In VXLAN packets, the source IP address is the source VTEP's IP address, and the destination IP address is a remote VTEP's IP address. This pair of VTEP addresses corresponds to a VXLAN tunnel.

Precautions

You can specify a physical interface address or loopback interface address as the source VTEP IP address. Using the loopback interface address as the source VTEP IP address is recommended.

Generally, NVE interfaces on different devices need to be configured with different VTEP addresses. Otherwise, traffic may be forwarded incorrectly. In specific scenarios (for example, M-LAG dual-homing access scenario), if multiple devices are required to function as the same NVE, configure the same VTEP address for the NVE interfaces of these devices.

Usage Scenario

To check statistics about packets sent and received in a BD for fault locating, run this command in the BD view to enable traffic statistics collection. Otherwise, you cannot view traffic statistics in the BD.

Follow-up Procedure

After running the statistic enable command, run the display bridge-domain statistics command to view traffic statistics in the BD. The command output helps you diagnose faults.

Usage Scenario

By default, VXLAN packet statistics collection is disabled. To view VXLAN packet statistics of a specified VNI for fault locating, run this command in the VNI view to enable VXLAN packet statistics collection. Otherwise, you cannot view VXLAN packet statistics of the VNI.

Configuration Impact

If a large number of VXLAN packets exist, the device counts all these packets and subsequently stores large amounts of statistics, causing device operation performance to deteriorate. If VXLAN traffic statistics collection is not needed, run the undo statistic enable command to disable the function.

Follow-up Procedure

After running the statistics enable command, you can run the display vxlan statistics vni <vni-id> command to view VNI-specific statistics. The statistics can be used for fault diagnosis.

Usage Scenario

VNIs are similar to VLAN IDs. VXLAN uses VNIs to differentiate VXLAN segments and identify tenants. A VNI identifies only one tenant. Even if multiple terminal users belong to the same VNI, they are considered one tenant. Run this command to configure a VNI for an NVE interface.

After the ingress of a VXLAN tunnel receives broadcast, unknown unicast, and multicast (BUM) packets, it replicates these packets and sends a copy to each VTEP in the ingress replication list. The ingress replication list is a collection of remote VTEP IP addresses to which the ingress of a VXLAN tunnel should send replicated BUM packets.

If a source VTEP on a VXLAN connects to multiple remote VTEPs on the same VXLAN segment, run the vni head-end peer-list command to configure an ingress replication list that contains the IP addresses of those remote VTEPs. After the source NVE receives BUM packets, the local VTEP sends a copy of the BUM packets to every VTEP in the list.

Configuration Impact

Ingress replication allows BUM packets to be transmitted in broadcast mode, independent of multicast routing protocols.

Precautions

Even if a source VTEP connects only to one remote VTEP, you still need to run the vni head-end peer-list command to configure an ingress replication list with the remote VTEP's IP address specified.

If other configurations are performed for the same VNI on the current NVE interface, the command configuration will be overwritten.

Usage Scenario

VNIs, similar to VLAN IDs, are used to differentiate VXLAN segments and identify tenants. A VNI identifies only one tenant. If multiple terminal users share the same VNI, they are considered one tenant. To create a global VNI and enter the VNI view, run the vni command. Then, global VNI configurations can be performed in the view.

Follow-up Procedure

Run the peer ip-address command in the VNI view to create and display the VNI peer view.

Usage Scenario

After the ingress of a VXLAN tunnel receives broadcast, unknown unicast, and multicast (BUM) packets, it replicates these packets and sends a copy to each VTEP in the ingress replication list. The ingress replication list is a collection of remote VTEP IP addresses to which the ingress of a VXLAN tunnel should send replicated BUM packets.

If a source VTEP on a VXLAN connects to multiple remote VTEPs on the same VXLAN segment, run the vni head-end peer-list command to configure an ingress replication list that contains the IP addresses of those remote VTEPs. After the source NVE receives BUM packets, the local VTEP sends a copy of the BUM packets to every VTEP in the list. To use BGP to dynamically establish Layer 2 VXLAN tunnels, run the vni head-end peer-list protocol bgp command.

Configuration Impact

Ingress replication allows BUM packets to be transmitted in broadcast mode, independent of multicast routing protocols.

Precautions

If other configurations are performed for the same VNI on the current NVE interface, the command configuration will be overwritten.

Usage Scenario

Using the ingress replication mode to forward a large number of Broadcast&Unknown-unicast&Multicast (BUM) packets on a VXLAN network increases the network load and consumes lots of network bandwidth resources. To resolve the issue, run the vni mcast-group command on each VTEP to configure the multicast replication mode. In multicast replication mode, all VTEPs with the same VNI join the same multicast group. A multicast routing protocol, such as PIM, is used to create a multicast forwarding entry for the multicast group. When a VTEP receives a BUM packet from a local VM, it adds a multicast destination IP address to the BUM packet before sends the packet to the remote VTEPs based on the created multicast forwarding entry.

After you run the vni mcast-group command, mappings between VNIs and multicast groups are established. After receiving a VXLAN multicast packet, the VTEP checks the UNI in the packet. If no matching mapping between the VNI and multicast group is found, the VTEP will discard the packet.

Precautions

• This command is mutually exclusive with the vni flood-vtep command. In other words, multicast replication and centralized replication of BUM packets cannot be configured together.
• After configuring multicast replication, you can still run the vni head-end peer-list command to generate a remote VTEP address list for VXLAN tunnel establishment. However, multicast replication, instead of ingress replication, is used for BUM packets.
• One VNI can be configured with only one multicast replication address, and multiple VNIs can share one multicast replication address. That is, one VNI can correspond to only one multicast group, but one multicast group can correspond to multiple VNIs.
• This command cannot be used if BIDIR-PIM or PIM-DM has been enabled.
• If a VXLAN VNI has been configured in the BD view and IGMP snooping has been enabled in the BD view, multicast replication of BUM packets for the VNI cannot be enabled on an NVE interface.
• If a VXLAN VNI has been configured in the BD view and IGMP has been enabled (using the igmp enable command) in the VBDIF view of the BD, multicast replication of BUM packets for the VNI cannot be enabled on an NVE interface.
• The multicast replication address of a VNI specified on an NVE interface cannot be the same as the share-group address (multicast-domain share-group).
• A multicast group address in the switch-MDT switch-address pool (multicast-domain switch-group-pool) cannot be used as a multicast replication address for a specified VNI on an NVE's interface.

Usage Scenario

To enable distributed gateway on a VBDIF interface and allow the gateway to learn only user-side ARP, ND, or DHCP packets, run the

vxlan anycast-gateway enable command. After distributed gateway is enabled, the gateway:

• Processes only received user-side ARP, ND, or DHCP packets and generates host routes accordingly.
• Deletes network-side ARP, ND, or DHCP entries already learned and deletes the corresponding host routes.

Configuration Impact

After distributed gateway is enabled:

• VXLAN tunnel-side static ARP, ND, or DHCP entries cannot be configured on the gateway.
• If distributed gateways have the same IP address, they do not report ARP, ND, or DHCP conflicts.
• If ARP proxy is not enabled but the network-side devices and user-side hosts have the same IP address, the gateways do not report IP address conflict alarms.

By default, VXLAN traffic statistics collection is disabled. To enable the VXLAN traffic statistics collection function based on a VNI ID and VXLAN tunnel, run the vxlan statistics enable command. If the function of collecting VXLAN packet statistics is disabled, you cannot obtain the statistics.

By default, if the exact route to the source IP address of a VXLAN tunnel is reachable and the route to the network segment where the destination IP address resides is reachable, the VXLAN tunnel is considered Up. In actual networking, however, there may be multiple destination addresses on the same network segment. If one destination address is reachable, the network segment is reachable. If an IP address on the network segment is unreachable, the tunnel status is incorrectly reported and network problems cannot be detected in a timely manner. In this case, you can run the vxlan tunnel-status track exact-route command to enable subscription to the status of the exact route to the VXLAN tunnel destination. In this case, the VXLAN tunnel is Up only when the 32-bit or 128-bit host IP address of the destination VTEP is reachable. Otherwise, the VXLAN tunnel is Down.

You can run the display vxlan tunnel command to view the VXLAN tunnel status.

Usage Scenario

A virtual network (VN) on a VXLAN is a virtual broadcast domain. To allow a BD to function as a VXLAN network entity to transmit VXLAN traffic, run the vxlan vni command to map a VNI to a BD.

Precautions

• The VNI bound to a VPN instance cannot be bound to a BD.

Usage Scenario

A virtual network (VN) on a VXLAN is a virtual broadcast domain. To allow a BD to function as a VXLAN network entity to transmit VXLAN traffic, run the vxlan vni command to map a VNI to a BD in 1:1 mode.

To implement Layer 2 communication between hosts in different DCs in a scenario where segment VXLAN is used, run the vxlan vni split-group command on transit leaf nodes (edge devices interconnecting the DCs) to configure a mapping VNI to be associated with the BD. The mapping VNI is used for the VXLAN tunnel between the DCs. After this configuration is complete, a transit leaf node replaces the VNI in VXLAN packets received within the DC with the mapping VNI. This configuration decouples the VNI space for a DC's network from the VNI space for the network between DCs and isolates faults.

Additionally, to prevent loops when a transit leaf node forwards BUM traffic, the split horizon group to which the mapping VNI belongs must be specified, so that devices within a DC belong to the default SHG, and transit leaf nodes between DCs belong to the specified SHG. In this manner, when a transit leaf node receives BUM traffic, it does not forward traffic to a device belonging to the same SHG, therefore preventing loops.

Precautions

This command is mutually exclusive with the port vlan exclude command.

The VNI bound to a VPN instance cannot be bound to a BD.

For the same mapping VNI, the split-group parameter in the vxlan vni split-group command must reference the value configured using the vni head-end peer-list split-group or peer split-group command.

Usage Scenario

To isolate tenants at Layer 3, VPN is generally used. In a distributed VXLAN gateway scenario, to implement Layer 3 communication through a Layer 3 gateway, the Layer 3 gateway must be bound to a VPN instance.

The Layer 3 gateway assigns a Layer 2 VNI to each tenants and a Layer 3 VNI to each tenant identified by a VPN instance. To bind a VNI to a VPN instance, run the vxlan vni command. During Layer 3 communication through the Layer 3 gateway, the VNI ID bound to the VPN instance is transmitted to the remote Layer 3 gateway through the VXLAN tunnel. The remote Layer 3 gateway identifies VPNs based on tenants' VNI IDs to determine whether tenants belong to the same VPN for communication or isolation purposes.

Precautions

A VNI can be bound only to one VPN instance.

The VNI bound to a VPN instance cannot be bound to a BD.