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
(/ ) (http://www.vmware.com) VMware.com
Communities (http://communities.vmware.com)
Home (http:/ / communities.vmware.com) > Blogs (http:/ / blogs.vmware.com) > The Network Virtualization Blog
The Network Virtualization Blog

(https://blogs.vmware.com/networkvirtualization)
Tw eet 3 Like 0
Share
Share
178
Seven reasons VMware NSX, Cisco UCS and Nexus are orders of magnitude 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 management platform. Adding state of the art virtual networking (VMware NSX) to best-in-class physical networking (Cisco UCS & Nexus) produces signicant optimizations in these key areas: Provision services-rich virtual networks in seconds Orders of magnitude more scalability for virtualization The most ecient application trac forwarding possible Orders of magnitude more rewall performance Sophisticated application-centric security policy More intelligent automation for network services
https://blogs.vmware.com/networkvirtualization/2013/09/vmware_nsx_cisco.html 1/31
4/2/2014
Best-of-breed synergies for multi data center More simplied network congurations
Cisco UCS and Nexus 7000 infrastructure awesomeness

A well-engineered physical network always has been and will continue to be a very important part of the infrastructure. The Cisco Unied Computing System (UCS) is an innovative architecture that simplies and automates the deployment of stateless servers on a converged 10GE network. Cisco UCS Manager simultaneously deploys both the server and its connection to the network through service proles and templates; changing what was once many manual touch points across disparate platforms into one automated provisioning system. Thats why it works so well. Im not just saying this; Im speaking from experience (http://bradhedlund.com/2011/03/08/cisco-ucs-networking-videos-in-hd-updatedimproved/) . 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-performance modular data center switch platform with many features highly relevant to virtualization, such as converged networking (FCoE), data center interconnect (OTV), Layer 2 fabrics (FabricPath, vPC), and location independent routing with LISP. This typically represents best-in-class data center physical networking. With Cisco UCS and Nexus 7000 platforms laying the foundation for convergence and automation in the physical infrastructure, the focus now turns to the virtual infrastructure. VMware NSX, when deployed with Cisco UCS and Cisco Nexus, elegantly solves many of the most pressing issues at the intersection of networking and virtualization. VMware NSX represents the state of the art for virtual networking.
1) Virtualization-centric operational model for networking
https://blogs.vmware.com/networkvirtualization/2013/09/vmware_nsx_cisco.html
2/31
4/2/2014
VMware NSX adds network virtualization capabilities to existing Cisco UCS and Cisco Nexus 7000-based infrastructures, through the abstraction of the virtual network, complete with services such as logical switching, routing, load balancing, security, and more. Virtual networks are deployed programmatically with a similar speed and operational model as the virtual machine create, start, stop, template, clone, snapshot, introspect, delete, etc. in seconds. The virtual network allows the application architecture (including the virtual network and virtual compute) to be deployed together from policybased templates, consolidating what was once many manual touch points across disparate platforms into one automated provisioning system. In a nutshell, VMware NSX is to virtual servers and the virtual network what Cisco UCS is to physical servers 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 for application virtual machines across multiple hypervisor hosts, without any requisite VLAN or IP Multicast conguration in the Cisco UCS and Cisco Nexus 7000 infrastructure. For example, thousands of VXLAN logical Layer 2 networks can be added or removed programmatically through the NSX API, with only a few static infrastructure VLANs; compared to what was once thousands of manually provisioned VLANs across hundreds of switches and interfaces.
4/2/2014
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 dont want a visible ceiling on. Fortunately, VMware NSX provides signicant headroom for both, by orders of magnitude, for the simple reason that VLAN and STP instances are dramatically reduced; and hardware forwarding tables are utilized much more eciently. Consider (P1 * V1) = T. Switch ports * number of active VLANs = STP logical ports. One thousand fewer infrastructure VLANs with VMware NSX translates into one thousand times fewer STP logical port instances loading the Cisco UCS and Nexus 7000 control plane CPUs. This can only help ongoing operational stability, along with the obvious scaling headroom. Consider (P2 * V2) = 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 of total 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 consume MAC & IP forwarding table entries in the Cisco UCS and Nexus 7000 switch hardware. Only the physical hosts require entries. In other words, with VMware NSX, the ceiling is placed on the multiplier (P2), not the total (D). Reduced VLAN sprawl and logical Layer 2 networks compound to both simplify the Cisco UCS and Nexus congurations and signicantly extend the virtualization scalability and virtual life of these platforms.
4/31
4/2/2014
3) Most ecient application trac forwarding possible

Have you ever noticed the paradox that good virtualization is bad networking? For example, the network design that works best for virtualization (Layer 2 fabric) isnt the best design for Layer 3 trac forwarding, and vice versa. That is, until now. VMware NSX provides distributed logical Layer 3 routing capabilities for the virtual network subnets at the hypervisor kernel. Each hypervisor provides the Layer 3 default gateway, ARP resolver, and rst routing hop for its hosted virtual machines. The result is the most ecient forwarding possible for east-west application trac on any existing Layer 2 fabric design, most notably Cisco UCS.
Figure: NSX Distributed Layer 3 routing intra host
In the diagram above, VMware NSX distributed logical routing provides east-west Layer 3 forwarding directly between virtual machines on the same Cisco UCS host, without any hairpin hops
4/2/2014
to the Cisco Nexus 7000 the most ecient 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 kernel I/O path, without impact on system CPU. Layer 3 trac between virtual machines travels directly from source to destination hosts inside the non-blocking Cisco UCS fabric the most ecient path possible.
Figure: NSX Distributed Layer 3 routing inter host
This ecient Layer 3 forwarding works with the existing Cisco UCS Layer 2 fabric, keeping more east-west application trac within the non-blocking server ports, minimizing trac on the fewer uplink ports facing the Cisco Nexus 7000 switches. With Layer 3 forwarding for the virtual network handled by the hypervisors on Cisco UCS, the Cisco Nexus 7000 switch congurations are simpler; because VMware NSX distributed routing obviates the need for numerous congurations of virtual machine adjacent Layer 3 VLAN interfaces (SVIs) and their associated HSRP settings.
4/2/2014
Note: HSRP is no longer necessary with the VMware NSX distributed router, for the simple reason that virtual machines are directly attached to one logical router that hasnt failed until the last remaining hypervisor has failed. The Cisco Nexus 7000 switches are also made more scalable and robust as the supervisor engine CPUs are no longer burdened with ARP and HSRP state management for numerous VLAN interfaces and virtual machines. Instead, VMware NSX decouples and distributes this function across the plethora of x86 CPUs at the edge.
4) More awesome rewall, by orders of magnitude (H*B)

Similar to the aforementioned distributed logical routing, VMware NSX for vSphere also includes a powerful distributed stateful rewall in the hypervisor kernel, which is ideal for securing east-west application trac directly at the virtual machine network interface (inspecting every packet) with scale-out data plane performance. Each hypervisor provides transparent stateful rewall inspection for its hosted virtual machines, in the kernel, as a service and yet all under centralized control. The theoretical throughput of the VMware NSX distributed rewall (http://blogs.vmware.com/networkvirtualization/2013/07/what-is-a-distributed-rewall.html) is some calculation of (H * B). The number of Hypervisors * network Bandwidth per hypervisor. For example, 500 hypervisors each with two 10G NICs would approximate to a 20 Terabit east-west rewall.
7/31
4/2/2014
Figure: NSX Distributed Firewall intra host
As we see in the diagram above, the distributed rewall provides stateful east-west application security directly between virtual machines on the same Cisco UCS host, without any hairpin trac steering through a traditional rewall choke point. Zero hops. The most ecient path possible. The VMware NSX distributed rewall spans multiple Cisco UCS hosts, like one massive rewall connected directly to every virtual machines. Each hypervisor kernel provides the stateful trac inspection for its hosted virtual machines. In other words, trac leaving a Cisco UCS host and hitting the fabric has already been permitted by a stateful rewall, and is therefore free to travel directly to its destination (where its inspected again).
8/31
4/2/2014
Figure: NSX Distributed Firewall inter host
Given the VMware NSX distributed rewall is directly adjacent to the virtual machines, sophisticated security 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 the logical network Web to App no matter the IP address. Consider a scenario where this application is moved to a dierent data center, with dierent IP address assignments for Web and App networks; and having no aect on the applications security policy. No need to change or update rewall rules. Finally, we can see again that more east-west application trac stays within the low latency nonblocking Cisco UCS domain right where we want it. This can only help application performance while freeing more ports on the Cisco Nexus 7000 previously needed for bandwidth to a physical rewall.
5) More awesome network services

4/2/2014
One of the more pressing challenges in a virtualized data center surrounds ecient network service provisioning (rewall, load balancing) in a multi-tenant environment. Of particular importance are the services establishing the perimeter edge the demarcation point establishing the applications point 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 (NSX Edge Services), auto deployed with the NSX API into a vSphere HA & DRS edge cluster. Multitenancy contexts are virtually unlimited by shifting perimeter services from hardware appliances to NSX Edge virtual machines on Cisco UCS.
10/31
4/2/2014
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 7000 switches to learn about new (or moved) virtual network IP prexes automatically doing away with stale and error prone static routes. VMware NSX Edge instances leverage HA & DRS clustering technology to provide dynamic service placement and perpetual N+1 redundancy (auto re-birth of failed instances); while Cisco UCS stateless computing provides the simplied and expedient restoration of service capacity (re-birth of failed hosts).
11/31
4/2/2014
Figure: Application trac ow. B efore & After
With VMware NSX, trac enters the Cisco UCS domain where all required network services for both north-south and east-west ows are applied using high performance servers within the non-blocking converged fabric, resulting in the most ecient application ows possible. Note: VMware NSX is also capable of bridging virtual networks to physical through the NSX Edge, where specic 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 dierent problem areas related to networking. Rarely does one platform have all the tools to solve all of the dierent problems in the most elegant way. Its usually best to divide and conquer each problem area with the best tool for the job. In moving an application from one data center to another, the networking challenges generally boil down to three problem areas: Recreate the applications network topology and services Optimize Egress routing Optimize Ingress routing
4/2/2014
In abstracting the virtual network, complete with Logical Layer 2 segments, distributed logical routing, distributed rewall, perimeter rewall, and load balancing, all entirely provisioned by API and software, VMware NSX is the ideal tool for quickly and faithfully recreating the applications network topology and services in another data center. At this point the NSX Edge provides the application 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 Nexus 7000 series, where the virtual networks NSX Edge is given a consistent egress gateway network at either data center, with localized egress forwarding. Cisco OTV services are focused on the DMZ VLAN and the NSX Edge, and not burdened with handling every individual network segment, every virtual machine, and every default gateway within the application. With this simplicity the OTV solution becomes more scalable to handle larger sets of applications, and easier to congure and deploy.
4/2/2014
With the Cisco Nexus 7000 and OTV keying on the NSX Edge (via VIPs and IP routing) for the applications point of presence, this serves as in ideal layering point for the next problem area of optimized ingress routing. This challenge is ideal for tools such as BGP routing, or LISP on the Cisco Nexus 7000 switches and LISP capable routers; delivering inbound client trac immediately and directly to the data center hosting the application.
7) A superior track record of integration and operational tools

