Changing the switchport default mode

posted on April 25, 2017 by

By default all ports on an Arista switch are configured to be switch ports, as you would expect. If you are mostly dealing with routed ports, this behaviour may not be totally desirable. Starting in EOS-4.18.0, this behaviour is configurable e.g. we can have all interfaces in routed mode by default. switch1...11:10:56(config)#show run int et 1-4interface Ethernet1interface Ethernet2interface Ethernet3interface Ethernet4switch1...11:11:00(config)#show interface Et1-4 switchport | i Name|Switchport:Name: Et1Switchport: EnabledName: Et2Switchport: EnabledName: Et3Switchport: EnabledName: Et4Switchport: Enabled To change the default, simply issue the configuration command switchport default mode routed As you can see, all interfaces are now in routed mode by default:...
Continue reading →

VM Tracer configuration on a layer 2 switch

posted on April 18, 2017 by

Introduction There are many network architectures, which include a separate network for out-of-band management. All Arista switches come with at least one designated management interface that is VRF-aware. When VM Tracer is configured on an Arista switch, by default, vCenter communication will be sourced from the management interface. There are situations where a layer 2 switch has the management interface configured in a separate VRF, not reachable from the vCenter network segment.  Objective Create reachability to vCenter from layer 2 switches that have the management interface configured in a separate VRF, not reachable from the vCenter network segment.  Prerequisites Proper VM Tracer configuration...
Continue reading →

Arista 7280QR-C36 Load Balancing Optimization for Dual Homed Systems and Networks

posted on December 21, 2016 by

Arista 7280QR-C36  The Arista DCS-7280QR-C36 switch is a purpose built flexible fixed configuration 1RU system capable of supporting a wide range of interface choices. Its designed for the highest performance environments such as IP Storage, Content Delivery Networks, Data Center Interconnect and IP Peering. The 7280QR-C36 is optimized for environments with dual connected nodes such as storage and for spine applications with dual homed leaf switches. This technical application note describes the internal optimized load-balancing mechanism used within the switch and how network architects can best deploy this system to maximize overall system performance. The internal architecture of the DCS-7280QR-C36...
Continue reading →

MLAG ISSU

posted on June 28, 2016 by

Overview MLAG ISSU (In-Service Software Upgrade) upgrades EOS software on one MLAG peer with minimal traffic disruptions on active MLAG interfaces and without changing the network topology. Note: Traffic impact could be seen for orphan links, active partial links and packets in flight   MLAG considerations before upgrade   I. Check for configuration inconsistencies Following features should be configured consistently on each switch: VLANs Switchport configuration on port channel interfaces that are configured with an MLAG ID STP configuration (global) In EOS versions 4.15.2F onwards, we can use MLAG configuration check feature: https://eos.arista.com/eos-4-15-2f/mlag-config-check/   II. Resolve ISSU warnings Resolve the...
Continue reading →

Config Sessions Tips

posted on March 16, 2016 by

Description: You want to implement human error prevention, 4-eyes-principle, task separation and delegation in your network? Then read on. We’ll show you how you can delegate configuration preparation to the operators team, retaining the control to commit the submitted changes, and having a delayed roll-back as a safety network in case something went wrong. Please also refer to the article “How to keep last X startup configs” for further tips on config handling and versioning. User Management: Let’s create two roles: one for the Network Operations team, that is allowed to use “configure session” to prepare changes, but is not...
Continue reading →

How to keep last X startup configs

posted on April 24, 2015 by

If you would like to keep track of last 10 (or more, or less) configuration changes, here’s the event-handler code to do that: event-handler config-versioning    trigger on-startup-config action bash FN=/mnt/flash/startup-config; LFN="`ls -1 $FN.*-* | tail -n 1`"; if [ -z "$LFN" -o -n "`diff -I 'last modified' $FN $LFN`" ]; then cp $FN $FN.`date +%Y%m%d-%H%M%S`; ls -1r $FN.*-* | tail -n +11 | xargs -I % rm %; fi    delay 0 Description: Every time the startup config gets changed, this event handler will be executed (“trigger on-startup-config”). You could increase the delay, if you wish, but now it’s engaged immediately...
Continue reading →

VMTracer ESX port configurations

posted on March 12, 2015 by

I am configuring a pair of new Arista 7050T switches in MLAG.  My question relates to port configurations for the ports that will connect to the 6 x ESX hosts.  Each host has 2 dual port NICS and 2 vDS (1 for VM and 1 for IPStorage). Each vDS has a single uplink to each NIC(2 in total) and each NIC is connected to both switches. 1. When using vmtracer is the only config I need on the port “vmtracer vmware-esx” and this implements best practices regarding spanning-tree, switchport mode, flow control etc on each port or is this command...
Continue reading →

Intelligent Bootstrap with Arista EOS and ZTPServer

posted on August 25, 2014 by

