Tag :: TOI

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

When a frame gets bridged from an edge port to a VXLAN core port, it is necessary to encode the QOS fields in the outer

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.

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.

The VXLAN Control Service (VCS) provides a mechanism by which hardware VTEPs share states between each other in order

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.

Hardware Head End Replication (HW HER) optimizes flooding of inter VTEP broadcast, unknown unicast and broadcast

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

VXLAN multicast decapsulation enables VTEPs that only support HER (Head End Replication) to terminate multicast

VXLAN is a Layer 2 technology that helps you to create a virtual Layer 2 network (overlay network) on top of a physical

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).

With the 12.0 release, CloudVision Cognitive Unified Edge (CV-CUE) supports a new tunnel type —  VXLAN over IPSec. You need to specify a tunnel type when you create an SSID.

VxLAN bridging enables stretching Layer 2 domains across a Layer 3 cloud. VxLAN routing provides the capability to

The 7500 and 7280 switch series platforms have previously supported VXLAN bridging, which enables stretching of

Vxlan routing in multichip systems uses the different modules to do different portions of the packet processing.

MLAG provides Layer2 active/active redundancy. VXLAN is supported over an MLAG setup by having the two switches

This document describes VXLAN routing with overlay VRFs on the DCS 7050X platforms. The feature allows users to

Up until now, the mirroring ACLs on the DCS 7150 series used to support only the security ACL rules. This meant that

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 document describes the support for policing on one or more VNIs configured on a Vxlan interface. This feature allows dedicated policing of flows on a VNI in both directions which corresponds to incoming traffic from a remote VTEP and outgoing traffic towards a remote VTEP. Policers in the hardware are created with policer profiles attached to VNIs. Policer profiles can be shared across multiple VNIs but policers are dedicated.

This document describes the support for VNI policing counters on VNIs where the VNI policing feature has been provisioned. Counters for this feature provide information on how many packets are being allowed or dropped for a VNI specific flow due to configured VNI policers. VNI policing counters are supported in both directions which correspond to incoming traffic from a remote VTEP and outgoing traffic towards a remote VTEP. Counters in each direction are configured separately. Both packet and bytes counts are supported.

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

Pathfinder deployments have restrictions on what devices can form a DPS tunnel between them. All the devices are categorized as either Site or Zone transit or Region transit.

WAN Routing system network comprises multiple routers interconnected using Dynamic Path Selection (DPS) tunnels. Prior to EOS-4.34.2F, the High Availability solution used a static hash to assign flow ownership to an HA peer. This peer was then responsible for Deep Packet Inspection (DPI) and subsequent Advanced Virtualization Technology (AVT) selection based on the DPI results.

With the 16.0 release, CV-CUE introduces Webhooks that let you send alert notifications in real time to third-party applications. By configuring a webhook, you can share content and notifications with external applications such as Microsoft Teams, ServiceNow, Slack, GSpace, etc.

EOS supports different scheduling policies which dictate the way packets at different transmit queues

WRAS is an EOS extension to automatically manage the layer 1 connectivity of the MetaWatch's WhiteRabbit interface.

With the 18.0 release, the Access Point (AP) and CV-CUE Server (previously called Wireless Manager Server or WM Server) connectivity for on-premises and cloud deployments have been updated with additional security and improved security posture of AP-Server communication.

With the 14.0 release, CV-CUE introduces the following enhancements to WIPS to ensure compliance with Wi-Fi 6 and 6E security requirements:

With the 13.0.1 release, you can monitor wired hosts that are physically connected to access points (APs) through Ethernet cables. Currently, the W-118 AP and W-318 AP through their additional LAN ports support connecting hosts directly to the AP.

With the 13.0 release, you can now view switch-related data, which is managed by CVaaS, from CV-CUE. With this capability, CV-CUE provides you full visibility of the edge network from a single pane. You can monitor the network and make informed decisions –  for example, when you want to troubleshoot any network issues and find out whether the root cause lies in the wired architecture or the wireless.

With the 12.0 release, you can view the details of access switches to which the access points (APs) are connected on the MONITOR > Switch page in CloudVision Cognitive Unified Edge (CV-CUE). The Switch page displays the list of switches to which the APs are connected and the connected Wi-Fi clients. 

WRED ( Weighted Random Early Detection ) is one of the congestion management techniques. It works at queue level to drop packets randomly after crossing the given queue threshold even before the queue is full. Without WRED, all newly arriving packets get tail dropped once the queue is full, which creates TCP global synchronization issues. WRED helps to avoid TCP global synchronization.

EOS Yum support is a feature that allows yum repositories to be configured and saved in the running config. This allows

This guide details how to use Zero Touch Provisioning (ZTP) on Arista switches.

The primary purpose of the ZTX Node in Monitor Mode is to provide visibility into app-to-app traffic in the network and to develop non-intrusive MSS policies that are aligned with applications requirements. Deploying group-based MSS policies is essential to secure Data Center and Campus environments, the ZTX Monitor Node provides the visibility needed to build such policies. The below diagram depicts how ZTX Node fits into a network to provide visibility.