VMware Hands-on Labs - HOL-SDC-1425


Lab Overview - HOL-SDC-1425 - VMware NSX Advanced

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!

 

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 advanced NSX functions that can further grow your virtual network functionality and security. A brief description of each module follows:

Lab Module List:

Lab Captains:

 


Lab Topology


This section will detail the overall topology of the HOL-SDC-1425 lab.  Then within each specific lab module will be a detailed topology, where required.


 

Lab and NSX Components Detail

All of the following is detailed in the topology digram in the next screen.

The lab has four clusters, in two separate sites, configured with VMware's vSphere product.  There are two compute clusters and one Management and Edge cluster managed by the vCenter Server in Site A. Then there is a single compute cluster managed by a second vCenter Server in Site B.  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 Overview

 

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)

Note : The section encircled in red and labeled, "Module 3", is only used in module 3 of this lab.

 

Module 1 - DHCP Relay (25 minutes)

Introduction to DHCP Relay


This lab will cover the new DHCP Relay functionality within NSX and will take approximately 30 minutes to complete.

In a network where there are only single network segments, DHCP clients can communicate directly with their DHCP server.  DHCP servers can also provide IP addresses for multiple networks, even ones not on the same segment as themselves.   Though when serving up IP addresses for IP ranges outside its own, it is unable to communicate with those clients directly.  This is due to the clients not having a routable IP address or a gateway that they are aware of.

In these situations a DHCP Relay agent is required in order to relay the received broadcast from DHCP clients by sending it to the DHCP server in unicast.  The DHCP server will select a DHCP scope based upon the range the unicast is coming from, returning it to the agent address which is then broadcasted back to the original network to the client.

Areas to be covered in this lab:

In this lab the following items have been pre-setup


 

Lab Topology

 

This diagram lays out the final topology that will be created and used in this lab module.

 

Configure Network Dependencies and DHCP Scope


This section will cover the configuration of a new network segment where DHCP relay will be configured to server DHCP requests originated from PXE-booting clients, along with the creation of the new DHCP scope on the DHCP server.


 

Access the vSphere Web Client

 

Bring up the vSphere Web Client via the icon on the desktop labeled, vSphere Web Client - A

 

 

Log into vSphere Web Client

 

Log into the vSphere Web Client with the following credentials:

 

 

Minimize Right Panel

 

In order to improve overall workspace within the vSphere Web Client for the duration of this lab, we are going to minimize the task pane on the right side.

This will minimize the task pane, giving the center pane more room.

 

 

Access NSX Through the Web Client

 

Access the Networking & Security section of the Web Client

  1. Click Networking & Security in the left pane.

 

 

Create New Logical Switch

 

We must first create a new Logical Switch that will run our new 172.16.50.0/24 network.

  1. Select Logical Switches
  2. Click the + sign to create a new Logical Switch

 

 

Configure New Logical Switch

 

In order to configure the Logical Switch, we must set the name and transport zone.  Follow these steps:

  1. Name = PXE-Boot_DHCP-Relay - The name does not specifically matter, but it is used to help identify the switch.
  2. Description = 172.16.50.0/24 - Not required, but further helps to identify the switch.
  3. Transport Zone, click Change, a dialogue box will appear with a single Transport Zone to select.  Select "Global-Transport-Zone" and click OK
  4. Select Replication Mode: Select Unicast
  5. Click OK

 

 

Verify Logical Switch was Created

 

Upon creation of the new Logical Switch, you will see a new switch named PXE-Boot_DHCP-Relay and its status will be Normal

 

 

Connect Logical Switch to Logical Distributed Router

 

We will now create a new interface on the Logical Distributed Router that will act as the gateway for this new Logical Switch.  This interface will be the default gateway for the 172.16.50.0/24 network with an address of 172.16.50.1.

  1. Click NSX Edges in the left pane.
  2. Double Click edge-2 which is the Distributed Router in this lab.

 

 

Add Logical Interface to Logical Distributed Router

 

This section will add a new interface to the Logical Distributed Router.

  1. Click Manage
  2. Click Settings
  3. Click Interfaces
  4. Click the + sign to add the new interface

 

 

Select What Logical Switch Interface is Connected to

 

We will select what Logical Switch the interface is connected to.

  1. Click Select

 

 

Select Newly Created Logical Switch

 

Select the new Logical Switch that we just created in the previous steps.

  1. Select PXE-Boot_DHCP-Relay Logical Switch
  2. Click OK

 

 

Add Interface IP Address

 

We will add a new IP Address.

  1. Click the + sign

 

 

Configure Interface IP Address

 

We will assign the new interface an IP Address.

  1. Click the + sign.
  2. IP address = 172.16.50.1
  3. Subnet Prefix Length of = 24
  4. Click OK

 

 

Complete Interface Configuration

 

Verify all information and complete the configuration

  1. Name = PXE Boot Internal
  2. Type = Internal
  3. Click OK

 

 

Verify Interface Creation

 

Verify the new interface named PXE Boot Internal with the IP of 172.16.50.1 has been created.

 

 

Access DHCP Server Management

 

We will now bring up the management interface for the DHCP Server that resides on the control center system ( 192.168.110.10 ).  This DHCP server was pre-installed and authorized for you.

  1. Double-Click the DHCP Icon located on the desktop.

 

 

Create a New DHCP Scope

 

A DHCP scope is a network segment that the DHCP server is configured to assign addresses for.  We will now create a scope for the 172.16.50.0/24 network that we just created.

  1. Click the arrows to expand the menu under Controlcenter.corp.local and IPv4.
  2. Right-Click IPv4
  3. Click New Scope

 

 

Configure DHCP Scope - Start Wizard

 

We must configure the DHCP scope for the options required by our new network segment.

This section will consist of several steps a part of the New Scope wizard.  Follow each step below exactly.

  1. Click Next on the Wizard Welcome window.

 

 

Configure DHCP Scope - Name Scope

 

  1. Enter Name = 172.16.50.0/24 Scope
  2. Click Next

 

 

Configure DHCP Scope - Set IP Range

 

  1. Start IP Address: 172.16.50.10
  2. End IP Address: 172.16.50.49
  3. Length 24
  4. Click Next

 

 

Configure DHCP Scope - Exclusions

 

  1. No entries needed for exclusions, click Next

 

 

Configure DHCP Scope - Lease Duration

 

  1. No changes to lease duration, click Next.

 

 

Configure DHCP Scope - Additional Options

 

  1. We now need to configure additional options.  Select, Yes, I want to configure these options now and click Next

 

 

Configure DHCP Scope - Default Gateway

 

  1. Router ( Default Gateway ) IPaddress= 172.16.50.1
  2. Click Add ( Make sure the IP Address moved to the field below )
  3. Click Next

 

 

Configure DHCP Scope - DNS Servers

 

  1. No changes to domain name or DNS servers, click Next

 

 

Configure DHCP Scope - WINS Servers

 

  1. No changes to WINS Servers, click Next

 

 

Configure DHCP Scope - Activate Scope

 

  1. Select Yes I want to activate this scope now
  2. Click Next

 

 

Configure DHCP Scope - Complete Creation

 

  1. Click Finish

 

 

Verify New Scope was Created

 

You will see the new IPv4 Scope that has been created with the name Scope [172.16.50.0] 172.16.50.0/24 Scope

 

 

Add Additional Boot Options

 

There are additional boot options that need to be added for PXE boot to properly function.  These are the location of the TFTP server, which has been pre-setup for you, and the boot file the OS is to boot from.  We will now add these to this newly created scope.

  1. In the newly created scope, left-click scope options then right-click Scope Options after expanding the scope by clicking the arrow.
  2. Click Configure Options

 

 

 

Select Options and Set - Option 066

 

Here you must select two scope options that will be used, then set those values.  These scope options set the server and location of the PXE boot files.

  1. Scroll down using the right scroll bar.
  2. Select the check box on option 066 Boot Server Host Name
  3. String value = 192.168.110.10
  4. Continue to the next step.

 

 

Select Options and Set - Option 067

 

Set the section option required

  1. Select the check box on option 067 Bootfile Name
  2. String value = pxe\pxelinux.0
  3. Click OK

 

 

Verify Scope Options

 

Let's verify the new scope options are in place and correct.

Upon completion of the last step, you should see both new boot options with their values in the list.  Verify they match the image and continue to the next steps.

 

Configure DHCP Relay and PXE Boot a Linux VM


In this lesson we will create a blank VM.  This VM will network boot via the DHCP scope and its options we previously set via DHCP Relay.  For the boot process to work, we will enable DHCP Relay on the distributed router interface we created earlier.


 

Access the vSphere Web Client

 

Return to the vSphere Web Client that should still be open.  If it is not open, access it via the "vSphere Web Client - A " icon on the desktop.

  1. Click the Home icon on the Web Client to return to the main page.

 

 

Enter the VMs and Templates Menu

 

  1. Select VMs and Templates

 

 

Create a New VM

 

We will now create a new and blank VM that will be used to boot from the network.

  1. Right-click the Hands on Labs datacenter
  2. Click on New Virtual Machine

 

 

Configure the New VM

 

  1. Select Create a New Virtual Machine
  2. Click Next

 

 

Name the VM

 

  1. Name = Linux PXE Boot
  2. Click Next

 

 

Select Cluster

 

  1. Select Compute Cluster A
  2. Click Next

 

 