Its hard to think of two technology leaders with a better track record of doing more operationally focused 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/uniedcomputing/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. A comprehensive API is the basis on which two industry leaders can engineer tools together exchanging data to provide superior operational visibility. Cisco UCS and VMware NSX are two platforms with a rich API engineered at its core (not a bolted on afterthought). When looking at both the track record and capabilities of VMware and Cisco, working together to serve their mutual customer better, were excited about what lies ahead.
In closing
VMware NSX represents best-in-class virtual networking, for any hypervisor, any application, any cloud platform, and any physical network. A well-engineered physical network is, and always will be, an important part of the infrastructure. Network virtualization makes it even better by simplifying the conguration, making it more scalable, enabling rapid deployment of networking services, 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 and physical network. The point of this post is not so much to help you decide what your data center infrastructure should be, but to show you how adding VMware NSX to Cisco UCS & Nexus will allow you to get much more out of those best-in-class platforms. Brad Hedlund Engineering Architect VMware 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 network virtualization (https:/ / blogs.vmware.com/ networkvirtualization/ tag/ network14/31
computing (https:/ / blogs.vmware.com/ networkvirtualization/ tag/ cloud-computing) , data center

(https:/ / blogs.vmware.com/ networkvirtualization/ tag/ data-center) ,
4/2/2014
virtualization) ,
Nexus (https:/ / blogs.vmware.com/ networkvirtualization/ tag/ nexus) , UCS (https:/ / blogs.vmware.com/ networkvirtualization/ tag/ ucs) , Hedlund
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 (https:/ / blogs.vmware.com/ networkvirtualization/ author/ brad_hedlund) .
About Brad Hedlund
Brad Hedlund is an Engineering Architect in the CTO oce of VMwares Networking and Security Business Unit (NSBU). Brads 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
David Zhang
September 4, 2013 at 6:17 pm
(https://blogs.vmware.com/networkvirtualization/2013/09/vmware_nsx_cisco.html#comment-312)
Hi Brad, Great post! Thank you very much for sharing! Could you please let me know where i can nd more technical details about NSX? Best Regards, David
Dmitri Kalintsev (http:/ / sapientnetworks.com)

15/31
4/2/2014
Hi David, I think https://nsx.eventbrite.com/?ref=ebapi (https://nsx.eventbrite.com/?ref=ebapi) should be good. VMware NSX Architecture Ivan Pepelnjak Wednesday, September 18, 2013 at 11:00 AM (EDT)
Kelly McGrew
September 6, 2013 at 9:00 am
Ivans seminars are always top-notch! I highly recommend themand look forward to this one myself. Kelly
Diego Quintana (http:/ / www.wetcom.com.ar)

Excellent Article, this is the start of the journey, we see that NSX allows the next step to real cloud convergence.
Juan Tarro (BROCADE) (http:/ / www.twitter.com/ jtarrioBRCD)

There isnt much here that cannot be achieved with any other vendors networking infrastructure. In fact, isnt the whole point and marketing message of VMware NSX is that you can build these virtual networks regardless of the underlying physical infrastructure, and that it provides all these benets to any existing network from any vendor? Isnt the whole point of SDN to commoditize the physical network infrastructure? I think its unprofessional of VMware to publish in their ocial blogs a post that sides so much with one of their many networking partners and shamelessly promotes Cisco Nexus and UCS
4/2/2014
infrastructure over other vendors in this manner. Of course, Brad, you can have your personal opinion and this post doesnt 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) to convince their customers why VMware NSX is better running on their own networking infrastructure. DISCLAIMER: I work for Brocade. This is my personal opinion.
Mark Berly
The concept of virtual overlay topologies that NSX enables is truly intriguing and exciting technology. Unfortunately there really is nothing in the above post that discusses any dierentiators that you get when using NSX with a Cisco infrastructure. Alternately there is one vendor that has products that are ready today that have deep integrations with NSX these come from Arista Networks. Arista believes in a open ecosystem in which the customer can choose the vendors that best meet their need, to this end there are many direct integrations with Arista EOS and other vendors. In the case of NSX here are a few truly dierentiating features / functions: 1) Shipping VXLAN VTEP 2) Tight integration with NSX / OVSDB 3) Dynamic just in time provisioning of network resources for vm placement or during DRS, this includes VLANs and VTEPs 4) Complete visibility to both physical and virtual topologies via the switches CLI 5) 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 a roadmap item or marchitecture its a reality Disclaimer: I work at Arista Networks, opinions expressed are my own
ted
Mark, Can you please explain more about this Complete visibility to both physical and virtual topologies via the switches CLI? Thanks
4/2/2014
Mark Berly
Ted From the switchs CLI you can see the physical servers attached, the virtual machines associated with those servers, the status of the virtual machines as well as dvuplink and vnic information. This is all done with the native hypervisor from vmware and does not require a rip-nreplace.
Kanat
Hi Mark, Is this information embedded into NSX management tools or you need to jump to Arista CLI to access it? Can you share this info across the physical topology to say track VM trac path?
Brad Hedlund
Post author

