Category Archives: Arista

iperf Testing on Arista EOS

Leave a reply

One of the many useful tools included with Arista EOS is iperf(2.0.5) which allows the switch to generate test TCP or UDP traffic. Something to note is that the total generated traffic is limited by the both the CPU capacity and the link between the CPU and the forwarding hardware, so do not expect this to be capable of linerate testing. This is useful for functional testing only.

For the client side, just drop to the bash shell, and point it towards the iperf server

L1#bash
Arista Networks EOS shell
[admin@L1 ~]$ iperf
Usage: iperf [-s|-c host] [options]
Try `iperf --help' for more information.
[admin@L1 ~]$ iperf  -c 172.16.0.4
------------------------------------------------------------
Client connecting to 172.16.0.4, TCP port 5001
TCP window size: 22.5 KByte (default)
------------------------------------------------------------
[  3] local 172.16.12.1 port 51455 connected with 172.16.0.4 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-28.6 sec   384 KBytes   110 Kbits/sec

Running the IPerf server (traffic is from client to server) on the switch requires a little more work. By default iperf uses the port TCP/5001 in server mode for inbound connections. But Arista blocks this port by default as part of the Control Plane Policer. Therefore you have to temporarily add an iptables rule in the EOS shell to allow access to port TCP/5001.

[admin@L1 ~]$ sudo iptables -I INPUT -p tcp -m tcp --dport 5001 -j ACCEPT

This can later be undone by

[admin@L1 ~]$ sudo iptables -D INPUT -p tcp -m tcp --dport 5001 -j ACCEPT

Once you have the port open, start iperf in server mode and you will see reports of the incoming connections.

[admin@L2 ~]$ iperf -s -i 5
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 172.16.0.4 port 5001 connected with 172.16.12.1 port 51455
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 5.0 sec  55.1 KBytes  90.4 Kbits/sec
[  4]  5.0-10.0 sec  59.4 KBytes  97.3 Kbits/sec
[  4] 10.0-15.0 sec  58.0 KBytes  95.0 Kbits/sec
[  4] 15.0-20.0 sec  67.9 KBytes   111 Kbits/sec
[  4] 20.0-25.0 sec  65.0 KBytes   107 Kbits/sec
[  4] 25.0-30.0 sec  18.4 KBytes  30.1 Kbits/sec
[  4]  0.0-31.7 sec   384 KBytes  99.3 Kbits/sec

Note that these results are in a virtualized, simulated environment. The amount of traffic that a real switch can generate is much higher.

Adding Arista vEOS images to UnetLab

Leave a reply

Arista provides a number of VM type images that you can use. The one with the software forwarding plane is vEOS-lab. This image has all the control plane features of standard EOS from Arista, with a software dataplane – the downside to this is that features that rely on the hardware e.g. NAT aren’t available.

There are two files required to get a working vEOS switch. The vmdk file and the Aboot ISO. To create a working vEOS on 4.17.5M we need:

  • vEOS-lab-4.17.5M.vmdk
  • Aboot-veos-serial-8.0.0.iso

To create an image that UnetLab will recognise the following steps should turn the trick

  1. Create the directory for the version in question
  2. Copy the two files in there
  3. Convert the vEOS-lab-4.17.5M.vmdk to a qcow image
  4. Rename the Aboot ISO to cdrom.iso file
  5. All done – fire up your Lab and select Arista vEOS as the template
mkdir /opt/unetlab/addons/qemu/veos-4.17.4M/
/opt/qemu/bin/qemu-img convert -f vmdk -O qcow2 ./vEOS-4.17.5M.vmdk hda.qcow2
mv Aboot-veos-serial-8.0.0.iso /opt/unetlab/addons/qemu/veos-4.17.5M/cdrom.iso
rm ./vEOS-4.17.5M.vmdk
/opt/unetlab/wrappers/unl_wrapper -a fixpermissions

 

Customising Arista EOS

Leave a reply

Arista EOS is very customisable, but if you want to customise the image you are going to deploy it can take a little work. The SWI EOS image (the part we care about anyway) is basically a squash-fs file system wrapped up as an uncompressed zip image (store).

To get at the interesting bits:

  1. unzip EOS-4.14.6M.swi
  2. unsquashfs rootfs-i386.sqsh (as root)
  3. Make any changes you want (add files, edit the python files, whatever)
  4. Delete the original rootfs-i386.sqsh, and then make a new one mksquashfs  squashfs-root/ rootfs-i386.sqsh
  5. Zip everything back up again: zip -Z store EOS-4.14.6M_custom.swi boot0 initrd-i386 linux-i386 rootfs-i386.sqsh version

Of course it is worth noting that the this would violate the Arista license agreement:

Customer shall have no right and Customer specifically agrees not to:
…
(iii) decompile, decrypt, reverse engineer, disassemble or otherwise reduce the Software to human-readable form ..

Arista EOS, VRFs, and the CLI

Leave a reply

A very common approach for networks is to have the management interface of the network node (switch, router, load balancer, etc.) in a separate VRF [Virtual Routing and Forwarding] instance. This has many security benefits, especially in the case of internet facing devices.

Main ones from my perspective are:

  • Separate routing table to the rest of the device
  • Isolation of management services
  • Independent virtual/physical interfaces, with tightened ACLs

Arista EOS for quite some time has supported VRFs, but something that you need to keep in mind when using them is that the VRF has it’s own routing table. So when you create a VRF e.g. MGMT-VRF all your addresses and routes for the management network are no longer in the default routing instance.

switch(config)# vrf definition MGMT-VRF
switch(config-vrf-MGMT-VRF)# rd 123:12
switch(config)# interface et1
switch(config-if-et1)# vrf forwarding MGMT-VRF

Some commands are VRF aware e.g. ping. For example you can run the following command:

ping vrf MGMT-vrf 10.10.10.1

Unfortunately not all commands are VRF aware yet – an obvious one is the copy command. The solution to this is to switch to the routing-context that you are trying to copy to/from and then run the copy command (this applies to all non-VRF-aware commands).

switch# routing-context vrf MGMT-VRF
switch# show routing-context vrf
Current VRF routing-context is MGMT-VRF
switch# copy ...

Then afterwards switch back to the default

switch# routing-context vrf default

Configuring Q-in-Q (802.1ad) on Arista

Leave a reply

Lately I’ve been playing around with some Arista Networks switches (nice switches, not a fan of the Cisco-style CLI) and was having issues with the configuration of Q-in-Q for VLANs (802.1ad or double tagging). There is an interesting little gotcha for the port configuration on those puppies:

interface Ethernet1
switchport access vlan 500
switchport mode dot1q-tunnel

This will tag the packet with an outer VLAN tag of 500, while leaving the inner tag untouched.