VMware NSX With Cisco

4/2/2014 Seven reasons VMware NSX, Cisco UCS and Nexus are orders of magnitude more awesome together | The Network Virtualization Blog - VMware Blogs

https://blogs.vmware.com/networkvirtualization/2013/09/vmware_nsx_cisco.html 1/31

Tweet 3 0Like Share 3

Home (http:/ / communities.vmware.com) > Blogs (http:/ / blogs.vmware.com) > The Network Virtualization Blog

The Network Virtualization Blog(https://blogs.vmware.com/networkvirtualization)

Seven reasons VMware NSX, Cisco UCS and Nexus are orders ofmagnitude more awesome together

Posted on September 4, 2013 (https:/ /b logs.vmware.com/networkvirtualization/2013/09/vmware_nsx_cisco.html) by Brad Hedlund(https:/ /b logs.vmware.com/networkvirtualization/author/b rad_hedlund)

VMware NSX, Cisco UCS and Cisco Nexus, TOGETHER solve many of the most pressing issues at the

intersection of networking and virtualization.

Executive Summary

VMware NSX (http://blogs.vmware.com/networkvirtualization/2013/08/vmware-nsx.html) brings industry-leading network

virtualization (http://blogs.vmware.com/networkvirtualization/2013/06/18.html) capabilities to Cisco UCS and Cisco

Nexus infrastructures, on any hypervisor, for any application, with any cloud managementplatform. Adding state of the art virtual networking (VMware NSX) to best-in-class physicalnetworking (Cisco UCS & Nexus) produces significant optimizations in these key areas:

Provision services-rich virtual networks in seconds

Orders of magnitude more scalability for virtualization

The most efficient application traffic forwarding possible

Orders of magnitude more firewall performance

Sophisticated application-centric security policy

More intelligent automation for network services

(/ )VMware.com (http://www.vmware.com) Communities (http://communities.vmware.com)

Share 178

https://twitter.com/intent/tweet?original_referer=https%3A%2F%2Fblogs.vmware.com%2Fnetworkvirtualization%2F2013%2F09%2Fvmware_nsx_cisco.html&text=Seven%20reasons%20VMware%20NSX%2C%20Cisco%20UCS%20and%20Nexus%20are%20orders%20of%20magnitude%20more%20awesome%20together&tw_p=tweetbutton&url=https%3A%2F%2Fblogs.vmware.com%2Fnetworkvirtualization%2F2013%2F09%2Fvmware_nsx_cisco.html

http://twitter.com/search?q=https%3A%2F%2Fblogs.vmware.com%2Fnetworkvirtualization%2F2013%2F09%2Fvmware_nsx_cisco.html

http://communities.vmware.com/

http://blogs.vmware.com/

https://blogs.vmware.com/networkvirtualization

https://blogs.vmware.com/networkvirtualization/2013/09/vmware_nsx_cisco.html

https://blogs.vmware.com/networkvirtualization/author/brad_hedlund

http://blogs.vmware.com/networkvirtualization/2013/08/vmware-nsx.html

http://blogs.vmware.com/networkvirtualization/2013/06/18.html

https://blogs.vmware.com/

http://www.vmware.com/

http://communities.vmware.com/



Best-of-breed synergies for multi data center

More simplified network configurations

Cisco UCS and Nexus 7000 infrastructure awesomeness

A well-engineered physical network always has been and will continue to be a very important part ofthe infrastructure. The Cisco Unified Computing System (UCS) is an innovative architecture thatsimplifies and automates the deployment of stateless servers on a converged 10GE network. CiscoUCS Manager simultaneously deploys both the server and its connection to the network throughservice profiles and templates; changing what was once many manual touch points across disparateplatforms into one automated provisioning system. That’s why it works so well. I’m not just sayingthis; I’m speaking from experience (http://bradhedlund.com/2011/03/08/cisco-ucs-networking-videos-in-hd-updated-

improved/) .

Cisco UCS is commonly integrated with the Cisco Nexus 7000 series(http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/white_paper_c11-623265.html) ; a high-performancemodular data center switch platform with many features highly relevant to virtualization, such asconverged networking (FCoE), data center interconnect (OTV), Layer 2 fabrics (FabricPath, vPC), andlocation independent routing with LISP. This typically represents best-in-class data center physicalnetworking.

With Cisco UCS and Nexus 7000 platforms laying the foundation for convergence and automation inthe physical infrastructure, the focus now turns to the virtual infrastructure. VMware NSX, whendeployed with Cisco UCS and Cisco Nexus, elegantly solves many of the most pressing issues atthe intersection of networking and virtualization. VMware NSX represents the state of the art forvirtual networking.

1) Virtualization-centric operational model for networking

http://bradhedlund.com/2011/03/08/cisco-ucs-networking-videos-in-hd-updated-improved/

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/white_paper_c11-623265.html



VMware NSX adds network virtualization capabilitiesto existing Cisco UCS and Cisco Nexus 7000-basedinfrastructures, through the abstraction of the virtualnetwork, complete with services such as logicalswitching, routing, load balancing, security, andmore. Virtual networks are deployedprogrammatically with a similar speed andoperational model as the virtual machine — create,start, stop, template, clone, snapshot, introspect,delete, etc. in seconds.

The virtual network allows the applicationarchitecture (including the virtual network and virtualcompute) to be deployed together from policy-based templates, consolidating what was oncemany manual touch points across disparateplatforms into one automated provisioning system.In a nutshell, VMware NSX is to virtual servers andthe virtual network what Cisco UCS is to physicalservers and the physical network.

2) More headroom for virtualization, by orders of

magnitude (P*V)

VMware NSX provides the capability to dynamically provision logical Layer 2 networks forapplication virtual machines across multiple hypervisor hosts, without any requisite VLAN or IPMulticast configuration in the Cisco UCS and Cisco Nexus 7000 infrastructure. For example,thousands of VXLAN logical Layer 2 networks can be added or removed programmatically throughthe NSX API, with only a few static infrastructure VLANs; compared to what was once thousands ofmanually provisioned VLANs across hundreds of switches and interfaces.



Figure: NSX dynamic logical Layer 2 networks

Two of the most common breaking points when scaling a network for virtualization are:

Limited number of STP logical port instances the switch control plane CPUs can support, placing a

ceiling on VLAN density.

Limited MAC & IP forwarding table resources available in switch hardware, placing a ceiling on

virtual machine density.

VLANs and virtual machines; two things you don’t want a visible ceiling on. Fortunately, VMwareNSX provides significant headroom for both, by orders of magnitude, for the simple reason thatVLAN and STP instances are dramatically reduced; and hardware forwarding tables are utilizedmuch more efficiently.

Consider (P * V ) = T. Switch ports * number of active VLANs = STP logical ports.

One thousand fewer infrastructure VLANs with VMware NSX translates into one thousand timesfewer STP logical port instances loading the Cisco UCS and Nexus 7000 control plane CPUs. Thiscan only help ongoing operational stability, along with the obvious scaling headroom.

Consider (P * V ) = D. Physical hosts * VMs per host equals virtual machine density.

Normally, the size of the MAC & IP forwarding tables in a switch roughly determines the ceiling oftotal virtual machines you can scale to (D), as each virtual machine requires one or more entries.With VMware NSX, however, virtual machines attached to logical Layer 2 networks do not consumeMAC & IP forwarding table entries in the Cisco UCS and Nexus 7000 switch hardware. Only thephysical hosts require entries. In other words, with VMware NSX, the ceiling is placed on themultiplier (P ), not the total (D).

Reduced VLAN sprawl and logical Layer 2 networks compound to both simplify the Cisco UCS andNexus configurations and significantly extend the virtualization scalability and virtual life of theseplatforms.

―

1 1

2 2

2



3) Most efficient application traffic forwarding possible

Have you ever noticed the paradox that good virtualization is bad networking? For example, thenetwork design that works best for virtualization (Layer 2 fabric) isn’t the best design for Layer 3traffic forwarding, and vice versa. That is, until now.

VMware NSX provides distributed logical Layer 3 routing capabilities for the virtual networksubnets at the hypervisor kernel. Each hypervisor provides the Layer 3 default gateway, ARPresolver, and first routing hop for its hosted virtual machines. The result is the most efficientforwarding possible for east-west application traffic on any existing Layer 2 fabric design, mostnotably Cisco UCS.

Figure: NSX Distributed Layer 3 routing — intra host

In the diagram above, VMware NSX distributed logical routing provides east-west Layer 3forwarding directly between virtual machines on the same Cisco UCS host, without any hairpin hops

―



to the Cisco Nexus 7000 — the most efficient path possible.

VMware NSX spans multiple Cisco UCS hosts acting as one distributed logical router at the edge.Each hypervisor provides high performance routing only for its hosted virtual machines in the kernelI/O path, without impact on system CPU. Layer 3 traffic between virtual machines travels directlyfrom source to destination hosts inside the non-blocking Cisco UCS fabric — the most efficient pathpossible.

Figure: NSX Distributed Layer 3 routing — inter host

This efficient Layer 3 forwarding works with the existing Cisco UCS Layer 2 fabric, keeping moreeast-west application traffic within the non-blocking server ports, minimizing traffic on the feweruplink ports facing the Cisco Nexus 7000 switches.

With Layer 3 forwarding for the virtual network handled by the hypervisors on Cisco UCS, the CiscoNexus 7000 switch configurations are simpler; because VMware NSX distributed routing obviatesthe need for numerous configurations of virtual machine adjacent Layer 3 VLAN interfaces (SVIs) andtheir associated HSRP settings.

―



Note: HSRP is no longer necessary with the VMware NSX distributed router, for the simple reasonthat virtual machines are directly attached to one logical router that hasn’t failed until the lastremaining hypervisor has failed.

The Cisco Nexus 7000 switches are also made more scalable and robust as the supervisor engineCPUs are no longer burdened with ARP and HSRP state management for numerous VLANinterfaces and virtual machines. Instead, VMware NSX decouples and distributes thisfunction across the plethora of x86 CPUs at the edge.

4) More awesome firewall, by orders of magnitude (H*B)

