VMware Hands-on Labs - HOL-SDC-1403


Lab Overview - HOL-SDC-1403 - VMware NSX Introduction

Lab Guidance


Many of the modules will have you enter Command Line Interface (CLI) commands.  A text file has been placed on the desktop of the environment allowing you to easily copy and paste complex commands or passwords in the associated utility (CMD, Putty, console, etc). Certain characters are often not present on keyboards throughout the world.  This text file is also included for keyboard layouts which do not provide those characters.

The text file is README.txt and is found on the desktop.  The file is divided into Module Sections and numbered.  The manual will have a number associated with every CLI command.  That command will be numbered in the file for you to copy and paste.

Thank you and enjoy the labs!

The following module is informational in nature.  If you would like to jump directly to the lab work, please advance to Module 2 in the table of contents. The Table of Contents can be accessed under MORE OPTIONS in the upper right-hand corner.

Server virtualization brings efficiency, flexibility and speed to how compute and memory resources are consumed and managed in a datacenter. This is possible because of the decoupling of compute and memory resources from the physical hardware.

However, if you look at the state of the network and network services, such as Firewall and Load Balancer within a data center, they are tied to physical hardware. For example, if a server administrator wants to provision a three-tier application, they have to first ask the Network/Security administrator for a set of isolated networks along with Routing, Firewall, and Load Balancer services. It takes days to configure physical devices and enable these networks and services. So, even if provisioning a virtual machine takes a few clicks, server administrators have to wait days or weeks to roll out an application.

This problem of lack of speed and flexibility in provisioning network and network services is addressed through Network virtualization. Network virtualization achieves this by first decoupling the network and network services from the physical hardware and then allowing you to reproduce similar physical network topologies in logical space.

Note: It will take more than 90 minutes to complete this lab. You should expect to only finish 2-3 of the modules during your time.  The modules are independent of each other so you can start at the beginning of any module and proceed from there.

As part of the lab modules, we will demonstrate how NSX platform helps speed up provisioning of the required network and network services for the three-tier application. A brief description of each module follows:

Lab Module List:

Lab Captains:


 

VMware NSX

VMware NSX is the leading network virtualization platform that delivers the operational model of a virtual machine for the network. Just as server virtualization provides flexible control of virtual machines running on a pool of server hardware, network virtualization with NSX provides a centralized API to provision and configure many isolated logical networks that run on a single physical network.

Logical networks decouple virtual machine connectivity and network services from the physical network, giving cloud providers and enterprises the flexibility to place or migrate virtual machines anywhere in the data center while still supporting layer-2 / layer-3 connectivity and layer 4-7 network services.

 

 

 

 

Decoupled Logical Networks

 

Lab Scenario


The scenario in this lab depicts a company ABC who wants to host a web application in the data center. The users/customers of this ABC company access the application remotely.

The web application is a three-tier app with each tier in a different Layer 2 network. The following are some of the key services required for the application

  1. Load balancer service to provide better application user experience
  2. Firewall service that protects the three tiers of the application. Web, App and DB servers are protected from each other and from external world through Firewall rules.
  3. Routing service to provide access across the tiers and to the physical network

 

Lab and NSX Components Detail

The lab has three clusters configured with VMware's vSphere product, as shown in the diagram in the next screen. There are two compute clusters and one Management and Edge cluster managed by vCenter Server. In the Management and Edge cluster all the control and management plane components of NSX are deployed. In the compute cluster A and B there are virtual machines deployed. The diagram doesn't show the underlying physical network topology, but each cluster runs in a different network. The Compute Clusters A and B are connected to one subnet (192.168.250.0/24).  The Management Cluster is in the 192.168.150.0/24 subnet.

 

 

 

Lab Topology

 

The NSX Controller Cluster is a distributed and scale out system that supports VXLAN and Distributed Routing Functions.

The NSX Manager is the centralized network management component of NSX, and manages the network and network services across the vCenter Server environment.

The NSX edge provides firewall, routing, and gateway services to the logical networks. There are two types of NSX edge deployment possible. You can install NSX edge either as a logical router or a services gateway.

There are four kernel modules deployed on each vSphere host as part of NSX configuration. These hypervisor level modules handle data path functionality of the following functions

  1. Port Security
  2. VXLAN
  3. Distributed firewall (DFW)
  4. Distributed Routing (DR)

 

 

VMware NSX Components

 

After this overview of the different components let's jump into Module 1 to explore further.

 

Module 1 - Component Overview & Terminology (15 minutes)

Quick Component Overview


This module is a quick overview of the NSX components and terminology.  This module is informational only and there are no associated lab activities.  All of the components are addressed in more details in Module 2.


 

NSX Components

 

The diagram shows all the major components of NSX.  Following will be a brief description of each component and its function and relation to the others.

 

 

NSX Manager

The NSX Manager is the centralized network management component of NSX, and is installed as a virtual appliance on any ESXi™ host in your vCenter Server environment. It provides an aggregated system view.

One NSX Manager maps to a single vCenter Server environment and multiple NSX Edge and NSX Data Security instances.

 

 

NSX vSwitch

NSX vSwitch is the software that operates in server hypervisors to form a software abstraction layer between servers and the physical network.

As the demands on datacenters continue to grow, we also see a need for increased speed and access to the data itself. Today most virtual machine access and mobility depends on physical networking infrastructure. This can force workloads into less than ideal environments due to potential layer 2 or layer 3 boundaries, such as being tied to specific VLANs.

NSX vSwitch allows you to place these virtual workloads on any available infrastructure in the datacenter regardless of the underlying physical network infrastructure. This not only allows increased flexibility and mobility, but increased availability and resilience.

 

 

NSX Controller

NSX controller is an advanced distributed state management system that controls virtual networks and overlay transport tunnels.

NSX controller is the central control point for all logical switches within a network and maintains information of all virtual machines, hosts, logical switches, and VXLANs. The controller supports two new logical switch control plane modes, Unicast and Hybrid. These modes decouple NSX from the physical network. VXLANs no longer require the physical network to support multicast in order to handle the Broadcast, Unknown unicast, and Multicast (BUM) traffic within a logical switch. The unicast mode replicates all the BUM traffic locally on the host and requires no physical network configuration. In the hybrid mode, some of the BUM traffic replication is offloaded to the first hop L2 physical switch to achieve better performance.

 

 

NSX Edge

 

NSX Edge provides network edge security and gateway services to isolate a virtualized network. You can install an NSX Edge either as a logical (distributed) router or as a services gateway.

The NSX Edge gateway connects isolated, stub networks to shared (uplink) networks by providing common gateway services such as DHCP, VPN, NAT, dynamic routing, and Load Balancing. Common deployments of NSX Edge include in the DMZ, VPN Extranets, and multi-tenant Cloud environments where the NSX Edge creates virtual boundaries for each tenant.

 

NSX Edge Services

Dynamic Routing:   Provides the necessary forwarding information between layer 2 broadcast domains, thereby allowing you to decrease the scope of layer 2 broadcast domains and improve network efficiency and scale. NSX extends this intelligence to where the workloads reside for doing East-West routing. This allows more direct virtual machine to virtual machine communication without the costly or timely need to extend hops. At the same time, NSX also provides North-South connectivity, thereby enabling tenants to access public networks.

Firewall:  Supported rules include IP 5-tuple configuration with IP and port ranges for stateful inspection for all protocols.

Network Address Translation: Separate controls for Source and Destination IP addresses, as well as port translation.

Dynamic Host Configuration Protocol (DHCP): Configuration of IP pools, gateways, DNS servers, and search domains.

Site-to-Site Virtual Private Network (VPN): Uses standardized IPsec protocol settings to interoperate with all major VPN vendors.

L2 VPN: Provides the ability to stretch your L2 network.

SSL VPN-Plus:  Enables remote users to connect securely to private networks behind a NSX Edge gateway.

Load Balancing:  Simple and dynamically configurable virtual IP addresses and server groups.

High Availability:  High availability ensures an active NSX Edge on the network in case the primary NSX Edge virtual machine is unavailable.

NSX Edge supports syslog export for all services to remote servers.

 

 

 

Distributed Firewall

NSX Distributed Firewall is a hypervisor kernel-embedded firewall that provides visibility and control for virtualized workloads and networks. You can create access control policies based on VMware vCenter objects like datacenters and clusters, virtual machine names and tags, network constructs such as IP/VLAN/VXLAN addresses, as well as user group identity from Active Directory. Consistent access control policy is now enforced when a virtual machine gets migrated (vMotion) across physical hosts without the need to rewrite firewall rules. Since Distributed Firewall is hypervisor-embedded, it delivers close to line rate throughput to enable higher workload consolidation on physical servers. The distributed nature of the firewall provides a scale-out architecture that automatically extends firewall capacity when additional hosts are added to a datacenter.

 

Module 2 - Logical Switching (30 minutes)

Component Overview and Logical Switching


In this lab you will first explore the key components of VMware NSX. The following other key aspects are covered in this module:

1) With the addition of the NSX controller the requirement for Multicast protocol support on the physical fabric has been removed for VXLAN. We will demonstrate how to create a Logical Switch and then attach two VM's to the Logical Switch that you created.

2) Then demonstrate how the logical switch can span across L3 Physical Networks, and still have L2 connectivity between the two Web Servers.

3) The VXLAN to VLAN bridge function allows users to provide P to V communication as well as P to V migration capability. We will show the configuration process.

4) Lastly, we will demonstrate the scalability and high availability of the NSX platform. We will shutdown one of the Controllers and show that network still operates.

Note: There is a file on the desktop, README.txt, that contains all the CLI commands used in this module.  You can copy and paste the commands if you are having trouble entering them.  The commands have a number and "French brackets - {x}" that correspond with the commands in the exercises.


 

Component Overview

 

You will start by clicking on Chrome on the Taskbar.

Login to the vSphere Web Client with the following credentials:

 

 

Exploring the new Networking and Security Section in the Web Client

 

 

 

Verify the deployed components

 

  1. Click Installation.
  2. Click Host Preparation.  You will see the data plane components, also called network virtualization components, on the hosts. These components include the following:  Hypervisor level kernel modules for Port Security, VXLAN, Distributed Firewall and Distributed Routing

You see that Firewall and VXLAN functions are enabled on each cluster after the installation of the network virtualization components. The Port security module assists the VXLAN function while the Distributed routing module is enabled once the NSX edge logical router is configured.

 

 

The topology after the host is prepared with data path components

 

In the next step, you will look at the VXLAN related configuration steps by selecting Logical Network Preparation Tab.

VXLAN configuration can be broken down into three important steps

 

 

View the VTEP configuration

 

  1. Click Logical Network Preparation tab.
  2. Click VXLAN Transport tab.
  3. Click the twistie to expand the clusters.

As shown in the diagram the hosts in the compute clusters are configured with VTEP IP address in a different subnet to the management cluster.  (You may need to unpin the left-hand pane to view the IP Pool info on the right of the screen)

 

 

The topology after the VTEPs are configured across the Clusters

 

One of the key challenges customers have with VXLAN deployment is that Multicast protocol support is required from physical network devices. This challenge is addressed In the NSX Platform by providing Controller based VXLAN implementation and removing any need to configure multicast in the physical network. This mode is the default mode and customers don't have to configure any multicast addresses while defining the logical network pool.

 

 

