Home > Blogs > The Network Virtualization Blog > Tag Archives: VMware NSX

Tag Archives: VMware NSX

Juniper and VMware: Collaborating to Enable Cloud Builders

The need for businesses to enhance the efficiency of IT and increase application agility is overwhelming. Embracing operational models such as cloud computing helps, but in order to fully leverage these new models companies must explore new ways of handling network connectivity. Network virtualization solutions such as VMware NSX provide an answer for the new cloud-centric networking models. As with any technology, though, network virtualization doesn’t solve some existing challenges by itself: consistent, efficient performance for business-critical applications that span virtual and physical worlds; correlated and integrated management; and enhancing data sharing between the network virtualization solution and the underlying physical network are all critical elements to successful cloud deployments. To address these challenges, we are pleased to announce that Juniper and VMware are expanding our partnership to help our joint customers achieve better application agility for their cloud environments.

When it came to helping our joint customers make the move to virtualized environments, expanding Juniper Networks’ longstanding relationship with VMware was a no-brainer.  VMware NSX brings powerful networking capabilities to today’s data centers. For VMware, the move was equally obvious, since Juniper delivers the industry’s only universal software-defined networking (SDN) gateway that addresses heterogeneous intra- and inter-data center environments for helping customers seamlessly adopt SDN and NSX without replacing their existing network infrastructure.

As part of this expanded partnership, both companies will commit engineering resources to jointly develop network virtualization solutions, build collaborative engineering teams in three key areas that will need co-development.

First, expanding the integration of our management tools such as VMware vCenter and Juniper Junos Space so our customers will be able to easily share data across both physical and virtual networks for dynamic threshold detection, trending analysis, root cause detection and automated workload placement. By intelligently sharing the right data via standards based APIs, we offer our customers a “single pane of glass” visibility for the underlay and overlay topologies, thereby simplifying troubleshooting and making managing the datacenter much more efficient.

Second, uniting switching and routing across physical and virtual networks to enable NSX and non-NSX-controlled resources to connect with Juniper Networks’ high-performance, programmable routers and switches acting as gateways between physical and virtual networks.  Juniper will also deliver VXLAN virtual tunnel endpoint (VTEP) technology across its routing and switching platforms, delivering an integrated approach for routing traffic across physical and virtual networks on a per-flow, per-application basis to ensure the best possible performance for every application. This technology allows a customer that is considering network virtualization to confidently integrate this new technology with its existing infrastructure – enabling an easier migration and the ability to seamlessly connect the old and the new.

Third, by sharing analytics and telemetry data, together we will provide correlated historical information as well as the ability to proactively detect and fix anomalies and errors without human intervention. Consider the benefit of automated network optimization for “Elephant and Mice” flows or for the ability to provide end-to-end Quality of Service (QoS) for prioritized traffic that originates at the hypervisor.

But that’s only part of the story.  There is plenty more to the relationship than we don’t have room to share in this short blog.  Here is a link to the video from the recently concluded Interop event where Pat Gelsinger, VMware CEO references the collaboration with Juniper. For additional background on the Juniper-VMware relationship and the benefits it brings to our joint customers, watch this video featuring Juniper Networks EVP Rami Rahim and VMware SVP Stephen Mullaney discussing the opportunities and challenges of network virtualization and how Juniper and VMware are working together to help customers on their journey.

Hatem Naguib, Vice President, Networking and Security, VMware

Denise Shiffman, VP Product Management & Strategy, Juniper

Guest Post – When Pets Meet Cattle: OpenStack and VMware, Part 1

VMware is the industry’s leading enterprise virtualization software company. So it’s not OpenStack Logosurprising that one of the most common questions asked by enterprises considering OpenStack is: “How does OpenStack integrate with VMware vSphere and VMware NSX?” In November 2013, Mirantis and VMware set forth plans to work together on integrating Mirantis OpenStack with vSphere and NSX. Now, as a result of our collaboration, we have built what we believe to be the easiest way to configure OpenStack for a VMware environment. And we’ve scheduled a webcast to do some show and tell about how the technologies work together. You can register for the webinar here.

