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

Tag Archives: NSX

A Customer Perspective: VMware NSX, Micro-Segmentation & Next-Generation Security

VMware NSX and Palo Alto Networks are transforming the data center by combining the Columbia-S12_WTR_MGHI_564fast provisioning of network and security services with next-generation security protection for East-West traffic. At VMworld, John Spiegel, Global IS Communications Manager for Columbia Sportswear will take the stage to discuss their architecture, their micro-segmentation use case and their experience. This is session SEC1977 taking place on Tuesday, Aug 26, 2:30-3:30 p.m.

Micro-segmentation is quickly emerging as one of the primary drivers for the adoption of NSX. Below, John shares Columbia’s security journey ahead of VMworld

+++++++++++++++++++++++++++++++++++++++

When I started at Columbia, we were about a $500 million company. Now we’re closing in on $2 billion and hoping to get to $3 billion rather quickly. So as you can imagine, our IT infrastructure has to scale with the business. In 2009, we embarked on a huge project to add a redundant data center for disaster recovery. As part of the project, we partnered with VMware and quickly created a nearly 100% virtualized datacenter.  It was a huge success. But something was missing; a security solution that matched our virtualized data center. There just wasn’t a great way to insert security in order to address east-west traffic between VMs, nor have the security tied to the applications as they moved around dynamically.

 We set out looking for a solution to bridge that gap.

To address our security needs in the data center, we looked at several different strategies and at that time, there really weren’t any good solutions. Many of the solutions were physical in nature. They required us to do some crazy configurations to apply security. We looked at the Cisco 6500 firewall blades, Juniper’s virtual solution and a few other lightweight security offerings, but they just didn’t have what we needed. The solutions at the time didn’t have what we needed. We kept looking.

At VMworld last year, we were introduced to VMware NSX. I saw the power of the platform, and it all started to click. And when Palo Alto Networks (our perimeter firewall vendor) announced they were a major partner, and that their technology integrated with NSX to give us an additional level of security, things really came together for us. The ability to drive security down into the infrastructure, down to the kernel level, and then take advantage of Palo Alto Networks next generation security was very attractive. Doing micro-segmentation with NSX, and then having the option of inserting next generation firewalling services from Palo Alto Networks in those areas of the business that require them, will really help us improve our overall security posture. A solution like this is where we need to be. These tools give us the ability to manage both physical and virtual security policies centrally with Palo Alto Networks management tool Panorama. I know that when workloads move the security and policies follow the workloads.

To me, that’s what it is about – advanced security inside the data center, plus automation via software that’s completely independent of the underlying physical infrastructure. With solutions such as NSX and the integration with Palo Alto Networks to provide advanced security services, we are going put security back in the data center, the right way.=

Jspiegel

John Spiegel
Columbia Sportswear

 

VMware NSX Use Case – Simplifying Disaster Recovery (Part 1)