Similar to the aforementioned distributed logical routing, VMware NSX for vSphere also includes apowerful distributed stateful firewall in the hypervisor kernel, which is ideal for securing east-westapplication traffic directly at the virtual machine network interface (inspecting every packet) withscale-out data plane performance. Each hypervisor provides transparent stateful firewall inspectionfor its hosted virtual machines, in the kernel, as a service – and yet all under centralized control.

The theoretical throughput of the VMware NSX distributed firewall(http://blogs.vmware.com/networkvirtualization/2013/07/what-is-a-distributed-firewall.html) is some calculation of (H * B). The

number of Hypervisors * network Bandwidth per hypervisor. For example, 500 hypervisors eachwith two 10G NICs would approximate to a 20 Terabit east-west firewall.

http://blogs.vmware.com/networkvirtualization/2013/07/what-is-a-distributed-firewall.html



Figure: NSX Distributed Firewall — intra host

As we see in the diagram above, the distributed firewall provides stateful east-west applicationsecurity directly between virtual machines on the same Cisco UCS host, without any hairpin trafficsteering through a traditional firewall choke point. Zero hops. The most efficient path possible.

The VMware NSX distributed firewall spans multiple Cisco UCS hosts, like one massive firewallconnected directly to every virtual machines. Each hypervisor kernel provides the stateful trafficinspection for its hosted virtual machines. In other words, traffic leaving a Cisco UCS host and hittingthe fabric has already been permitted by a stateful firewall, and is therefore free to travel directly toits destination (where it’s inspected again).

―



Figure: NSX Distributed Firewall — inter host

Given the VMware NSX distributed firewall is directly adjacent to the virtual machines, sophisticatedsecurity policies (http://www.networkworld.com/news/2013/082813-vmware-nsx-security-273286.html) can be created

that leverage enormous amount of application-centric metadata present in the virtual compute layer(things such as user identity, application groupings, logical objects, workload characteristics, etc.);far beyond basic IP packet header inspection.

As a simple example, a security policy might say that protocol X is permitted from thelogical network ”Web” to ”App” – no matter the IP address. Consider a scenario where thisapplication is moved to a different data center, with different IP address assignments for “Web” and“App” networks; and having no affect on the application’s security policy. No need to change orupdate firewall rules.

Finally, we can see again that more east-west application traffic stays within the low latency non-blocking Cisco UCS domain — right where we want it. This can only help application performancewhile freeing more ports on the Cisco Nexus 7000 previously needed for bandwidth to a physicalfirewall.

5) More awesome network services

―

http://www.networkworld.com/news/2013/082813-vmware-nsx-security-273286.html



One of the more pressing challenges in a virtualized data center surrounds efficient network serviceprovisioning (firewall, load balancing) in a multi-tenant environment. Of particular importance are theservices establishing the perimeter edge — the demarcation point establishing the application’spoint of presence (NAT, VIP, VPN, IP routing). Typical frustrations often include:

Limited multi-tenancy contexts on hardware appliances

Static service placement

Manually provisioned static routing

Limited deployment automation

Service resiliency

To address this, VMware NSX includes performance optimized multi-service virtual machines (NSXEdge Services), auto deployed with the NSX API into a vSphere HA & DRS edge cluster. Multi-tenancy contexts are virtually unlimited by shifting perimeter services from hardware appliances toNSX Edge virtual machines on Cisco UCS.



Figure: Sample VMware NSX logical topology on Cisco UCS

Dynamic IP routing protocols on the NSX Edge (BGP, OSPF, IS-IS) allow the Cisco Nexus 7000switches to learn about new (or moved) virtual network IP prefixes automatically — doing away withstale and error prone static routes.

VMware NSX Edge instances leverage HA & DRS clustering technology to provide dynamic serviceplacement and perpetual N+1 redundancy (auto re-birth of failed instances); while Cisco UCSstateless computing provides the simplified and expedient restoration of service capacity (re-birthof failed hosts).

―



Figure: Application traffic flow. Before & After

With VMware NSX, traffic enters the Cisco UCS domain where all required network services for bothnorth-south and east-west flows are applied using high performance servers within the non-blockingconverged fabric, resulting in the most efficient application flows possible.

Note: VMware NSX is also capable of bridging virtual networks to physical through the NSX Edge,where specific VXLAN segments can be mapped to physical VLANs connecting physical workloads,or extended to other sites.

6) Divide and Conquer multi data center

