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.”

During yesterday’s Data Center Fabrics Update presentation, one of the attendees sent me this question while I was talking about the Arista 7300 series switches:

Is the 7300 really non-blocking at all packet sizes? With only 2 x Trident-2 per line card it can't support non-blocking for small packets based on Trident-2 architecture.

It was an obvious example of vendor bickering, so I ignored the question during the presentation, but it still intrigued me, so I decided to do some more research.

A long while ago there was an interesting discussion started by Brad Hedlund (then at Dell Force10) comparing leaf-and-spine (Clos) fabrics built from fixed-configuration pizza box switches with high-end chassis switches. The comments made by other readers were all over the place (addressing pricing, wiring, power consumption) but surprisingly nobody addressed the queuing issues.

This blog post focuses on queuing mechanisms available within a switch; the next one will address end-to-end queuing issues in leaf-and-spine fabrics.

Idiots posting random comments with (not-so-very) hidden links to whatever warez they're selling are utterly annoying, but there's always one-in-a-million chance for a hilarious one. This is what I got on the Traffic Trombone post:

The traffic across the network core and the end-to-end latency would be minimal (the same packet would traverse the core only once), increasing visits to my adult site.

HP representatives made some pretty bold claims during Networking Tech Field Day 1, including “our switches will support EVB, FCoE, SPB and TRILL.” I took them three years to deliver on those promises (and the hardware they had at that time doesn’t exactly support all features they promised), but their current protocol coverage is impressive.

A while ago Paul Stewart wrote a fantastic blog post listing the potential business benefits of SDN (as promoted by SDN evangelists and SDN-washing vendors).

Here’s his list:

After the Designing Private Cloud Infrastructure workshop I had in Slovenia last week (in a packed room of ~60 people), someone approached me with a simple question: “I like the idea of using overlay virtual networks in my private cloud, but where do I start?”

A while ago I wrote “vMotion over VXLAN is stupid and unnecessary” in a comment to a blog post by Duncan Epping, assuming everyone knew the necessary background details. I was wrong (again).

Recently I had a fantastic conversation with Erich Hohermuth, a networking engineer with an unusual hobby: he’s a professional firefighting instructor (teaching firefighters across the country how to do their job).

Volunteer fire departments are pretty popular in Central European countries, and so he’s not the only one on his team with that skillset. The (not so unexpected) side effect: these people are the best ones when it comes to fighting IT disasters.

Good news: In the last few months, almost all major data center Ethernet switching vendors (Arista, Cisco, Dell Force 10, HP, and Juniper) released documented GA version of OpenFlow on some of their data center switches.

Bad news: no two vendors have even remotely comparable functionality.

One of my readers sent me this question:

I have a data center with huge L2 domains. I would like to move routing down to the top of the rack, however I’m stuck with a load-balancing question: how do load-balancers work if you have routed network and pool members that are multiple hops away? How is that possible to use with Direct Return?

There are multiple ways to make load balancers work across multiple subnets:

Craig Matsumoto recently quoted some astonishing claims from Dell’Oro Group analyst Alan Weckel:

• Whitebox switches (combined) will be the second largest ToR vendor;
• Whitebox 10GE ports will cost around $100.

Let’s try to guestimate how realistic these claims are.