Select Storage

 

  1. There is only one storage volume to select, which is already selected.  Click Next

 

 

Select VM Compatibility

 

  1. Compatibility Selection, leave this at the default of ESXi 5.5 and later and click Next

 

 

Select Guest OS

 

We must select the proper OS for this VM.

  1. Click the drop down and select Linux
  2. Using the scroll bar, scroll down to the bottom.
  3. Select Other Linux (64-bit)
  4. Click Next

 

 

Specify Hardware - Change RAM & Remove Hard Disk

 

We need to adjust the memory on this system along with delete the hard disk that comes default.  The reason we delete the hard disk is that it is not needed for the OS to run.  This is because it is PXE booting and running completely within RAM.

  1. Set memory to MB via the drop down and set the amount to 128
  2. Move the mouse cursor over New Hard Disk and the X will appear to the right.  Click this X to remove the hard drive.

 

 

Verify Hardware and Complete

 

Verify the memory change is set as shown and the hard drive is no longer listed.

  1. Once verified, click Next
  2. Click Finish at the summary screen

 

 

Attach Newly Created VM to Logical Switch

 

Next we need to attach this VM to the Logical Switch we created earlier.  Navigate through the following menus, then follow the steps.

  1. Select the PXE-Boot_DHCP-Relay logical switch we created earlier.
  2. Click the Add VM icon

 

 

Select VM

 

  1. Select our newly created Linux PXE Boot VM
  2. Click Next

 

 

Select the Network Adapter

 

  1. There is only one selection since there is only one NIC.  Check the checkbox for Linux PXE Boot - Network adapter 1 (VM Network)
  2. Click Next
  3. Click Finish

 

 

Navigate Back to New VM

 

Quickly navigate to our new VM by using the search feature in the upper right corner.

  1. Type "PXE" in the search box in the upper right corner
  2. Click the Linux PXE Boot VM

 

 

Power Up New VM

 

  1. Click the Actions drop down next to the Linux PXE Boot name
  2. Click Power On

 

 

Open Console of VM

 

Once the VM powers on, the Launch Console link will activate.

  1. Click Launch Console just under the console window.

 

 

Note DHCP Error in Console Window

 

Since this system does not have a local disk, the VM attempted to boot from the network.  As per the error stated, the VM was unable to locate a DHCP server to receive an address.  This is because we have yet to configure DHCP relay for this network, which we will now complete.

Leave this tab open as we will use it again.

 

 

Configure DHCP Relay

 

In this section we will create the DHCP relay for the network segment we created.

Navigate back to the NSX Configuration menus by the following:

  1. Click NSX Edges
  2. Double-click Edge-2which is the distributed router

 

 

DHCP Relay Configuration Menu

 

First we must do the global configuration of DHCP Relay.

  1. In the Distributed Router Menu, click Manage
  2. Click DHCP Relay
  3. Click Edit

 

 

DHCP Global Configuration

 

Within the global configuration of DHCP is where you select the DHCP servers that will respond to DHCP requests from your guest VMs.

There are three methods by which you can set DHCP Server IPs:

IP Sets

IP Sets are configured from the NSX Manager Global Configuration and allow you to specify a subset of DHCP servers by creating a named grouping.

IP Addresses

You can manually specify IP addresses of DHCP servers in this method.

Domain Names

This method allows you to specify a DNS name that could be a single or multiple DHCP server addresses.

 

For the sake of this lab, we will be using a single IP address.

  1. IP Addresses = 192.168.110.10 that is the IP of the DHCP server.
  2. Click OK

 

 

Configure DHCP Relay Agent

 

The DHCP Relay Agent will relay any DHCP requests from the gateway address on the logical switch to the configured DHCP Servers.  We must add an agent to the logical switch / segment we created on 172.16.50.0/24.

  1. Under the DHCP Relay Agents section, click the + sign

 

 

Select Distributed Router Interface

 

Select which interface on the distributed router will have the relay agent.

  1. Click the vNIC drop down, select the interface we created earlier, PXE Boot Internal

 

 

Confirm Relay Agent Settings

 

There is only gateway IP address on this interface, so "172.16.50.1" is the only option.

  1. Click OK.

 

 

Publish Settings to DHCP Relay Settings

 

We now need to publish all of these changes to the distributed router.

  1. Scroll all the way to the top using the scroll bar
  2. Click Publish Changes

 

 

 

Attempt to Boot VM

 

Now that we have DHCP Relay in place, our VM should receive an IP Address along with the PXE boot options.

  1. Navigate back to internet tab for the VM Console by clicking on the tab.

 

 

Reboot VM

 

You will note that the console is still sitting at the "Operating System not found" point.  

  1. Click Send Ctrl-Alt-Delete button in the upper right corner to reboot the VM.

 

 

Boot Linux OS

 

The VM should now boot to this boot menu which is the PXE boot image that is served up by our DHCP server.

  1. You can click inside of the console window and press the enter key to start the boot process.  Note that it does not change the screen while the boot process is running and it will take approximately one to two minutes to complete. Proceed to the next step while waiting.

TO RELEASE YOUR CURSOR FROM THE CONSOLE - PRESS CTRL+ALT

While we wait for the boot to complete, let's review the DHCP server by continuing to the next step.

 

 

Review DHCP Server Leases

 

We can see the lease of the VM that was booted up by reviewing the DHCP server.

  1. Go to the DHCP server admin menu that should still be open from our previous work.  If it is not open, open it via the desktop DHCP icon that we used prior.
  2. Expand the 172.16.50.0/24 Scope we created and select Address Leases
  3. You should see a lease for 172.16.50.10 in the right pane.  This is the address of the VM now booting to Linux.

 

 

Review the Now Booted VM

 

Return to your web browser tab for the console of the Linux PXE Boot VM.

You should have a fully running and functional Linux OS that can communicate with the rest of the NSX network within this lab.  Also note the IP address in the right widget should match what was seen in the DHCP leases.

 

 

Conclusion

In this lab we have completed the creation of a new network segment, then relayed the DHCP requests from that network to an external DHCP server.  In doing so we were able to access additional boot options of this external DHCP server and PXE into a Linux OS.

This lab is now completed, thank you for completing the DHCP Relay lab.

 

Module 2 - Scale Out L3 (45 minutes)

Introduction


In this lab, we will focus on scaling out L3 through the use of Equal Cost Multi-Path (ECMP), which is an exciting new feature enhancement.  

Scale out L3 enhancements included in this release include:

Key use cases from these enhancements are:

Lab Objective:

This lab will demonstrate ECMP functionality and the ability to add this feature “non-disruptively” to an existing NSX environment.


 

ECMP Overview

Equal-Cost Multi-Path (ECMP) routing is a routing strategy that provides the ability to forward traffic across multiple next-hop "paths" to a single destination (IP prefix).  These next-hop "paths" can be added statically via static routes, or through the use of dynamic routing protocols that support ECMP such as Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP).

In the case of dynamic routing protocols that support ECMP; multiple routes, which share the same "metric" to a specific destination prefix are added to the route table.  For example note the following output of "show ip route" from an NSX router, which shows there are 2 "paths"  to the 192.168.100.0/24 network via the next-hops of 192.168.10.1 and 192.168.10.4.

 

 

Example of ECMP routes learned via a Dynamic Routing Protocol

 

The use of ECMP can substantially increase bandwidth by providing a method of load-balancing traffic over multiple paths while also providing additional fault tolerance in the event of a path failure.

During a path failure, the affected network traffic, which was previously being forwarded on the failed path, is rerouted to alternative paths, while network traffic that was being forwarded across the non-affected paths remain unaffected.  

This approach can dramatically improve network availability and improve convergence.

 

 

Lab Logical Topology Overview

 

In this lab, we already have an existing deployment that consists of a 3 tier application with the Web tier (172.16.10.0/24), Application Tier (172.16.20.0/24) and Data Base Tier (172.16.30.0/24) networks deployed on an NSX Distributed Router.  This deployment also utilizes an NSX Edge Service Gateway named "Perimeter-Gateway" which provides external access for the environment.  Connectivity between the Distributed Logical Router and the Perimeter Gateway is through a logical switch named "Transit " with interfaces on the (192.168.10.0/24) network.  The Perimeter-Gateway has a northbound connection to the HQ Access DVS switch that is on the (192.168.100.0/24) network.

OSPF has been enabled between the Distributed Router and the Perimeter-Gateway with the Transit Switch interfaces added to OSPF Area 10.  Route Redistribution has also been enabled to redistribute "Connected" routes into OSPF.

 

 

Accessing the Lab

 

First we will explore the existing lab OSPF configuration.

