‹ Nick Plunkett

Tags / automation

I have recently been integrating Peering Manager into my network deployment at my day job in order to help automate our BGP configuration & management. We run Arista switches running as routers across our entire footprint. Peering Manager has NAPALM integration built into it, both for managing and deploying configuration as well as polling device status. However, for Arista devices, this requires the Arista eAPI to be enabled on the router, and it must be running in HTTPS mode. That means you need some sort of security certificate installed. I hadn’t dealt with this before and this wasn’t straightforward. I wasn’t able to find great documentation online for how to do this. Below is my process for generating a self signed key, then using that key to generate a self-signed certificate, then using that certificate to allow HTTPS connections to the router over the management interface for eAPI command and control.
Recently, as a part of network automation at $dayjob, I have been provisioning Salt across our network footprint. One particular problem I’ve run into is that we use a dedicated management VRF on all of our devices. This was an issue because by default, commands ran on bash on the Arista software run in the default VRF, and in that state we can’t communicate with our management IP networks. There just isn’t a route to the management networks on the default routing table. Our Salt server only has a Management VRF IP address, and we did not want to configure a proxy to make the Salt master reachable outside the Management VRF. I had previously had no experience with management VRFs on Linux, and there were no articles that were particularly helpful in helping me to run commands specifically in the management VRF of an Arista switch, within the context of the Bash/Linux shell.
« Older posts Newer posts »