Upcoming Events and Webinars (September 2019)

We’re back from the summer break for real - the first autumn 2019 ipSpace.net event takes place today: I’ll talk about the fallacies of distributed computing.

September will be an intensive month:

• We’re starting the autumn 2019 network automation course on September 3^rd;
• A week after that (September 10^th) I’ll run a day-long VMware NSX workshop in Zurich;
• Azure Networking webinar series is starting on September 12^th and continuing on September 24^th;
• Lukas Krattiger will talk about service insertion in leaf-and-spine fabrics on September 17^th.

Of course, we’ll keep going… our event calendar is fully packed till mid-November. More about that in a month.

Updated: Never-Ending Story of IP Fragmentation

In mid 2000s I wrote a number of articles describing various TCP/IP features. Most of them are a bit outdated, so I decided to clean up, update and repost the most interesting ones on ipSpace.net, starting with Never-Ending Story of IP Fragmentation.

The first part of that article is already online, covering MTU basics and drawbacks of IP fragmentation.

NETCONF and RESTCONF Overview

Andrea Dainese decided to describe a series of mechanisms and protocols you can use in network automation. He started with Zero-Touch Provisioning and continued with screen scraping. Next one on his list: NETCONF and RESTCONF

Recently Published: Azure Networking Demo Videos

Remember my rant about the glacial speed of Azure orchestration system? I decided I won’t allow it to derail yet another event and recorded the demos in advance of the first live session. The final videos are just over an hour long; it probably took me at least three hours to record them.

If you plan to attend the live webinar session on September 12th, you might want to watch at least the first few videos before the live session - I will not waste everyone’s time repeating the demos during the live session.

Video: Networking Challenges

Whenever you’re discussing a complex topic it’s worth adhering to two principles: (A) identify the challenges you’re trying to solve and (B) start as simple as you can and add complexity later.

We did exactly that in the Introducing Networking Challenges part of How Networks Really Work webinar. We started with the simplest possible case of two computers connected with a cable… and even there identified a plethora of challenges that had to be solved more than half a century ago (and still have to be solved today no matter what magic software-defined technology someone pulls out of their wizard hat).

You need free ipSpace.net subscription to watch the video, or a paid ipSpace.net subscriptions to watch the rest of the webinar.

Must Read: When Redundancy Actually Helps

Stumbled upon an excellent redundancy-focused blog post (HT: High Scalability). Here are just a few important points:

• Don’t make things too complex;
• Don’t add more risk than you take away;
• You’ve got to fail over in the right direction;
• You must be able to return to fully-redundant mode.

I’m guessing that people promoting stretched VLANs, vSphere and/or NSX clusters running across multiple sites, weird combination of EVPN and OTV, and a dozen similar shenanigans never considered any one of these points.

Brief History of VMware NSX

I spent a lot of time during this summer figuring out the details of NSX-T, resulting in significantly updated and expanded VMware NSX Technical Deep Dive material… but before going into those details let’s do a brief walk down the memory lane ;)

You might remember a startup called Nicira that was acquired by VMware in mid-2012… supposedly resulting in the ever-continuing spat between Cisco and VMware (and maybe even triggering the creation of Cisco ACI).

The First Networking Fundamentals Videos are Online

In mid-June I started another pet project - a series of webinars focused on networking fundamentals. In the first live session on June 18th we focused on identifying the challenges one has to solve when building an end-to-end networking solution, and the role of layered approach to networking.

Not surprisingly, we quickly went down the rabbit holes of computer networking history, including SCSI cables, serial connections and modems… but that’s where it all started, and some of the concepts developed at that time are still used today… oftentimes heavily morphed by recursive application of RFC 1925 Rule 11.

Migrating ipSpace.net Infrastructure to AWS

I’m too stupid to unwind and relax over summer - there’s always some janitorial task to be done, and I simply cannot leave it alone. This summer, I decided to migrate our server infrastructure to AWS.

TL&DR: It went smoother than I expected, and figuring out how AWS virtual networks, public IP addresses, and security groups work while creating AWS Networking webinar definitely helped, but it also took way longer than I expected.

Reinventing Your Own STP Wheel…

One of my readers sent me a link to an interesting L2-over-IP "design". Someone tried to connect two data centers with redundant etherip links using home-brewed redundancy mechanism and (surprise, surprise) managed to bring both of them down. The obvious fix: patch the etherip device driver.

I don't know enough about OpenBSD to figure out whether (A) it doesn't have STP at all, (B) STP doesn't work over EtherIP, (C) host routing based on ARP entries would be too much of a hassle, (D) some people don't understand the networking fundamentals, (E) everything looks like a nail once you found a hammer, or (F) all of the above. Insightful comments would be highly appreciated.