Many customers inquire about how to get started with automation into their operational networks. These conversations tend to revolve around how to reduce the operational expense and risk associated with managing data center networks. In most cases, the general consensus leads to starting automation around the bootstrap process or, in other words, how to find a better way to introduce consistency and agility into the deployment process.  Arista’s early heritage grew from solving real world operational problems that enhance our customers ability to deliver massively scalable data center networks efficiently. Throughout the development process EOS has provided innovative solutions that...
Continue reading →

Introducing Arista EOS Roles for Ansible

posted on August 19, 2014 by

This article introduces the newly released Arista EOS role for Ansible.  The Arista EOS role provides a set of Ansible modules that can used in playbooks for automating the configuration of network resources contained in Arista EOS nodes.  The EOS role replaces the existing arista_* modules that are currently available in the Ansible distribution.  The base code that comprises the EOS role has been re-worked from the beginning, influenced by lessons learned from the first generation modules.   In addition, the EOS role now takes advantage of Ansible Galaxy to provide a streamlined distribution mechanism to make getting started with...
Continue reading →

Configuring Port Channel LACP Fallback on Arista Switches

posted on July 9, 2014 by

The Port-Channel Fallback mode in Arista switches allows an active LACP interface to establish a Port Channel/LAG before it receives LACP PDU’s from its peer. This feature is useful in environments where customers have Preboot Execution Environment (PXE) Servers connected with a LACP Port Channel to the Ethernet switch.  Since PXE images are very small, many operating systems are unable to leverage LACP during the preboot process.  The Server NICs do not have the capability to run LACP without the assistance of a fully functional OS, and during the PXE process they are independent and have no knowledge of the...
Continue reading →

Running vEOS on ESXi 5.5

posted on July 9, 2014 by

What is vEOS? Arista Networks vEOS is a software only version of the EOS network operating system. vEOS is meant to be run in a virtual machine environment. vEOS is useful for feature testing and especially for development of scripts and extensions. vEOS can be run on many different virtualization platforms like Virtual Box, VMware Fusion or Workstation as well as ESXi. Arista Networks has previously published how to documentation for running vEOS on other virtualization platforms and this document will extend that documentation to ESXi. What is ESXi? VMware ESXi is a server virtualization platform that supports hypervisor clustering,...
Continue reading →

DANZ TAP Aggregation Configuration: Quick Start

posted on May 12, 2014 by

TAP Aggregation Overview TAP Aggregation enables N:M packet replication, unlike SPAN/mirror ports, which have limited filtering capability and only a few ports with which to mirror to. Besides that, Arista’s TAP aggregation offering enables users to leverage the extensibility of EOS – click here for a more in depth overview of TAP aggregation or contact your local account team for an in depth overview of DANZ. Enabling Tap Aggregation By default, Arista switches operate in normal switching mode. To place the switch into TAP aggregation mode, the following configuration must be added: tap aggregation   mode exclusive This configuration disables all ports...
Continue reading →

TCPDUMP on an Arista switch and redirect or send output via email, SCP and TFTP

posted on February 18, 2014 by

Sending TCPDUMP output to external servers Objective Perform tcpdump on switch to help with troubleshooting control-plane traffic e.g.m STP, OSPF, BGP, NTP etc. directed to CPU of the switch without impacting performance. Then redirect the output to email/tftp/ftp server. Prerequisites Email server SSH server TFTP server DNS Resolution Arista switch configured to send email: (read all about it here) Email example Security Considerations Arista Networks EOS supports TLS and SMTP Authentication for email. It is important to understand that this provides security, but does not guarantee security end-to-end. For example, if you send an email from a switch with TLS...
Continue reading →

Configuring LACP Fallback Individual Ports on Arista Switches

posted on February 18, 2014 by

LACP Fallback Individual Ports Feature Overview LACP Fallback Individual Ports is a feature introduced in EOS 4.13.0 that allows all ports in a port- channel to fallback to individual switch ports when negotiation fails The feature is applied to the port-channel interface and consists of two configuration elements which will be described in the following sections Setting the port-channel to individual fallback Setting the fallback timeout   Feature Operation LACP Fallback Individual Ports use cases This feature is useful for servers with multiple NICs where it is difficult to predict which NIC the server might use for PXE boot. Summary of...
Continue reading →

MLAG – basic configuration

posted on February 18, 2014 by

MLAG overview LAG or link aggregation is a way of bonding multiple physical links into a combined logical link. MLAG or multi-chassis link aggregation extends this capability allowing a downstream switch or host to connect to two switches configured as an MLAG domain. This provides redundancy by giving the downstream switch or host two uplink paths as well as full bandwidth utilization since the MLAG domain appears to be a single switch to Spanning Tree (STP). Because the MLAG domain appears to STP as a single switch there are no blocked ports. Configuration The following will provide instructions on how...
Continue reading →

Active-active router redundancy using VARP

posted on February 12, 2014 by