Solving the multi data center challenge involves tackling a few very different problem areas relatedto networking. Rarely does one platform have all the tools to solve all of the different problems inthe most elegant way. It’s usually best to divide and conquer each problem area with the best toolfor the job. In moving an application from one data center to another, the networking challengesgenerally boil down to three problem areas:

Recreate the application’s network topology and services

Optimize Egress routing

Optimize Ingress routing

―



In abstracting the virtual network, complete with Logical Layer 2 segments, distributed logicalrouting, distributed firewall, perimeter firewall, and load balancing, all entirely provisioned by APIand software, VMware NSX is the ideal tool for quickly and faithfully recreating the applicationsnetwork topology and services in another data center. At this point the NSX Edge provides theapplication a consolidated point of presence for optimized routing solutions to solve against.

Figure: Multi data center with VMware NSX, Cisco OTV and LISP

The next problem area — optimized egress routing — is ideal for a tool like OTV on the Cisco Nexus7000 series, where the virtual network’s NSX Edge is given a consistent egress gateway network ateither data center, with localized egress forwarding. Cisco OTV services are focused onthe DMZ VLAN and the NSX Edge, and not burdened with handling every individual networksegment, every virtual machine, and every default gateway within the application. With thissimplicity the OTV solution becomes more scalable to handle larger sets of applications, and easierto configure and deploy.

―



With the Cisco Nexus 7000 and OTV keying on the NSX Edge (via VIPs and IP routing) for theapplication’s point of presence, this serves as in ideal layering point for the next problem area ofoptimized ingress routing. This challenge is ideal for tools such as BGP routing, or LISP on the CiscoNexus 7000 switches and LISP capable routers; delivering inbound client traffic immediately anddirectly to the data center hosting the application.

7) A superior track record of integration and operational

tools

