Wherever you look you find three kinds of people: those that build tools they need, those that find the tools they need, and those that yammer about the lack of tools without ever doing anything to solve the problem.

Daniel Teycheney is clearly in the first category. When faced with “collect some data and create a simple report” hands-on assignment during the Building Network Automation Solutions course he started creating a toolbox of playbooks that can be used in initial network auditing. I’m positive you’ll find tons of useful tidbits in his code ;)

Want to be able to do something similar? You missed the Spring 2019 online course, but you can get the mentored self-paced version with Expert Subscription.

In the first blog post of this series I described how you could start building the prerequisite for any network automation solution: the device inventory.

Having done that, you should know what is in your network, but you still don’t know how your network is supposed to work and what services it is supposed to provide. Welcome to the morass known as building your source-of-truth.

One of my subscribers sent me this question after watching the latest batch of Data Center Fabrics videos:

You haven’t mentioned Intel's Omni-Path at all. Should I be surprised?

While Omni-Path looks like a cool technology (at least at the whitepaper level), nobody ever mentioned it (or Intel) in any data center switching discussion I was involved in.

A month ago Josef Fuchs described the process he uses to merge existing Cisco IOS device configuration with configuration snippets generated by his network automation solution.

In the second part of his article he dived deep into implementation details, described Ansible playbook and Jinja2 templates he’s using, how he optimized the solution with a custom Jinja2 filter, and the caveats he encountered.

We’re starting the Spring 2019 workshop season in March with open-enrollment workshops in Zurich (Switzerland). It was always hard to decide which workshop to do (there are so many interesting topics), so we’ll do two of them in the same week:

• Network and Security Automation with Ansible on March 12^th and
• Designing Infrastructure for Private Clouds on March 13^th.

Rachel Traylor will continue her Graph Theory webinar on March 7^th with a topic most relevant to networking engineers: trees, spanning trees and shortest-path trees, and I’ll continue with two topics I started earlier this year:

A while ago we did a podcast with Luke Gorrie in which he explained why he’d love to have simple, dumb, and easy-to-work-with Ethernet NICs. What about the other side of the coin – smart NICs with their own CPU, RAM and operating system? Do they make sense, when and why would you use them, and how would you integrate them with Linux kernel?

We discussed these challenges with Or Gerlitz (Mellanox), Andy Gospodarek (Broadcom) and Jiri Pirko (Mellanox) in Episode 99 of Software Gone Wild.

A long while ago I published my solution for automated L3VPN provisioning… and I’m really glad I can point you to a much better one ;)

Håkon Rørvik Aune decided to tackle the same challenge as his hands-on assignment in the Building Network Automation Solutions course and created a nicely-structured and well-documented solution (after creating a playbook that creates network diagrams from OSPF neighbor information).

Want to be able to do something similar? You missed the Spring 2019 online course, but you can get the mentored self-paced version with Expert Subscription.

Albert Siersema sent me his thoughts on lock-in and the recent tendency to sell network device (or software) subscriptions instead of boxes. A few of my comments are inline.

Another trend in the industry is to convert support contracts into subscriptions. That is, the entrenched players seem to be focusing more on that business model (too). In the end, I feel the customer won't reap that many benefits, and you probably will end up paying more. But that's my old grumpy cynicism talking :)

While I agree with that, buying a subscription instead of owning a box (and deprecating it) also makes it easier to persuade the bean counters to switch the gear because there’s little residual value in existing boxes (and it’s easy to demonstrate total-cost-of-ownership). Like every decent sword this one has two blades ;)

This is one of the “thinking out loud” blog posts as I’m preparing my presentation for the Building Network Automation Solutions online course. I’m probably missing a gazillion details - your feedback would be highly appreciated

One of the toughest challenges you’ll face when building a network automation solution is “where is my source of truth” (or: what data should I trust). As someone way smarter than me said once: “You could either have a single source of truth of many sources of lies”, and knowing how your devices should be configured and what mistakes have to be fixed becomes crucial as soon as you move from gathering data and creating reports to provisioning new devices or services.

Ethan Banks joined the grumpy old networking engineer club - a must-read collection of lessons-learned and disappointments he encountered in his career (and I love to see how someone else says what I always wanted to say way more eloquently)

In previous Software Gone Wild episodes we covered Snabb Switch and numerous applications running on it, from L2VPN to 4over6 gateway and integration with Juniper vMX code.

In Episode 98 we focused on another interesting application developed by Max Rottenkolber: high-speed VPN gateway using IPsec on top of Snabb Switch (details). Enjoy!

I got this remark from a reader after he read the VXLAN and Q-in-Q blog post:

Another area with a feature gap with EVPN VXLAN is Private VLANs with VXLAN. They’re not supported on either Nexus or Juniper switches.

I have one word on using private VLANs in 2019: Don’t. They are messy and complicated to maintain (not to mention how exciting it gets to combine virtual and physical switches).

Jon Langemak is on a writing spree: after completing his MPLS-on-Junos series he started a deep dive into ExaBGP. Well worth reading if you’re enjoying detailed technical blog posts.

Craig Weinhold sent me his thoughts on using Cisco ACI to implement cross-data-center L4-7 services. While we both believe this is not the way to do things (because you should start with proper application architecture), you might find his insights useful if you have to deal with legacy environments that believe in Santa Claus and solving application problems with networking infrastructure.

An “easy button” for multi-DC is like the quest for the holy grail. I explain to my clients that the answer is right in front of them – local IP addressing, L3 routing, and DNS. But they refuse to accept that, draw their swords, and engage in a fruitless war against common sense. Asymmetry, stateful inspection, ingress routing, split-brain, quorums, host mobility, cache coherency, non-RFC complaint ARP, etc.  

One of the rules of sane social media presence should be don’t ever engage with evangelists believing in a particular technology religion, more so if their funding depends on them spreading the gospel. I was called old-school networking guru from ivory tower when pointing out the drawbacks of TRILL, and clueless incompetent (in more polite words) when retweeting a tweet pointing out the realities of carbon footprint of proof-of-work technologies.

Interestingly, just a few days after that Bruce Schneier published a lengthy essay on blockchain and trust, and even the evangelists find it a bit hard to call him incompetent on security topics. Please read what he wrote every time someone comes along explaining how blockchains will save the world (or solve whatever networking problems like VTEP-to-MAC mappings).