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

Tag Archives: VMware NSX

VMworld 2014 Networking and Security Session Guide

At last year’s show, we introduced you to VMware NSX, and presented a vision for how network virtualization will fundamentally change data center networking. We focused a lot on what NSX is, what it does, and why you should start planning to virtualize your network.

This year, we’re still focused on the basics. We have a lot of content that will help those of you who are new to network virtualization and NSX start to establish a base. But of course, we have a whole year of selling NSX under our belt. And we want to share that experience with you in a VMworld program that will take you, and NSX, to the next level.

Security and network micro-segmentation?  We’ve got it covered.  Customer deployment stories? You bet. Partners with real GA solutions, solving real-world problems? They are on the agenda.

Take a pass through the list below, and then check out the schedule builder on VMworld.com to organize your week.

We think the #NSXninjas will be out in full force at VMworld. Are you one?  We hope so!

Monday August 25, 2014

Networking Sessions

NET1846

Introduction to NSX

11:00 – 12:00 PM

NET1214

NSX Certification – the Next Step in Your Networking Career

11:30 – 12:30 PM

NET3441-GD

vSphere Distributed Switch

12:30 – 1:30 PM

NET2747

VMware NSX: Software Defined Networking in the Real World

1:00 – 2:00 PM

NET1743

VMware NSX – A Technical Deep Dive

2:00 – 3:00 PM

NET1786

The Business Case for Network Virtualization

2:30 – 3:30 PM

NET1949

VMware NSX for Docker, Containers & Mesos

3:30 – 4:30 PM

NET3305-S

Virtualize your Network with VMware NSX

3:30 – 4:30 PM

NET3442-GD

vCAC and NSX

4:00 – 5:00 PM

NET1745

The Case for Network Virtualization: Customer Case Study

5:30 – 6:30 PM

NET1957

NFV for Telco Infrastructure

5:30 – 6:30 PM

Security Sessions

SEC1196

Who Can You Trust? Strategies and Designs for Implementing a Zero Trust Model Leveraging NSX

12:30 – 1:30 PM

SEC2238

Security and Microsegmentation for the Software Defined Data Center

5:00 – 6:00 PM

Tuesday August 26, 2014

 Networking Sessions

NET1589

Reference Design for SDDC with NSX & vSphere

11:00 – 12:00 PM

NET1468

A Tale of Two Perspectives: IT Operations with VMware NSX

11:30 – 12:30 PM

NET1583

NSX for vSphere Logical Routing Deep Dive

12:30 – 1:30 PM

NET3445-GD

NSX Multi-site Deployments

12:30 – 1:30 PM

NET1586

Advanced Network Services with NSX

1:00 – 2:00 PM

NET1560

The NSX Guide to Horizon View

2:00 – 3:00 PM

NET1974

Multi-Site Data Center Solutions with VMware NSX

2:00 – 3:00 PM

NET3444-GD

NSX Network Services

2:00 – 3:00 PM

NET1743

VMware NSX – A Technical Deep Dive

2:30 – 3:30 PM

NET1674

Advanced Topics & Future Directions in Network Virtualization with NSX

3:30 – 4:30 PM

NET1883

NSX Performance Overview

5:00 – 6:00 PM

NET1966

Operational Best Practices for VMware NSX

5:00 – 6:00 PM

NET3443-GD

NSX Routing Design Best Practices

5:00 – 6:00 PM

NET1588

Load Balancer as a Service using NSX or Partner Solutions

5:30 – 6:30 PM

 Security Sessions

SEC1959-S

The Goldilocks Zone for Security

11:00 – 12:00 PM

SEC1746

NSX Distributed Firewall Deep Dive

11:30 – 12:30 PM

SEC1958

Automating Security Policy Enforcement With VMware NSX

12:30 – 1:30 PM

SEC1977

A Customer Perspective: VMware NSX and Next-Generation Security

2:30 – 3:30 PM

SEC1698

Optimize Security with Context and Isolation Using NSX Guest Introspection

4:00 – 5:00 PM

 Other Sessions

MGT2385

McKesson One Cloud – The One Cloud to Rule Them All

4:00 – 5:00 PM

MGT1878

Deep Dive into How vCenter Operations Simplifies NSX Operations

2:30 – 3:30 PM

TEX2211

VMware NSX and Riverbed Cascade Solution – Monitoring Network and Application Performance in NSX environment

3:30 – 4:30 PM

 Wednesday August 27, 2014

 Networking Sessions

NET1401

vSphere Distributed Switch Best Practices for NSX

8:00 – 9:00 AM

NET1861

Automating Networking and Security Services with NSX for vSphere and vCenter Orchestrator (vCO)

8:00 – 9:00 AM

NET1581

Reference Design for SDDC with NSX for Multi-Hypervisors (NSX-MH)

9:30 – 10:30 AM