It’s hard to think of two technology leaders with a better track record of doing more operationallyfocused engineering work together than Cisco and VMware. Examples are both recent and plenty;such as the Cisco Nexus 1000V, Cisco UCS VM-FEX, Cisco UCS Plugin for VMware vCenter(http://developer.cisco.com/web/unifiedcomputing/vmware) , the Cisco UCS Plugin for VMware vCenter Orchestrator(http://www.vmware.com/support/orchestrator/doc/ucs_plugin_10_release_notes.html) , and so on.

Operational visibility is all about providing good data and making it easily accessible. Acomprehensive API is the basis on which two industry leaders can engineer tools togetherexchanging data to provide superior operational visibility. Cisco UCS and VMware NSX are twoplatforms with a rich API engineered at its core (not a bolted on afterthought). When looking at boththe track record and capabilities of VMware and Cisco, working together to serve their mutualcustomer better, we’re excited about what lies ahead.

In closing

VMware NSX represents best-in-class virtual networking, for any hypervisor, any application, anycloud platform, and any physical network. A well-engineered physical network is, and always willbe, an important part of the infrastructure. Network virtualization makes it even better bysimplifying the configuration, making it more scalable, enabling rapid deployment of networkingservices, and providing centralized operational visibility and monitoring(http://networkheresy.com/2013/07/15/visibility-debugging-and-network-virtualization-part-1/) into the state of the virtual andphysical network.

The point of this post is not so much to help you decide what your data center infrastructure shouldbe, but to show you how adding VMware NSX to Cisco UCS & Nexus will allow you to get muchmore out of those best-in-class platforms.

Brad HedlundEngineering ArchitectVMware NSBU

This entry was posted in Network Virtualization (https:/ / blogs.vmware.com/ networkvirtualization/ network-virtualization-2) , NSX

(https:/ / blogs.vmware.com/ networkvirtualization/ nsx) and tagged Cisco (https:/ / blogs.vmware.com/ networkvirtualization/ tag/ cisco) , cloud

computing (https:/ / blogs.vmware.com/ networkvirtualization/ tag/ cloud-computing) , data center

(https:/ / blogs.vmware.com/ networkvirtualization/ tag/ data-center) , network virtualization (https:/ / blogs.vmware.com/ networkvirtualization/ tag/ network-

http://developer.cisco.com/web/unifiedcomputing/vmware

http://www.vmware.com/support/orchestrator/doc/ucs_plugin_10_release_notes.html

http://networkheresy.com/2013/07/15/visibility-debugging-and-network-virtualization-part-1/

https://blogs.vmware.com/networkvirtualization/network-virtualization-2

https://blogs.vmware.com/networkvirtualization/nsx

https://blogs.vmware.com/networkvirtualization/tag/cisco

https://blogs.vmware.com/networkvirtualization/tag/cloud-computing

https://blogs.vmware.com/networkvirtualization/tag/data-center

https://blogs.vmware.com/networkvirtualization/tag/network-virtualization



virtualization) , Nexus (https:/ / blogs.vmware.com/ networkvirtualization/ tag/ nexus) , UCS (https:/ / blogs.vmware.com/ networkvirtualization/ tag/ ucs) ,

VMware NSX (https:/ / blogs.vmware.com/ networkvirtualization/ tag/ vmware-nsx) on September 4, 2013

[https:/ / blogs.vmware.com/ networkvirtualization/ 2013/ 09/ vmware_nsx_cisco.html] by Brad Hedlund

(https:/ / blogs.vmware.com/ networkvirtualization/ author/ brad_hedlund) .

About Brad Hedlund

Brad Hedlund is an Engineering Architect in the CTO office of VMware’s Networking and Security

Business Unit (NSBU). Brad’s background in data center networking begins in the mid-1990s with a

variety of experience in roles such as IT customer, value added reseller, and vendor, including Cisco

and Dell. Brad also authors a popular data center networking blog at http://bradhedlund.com. CCIE

Emeritus #5530.

View all posts by Brad Hedlund → (https:/ / blogs.vmware.com/ networkvirtualization/ author/ brad_hedlund)

32 thoughts on “Seven reasons VMware NSX, Cisco UCS and Nexus are orders of

magnitude more awesome together”

Hi Brad,

Great post!

Thank you very much for sharing!

Could you please let me know where i can find more technical details about NSX?

Best Regards,

David

David Zhang

September 4, 2013 at 6:17 pm

(https://blogs.vmware.com/networkvirtualization/2013/09/vmware_nsx_cisco.html#comment-312)

Dmitri Kalintsev (http:/ / sapientnetworks.com)



https://blogs.vmware.com/networkvirtualization/tag/network-virtualization

https://blogs.vmware.com/networkvirtualization/tag/nexus

https://blogs.vmware.com/networkvirtualization/tag/ucs

https://blogs.vmware.com/networkvirtualization/tag/vmware-nsx

https://blogs.vmware.com/networkvirtualization/2013/09/vmware_nsx_cisco.html



http://sapientnetworks.com/



Hi David,

I think https://nsx.eventbrite.com/?ref=ebapi (https://nsx.eventbrite.com/?ref=ebapi) should be good.

VMware NSX ArchitectureIvan PepelnjakWednesday, September 18, 2013 at 11:00 AM (EDT)

Ivan’s seminars are always top-notch! I highly recommend them…and look forward to this onemyself.

Kelly

Kelly McGrew

September 6, 2013 at 9:00 am


Excellent Article, this is the start of the journey, we see that NSX allows the next step to real cloudconvergence.

Diego Quintana (http:/ /www.wetcom.com.ar)



There isn’t much here that cannot be achieved with any other vendor’s networking infrastructure. Infact, isn’t the whole point and marketing message of VMware NSX is that you can build these virtualnetworks regardless of the underlying physical infrastructure, and that it provides all these benefitsto any existing network from any vendor? Isn’t the whole point of SDN to “commoditize” thephysical network infrastructure?

I think it’s unprofessional of VMware to publish in their official blogs a post that sides so much withone of their many networking partners and shamelessly promotes Cisco Nexus and UCS

Juan Tarrío (BROCADE) (http:/ /www.twitter.com/ jtarrioBRCD)



https://nsx.eventbrite.com/?ref=ebapi

http://www.wetcom.com.ar/

http://www.twitter.com/jtarrioBRCD



infrastructure over other vendors in this manner. Of course, Brad, you can have your personal opinionand this post doesn’t surprise me given your past, but you should keep that to bradhedlund.com.VMware should be neutral. It should be up to Cisco (and the rest of the networking vendors) toconvince their customers why VMware NSX is better running on their own networking infrastructure.

DISCLAIMER: I work for Brocade. This is my personal opinion.

The concept of virtual overlay topologies that NSX enables is truly intriguing and excitingtechnology. Unfortunately there really is nothing in the above post that discusses any differentiatorsthat you get when using NSX with a Cisco infrastructure. Alternately there is one vendor that hasproducts that are ready today that have deep integrations with NSX – these come from AristaNetworks.

Arista believes in a open ecosystem in which the customer can choose the vendors that best meettheir need, to this end there are many direct integrations with Arista EOS and other vendors. In thecase of NSX here are a few truly differentiating features / functions:

1) Shipping VXLAN VTEP2) Tight integration with NSX / OVSDB3) Dynamic just in time provisioning of network resources for vm placement or during DRS, thisincludes VLANs and VTEPs4) Complete visibility to both physical and virtual topologies via the switches CLI5) Works with native hypervisor, no need for rip-n-replace

All of the above was demonstrated at vmware 2013 by Arista and vmware, with Arista its not aroadmap item or marchitecture its a reality…

Disclaimer: I work at Arista Networks, opinions expressed are my own

Mark,Can you please explain more about this “Complete visibility to both physical and virtual topologiesvia the switches CLI”?

Thanks

Mark Berly



ted





Ted – From the switch’s CLI you can see the physical servers attached, the virtual machinesassociated with those servers, the status of the virtual machines as well as dvuplink and vnicinformation. This is all done with the native hypervisor from vmware and does not require a rip-n-replace.

Hi Mark,Is this information embedded into NSX management tools or you need to jump to Arista CLI toaccess it?Can you share this info across the physical topology to say track VM traffic path?

Hi Mark, Hi Juan,

This post was written to answer questions from customers about how NSX can be used on theirexisting infrastructure, and what the benefits are.

A large number of our enterprise and service provider customers have a significant Cisco installedbase of physical network infrastructure. This post was intended to make sure that those customershave the information they need to understand how and why they should consider looking at VMwareNSX today.

We look forward to working with all of our partners, including Arista and Brocade, to promote howcustomers can benefit from deploying NSX across those infrastructure choices as well.

Mark Berly



Kanat



Brad Hedlund



Post author



Hi Brad, thanks for taking the time to respond. While I certainly acknowledge Cisco’s dominance inthe networking industry, there are thousands of Brocade, Arista and many other vendors’ customersout there reading this post and wondering by VMware NSX is “better together” with Cisco Nexusand UCS and not any other vendor’s infrastructure. I still think this post would have made a betterpublic service if it had stayed more “neutral” with regards to the underlying hardware vendor andhad highlighted how important the underlying physical infrastructure continues to be when youdeploy network virtualization, in line with your recent tweets…

