Blog Posts in June 2014
The Mice and Elephants is a traditional QoS fable – latency-sensitive real time traffic (or request-response protocol like HTTP) stuck in the same queue behind megabytes of file transfer (or backup or iSCSI) traffic.
The solution is also well known – color the elephants pink (aka DSCP marking) and sort them into a different queue – until the reality intervenes.
True old-timers might appreciate the analogies I got while writing the Network Infrastructure as Code article. Let’s start with “do you remember this thingy?”
If you recognized the state-of-the-art (in those days) box in the picture, you might be able to relate to this screenshot:
This is pretty close to some SDN architectures I was privileged to see in the last three years.
Source: strategic humor @ HBR
I was asked to do a presentation at the recent Slovenian NOG (SINOG) meeting. I did an SDN one at the previous meeting, making NFV the next obvious choice… but I decided to put an interesting spin on it and focused on virtual routers.
When I heard people talking about “networking infrastructure as code” I dismissed that as yet another Software-Defined-Everything one-controller-to-rule-it-all hype. Boy was I wrong.
Last September I received a peculiar tweet from Luke Gorrie pointing me to a software switch pushing 200 Gbps through an Intel server literally hours after I’d watched the Deutsche Telekom Terastream presentation, so I mentioned Luke’s Snabb Switch as a potential performance solution in an email to Ian Farrer… and before Ian managed to reply, Luke was already working for Deutsche Telekom.
Carlos Mendioroz sent me an interesting question about unnumbered interfaces in Cumulus Linux and some of the claims they make in their documentation.
TL&DR: Finally someone got it! Kudos for realizing how to use an ancient trick to make data center fabrics easier to deploy (and, BTW, the claims are exaggerated).
After the excellent IPv6 security presentation Eric Vyncke had @ 9th Slovenian IPv6 summit someone asked me: “Why is IPv6 first-hop security so complex? It looks like the developers of IPv6 protocol stack tried to make users anonymous and made everyone’s life complex while doing that.”
Well, he was totally surprised by my answer: “The real reason IPv6 first-hop security is so complex is the total mess we made of L2/L3 boundary.”
Tired of endless debates discussing trivial matters? You're not alone (bonus point: a few pop-up windows every mail client should have).
The “bring Amazon Web Services mentality back home” blog post generated the expected comments, from “developers have no clue about networking or network services” to “we went through the whole thing and failed badly.”
Well, even though it might have seemed so, I didn’t advocate letting the developers go unchecked, I was just pointing out that double standards make no sense.
After months of being on a back burner, my first self-publishing book is out: Data Center Design Case Studies are available on my web site (Amazon Kindle version coming whenever I find time to figure out all the details).
Subscribers can download the book immediately (you’ll find it in the new Books section), as can anyone who bought the Designing Private Cloud Infrastructure webinar (you’ll find it in the webinar materials), and you can buy a copy on my web site.
Update 2014-06-18 05:13Z - We slashdotted Christoph's site yesterday. He moved to a new server during the night; the links should work now.
Christoph Jaggi focused on analyzing Metro Ethernet and Carrier Ethernet encryption gear. The introductory part of this year’s report has just been published and it’s definitely worth reading even if you have no immediate plans to buy such gear – it’s a nice overview document covering numerous encryption technologies, key distribution systems, network topologies, and operational aspects. If you want to get in-depth evaluation of individual vendors or solutions, you’ll obviously have to contact Christoph.
Most recently launched data center switches use the Trident 2 chipset, and yet we know almost nothing about its capabilities and limitations. It might not work at linerate, it might have L3 lookup challenges when faced with L2 tunnels, there might be other unpleasant surprises… but we don’t know what they are, because you cannot get Broadcom’s documentation unless you work for a vendor who signed an NDA.
Interestingly, the best source of Trident 2 technical information I found so far happens to be the Cisco Live Nexus 9000 Series Switch Architecture presentation (BRKARC-2222). Here are a few tidbits I got from that presentation and Broadcom’s so-called datasheet.
I found two interesting data center/virtualization blogs this week (can’t remember the last time I found two new blogs in a week):
- Pedro Marques’ blog – it focuses primarily on Open Contrail, but you’ll find interesting gems questioning the wisdom of OpenFlow and Segment Routing (among other things);
- Aldrin Isaac’s blog – unfortunately he stopped writing in the last months, but some of his older posts are pure gold.
Enjoy – and poke Aldrin to continue writing ;)
Jure Špiler, an old friend of mine (and my first boss) sent me a link to a fantastic YouTube video documenting how we did programming on PDP-11 computers when I started my programming career (note: I did not enter compiled assembly code with console switches on PDP-11, but I did do that on an 6800-based box with 2K of RAM).
Related videos tab revealed another gem: PDP-11/34 with RL-01 disk drives – the very same system where I started my IT career as a high-school kid. Enjoy!
It looks like I’m not the only one with heretic opinions; Fred Baker reached similar conclusions in his Happier Eyeballs draft and Brian Carpenter recently published a lengthy article title IP Addresses Considered Harmful which documents (among other things) the history of socket API and the reasons DNS isn’t tightly integrated with it. Both documents are definitely worth reading.
Overlay virtual networks were the first commercial-grade OpenFlow use case – Nicira’s Network Virtualization Platform (NVP – rebranded as VMware NSX for Multiple Hypervisors after the acquisition, and finally rearchitected into VMware NSX-T) used OpenFlow to program the hypervisor virtual switches (Open vSwitches – OVS).
OpenStack is using the same approach in its OVS Neutron plugin, and it seems Open Daylight aims to reinvent that same wheel, replacing OVS plugin running on the hypervisor host agent with central controller.
Does that mean one should always use OpenFlow to implement overlay virtual networks? Not really, OpenFlow is not exactly the best tool for the job.
I know numerous engineers who decided to pursue a career in networking because they didn’t want to deep-dive into programming. Will that change when the Software Defined Everything takes over the world?
TL&DR summary: Of course not.
One of my readers sent me an interesting question:
I have been reading at many places about "throwing more bandwidth at the problem." How far is this statement valid? Should the applications(servers) work with the assumption that there is infinite bandwidth provided at the fabric level?
Moore’s law works in our favor. It’s already cheaper (in some environments) to add bandwidth than to deploy QoS.
Some of the comments I get every time I write about the idea of merging network services deployment with application deployments, and making application developers responsible for the results of their code (aka DevOps) remind me of a very long list of “this will never work” sentiments I encountered in the 30 years I spent in IT and networking. Here are just a few of them:
I’m not sure I wrote about the taxonomy of numerous virtual networking implementations. Just in case, here it is ;)
Layer-2 or layer-3 networks?
Some virtual networking solutions emulate thick coax cable (more precisely, layer-2 switch), giving their users the impression of having regular VLAN-like layer-2 segments.
One of my readers wanted to deploy FCoE on UCS in combination with Nexus 1000v and wondered how the FCoE traffic impacts QoS on Nexus 1000v. He wrote:
Let's say I want 4Gb for FCoE. Should I add bandwidth shares up to 60% in the nexus 1000v CBWFQ config so that 40% are in the default-class as 1kv is not aware of FCoE traffic? Or add up to 100% with the assumption that the 1kv knows there is only 6Gb left for network? Also, will the Nexus 1000v be able to detect contention on the uplink even if it doesn't see the FCoE traffic?
As always, things aren’t as simple as they look.
Last Friday my students attending this year’s Designing Scalable Web Applications course presented their semester-long assignments. I can’t tell you how pleasantly surprised I was – the results were much better and more polished than what I’ve seen during the previous years.