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, while 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 since 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.
When first learning about any new product or vendor, getting to know the lingo can be a challenge. Arista doesn’t have many of these terms, probably because they are very pro open source. There are a few that I’ve stumbled over, so I made a short list and they ended up here.
- Advanced Event Management (AEM)
According to the press release on the topic, AEM is a “suite of new capabilities in Arista’s Extensible Operating System, the world’s most advanced network operating system, that enables increased and unprecedented levels of network automation while improving overall system uptime.” Man, if that doesn’t get the marketing guys excited, I don’t know what would! But what does all that really mean?
AEM includes the following features, referenced together as a group: event-handler, Event Monitor, the ability to use bash (Linux tools), and the CLI Scheduler. To be fair, these tools grouped together are a huge part of what makes Arista switches so amazing, so I can’t fault the marketing team for trying to make some noise about them.
- Spine and Leaf Switches
Much of the Arista documentation talks about spine switches and leaf switches. In its simplest deployment, a spine switch is a core device, and a leaf switch is an access device. The spine and leaf design paradigm is more or less a collapsed core network design, and although I’d love to pick on the marketing guys for making up new terms needlessly, the reality is that the old terms don’t necessarily make sense any more.
Many data centers don’t have distribution layers anymore, instead opting for a wider design with multiple interlinked “cores,” with all of the access switches connecting directly to them. Since there’s no real “center” to a network like this, it doesn’t make sense to call them core switches. When and if new networking protocols like TRILL take off, the spine and leaf paradigm will become a lot more commonplace.
Although 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.
I learned this the hard way when I tried to import 20 or so Cisco switch configs 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 [Autonegotiation] 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 7048T (48-port copper 1 Gbs) switch, the following options
are available for the interface speed
command:
Arista-7048T(config-if-Et2)#speed ?
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 SFPSince the servers were hardcoded (grr), and I wasn’t using
copper SFPs, I needed to use the forced keyword. Using the forced keyword results in the following
additional options:
Arista-7048T(config-if-Et2)#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
40gfull Disable autoneg and force 40 Gbps/full duplex operationResisting the urge to configure the port for 40 Gbps/full duplex, I used the following command to result in a hardcoded 1,000 Gbps/full duplex interface:
Arista-7048T(config-if-Et2)#speed forced 1000fullWhile much of the configuration can be cut and pasted from a Cisco IOS switch into EOS, beware of speed and duplex when they’re hardcoded. Better yet, convince the server guys to stop hardcoding gigabit interfaces.
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 configs 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 configs 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!
I covered this in the routing chapter, but it’s worth
another mention. When you configure a simple 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
shutdownClearly, 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 shutTrunk groups are mentioned in the MLAG chapter (Chapter 12), but they’re worth another mention since they’re pretty darn cool. Here’s what the EOS 4.9.4 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 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 see it in use for the MLAG peer, but let’s try some other ways to use it. Here I’ll configure the range of VLANs 100 through 105, and then include them all in the trunk group Leelu:
SW1(config)#vlan 100-105SW1(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:
SW1(config-vlan-100-105)#int e10SW1(config-if-Et10)#switchport mode trunkSW1(config-if-Et10)#switchport trunk group Leelu
Now, the output of show vlan shows that all of
these VLANs are active on the trunk port e10:
SW1(config-if-Et10)#sho vlan
VLAN Name Status Ports
----- -------------------------------- --------- -------------------------------
1 default active Et10
100 VLAN0100 active Et10
101 VLAN0101 active Et10
102 VLAN0102 active Et10
103 VLAN0103 active Et10
104 VLAN0104 active Et10
105 VLAN0105 active Et10
200 VLAN0200 active Et10While 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! Let me show you what I mean. I’ll configure the same VLANs to be
allowed on a trunk port configured on e11, only this time I’ll use the
traditional method of limiting and allowing VLANs on a trunk port by
using the switchport trunk allowed
vlan command:
SW1(config-if-Et10)#int e11SW1(config-if-Et11)#switchport mode trunkSW1(config-if-Et11)#switchport trunk allowed vlan 100-105
From experience, VLANs 100 through 105 should now be included
on the e11 trunks, but the output of the show
vlan command tells a different story:
SW1(config-if-Et11)#sho vlan
VLAN Name Status Ports
----- -------------------------------- --------- -------------------------------
1 default active Et10
100 VLAN0100 active Et10
101 VLAN0101 active Et10
102 VLAN0102 active Et10
103 VLAN0103 active Et10
104 VLAN0104 active Et10
105 VLAN0105 active Et10
200 VLAN0200 active Et10To 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:
SW1(config-if-Et11)#sho int trunk
Port Mode Status Native vlan
Et5 trunk trunking 1
Et6 trunk trunking 1
Et10 trunk trunking 1
Et11 trunk trunking 1
Port Vlans allowed
Et5 All
Et6 All
Et10 All
Et11 100-105
Port Vlans allowed and active in management domain
Et5 None
Et6 None
Et10 1,100-105,200
Et11 None
Port Vlans in spanning tree forwarding state
Et5 None
Et6 None
Et10 1,100-105,200
Et11 NoneTake 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 may 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 only be
included in a trunk 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! That 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’ll remove the trunk
allowed stuff that wasn’t working anyway:
SW1(config-if-Et11)#no switchport trunk allowed vlan 100-105Now, I’ll go to VLAN 101 and add a new trunk group. Remember, this VLAN is already part of trunk group Servers:
SW1(config-if-Et11)#vlan 101SW1(config-vlan-101)#trunk group Multipass
At this point, VLAN 101 belongs to two trunk groups, Leelu and Multipass:
SW1(config-vlan-101)#int e11SW1(config-if-Et11)#switchport trunk group Multipass
Now the output of show vlan is more to my
liking:
SW1(config-vlan-101)#sho vlan
VLAN Name Status Ports
----- -------------------------------- --------- ---------------------
1 default active Et10, Et11
100 VLAN0100 active Et10
101 VLAN0101 active Et10, Et11
102 VLAN0102 active Et10
103 VLAN0103 active Et10
104 VLAN0104 active Et10
105 VLAN0105 active Et10You can also show what VLANs belong to what trunk groups with
the show vlan trunk group command:
SW1#sho vlan trunk group
VLAN Trunk Groups
---- -------------------------------------------------------------
1
100 Leelu
101 Leelu, Multipass
102 Leelu
103 Leelu
104 Leelu
105 LeeluEOS Version 4.10 supports a Virtual Routing and Forwarding (VRF) instance for management. VRFs are essentially multiple copies of the routing table that allow the same IP space to exist more than once in a single switch. Sadly, the way this feature has so far been implemented only allows the management VRF to be used on an SVI, and not on the physical management interface. Still, it’s a very cool feature if you do your management in-band on SVIs.
There can be only one additional nondefault VRF configured at this time (EOS v4.10). I’ll configure one called management.
First, the VRF needs to be defined using the vrf definition
vrf-name command mode:
Arista(config)#vrf definition managementThe 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 very cool feature that is beyond the scope of this book, so since there can only be one nondefault VRF anyway, I’ll just use the one included in the Arista EOS 4.10 documentation and not worry about the details. If you’d like to read up on how this really works, check out its page on the Arista website. The route distinguisher is comprised of two numbers separated by a colon:
Arista(config-vrf-management)#rd ?<admin>:<local assignment> Route Distinguisher Arista(config-vrf-management)#rd 101:1
Now that the VRF is defined, we can apply it to an interface. I’ll be using VLAN 901’s SVI. First, here’s the existing configuration from when I had the SVI set up for management without a VRF:
Arista(config)#sho run int vlan 901
interface Vlan901
ip address 192.168.1.188/24Now I’ll go ahead and assign the VRF to the interface:
Arista(config)#int vlan 901Arista(config-if-Vl901)#vrf forwarding managementInterface Vlan901 IP address 192.168.1.188 removed due to enabling VRF management
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:
Arista(config-if-Vl901)#ip address 192.168.1.188/24With 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 management 0/0 192.168.1.1To show how it all works, here’s the default routing table with the default route in bold:
Arista(config)#sho ip route | beg Gateway
Gateway of last resort:
S 0.0.0.0/0 [1/0] via 20.0.0.2
C 20.0.0.0/30 is directly connected, Ethernet2
C 50.50.50.0/24 is directly connected, Vlan101Here’s the routing table for the management VRF I created, with the different default route (and the warning about routing) in bold:
Arista(config)#sho ip route vrf management | beg Gateway
Gateway of last resort:
S 0.0.0.0/0 [1/0] via 192.168.1.1
C 192.168.1.0/24 is directly connected, Vlan901
! IP routing not enabledWith the VRF 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(config)#ping vrf management 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 72(100) bytes of data.
80 bytes from 192.168.1.1: icmp_req=1 ttl=255 time=4.79 ms
80 bytes from 192.168.1.1: icmp_req=2 ttl=255 time=1.06 ms
80 bytes from 192.168.1.1: icmp_req=3 ttl=255 time=1.29 ms
80 bytes from 192.168.1.1: icmp_req=4 ttl=255 time=1.34 ms
80 bytes from 192.168.1.1: icmp_req=5 ttl=255 time=1.50 ms
--- 192.168.1.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 msWhen adding a VRF, the behavior of some common services changes a bit. For the most part, this involves the limitation that they can only reside in one VRF. Not surprisingly, these services are all related to management of the switch. Examples include SNMP, Syslog, TACACS+, NTP, and DNS, all of which should be configured to work within the management VRF.
Note
Though future versions of EOS will likely support multiple VRFs, for now only one nondefault VRF is supported, and it’s really designed for in-band management. Hence the limitations, which really aren’t that big of a deal.
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, then you will be greeted with a
message similar to the following when configuring them for the new
VRF:
Arista(config)#ip name-server vrf management 192.168.1.200
% Nameservers are supported in only one VRF at a time.
Please unconfigure nameservers from Main VRF before continuing.Once you remove the other name servers, the VRF-enabled version no longer gives a warning:
Arista(config)#no ip name-server 192.168.1.200Arista(config)#no ip name-server 192.168.1.205Arista(config)#ip name-server vrf management 192.168.1.200Arista(config)#
And now management is separate from the rest of the switch. This is cool because I could reuse the network assigned to management in the default VRF without penalty. In other words, I could also apply the same IP address to another interface. 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.
Because you wouldn’t believe me unless I showed you myself, here is the version I’m running first:
SW1#sho ver | inc image
Software image version: 4.9.4For your Arista CLI enjoyment:
SW1#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. Try that on a Cisco
switch!