NET2318

Scale-Out NSX Deployments:  With VMware-powered SDDC Converged Infrastructure Solution

9:30 – 10:30 AM

NET2379

Dynamically Configuring Application Specific Network Services with vCAC and NSX

9:30 – 10:30 AM

NET3448-GD

NSX Platform Extensibility

9:30 – 10:30 AM

NET2745

vSphere Distributed Switch: Technical Deep Dive

11:00 – 12:00 PM

NET2225

NSX Platform: Enabling Third Party Network and Security Solutions

11:30 – 12:30 PM

NET1846

Introduction to NSX

1:00 – 2:00 PM

NET1592

Under the Hood: Network Virtualization with OpenStack Neutron and VMware NSX

2:00 – 3:00 PM

Security Sessions

SEC3446-GD

Security and Micro-segmentation

11:30 – 12:30 PM

SEC2567

Unleashing Collaborative Security with VMware NSX – Advanced Defense for Advanced Threats

12:30 – 1:30 PM

SEC2421

VMware NSX Security Operations Best Practices

2:30 – 3:30 PM

SEC1958

Automating Security Policy Enforcement with VMware NSX

3:30 – 4:30 PM

 Thursday August 28, 2014

 Networking Sessions

NET2118

NSX PCI Reference Architecture – Policy, Audit and Remediation

10:30 – 11:30 AM

NET1589

Reference Design for SDDC with NSX & vSphere

1:30 – 2:30 PM

Security Sessions

SEC2238

Security and Microsegmentation for the Software Defined Data Center

10:30 – 11:30 AM

SEC1196

Who Can You Trust? Strategies and Designs for Implementing a Zero Trust Model Leveraging NSX

12:00 – 1:00 PM

SEC3449-GD

Security Policy using NSX Service Composer

12:00 – 1:00 PM

 

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

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 is Part 2 in a series of posts the describes a specific use case for VMware NSX in the context of Disaster Recovery. Here’s part 1,

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

Deploying the environment

Now let’s see have a closer look at how to create this environment. The following picture represents the vSphere logical architecture and the associated IP scheme…

ipNSX

 

… and the networks mapping:

logicalnetNSX

First of all you have to create three vSphere clusters: one Management Cluster and two Compute Clusters, as well as  two distinct VDS, within the same vCenter. Each Compute cluster will be connected to the same VDS. One cluster will represent DC1, and the other one will represent DC2. The second VDS will connect to the Management and vMotion networks. Also, you have to create a couple of VLANs: one VLAN for VTEPs, used as the outer dot1q tag to transport VXLAN frames, two external transit VLANs to allow the ESGs to peer with your IP core and VLANs for traditional vSphere functions, such as Management, vMotion and IP storage if required.

Note: As this lab has been created for educational purpose, it is clearly not aligned with NSX design considerations for a production environment. I’ll probably dedicate another blog post for that.

Now let’s get our hands dirty. I have to assume that you already have the NSX Manager deployed as well as 3 controllers. All those virtual appliances should be placed in the Management Cluster and connected to the Management VDS. For the sake of simplicity you can use the same Management VLAN for both ESXi and NSX components management.

The first step after having deployed the controllers is to install the ESXi vibs:  go to the NSX vCenter Plugin, then under Installation, select the Host Preparation tab. Select your Compute Clusters and click Install.

01

Once done, click Configure under the VXLAN section to configure the VXLAN networking:

02

The VLAN field is the outer VLAN ID for your VXLAN overlay. Create a new IP pool named VTEP and use it at the reference pool for your VTEP configuration. Note that if you select “Load Balance – SRCID” or “Load Balance - SRCMAC” as the teaming policy, two VTEPs will be created within the same IP Pool. It means that if you want your VTEPs to reside in two different subnets, you have to use a DHCP server. Another thing I noticed: be sure to create the appropriate number of VDS uplinks BEFORE preparing the hosts, or the NSX manager may not see the right number of uplinks when you want to deploy multiple VTEPs.

03

Next step is to configure the Segment ID range, which will represent your pool of available VNIs. As we will be using unicast transport mode, we don’t need to configure any Multicast Group.

04

Then you can go under Logical Network Preparation > Transport Zones. Add two Transport Zones, as we’ll be simulating two distinct datacenters. Select Unicast as the Control Plane Mode.

05

Each simulated datacenter should end up with its own transport zone, as shown below:

27

Now it’s time to create the Logical Switches. In the Network & Security pane, go to Logical Switches. In the right pane click the “+” icon. Give it a name, and select the first Transport Zone.

07

Create a second Logical Switch, linked to the second Transport Zone. As both Logical Switches are in two different Transport Zones, they will be completely isolated, without any possibility to connect them to the same Logical Router.

08

