NSX Lab Description

HOL-1803-05-NET
Table of Contents
Lab Overview - HOL-1803-05-NET - SocaiLab: Getting Started with VMware NSX ............ 3
Lab Guidance .......................................................................................................... 4
Module 1 - NSX Manager Installation and Configuration (15 Minutes) ............................ 10
Introduction........................................................................................................... 11
Hands-on Labs Interactive Simulation: NSX Installation and Configuration - Part
1............................................................................................................................ 13
Hands-on Labs Interactive Simulation: NSX Installation and Configuration - Part
2............................................................................................................................ 16
Module 1 Conclusion ............................................................................................. 17
Module 2 - Logical Switching (30 minutes) ..................................................................... 19
Logical Switching - Module Overview .................................................................... 20
Logical Switching .................................................................................................. 21
Scalability and Availability .................................................................................... 48
Module 2 Conclusion ............................................................................................. 52
Module 3 - Logical Routing (60 minutes)......................................................................... 54
Routing Overview .................................................................................................. 55
Dynamic and Distributed Routing ......................................................................... 57
Centralized Routing............................................................................................... 86
ECMP and High Availability.................................................................................. 105
Prior to moving on - Please complete the following cleanup steps ..................... 154
Module 3 Conclusion ........................................................................................... 159
Module 4 - Service Composer and Distributed Firewall Overview (45 minutes) ............ 161
Distributed Firewall - Micro-segmentation Overview ........................................... 162
Improved IP Discovery Mechanism for Virtual Machines and SpoofGuard........... 191
Security Groups Overview................................................................................... 206
Security Policy Overview ..................................................................................... 211
Review of Service Composer Canvas .................................................................. 221
Module 4 - Conclusion ......................................................................................... 229
Module 5 - Intelligent Grouping (30 minutes) ............................................................... 232
Intelligent Grouping ............................................................................................ 233
Log on to the End of Support Virtual Machines ................................................... 234
Security Group Creation ...................................................................................... 242
Limit VM Access .................................................................................................. 248
Verify Limited Access from Windows XP VMs ...................................................... 262
Module 6 - User Based Security with a Jump Box (45 minutes)..................................... 268
User Based Security in a Jump Box Scenario....................................................... 269
Explore Link between NSX and Active Directory ................................................. 270
Use Security Objects based on AD Groups.......................................................... 279
Define Internal Application Firewall Rules ........................................................... 295
Testing User Identity Based Rules ....................................................................... 301
HOL-1803-05-NET Page 1
HOL-1803-05-NET
Module 7 - NSX Application Rule Manager (30 minutes) ............................................... 314

Application Rule Manager ................................................................................... 315
Application Microsegmentation ........................................................................... 316
Module 7 Conclusion .......................................................................................... 342
HOL-1803-05-NET
Lab Overview -
HOL-1803-05-NET -
SocaiLab: Getting Started
with VMware NSX
HOL-1803-05-NET
Lab Guidance
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. You can use the Table of Contents to access any
module of your choosing.
The Table of Contents can be accessed in the upper right-hand corner of the
Lab Manual.
VMware NSX is the platform for Network Virtualization. You will gain hands-on
experience with Logical Switching, Distributed Logical Routing, Dynamic Routing,
Distributed Firewall and Logical Network Services. This lab introduces the core
capabilities of VMware NSX in vSphere environments used to enable Network and
Security virtualization.
Lab Module List:
• (15 minutes) - Basic - This module will walk you through a basic install of NSX
including deploying the .ova, configuring NSX Manager, deploying controllers and
preparing hosts.
• (30 minutes) - Basic - This module will cover the creation of logical switches and
add virtual machines to the logical switches.
• (60 minutes) - Basic - This module will demonstrate the dynamic and distributed
routing capabilities supported on the NSX platform by providing routes between a
3-tier application.
• (45 minutes) - Basic - This module will cover the Distributed Firewall and Service
Composer creating firewall rules between a 3-tier application.
• (30 Minutes) - Basic - This module will help understand how NSX can help secure
applications and virtual machines using dynamic inclusion with security groups.
• (45 Minutes) - Basic - This module will demonstrate the capabilities of the Identity
Based Firewall feature and how it can provide security with Active Directory
integration.
• (30 Minutes) - Basic - This module will demonstrate application micro-
segmentation with Application Rule Manager.
Lab Captains:
• Module 1 - Michael Armstrong, Senior Systems Engineer, United

Kingdom
• Module 2 - Tay Wen Bin, Systems Engineer, Singapore
• Module 4 - Chris Cousins, Sr. Systems Engineer, USA
HOL-1803-05-NET
This lab manual can be downloaded from the Hands-on Labs Document site found here:
http://docs.hol.vmware.com
This lab may be available in other languages. To set your language preference and have
a localized manual deployed with your lab, you may utilize this document to help guide
you through the process:
http://docs.hol.vmware.com/announcements/nee-default-language.pdf
Location of the Main Console
1. The area in the RED box contains the Main Console. The Lab Manual is on the tab
to the Right of the Main Console.
2. A particular lab may have additional consoles found on separate tabs in the upper
left. You will be directed to open another specific console if needed.
3. Your lab starts with 90 minutes on the timer. The lab can not be saved. All your
work must be done during the lab session. But you can click the EXTEND to
increase your time. If you are at a VMware event, you can extend your lab time
twice, for up to 30 minutes. Each click gives you an additional 15 minutes.
Outside of VMware events, you can extend your lab time up to 9 hours and 30
minutes. Each click gives you an additional hour.
HOL-1803-05-NET
Alternate Methods of Keyboard Data Entry
During this module, you will input text into the Main Console. Besides directly typing it
in, there are two very helpful methods of entering data which make it easier to enter
complex data.
Click and Drag Lab Manual Content Into Console Active

Window
You can also click and drag text and Command Line Interface (CLI) commands directly
from the Lab Manual into the active window in the Main Console.
Accessing the Online International Keyboard
You can also use the Online International Keyboard found in the Main Console.
1. Click on the Keyboard Icon found on the Windows Quick Launch Task Bar.
HOL-1803-05-NET
Click once in active console window
In this example, you will use the Online Keyboard to enter the "@" sign used in email
addresses. The "@" sign is Shift-2 on US keyboard layouts.
1. Click once in the active console window.

2. Click on the Shift key.
Click on the @ key
1. Click on the "@ key".
Notice the @ sign entered in the active console window.
HOL-1803-05-NET
Activation Prompt or Watermark
When you first start your lab, you may notice a watermark on the desktop indicating
that Windows is not activated.
One of the major benefits of virtualization is that virtual machines can be moved and
run on any platform. The Hands-on Labs utilizes this benefit and we are able to run the
labs out of multiple datacenters. However, these datacenters may not have identical
processors, which triggers a Microsoft activation check through the Internet.
Rest assured, VMware and the Hands-on Labs are in full compliance with Microsoft
licensing requirements. The lab that you are using is a self-contained pod and does not
have full access to the Internet, which is required for Windows to verify the activation.
Without full access to the Internet, this automated process fails and you see this
watermark.
This cosmetic issue has no effect on your lab.
Look at the lower right portion of the screen
HOL-1803-05-NET
Please check to see that your lab is finished all the startup routines and is ready for you
to start. If you see anything other than "Ready", please wait a few minutes. If after 5
minutes your lab has not changed to "Ready", please ask for assistance.
HOL-1803-05-NET
Module 1 - NSX Manager

Installation and
Configuration (15
Minutes)
HOL-1803-05-NET
Introduction
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 extensible 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 fexibility 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.
Within this module we will be using an Interactive Simulation to focus on how to perform
the actual deployment of NSX within your environment. Within the lab environment the
actual deployment has already been completed for you.
In the Interactive Simulation, you will see how to:
• Deploying the NSX Manager OVA

