In criticizing software-only overlays for network virtualization, two points Cisco continually brings up are hypervisor dependency and the need to touch all endpoints when network changes are made. But VMware, the chief target of Cisco's criticism, takes issue with both counts.
With the first, VMware's NSX software is installed in many multi-hypervisor hybrid environments and some with non-VMware hypervisors, says Martin Casado, the company's chief architect of networking. Some of those deployments include eBay, Rackspace and AT&T.
"We've supported multiple hypervisors since forever," Casado says. "Since the inception of the product. That was the whole goal. We've got deployments with every hypervisor today. It's pretty clear that it's not dependent on any specific hypervisor.
"I'm not sure how to reconcile this position Cisco's taking."
NSX supports Citrix XenServer and Red Hat KVM as well as VMware ESX, he says. Support for Microsoft Hyper V is coming. And if the point Cisco's trying to make is that software overlays require a hypervisor, well, NSX can also run on bare metal servers without one, Casado claims. It can create tunnels from a Linux endpoint, he says.
What's more, all of the features - logical switching, logical routing, logical firewalls, etc. -- are in software across all hypervisors. It doesn't take a lengthy ASIC spin to implement them in a virtualized network. It only takes a software upgrade.
The second criticism has to do with scale. Cisco claims that whenever changes are made to the network, the network services, the application profiles and policies, they have to be reflected at all of the endpoints in a software-only overlay, which limits scale. Cisco's Application Centric Infrastructure has a database of tables that are continuously available in the ACI spine switch through the Insieme-developed "Alpine" ASIC, says Insieme founder Mario Mazzola.
Casado says NSX can reflect policy and profile changes at the top-of-rack switches as well as at the endpoints. And he says there's no performance or scale detriment to updating them at the endpoints anyway.
"Policy is not myopically focused on the network, it touches all pieces of the infrastructure - compute, network, storage," Casado says. "There's a limited amount of state to declare that. Independent of where you put that state, that state still exists. It's no easier or harder for me to put state on the edge than it is in the switch, it's still the same exact amount of state."
And enforcing it at the endpoint, where the hypervisor and vSwitch reside, allows easier mapping of VM UUIDs to port numbers every time a VM is moved, Casado says. In order to enforce policy and track events, you have to know the UUID.
But Casado also points out that reflecting policy changes at the top-of-rack leaf or at the spine requires keeping state on everything connected to the physical switch ports as well as the multiple VMs per port; if a top-of-rack switch enforces ACLs for every physical endpoint connected to its 48 ports, it also has to enforce those ACLs for multiple VMs on each port.
"This is a problem we've seen in physical networks for some time," he says. "With the proliferation of virtualization, you have 40 times as many MACs that would be on the network as well, and this can overrun MAC tables. Traditional network gear in virtualized environments has had huge issues with MAC tables. We have a long history of running out of hardware tables that we can easily alleviate in software."
More from Cisco Subnet:
The Cisco Subnet blog is written by Network World managing editor Jim Duffy Visit the Cisco Subnet home page daily and while you are there, subscribe to the Cisco Alert e-mail newsletter, which includes news and views generated by the Cisco Subnet community as well as Cisco-related stories on Network World and elsewhere on the Web.
Follow Jim Duffy on Twitter