And in case you were wondering about the headline of this post, it was taken from a blog post written by our friend Nick Chase over at Mirantis.  Take a read of his post here.


VMware at RSA Conference 2014 (#RSAC)


        • Company outlines vision for security in the Software-Defined Data Center
        • Product and partner demonstrations in Booth #1615 to showcase growing security portfolio
        • New PCI-DSS 3.0 and FedRAMP reference architectures to be presented

Throughout its history, RSA Conference has consistently attracted the world’s best and brightest in the security field, creating opportunities for attendees to learn about IT security’s most important issues through first-hand interactions with peers, luminaries and emerging and established companies.

At next week’s conference, VMware will take an important step in outlining details of its vision for advancing security for the software-defined data center. During major periods of IT architecture change, security has often been relegated to an afterthought. But as we enter the Era of the Software-Defined Data Center, security is being designed into the foundation of the architecture from the beginning. If you’re attending the show we invite you to join Martin Casado, our CTO of networking, and Tom Corn, VP of Security Strategy, for a presentation titled, “The Goldilocks Zone: VMware’s vision for security in the Era of the Software-Defined Data Center.” Casado and Corn will detail why the hypervisor represents the ideal place to optimize security by providing the perfect place for delivering for both application context and physical isolation. This is a must attend for executives, CISOs, ISVs, press and analysts attending RSA Conference 2014. The session is on Monday, February 24 at 1pm PST in Moscone West, Room 2022.

VMware Sessions at RSA Conference 2014

  • Tuesday, February 25, 2014, 1:20–2:20pm, Moscone West, Room 2002 – Shifting Roles for Security in the Virtualized Data Center: Who Owns What? (CSV-TO7). VMware’s Rob Randall will join Malcolm Rieke of CatBird to explore how virtualization technologies are changing the operational and architecture roles in IT Networking and Security, and the skill sets required of these updated roles.
  • Wednesday, February 26, 2014, 8–9:00am, Moscone West, Room 2007 – Hot Topics in Information Security Law 2014 (LAW – W01). VMware’s Rebecca Matthais will participate on a panel put on by the American Bar Association’s Information Security Committee that will provide up-to-the-minute reporting on key infosec legal developments and insight into legal trends.

VMware Booth #1615 Portfolio Demonstrations

  • End-User Computing – VMware will demonstrate the latest end-user computing technologies available in VMware Horizon View, Horizon Mirage and Horizon Workspace that help organizations secure enterprise mobility and deliver desktops, applications and data as-a-service.
  • Network Virtualization – VMware will demonstrate the VMware NSX network virtualization platform and how NSX integrates with solutions from leading security ecosystem partners.
  • Cloud Management– VMware will present the latest developments in Cloud operations visualization with VMware vCenter Log Insight 1.5, which delivers automated log management through aggregation, analytics and search, enabling operational intelligence and enterprise-wide visibility in dynamic hybrid cloud environments.

New PCI-DSS 3.0 and FedRAMP Reference Architectures

VMware and its partners will showcase new validated reference architectures designed to accelerate deployment of a software-defined data center while helping to ensure compliance for regulated workloads. These new reference architectures for PCI-Data Security Standard 3.0 and FedRAMP 1.1 have been validated by Coalfire, a leading independent IT GRC audit/assessment services firm, QSA and 3PAO member, and accredited VMware Consulting and Integration Partner Program partners.

The RSA Conference takes place at Moscone Center in San Francisco, February 24-27, 2014. We hope to see you there.

The VMware Team

Deploying VMware NSX with Cisco UCS and Nexus 7000

VMware NSX network virtualization software makes it possible for IT organizations to obtain new levels of business agility, allowing you to deploy advanced policy based network services for your applications as quickly as a virtual machine, today, leveraging your existing physical network infrastructure or next generation network hardware from any vendor.

Back in September, I wrote about the value of deploying the VMware NSX network virtualization platform on Cisco UCS and Nexus infrastructure. We had an overwhelming amount of customer response and request for more content about this deployment scenario. As such, we’ve created a new design guide which you can download here that describes a simple and straight forward example of how to deploy VMware NSX for vSphere on an infrastructure consisting of Cisco UCS and Nexus 7000 series switches. This basic guide should serve as a starting point from which to tailor a design for your specific environment.

We want to offer our thanks to the content creation team here at VMware for collaborating on this effort:

• Dmitri Kalintsev
• Bruce Davie
• Ray Budavari
• Venky Deshpande
• Nikhil Kelshikar
• Rod Stuhlmuller
• Scott Lowe
• Marcos Hernandez
• Chris King


VMware NSX: Helping Make the Software-Defined Data Center Real in 2014

Software is the foundation that is powering the next evolution of networks and data center Training-PEX Postinfrastructure in today’s digital age. The manifestation of this trend is the software-defined data center, which gains momentum in the market on a daily basis. VMware is committed to providing the knowledge required for the adoption of the new operating model for the network in the era of the software-defined data center. To help the industry take advantage of the opportunity to virtualize their infrastructure, and specifically the network, VMware is providing the programs, curriculum and blueprints to help you capture this transformational opportunity. At VMware Partner Exchange (PEX) in San Francisco this week, we outlined three ways we’re helping to make the software-defined data center real in 2014.

Setting the New Career Path for Customers and Partners

In a recent InformationWeek article about Bank of America’s cloud strategy, the writer noted “changing to private cloud architecture and a software-centric datacenter will require different skills.” He wrote that infrastructure pros today define themselves by the gear they run: “I run my company’s million-port Cisco network…” So how will IT pros define themselves in the future? Many will expand the scope of their skills to include network virtualization competency. In 2014, we will deliver the VMware Network Virtualization Certification Program and the requisite curriculum for networking and virtualization professionals who want to lead the network virtualization transformation.

Empowering Partners to Grow their Businesses

Today we announced the Elite Partner Initiative, which will provide a unique introductory market opportunity for qualified VMware partners capable of leading early adoption and investment in the newest VMware technologies and markets, including VMware NSX. Elite partners will possess deep technical skills, an established solution practice, and highly advanced resources to engage closely with VMware on new product strategy, customer wins and deployments. The new global partners for NSX are Accenture, AdvizeX, August Schell, Computacenter, Dimension Data, ePlus, Forsythe, Kelway, O2 Networks and WWT. These partners are investing significant technical and personnel resources to work with VMware in developing specific consulting practices and advanced competency for VMware NSX network virtualization. They are also aligned closely with VMware’s vision for helping customers implement a Software-Defined Data Center, and recognize the important role network virtualization will play. Partners interested in the Elite initiative can login to Partner Central and learn more at www.vmware.com/go/partner_elite.

Providing the Blueprints for NSX Success

To help our growing list of customers deploy NSX, VMware is creating a library of materials to serve as the recipes for success in deploying NSX.  We’re teaming with early adopter customers and network virtualization experts to codify the best approaches for technical implementation. We already published our initial design guide for VMware NSX. This week we delivered our latest design guide outlining NSX implementation over Cisco Nexus 7000 switches and UCS compute infrastructure. In the coming weeks, we will be rolling out design guides with NSX and a variety of our design partners. If you are attending PEX in San Francisco this year attend the workshop SDDC3360-WS (Reference Design for Network Virtualization with NSX).

VMware is committed to helping partners capture new market opportunities for the software-defined data center and guiding customers through this transformative period in IT.


Elephant Flow Mitigation via Virtual-Physical Communication

Note: this post was developed jointly by Justin Pettit of VMware and Mark Pearson of HP, with additional content from VMware’s Martin Casado and Bruce Davie.

A recent Network Heresy post “Of Mice and Elephants” discussed the impact long-lived flows (elephants) have on their short-lived peers (mice).  A quick summary is that, in a datacenter, it is believed that the majority of flows are short-lived (mice), but the majority of packets are long-lived (elephants). Mice flows tend to be bursty and latency-sensitive, whereas elephant flows tend to transfer large amounts of data, with per-packet latency being of less concern.  These elephants can fill up network buffers, which can introduce latency for mice.

At the HP 2013 Discover Conference, HP and VMware demonstrated a technology preview of detecting and handling elephant flows in an overlay network. The demonstration featured the joint HP-VMware solution announced at VMworld 2013.  VMware NSX provided an overlay network using HP switches as the underlay along with the HP VAN SDN controller. Through controller federation interfaces, the overlay and the underlay co-operated to mitigate the effects of the elephant flows on the mice. The solution shows the power of integration between network virtualization and SDN solutions. Continue reading

VMware NSX is Off and Running In 2014

This afternoon, VMware announced Q4 2013 and FY2013 earnings. The results can be found here in our earnings press release. During the earnings call, we provided an update on VMware NSX momentum which we want to share with you.

In the fourth quarter, we delivered VMware NSX, our network virtualization platform, which we believe will do for networking what vSphere and server virtualization did for compute. The VMware NSX customers we highlighted for the fourth quarter are great examples of innovative companies that have made the architectural decision to deploy network virtualization and the Software-Defined Data Center as the heart of their data center strategies. They are virtualizing their networks to deliver the speed and agility they need today. These deals in the quarter included three of the top five investment banks, as well as several of the most respected enterprises and Telcos from around the world, including McKesson, Starbucks, Medtronic and China Telecom.

Additionally, this quarter we announced VMware and Palo Alto Networks will deliver a jointly-developed solution for network security. The integrated solution will enable customers to use the VMware NSX network virtualization platform to automate provisioning and distribution of Palo Alto Networks’ next-generation network security in their software-defined data centers. Side Note: if you are planning to attend the upcoming RSA Conference, read about our session which will take place on Monday, February 24 at 1pm titled, “The Goldilocks Zone: Security in the Era of the SDDC.”

Network virtualization with VMware NSX is a key enabler for the software-defined data center. In 2013, VMware took big steps to present a vision for the future of the data center and the transformation of the network. In 2014 we expect to see an accelerated pace of network virtualization adoption as companies move from consideration to decision on the software-defined data center, and we feel very strong in opportunity to capture this market transformation.

Chris King, VP Product Marketing

Networking & Security Business Unit

Distributed virtual and physical routing in VMware NSX for vSphere

NOTE – this post originally appeared on Bradhedlund.com

This post is intended to be a primer on the distributed routing in VMware NSX for vSphere, using a basic scenario of L3 forwarding between both virtual and physical subnets. I’m not going to bore you with all of the laborious details, just the stuff that matters for the purpose of this discussion.

In VMware NSX for vSphere there are two different types of NSX routers you can deploy in your virtual network.

  1. The NSX Edge Services Router (ESR)
  2. The NSX Distributed Logical Router (DLR)

Both the ESR and DLR can run dynamic routing protocols, or not.  They can just have static/default routes if you like.

The ESR is a router in a VM (it also does other L4-L7 services like FW, LB, NAT, VPN, if you want).  Both the control and data plane of the ESR router are in the VM.  This VM establishes routing protocol sessions with other routers and all of the traffic flows through this VM.  It’s like a router, but in a VM.  This should be straight forward, not requiring much explanation.

The ESR is unique because it’s more than a just router.  It’s also a feature rich firewall, load balancer, and VPN device.  Because of that, it works well as the device handling the North-South traffic at the perimeter of your virtual network.  You know, the traffic coming from and going to the clients, other applications, other tenants.  And don’t be fooled.  Just because it’s a VM doesn’t mean the performance is lacking.  Layer 4 firewall and load balancer operations can reach and exceed 10 Gbps throughput, with high connections per second (cps).  Layer 7 operations also perform well compared to hardware counterparts.  And because it’s a VM, well, you can have virtually unlimited ESRs running in parallel, each establishing the secure perimeter for their own “tenant” enclave.

The DLR is a different beast.  With the DLR the data plane is distributed in kernel modules at each vSphere host, while only the control plane exists in a VM.  And that control plane VM also relies on the NSX controller cluster to push routing updates to the kernel modules.

The DLR is unique because it enables each vSphere hypervisor host to perform L3 routing between virtual and physical subnets in the kernel at line rate.  The DLR is configured and managed like one logical router chassis, where each hypervisor host is like a logical line card.  Because of that the DLR works well as the “device” handling the East-West traffic in your virtual network.  You know, the traffic between virtual machines, the traffic between virtual and physical machines, all of that backend traffic that makes your application work.  We want this traffic to have low latency and high throughput, so it just makes sense to do this as close to the workload as possible, hence the DLR.

The ESR and DLR are independent.  You can deploy both in the same virtual network, just one, or none.

Now that we’ve established the basic difference and autonomy between the ESR and DLR, in this blog we’ll focus on the DLR.  Let’s look at a simple scenario where we have just the DLR and no ESR.

Let’s assume a simple situation where our DLR is running on two vSphere hosts (H1 and H2) and has three logical interfaces:

  • Logical Interface 1: VXLAN logical network #1 with VMs (LIF1)
  • Logical Interface 2: VXLAN logical network #2 with VMs (LIF2)
  • Logical Interface 3: VLAN physical network with physical hosts or routers/gateways (LIF3)

Routers have interfaces with IP addresses and the DLR is no different.  Each vSphere host running the DLR has an identical instance of these three logical interfaces, with identical IP and MAC addresses (with the exception of LIF3).

  • The IP address and MAC address on LIF1 is the same on all vSphere hosts (vMAC)
  • The IP address and MAC address on LIF2 is the same on all vSphere hosts (vMAC)
  • The IP address on LIF3 is the same on all vSphere hosts, however the MAC address on LIF3 is unique per vSphere host (pMAC)

LIFs attached to physical VLAN subnets will have unique MAC addresses per vSphere host.

Side note: the pMAC cited here is not the physical NIC MAC.  It’s different.

The DLR kernel modules will route between VXLAN subnets.  If for example VM1 on Logical Network #1 wants to communicate with VM2 on Logical Network #2, VM1 will use the IP address on LIF1 as it’s default gateway, and the DLR kernel module will route the traffic between LIF1 and LIF2 directly on the vSphere host wherever VM1 resides.  The traffic will then be delivered to VM2, which might be on the same vSphere host, or perhaps another vSphere host where VXLAN encapsulation on Logical Network #2 will be used to deliver the traffic to the hypervisor host where VM2 resides.  Pretty straight forward.

The DLR kernel modules can also route between physical and virtual subnets.  Let’s see what happens when a physical host PH1 (or router) on the physical VLAN wants to deliver traffic to a VM on a VXLAN logical network.

PH1 either has a route or default gateway pointing at the IP address of LIF3.
PH1 issues an ARP request for the IP address present on LIF3.
Before any of this happened, the NSX controller cluster picked one vSphere host to be the Designated Instance (DI) for LIF3.

  • The DI is only needed for LIFs attached to physical VLANs.
  • There is only one DI per LIF.
  • The DI host for one LIF might not be the same DI host for another LIF.
  • The DI is responsible for ARP resolution.

Let’s presume H1 is the vSphere host selected as the DI for LIF3, so H1 responds to PH1′s ARP request, replying with its own unique pMAC on its LIF3.
PH1 then delivers the traffic to the DI host, H1.
H1 then performs a routing lookup in its DLR kernel module.
The destination VM may or may not be on H1.
If so, the packet is delivered directly. (i)
If not, the packet is encapsulated in a VXLAN header and sent directly to the destination vSphere host, H2. (ii)

For (ii) return traffic, the vSphere host with the VM (H2 in this case) will perform a routing lookup in its DLR kernel module and see that the output interface to reach PH1 is its own LIF3.  Yes, if a DLR has a LIF attached to a physical VLAN, each vSphere host running the DLR had better be attached to that VLAN.

Each LIF on the DLR has its own ARP table.  By consequence, each vSphere host in the DLR carries an ARP table for each LIF.
The DLR ARP table for LIF3 may be empty or not contain an entry for PH1, and because H2 is not the DI for LIF3, it’s not allowed to ARP.  So instead H2 sends a UDP message to the DI host (H1) asking it to perform the ARP.

Note: The NSX controller cluster, upon picking H1 as the DI, informed all hosts in the DLR that H1 was the DI for LIF3.

The DI host for LIF3 (H1) issues an ARP request for PH1 and subsequently sends a UDP response back to H2 containing the resolved information. H2 now has an entry for PH1 on its LIF3 ARP table and delivers the return traffic directly from the VM to PH1.  The DI host (H1) is not in the return data path.

All of that happened with just a DLR and static/default routes (no routing protocols).

The DLR can also run IP routing protocols — both OSPF and BGP.

In the case where the DLR is running routing protocols with an upstream router, the DLR will consume two IP addresses on that subnet. One for the LIF in the DLR kernel module in each vSphere host, and one for the DLR control VM.  The IP address on the DLR control VM is not a LIF, it’s not present in the DLR kernel modules of the vSphere hosts, it only exists on the control VM and will be used for establishing routing protocol sessions with other routers — this IP address is referred to as the “Protocol Address”.

The IP address on the LIF will be used for the actual traffic forwarding between the DLR kernel modules and the other routers — this IP address is referred to as the “Forwarding Address” – and is used as the next-hop address in routing advertisements.

When the DLR has a routing adjacency with another router on a physical VLAN, the same process described earlier concerning Designated Instances happens when the other router ARPs for the DLR’s next-hop forwarding address.  Pretty straight forward.

If however the DLR has a routing adjacency with the “other” router on a logical VXLAN network — such as with a router VM running on a vSphere host (eg. ESR) – where that vSphere host is also running the DLR — then no Designated Instance process is needed because the DLR LIF with the Forwarding Address will always be present on the same host as the “other” router VM.  How’s that for a Brain Twister? ;)

