Tag :: TOI

This document describes managing certificates and private keys in DMF.

A server cluster or a cluster is a group of Wireless Manager (WM) servers. A cluster comprises a parent WM server and one or more child WM servers.  A cluster is created to manage multiple servers using a single server. 

Beginning with DMF version 8.9, the action keyword is required to add or modify actions within a managed service. This keyword is a mandatory token across all managed service submodes, providing a consistent way to define service behaviors.

DMF 8.9 introduces a redesigned Managed Services dashboard, replacing the former interface.

The Management Connectivity Studio is used to configure out-of-band (OOB) management interfaces. You’ll create a profile of configured attributes for management interfaces, which can be assigned to multiple devices at once using tags.

Container-based deployments make creating cloud portable applications extremely easy. An application can be written on normal build infrastructure, that in turn can be run on a EOS switch or any Linux device that runs docker run time engine. So the same applications that are run on a server for microservices can be run on a switch with Arista EOS. Since Arista extensible operating system is simply linux (AlmaLinux 9.7 at this time – 2026) we are able to integrate a container runtime engine into the operating system.

In general, EOS always configures the PHYs to have the correct polarity to match that of the standard, such that if a standard compliant transceiver is plugged in and the peer is standard compliant everything will work.

MapReduce Tracer is an existing feature that monitors MapReduce nodes that are directly connected to Arista

The Mask Dual-tone Multi-Frequency (DTMF) in Real-time Transport Protocol (RTP) feature supports masking digits in voice data to hide sensitive information, such as credit card or social security numbers. Masking of sensitive data is a compliance issue that various agencies require to obfuscate information before storage.

In DMF 8.7.0,  the redesigned integration configuration now masks the password field and improves the configuration management. Use the Edit icon to Add, Modify, or Delete the Integration configuration.

Classification of MPLS packets based on traffic class bits in MPLS header for QoS Policy Maps. DCS

As of DMF-8.9.0, when several IP addresses are used in a single policy (whether via an address group or individually across match rules with otherwise identical conditions), the controller groups the addresses together and programs them as a field set on supported switches. This field set has a label that can be directly referenced by TCAM, which allows that TCAM entry to match against packets with any of the IP prefixes in that field set. This optimization dramatically reduces the TCAM consumption for policies that reference many addresses, allowing significantly more policies or addresses to be programmed without exceeding switch TCAM capacity limits. For example, on a switch incapable of performing this optimization, a policy matching traffic from a 100-entry source address group to a 100-entry destination address group would require 100x100=10,000 individual entries. With this optimization, the controller programs two field sets and a single match rule that references both field sets, reducing TCAM consumption from 10,000 entries to just 1 entry for that policy.

This feature allows classification of packets on QoS policy-maps based on the Class of Service (CoS), VLAN, Drop Eligible Indicator (DEI) in the 802.1q header of the packet. CoS (Class of Service) corresponds to the Priority code point (PCP) bits in the 802.1q header.

This feature allows setting the desired maximum VOQ latency. Drop probabilities are adjusted in hardware to meet this limit.

Currently, the 'maximum routes' knob allows one to set an upper bound on the number of routes that can be received from a

Previously, the maximum valid port channel ID was equal to the maximum number of port channels configurable on the

Measured boot is a tamper-detection mechanism that records a system's boot process. It calculates cryptographic hashes of system components and configurations, which are then securely stored in the Platform Configuration Registers (PCRs) of a Trusted Platform Module (TPM) chip. This process creates a secure "hash chain" of the boot sequence. After the system starts, the TPM Quote operation, along with the PCR extension records, can be used to verify the PCR values, confirming that the system components are unchanged and the software is trusted.

Measured boot is an anti-tamper mechanism. It calculates the cryptographic signatures for software system components and extends the signatures into the Trusted Platform Module (TPM) security chip. Upon startup, with the feature turned on, the Aboot bootloader and EOS calculate the hash of various system components and extend the hashes into the Platform Configuration Registers (PCRs), which is one of the resources of the Trusted Platform Module (TPM) security chip. The calculation and extension event is called the measured boot event, and the event is associated with a revision number to help the user identify changes to the event.

Media Access Control Security (MACSec) is an industry standard encryption mechanism to protect all traffic flowing

MetaMux is an FPGA-based feature available on Arista’s 7130 platforms. It performs ultra-low latency Ethernet packet multiplexing with or without packet contention queuing. The port to port latency is a function of the selected MetaMux profile, front panel ingress port, front panel egress port, FPGA connector ingress port, and platform being used.

MetaWatch is an FPGA-based feature available for Arista 7130 Series platforms. It provides precise timestamping of packets, aggregation and deep buffering for Ethernet links. Timestamp information and other metadata such as device and port identifiers are appended to the end of the packet as a trailer.

CloudVision provides support for microperimeter segmentation and enforcement as part of Arista’s Multi-Domain Segmentation Service (MSS) for Zero Trust Networking (ZTN).

ZTN works to reduce lateral movement into increasingly smaller areas where workloads are granularly identified and only approved connections are permitted.

Mirror on drop is a network visibility feature which allows monitoring of MPLS or IP flow drops occurring in the ingress pipeline. When such a drop is detected, it is sent to the control plane where it is processed and then sent to configured collectors. Additionally, CLI show commands provide general and detailed statistics and status.

This feature allows a user to configure a mirror session with subinterface sources from the CLI. This feature is only available with ingress mirroring (rx direction)

