Tag :: EOS 4.36.0F

7020 R4 Series Supports Speeds 25g, 10g, 1g on all SFP ports, 10g, 1g on all RJ45 ports, 100g, 50g, 25g on all QSFP ports

802.1X is an IEEE standard protocol that prevents unauthorized devices from gaining access to the network. We support dot1x protocol standard 802.1X-2004 (version=2)

Beginning with EOS version 4.36.0F, the CCS-710XP series offers the ability to increase ingress Access Control List (ACL) scale if counters are declared unnecessary. This will be the default behavior on CCS-710XP platforms running releases from 4.36.0F onwards. This document details steps to enable or disable counters as required, along with resources for related issues.

Agile ports allow users to connect 40G interfaces on 7130 products utilizing multiple parallel SFP ports per 40G capable interface. This enables 40G capable applications, such as MetaConnect and MetaWatch, to operate at that speed.

Groups of front panel ports can be controlled by one power controller module. Power faults can often be detected by the power controller, which causes loss of power for all ports controlled by the power controller. The fault can be triggered by inrush current during insertion or removal of transceivers. A broken transceiver can cause a fault too.

This feature introduces support for BGP route-target ranges specifically for route import. With this new capability, ranges of route targets can be configured for importing routes into VRFs.

When a BGP session cannot be established between two peers due to configuration inconsistencies, the peer is moved to the “idle state” and the session establishment is not retried. The session remains down until an operator issues a manual clear ip bgp command to bring it back up. This prevents continuous immediate reconnection attempts to the peer.

This feature adds support for BGP UCMP in the multi-agent routing protocol model. Unequal Cost Multi Path (UCMP) for BGP is a mechanism for forwarding traffic from a device for an ECMP route in the ratio of the weights with which the next hops of that route are programmed in the FIB. This is done for BGP by disseminating BGP link bandwidth extended community attribute information with BGP paths such that the receiver device of all such paths for a route programs next hops for that route in the FIB in the ratio of the received link bandwidth values.

This feature enables efficient cross-domain communication in a multi-domain deployment where the Layer 2 leaf VTEPs don't have arp learning bridged configured. Without this feature, cross-domain ARP requests must be flooded across all domains, creating significant overhead in large multi-domain deployments.

This feature allows failover to the backup path to occur in constant time per interface going down for features such as RSVP link protection, RSVP node protection, TI-LFA link protection, and BGP PIC. Without this feature enabled, it would take time proportional to the number of paths going over the interface experiencing the link down event to failover to the backup path. With this feature enabled, the failover time would be constant regardless of the number of paths.

This feature allows the configuration of custom DSCP-to-DSCP maps on a per-Nexthop Group (NHG) basis. When applied it rewrites the DSCP of the outer IPv4 header of IPvX-in-IPv4 (X represents both v4 and v6) encapsulated packets using the inner IPvX header’s DSCP value while ensuring the DSCP of the inner IPvX overlay is preserved.

Arista’s DCS-7130LBR series of switches are powerful network devices designed for ultra low latency applications along with a wealth of networking features.

Arista’s DCS-7135V series of switches are network devices designed for ultra low-latency applications along with a suite of networking features.

DirectFlow runs alongside the existing layer 2/3 forwarding plane, enabling a network architecture that incorporates new capabilities, such as TAP aggregation and custom traffic engineering, alongside traditional forwarding models. DirectFlow allows users to define flows that consist of match conditions and actions to perform that are a superset of the OpenFlow 1.0 specification. DirectFlow does not require a controller or any third party integration as flows can be installed via the CLI.

As Ethernet technologies made their way into the Metropolitan Area Networks (MAN) and the Wide Area Networks (WAN) from the conventional enterprise level usage, they are now widely being used by service providers to provide end-to-end connectivity to customers. Such service provider networks are typically spread across large geographical areas. Additionally, the service providers themselves may be relying on certain internet backbone providers, referred to as “operators”, to provide connectivity in case the geographical area to be covered is too huge.

