Tag :: VXLAN

EOS currently supports VXLAN L2 integration with external controllers using the Arista OVSDB HW VTEP schema ([HW

On MLAG devices, flood traffic over the peer link follows split-horizon rules to avoid duplicate delivery of packets on MLAG interfaces. However, when one of the MLAG devices becomes inactive, peer-link flooding can cause double delivery or Layer 2 loops. To mitigate this risk, peer-link forwarding restriction was introduced. As of 4.34.0F, support was added for peer-link forwarding restriction when MLAG is enabled but not fully formed to the primary or secondary role. In this transitional state, only MLAG VLANs carrying MLAG control (PDU) traffic are allowed over the peer link. As of 4.34.2F, peer-link forwarding restriction is enabled by default. Users may still disable the feature manually as needed.

Selective ARP install is the selective programming of remote ARPs in hardware as received through EVPN Type 2 MAC-IP routes in an EVPN VXLAN/ MPLS Integrated Routing and Bridging (IRB) scenario. Instead of installing every MAC+IP binding received from EVPN into the hardware, the switch installs them only when there is routed traffic destined to the IP, thereby saving TCAM space on the switch. However, there is a tradeoff as there is an initial one-time latency to install the hardware TCAM entry on the first flow of routed traffic to the IP.

Enabling “Proxy ARP/ND for Single Aggregation (AG) VTEP Campus Deployments without EVPN” allows an aggregation VTEP to proxy reply to a VXLAN-encapsulated ARP request/NS when the ARP/NS target host is remote and the ARP/ND binding is already learned by the AG VTEP.

Private VLAN is a feature that segregates a regular VLAN broadcast domain while maintaining all ports in the same IP

This feature introduces support for ACL configuration on VXLAN decapsulated packets. The configured ACL rules will

VXLAN UDP-ESP support allows the customer to encrypt traffic between two VXLAN VTEPs. The frame format looks like: NOTE, Secure VXLAN is s~upported with both the sectag2 and UDP-ESP format in 4.27.1, where sectag2 is the default encapsulation format. However, the sectag2 format is deprecated and should not be used.

The sFlow VXLAN extension adds support for providing VXLAN-related information to sFlow packet samples, for VXLAN forwarded traffic. Specifically, for customer traffic ingressing on a CE-facing PE interface and forwarded into a VXLAN tunnel, the IP address of the source VTEP, the IP address of the destination VTEP and the VNI will be included in the sFlow datagram.

Prior to 4.25.2F, support for BGP PIC was restricted to locally identifiable failures such as link failures. If a

The VLAN interface (SVI) counter feature allows the device to count packets received and sent by the device on a per SVI basis. By default, in a VXLAN routing scenario, packets are not counted on the "overlay" SVI. The platform CLI command described below allows for counting on the overlay SVI. When enabled, this feature still permits counting on underlay network SVIs

Prior to this feature, we supported a maximum of two levels of Forward Equivalence Class (FEC) hierarchies for vxlan routing tunnels in hardware.

Overlay IPv6 routing over VXLAN tunnel using an anycast gateway (direct routing) has been previously supported using the “ipv6 virtual-router” configuration for both the data-plane and EVPN (or CVX) control-plane learning environments. 

Several customers have expressed interest in using IPv6 addresses for VxLAN underlay in their Data Centers (DC). Prior to 4.27.2F, only IPv4 addresses are supported for VxLAN underlay, i.e VTEPs are reachable via IPv4 addresses only. This feature enables a VTEP to send VxLAN Encapsulated packets using IPv6 underlay.

This feature expands Multi Domain EVPN VXLAN to support an Anycast Gateway model as the mechanism for gateway

This feature enables support for migrating from only using VCS as the control plane to only using EVPN as a control

Traceroute and tracert are widely available diagnostic command-line interface commands for displaying possible routes (paths) and transit delays of packets across an Internet Protocol (IP) network. This enhancement applies to IPv4 and IPv6 overlay. The VTEP overlay ICMPs for “time-to-live expired” (aka TTL-expired) are sourced with the VTEP IP which results in the traceroute output to display the VTEP IPs on the overlay packet’s path from source to destination.

This feature allows the VRRP MAC and IP to be advertised via EVPN MAC-IP routes when VRRP is configured on the VTEP.

This feature allows an operator to configure a centralized routing topology with an IPv6 VXLAN underlay. This is useful for customers who want to use an anycast (VARP) gateway for routing over an IPv6 control plane. VARP allows multiple switches to simultaneously route packets from a common IP address in an active-active router configuration. Each switch is configured with the virtual IP address and a common virtual MAC address.

VXLAN flood lists are typically configured via CLI or learned via control plane sources such as EVPN. The

This feature makes IGMP Snooping aware of VXLAN endpoints. Without this feature, multicast data traffic is flooded to all the VXLAN endpoints in case of a VXLAN VLAN. This increases the underlay network utilization. It is desirable to forward multicast traffic to only those VXLAN endpoints that are attached to receivers. To identify interested VXLAN endpoints, this feature snoops IGMP reports that are coming from the remote VXLAN endpoints. Note: EVPN control plane is not required when using this feature.

Current VXLAN decapsulation logic requires the following hits on affected switches listed in the following

This feature allows selecting Differentiated Services Code Point (DSCP) and Traffic Class (TC) values for packets at VTEPs along VXLAN encapsulation and decapsulation directions respectively. DSCP is a field in IP Header and TC is a tag associated with a packet within the switch, both influence the Quality of Service the packet receives. This feature can be enabled via configuration as explained later in this document.

In EOS 4.18.0F, VXLAN direct routing was introduced on the 7500R and 7280E/R series platforms. VXLAN routing

VXLAN ARP and IPv6 Neighbor Discovery (NDP) packet headend replication capability via VxlanSwFwd matches the COPP rate limit for these packets for the supported platforms regardless of the size of the VXLAN flood VTEP list. However, there still remains a case where the handling capacity is limited by CPU: the handling of ARP broadcast and NS multicast that result from Glean traffic (post routing).

Configuration of VXLAN overlay using EVPN allows for extension of Layer 2 (L2) or Layer 3 (L3) networks across

The VXLAN VNI counters feature allows the device to count VXLAN packets received and sent by the device on a per VNI basis. Specifically, it enables the device to count bytes and packets that are encapsulated and decapsulated as they are passing through.

The VXLAN VTEP and VNI counters feature allows the device to count VXLAN packets received and sent by the device on a per VTEP and per VNI basis. Specifically, it enables the device to count bytes and packets that are encapsulated and decapsulated as they are passing through.

The VxLAN VTEP counters feature allows the device to count VxLAN packets received and sent by the device on a per

The VxLAN VTEP counters feature allows the device to count VxLAN packets received and sent by the device on a per VTEP

The VxLAN VTEP counters feature allows the device to count VxLAN packets received and sent by the device on a per VTEP

The “vxlan bridging vtep to vtep” feature allows VXLAN encapsulated packets ingressed at an Arista switch from a