• Curl’ing with EOS and third party devices

Print Friendly, PDF & Email

Perhaps you’re aware that EOS is based on Linux, which comes with many powerful & useful built-in utilities. I recently wrote an EOS Central article on sed. Even if you are not a pure networking person (perhaps you’re a server person), many of the familiar Linux tools you have used in your past exist on EOS natively today.

One of my customers recently shared an experience with me that made me smile because they had now started to embrace the Linux underpinnings & power of EOS after running into a configuration challenge with a 3rd party (television) broadcast IP/SDI gateway device (the Riedel/Embrionix emFUSION 6).

Let’s set the context of the discussion a bit. I was working with the customer & going over some IP addressing, subnetting, and configuration tasks. Part of their television broadcast environment utilizes the emFUSION devices for converting audio/video signals to/from the SMPTE ST-2110 IP multicast format, among other things. The emFUSION devices come from the factory with random IP addresses and also come with Windows software, which is required for auto-discovery of the devices on a link-local L2 network. Once found, the user can then configure the device, including changing its IP addresses to match their IP scheme. The emFUSION devices are not factory-programmed with default next-hop gateways either preventing them from talking at L3. The native Ethernet interfaces are 25GbE on these devices so interfacing your 1GbE laptop (where the auto-discovery software runs) requires some various media conversions via an Ethernet switch that has both 1GbE and 25GbE interfaces. In addition, if your SMPTE ST-2110 network is following best-practices & configured as an L3 network, the assumption that the network is a flat L2 network doesn’t work for link-local auto-discovery.

Since the media-conversion option was not easily available to the customer they looked for an alternative solution. Given that they knew the IP address & subnet mask that was factory-programmed on the emFUSION’s, they simply plugged in the 25GbE link on their Arista 7508R chassis. They discovered that the emFUSION has a RESTful API and that they could execute a set of Curl commands from EOS to send HTTP commands to the emFUSION in order to configure it properly. This eliminated the need to figure out connectivity from a Windows laptop into the fabric in order to run the Riedel/Embrionix software for the auto-discovery. The steps performed were as follows:
  1. Create a temporary VLAN and SVI ( on the same subnet as the emFUSION’s factory-programmed IP address & subnet mask (the emFUSION arrived pre-programmed within the range by default).
  2. Map that VLAN to the relevant 7508R port.
  3. Once the SVI is up, ping the emFUSION from the Arista 7508R. This will confirm IP connectivity between the two, since the IP addresses on both sides (Arista and Embrionix) are on the same subnet (ie. they are L2 adjacent).
  4. Drop to the Bash shell from the Arista EOS CLI (type bash on the CLI)
  5. Execute some Curl commands, replacing brackets and anything contained inside them with the relevant information in the below commands where the current IP (from the factory) is The first Curl command fetches the current state of the configuration. The second Curl command reprograms the emFUSION.
    • curl -X GET
    • curl -H "Content-Type: application/json" -H "Accept: application/json" -X PUT -d "{\"ip_addr\":\"[new ip]\”,\"gateway\":\"[new gateway]\”, \"subnet_mask\":\"[new mask]\",\"hostname\":\"[new hostname]\”}"
  6. The emFUSION then automatically reboots after the settings get changed.
  7. Undo the temporary VLAN & SVI on the 7508R, configure the proper VLAN & SVI for the emFUSION changes.
  8. Wait for the emFUSION to come back online, and it will be configured for your network.

There are a few interesting points to draw your attention to here:

  • It’s great that Riedel/Embrionix supports and documents external APIs for their customers to use. This provides flexibility in terms of provisioning and monitoring, and I encourage you to reach out to your vendors and discover more about their APIs.
  • The second interesting thing to point out is the fact that since Arista EOS in based on Linux all the familiar tools that you may have already used are available for you to be creative and help enable you to be more agile.
  • And the third thing to point out is the fact that my customers continue to discover the power of EOS.

NOTE: This 3rd party RESTful API device programming was performed from an Arista 7508R (with the R2-36CQ-LC linecard’s 100GbE port broken-out to 4x25GbE via a cassette) running EOS 4.23.3M.

If you want to play with some other interesting Curl stuff have a look at one of my colleague’s postings on EOS & our streaming Telemetry.

If you want to read more about Arista’s success and leadership in the Media & Entertainment (“M&E”) space, please visit this website.


Get every new post on this blog delivered to your Inbox.

Join other followers: