Tag :: TOI

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. 

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.

This feature allows users to preserve IP TTL and MPLS EXP (also known as TC) value on MPLS routers, as well as add a user-specified TTL/EXP value when pushing new MPLS labels in pipe mode. With the added pipe mode support, packets can traverse the network such that only the LSP ingress and egress nodes are visible to the end users and the MPLS core network can be hidden from the end user.

EOS 4.15.0F adds support for MPLS encapsulation of IP packets in EOS. The functionality is exposed through two

Multiprotocol Label Switching (MPLS) is a networking process that replaces complete network addresses with short

MPLS-over-GRE encapsulation support in EOS 4.17.0 enables tunneling IPv4 packets over MPLS over GRE tunnels. This feature leverages next-hop group support in EOS. With this feature, IPv4 routes may be resolved via MPLS-over-GRE next-hop group to be able to push one MPLS label and then GRE encapsulate the resulting labelled IPv4 packet before sending out of the egress interface.

This feature allows the Arista switch to act as the tunnel head for an MPLS tunnel and is exposed through two

Multiprotocol Label Switching (MPLS) is a networking process that replaces complete network addresses with short path labels for directing data packets to network nodes. The labels identify LSPs (label switched paths) between distant nodes rather than endpoints. MPLS is scalable and protocol-independent. Data packets are assigned labels, which are used to determine packet forwarding destinations without examining the packet.

Generic UDP Encapsulation (GUE) is a general method for encapsulating packets of arbitrary IP protocols within a UDP tunnel. GUE provides an extensible header format with optional data. In this release, the ability to encapsulate MPLS over GUE packets of variant 1 header format has been added. 

MRU (maximum receive unit) enforcement provides the ability to drop frames that exceed a configured threshold on the ingress interface.

EOS supports Multicast Source Discovery Protocol (MSDP) peering over TCP. Previously, MSDP sessions in EOS did not provide a built-in TCP-level authentication mechanism, leaving the MSDP TCP connection susceptible to spoofed or injected TCP segments (e.g., forged FIN/ACK/RSTs).

The TCP MSS clamping feature involves clamping the maximum segment size (MSS) in the TCP header of TCP SYN packets if it exceeds the configured MSS ceiling limit for the interface. Clamping MSS value helps in avoiding IP fragmentation in tunnel scenarios by ensuring that MSS is small enough to accommodate the extra overhead of GRE and tunnel outer IP headers. One of the most common use cases for this feature is connectivity towards Cloud providers via GRE which require asymmetric routing (for example DDoS protection).

While migrating from PVST to MSTP, or vice verse, the network engineer may choose not to run MSTP throughout the

EOS supported two routing protocol implementations: multi-agent and ribd. The ribd routing protocol model is removed starting from the EOS-4.32.0F release. Multi-agent will be the only routing protocol model. Both models largely work the same way though there are subtle differences.

This feature provides the ability to interconnect EVPN VXLAN domains. Domains may or may not be within the same data center network, and the decision to stretch/interconnect a subnet between domains is configurable. The following diagram shows a multi-domain deployment using symmetric IRB. Note that two domains are shown for simplicity, but this solution supports any number of domains.

Multi hop BFD  allows for liveness detection between systems whose path may consist of multiple hops. With an

Until now, a multi-band client (for example, a phone with 2.4, 5, and 6 GHz radios) could connect to an Access Point (AP) using only one of the bands. Therefore, only one connection link is formed between the client and the AP. Multi-link Operation (MLO) is the capability of the client and the AP to connect to more than one band simultaneously, thereby establishing multiple links. Clients that can connect to the Access Point over multiple radio links simultaneously are called Multi-Link Devices (MLD).

Until now, a multi-band client (for example, a phone with 2.4, 5, and 6 GHz radios) could connect to an AP using only one of the bands. Therefore, only one connection link formed between the client and the AP. Multi-link Operation (MLO) is the capability of the client and the AP to connect to more than one band simultaneously establishing multiple links. The clients that are capable of communicating with each other over multiple radio links at the same time are called Multi-Link Devices (MLD).

