Tag :: TOI

With the 12.0 release, you can configure DHCP fingerprinting to allow or deny clients getting connected to an SSID. Using DHCP fingerprinting, you can identify the operating system (OS) of the client based on the DHCP exchange packets between the client and the DHCP server. 

Dynamic Host Configuration Protocol (DHCP) is a feature which can be used to provide an IP address to the interfaces on

Arista Wi-Fi Access Points (AP) use DHCP Options 16 and 17 for IPv6 to discover and connect to a specific CV-CUE server on-premises or in the cloud. For a dual-stack DHCP server, IPv4 is preferred over IPv6.

The DHCP relay feature, forwards DHCP packets between a client and the DHCP server when the server is not in the same broadcast domain as the client. The DHCP relay should be configured on the gateway interface (SVI/ L3 interface) for the clients.

The EOS DHCP relay agent now supports forwarding of DHCP requests to DHCP servers located in a different VRF to the DHCP

Support for DHCPv4 (RFC 2131) and DHCPv6 Server (RFC 8415) was added to EOS-4.22.1 and EOS-4.23.0 respectively. EOS DHCP server leverages ISC Kea as backend. The router with DHCP Server enabled acts as a server that allocates and delivers network addresses with desired configuration parameters to its hosts.

EOS supports the DHCP Relay feature, which relays DHCP Requests/Responses between DHCP clients and DHCP servers in different subnets. However, the DHCP server does not have visibility of where the request originated from and can only make IP address allocation decisions based on the client MAC address alone (client MAC address is included in the DHCP packet as part of the payload). To remedy that, DHCP Option-82 was formalized to allow relay agents to include Remote ID and Circuit ID so that DHCP servers can apply a more intelligent allocation policy.

DHCPv6 Prefix Delegation support enables a DHCP relay agent to program routes for addresses assigned by a DHCP server. The assigned prefixes could either be DHCPv6 IA_PD prefix delegation addresses, or DHCPv6 IA_NA global /128 addresses.

Directed broadcast is method of transfer to send a packet to recipients in a target subnet. This is done by sending a

DirectFlow runs alongside the existing layer 2/3 forwarding plane, enabling a network architecture that

The following new enhancements to DirectFlow and/or OpenFlow are added in EOS 4.15.0F:. DirectFlow

With the 19.0 release, network administrators can turn off 802.11b rates on SSIDs operating in the 2.4 GHz band. Turning off these legacy rates enhances overall network performance and prevents the association from outdated 802.11b clients.

IEEE802.1D 2004, Section 7.12.6 specifies destination MAC addresses that are normally trapped (not forwarded) by

A policy-map defines a set of rules that prioritize network traffic, ensuring critical data isn't delayed by less important packets. Each policy-map aggregates multiple class-maps, which are associated with specific match criteria such as VLAN, DSCP, or IP ACLs. Actions — including DSCP marking, traffic-class assignment, and policing — can be applied to each policy-map and class-map pair. This allows specific QoS actions to be executed on every incoming packet based on defined parameters.

The Switch detail page in the DMF GUI has a new Inventory tab displaying information about optics, cables, and transceivers.

This document describes the updates to the DANZ Monitoring Fabric (DMF) 8.10 release verified scale and performance numbers.

This document describes the updates to the DANZ Monitoring Fabric (DMF) 8.7 release verified scale and performance numbers.

The hardware support update details newly supported hardware and other changes in the DANZ Monitoring Fabric (DMF) release 8.7.0.

This document describes the updates to the DANZ Monitoring Fabric (DMF) 8.8 release verified scale and performance numbers. Verified scale values for “DCA-DM-RN760” and “DCA-DM-RN760L” Recorder Nodes.

The hardware support update details newly supported hardware and other changes in the DANZ Monitoring Fabric (DMF) release 8.8.0.

Egress Filtering is an option to send different traffic to each tool attached to the policy's delivery setting. It provides additional filtering at the delivery ports based on the egress filtering rules specified at the interface.

The DMF 8.10.0 release introduces a completely redesigned Fabric page. This modernization effort improves visual clarity for data displays and the topology graph, providing an interactive fabric representation for a better understanding of device connectivity.

Match rules define the specific traffic forwarded through the fabric. These criteria are applied directly within a policy, as part of a rule within a referenced rule group, or as a post-service match in a managed service. Each rule specifies parameters such as IP addresses, protocols, and ports. This update introduces expanded matching capabilities and removes previous restrictions regarding the combination of match criteria, allowing for more granular traffic steering.

As of DMF version 8.7.0, all DMF appliances will operate on the AlmaLinux 9.4 operating system, replacing the previous Ubuntu 20.04 LTS. This migration of the underlying operating system will not impact any currently supported features.

The DMF Recorder Node now supports deployment as a Virtual Machine (VM) for functional testing in Proof of Concept (POC) environments. Performance is limited and will vary based on allocated VM resources. DMF 8.7.0 and later Recorder Node images support being deployed as a VM.

This feature provides a method to rename a DMF object. DMF 8.7 Controllers support the Policy rename feature.

The DMF VN-TAG Decapsulation (decap) feature introduces native support for removing the VN-TAG header within the DMF platform. This capability is implemented directly on the DMF Service Node to process traffic frames, and it integrates comprehensive control plane support via the Controller schema and the standard CLI workflow.