The basic point here is that the DLR provides optimal routing between virtual subnets, and physical subnets, and can establish IP routing sessions with virtual and physical routers.

One example where this would work might be a three tier application where each tier is its own subnet.  The Web and App tiers might be virtual machines on VXLAN logical networks, whereas the Database machines might be non-virtualized physical hosts on a VLAN.  The DLR can perform optimal routing between these three subnets, virtual and physical, as well as dynamically advertise new subnets to the data center WAN or Internet routers using OSPF for BGP.

Pretty cool, right?

Stay tuned.  More to come…



Network Security: The VMware NSX Network Virtualization Platform’s Hidden Gem

This week, we announced a new joint solution with our partner Palo Alto Networks that will

Best-In-Class Partners

automate and accelerate the deployment of next-generation network security with centralized management across physical and virtual domains. You can read the full announcement about the forthcoming integrated solution from our companies in our press release here.

For most data center operators, the idea of achieving the operational model of a VM for their data center networks is a top of mind benefit associated with the VMware NSX network virtualization platform. Through this model they can gain greater agility, efficiency and provisioning speed while reducing complexity as they implement a software-defined data center architecture. An often-overlooked feature set, fundamental to VMware NSX, is network security. Continue reading

VMware @ OpenStack Summit Hong Kong

Next week in Hong Kong, the VMware team will have a major presence at the OpenStack Summit, and we have an ever-growing presence on the agenda of speaking sessions and demos. As we did with the Portland show, he is a show planner with a schedule of all the VMware sessions. Here’s a snapshot of what you can expect (and experience) at the show. Continue reading