Juan Tarrío (http://www.twitter.com/jtarrio)



And VTEP on Cisco UCS (or Nexus 7000) is coming anytime soon?

N7k F3 supports VXLAN in hardware. UCS supports it via N1k ESX & HyperV with both multicast &unicast VXLAN modes.

Dieter Kast



MZ



Eli Ben-Shoshan (http:/ /www.benshoshan.com)



http://www.twitter.com/jtarrio

http://www.benshoshan.com/



I think you missed one important point: troubleshooting.

Where and how can a network engineer or systems or infrastructure engineer troubleshoot areported network problem? Will we have to touch a lot of different hosts to accomplish what wasonce a span of a physical switch port? While I think NSX adds a lot of value especially when itcomes to network provisioning for a VM, I would like to know how I am going to troubleshoot thisinfrastructure when something hits the virtual fan.

Providing linkages between infrastructure and applications is critical in any highly virtualized datacenter. These linkages should allow visibility for all of the administrators of the various componentsof the data center ecosystem.

As you point out having a SPAN session is critical is getting the appropriate information about whatis going on in the network. While there are different ways to accomplish this goal theimplementation of a tap aggregation switch can help solve many of these issues as it will allow thenetwork monitoring tools to stay in one place aggregating back of your data traffic and allowing youto select which flows go to which tools. In addition having hooks in the network operating systemwhich allow intelligent interaction with the virtualization platform so that SPAN sessions can follow aVM as it moves are vary useful.

The issues you bring up are good ones and are being solved by the networking vendors that looktoward an open ecosystem, instead of one that is closed. By working together best of breedvendors can provide both network and application teams the tools and visibility so they can worktogether in a positive manner.

Looking into the future the merger of all of the data center disciplines will happen, as it has with somany other technologies, but looking nearer term I 100% agree with you that tools are need to helpnot only deploy but to manage these highly virtualized overlay based networks.

Hi Eli,

You are absolutely right. Network virtualization approach advocated by VMware in a form of NSXproduct creates operational, administrative and maintenance silo of network, security andapplication delivery principles encapsulated in a software-only form. If you want to know how

Mark Berly (http:/ /www.aristanetworks.com/en/products/eos/network-telemetry)



David Klebanov



http://www.aristanetworks.com/en/products/eos/network-telemetry



VMware suggests you troubleshoot this silo, I advise you to take a look at session “NET5790 –Operational Best Practices for NSX in VMware Environments” from the recent VMworld 2013 event.In that session you will clearly see the deep networking expertise required for this task. You willhave two disparate environments to deploy, manage and troubleshoot, the physical network and thevirtual overlay.

The only correlation between physical and virtual is occurring at the edges of an overlay network oneither x86 hypervisors or one of the third-party partner switches supporting VXLAN VTEPfunctionality. This is “troubleshooting by rumor” approach, which is analogous to using traceroute todetermine network problems. Sure, you can look at counters or perform packet capture at theoverlay tunnel endpoints, you can also send a probe packets to determine end-to-end reachability,but it’s like trying to diagnose and solve a power grid problem in your neighborhood by looking atthe power outlet in your home… Comprehensive solution should treat virtual and physicalenvironments as one cohesive domain, where provisioning enhancements are coupled with fullvisibility and operational transparency. Organizations are striving to eliminate siloed approaches toincrease efficiencies and NSX is not helping much on this front.

Disclaimer: I work for Cisco, but this comment represents my own views only.

Thank you for reading.David@DavidKlebanov

hey David,ex Cisco myself, cheers for the tip on that session.It’s interesting, and I see how it’s not exactly easy to tshoot that. Actually it kinda looks like Cisco same sort of CLI kung-fu.

I agree with you that operational side of NSX is… clunky and will create some tension in betweenserver/network/security guys.

That said – NSX is ain’t perfect but it’s out there and it’s been deployed (as Nicira) by some ratherbig names. It offers very attractive benefits – mainly around speeding up the networkprovisioning/alteration in highly mobile DC/SP environment. It’s vendor agnostic. And it’s a softwaresolution, meaning more rapid development cycles.

Question to you – can you comment on how Cisco ACI will be better?

Kanat



network ace (http:/ /www.networkace.in)



http://www.networkace.in/



great blog…nice information,Most Demanded IT Certification of the world…Cisco has excellentcareer in IT Networking.visit http://www.networkace.in (http://www.networkace.in) for certification path.

Very nice post Brad. Useful information to learn NSX.

Eric Shanks (http:/ / theithollow.com)



sounds like the similiar argument for source base dedupe, inline dedupe and post dedupe on thestorage world.

Referring to the post above, there are arguments targeting the UCS Fabric Interconnect which didnot support L3 traffic forwarding, and now NSX will perform the L3 traffic forwarding via the L2physical link.Most data center do not enable L3 on every switch just to reduce the uplink and routing traffic. Thereare risk and operation concerns to enable L3 on every switch in the data center, by targeting toreduce latency on the number of hops. Throughput should not be the major challenge as 10GbpsNetwork is matured, and 40Gbps is on the way

will this be really practical in every environment? may be useful for public cloud, but may not bebest fit in every enterprise network. With NSX, the total packet forwarding speeds and limits will stilldepend on the physical switches. The network performance will not be determine by NSX only.

Virtual firewall is not new concept and most users will buy in to the multi vendors and multi tiersfirewall strategy, which doesn’t mean to remove all physical firewall, but introduce extra layersecurity on virtual layer

I agree NSX is brand new concept to be reconsidered for virtualize environment, but it may noteasily fit in to the existing infrastructure without major changes required. It may be good use case ifusers are targetting to deploy a brand new infrastructure and fully virtualize infrastructure.

ITnuts



Brad Hedlund


Post author

http://www.networkace.in/

http://theithollow.com/



Definitely agree that packet forwarding throughput in the physical network plays an important role inperformance. That’s true with or witout network virtualization. NSX provides the best possibleforwarding path on that network. And as a software solution, you can add NSX in an existingenvironment, in a walled garden, without any changes to the physical network. You can start smallwith just a few hosts, running just a few Dev/Test apps. Once you get a feel for how well that NSXgarden works, you can choose to grow it from there, or not.

Cheers,Brad


WOW. Why does this look like HP’s Virtual Connect? You finally admit that UCS must move packetout of the enclosure and return to the enclosure to communicate with a server in the sameenclosure? Could it be Cisco has it wrong? Cisco has a closed proprietary solution design -meant tosell more network devices. A Design that sends the Management packets down the same pipe asthe data! Nobody else in the network market does this. Shrinking switch market = the birth of UCS.Come on Brad, Have some intellectual honesty and admit that this is Virtual Connect for UCS. Kindof. Cisco gets to keep allof the useless iron (Fabric Interconnects) and bill people for ports!However, HP has always attempted to eliminate layers and complexity with VC. For full disclosure Iwork for a resller that spends on average 2 less days per solution to implement VC versus UCS.UCS is a dinosaur meant to fuel the Cisco machine with cash only. And the maintenance andheadaches with UCS are tremendous compared to the VC implementations I have done!

Jake



So I have to agree with Juan here and say this is a sad attempt at shilling for Cisco.Full disclosure, I work for HP. These opinions are my own.

Lets break it down further.1) You say NSX adds Vitual Networking to UCS, but doesn’t it add this Virtual Networking to almostany vendor the same way? There is ZERO mention of ACTUAL integration between the 2 products.

