Blog Posts in August 2019
After discussing the challenges one encounters even in the simplest networking scenario connecting two computers with a cable we took a short diversion into an interesting complication: what if the two computers are far apart and we can’t pull a cable between them?
Trying to answer that question we entered the wondrous world of transmission technologies. It’s a topic one can spent a whole life exploring and mastering, so we were not able to do more than cover the fundamentals of modulations and multiplexing technologies.
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 3rd;
- A week after that (September 10th) I’ll run a day-long VMware NSX workshop in Zurich;
- Azure Networking webinar series is starting on September 12th and continuing on September 24th;
- Lukas Krattiger will talk about service insertion in leaf-and-spine fabrics on September 17th.
Of course, we’ll keep going… our event calendar is fully packed till mid-November. More about that in a month.
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.
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
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.
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).
- 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.
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).
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.
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.
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.
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.