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.

More information

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!

A long while ago, I wrote about the brokenness of socket API and lack of session layer in TCP/IP stack.

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.

Everyone talks about Linux containers these days like they would be the hottest thing invented this spring. In reality, it’s a pretty old technology that was heavily used by some smart web hosting companies for years (but of course, some people think mentioning Google makes everything look sexier).

If you’re interested in a high-level overview of differences between Linux containers and more traditional virtual machines, watch the video from the Introduction to Virtual Networking webinar.

Recently I was discussing the benefits and drawbacks of virtual appliances, software-defined data centers, and self-service approach to application deployment with a group of extremely smart networking engineers.

After the usual set of objections, someone said “but if we won’t become more flexible, the developers will simply go to Amazon. In fact, they already use Amazon Web Services.”