Dan Robinson





This Bullet basically says, “they are compatible” And as Jake pointed out, Virtual Connect has beendoing this since around 2007.

2) This is very similar in its so generic. Use of Virtual VLANs reduces the use of Physical VLANs.Groundbreaking stuff here. Then you go on to say that UCS is better here because its no longercongested by traffic it might not have otherwise been able to handle. Thats not saying UCS/Nexus isbetter with NSX, its saying Nexus sucks LESS when NSX is handling that workload. But again, thereis nothing that points to actual integration or specific advantages for UCS/Nexus here.

3) I feel like a parrot here. You say yourself in Paragraph 2, “on any existing Layer 2″ but still feel theneed to call out UCS. The pictures here could have UCS Blade, UCS Fabric X and Nexus 7000swapped out with virtually ANY vendor’s Blade and Network solution and would look almostidentical. Again you point out the 7000 doesn’t scale high enough to handle this workload withoutNSX.

4) Ugh, do I even have to say it? Again, nothing specific to UCS or Nexus.In fact, the East/West traffic in other solutions, Virtual Connect, HPN on c7000, hell even Dell or IBMBlades don’t have to send the traffic up to the Distribution layer to allow 2 blades to talk to eachother INSIDE the same enclosure. HPN switches even allow “vPC” (called IRF on the HP side) rightin the back of the Blade Enclosure and it scales to more than just 2 switches.

5) Once again, nothing special here. Even the protocols mentioned like BGP and OSPF are industrystandards and not unique to Nexus.And Re-birthof failed hosts? Why would you bother setting up “spares” in a VMware environment.Wouldnt it be better to have that Spare node running and servicing VMs and simply spread its VMsback out via HA during a failure? The only advantage I can see here is maybe a License cost savingson the VMware side. But if you can afford UCS, I am sure you can afford a few more vSpherelicenses.

6) Here is the only one where I might award you any points at all. Sure OTV can handle this typeofwork, but its not the only one in the industry that can i’m sure. And again you point out that bymaking the Nexus 7000 work less, it gets faster.

7) Really? Superior track record of integration? The vCenter Plugin is still in Beta. The link youprovide says version 0.9.2. At least the vCenter Orchestrator link is (barely) out of Beta. I especiallylike this “integration here”Following caveats were resolved in 0.9(2) release-CSCue57514 – ESX servers are shown as non-ESX servers in vcenter pluginSo the plugin doesn’t know how to handle ESX (as opposedto ESXi). I can see those many years ofIntegration are paying off.

This entire Blog post reads as if Written by Cisco Marketing.Quite honestly I expected better.

BTW, can you tell me which Network Vendor is missing from this picture?http://img853.imageshack.us/img853/1692/d8to.jpg (http://img853.imageshack.us/img853/1692/d8to.jpg)

Marc Edwards (http:/ /www.linkedin.com/ in/santacruzbro)



http://img853.imageshack.us/img853/1692/d8to.jpg

http://www.linkedin.com/in/santacruzbro



There has been much hype in recent weeks about NSX positioning. Reading through blogs andlooking at marketing (most notably the man with the hammer ready to thwart the dragon in the city),it appears that vmware has aspirations attempting to commoditize the networking industry and bringCisco to it’s knees. Most of the marketing so far has been rather pretentious and would at least saythis is a modest improvement to understanding the realities that exist in service provider and datacenter environments throughout the world. You can not simply rip out Cisco. Especially when it’sgear can run for over 10 years w/out a hitch. Cisco also provides world-class support to theirproducts in development, pre sales, and post sales. Who has not been thankful to that TAC engineerwho was able to save the day at 2 AM minimizing downtimes, lost revenues, and resume writingevents. Simply can’t avoid Cisco and this article is what I see as a first attempt to also displayrecent innovations at Cisco with relation to hardware abstraction at server level drastically reducingthe time it takes to upgrade/service the underlying metal vm’s are hosted on.

Three are a few things that I believe do need clarification in this article.-’In a nutshell, VMware NSX is to virtual servers and the virtual network what Cisco UCS is tophysical servers and the physical network’ This isn’t all that true. UCS service profiles areessentially a shim between the metal and the operating system. unique characteristics of the server(UUID, MACs, FW updates, BIOS rev, boot order, vNICs, vHBAs, etc,,,,) are stored in files abstractingthese characteristics from the metal and automating the processes involved with prepping a serverfor an OS. As stated, it can reduce time to prep bare metal into minutes as opposed to hours (ormore depending on the sysadmin). That is how it was able to gain 2nd position worldwide in anindustry it did not compete in 4 years ago. You love UCS, I love UCS, and would bet that anybodywho has racked/stacked servers would love UCS just as much. NSX isn’t a shim so much as atunneling protocol that creates a lack of visibility into the physical characteristics of the network.This is a critical mis sight by vmware. By not marrying up both the physical and virtual networks, itadds additional troubleshooting for both network and systems admins = more finger pointing andless productivity.

“Limited number of STP logical port instances the switch control plane CPUs can support, placing aceiling on VLAN density.” – Have you heard of multiple spanning tree protocol? It bundles vlans intothe same instance and is how the savvy engineers run data center networks today. Speaking ofspanning tree, why do you see the need for spanning tree when there is now support for Multi-Chassis Etherchannels (vPC & VSS) , fabric path , TRILL already positioned to solve this issue andsipped in the Nexus 7000′s?

“Limited MAC & IP forwarding table resources available in switch hardware, placing a ceiling onvirtual machine density.” I don’t see this as a problem in Nexus 7000 that utilizes switch on chip(SOC) technology decoupling all forwarding from supervisors. Also scaling up to 1 million entries perline card.

