The operating system for Arista switches is called the Extensible Operating System, or EOS for short. Arista describes EOS as “...the interface between the switch and the software that controls the switch and manages the network.” This is sort of like Apple’s OS X operating system, in that what you see is actually a Unix shell—Unix is doing all the heavy lifting behind the scenes. Arista switches run Unix natively, but to make them easier for nonprogrammers to understand, EOS makes them look more like traditional (Cisco) networking devices.
The word extensible means “capable of being extended.” EOS was designed from the ground up to allow third-party development of add-ons. This is a first in the networking world, and is a big departure from traditional proprietary operating systems. This extensibility is shown in detail in Chapters 11, 28, and 29.
Arista is a big believer in open standards, and there are no proprietary protocols found in EOS. Even features such as MLAG and VARP, both Arista developments, use behaviors found in existing open-standard protocols, the details of which we will see later in Chapters 12 and 14.
Perhaps even more impressively, Arista allows the user to access the underlying Linux operating system and to even write Python scripts that can control the switch. This is a significant difference from other vendors who advertise that their switches run a derivative of Linux. While those switches may be based on Linux, you can’t get to it, and all the power of Linux remains just out of your grasp, while you struggle with a new operating system that’s mostly like the one you’ve grown accustomed to.
On an Arista switch, the switch is running Linux. In fact, the switch is actually a Linux server with custom hardware that has a lot of interfaces. I’ll show you just how true that is in this book.
Some customers have even built their own interface to the switches, bypassing EOS altogether. Arista offers APIs for programmers toward this end, and even hosts a website where customers can share their ideas or scripts with other users. This website, entitled EOS Central, can be found at http://eos.aristanetworks.com/ (registration is required).
Arista switches have, at their heart, a database called SysDB. This database contains the state information and settings for the switch, organized in such a way that every module can access it with ease. What’s more, Arista allows developers to access SysDB so that they can create add-ons.
Traditional networking hardware uses a monolithic software architecture. This means that there is a pretty significant risk of a bug in one section of code affecting or even bringing down the entire device. Furthermore, updating one section of code can be difficult because there may be repercussions in other areas unforeseen by the developer.
Arista’s EOS is more modular. Not only does EOS separate the networking state from the processing, but drivers, processes, management, and even security patches run in user address space, not in the kernel. This means that any process can be restarted without affecting the state of the network that it controls. This also means that any module can be upgraded without affecting traffic flow. Modules can be added with ease, and faults are isolated to their individual user spaces. Should one process crash, it cannot affect the rest of the system. Should the process crash or lock up, the EOS process manager (ProcMgr) can restart it without affecting other modules, and without affecting the networking state. Since SysDB is just a database, and contains no application code, it is extremely reliable.
Since EOS is so modular, the drivers for the ASICs are merely modules. Because of this, EOS is the same for every switch Arista makes. There are no release trains, no hardware-specific downloads, and no hours wasted trying to find the right code. If you want EOS 4.7.7, you download the code named EOS-4.7.7.swi. If you have a 384-port 7508 chassis switch or a 24-port 7124 fixed-configuration switch, the software image is the same.
You can see this in action, though indirectly. When you first log in to an Arista switch, the first thing you
might do is issue the show run command.
Since even your CLI session is a process with its own user space,
the first time you issue the show run
command, the process must mount the SysDB database. That takes a second or
two, and you may notice the lag. After you get the output delivered, if
you execute the show run command again,
it delivers the output much faster because SysDB is already mounted. If
you disconnect and then connect again, you’ll spawn a new CLI process,
which must then mount SysDB once more.
In fact, if you’re impatient enough when first logging in and if you bang on the Enter key, you might be treated to the following message:
Arista-7124SX login: admin
waiting for mounts to complete ...ok
Arista-7124SX>Technically, this message may appear without banging on the Enter key, but I’ve never been patient enough for that to happen. What can I say? I’m a happy key masher.
Note
I’ve been informed that this message is actually being removed from future releases since it plays havoc with scripts.
If you’ve used a Cisco switch running IOS, you can use an Arista switch. As soon as you log into an Arista switch, you’ll recognize the look and feel—it’s very similar to Cisco’s IOS. The important distinction is that it is not IOS—the internals have been completely written from scratch—only the command-line interface (CLI) is similar.
Note
There is a joke in the industry that Arista does Cisco better than Cisco does. What they mean by this quip is that probably 90% of what you’re used to seeing on Cisco IOS is the same on Arista EOS—it’s just written better. Of course “better” is a subjective term, but consider this: if you’ve ever had to learn NX-OS after spending years on IOS, I can all but guarantee that migrating to EOS will be easier.
One of the things that frustrated me when I hooked up my first Arista switch was the fact that, by default, telnet is not enabled. In its default configuration, SSH is the only means allowed to remotely access EOS. Certainly console access is allowed, and telnet can be enabled, but in this time of PCI, Sarbanes-Oxley, and countless other security-centric requirements, keeping telnet disabled is a good idea.
For my examples, I’m connecting through the console (through a console server). Logging into EOS is as simple as it is with IOS:
Arista-1 login: admin
Last login: Wed Sep 28 14:40:14 on ttyS0
Arista-1>With only simple login authentication configured I am dropped
into EXEC mode, which should look pretty familiar. At
this point I can access Privileged EXEC mode with the
enable command:
Arista-1>enable
Arista-1#The prompt has changed as I’d expect it to, and I now have the power. At this point, I’ll add my own username because I like to be accountable for my actions. Actually, that’s a lie. I’m so lazy that I like to have the same username and password on every device I’ve ever configured so that I don’t have to remember them. OK, so that’s not true either, but I figured I’d configure a username just to show how the process of configuration works in EOS.
Again, this is just like IOS. I’ll configure from the terminal using
the config terminal command,
then configure my username, then exit:
Arista-1#conf t
Arista-1(config)#At this point, I am in global configuration mode:
Arista-1(config)#username GAD secret ILikePieArista-1(config)#exit Arista-1#exit Arista-1 login: Arista-1 login:GADPassword:ILikePieArista-1>enArista-1#
See? Just like IOS, even down to the behavior of truncated commands
being accepted, so long as they are not ambiguous. For example, while in
configuration mode, entering just ro
will not work because the CLI interpreter cannot figure out if I mean
route-map or router:
Arista-1(config)#ro
% Ambiguous commandI can, however, find out what commands are available in one of two ways. First, I can hit question mark. This will give me a list of available commands that match what I’ve entered so far:
Arista-1(config)#ro?
route-map routerI can also hit the Tab key, at which point the switch will respond with the longest match based on what I’ve typed so far:
Arista-1(config)#ro<TAB>
Arista-1(config)#routeNote that I did not type the word route; the switch inserted that via
autocompletion when I hit Tab. At this point I
decided that it’s the router command I
was looking for, so I added the r, and
then hit question mark. The switch then recognized that router is a command, and listed the possible
associated keywords:
Arista-1(config)#router ?
bgp Border Gateway Protocol
ospf Open Shortest Path First (OSPF)I chose one of these protocols, after which the switch put me into protocol specific mode, and altered the command line to show where I was:
Arista-1(config)#router ospf 100
Arista-1(config-router-ospf)#As with IOS, typing exit
(or its nonambiguous abbreviation) got me out of the current level and
popped me back up one level:
Arista-1(config-router-ospf)#ex
Arista-1(config)#Note
You don’t need to type exit. If you want to work in another mode, you can just type in the command and EOS will switch modes for you, assuming it can figure out the proper mode.
By typing end, or
Control-Z, I was able to exit configuration mode entirely:
Arista-1(config-router-ospf)#end
Arista-1#At this point I’d like to add that the EOS CLI recognizes some Emacs control characters. I am constantly amazed that even networking guys with decades of experience are unaware of these simple CLI key combinations. The following Control key combinations will have the effects listed:
Like IOS, entering the interface command, followed by the interface name, will put you into interface configuration mode. Interface configuration mode is similar to IOS, but more robust.
Note
Interfaces on Arista switches are all Ethernet, and are not named in
accordance with their speed or type. All Ethernet interfaces on a fixed
configuration switch have the name ethernet interface#
(the space is optional). Ethernet interfaces on modular switches have
the name, ethernet
slot#/interface#. For example, the first
interface on an Arista 7124 is
ethernet1, or e1 for short. The first interface in slot
number one of an Arista 7508 modular switch is ethernet 1/1 or e1/1.
Here, I’ve entered the interface configuration mode for ethernet 1:
Arista-1#conf tArista-1(config)#int e1Arista-1(config-if-Et1)#
Note
There is no need to enter the command config terminal (conf
t) in EOS. Old habits die hard, however, and I’ve been typing
that since 1989. Simply typing conf
works just as well.
One of the cool enhancements to EOS is that it has no interface range command like there is in IOS. To configure multiple interfaces at one time, simply enter them separated by either a hyphen (for a range) or a comma (for a list). Here I’ve entered configuration mode for the interfaces e1, e2, e3, and e10. I’ve included the first three as a range:
Arista-1(config)#int e1-3, e10
Arista-1(config-if-Et1-3,10)#Check out the command prompt. It doesn’t show just “range,” but rather shows what interfaces are being configured. I love this feature, because I can never remember what I typed a few short seconds ago. Be warned, though, that it can be a bit unwieldy with long lists of interfaces, since they will all show up in the command prompt:
Arista-1(config)#int e1,3,5,7,9,11,13,15,17,19Arista-1(config-if-Et1,3,5,7,9,11,13,15,17,19)# Arista-1(config-if-Et1,3,5,7,9,11,13,15,17,19)#description Odd Ports
Another nice feature of EOS is that I don’t have to exit
configuration mode to run exec mode commands. I just run them, and EOS
figures it all out. There is no do
command necessary with EOS:
Arista-1(config-if-Et1,3,5,7,9,11,13,15,17,19)#sho run | include Odd
description Odd Ports
description Odd Ports
description Odd Ports
description Odd Ports
description Odd Ports
description Odd Ports
description Odd Ports
description Odd Ports
description Odd Ports
description Odd PortsTechnically, any mode can run commands from any parent mode. If you enter commands from a different mode at the same level (interface- and protocol-specific mode, for example), then the mode will switch accordingly. You cannot, however, execute child mode commands from a parent mode. For example, you cannot execute interface-specific commands from within the global configuration mode.
Just like IOS, I was able to pipe the output of show
run to include, which only
outputs what I wanted to see. This behavior is similar to the grep command in Unix. There are a bunch of
options for piping in EOS, which you can see by entering | ? (vertical bar, question mark) after any
show command:
Arista-1#sho run | ?
LINE Filter command pipeline
append Append redirected output to URL
begin Begin with the line that matches
exclude Exclude lines that match
include Include lines that match
no-more Disable pagination for this command
nz Include only non-zero counters
redirect Redirect output to URL
tee Copy output to URLThough include is similar to
grep, it differs in a significant way.
This distinction is important when stacking pipes. The command sho int | inc Ethernet will output the
following:
Arista#sho int | inc Ethernet
Ethernet1 is down, line protocol is down (notconnect)
Hardware is Ethernet, address is 001c.7308.80af (bia 001c.7308.80af)
Ethernet2 is down, line protocol is down (notconnect)
Hardware is Ethernet, address is 001c.7308.80b0 (bia 001c.7308.80b0)
Ethernet3 is down, line protocol is down (notconnect)
Hardware is Ethernet, address is 001c.7308.80b1 (bia 001c.7308.80b1)
Ethernet4 is down, line protocol is down (notconnect)
Hardware is Ethernet, address is 001c.7308.80b2 (bia 001c.7308.80b2)
Ethernet5 is administratively down, line protocol is down (disabled)
Hardware is Ethernet, address is 001c.7308.80b3 (bia 001c.7308.80b3)
[--- output truncated ---]Now let’s say that I wanted to further filter that output, and only
include the lines that include the word Hardware. My
inclination would be to add another pipe with another include, like this:
sho int | inc Ethernet | inc Hardware.
The problem is, this doesn’t work:
Arista#sho int | inc Ethernet | inc Hardware
Arista#If I change my includes to
greps, then it works as I
desire:
Arista#sho int | grep Ethernet | grep Hardware
Hardware is Ethernet, address is 001c.7308.80af (bia 001c.7308.80af)
Hardware is Ethernet, address is 001c.7308.80b0 (bia 001c.7308.80b0)
Hardware is Ethernet, address is 001c.7308.80b1 (bia 001c.7308.80b1)
Hardware is Ethernet, address is 001c.7308.80b2 (bia 001c.7308.80b2)
Hardware is Ethernet, address is 001c.7308.80b3 (bia 001c.7308.80b3)
Hardware is Ethernet, address is 001c.7308.80b4 (bia 001c.7308.80b4)
Hardware is Ethernet, address is 001c.7308.80b5 (bia 001c.7308.80b5)So why does this happen? While include is part of the command-line interpreter,
grep is a Unix command. Piping is a
Unix function, so EOS behaves more like Unix when stacking pipes the
way I have.
Warning
Remember, Arista switches aren’t similar to Linux devices, they are Linux devices. If what you’re doing isn’t working the way you’d expect it to, try thinking in terms of a Linux OS. More often than not, you’ll find your answer in the way Linux works.
EOS runs a flavor of Linux, and many of the command behaviors
reflect that ancestry. For example, unlike IOS, by default there is no
pagination enabled in EOS when using the console. Therefore, when you
execute the show run command, the
output will scroll by until the entire running configuration has been
displayed. To paginate on the fly, pipe your output to more. Just like using more in Unix, this will pause the output after
the screen length (-1) has been met, at which point the prompt --more-- will be shown. At this point, user
input is required to continue. Hitting Enter or Return will result in the
advancement of a single line, while hitting the spacebar will show another
page. Hitting the letter q (or Q) or entering Control-C will break the
output and return you to the command prompt:
Arista-1#sho run | more
! device: Arista-1 (DCS-7124S, EOS-4.7.3-EFT1)
!
! boot system flash:/EOS-4.7.3-EFT.swi
!
no aaa root
!
username GAD secret 5 $1$S4ddK.QkzZdxfffJ$2yi.y.tqweS/9l.1
!
logging console debugging
!
hostname Arista-1
!
spanning-tree mode mstp
no spanning-tree vlan 4094
!
--More--Speaking of show running-config,
there’s a cool feature in EOS that will include all of the commands, even
the defaults that aren’t usually shown. This is done by including the all keyword, and can be done even when showing
parts of the config such as an interface. Let me show you what I mean.
Here’s the output from the command show run int
e24:
Arista#sho run int e24
interface Ethernet24
switchport access vlan 901
switchport mode trunkAnd here’s the output of the show run all
int e24 command, truncated for brevity. All of the commands you
see here are active; they’re just defaults, so they’re not usually
shown:
Arista#sho run all int e24
interface Ethernet24
no description
no shutdown
default load-interval
logging event link-status use-global
no dcbx mode
no mac-address
no link-debounce
no flowcontrol send
no flowcontrol receive
no speed
switchport access vlan 901
switchport trunk native vlan 1
switchport trunk allowed vlan 1-4094
switchport mode trunk
switchport mac address learning
no switchport private-vlan mapping
switchport
snmp trap link-status
no channel-group
lacp rate normal
lacp port-priority 32768
lldp transmit
lldp receive
no priority-flow-control
no priority-flow-control priority 0
no priority-flow-control priority 1
[-- output truncated --]Another cool function you can invoke while piping is the nz command. This will output only lines that
have values of nonzero. Let’s look at an example. Here we have the output
from the command show interface Ethernet
23:
Arista-1#sho int e23
Ethernet23 is up, line protocol is up (connected)
Hardware is Ethernet, address is 001c.7308.fa60 (bia 001c.7308.fa60)
MTU 9212 bytes, BW 10000000 Kbit
Full-duplex, 10Gb/s, auto negotiation: off
Last clearing of "show interface" counters never
5 minutes input rate 764 bps (0.0% with framing), 1 packets/sec
5 minutes output rate 579 bps (0.0% with framing), 1 packets/sec
76946 packets input, 6948712 bytes
Received 0 broadcasts, 4818 multicast
0 runts, 0 giants
0 input errors, 0 CRC, 0 alignment, 0 symbol
0 PAUSE input
44504 packets output, 5239033 bytes
Sent 2 broadcasts, 8423 multicast
0 output errors, 0 collisions
0 late collision, 0 deferred
0 PAUSE outputThe lines in bold within the output all show values of zero. Chances are, we don’t care about this information, so why not display the same output without those lines? As here:
Arista-1#sho int e23 | nz
Ethernet23 is up, line protocol is up (connected)
Hardware is Ethernet, address is 001c.7308.fa60 (bia 001c.7308.fa60)
MTU 9212 bytes, BW 10000000 Kbit
Full-duplex, 10Gb/s, auto negotiation: off
Last clearing of "show interface" counters never
5 minutes input rate 774 bps (0.0% with framing), 1 packets/sec
5 minutes output rate 577 bps (0.0% with framing), 1 packets/sec
76956 packets input, 6949720 bytes
Received 0 broadcasts, 4820 multicast
44508 packets output, 5239461 bytes
Sent 2 broadcasts, 8423 multicastThis output was taken a few seconds later, so some of the values have changed, but notice that the lines that were all zero before are no longer included.
This can be especially useful for commands like show interface counters, where by default there
could be pages of all zero counters:
Arista-1#sho int count
Port InOctets InUcastPkts InMcastPkts InBcastPkts
Et1 962378 0 6216 0
Et2 0 0 0 0
Et3 0 0 0 0
Et4 0 0 0 0
Et5 0 0 0 0
Et6 0 0 0 0
Et7 0 0 0 0
Et8 0 0 0 0
Et9 0 0 0 0
[--- output truncated ---]Here’s the same command piped through nz:
Arista-1#sho int count | nz
Port InOctets InUcastPkts InMcastPkts InBcastPkts
Et1 964901 0 6233 0
Et19 6628804 0 45236 0
Et20 6629197 0 45237 0
Et23 6991534 72572 4848 0
Et24 30532241 74169 8711 4844
Po1 37523065 146741 13554 4844
Po12 964645 0 6230 0
Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Et1 767462 0 4827 0
Et1 460815 0 2413 0
Et20 434283 0 2413 0
Et23 5271088 36301 8475 2
Et24 24998928 188576 4845 0
Po1 30269272 224877 13315 2
Po12 766888 0 4823 0Every line that contains all zero counters has been removed, and only the useful information remains.
When I first started using Arista switches, I had been using
Cisco Nexus switches for years, and the lack of the | last output modifier bugged me when using
commands like show log. Then I sat and
thought about what I knew about EOS and had a crazy idea. Remember earlier
in this chapter where I showed how we could pipe to the Unix grep command? It struck me that grep was not listed as one of the options when
piping:
SW1(config)#sho run | ?
LINE Filter command pipeline
append Append redirected output to URL
begin Begin with the line that matches
exclude Exclude lines that match
include Include lines that match
no-more Disable pagination for this command
nz Include only non-zero counters
redirect Redirect output to URL
tee Copy output to URLI reasoned that if I could pipe to one Unix command, I would
likely be able to pipe to others. The Unix command that would serve me
here is tail, so I cast caution to the
wind and went for it with all the vigor of a sleep-deprived nerd hell-bent
on discovery.
Here’s the output of the show
log command piped through more:
Arista#sho log | more
Syslog logging: enabled
Buffer logging: level debugging
Console logging: level errors
Trap logging: level informational
Sequence numbers: disabled
Syslog facility: local4
Hostname format: Hostname only
Facility Severity Effective Severity
-------------------- ------------- ------------------
aaa debugging debugging
acl debugging debugging
agent debugging debugging
bgp debugging debugging
clear debugging debugging
envmon debugging debugging
eth debugging debugging
extension debugging debugging
focalpoint debugging debugging
fru debugging debugging
fwk debugging debugging
hardware debugging debugging
igmpsnooping debugging debugging
--More—With bated breath, I entered my wicked conglomeration of EOS and Unix commands:
Arista#sho log | tail
May 18 18:12:04 Arista Fru: %FRU-6-FAN_INSERTED: Fan tray 4 has been
inserted
May 18 18:12:04 Arista Fru: %FRU-6-FAN_INSERTED: Fan tray 5 has been
inserted
May 18 18:12:09 Arista Ebra: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Ethernet11, changed state to up
May 18 18:12:09 Arista Ebra: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Ethernet10, changed state to up
May 18 18:12:11 Arista Lldp: %LLDP-5-NEIGHBOR_NEW: LLDP neighbor with
chassisId 001c.7308.80ae and portId "Ethernet11" added on interface
Ethernet10
May 18 18:12:11 Arista Lldp: %LLDP-5-NEIGHBOR_NEW: LLDP neighbor with
chassisId 001c.7308.80ae and portId "Ethernet10" added on interface
Ethernet11
May 18 18:14:01 Arista SuperServer: %SYS-5-SYSTEM_RESTARTED: System
restarted
May 18 18:20:40 Arista Cli: %SYS-5-CONFIG_I: Configured from console
by admin on con0 (0.0.0.0)
May 19 13:41:56 Arista Fru: %FRU-6-TRANSCEIVER_REMOVED: The
transceiver for interface Ethernet24 has been removed
May 19 13:42:08 Arista Fru: %FRU-6-TRANSCEIVER_INSERTED: A
transceiver for interface Ethernet24 has been inserted.
manufacturer: Arista Networks model: SFP-1G-SX part number
SFP-1G-SX rev 0002 serial number XCW1036QH081Holy crap! It worked! Such was my enthusiasm that my wife came into my home office at 2 a.m. and told me to go to bed, or at least keep it down. I suppose I should be lucky to have a wife, being a guy who finds the ability to mix EOS and Unix commands exciting.
As previously discussed, Unix pipes can even be stacked:
Arista#sho log | tail | grep FAN
May 18 18:12:04 Arista Fru: %FRU-6-FAN_INSERTED:
Fan tray 4 has been inserted
May 18 18:12:04 Arista Fru: %FRU-6-FAN_INSERTED:
Fan tray 5 has been insertedWhy stop at two? Now that my wife had left me to my late night spell casting, I ventured down the rabbit hole. How about adding some redirection?
Arista#sho log | tail | grep FAN > /mount/flash/GAD.txtBecause tail is a Unix command, we must specify
the full path to get to the flash drive. You’ll see what happens if you
don’t in Chapter 9.
Now, my GAD.txt file is stored on the flash
drive, and can be seen with the dir
command from EOS:
Arista#dir
Directory of flash:/
-rwx 225217184 Apr 16 05:38 EOS-4.8.1.swi
-rwx 245827739 Apr 16 11:19 EOS-4.9.1.swi
-rwx 248665992 May 12 22:36 EOS-4.9.3.swi
-rwx 127 May 17 02:16 GAD
-rwx 156 May 21 20:40 GAD.txt
-rwx 137 May 18 18:20 boot-config
drwx 4096 May 18 18:11 debug
drwx 4096 May 18 18:11 persist
drwx 4096 May 17 02:27 schedule
-rwx 1351 May 18 18:20 startup-config
-rwx 0 May 14 23:46 zerotouch-config