Tag : 4.20.1F

Description The show interfaces capabilities default command provides static interface capability information.  This command outputs the default capabilities of the specified interfaces.  By ‘default capabilities’, we mean the set of capabilities unaffected by an external hardware component. For example, a transceiver is an external hardware component. This command’s output does not factor in the capabilities of a transceiver; rather, it only accounts for the capabilities of the system architecture. This command provides the speed, auto-negotiation, error correction, and modulation capabilities (when applicable) of a system’s ports.  This command solves a different problem than its sister command show interfaces capabilities because...
Continue reading →

Description IP traceroute and path MTU (PMTU) discovery both require that routers send ICMP reply messages to the host that invokes each network function.  When the route to the destination host traverses an MPLS label-switched path (LSP), the label switching routers (LSRs) will also need to send ICMP reply messages to the originating host. The MPLS ICMP tunneling feature enables these LSRs to generate ICMP reply messages and deliver them to the originating host using the same LSP on which the frame was received.  Once the frame exits the LSP, it is assumed that the ICMP reply can be routed...
Continue reading →

Description This feature allows users to view most recent history of offset from master, mean path delay and skew values via CLI command and optionally generate syslogs. To generate syslogs, users must configure threshold values for each metric, and whenever the switch sees an unusual data, it will generate a syslog. Recording and displaying recent history is enabled by default so the data is available in show tech-support command, but syslog feature is disabled by default, and user must configure in order to generate them. Platform compatibility This feature is available on all PTP supported products. Configuration Arista(config)#[no] ptp monitor...
Continue reading →

Introduction: DHCP relay agent uses one of the addresses configured on the interface as the source IP when relaying messages to the DHCP server. DHCP clients will acquire an address in this subnet. If an interface has multiple addresses configured and it is intended for DHCP clients to acquire addresses in a specific subnet, this particular address can be specified as the source-address for the DHCP server. DhcpRelay agent will use this address as the source IP when relaying messages to the corresponding server. Configuration A source-address can be specified for a DHCP server using the following CLI command  ...
Continue reading →

Description DHCPv6 relay supports Remote-ID option insertion in relay messages providing the Layer-3 interface name on which DHCPv6 relay is configured. However, DHCPv6 relay can’t provide Layer-2 information. This feature implements DHCPv6 snooping functionality to intercept DHCPv6 messages and insert Remote-ID option containing Layer 2 information such as VLAN and interface name. Remote-ID option uses the message format described in RFC4649, remote-id field contains DHCP Unique Identifier with LinkLayerAddress (DUID-LL) to achieve uniqueness and sub-option is a string representation of Layer-2 interface name and VLAN number separated by ‘:’ character. For example, DHCP solicit message received on interface Ethernet3/1 configured...
Continue reading →

Description Ahost is a generic Fedora-based Linux OS primarily for the purposes of hosting cEOS. It has a 64-bit kernel (EosKernel) and a 32-bit userspace. It is provided as a SWI called Ahost.swi. Platform compatibility DCS-7050CX3-32S DCS-7050SX3-48YC12 DCS-7060CX-32S-ES DCS-7060CX-32S-SSD DCS-7260CX3-64 Configuration To load Ahost on a box running EOS: Copy Ahost.swi to /mnt/flash/ on the box Modify the boot-config (/mnt/flash/boot-config) to point to Ahost.swi: SWI=flash:/Ahost.swi Reboot the box   Installation of Ahost.swi through onie-installer is supported on White Boxes in experimental mode.   Ahost acquires its IP over DHCP. This may result in a different IP address than the one...
Continue reading →

Starting in the EOS-4.21.1F release, reload console logs are available to help in debugging of unexpected reloads. The output of the serial console is available following any reload whether it is planned or unplanned. This output can be used to help debug unexpected reloads. This output complements the existing ‘show reload cause’ command. Platform compatibility Reload console logs are supported on the following platforms: DCS-7020TR-48   DCS-7020TRA-48   DCS-7050SX-72Q   DCS-7050SX2-72Q   DCS-7050TX-72Q   DCS-7060SX2-48YC6   DCS-7160-48TC6   DCS-7160-48YC6   DCS-7260CX3-64   DCS-7280CR2A-30   DCS-7280CR2K-30   DCS-7280QRA-C36S   DCS-7280SR-48C6   DCS-7280SR2-48YC6   DCS-7280SR2A-48YC6   DCS-7280SR2K-48C6   DCS-7280SR2L-48C6   DCS-7280SRA-48C6  ...
Continue reading →

