I've been documenting my quest to make building and destroying a local lab using NXOSv 9000 as painless as possible in part 1 and part 2. This post is pretty much the TL;DR of the series, as in the meantime I figured out the best way to run multiple instances of this image through Vagrant. So here's what I've been using for the past half year together with a few Ansible playbooks to perform some basic but very necessary tasks.

I started the new year troubleshooting Docker Overlay network traffic pushed through a Cisco ACI fabric that was not working despite physical connectivity and contracts being in place. Or so we thought... as VXLAN encapsulated packets (used by Docker overlays) do not follow the usual expected pattern.

In part one of this series we looked at starting up a couple of Nexus9000v machines using a tool called vagrant. It went OK, but we had some unfinished business. In this post we'll look at how I try to address the MAC address issues and run my first ansible playbook against this lab.

A recent tweet caught my eye: a new version of NX-OSv was available, together with instructions on setting it up in vagrant. Very good timing too, as I'm building automation (a bit of orchestration and a lot of validation) for a couple projects including for both the 7K and the 9K flavours of NX-API and could really use a decent machine-local lab.

The CCDE (Cisco Certified Design Expert) practical exam scheduled for May 11th 2017 has been cancelled globally. This is a heads-up for the article I've written on Packet Pushers about integrity, transparency and trust (with a call to action for Cisco) in the context of last week's events.

In a previous post I wrote about how raw SSL Performance looks like on a server, briefly mentioning network level encryption methods. I thought I'd post a brief note on some implications of using MACsec after watching a rather informative Cisco Live session on the topic.

It all started a while ago with a log message found on the hub of a large DMVPN/IPSEC deployment over mobile Internet connections. Given the increasing number of deployments that use the Internet as a cheaper, faster WAN for either primary or backup, I thought it would be useful to document the problems and the two main solutions.

I was recently watching BRKDCT-2333 - Data Center Network Failure Detection and, after going through the usual suspects - L1 (carrier loss, link signaling), L2 (LACP, UDLD, CFM/Link-OAM), L3 (protocol keepalives, BFD) - the presenter talks about BFD over EtherChannel. But not only for node protection (see below), but for link protection as well, running micro-BFD sessions on each individual EtherChannel member. After understanding how it is done, I started wondering what's the point (tangible benefit) of using this feature?