“Normally, the size of the MAC & IP forwarding tables in a switch roughly determines the ceiling oftotal virtual machines you can scale to” In my experiences, it has been the physical limitations ofservers deployed that determines how many VM’s can run in a cluster. Do you have any test resultsto back your claim?

In concluding. NSX has possibilities but really most of it’s capabilities already exist in virtually usingthe Cisco 1000v, VSG, ASA1000v, and Citrix 1000v. If a customer has invested in Cisco who hasgained their trust through proven performance. I believe it worth while for them to see whatcapabilities exist with said products and due a true apples to apples comparison on both featureand price before making any hasty decisions on a rev 0 product that has generated plenty of hypeand not much revenue.



Hi Marc,

You described how UCS abstracts the characteristics of a server into a profile stored as file that canbe copied and templated, and how that reduces the time to deploy a server. NSX does exactly thesame thing for the network. NSX abstracts network services such as Layer-2, Layer 3 routing,firewall, load balancing, vpn, etc. and stores it as a data object that can be copied and templated,dramatically reducing the time to deploy the network for virtual machines. Tunneling is just animplementation detail of how NSX accomplishes some of that, through decoupling.

“Have you ever heard of multiple spanning tree protocol?” Indeed I have. Making the migration toMST is anything but trivial. Tell a network admin that all problems will be solved by just completelyre-configuring the spanning tree in his/her production network and you’ll be shown the door. By theway, STP instances still count on VLANs in Multi-Chassis Etherchannel deployments.

“1 million entries per line card” Depends on which line card, and depends on which entries you’retalking about. Yes, some linecards have 1 million IP route entries — now take a look at the portdensity and cost of that linecard, and the MAC table size of that linecard. What you’ll often find isthat linecards with the best port density and cost are the ones with the smallest table sizes (16K insome cases).

“Do you have any test results to back your claim?” This is really more of an obvious reality than it isa theory. Consider a core switch with linecards that have 16K MAC/IP table sizes, if you had a 50:1vm density per server, that amounts to 320 servers. At 40 servers per rack, your deployment is only8 racks. Your awesome core switch can probably handle a lot more than 8 racks, so you’re notgetting the most potential out of that investment.

“More finger pointing and less productivity”. I disagree. Because with NSX and network virtualizationin general you’ll have a central view into the health and state of the complete virtual network(s),including L2, L3, FW, LB, and the health of the physical network. This allows you to get a lot moreinformation about where a problem exists, be it in the virtual network (bad ACL on virtual portsomewhere blocking traffic), or in the physical network (bad port dropping packets somewhere).NSX will be able to help you begin your troubleshooting exercise with more actionable data.

Cheers,Brad

Brad,

Brad Hedlund



Post author