Nicolas Vermandé (VCDX#055) is practice lead for Private Cloud & Infrastructure  at Kelway, a VMware partner. Nicolas covers the Software-Defined Data Center on his blog www.my-sddc.om,

This series of posts describes a specific use case for VMware NSX in the context of Disaster Recovery. The goal is to demonstrate the routing and programmability capabilities through a lab scenario. This first part presents the NSX components and details the use case. The second part will show how to deploy the lab and the third part will deal with APIs and show how to use python to execute REST API calls to recreate the required NSX components at the recovery site.

Introduction

When considering dual datacenter strategy with VMs recovery in mind, one important decision is whether to adopt an active/active or active/standby model. The former is generally much more complex to manage because it requires double the work in terms of procedures, testing and change controls. In addition, capacity management becomes challenging as you need to accommodate physical resources to be able to to run all workloads within whatever site. On top of that, stretched VLANs are sometimes deployed across datacenters so that recovered VMs can keep their IP addresses. This is generally very costly if you want to leverage proper L2 extension technology, such as Cisco OTV.

Alternatively, in a SDDC environment, you can leverage VMware NSX to efficiently manage connectivity and network changes required in the event of a full site failover. NSX gives you the ability to maintain the same IP address scheme for all you workloads by leveraging APIs, with little effort. Or with more granularity, you could even move a single subnet as part of a specific recovery plan. NSX will make this possible by providing:

  • An overlay network that allows you to decouple the backend VM network from the physical network. NSX-V is using VXLAN, each ESXi host acting as a VTEP.
  • Programmability through RESTful APIs that allows you to provision Logical Switches and modify Logical Routers configuration in seconds.
  • Dynamic routing protocol (OSPF, IS-IS, BGP) that will advertise VM subnets to your enterprise network, making them accessible for end users or other applications (North-South or East-West traffic)

NSX Components

As many NSX introduction blog posts can be found on the web (like here or here), I’m not gonna spend much time on this topic. NSX components are:

  • NSX Manager: it’s the single point of configuration and the REST API (and UI) interface. It is provided as a VM appliance and is actually the only appliance you have to manually install. There is a 1:1 mapping between the vCenter Server an the NSX Manager. The manager is responsible for deploying NSX Controllers, NSX Edge Gateways and Logical Router Controllers. It also installs the Distributed Routing and the firewall kernel modules on ESXi hosts, as well as the User World Agent (UWA). NSX configuration is accessible through vCenter once you’ve installed the NSX plugin.
  •  NSX Controller: it provides a control plane to distribute VXLAN Logical Routing and Switching network information to ESXi hosts. It also enables ARP suppression to reduce flooding. It is typically implemented as a 3-node cluster and maintains MAC, ARP and VTEP tables. It is finally responsible for installing routes into each ESXi host.
  • Logical Switch (LS): it acts as the L2 domain boundary for VMs, identified by a VXLAN ID (VNI) and associated with a specific subnet. Its vCenter representation is a distributed Portgroup with specific capabilities.
  • Distributed Logical Router (DLR): it’s the distributed L3 first-hop for VM traffic. As its name suggests, it’s completely distributed. You can think about it as an anycast gateway, where each ESXi corresponds to a node, sharing a single virtual IP and virtual MAC address. The data-path routing process runs within each ESXi in vmkernel space and enables East-West traffic optimisation, avoiding well-known hair-pinning effects when VMs want to talk to their default gateway.
  • Logical Router Control VM: it provides the DLR with a control plane and can be deployed as a redundant pair of VM appliances, in an active/standby fashion. It supports both OSPF and BGP as dynamic routing protocols. The Control VM receives its initial configuration from the NSX Manager.
  • Edge Services Gateway (ESG): it provides network perimeter services to the virtual environment. It is intended for North-South communication, i.e. between the physical and the virtual network or at the edge of your tenant. It is NOT distributed, meaning that its placement is critical. It can run in HA-mode, where the appliances are deployed in an active/standby fashion. The HA mechanism doesn’t rely on VMware HA (as some people at Cisco seem to think), but with minimum common sense, you’re gonna create a DRS anti-affinity rule to separate active and stanby VMs. Depending on specific requirements, the edge gateway can be deployed with several sizes:
    • Compact (1vCPU – 512MB RAM)
    • Large (2 vCPUs – 1GB RAM)
    • Quad-Large (4 vCPUs – 1GB RAM)
    • X-Large (6 vCPUs – 8GB RAM).

Available services include: Firewall, NAT, DHCP, Routing, Load-Balancing, Site-to-Site VPN, SSL VPN and L2VPN.

  • Distributed Firewall (DFW): It enables distributed security capabilities at VM NIC level as an East-West L2-L4 stateful firewall. The module is present on each ESXi host as a kernel module and therefore removes any form of bottleneck. If you need more bandwidth, just add a new host! It also includes the Service Composer feature, which allows you to create specific services by integrating additional 3rd party capabilities to the firewall, such as endpoint services (e.g. Anitivirus, Data Security) and deep packet inspection (Palo Alto). I have to say that this feature is one of the most compelling to me!

The following picture shows how those components fit together:

togetherNSX

Basic Understanding

To understand NSX concepts, it’s useful to map vSphere network components to NSX components:

In a traditional vSphere environment, a VM wishing to communicate with the outside world first hits a virtual port on the virtual switch. This virtual port is part of a Portgroup, which is basically a group of virtual network ports tagged with a specific VLAN ID. In the NSX world, when a VM is part of a Logical Switch, it hits a virtual port member of a Portgroup specifically created by the NSX Manager. It is created on every host member of the VDS, like a traditional distributed Portgroup. However, the difference is that all egress frames hitting this Portgroup will be forwarded inside a VXLAN tunnel, tagged with a specific external VLAN ID to transport the VXLAN frames on the physical network .

The role of the Logical Router is to connect two or more Logical Switches together, enabling routing between the corresponding subnets (you can assume 1 LS = 1 subnet). It also advertises (and learns) prefixes and routes to its neighbor(s) if a dynamic routing protocol has been activated. Alternatively, you can also configure static routes.

As an example, the following diagram shows the DLR establishing adjacency with the ESG, which is also running a dynamic routing protocol, and advertises VM subnets to the physical world. The ESG has its internal interface connected to a VXLAN and its uplink connected to a VLAN. As a result, the physical network can learn about the virtual network, and vice-versa.

example

Lab Architecture

Now that you’ve had a basic introduction to NSX principles, I can detail my scenario. In my lab environment, I’ve simulated the following architecture:

globalNSX

I didn’t actually deploy two sets of controllers and two managers linked to two different Virtual Centers in separate physical datacenters. Instead I’ve created logical containers called “Transport Zones” to make both virtual datacenters completely independent from a data-plane standpoint. The goal here is to demonstrate how to integrate virtual network operations into an orchestrated Disaster Recovery Plan with NSX. The only requirement is the ability to run a script as part of your DR procedures. This may be ultimately be achieved by VMware Site Recovery Manager, or another orchestration tool.

This architecture represents a traditional dual datacenter environment, connected over a L3 IP cloud. In a standard network environment, it basically means that you have to change VMs IP addresses upon recovery. (There are other alternatives, like host routes, RHI and NAT, but these solutions come at a certain complexity cost).

The main goal of the scenario is to show how to provide a flexible orchestrated Disaster Recovery solution without having to change VMs IP addresses. Let’s see how we can achieve this with NSX. The order of operations would be:

  1. Disconnect LS1 and LS2 in DC1.
  2. Create new LS in DC2: DR_LS1 and DR_LS2 (Or pre-create them without connecting the upstream DLR).
  3. Add two new interfaces to DLR2 in DC2, with the same IP addresses as previously used by DLR1 to connect LS1 and LS2. In this way, we don’t have to change the default gateway of the recovered VMs.
  4. Connect those interfaces to the corresponding LS.
  5. Recover VMs in DC2.
  6. Connect VMs to the appropriate LS.
  7. Boot VMs and test connectivity.
  8. Check route updates on the physical network.

Note: I’m assuming here that security devices configuration are synchronized between datacenters.

NSX

Because OSPF is running within the virtual network on both DLR1 and DLR2, routing updates will be sent up to the IP cloud to reflect that DR_LS1 and DR_LS2 subnets are now reachable through DC2. In the same way, because LS1 and LS2 have been disconnected from DLR1, corresponding routes will be removed to reflect that LS1 and LS2 subnets are not reachable in DC1 anymore. Magic??!! No, just awesome technology :-)