Segment ID and Multicast Group Address Configuration

 

With NSX for vSphere there is no longer the requirement for Multicast Addresses.  For this lab we are going to use Unicast Mode.

 

 

The final step is defining the span of the logical networks through Transport Zone settings

 

  1. Click Transport Zones.
  2. Right-click Global_Transport_Zone 
  3. Click Edit Settings.

 

 

Confirm Clusters as members of Global Transport Zone

 

Confirm all 3 clusters are present in the Transport Zone.

 

 

The topology after the Transport Zone is defined

 

As you add new clusters in your datacenter, you can increase the transport zone and thus increase the span of the logical networks. Once you have the logical switch spanning across all compute clusters, you remove all the mobility and placement barriers you had before because of limited VLAN boundary.

After looking at the different NSX components and VXLAN related configuration let's go through creation of a logical network also known as logical switch.

 

 

Create a new Logical Switch

 

  1. Click Logical Switches on the left hand side
  2. Click the "Green plus" sign to create a new Logical Switch
  3. Name the Logical Switch - Prod_Logical_Switch
  4. Click Change to the right of the Transport Zone
  5. Select the Radio button by Global-Transport-Zone
  6. Click OK and then
  7. Click OK again.  

Leave the Enable IP Discovery box checked - then click OK.

*Note - Enable IP Discovery and Enable MAC Learning are new features in NSX for vSphere v6.1.

IP Discovery activates ARP Suppression.

MAC Learning builds a VLAN - MAC pair learning table on each vNic. This table is stored as part of the dvfilter data. During vMotion, dvfilter saves/restores the table at the new location. The switch then issues RARPs for all the VLAN - MAC entries in the table.

Enabling this feature avoids possible traffic loss during vMotion in the following cases:

 

 

Attach the new Logical Switch to the NSX Edge services gateway for external access

 

  1. Highlight the newly created logical switch
  2. Click on Add NSX Edge icon.

 

 

Add the Logical Switch to the NSX Edge.

 

As mentioned in the components section, NSX Edge can be installed in two different forms: Distributed-Router and Perimeter-Gateway.

In this example, you are going to connect the logical switch to the NSX Edge services gateway (Perimeter-Gateway).

  1. Click the radio button next to Perimeter-Gateway
  2. Click Next

 

 

The NSX Edge services gateway has ten interfaces. You will need to attach the logical switch to vNIC5.

 

  1. Click the radio button next to vnic5
  2. ClickNext.

 

 

Name the Interface and configure the IP address for the interface

 

  1. Name the Interface - Prod_Interface,
  2. Select Connected.
  3. Click the Plus sign to Configure subnets.

 

 

Assign an IP to the Interface.

 

  1. Click the Plus sign
  2. Enter theIP Address 172.16.40.1
  3. Enter 24 for the prefix length
  4. Click OK.

 

 

Complete the interface editing process

 

 

 

The topology after Prod_Logical_Switch is connected to the NSX Edge services gateway

 

After configuring the logical switch and providing access to the external network it is time to connect the application virtual machines to this network.

 

 

Attach web-sv-03a and web-sv-04a to the newly created Prod_Logical_Switch

 

  1. Click the new Logical Switch that was created
  2. Click the Add Virtual Machine button.

 

 

Add Virtual Machines to attach to the new Logical Switch.

 

  1. Enter a filter to locate those VM's whose name start with"web-sv".
  2. Select web-sv-03a and web-sv-04a
  3. Click Next

 

 

Add VM's vNIC to Logical Switch

 

  1. Select the vNiCs for the two VMs.
  2. Click Next  - and then on the following screen -  Click Finish.

 

 

The Topology after the Virtual Machines are connected to the logical switch

 

Creating a logical switch and then connecting the virtual machine to the logical switch is an easy and quick process when using this network virtualization platform.

This approach of provisioning logical switches is much simpler and faster than the re-configuration process of any physical devices.

Next you will see the communication between the virtual machines on the logical network. The access from the external world is shown by establishing an SSH session to the virtual machines. The communication across the virtual machines hosted on two different clusters will demonstrate that the logical switch spans across physical layer 3 boundaries and still provides layer 2 connectivity.

 

 

Hosts and clusters view

 

  1. Click the Home Button.
  2. Click the Hosts and Clusters Button.

This step will demonstrate the ability of our new logical switch to span a Layer 2 logical segment across a Layer 3 Compute infrastructure.

 

 

Expand the Clusters

 

 

 

Open Putty

 

  1. Click Start
  2. Click the Putty Application icon from the Start Menu.

You are connecting from the control center which is in 192.168.110.0/24 subnet. The traffic will go through the NSX Edge and then to the Web Interface.

 

 

Open SSH session to web-sv-03a

 

  1. Select web-sv-03a.corp.local.
  2. Click Open.
  3. **Note - if the web-sv-03a is not showing as an option, you can also try putting the IP address in the Host Name box.  If you still are not connected you can review steps 22-27 and then contact a lab Proctor for assistance.

 

 

Login into the VM.

 

Note: If you encounter difficulties connecting to web-sv-03a, please repeat steps 22-27 and verify they have been completed.

 

 

Ping web server web-sv-04a to show the layer 2 connectivity.

 

Note: Remember the {#} below is just a reference to the CLI file on your desktop.  Do not include as part of your command!

***Note you might see DUP! packets. This is due to the nature of VMware's nested lab environment. This will not happen in a production environment.

****Do not close your Putty Session. Minimize the window for later use.

 

Next you are going to look at another capability of NSX Edge that allows you to extend your logical switch network to a physical VLAN. Instead of routing the traffic to the external world from the logical switch, you can bridge the logical and physical environments together. The following common use cases are addressed by this feature:

 

 

The topology below shows bridging of logical switch to VLAN 100

 

For a given VXLAN-VLAN pair, the L2 bridging function is performed in the kernel of the single ESXi host - which is hosting the Active Control VM for the specific DLR where the VXLAN-VLAN mapping has been configured (as shown above)

 

 

Configure VXLAN to VLAN Bridging

 

In this lab setup the VLAN tagging capability is not available and thus we can't demonstrate the communication across the physical and logical L2 networks. We are going to show how you would perform the configuration steps without saving.

  1. Click on the Home Icon,
  2. Click on the Networking & Security button

 

 

Select NSX Edge named as distributed-edge for the bridging configuration

 

 

  1. Select NSX Edges in the left panel.
  2. Double-click edge-2 to to edit the properties

 

 

Bridging a Logical Network to a VLAN.

 

  1. Click the Manage tab
  2. Select Bridging
  3. Click the Plus sign

There are three Options to complete the Bridge.  Name the bridge, select the Logical switch that you want to Bridge onto the Physical Network, then Select the Distributed Virtual Port Group that is tied to the VLAN you would like to Bridge into Logical space.

4.     Click Cancel here as the configuration is not supported in this lab environment.

The configuration is straight forward where we just have to select the logical switch and a VLAN.

In the next section you will take a look at the controller scalability and availability. The NSX controller cluster is distributed and can scale-out by adding additional controller nodes. The current best practice (and the only supported configuration) is for the cluster to have three nodes of active-active-active load sharing and redundancy.

We will show you how to add a new controller node and also demonstrate that the failure of one node does not impact the logical switch or logical routing operation.

 

 

NSX Controller Scalability/Availability

 

We will see how to add a controller and also verify what happens if one of controller is brought down.

  1. Click the Home Icon
  2. Click Networking & Security

 

 

Verify the existing controller setup.

 

  1. Click Installation
  2. Click Management

Examine the NSX Controller nodes, you can see that there are three controllers deployed. NSX Controllers are always deployed in odd numbers for high availability and scalability.

 

 

View NSX Controller VMs.

 

To see the NSX Controllers in the virtual environment

  1. Click the Home icon
  2. Click the VMs and Templates button.

 

 

Shutdown one of the NSX Controllers.

 

  1. Expandthe "Hands On Labs" container
  2. Right-clickon one of the NSX_Controllers
  3. Click Shut Down Guest OS
  4. Confirm Shutting the VM down by clicking Yes

 

 

Let's test the connection again with Putty by logging into web-sv-03a.

 

Open your minimized Putty Session.

Login with

 

 

Perform a connectivity test.

 

Note: Remember the {#} below is just a reference to the CLI file on your desktop.  Do not include as part of your command!

With one NSX controller shut down the other two are providing availability.

If you decide to go on your own and shut down a second or even all three controllers you will find the ping continues. This is because the tunnel information has been pushed down to the logical switches (the data plane). What you can not do is make add/moves/changes without the control plane.

You can close the Putty session.

**NOTE: Restart the NSX_controller by right-clicking the controller VM and choosing Power On.

 

 

Module 2 Conclusion

In this module we demonstrated the following key benefits of the NSX platform

The speed at which you can provision logical switches and interface them with virtual machines and external networks

Platform scalability is demonstrated by the ability to scale the transport zones as well as the controller nodes.

 

Video Demonstration of Bridging


On the following step you will be presented with a video demonstrating bridging a logical switch to a physical layer 2 VLAN. This feature provides a layer 2 adjacency between VMs that are located on a physical VLAN and VMs that are attached to the logical switch within NSX.


 

To watch the video, click the play button below.

 
 

 

 

 

 

We will demonstrate communication between logical and physical networks. The Topology is as follows:

 

 

Module 3 - Logical Routing (30 minutes)

Distributed Logical Routing


Lab overview

In the previous module you saw that users can create isolated logical switches/networks with few clicks. To provide communication across these isolated logical layer 2 networks, routing support is essential. In the NSX platform the distributed logical router allows you to route traffic between logical switches. One of the key differentiating feature of this logical router is that the routing capability is distributed in the hypervisor. By incorporating this logical routing component users can reproduce complex routing topologies in the logical space. For example, in a three tier application connected to three logical switches, the routing between the tiers is handled by this distributed logical router.

In this module you will demonstrate the following

1) How traffic flows when the routing is handled by an external physical router or NSX edge services gateway.

2) Then we will go through the configuration of the Logical Interfaces (LIFs) on the Logical router and enable routing between the App and DB tiers of the Application

3) We will explain the traffic flow between App and DB VMs that are running on the same host after distributed routing is enabled.

4) Later we will configure dynamic routing protocols across the distributed logical router and the NSX Edge services gateway. We will show how internal route advertisements to the external router are controlled.

This module will help you understand some of the routing capabilities supported in NSX platform and also how to utilize these capabilities while deploying a three tier application.


Configuring Distributed and Dynamic Routing


You will first take a look at the configuration of distributed routing and see the benefits of performing routing at the kernel level


 

A look at the Current Topology and Packet Flow

 

In the above picture, notice that the Application VM and the Database VM both reside on the same physical host, which is the scenario in the lab.  Without distributed routing, for these two VM's to communicate, we can see the traffic flow noted by the red arrow steps above.  First we see the traffic leave the Application VM and because the Database VM is not on the same network subnet, the physical host will send that traffic to a layer 3 device.  In the environment, this is the NSX (perimeter) Edge which resides on the Management Cluster.  The NSX Edge then sends the traffic back through to the host where it finally reaches the Database VM.  