For the sake of completeness and to match the initial design, you can create a second Logical Switch in each datacenter. Additional Logical Switches to be created create are those connecting Logical Routers to the upstream Edge Gateway. Name those Logical Switches dc1_transit and dc2_transit.

09

The next components to be deployed are the Logical Routers. In the Networking & Security Pane, go to NSX Edges. In the right pane, click the “+” icon. Select Logical Router, you can enable HA if you wish so (I know it’s kind of weird to configure the DLR under the NSX Edge menu…).

10

Configure the credentials and at the “Configure deployment” step, click the “+” icon under NSX Edge Appliances. Select you first datacenter cluster and the appropriate Datastore, Host and Folder.

11

Then configure the management interface by clicking Select, next to “Connected To”. You should select aDistributed Portgroup, not a Logical Switch.

Next, go under Configure interfaces of this NSX Edge and click the “+” icon. Give the interface a name and selectinternal as the interface type. Connect the interface to the first Logical Switch in DC1 and configure its IP address and subnet mask. Repeat the steps to connect a second internal interface to dc1_ls02.

14

As you can imagine, the Uplink interface type will be used to connect the Logical Router interface to thedc1_transit Logical Switch. Add this interface and configure its IP address and subnet mask. It is worth noting that in the case of an internal LIF, the IP address given must be the default gateway for the VMs belonging to that particular Logical Switch.

Here is a screenshot of what you should have as the final configuration:

15

You can then click Next, Next, Finish. Repeat the same operations to create a second Logical Router, but this time in the second datacenter. The cluster/resource pool parameter must be set do dc2 so you can have access to the NSX components available in that specific Transport Zone. Here is a screenshot of what you should have in the end:

16

The last components to be deployed are the NSX Edge Gateways, which connect to the Logical Routers Uplink LIF through the transit Logical Switch. The Edge Gateways must have both a VXLAN interface (the internal interface connecting to the Logical Router) and a VLAN interface, connecting to the external, physical network.

To deploy an Edge Gateway, go to NSX Edges and click on the “+” icon under NSX Edge Appliances. Select Edge Services Gateway as the install type, enable HA and give a name to the gateway.

17

Click Next and configure the credentials. Then click Next and select the appliance size. Compact is ok for a lab, bigger appliances support a higher number of adjacencies, firewall rules, etc.

18

Then click the “+” icon under NSX Edge Appliances and select dc1 as the Cluster/Resource Pool and the appropriate Datastore, Host and Folder.

Click Next, then the “+” icon to add an interface. Give the interface a name and connect it to thedc1_transit network as an internal interface. Configure the IP address and the subnet mask, click OK and repeat the procedure to create an Uplink interface connected to a VDS Portgroup that represents the external network (It can be a VDS or VSS Portgroup).

21

The end result should look like this:

22

Click Next and configure a default gateway if you wish so. However, it’s not strictly necessary in our scenario. You can then click Next, Next and Finish to deploy the Edge Gateway in the first datacenter. Repeat the deployment procedure for the second datacenter by selecting dc2 as the cluster/resource pool so you can connect the appliance to the NSX components available in the second Transport Zone.

Before activating dynamic routing protocols within the NSX environment, we must configure an external device to enable routing adjacency with Edge Gateways in both simulated datacenters. You can use a physical device but if you want to deploy this in your home lab or if you don’t have access to a physical device, I recommend using a Vyatta virtual appliance. It has decent routing capabilities and OSPF configuration is pretty straight forward. I’m using VC6.6R1 in my lab.

Your external routing device should have two interfaces: one connecting to the DC1 Edge Gateway external interface network and one connecting to the DC2 Edge Gateway external interface network. Refer to the global topology diagram for IP addresses and subnets. Here is a screenshot of my Vyatta hardware configuration (I’ve added a third VNIC to connect to the management network so I can SSH into the appliance):

28

Now let’s see how to activate OSPF on the Logical Router and the Edge Gateway:

Under Network & Security, go to NSX Edges and select the Logical Router for DC1. Double-click on it. Go toManage > Global Configuration and click Edit next to Dynamic Routing Configuration. Set a custom Router IDand click save (Don’t tick the OSPF box)

24

Then go to OSPF and click Edit next to OSPF Configuration. You have to set two IP addresses: the Protocol Address is used to establish adjacency with neighbors. The Forwarding Address is the actual address used by the ESXi kernel module in the data plane. They must be part of the same subnet and the Forwarding Address must be the IP address of the Logical Router Uplink interface you have previously configured.

23

Click on the “+” icon under Area Definitions and add Area 0.

25

Then go to Area to Interface Mapping and add the transit vNIC to Area 0. Don’t add the Logical Switch internal LIFs to Area 0 as they’re not participating in the OSPF process. Instead the Logical Switch routing information is redistributed into OSPF (redistribute connected routes). Don’t forget to Publish Changes.

26

Repeat the same procedure for the second Logical Router in DC2.

