Blog Posts in September 2019
I have exciting news I’d love to share with you: we’re launching a new online course focused on networking in public clouds starting in February 2020 (I’ve been mulling over this idea and polishing the concept for almost 18 months, and finally it all came together ;)
With Go To The Cloud becoming the answer to all questions (regardless of what the question is), you can find tons of materials describing various aspects of public clouds, so you might wonder why I decided to enter the fray. The answer is simple: with everyone being focused on developers, there’s not much that an infrastructure engineer could use to help him survive when the developers move on and he’s left to manage whatever they put in place.
Every few weeks I stumble upon an article (or twitter storm) in which someone claims you don’t need formal education to get started as a Software Engineer (or whatever else) - all you need is a coding academy/bootcamp and you're all set.
George V. Neville-Neil wrote a hilarious rebuttal of this idea followed by some pretty good advice. Hope you’ll enjoy it as much as I did ;)
A long while ago Daniel Dib wrote a nice blog post on “SDN will make the networking engineers obsolete” theme. While it sounds like beating a dead horse, the SDN craze isn’t subsiding, so another healthy dose of common sense might come handy.
Hint: if you’re not following Daniel’s blog, you should… even though he decided to make old farts’ life harder by publishing on LinkedIn.
Sick-and-tired of intent-based GUIs that are barely better than CiscoWorks on steroids? How about asking Siri-like assistant queries about network state in somewhat-limited English and getting replies back in full-blown sentences?
A while ago Ruben Tripiana tried to configure BGP on Cisco IOS using IETF YANG data models… and failed. In Spring 2019 Building Network Automation Solutions online course Chris Crook decided to deploy BGP routing on multiple platforms using YANG data models instead of configuration templates. Not only did he succeed, he also documented his work and the tools he used, and published the solution so you can replicate his efforts.
You can find many more network automation solutions created by the attendees of our automation course in solutions showcase.
Two weeks ago I replied to a battle-scar reaction to 7-layer OSI model, this time I’ll address a much more nuanced view from Russ White. Please read his article first (as always, it’s well worth reading) and when you come back we’ll focus on this claim:
The OSI Model does not accurately describe networks.
Like with any tool in your toolbox, you can view the 7-layer OSI model in a number of ways. In the case of OSI model, it can be used:
In last week’s continuation of EVPN never-ending story Lukas Krattiger described how you could use EVPN constructs (VNIs, VRFs) to implement service insertion, and how you could combine then with policy-based routing.
TL&DW: It’s bridging and routing ;)
You’ll need Standard ipSpace Subscription to access the videos.
People who can explain complex topics in simple terms, or focus on the essentials of a particular topic are exceedingly rare… and two of the best are Randall Munroe of the XKCD fame and Julia Evans, the mastermind behind WizardZines. I loved her recent curl and git exercises, and I’m guessing a lot of people in this industry would benefit from her latest HTTP zine.
Similarly to what I did a long time ago with ipSpace.net, Julia recently decided to go all-in, leaving her job and focusing on explaining things. I hope it will work out and we’ll keep enjoying her tidbits of wisdom for years to come.
After identifying some of the challenges every network solution must address (part 1, part 2, part 3) we tried to tackle an interesting question: “how do you implement this whole spaghetti mess in a somewhat-reliable and structured way?”
The Roman Empire had an answer more than 2000 years ago: divide-and-conquer (aka “eating the elephant one bite at a time”). These days we call it layering and abstractions.
In the Need for Network Layers video I listed all the challenges we have to address, and then described how you could group them in meaningful modules (called networking layers).
I had a fantastic chat with David Bombal a while ago in which we covered tons of network automation topics including “should I use Nornir or NAPALM or Netmiko?”
The only answer one can give would be “it depends… on what you’re trying to do” as these three tools solve completely different challenges.
Paramiko is SSH implementation in Python. It’s used by most Python tools that want to use SSH to connect to other hosts (including networking devices).
In Never-Ending Story of IP Fragmentation I described how you could use TCP Maximum Segment Size to minimize the impact of IP fragmentation and PMTUD blackholes (more details on TCP MSS clamping)… but one has to wonder how people use TCP MSS in the wild and what values you might see.
As is often the case, Geoff Houston found a way to measure them, and published the answer: TCP MSS Values
Someone working for a network automation startup desperately tried to persuade me how cool their product is. Here’s what he sent me:
We let network engineers build their own network automation solutions in no time without requiring coding or scripting knowledge. It’s all GUI based, specifically geared towards network engineers - they can simply model services or roll-out networks “as-designed”.
The only problem: I’ve seen that same argument numerous times…
I recorded the hands-on demos in advance so we had plenty of time to discuss Azure API and CLI, geographies, regions and availability zones, high-availability concepts, and deployments models… and spent the second half of the live session focusing on virtual networks, subnets, interface, and IP addresses. The videos are already online and accessible with Standard ipSpace.net Subscription.
Next step (on September 24th): network security and user-defined routes.
I apologize to my regular readers for a completely off-topic post, but if I manage to save a single traveller the frustrations I experienced a few weeks ago it was well worth it. Also, please help spread the word…
TL&DR: If you travel to Slovenia, DO NOT even consider flying with Adria Airways (and carefully check the code-share flights, they might be hiding under a Lufthansa or Swiss flight number). Their actual flight schedule is resembling a lottery, and while I always had great experience with the friendly, courteous and highly professional cabin crews, it’s totally impossible to reach their customer service.
2019-09-30: The agony ended sooner than I expected. On September 30th Adria Airways declared bankruptcy, ending the frustration and uncertainty of thousands of passengers they left stranded across Europe for almost 10 days. So long Adria, and thanks for all the good flights (we'll eventually forget all the mess you made in the last year)
2019-09-22: Added updates on what happened during last week. The whole thing is becoming a soap opera
In the introductory videos of How Networks Really Work webinar I described the mandatory elements of any networking solution and additional challenges you have to solve when you can’t pull a cable between the adjacent nodes.
It’s time for the next bit of complexity: what if we have more than two nodes connected to the same network segment? Welcome to the world of multi-access networks and data link control.
The March 2019 Packet Pushers Virtual Design Clinic had to deal with an interesting question:
Our server team is nervous about full-scale DR testing. So they have asked us to stretch L2 between sites. Is this a good idea?
The design clinic participants were a bit more diplomatic (watch the video) than my TL&DR answer which would be: **** NO!
Let’s step back and try to understand what’s really going on:
The last bits of updated Never-Ending Story of IP Fragmentation were published a few days ago: IP fragmentation and tunnels and summary and related blog posts, RFCs and other articles.
Every now and then I stumble upon a blog post saying “OSI 7-layer model sucks” or “OSI 7-layer model is a lie”, most recent one coming from Robert Graham.
Before going into the details, let’s agree on the fundamentals.
Most everyone who ever tried to build a network spanning more than one transmission technology and including intermediate nodes came to the conclusion that layered approach to networking makes sense.
Whether you have three, four, five, or seven layers in your model doesn’t matter. What really matters is that your model contains all the functionality you need to implement host-to-host networking in target environment.
TL&DR: Can I download whatever stuff I found as my first Google hit and use it in my automation solution? ****, NO!
Matthias covered these topics:
Imagine you would have a system that would read network device configurations, figure out how those devices might be connected, reverse-engineer the network topology, and be able to answer questions like “what would happen if this link fails” or “do I have fully-redundant network” or even “how will this configuration change impact my network”. Welcome to Batfish.
As I was preparing the materials for Ansible 2.7 Update webinar sessions I wanted to dive deeper into declarative configuration modules, starting with “I wonder what’s going on behind the scenes”
No problem: configure EEM applet command logging on Cisco IOS and execute an ios_interface module (more about that in another blog post)
Next step: let’s see how multi-platform modules work. Ansible has net_interface module that’s supposed to be used to configure interfaces on many different platforms significantly simplifying Ansible playbooks.
Interested in similar topics? Check out How Networks Really Work webinar.
This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.
Have you ever seen a presentation in which a startup is telling you how awesome their product is because it allows you to simulate your whole network in a virtual environment? Not only that, you can use that capability to build a test suite and a full-blown CI/CD pipeline and test whether your network works every time you make a change to any one box in the network.
Sounds awesome, right? It’s also dead wrong. Let me explain why that’s the case.
Last year when I was creating the first version of VMware NSX Deep Dive content, NSX-V was mainstream and NSX-T was the new kid on the block. A year later NSX-V is mostly sidelined, and all the development efforts are going into NSX-T. Time to adapt the webinar to new reality… taking the usual staged approach:
- The new slide deck covering NSX-V and NSX-T is ready. It includes early information about NSX-T release 2.5; I’ll fill in the details once the documentation becomes public.
- I’ll use the slide deck in day-long workshop in Zurich on September 10th.
- The live webinar sessions (including updated NSX-T 2.5 content) will start on November 14th.