Marc Edwards (http://www.linkedin.com/in/santacruzbro)






Thanks for reply. It is worth getting mac entry numbers straight for Nexus 7000:

M1: 128,000F2: 16,384 per SoC, and up to 196,608 per module (depending on VLAN allocation)F3 40G: 64K

To your point, routes would be higher but from a raw layer 2 perspective, it scales much higher than16K mostly due to the custom ASICS and integrated Switch On Chip (SOC) capabilities of the linecards. That might make the ‘obvious’ a bit more fuzzy and perhaps why I didn’t understand the logicbehind stated numbers and claims. I find it good practice state proven validations opposed tomarketing. I have seen that get a company in trouble on a few levels and occasions.

I have been personally thanked by network admins for upgrading per VLAN STP to MST. I set upproof of concept displaying faster convergence times and it usually sells itself. No need to fearwhen benefits are in plain sight. Typically, I am shown the console as opposed to the door.

Again, glad to see acceptance of Cisco innovation and architecture. I think it is a positive stepforward for the SDN movement. On that note Cisco does offer 1000v, Cloud Services Rotuer, 1000vASA, VSG essentially already solving problems that have been identified int his article. It also doesit with the same look and feel network engineers are used to.

In concluding, very soon Cisco will shed light to an application centric infrastructure(http://blogs.cisco.com/datacenter/limitations-of-a-software-only-approach-to-data-center-networking/ (http://blogs.cisco.com/datacenter/limitations-of-a-software-only-approach-to-data-center-networking/) ) that moves

SDN past data center into all aspects of the network. a marriage of both physical and virtual thathelps ease deployment time and reacts to the whole network in an application centric manner.

Regards,

Marc

Hey Marc,

“depending on VLAN allocation”It’s worth explaining that because it’s highly relevant. Meaning, if you forward the same set ofVLANs on all ports, which is pretty typical in a server virtualization environment, the F2 modulesupports 16K.

At any rate, the point of the post was show that NSX helps to extend the scalability of the existingNexus hardware you have, without any necessary change to its configuration. For example, no needto make a change from STP to MST.

Cheers,Brad

Brad Hedlund



Post author

http://blogs.cisco.com/datacenter/limitations-of-a-software-only-approach-to-data-center-networking/



Brad,

Thanks again for response. My final thought on this. The article does a great job pointing out recentinnovations at Cisco both in compute, data center switching, and data center interconnecttechnologies.

The Nexus 1000v soft-switch, which 1000′s of installs has proved to solve many of the traffic flowissues pointed out in this article.

Cisco is continuing to innovate in the both the virtual switching space as well as moving intoapplication centric architectures that will ease implementation, troubleshooting, and support byproviding visibility of traffic both P to V and in a uniform manner.

Things are surely changing. This blog came as a surprise to me, but it was well worth the read and Iappreciate your prompt and candid feeback.

Regards,

Marc

Marc Edwards (http://www.linkedin.com/in/santacruzbro)



Innovate the Virtual switch? That is laughable. The same and MORE features are in VMWaredistributed switch technology without vendor lock-in. Cisco only tries to modify any standardenough to make it proprietary on their switches. And then if connecting to competitor product youhave to dumb everything down to talk to Cisco. If the Virtual Switch from CIsco is so fantastic, Ciscoshould be selling millions of them. Want to post the numbers on those? OR deos Cisco evenseperate that from switches? Faster convergence times on Cisco versus Cisco. WOW that’s great!How about Cisco versus the competition. This Cisco blather just makes me. Have you even lookedat IRF and the capabilities of IRF? How many consoles and command lines do you need to eventroubleshoot and maintain Cisco switches. 20? I am done here. Cannot even admit that Cisco needsNSX to help them perform better by doing the hairpin turn that is VEPA….

Jake










‘Want to post the numbers on those? ‘

CTO states there are over 6000 instances of 1000v in production. With respect to lock-in, it ishypervisor agnostic and officially supported on vmware, hyper-v, and KVM. How many instances ofNSX are in production?

With respect to innovations. Cisco typically innovates technologies that are released to standardsbodies. They become standards due to high adoption levels. Where to start on this one HSRP(VRRP), CDP (LLDP), Fabric Path (TRILL), FCoE… It is a large list and growing.

‘How many consoles and command lines do you need to even troubleshoot and maintain Ciscoswitches. 20?’

Well, if one adopts Nexus,UCS,1000v architecture it would be 1 for Nexus and supporting FEX, 1 forUCS (mostly gui based but also RESTFUL and programatic w/open APIS, or console access ifneeded), 1 for virtual. That totals 3. On that note in coming months this will be further simplified withACI.

Why admit Cisco needs NSX when they have innovated technologies that already solve these trafficflow challenges?

Regards,

Marc

‘a VEPA based approach makes existing network tools and processes work consistently acrossboth virtualized and non-virtualized environments as well as across hypervisor technologies.’

http://www.networkworld.com/news/tech/2010/101223techupdate-vepa.html?page=2(http://www.networkworld.com/news/tech/2010/101223techupdate-vepa.html?page=2)

I don’t see any issues with that from a networking standpoint




Wow… Nice article, but i’d expect it to come from cisco partner engineer trying to bundlevmware/cisco solution…And it kinda goes the opposite direction to VMware’s marketing message – NSX will run on any HW

Kanat



http://www.networkworld.com/news/tech/2010/101223techupdate-vepa.html?page=2




Comments are closed.

and liberate you from vendor shackles.

First of I’d like to thank you for including some technical depth to your points, it’s kind of refreshinggiven usually these kind of blogs are very fluffy and vague.

Question Brad – how are we supposed to take this without a grain (although i’d say spoon-full) ofsalt in the light of the fact that cisco is not listed as NSX HW partner and instead going with an in-house competitive solution (ACI)?I understand your attempt to reassure the customer base that invested in cisco, but don’t see anykiller reasons to go for cisco+nsx pair (apart from the UCS platform distinct simplified deploymentfeatures + perhaps OTV, if you can live with multicast ).Can’t you achieve all above mentioned points with other vendor gear? Isn’t it the point of NSX?

Also, Cisco pr machine is pretty persistent in pointing at NSX shortcoming – lack of visibility andmultiple management slios. Can you refer me any material that describes the NSX functionality inthose areas?

Thank you.

p.s. I’m ex Cisco.

VMware Technology

Virtualization(/ /www.vmware.com/virtualization/ )

Data Center Virtualization(/ /www.vmware.com/products /datacenter-

virtualization/ )

Desktop Virtualization(/ /www.vmware.com/products /desktop-

virtualization.html)

Virtualizing EnterpriseApplications(/ /www.vmware.com/bus iness-

critical-apps/ index.html)

Cloud Computing(/ /www.vmware.com/cloud-

computing/overview.html)

Hybrid Cloud(/ /www.vmware.com/products /vcloud-

hybrid-service/ )

Private Cloud Computing(/ /www.vmware.com/cloud-

computing/private-cloud.html)

Software-Defined DataCenter(/ /www.vmware.com/software-

Company Information

Leadership(/ /www.vmware.com/company/ leadership/ )

Careers at VMware(/ /www.vmware.com/company/careers / )

Acquisitions(/ /www.vmware.com/company/acquis itions/ )

Office Locations(/ /www.vmware.com/company/office_locations/ )

Contact VMware(/ /www.vmware.com/company/contact/ )

Investor Relations(http :/ / ir.vmware.com/)

VMware Foundation(/ /www.vmware.com/company/foundation.html)

Why Choose VMware?(/ /www.vmware.com/why-choose-

vmware/overview.html)

News & Events

Newsroom(/ /www.vmware.com/company/news/ )

Articles(/ /www.vmware.com/company/news/articles / )

Events(/ /www.vmware.com/events / )

Awards(/ /www.vmware.com/company/news/awards .html)

Media Resource Center(/ /www.vmware.com/company/news/mediaresource/ index.html)

Media & Contacts(/ /www.vmware.com/company/news/releases/pr_contacts .html)

Community

VMTN Communities(http :/ /communities .vmware.com/community/vmtn/ )

VMware Blogs(http :/ /blogs .vmware.com/)

VMware on Twitter(http :/ /communities .vmware.com/community/ twitter)

VMware on Facebook(http :/ /communities .vmware.com/community/ facebook)

VMware on YouTube(http :/ /communities .vmware.com/community/youtube)

Community Terms of Use(/ /www.vmware.com/community_terms .html)

https://www.vmware.com/virtualization/

https://www.vmware.com/products/datacenter-virtualization/

https://www.vmware.com/products/desktop-virtualization.html

https://www.vmware.com/business-critical-apps/index.html

https://www.vmware.com/cloud-computing/overview.html

https://www.vmware.com/products/vcloud-hybrid-service/

https://www.vmware.com/cloud-computing/private-cloud.html

https://www.vmware.com/software-defined-datacenter/index.html

https://www.vmware.com/company/leadership/

https://www.vmware.com/company/careers/

https://www.vmware.com/company/acquisitions/

https://www.vmware.com/company/office_locations/

https://www.vmware.com/company/contact/

http://ir.vmware.com/

https://www.vmware.com/company/foundation.html

https://www.vmware.com/why-choose-vmware/overview.html

https://www.vmware.com/company/news/

https://www.vmware.com/company/news/articles/

https://www.vmware.com/events/

https://www.vmware.com/company/news/awards.html

https://www.vmware.com/company/news/mediaresource/index.html

https://www.vmware.com/company/news/releases/pr_contacts.html

http://communities.vmware.com/community/vmtn/

http://blogs.vmware.com/

http://communities.vmware.com/community/twitter

http://communities.vmware.com/community/facebook

http://communities.vmware.com/community/youtube

https://www.vmware.com/community_terms.html



Copyright © 2014 VMware, Inc. All rights reserved.

defined-datacenter/ index.html)

Workforce Mobility(/ /www.vmware.com/workforce-

mobility/ )

https://www.vmware.com/software-defined-datacenter/index.html

https://www.vmware.com/workforce-mobility/

Documents

VMware NSX With Cisco