The DANZ Monitoring Fabric (DMF) allows the integration and monitoring of virtual machines in a VMware NSX fabric deployed in a vSphere environment. The DMF Controller communicates with NSX to retrieve its managed inventory and configures port mirroring sessions for selected virtual machines managed by the NSX fabric.

The DANZ Monitoring Fabric (DMF) allows the integration and monitoring of virtual machines in a VMware NSX fabric deployed in a vSphere environment. The DMF Controller communicates with NSX to retrieve its managed inventory and configures port mirroring sessions for selected virtual machines managed by the NSX fabric.

The feature adds support for dynamic prefix-list to match on all protocol routes, and not just BGP. Dynamic prefix-list policy construct is similar to the traditional IP and IPv6 prefix-list, except that they have an additional state associated. This state associated with the dynamic prefix-lists, is determined on the basis of the route entries in FIB, and hence as and when the FIB changes, the state also changes dynamically. 

Currently data packets going over a DPS+IPsec tunnel have a fixed source IP, destination IP, protocol, source port and destination port after encapsulation for a given DPS path. Because of this, there is no good way to load-balance the tunneled traffic. However, to improve performance there is a need to load-balance the tunneled traffic. 

With this feature, user can fetch various internal hardware drops info from each switch and isolate the switch or

Precision Time Protocol (PTP) management messages are general PTP messages sent to PTP-enabled switches on the data plane. On Arista switches, its behavior depends on the configured PTP mode. In Boundary Clock mode, they are handled by the control plane. In Transparent Clock mode, they are forwarded in the data plane. PTP management messages can be sent through the PTP network either in a multicast or unicast fashion (by using ptp forward unicast, see Forwarding Unicast PTP Packets in Boundary Mode).

By default, the DSCP and ECN bits of VXLAN bridged packets are not rewritten. Currently, for bridged packets undergoing VXLAN encapsulation, the DSCP in the outer IP header is derived from TC and the ECN bits are set to zero. The desired behavior is that the outer IP header should be remarked with ingress packet DSCP and ingress packet ECN. Also, local congestion should be handled correctly.

DCS 7280E. Arad QOS MAP:. This command assigns the DSCP rewrite value of 37 to traffic classes 2, 4, and 6.

Dual Tag VLAN mapping feature defines mapping between (outer VID and inner VID of double tagged packet) and bridging

Starting with EOS4.15.0F, dynamic and symmetric LAG hashing policies are supported on the 7500E platform. Dynamic

Dynamic Explicit Congestion Notification (D-ECN) configures an ECN marking threshold that changes dynamically based on a transmit queue’s available shared buffers. A D-ECN offset and D-ECN floor is configured per unicast transmit queue which defines how the ECN marking threshold will change as the queue’s shared buffer limit changes.

Until EOS release 4.32.0F, EOS allows users to statically configure link min-delay and max-delay used for IS-IS FlexAlgo. This feature adds support for dynamic measurement of link delay using the TWAMP Light protocol described in RFC 8186 and provides it to IS-IS FlexAlgo dynamically.

This document describes how to configure and monitor this feature.

Dynamic NAT connection limit is a feature that provides the functionality to limit the number of dynamic NAT connections.

Dynamic resizing of nexthop groups, as the name suggests, is a feature that enables a nexthop group to dynamically

Segment Routing Traffic Engineering Policy (SR-TE) aka SR Policy makes use of Segment Routing (SR) to allow a headend to steer traffic along any path without maintaining per flow state in every node. A headend steers traffic into an SR Policy. SR-TE policies allow creating segment lists using segments along the shortest path or along a flex algo path. These policies can be traffic engineered to avoid the shortest or flex-algo paths.

This feature allows eAPI to run in multiple non default VRFs on the same physical router. In this way, users can

eAPI over SSH provides programmatic access to Arista EOS Command API using SSH as the transport protocol, offering an alternative to HTTP/HTTPS-based eAPI. This feature enables network automation tools and scripts to execute CLI commands and retrieve structured output via JSON-RPC 2.0 over an SSH connection.

The feature uses the standard SSH subsystem mechanism, allowing clients to invoke the "eapi" subsystem after SSH authentication. Commands and responses use the same JSON-RPC 2.0 format as HTTP-based eAPI, ensuring compatibility with existing eAPI client libraries and scripts with minimal modifications.

ECMP Hash visibility CLI determines the output interface for an ECMP set based on the flow parameters supplied by the user. Ingress interface, source IP address, destination IP address and IP protocol are the required parameters. L4 source and destination ports and VLAN identifier are optional, but should be specified if the packet has them.

By default EOS does not perform Overlay ECMP for hosts connecting to a Multihoming Ethernet segment in an Asymmetric-IRB setup. Instead it picks one of the paths statically for sending the traffic. This feature enables ECMP for the multihomed hosts connected in an EVPN VXLAN all active multihoming Asymmetric-IRB setup.

This feature supports counting ECN-marked packets (ECN = Explicit Congestion Notification) on a per egress port per tx-queue basis. The feature can be used to gather these packet counts via CLI or SNMP.

Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and to the Transmission Control Protocol which allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that is only used when both endpoints support it and are willing to use it. ECN operates over an active queue management algorithm.

This feature provides the capability to count the number of packets hitting rules associated to egress ACLs applied

This feature allows generating the syslog message for the packets matching rules in egress ACLs. This can be enabled using the log keyword when configuring an ACL rule. A copy of the packet matching such an ACL rule is sent to the control plane, where a syslog entry for the packet header is generated.