At the end of the lab, we will again visit a similar traffic flow diagram to see how we have changed this behavior after configuring distributed routing.

 

 

Login to vSphere WebClient

 

Click Chrome on the Taskbar.

Login with the following credentials:

 

 

Confirm 3 Tier Application Functionality

 

 

 

Web Application Returning Database Information

 

Before you begin configuring Distributed Routing let us verify that the three tiered Web Application is working correctly. The three tiers of the application (web, app and database) are on different logical switches and NSX Edge providing routing between tiers.

The web server will return a web page with customer information stored in the database.

 

 

Removal of the App and Db Interfaces from the Perimeter Edge

 

As you saw in the earlier topology the three logical switches or three tiers of the application are terminated on the perimeter edge. The perimeter edge provides the routing between the three tiers. We are going to change that topology by first removing the App and DB interfaces from the perimeter edge. After deleting the interfaces, we will move those on to the distributed edge.  For saving the time of deploying a component, the Distributed Router has been created for you.

  1. Click the Home icon.
  2. Click on the Networking & Security button.

 

 

Select NSX Edge

 

  1. Click on NSX Edges in the left navigation pane.  
  2. Double click "edge-1" to open the Perimeter-Gateway configuration.

 

 

Select Interfaces from the Settings Tab to Display Current Interfaces

 

  1. Click on Manage Tab.
  2. Click on Settings.
  3. Click on Interfaces under the Settings navigation tab.  

You will see the currently configured interfaces and their properties.  Information includes the vNIC number, interface name, whether the interface is configured as internal or an uplink and what the current status is, active or disabled.

 

 

Delete the App and DB Interfaces

 

  1. Highlight "App Internal" interface, the Actions bar will illuminate giving specific options for the selected interface.
  2. Select the red "X" to delete the selected interface from the perimeter edge.  A warning box will pop-up asking us to confirm we want to delete the interface,
  3. Click "Ok" to confirm the deletion.  

4.*****Note: Repeat the steps to delete the "DB Internal" interface. *******

 

 

The Topology After the App and DB Interfaces are Removed from the Perimeter Edge

 

 

 

Navigate Back to the NSX Home Page

 

Now that you have removed the App and DB interfaces from the perimeter edge, you need to navigate back to the edge device screen in order to access the distributed edge.  

 

 

Add App and DB Interfaces to the Distributed Router

 

We will now begin configuring Distributed Routing by adding the App and DB interface to the "Distributed Router".

 

 

Display the Interfaces on the Distributed Router

 

  1. Click on "Manage."
  2. Click on "Settings."
  3. Click on "Interfaces" to display all the interfaces currently configured on the Distributed Router.

 

 

Add Interfaces to the Distributed Router

 

  1. Click on the Green Plus sign to add a new interface.
  2. Name the interface App_Interface
  3. Make the type Internal.

 

 

Specify the Network

 

  1. Click onSelect to open the "Connect NSX Edge to a Network" dialog box.  
  2. Select the "App-Tier-01" radio button which will be the network this interface will communicate on.
  3. Click OK.

 

 

Add Subnets

 

  1. Click the Green Plus sign in the "IP Address" dialog box to open the "Add Subnet" dialog box.
  2. Click on the Green Plus sign under "Edit IP addresses in this subnet".  This will illuminate and add an "IP Address" dialog box as well as a radio button which is already selected.
  3. Click on the IP Address box and enter 172.16.20.1 as the IP address,
  4. 24 as the "Subnet Prefix Length."
  5. Click OK to return to the main "Add Logical Router Interface" dialog box which should now have the complete configuration.  

6.     ********Then click OK again to create the new interface.********

 

 

Confirm that the App_Interface has Been Added

 

Once the system is done configuring and adding the interface, the main Interface page will be displayed where we should see the App_Interface interface you just added.  

 

 

Add the DB Interface

 

Once the system completes adding and configuring the DB_Interface, the main interface window will be displayed where we can confirm that both interfaces have now been added.  

 

 

The New Topology after Moving the App and DB Interfaces to the Distributed Router

 

After these interfaces are configured on the Distributed Router those interface configurations are automatically pushed to each host in the environment. From here on the Host's Distributed Routing (DR) Kernel loadable module handles the routing between the App and DB interfaces. So if the two VMs connected to two different subnets are running on the same host wants to communicate, the traffic will not take un-optimal path as shown in the earlier traffic flow diagram.

 

 

Optimized Traffic Flow after Enabling Distributed Routing

 

As shown in the diagram above the routing for the VMs running on the same host happens in the kernel and traffic doesn't leave the host. In this topology now the App and DB tiers are connected to one router while the Web tier is connected to Perimeter Edge Router. These two routers now have to talk to each other through dynamic routing protocol. We will now enable OSPF on both the routers to provide the communication across the tiers of the 3 tier ApplicationB

 

 

The Topology Shows how the Distributed Router and the Perimeter Edge Router are Connected to the 192.168.9.0/29 Network

 

In the above topology the Web tier of the application is connected to one router while the other two tiers are connected to a different router. So the application access will fail unless dynamic routing is enabled on both the routers

 

 

Verify that the 3 Tiered Application Stops Working

 

After making the changes, you will test that the 3 Tier Application access fails.

  1. Click on the NSX HOL - Multi-Tier App Tab
  2. Click Refresh.

The application may take a few minutes to actually time out, you may need to select the red "x" to stop the browser.  If you do see customer data, it may be cached from before and you may need to close and re-open the browser to correct it.  

Close the tab created to test connectivity to the web server. Next we will configure routing to restore the service.

Note: If you do have to re-open the browser, after verifying the 3 tier application is not working, click on the bookmark in the browser for vSphere Web Client and login again with the credentials "root" password "VMware1!".  Then click on Networking and Security, Edge Appliances and finally double-click on "Distributed-Router".

 

 

Configure Dynamic Routing on the Distributed Router

 

  1. Click the "Routing" button.
  2. Click the "Edit" button next to "Default Gateway" which will open the "Edit Default Gateway" dialog box.

Note: On this screen a button labeled 'ECMP' can be seen just under the "Router Configuration" header. This feature allows for the scaling out of layer 3 connectivity through the use of Equal Cost Multi-Path (ECMP), which is an exciting new feature enhancement in NSX 6.1. Practical examples of this feature are documented in HOL-SDC-1425 VMware NSX Advanced.

Scale out L3 enhancements included in this release include:

Key use cases from these enhancements are:

 

 

 

Default Gateway Configuration

 

  1. Enter 192.168.10.1 in the "Gateway IP" dialog box.  The gateway address in this example is the next hop router which is the perimeter-edge.  You may leave the rest of the dialog boxes as default.
  2. Click OK.  

 

 

Publish Changes

 

After the system completes publishing the changes, the screen will return to the main "Global Configuration" page with our changes for the "Default Gateway" now applied.

 

 

Edit Dynamic Routing Configuration

 

  1. Click "Edit" to the right of "Dynamic Routing Configuration" which will open the "Edit Dynamic Routing Configuration" dialog box.  
  2. Select the default router id which is the IP address of the Uplink interface 192.168.10.5.
  3. Click OK

Note: The router ID is important in the operation of OSPF as it indicates the routers identity in an autonomous system.  It is a 32 bit identifier denoted as an IP address but can be specific to the subnets interesting to the specific router. In our case, we are using a router ID that is the same as the IP address of the uplink interface on the edge device which is acceptable although not necessary.  The screen will return to the main "Global Configuration" screen and again the "Publish Changes" green dialog box appears.

 

 

Publish Changes

 

Click the "Publish Changes" button in the dialog box again to push the updated configuration to the distributed-edge device.

 

 

Configure OSPF Specific Parameters

 

We will be using OSPF as our dynamic routing protocol.

  1. Select "OSPF" in the navigation tree under "Routing" to open the main OSPF configuration page.
  2. Click "Edit" to the right of "OSPF Configuration" to open the "OSPF Configuration" dialog box.

 

 

Enable OSPF

 

  1. Click the "Enable OSPF" dialog box.  
  2. Enter 192.168.10.3 in the "Protocol Address" box.
  3. Enter 192.168.10.5 in the "Forwarding Address" box.  
  4. Verify that the "Enable Graceful Restart" dialog box is checked.
  5. Then click "OK".  

NOTE: For the Distributed Router the "Protocol Address" field is required to send the Control traffic to the Distribute router Control Virtual Machine. The Forwarding address is where all the normal data path traffic will be sent.  The screen will return to the main "OSPF" configuration window.  The green "Publish Changes" dialog box will be displayed.

NOTE: The separation of control plane and data plane traffic in NSX creates the possibility of maintaining the routing instance's data forwarding capability while the control function is restarted or reloaded. This function is referred to as "Graceful Restart" or "Non-stop Forwarding".

DO NOT PUBLISH CHANGES YET!Rather than publishing changes at every step, we'll continue though the configuration changes and publish them all at once.

 

 

Configure Area Definition

 

  1. Click the Green Plus sign which will open the "New Area Definition" dialog box.  
  2. Enter 10 into the "Area ID" box.  You may leave the other dialog boxes at their default settings
  3. Click OK.  

Note: The Area ID for OSPF is very important.  There are several types of OSPF areas.  Be sure to check the correct area the edge devices should be in to work properly with the rest of the OSPF configuration within the network.

 

 

Area to Interface Mapping

 

  1. Click the Green Plus sign under the "Area to Interface Mapping" area to open the "New Area to Interface Mapping" dialog box.  Ensure that in the "Interface" pull-down,
  2. Transit Uplink is selected.
  3. Select Area 10. You may leave the rest of the settings as default
  4. Click "OK"

If the interface pull down menu is empty, please restart the browser within the lab console and proceed through these instructions a second time.  

 

 

Publish Changes

 

You should now see the main OSPF configuration screen with our settings updates and the green dialog box for "Publish Changes"  

 

 

Confirm OSPF Routing is Enabled on the Distributed Router

 

We can now confirm that we have enabled and configured OSPF on the distributed-edge.

 

 

Configure Route Redistribution

 

 

 

Verify Route Redistribution

 

The main "Route Redistribution" window will be displayed again, with the "Publish Changes" green dialog box.  DO NOT PUBLISH CHANGES YET! 

  1. Click on the "Edit" button to the right of "Route Redistribution Status" which will open the "Change Redistribution Settings" dialog box.
  2. Verify that Route Redistribution is already enabled for "OSPF".  
  3. Click "Cancel" to return to the main "Route Redistribution" window

 

 

Configure OSPF Routing on the Perimeter Edge

 

Now we must configure the dynamic routing on the perimeter-edge device to restore connectivity to our test 3 Tier Application.  

 

 

Select the Perimeter Edge

 

From the main "Edge Services" page, our configured edge devices are displayed.  

 

 

Global Configuration for the Perimeter Edge

 

  1. Ensure you are under the "Manage" navigation tab,
  2. Select the "Routing" navigational button to get to the device routing configuration page.
  3. Click on "Global Configuration" if not displayed to open the main "Global Configuration" page.

 

 

Configure Router ID

 

