Arista EOS Spooky Motion at a Distance « ipSpace.web weblog

This weblog submit describes one more weird conduct found throughout the netlab integration testing.

It began innocently sufficient: I used to be engaged on the VRRP integration take a look at and wished to make use of Arista EOS because the second (probe) machine within the VRRP cluster as a result of it produces good JSON-formatted outcomes which are simple to make use of in validation exams.

Every thing appeared nice till I ran the take a look at on all platforms on which netlab configures VRRP, and all of them handed aside from Arista EOS (that was earlier than we discovered how Sturgeon’s Legislation applies to VRRPv3) – a “That’s humorous” second that was instantly accountable for me losing a number of hours chasing white rabbits down this path.

I whittled the lab topology to the naked minimal: two routers and a bunch related to the identical LAN section. I had to make use of Arista VMs; Arista EOS containers don’t reply to pings to the VRRP IP handle^.

Minimal VRRP lab topology

module: [ gateway ]
gateway.protocol: vrrp
gateway.id: 1

nodes:
  r1: { machine: eos }
  r2: { machine: eos }
  h:  { machine: linux }

hyperlinks:
- interfaces: [ r1, r2, h ]
  gateway: True

The lab began, and the host may ping the VRRP IPv4 handle. Nonetheless, after I shut down the Ethernet interface on the VRRP grasp, the VRRP backup router failed to answer pings. That’s not how VRRP is meant to work, proper?

The “that’s humorous” second shortly changed into a “that’s undoubtedly bizarre” one after I found the basis explanation for the issue: after I shut down the Ethernet interface on one Arista swap, the line protocol on the Ethernet interface on the opposite swap went down.

Shutting down the Ethernet interface on R2…

$ netlab join r2
Connecting to 192.168.121.103 utilizing SSH port 22
Final login: Solar Mar  9 13:35:40 2025 from 192.168.121.1
r2#conf t
r2(config)#int eth1
r2(config-if-Et1)#shut
r2(config-if-Et1)#

… causes a hyperlink loss on R1

$ netlab join r1
Connecting to 192.168.121.102 utilizing SSH port 22
Final login: Solar Mar  9 13:35:40 2025 from 192.168.121.1
r1#time period mon
Mar  9 13:36:24 r1 Fhrp: %VRRP-5-STATECHANGE: Ethernet1 Grp 1 state Backup -> Stopped
Mar  9 13:36:24 r1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1 (r1 -> [r2,h]), modified state to down

If this had been to occur with Arista EOS containers, I might need suspected that an motion on one Linux interface may have an effect on one other interface related to the identical bridge. Nonetheless:

• I used to be utilizing VMs
• There’s QEMU between the VM NIC and the interface related to a Linux bridge
• Quantum entanglement doesn’t work throughout Linux bridges (but)
• Like Einstein, I don’t imagine in spooky motion at a distance.

The one sane conclusion was that one Arista swap instructed the opposite, “I’m shutting down this interface.”

Subsequent step: determining how that works. I eliminated VRRP from the lab topology to scale back the litter produced by tcpdump, began packet seize on the Linux bridge, and shortly discovered the offender. The Arista swap on which I shut down the Ethernet interface despatched out a squeak simply earlier than it obeyed:

Packet captured in the mean time the Ethernet interface was shut down

$ sudo tcpdump -evvv -i virbr1
tcpdump: listening on virbr1, link-type EN10MB (Ethernet), snapshot size 262144 bytes
13:45:08.860471 08:4f:a9:fb:f2:43 (oui Unknown) > 01:1c:73:ff:ff:ff (oui Unknown), ethertype Arista Vendor Particular Protocol (0xd28b), size 19: SubType: 0xe1ba, Model: 0x0000,
	0x0000:  e1ba 0000 00                             .....

The identical swap despatched one other packet after I reenabled the interface:

Packet captured after the Ethernet interface was reenabled

13:45:20.660672 08:4f:a9:fb:f2:43 (oui Unknown) > 01:1c:73:ff:ff:ff (oui Unknown), ethertype Arista Vendor Particular Protocol (0xd28b), size 19: SubType: 0xe1ba, Model: 0x0000,
	0x0000:  e1ba 0000 01

It seems like Arista’s builders tried actually laborious to emulate point-to-point Ethernet hyperlinks, together with the hyperlink loss conduct when the distant interface is shut down. That’s great, however sadly:

• They used a proprietary implementation (not that I might pay attention to a regular resolution they may use)
• Their implementation brings down the Ethernet interfaces on all Arista switches related to the identical bridged section (however not on some other machine).
• I couldn’t discover this conduct documented wherever.