On supported devices, a port-channel can be configured as a mirroring destination for both ingress and egress source directions. Traffic mirrored to a port-channel is load-balanced based on the global port-channel load-balance configuration, which is the same for other port-channels.

An interface may be a source for both a mirroring session and sFlow at the same time. For more information about mirroring and ingress and egress sFlow look in the Resources section below.

Port mirroring allows you to duplicate ethernet packets or frames on a source interface to send to a remote host, like DANZ Monitoring Fabric (DMF). The mirrored packets or frames can be sent via a SPAN interface dedicated for communication with the host or over an L2 Generic Routing Encapsulation (L2GRE) tunnel.

Arista switches provide several mirroring features. Filtered mirroring to CPU adds a special destination to the mirroring features that allows the mirrored traffic to be sent to the switch supervisor. The traffic can then be monitored and analyzed locally without the need of a remote port analyzer. Use case of this feature is for debugging and troubleshooting purposes.

For traffic mirroring, Arista switches support several types of mirroring destinations. This document describes a new type of mirroring destination in which mirrored traffic is tunneled over VXLAN as the inner packet to a remote VTEP. This feature is useful for when the traffic analyzer is a VTEP reachable over a VXLAN tunnel.

Mirrored packets may be configured to be truncated per mirroring session.

DMF 8.7.0 introduces an updated dashboard for viewing sFlow drops. The DMF analytics Node (AN) displays reasons for dropped packets as a Mirror on Drop (MOD) drop Flow sFlow collector by analyzing overall drops and drops by flow.

In an MLAG setup, routing on a switch (MLAG peer) is possible using its own bridge/system MAC, VARP MAC or VRRP MAC. When a peer receives an IP packet with destination MAC set to one of the aforementioned MACs, the packet gets routed if the hardware has enough information to route the packet. Before introducing this feature, if the destination MAC is peer’s bridge MAC, the packet is L2 bridged on the peer-link and the routing takes place on the peer. This behavior to use the peer-link to bridge the L3 traffic to the peer is undesirable especially when the MLAG peers can route the packets themselves.

MLAG currently checks for basic MLAG configuration to be consistent (e.g. domain id) before formation with the peer.

When MLAG peer link goes down, the secondary peer assumes the primary peer is down/dead, and takes over the primary

In an MLAG setup, periodic TCP/UDP heartbeats are sent over peer link to ensure IP connectivity between peers. Prior

This feature allows users to configure L2 subinterfaces on MLAG interfaces. L2 subinterfaces are not supported on the MLAG peer-link.

The objective of Maintenance Mode on MLAG is to gracefully drain away the traffic (L2 and BGP) flowing through a switch

MLAG Smart System Upgrade (SSU) provides the ability to upgrade the EOS image of an MLAG switch with minimal traffic disruption.

MLAG will support the following features Bridging, Routing, STP, VARP

If an MLAG flaps on one peer, then we may have to remap the MAC addresses learned, such that the reachability is via the

On a MLAG chassis, MAC addresses learned on individual peers are synced and appropriate interfaces are mapped to these MAC addresses. In case of unexpected events like reloading of one of the peers in the MLAG chassis or flapping of one or more MLAG interfaces, some loss of traffic may be observed.

For packets sent and received on the front-panel interfaces, this feature allows creation of a profile to configure buffer reservations in the MMU (MMU = Memory Management Unit which manages how the on-chip packet buffers are organized).

For packets sent and received on the front-panel interfaces, this feature allows creation of a profile to configure buffer reservations in the MMU (MMU = Memory Management Unit which manages how the on-chip packet buffers are organized). The profile can contain configurations for ingress and egress. On the ingress, configuration is supported at both a port level as well as a priority-group level. 

Mobility Domain is a logical grouping of Access Points (AP) that allows APs to share clients' security credentials and operational keys with neighboring APs, enabling seamless, ultra-fast client roaming. In CV-CUE, you can create a mobility domain in the Inter AP Coordination section in the Network tab while configuring an SSID. CV-CUE assigns a mobility domain ID to each mobility domain name in its database.

The main objective of this feature is to prevent modular systems from being shut down due to insufficient power by powering off cards if there is not enough power in the system at card startup.

This feature allows the removal of a configurable number of leading bytes starting from the Ethernet layer of packets sent to a monitor session. A new per-monitor session CLI command is provided to configure this, up to a maximum of 90 bytes.

With the 17.0 release, you can view the Tunnel Status and Tunnel State of the standby VXLAN tunnel. Until now, you could only see the status of the tunnel being used. There was no way to know if your standby tunnel was reachable or not. With this release, you can view the Tunnel Status and the Tunnel State of your primary or secondary tunnel operating in the Standby Mode.

From the 4.29.2F release of EOS, proactive probing of servers is supported. Using this feature Arista switches can continuously probe configured servers to check their liveliness and use the information obtained from these probes while sending out requests to the servers.

The feature MP BGP Multicast provides a way to populate the MRIB (Multicast Routing Information Base). MRIB is an

The intended purpose of this feature is to introduce a server streaming RPC. When a client subscribes to this RPC, they will receive a message anytime there is an update to the hardware programming state of an MPLS route or the Nexthop-Group to which it points to. Note that messages will only be streamed in this RPC callback for versioned MPLS routes that point to versioned nexthop-groups. Messages will not be streamed via this RPC for MPLS routes and Nexthop-Groups that don’t meet this criteria.