EOS release 4.20.5F adds asset tagging support that aids hardware identification by the use of user-supplied strings. Platform compatibility Asset tagging is currently supported only on fixed systems. Configuration Asset tags are configured via the CLI or eAPI using the following command: [ no | default ] hardware asset-tag <hardware> <tag> On a fixed system, <hardware> can be either ‘switch’ or ‘powersupply <1-2>’, depending on the power supplies present. For example, Arista# hardware asset-tag switch Floor3RU4 The current configuration can be viewed with the ‘show’ command: Arista# show hardware asset-tagComponent           Serial Number       Asset Tag ...
Continue reading →

Bidirectional PIM has information on Bidirectional Protocol Independent Mulicast (PIM). Additional information applicable to DCS-7020R, DCS-7280E/R/R2 and DCS-7500E/R/R2 is documented here. Platform compatibility DCS-7020R DCS-7280E DCS-7280R DCS-7280R2 DCS-7500E DCS-7500R DCS-7500R2 Limitations “Bidirectional PIM” is incompatible with “Dot1x MAB” and “Drop Mac” features. When more than one feature is configured, “Bidirectionl PIM” gets priority followed by “Dot1x MAB” followed by “Drop Mac”. If “Bidirection PIM” is enabled on platforms using Arista Algomatch, ACLs are not supported on routed multicast traffic including sparse-mode PIM

Classification of MPLS packets based on traffic-class bits in MPLS header for QoS Policy-Maps. Platform compatibility DCS-7020R DCS-7280R DCS-7280R2 DCS-7500 DCS-7500R2 Configuration 7500(config)#hardware tcam 7500(config-hw-tcam)#system profile qos 7500(config-hw-tcam)#exit 7500(config)#class-map type qos match-any class1 7500(config-cmap-qos-class1)#match mpls traffic-class ? $      end of range <0-7>  Match packets by Mpls Traffic Class value 7500(config-cmap-qos-class1)#match mpls traffic-class 4 7500(config-cmap-qos-class1)#exit 7500(config)#policy-map type qos policy1 7500(config-pmap-qos-policy1)#class class1 7500(config-pmap-c-qos-policy1-class1)#set traffic-class 3 7500(config-pmap-c-qos-policy1-class1)#exit 7500(config-pmap-qos-policy1)#exit 7500(config)#interface ethernet 3 7500(config-if-Et3)#service-policy input policy1 7500(config-if-Et3)#exit Status 7500(config)#show class-map class1   Class-map: class1 (match-any)     Match: mpls traffic-class 4 7500(config)#show policy-map policy1 Service-policy input: policy1   Hardware programming status: Successful   Class-map: class1 (match-any)...
Continue reading →

This features enables ARPs learnt on an SVI interface to be converted into Host routes which can further be redistributed into BGP protocol to take part in the route selection decision process and to get advertised to the peers. These Host routes are not installed into the hardware and are only being generated for advertisement purpose. This feature works for both static and dynamic ARPs. ARP will be converted to Host route, if the feature is enabled using the CLI (as described in the next section), and corresponding MAC address exists in the MAC table Host route will be deleted,...
Continue reading →

Introduction PIM Static Source Discovery (PIM-SM SSD) is a feature implemented as part of PIM-SM. Familiarity with setting up and configuring PIM-SM ( Sparse Mode ) and PIM-SSM ( Source Specific Multicast ) is assumed. PIM-SSM is used to deliver multicast packets from a specific source address requested by a multicast receiver. PIM-SSM bring several benefits over PIM-SM. It does not rely on the designation of a rendezvous point (RP) to establish a RP tree and then switch to Shortest-Path Tree to source. Instead, PIM-SSM builds Shortest-Path Tree to source directly since source is always known in advance. However, PIM-SSM...
Continue reading →

BFD for static routes enables monitoring of directly connected next-hop reachability using a BFD session. This is achieved by associating the next-hop of the static route with a static BFD neighbor configuration. The static route is either installed or removed based on the status of the underlying BFD session. A static route whose next-hop is configured to be tracked by BFD is referred to as a ‘BFD tracked static route’ in the context of this document. This feature is supported for both IPv4 and IPv6 static routes. Platform compatibility BFD for Static Routes feature is supported on all platforms. Configuration The existing...
Continue reading →

