It took years before the rumored Cisco vSwitch materialized (in the form of Nexus 1000v), several more years before there was the first competitor (IBM Distributed Virtual Switch), and who knows how long before the third entrant (recently announced HP vSwitch) jumps out of PowerPoint slides and whitepapers into the real world.

Compare that to the Hyper-V environment, where we have at least two virtual switches (Nexus 1000V and NEC's PF1000) mere months after Hyper-V's general availability.

The difference: Microsoft did the right thing, created an extensible vSwitch architecture, and thoroughly documented all the APIs (there's enough documentation that you can go and implement your own switch extension if you're so inclined).

A short video taken from Virtual Firewalls webinar describes the extensible architecture of Hyper-V virtual switch.

Short Summary

• A switch extension can be a capturing, filtering, or forwarding extension;
• Capturing extensions can capture packets and generate their own packets (example: report to an sFlow collector, implement ERSPAN functionality);
• Filtering extensions can inspect, drop (traffic policing or filtering) or delay (traffic shaping) packets, as well as generate their own packets;
• Forwarding extensions can do all of the above, plus replace the default forwarding rules (specify their own set of output ports). Each packet can be set to one or more output ports to implement flooding, multicast, or SPAN-like behavior.
• Each extension is called twice, first on the Ingress path (input VM or port to switch), then (when the set of destination physical or virtual ports is known) on the Egress path (switch to set of output ports).

It seems Microsoft really learned the hard lessons of the circuitous history of virtual networking, and it looks like they did the right thing … assuming the highly extensible mechanism they implemented doesn’t bog down the switching performance. Time to do some performance tests. Any volunteers?