Blog Posts in September 2020
Post-quantum cryptography (algorithms resistant to quantum computer attacks) is quickly turning into another steaming pile of hype vigorously explored by various security vendors.
Christoph Jaggi made it his task to debunk at least some of the worst hype, collected information from people implementing real-life solutions in this domain, and wrote an excellent overview article explaining the potential threats, solutions, and current state-of-the art.
You (RFC 6919) OUGHT TO read his article before facing the first vendor presentation on the topic.
The mission of ipSpace.net is very simple: explain new networking technologies and products in a no-nonsense marketing-free and hopefully understandable way.
Sometimes we’re probably way off the mark, but every now and then we get it just right as evidenced by this feedback from one of our subscribers:
I was given short notice to present a board-level overview of VMWare NSX-T for an urgent virtualization platform change from Microsoft. Tech execs needed to understand NSX-T’s position in the market, in its product lifecycle, feature advantages, possible feature deficits, and an idea of the level of effort for implementation.
Got this interesting question from one of my readers
Based on my experience, the documentation regarding Linux networking is either elementary man pages for user-space utilities or very complicated Linux kernel source code. Does getting deep into Linux networking mean reading source code?
It all depends on how deep you plan to go:
Russ White published an interesting story explaining why we’re using IP and not CLNS to build today’s Internet.
Let’s start with a few minor details he missed that I feel obliged to point out (apologies to Russ for being too pedantic, but you know me…):
In one of his recent blog posts Tom Hollingsworth described what I semi-consciously felt about the CCIE lab exam for at least 25 years: it’s full of contrived scenarios that look more like Iron Chef than real life.
I understand they had to make the lab harder and harder to stop cheating (because talking with candidates and flunking the incompetents is obviously not an option), and there’s only so much one can do with a limited set of technologies… but forcing networking engineers to find ever-more-devious ways to solve overly-complex problems is nothing else but fuel for rampant MacGyverism.
Anyway, I don’t think this mess will ever be fixed, so the only thing we can do is to enjoy the rant.
If you’re working solely with IP-based networks, you’re probably quick to assume that hop-by-hop destination-only forwarding is the only packet forwarding paradigm that makes sense. Not true, even today’s networks use a variety of forwarding mechanisms, most of them called some variant of routing or switching.
What exactly is the difference between the two, and what is bridging? I’m answering these questions (and a few others like what’s the difference between data-, control- and management planes) in the Bridging, Routing and Switching Terminology video.
In March I explained why it’s unrealistic to expect to use machine learning to solve unknown problems in today’s snowflake networks… but are there other problems that could be solved?
I have NEVER found a customer application team that can tell me all the servers they are using, their IP addresses, let alone the ports they use.
His proposed solution: use software like Tetration (or any other flow collecting tool) to figure out what’s really going on:
Getting Docker to work with IPv6 is an interesting and under-documented (trying to stay diplomatic) adventure, but there’s a shortcut to the promised land: even if your Docker environment is pure IPv4 morass, you can still reach published container ports over IPv6 thanks to the userland proxy I described last week. The performance is obviously commensurate with traversing kernel-user boundary too many times.
New to this rabbit hole? Start here.
Finally, you don’t have to tell me (again) that Docker is dead and we should all use K8s. It’s as useful as telling me CloudStack is dead and we should all use OpenStack. Different challenges deserve different tools.
Remember my rants about VMware and firewall vendors promoting crazy solutions that work best in PowerPoint and cause more headaches than anything else (excluding increased vendor margins and sales team bonuses, of course)?
Here’s another we-don’t-need-all-that-complexity real-life story coming from one of my long-term subscribers:
If you’re like me, you’re probably sick-and-tired of Python versions, environments… Every time I update Python on my MacBook Pro with Homebrew, I lose all packages I installed for the previous version of Python (because I’m installing them system-wide and they’re stored in version-specific directory).
Jon Langemak found a potential solution to this problem: PyEnv. My first reaction was: Great, just what I need… but as he described how it really works, I realized that it’s always possible to add another layer of indirection. RFC1925 strikes again.
One of the weekend reads collected by Russ White contained a pointer to a hilarious description of blockchain - a solution in search of a problem. Here are a few quotes to get you started (and I had a really hard time selecting just a few):
I’ve never seen so much bloated bombast fall so flat on closer inspection.
At its core, blockchain is a glorified spreadsheet.
The only thing is that there’s a huge gap between promise and reality. It seems that blockchain sounds best in a PowerPoint slide.
Someone should use that article as a framework and replace blockchain with OpenFlow or SDN ;)
After covering the Cisco SD-WAN components and its architecture in the Cisco SD-WAN Foundations and Design Aspects webinar, David Penaloza focused on the routing capabilities it offers and its control plane characteristics, including types of routes and some scalability recommendations.
Every now and then I call someone’s baby ugly (or maybe it was their third cousin’s baby and they nonetheless feel offended). In such cases a common resort is to cite business or market needs to prove how ignorant and clueless I am. Here’s a sample LinkedIn comment talking about my ignorance about the need for smart NICs:
The rise of custom silicon by Presando [sic], Mellanox, Amazon, Intel and others confirms there is a real market need.
Now let’s get something straight: while there are good reasons to use tons of different things that might look inappropriate, irrelevant or plain stupid to an outsider, I don’t believe in real market need argument being used to justify anything without supporting technical facts (tell me why you need that stuff and prove to me that using it is the best way of solving a problem).
Perhaps a paradigm shift is due for firewalls in general? I’m thinking quickly here but wondering if we perhaps just had a protocol by which a host could request upstream firewall(s) to open access inbound on their behalf dynamically, the hosts themselves would then automatically inform the security device what ports they need/want opened upstream.
Now let’s peek behind the curtain and explore how Docker uses iptables to publish container ports, and why it runs a userland proxy process for every published port.
For even more details, explore the Docker Networking Deep Dive webinar.
A friend of mine involved in multiple Cisco ACI installations sent me this comment on their tenant connectivity model:
I’m a bit allergic to ACI. The abstraction is mis-aligned with familiar configurations, in particular contracts being independent of and over-riding routing, tenants, etc. You can really make a mess with that, and I’ve seen some! One needs to impose some structure, naming conventions…, and most people don’t seem to get that done.
As I noticed in the NSX-or-ACI webinar, it’s interesting how NSX decided to stay with the familiar VLAN/routing/filtering paradigm (more details), whereas the designers of Cisco ACI decided to go down a totally different path.
CPU is not designed for the purpose of packet forwarding. One example is packet order retaining. It is impossible for a multicore CPU to retain the packet order as is received after parallel processing by multiple cores. Another example is scheduling. Yes CPU can do scheduling, but at a very high tax of CPU cycles.
Years ago I was naive enough to participate in writing an IETF document. Three years later we finally managed to turn it into an RFC, and I decided that was enough for one lifetime.
But wait, it gets worse… as Geoff Huston argues in his article, the lengthy review process doesn’t necessarily result in better (or more precise) documents.
Seems like we managed to turn IETF into yet another standard body like IEEE, ISO or ITU/T.
Earlier this year, Pete Lumbis returned as an ipSpace.net webinar guest speaker with a great presentation describing data center switching ASICs from the perspective of networking engineers. After a brief intro, he started with ASIC Basics… a topic which generated a 25-minute Q&A session.
Several engineers formerly working for a large virtualization vendor were pretty upset with me when I claimed that the virtualization consultants promote “disaster recovery using stretched VLANs” designs instead of alternatives that would implement proper separation of failure domains.
Guess what… it’s even worse than I thought.
Here’s a sequence of comments I received after reposting one of my “disaster recovery doesn’t need stretched VLANs” blog posts on LinkedIn sometime in late 2019:
We did a number of Software Gone Wild podcasts trying to figure out whether smart NICs address a real need or whether it’s just another vendor attempt to explore all potential markets. As expected, we got opposing views from Luke Gorrie claiming a NIC should be as simple as possible to Silvano Gai explaining how dedicated hardware performs the same operations at lower cost, lower power consumption and way higher speeds.
In theory, there’s no doubt that Silvano is right. Just look at how expensive some router line cards are, and try to figure out how much it would cost to get 25.6 Tbps of forwarding performance that we’ll get in a single ASIC (Tomahawk-4) in software (assuming ~10 Gbps per CPU core). High-speed core packet forwarding has to be done in dedicated hardware.
When planning to move your workloads to a public cloud you might want to consider the minor detail of public IPv4 connectivity (I know of at least one public cloud venture that couldn’t get their business off the ground because they couldn’t get enough public IPv4 addresses).
Here’s a question along these lines that one of the attendees of our public cloud networking course sent me:
You might remember my occasional rants about lack of engineering in networking. A long while ago David Barroso nicely summarized the situation in a tweet responding to my BGP and Car Safety blog post:
If we were in a proper engineering we’d be discussing how to regulate and add safeties to an important tech that is unsafe and hard to operate. Instead, we blog about how to do crazy shit to it or how it’s a hot mess. Let’s be honest, if BGP was a car it’d be one pulled by horses.
Justin Pietsch published another must-read article, this time dealing with operational complexity of load balancers and IP multicast. Here are just a few choice quotes to get you started:
- A critical lesson I learned is that running out of capacity is the worst thing you can do in networking
- You can prevent a lot of problems if you can deep dive into an architecture and understand it’s tradeoffs and limitations
- Magic infrastructure is often extremely hard to troubleshoot and debug
You might find what he learned useful the next time you’re facing a unicorn-colored slide deck from your favorite software-defined or intent-based vendor ;))
In December 2019 I finally turned my focus on business challenges first presentation into a short webinar session (part of Business Aspects of Networking Technologies webinar) starting with defining the problem before searching for a solution including three simple questions:
- What BUSINESS problem are you trying to solve?
- Are there good-enough alternatives or should you really invest into new technology and/or equipment?
- Is the problem worth solving?
Having spent my career in various roles in IT security, Ivan and I always bounced thoughts on the overlap between networking and security (and, more recently, Cloud/Container) around. One of the hot challenges on that boundary that regularly comes up in network/security discussions is the topic of this blog post: microsegmentation and host-based firewalls (HBFs).
- Security groups to restrict access to web server and SSH bastion host;
- An IAM policy and associated user that has read-only access to EC2 and VPC resources (used for monitoring)
- An IAM policy that has full access to as single S3 bucket (used to modify static content hosted on S3)
- An IAM role for AWS CloudWatch logs
- Logging SSH events from the SSH bastion host into CloudWatch logs.
Last week I published an overview of how complex (networking-wise) Docker Swarm services can get. This time let’s focus on something that should have been way simpler: running container-based services on a single Linux host.
In the first part of this article I’m focusing on the basics, including exposed ports, and published ports. The behind-the-scenes details are coming in a week or so; in the meantime you can enjoy (most of them) in the Docker Networking Deep Dive webinar.