Hi Mark, Hi Juan, This post was written to answer questions from customers about how NSX can be used on their existing infrastructure, and what the benets are. A large number of our enterprise and service provider customers have a signicant Cisco installed base of physical network infrastructure. This post was intended to make sure that those customers have the information they need to understand how and why they should consider looking at VMware NSX today. We look forward to working with all of our partners, including Arista and Brocade, to promote how customers can benet from deploying NSX across those infrastructure choices as well.
18/31
4/2/2014
Juan Tarro (http://www.twitter.com/jtarrio)

Hi Brad, thanks for taking the time to respond. While I certainly acknowledge Ciscos dominance in the networking industry, there are thousands of Brocade, Arista and many other vendors customers out there reading this post and wondering by VMware NSX is better together with Cisco Nexus and UCS and not any other vendors infrastructure. I still think this post would have made a better public service if it had stayed more neutral with regards to the underlying hardware vendor and had highlighted how important the underlying physical infrastructure continues to be when you deploy network virtualization, in line with your recent tweets
Dieter Kast
And VTEP on Cisco UCS (or Nexus 7000) is coming anytime soon?
MZ
N7k F3 supports VXLAN in hardware. UCS supports it via N1k ESX & HyperV with both multicast & unicast VXLAN modes.
Eli Ben-Shoshan (http:/ / www.benshoshan.com)

19/31
4/2/2014
I think you missed one important point: troubleshooting. Where and how can a network engineer or systems or infrastructure engineer troubleshoot a reported network problem? Will we have to touch a lot of dierent hosts to accomplish what was once a span of a physical switch port? While I think NSX adds a lot of value especially when it comes to network provisioning for a VM, I would like to know how I am going to troubleshoot this infrastructure when something hits the virtual fan.
Mark Berly (http:/ / www.aristanetworks.com/ en/ products/ eos/ network-telemetry)

Providing linkages between infrastructure and applications is critical in any highly virtualized data center. These linkages should allow visibility for all of the administrators of the various components of the data center ecosystem. As you point out having a SPAN session is critical is getting the appropriate information about what is going on in the network. While there are dierent ways to accomplish this goal the implementation of a tap aggregation switch can help solve many of these issues as it will allow the network monitoring tools to stay in one place aggregating back of your data trac and allowing you to select which ows go to which tools. In addition having hooks in the network operating system which allow intelligent interaction with the virtualization platform so that SPAN sessions can follow a VM as it moves are vary useful. The issues you bring up are good ones and are being solved by the networking vendors that look toward an open ecosystem, instead of one that is closed. By working together best of breed vendors can provide both network and application teams the tools and visibility so they can work together in a positive manner. Looking into the future the merger of all of the data center disciplines will happen, as it has with so many other technologies, but looking nearer term I 100% agree with you that tools are need to help not only deploy but to manage these highly virtualized overlay based networks.
David Klebanov
Hi Eli, You are absolutely right. Network virtualization approach advocated by VMware in a form of NSX product creates operational, administrative and maintenance silo of network, security and application delivery principles encapsulated in a software-only form. If you want to know how
4/2/2014
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 will have two disparate environments to deploy, manage and troubleshoot, the physical network and the virtual overlay. The only correlation between physical and virtual is occurring at the edges of an overlay network on either x86 hypervisors or one of the third-party partner switches supporting VXLAN VTEP functionality. This is troubleshooting by rumor approach, which is analogous to using traceroute to determine network problems. Sure, you can look at counters or perform packet capture at the overlay tunnel endpoints, you can also send a probe packets to determine end-to-end reachability, but its like trying to diagnose and solve a power grid problem in your neighborhood by looking at the power outlet in your home Comprehensive solution should treat virtual and physical environments as one cohesive domain, where provisioning enhancements are coupled with full visibility and operational transparency. Organizations are striving to eliminate siloed approaches to increase eciencies 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
Kanat
hey David, ex Cisco myself, cheers for the tip on that session. Its interesting, and I see how its 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 between server/network/security guys. That said NSX is aint perfect but its out there and its been deployed (as Nicira) by some rather big names. It oers very attractive benets mainly around speeding up the network provisioning/alteration in highly mobile DC/SP environment. Its vendor agnostic. And its a software solution, meaning more rapid development cycles. Question to you can you comment on how Cisco ACI will be better?
network ace (http:/ / www.networkace.in)

4/2/2014
great blognice information,Most Demanded IT Certication of the worldCisco has excellent career in IT Networking.visit http://www.networkace.in (http://www.networkace.in) for certication path.
Eric Shanks (http:/ / theithollow.com)

Very nice post Brad. Useful information to learn NSX.
ITnuts
sounds like the similiar argument for source base dedupe, inline dedupe and post dedupe on the storage world. Referring to the post above, there are arguments targeting the UCS Fabric Interconnect which did not support L3 trac forwarding, and now NSX will perform the L3 trac forwarding via the L2 physical link. Most data center do not enable L3 on every switch just to reduce the uplink and routing trac. There are risk and operation concerns to enable L3 on every switch in the data center, by targeting to reduce latency on the number of hops. Throughput should not be the major challenge as 10Gbps Network 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 be best t in every enterprise network. With NSX, the total packet forwarding speeds and limits will still depend on the physical switches. The network performance will not be determine by NSX only. Virtual rewall is not new concept and most users will buy in to the multi vendors and multi tiers rewall strategy, which doesnt mean to remove all physical rewall, but introduce extra layer security on virtual layer I agree NSX is brand new concept to be reconsidered for virtualize environment, but it may not easily t in to the existing infrastructure without major changes required. It may be good use case if users are targetting to deploy a brand new infrastructure and fully virtualize infrastructure.
Brad Hedlund
Post author

4/2/2014
Denitely agree that packet forwarding throughput in the physical network plays an important role in performance. Thats true with or witout network virtualization. NSX provides the best possible forwarding path on that network. And as a software solution, you can add NSX in an existing environment, in a walled garden, without any changes to the physical network. You can start small with just a few hosts, running just a few Dev/Test apps. Once you get a feel for how well that NSX garden works, you can choose to grow it from there, or not. Cheers, Brad
Jake
WOW. Why does this look like HPs Virtual Connect? You nally admit that UCS must move packet out of the enclosure and return to the enclosure to communicate with a server in the same enclosure? Could it be Cisco has it wrong? Cisco has a closed proprietary solution design -meant to sell more network devices. A Design that sends the Management packets down the same pipe as the 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. Kind of. 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 I work 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 and headaches with UCS are tremendous compared to the VC implementations I have done!
Dan Robinson
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 doesnt it add this Virtual Networking to almost any vendor the same way? There is ZERO mention of ACTUAL integration between the 2 products.
4/2/2014
This Bullet basically says, they are compatible And as Jake pointed out, Virtual Connect has been doing this since around 2007. 2) This is very similar in its so generic. Use of Virtual VLANs reduces the use of Physical VLANs. Groundbreaking stu here. Then you go on to say that UCS is better here because its no longer congested by trac it might not have otherwise been able to handle. Thats not saying UCS/Nexus is better with NSX, its saying Nexus sucks LESS when NSX is handling that workload. But again, there is nothing that points to actual integration or specic 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 the need to call out UCS. The pictures here could have UCS Blade, UCS Fabric X and Nexus 7000 swapped out with virtually ANY vendors Blade and Network solution and would look almost identical. Again you point out the 7000 doesnt scale high enough to handle this workload without NSX. 4) Ugh, do I even have to say it? Again, nothing specic to UCS or Nexus. In fact, the East/West trac in other solutions, Virtual Connect, HPN on c7000, hell even Dell or IBM Blades dont have to send the trac up to the Distribution layer to allow 2 blades to talk to each other INSIDE the same enclosure. HPN switches even allow vPC (called IRF on the HP side) right in 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 industry standards 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 VMs back out via HA during a failure? The only advantage I can see here is maybe a License cost savings on the VMware side. But if you can aord UCS, I am sure you can aord a few more vSphere licenses. 6) Here is the only one where I might award you any points at all. Sure OTV can handle this type ofwork, but its not the only one in the industry that can im sure. And again you point out that by making the Nexus 7000 work less, it gets faster. 7) Really? Superior track record of integration? The vCenter Plugin is still in Beta. The link you provide says version 0.9.2. At least the vCenter Orchestrator link is (barely) out of Beta. I especially like this integration here Following caveats were resolved in 0.9(2) release -CSCue57514 ESX servers are shown as non-ESX servers in vcenter plugin So the plugin doesnt know how to handle ESX (as opposedto ESXi). I can see those many years of Integration are paying o. 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)