This feature adds the support for OSPFv3 multi-site domains (currently this feature is added for IPv6 address family only) described in RFC6565 (OSPFv3 as a Provider to Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) ) and enables routes BGP VPN routes to retain their original route type if they are in the same OSPFv3 domain. Two sites are considered to be in the same OSPFv3 domain if it is intended that routes from one site to the other be considered intra-network routes.

The Multi-vCenter VM Support in Single Policy feature enhances scalability and configuration management by allowing the inclusion of Virtual Machines (VMs) from multiple vCenters within a single policy. Previously, integrating a large number of vCenters with a single DMF fabric required a separate policy for each instance. With this update, DMF supports configuring match rules to include multiple VMs across disparate vCenters, unifying policy application and reducing configuration overhead.

In conventional VXLAN deployments, each MLAG pair of switches are represented as a common logical VTEP. VXLAN traffic can be decapsulated on either switch. In some networks, there are hosts that are singly connected to one of the MLAG pair. VXLAN packets destined for the singly connected host could land on the other MLAG peer and subsequently be forwarded over the MLAG peer-link to reach the destination host. This path is undesirable since it would use up some bandwidth on the peer-link.

MultiAccess is a low latency FPGA-based Ethernet firewall or multiplexer/demultiplexer with configurable port ACLs (PACL). The MultiAccess FPGA application, which is delivered as an EOS extension in a “swix” file format includes various profiles which dictate and instantiate supported interface speeds and features. All MultiAccess profiles support MAC and IP PACLs, in either ingress, egress, or ingress and egress directions. Profiles may also perform packet multiplexing and demultiplexing, storm control, firewalling, and VLAN tunneling, all across various speeds and port layouts.

E-Tree is an L2 EVPN service (defined in RFC8317) in which each attachment circuit (AC) is assigned the role of Root or Leaf. Root ACs can communicate with leaf ACs and other root ACs. Leaf ACs can only communicate with root ACs. Leaf AC to leaf AC traffic is blocked. In this implementation, ACs are configured at the VLAN level, and the forwarding rules are enforced using a combination of local configuration of leaf VLANs (for local hosts), and asymmetric route targets (for remote hosts).

Evpn multicast IRB allows multicast traffic from the external Pim domain to flow through the EVPN network via PIM EVPN Gateway Designated Router (PEG-DR). The solution won’t work when the external Pim source or RP is not connected to PEG-DR in the external Pim domain. EVPN Multicast Transit solves the issue by allowing any PEG with transit configured (PEG-Transit) to act as PEG-DR.

The solution described in this document allows multicast traffic arriving on a VRF interface on a Provider’s Edge (PE) router to be delivered to Customer’s Edge (CE) routers with downstream receivers in the same VPN.

Multicast Only Fast Reroute (MoFRR) is a feature based on PIM sparse mode (PIM SM) protocol to minimize packet loss in a

The PIM routing protocol builds multicast routing state based on control packets and multicast data events. In our current implementation, we rely on theLinux kernel to notify the PIM agents regarding the multicast data events. Also, the Linux kernel forwards a multicast data packet before hardware gets programmed to do so. As an alternative to the Linux kernel, Multicast Forwarding based on BESS ( Berkeley Extensible Soft Switch ), MFA, can be used to generate multicast data events and forward multicast data packets.

LANZ adds support for monitoring congestion on backplane (or fabric) ports on DCS 7304, DCS 7308, DCS 7316, DCS

This feature adds all-active (A-A) multihoming support on the multi-domain EVPN VXLAN-MPLS gateway. It allows L2 and L3 ECMP to form between the multihoming gateways on the TOR devices inside the site and on the gateways in the remote sites. Therefore, traffic can be load-balanced to the multi-homing gateway and redundancy and fast convergence can be achieved.

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.

In Tap Aggregation mode, an interface can be configured as tap or tool port. Tap ports are used to 'tap' the traffic and

Multiple VLAN Registration Protocol (MVRP) is a Layer 2 protocol. The protocol allows access points to propagate the VLAN created on CV-CUE to the connected Switches. The real-time propagation of configuration allows you the flexibility of configuring your wired and wireless network in one interface and distributing it to other active interfaces. You do not have to worry about managing and maintaining the configurations in all interfaces.