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.