• Author : Sahil Midha

 
 

Link Fault Signaling

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 →

Policy maps under QoS Profiles

QoS profiles have been applicable on fabric and front panel ports across all platforms from EOS 4.17.0F release onwards with support for all interface level QoS configurations. Support for application of a policy-map under QoS profile has now been added in EOS 4.18.0F. The same policy-map can be applied through QoS profile on one interface and directly attached on another. If two policy-maps are applied on an interface through directly and QoS profile, the one applied directly is given more priority and used. Configuration The command to configure a policy-map under qos profile is – Arista(config)#qos profile <qos-profile name> Arista(config-qos-profile-name)#service-policy...
Continue reading →

Show command for fabric interfaces

The show command ‘show qos interface fabric’ was introduced for DCS-7250QX and DCS-7300X series starting EOS-4.15.2F release, which just displayed the Qos profile applied on the fabric interface. This command has now been modified to display detailed information about configured/operational values of interface Qos configurations, as is shown by the command – ‘show qos interfaces <intfName>’ for front panel ports. Variants of the command have also been added to display information of fabric ports across all chips and to display ECN thresholds for ECN configuration on the ports. Platform compatibility DCS-7250X DCS-7300X Configuration All configurations on the fabric port is through...
Continue reading →

QoS Profiles

QoS profiles are a collection of interface level QoS configuration commands, that are used as an alternate means of input to the traditional CLI. They help in reducing clutter in the running configuration. A possible use-case would be when there are common QoS configuration statements that need to be applied or modified on multiple interfaces. Introduced first for the DCS-7250QX and DCS-7300X series with the EOS-4.15.2F release, they have been improved upon in this release. Previously, they were applicable only on the fabric interface and supported priority flow control, tx-queue ECN, WRED and guaranteedBandwidth configurations. Now they are also applicable...
Continue reading →

Deep packet inspection – SCTP support

Stream Control Transmission Protocol ( 132 ) is a transport layer protocol, much like TCP. After the IP header, a SCTP packet has the following fields: source port, destination port, tag and checksum. Starting EOS 4.15.0F, deep packet inspection on Arista DCS 7150 allows for filtering of SCTP traffic via ACLs, by matching on source port, destination port and payload. Configuration The feature can be configures using following set of CLI commands: Arista(config)#tap aggregation Arista(config-tap-agg)#mode exclusive Arista(config)#ip access-list <acl name> Arista(config-acl)#permit/deny sctp <srcIp> <sport> <dstIp> <dport> payload [ { offset <value> pattern <value> mask<value> }+] switch(config-acl)#permit/deny sctp <srcIp> <dstIp> [ userl4 pattern < value>...
Continue reading →

Permit during ACL update for security ACLs

  Permitting traffic during ACL updates has been available for traffic steering in tap aggregation mode since EOS 4.14.0F. In EOS 4.15.0F, this feature is extended for security ACLs in regular switch mode. By default, the feature is disabled. If there is any change in the ACL configuration, the traffic flow to all Ethernet ports is stopped until the ACLs have been successfully applied and the system in a stable state once again. As a result, a considerable number of packets could be dropped on all ports and features like routing or dynamic NAT can be affected (in this window of time)....
Continue reading →