The next post will focus on how to deploy this lab environment.

Nicolas

 

Geneve, VXLAN, and Network Virtualization Encapsulations

In this post, Bruce Davie and T. Sridhar of VMware’s Networking and Security Business Unit take a look at a proposed a new encapsulation protocol that would standardize how traffic is tunneled over the physical infrastructure by network overlay software.

++++

For as long as we’ve been doing Network Virtualization, there has been debate about how best to encapsulate the data. As we pointed out in an earlier post, it’s entirely reasonable for multiple encapsulations (e.g. VXLAN and STT) to co-exist in a single network. With the recent publication of “Geneve”, a new proposed encapsulation co-authored by VMware, Microsoft, Red Hat and Intel, we thought it would be helpful to clarify a few points regarding encapsulation for network virtualization. First, with all the investment made by us and our partners in developing support for VXLAN (described here), we very much intend to continue supporting VXLAN — indeed, we’ll be enhancing our VXLAN capabilities. Second, we want to explain why we believe Geneve is a necessary and useful addition to the network virtualization landscape.

Read the rest of Bruce’s blog on the Office of the CTO blog here.

Micro-Segmentation: VMware NSX’s Killer Use Case

The advantages a software-defined data center, using network virtualization as a core underpinning, include service delivery speed, operational efficiency, reduced hardware dependency and lower cost. However, by far the most popular use case by customers thus far has been the use of NSX for network microsegmentation. Why? Because perimeter-centric network security has proven insufficient, and micro-segmentation has to date been operationally and economically infeasible. With NSX, security teams, in partnership with their network and virtualization teams, are benefiting from network micro-segmentation to begin to transform their data center security architecture. Then read the VMware SDDC Micro-Segmentation White Paper.

Rod

The Goldilocks Zone: Security In The Software-Defined Data Center Era

Last week, we spoke at the RSA Conference about a new concept in security – the Goldilocks zone.  With the help of Art Coviello, Executive Chairman of RSA, Chris Young, senior vice president and GM of Cisco’s Security business unit, and Lee Klarich, senior vice president of product management from Palo Alto Networks, we departed from the typical discussions about new controls or the latest threats.  We took the opportunity to lay out what we believe is a fundamental architectural issue holding back substantial progress in cyber security, and how virtualization may just provide the answer. The growing use of virtualization and the move towards software-defined data centers enable huge benefits in speed, scalability and agility; those benefits are undeniable. It may turn out, however, that one of virtualization’s biggest benefits is security. Continue reading

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