If you are not already logged into the vSphere Web Client. (https://vc-l-01a.corp.local:9443/vsphere-client/)

 

 

 

Gain screen space by collapsing the right Task Pane.

 

 

 

Network and Security

 

  1. Click on the Network and Security Tab

 

 

Access Perimeter-Gateway

 

  1. Click on the NSX Edges Tab
  2. Double Click on the Perimeter-Gateway Tab

 

 

Review Perimeter-Gateway Interfaces / Routing Configuration

 

  1. Click on "Manage"
  2. Click on "Settings"
  3. Click on "Interfaces"

Review the IP interfaces on this perimeter router.   Notice the perimeter router has an interface on the Transit Network (192.168.10.1/29) and on the HQ Access Network (192.168.100.3/24).

 

 

Review Perimeter-Gateway Routing Configuration

 

  1. Click on "Routing"
  2. Click on "Global Configuration"
  3. Notice OSPF is enabled and we have a router ID of 192.168.100.3

 

 

Review Perimeter-Gateway Router Configuration

 

  1. Click on "OSPF"
  2. Notice we have created OSPF Area 0
  3. Notice we have added the interface "Transit Interface (192.168.10.1) to OSPF Area 0

 

 

Access Distributed Logical Router

 

Similar to the previous steps you used to access the Perimeter-Gateway, review the configuration of the Distributed Logical Router

  1. Click on "Networking and Security"
  2. Click on "NSX Edges"
  3. Double click on "Distributed-Router"

 

 

Review the OSPF Configuration on the Distributed Logical Router

 

  1. Click on "Manage" tab
  2. Click on "Router" tab
  3. Click on "OSPF"
  4. Notice OSPF is enabled - With a "Protocol Address" of 192.168.10.6 and a "Forwarding Address" of 192.168.10.5
  5. Notice we created an OSPF area, Area 0
  6. Notice we have the "Transit Uplink" (192.168.10.3) added to OSPF area 0

Note:  A protocol address is required because the routing stack is a function of the control VM and the IP Address it uses for protocol updates needs to be local, unlike the forwarding address which is distributed across all ESXi hosts.

 

 

Accessing Router Console(s)

 

From the "Home" menu

  1. Click on "Hosts and Clusters"

 

 

Accessing Router Console (Perimeter-Gateway)

 

  1. Find and right click on the "Perimeter-Gateway-0" VM
  2. Click on "Open Console"

 

 

Logging into the Router Console (Perimeter-Gateway)

 

Login as "admin" with a password of "VMware1!VMware1!" to access the console

Run the following commands to validate that OSPF is running in this environment and to familiarize yourself with the console

Go back to the "Hosts and Clusters" Tab as well now access the "Distributed-Router" console

 

 

Accessing Router Console (Distributed-Router)

 

  1. Find and right click on the "Distributed-Router-0" VM
  2. Click on "Open Console"

 

 

Logging into the Router Console (Distributed-Router)

 

Login as "admin" with a password of "VMware1!VMware1!" to access the console

Run the following commands to validate that OSPF is running in this environment and to familiarize yourself with the console

Leave the router consoles open as we will use them again in the next module

 

Deploying ECMP (Upgrade in Place)


Here we will demonstrate how additional NSX Service Gateways can be deployed non-disruptively to an existing NSX deployment (Upgrade in place) providing additional scale through the use of ECMP


 

ECMP Topology

 

In this module we will add L3 scale out to our existing environment:

  1. We will create an additional NSX Edge called "Perimeter-Gateway-2" and configure OSPF
  2. We will enable Equal Cost Multi-Path "ECMP" on our Distributed-Router

 

 

Return to the vSphere Web Client

 

If you are not logged into the vSphere Web Client. (https://vc-l-01a.corp.local:9443/vsphere-client/)

 

 

 

Network and Security

 

  1. Click on the Network and Security Tab

 

 

Create an Additional NSX Edge Services Gateway

 

Return to the "NSX Edges" section in the "Network and Security" tab

  1. Click the NSX Edges Tab
  2. Click the "Plus" icon to create a new Edge Services Gateway

 

 

Create an Additional NSX Edge Services Gateway Cont'd

 

  1. Click on "Edge Services Gateway"
  2. Assign the Edge Services Gateway a name such as "Perimeter-Gateway2" or similar.
  3. Click "Next"

 

 

Create an Additional NSX Edge Services Gateway Cont'd

 

  1. Provide the new NSX Edge a password "VMware1!VMware1!" or similar (Note password fields must match and must contains at least 12 characters)
  2. Enable SSH access
  3. Click Next

 

 

Create an Additional NSX Edge Services Gateway Cont'd

 

  1. Click "Plus" on the NSX Edge Appliances
  2. Select "Management and Edge Cluster"
  3. Select the default Datastore
  4. Click "OK"
  5. Click "Next"

 

 

Create an Additional NSX Edge Services Gateway Cont'd

 

  1. Click on the "PLUS" icon to configure interfaces
  2. Give this interface a name "HQ-Uplink" or similar
  3. Select "Uplink"
  4. Click "Select" to select the item to connect this interface to
  5. Select the Distributed Portgroups
  6. Select the "Mgmt_Edge_VDS-HQ Access" port group
  7. Click "OK"

 

 

Create an Additional NSX Edge Services Gateway Cont'd

 

  1. To configure subnets, click "PLUS"
  2. To add a subnet, click "PLUS"
  3. Enter an IP address for this subnet "192.168.100.5"
  4. Enter the prefix Length "24"
  5. Click OK

 

 

Create a Second Interface on this Edge on the Transit Network

 

  1. Click "PLUS" to configure the second interface
  2. Name this interface "Transit-Internal" or similar
  3. Select "Internal" for interface type
  4. Click on "Select" to select the item to connect this interface to
  5. Select the "Logical Switch"
  6. Select the "Transit-Network-01" logical switch
  7. Click OK

 

 

Create a Second Interface on this Edge on the Transit Network Cont'd

 

Configure Subnet click "PLUS"

  1. Click "PLUS" to add a subnet
  2. Click "Plus to specify an IP address
  3. Enter an IP address of "192.168.10.2"
  4. Enter the prefix Length of "29" (NOTE THIS PREFIX IS A /29)
  5. Click "OK" then "Next"

 

 

Configure Default Gateway

 

Note:  The gateway address of 192.168.100.2 is the next L3-hop north of the NSX Perimeter-Gateway-2.

 

 

Firewall and HA Parameters

 

  1. Click "Configure Firewall Policy"
  2. Set default traffic policy to "Accept"

Click Next

 

 

Verify Configuration and interfaces of Gateway

 

  1. Verify your configuration and interfaces
  2. Click "Finish" to deploy this new Edge Services Gateway

Note:  It will take a moment for the new Edge Services Gateway to deploy.  Please wait until the newly created Edge Services Gateway has completely installed prior to moving forward with the next steps.

 

 

Access Perimeter-Gateway-2

 

  1. Click on the NSX Edges Tab
  2. Double Click on the Perimeter-Gateway-2 Tab

 

 

Configure Router-ID on newly created Edge

 

  1. Click on the "Routing" Tab
  2. Click on the "Global Configuration" section
  3. Click on "Edit" in the Dynamic Routing Configuration

 

 

Configure Router-ID on newly created Edge Cont'd

 

Under Global Configuration configure the Router-ID

  1. Select the "HQ-Uplink" interface
  2. Click "OK"

 

 

Publish Changes

 

Select "Publish Changes" to update the configuration parameters you just entered.

 

 

Configure OSPF on newly created Edge

 

  1. Click on the OSPF section
  2. Within the OSPF Configuration Section, Click edit to add in OSPF parameters

 

 

Configure OSPF on newly created Edge Cont'd

 

 

 

Publish Changes

 

Select "Publish Changes" to update the configuration parameters you just entered.

 

 

Map OSPF Area to Specific Interface

 

Next, we must map the correct interface to the OSPF Area.

  1. Click the + sign in order to add a new mapping

 

 

Configure OSPF on newly created Edge Cont'd

 

Map Interface to OSPF Area

  1. Select "Transit-Internal" interface (or the name of the interface you created attached to the "transit logical switch" if you did not use the default)
  2. Select OSPF Area "0"
  3. Click OK

 

 

Publish Changes

 

Select "Publish Changes" to update the configuration parameters you just entered.

 

 

Configure Route Redistribution

 

Under the Route Redistribution Configuration

  1. Highlight the Route Redistribution area
  2. Click "edit"
  3. Click OSPF checkbox
  4. Click "OK"

Note:  This step is needed in order to advertise the 192.168.100.0/24 prefix to the Distributed-Router in our environment, providing a second path from our Distributed-Router to this prefix.

 

 

Configure Route Redistribution Cont'd

 

Under Route Redistribution Table

  1. Click "PLUS" to configure redistribution
  2. Click checkbox to allow connected interfaces to be redistributed into OSPF
  3. Click OK

 

 

Publish Changes

 

Select "Publish Changes" to update the configuration parameters you just entered.

 

 

Enabling ECMP

Now that we have configured and additional Edge Services Gateway (ESG) wewill enable ECMP in our environment on our Distributed Logical Router.  

Note that while ECMP is supported on both the Distributed Logical Router and on the Edge Services Gateway we will only enable ECMP on the Distributed Logical Router in this lab since this lab is hosted in a nested environment.  In a real life deployment up to 8 ECMP paths per DLR and per Edge are supported to provide scale out.

 

 

Distributed Logical Router Console Output

 

From the Distributed-Router Console output above we can see that we now have 2 OSPF neighbor adjacencies with both of the Perimeter-Gateways (192.168.10.1 and 192.168.10.2).  Also note that we still only have a single path to the 192.168.100.0/24 prefix from the Distributed-Router.  In order to learn multiple paths we will need to enable ECMP on the Distributed-Router which we will do in the following steps.

 

 

Access Distributed Logical Router

 

Similar to the previous steps you used to access the Perimeter Router, review the configuration of the Distributed Logical Router

  1. Click on "Networking and Security"
  2. Click on "NSX Edges"
  3. Double click on "Distributed-Router"

 

 

Configuring the Distributed Logical Router

 

  1. Click on the "Routing" tab
  2. Click on "Global Configuration"
  3. Under Routing Configuration - ECMP, click "Enable" to enable Equal Cost Multi-Path

 

 

Warning

 

Click "Yes"

 

 

Publish Changes

 

Select "Publish Changes" to update the configuration parameters you just entered.

 

 

Disable Route Redistribution

 

Due to the nature of the nested environment of the Hands on Labs, we need to restart the route redistribution process on the Logical Distributed Router.  In the menu for the Logical Distributed Router, follow the below steps:

  1. Click "Manage"
  2. Click "Routing'
  3. Click "Route Redistribution"
  4. Click "Edit"
  5. Uncheck"OSPF"
  6. Click "OK"

 

 

Publish Changes

 

Select "Publish Changes" to update the configuration parameters you just entered.

 

 

Enable Route Redistribution

 

Next we must re-enable route redistribution.

  1. Click "Edit"
  2. Check"OSPF"
  3. Click "OK"

 

 

Publish Changes

 

Select "Publish Changes" to update the configuration parameters you just entered.

 

 

Validating ECMP

Now that we have scaled out to 2 ECMP gateways in our environment, let's validate the results.

 

 

Log into the Distributed Router Console

 

Using the steps outlined in the previous module, log into the console of the Distributed-Router and ensure that there are 2 OSPF Neighbors by typing "show ip ospf neighbor"

 

 

Validate ECMP is enabled on the DLR

 

Validate ECMP is enabled by typing "show configuration routing-global"

 

 

Validate multiple routes with Equal Costs

 

Validate that there are multiple routes (ECMP routes) by typing "show ip route"

 

 

Demonstrating ECMP Multi-path

Now that we've validated that we have multiple equal cost paths, let's demonstrate the load balancing aspect with some generated traffic.

 

 

Packet Capture from upstream Edges

 

Log into the Perimeter-Gateway and Perimeter-Gateway-2 consoles

(in case you previously closed your session using the username "admin" and a password of "VMware1!VMware1!")

On both consoles type "debug packet display interface vNic_1 not_ip_proto_ospf" which will display all packets seen by the interface that are not OSPF.

Leave both consoles open for the next step

 

 

 

Generate Traffic

 

From the Control Center Desktop (the desktop you are using for this lab)

 

 

Verify Load Balancing based on out packet capture

 

You should notice different IP streams appearing on both Edge Services Gateways demonstrating that multiple paths are being utilized.

Once you have validated that IP streams are being distributed across the ECMP paths, we will want to disable the packet capture on both the Edge Services Gateways by typing "no debug all" on Edge Console or hold the "Ctrl" and"c" keys simultaneously while within the console screen to conserve resources.

 

 

 

OPTIONAL BONUS LAB

Create and Deploy an additional 2 Edge Services Gateways with the following parameters:

Perimeter-Gateway-3 with the following interfaces

Perimeter-Gateway-4 with the following interfaces

Validate using the same methods outlined previously

 

Increased Availability and Improved Convergence Time



 

Increased Availability

 

As previously mentioned, the use of ECMP can substantially increase bandwidth by providing a method of load-balancing traffic over multiple paths while also providing additional fault tolerance in the event of a path failure.

For example in the diagram above, should a failure occur to the Perimeter-Gateway, affected network traffic, which was previously being forwarded on the failed path, is rerouted to alternative paths (in our example traffic would be forwarded to Perimeter-Gateway-2).    

It is also important to note that only a subset of network traffic is affected in a failure scenario as any traffic which was previously being forwarded through Perimeter-Gateway-2 remain unaffected.

 

 

Improving Convergence Time

Now that we've demonstrated scaling out our environment while also increasing availability by adding additional Edge Services Gateways and enabling ECMP on the Distributed Logical Router, lets look at ways to improve convergence times in the event of a failure.

The main influence on OSPF convergence times is the OSPF Hello Interval (how often an OSPF Hello is sent) and the OSPF Dead Interval (how long to wait before considering an OSPF Neighbor "down").  OSPF Dead Interval is the main factor influencing convergence time.

In the following steps, we will decrease OSPF "Hello Interval" and "Dead Interval" timers from 10 & 40 seconds respectively to 2 and 8 seconds.  Generally speaking the Dead Interval is usually 4 times the Hello Interval but can be set as low as 1 second (hello interval) and 3 second (dead interval) if so desired.  

 

 

Temporarily disabling OSPF while we reduce timers

 

Temporarily disable OSPF on all three routers (Distributed-Router, Perimeter-Gateway, and Perimeter-Gateway-2)

From the "NSX Edges" section, double click on the NSX Edge to access the Edge OSPF Configuration Area

 

 

Temporarily disabling OSPF while we reduce timers Cont'd

 

Under OSPF Configuration Click "Edit"

 

 

Temporarily disabling OSPF while we reduce timers Cont'd

 

  1. Remove the checkbox for "Enable OSPF" to temporarily disable OSPF
  2. Click OK

 

 

Temporarily disabling OSPF while we reduce timers Cont'd

 

Click on "Publish Changes" for the change to take effect.

Follow the same procedure to temporarily disable OSPF on the both Perimeter-Gateways and the Distributed Router

 

 

Set OSPF Timers

 

For each of the NSX Edges we will now decreased the OSPF timers.  To do this click on the "edit" icon under Area to Interface Mapping

 

 

Set OSPF Timers Cont'd

 

  1. Set the OSPF Area timers to a Hello Interval of 2 seconds and Dead Interval of 8
  2. Click OK

 

 

Set OSPF Timers Cont'd

 

  1. Edit the OSPF Configuration
  2. Click the checkbox to enable OSPF
  3. Click "OK"

 

 

 

Set OSPF Timers Cont'd

 

Click on "Publish Changes" for the change to take effect.

Repeat this process for each of the NSX Edges (Perimeter-Gateway, Distributed-Router, and Perimeter-Gateway-2)

 

 

Validate OSPF Neighbor Adjacencies with new OSPF Parameters

 

Open a console for the Distributed-Router

 

 

Validate OSPF Neighbor Adjacencies with new OSPF Parameters Cont'd

 

 

 

Validate OSPF Neighbor Adjacencies with new OSPF Parameters Cont'd

 

Type "show ip ospf neighbors" and confirm we have adjacencies with both NSX Edges as shown above

 

 

Validate OSPF Neighbor Adjacencies with new OSPF Parameters Cont'd

 

Type "show configuration ospf"

Notice OSPF timers are set accordingly

 

 

Testing Convergence and High Availability

In the next few steps wil validate our improved convergence for our environment

 

 

Packet Capture from upstream Edges

 

Log into the Perimeter-Gateway and Perimeter-Gateway 2 consoles (in case you previously closed your session)

On both consoles type "debug packet display interface vNic_1 not_ip_proto_ospf" which will display all packets seen by the interface that are not OSPF.

Leave both consoles open for the next step

 

 

 

Generate Traffic

 

From the Control Center Desktop (the desktop you are using for this lab)

 

 

Verify traffic being seen on Perimeter-Gateway(s)

 

You should notice different IP streams appearing on both Edge Services Gateways

 

 

Disable one NSX Edge

 

Under the "Hosts/Clusters" tab find the Perimeter-Gateway-2 VM, and shut down the guest OS

Select "yes" to confirm

 

 

Return to the Perimeter-Router Console and Confirm

 

Type "show ip ospf neighbors" - Notice we only now have an adjacency with one Perimeter-Gateway

 

 

Validate traffic flows are now forwarding across Perimeter-Gateway

 

From the "perimeter-gateway" console you should now notice traffic forwarding

After validating, we will want to disable the packet capture on the Edge Services Gateway by typing "no debug all" on Edge Console to conserve resources.

 

 

Prior to moving on to Module 3 and above please complete the following steps


In order to proceed to any additional modules and to conserve resources, we will need to prepare the environment.


 

Delete NSX Edge "Perimeter-Gateway-2"

 

  1. Select the "Perimeter-Gateway-2" NSX Edge
  2. Select "delete" to remove the NSX Edge
  3. Confirm by clicking "yes"

 

 

Disable "ECMP" on Distributed-Router

 

Navigate to the Distributed-Router

Under Routing / Global Configuration

Disable ECMP and click "OK"

Publish Changes

Your lab environment is now ready to proceed to additional modules

 

Module 3 - L2VPN (40 minutes)

Introduction to L2VPN


In this lab, we will focus on the L2VPN capabilities on the Edge Services Gateway and some exciting enhancements made to this feature.

Some enhancements that have been made in this release are:

Use cases for this feature include:

Lab Objective:

This lab will provide secure remote access connectivity between ABC medical management VMs running across multiple sites. 

  1. Provide secure remote access connectivity between selected networks running on an NSX Server Edge and an unbundled Client Edge running on a separate VC.
  2. Demonstrate the Hybrid cloud use-case by stretching our load-balancer pool to a remote site to increase capacity.
  3. (Optional) Migration of a VM from a remote site to an NSX managed local site.

 

Lab Topology

 

Here is a view of the lab-topology for this module. Upon completion of this module, we will have the Web Tier logical switch trunked as a sub-interface directly to Perimeter NSX edge(managed by vCenter-A) . This VXLAN backed network(Web-Tier) will be stretched across the VPN tunnel to the VLAN backed network(VLAN 100) on the l2vpn-client(managed by vCenter-B).

 

Deploying L2VPN on Edge Services Gateway


In this section, you will enable L2VPN services on the Edge-Services Gateway at the local site. Once this is complete, a standalone L2VPN client edge will be deployed at the remote site.

Objective: Bring up a L2VPN tunnel between the Edge-Services Gateway and the standalone L2VPN client edge at remote site


 

Launch vCenter Client

 

  1. Click on vSphere Web Client - A on the desktop to launch the VMware vSphere Web Client

 

 

Log into vCenter

 

  1. User name =  root
  2. Password = VMware1!
  3. Click Login

 

 

Minimize Right Panel

 

In order to improve overall workspace within the vSphere Web Client for the duration of this lab, we are going to minimize the task pane on the right side.

This will minimize the task pane, giving the center pane more room.

 

 

Access NSX

 

  1. Click on the Network & Security (NSX) icon

 

 

Logical Switches

 

  1. Click on Logical Switches
  2. Verify that Web-Tier-01, App-Tier-01, and DB-Tier-01 Logical Switches exist.

 

 

Verify Edge Gateways

 

  1. Click on NSX Edges.
  2. Double click on edge-2 (Distributed-Router)

 

 

Delete Web-Tier interface

 

In this step, we will delete the Web-Tier interface from Distributed-Router and move it to the Perimeter-gateway.

  1. Click on the Manage Tab
  2. Click on Settings
  3. Click on Interfaces
  4. Highlight the Web Internal interface
  5. Click the X button to delete the interface.   Click OK
  6. Click on the Network and Security back arrow

 

 

Perimeter-gateway Configuration

 

  1. Double click on edge-1 Perimeter-gateway

 

 

Adding a sub-interfaces on the Perimeter-Gateway

 

Now add the networks that will be stretched as sub-interfaces to the trunk interface on the Perimeter-Gateway

 

  1. Click on the Manage tab
  2. Click on Settings
  3. Click on  Interfaces
  4. Highlight interface called L2VPN Trunk
  5. Click on the edit button

 

 

Add a Sub-interface

 

  1. Click on the + sign to  add a Sub-interface

 

 

Configure the Sub Interface as shown

 

  1. Make sure the checkbox is checked for Enable Sub-Interface
  2. Enter the following in the Name Field: SubInt-to-Web-Tier
  3. Enter the following in the Tunnel ID field: 1
  4. Click on the Select

 

 

Select Web-Tier-01 Logical Switch

 

  1. Select the Web-Tier-01 Logical Switch
  2. Click OK

 

 

Configure Subnets

 

  1. Click on the + icon
  2. Click on the + icon in the Add Subnet window
  3. Enter IP Address: 172.16.10.1
  4. Enter Prefix Length: 24
  5. Click OK 

 

 

Finalize the sub-interface

 

  1. Click the OK button to complete the configuration

 

 

Reviewing the configuration

 

We now have Web-Tier sub-interface successfully created on the L2VPN trunk port.

  1. Click OK

 

 

Certificate Generation

 

A certificate needs to be generated for the SSL to use with the NSX Edge L2VPN Server.

  1. Click on Certificates on the left hand

 

 

Generate CSR

 

  1. Click on Actions
  2. Generate CSR

 

 

CSR form

 

  1. Common Name = med-app.corp.local
  2. Organization Name = vmware
  3. Organization Unit = nsbu
  4. Locality = palo alto
  5. State = California
  6. Country = United States (US)
  7. Click OK

 

 

Self Sign

 

  1. Select Actions
  2. Select Self Sign Certificate

 

 

Cert days

 

  1. Enter the number of days =  365
  2. Click OK

 

 

CSR signed

 

Verify that the new self signed certification was created and then continue to the next step.

 

 

Configure L2VPN Service on the Perimeter-Gateway

 

Next we will configure and enable the L2VPN service on the perimeter-gateway.

  1. Click on the VPN tab
  2. Click on L2 VPN
  3. Click Enable L2VPN

 

 

Global Configuration

 

  1. On the Global Configuration Details line, click Change

 

 

Server Settings

 

Complete the below settings to configure the server:

  1. Select 192.168.100.3 (Primary) as the Lister IP from the pull down
  2. Listener Port = 443
  3. Encryption Algorithm = RC4-MD5
  4. Uncheck Use System Generated Certificate
  5. Click the radio-button for med-app.corp.local
  6. Click OK

 

 

Add New Peer Site

 

  1. Click the + sign to add a new peer site.

 

 

Configure New Peer Site

 

Complete the below settings to add the peer site:

  1. Click Enable Peer Site
  2. Name = L2VPN-Site1
  3. User Id = vpnuser1
  4. Password and confirm password = VMware1!
  5. Click Select Sub Interfaces

 

 

Select Sub Interfaces

 

  1. Select Subint-to-Web-Tier from Available Objects
  2. Click the arrow to move it into Selected Objects
  3. Click OK

 

 

Submit All Peer Site Changes

 

All settings have been entered, click OK to complete the configuration.

 

 

Publish Changes

 

All settings that were just configured must now be published before they are active.

  1. Click Publish Changes

 

 

Login to vSphere Web Client for Site B

 

Next, we will configure the other side of the L2VPN connection via the vSphere Web Client for Site B.

  1. Click on vSphere Web Client - B on the desktop to launch the VMware vSphere Web Client

 

 

Log into vCenter

 

  1. User name =  root
  2. Password = VMware1!
  3. Click Login

 

 

Deploy New Standalone Edge

 

We must now deploy the standalone edge OVF template for the other side of the L2VPN bridge.

  1. Navigate to VMs and Templates

 

 

 

Deploy OVF Template

 

  1. Right-click Legacy Site
  2. Select Deploy OVF Template

 

 

Select Source

 

The URL for the standalone edge is a network location that the OVF is hosted, in this case a local webserver.

  1. Enter http://172.16.10.11/l2vpn/l2vpn-client-standalone.ovf
  2. Click Next

 

 

Extra Configuration Options

 

There are additional configuration options that are apart of this OVF, they must be accepted.

  1. Click Accept extra configuration options checkbox
  2. Click Next

 

 

Enter Name and Select Folder

 

  1. Rename the VM to L2VPN-Client
  2. Select the Legacy Site folder
  3. Click Next

 

 

Select Cluster Resources

 

  1. Select Compute Cluster C
  2. Click Next

 

 

Select Storage

 

  1. Select datastore ds-site-b-vmfs01
  2. Click Next

 

 

Setup Network

 

We must now select the proper networks for the edge device to use.

  1. For Public, using the drop down, select Compute_VDS-Uplink (L2VPN client will establish SSL connection using this interface)
  2. For Trunk, using the drop down, select Compute_VDS-Trunk  (This interface is backed by VLAN Trunk PortGroup. All VLAN's backed by this PG will be stretched by L2VPN Client)

Note: We had VXLAN backed networks stretched on the server side in the L2VPN Server Configuration step and we have VLAN based networks stretched here on the client side step. Hence we are successfully connecting a VXLAN segment on local site(server) to VLAN segment on remote site(client).

 

 

Customize Template - Password

 

In the following steps, we must enter various custom template information.  Enter the following:

  1. CLI admin user password = VMware1! and confirm by entering the same password.
  2. CLI root user password = VMware1! and confirm by entering the same password.

 

 

Customize Template - Uplink Interface

 

Configure the Uplink Interface

  1. Select the arrow next to the Uplink Interface to expand it
  2. IP Address = 192.168.240.3
  3. Prefix Length = 24
  4. Default GW = 192.168.240.2
  5. DNS Name = nsx-l2vpn-edge

 

 

Customize Template - L2VPN

 

Configure the L2VPN

  1. Expand the L2VPN section by clicking the arrow
  2. Using the right scroll bar, scroll all the way down
  3. Using the dropdown, select RC4-MD5
  4. Server Address = 192.168.100.3
  5. Username = vpnuser1
  6. Password and Confirm = VMware1!

 

 

Customize Template - Sub Interfaces

 

We must enter the VLAN ID along with the Tunnel ID

  1. Expand the Sub Interfaces section by clicking the arrow
  2. Sub Interface VLAN(Tunnel Id) = 100(1)
  3. Click Next

 

 

Review All Settings and Set Power On

 

  1. Check the Power On After Deployment and Hit Finish

 

 

Navigate to Edge

 

Once the initial deployment is complete, lets navigate to the summary window of the new edge VM.

  1. Using the search function in the upper right corner of the Web Client, type in L2VPN
  2. Select the L2VPN-Client Virtual Machine once it appears

 

 

 

Verify Edge Online

 

Looking at the summary tab, verify VM Tools are running.

  1. Select Summary tab
  2. Verify that VM Tools are in a Running state.  Do not proceed to the next step until it shows that it is running. Use the refresh icon at the top of the page to accelerate refreshes.

 

 

 

Access Perimeter-Gateway

 

Next we will verify that the L2VPN status is up.  In order to do this, we must access the vSphere Web Client for Site A.

  1. Select NSX Edges
  2. Double-click Edge-1

 

 

Access VPN Statistics

 

We will now bring up the interface to view the L2VPN status.

  1. Click the pin icon on the left pane to reduce it.
  2. Click Manage
  3. Click VPN
  4. Click L2 VPN
  5. Click Show L2VPN Statistics

 

 

Review VPN Statistics

 

  1. You will see that the L2VPN-Site1 tunnel status is UP
  2. Click the X to close this window
  3. Click the pin icon to return the left pane

 

 

Verify Connectivity - Open Putty

 

With the tunnel now online, we can test connectivity between the web servers across the sites.

 

 

Access web-sv-01a

 

Using Putty, open a connection to web-sv-01a.corp.local

  1. Using the scroll bar, scroll all the way down.
  2. Select web-sv-01a.corp.local
  3. Click Load
  4. Click Open

 

 

Login to web-sv-01a

 

Log into the session using the following credentials:

 

 

Ping web-sv-03a an web-sv-04a

 

We will now ping web-sv-03a (172.16.10.13) and web-sv-04a (172.16.10.14 )

  1. Enter the command ping 172.16.10.13 then press Enter
  2. Press Ctrl+C to stop ping
  3. Enter the command ping 172.16.10.14 then press Enter
  4. Press Ctrl+C to stop ping

Noting the screenshot above, you will see the successful pings.  Also you may see duplicate pings with the indicator of (DUP!), this is normal and due to our nested lab environment.

 

 

Conclusion

This completes the L2VPN section of this lab and the next sections will cover potential use cases.

 

L2VPN Use Case: Cloud


In this section, we will demonstrate the L2VPN Cloud use-case. We already have in place a load balancer pool enabled and configured as a service on our Perimeter-Gateway. First, we will verify if it works as expected.

 

For more information on setting up load balancer and other services on Edge, please refer to NSX introductory lab HOL 1403.


 

Lab Topology Diagram

 

 

 

Launch vCenter Client

 

  1. Click on vSphere Web Client - A on the desktop to launch the VMware vSphere Web Client

 

 

Log into vCenter

 

  1. User name =  root
  2. Password = VMware1!
  3. Click Login

 

 

Access NSX

 

  1. Click on Pin Icon to reduce right pane
  2. Click on the Network & Security (NSX) icon

 

 

Verify Edge Gateways

 

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

 

 

Access Load Balance Statistics

 

With the pool configuration already being done, we will look at the statistics to verify its function.

  1. Click Manage
  2. Click Load Balancer
  3. Click Pools
  4. Click Show Pool Statistics

 

 

Pool Status

 

You will see that pool-1 status is UP, verifying the pool is functional.

 

 

Extending Capacity into Cloud

In the event that your environment ran out of capacity on the local systems, we could utilize systems located in another site.  

We already have verified reachability to the web-servers at the remote site, those being web-sv-03a and web-sv-04a via the L2VPN tunnel. Now we can add these severs, web-sv-03a and web-sv-04a to the load-balancer pool.

 

 

Edit Pool

 

  1. Select pool-1
  2. Click the pencil icon to edit the pool

 

 

Add Servers to Pool

 

We need to add both web servers at the remove site.  The below section will need to be completed twice, once for each server.

web-sv-03a - 172.16.10.13

  1. Click + sign
  2. Name = web-sv-03a-REMOTE
  3. IP Address = 172.16.10.13
  4. Port = 443
  5. Monitor Port = 443
  6. Click OK

web-sv-04a - 172.16.10.14

  1. Click + sign
  2. Name = web-sv-04a-REMOTE
  3. IP Address = 172.16.10.14
  4. Port = 443
  5. Monitor Port = 443
  6. Click OK

 

 

Complete Pool Settings

 

  1. Click OK to complete the pool edit

 

 

Verify Functionality of Load Balancer

 

When accessing the web site that is backed by this pool, we will be able to see it access the various servers.

  1. Open a new web browsing tab, click the 3 Tier WebApp Inline favorite link
  2. You will see the server that this web page is coming from, in this case, web-sv-03a

Now by repeatedly pressing F5, you will see the server change as the load balancer selects different web servers in both locations.  Note, it may take many refreshes for it to cycle all servers.

 

 

Conclusion : Cloud Use Case

You have completed the cloud use case for L2VPN NSX functionality.

 

L2VPN Use Case: Migration (Optional)


In this lab, we will migrate a workload from the remote site to an NSX enabled site. This will show how you can relocate a VM from one site to another, without having to re-IP the system.

 


 

Export of web-sv-03a VM

This step has been completed for you.

The web-sv-03a VM from the vSphere Web Client - B was exported into an OVF. This OVF file has been placed into C:/Exports on the Control Center VM that you are working from.

 

 

Launch vCenter Client  - Site B

 

  1. Click on vSphere Web Client - B on the desktop to launch the VMware vSphere Web Client

 

 

Log into vCenter - Site B

 

  1. User name =  root
  2. Password = VMware1!
  3. Click Login

 

 

Navigate to VM

 

We need to power down the web-sv-03a VM so that when we bring it up in Site A, there is not a conflict.

  1. Using the search feature in the upper right corner, type web
  2. Select the web-sv-03a VM

 

 

Shut Down VM

 

  1. Select Actions
  2. Select Shut Down Guest OS

Confirm Shut Down - Click "yes"

Once the VM is shut down, you can close this browser tab.

 

 

Launch vCenter Client  - Site A

 

  1. Click on vSphere Web Client - A on the desktop to launch the VMware vSphere Web Client

 

 

Log into vCenter - Site A

 

  1. User name =  root
  2. Password = VMware1!
  3. Click Login

 

 

Access VMs and Templates

 

  1. Click on Pin Icon to reduce right pane
  2. Click on the VMs and Templates icon

 

 

Deploy Exported VM

 

Next the OVF template of the exported VM will be deployed.

  1. Right-click Hands on Lab datacenter
  2. Left-Click Deploy OVF Template

 

 

Select Source

 

We need to browse to the exported OVF file that is located at C:/Exports

  1. Select Local File
  2. Click Browse

 

 

Select Local C: Drive

 

  1. Click the Look In drop down, select Local Disk (C:)
  2. Select Local Disk (C:)

 

 

Enter Exports Folder

 

  1. Double-click Exports

 

 

Select Local C: Drive

 

  1. Select web-sv-03a.ova
  2. Click Open

 

 

Continue Import

 

  1. Now that the file is selected, click Next

 

 

Accept Options and Continue to Next Step

 

  1. Click Accept extra configuration options
  2. Click Next

 

 

Select Name and Folder

 

  1. No changes required here as the Hands on Labs datacenter is already selected, click Next

 

 

Select Cluster Resource

 

  1. Select Compute Cluster A
  2. Click Next

 

 

Select Storage

 

  1. The only datastore is already selected, click Next

 

 

Select Network

 

  1. Click the network drop down to expose all networks on the Compute_VDS - VM Access
  2. Using the scroll bar, scroll to the bottom
  3. Select vxw-dvs-44-virtualwire-2-sid-5001-Web-Tier01 - This is the Web-Tier-01 Logical Switch
  4. Click Next

 

 

Select Network

 

  1. Check Power on after deployment
  2. Click Finish

 

 

Open a Command Prompt

 

The VM is now deploying and powering up, upon power up it will be accessible by its old IP of 172.16.10.13.  We will start a ping to show the VM as it comes online.

Open a command prompt window

 

 

Start Ping to web-sv-03a Server

 

The VM is now deploying and powering up, upon power up it will be accessible by its old IP of 172.16.10.13.  We will start a ping to show the VM as it comes online.

Open a command prompt

 

 

Conclusion

You have completed the optional migration lab.  In this lab we ended up moving a VM from a remote site on a stretched IP segment, over to another datacenter with the same segment.  This move was completed without any changes to the OS configuration because of the stretched networking.

 

Module 4 - Trend Micro Integration (45 minutes)

Introduction to Service Composer


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.

Areas to be covered as part of this lab:

While walking you through these aspects we will also demonstrate how working with the third party vendors we can leverage dynamic security tagging for such things as AV protection and use traffic steering to send specific traffic to a virtual IPS.


Service Composer and Trend Micro AV integration


In this lab, we will create a quarantine security group that will be leveraged by the Trend Micro product to assign to  VMs that have been found to have a virus.


 

Launch vCenter Client

 

  1. Click on vSphere Web Client - A to launch the VMware vSphere Web Client

 

 

Log into vCenter and the NSX

 

  1. User name =  root
  2. Password = VMware1!
  3. Click Login

 

 

Select NSX

 

  1. Click on the Home icon.
  2. Click on the Network & Security (NSX) icon.

 

 

Creating Service Composer rules

 

  1. Click on Service Composer
  2. Click on Security Groups

 

 

Security groups

 

You are going to make a new security group that will be used to quarantine VMs that may be infected with malware.

  1. Click on the Create new Security Group (SG) icon

 

 

Name the SG

 

  1. In the Name field, type Quarantine
  2. Click Next

 

 

Define Dynamic Membership

 

  1. Click on the pull down menu and Select Security Tag
  2. Select Contains in the pull down menu
  3. Type ANTI_VIRUS in the text box
  4. Click Finish

 

 

Security Group Review

 

Now review the security groups within Service Composer. You should see the new group you just created call Quarantine. You should not see any Virtual Machines or rules applied to your newly created security group.

 

 

Security Policy review

 

1.     Click on the Security Policy Tab.

A security policy for Malware protection has already been created. This policy incorporates the Trend Micro AV capabilities with NSX.

2.     Double click on the Trend Micro AV and review the policy.

 

 

Security policy review continued...

 

As you can see, only Guest Introspection Services are currently enabled. The Trend Micro Deep security is what is leveraged.

  1. Click on the Manage tab

 

 

Security Policy review continued...

 

  1. Click on Information Security
  2. Guest Introspection Services
  3. Then highlight the Trend AV Service and click Edit

 

 

Trend Micro AV Service

 

  1. Highlight the Trend AV service.
  2. Click on Edit.

 

 

Trend AV service review continued...

 

As you can see, the Service and Service Profile both point to the Trend Micro Deep Security service and profile.  

  1. Click on Cancel and then Cancel on the next screen.

 

 

Return to Security Policy screen

 

  1. Click on the Network and Security arrow to return to the Security Policies screen

 

 

Creating a quarantine security policy

 

You will now create a quarantine security policy that will be enforced on any VM that has been tagged with the ANTI_VIRUS security tag.

  1. Click on the create security policy icon

 

 

Quarantine security policy creation

 

  1. Enter Quarantine Policy as the name for the security policy
  2. Click Next

 

 

Firewall Rule

 

  1. Click the Firewall Rules section.
  2. Click on the plus sign to create a quarantine firewall rules.

 

 

Quarantine firewall rules

 

  1. Enter Quarantine access in the Name field
  2. Select Block in the Action section
  3. Click OK

This rule will disable any traffic from the infected machine from communicating to any other machine by blocking all of its outbound traffic.

 

 

Quarantine firewall policy

 

1. Click on Finish

 

 

Apply policy to security group

 

Now that we have reviewed the Security Policy, we need to apply it to the Security group we created.

  1. Highlight the newly created policy
  2. Click on Action
  3. Click on Apply Policy

 

 

Apply policy to Security group

 

  1. Select the Quarantine security group
  2. Click OK

 

 

Security Group review

 

  1. Click on Security Groups tab

 

 

Review policy and security group

 

The Quarantine security group shows a 1 in the Firewall Rules section.

  1. Click on the 1 to see the group member.  Close the window.
  2. Click on the Home icon when done.

You have now created a security group and policy that will automatically quarantine an infected VM if a virus is detected by Trend Micro Deep Security.

 

 

Trend Micro

Now that we have the quarantine group setup, we need to check that Trend Micro is protecting the VM.

 

 

Verify Malware protection of VM

 

  1. Click on the tab to open a new tab in Chrome.
  2. Click on the Trend Micro Deep Security bookmark

 

 

Login to Trend Micro Deep Security Manager

 

  1. Login with username =  admin
  2. Password = VMware1!
  3. Click Sign In

 

 

Trend Micro dashboard

 

This is the Deep Security dashboard. Here you can see system alerts and status reports. Take a moment to look around.

  1. Click on Computers when your ready to move forward

 

 

Trend Micro protection online verification

 

  1. Click on Hands of Lab under the Virtual Machines folder
  2. In the main window, scroll down to the bottom of the screen
  3. Verify that Win7-AV.corp.local is showing green and Managed (Online)
  4. Verify that localhost.localdom (Trend Micro Deep Security...  is showing green and Managed (Online)

 

 

Win-AV protection check

 

  1. Right click on the WIN7-AV.corp.local machine
  2. Click on Details...

 

 

Trend Micro Detail view

 

Here we can see which features are enabled for the VM that is protected.  For this lab, we will focus on the Anti-Malware portion.

  1. Click on the Anti-Malware tab to look at the detail configuration

NOTE: You may see a dialogue box asking to "Leave this Page" or to "Stay on this Page".  Choose "Leave this Page".

 

 

Details of the Anti-Malware setting

 

Here you can configure the malware scan schedules.  

  1. Click on the Advanced tab

 

 

Trend Anti-Malware and NSX tagging integration

 

  1. Scroll to the bottom of the page
  2. Here is where the NSX Security tagging is enabled
  3. The security tag settings and name can be found in this pull down.  This Tag should match the Security tag name that was used in creating the security group in Service Composer.
  4. Click on Close when done

 

 

Testing AV policy enforcement

 

 

vCenter home

 

  1. Click on the vSphere Web Client Tab.
  2. Click on the home icon.

 

 

Log into AV-VM console

 

  1. Click on Hosts and Cluster

 

 

AV-VM console access cont...

 

  1. Click on the arrow next to Hands on Labs
  2. Click on the arrow next to Compute Cluster B
  3. Click on av-win7-01a
  4. Click on Launch Console

 

 

CTRL-ALT-DELETE

 

  1. Once the new windows opens, click on the Send Ctrl-Alt-Delete

 

 

Log into AV-VM

 

1. Enter VMware1! as the password and login.

 

 

Start the cmd prompt

 

  1. Click on the Windows icon
  2. Type cmd in the search programs field and hit enter

 

 

Start a ping Test

 

  1. In the command prompt, type ping 172.16.10.11 -t
  2. Once you see few successful pings, minimize the window

This ping will run in the background while you download the test virus and will be blocked once the security policy is enforced.

 

 

Test malware file

 

  1. From the Taskbar within your same Console window, launch IE
  2. Click on the corp.local Admin Portal bookmark
  3. Click the link Configuration Settings File

 

 

Test of malware protection

 

  1. Click Save and then Save again at the next screen
  2. Minimize the av-win7 console window

 

 

Trend Deep Security Event review

 

Deep Security Console, which is a tab on your Chrome web session

  1. Click on the Trend Micro Deep Security browser tab.
  2. Click on the Computer tab.
  3. Click on the Virtual Machines.
  4. Right-click on the WIN7-AV.corp.local.
  5. Click on Actions
  6. Click on Get Events. This will force the AV events to be updated.

 

 

Check vCenter to see security tag

 

  1. Click on the vSphere Web Client tab
  2. Click the refresh button

 

 

Security Tag

 

  1. You now see that the Security Tag was applied to the av-win7-01a by Trend Micro after the attempted download of the EICAR file.

 

 

Security Policy enforcement

 

Return to your av-win7-01a console window and open/maximize the cmd windows. You should see that the pings have been blocked.

  1. Close the cmd window
  2. Minimize the av-win7-01a console window. You will go back to it in the next section.

 

 

Return to Networking & Security

 

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

 

 

Click on Service Composer

 

  1. Click on Service Composer

 

 

Check within Service composer that VM is part of the Quarantine Security group

 

The Quarantine group that was created before now has a number 1 in the Virtual Machine column.

  1. Click on the 1 to see the Virtual machine that is now part of the Security Group.

 

 

Verification

 

We now see that av-win7-01a is part of the Quarantine group and firewalled off from other virtual machines.

 

 

AV Conclusion

This brings you to the conclusion of AV section of this lab. Please continue to see how NSX and Trend can provide virtual IPS services.

 

Trend Micro IPS and VMware NSX


In this section of the lab, we will create a test IPS signature and test that traffic from the VM is steered to the Trend Micro IPS and blocked.  The ability to steer traffic within your virtual environment to an IPS and not have to send the traffic out of the host to a physical IPS provides customers increased flexibility and protections.  Customers can now send their East-West traffic to an IPS instead of being limited to North-South.


 

Log into vCenter and the NSX

 

If you are not in the vSphere Web Client,  click on the Chrome icon on the task bar to launch the client.

  1. User name = root
  2. Password = VMware1!
  3. Click Login

 

 

Log into AV-VM console

 

  1. Click on Hosts and Cluster

 

 

AV-VM security tag cleanup

 

  1. Click on av-win7-01a

We will need to remove the security tag from this VM to be able to show how IPS works.  Due to limited screen steps you may need to perform the action below.  If you are able to see the Manage link at the bottom corner of the Security Tags section, click on it, otherwise follow the below steps.

2.     Double click on the Security Tags bar

 

 

Removing Tag

 

  1. Scroll all the way down to the bottom til you see the Manage link
  2. Click on the Manage link

 

 

Removing Tag selection

 

  1. Uncheck the box for ANTI_VIRUS.VirusFound.Threat=medium
  2. Click OK

Now click back into your av-win7-01a console window that you should still have in your task bar.

 

 

Test search web site

 

  1. From the av-win7-01a Console task bar, launch IE and click on the corp.local Admin Portal bookmark
  2. In the search field, enter the word google
  3. Click Submit

 

 

Successful web site query

 

This results in a simple form response page with Admin Portal Search Results as the test along with the search string.

Minimize the console window once again and return to the vSphere Web Client

 

 

Select NSX

 

  1. Click on the Home Icon
  2. Click on Network & Security (NSX)

 

 

Creating Service Composer traffic steering

 

  1. Click on Service Composer
  2. Click on Security Policies

 

 

Creating a IPS security policy

 

  1. Click on the create security policy icon

 

 

Creating a IPS security policy

 

  1. Enter the name Trend IPS Policy in the name field
  2. Click Next and click Next on the next two screens until you get to the Network Introspection Services section

 

 

Create traffic steering to Trend IPS

 

  1. Once on the Network Introspection Services section
  2. Click on the plus sign to create a new policy
  3. Type Trend Outbound IPS as the rule name
  4. This first rule is from the protected VM (Policy's Security Group) to Any
  5. Click Ok

 

 

IPS Inbound Rule

 

  1. Click on the plus sign
  2. Type Trend Inbound IPS as the rule name
  3. Click on the Change link

 

 

Change the direction

 

  1. Click on the Any as the Source
  2. Click OK

 

 

Inbound IPS

 

  1. The source has now changed to any and the Destination has automatically changed to the Policy's Security Group
  2. Click Ok

 

 

Finish the policy

 

Click Finish

 

 

Applying the IPS policy

 

  1. Highlight the newly created policy
  2. Click on the Actions pull down menu
  3. Click on Apply Policy

 

 

Apply the Policy

 

  1. Select the Protect group Security group
  2. Click OK

 

 

Testing IPS

Now, go back the av-win7-01a console window

 

 

Test IPS rules

 

  1. If you don't have IE still open, launch IE from the task bar and click on the corp.local Admin Portal bookmark
  2. In the search field, enter the word google
  3. Hit Submit

 

 

 

Blocked web page

 

This time, the website does not come back. The Trend Micro IPS has dropped the communication.  

We are now done with the console window. Please close the console window.

 

 

Trend Micro IPS Sig rule review

 

Now go to the Trend Micro Deep Security console to review the rule that was triggered by the VM. If you have the Trend Micro Deep Security tab still running in Chrome, return to it, otherwise follow the steps below.

  1. Click on the tab to open a new tab in Chrome.
  2. Click on the Trend Micro Deep Security bookmark

 

 

Login to Trend Micro Deep Security Manager

 

  1. Login with username =  admin
  2. Password = VMware1!
  3. Click Sign In

 

 

Trend Micro dashboard

 

This is the Deep Security dashboard. Here you can see system alerts and status reports.

  1. Click on Computers when your ready to move forward

 

 

Trend Micro protection online verification

 

  1. Click on Hands of Lab under the Virtual Machines folder
  2. In the main window, scroll down to the bottom of the screen
  3. Verify that Win7-AV.corp.local is showing green and Managed (Online)
  4. Verify that localhost.localdom (Trend Micro Deep Security...  is showing green and Managed (Online)

 

 

Win-AV protection check

 

  1. Right click on the WIN7-AV.corp.local machine
  2. Click on Details...

 

 

IPS

 

Now to show you why the website was blocked.  A test IPS signature was created to trigger if the word google was entered into a search form.  Follow the next steps to see details.

  1. Click on Intrusion Prevention
  2. Highlight the Test IPS signature rule
  3. Click on Properties

 

 

Test IPS signature review

 

  1. For this rule, Internet Explorer was specified as the application type
  2. Click on Rules

 

 

IPS signature rule

 

  1. The rule is written to match the text "google"
  2. Click cancel

 

 

IPS event Review

 

To see the details of the event

  1. Click on the Events tag
  2. Click on Get Events
  3. Set the Period to 7 days
  4. Click on the blue arrow to retrieve all the events.
  5. Click on any of the Events to see the details of the IPS that was triggered and the action taken.

Please exit out and close all windows when you are finished.

 

 

Conclusion

This brings you to the conclusion of this module.  

As you have seen, Service composer and security tags provide a very powerful security and automation tool.  With the integration of third party products such as Trend Micro Deep Security, you are now able to automate the quarantining of infected machines without requiring any manual intervention.  This allows for the reduced time from detection to mitigation within your environment.  

Leveraging traffic steering, customers can now send their data to virtual security appliances, such as the Trend Micro IPS to provide virtual protection for east/west or north/south traffic.

This brings us to the end of the module.  

 

Module 5 - Riverbed Integration (15 minutes)

Riverbed Network monitoring of NSX and VMware networks overview


Riverbed® and VMware are working together to provide comprehensive monitoring and troubleshooting capabilities for VMware NSX environments using Riverbed® Cascade®. Riverbed Cascade is industry-leading, application-aware network performance management solution that provides real-time, end-to-end visibility into the performance of critical business applications, across both physical and virtual networks.


 

Generating Traffic

 

In order to ensure that lab contains data within its reports, two scripts have been created to generate web traffic.

  1. Click on Web Traffic .11 shortcut and let it run
  2. Click on Web Traffic .12 shortcut and let it run
  3. Click on HTTPS Traffic .11 shortcuts and let it run
  4. Click on HTTPS Traffic .12 shortcuts and let it run

This will provide the data needed for this lab.

Minimize these windows while continuing through this lab.

 

 

Launch vCenter Client

 

  1. Double click on vSphere Web Client - A to launch the VMware vSphere Web Client

 

 

Log into vCenter and the NSX

 

  1. User name =  root
  2. Password = VMware1!
  3. Click Login

 

 

Setting up Netflow on the VDS

 

  1. Click on Networking

 

 

Netflow VDS settings

 

  1. Click on the arrow next to Hands on Labs
  2. Click on the Compute_VDS
  3. Click on the Manage tab

 

 

Netflow settings

 

To enable Netflow for any of the port groups or logical switches, you must first enable Netflow on the VDS.  In order to collect data for this lab, Netflow has already been enabled.

  1. Click on Settings
  2. Click on NetFlow to see the setting for the collector

 

 

Netflow on Uplink

 

Now to set the uplink Netflow settings

  1. Click on the arrow next to the Compute_VDS
  2. Click on the Compute_VDS_DVUplink
  3. Click on Manage
  4. Click on Settings -  (This has been pre-configured in order to collect data for this lab)

Once the uplink port group is enabled, the IPFIX templates will carry the external tunnel headers along with internal flow information.  This is required in order for the Riverbed product to collect and understand VXLAN headers and the different logical switches.

 

 

 

Netflow on the Virtual switches

 

To enable Netflow on the virtual switches  

  1. Click on the Web virtual switch (vxw-dvs-44-virtualwire-2-sid-5001-Web-Tier-01) You may need to click on a few of them if you can't see the entire switch name
  2. Click Manage
  3. Click Properties.  Here you can see that NetFlow is enabled. (Again this has been pre-configured, but don't worry you get to set up one.)

 

 

Enabling Netflow on the DB Virtual switch

 

Netflow is not enabled for the DB virtual switch and will need to be configured.

  1. Click on the DB virtual switch (vxw-dvs-44-virtualwire-4-sid-5003-DB-Tier-01)
  2. Click on Manage
  3. Click on Settings
  4. Click on the Edit button within the Properties screen

 

 

Enabling Netflow

 

  1. Click on Advanced
  2. Click on Allowed for the Netflow settings for the virtual switch

 

 

Enabling Netflow continued...

 

  1. Click on Monitoring
  2. Click on the pull down menu and set it to Enabled
  3. Click on Ok

Now Netflow is enabled for the DB virtual switch.

4.    Close the browser window and return to the desktop.

 

 

Netflow and IPFIX information in Riverbed

 

To launch the Riverbed Cascade manager

  1. Click on the Firefox icon from the task bar
  2. Click on the Riverbed Cascade bookmark
  3. Type in admin as the username
  4. Type in VMware1! as the password
  5. Click on Login

 

 

Riverbed Console

 

Once you log in the Riverbed Profile, take a look at some of the charts being displayed on the main dashboard.  You are welcome to look at some of the data displayed on this screen.

 

 

VXLAN report

 

Now to see the VXLAN and SDN report specific reports.

  1. Click on Reports
  2. Click on Shortcuts

 

 

Select SDN Report

 

  1. Scroll down to SDN Report and click on VXLAN Summary

 

 

Report Setting

 

  1. Verify that the report is set for 1 hour as the time frame.
  2. Click on Run now

 

 

No data

 

If the report appears to have no data, please provide additional time and then rerun the report.

 

 

Seeing data

 

Your report should show data as above.

 

 

Tenant Traffic

 

  1. Scroll down to the Virtual Network Details:Tenant Traffic section. This portion of the report provides information on how the traffic to each VNI or virtual switch is divided up.
  2. In this section of the report, each virtual network is split out and traffic data is provided.

 

 

Tunnel Endpoints

 

  1. The next section below, Top 10 Tunnel Endpoints by Avg, provides the information about when Tunnel Endpoints (VTEP) had the top traffic.
  2. Traffic for ESXi host are listed here

 

 

Endpoint Traffic

 

  1. Scroll down to the end of the report to the Tunnel Endpoint Pairs by Avg Bits/s section

Here is the virtual representation of the different ESXi hosts that are participating in the VXLAN network.  This information can be used for troubleshooting and validation of configurations.

 

 

Virtual Network detail report

 

  1. Scroll up slightly to the Virtual Networks by Avg Bits/s section
  2. Click on the Virtual Network 5001. This will generate a new report in its own window.

 

 

VXLAN Tunnel Traffic

 

Take some time to review this new report

  1. Scroll down to the Hosts by Avg Bits/s section.

In this section of the report, information about the VM that were communicating on VXLAN 5001, which is the web virtual switch, is provided. Even though some of the data was encapsulated with VXLAN headers, the Riverbed product is able to provide the IP addresses of the VMs communicating within that tunnel.   For example, 192.168.110.10, is the control center and is not part of any virtual switch, while 172.16.20.11, the App server VM, is part of the App virtual switch.

2. In the Application with Ports by Avg Bits/s section, just below, a breakdown of ports utilized is provided.  The web server traffic (HTTPS) and the web to app (8443) traffic is show. The information provided by these reports is very powerful for understanding your network and the communication between different components. They can also help find unauthorized traffic.

Continue looking through the report as you like. When done, please close the window. You may continue to look at other reports provided or you may close all windows and conclude this module.

 

 

Conclusion

The joint Riverbed and VMware solution enables organizations to embrace network virtualization without sacrificing operational visibility. Riverbed Cascade provides comprehensive and unified visibility across the WAN, LAN, virtual overlay networks and cloud-based data centers to meet the rapidly changing needs of forward-thinking organizations. It enables network operations to find and fix network and application performance by providing visibility into the tunnel traffic.

 

 

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-1425

Version: 20150227-061703