In the next session of Network Automation Use Cases webinar (on Thursday, February 16th) I’ll describe how you could implement automatic deployment of network services, and what you could do to minimize the impact of unintended consequences.

If you attended one of the previous sessions of this webinar, you’re already registered for this one, if not, visit this page and register.

Most networking operating systems include a mechanism to roll back device configuration and/or create configuration snapshots. These mechanisms usually work only for the device configuration, but do not include operating system images or other components (example: crypto keys).

Now imagine using RFC 1925 rule 6a and changing the “configuration rollback” problem into “file system snapshot” problem. That’s exactly what Cumulus Linux does in its newest release. Does it make sense? It depends.

Some of the engineers building Ansible-with-VIRL lab in my Building Network Automation Solutions online course experienced interesting challenges, so I made the how-to instructions more explicit and added a troubleshooting section to the Using Ansible Playbooks with Cisco VIRL document. Hope you’ll find them useful.

When I recorded the first podcast with Thomas Graf we both found it so much fun that we decided to do it again. Thomas had attended the NetDev 1.2 conference so when we met in November 2016 we warmed up with What’s NetDev and then started discussing the hot new networking stuff being added to Linux kernel:

In the previous blog posts I described how OSPF tries to solve some broken designs with Forwarding Address field in Type-5 LSA – a kludge that unnecessarily increases the already too-high complexity of OSPF.

NSSA areas make the whole thing worse: OSPF needs a Forwarding Address in Type-5 LSAs generated from Type-7 LSAs to ensure optimal packet forwarding. Here’s why:

In the last few weeks I’ve seen numerous questions along the lines of “how do I manage VLANs on my switch with Ansible”. You can look at this question from two perspectives: the low-level details (which modules do I use, how do I push commands to the box…) or the high-level challenges (how do I make sure actual device state matches desired device state). Obviously I’m interested in the latter.

I’m positive I’ve answered this question a dozen times in various blog posts and webinars, but it keeps coming back:

You always mention that high speed links are always better than parallel low speed links, for example 2 x 40GE is better than 8 x 10GE. What is the rationale behind this?

Here’s the N+1-th answer (hoping I’m being consistent):

In Episode 69 of Software Gone Wild we discussed ways of increasing visibility into VXLAN transport fabric. Another thing we badly need is visibility into the virtual edge behavior, and to help you get there Iwan Rahabok created a set of vRealize dashboards that include the virtual edge networking components. Hope you’ll find them useful.

A while ago I decided it's time to figure out whether it's better to drop or to delay TCP packets, and quickly figured out you get 12 opinions (usually with no real arguments supporting them) if you ask 10 people. Fortunately, I know someone who deals with TCP performance for living, and Juho Snellman was kind enough to agree to record another podcast.

In my initial OSPF Forwarding Address blog post, I described a common Forwarding Address (FA) use case (at least as preached on the Internet): two ASBRs connected to a single external subnet with route redistributing configured only on one of them.

That design is clearly broken from the reliability perspective, but are there other designs where OSPF FA might make sense?

One of the engineers attending my Building Network Automation Solutions online course got the lab up and running, wanted to execute a simple IOS command from an Ansible playbook and failed.

He quickly realized he needs to set connection to local or network_cli; for more details watch the Connecting and Authenticating section of Ansible Networking Modules - Executing Commands part of Ansible for Networking Engineers webinar.

Ansible (or Python+Paramiko/Netmiko) seems to be the tool used in most do-it-yourself network automation presentations and videos. Did you know there’s a scripting/automation alternative that’s hugely popular in parts of sysadmin and virtualization universe that almost nobody talks about in networking (because everyone is focused on huge data center fabrics and unicorns) – PowerShell (now also available on OSX and Linux).

One of the quotes I found in the Mythical Man-Month came from the pre-GPS days: “never go to sea with two chronometers, take one or three”, and it’s amazing the networking industry (and a few others) never got the message.

One would think that we're the only ones struggling with Linux CLI (read: bash). Seems like cyber security professionals might be in the same boat according to the nice summary of dozens of Linux/bash commands collected by Robert Graham.

Running Linux containers on a single host is relatively easy. Building private multi-tenant networks across multiple hosts immediately creates the usual networking mess.

Fortunately the Socketplane team did a pretty good job; for more details watch the video from Docker Networking Fundamentals webinar or listen to the podcast I did with them a year ago.