The "Default Gateway" has been previously configured so we will need to edit the "Dynamic Routing Configuration"

  1. Clicking the "Edit" button to the right of its section which will open the "Edit Dynamic Configuration" dialog box.
  2. Select the default Router ID - HQ Access - 192.168.100.3 in the "Router ID" dialog box.  
  3. Click "OK"

 

 

Publish Global Configuration

 

The system will display the main "Global Configuration" window with the green "Publish Changes" dialog box.  

Once complete, the "Global Configuration" page should display our updated changes.

 

 

Configure OSPF on the Perimeter Edge

 

 

 

Configure an OSPF Area

 

  1. Click on the Green Plus sign under Area Definitions to add an OSPF area
  2. Enter Area ID 10 and leave default Type and Authentication values
  3. Click OK

 

 

Configure Area to Interface Mapping

 

  1. Click on the Green Plus sign under the "Area to Interface Mapping" area to open the "New Area to Interface Mapping" dialog box.
  2. Select "Transit_Internal" for the vNIC.
  3. Select area ID of 10.
  4. Click "OK"

Note: We are selecting the interface that we want to send the OSPF updates across, in this case, across the Transit Internal vNic.

 

 

Enable OSPF

 

  1. Click the "Edit" button to  enter the OSPF configuration dialog,
  2. Select the "Enable OSPF" button.
  3. Click "OK".

 

 

Publish OSPF Configuration Changes

 

 

 

Confirm OSPF Routing is Enabled for the Perimeter Edge Device

 

 

 

Configure Route Redistribution for the Perimeter Edge Device

 

Now that we have configured OSPF on the perimeter-edge device, we need to configure route redistribution.

 

 

Configure Route Redistribution Table

 

  1. Click the Green Plus sign under the "Route Redistribution table" to open the "New Redistribution criteria" dialog box.
  2. "Prefix name" = Any
  3. "Learner Protocol" = OSPF.
  4. Click the checkbox for "Connected"
  5. Click"OK".

 

 

Enable Redistribution

 

The main "Route Redistribution" window will be displayed again, with the "Publish Changes" green dialog box.

DO NOT PUBLISH CHANGES YET! 

  1. Click "Edit" button to the right of "Route Redistribution Status" which will open the "Change Redistribution Settings" dialog box.  
  2. Click the checkbox for OSPF
  3. Click "OK"

 

 

Publish Changes

 

 

 

Verify Communication to the 3-Tier App

 

  1. Click on the tab for the NSX HOL - Multi-Tier App.
  2. Refresh your browser to verify the 3-Tier webapp works again.

 

 

Dynamic Routing Across the Two Routers

 

Once the OSPF peering happens between the two routers. The Web tier VMs will be able to access App tier VMs connected across the distributed router.

 

This completes the section on configuring Dynamic and Distributed routing.  In the next section we will verify the configured routing.

 

Dynamic Route Advertisement and Control


In this section, we will look at various elements to see how the OSPF dynamic routing is controlled, updated, and propagated throughout the system.  We will verify the routing on the perimeter edge appliance through the console as well as verify the 3 Tiered Application is working correctly.

Special Note: On the desktop you will find a file names README.txt.  It contains the CLI commands needed in the lab exercises.  If you can't type them you can copy and paste them into the putty sessions.  If you see a number with "french brackets - {1}" this tells you to look for that CLI command for this module in the text file.


 

Verify OSPF Routing

 

Now that the OSPF configuration is complete, we can check to ensure that the OSPF routing process successfully initiates and forms a neighbor relationship between the two edge devices.  We can do this, by using ssh to connect to the perimeter-router device and examining the OSPF process.

  1. Scroll down and select "perimeter-gateway".
  2. Click Open.

 

 

SSH Security Alert

 

Note: You may get a PuTTY security alert similar to below.  This is just an ssh key verification notice.  Click "Yes" to continue

 

 

Login to PuTTy

 