24/31
4/2/2014
There has been much hype in recent weeks about NSX positioning. Reading through blogs and looking 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 bring Cisco to its knees. Most of the marketing so far has been rather pretentious and would at least say this is a modest improvement to understanding the realities that exist in service provider and data center environments throughout the world. You can not simply rip out Cisco. Especially when its gear can run for over 10 years w/out a hitch. Cisco also provides world-class support to their products in development, pre sales, and post sales. Who has not been thankful to that TAC engineer who was able to save the day at 2 AM minimizing downtimes, lost revenues, and resume writing events. Simply cant avoid Cisco and this article is what I see as a rst attempt to also display recent innovations at Cisco with relation to hardware abstraction at server level drastically reducing the time it takes to upgrade/service the underlying metal vms are hosted on. Three are a few things that I believe do need clarication in this article. -In a nutshell, VMware NSX is to virtual servers and the virtual network what Cisco UCS is to physical servers and the physical network This isnt all that true. UCS service proles are essentially 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 les abstracting these characteristics from the metal and automating the processes involved with prepping a server for an OS. As stated, it can reduce time to prep bare metal into minutes as opposed to hours (or more depending on the sysadmin). That is how it was able to gain 2nd position worldwide in an industry it did not compete in 4 years ago. You love UCS, I love UCS, and would bet that anybody who has racked/stacked servers would love UCS just as much. NSX isnt a shim so much as a tunneling 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, it adds additional troubleshooting for both network and systems admins = more nger pointing and less productivity. Limited number of STP logical port instances the switch control plane CPUs can support, placing a ceiling on VLAN density. Have you heard of multiple spanning tree protocol? It bundles vlans into the same instance and is how the savvy engineers run data center networks today. Speaking of spanning tree, why do you see the need for spanning tree when there is now support for MultiChassis Etherchannels (vPC & VSS) , fabric path , TRILL already positioned to solve this issue and sipped in the Nexus 7000s? Limited MAC & IP forwarding table resources available in switch hardware, placing a ceiling on virtual machine density. I dont 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 per line card. Normally, the size of the MAC & IP forwarding tables in a switch roughly determines the ceiling of total virtual machines you can scale to In my experiences, it has been the physical limitations of servers deployed that determines how many VMs can run in a cluster. Do you have any test results to back your claim? In concluding. NSX has possibilities but really most of its capabilities already exist in virtually using the Cisco 1000v, VSG, ASA1000v, and Citrix 1000v. If a customer has invested in Cisco who has gained their trust through proven performance. I believe it worth while for them to see what capabilities exist with said products and due a true apples to apples comparison on both feature and price before making any hasty decisions on a rev 0 product that has generated plenty of hype and not much revenue.
25/31
4/2/2014
Brad Hedlund
Post author

