Tag Archives: EOS

iperf Testing on Arista EOS

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.

Customising Arista EOS

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

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