In most of Leaf-Spine deployments, redundancy in Spine layer is required to achieve high availability and to prevent network service disruption. Modern layer 2 networks adopted loop-free and balanced path networks using Multi Chassis Link Aggregation topologies with LACP port channels, leaving loop control methods (STP) as second protection layer. Spines also supports layer 3 networks, using ECMP in a scalable network topology. For unicast redundancy in layer 3, a common method is use First Hop Router Redundancy (FHRR) to provide a simple and unique gateway for Leaf level. VRRP and HRSP are popular FHRR protocols and supported in most...
Continue reading →

How to configure Link Aggregation Groups in EOS

posted on February 12, 2014 by

This article describes the configuration of Link Aggregation Groups (LAGs) between two Arista 7050T-64 switches. The configuration examples are not specific to the switch model and this guide should apply to configuring LAGs on all Arista hardware. Static Link Aggregation Configuration of 7050-01 7050-01(config-if-Et17-20)#channel-group 200 mode on Once the above sequence is entered, Ethernet interfaces 17 through 20 are bound in a LAG as port-channel 200: 7050-01#show int po200 Port-Channel200 is down, line protocol is lowerlayerdown (notconnect) Hardware is Port-Channel, address is 001c.731c.46f9 Ethernet MTU 9214 bytes Full-duplex, Unconfigured Active members in this channel: 0 Fallback mode is: off Fallback...
Continue reading →

Restricting access to the switch

posted on January 24, 2014 by

In this article we demonstrate how you can enable your Arista switch to restrict access to various network services. By default, Arista EOS implements a control-plane ACL to restrict the packets going to the CPU.  This is done for security purposes, but in its default configuration is very permissive.  As such, it is recommended that the sources which can access the switch be restricted using the methods described below. To view the default ACL issue the following command: Arista#sh ip access-lists default-control-plane-acl IP Access List default-control-plane-acl [readonly] statistics per-entry 10 permit icmp any any [match 4, 11 days, 20:46:23 ago]...
Continue reading →

SSH login without password

posted on January 22, 2014 by

This article describes how you can configure your switch with a pre-shared SSH key from a host. 1. Create the user account on the switch   Arista(config)#username <user> privilege 15 secret <secret password> 2. Generate SSH key files on the SSH client host. If you already have the SSH key files, skip to step 3. <host>$ssh-keygen -t dsa -f testkey Generating public/private dsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in testkey. Your public key has been saved in testkey.pub. The key fingerprint is: 38:dd:3a:68:ea:36:f1:9b:fa:69:ba:43:38:2f:98:f0 fred@HOST1.yourdomain.local The key's randomart image...
Continue reading →

How to backup EOS configs to a remote server

posted on January 22, 2014 by

This article describes how a switch can push its configuration to a remote server, either on demand or periodically. Automating remote authentication using SSH keys Generate public/private DSA key pair: [root@Arista root]#ssh-keygen -t dsa Enter file in which to save the key (/root/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_dsa. Your public key has been saved in /root/.ssh/id_dsa.pub. Create an ssh config file for the (in this example) root user. Make sure the formatting is correct. [root@Arista ~]#vi /root/.ssh/config Host * IdentityFile /root/.ssh/id_dsa Copy the public key to the remote...
Continue reading →

Email client configuration in EOS

posted on January 21, 2014 by

This article covers the configuration and use of email in Arista EOS. 1) Configuring Email Arista switches can be configured as email clients and can be used to send email alerts through event handlers (which trigger an action when a certain event happens, for example when an interface goes down). This capability is in addition to the other management and monitoring methods available in EOS. Email can also be used from the CLI, as a convenient way to retrieve information for support. EOS email supports both TLS and SMTP authentication. Arista(config)#email Arista(config-email)#? auth Email account authentication from-user Send email from...
Continue reading →

Dynamically update your interface name via port auto-description

posted on January 15, 2014 by

Overview: Port auto-description will dynamically update the port description based on the LLDP information received from the neighbour. As always we are looking for your feedback please let us know if you have ideas on how to improve this script or other ideas… The tool: The script, called ‘portAuto’, will dynamically change the port description based on the neighbour’s LLDP information. This could be used as a stand alone script or part of a larger toolset. How to get the code: Get the code directly from Github https://github.com/arista-eosext/PortAutoDescription4 forks.11 stars.2 open issues.Recent commits: Update README.md, GitHub Add unix socket support, Philip DiLeo...
Continue reading →

Configuring LACP Fallback in EOS

posted on October 31, 2013 by

The LACP Fallback mode in Arista switches allows an active LACP interface to establish a port-channel (LAG) before it receives LACP PDUs from its peer. This feature is useful in environments where customers have Preboot Execution Environment (PXE) Servers connected with a LACP Port Channel to the switch.  Since PXE images are very small, many operating systems are unable to leverage LACP during the preboot process.  The server’s NICs do not have the capability to run LACP without the assistance of a fully functional OS; during the PXE process, they are unaware of the other NIC and don’t have a...
Continue reading →