Hi Marc, You described how UCS abstracts the characteristics of a server into a prole stored as le that can be copied and templated, and how that reduces the time to deploy a server. NSX does exactly the same thing for the network. NSX abstracts network services such as Layer-2, Layer 3 routing, rewall, 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 an implementation 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 to MST is anything but trivial. Tell a network admin that all problems will be solved by just completely re-conguring the spanning tree in his/her production network and youll be shown the door. By the way, 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 youre talking about. Yes, some linecards have 1 million IP route entries now take a look at the port density and cost of that linecard, and the MAC table size of that linecard. What youll often nd is that linecards with the best port density and cost are the ones with the smallest table sizes (16K in some cases). Do you have any test results to back your claim? This is really more of an obvious reality than it is a theory. Consider a core switch with linecards that have 16K MAC/IP table sizes, if you had a 50:1 vm density per server, that amounts to 320 servers. At 40 servers per rack, your deployment is only 8 racks. Your awesome core switch can probably handle a lot more than 8 racks, so youre not getting the most potential out of that investment. More nger pointing and less productivity. I disagree. Because with NSX and network virtualization in general youll 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 more information about where a problem exists, be it in the virtual network (bad ACL on virtual port somewhere blocking trac), 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
Marc Edwards (http://www.linkedin.com/in/santacruzbro)

Brad,
4/2/2014
Thanks for reply. It is worth getting mac entry numbers straight for Nexus 7000: M1: 128,000 F2: 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 than 16K mostly due to the custom ASICS and integrated Switch On Chip (SOC) capabilities of the line cards. That might make the obvious a bit more fuzzy and perhaps why I didnt understand the logic behind stated numbers and claims. I nd it good practice state proven validations opposed to marketing. 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 up proof of concept displaying faster convergence times and it usually sells itself. No need to fear when benets 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 step forward for the SDN movement. On that note Cisco does oer 1000v, Cloud Services Rotuer, 1000v ASA, VSG essentially already solving problems that have been identied int his article. It also does it 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-centernetworking/ (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 that helps ease deployment time and reacts to the whole network in an application centric manner. Regards, Marc
Brad Hedlund
Post author

Hey Marc, depending on VLAN allocation Its worth explaining that because its highly relevant. Meaning, if you forward the same set of VLANs on all ports, which is pretty typical in a server virtualization environment, the F2 module supports 16K. At any rate, the point of the post was show that NSX helps to extend the scalability of the existing Nexus hardware you have, without any necessary change to its conguration. For example, no need to make a change from STP to MST. Cheers, Brad
27/31
4/2/2014
Marc Edwards (http://www.linkedin.com/in/santacruzbro)

Brad, Thanks again for response. My nal thought on this. The article does a great job pointing out recent innovations at Cisco both in compute, data center switching, and data center interconnect technologies. The Nexus 1000v soft-switch, which 1000s of installs has proved to solve many of the trac ow issues pointed out in this article. Cisco is continuing to innovate in the both the virtual switching space as well as moving into application centric architectures that will ease implementation, troubleshooting, and support by providing visibility of trac 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 I appreciate your prompt and candid feeback. Regards, Marc
Jake
Innovate the Virtual switch? That is laughable. The same and MORE features are in VMWare distributed switch technology without vendor lock-in. Cisco only tries to modify any standard enough to make it proprietary on their switches. And then if connecting to competitor product you have to dumb everything down to talk to Cisco. If the Virtual Switch from CIsco is so fantastic, Cisco should be selling millions of them. Want to post the numbers on those? OR deos Cisco even seperate that from switches? Faster convergence times on Cisco versus Cisco. WOW thats great! How about Cisco versus the competition. This Cisco blather just makes me. Have you even looked at IRF and the capabilities of IRF? How many consoles and command lines do you need to even troubleshoot and maintain Cisco switches. 20? I am done here. Cannot even admit that Cisco needs NSX to help them perform better by doing the hairpin turn that is VEPA.

4/2/2014
Want to post the numbers on those? CTO states there are over 6000 instances of 1000v in production. With respect to lock-in, it is hypervisor agnostic and ocially supported on vmware, hyper-v, and KVM. How many instances of NSX are in production? With respect to innovations. Cisco typically innovates technologies that are released to standards bodies. 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 Cisco switches. 20? Well, if one adopts Nexus,UCS,1000v architecture it would be 1 for Nexus and supporting FEX, 1 for UCS (mostly gui based but also RESTFUL and programatic w/open APIS, or console access if needed), 1 for virtual. That totals 3. On that note in coming months this will be further simplied with ACI. Why admit Cisco needs NSX when they have innovated technologies that already solve these trac ow challenges? Regards, Marc

a VEPA based approach makes existing network tools and processes work consistently across both 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 dont see any issues with that from a networking standpoint
Kanat
Wow Nice article, but id expect it to come from cisco partner engineer trying to bundle vmware/cisco solution And it kinda goes the opposite direction to VMwares marketing message NSX will run on any HW
4/2/2014
and liberate you from vendor shackles. First of Id like to thank you for including some technical depth to your points, its kind of refreshing given usually these kind of blogs are very uy and vague. Question Brad how are we supposed to take this without a grain (although id say spoon-full) of salt in the light of the fact that cisco is not listed as NSX HW partner and instead going with an inhouse competitive solution (ACI)? I understand your attempt to reassure the customer base that invested in cisco, but dont see any killer reasons to go for cisco+nsx pair (apart from the UCS platform distinct simplied deployment features + perhaps OTV, if you can live with multicast ). Cant you achieve all above mentioned points with other vendor gear? Isnt it the point of NSX? Also, Cisco pr machine is pretty persistent in pointing at NSX shortcoming lack of visibility and multiple management slios. Can you refer me any material that describes the NSX functionality in those areas? Thank you. p.s. Im ex Cisco.
Comments are closed.
VMware Technology
Virtualization
Company Information News & Events

Leadership Newsroom Articles Events
Community
VMTN Communities VMware Blogs VMware on Twitter
(//www.vmware.com/virtualiz ation/) (//www.vmware.com/company/leaders (//www.vmware.com/company/news hip/) (http://communities /) .vmware.com/communit
Data Center Virtualization Careers at VMware Desktop Virtualization Virtualizing Enterprise Applications Cloud Computing
(//www.vmware.com/cloudcomputing/overview.html)
(//www.vmware.com/products /datacenter(//www.vmware.com/company/careers (//www.vmware.com/company/news /) (http://blogs /articles /) .vmware.com/) virtualiz ation/)
Acquisitions
(//www.vmware.com/company/acquis (//www.vmware.com/events itions /) /) (http://communities .vmware.com/communit (//www.vmware.com/products /des ktopOce Locations Awards VMware on Facebook virtualiz ation.html) (//www.vmware.com/company/oce_locations (//www.vmware.com/company/news /) (http://communities /awards .html) .vmware.com/communit
Contact VMware Investor Relations

(http://ir.vmware.com/)
Media Resource Center Media & Contacts
VMware on YouTube Community Terms of Use
(//www.vmware.com/bus ines s critical-apps /index.html)
(//www.vmware.com/company/contact/) (//www.vmware.com/company/news (http://communities /mediares ource/index.html) .vmware.com/communit
(//www.vmware.com/company/news (//www.vmware.com/community_terms /releas es /pr_contacts .html) .htm
VMware Foundation
(//www.vmware.com/company/foundation.html)
Hybrid Cloud
Why Choose VMware?
(//www.vmware.com/why-choos e(//www.vmware.com/products /vcloudvmware/overview.html) hybrid-s ervice/)
Private Cloud Computing

(//www.vmware.com/cloudcomputing/private-cloud.html)
Software-Dened Data Center

(//www.vmware.com/s oftwarehttps://blogs.vmware.com/networkvirtualization/2013/09/vmware_nsx_cisco.html 30/31
4/2/2014
dened-datacenter/index.html)
Workforce Mobility
(//www.vmware.com/workforcemobility/)
Copyright 2014 VMware, Inc. All rights reserved.
31/31

VMware NSX With Cisco

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

VMware NSX With Cisco

Transféré par

Droits d'auteur :

Formats disponibles

4/2/2014

The Network Virtualization Blog

Cisco UCS and Nexus 7000 infrastructure awesomeness

1) Virtualization-centric operational model for networking

2) More headroom for virtualization, by orders of magnitude (P*V)

Figure: NSX dynamic logical Layer 2 networks

3) Most ecient application trac forwarding possible

Figure: NSX Distributed Layer 3 routing intra host

Figure: NSX Distributed Layer 3 routing inter host

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

Figure: NSX Distributed Firewall intra host

Figure: NSX Distributed Firewall inter host

5) More awesome network services

Figure: Sample VMware NSX logical topology on Cisco UCS

Figure: Application trac ow. B efore & After

6) Divide and Conquer multi data center

7) A superior track record of integration and operational tools

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

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

About Brad Hedlund

Dmitri Kalintsev (http:/ / sapientnetworks.com)

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

Juan Tarro (BROCADE) (http:/ / www.twitter.com/ jtarrioBRCD)

September 6, 2013 at 1:33 pm

Juan Tarro (http://www.twitter.com/jtarrio)

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

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

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

Eric Shanks (http:/ / theithollow.com)

Very nice post Brad. Useful information to learn NSX.

September 10, 2013 at 10:33 am

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

September 12, 2013 at 10:19 am

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

September 12, 2013 at 4:21 pm

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

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

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

I dont see any issues with that from a networking standpoint

Comments are closed.

Company Information News & Events

(//www.vmware.com/virtualiz ation/) (//www.vmware.com/company/leaders (//www.vmware.com/company/news hip/) (http://communities /) .vmware.com/communit

(//www.vmware.com/products /datacenter(//www.vmware.com/company/careers (//www.vmware.com/company/news /) (http://blogs /articles /) .vmware.com/) virtualiz ation/)

Contact VMware Investor Relations

Media Resource Center Media & Contacts

VMware on YouTube Community Terms of Use

(//www.vmware.com/bus ines s critical-apps /index.html)

(//www.vmware.com/company/contact/) (//www.vmware.com/company/news (http://communities /mediares ource/index.html) .vmware.com/communit

(//www.vmware.com/company/news (//www.vmware.com/community_terms /releas es /pr_contacts .html) .htm

Why Choose VMware?

(//www.vmware.com/why-choos e(//www.vmware.com/products /vcloudvmware/overview.html) hybrid-s ervice/)

Private Cloud Computing

Software-Dened Data Center

Copyright 2014 VMware, Inc. All rights reserved.

Vous aimerez peut-être aussi