We all know that the performance of virtual networking appliances (firewalls, load balancers, routers ... running inside virtual machines) really sucks, right? Some vendors managed to offload the packet-intensive processing into the hypervisor kernel, getting way more bang for the buck, but that’s a pretty R&D-intensive undertaking.

We also know that The Real Men use The Real Hardware (ASICs and FPGAs) to get The Real Performance, right? Wrong!

Three days ago IBM launched Distributed Virtual Switch 5000V, its own distributed vSwitch for VMware ESX platform. On one hand, it proves Cisco has been going the right way with Nexus 1000v (just in case you wondered), on the other hand, things just got way more interesting – IBM is obviously returning to networking.

Just before 2011 hit its expiration date, Derick Winkworth published Being Good at IT Stuff where among a gazillion things I totally agree with he also wrote “Even in IT, an IT degree is useless.”

I know exactly why he wrote that; I’d attended plenty of seemingly useless lectures (although it turns out sometimes it pays to understand those topics), and some people still think teaching History of Computer Engineering or obscure programming languages makes perfect sense.

I figured out I wrote a lot about Microsoft Network Load Balancing (NLB) without ever explaining how that marvel of engineering works. To fix that omission, here’s a short video taken from the Data Center 3.0 webinar.

Whenever the networking industry invents a new (somewhat radical) technology, bandwidth-on-demand seems to be one of the much-touted use cases. OpenFlow/SDN is no different – Juniper used its OpenFlow implementation (Open vSwitch sitting on top of Junos SDK) to demonstrate Bandwidth Calendaring (see Dave Ward’s presentation @ OpenFlow Symposium for more details), and Dmitri Kalintsev recently blogged “How about an ability for things like Open vSwitch ... to actually signal the transport network its connectivity requirements ... say desired bandwidth” I have only one problem with these ideas: I’ve seen them before.

One of my readers sent me the following question:

I know that if I purchase a single webinar, I can apply that cost toward a yearly subscription. Is it additive? If I start buying recordings one-by-one until I reach $200, will I be given the yearly subscription?

The answer is a qualified yes (and you can find all the details on my web site):

Numerous articles published in the last few days describing how Nicira clashes heads-on with Cisco and Juniper just proved that you should never let facts interfere with a good story (let alone eye-catching headline). Just in case you got swayed away by those catchy stories, here’s the real McCoy (as I see it):

I got intrigued when reading Nicira’s white paper claiming their Open vSwitch can run within vSphere/ESX hypervisor. There are three APIs that you could use to get that job done: dvFilter API (intercepting VM NIC like vCDNI does), the undocumented virtual switch API used by Cisco’s Nexus 1000v, or the device driver interface (intercepting uplink traffic). Turns out Nicira decided to use a fourth approach using nothing but publicly available APIs.

We have a public holiday today, so I’ll spend the morning with my kids instead of writing yet another whatever-does-not-scale post. However, I did stumble across two fantastic cartoons that I simply have to share with you.

Nicira, the OpenFlow startup behind the Open vSwitch, has finally dropped the stealthy cloak. Congratulations!!! Their web site is still pretty sparse on details, but you can get an initial impression of what they’re doing from a number of white papers describing Network Virtualization Platform and DVNI architecture. Short summary: I was almost right, but being a routing-and-switching bloke missed a few interesting bits – OpenFlow (and Open vSwitch) can easily combine security and forwarding functionality.

Two days ago I described how you can use tunneling or labeling to reduce the forwarding state in the network core (which you have to do if you want to have reasonably fast convergence with currently-available OpenFlow-enabled switches). Now let’s see what you can do in the very limited world of OpenFlow 1.0.

For whatever reason, Easy Virtual Network (EVN), a configuration sugar-glaze on top of VRF-lite (oops, multi-VRF) that has been lurking in the shadows for the last 18 months erupted into the twittersphere after Cisco’s latest switching launch. I can’t possibly understand why the implementation of a decade-old technology on mature platform (Catalyst 4500 and Catalyst 6500) makes news at the time when 40GE and 100GE interfaces were launched, but the intricacies of marketing always somehow escaped me.

Yesterday I described how the limited flow setup rates offered by most commercially-available switches force the developers of production-grade OpenFlow controllers to drop the microflow ideas and focus on state abstraction (people living in a dreamland usually go in a totally opposite direction). Before going into OpenFlow-specific details, let’s review the existing forwarding state abstraction technologies.

Last week I described the problems high-end service provider routers (or layer-3 switches if you prefer that terminology) face when they have to update large number of entries in the forwarding tables (FIBs). Will these problems go away when we introduce OpenFlow into our networks? Absolutely not, OpenFlow is just another mechanism to download forwarding entries (this time from an external controller) not a laws-of-physics-changing miracle.

Did you rush to try OSPF Loop-Free Alternate on a Cisco 7200 after reading my LFA blog post… and disappointedly discovered that it only works on Cisco 7600? The reason is simple: while LFA does add feasible-successor-like behavior to OSPF, its primary mission is to improve RIB-to-FIB convergence time.