Chapter 33. Aristacisms
This chapter is an appendix of sorts, but it’s not really, because some of the content comprises items that I felt should be included in the book, but weren’t long enough to warrant their own chapter, whereas other items are just Arista-specific terms or nuances that I felt should be included but didn’t fit in any other chapter. This chapter is like the trash bin in my brain. I took a lot of notes for topics to put in this book, and this is the stuff that’s left over or didn’t make it into other chapters.
It is with great pleasure that a writer makes up his own words, and because I’ve been writing for a year and this is the last chapter, I’m a little punchy. I do hereby dub the items in this chapter, Aristacisms.
Arista-Specific Configuration Items
Although Arista’s Extensible Operating System (EOS) is a decidedly open source platform, there are some things that are configured differently on an Arista switch than on other vendor’s switches. This is my repository for such items that don’t warrant their own chapters.
There Is No Duplex Statement in EOS
I learned this the hard way when I tried to import 20 or so Cisco switch configurations into my client’s shiny new Arista switches. Many of the ports had hardcoded speed and duplex settings (which I quickly scolded them for; read Chapter 3 in Network Warrior if you don’t know why). Every one of these entries failed when I pasted them into EOS. Here’s what happened when I tried:
SW1(config-if-Et5)#Speed 1000 % Invalid input SW1(config-if-Et5)#Duplex full % Invalid input
Flummoxed, I scrambled around quickly within EOS until I discovered that the speed command is supported (duplex is not), but it works in a very different fashion than that which I was used to.
On a 7050TX switch (48-port copper with four Quad Small Form-Factor Pluggables [QSFPs]), the following options are available for the interface speed command:
7050TX(config-if-Et33)#speed ? 100full Disable autoneg and force 100 Mbps/full duplex operation 10full Disable autoneg and force 10 Mbps/full duplex operation auto Enable autoneg for speed, duplex, and flowcontrol forced Disable autoneg and force speed/duplex/flowcontrol sfp-1000baset Configure autoneg and speed/duplex on 1000BASE-T SFP 7050TX(config-if-Et33)#speed forced ? 10000full Disable autoneg and force 10 Gbps/full duplex operation 1000full Disable autoneg and force 1 Gbps/full duplex operation 1000half Disable autoneg and force 1 Gbps/half duplex operation 100full Disable autoneg and force 100 Mbps/full duplex operation 100gfull Disable autoneg and force 100 Gbps/full duplex operation 100half Disable autoneg and force 100 Mbps/half duplex operation 10full Disable autoneg and force 10 Mbps/full duplex operation 10half Disable autoneg and force 10 Mbps/half duplex operation 25gfull Disable autoneg and force 25 Gbps/full duplex operation 40gfull Disable autoneg and force 40 Gbps/full duplex operation 50gfull Disable autoneg and force 50 Gbps/full duplex operation
Resisting the urge to configure the port for 50 Gbps/full duplex, I used the following command to result in a hardcoded 1 Gbps/full duplex interface:
7050TX(config-if-Et2)#speed forced 1000full
Even though much of the configuration can be cut and pasted from other vendors’ switches, beware of speed and duplex when they’re hardcoded. Better yet, convince the server guys to stop hardcoding gigabit interfaces.
Watch Out for Those Comments!
One of my favorite features of EOS is the ability to put comments in the configuration. As you’ve no doubt seen by now, when a comment is allowed, I’ll jam one in there. Blame my obsessive nature and my college professor who insisted on well-commented code while I was programming COBOL on punch cards in 1984. Ooh, 80s flashback time!
Anyway, another case of pasting configurations from an IOS device bit me in the ass when, after a few days, I got a call about one of the ports on the new Arista switches not working. After digging in, one of the guys on the team discovered this configured on the port:
interface Ethernet25 ! interface Ethernet26 ! ! interface Ethernet28 description Server11 switchport access vlan 11 spanning-tree portfast ! interface Ethernet27 ! interface Ethernet28 !
Anything look wrong there to you?
This is the relevant snippet of what was actually pasted:
interface Ethernet26 description Server10 switchport access vlan 10 spanning-tree portfast ! interface Ethernet28 description Server11 switchport access vlan 11 spanning-tree portfast !
When I pasted the configuration, I did so with a console cable, and, apparently, I pasted too much, which caused the serial port buffer to overrun. That caused a glitch, which caused a carriage return to be missed, which caused the line containing the command interface Ethernet28 to be considered part of the comment line before it. Because interfaces can include comments, it just took that line as a comment on the previously configured interface (I had removed all empty interfaces to make the cut/paste job go more quickly). As a result, this is what the command parser saw, which resulted in the configuration shown previously:
interface Ethernet26 description Server10 switchport access vlan 10 spanning-tree portfast ! !interface Ethernet28 description Server11 switchport access vlan 11 spanning-tree portfast
When pasting configurations from one switch into another, verify what you’ve pasted. If possible, don’t use a console cable. And whatever you do, watch out for those comments!
The cool thing that I learned from all this was that I could put comments into interface configurations, so now I can annoy my clients with interface descriptions and comments!
Some Routing Protocols Are Shut Down by Default
When you configure a simple Routing Information Protocol (RIP) configuration, before you spend hours trying to figure out why it doesn’t work, issue the show active command. You’ll promptly discover that RIP is in a shutdown state by default:
SW1(config-router-rip)#sho active router rip ! - RIPv2 link to R1 network 10.0.0.1/32 shutdown
Clearly, even the switch thinks you should use something else, but if you’re hell-bent on using RIP, negating the shutdown command will bring up RIP:
SW1(config-router-rip)#no shut
Honestly, by the time most of you will read this, we’ll be into the 2020s, so I think it’s time to stop using RIP.
Trunk Groups
Trunk groups are mentioned in the Multichassis Link Aggregation (MLAG) chapter (Chapter 18), but they’re worth another mention here because they’re pretty darn cool. Here’s what the EOS 4.21.3F configuration guide has to say about them:
A trunk group is the set of physical interfaces that comprise the trunk and the collection of VLANs whose traffic is carried on the trunk. The traffic of a VLAN that belongs to one or more trunk groups is carried only on ports that are members of trunk groups to which the VLAN belongs, i.e., VLANs configured in a trunk group are pruned of all ports that are not associated with the trunk group.
I just love paragraphs like that in official documentation. They drive people to buy O’Reilly books.
A trunk group is a named group of VLANs with an added twist. Let’s look at the potential for such a tool. We’ve already seen it in use for the MLAG peer, but let’s try some other ways to use it. Here, I configure the range of VLANs 100 through 105 and then include them all in the trunk group Leelu:
Arista(config)#vlan 100-105 Arista(config-vlan-100-105)#trunk group Leelu
Now I’ll go to interface e10, configure it as a trunk, and apply the trunk group Servers to that interface:
Arista(config-vlan-100-105)#int e1 Arista(config-if-Et1)#switchport mode trunk
Remember that, by default, all VLANs are included on trunks, but if we look at the output of show vlan, Ethernet1 is not active for these VLANs:
Arista(config-if-Et1)#sho vlan VLAN Name Status Ports ----- -------------------------------- --------- ------------------------------- 1 default active Et1 100 VLAN0100 active 101 VLAN0101 active 102 VLAN0102 active 103 VLAN0103 active 104 VLAN0104 active 105 VLAN0105 active
If we want the VLANs in a trunk group to be included on a trunk, we must add that trunk group to the interfaces in question:
Arista(config-if-Et1)#switchport trunk group Leelu
Now, the output of show vlan shows that all of these VLANs are active on the trunk port (ethernet 1):
Arista(config-if-Et1)#sho vlan VLAN Name Status Ports ----- -------------------------------- --------- ------------------------------- 1 default active Et1 100 VLAN0100 active Et1 101 VLAN0101 active Et1 102 VLAN0102 active Et1 103 VLAN0103 active Et1 104 VLAN0104 active Et1 105 VLAN0105 active Et1
Even though the ability to group VLANs like that is pretty cool, there’s more to it than that. When a VLAN is added to a trunk group, trunk ports must include that trunk group in order to pass that VLAN! Using the same interface, I add the switchport trunk allowed vlan command and then remove the switchport trunk allowed vlan command:
Arista(config-if-Et1)#switchport trunk allowed vlan 100-105 Arista(config-if-Et1)#no switchport trunk group Leelu
From experience, VLANs 100 through 105 should now be included on the e1 trunk, but the output of the show vlan command tells a different story:
Arista(config-if-Et1)#sho vlan VLAN Name Status Ports ----- -------------------------------- --------- ------------------------------- 1 default active 100 VLAN0100 active 101 VLAN0101 active 102 VLAN0102 active 103 VLAN0103 active 104 VLAN0104 active 105 VLAN0105 active
To make matters worse, if you’re not careful, you’ll convince yourself that it should be working by looking at the output of the show interface trunk command:
Arista(config-if-Et1)#sho int trunk Port Mode Status Native vlan Et1 trunk trunking 1 Po1 trunk trunking 1 Po1000 trunk trunking 1 Port Vlans allowed Et1 100-105 Po1 All Po1000 All Port Vlans allowed and active in management domain Et1 None Po1 None Po1000 None Port Vlans in spanning tree forwarding state Et1 None Po1 None Po1000 None
Take a look at the lines in bold in the previous output. It clearly says that VLANs 100 through 105 are allowed! The key is that they’re not allowed and active in the management domain (next paragraph in the output). This is due to the fact that these VLANs are configured in a trunk group.
Warning
You might be tempted to use the trunk group command as sort of a macro for a list of VLANs, and you can, but if you do that, the VLANs will be included in a trunk only if you use the trunk group. You can no longer include even one of the referenced VLANs in a trunk without using the trunk group. Think of this feature more as a way of securing VLANs from use as opposed to a way to make configurations simpler.
The good news is that VLANs can belong to more than one trunk group! This means that if we wanted to include only VLAN 101 on interface e11, we could do so by adding a new trunk group to VLAN 101 and then applying that trunk group to the interface. Let’s try that.
First, I remove the trunk allowed stuff that wasn’t working anyway:
Arista(config-if-Et1)#no switchport trunk allowed vlan 100-105
Now, I go to VLAN 101 and add a new trunk group. Remember, this VLAN is already part of trunk group Servers:
Arista(config-if-Et1)#vlan 101 Arista(config-vlan-101)#trunk group Multipass
At this point, VLAN 101 belongs to two trunk groups, Leelu and Multipass:
Arista(config-vlan-101)#int e31 Arista(config-if-Et31)#switchport mode trunk Arista(config-if-Et31)#switchport trunk group Multipass
Now the output of show vlan is more to my liking:
Arista(config-if-Et31)#sho vlan VLAN Name Status Ports ----- -------------------------------- --------- ------------------------------- 1 default active Et1, Et31 100 VLAN0100 active 101 VLAN0101 active Et31 102 VLAN0102 active 103 VLAN0103 active 104 VLAN0104 active 105 VLAN0105 active
You can also show what VLANs belong to what trunk groups by using the show vlan trunk group command:
Arista#sho vlan trunk group VLAN Trunk Groups ---- ---------------------------------------------------------------------- 1 100 Leelu 101 Leelu, Multipass 102 Leelu 103 Leelu 104 Leelu 105 Leelu
Virtual Routing and Forwarding
EOS supports Virtual Routing and Forwarding (VRF) instances. VRFs are essentially multiple copies of the routing table that allow the same IP space to exist more than once in a single switch. Although Arista does support routing within the VRFs, it does not support something called route leaking or routing between VRFs.
Note
As this book is nearing its finishing stages, route leaking has been announced and is being supported in upcoming releases. Additionally, the structure of VRFs has changed such that the number of them supported is limited by memory and not the Application-Specific Integrated Circuits (ASIC) type.
You need to define VRFs by using the vrf definition vrf-name command mode. Although I’m not of fan of naming VRFs after colors, everyone does it, so I’m going to conform. Mostly.
Arista(config)#vrf definition PlumCrazy Arista(config-vrf-PlumCrazy)#
The only thing that needs to be done here is to define a route distinguisher. VRFs in EOS work through something called network namespaces in Linux. This is a nifty operating system feature that is beyond the scope of this book, so I’ll just let you know that the route distinguisher comprises two numbers separated by a colon (if you’d like to read up on how this really works, check out its page on the Arista website):
Arista(config-vrf-PlumCrazy)#rd ? <admin>:<local assignment> Route Distinguisher Arista(config-vrf-PlumCrazy)#rd 100:1 Arista(config-vrf-PlumCrazy)#
Note
This behavior has also changed in the latest revisions of EOS, and route discriminators may no longer be required when creating VRFs.
Because more VRFs equals more fun, let’s add two more:
Arista(config-vrf-PlumCrazy)#vrf definition SubLime Arista(config-vrf-SubLime)#rd 100:2 Arista(config-vrf-SubLime)#vrf definition ToxicOrange Arista(config-vrf-ToxicOrange)#rd 100:3
Now that the VRFs are defined, we can apply them to interfaces. On this first interface I do what I do every single time and apply the IP address first:
Arista(config)#int vlan 101 Arista(config-if-Vl101)#ip address 11.0.0.2/24 Arista(config-if-Vl101)#vrf forwarding PlumCrazy ! Interface Vlan101 IP address 11.0.0.1 removed due to enabling VRF PlumCrazy Arista(config-if-Vl101)#
That’s sort of a drag, but necessary I assume. No matter, I’ll just reapply the IP address and all is well. Be prepared for this, because it will always remove the IP address if there’s one assigned. It will also do this if you change or remove the VRF.
Arista(config-if-Vl101)#ip address 11.0.0.2/24
With that done, I need to add a default route for the new VRF. Routing is not permitted in the nondefault VRF, so all I can add is a static route, which is fine for management:
Arista(config)#ip route vrf PlumCrazy 0/0 11.0.0.1
Check out how I can add the same IP address to other interfaces in other VRFs. I can also add the same default route in each VRF:
Arista(config)#int vlan 102 Arista(config-if-Vl102)#vrf forwarding SubLime Arista(config-if-Vl102)#ip address 11.0.0.2/24 Arista(config-if-Vl102)#ip route vrf SubLime 0/0 11.0.0.1 Arista(config)#int vlan 103 Arista(config-if-Vl103)#vrf forwarding ToxicOrange Arista(config-if-Vl103)#ip address 11.0.0.2/24 Arista(config-if-Vl103)#ip route vrf ToxicOrange 0/0 11.0.0.1 Arista(config)#
To show how it all works, here’s the default routing table with the default route in bold. Note the first line of the output that states VRF name: default:
Arista#sho ip route
VRF name: default
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - ISIS level 1, I L2 - ISIS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service
Gateway of last resort is not set
C 10.0.0.0/24 is directly connected, Management1
Here’s the routing table for the other VRFs I created, with the different default route:
Arista#sho ip route vrf PlumCrazy
VRF name: PlumCrazy
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - ISIS level 1, I L2 - ISIS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service
Gateway of last resort:
S 0.0.0.0/0 [1/0] via 11.0.0.1, Vlan101
C 11.0.0.0/24 is directly connected, Vlan101
! IP routing not enabled
Crap! That’s another mistake I make every single time: IP routing must be enabled on a per-VRF basis.
Arista(config)#ip routing vrf PlumCrazy Arista(config)#ip routing vrf SubLime Arista(config)#ip routing vrf ToxicOrange
Now let’s see how the routing tables look. You can view them all by using the sho ip route vrf all command:
Arista(config)#sho ip route vrf all
VRF name: default
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - ISIS level 1, I L2 - ISIS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service
Gateway of last resort is not set
C 10.0.0.0/24 is directly connected, Management1
VRF name: PlumCrazy
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - ISIS level 1, I L2 - ISIS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service
Gateway of last resort:
S 0.0.0.0/0 [1/0] via 11.0.0.1, Vlan101
C 11.0.0.0/24 is directly connected, Vlan101
VRF name: SubLime
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
[-- output truncated --]
With VRFs in place, I can ping using the vrf vrf-name keywords inserted directly after the ping command. I prefer the Cisco method that puts the VRF keyword at the end, because I constantly make this mistake, and just adding another keyword at the end is easier than inserting it into the middle of a command. But, after a few times of making the mistake, I’ve learned to adapt:
Arista#ping vrf PlumCrazy 11.0.0.1 PING 11.0.0.1 (11.0.0.1) 72(100) bytes of data. 80 bytes from 11.0.0.1: icmp_req=1 ttl=255 time=4.79 ms 80 bytes from 11.0.0.1: icmp_req=2 ttl=255 time=1.06 ms 80 bytes from 11.0.0.1: icmp_req=3 ttl=255 time=1.29 ms 80 bytes from 11.0.0.1: icmp_req=4 ttl=255 time=1.34 ms 80 bytes from 11.0.0.1: icmp_req=5 ttl=255 time=1.50 ms --- 11.0.0.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 17ms rtt min/avg/max/mdev = 1.069/2.001/4.791/1.402 ms, ipg/ewma 4.254/3.357 ms
When adding a VRF, the behavior of some common services changes a bit. For the most part, this involves the limitation that they can reside in only one VRF. Not surprisingly, these services are all related to management of the switch. Examples include Simple Network Management Protocol (SNMP), Syslog, TACACS+, Network Time Protocol (NTP), and DNS, all of which you should configure to work within the management VRF.
Configuring these services is simply a matter of adding the vrf vrf-name to the command, again, right after the command itself (not at the end). If you’ve previously configured these services, you will be greeted with a message similar to the following when configuring them for the new VRF:
Arista(config)#ip name-server 10.0.0.100 Arista(config)#ip name-server vrf PlumCrazy 11.0.0.100 % Nameservers are supported in only one VRF at a time. Please unconfigure nameservers from Main VRF before continuing.
After you remove the other name servers, the VRF-enabled version no longer gives a warning:
Arista(config)#no ip name-server 10.0.0.100 Arista(config)#ip name-server vrf PlumCrazy 11.0.0.100 Arista(config)#
This is a great solution for switches that might reside in a customer’s network but need to be managed from within the data center’s management scheme.
Open Flow and Direct Flow
Open Flow is the ability for certain Arista switches to have their forwarding tables programmed remotely. Direct Flow is the same thing, but configurable through the command-line interface (CLI) on the switch itself. A clever application of this technology is the Direct Flow Assist Solution brief. This basically allows the Palo Alto firewall to tell the Arista switch that a flow is allowed and thus offloads the traffic to the switch so that it can traverse the network more quickly and without the added latency that the firewall incurs. Open Flow and Direct Flow are hardware features and are thus only supported on certain hardware.
Macro-Segmentation Service
Macro-Segmentation Service (MSS) is the ability to program a supported firewall into the network wherever you want. Using a combination of CloudVision, Direct Flow, Virtual eXtensible Local Area Network (VXLAN), and some very clever thinking, MSS allows the ability to basically place a firewall logically in a way that would have caused physical redesigns, outages, and additional expense in a traditional network.
And, Finally...
Because you wouldn’t believe me unless I showed you myself, here is the version I’m running first:
Arista#sho ver | inc Software Software image version: 4.21.1F
For your Arista CLI enjoyment:
Arista#sho donkeys
Farm utilization for 5 seconds: 0%/0%; 1 minute: 0%; 5 minutes: 0%
DID S Ty DC Runtime(ms) Rides Poops Hay DKY Donkeyname
1 M sp 602F3AF0 0 1627 0 2600/3000 0 Eeyore
2 F we 60C5BE00 4 136 29 5572/6000 0 Tingaleo
3 F st 602D90F8 1676 837 2002 5740/6000 0 Daisy
4 M we 602D08F8 0 1 0 5568/6000 0 Wonky Don
5 F we 602DF0E8 0 1 0 5592/6000 0 Dakota
6 M st 60251E38 0 2 0 5560/6000 0 Superdonkey
7 M we 600D4940 0 2 0 5568/6000 0 Cookie Dough
8 F we 6034B718 0 1 0 2584/3000 0 Sandy
9 F we 603FA3C8 0 1 0 5612/6000 0 Kekie
10 M we 603FA1A0 0 8124 0 5488/6000 0 Shrek
11 M we 603FA220 0 9 0 4884/6000 0 BillyJoe-Bob
12 U we 60406818 124 2003 61 5300/6000 0 Smokey
13 M we 60581638 0 1 0 5760/6000 0 Snickers
14 M we 605E3D00 0 2 0 5564/6000 0 D.K.
15 M we 605FC6B8 0 2 011568/12000 0 Hee-Haw
/ /
( \ // )
\ // /
\_\||||//_/
/ _ _
/|(o)(O)|
/ | |
___________________/ /
// // |____| Cluck cluck cluck!
// || /
//| | 0 0 /
// ) V / \____/
// / ( /
"" /_________| |_/
/ / / | ||
/ / / / ||
| | | | | ||
| | | | | ||
|_| |_| |_||
\_ \_ \_\
It works on every version I’ve tried it on, as does show chickens. show farm shows them both (they’re technically different)! But wait, there’s more! Check out what happens if you run show elephants:
Arista#show elephants % Internal error % To see the details of this error, run the command 'show error 0' Arista#
Uh-oh! I broke it! Better check out that error:
Arista#sho error 0
Command: show elephants
=============== Exception raised in 'Cli [interac -d -i --dlopen
-p -f -l libLoadDynamicLibs.so procmgr libProcMgrSetup.so
--daemonize ' (PID 4951; PPID 4950) ===============
Local variables by frame (innermost frame last):
[-- much scary output removed because it's scary --]
File "/usr/lib/python2.7/site-packages/BasicCli.py", line 2107,
in runShowCommand
result = valueFunction( mode, **kwargs )
File "/usr/lib/python2.7/site-packages/CliPlugin/DonkeyCli.py",
line 103, in showElephants
''' )
ScaredyException:
( ____ .-.
.-""-. .'` _ `'-,//`|-.
/ ,-'-.`. | `. ( `
| ` `.)
| \_@ .=` |
| / .=
| / |
| . ,____ ==; |
__.-;.__. '--'`"-, | |
`"` / _ '=| |
| _.' \_) / /
| ( _ '=_.' |
.-`` `---'` | _
| = , , / ,_())
) `| \__.-'` / ' / .--.
/` |nnn / / =/ (
jgs / ;""""`nn| ( \_ )
(nnn__.' '-nnn-' _( |`
`"""`
Try that on another vendor’s switch! Why do these commands exist? That’s not for me to say, but I love them.
Conclusion
Hopefully, after all these pages, you have the same sense of how great Arista is as I do. It’s a great place to work, it has great people at all levels who make and support great products, and it is fun in a way that permits things like show elephants to remain in the code. After almost 10 years of exposure and more than six years of employment, I can honestly say that Arista is still the best and most innovative networking company I’ve ever been exposed to.
I wrote the first edition of Arista Warrior because the company and the technology blew me away. I wrote the second edition for the same reasons. I’m excited to see what Arista produces over the next few years to warrant a third.