Way too many people still believe in Security Fairy (the mythical entity that makes your application magically secure), fueling the whole industry of security researchers who happily create excruciatingly detailed talks of how you can use whatever security oversight to wreak havoc (even when the limitations of a technology are clearly spelled out in an RFC).

In the Networks Are Not Secure (part of How Networks Really Work webinar) I described why we should never rely on the network infrastructure to provide security but have to implement it higher up in the application stack.

Andrea Dainese added REST (Web) API to his Automation for Cisco NetDevOps article. You might love his explanation of the screen scraping methods used by legacy implementations. He was too polite to throw around any names, but I could immediately think of NETCONF or RESTCONF implementation on Cisco IOS.

One of our subscribers sent me this email when trying to use ideas from Ansible for Networking Engineers webinar to build BGP route reflector configuration:

I’m currently discovering Ansible/Jinja2 and trying to create BGP route reflector configuration from Jinja2 template using Ansible playbook. As part of group_vars YAML file, I wish to list all route reflector clients IP address. When I have 50+ neighbors, the YAML file gets quite unreadable and it’s hard to see data model anymore.

Whenever you hit a roadblock like this one, you should start with the bigger picture and maybe redefine the problem.

Aldrin sent me an interesting question as a comment to one of my EVPN blog posts:

How does the network know that a VTEP is actually alive? (1) from the point of view of the control plane and (2) from the point of view of the data plane? And how do you ensure that control and data plane liveness monitoring has the same view? BFD for BGP is a possible solution for (1) but it’s not meant for 3rd party next hops, i.e. it doesn’t address (2).

Let’s stop right there (or you’ll stop reading in the next 10 milliseconds). I will also try to rephrase the question in more generic terms, hoping Aldrin won’t mind a slight detour… we’ll get back to the original question in another blog post.

Over the last weekend I almost got pulled into yet-another CLI-or-automation Twitter spat. The really sad part: I thought we were past that point. After all, I’ve been ranting about that topic for almost seven years… and yet I’m still hearing the same arguments I did in those days.

Just for the giggles I collected a few old blog posts on the topic (not that anyone evangelizing their opinions on Twitter would ever take the time to read them ;).

Most of us are in some sort of lockdown (or quarantine or shelter-in-place or whatever it’s called) at the moment. Some have their hands full balancing work and homeschooling their kids (hang in there!), others are getting bored and looking for networking-related content (or you wouldn’t be reading this blog).

If you’re in the latter category you might want to browse some of the free ipSpace.net content: almost 3500 blog posts, dozens of articles, over a hundred podcast episodes, over 20 free webinars, and another 30+ webinars with sample videos that you can access with free subscription.

As I explained in How Networks Really Work and Upcoming Internet Challenges webinars, routing security, and BGP security in particular remain one of the unsolved challenges we’ve been facing for decades (see also: what makes BGP a hot mess).

Fortunately, due to enormous efforts of a few persistent individuals BGP RPKI is getting traction (NTT just went all-in), and Flavio Luciani and Tiziano Tofoni decided to do their part creating an excellent in-depth document describing BGP RPKI theory and configuration on Cisco- and Juniper routers.

Every time I’m complaining about the stupidities $vendors are trying to sell us, someone from vendorland saddles a high horse and starts telling me how I got it all wrong, for example:

It is a duty of a pre-sales, consultant, vendor representative to inform the customer about the risk.

When you stop laughing (maybe it was just April Fools’ joke ;), here’s how the reality of that process looks like (straight from one of my readers):

One of the first hands-on exercises in our Networking in Public Cloud Deployments asks the attendees to automate something. They can choose the cloud provider they want to work with and the automation tool they prefer… but whatever they do has to be automated.

Most solutions include a simple CloudFormation, Azure Resource Manager, or Terraform template with a line or two of README.MD, but Erik Auerswald totally astonished me with a detailed and precise writeup. Enjoy!

With webinars being the only way to deliver training content these days, we’ll run one every week in April 2020:

• Starting on April 2nd I’ll talk about one of my favorite topics: switching, bridging and routing, covering almost everything ever invented from virtual circuits and source route bridging to so-called routing at layer-2 and IP forwarding based on host routes;

• I was planning to update the Introduction to Containers and Docker material for ages… but then had to move the December 2019 workshop to March 2020, only to cancel it a week before the coronavirus exploded for real in Switzerland. I hope I’ll manage to deliver the online version on April 9th ;)