This feature introduces the show bgp evpn sanity ( brief | detail )command. This command displays which EVPN configuration attributes are inconsistent as well as potential errors in the EVPN operational state.

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

Ethernet VPN (EVPN) networks normally require some measure of redundancy to reduce or eliminate the impact of outages and maintenance. RFC7432 describes four types of route to be exchanged through EVPN, with a built-in multihoming mechanism for redundancy. Prior to EOS 4.22.0F, MLAG was available as a redundancy option for EVPN with VXLAN, but not multihoming. EVPN multihoming is a multi-vendor standards-based redundancy solution that does not require a dedicated peer link and allows for more flexible configurations than MLAG, supporting peering on a per interface level rather than a per device level. It also supports a mass withdrawal mechanism to minimize traffic loss when a link goes down.

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

Forwarding destination prediction allows users to determine which interface a given packet will egress out. This feature is enhanced to identify the TCAM bank and rule offset for the matched ACL rule responsible for the forwarding decision. This allows network operators to trace the egress result back to the exact rule that triggered the action.

This feature adds support for the front panel Ethernet (Et) interface counters on the platforms listed below and enables the Et interfaces to dynamically adopt the counter values (packet and error) of interfaces (Switch, App interfaces etc.) related to the currently running FPGA application, based on user or default configuration. All Arista FPGA applications are supported. Both the receive and transmit packet counters can be independently configured for each interface, as desired. Counters are supported for interfaces of any speed including agile ports.

The document describes the support for dedicated and group ingress policing on interfaces without using QoS policy-maps to match on the traffic and apply policing.

This document describes the support for interface policing counters on interfaces where interface policing feature is configured. Counters for this feature provide information on how many packets are being allowed or dropped on a given interface via the policers configured. The counters are only supported on interfaces where dedicated policers are configured.

IP Locking is an EOS feature configured on an Ethernet Layer 2 port or on a VLAN. When enabled, it ensures that a configured port or all member ports of a configured VLAN will only permit IP and ARP packets with IP source addresses that have been authorized. IP Locking prevents another host on a different IP Locking enabled interface from claiming ownership of an IP address through either IP or ARP spoofing. Additionally, IP Locking prevents hosts from masquerading as a DHCP server by blocking DHCP (server-to-client) packets.

IPv4 routes of certain prefix lengths can be optimized for enhanced route scale. This document describes the enhancements done to IPv4 route scale in subsequent EOS releases.

Normally, a switch traps L2 protocol frames to the CPU. However, certain use-cases may require these frames to be forwarded or dropped. And in cases where the L2 protocol frames are forwarded (eg: Pseudowire), we may require the frames to be trapped to the CPU or dropped. The L2 Protocol Forwarding feature provides a mechanism to control the behavior of L2 protocol frames received on a port or subinterface.

Subinterfaces divide a single ethernet or port channel interface into multiple logical L3 interfaces based on the 802.1q tag (VLAN ID) of incoming traffic. Subinterfaces are commonly used in the L2/L3 boundary device, but they can also be used to isolate traffic with 802.1q tags between L3 peers by assigning each subinterface to a different VRF. L3 subinterface shaping + VRF is also supported.

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

IPv6 static routes can be configured with link-local next-hop addresses on point-to-point interfaces. However, in deployments that rely on Zero Touch Provisioning (ZTP) to bring up devices with static routes, specifying link-local addresses in configuration templates is cumbersome because link-local addresses vary per device and per interface. This makes it impossible to use a single configuration template across multiple devices.

This capability allows for the logging of Access Control List (ACL) actions on CloudEOS and AWE-series platforms. Logging is supported for various ACL actions including permit, drop, and redirect.

