News Stay informed about the latest enterprise technology news and product updates.

VARs can help network teams gain control over virtual network switches

Networking pros struggle with visibility and control over virtual network switches. With new, emerging standards such as VN-Tagging and Virtual Ethernet Port Aggregator (VEPA), VARs can give control over virtual server networking back to networking pros.

With server virtualization, VARs have been able to help customers build dynamic data centers with advanced resource allocation and disaster recovery capabilities that allow them to scale applications fluidly. However, the fundamental disconnect between virtualization software and basic networking continues to dog efforts to make data center management a seamless experience.

Simply put, VARs struggle to help network administrators gain visibility and control over the virtual network switches that are embedded within hypervisors, making it difficult for them to apply network and security policies to virtual machines and to troubleshoot virtual machines.

Networking vendors have begun offering solutions to this problem. Cisco released the Nexus 1000v, a virtual software switch that sits in VMware ESX host and replaces its virtual switch. It gives networking teams a familiar interface for gaining visibility into hypervisor networking. Arista has introduced its vEOS, another virtual software switch that cooperates with VMware's virtual switches. Yet, for the most part, networking vendors are still struggling to offer tight integration between their network hardware and hypervisors' virtual switches.

Now, HP ProCurve and Cisco Systems are hashing out proposals for new standards for the consideration of the IEEE's 802.1 Working Group that could help all networking vendors and their VARs offer a solution to this problem.

Cisco has proposed a standard called VN-Tagging, also known as port extension, and ProCurve has proposed Virtual Ethernet Port Aggregation (VEPA). Originally, these proposals to the IEEE were competing, but now Cisco and ProCurve have actually come together and created something of a joint proposal with a spectrum of standards that include both VEPA and VN-Tagging, dubbed 802.1qbg and 802.1gbh, respectively. Both are on the verge of being accepted as new standards projects by the IEEE. Based on how the standards have evolved, VEPA will serve as something of a foundation for Cisco's more ambitious VN-Tagging approach

VEPA and multicasting

VEPA is the foundation of the proposed standard. It creates a series of "port profiles" with relevant security and network policy settings that can apply to various types of virtual machines provisioned by server administrators. When the virtual machine is instantiated, network frames are forwarded to an adjacent physical network switch, most likely the top-of-rack switch. That switch can then apply the appropriate port profile to the virtual machine and, depending on the preference of the enterprise, then send the profile back to the virtual network switch or replace it altogether.

The pending VEPA standard also contains a critical feature, known as multicasting, which is something of a hybrid of the proposals ProCurve and Cisco originally brought forward, said Joe Pelissier, principal engineer at Cisco.

Since many virtual servers contain more than one virtual network switch, physical switches need to be able to identify which virtual switch traffic is coming from. The multicasting element of VEPA will perform that task and allow physical switches to directly connect to those virtual switches. This more advanced feature will require some hardware upgrades, but the basic VEPA technology can be supported with a simple software upgrade.

VN-Tagging and port extension

Finally, Cisco's VN-Tagging approach is based on the notion that not all physical switches will have the advanced features that network administrators want to apply to virtual machines, such as QoS and security. While VEPA concerns itself only with connections between virtual machines and adjacent switches, Cisco's VN-Tagging introduces port-extender technology, allowing the traffic from a virtual machine to move up the network hierarchy to the switch that does have the needed features.

"Port extension allows you to replace a back-of-blade rack switch, for instance, with a device called a port extender, and the next-higher-up switch in the network becomes the adjacent switch," Pelissier said. "From the Cisco perspective, we were looking at it as a problem of how you manage large networks, especially networks with lots of embedded virtual switches in each switch," he said.

The notion of port extension will require hardware upgrades, however, since many existing switches just won't recognize the changes to packet formats that VN-Tagging will require, according to Paul Congdon, CTO of ProCurve and vice-chairman of the 802.1 Working Group.

"Cisco's approach was, 'We are 100% of the time going to bypass the hypervisor and force things out into the network,'" Congdon said. "We believe that there are situations [when] having local switching on the NIC for performance reasons is going to be important. Our approach with VEPA enables you to have both choices."

Will VEPA or VN-Tagging be profitable for vendors and the channel?

Steve Schuchart, principal analyst for Current Analysis, said a standard like VEPA has the potential to give all networking vendors a credible story in solving the problem of visibility and control over virtual network switches in hypervisors. Extreme Networks endorsed VEPA last week. Schuchart said he wouldn't be surprised to see other vendors, such as Juniper Networks, follow.

"At this point, the shortest path to market is VEPA," he said. "I've been waiting for something like this. I've been saying for the last several months there's got to be a way for other vendors to integrate more tightly with virtualized infrastructure and computing infrastructure, otherwise the market is only going to be IBM, HP, Dell and Cisco, and everyone else [in the networking industry] is frozen out."

Cisco's VN-Tagging, which will require network refreshes, may be a harder sell for some vendors. ProCurve's Congdon said his company isn't convinced that it will follow that path; but others may.

Eric Ustaoglu, director of data center technologies for Cisco VAR Bluewater Communications Group, said there are many options for enterprises whose networking teams are looking to get more visibility and control over virtual network switching.

"We were an original partner with the Nexus 1000v," Ustaoglu said. "We've been trying to educate both the networking and server teams [of our customers]. The networking teams have been very receptive. But the Nexus 1000v has been a challenge to implement. The networking teams have needed a lot of help from the server team because the 1000v is a virtual box, not a physical box. With a virtual 1000v switch, the two departments need to work together because the concept of importing that virtual switch into your environment is something the networking team can't do by themselves. Because we have expertise in both networking and virtualization, we're basically going in and doing the implementation and trying to unite the [networking and server] silos together."

If the IEEE approves the standards put forward by Cisco and ProCurve, the functions that Nexus 1000v performs for the network can be done on the hardware level, Ustaoglu said. In Cisco's case, he sees it being added to the Nexus 5000 and other switches. This advance will make the process easier for networking pros, who can work directly with the network hardware they're accustomed to in order to manage the switching that takes place with hypervisors.

He pointed out that Single Root I/O Virtualization (SRIOV) is another standard that's pending from PCI SIG. He said that Cisco will bring an adaptor to market for its Unified Computing System (UCS) servers that will allow companies to bypass the hypervisor's virtual switches and put it on the NICs.

"It's going to free things up so that the hypervisor is not worried about making any network decisions when it goes to the virtual switch," Ustaoglu said. "It's going directly to the hardware."

Outside a Cisco-only world, ProCurve's VEPA proposal holds a great deal of promise for other vendors.

"There is broad support across a large number of vendors for VEPA because it brings value and it does it in a very non-disruptive, cost-effective way. And because of the simplicity of it, it takes only about 120 lines of code [in a switch's operating system] to implement it," said Joe Skorupa, research vice president at Gartner. "Assuming no one tries to be obstructionist and tries to block the standard, this one should be able to go ahead relatively quickly. And if it can be implemented in just a software update, that's very good."

In addition to improved visibility and control for networking pros, VEPA should also improve performance, Skorupa said. A hypervisor's virtual switch consumes processing power and memory inside a physical switch, which affects performance. By pulling virtual switching out of the server, enterprises can improve server performance and even increase the number of virtual machines on each box.

"I have heard some arguments – I haven't seen the numbers yet – that pulling [virtual switching] out of the server, even if you have to go down the wire all the way to the top-of-rack switch and back again, you'd actually have higher performance and lower latency than you would get switching between two virtual machines on the same server," Skorupa said.

Let us know what you think about the story; email: Shamus McGillicuddy, News Editor

Dig Deeper on Managed network services technology

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.