Overview Equal Cost Multi-path (ECMP) provides the ability to load-share traffic across multiple next-hops. When a next-hop fails or is deleted all flows are affected. This is due to the nature of the load-balancing algorithm which re-calculates a new hash for the flows based on the remaining active next-hops. Resilient ECMP keeps the total number of next-hops same by replacing the deleted next-hop with one or more of the remaining active next-hops and maintain the order of next-hops in the ECMP groupset. This feature is currently supported on the 7050, 7160, 7280, 73xx, 75xx platforms Benefits When a next-hop fails,...
Continue reading →

Introduction Link Fault Signalling (LFS) is a mechanism by which remote link faults are asserted over a link experiencing problems. Link fault signalling operates between the remote Reconciliation Sublayer (remote RS) and the local Reconciliation Sublayer (local RS). Faults detected between the remote RS and the local RS are treated by the local RS as Local Faults. Configuring LFS parameters is supported on compatible Arista switches from version EOS 4.20.1F onwards. Starting 4.20.5F LFS is also supported on DCS-7050X, DCS-7250X, DCS-7060X, DCS-7260X, DCS-7300, DCS-7320 As part of this feature FCS and Symbol errors are monitored on an interface and if they...
Continue reading →

Connectivity Fault Management (CFM) is used in Virtual Bridged Local Area Networks for detecting, isolating, and reporting connectivity faults. Please refer IEEE 802.1ag standard for more details. This document introduces to the concept of Default Maintenance Intermediate Point and how to configure it on a switch for monitoring connectivity between various Maintenance Points within a Maintenance Domain. This feature is supported from EOS-4.20.1F onwards. Platform compatibility DCS-7020R DCS-7280R DCS-7280R2 DCS-7500R DCS-7500R2 Abbreviations MD Maintenance Domain MDL Maintenance Domain Level MP Maintenance Point MEP Maintenance End Point MIP Maintenance Intermediate Point CCM Continuity Check Message LTM Linktrace Message LTR Linktrace Reply...
Continue reading →

This article describes various advanced mirroring features. Filtered Mirroring Mirroring to Gre Sampled Mirroring Rate Limiting of Mirrored Traffic Mirroring and sFlow Mirroring Truncation Mirroring to Port-Channel Filtered Mirroring Current Behavior Overview Filtered Mirroring allows certain packets to be selected for mirroring, rather than all packets ingressing or egressing a particular port. Platform compatibility DCS-7010T, DCS-7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-7300X, DCS-7280E, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R, DCS-7500R2, and DCS-7020 are supported. Configuration Note: To use this feature on the DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R and DCS-7500R2 series, a platform configuration may be required to enable the mirroring ACL profile. See the platform-specific section...
Continue reading →

Introduction   Hierarchical Forwarding Equivalence Class (HFEC) changes a FEC from a single flat level to a multi-level FEC resolution. On 7280R/7500R onwards, two level HFEC is supported: the 1st level FEC points to tunnel next hops and the 2nd level FEC points to direct next hops for each of the tunnel’s next hops.   HFEC has below benefits: Supports larger ECMP since only the 1st level tunnel FEC is exposed to RIB, the 2nd level interface FEC is hidden to RIB. Achieves faster convergence since tunnel FEC and interface FEC at each level can be independently updated. Supported Platforms:...
Continue reading →

EVPN Integrated Routing and Bridging (IRB) with VXLAN In the traditional data center design, inter-subnet forwarding is provided by a centralised router, where traffic traverses across the network to a centralised routing node and back again to its final destination. In a large multi-tenant data center environment this operational model can lead to inefficient use of bandwidth and sub-optimal forwarding.   To provide a more optimal forwarding model and avoid traffic tromboning, the EVPN inter-subnet draft (draft-sajassi-l2vpn-evpn-inter-subnet-forwarding) proposes integrating the routing and bridging (IRB) functionality directly onto the VTEP, thereby allowing the routing operation to occur as close to the...
Continue reading →

This feature is available when configuring BGP in the multi-agent routing protocol model. Ethernet VPN (EVPN) is an extension of the BGP protocol introducing a new address family: L2VPN (address family number 25) / EVPN (subsequent address family number 70). It is used to exchange overlay MAC and IP address reachability information between BGP peers [1]. EVPN supports the exchange of layer 3 IPv4 and IPv6 overlay routes through the extensions described in [2] (type 5 EVPN routes). An IP VRF is used on a Provider Edge (PE) router for each layer 3 overlay. VRF IPv4 and IPv6 routes are...
Continue reading →