Media Access Control Security (MACSec) is an industry standard encryption mechanism that protects all traffic flowing on the Ethernet links. MACSec is based on IEEE 802.1X and IEEE 802.1AE standards. This document describes the details of MACSec on CCS-722XPM-48Y4 and CCS-722XPM-48ZY8 products. MACSec on these platforms is implemented by internally sending frames to be decrypted or encrypted to a block of the switch chip, referred to as the MACSec engine.

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. The MetaWatch application consists of 4 MetaWatch cores with input ports at 1G, 10G, 25G or 40G, depending on the profile. The packets ingressing these inputs are timestamped and aggregated into a deep buffer private to each core.

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.

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.

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.

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. MultiAccess’s port to port latency is a function of the selected MultiAccess profile, interfaces being used, interface configuration, and the platform itself. For latency details, please refer to the Latencies section of this TOI.

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

In certain IPsec VPN scenarios, the responder needs to assign a virtual IP address (peer address) to an initiator. During the IKE negotiation, the initiator requests a virtual IP to be assigned with an IPsec configuration payload parameter. The responder establishes the connection after assigning an IP to the initiator.

This article provides a general introduction to Precision Time Protocol (PTP) supported within EOS. PTP is aimed at distributing time with sub-microsecond accuracy. PTP support is based on the IEEE-1588 specification for version 2 of the protocol. 

Forwarding destination prediction allows users to determine which interface a given packet will egress out. This feature is enhanced to identify the TCAM bank and rule offset for the matched ACL rule responsible for the forwarding decision. This allows network operators to trace the egress result back to the exact rule that triggered the action.

This feature provides protocol independent UCMP support for all the routes which follow the IGP path provided there is no UCMP computation done at the protocol level itself. This feature optimizes bandwidth utilization by weighting next-hop members according to their link capacity.

Routing control functions (RCF) is a language that can be used to express route filtering and attribute modification logic in a powerful and programmatic fashion. This document serves as a reference guide for Routing protocol attributes, Operators for comparing and modifying attributes, built-in functions provided in RCF

RSVP-TE, the Resource Reservation Protocol (RSVP) for Traffic Engineering (TE), is used to distribute MPLS labels for steering traffic and reserving bandwidth. The Label Edge Router (LER) feature implements the headend functionality, i.e., RSVP-TE tunnels can originate at an LER which can steer traffic into the tunnel.

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”. EOS 4.21.0F adds support for SR Policy for the MPLS dataplane (SR-MPLS) for Type-1 SR Policy segments with BGP and locally configured policies as sources of SR Policies on Arista’s 7500, 7280 families of switches.

The Dynamic Load Balancing (DLB) feature is currently supported in the DCS-7060 Arista switches in order to provide an alternative to the hash-based ECMP load balancing, which selects the next hop for routed packets using a static hash algorithm. DLB considers the state and quality of the port while assigning egress ports to packets, resulting in a more even flow. The state of each port member is determined by measuring the amount of data transmitted from a given port and the total number of packets enqueued to a given port.

The identity of a remote peer (used to authenticate the remote peer in IKE phase 1) can be specified in the form of an IP address or a Fully Qualified Domain Name (FQDN) / User Fully Qualified Domain Name (UFQDN). This feature allows specifying an X.500 distinguished name (RFC 4514) as the remote peer identity.

This TOI describes details and limitations of Stateful Switchover on Modular chassis with 7500R3, 7800R3, 7800R3A, 7800R4, 7800R4C based line cards.

A fundamental business requirement for any network operator is to reduce costs where possible. For network operators, deploying devices to many locations can be a high cost, as sending trained specialists to each site for installations is both time-consuming and expensive. Arista devices support Zero Touch Provisioning (ZTP), a bootstrapping strategy that enables devices to obtain configuration data with no installer action beyond physical placement and connecting network and power cables. Secure Zero Touch Provisioning (SZTP) builds on ZTP and securely supports provisioning as defined in RFC 8572.

Dynamic NAT is a feature which dynamically allocates an IP address to an incoming or outgoing flow. This address will replace source or destination IP for all packets of the flow. The new IP address given to the flow is from a pool of addresses called NAT pool. L4 port can also be replaced by a new one in case of NAPT (Network Address Port Translation). In address only NAT only the IP address is translated. NAPT is not supported in masquerade or overload mode.