Note: Remember the {#} below is just a reference to the CLI file on your desktop.  Do not include as part of your command!

At the login prompt:

If the login fails more than 3 consecutive times, PuTTY will display a failure message.  Simply begin at Step 1. to restart the process of logging into the edge device.  

 

 

Console Prompt

 

If successful, you should be presented with the prompt for the perimeter-edge device plr-01-0>

 

 

Confirm OSPF Neighbor Relationship

 

Here we can see the Neighbor ID of the router we have a routing relationship with, in this case 192.168.10.5 (Distributed Logical Router), any associated timers and the status of the OSPF neighbor process (highlighted in red box) which indicates the status of the neighbors exchanging routes.  By now, the process should have completed and "Status" indicated as "Full" meaning the OSPF process complete and routing updates completed.

 

 

Show the Routing Table

 

The 172.16.20.0/24 is the route to Application layer.

The 172.16.30.0/24 is the route to the Database layer. 

The table shows us that we have successfully attached those two subnets to the distributed-edge appliance and correctly configured routing via OSPF to the distributed-edge appliance from the perimeter-edge.

You can close the PuTTy session.

 

 

Confirm functionality of the 3 Tier Application

 

Now we will confirm that the test 3 Tier Application works which is the final confirmation that we have correctly configured dynamic routing.

  1. Begin by opening a new tab in the browser.
  2. Click on the "3 Tier WebApp Inline" bookmark.  Confirm that the test customer data appears.  
  3. Click on the web refresh button to ensure we see the customer data load balanced between the two web instances.  You can refresh it a few times to see the web instance change.

 

 

Default Route Origination

 

  1. Click the Back button to return to Networking & Security.
  2. Select the "NSX Edges" item from the navigation bar on the left.
  3. Double-Click the "edge-1" Perimeter-Gateway

 

 

Navigate to the OSPF Configuration

 

  1. Select the "Manage" tab,
  2. Select the "Routing" menu.
  3. Choose the "OSPF" item from the navigation bar to the left.

 

 

Configure OSPF Default Originate

 

  1. Click the "Edit" button to enter the OSPF Configuration.
  2. Check the box labeled "Enable Default Originate",
  3. Click the "OK" button.

Note: The Default Originate option creates a static default route to IP address 0.0.0.0/0 on the NSX edge. This route can be propagated throughout the OSPF domain by redistributing static routes under the "Route Redistribution" section of the routing configuration.

 

 

Publish the Configuration Change

 

 

 

Verify the Default Route

 

To verify that the default route has been created, ensure that a green check mark appears next to "Default Originate" on the OSPF Configuration screen.

 

 

Conclusion

At the beginning of the lab, we saw how without distributed and dynamic routing, the traffic from two VM's having different IP subnets yet residing on the same physical host had to traverse through the Perimeter-Edge to communicate with one another.  With the distributed routing we demonstrated the traffic flows did not have to leave the host.  Also, we demonstrated the dynamic routing configuration across the two routers through the OSPF protocol configuration, and some methods to control route advertisement.

In this module we demonstrated the following key benefits of the NSX platform

 

Module 4 - Distributed Firewall (60 minutes)

Distributed Firewall East-West Protection - Micro Segmentation


NSX Distributed Firewall (DFW). One component of NSXis a distributed firewall kernel module.  The distributed firewall is installed in each vSphere host to enable the functionality. The Distributed Firewall is near line-speed and has the resilience of vSphere's host platform. It is also user-identity aware and provides unique activity monitoring tools.

In this module you will explore how the distributed firewall helps protect a 3-tier application.  We will also demonstrate the firewall rule creation process based on security groups and identity rather than IP address based rules.  IP Address based rules impose hard limits on mobile VMs and reduces the flexibility of using resource pools.

This module is based on four guest VMs making up a common 3-tier application.  The web tier has two web servers (web-sv-01a and web-sv-02a). The web servers will be seen in a load balanced pool later.  The web tier communicates to a VM named app-sv-01a that is running an application software, acting as the application tier.  The app tier VM in turn communicates to a VM named db-sv-01a running MySQL in the database tier.  Enforcement of access rules between the tiers is provided by NSX DFW Firewall.  

The outline of this module is:

Start the module from your desktop.  The desktop is your Control center jumpbox in the virtual environment.  From this desktop you will access the vCenter Server Appliance deployed in your virtual datacenter.

Special Note: On the desktop you will find a file names README.txt.  It contains the CLI commands needed in the lab exercises.  If you can't type them you can copy and paste them into the putty sessions.  If you see a number with "french brackets - {1}" this tells you to look for that CLI command for this module in the text file.


 

Confirm DFW Enablement

 

First you will explore the new NSX Distributed Firewall Kernel Loadable Module.

If you are not already logged into the vSphere Web Client.

  1. Click on the Taskbar icon for Google Chrome. The home page should be the vSphere Web Client.
  2. Login using: User = root and Password = VMware1!
  3. Click Login button.

Note:  VMware1! will be the common password for all passwords during the module.

 

 

Gain screen space by collapsing the right Task Pane.

 

 

 

Explore the new NSX Distributed Firewall

 

 

 

Open Installation

 

  1. First click on Installation
  2. Click on the Host Preparation tab.  The table will show the clusters in the virtual datacenter.  

Notice that NSX is installed at the Cluster level, meaning that installation, removal, and updates all are a cluster level definition.  If later a new physical host is added to the cluster it will have NSX added automatically.  This provides a cluster level of networking and security without fear of a VM migrating to a host without NSX.

 

 

Configure Rules for Web Application Access

You will now configure Distributed Firewall access to a 3-tier application.  The application has two web servers, and one each of an application and database server.  There is also a Load Balancer servicing the two web servers.

 

 

Test 3-tier VM to VM connectivity using Putty

 

Next you will test communication and access between the network segments and guest VMs making up the 3-tier application. Your first test will be to open a console to web-sv-01a and ping the other members.

  1. Click on the Putty shortcut on the desktop taskbar.  
  2. Highlight the saved session named web-sv-01a.corp.local.  
  3. Click on Open.

 

 

Accept the Putty Security Alert

 

Click Yes if you see the security certificate warning.

Login using:

 

 

Ping from web-sv-01a to other 3-tier members

 

Note: Remember the {#} below is just a reference to the CLI file on your desktop.  Do not include as part of your command!

Now test connectivity between web-sv-01a and app-sv-01a and db-sv-01a:

(Note: You might see DUP! at the end of a Ping line.  This is due to the nature of the virtual lab environment using nested virtualization and promiscuous mode on the virtual routers. You will not see this in production.)

Don't close the window just minimize it for later use.

 

 

Demonstrate 3-tier application using a web browser

 

Using a browser you will access the 3-tier application to demonstrate the function between the 3 parts.  

  1. Open a new browser tab.
  2. Use the bookmark for 3 Tier WebApp Inline.

 

 

Demonstrate 3-tier application using a web browser-cont.

 

You should get back data that passed from the web tier to the app-sv-01a vm and finally queried the db-sv-01a vm.

The page will return which web server in the Load Balancer pool was contacted.

Refreshing your browser will Round-Robin a connection to another web server in the Load Balancer pool.

 

 

Change the default firewall policy from Allow to Block

 

In this section you will change the default Allow rule to Block and show communication to the 3-tier application to be broken.  After that you will create new access rules to re-establish communication in a secure method.

 

 

Examine the Default Rules

 

Expand the section using the "twistie."  

Notice the Rules have green check marks.  This means a rule is enabled.  Rules are built in the typical fashion with source, destination, and service fields.  Services are a combination of protocols and ports.  

The last Default Rule is a basic any-to-any-allow.

 

 

Explore the Last Default Rule

 

Scroll to the right and you can see the Action choices for the Default Rule by placing the cursor in the field for Action:Allow.  This will bring up a plus sign that allows you to see the choices for this field.

 

 

Change the Last Default Rule Action from Allow to Block

 

  1. Select the Block action choice and select.
  2. Click OK.  

 

 

Publish the Default Rule changes

 

You will notice a green bar appears announcing that you now need to choose either to Publish Changes, Revert Changes or Save Changes.  Publish pushes to the DFW.  Revert cancels your edits.  Save Changes allows you to save and publish later.

 

 

Verify the Rule change blocks communication

 

To test the block rule using your previous Putty and browser sessions

 

 

Create 3-Tier Security Groups

 

Service Composer defines a new model for consuming network and security services in virtual and cloud environments. Polices are made actionable through simple visualization and consumption of services that are built-in or enhanced by 3rd party solutions. These same polices can be made repeatable through export/import capabilities, which would help make it easier to stand up and recover an environment when there is an issue. One of those objects for repeatable use is a Security Group.

 

 

Add Security Group

 

  1. Select Security Groups.Notice there are existing security groups to be used in another lab module.
  2. To add a new security group click the New Security Group icon.

 

 

New Security Group - Web

 

 

 

Select objects to include

 

  1. Pull down the Object Types and select Virtual Machines.
  2. You can filter by typing web into the search widow.
  3. Select web-sv-01a
  4. Click the Right Hand arrow to push the VM to the Selected Objects window.  Repeat for web-sv-02a
  5. Click Finish.

Note:  As a shortcut you can double-click the VMs on the left and they will move to the right in this one step.

 

 

Verify Security Group Creation

 

You have created a security group named Web-tier having 2 VMs assigned.

 

 

Create 3-Tier Access Rules

 

Next you will add new rules to allow access to the web vm and then set up access between the tiers.  

 

 

Add New Rule Section for 3-Tier Application

 

  1. On the far right of the "Default Section Layer3 (Rule 1 - 4)" row click on Add Section which looks like a folder.
  2. Name the section 3-tier App for the name.  
  3. Click OK.

 

 

Add Rule to New Section

 

 

 

Edit New Rule

 

  1. Click the "twistie" to open the rule.
  2. Hover in upper right of the Name field until the plus sign appears and click on it.
  3. Enter "Ext to Web" for the name.  
  4. Click OK.

 

 

Set Rule Source and Destination

 

Source:Leave the Rule Source set to any.

 

 

Set Security Group values

 

Destination:

  1. Pull down the Object Type and scroll down until you find Security Group.  
  2. Click on Web-tier
  3. Click on the top arrow to move the object to the right.  
  4. Click OK.

 

 

Set Rule Service

 

Again hover in the Service field and click on the plus sign.  (

  1. In the search field you can search for service pattern matches.  Enter "https"and press enter to see all services associated with the name https.
  2. Select the simple HTTPS service
  3. Click on the top arrow
  4. Note: Repeat the above steps to find andadd SSH.  (You will see later in the module that we need SSH.)
  5. Click OK.

Note: This will cause the green bar with the option to publish or revert changes.  DO NOT Publish, as you have more rules to make.

 

 

Create Rule to Allow Web Security Group Access to App Logical Switch

 

You will now add a second rule to allow the Web Security Group to access the App Security Group via the App port.  

  1. Start by opening the plus sign.  
  2. You want this rule to be processed below the previous rule so choose Add Below from the drop down box.

 

 

Create Second Rule Name and Source fields

 

  1. As you did before hover the mouse over the Name field and click the plus-sign.  Enter "Web to App" for the name.
  2. Choose Web-tier Security Group for the Source field.

 

 

Create Second Rule Destination field: Choose Logical Network

 

In the first rule you used the Web-tier security group as the destination.  You could proceed with the remaining rules in the same fashion.  But as you see from the drop-down you can use several vCenter objects already defined.  A powerful time saving aspect of the integrated vSphere with NSX Security is you can use existing virtual datacenter objects for your rules rather having to start from scratch.  Here you will use a VXLAN Logical Switch as the destination. This allows you to create a rule to be applied to any VM attached to this network.

  1. Scroll down in the Object Type drop-down and click on theLogical Switch choice.  
  2. SelectApp_Tier-01
  3. Click on the top arrow to move the object to the right
  4. Click OK.

 

 

Create Second Rule Service Field: New Service

 

The 3-tier application uses tcp port 8443 between the web and app tiers.  You will create a new Service called MyApp to be the allowed service.

  1. Click on New Service.
  2. Enter MyApp for the new service name.
  3. Select TCP for the Protocol.
  4. Enter 8443 for the Port number.
  5. Click OK.

 

 

Click OK

 

 

 

Create Third Rule: Allow Logical Switch App to Access Logical Switch Database

 

Repeating the steps: On your own create the third and last rule giving access between the App-tier and the Database-tier.

  1. Create the final rule allowing the App Logical Switch to communicate with the Database Logical Switch via the predefined service for MySQL.  The service is predefined so you will only have to search for it rather than create it.
  2. Publish Changes.

 

 

Verify New Rule Allow 3-Tier Application Communication

 

 

 

Restart Putty Session to web-sv-01a

 

  1. Click the Session icon in the upper left
  2. Click Restart Session.

 

 

Ping Test between Tiers

 

Try to ping 3-tier application guest VMs.

Note: Remember the {#} below is just a reference to the CLI file on your desktop.  Do not include as part of your command!

  1. {4} ping -c 2 172.16.10.12 (other web server)
  2. {5} ping -c 2 172.16.20.11 (app server)
  3. {6} ping -c 2 172.16.30.11 (database server)

Pings are not allowed and will fail as ICMP is not allowed between tiers or tier members in your rules.  Without allowing for ICMP between the tiers the Default Rule now blocks all other traffic.

 

 

Topology After Adding Distributed Firewall Rules for the 3-Tier Application

 

The diagram shows the relative enforcement point of the vNIC level firewall.  Although the DFW is a Kernel Loadable Module (KLM) of the vSphere ESXi Host the rules are enforced at the vNIC of the guest VM.  This protection moves with the VM during vMotion to provide complete fulltime protection not allowing for a "window of opportunity" during which the VM is susceptible to attack.

 

Identity Based Firewall Rules



 

Identity Base Firewall Rules

The NSX suite now provides you the ability to create rules using Active Directory Groups.  This allows you to control the access of users to other security objects such as networks, IP addresses, and other security groups.

Before you begin creating User based rules you need to link NSX to an Active Directory.

 

 

Explore Link between NSX and Active Directory

 

On the left go down to the NSX Managers.  Notice it denotes only one.  

 

 

Choose NSX Manager

 

 

 

Explore Domain Connector

 

Notice that the table has an entry.  This is pre-configured for another lab module but you will step through the process so you have the opportunity to review how the connection was created.  

This connection requires you to provide AD information so that vCenter can access AD for group information.  NOTE: This is different from associating a vCenter to AD for permissions used in Users/Roles.  

  1. Click on Manage tab.
  2. Click on Domains tab.
  3. Click on corp.
  4. Click on Edit.

 

 

Provide NetBIOS Name

 

For the name field you would enter a name.   You would next enter the NetBIOS name for the domain.  In this case it is CORP.  

 

 

Provide LDAP Options

 

You would enter the IP Address or FQDN for the Domain Controller.  Next you will enter a Username/Password for a user with READ rights to the domain.

 

 

Security Event Log Access Options

 

Here you would enter settings for the log access.

 

 

Ready to Complete - Verify Settings

 

Now you would verify all your settings.

 

 

AD Synchronization

 

  1. Click the "Double-Gear"
  2. Click the "Single-Gear" to get updates from the AD.  You should see a Success Status and the current date.

With a configured and synchronized AD connection you are ready to make use of the AD Groups in your security policies.

 

 

Create a Security Object based on AD Groups

 

  1. Click the Home icon.
  2. Click on Networking & Security.

 

 

Edit Ext to Web Rule

 

You are going to add a Domain Group to the Source field of the Ext to Web rule.

  1. Click on Firewall.
  2. Click on the plus-sign in the Source Field.
  3. Select Security Group in the Object Type pull-down.
  4. Click on New Security Group.

 

 

Name New Security Group - AD Sales

 

  1. Enter AD-Sales for the name.
  2. Click on Select objects to include.

 

 

Select Objects to include

 

  1. Select Directory Group from Object Type.
  2. Filter by entering Sales in the Search window.
  3. Select Sales From Available Objects.
  4. Click on the Right-hand Arrow to move Sales to the Selected Objects window.
  5. Click Finish.

 

 

Click Ok on Settings.

 

 

 

Publish Changes

 

You now have a Domain Group, AD-Sales, set as the source for access to the Web-tier.  In this case a user will have to be a member of the AD Group Sales to gain access to the Web-tier of the 3-tier application.

 

 

Test User Identity Rule

 

You can test the new Identity based rule by opening a console to another VM in the domain and logging in as a member of the Active Directory Sales Group.  User:Sales1 is a member of the Sales Group.  User:NonSales is not a member of the group.  You will login as each and see the results of trying to access the 3-tier application.

  1. Clicking on the Home icon
  2. Click on the VMs and Templates.

 

 

Open Console to iis-w-01a

 

Expand the containers "Hands on Labs" and "Discovered virtual machines" to find iis-w-01a.

  1. Right click on iis-w-01a.
  2. Click on Open Console.

 

 

Login in as NonSales

 

 

 

Login as nonsales

 

  1. Enter User name = nonsales, Password = VMware1!
  2. Click OK.

 

 

Open Internet Explorer

 

User nonsales is not part of the AD-Sales Group an is blocked from accessing the 3-tier application.

 

 

Log Off as nonsales

 

  1. Click on Send Ctrl-Alt-Del.
  2. Click Log Off...

 

 

Log On as sales1

 

  1. Click on Send Ctrl-Alt-Del.
  2. Enter Sales1 for the User name. Password is VMware1!.
  3. Click OK.

 

 

Use IE and access 3-tier Application

 

Open IE from the Taskbar.

  1. Click on the "NSX HOL - Muti-Tier App" Favorite
  2. Accept the risk.

 

 

Verify Access

 

User Sales1 is a member of the AD-Sales group and allowing access to the 3-tier application.

 

Demonstrate New Unified Firewall Management



 

Demonstrate new Unified Management

NSX 6.1 offers a new Unified Management of the Edge Services Gateway's Firewall and the Distributed Firewall.  The two firewalls can now be controlled with a single rule entry.  You will make a change to the existing firewall rules to include the Edge Firewall and show that the Edge is now taking a protective posture.

 

 

Review Existing Edge Gateway Firewall Rules

 

Click on the browser tab for the vSphere Web Client

  1. Click on the Home Icon.
  2. Click on Networking & Security.

 

 

Open Edge-1 Perimeter Router

 

  1. Click on the NSX Edges.
  2. Double-click on the edge-1 (Perimeter-Gateway).

 

 

Review Edge Firewall

 

  1. Click on the Manage Tab.
  2. Click on the Firewall Tab.

Note: If you continued to this module from Module 3 you will see an additional rule for OSPF in the number 2 position and the Default Rule will be number 3.

Notice that the Default Rule is an Any-Any-Any-Allow.  This means that currently the Edge is allowing all traffic to pass through.

3.     Click on the "Back/History" button to return to the Networking & Security menu.  

 

 

Review Existing DFW Rules

 

Notice the current DFW rule has a rule allowing SSH to the Web-tier security group only if you are a member of the AD-Sales group.

 

 

Edit DFW Rule - set source to Any

 

 

 

Edit DFW Rule - set rule to log

 

  1. Scroll right and click the plus-sign in the Action field.
  2. Select Block for the Action.  New to 6.1 is the Action-Reject.  This will send a TCP Reset to clear the session.  Block drops the packet without response.
  3. Select Log radio button.
  4. Click on OK.

 

 

Edit DFW Rule - set

 

  1. In the Applied To field click the plus-sign. (Not shown in the capture)
  2. Click the Perimeter-Gateway.
  3. Click the top, right-hand arrow to move the object to the Selected Objects list.
  4. Click OK.

Notice that the New Unified Management window allows you to select the application of the rule to "all Edge gateways" or to selectively pick from the Available Objects list.

 

 

Edit DFW Rule - Add Rule-ID

 

  1. Click on the "Add column" icon.
  2. Click the check box for Rule-ID.

 

 

Publish Changes

 

Note that this rule has the Rule-ID of 1008 (if your number is different take note of it for later).  You will look for this number in the logs to identify this rule.

 

 

Review DFW Rule

 

The edited DFW rule shows that Any to Web-tier for SSH will now be Block the packet.  This rule now applies to the Edge Perimeter-Gateway as well as the DFW.

 

 

Review Edge FW Changes due to Unified Management

 

  1. Click on NSX Edges.
  2. Double-click on the edge-1 (Perimeter-Gateway).

 

 

Review Edge FW Pre-Rules

 

  1. Click on the Manage tab.
  2. Click on the Firewall tab.
  3. Click on the Add-column icon.
  4. Check the Rule-Tag. (Rule-tag here is the same as Rule-ID in DFW)

Note that a new rule has been added to the Edge in the form of a Pre-Rules.  The Rule-Tag is the same number as in the DFW earlier.

 

 

Open SSH to Edge to read FW log entries

 

Open or start a new Putty Session.

  1. Choose the perimeter-gateway (192.168.100.3)
  2. Click Open.

Click Yes on the Security Warning.

 

 

Change PuTTy window settings

 

  1. Click the Window icon to get the PuTTy menu.
  2. Click Change Settings.

 

 

Change PuTTy columns.

 

  1. Click Window.
  2. Enter 100 for the Column value.
  3. Click Apply.

 

 

View the Edge FW

 

Note: Remember the {#} below is just a reference to the CLI file on your desktop.  Do not include as part of your command!

You will now see the live log entries from the Edge Firewall.

 

 

Open SSH to web-sv-01a

 

  1. Open a second Putty session by clicking on the upper-left session icon.  Choose Start New Session.
  2. Choose web-sv-01a
  3. Click Open.

Your session will timeout with a Putty Fatal Error.

 

 

Review Edge Log for Block

 

Click back to the Putty Session for the Perimeter-Router

Enter a Cntl+C to stop the log follow command.

  1. Rule-ID AND Action: Drop_1008 (Remember, if your Rule-ID was different look for your number in the log)
  2. Source: 192.168.110.10 (ControlCenter - Jumpbox)
  3. Destination: 172.16.10.11 (web-sv-01a)
  4. Protocol: TCP
  5. Port: 22 (SSH)

This demonstrates that a rule placed in the DFW window can be pushed to the Edge at the same time.

 

 

Optional - Lab Clean Up

 

If you are continuing on to Module 5 - Edge Services Gateway, you will need to change a few firewall rules to clean up your work in this module.

  1. Click the Home icon.
  2. Click on Networking & Security.

 

 

Click on Firewall

 

 

 

Delete 3-Tier App Section

 

  1. Scroll to the far right of the 3-tier App section.  Click the Red-X to delete the entire section.
  2. Click Yes.

 

 

Change Default Rule back to Allow

 

  1. Click on the "twistie" next to the Default Section
  2. Click on the "plus-sign" on the Action column for the Default Rule.
  3. Change the Action to Allow.
  4. Click OK.

 

 

 

Publish Changes.

 

You are now ready to proceed to Module 5.

 

Module 5 - Edge Services Gateway (30 minutes)

NSX Edge Services Gateway - VPN (SSL VPN-Plus)


VMware's NSX platform provides the ability to perform a number of logical networking services.  In this module, you'll be focusing on some of the logical services offered by the NSX Edge Services Gateway. The Edge Services Gateway (ESG) provides network gateway and security services for a virtualized network or networks.  

In this module, the services provided by the Edge Services Gateway that you will be focusing on will be:

This module will start with the client-based VPN services, and will then lead to handling the load balancing of the web servers utilized in previous modules. Lastly, you'll go and power off one of two deployed ESGs in an HA state to observe the failover of traffic and services to the standby ESG.

The topology of this module includes two web servers (web-sv-01a and web-sv-02a) that sit on the "front end" of the 3-tier web app presented in this lab, a "middleware" layer (app-sv-01a), and a "backend" database server (db-sv-01a).

IP Addresses

*-Designates Edge Services Gateway

*Perimeter-Router-0 - 192.168.10.2

web-sv-01a - 172.16.10.11

web-sv-02a - 172.16.10.12

app-sv-01a - 172.16.20.11

db-sv-01a - 172.16.30.11

 

 


 

Logging into the vSphere Web Client

 

If you are not already logged into the vSphere Web Client.

  1. Click on the Taskbar icon for Google Chrome. The home page should be the vSphere Web Client.
  2. Login using: User = root and Password = VMware1!
  3. Click Login button.

Note:  VMware1! will be the common password for all passwords during the module.

 

 

Improving Screen Real-Estate

 

Clicking on the Push-Pin will allow the right-hand pane to collapse and provide more viewing space to the main pane.  You can also collapse the left-hand pane to gain the maximum space.

 

 

Open Networking & Security Section of Web Client

 

 

 

List deployed NSX Edge Service Gateways

 

  1. First, click on NSX Edges, and then
  2. Double click on the item labelled as edge-1.

You will notice that there are three NSX Edges here.  Later on in this module, you'll return here to work on the OneArm-LoadBalancer.

 

 

Working with NSX Edge Services Gateway

 

This is the management page for this particular NSX Edge Services Gateway.  From here, one can observe/change the IP addresses of the different interfaces of the ESG, and configure the different services offered by this particular Edge Services Gateway.  

To continue with the configuration of the client-based SSL (SSL VPN Plus) service,

  1. Click on the Manage tab.
  2. Click on the SSL VPN Plus sub-tab.

 

 

SSL VPN-Plus Service

 

From here, one can observe the operational details of the SSL VPN service.  Take note that the service is currently disabled (see the red arrow above). You will not be enabling the service quite yet.

 

 

Server Settings

 

Under Server Settings, one can assign the IP address and port used to provide the SSL VPN service on the Edge Services Gateway.  This will be the actual VPN endpoint that clients connect to initiate the VPN tunnel.  

  1. Click on Server Settings.
  2. Click on Change button to continue with the configuration.

 

 

Configure Server Settings

 

For the Server Settings, enter the following values:

  1. Cipher List: AES256-SHA
  2. Click the OK button.

DO NOT UNCHECK the Default Certificate.

 

 

IP Pool

 

A list of IP addresses to provide to connecting clients will need to be configured, so that's what you'll be performing next:

  1. Click on IP Pool.
  2. Click on the green plus sign to open the Add IP Pool popup window.

 

 

Add IP Pool

 

Here is where one would configure the list of IP addresses available for connecting clients, as well as what will be passed to those users for a gateway, primary/secondary DNS servers, DNS search suffix, and WINS server.

  1. For the IP range, enter 172.16.31.200 as the starting IP address, and 172.16.31.205 as the ending IP address.
  2. The 172.16.31.0 network is a /24 network, so enter 255.255.255.0 as the netmask.
  3. Enter 172.16.31.1 as our gateway for this IP Pool.
  4. Click OK.

 

 

Private Networks

 

This is where one would configure what IP networks are to be reachable via the usage of the SSL VPN Client.  These are the destinations that one would configure to have traffic encrypted.  Conversely, networks can be specified so that traffic to those networks is not encrypted.  To configure a new private network...

  1. Click on Private Networks.
  2. Click the green plus sign to open the Add Private Network popup window.

 

 

Add Private Network

 

  1. 172.16.10.0 (This will be the network address for what we're allowing access to via the VPN.)
  2. 255.255.255.0  (This is the corresponding subnet mask for the network defined in step 1.)
  3. Click the OK.

Options:

 

 

Authentication

 

Next up will be configuring the method of authentication for our clients utilizing the SSL VPN-Plus service.  There are a number of methods supported for Authentication, including Active Directory and LDAP.  For your lab, you'll be configuring a local authentication store on the Edge Services Gateway itself.

To do so:

  1. Click Authentication
  2. Click the small green plussign to bring up the New Authentication Server popup.

 

 

Add Authentication Server

 

For your new authentication server for this Edge Services Gateway set the following options (leave the default for all other options):

  1. Authentication Server Type:  LOCAL
  2. Click the OK button

Now that you have an authentication server ready to go, you'll need to create a user account to utilize for the client. That's next!

 

 

Users

 

To continue with the process of creating a new user for your newly created local authentication store:

  1. Click Users
  2. Click the small green plussign to bring up the new user popup.

 

 

Add New User

 

You have the option here to set what you'd like for a User ID and other options, but here are some suggested values that may be easy to remember for the rest of the lab:

(If you decide to use different values for User ID and Password, be sure to make sure you'll remember them before continuing!)

  1. User ID:  user1
  2. Password:  VMware1!
  3. Click the checkbox for Password never expires so that it's checked.
  4. When you're finished, click the OK button to create this new user.

With a new user and authentication store made, your next step will be to create an "Installation Package," which contains the actual client installer for your user's workstations.

 

 

Installation Package

 

To continue with the creation of a new Installation Package, perform the following actions:

  1. ClickInstallation Package
  2. Click the small green plus sign to bring up the new Installation Package popup.

 

 

Add Installation Package

 

Before you go into the configuration of the installation package here, it's worth highlighting some of the options here that you won't be configuring.  By default, an installation package is for a Windows client, and as such has some extra installation parameters to make deployment easier for systems administrators, such as silent mode installation, the ability to make the SSL client network adapter invisible, hiding the system tray icon, etc.

Also, you have the ability to generate an installation package for both Linux and Mac clients.  An installation package can be for all three client OS types, if so desired.  

For your lab, we'll only be configuring the Windows client, so follow these steps:

  1. Profile Name: winPackage1
  2. Enter 192.168.100.3 for a gateway address.
  3. Click the OK button to save that gateway server option for this installation package.
  4. Click the OK button to accept the configuration for this new Installation Package.

After this, you'll be configuring the Client Configuration behavior for this SSL VPN-Plus instance.

 

 

Client Configuration

 

 

 

Portal Customization

 

The SSL VPN-Plus service also provides the ability to customize the Web Portal where users will download the SSL VPN client.  There are a number of options available here that can be changed such as logo, color scheme, company name, and individual icons for the connected state of the clients.  You'll be leaving all of these on the defaults, but it's worth mentioning that there is a fair amount of customization that is possible here.

 

 

Enabling the SSL VPN Service

 

All that's left to do at this point is enable the SSL VPN-Plus service itself.  

  1. Click on Dashboard,
  2. Click on the Enablebutton
  3. Click Yes, to turn on the SSL VPN-Plus service.  

Next, you'll be logging into the Web Portal to download the Client Installation Package you configured earlier, and then install the client and utilize it to create a new SSL VPN connection from your Control Center.

 

 

Prepare Edge Firewall rule To Block Traffic between ControlCenter and web-sv-01a

 

You will now create a firewall rule to block traffic between the ControlCenter and web-sv-01a.  This is needed to test and prove the use of the SSLVPN.

  1. Click on the Firewall tab
  2. Click on the green plus sign to add a rule.

 

 

Set Rule Name

 

  1. Hover the mouse in the Name column to click on the plus-sign box.
  2. Enter "Block Control to web" for the name.
  3. Click OK.

 

 

Set Rule Source

 

  1. Pull down to select the object type: IP Sets.
  2. Select the ControlCenter object.
  3. Click the top right-hand arrow to move the ControlCenter into the Selected Objects widow.
  4. Click OK.

 

 

Set Rule Destination

 

  1. Scroll down to select the Object Type: Virtual Machine.
  2. Enter web as the filter and press enter.
  3. Select web-sv-01a.
  4. Click the top right-hand arrow to move web-sv-01a into the Selected Objects window.
  5. Click OK.

 

 

Set Rule Action

 

  1. Hover the mouse in the Action column to click on the plus-sign box.
  2. Set Action to Deny.
  3. Click OK.

 

 

Publish the Rule to the Edge Gateway

 

 

 

Verify no route for 172.16.10.0 network on Control Center

 

 

 

Verify no route for 172.16.10.0 network on Control Center

 

Notice that there is no entry for the 172.16.10.0 network before we install and connect our SSL-VPN connection.

 

 

Test ping to web-sv-01a

 

Test a ping connection between the ControlCenter and web-sv-01a.

 

 

Obtain the SSL VPN Client - Open a new browser tab

 

  1. Click on a new tab in the browser.
  2. Note: Remember the {#} below is just a reference to the CLI file on your desktop.  Do not include as part of your command!                                                              Enter  {3} https://192.168.100.3/sslvpn-plus/ for the URL address.
  3. Click on Proceed anyway.

 

 

Obtain the SSL VPN Client - Logging into the Web Portal

 

Login:

 

 

Obtaining the SSL VPN Client - Downloading the Client

 

Once successfully logged in, you'll be presented with the available list of Installation Packages that you have already configured.  You should be logged in with the user you created earlier, and you'll notice the Installation Packages previously configured.  

 

 

Installing the SSL VPN Client

 

  1. Click the Maximize button to have this window go full screen.
  2. Click the "click here" link to start the download of the SSL VPN client installer.
  3. After download is finished click the installer.

 

 

Installing the SSL VPN Client Part 2

 

 

 

Confirm Installer

 

 

 

Open SSLVPN-Plus Client

 

  1. Click on the "Show hidden icons" button in the lower right of the Taskbar.
  2. Double-click the SSLVPN-Plus icon.

 

 

Utilizing the SSL VPN Client Part 1

 

One the installer has finished, the client should automatically launch with a window much like in the screenshot above.  Click the Login button to continue with your first use of the client.

 

 

Utilizing the SSL VPN Client Part 2

 

  1. User Name: user1
  2. Password: VMware1!
  3. Click OK

 

 

SSLVPN-Plus Established.

 

 

 

Verify IP Address assignment from SSL IP Pool and Ping connectivity

 

Open Command Prompt window again.

Notice that you were given 172.16.31.200 as an IP address from the VPN Pool.  

 

 

Verify connectivity with Ping

 

And that now you can ping web-sv-01a behind the firewall.

 

 

Show route table after SSLVPN established

 

Show the route table again to see the entries made by the SSLVPN-Plus client.

After establishment of the vpn you will see that the route table now has an entry for the 172.16.10.0 network pointing to the 172.16.31.1 gateway address.

 

 

Disconnect SSL-VPN Client

 

  1. Click on the Hidden Icons button.
  2. Double-Click on the SSL-VPN icon.
  3. Click Logout.
  4. Click Yes.

 

 

Remove the Firewall Rule.

 

To prepare for the following sections, you need to disable the SSL VPN-Plus service on the Edge Service Gateway.

  1. On the Firewall Rule you created, hover the mouse next to the number to expose and click the plus-sign box.  
  2. Click Delete.

 

 

Confirm Rule Deletion.

 

 

 

Publish the Rule Removal.

 

 

 

Disabling SSL VPN-Plus Service

 

To disable the SSL VPN-Plus Service, go back to the vSphere Web Client, navigate to the management page for the Edge Service Gateway you worked with earlier, and under the SSL VPN-Plus service,

  1. Click on the SSL VPN-Plus tab.
  2. Click on Dashboard.
  3. Click on theDisable button and click Yes to confirm.

You can now move onto the next section of this module.

 

NSX Edge Services Gateway - Logical Load Balancing


The NSX Edge Services Gateway can also provide load balancing functionality.  Employing a load balancer is advantageous as it can lead towards a more ideal resource utilization scenario. Such a scenario includes a more efficient usage of network throughput, shorter response times for applications, the ability to scale, and can also be part of a strategy for service redundancy.

TCP, HTTP, or HTTP requests can be load balanced utilizing the NSX Edge Services gateway, as it can provide load balancing up to Layer 7 of the Open Systems Interconnection model (OSI).  

In this section, you will be creating and configuring a new NSX Edge, then modifying a pre-made one to perform two kinds of load balancing scenarios:


 

New Edge Services Gateway - Topology

 

 

 

Creating a New Edge Services Gateway

 

You'll be configuring the one-armed load balancing service on a new Edge Services Gateway, so to get started with that new Edge creation process, make sure you're in the Networking & Security section of the vSphere Web Client,

  1. Click on the Back button to move back one level.
  2. Click on NSX Edges.
  3. Click the green plus sign icon.

 

 

Defining Name and Type

 

For your new NSX Edge Services Gateway, set the following configuration options

  1. Enter Name: OneArm-LoadBalancer.
  2. Click the Next button.

 

 

Configuring admin account

 

One has the option of configuring an account with read-only functionality. This may be of use in troubleshooting issues via the VMware Remote Console, or remotely via SSH.  In this section of the New NSX Edge installation process, you will configure a read-only user to access the CLI of the NSX Edge, while leaving the Enable SSH access, and Enable High Availability disabled.  High Availability will be revisited in the next section of this lab module.  For this particular Edge, configure the following settings:

Configure your credentials with the following:

  1. Set the password as: VMware1!VMware1! 
  2. Click the Next button.

 

 

Defining Edge Size and VM placement

 

There are four different appliance sizes that one can choose for their Edge Service Gateway, with the following specifications (#CPUs, Memory):

You'll be selecting a compact sized Edge for this new Edge Services Gateway, but it's worth remembering that these Edge Service Gateways can also be upgraded to a larger size after deployment.  To continue with the new Edge Service Gateway creation:

 

 

Cluster/Datastore placement

 

  1. Select Management and Edge Cluster for your Cluster/Resource Pool placement
  2. Select ds-site-a-nfs01 for your Datastore placement.
  3.  Click theOK.

 

 

Confirming Edge Size and Placement

 

Review your settings/selection of Hands on Labs is selected for the Datacenter placement, Compact is the chosen size of this new Edge, and the Deploy NSX Edge checkbox is checked. Once you have confirmed those settings, cl

 

 

Placing a new network interface on the NSX Edge

 

Since this is a one-armed load balancer, it will only need one network interface.  In this section of the New NSX Edge process, you will be giving this Edge a new network adapter and configure it.  

 

 

Configuring the new network interface for the NSX Edge

 

This is where you will be configuring the first network interface for this new NSX Edge.  

  1. Name the new interface the name of WebNetwork.  
  2. Clicking the Select link.

 

 

Selecting Network for New Edge Interface to Connect to.

 

This one-armed load balancer's interface will need to be on the same network as the two web servers that this Edge will be providing Load Balancing services.

  1. Select the Logical Switch tab to display all logical switches.
  2. Select the radio button for "Web-Tier-01 - 5001".
  3. Click the OK button.

 

 

Configuring Subnets

 

Next, you'll be configuring an IP address for this interface

 

 

Configuring Subnets Popup

 

To add a new IP address to this interface:

  1. Click the small green plus sign icon to add a new row to the list of IPs.
  2. Enter an IP address of 172.16.10.10.
  3. Click the OK button to confirm this new IP address entry.
  4. Enter a subnet prefix length of 24.
  5. Click the OK button.

 

 

Confirm New Network Interface Configuration

 

 

 

Confirm List of Interfaces

 

 

 

Configuring the Default Gateway

 

This next section of provisioning a new Edge allows you to configure the default gateway for this Edge Services Gateway.  To configure the gateway:

  1. Enter a gateway IP of 172.16.10.1.
  2. Click the Next button.

 

 

Configuring Firewall and HA options

 

To save time later, you have the ability to configure some default Firewall options, as well as enable an Edge Services Gateway to run in High Availability (HA) mode.  Neither feature is relevant to this particular section of the module, so to continue, configure the following:

  1. Check the checkbox for Configure Firewall default policy.
  2. Select Accept as the Default Traffic Policy.
  3. Click Next.

 

 

Review of Overall Configuration

 

 

 

Monitoring Deployment

 

To monitor deployment of the Edge Services Gateway,

Afterwards, you should see the progress of the Edge deployment.  

 

 

Configure Load Balancer Service

 

The above depicts the eventual topology you will have for the load balancer service provided by the NSX Edge Services Gateway you just deployed.  To get started, from within the NSX Edges area of the Networking & Security plugin for the vSphere Web Client, double click on the Edge you just made to go into its management page.

 

 

Configure Load Balancer Feature on OneArm-Load Balancer

 

 

 

Navigating to New Edge's Management Page

 

  1. Click  the Manage tab,
  2. Click Load Balancer sub-tab.
  3. Click Global Configuration.
  4. Click the Edit button to go to the Edit Load Balancer global configuration popup window.

 

 

Edit Load Balancer Global Configuration

 

To enable the load balancer service;

  1. Check the checkbox for Enable Load Balancer.
  2. Click the OK button.

 

 

Creating a New Application Profile

 

An Application Profile is how you define the behavior of a typical type of network traffic.  These profiles are then applied to a virtual server (VIP) which then handles traffic based on the values specified in the Application Profile.  

Utilizing profiles can make traffic-management tasks less error prone and more efficient.  

  1. Click on Application Profiles.
  2. Click on thegreen plus sign icon to bring up the New Profile popup window.

 

 

Configuring a New Application Profile HTTPS

 

For the new Application Profile, configure the following options:

  1. Name: OneArmWeb-01.
  2. Type: HTTPS.
  3. Check the checkbox for Enable SSL Passthrough. This will allow HTTPS to terminate on the pool server.
  4. Click the OK button when you are done.

 

 

Create New Pool

 

A group of servers of Pool is the entity that represents the nodes that traffic is getting load balanced to.  You will be adding the two web servers web-sv-01a and web-sv-02a to a new pool. To create the new pool, first

  1. Click on Pools,
  2. Click the green plus sign icon to bring up the Edit Pool popup window.

 

 

Configuring New Pool

 

For the settings on this new Pool, configure the following:

  1. Name: Web-Tier-Pool-01
  2. Monitors: default_https_monitor
  3. Click thegreen plus sign icon.

 

 

Add web-sv-01a and web-sv-02a as Pool members

 

  1. Enter web-sv-01a as the name.
  2. Enter 172.16.10.11 as the IP Address.
  3. Enter 443 for the Port.
  4. Enter 443 for the Monitor Port.
  5. Click OK.

Repeat the process for:

 

 

Save Pool Settings

 

Save Pool Settings.

 

 

Create New Virtual Server

 

A Virtual Server is the entity that accepts traffic from the "front end" of a load balanced service configuration.  User traffic is directed towards the IP address the virtual server represents, and is then redistributed to nodes on the "back end" of the load balancer. To configure a new Virtual Server on this Edge Services Gateway, first

  1. Click Virtual Servers,
  2. Click the small green plus sign icon to bring up the New Virtual Server popup window.

 

 

Configure New Virtual Server

 

Please configure the following options for this new Virtual Server:

  1. Name this Virtual Server Web-Tier-VIP-01.
  2. Enter IP address of 172.16.10.10.
  3. Select HTTPS as the protocol.
  4. Select Web-Tier-Pool-01, or whatever you named the new Pool you previously created.
  5. Click the OK button to finish creating this new Virtual Server.

 

 

Test Access to Virtual Server

 

  1. Click on a blank browser tab
  2. Click on the Favorite Bookmark for "3 Tier WebApp One..."
  3. Click on the Proceed anyway.

 

 

Test Access to Virtual Server

 

At this time, you should be successful in accessing the one-armed load balancer you just configured!  

 

 

Show Pool Statistics

 

To see the status of the individual pool members:

  1. Click on Pools
  2. Click Show Pool Statistics.
  3. Click on "pool-1".

You will see the each member's current status.

 

 

SSL Offload - Terminate the SSL session on the Load Balancer

 

For this next section, you will be introduced to SSL termination into the load balanced service.  This will allow you to terminate the SSL session on the Load Balancer.  This will allow you to use HTTP between the Load Balancer and pool member servers.  

You will configure the "edge-1".

To begin, first return to the list of NSX Edges under Networking & Security in the vSphere Web Client.  

 

 

Navigate to Management Page for Perimeter-Gateway

 

 

 

SSL Certificate Generation

 

You will need to first go through the process of generating a self-signed certificate. To begin,

  1. Click on the Settings button.
  2. Click Certificates.  
  3. Click on the Actions button.
  4. Select Generate CSR to open the popup window for creating a Certificate Signing Request.

 

 

Generate Certificate Signing Request

 

For the parameters of this certificate signing request:

  1. For the Common Name AND Organization Name, type in web-app.corp.local
  2. Type in VMWorld for the Organization Unit
  3. Type in San Francisco for Locality,
  4. CA for State,
  5. Select United States [US] for Country.
  6. Click the OK button to continue.

 

 

Self Sign the Certificate Signing Request

 

Next you will sign the certificate signing request we generated in the previous step.

  1. Click on theActions.
  2. SelectSelf Sign Certificate.

 

 

 

Set Certificate Life Span

 

  1. Enter in 365 for the number of days for this self-signed certificate to be valid.
  2. Click OK.

 

 

Verify Self Signed Certificate Creation

 

You will be able to observe an entry of type Self Signed issued to web-app.corp.local.  

Now that you have a certificate ready to use for SSL termination, it's time to assign this certificate to a new Application Profile configured for SSL termination.

 

 

Create New Application Profile used for SSL Termination

 

There is an existing Load Balancer Application Profile for SSL-Passthrough listening on the external Virtual Server.    You will create a new Application Profile for SSL-Offload.

  1. Click on the Load Balancer tab.
  2. Click on Application Profiles.
  3. Click the green plus icon to create a new Application Profile

 

 

New Application Profile Configuration (SSL Termination)

 

For this new Application Profile, you will use the following settings:

  1. Name: Web-SSL-Term-Profile-01
  2. Type: HTTPS
  3. Click the OK button.

Notice you will use the Service Certificate you created.

 

 

Topology for In Line Load Balancer

 

To get a better understanding of what you'll be accomplishing, observe the above topology. From the ControlCenter, you will visit a Virtual Server located at IP Address 192.168.100.4. The Edge Services Gateway at that address will handle SSL Termination, and forward HTTP packets to web-sv-01a and web-sv-02a.

Next, you'll be configuring a new Pool.

 

 

Create New Pool

 

  1. Click on Pools.
  2. Click on the green plus icon to bring up the new Pool popup.

 

 

New Pool Configuration

 

For this new Pool, configure the following parameters:

  1. For a name, type in Web-Tier-Pool-02.
  2. Select default_http_monitor from the drop down list for Monitors. This time you will monitor an HTTP service between the Load Balancer and member servers.
  3. Click the green plus sign icon to bring up a pop up window where you'll select the members for this pool.

 

 

Add web-sv-01 and web-sv-02 as Pool Members

 

  1. Enter web-sv-01a as the name.
  2. Enter 172.16.10.11 as the IP Address.
  3. Enter 80 for the Port.
  4. Enter 80 for the Monitor Port.
  5. Click OK.

Repeat the process for:

 

 

Save Pool Settings

 

 

 

Edit Existing Virtual Server

 

The Edge Gateway allows for only one VIP to Port Listener combination at a time.  So you will modify the existing 443 listener.

  1. Click on Virtual Servers
  2. Click the Edit icon to bring up the popup window for editing a Virtual Server.

 

 

Edit Virtual Server Configuration

 

This will allow a external client to create an SSL session to be terminated on the Load Balancer and complete the session using HTTP from the Load Balancer to the pool member server.

Edit the Virtual Server settings:

  1. Select Web-SSLTerm-Profile-01 for the Application Profile.
  2. Type in Web-Tier-SSL-01 for the name of this Virtual Server
  3. Enter 192.168.100.4 for the IP Address.
  4. Select Web-Tier-Pool-02 for the Default Pool.
  5. Click the OK button when you're done.  At this point you should be ready to test load balancer functionality.  

 

 

Accept Security Certificate

 

  1. Click on a blank tab in the browser.
  2. Note: Remember the {#} below is just a reference to the CLI file on your desktop.  Do not include as part of your command!                                                            Enter {9} https://web-app.corp.local/finance/data.html and press enter
  3. Click the "Proceed anyway" button.

 

 

Confirm Load Balancer Functionality

 

You will get a web page for the Finance Department.

 

 

Explore the Certificate

 

  1. Click on the "Broken Certificate" button in the URL.
  2. Click on Certificate information.

 

 

Certificate Details

 

You will see that the certificate has the name and a valid date of today for the next year.

You have just completed the Load Balancer Section of Module 5.

 

NSX Edge Services Gateway - High Availability Edge Gateways


An Edge Services Gateway can be enabled to be in a High Availability mode, where a passive copy of the primary Edge Services Gateway is made and powered on.

In the case of a failure with the VM acting as the primary Edge in the HA pair, the passive copy will quickly take the primary's place and restore all offered services from that Edge Services Gateway. In this case, you'll be using the Perimeter-Gateway Edge from the previous section to turn into an HA pair.


 

Enable High Availability on Edge Gateway

 

You will first enable HA mode on an Edge Services Gateway.  You'll be using the Perimeter-Gateway Edge

  1. Click on the Manage tab,
  2. Click Settings button.
  3. Click Configuration.
  4. Click the Change link.  This will bring up the Change HA Configuration popup window.

 

 

Configure High Availability Mode for Edge Services Gateway

 

For the HA configuration, use the following settings:

  1. Click the Enable Radio button.
  2. Select Transit Internal for the vNIC.
  3. Click the OK button to continue.

 

 

Identify Passive Edge in HA Pair

 

Once you have click the OK button to save that HA configuration, a new vSphere task for Deploying an OVF will appear.  That task represents the deployment of the passive Edge Services Gateway. Next you'll be confirming the HA status for the new Edge via its CLI interface,

Confirm that HA Status shows as Enabled.

You will see the new "Perimeter-Gateway-1" Edge deployed as the new passive-secondary.

 

 

Open PuTTy to Primary Edge to Verify HA Status

 

  1. Click on the PuTTy application icon on the Taskbar.
  2. Select the "perimeter-gateway" of saved sessions.
  3. Click Open.

 

 

Accept Certificate

 

 

 

Login to Edge-1

 

Login using:

Take note of the Edge Services Gateway you are logged into.  In this case you are on the Active Primary Unit named "plr01-0".

 

 

Verify HA Status via CLI

 

Once you have established the SSH connection,

You can see that this unit is the Active or Primary.  

You will see the passive peer and active Edge are both showing good for High Availability Health Check Status.  

Next you will shut down the primary Edge and observe failover to the passive Edge.

 

 

Preparation to Monitor HA Failover

 

To further observe the failover between the active and passive Edge Service Gateways, you'll also be starting a continuous ping to the active Edge.

 

 

Start Continuous Ping to Edge

 

Leave this ping running, but make sure the Command Prompt window is visible if possible.  You'll next be navigating to the VM object representing the active Edge in preparation to shut it down to force a failover scenario.

 

 

Navigating to Hosts and Clusters View

 

  1. Click on the Home icon.
  2. Click on the Hosts and Clusters icon to bring you to the Hosts and Clusters section.

 

 

Power Off Active Edge

 

  1. Expand the Management and Edge Cluster,
  2. Right-click the VM named Perimeter-Gateway-0      (*VERY important that it's the one that ends in -0, NOT -1*)
  3. ChooseShut Down Guest OS.

 

 

Observing failover during continuous ping

 

You will notice that during the failover phase, you will observe a couple of timed out responses for the ping.

Around 2-6 time outs are normal, given the density of our lab environment.  You will see the pings starting to reply again which is evidence of the passive Edge taking over services after you shut down the active Edge.

 

 

Restart PuTTy session

 

  1. Click on the PuTTy application icon.
  2. Click OK to acknowledge that the session has stopped.

 

 

Restart session

 

  1. Click the Application icon in the upper left of the window.
  2. Click Restart Session.

 

 

Verify downed member via CL

 

You should now see that the peer host listed here is the originally active Edge, and it should list its status as Unreachable.

 

You have now finished the last section of Module 5.

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-SDC-1403

Version: 20150605-071434