Networking Quirks Observed During netlab Tests

One of the interesting netlab use cases is the ability to explore how different vendors implement the same functionality. For that to work, we try to configure network devices to maximize interoperability with devices from other vendors. We might miss some details, but as the average vendor investment in helping us get things right (so far) has been close to zero, I don’t think they have a right to complain ;)

We also want to ensure the device configurations we created work as expected, so we run hundreds of integration tests. We run integration tests between devices from different vendors whenever possible, using FRR or Arista EOS containers as the probe device. There are a few reasons we’re using these devices as probes:

  • Their container versions boot surprisingly fast.
  • They are easily configured using the “industry standard” configuration syntax1.
  • Their show commands produce easy-to-consume JSON data.

We prefer FRR (it boots faster and has a much smaller memory footprint) but use Arista when needed because it can display more information (for example, VRRP neighbors) in JSON format.

The focus on interoperability inevitably uncovers quirks that would remain unnoticed when building a single-vendor network. Please don’t blame us for the quirks we document or for mentioning a device on which we found the unexpected behavior. If you’re working for a vendor, getting them fixed is much better.

Finally, pull requests that improve device configuration templates while keeping configurations relatively simple are always most welcome.


  1. A weasely way of saying “Cisco IOS” without getting sued ↩︎

Sidebar