The Connectivity Transformation Blog

Recently I have been working more with network automation and using Arista Validated Designs (AVD), Ansible and Netbox. A somewhat common request that I encounter is being able to pull the Ansible inventory from Netbox. There is an Ansible plugin for this called “nb_inventory” to do this exact function. However, through my testing I have found a more preferable approach. I opt for executing an Ansible playbook with a GraphQL query, which then processes the output through a Jinja template to create the inventory file. This technique offers a significant advantage: in the event of a Netbox server outage or accessibility issues, the inventory remains usable for running Ansible playbooks until access to Netbox is restored. In the upcoming example, I’ll introduce additional logic tailored for environments using AVD. However, the approach can be easily adapted for scenarios involving only Ansible and Netbox. This article presumes the presence of functional Netbox and AVD environments which is out of scope for this post.

As network operators, we often face the daunting task of troubleshooting duplicate IP addresses on the network. This is an age-old issue that can turn into a tedious and time-consuming process if not handled efficiently. Traditional troubleshooting methods involve pinging the IP address and checking the ARP cache on the switch. However, Arista switches, with their Linux foundations, offer a more streamlined approach - the use of the "arping" command.

Packet Captures or PCAPs are often necessary for network engineers to get to the root cause of issues in a network. As an esteemed friend and talented network engineering friend likes to say, “PCAP or it didn’t happen.” That said, getting a packet capture can be fraught with issues. How do you get mirrored packets for capture to a laptop or other computer that can review them onsite? Can you easily get a remote desktop session going to it? What if that host goes to sleep or goes offline for some reason? Is there a user that has the technical capability at the location in question to set up a capture?

It’s the year 2022 so can we collectively agree to stop using insecure protocols like FTP and TFTP to transfer files to and from your network devices? One of the many advantages of Arista switches is that you can use Secure Copy Protocol (SCP) which is an encrypted protocol to move files to and from them and also use the switch itself as an SCP source or destination. Years ago if you were remote and performed a firmware update to a network device you’d have to set up an FTP or TFTP server and then deal with the headaches when doing active vs. passive FTP if going through a firewall etc. With SCP it runs over port 22 (same as SSH) so in theory if you can SSH to the device you should also be able to SCP to it.

Using SSH key based authentication for managing Arista switches can be useful for the purposes of better security, automation and not having to remember passwords. In this blog post, we’ll go through an example on how to set SSH key based authentication with Arista switches. These instructions should cover any MacOS or Linux variant operating system. Windows works as well but I don’t use it so you would be on your own to configure Windows on the client side. The switch configuration would be the same for any operating system you choose.

It’s no secret that we at WAN Dynamics are big fans of Arista switches. There is a definite feeling when using them that the Arista Extensible Operating System (EOS) was written by engineers for engineers in order to make the network operator’s life easier. In this post, we will discuss three features that are great on their own, however when coupled together, you get an amazing amount of flexibility to solve real world problems. The sum of these features is greater than each of their parts.

WAN Dynamics received a message from a customer late one evening that no network services company wants to get: “We performed a code upgrade and broke connectivity to our disaster recovery site”. This customer had a datacenter interconnect (DCI) with BGP routing and VXLAN between the datacenters but after the EOS upgrade there was reachability issues between them. I jumped in to assist and at first glance, things looked good. The switch interfaces and BGP sessions were up and there was full connectivity from VTEP to VTEP in the datacenter interconnect. That said, MAC addresses were not being learned across VXLAN. Hmmm, wonder why that would be? I decided to check the switch logs for any potential clues as to what could be happening. Aha! in the log buffer there are messages about VXLAN being disabled:

Recently while setting up a new Fortinet FortiGate firewall High Availability (HA) pair, I ran into an issue that I hadn’t encountered before. The goal was to set up an active/standby HA pair and having done this many times, didn’t think much of it when configuring the normal HA settings...

Even though managing Arista switches is pretty great, sometimes performing things like software upgrades can be tedious and boring, especially when there are a lot of switches to upgrade at a time. Here at WAN Dynamics, we like to solve tedious problems with automation so to for this particular challenge.