Why You Can’t Fix a System from the Inside

Stumbled upon an interesting article describing numerous examples of how it's impossible to fix a system from the inside because the good guys always lose to the more aggressive (and less scrupulous) individuals.

It's amazing how well the same ideas apply to TCP-versus-UDP, P2P traffic versus everything else (this one has been fixed after a lot of pressure from the outside), latency- versus drop-based TCP congestion management and $vendor marketing.

Software Engineers and Network Automation

I was saying “you’ll get the best network automation (or SDN) results if you pair network engineers with software engineers” for ages, but there’s always someone else saying it more eloquently, in this case Jeremy Schulman in his recent blog post.

Jeremy will talk about ChatOps in Autumn 2019 Building Network Automation Solutions online course, but of course you’re more than welcome to ask him other questions as well.

Rant: Some Internet Service Providers Should Really Know Better…

I was listening to a nice podcast with Nick Buraglio discussing the recent BGP hijack SNAFU impacting Cloudflare (and their reaction) and while I usually totally agree with Nick, I think that he tried to be way too nice when saying (paraphrasing) “I think Cloudflare was a bit harsh - I would prefer a more community-oriented approach along the lines of how could we help you do your job better”

We Are on a Break ;)

It’s high time for another summer break (I get closer and closer to burnout every year - either I’m working too hard or I’m getting older ;).

Of course we’ll do our best to reply to support (and sales ;) requests, but it might take us a bit longer than usual. I will publish an occasional worth reading or watch out blog post, but don’t expect anything deeply technical for the new two months.

We’ll be back (hopefully refreshed and with tons of new content) in early September, starting with network automation course on September 3rd and VMware NSX workshop on September 10th.

In the meantime, try to get away from work (hint: automating stuff sometimes helps ;), turn off the Internet, and enjoy a few days in your favorite spot with your loved ones!

First-hand Feedback: ipSpace.net Network Automation Course

Daniel Teycheney attended the Spring 2019 Building Network Automation Solutions online course and sent me this feedback after completing it (and creating some interesting real-life solutions on the way):

I spent a bit of time the other day reflecting on how much I’ve learn’t from the course in terms of technical skills and the amount I’ve learned has been great. I literally no idea about things like Git, Jinja2, CI testing, reading YAML files and had only briefly seen Ansible before.

I’m not an expert now, but I understand these things and have real practical experience on these subjects which has given me great confidence to push on and keep getting better.

Device Configuration Synthesis with NetComplete on Software Gone Wild

When I was still at university the fourth-generation programming languages were all the hype, prompting us to make jokes along the lines “fifth generation will implement do what I don’t know how”

The research team working in Networked Systems Group at ETH Zurich headed by prof. Laurent Vanbever got pretty close. The description of their tool says:

Impact of Controller Failures in Software-Defined Networks

Christoph Jaggi sent me this observation during one of our SD-WAN discussions:

The centralized controller is another shortcoming of SD-WAN that hasn’t been really addressed yet. In a global WAN it can and does happen that a region might be cut off due to a cut cable or an attack. Without connection to the central SD-WAN controller the part that is cut off cannot even communicate within itself as there is no control plane…

A controller (or management/provisioning) system is obviously the central point of failure in any network, but we have to go beyond that and ask a simple question: “What happens when the controller cluster fails and/or when nodes lose connectivity to the controller?”

Real-Life SD-WAN Experience

SD-WAN is the best thing that could have happened to networking according to some industry “thought leaders” and $vendor marketers… but it seems there might be a tiny little gap between their rosy picture and reality.

This is what I got from someone blessed with hands-on SD-WAN experience:

Read Network Device Information with REST API and Store It Into a Database

One of my readers sent me this question:

How can I learn more about reading REST API information from network devices and storing the data into tables?

Long story short: it’s like learning how to drive (well) - you have to master multiple seemingly-unrelated tasks to get the job done.

How Microsoft Azure Orchestration System Crashed My Demos

One of the first things I realized when I started my Azure journey was that the Azure orchestration system is incredibly slow. For example, it takes almost 40 seconds to display six routes from per-VNIC routing table. Imagine trying to troubleshoot a problem and having to cope with 30-second delay on every single SHOW command. Cisco IGS/R was faster than that.

If you’re old enough you might remember working with VT100 terminals (or an equivalent) connected to 300 baud modems… where typing too fast risked getting the output out-of-sync resulting in painful screen repaints (here’s an exercise for the youngsters: how long does it take to redraw an 80x24 character screen over a 300 bps connection?). That’s exactly how I felt using Azure CLI - the slow responses I was getting were severely hampering my productivity.