Cheers,
Brad

I’m not sure I understand your stance, though, with regard to distributed forwarding intelligence at the chassis level. When I made the comment before that I wasn’t too crazy about the fact that the UCS does not have any forwarding intelligence in the chassis, and that it has to forward traffic to the 6100s just to go from server blade to server blade in the same chassis, you opined that its a better approach to have predictable traffic flows.

THIS WAS MY COMMENT:

“By the way, that brings up another point I’m not too crazy about: the fact that the UCS chassis does not provide distributed intelligence, which forces intra-chassis traffic to get forwarded to the FEX, then up to the FI, and then right back down again. ”

THIS WAS YOUR ANSWER:

“Localizing intra-chassis traffic might be important if your data center is nothing more than (1) chassis, and there isn’t much bandwidth between your chassis and the network — but that’s simply not the case anymore. Once you add a second chassis you now have inter-chassis traffic that has a difference performance profile than the intra-chassis traffic.

That’s not the case with UCS. Whether you have (1) chassis, (2) chassis, or (20) chassis, all traffic patterns are consistent and predictable. This makes it easier to keep a consistent SLA in a virtual data center with VM’s moving from one chassis to the next. With UCS, the location of the workload is of little significance.”

So, I am trying to understand your philosophy (read; Cisco’s philosophy) when it comes to distributed forwarding intelligence. Is it better to forward all traffic to the network and have predictable flows and consistent SLAs, as you put it before? Or is it OK to have a hybrid model in which some flows will remain in the chassis and others will be forwarded to the LAN, as you are saying now?

Thanks

VMware themselves will be quick to disagree with you and make the case that the hypervisor software switch model provides the most flexibility, feature velocity, scalability, and more intelligent automated provisioning for the cloud. This was the case VMware made in some of the sessions at VMworld 2010. While VMware has a vested interest in the software switch model, some of that argument is pure marketing and turf defending, however they do make some valid points that I tend to agree with.

The hypervisor software switch will always be able to bring features to market faster than hardware based solutions. Example: Netflow, DHCP Snooping, ERSPAN, etc, already present in Nexus 1000V.

The hypervisor software switch does not have the same hard scalability limits (VM’s per host) as compared to hardware based solutions (VM-FEX, VEPA, etc.). Example with Cisco VM-FEX you can have around 50 VMs per host, versus 248 VM’s per host with Nexus 1000V.

If the hypervisor has all the visibility into the information about VMs, including a VMs relationship to other VMs (vApp), can it perhaps make a more intelligent decision about network services and policies that should be provisioned? I think so. How much this really matters remains to be seen.

Cheers,
Brad

The industry roadmap with regard to virtual server networking is clearly to bypass the ESX server’s hypervisor and offload all the switching functions from the software switch to the adjacent physical bridge, as in VN-link in hardware and VEPA.

If this is the case, I really don’t understand why an organization will invest tens or hundreds of thousands of dollars on the N1Kv?

Thanks,
Ken Henault

Either you or your documentation team need to spend some more time understanding your own product a little better. Here is a direct quote from Page 75 of the latest Virtual Connect 2.30 User Guide:

http://bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c01880580/c01880580.pdf

If Virtual Connect is set to map VLAN tags, VC-Enet modules accept incoming frames with valid server VLAN tags and translate server-assigned VLANs into corresponding internal network VLANs, thus placing the server packet on the correct network. When these frames reach the uplinks, network VLANs are once again translated into external data center VLANs. Similarly, VLANs are translated back to server-assigned VLANs (or stripped and untagged) before sending frames out to servers. This function allows for the possibility of configurations where server VLANs might not match external VLANs used on uplinks.

Am I reading that wrong?

Cheers,
Brad

Thanks,
Ken