To activate OSPF within the Edge Gateways, configure the Router ID and tick the OSPF box. There is no need to split the control plane from the data plane as the Edge Gateway is a virtual appliance and as such, it doesn’t have any kernel module installed on the ESXi host. Another difference is that you have to add both the transit and the external network interfaces into Area 0.

Note that if you want to ping the DLR and the ESG from you external network, you’ll have to modify appropriate firewalls rules as both components may have a default deny rule on their local firewall.

If you have configured everything correctly, you should see OSPF information about all routes on the external routing device:

vyatta@vyatta:~$ sh ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

O>* 192.168.0.0/24 [110/1] via 192.168.6.2, eth0, 00:06:08
O>* 192.168.1.0/24 [110/1] via 192.168.6.2, eth0, 00:06:08
O   192.168.6.0/30 [110/10] is directly connected, eth0, 00:22:31
O>* 192.168.7.0/29 [110/11] via 192.168.6.2, eth0, 00:11:38
O>* 192.168.10.0/24 [110/1] via 192.168.14.2, eth1, 00:00:21
O>* 192.168.11.0/24 [110/1] via 192.168.14.2, eth1, 00:00:21
O   192.168.14.0/30 [110/10] is directly connected, eth1, 00:22:31
O>* 192.168.15.0/29 [110/11] via 192.168.14.2, eth1, 00:00:38

By default, the Vyatta appliance adds a cost of 10 to its ospf interfaces and the ESG adds a cost of 1. This is customizable, and so are OSPF Hello and Dead intervals.

Hopefully you’ve got everything working now! :-P

The next post will focus on the very cool part, which is how to use python and pyVmomi to perform both NSX and vSphere tasks to move things around.

Physical Networks in the Virtualized Networking World

[This post was co-authored by VMware's Bruce Davie and Ken Duda from Arista Networks, and originally appeared on Network Heresy]

Almost a year ago, we wrote a first post about our efforts to build virtual networks that span both virtual and physical resources. As we’ve moved beyond the first proofs of concept to customer trials for our combined solution, this post serves to provide an update on where we see the interaction between virtual and physical worlds heading.

Our overall approach to connecting physical and virtual resources can be viewed in two main categories:

  • terminating the overlay on physical devices, such as top-of-rack switches, routers, appliances, etc.
  • managing interactions between the overlay and the physical devices that provide the underlay.

The latter topic is something we’ve addressed in some other recent posts (herehere and here) — in this blog we’ll focus more on how we deal with physical devices at the edge of the overlay. Continue reading

Getting Started with VMware NSX Part II – Building Virtual Networks

In the previous post we took a look at the simplicity of deploying VMware NSX into a new or existing VMware environment. This post looks to develop upon our existing infrastructure and build out a three-tier application with a Web, App and Database tier.

Application Topology

Screen Shot 2014-06-26 at 3.10.48 pm

This application displayed above highlights what this blog seeks to build out. Note that there are three logical network segments – Web, App, DB and Uplink (Transport) – routing functionality provided by the Logical Distributed Router and an NSX Edge Services Gateway that is used to connect the logical network topology to the physical infrastructure. Continue reading

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

Getting Started with VMware NSX Part I – Preparation

This short series will focus on how virtualization administrators and network engineers alike can easily and efficiently deploy VMware NSX and network virtualization into their existing environments. From the simple and seamless installation, building your first virtual network to management and administration of an NSX environment, this series will highlight how easy it is to gain the benefits of network function virtualization.

Integrating NSX Manager into vCenter

Integration of the NSX manager into vCenter is the first task to be undertaken. NSX manager helps create a management plane for the NSX environment. When this is connected it will provide the Networking and Security plugin. It exposes a RESTful API for consumption by a customer or a cloud management platform. Such examples of those that can integrate with this API are vCloud Automation Center or OpenStack. Log into the NSX manager web interface with the credentials you specified during installation. Continue reading

VMware NSX Runs Great on VCE Vblock Systems

Vblock SystemsLast week at EMC World in Las Vegas, one of the industry’s best offerings in converged infrastructure was on display. The adoption of converged infrastructure is becoming increasingly common in many organizations. In fact, research estimates that the total addressable market for converged infrastructure will reach $402B by 2017. Companies are taking advantage of converged infrastructure to accelerate cloud and software-defined data center deployments. Converged infrastructure is used by IT organizations to reduce provisioning times, centralize the management of IT resources, and increase resource utilization rates – resulting in lower costs. These objectives are enabled by the creation of pools of compute, storage and networking resources that can be shared by multiple applications and managed in a collective manner using policy driven processes. Continue reading

Juniper and VMware: Collaborating to Enable The Software-Defined Data Center

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. Continue reading

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.

Roger

VMware at RSA Conference 2014 (#RSAC)

Summary:logo_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. Continue reading