• Registering NSX with vCenter
• Configuring Syslog and NSX Manager Backups
• Deploying NSX Controllers
• Preparing a Cluster for NSX
• Configuring and verifying VXLAN Tunnel End Points (VTEP's)
• Creating VXLAN Network Identifier Pools (VNI's)
• Creating Transport Zones
• NSX Manager Dashboard
HOL-1803-05-NET
NSX Components
HOL-1803-05-NET
Hands-on Labs Interactive Simulation:

NSX Installation and Configuration -
Part 1
HOL-1803-05-NET
This part of the lab is presented as a Hands-on Labs Interactive Simulation. This will
allow you to experience steps which are too time-consuming or resource intensive to do
HOL-1803-05-NET
live in the lab environment. In this simulation, you can use the software interface as if
you are interacting with a live environment.
*** SPECIAL NOTE *** The simulation you are about to do is comprised of two parts.
The first part will finish at the end of NSX Manager configuration. To continue to the
second half of the simulation you will need click on "Return to the Lab" in the upper
right of the screen. The manual will also outline the steps at the conclusion of the NSX
Manager configuration.
1. Click here to open the interactive simulation. It will open in a new browser
window or tab.
2. When finished, click the “Return to the lab” link to continue with this lab.
HOL-1803-05-NET
Hands-on Labs Interactive Simulation:

NSX Installation and Configuration -
Part 2
This part of the lab is presented as a Hands-on Labs Interactive Simulation. This will
allow you to experience steps which are too time-consuming or resource intensive to do
live in the lab environment. In this simulation, you can use the software interface as if
you are interacting with a live environment.
1. Click here to open the interactive simulation. It will open in a new browser
window or tab.
2. When finished, click the “Return to the lab” link to continue with this lab.
HOL-1803-05-NET
Module 1 Conclusion
In this module we showed the simplicity in which NSX can be installed and configured to
start providing layer two through seven services within software.
We covered the installation and configuration of the NSX Manager appliance which
included deployment, integrating with vCenter and configuring logging and backups. We
then covered the deployment of NSX Controllers as the control plane and installation of
the VMware Infrastructure Bundles (vibs) which are kernel modules pushed down to the
hypervisor. Finally we showed the automated deployment of VXLAN Tunnel Endpoints
(VTEP's), creation of a VXLAN Network Identifier pool (VNI's) and the creation of a
Transport Zone.
You've finished Module 1
Congratulations on completing Module 1.
If you are looking for additional information on deploying NSX then review the NSX 6.3
Documentation Center via the URL below:
• Go to http://tinyurl.com/hkexfcl
Proceed to any module below which interests you the most:
Lab Module List:
preparing hosts.
3-tier application.
integration.
Lab Captains:
HOL-1803-05-NET

Kingdom
How to End Lab
To end your lab click on the END button.
HOL-1803-05-NET
Module 2 - Logical
Switching (30 minutes)
HOL-1803-05-NET
Logical Switching - Module Overview

In this module, we will explore the following components of VMware NSX:
• Review the NSX controller cluster. The NSX controller cluster has eliminated the
requirement for multicast protocol support on the physical fabric, and also
provides functions such as VTEP, IP and MAC resolution.
• Create a Logical Switch and attach two VMs to the Logical Switch.
• Review the scalability and high availability of the NSX platform.
HOL-1803-05-NET
Logical Switching
In this section, we will be doing the following:
1. Confirm the configuration readiness of the hosts.

2. Confirm the logical network preparation.
3. Create a new logical switch.
4. Attach the logical switch to the NSX Edge Gateway.
5. Add VMs to the logical switch.
6. Test connectivity between VMs.
Launch Google Chrome
Open a browser by double clicking on the Google Chrome icon on the desktop.
Login to the vSphere Web Client
The home page should be the vSphere Web Client. Otherwise, click on the vSphere Web
Client Taskbar icon for Google Chrome.
1. Enter administrator@vsphere.local as User name.

2. Enter VMware1! as Password.
3. Click Login.
HOL-1803-05-NET
Navigate to Networking & Security in vSphere Web Client
1. Click Home icon.

2. Click Networking & Security.
View the deployed components
1. Click Installation.
2. Click Host Preparation.
HOL-1803-05-NET
You will see that the data plane components, also called network virtualization
components, are installed on the hosts in our clusters. These components include the
following: Hypervisor level kernel modules for Port Security, VXLAN, Distributed Firewall
and Distributed Routing.
Firewall and VXLAN functions are configured and 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 control VM is configured.
The topology after the host is prepared with data path

components
HOL-1803-05-NET
View the VTEP configuration
1. Click Logical Network Preparation tab.

2. Click VXLAN Transport tab.
3. Click the twistie to expand the clusters.
VXLAN configuration can be broken down into three important steps:
• Configure VXLAN Tunnel End Point (VTEP) on each host.

• Configure Segment ID range to create a pool of logical networks. As we are
utilizing Unicast mode in this lab, we do not need to specify a multicast range.
Otherwise, this step may require Multicast group address configuration.
• Configure the Transport Zone to define the span of the logical network.
As shown in the diagram, the hosts in the compute clusters are configured with VXLAN
Tunnel End Point (VTEP). The environment uses the 192.168.130.0/24 subnet for the
VTEP pool.
HOL-1803-05-NET
The topology after the VTEPs are configured across the

Clusters
One of the key challenges with VXLAN deployment in the past is that multicast protocol
support is required from physical network devices. This challenge is addressed in the
NSX Platform by providing a controller based VXLAN implementation and removing any
need to configure multicast in the physical network. This mode (Unicast) is the default
mode and customers don't have to configure any multicast addresses while defining the
logical network pool.
If Multicast replication mode is chosen for a given Logical Switch, NSX relies on the
native L2/L3 multicast capability of the physical network to ensure VXLAN encapsulated
multi-destination traffic is sent to all VTEPs. In this mode, a multicast IP address must be
associated to each defined VXLAN L2 segment (i.e., Logical Switch). L2 multicast
capability is used to replicate traffic to all VTEPs in the local segment (i.e., VTEP IP
addresses that are part of the same IP subnet). Additionally, IGMP snooping should be
configured on the physical switches to optimize the delivery of L2 multicast traffic.
Hybrid mode offers operational simplicity similar to unicast mode – IP multicast routing
configuration is not required in the physical network – while leveraging the L2 multicast
capability of physical switches.
The three modes of control plane configuration are:
HOL-1803-05-NET
• Unicast : The control plane is handled by an NSX controller. All unicast traffic
leverages headend replication. No multicast IP addresses or special network
configuration is required.
• Multicast: Multicast IP addresses on the physical network are used for the
control plane. This mode is recommended only when you are upgrading from
older VXLAN deployments. Requires PIM/IGMP on physical network.
• Hybrid : The optimized unicast mode. Offloads local traffic replication to physical
network (L2 multicast). This requires IGMP snooping on the first-hop switch, but
does not require PIM. First-hop switch handles traffic replication for the subnet.
Hybrid mode is recommended for large-scale NSX deployments.
Segment ID and Multicast Group Address Configuration
1. Click on Segment ID. Note that the Multicast addresses section above is blank.
As mentioned earlier, this is because we are using the default unicast mode with
a controller-based VXLAN implementation.
Defining Transport Zone settings
1. Click Transport Zones.
HOL-1803-05-NET
2. Double-click on RegionA0-Global-TZ.
A transport zone defines the span of a logical switch. Transport Zones dictate the
clusters that will participate in the use of a particular logical network. As you add new
clusters in your datacenter, you can increase the transport zone and thus increase the
span of the logical network. Once the logical switch spans across all compute clusters,
mobility and placement barriers (due to limited VLAN boundaries) are removed.
Confirm Clusters as members of Local Transport Zone
Confirm all 3 clusters are present in the Transport Zone.
1. Click on the Manage tab. It will show the clusters that are part of this Transport
Zone.
HOL-1803-05-NET
The topology after the Transport Zone is defined
After looking at the various NSX components and VXLAN configuration, we will now
create a NSX logical switch. The NSX logical switch creates logical broadcast domains or
segments to which an application or tenant virtual machine can be logically wired.
Go back to Networking & Security Menu
1. Click Back until we return to the Networking & Security Section.
If you have already navigated to other pages, return to the Networking & Security
Section via the Home Section on vSphere Web Client (the steps can be found at the
start of this chapter).
HOL-1803-05-NET
Create a new Logical Switch
1. Click Logical Switches on the left hand side.

2. Click on the "Green Plus" icon to create a new Logical Switch.
3. Name the Logical Switch: Prod_Logical_Switch.
4. Make sure RegionA0-Global-TZ is selected as the Transport Zone.
5. Unicast should be selected automatically.
6. Make sure you leave the Enable IP Discovery box checked. IP Discovery
enables ARP Suppression and is explained below.
7. Click OK.
Selecting "Enable IP Discovery" activates ARP (Address Resolution Protocol)

suppression. ARP is used to determine the destination MAC (Media Access Control)
address from an IP address by means of sending a broadcast on a layer 2 segment. If
the ESXi host with NSX Virtual Switch receives ARP traffic from a VM (Virtual Machine) or
an Ethernet request, the host sends the request to the NSX Controller which holds an
ARP table. If the NSX Controller instance already has the information in its ARP table, it
is returned to the host which replies to the VM.
HOL-1803-05-NET
Attach the new Logical Switch to the NSX Edge Services

Gateway for external access
1. Select the newly created logical switch (Prod_Logical_Switch).

2. Right-click on Prod_Logical_Switch and select Connect Edge.
HOL-1803-05-NET
Connect the Logical Switch to the NSX Edge
NSX Edge can be installed as a logical (distributed) router or as a edge services

gateway.
• The Edge Services Gateway, "Perimeter-Gateway-01", provides network services

such as DHCP, NAT, Load Balancer, Firewall and VPN and includes dynamic
routing capability.
• The Logical Distributed Router, "Distributed-Router-01" supports distributed and
dynamic routing.
We will cover more details on NSX Edge and routing in the subsequent modules.
For now, we will need to connect our logical switch to the NSX Edge Services Gateway,
Perimeter-Gateway-01. This will provide connectivity between VMs that are connected to
the logical switch and VMs that are not connected to the logical switch.
1. Click the radio button next to Perimeter-Gateway.

2. Click Next.
HOL-1803-05-NET
Attach logical switch to NSX Edge
1. Click the radio button next to vnic7.

2. Click Next.
Name the Interface
1. Name the Interface: Prod_Interface.

2. Select Connected.
3. Click the "Green Plus" icon to configure subnets.
HOL-1803-05-NET
Assign an IP Address to the Interface
1. Enter 172.16.40.1 as the Primary IP Address (Leave the Secondary IP Address

blank).
2. Enter 24 for the Subnet Prefix length.
3. Verify your settings are correct and click Next.
HOL-1803-05-NET
Complete the interface editing process
1. Click Finish.
HOL-1803-05-NET
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 web application virtual machines to this network.
HOL-1803-05-NET
Go to Hosts and Clusters
1. Click Home icon.

2. Click Hosts and Clusters.
Connect VMs to vDS
In order to be able to add the VMs to the logical switch that we created, we need to
make sure that the VMs network adapter is enabled and connects to the correct vDS.
HOL-1803-05-NET
1. Click Hosts and Clusters icon.

2. Expand RegionA01-COMP01.
3. Select web-03a.corp.local.
4. Click Configure.
5. Click Edit.
Connect and enable network interface
Ensure that web-03a.corp.local has it's network adapter connected to VM-

RegionA01-vDS-COMP (RegionA01-vDS-COMP). Otherwise, perform the following
steps:
1. Click on the dropdown list next to Network Adapter 1.
HOL-1803-05-NET
2. Select VM-RegionA01-vDS-COMP (RegionA01-vDS-COMP) as the interface. If

the correct interface is not being displayed, click Show more networks... and
the full list of interfaces will be displayed.
3. Check the Connected box next to Network Adapter 1.
4. Click OK.
Repeat the same steps for web-04a.corp.local in RegionA01-COMP2 cluster.
Attach web-03a and web-04a to the newly created

Prod_Logical_Switch
1. Click on the Home icon.

HOL-1803-05-NET
Select Logical Switches
1. Click Logical Switches tab.

2. Select Prod_Logical_Switch. Note the Virtual Wire ID and Segment ID may
differ.
3. Right-click Prod_Logical_Switch and select Add VM
HOL-1803-05-NET
Add virtual machines to Logical Switch
1. Search for VMs with "web" in their names.

2. Select web-03a.corp.local and web-04a.corp.local.
3. Click right arrow to add VMs to this logical switch.
4. Click Next.
HOL-1803-05-NET
Add virtual machines' vNIC to Logical Switch
1. Select the vNiCs of the two VMs.

2. Click Next.
HOL-1803-05-NET
Complete addition of VMs to Logical Switch
1. Click Finish.
Test connectivity between Web-03a & Web-04a
HOL-1803-05-NET
Hosts and clusters view
1. Click Home icon.

2. Click Hosts and Clusters.
HOL-1803-05-NET
Expand the Clusters
• Expand RegionA01-COMP01 and RegionA01-COMP02. You should see that

the two VMs, web-03a.corp.local and web-04a.corp.local are on two different
compute clusters. Note that these two VMs were added to the Logical Switch in
the previous steps.
HOL-1803-05-NET
Open Putty
1. Click Start.
2. Click the Putty Application icon from the Start Menu.
You are connecting from the Main Console which is in the 192.168.110.0/24 subnet.
The traffic will go through the NSX Edge and then to the Web Interface.
HOL-1803-05-NET
Open SSH session to web-03a
1. Select web-03a.corp.local.
2. Click Open.
Note: If web-03a.corp.local does not show up as an option, you can put 172.16.40.11
as the IP address in the Host Name text field.
Login into the VM
• If prompted, click Yes to accept the server's host key.

• If you are not automatically logged in, login as user root and password
VMware1!
HOL-1803-05-NET
Note: If you encounter difficulties connecting to web-03a.corp.local, please review

your previous steps and verify they have been completed correctly.
Ping web server web-sv-04a to show the layer 2

connectivity
Remember to use the SEND TEXT option to send this command to the console.
(See Lab Guidance)
Type ping -c 2 web-04a to send two pings instead of a continuous ping.
ping -c 2 web-04a
Note: web-04a.corp.local has an IP address of 172.16.40.12. If required, you can also

ping by IP address.
If you see DUP! packets, that 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.
HOL-1803-05-NET
Scalability and Availability

In this section, we will take a look at the scalability and availability of NSX controllers.
The NSX controller cluster in the NSX platform is the control plane component that is
responsible for managing the switching and routing modules in the hypervisors. The
NSX controller cluster consists of NSX controller nodes that manage specific logical
switches. The use of a NSX controller cluster for the management of VXLAN based
logical switches eliminates the need for multicast support from the physical network
infrastructure.
For resiliency and performance, production deployments must deploy a NSX controller
cluster with multiple NSX controller nodes. The NSX controller cluster represents a scale-
out distributed system, where each NSX controller node is assigned a set of roles. The
assigned role defines the types of task that can be implemented by the NSX controller
node. NSX controller nodes are deployed in odd numbers. The current best practice (and
the only supported configuration) is for the NSX cluster to have three NSX controller
nodes of active-active-active load sharing and redundancy.
To improve the scalability of the NSX architecture, a “slicing” mechanism is utilized to

ensure that all the NSX controller nodes can be active at any given time.
If a NSX controller(s) fail, the data plane (VM) traffic will not be affected. Traffic will
continue as the logical network information has already been pushed down to the logical
switches (the data plane). However, you will not be able to edit (add/move/change)
without the control plane (NSX controller cluster).
HOL-1803-05-NET
NSX Controllers' Scalability and Availability
1. Click Home icon.

Verify Existing NSX Controller Cluster Setup
HOL-1803-05-NET
1. Click Installation.
2. Click Management.
Under the NSX Controller nodes section, you can see that there are three NSX
controller nodes. NSX controller nodes are always deployed in odd numbers for high
availability and scalability.
Go to VMs and Templates
To see the NSX Controllers in the virtual environment:
1. Click Home icon.

2. Click VMs and Templates.
HOL-1803-05-NET
View NSX Controller Nodes (virtual machines)
1. Expand RegionA01
2. Click on one of the three NSX Controllers
3. Click Summary tab.
Observe the host that this NSX controller is residing on. The remaining two NSX
controllers will reside in two different hosts as well. In a production environment, all
three NSX controllers will reside on three different hosts with DRS anti-affinity rules to
avoid multiple failure of NSX controllers due to a single host outage.
HOL-1803-05-NET
Module 2 Conclusion
In this module, we demonstrated the following benefits of the NSX platform:
1. Network agility like the speedy provisioning and configuring of logical switches to
interface with virtual machines and external networks.
2. Scalability of the NSX architecture like the ability of the transport zone to quickly
span across multiple compute clusters and NSX controller cluster's capability as a
scale-out distributed system.
You have completed Module 2
Congratulations on completing Module 2!
If you are keen to learn more about NSX, please visit the NSX 6.3 Documentation Center
via the following URL:
• Go to https://tinyurl.com/y9zy7cpn
Proceed to any of the following modules:
Lab Module List:
preparing hosts.
3-tier application.
integration.
Lab Captains:

Kingdom
HOL-1803-05-NET

How to End Lab
To end your lab, click on the END button.
HOL-1803-05-NET
Module 3 - Logical
Routing (60 minutes)
HOL-1803-05-NET
Routing Overview
Lab Module Overview
In the previous module, we experienced the ease and convenience of creating isolated
logical switches/networks with a 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 and the
routing capability is distributed in the hypervisor. By incorporating this logical routing
component, NSX can reproduce complex routing topologies in the logical space. For
example, a three-tier application will be connected to three logical switches and the
routing between the tiers handled by this distributed logical router.
This module will help us understand some of the routing capabilities supported in the
NSX platform and how to utilize these capabilities while deploying a three-tier
application.
In this module, we will be doing the following:
• Examine traffic flow when the routing is handled by an external physical router or
NSX Edge Services Gateway.
• Configure the Distributed Logical Router and it's Logical Interfaces (LIFs) to
enable routing between app-tier and db-tier of the 3-tier application.
• Configure dynamic routing protocols on the Distributed Logical Router and NSX
Edge Services Gateway and understand the control of internal route
advertisements to external router.
• Scale and protect the NSX Edge Services Gateway through the use of other
routing protocols such as ECMP (Equal Cost Multipath Routing).
HOL-1803-05-NET
Special Instructions for CLI Commands
Many of the modules will have you enter Command Line Interface (CLI) commands.
There are two ways to send CLI commands to the lab.
First to send a CLI command to the lab console:
1. Highlight the CLI command in the manual and use Control+c to copy to
clipboard.
2. Click on the console menu item SEND TEXT.
3. Press Control+v to paste from the clipboard to the window.
4. Click the SEND button.
Second, a text file (README.txt) has been placed on the desktop of the environment
allowing you to easily copy and paste complex commands or passwords in the
associated utilities (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.
HOL-1803-05-NET
Dynamic and Distributed 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
The above picture shows this lab's environment where both Application VM and
Database VM reside on the same physical host. The red arrows show the traffic flow
between the two VMs.
1. The traffic leaves the Application VM and reaches the host.

2. As the Application VM and Database VM are not on the same network subnet, the
host will need to send that traffic to a layer 3 device. The NSX Edge, Perimeter
Gateway, which resides in the Management Cluster will perform the functions of a
layer 3 device. The traffic is sent to the host which the Perimeter Gateway (NSX
Edge) resides on.
3. The traffic reaches the Perimeter Gateway (NSX Edge) from the host.
4. The Perimeter Gateway (NSX Edge) sends the traffic back to the host.
HOL-1803-05-NET
5. The traffic is sent to the host which the Database VM is residing on.
6. The traffic reaches the Database VM from the host.
At the end of this lab, we will review the traffic flow diagram after distributed routing is
configured. This will help us to understand the positive impact that distributed routing
has on network traffic.
Access vSphere Web Client
• Open a browser by double clicking on the Google Chrome icon on the desktop.
The home page should be the vSphere Web Client. Otherwise, click on the vSphere Web
Client Taskbar icon for Google Chrome.
1. Type in administrator@vsphere.local into User name

2. Type in VMware1! into Password
3. Click Login
Confirm 3 Tier Application Functionality
1. Open a new browser tab.

2. Click Customer DB App bookmark.
HOL-1803-05-NET
Web Application Returning Database Information
Before you start the configuration for Distributed Routing, let's verify that the 3-tier Web
Application is working correctly. The three tiers of the application (web, app and
database) are on different logical switches and NSX Edge is providing routing between
these tiers.
• The web server will return a web page with customer information stored in the
database.
HOL-1803-05-NET
Removal of the App and Db Interfaces from the Perimeter

Edge
As you have seen in the earlier topology, the three logical switches or three tiers of the
application are terminated on the Perimeter Gateway (NSX Edge). The Perimeter
Gateway (NSX Edge) provides the routing between the three tiers. We are going to
change that topology by removing the App and DB interfaces from the Perimeter
Gateway (NSX Edge). After deleting the interfaces, we will move those interfaces on to
the Distributed Router (NSX Edge). To save time, a Distributed Router (NSX Edge) has
been deployed for you.
1. Click vSphere Web Client browser tab.

2. Click Home icon.
HOL-1803-05-NET
Select NSX Edge
1. Click NSX Edges.

2. Double-click Perimeter-Gateway-01.
Select Interfaces from the Settings Tab to Display Current

Interfaces
1. Click Manage.
2. Click Settings.
3. Click Interfaces.
HOL-1803-05-NET
You will see the configured interfaces and their properties. Information includes the vNIC
number, interface name, interface type (Internal, Uplink or Trunk) and interface status
(active or disabled).
Delete the App Interface
1. Click App_Tier interface.

2. Click red X to delete the selected interface from Perimeter-Gateway-01 (NSX
Edge). A warning box will pop-up to confirm interface deletion.
3. Click Ok to confirm the deletion.
Delete the DB Interface
1. Click DB_Tier interface.

2. Click red X to delete the selected interface from Perimeter-Gateway-01 (NSX
Edge). A warning box will pop-up to confirm interface deletion.
HOL-1803-05-NET
3. Click OK to confirm the deletion.
The Topology After the App and DB Interfaces are

Removed from the Perimeter Gateway (NSX Edge)
Navigate Back to the NSX Home Page
HOL-1803-05-NET
After removing the App and DB interfaces from the Perimeter-Gateway-01 (NSX Edge),
we will navigate back to the Networking & Security section to access the Distributed-
Router-01 (NSX Edge).
1. Click Back until we return to NSX Edges section.
Add App and DB Interfaces to the Distributed Router
We will begin configuring Distributed Routing by adding the App and DB interfaces to
the Distributed Router (NSX Edge).
1. Double-click Distributed-Router-01.
Display the Interfaces on the Distributed Router
1. Click on Manage.
HOL-1803-05-NET
2. Click on Settings.
3. Click on Interfaces to display all the interfaces configured on the Distributed
Router (NSX Edge).
Add Interfaces to the Distributed Router
1. Click Green Plus icon to add a new interface.

2. Name the interface as App_Tier.
3. Click Select under Connected To configuration.
HOL-1803-05-NET
Specify the Network
1. Select the App_Tier_Logical_Switch radio button. The interface will

communicate on this network.
2. Click OK.
Add Subnets
HOL-1803-05-NET
1. Click Green Plus icon to configure subnets.

2. Enter 172.16.20.1 as the Primary IP Address.
3. Enter 24 as the Subnet Prefix Length.
4. Click OK. This will add the interface and it's configuration to the logical router.
Add the DB Interface
• Repeat the previous two steps to add and configure the DB_Tier Interface
on Distributed-Router-01 (NSX Edge).
• Name DB_Tier.
• Connect to DB_Tier_Logical_Switch.
• IP address 172.16.30.1 and a subnet prefix length of 24.
Ensure the configuration of App_Tier and DB_Tier interfaces on Distributed-Router-01

(NSX Edge) matches the picture above.
HOL-1803-05-NET
The New Topology after Moving the App and DB Interfaces

to the Distributed Router
After the two interfaces are configured on Distributed-Router-01 (NSX Edge), the
interface configurations are automatically pushed to every host in the environment. In
each host, there is a Routing (DR) Kernel loadable module which will handle routing
between VMs. In our lab scenario, the routing between the App and DB interfaces will be
handled by the Distributed Routing (DR) Kernel loadable module in the host instead of
Perimeter Gateway (NSX Edge). If there is communication between VMs that are
connected to different subnets but resides on the same host, traffic will not take an un-
optimal path as shown in the earlier traffic flow diagram.
Return to Browser Tab with 3-Tier Web App
HOL-1803-05-NET
After making the changes for routing to be handled by the distributed router, you will
notice that access to the 3-tier Web Application fails. This is because there is currently
no route between the Web Servers and App/DB VMs.
1. Click on HOL - Customer Database browser tab (this tab was opened in the
previous steps).
Note: If you close the HOL - Customer Database browser tab earlier, open a new
browser tab and click Customer DB App bookmark.
Verify that the 3 Tiered Application Stops Working
1. Click Refresh.
The application will take a few seconds to time out and you may need to click "X" to
stop the browser. If you see customer data, it may be cached data and you will need to
close and re-open the browser to correct it.
Next, we will configure dynamic 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".
HOL-1803-05-NET
Configure Dynamic Routing on the Distributed Router
Return to the vSphere Web Client browser tab.
1. Click Routing.
2. Click Global Configuration.
3. Click Edit to change Dynamic Routing Configuration.
Edit Dynamic Routing Configuration
1. Select the IP address of the Uplink interface as the default Router ID. In our case,
the Uplink interface is Transit_Network_01 and the IP address is 192.168.5.2.
HOL-1803-05-NET
2. Click OK
Note: The router ID is a 32 bit identifier denoted as an IP address and is important in the
operation of OSPF as it indicates the routers identity in an autonomous system. In our
lab scenario, we are using a router ID that is the same as the IP address of the uplink
interface on the NSX edge which is acceptable but not necessary. The screen will return
to the Global Configuration section with the option to Publish Changes.
Publish Changes
1. Click Publish Changes to update the configuration on Distributed-Router-01

(NSX Edge).
Configure OSPF Specific Parameters
We will be using OSPF as our dynamic routing protocol.
1. Click OSPF.
2. Click Edit to change OSPF Configuration. This will open the OSPF Configuration
dialog box.
HOL-1803-05-NET
Enable OSPF
1. Check Enable OSPF.

2. Enter 192.168.5.3 as the Protocol Address.
3. Enter 192.168.5.2 as the Forwarding Address.
4. Check Enable Graceful Restart.
5. Click OK.
Note: The Protocol Address is required for sending control traffic to the Distributed
Router Control VM while the Forwarding Address is used by the router datapath
module in the hosts to forward datapath packets. The separation of control plane and
data plane traffic in NSX means that the routing instance's data forwarding capability is
maintained even when the control function is restarted or reloaded. The control function
is referred to as "Graceful Restart" or "Non-stop Forwarding". The screen will return
to the Global Configuration section with the option to Publish Changes. However,
please DO NOT publish changes yet. Instead of publishing changes for every
configuration, we will complete all the configurations and publish them all at one time.
HOL-1803-05-NET
Configure Area Definition
1. Click Green Plus icon. This will open the New Area Definition dialog box.
2. Enter 10 as the Area ID. Leave the other settings as default.
3. Click OK
Note: The Area ID for OSPF is very important and there are several types of OSPF
areas. Hence, please ensure that the NSX Edge is defined in the correct area so that it
can work properly with the OSPF configuration within the network.
HOL-1803-05-NET
Area to Interface Mapping
1. Click Green Plus icon. This will open the New Area to Interface Mapping
dialog box.
2. Select Transit_Network_01 as the Interface.
3. Select 10 as the Area.
4. Click OK.
Publish Changes

(NSX Edge).
HOL-1803-05-NET
Confirm OSPF Routing is Enabled on the Distributed

Router
Ensure the OSPF configuration on Distributed-Router-01 (NSX Edge) matches the picture
above.
Confirm Route Redistribution
1. Click Route Redistribution.
HOL-1803-05-NET
Verify Route Redistribution
• Ensure that route redistribution for OSPF is enabled.
Add BGP to OSPF Route Redistribution Table
1. Click OSPF in the Route Redistribution table.

2. Click Pencil icon to change the configuration for OSPF.
3. Check BGP. Leave the other settings as default.
4. Click OK.
HOL-1803-05-NET
Publish Changes

(NSX Edge).
Configure OSPF Routing on the Perimeter Edge
Next, we will configure dynamic routing on Perimeter-Gateway-01 (NSX Edge) to restore

connectivity to the 3-tier Application.
HOL-1803-05-NET
Select the Perimeter Edge
Global Configuration for the Perimeter Edge
HOL-1803-05-NET
1. Click Manage.
2. Click Routing.
3. Click OSPF.
4. Click Edit to change OSPF Configuration. This will open the OSPF Configuration
dialog box.
Enable OSPF

2. Check Enable Graceful Restart.
3. Click OK.
Configure Area Definition
1. Click Green Plus icon. This will open the New Area Definition dialog box.
2. Enter 10 as the Area ID. Leave the other settings as default.
3. Click OK
HOL-1803-05-NET
Note: The Area ID for OSPF is very important and there are several types of OSPF
areas. Hence, please ensure that the NSX Edge is defined in the correct area so that it
can work properly with the OSPF configuration within the network.
Add Transit Interface to Area to Interface Mapping
1. Click Green Plus icon. This will open the New Area to Interface Mapping
dialog box.
2. Select Transit_Network_01 as the vNIC.
3. Select 10 as the Area.
4. Click OK.
Publish Changes
1. Click Publish Changes to update the configuration on Perimeter-Gateway-01

(NSX Edge).
HOL-1803-05-NET
Confirm OSPF Routing is Enabled on the Perimeter Edge
Ensure the OSPF configuration on Perimeter-Gateway-01 (NSX Edge) matches the

picture above.
Configure Route Redistribution

2. Click Edit to change Route Redistribution Status. This will open the Change
redistribution settings dialog box.
You will notice that Perimeter-Gateway-01 (NSX Edge) has already been configured for
dynamic routing with BGP. This dynamic routing configuration allows Perimeter-
Gateway-01 (NSX Edge) to communicate and distribute routes to the router running the
overall lab.
HOL-1803-05-NET
Change Redistribution Settings
1. Check OSPF.
2. Verify BGP is checked.
3. Click OK.
Note: BGP is the routing protocol used between Perimeter-Gateway-01 (NSX Edge) and
the vPod Router.
Edit BGP Redistribution Criteria
1. Click BGP in the Route Redistribution table.

2. Click Pencil icon to change the configuration for BGP.
3. Check OSPF.
4. Click OK.
HOL-1803-05-NET
Configure OSPF Route Redistribution
1. Click Green Plus icon.

2. Select OSPF as the Learner Protocol.
3. Check BGP.
4. Check Connected.
5. Click OK.
Publish Changes

(NSX Edge).
HOL-1803-05-NET
Review New Topology
The new topology shows route peering between Distributed Router and Perimeter
Gateway (NSX Edge). Routes to any network connected to the Distributed Router will be
distributed to the Perimeter Gateway (NSX Edge). In addition, we also have control over
the routing from the Perimeter Gateway to the physical network.
The next section will cover this in more detail.
HOL-1803-05-NET
Verify Communication to the 3-Tier App
The routing information is being exchanged between the Distributed Router and
Perimeter Gateway. Once the routing between the two NSX Edges is established, the
connectivity to the 3-tier Web Application will be restored. Let's verify that the routing is
functional by accesssing the 3-tier Web Application.
previous steps). However, it may show 504 Gateway Time-out instead.
2. Click Refresh.
Note: It may take a minute for route propagation as the lab is a nested environment.
Dynamic and Distributed Routing Completed
In this section, we have successfully configured dynamic and distributed routing. In the
next section, we will review centralized routing with the Perimeter Gateway (NSX Edge).
HOL-1803-05-NET
Centralized Routing
In this section, we will look at various elements to see how the routing is done
northbound from the edge. This includes how OSPF dynamic routing is controlled,
updated, and propagated throughout the system. We will verify the routing on the
perimeter edge appliance through the virtual routing appliance that runs and routes the
entire lab.
Special Note: On the desktop, you will find a file named 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.
Current Lab Topology
HOL-1803-05-NET
The above diagram shows the current topology where OSPF is redistributing the routes
between Perimeter Gateway and Distributed Router. In addition, we also see the
northbound link from Perimeter Gateway to the vPod Router.
Look at OSPF Routing in Perimeter Gateway
First we will confirm the Web App is functional, then we will log into the NSX Perimeter
Gateway to view OSPF neighbors and see existing route distribution. This will show how
the Perimeter Gateway is learning routes from not only the Distributed Router, but the
vPod router that is running the entire lab.
Confirm 3 Tier Application Functionality
1. Open a new browser tab.

2. Click Customer DB App bookmark.
Web Application Returning Database Information
HOL-1803-05-NET
Before you start the configuration for Distributed Routing, let's verify that the 3-tier Web
Application is working correctly. The three tiers of the application (web, app and
database) are on different logical switches and NSX Edge is providing routing between
these tiers.
• The web server will return a web page with customer information stored in the
database.
Navigate to Perimeter-Gateway VM

2. Click Home icon.
HOL-1803-05-NET
Launch Remote Console
1. Expand RegionA01.
2. Select Perimeter-Gateway-01-0.
3. Click on the Black Screen.
HOL-1803-05-NET
Access Remote Console
When the VM console launches in the browser tab, it will appear as a black screen. Click
inside the black screen and press Enter a few times to make the VM console appear
from the screensaver.
HOL-1803-05-NET
Login to Perimeter Gateway
Log into Perimeter-Gateway-01 with the following credentials:
1. Username: admin
2. Password: VMware1!VMware1!
Note: NSX Edge require a 12-character complex password.
HOL-1803-05-NET
Special Instructions for CLI Commands
Many of the modules will have you enter Command Line Interface (CLI) commands.
There are two ways to send CLI commands to the lab.
First to send a CLI command to the lab console:
1. Highlight the CLI command in the manual and use Control+c to copy to
clipboard.
2. Click on the console menu item SEND TEXT.
3. Press Control+v to paste from the clipboard to the window.
4. Click the SEND button.
Second, a text file (README.txt) has been placed on the desktop of the environment
allowing you to easily copy and paste complex commands or passwords in the
associated utilities (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.
View BGP Neighbors
Let's look at the BGP neighbors of Perimeter-Gateway-01.
1. Enter show ip bgp neighbors.
HOL-1803-05-NET
show ip bgp neighbors
Reviewing Displayed BGP Neighbor Information
Let's review the information on BGP neighbors.
1. BGP neighbor is 192.168.100.1 - This is the router ID of the vPod Router inside
the NSX environment.
2. Remote AS 65002 - This is the autonomous system number of the vPod Router's
external network.
3. BGP state = Established, up - This means the BGP neighbor adjacency is
complete and the BGP routers will send update packets to exchange routing
information.
Review Routes on Perimeter Edge and their Origin
Let's see the available routes on Perimeter-Gateway-01.
1. Enter show ip route.
show ip route
HOL-1803-05-NET
Review Route Information
Let's review the information on routes.
1. B indicates that this route is learned via BGP. This is also the default route and it
originates from the vPod Router (192.168.100.1).
2. C indicates that this route is directly connected to Perimeter-Gateway-01.
172.16.10.0/24 is the Web-Tier Logical Switch (network segment).
3. O indicates that this route is learned via OSPF from Distributed-Router-01
(192.168.5.2). 172.16.20.0/24 and 172.16.30.0/24 are the App-Tier Logical
Switch and DB-Tier Logical Switch (network segments).
Controlling BGP Route Distribution
There could be a situation where you would only want BGP routes to be distributed
inside of the virtual environment, but not with the physical world. We are able to control
that route distribution easily from the NSX Edge configuration.
HOL-1803-05-NET
Navigate to NSX in vSphere Web Client
Return to vSphere Web Client.
1. Click on the Home icon.

Access Perimeter Gateway
1. Click NSX Edges.

HOL-1803-05-NET
Access BGP Routing Configuration
1. Click Manage.
2. Click Routing.
3. Click BGP.
Remove BGP Neighbor Relationship to vPod Router
We will remove the mapping of BGP Local AS 65002 so that Perimeter-Gateway-01

and vPod Router will no longer be route peered.
1. Select the IP Address of the vPod Router, 192.168.100.1.

2. Click red X to delete the selected neighbor from Perimeter Gateway (NSX Edge).
A warning box will pop-up to confirm neighbor deletion.
3. Click Yes.
HOL-1803-05-NET
Publish Change

(NSX Edge).
Naivgate to Perimeter Gateway VM Console
1. Click on Perimeter-Gateway-01-0 browser tab (this tab was opened in the

previous steps).
Show BGP Neighbors
The VM console may appear as a black screen in the browser tab. Click inside the black
screen and press Enter a few times to make the VM console appear from the
screensaver.
You will notice that vPod Router (192.168.250.1) has been dropped from the list.
HOL-1803-05-NET
Show Routes
show ip route
Notice that the only routes being learned via OSPF is from the Distributed Router
(192.168.5.2).
HOL-1803-05-NET
Verify that the 3-Tiered Application Stops Working
Since no routes exist between the control center and the virtual networking
environment, the web app should fail.
previous steps).
2. Click Refresh.
The application will take a few seconds to time out and you may need to click "X" to
stop the browser. If you see customer data, it may be cached data and you will need to
close and re-open the browser to correct it.
HOL-1803-05-NET
Re-Establish Route Peering
Now let's get the route peering between the Perimeter-Gateway-01 and vPod Router
back in place.
1. Click on vSphere Web Client browser tab

HOL-1803-05-NET
Add BGP Neighbor Configuration Back in

2. Enter 192.168.100.1 as the IP Address.
3. Enter 65002 as the Remote AS.
4. Click OK.
Publish Change

(NSX Edge).

HOL-1803-05-NET
Naivgate to Perimeter Gateway VM Console
1. Click on Perimeter-Gateway-01-0 browser tab (this tab was opened in the

previous steps).
The VM console may appear as a black screen in the browser tab. Click inside the black
screen and press Enter a few times to make the VM console appear from the
screensaver.
Show BGP Neighbors
1. Enter show ip bgp neighbors
You will notice that vPod Router (192.168.100.1) is shown as a neighbor now.

HOL-1803-05-NET
Review Routes on Perimeter Edge and their Origin
Type "show ip route"
show ip route
Show Routes
The default route from the vPod Router (192.168.100.1) is now back in the list.

HOL-1803-05-NET
Verify that the 3-Tiered Application Is Working
With the routes back in place, the Web App should be functional again.
previous steps).
2. Click Refresh.
We have successfully completed this section of the lab and will move on to ECMP and
High Availability with the NSX Edges in the next section.

HOL-1803-05-NET
ECMP and High Availability

In this section, we will now add another Perimeter Gateway to the network and then use
ECMP (Equal Cost Multipath Routing) to scale out Edge capacity and increase its
availability. With NSX we are able to perform an in place addition of an Edge device and
enable ECMP.
ECMP is a routing strategy that allows next-hop packet forwarding to a single destination
can occur over multiple best paths. These best paths can be added statically or as a
result of metric calculations by dynamic routing protocols like OSPF or BGP. The Edge
Services Gateway utilizes Linux network stack implementation, a round-robin algorithm
with a randomness component. After a next hop is selected for a particular source and
destination IP address pair, the route cache stores the selected next hop. All packets for
that flow go to the selected next hop. The Distributed Logical Router uses an XOR
algorithm to determine the next hop from a list of possible ECMP next hops. This
algorithm uses the source and destination IP address on the outgoing packet as sources
of entropy.
Now we will configure a new Perimeter Gateway, and establish an ECMP cluster between
the Perimeter Gateways for the Distributed Logical Router to leverage for increased
capacity and availability. We will test availability by shutting down one of the Perimeter
Gateways, and watching the traffic path change.

HOL-1803-05-NET
Navigate to NSX in vSphere Web Client

2. Click Home icon.

HOL-1803-05-NET
Add Additional Perimeter Gateway Edge
Let's add an additional Perimeter Gateway NSX Edge.
1. Click NSX Edges.


HOL-1803-05-NET
Select and Name Edge
1. Select Edge Services Gateway as Install Type.

2. Enter Perimeter-Gateway-02 as Name.
3. Click Next.

HOL-1803-05-NET
Set Password
1. Enter VMware1!VMware1! as Password.

2. Enter VMware1!VMware1! for Confirm password.
3. Check Enable SSH access.
4. Click Next.
Note: All passwords for NSX Edges are 12-character complex passwords.

HOL-1803-05-NET
Add Edge Appliance
1. Click Green Plus icon. The Add NSX Edge Appliance dialog box will appear.
2. Select RegionA01-MGMT01 for Cluster/Resource Pool.
3. Select RegionA01-ISCSI01-MGMT01 for Datastore.
4. Select esx-04a.corp.local for Host.
5. Click OK.

HOL-1803-05-NET
Continue Deployment
1. Click Next.

HOL-1803-05-NET
Add Uplink Interface
1. Click Green Plus icon. This will add the first interface.

HOL-1803-05-NET
Select Switch Connected To
We have to pick the northbound switch interface (a distributed port group) for this
Perimeter Gateway.
1. Click Select under Connected To.

2. Click Distributed Portgroup.
3. Select Uplink-RegionA01-vDS-MGMT.
4. Click OK.

HOL-1803-05-NET
Name and Add IP
1. Enter Uplink as Name.

2. Select Uplink as Type.
4. Enter 192.168.100.4 as Primary IP Address.
5. Enter 24 as Subnet Prefix Length.
6. Click OK.

HOL-1803-05-NET
Add Edge Transit Interface
1. Click Green Plus icon. This will add the second interface.

HOL-1803-05-NET
Select Switch Connected To
We have to pick the northbound switch interface (VXLAN Backed Logical Switch) for this
Perimeter Gateway.
1. Click Select under Connected To.

2. Click Logical Switch.
3. Select Transit_Network_01_5006.
4. Click OK.

HOL-1803-05-NET
Name and Add IP
1. Enter Transit_Network_01 as Name.

2. Select Internal as Type.
4. Enter 192.168.5.4 as Primary IP Address.
5. Enter 29 as Subnet Prefix Length. Please ensure the correct Subnet Prefix
Length (29) is provided or the lab will not function.
6. Click OK.

HOL-1803-05-NET
Continue Deployment
Ensure the IP Addresses and Subnet Prefix Length information are the same as the
picture.
1. Click Next.

HOL-1803-05-NET
Remove Default Gateway
We are removing the default gateway since information is received via OSPF.
1. Uncheck Configure Default Gateway.

2. Click Next.

HOL-1803-05-NET
Default Firewall Settings
1. Check Configure Firewall default policy.

2. Select Accept as the Default Traffic Policy.
3. Click Next.

HOL-1803-05-NET
Finalize Deployment
1. Click Finish. This will start the deployment.

HOL-1803-05-NET
Edge Deploying
It will take a couple of minutes for the NSX Edge to deploy.
1. The NSX Edges section will show that there is 1 Installing while Perimeter-
Gateway-02 is being deployed.
2. The status for Perimeter-Gateway-02 will indicate that it is Busy. This means the
deployment is in process.
3. Click refresh icon on the vSphere Web Client to see the deployment status of
Perimeter-Gateway-02.
Once the status for Perimeter-Gateway-02 indicates that it is Deployed, we can move on
to the next step.
Configure Routing on New Edge
We will need to configure OSPF on Perimeter-Gateway-02 (NSX Edge) before ECMP can
be enabled.

HOL-1803-05-NET
Routing Global Configuration
We need to configure the identity of this router on the network.
1. Click Manage.
2. Click Routing.
3. Select Global Configuration.
4. Click Edit to change Dynamic Routing Configuration.
5. Select Uplink -192.168.100.4 as Router ID.
6. Click OK.
Publish Changes

(NSX Edge).

HOL-1803-05-NET
Enable OSPF
1. Click OSPF.
2. Click Edit to change OSPF Configuration.
4. Click OK.

HOL-1803-05-NET
Add New Area

2. Enter 10 as Area ID.
3. Click OK.

HOL-1803-05-NET
Add Transit Interface Mapping
Now the same must be done for the downlink interface to the Distributed Router

2. Select Transit_Network_01 as vNIC.
3. Select 10 as Area.
4. Click OK.

HOL-1803-05-NET
Publish Changes

(NSX Edge).
Enable BGP
1. Select BGP.
2. Click Edit to change BGP Configuration.
3. Check Enable BGP.
4. Enter 65001 as the Local AS.
5. Click OK.

HOL-1803-05-NET
Add New Neighbor

2. Enter 192.168.100.1 as the IP Address.
3. Enter 65002 as the Remote AS.
4. Click OK.
Publish Changes

(NSX Edge).

HOL-1803-05-NET
Enable BGP and OSPF Route Distribution
We must now enable BGP and OSPF route redistribution in order for the routes to be
accessible through this edge.

2. Click Edit to change Route Redistribution Status.
3. Check OSPF.
4. Check BGP.
5. Check OK.

HOL-1803-05-NET
OSPF Route Distribution Table
1. Click the Green Plus icon.

2. Check BGP.
3. Check Connected.
4. Click OK.

HOL-1803-05-NET
BGP Route Distribution Table

2. Select BGP as the Learner Protocol.
3. Check OSPF.
4. Check Connected.
5. Click OK.
Publish Changes

HOL-1803-05-NET

(NSX Edge).
Enable ECMP
We are now going to enable ECMP on the Distributed Router and Perimeter Gateways
1. Click Back until we return to the NSX Edges section.
Enable ECMP on Distributed Router
We will first enable ECMP on the Distributed Router.
1. Click NSX Edges.


HOL-1803-05-NET
Enable ECMP on DLR
1. Click Manage.
2. Click Routing.
4. Click Enable.
Publish Change

(NSX Edge).

HOL-1803-05-NET
Return to Edge Devices
1. Click Back until we return to the NSX Edges section.
Access Perimeter Gateway 01

HOL-1803-05-NET
Enable ECMP on Perimeter Gateway 01
1. Click Manage.
2. Click Routing.
4. Click Enable.
Publish Change

(NSX Edge).
1. Click Back.

HOL-1803-05-NET
Enable ECMP on Perimeter Gateway 02
1. Click Manage.
2. Click Routing.
4. Click Enable.

HOL-1803-05-NET
Publish Change

(NSX Edge).
Topology Overview
At this stage, this is the topology of the lab. This includes the new Perimeter Gateway
that has been added, routing configured, and ECMP turned on.

HOL-1803-05-NET
Verify ECMP Functionality from Distributed Router
Let's now access the distributed router to ensure that OSPF is communicating and ECMP
is functioning.
1. Click Home icon.


HOL-1803-05-NET
Launch Remote Console
1. Click Refresh.
3. Select Distributed-Router-01-0.
4. Select Summary.
5. Click on VM Console.

HOL-1803-05-NET
Access VM Console
Login to Perimeter Gateway
Log into the Distributed-Router-01 with the following credentials.
1. Username: admin
2. Password: VMware1!VMware1!

HOL-1803-05-NET
View OSPF Neighbors
The first thing we will do is look at the OSPF neighbors to the Distributed Router.
1. Enter show ip ospf neighbors.
show ip ospf neighbors
This shows us that the Distributed Router has two OSPF neighbors. The neighbors are
the Perimeter-Gateway-1(192.168.100.3) and Perimeter-Gateway-2
(192.168.100.4).
Review Routes from Distributed Router to Perimeter Edges
show ip route

HOL-1803-05-NET
Note: The vPod Router network segments and default route are advertised via both
Perimeter Gateway network addresses. The red arrows above are pointing to the
addresses of both the Perimeter-Gateway-01 and Perimeter-Gateway-02.
Leave this window open for the following steps.
Verify ECMP Functionality from vPod Router
Note: To release your cursor from the window, press Ctrl+Alt keys.
Now we will look at ECMP from the vPod Router, which simulates a physical router in
your network.
1. Click PuTTY icon on the taskbar.
Open SSH Session to vPod Router
1. Enter 192.168.100.1 as the Host Name. 192.168.100.1 is the IP address of vPod

Router.
2. Login as root.

HOL-1803-05-NET
3. Enter VMware1! as password.
Access BGP Module
We must telnet into the module that controls BGP in the vPod Router.
1. Enter telnet localhost 2605.
telnet localhost 2605
2. Enter VMware1! as the password.

HOL-1803-05-NET
Show BGP Neighbors
We must telnet into the module that controls OSPF in the vPod Router.
2. We will see Perimeter-Gateway-01 (192.168.100.3) as a BGP neighbor with

a BGP state of Established, up
Verify Perimeter-Gateway-02 Relationship
1. Scroll down the BGP Neighbors list. We will see Perimeter-Gateway-02

(192.168.100.4) as a BGP neighbor with a BGP state of Established, up

HOL-1803-05-NET
Show Routes
1. Enter show ip bgp.
show ip bgp
2. In this section you notice that all networks have two next hop routers listed, and this
is because Perimeter-Gateway-01 (192.168.100.3) and Perimeter-Gateway-02
(192.168.100.4) are both Established neighbors for these networks.
At this point, any traffic connected to the distributed router can egress out either of the
perimeter gateways with ECMP.
Leave this window open for following steps.

HOL-1803-05-NET
Shutdown Perimeter Gateway 01
We will simulate a node going offline by shutting down Perimeter-Gateway-01.
Return to vSphere Web Client browser tab.
2. Right-click Perimeter-Gateway-01-0.
3. Click Power.
4. Click Shut Down Guest OS.

HOL-1803-05-NET
Confirm Shutdown
1. Click Yes.
Test High Availability with ECMP
With ECMP, BGP, and OSPF in the environment, we are able to dynamically change
routes in the event of a failure in a particular path. We will now simulate one of the
paths going down, and route redistribution occuring.
1. Click Command Prompt icon on the taskbar.
Ping db-01a Database Server
1. Enter ping -t db-01a.
ping -t db-01a

HOL-1803-05-NET
You will see pings from the control center to the database server (db-01a) start.
Leave this window open and running as you go to the next step.
Access Distributed Router VM Console
1. Click Distributed-01-0 browser tab.
Check Current Routes

HOL-1803-05-NET
show ip route
Note: Only the Perimeter-Gateway-02 is now available to acces the vPod Router network
segments.
Leave this window open for the following steps.
Power Up Perimeter Gateway 01
2. Right-click Perimeter-Gateway-01-0.
3. Click Power.
4. Click Power On.

HOL-1803-05-NET
Verify Perimeter-Gateway-01 is Online
It will take a minute or two for the VM to power up. Once it shows the VMTools are online
in the VM Summary, you can move to the next step.
1. Click Refresh icon. This will check for updates on the VMTools status.
Return to Ping Test
• On the taskbar, go back to your command prompt running your ping test.

HOL-1803-05-NET
BGP Neighbor Peering
Although this is not a clear depiction of the fail over from Perimeter-Gateway-02 to
Perimeter-Gateway-01, the ping traffic would migrate from Perimeter-Gateway-02 to
Perimeter-Gateway-01 with minimal impact if the active path went down.
Access Distributed Router VM Console

HOL-1803-05-NET
1. Click Distributed-01-0 browser tab.
Show Routes
Let's check the status of the routes on the Distributed-Router-01 since we powered
Perimeter-Gateway-01 back up.
show ip route
Note: we should now see that all vPod Router networks have returned to dual
connectivity.
Final Note on ECMP
A final note on ECMP and HA in this lab. While we have shutdown Perimeter-
Gateway-01, the result of of doing this on Perimeter-Gateway-02 would be the
same.
The only caveat is that the Customer DB App does not work when Perimeter-
Gateway-01 is offline since the web server VMs are directly connected to it. We could
resolve this by moving the Web-Tier down to the Distributed-Router-01 as you did the

HOL-1803-05-NET
Database and App networks in the Dynamic and Distributed Routing section of this
lab. Once that is complete, the Customer DB App will function if Perimeter Gateway 1 or
2 were offline. It is important to note that performing this migration will break
other modules in this lab! This is the reason it is not done as part of the
manual. If other modules are not going to be attempted, this migration can
be performed without an issue.

HOL-1803-05-NET
Prior to moving on - Please complete

the following cleanup steps
If you plan to continue to any other module in this lab after completing Module 2, you
must complete the following steps or the lab will not function properly going forward.
Delete Second Perimeter Edge Device
1. Click Home icon.


HOL-1803-05-NET
Delete Perimeter-Gateway-02
We need to delete the Perimeter-Gateway-02 that we created.
1. Click NSX Edges.

2. Select Perimeter-Gateway-02.
3. Click red X.
Confirm Delete
1. Click Yes.
Disable ECMP on DLR and Perimeter Gateway-01

HOL-1803-05-NET
Disable ECMP on Distributed Router
1. Click Manage.
2. Click Routing.
4. Click Disable.
Publish Change
1. Click Publish Changes to push the configuration change.

HOL-1803-05-NET

HOL-1803-05-NET
Disable ECMP on Perimeter Gateway 1
1. Click Manage.
2. Click Routing.
4. Click Disable.
Publish Change
1. Click Publish Changes to push the configuration change.

HOL-1803-05-NET
Module 3 Conclusion
In this module, we covered the routing capabilities of NSX Distributed Logical Router and
Edge Services Gateways:
1. Migrated Logical Switches from Edge Services Gateway (ESG) to the Distributed
Logical Router (DLR).
2. Configured the dynamic routing protocol between ESG and DLR.
3. Review the centralized routing capabilities of ESG and dynamic route peering
information.
4. Demonstrated scalability and availablity of ESG by deploying a second ESG and
establishing route peering between the two ESGs via Equal Cost Multipath (ECMP)
route configuration.
5. Removed ESG2 and ECMP route configuration.
You've completed Module 3
If you are keen to learn more about NSX, please visit the NSX 6.3 Documentation Center
via the following URL:
• Go to https://tinyurl.com/y9zy7cpn
Proceed to any of the following modules:
Lab Module List:
preparing hosts.
3-tier application.
integration.

HOL-1803-05-NET
Lab Captains:

Kingdom
How to End Lab
To end your lab, click on the END button.

HOL-1803-05-NET
Module 4 - Service
Composer and Distributed
Firewall Overview (45
minutes)

HOL-1803-05-NET
Distributed Firewall - Micro-

segmentation Overview
NSX Distributed firewall (DFW) 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
and virtual machine names; network constructs like IP or IPSets, VLAN (DVS port-
groups), VXLAN (logical switches), security groups, as well as user group identity from
Active Directory. Firewall rules are enforced at the vNIC level of each virtual machine to
provide consistent access control even when the virtual machine gets vMotioned. The
hypervisor-embedded nature of the firewall 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.
Micro-segmentation is powered by the Distributed Firewall (DFW) component of NSX.

DFW operates at the ESXi hypervisor kernel layer and processes packets at near line-
rate speed. Each VM has its own firewall rules and context. Workload mobility (vMotion)
is fully supported with DFW, and active connections remain intact during the move. This
advance security capability makes the data center network more secure by isolating
each related group of virtual machines onto a distinct logical network segment, allowing
the administrator to firewall traffic traveling from one segment of the data center to
another (east-west traffic). This limits attackers’ ability to move laterally in the data
center.
The outline of this module is:
Distributed Firewall Basic Functionality
• Check the status of the Distributed Firewall on vSphere hosts.

• Verify full open communication to the web application and between the 3-tiers.
• Block access to 3-tier app and verify.
• Create a security group for the web tier.
• Create Firewall rules to allow secure access to the web application.
Improved IP discovery mechanism for Firewall function
• Review existing rule rejecting access to Linux-01a VM

• Enable IP discovery with Arp Snooping
• Verify that the reject rule now takes effect and denies access to Linux-01a VM
Logically apply Security with Service Composer
• Review and create a Security Group for VMs, defined by dynamic membership

HOL-1803-05-NET
• Review, create, and apply a firewall rule to the Security Group via a Security
Policy
• Review the Service Composer Canvas as an interface to show the mapping of
Security Policies to Security Groups
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 user accounts and passwords used for all the virtual devices and
VM's in the lab.
Notice to User about Distributed Firewall - Micro-

segmentation Section
If you have completed HOL-1803-01-NET, Module 6 - Distributed Firewall, then it is

important to note that this section titled, Distributed Firewall in this lab is a repeat of
that module, and is not required to continue on with this lab. If you would like to skip
this section and move to the next section in this lab, we provide a link below to skip
ahead.
Click here to skip to Improved IP Discovery Mechanism for Virtual Machines

and SpoofGuard module
Alternate Methods of Keyboard Data Entry
During this module, you will input text into the Main Console. Besides directly typing it
in, there are two very helpful methods of entering data which make it easier to enter
complex data.

HOL-1803-05-NET
Click and Drag Lab Manual Content Into Console Active

Window
You can also click and drag text and Command Line Interface (CLI) commands directly
from the Lab Manual into the active window in the Main Console.
Access vSphere Web Client
1. Bring up the vSphere Web Client via the icon on the desktop labeled, Google
Chrome.

HOL-1803-05-NET
If you are not already logged into the vSphere Web Client:
(The home page should be the vSphere Web Client. If not, Click on the vSphere Web
Client Taskbar icon for Google Chrome.)

3. Click Login
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.

HOL-1803-05-NET
1. Click on the PuTTY shortcut on the desktop taskbar

2. Select web-01a.corp.local
3. Click on Open
Ping from web-01a to other 3-tier members
First you will show that web-01a can Ping web-02a by entering
ping -c 2 172.16.10.12
Now test connectivity between web-01a to app-01a and db-01a:
ping -c 2 172.16.20.11
ping -c 2 172.16.30.11
(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.

HOL-1803-05-NET
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. Click on the bookmark "Customer DB App"
Demonstrate 3-tier application using a web browser-cont
You should get back data that passed from the web tier to the app-01a vm and finally
queried the db-01a vm.

HOL-1803-05-NET
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.
1. Click the browser tab for the vSphere Web Client.
2. Click Home and select Networking and Security
3. Select Firewall on the left. You will see the Default Section Layer3 on the General
Section.

HOL-1803-05-NET
Examine the Default Rules
1. Expand the section using the drop down arrow
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 on rule 5. This will bring up a pencil sign that allows
you to see the choices for this field.
1. Click on the Pencil icon.

HOL-1803-05-NET
Change the Last Default Rule Action from Allow to Block
Click the drop-down arrow and select the Block action
1. Click Save
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.
1. Select Publish Change to save your block rule.

HOL-1803-05-NET
Verify the Rule change blocks communication
To test the block rule using your previous Putty and browser sessions
• Putty: In a few moments opening Putty will show it is no longer active due to the
default rule now blocks everything including SSH. Minimize the console again.

HOL-1803-05-NET
Verify the Rule blocks https using Web Browser
1. Open the tab for the Customer DB App

2. Refresh your browser. You will get an error.
3. Click the browser tab for vSphere Web client.

HOL-1803-05-NET
Create 3-Tier Security Groups
1. Click on 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. One of those objects for repeatable use is a Security Group. We
will cover Service Composer and Security Groups in depth in a later the module, called
"Service Compose and DFW Overview."

HOL-1803-05-NET
Add Security Group
1. Select Security Groups. Note: there may be 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
1. Name this first group "Web-tier"

2. Click the "Select objects to include" section

HOL-1803-05-NET
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-01a
4. Click the Right Hand arrow to push the VM to the Selected Objects window
5. Repeat for web-02a
6. 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.

HOL-1803-05-NET
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.
1. On the left hand menu, select Firewall.

HOL-1803-05-NET
Create New Firewall Section
1. On the far right of the "Flow Monitoring & Trace Flow Rules-Disabled by Default
(Rule 1)" row click on Add Section which looks like a folder
Add New Rule Section for 3-Tier Application
1. Name the section "3-tier App"

2. Select Add above
3. Click Save
Add Rule to New Section
1. On the row for the new "3-tier App" section click on the Add rule icon which is a
green plus-sign.

HOL-1803-05-NET
Edit New Rule name
1. Click the Drop down arrow to open the rule

2. Hover to the upper right corner of the "Name" field until a pencil icon appears,
then click on the pencil
Edit New Rule name cont
1. Enter "Ext to Web" for the name

2. Click Save
Set Rule Source and Destination
Source: Leave the Rule Source set to any.
1. Hover the mouse pointer in the Destination field and select the Destination
pencil sign.

HOL-1803-05-NET
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
Edit Service
1. Again hover in the Service field and click on the pencil sign.

HOL-1803-05-NET
Set Rule Service
In the search field you can search for service pattern matches.
1. 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 1-3 to find and add 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 yet, as you have more rules to make.

HOL-1803-05-NET
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 pencil sign beside rule ID 1

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 pencil.
Enter "Web to App" for the name
2. Choose Web-tier Security Group for the Source field

HOL-1803-05-NET
Create Second Rule Destination
1. Hover over the Destination Field

2. Click the pencil to edit.
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

HOL-1803-05-NET
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 Logical Switch choice
2. Select App_Tier-Logical_Switch
3. Click on the top arrow to move the object to the right
4. Click OK
Create Second Rule Service
1. Hover over the Service Field and click the pencil to edit.

HOL-1803-05-NET
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

HOL-1803-05-NET
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 below your last rule to
give access between the App Tier Logical Switch and the DB Tier Logical Switch.
1. Create the final rule allowing the App Logical Switch to communicate
with the Database Logical Switch via the HTTP service.

HOL-1803-05-NET
Your new rule should look like the one listed in the example.
2. Publish Changes
Verify New Rule Allow 3-Tier Application Communication
1. Return to the tab you used previously for the Web App.
2. Refresh the browser to show you are getting the data via the 3-tier app.
Your new "3-tier App" section allows access to the application.

HOL-1803-05-NET
Restart Putty Session to web-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.

HOL-1803-05-NET
Note: Remember to use the Click and Drag feature.
web-02a
ping -c 2 172.16.10.12
app-01a
ping -c 2 172.16.20.11
db-01a
ping -c 2 172.16.30.11
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.
• Minimize Putty Session to web-01a.

HOL-1803-05-NET
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.

HOL-1803-05-NET
Module Clean Up
You will need to set the Default Rule back to Allow to proceed to the next Module.
1. Change the Default Rule Action back to Allow.

2. Publish Changes.

HOL-1803-05-NET
Improved IP Discovery Mechanism for

Virtual Machines and SpoofGuard
After synchronizing with the vCenter Server, NSX Manager collects the IP addresses of
all vCenter guest virtual machines. If a virtual machine has been compromised, the IP
address can be spoofed and malicious transmissions can bypass firewall policies.
You create a SpoofGuard policy for specific networks that allows you to authorize the IP
addresses reported and alter them if necessary to prevent spoofing. SpoofGuard
inherently trusts the MAC addresses of virtual machines collected from the VMX files
and vSphere SDK. Operating separately from Firewall rules, you can use SpoofGuard to
block traffic determined to be spoofed.
SpoofGuard supports both IPv4 and IPv6 addresses. When using IPv4, the SpoofGuard
policy supports a single IP address assigned to a vNIC. IPv6 supports multiple IP
addresses assigned to a vNIC. The SpoofGuard policy monitors and manages the IP
addresses reported by your virtual machines in one of the following modes:
• Automatically Trust IP Assignments On Their First Use
This mode allows all traffic from your virtual machines to pass while building a table of
vNIC-to-IP address assignments. We can review this table at our convenience and make
IP address changes. This mode automatically approves all ipv4 and ipv6 address on a
vNIC.
• Manually Inspect and Approve All IP Assignments Before Use
This mode blocks all traffic until there is an approval each vNIC-to-IP address
assignment.
Note: SpoofGuard inherently allows DHCP requests regardless of enabled

mode. However, if in manual inspection mode, traffic does not pass until the
DHCP-assigned IP address has been approved.
SpoofGuard includes a system-generated default policy that applies to port groups and
logical networks not covered by the other SpoofGuard policies. A newly added network
is automatically added to the default policy until the administrator adds the network to
an existing policy or creates a new policy for it.
NSX distributed firewall operation requires discovery of IP addressees for objects that
are specified as a source or a destination. Prior to NSX 6.2, this was achieved by
VMtools inside the VM. This exercise will show you how to discover IP addresses with
VMtools and Trust-On-First-Use.

HOL-1803-05-NET
Review SpoofGuard Settings
Click on the browser tab for the vSphere Web Client
1. Click the Home Icon

2. Click Networking & Security
Explore SpoofGuard

HOL-1803-05-NET
1. Click SpoofGuard in the Navigator
Enable IP address discovery via ARP Snooping
1. Click Change
Change IP detection type to ARP Snooping
Now we will enable IP address discovery with "ARP Snooping"
1. Check ARP Snooping

2. Click OK

HOL-1803-05-NET
Edit Default SpoofGuard Policy
1. Click on Default Policy

2. Click on Pencil to edit
Enable SpoofGuard
1. Click the Radio button for Enabled

HOL-1803-05-NET
2. Click Finish
Migrate Linux-01a from vDS to a new Logical Switch
First, we must migrate the linux-01a VM from its existing vDS to a Logical Switch to
leverage SpoofGuard IP Discovery capabilities.
Navigate to Logical Switches
1. Click the Logical Switches section

2. Click the Green plus icon to create a new Logical Switch

HOL-1803-05-NET
Name the New Logical Switch
1. Name the Logical Switch, "Linux_Logical_Switch"

2. Click OK to continue.

HOL-1803-05-NET
Add Virtual Machines to the Logical Switch
1. To add virtual machines, we will right-click the Linux_Logical_Switch

2. Select the Add VM option

HOL-1803-05-NET
Select the Virtual Machine to Migrate
1. Enter "linux" into the Filter

2. Select the linux-01a VM
3. Click the Blue arrow to add the linux-01a VM to the Selected Objects list
4. Click Next

HOL-1803-05-NET
Select vNIC to Migrate to new Logical Switch
1. Check the box for the linux-01a vNIC to migrate to the Logical Switch
2. Click Next

HOL-1803-05-NET
Finish Migration of VMs to Collapsed Logical Switch
1. Click Finish to complete the migration of the linux-01a VM to the new

Linux_Logical_Switch.
Access the Logical Switch

HOL-1803-05-NET
1. Double-click the new Linux_Logical_Switch to view the associated virtual

machines.
View Related Virtual Machines
1. Click the Virtual Machines section

2. Verify the linux-01a VM is listed
Open Console to linux-01a VM

HOL-1803-05-NET
1. Select the linux-01a VM

2. Click Gear Icon
3. Select Launch Remote Console
Enter Username and Password to linux-01a
Remember you can use the "click and drag" feature to copy CLI commands into the
active window
1. Enter "root" at the login prompt

2. Enter "VMware1!" at the password prompt
Verify IP Configuration
1. Enter "ifconfig" in the command line

HOL-1803-05-NET
ifconfig
Note: the IP address of the linux-01a VM is 192.168.120.115.
Test Network Connectivity
1. Enter "ping -c 2 192.168.120.1" to initiate a ping test to an assumed default

gateway
ping -c 2 192.168.120.1
Note: the ping test in this step will fail because we have not connected the
Linux_Logical_Switch to an NSX Edge to provide routing. We only want to
initiate traffic from the VM in order for SpoofGuard to identify this VM.
Exit the Remote Console
1. Press Control+Alt to move your cursor out of the Remote Console Window
2. Return to the vSphere Web Client browser tab by clicking on it
Navigate back to Networking & Security

HOL-1803-05-NET
1. Under the Navigator, click the Back buton in the history field until you get back
to to the NSX configuration interface.
Verify that Linux-01a was discovered via ARP Snooping
1. Select SpoofGuard from the Navigator menu

2. Click on Default Policy
3. Pick Active Virtual NICs in the View dropdown
4. Enter "lin" and press enter to filter for linux-01a
Notice that the Source Field denotes TOFUARP (Trust On First Use ARP) for the address
192.168.120.115.
Approve Linux-01a new IP Address
• Click Approve
Note: we may have to scroll to the right to view the Approve action

HOL-1803-05-NET
Publish IP Approval
• Click on Publish Changes
View Active Virtual NICs Since Last Published
1. Select Active Virtual NICs Since Last Published from the drop down menu
Note: linux-01a is no longer listed because we have approved the IP address for use by
that VM, and no activity has originated from the VM since the approval.
SpoofGuard Wrap Up
This concludes the section on Improved IP Discovery Mechanism for Virtual Machines
and SpoofGuard. We have successfully migrated a VM into the NSX environment, and
leveraged SpoofGuard to learn the IP address of the VM with the new Trust-On-First-Use
ARP feature.

HOL-1803-05-NET
Security Groups Overview

We will now build upon the Security Group capabilities we discovered in the Distributed
Firewall - Micro-segmentation Overview. NSX Security Groups are a way to logically
group and define assets that you want to protect. Security groups may be static
(including specific virtual machines) or dynamic where membership may be defined in
one or more of the following ways:
• vCenter containers (clusters, port groups, or datacenters)

• Security tags, IPset, MACset, or even other security groups. For example, you
may include a criteria to add all members tagged with the specified security tag
(such as AntiVirus.virusFound) to the security group
• Directory Groups (if NSX Manager is registered with Active Directory)
• Regular expressions such as virtual machines with name VM1
Note that security group membership changes constantly. For example, a virtual
machine tagged with the AntiVirus.virusFound tag is moved into the Quarantine security
group. When the virus is cleaned and this tag is removed from the virtual machine, it
again moves out of the Quarantine security group.
Access the Service Composer
1. Click the Service Composer on the left panel.

HOL-1803-05-NET
Create the Web Security Group
1. Click the Security Groups tab in Services Composer.

2. Click the New Security Group icon.
3. Enter "Web Security Group" in the Name diaglog box.
4. Click Next.

HOL-1803-05-NET
Explore Object List
1. Open the Object Drop Down box.
You will see that you can use Computer OS Name, Computer Name, VM Name, Security
Tag, or Entity. Entity allows you to pick from many elements of the vCenter including
Resource Pool, Directory Domain Group, Logical Switches, Distributed Port Group and
many more.
Explore Object member criteria list

HOL-1803-05-NET
The Criteria choices will vary depending on the Object Type chosen.
Define Dynamic Membership
1. Select VM Name from the first Criteria Details drop down list.
2. Verify Contains is selected in the middle drop down of the page.
3. Enter "web" in the dialog box.
4. Click Finish.

HOL-1803-05-NET
View Membership
1. Click the number in the Virtual Machine column associated with the new Web
Security Group.
Note: There should 6 in the Virtual Machine column for the Web Security Group,
including all VMs with "WEB" in their name, without consideration for capitalization, or IP
networks.
2. Click the X in the upper right hand corner of the dialog box to close it.

HOL-1803-05-NET
Security Policy Overview

NSX Security Policies can be a collection of the following service configurations, Firewall
rules, Endpoint services, Network introspection services. Firewall rules can consist of
rules that define the traffic to be allowed to, from, or within the security group.
Endpoint services can implemented via third party solution provider services such as
anti-virus or vulnerability management services. Network introspection services are
services that monitor your network such as IPS.
During service deployment in NSX, the third party vendor selects the service category
for the service being deployed. A default service profile is created for each vendor
template.
Note When you have many security groups to which you need to attach the same
security policy, create an umbrella security group that includes all these child security
groups, and apply the common security policy to the umbrella security group. This will
ensure that the NSX distributed firewall utilizes ESXi host memory efficiently.
Create a New Security Policy
1. Select the Security Policies tab in the Service Composer panel

2. Click the Create Security Policy icon
3. Type in "Block Web-to-Web Traffic" in the Name field
4. Click Firewall Rules in the left panel

HOL-1803-05-NET
Create a New Firewall Rule
1. Click the Green Plus icon to add a New Firewall Rule

2. Type in "Block Web-to-Web Traffic" in the Name field
3. Select Block from the Action list
4. Click Change... to the right of the Destination: Any

HOL-1803-05-NET
Firewall Rule - Select Destination
1. Select Policy's Security Group at the top of the list of options

2. Click OK
Note: we are going to apply this Security Policy to the Policy's Security Group,
which is now defined as the Source and Destination for our Firewall rule.  

HOL-1803-05-NET
Click OK
1. Click OK

HOL-1803-05-NET
Finish Security Policy Definition
1. Click Finish

HOL-1803-05-NET
Apply the Security Policy to a Security Group
1. Highlight the Block Web-to-Web Traffic security policy

2. Click the Apply Security Policy icon
3. Select the Web Security Group
4. Click OK

HOL-1803-05-NET
Verify Security Policy Application
1. Verify the Sync Status column changed to Published

2. Verify the Applied to have a 1 in the column
3. Verify the Firewall Rules have a 1 in the column
This information verifies that our rules have successfully synced with the Firewall rules
in NSX, and are being correctly applied to the Security Groups
Verify Firewall Rule Synchronization

HOL-1803-05-NET
1. Click on Firewall
View Service Composer Firewall rules
1. Expand the firewall section "Block Web-to-Web Traffic" and verify the
rules creation

HOL-1803-05-NET
Test Web VM to Web VM connectivity using Putty
Next we will test communication and access between the Web VMs making up the 3-tier
application. Our first test will be to open a console to web-01a and ping web-02a.
1. Click on the PuTTY shortcut on the desktop taskbar

2. Select web-01a.corp.local
3. Click on Open
Ping from web-01a to web-02a
We will show that web-01a cannot ping web-02a by entering.

HOL-1803-05-NET
1. Ping web-02a.
ping -c 2 web-02a
Pings will fail between the Web VMs per the Security Policy.

HOL-1803-05-NET
Review of Service Composer Canvas

Service Composer offers a canvas view displaying all security groups within the selected
NSX Manager. The view also displays details such as members of each security group as
well as the security policy applied on it.
This topic introduces Service Composer by walking you through a partially configured
system so that you can visualize the mappings between security groups and security
policy objects at a high level from the canvas view.
Graphical View of Service Composer Canvas
1. Click Service Composer

2. Click Canvas
All security groups within the selected NSX Manager (that are not contained within
another security group) are displayed along with the policies applied on them. The NSX
Manager drop-down lists all NSX Managers on which the currently logged in user has a
role assigned.
Each rectangular box in the canvas represents a security group and the icons within the
box represent security group members and details about the security policy mapped to
the security group.

HOL-1803-05-NET
Applied Security Policy
A number next to each icon indicates the number of instances - for example, the
number 1 next to the Security Policy icon indicates that a policy is mapped to that
Security Group
Nested Security Groups
This icon Security Groups nested within the main security group. In your Security
Group there are no nested groups.

HOL-1803-05-NET
Effective Virtual Machine Membership
1. Click the Virtual Machine icon in the bottom left hand corner of the Canvas.
2. Close the window.
Virtual machines that are currently part of the main security group as well as nested
security groups. If we had any virtual machines with services errors, we could click on
the the Errors tab to see those virtual machines.

HOL-1803-05-NET
Effective Security Policies mapped to the Security Group
1. Click the Security Policy icon in the top right hand corner of the Canvas.
Optional Actions:
• You can create a new security policy by clicking the Create Security Policy
icon. The newly created security policy object is automatically mapped to the
security group.
• Map additional security policies to the security group by clicking the Apply
Security Policy icon.
Effective Guest Introspection services
1. Click Guest Introspection Services icon to display services associated with

the security policy mapped to the security group.

HOL-1803-05-NET
Suppose you have two policies applied to a security group and both have the same
category Endpoint service configured. The effective service count in this case will be 1
(since the second lower priority service is overridden).
Note: Guest Introspection Service failures, if any, are indicated in the Errors tab.
Clicking the Errors icon displays the issues.
2. Close the Window.
Effective Firewall rules
1. Click the Firewall rules icon to display firewall rules associated with the
security policy mapped to the security group.

HOL-1803-05-NET
Effective Network Introspection services
1. Click the Network Introspection Services icon to display the services

associated with the security policy mapped to the security group.
Note: Again, Network Introspection Service failures, if any, are indicated in the Errors
tab. Clicking the Errors icon displays the issues.
Search Security Groups
1. Enter "hr" in the search field in the top right corner of the Canvas window to
display only the security groups with "hr" in their names.

HOL-1803-05-NET
View Security Group Hierarchy
1. Click the Top Level icon at the top left of the window
2. Click the Internal Services
This will allow us to see the security group hierarchy, and if a security group contains
nested security groups
View Parent Security Group services
The top bar displays the name of the parent security group and the icons in the bar
display the total number of security policies, endpoint services, firewall services, and
network introspection services applicable to the parent group.

HOL-1803-05-NET
1. We can navigate back up to the top level by clicking the blue Go up one level
arrow icon in the top left part of the window.
Smooth Zoom In and Out of Canvas View
You can zoom in and out of the canvas view smoothly by moving the zoom slider on the
top right corner of the window. The Navigator box shows a zoomed out view of the
entire canvas. If the canvas is much bigger than what fits on your screen, it will show a
box around the area that is actually visible and you can move it to change the section of
the canvas that is being displayed.

HOL-1803-05-NET
Module 4 - Conclusion
This now completes Module 4 on Service Composer and Distributed Firewall. We have
created both static and dynamic Security Groups, applied both static and dynamic
Security Policies, including firewall rules, and used SpoofGuard to discover and allow
VMs on to the network that are not running VMTools.
Module 4 Clean Up
Prior to finishing Module 4, you need to remove the rule that was created during this
section.
1. Navigate back to Service Composer

2. Select Security Policies tab
3. Right-click on Block Web-to-Web Traffic row
4. Select the Delete option. When prompted "Remove security policy?", click Yes

HOL-1803-05-NET
You've finished Module 4
If you are looking for additional information on NSX Routing capabilities and
configuration, then please review the NSX 6.3 Documentation Center via the URL below:
• Go to https://tinyurl.com/zwch3gh
Proceed to any module below which interests you the most:
Lab Module List:
preparing hosts.
3-tier application.
integration.
Lab Captains:

Kingdom

HOL-1803-05-NET
How to End Lab
To end your lab click on the END button.

HOL-1803-05-NET
Module 5 - Intelligent
Grouping (30 minutes)

HOL-1803-05-NET
Intelligent Grouping
Module 3 Intelligent Grouping
Introduction
The End of Support (EOS) of major enterprise platforms like Windows XP, Windows
2000 Server, and Windows Server 2003 are a major challenge for organizations running
mission-critical applications necessary for day-to-day business. For example, in July
2015, when Microsoft ended support for Windows 2003, it put millions of enterprise
servers at risk.
Organizations using an Operating Systems that is EOS likely introduced serious security
risks into their environments, unless they are fully prepared to migrate to a new
platform or put compensating controls in place. Hackers know that platform providers
like Microsoft will no longer acknowledge or patch vulnerabilities, so these systems
quickly become a favorite target for attacks, and the risks of running an unsupported
platform after EOS will increase over time as more issues are found and not patched.
NSX can help mitigate the issue of EOS Operating Systems by providing additional
security via the Distributed FireWall (DFW) and Service Composer. In this lab you will use
NSX Security Groups to corral windows XP VMs and provide firewall polices to protect
them in a simulated environment.
The outline of this module is:
• Create Security Group For Windows XP VM.

• Use Dynamic Inclusion to automatically group Windows XP VM.
• Apply Firewall rules to provide protection of Windows XP VM.
• Test Windows XP VM access to external networks.
Lab Captain:
Module 3 - Chris Cousins, Sr. Systems Engineer, United States.

HOL-1803-05-NET
Log on to the End of Support Virtual

Machines
Using Windows XP VMs we will determine the current security access to external and
internal resources.

3. Click Login
1. Clicking on the Push-Pins will allow task panes to collapse and provide more
viewing space to the main pane. You can also collapse the left-hand pane to gain
the maximum space.

HOL-1803-05-NET
Log on to EOS Virtual Machines
1. Select Home
2. Select VMs and Templates

HOL-1803-05-NET
Launch the VM console for win-xp-01
1. Select win-xp-01.corp.local.
2. Select the Summary tab.
3. Click to launch the console.
Wake up win-xp-01 desktop
Click to wake desktop
1. Click Send Ctrl+Alt+Delete button to log in.

HOL-1803-05-NET
Log on to win-xp-01 desktop
login Creditials
1. User name: Administrator.

2. Password: VMware1!
3. Click OK

HOL-1803-05-NET
Verify Internal Access
Launch Mozilla Browser from desktop.
1. Click Customer DB-App link to launch internal application.

HOL-1803-05-NET
Internal application launches.
We see the Windows XP VM has full access to our internal applications. This is the
desired security posture.

HOL-1803-05-NET
Open Command Prompt for External Access
The control console VM exists outside of the virtual environment we are using for this
lab. As such it represents a service external to our environment. We will use the control
center IP address 192.168.110.10 to represent Internet services.
1. Click Start menu.

2. Launch Command prompt.
If “Command Prompt” icon not shown. Click “Run” and type “cmd” and press
Enter to bring up the Command Prompt”

HOL-1803-05-NET
Verify External Access
First you will show that win-xp-01 can reach the external network by pinging a vm
external to the defined virtual datacenter. In this case you will use the address of the
Main Console (192.168.110.10). This represents the Internet.
ping 192.168.110.10
As you can see as illustrated by the ping we can reach External Services. This creates a
large potential security concern for VMs running End of Support Operating Systems.

HOL-1803-05-NET
Security Group Creation

Now that we see the potential vulnerability of allowing end of support VMs to access
external resources we want to find a way to secure them. We will use Security Groups in
NSX to quickly identify machines running EOS OSes and secure them using policy
enforcement.
Create Security Group
1. Click the vSphere Web Client browser tab.

2. Click the HOME icon.
3. Select Networking & Security.

HOL-1803-05-NET
Launch Service Composer
1. Click on Service Composer.

HOL-1803-05-NET
Create Security Group
1. Select the Security Groups Tab.

2. Click New Security Group.

HOL-1803-05-NET
New Security Group
1. Name type: Windows XP EOS.

2. Click Next.

HOL-1803-05-NET
Define Dynamic membership
1. Select Computer OS Name.

2. Select Contains.
3. Enter Windows XP.
4. Click Finish.

HOL-1803-05-NET
Verify Security Group Membership
The Security Group has been created and has Dynamically included the windows XP VM.
Move your mouse of over the Virtual Machines column. It should indicate 1.
1. Click the number "1" to display the name of the VM in the Security Group.
2. Click the "X" to close the window.

HOL-1803-05-NET
Limit VM Access
We will now apply rules to limit VM external access.
Apply Policy
Go to Service Composer.
1. Select the "Windows XP EOS" Security Group we created previously.

2. Click the "Apply Policy" icon.

HOL-1803-05-NET
New Security Policy
1. Click New Security Policy
Create security policy
1. Type Name: Security Policy Internal Only Access.

2. Click Firewall Rules.

HOL-1803-05-NET
Creating Firewall Rules
1. Click New Firewall Rule.

HOL-1803-05-NET
Configure 1st Firewall Rule
1. Name: Access Internal Resources

2. Action : Allow
3. Source: Policy's Security Group
4. Destination: Click Change

HOL-1803-05-NET
Select Destination
In order to make this Lab easier to configure the Internal Services Security Group was
premade and contains VMs that are apart of the internal applications. We are creating
rules that will allow the EOS XP VMs to access these Internal Services but not to access
external services(i.e the internet).
1. Select: "Select Security Groups".

2. Select: Internal Services.
3. Click OK.

HOL-1803-05-NET
Verify Firewall rule settings
Verify settings:
Service: Any
State: Enabled
Log: Do not log
1. Click OK.

HOL-1803-05-NET
Verify Firewall Rule
1. Click Finish.

HOL-1803-05-NET
Add Additional Firewall Rule
We have created a Security Group to allow Windows XP VM to access the Internal

Services (internal Applications). However we still need to Add an additional rule to allow
access between internal services as well as modifying the Default firewall rule to block
all other access including External access.
1. Click Firewall to access the firewall rules.

HOL-1803-05-NET
Edit Section Name
On the Firewall configuration tab.
1. Click the Add Section icon on the Flow Monitoring Rule section
2. Type "Internal Services to Internal Services" as the Section Name
3. Verify Add section Below is selected
4. Click Save
Publish Changes
1. Click Publish Changes.

HOL-1803-05-NET
Add rules to the New Section
1. Click Add Rule.

2. Click to expand the rules section.
Edit Firewall Rule Name
1. Hover and Click the Pencil Icon to Edit the Firewall Name.
2. Type the rule name: App to App.
3. Click Save.

HOL-1803-05-NET
Select the Source.
1. Click the pencil Icon in the Source column.

2. Select Security Group as the Object Type.
3. Select the Internal Services security group.
4. Click the arrow to add it to Selected Objects.
5. Click Ok.

HOL-1803-05-NET
Select the Destination
1. Click the pencil Icon in the Destination column.

3. Select the Internal Services security group.
5. Click Ok.

HOL-1803-05-NET
Our new firewall rule will allow our internal application to communicate between
Application Tiers.
Verify the Source security group is Internal Services
Verify the Destination security group is Internal Services
Verify Action Allow
Modify Default Firewall Rule

HOL-1803-05-NET
In order to block any unwanted traffic including traffic to external services from the
Windows XP EOS VMs we need to enable blocking on the default firewall rule. The
default firewall rule is in the default firewall section.
1. Click to expand the Default Firewall Rule section.

2. Click the Pencil Icon on the Action Column of the Default Rule.
3. Select Block as the action.
4. Click Save.
Publish Changes

HOL-1803-05-NET
Verify Limited Access from Windows

XP VMs
We now have rules in place for the EOS windows XP VMs. We can proceed with testing
access to internal and external services.
Reopen Console to win-xp-01a
1. Click the browser tab for "win-xp-01a".

HOL-1803-05-NET
Verify Internal Services are Allowed
1. Refresh your browser tab for "Customer DB-App".
You will see that the page is refreshed. This is allowed by your firewall rule between
Internal Services.

HOL-1803-05-NET
Verify External Access is Blocked
1. Reopen the Command Prompt on the win-xp-01a desktop.

2. In the Command Prompt, enter: ping 192.168.110.10
3. Verify that external access to the Control Center is now blocked.
ping 192.168.110.10
Now we can see that win-xp-01a has access to internal services, but its external access
has been completely blocked per the Group Policy.

HOL-1803-05-NET
Module Clean-Up: Set Default Rule to Allow
1. Expand the Default Section Layer3.

2. Hover and Click the pencil on the Action column of the Default Rule.
3. Select the Allow Action.
4. Click Save.
Publish Changes
1. Publish Changes.

HOL-1803-05-NET
Module 5 Conclusion
In the lab we have seen how using intelligent grouping can quickly containerize End of
Support Operating Systems via security groups. Once security groups are in place we
can use them to create firewall rules that can both limit access to and from the virtual
machines contained within. The Security Groups are a versatile tool and can be reused
to change or create new policies as our security requirements evolve.
If you are looking for additional information on NSX Security Groups capabilities and
configuration, then please review the NSX 6.3 Documentation Center via the URL below:
Lab Module List:
preparing hosts.
3-tier application.
integration.
Lab Captains:

Kingdom

HOL-1803-05-NET
How to End Lab
To end the lab click on the END button.

HOL-1803-05-NET
Module 6 - User Based

Security with a Jump Box
(45 minutes)

HOL-1803-05-NET
User Based Security in a Jump Box

Scenario
Module 4
User Based Security in a Jump Box Scenario.
Introduction
In this Lab Module you will create firewall rules using the NSX Identity Based Firewall
feature. This feature uses a connection to Active Directory from the NSX manager. The
NSX manager scans the event log of the AD Server to determine log on credentials and
events. Users logging on to VMs can have their VMs instantly assigned to Security
Groups based on their AD groups. The Security Groups combined with firewall rules
allow us to control access within our environment.
This lab uses two different Active Directory groups and two different users. The first
user, a network administrator who should be able to get to any application in the
environment and a Human Resources administrator who should only have access to a
specific HR web based application.
This is the outline for this module:
• Configure NSX link to Active Directory.

• Create Security Groups Based on AD Groups.
• Add Application Rules for Internal Applications.
• Verify and Test AD Based Rules.
Lab Captain:
Module 4 Chris Cousins, Sr. Systems Engineer, United States.

HOL-1803-05-NET
Explore Link between NSX and Active

Directory
NSX links with Active Directory to use AD groups to provide identity based firewall rules.
Launch Browser and vSphere Web Client
• Double click on Chrome icon on the desktop.

HOL-1803-05-NET

3. Click Login
Explore Link between NSX and Active Directory
1. Click on Home icon

2. Click on Networking & Security

HOL-1803-05-NET
Select NSX Manager
On the left go down to the NSX Managers. Notice it denotes only one.
1. Click on NSX Managers.
Choose NSX Manager

HOL-1803-05-NET
1. Click on 192.168.110.42.
Explore Domain Connector
1. Click on Manage tab.

2. Click on Domains tab.
3. Click on corp.local.
4. Click on Pencil to edit.
Notice that the table has an entry. This is partially-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.

HOL-1803-05-NET
Provide NetBIOS Name
For the name field you would enter a name. You would next enter the NetBIOS name
for the domain.
1. Click Next

HOL-1803-05-NET
Provide LDAP Options
Here you will complete the configuration.
1. Enter VMware1! for the password.

2. Click Next.

HOL-1803-05-NET
Security Event Log Access Options
Here you would enter settings for the log access.
1. Uncheck the Use Domain Credentials box

2. Enter administrator and VMware1! for the Credentials
3. Click Next

HOL-1803-05-NET
Ready to Complete - Verify Settings
Now you would verify all your settings.
1. Click Finish.
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.
Note this may take 2-3 minutes to succeed.

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

HOL-1803-05-NET
Use Security Objects based on AD

Groups
1. Security Objects are defined to based on AD group membership and will be used
to enforce security policy.
Create a Security Object based on AD Groups
1. Hover the mouse over the Home Button.

2. Click on Networking & Security.
Create New Firewall Rule Section
1. Click the Firewall link on the navigation pane.

2. Click the "Add Section" icon on the "Flow Monitoring & Traceflow Rule
section"

HOL-1803-05-NET
AD-Group Firewall Rule Section
1. Name the new section AD Based Firewall Rules.

2. Verify Add section below is selected.
3. Click Save.
Add Rule Net-Admin
1. Click the Add rule icon on the newly created rule section.
2. Click to Expand the newly created rule section.
3. Click the pencil Icon on the Name column to edit the new rule.
Name Rule
1. Type name: Network Admin Access

HOL-1803-05-NET
2. Click Save.
Edit Source
You are going to add a Domain Group to the Source field of the Network Admin rule.
1. Hover on to source field and click on the pencil sign.

2. Select Security Group in the Object Type pull-down.
3. Click on New Security Group.

HOL-1803-05-NET
Name New Security Group - Net-Admin
1. Enter Net-Admin for the name.

2. Click on Define Dynamic membership.
1. Select "Entity" from the drop-down

2. Select "Belongs to"
3. Click to open "Select Entity" window

HOL-1803-05-NET
Choose AD Group
1. Select type "Directory Group".

2. Type "app" in search box.
3. Select "AppConfiguration".
4. Click on "OK".

HOL-1803-05-NET
Complete AD Group
1. Click Finish.

HOL-1803-05-NET
Verify Security Group Selection
1. Click OK
Edit Rule Destination
1. Hover and Click Pencil Icon in the Destination Column of the new created rule.

HOL-1803-05-NET
Select the Internal Services Security Group
1. Select Security Group from the Object type Pull down menu.
2. Select the pre-created Internal Services security group.
3. Click the Right-arrow icon to add it to the Selected Objects.
4. Click OK.
The "Internal Services" security group is made up of all the VMs in the internal
environment. This rule will allows the admin to connect to any application and or any
VM in the internal environment.
Verify Rule Settings.
The new rule should Allow Net-Admin (AppConfiguration AD group members) to

access Internal Services( all internal applications) using Any Service.

HOL-1803-05-NET
Add Rule HR-Admin
1. Click to Expand the AD based Rule section

2. Click the Add Rule icon.
Name Rule
1. Hover and Click the Pencil icon in the Name column of the newly created rule.
2. Rule Name type: Human Resources Access.
3. Click Save.

HOL-1803-05-NET
Edit Source
You are going to add a Domain Group to the Source field of the HR Admin rule.
1. Hover on to source field and click on the pencil sign

2. Select Security Group in the Object Type pull-down
3. Click on New Security Group
Name New Security Group - HR-Admin
1. Enter HR-Admin for the name.

2. Click on Define Dynamic membership.

HOL-1803-05-NET
1. Select "Entity" from the drop-down

2. Select "Belongs to"
3. Click to open "Select Entity" window
Choose Directory Group
1. Select Type "Directory Group"

2. Type "Hr" in search box
3. Select "HResources"

HOL-1803-05-NET
4. Click on "OK"
Complete Security Group Creation
1. Click on "Finish".

HOL-1803-05-NET
Verify Security Group Selection
1. Click OK.
Edit Rule Destination
1. Hover and Click Pencil Icon in the Destination Column of the new created
rule.

HOL-1803-05-NET
Define Destination selection
HR Admins should only have access to the HR web application.
1. Select Virtual Machine from the Object type Pull down menu.
2. Enter "web" in search field.
3. Select hr-web-01a from the Available Objects window.
4. Click the arrow icon to add it to the Selected Objects.
5. Click OK.
Define Service

HOL-1803-05-NET
1. Hover and Click the pencil to edit Service.
Limit the Allowed services.
HR Admins should only have access to the applications via web access. (HTTP and
HTTPS)
1. Select Service from the Object type Pull down menu.

2. Type http in to the search window.
3. Select HTTP and HTTPS from the Available Objects window.
4. Click the arrow icon to add it to the Selected Objects.
5. Click OK.

HOL-1803-05-NET
Verify Rule Settings.
The new rule should Allow HR-Admin (Human Recources AD group members) to
access the HR and Web Applications using HTTP and HTTPS Services.

HOL-1803-05-NET
Define Internal Application Firewall

Rules
Internal applications in this lab will require additional rules to allow for communication
between application tiers.
Add Additional Firewall Rule
We have created a AD based firewall rules to allow HR admins and Net admins to access
the appropriate applications based on there role. However we still need to Add an
additional rule to allow access between internal services as well as modifying the
Default firewall rule to block all other access including External access.
1. Click Firewall to access the firewall rules.

HOL-1803-05-NET
Edit Section Name
On the Firewall configuration tab.
1. Click the Add Section icon on the "Flow Monitoring & Traceflow Rule
Section"
2. Type "Internal Services to Internal Services" as the Section Name
3. Verify Add section Below is selected
4. Click Save
Publish Changes
Add rules to the New Section
1. Click Add Rule.

2. Click to expand the rules section.

HOL-1803-05-NET
Edit Firewall Rule Name
1. Click the Pencil Icon to Edit the Firewall Name

2. Type the rule name: App to App
3. Click Save.
Select the Source.

HOL-1803-05-NET
1. Click the "pencil" Icon in the Source column.

3. Select the "Internal Sevices" security group.
5. Click Ok.
Select the Destination
1. Click the "pencil" Icon in the Destination column.

3. Select the "Internal Sevices" security group.
5. Click Ok.

HOL-1803-05-NET
Our new firewall rule will allow our internal application to communicate between
Application Tiers.
1. Verify the Source and Destination are security group " Internal Services"
2. Verify Action Allow
3. Click Publish Changes
Modify Default Firewall Rule
In order to block any unwanted traffic we need to enable blocking on the default firewall
rule. The default firewall rule is in the default firewall section.
1. Click to expand the Default Firewall Rule section.

2. Click the Pencil Icon on the Action column of the Default Rule.
3. Select Block as the action.
4. Click Save.

HOL-1803-05-NET
Publish Changes

HOL-1803-05-NET
Testing User Identity Based Rules

In order to test the newly created rules we must log on to the win12-jump VM with
different user AD credentials.
Test User Identity Rule
You can test the new Identity based rules by opening a console to the Jump Box
(win-12-jump) VM in the domain and logging in as a member of the Active Directory
AppConfiguration group or the Human Resources group. User Netadmin is a member
of the AppConfiguration group and therefore can login into any internal application or
application teir. User HRadmin is a member of the Human Resources group and can
only login into HR web application and the Financial web application. You will login as
each and see the results of trying to access the multiple 3-tier applications.
1. Clicking on the Home icon.

2. Click on the VMs and Templates.

HOL-1803-05-NET
Open Console to Jumpbox
Expand the containers "RegionA01" and "Discovered virtual machines" to find

win12-jump.
1. Expand Misc VMs.

2. Right Click on "win12-jump".
3. Click on "Open Console".

HOL-1803-05-NET
Login in as HRadmin
1. Send Ctrl-Alt-Del. Use the console button.

2. Click the Left Arrow.
3. Choose Other user.
4. Enter User name = hradmin
5. Password = VMware1!. (be sure to include "." after the "!" mark)
6. Click on the arrow.

HOL-1803-05-NET
Open Chrome browser
1. Start Chrome Browser from desktop icon.

HOL-1803-05-NET
Launch the HR DB App.
1. Click on the bookmark, "HR DB App".
User HRadmin is part of the Hresources domain group and is ONLY allowed to access
the HR Medical application.

HOL-1803-05-NET
Attempt to launch the Finance DB App
1. Click on the bookmark, "Finance DB App".
This link will FAIL. Again user HRadmin is part of the Hresources domain group and is
ONLY allowed to access the HR Medical application.
Log Off as HRadmin

HOL-1803-05-NET
1. Click on Send Ctrl-Alt-Del.

2. Click "Sign Out".
Switch to other user
1. Click on Send Ctrl-Alt-Del.

2. Click on "Other user".
Login in as NetAdmin
1. Enter User name = NetAdmin.

HOL-1803-05-NET
2. Password = VMware1!. (be sure to add "." after "!" mark)

3. Click on the arrow.
Open Firefox browser
1. Start Chrome Browser from desktop icon.

HOL-1803-05-NET
Launch the HR DB App.
1. Click on the bookmark, "HR DB App" APP.
User NetAdmin is part of the AppConfiguration domain group and is allowed to access all
applications.

HOL-1803-05-NET
Launch the HOL-Finance App.
1. Click on the bookmark, "Finance DB App".
applications.

HOL-1803-05-NET
Launch the Customer DB App.
1. Click on the bookmark, "Customer DB App".
applications.
You can close the console to jumpbox.

HOL-1803-05-NET
Module 6 Conclusion
In the lab we have seen how using Identity Based Firewall features within NSX we can
control access to internal applications. We created AD based firewall rules for both a
Network Administrator and a Human Resources Administrator. These rules allow the HR
admin to only connect to the HR web application via HTTP protocol. The rules also
allow the Network Admin to connect to any of the applications via any protocol. In this
way we can control access to the correct applications with the correct level of privilege
based on roles within the organization.
If you are looking for additional information on NSX Identity Based Firewall capabilities
and configuration, then please review the NSX 6.3 Documentation Center via the URL
below:
Lab Module List:
preparing hosts.
3-tier application.
integration.
Lab Captains:

Kingdom

HOL-1803-05-NET

How to End Lab

HOL-1803-05-NET
Module 7 - NSX
Application Rule Manager
(30 minutes)

HOL-1803-05-NET
Application Rule Manager

Introduction
The Application Rule Manager (ARM) is a new toolset introduced in NSX 6.3. Application
Rule Manager utilizes real-time flow data to enable quick and efficient
microsegmentation planning and implemenation of Zero Trust security models. ARM
provideds a new way to help secure new or existing applications on scales larger than
what Log Insight can handle, and environments on a smaller scale than what vRealize
Network Insight (vRNI) would address.
ARM gathers real-time flow data both IN, OUT and between application workloads
allowing for the creation of app-centric security models. ARM can monitor up to 30 VMs
per session and a total of 5 sessions can be running at any given time. ARM also
provides visibility into blocked flows and the firewall rules that are blocking the traffic.
There are three steps in the application rule manager workflow:
1. Select virtual machines (VMs) that form the application and need to be
monitored. Once configured, all incoming and outgoing flows for a defined set of
VNICs (Virtualized Network Interface Cards) on the VMs are monitored. There can
be up to five sessions collecting flows at a time.
2. Stop the monitoring to generate the flow tables. The flows are analyzed to reveal
the interaction between VMs. The flows can be filtered to bring the flow records to
a limited working set.
3. Use flow tables to create grouping object such as security groups, IP sets,
services and service groups and firewall rules.
Lab Captain:
Module 5 - Chris Cousins, Sr. Systems Engineer, United States

HOL-1803-05-NET
Application Microsegmentation
Launch Chrome Browser and vSphere Web Client
1. Double-click on Chrome icon on the desktop

HOL-1803-05-NET
(The home page should be the vSphere Web Client. If not, click on the vSphere Web
1. Type in administrator@vsphere.local in to User name

3. Click Login
Explore Application Rule Manager
1. Select Home
2. Select Networking & Security

HOL-1803-05-NET
Select Flow Montoring
1. Select Flow Monitoring
Start New Session for HR_App
1. Select Application Rule Manager tab

2. Click Start New Session to start collecting application flow data.

HOL-1803-05-NET
Select HR_DB_App Virtual Machines
1. Session Name: HR_DB_App.

2. Select Virtual Machine in the Object Type drop-down menu.
3. Type hr into the Search field.
4. Select hr-web-01a.corp.local, hr-db-01a.corp.local, and hr-
app-01a.corp.local.
5. Click on the right arrow
6. Click OK.

HOL-1803-05-NET
Create Some Traffic Flows - ICMP
Application Rule Manager is now collecting flow data from the three HR_App virtual
machines. The longer the collection process runs, the more data you will have to
analyze. For our purposes, we will collect flow data for three minutes. To generate some
flow data:
1. Open a Putty session and select hr-web-01a.corp.local

2. In the commmand line, type ping -c 2 172.16.60.12
3. Open the Command Prompt on the Main Console
4. ping 172.16.60.10
ping -c 2 172.16.60.12
ping 172.16.60.10

HOL-1803-05-NET
Create More Traffic Flows - HTTPS
1. Open a new Chrome browswer tab

2. Click on the HR DB App bookmark
3. Refresh the page several times.
Data Collection - Stop

HOL-1803-05-NET
Within three minutes, you will see Flows in the Flow Monitoring console. The number of
flows will vary in each lab.
1. After three minutes, click Stop.

2. Click Yes to confirm.
Review Flow Data
Here we can see source and destination IPs as well as services like HTTP, HTTPS, etc.
Start New Session for Finance_DB_App
Before we analyze the data collected for HR_App, we will configure a second session for
Fin_App in order to demonstrate collecting multiple data flow sessions.
Start Session for Finance_DB_App
1. Click Start New Session

HOL-1803-05-NET
Select Finance_App Virtual Machines
1. Session Name: Finance_DB_App.

2. Select Virtual Machine in the Object Type drop-down menu.
3. Type fin into the Search field.
4. Select fin-web-01a.corp.local, fin-db-01a.corp.local, and fin-
app-01a.corp.local.
5. Click on the right arrow
6. Click OK.

HOL-1803-05-NET
Finance_App Data Collection
Application Rule Manager is now collecting flow data from the three Finance_App virtual
machines. The longer the collection process runs, the more data you will have to
analyze. For our purposes, we will collect flow data for three minutes. To generate flow
data, open a new Chrome browswer tab and click on the Finance DB App bookmark
and refresh the page several times. Within three minutes, you will see Flows in the Flow
Monitoring console. The number of flows will vary in each lab.
1. Click Stop
2. Click Yes
Review Sessions

HOL-1803-05-NET
We can now see that Application Rule Manager has successfully collect flow data for
both the HR_DB_App and Finance_DB_App virtual machines.
Review Sources
1. Click on Source to review vnics being montiored.

HOL-1803-05-NET
Review Flow Duration
1. Click on Flows to review collection time and duration.
Start Flow Analysis for Finance_DB_App
1. Click Analyze to being analyzing the collected flow data.

HOL-1803-05-NET
Start Flow Analysis for HR_App
When the data analysis is complete for Finance_DB_App:
1. Select HR_DB_App in the Session drop down menu

2. Click Analyze
Verify Data Analysis
1. Verify Analysis Complete has green checkmark. This indicates data analysis
was successful.

HOL-1803-05-NET
HR_DB_App Processed View
After analyzing and processing flow data, NSX has replaced the IPs with VM names,
making it easier to logically map flows between objects.
HR_DB_App Firewall Rules
We will use the information ARM has given us to microsegment virtual machines within
and between HR__DB_App & Finance_DB_App. Let's see if hr-web-01a can communicate
with hr-db-01a.

HOL-1803-05-NET
1. Open a Putty session for hr-web-01a.corp.local.

2. Click hr-db-01a.corp.local in the Destination column to retrieve its IP address.
3. Here we can see the IP address 172.16.60.12 as well as the Vnic information.
4. Ping 172.16.60.12. You should see a successful ping with no packet loss.
ping -c 2 172.16.60.12
We just verified that the HR_DB_App web-01a virtual machine can communicate directly
with the db-01a virtual machine. This is not an ideal situation! Next, we will configure
appropriate firewall rules to control traffic between the three-tiered virtual machines.
New Firewall Rules
1. Select the flow with Source (192.168.110.10), Destination (hr-web-01a.corp.local)

and Service (SSH).
2. Click the Gear icon
3. Select Create Firewall Rule

HOL-1803-05-NET
Control Center to HR_Web
1. Name: Control Center to HR_Web

2. Click Select across from Service

HOL-1803-05-NET
Select Services
1. Enter https in the search field.

2. Select HTTPS.
3. Click right arrow.
4. Confirm SSH and HTTPS are selected
5. Click OK

HOL-1803-05-NET
Confirm Configuration
1. Confirm your configuration matches the image and click OK

HOL-1803-05-NET
Configure HR_Web to HR_App Firewall Rule
1. Select the row that lists hr-app-01a as the Destination.

2. Click the Actions gear and select Create Firewall Rule.

HOL-1803-05-NET
New Firewall Rule: HR_Web to HR_App
1. Name: HR_Web to HR_App

2. Leave everything else as default and click OK

HOL-1803-05-NET
Configure New Firewall Rule: HR_App to HR_DB
1. Select the row with hr-db-01a as the Destination.

2. Click the Gear icon and select Create Firewall Rule
3. Do NOT select the row with ICMP Echo as the Service

HOL-1803-05-NET
New Firewall Rule: HR_App to HR_DB
Publish Firewall Rules

HOL-1803-05-NET
1. Under Flow Details, select the Firewall Rules tab. Here we can see the firewall
rules you just created.
2. Firewall rules can also be Edited and Deleted from this view.
3. Click Publish
Enter Name
1. Section Name: HR_DB_App

2. Select Default Section Layer 3
Review HR_DB_App Firewall Rule
1. Select Firewall in the Navigator panel

HOL-1803-05-NET
HR_DB_App 3 Tier Firewall Rule
Here we can review the firwall rules we just configured in Application Rule Manager.
Next, we will test the HR_DB_App to make the web page still resolves and unsecure
traffic has been blocked.
Edit Default FW Rule

HOL-1803-05-NET
1. Under the Default Rule, click on the Pencil icon to edit the rule.
2. Action: Block
3. Click Save
1. Publish Changes
Verify HR_DB_App is working
If you closed the HOL-HR Department tab:
1. Open a new Chrome browser tab

2. Click on the HR DB App bookmark.
You should be able to see the HR Employee Salary Database.

HOL-1803-05-NET
Open Command Prompt
Let's test if we can successfully ping the web, application and database servers from the
Main Console:
1. ping 172.16.60.10
2. ping 172.16.60.11
3. ping 172.16.60.12
ping 172.16.60.10
ping 172.16.60.11
ping 172.16.60.12
Now we can see that ICMP traffic is being blocked. The only allowed traffic is HTTPS.

HOL-1803-05-NET
Note: In this lab, we configured the web-01a firewall rule to allow SSH so we can access
the virtual machine via Putty to do the next test.
Open Putty
ping -c 2 172.16.60.12
1. ping -c 2 172.16.60.12
2. After about 10 seconds, enter Control+C to terminate.
Now we can see traffic from the web-01a to db-01a has been blocked!

HOL-1803-05-NET
Module 7 Conclusion
If you are looking for additional information on NSX Application Rule Manager
capabilities and configuration, then please review the NSX 6.3 Documentation Center
via the URL below:
Lab Module List:
preparing hosts.
3-tier application.
integration.
Lab Captains:

Kingdom

HOL-1803-05-NET
How to End Lab

HOL-1803-05-NET
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-1803-05-NET
Version: 20171023-155706

NSX Lab Description

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

NSX Lab Description

Încărcat de

Drepturi de autor:

Formate disponibile

HOL-1803-05-NET

Module 7 - NSX Application Rule Manager (30 minutes) ............................................... 314

Lab Module List:

• Module 1 - Michael Armstrong, Senior Systems Engineer, United

• Module 7 - Chris Cousins, Sr. Systems Engineer, USA

Location of the Main Console

Alternate Methods of Keyboard Data Entry

Click and Drag Lab Manual Content Into Console Active

Accessing the Online International Keyboard

Click once in active console window

1. Click once in the active console window.

Click on the @ key

1. Click on the "@ key".

Notice the @ sign entered in the active console window.

Activation Prompt or Watermark

This cosmetic issue has no effect on your lab.

Look at the lower right portion of the screen

Module 1 - NSX Manager

In the Interactive Simulation, you will see how to:

• Deploying the NSX Manager OVA

Hands-on Labs Interactive Simulation:

Hands-on Labs Interactive Simulation:

You've finished Module 1

Congratulations on completing Module 1.

Proceed to any module below which interests you the most:

Lab Module List:

• Module 1 - Michael Armstrong, Senior Systems Engineer, United

How to End Lab

To end your lab click on the END button.

Logical Switching - Module Overview

1. Confirm the configuration readiness of the hosts.

Launch Google Chrome

Login to the vSphere Web Client

1. Enter administrator@vsphere.local as User name.

Navigate to Networking & Security in vSphere Web Client

1. Click Home icon.

View the deployed components

The topology after the host is prepared with data path

View the VTEP configuration

1. Click Logical Network Preparation tab.

VXLAN configuration can be broken down into three important steps:

• Configure VXLAN Tunnel End Point (VTEP) on each host.

The topology after the VTEPs are configured across the

The three modes of control plane configuration are:

Segment ID and Multicast Group Address Configuration

Defining Transport Zone settings

1. Click Transport Zones.

Confirm Clusters as members of Local Transport Zone

Confirm all 3 clusters are present in the Transport Zone.

The topology after the Transport Zone is defined

Go back to Networking & Security Menu

1. Click Back until we return to the Networking & Security Section.

Create a new Logical Switch

1. Click Logical Switches on the left hand side.

Selecting "Enable IP Discovery" activates ARP (Address Resolution Protocol)

Attach the new Logical Switch to the NSX Edge Services

1. Select the newly created logical switch (Prod_Logical_Switch).

Connect the Logical Switch to the NSX Edge

NSX Edge can be installed as a logical (distributed) router or as a edge services

• The Edge Services Gateway, "Perimeter-Gateway-01", provides network services

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

Attach logical switch to NSX Edge