Network Virtualization: The Holy Grail of Workload Agility

This is a guest post from vCloud Service Provider Logicworks which originally appeared on the VMware vCloud Blog. You can read more from Logicworks on their blog, Gathering Clouds.

Everyone is familiar with virtualization. It’s become the IT standard for achieving greater levels of resource efficiency and functionality. While it’s just a tool, the vast majority of new builds utilize it in some way.

This holds true for managed service providers (MSPs) as well. The benefits of virtualization to an MSP are similar to what an enterprise would experience. Given the nature of their business, MSPs put a great emphasis on truly being agile to client requirements, both in terms of build times and modifications of client environments.

Virtualization is absolutely key to that, and has been since the inception of VMware. The ability to resize a component of a client’s infrastructure on-demand and on the fly is an absolute must nowadays.

However, when we talk about virtualization, we mean virtualization of the compute layer, which is what everyone speaks about relative to virtual machines (VMs). And while VMs are an amazing innovation, the really interesting stuff is happening at the storage and network virtualization layers.

Logicworks is very keen on network virtualization, as opposed to the traditional configuration of hardware switches, which is a major reason we joined the NSX Beta Program.

Historically, the challenge with network virtualization’s centered on the limitations of spanning the network virtualization layer from a client’s existing virtual environment to other environments, including other data centers.

One of the major benefits we’re looking to achieve with the NSX beta program is that the technology after the acquisition of Nicira makes it possible to span virtualization between data centers which helps realize the dream of true, still completely active mobile workloads.

One of the challenges that this resolves is lead times in deployments. As it is today, providers still need to log into various switches between different vendors to configure and test them. While this is somewhat automatable, it hasn’t achieved that same degree of automation, which compute virtualization enjoys. Network virtualization gives us the ability, using software and scripts and predetermined runbooks, to deploy clients via API calls to a control cluster instead of logging into physical devices.

In addition, providers also use various vendors’ networks offerings. This means that the set of commands one will have to run on a Juniper device is going to different than on an Extreme device, and complex configurations can be quite a bit different between the two.

If we abstract that away by making the basic configuration of either of those hardware devices as simple as possible, enough to enable network virtualization on top of it, then we can standardize our configurations across our clients. This process becomes more repeatable and much quicker to deploy –like the DevOps model applied to network virtualization, to a degree. If the work being done is as close to possible from one client to another, then we can remove potential errors and increase efficiencies through more automation.

Being on the cutting edge of not-yet-industry-standard technology enables Logicworks to deploy cross-production workloads, and serve as an agile service provider. This dovetails nicely with the next generation of network virtualization in that it mirrors our ability to respond quickly and dynamically to make adjustments in deployments.  For the first time, the capabilities of the technology match exactly what it is that we, as a hosting provider, do every day.

VMware NSX Virtualizes the Network to Transform Network Operations

Summary:

  • VMware announces VMware NSX™, the platform for network virtualization
  • Leading Companies to Virtualize Their Networks to Speed Innovation
  • Partner Ecosystem Aligns with VMware to Support Customer Transition to Virtual Networking

Today at VMworld®, we announced VMware NSX, the platform for network virtualization. This announcement is another giant step for VMware as we evolve from being a server virtualization vendor into a supplier of an entire solution for the data center. At the show, our CEO Pat Gelsinger talked about how VMware is helping to transform the network to radically simplify IT as part of his VMworld keynote presentation.  He was joined on stage by several leading companies, including CITI, eBay and GE, to discuss the value of network virtualization. Additionally, more than 20 partners announced support for VMware NSX. Continue reading

Introducing VMware NSX – The Platform For Network Virtualization

Executive Overview: Today’s data center is largely virtualized from a compute perspective, and has unleashed unprecedented benefits of agility, efficiency and capex/opex savings. What is less known is that virtual network access ports have exceeded physical network access ports in number, and this trend is accelerating. In fact, today, 40% of vAdmins manage virtual networks. Beyond virtual switching, the time is ripe to virtualize the rest of the networking stack, and accelerate our customer’s journey to the software-defined data center.

The VMware NSX platform delivers the entire networking and security model in software, decoupled from traditional networking hardware, representing a transformative leap forward in data center networking architecture.