Tidbit: Arista/NAPALM Config Replace

Quick one here — if you are dorking about with NAPALM and config replace (I’ve been using Ansible, but probably same story for just pure Python) and you are getting annoying errors on whatever is AFTER your BGP stanza, make sure you “exit” out of your BGP stanza like so:


router bgp 1234
   neighbor remote-as 1234
   neighbor update-source loopback0
  address-family ipv4
   neighbor activate
router ospf 1

Basically I was getting an annoying error saying something about an invalid token and “‘router ospf 1’ failed:”. Adding the “exit” statements out of each of the nested stanzas of BGP fixed this right away. Hopefully this saves somebody some time 🙂


Nexus 9000v & Vagrant: invalid config.ssh.shell

I was working on getting some base Nexus 9000v stuff setup in Vagrant recently and ran into an issue that I couldn’t find good info on, so I figured I would dust off the old blog and document this briefly.

The core of the issue is that in order to validate that the VMs Vagrant is bringing up are working properly, Vagrant connects to the device and runs some command(s) (what I’m not entirely sure, but it seems to connect and try to do “stuff”). When booting a Nexus 9000v with a basic minimal Vagrantfile I was getting the following error:

==> nxos: Waiting for machine to boot. This may take a few minutes...
nxos: SSH address:
nxos: SSH username: vagrant
nxos: SSH auth method: private key
The configured shell (config.ssh.shell) is invalid and unable
to properly execute commands. The most common cause for this is
using a shell that is unavailable on the system. Please verify
you're using the full path to the shell and that the shell is
executable by the SSH user.

With the ASAv, CSR1000v, and VEOS machines I have been playing with I never run into this issue. I’m 100% positive there is a solid explanation for this, but I just can’t seem to find a good one. My speculation is that Vagrant knows that the Nexus is a Linux box of some flavor and therefore tries to connect and runs into issues when it logs in and sees NX-OS instead of a regular shell. How it gets around this with the ASA for example though I’m not entirely sure. Perhaps the auto-discovered guest OS type doesn’t bother executing a command and/or validating the output for the Linux 2.6 type that I suspect the ASA/CSR get (anyone who can explain that would be great!!).

Anyway, I found two decent work arounds for this. Firstly, when configuring the vagrant user on the base NX-OS box you can simply set the shell type to bash. You can do this very simply with the following command:

username vagrant shelltype bash

Reference: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/programmability/guide/b_Cisco_Nexus_9000_Series_NX-OS_Programmability_Guide_7x/Bash.html

This will drop the vagrant user straight into bash which will get you past the above error, and that’s pretty snazzy, but…. is annoying when using “vagrant ssh” to connect to your host because you get dropped into bash instead of into NX-OS like you (probably) would be hoping for.

While combing through the above document I realized that there may be a little bit better of a workaround by setting the “config.ssh.shell” to be “run bash” which the doc clearly shows as a bit of a shortcut to executing bash commands directly from the NX-OS cli. Thankfully this did the trick!! You can set this in your Vagrantfile as follows:

config.ssh.shell = "run bash"

It’s that easy!

In my case I was working on a multi machine Vagrantfile however, so by setting the shell to this it worked for the Nexus device, but not for another Ubuntu host. So I added a super simple conditional to only set the shell to “run bash” for the NX-OS device:

if machine[:ssh_shell]
  config.ssh.shell = machine[:ssh_shell]
  config.ssh.shell = "bash -l"

My array of devices then just has a variable “ssh_shell” set to “run bash” for the Nexus host; otherwise we can set the config.ssh.shell to the Vagrant default of “bash -l” which you can find in the lovely Vagrant docs here: https://www.vagrantup.com/docs/vagrantfile/machine_settings.html#config-vm-guest

Hopefully this saves somebody some time/annoyance!