Yash Boss PDF

HOL-SDC-1603
Table of Contents
Lab Overview - HOL-SDC-1603 - VMware NSX Introduction .............................................. 2
Lab Guidance .......................................................................................................... 3
Module 1 - Logical Switching (30 min) .............................................................................. 8
Controller Based VXLAN .......................................................................................... 9
Module 2 - Logical Routing (60 min) ............................................................................... 45
Routing Overview .................................................................................................. 46
Dynamic and Distributed Routing ......................................................................... 48
Centralized Routing............................................................................................... 79
ECMP and High Availability.................................................................................... 99
Prior to Moving to Module 3 - Please Complete the Following Cleanup Steps ..... 148
Module 3 - Distributed Firewall (60 min) ....................................................................... 153
Distributed Firewall East-West Protection - Micro Segmentation ......................... 154
Identity Based Firewalling ................................................................................... 184
Improved IP Discovery Mechanism for Virtual Machines and SpoofGuard........... 203
Module 4 - Edge Services Gateway (30 min) ................................................................ 221
DHCP Relay ......................................................................................................... 222
NSX Edge Services Gateway - Logical Load Balancing ........................................ 255
NSX Edge Services Gateway - SSL Offload on Logical Load Balancer.................. 300
Module 5 - Service Insertion and Security Policies (30 min).......................................... 316
Service Composer ............................................................................................... 317
Service Insertion ................................................................................................. 359
Data Security ...................................................................................................... 367
Module 6 - Monitoring and Visibility (45 min)................................................................ 382
Traceflow ............................................................................................................. 383
Flow Monitoring................................................................................................... 401
Activity Monitoring .............................................................................................. 418
HOL-SDC-1603 Page 1
HOL-SDC-1603
Lab Overview - HOL-

SDC-1603 - VMware NSX
Introduction
HOL-SDC-1603 Page 2
HOL-SDC-1603
Lab Guidance
The following module is informational in nature. If you would like to jump
directly to the lab work, please advance to step 8.
The Table of Contents can be accessed in the upper right-hand corner.
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.
Server virtualization brings efficiency, flexibility and speed to how compute and memory
resources are consumed and managed in a datacenter. This is possible because of the
decoupling of compute and memory resources from the physical hardware.
However, if you look at the state of the network and network services, such as Firewall
and Load Balancer within a data center, they are tied to physical hardware. For
example, if a server administrator wants to provision a three-tier application, they have
to first ask the Network/Security administrator for a set of isolated networks along with
Routing, Firewall, and Load Balancer services. It takes days to configure physical devices
and enable these networks and services. So, even if provisioning a virtual machine takes
a few clicks, server administrators have to wait days or weeks to roll out an application.
This problem of lack of speed and flexibility in provisioning network and network
services is addressed through Network virtualization. Network virtualization achieves
this by first decoupling the network and network services from the physical hardware
and then allowing you to reproduce similar physical network topologies in logical space.
As part of the lab modules, we will demonstrate how NSX platform helps speed up
provisioning of the required network and network services for the three-tier application.
A brief description of each module follows:
Lab Module List:
Module 1 - Logical Switching (30 Minutes). Will walk you through the
different components in the NSX platform in greater detail and also show how to
create a logical switch/network and connect virtual machines to that logical
switch. As part of this module we will show how the logical switch (VXLAN)
domain can be extended to the physical network (VLAN) using the VXLAN-VLAN
Bridging feature. This feature is useful in scenarios where you want to provide
layer 2 communication between the logical and physical world
Module 2 - Logical Routing (60 Minutes). In this module you will enable the
distributed routing capability and benefit of performing routing at the hypervisor
layer. Also, Dynamic routing protocol OSPF configuration will allow you to
exchange routing table entries across the physical and virtual routers. Lastly, you
HOL-SDC-1603 Page 3
HOL-SDC-1603
will configure ECMP (Equal Cost Multipath Routing) to show scaling and high
availability of the edge gateways.
Module 3 - Distributed Firewall (60 Minutes). You will enable a Distributed
Firewall to protect a 3-tier application using Micro-Segmentation. This will allow
you to protect VM to VM (east-west traffic). You will explore the Distributed
Firewall interface.
Module 4 - Edge Services Gateway(30 Minutes). In this module you will
explore advanced features of the Edge Services Gateway. While these include
such things as DHCP Relay, and load-balancing, and high-availability (HA),you will
be focusing on DHCP Relay and Load Balancing for this module.
Module 5 - Service Insertion and Security Policies (30 Minutes). Service
Composer will be the feature you will use to create Security Groups and Security
Policies. In addition you will install NSX Data Security to monitor a VM for the
presence of credit card numbers and take actions.
Module 6 - Monitoring and Visibility (45 Minutes). NSX provides visibility
into the traffic in the virtual network. You can view protocol traffic using Flow
Monitor. You can also trace traffic between source and destination for
troubleshooting purposes. And you can track users and what applications they
are using in the virtual network.
Lab Captains:
Module 1 - Melanie Spencer

Module 2 - Joe Silvagi
Module 3 - Sachin Thatte
Module 4 - Joe Silvagi & Sachin Thatte
Module 5 - Devender Sharma
Module 6 - Melanie Spender
HOL-SDC-1603 Page 4
HOL-SDC-1603
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 providing you with all the user accounts and passwords for the
environment.
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.
HOL-SDC-1603 Page 5
HOL-SDC-1603
Without full access to the Internet, this automated process fails and you see this
watermark.
This cosmetic issue has no effect on your lab.
VMware NSX
VMware NSX is the leading network virtualization platform that delivers the operational
model of a virtual machine for the network. Just as server virtualization provides flexible
control of virtual machines running on a pool of server hardware, network virtualization
with NSX provides a centralized API to provision and configure many isolated logical
networks that run on a single physical network.
Logical networks decouple virtual machine connectivity and network services from the
physical network, giving cloud providers and enterprises the flexibility to place or
migrate virtual machines anywhere in the data center while still supporting layer-2 /
layer-3 connectivity and layer 4-7 network services.
HOL-SDC-1603 Page 6
HOL-SDC-1603
Decoupled Logical Networks
Disclaimer
This session may contain product features that are currently under
development.
This session/overview of the new technology represents no commitment from

VMware to deliver these features in any generally available product.
Features are subject to change, and must not be included in contracts,

purchase orders, or sales agreements of any kind.
Technical feasibility and market demand will affect final delivery.
Pricing and packaging for any new technologies or features discussed or

presented have not been determined.
These features are representative of feature areas under development. Feature

commitments are subject to change, and must not be included in contracts,
purchase orders, or sales agreements of any kind. Technical feasibility and market
demand will affect final delivery.
HOL-SDC-1603 Page 7
HOL-SDC-1603
Module 1 - Logical
Switching (30 min)
HOL-SDC-1603 Page 8
HOL-SDC-1603
Controller Based VXLAN

Component Overview and Logical Switching
In this lab you will first explore the key components of VMware NSX. The following other
key aspects are covered in this module:
1) With the addition of the NSX controller, the requirement for Multicast protocol support
on the physical fabric has been removed for VXLAN. We will demonstrate how to create
a Logical Switch and then attach two VM's to the Logical Switch that you created.
2) Then demonstrate how the logical switch can span across L3 Physical Networks, and
still have L2 connectivity between the two Web Servers.
3) The VXLAN to VLAN bridge function allows users to provide P to V communication as

well as P to V migration capability. We will show the configuration process.
4) Lastly, we will review the scalability and high availability of the NSX platform.
Component Overview
Open a browser by double clicking on the Google Chrome icon on the desktop.
HOL-SDC-1603 Page 9
HOL-SDC-1603
Login to the vSphere Web Client
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.)
1. Login by checking the "Use Windows Session Authentication" box.

2. Click Login
Navigate to the Networking & Security Section in the Web

Client
1. Click to open the Networking & Security Section.
Verify the deployed components
1. Click Installation.
HOL-SDC-1603 Page 10
HOL-SDC-1603
2. Click Host Preparation. 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.
HOL-SDC-1603
The topology after the host is prepared with data path

components
In the next step, you will look at the VXLAN related configuration steps by selecting the
Logical Network Preparation Tab.
VXLAN configuration can be broken down into three important steps
Configure Virtual Tunnel Endpoint (VTEP) on each host

Configure Segment ID range to create a pool of logical networks. (In some
configurations, this step may require Multicast group address configuration.)
However, in this lab we are utilizing Unicast mode and we don't need to specify a
multicast range.
Define the span of the logical network by configuring the transport zone
View the VTEP configuration
1. Click Logical Network Preparation tab

2. Click VXLAN Transport tab
3. Click the twistie to expand the clusters
HOL-SDC-1603
As shown in the diagram the hosts in the compute clusters are configured with VTEP IP
address in a different subnet to the management cluster. (You may need to unpin the
left-hand pane or scroll to the right to view the IP Pool info on the right of the screen)
Computer Cluster A is in 192.168.130.0/24 subnet

Computer Cluster B is in 192.168.130.0/24 subnet
Management Edge Cluster is in 192.168.230.0/24 subnet
HOL-SDC-1603
The topology after the VTEPs are configured across the

Clusters
One of the key challenges customers have had 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.
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.
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.
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.
HOL-SDC-1603
Segment ID and Multicast Group Address Configuration
Click on Segment ID. Note that the Multicast addresses section above is blank.
With NSX for vSphere there is no longer the requirement for Multicast Addresses. For
this lab we are going to use Unicast Mode.
The final step is defining the span of the logical networks

through Transport Zone settings
1. Click Transport Zones

2. Double-click on Local-Transport-Zone-A
Confirm Clusters as members of Local Transport Zone
Confirm all 3 clusters are present in the Transport Zone.
HOL-SDC-1603
Click on the Manage tab to show the clusters that are part of this Transport
Zone.
HOL-SDC-1603
The topology after the Transport Zone is defined
A transport zone defines the span of a logical switch. Transport Zones dictate which
clusters can 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 networks. Once you have the logical switch spanning across all
compute clusters, you remove all the mobility and placement barriers you had before
because of limited VLAN boundaries.
After looking at the different NSX components and VXLAN related configuration, we will
now go through the creation of a logical network also known as logical switch.
HOL-SDC-1603
Go back to Networking & Security Menu
Click the history back button to return to the last window, in your case
the Networking & Security menu.
If by chance you clicked on something else after view the Transport
Zone, return to the Networking & Security Section of the Web Client via
the Home menu as used in previous steps.
HOL-SDC-1603
Create a new Logical Switch
1. Click Logical Switches on the left hand side

2. Click the "Green plus" sign to create a new Logical Switch
3. Name the Logical Switch: Prod_Logical_Switch
4. Click Change to the right of the Transport Zone Note: Unicast mode will
automatically be selected when you choose the Local-Transport-Zone-A
5. Select the Radio button by Local-Transport-Zone-A
6. Click OK and then
7. Click OK again
Leave the Enable IP Discovery box checked - then click OK.
IP Discovery enables ARP Suppression.
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 virtual machine.
HOL-SDC-1603
Attach the new Logical Switch to the NSX Edge services

gateway for external access
1. Highlight the newly created logical switch

2. Right Click on the Prod_Logical_Switch and select Connect Edge.
HOL-SDC-1603
Connect the Logical Switch to the NSX Edge
Routing is described in more detail in the next module, however, in order to gain
connectivity from our Control Center VM and/or other VMs in our lab, to the VMs on our
new logical switch, we need to connect to the router. As mentioned in the components
section, NSX Edge can be installed in two different forms: Distributed-Router and
Perimeter-Gateway.
The Edge Services gateway which is named a "Perimeter-Gateway" provides

network services such as DHCP, NAT, Load Balancer, Firewall and VPN along with
dynamic routing capability.
The "Distributed-Router" supports distributed routing, and dynamic routing.
In this example, you are going to connect the logical switch to the NSX Edge services
gateway (Perimeter-Gateway).
1. Click the radio button next to Perimeter-Gateway

2. Click Next
HOL-SDC-1603
The NSX Edge services gateway has ten interfaces. You

will need to attach the logical switch to vNIC5
1. Click the radio button next to vnic5

2. Click Next
HOL-SDC-1603
Name the Interface and configure the IP address for the

interface
1. Name the Interface: Prod_Interface

2. Select Connected
3. Click the Plus sign to Configure subnets (Leave the other settings as they
are)
HOL-SDC-1603
Assign an IP to the Interface
1. Enter the Primary IP Address 172.16.40.1 (Leave the Secondary IP Address

blank)
2. Enter 24 for the Subnet Prefix length
3. Verify your settings are correct and Click Next
HOL-SDC-1603
Complete the interface editing process
1. Click Finish (You will see your new logical switch show up in the logical switch
list)
HOL-SDC-1603
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-SDC-1603
Attach web-03a and web-04a to the newly created

Prod_Logical_Switch
1. Click to highlight the new Logical Switch that was created

2. Right Click and selectthe Add VM menu item
HOL-SDC-1603
Add Virtual Machines to attach to the new Logical Switch
1. Enter a filter to locate those VM's whose name start with"web"

2. Highlight web-03a and web-04a VM's
3. Click the right arrow to select the VM's to add to the Logical Switch
4. Click Next
HOL-SDC-1603
Add VM's vNIC to Logical Switch
1. Select the vNiCs for the two VMs

2. Click Next
Complete Add VMs to Logical Switch
1. Click Finish
HOL-SDC-1603
The Topology after the Virtual Machines are connected to

the logical switch
Creating a logical switch and then connecting the virtual machine to the logical switch is
an easy and quick process when using this network virtualization platform.
This approach of provisioning logical switches is much simpler and faster than the re-
configuration process of any physical devices.
Next you will see the communication between the virtual machines on the logical
network. The access from the external network is shown by establishing an SSH session
to the virtual machines. The communication across the virtual machines hosted on two
different clusters will demonstrate that the logical switch spans across physical layer 3
boundaries and still provides layer 2 connectivity.
HOL-SDC-1603
Hosts and clusters view
1. Click the Home Button

2. Select Hosts and Clusters from the drop down menu
This step will demonstrate the ability of our new logical switch to span a Layer 2 logical
segment across a Layer 3 Compute infrastructure.
HOL-SDC-1603
Expand the Clusters
Expand the arrows to see the VM's you just added to the Logical Switch. Notice
the two added VMs are on different Compute Clusters.
HOL-SDC-1603
Open Putty
1. Click Start
2. Click the Putty Application icon from the Start Menu
You are connecting from the control center which is in 192.168.110.0/24 subnet. The
traffic will go through the NSX Edge and then to the Web Interface.
HOL-SDC-1603
Open SSH session to web-03a
1. Select web-03a.corp.local
2. Click Open
**Note - if the web-3a is not showing as an option for some reason, you can also try
putting the IP address 172.16.40.13 in the Host Name box. If you still are not connected
you can review your previous steps and then contact a lab Proctor for assistance.
HOL-SDC-1603
Login into the VM
If prompted, Click Yes to accept the server's host key

If not automatically logged in, Login as user root and password VMware1!
Note: If you encounter difficulties connecting to web-03a, please review your previous
steps and verify they have been completed correctly.
HOL-SDC-1603
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 only send 2 pings instead of a continuous ping. NOTE:
web-04a has an IP of 172.16.40.14, you can ping by IP instead of name if needed.
ping -c 2 web-04a
***Note you might see DUP! packets. This is due to the nature of VMware's nested lab
environment. This will not happen in a production environment.
****Do not close your Putty Session. Minimize the window for later use.
Next you are going to look at another capability of NSX Edge that allows you to extend
your logical switch network to a physical VLAN. Instead of routing the traffic to the
external world from the logical switch, you can bridge the logical and physical
environments together. The following common use cases are addressed by this feature:
Physical to Virtual (P-V) communication. For example, you have physical database
servers and you want them to talk to the other tiers of the application that are
virtualized
You want to migrate workloads running on physical to a virtual environment
HOL-SDC-1603
VXLAN to VLAN Bridging: The topology below shows

bridging of logical switch to VLAN 100
For a given VXLAN-VLAN pair, the L2 bridging function is performed in the kernel of the
single ESXi host - which is hosting the Active Control VM for the specific DLR where the
VXLAN-VLAN mapping has been configured (as shown above)
HOL-SDC-1603
Configure VXLAN to VLAN Bridging
In this nested lab setup the VLAN tagging capability is not available and thus
we can't demonstrate the communication across the physical and logical L2
networks. We are going to show how you would perform the configuration
steps without saving. This is for demonstration purposes only.
1. Hover over the Home Icon

2. Click on Networking & Security
HOL-SDC-1603
Select NSX Edge named as Distributed-Router for the

bridging configuration
1. Select NSX Edges in the left panel

2. Double-click edge-4 Distributed-Router to to edit the properties
HOL-SDC-1603
Bridging a Logical Network to a VLAN.
1. Click the Manage tab

2. Select Bridging
3. Click the Plus sign
There are three Options to complete the Bridge. Name the bridge, select the Logical
switch that you want to Bridge onto the Physical Network, then Select the Distributed
Virtual Port Group that is tied to the VLAN you would like to Bridge into Logical space.
4. Click Cancel here as the configuration is not supported in this lab environment.
The configuration is straight forward where we just have to select the logical switch and
a VLAN.
NSX Controller Scalability/Availability
In this section you will take a look at the controller scalability and availability. The
Controller cluster in the NSX platform is the control plane component that is responsible
in managing the switching and routing modules in the hypervisors. The controller cluster
consists of controller nodes that manage specific logical switches. The use of a
controller cluster in managing VXLAN based logical switches eliminates the need for
multicast support from the physical network infrastructure.
For resiliency and performance, production deployments must deploy a Controller

Cluster with multiple nodes. The NSX Controller Cluster represents a scale-out
distributed system, where each Controller Node is assigned a set of roles that define the
type of tasks the node can implement. Controller nodes are deployed in odd numbers.
HOL-SDC-1603
The current best practice (and the only supported configuration) is for the cluster to
have three nodes of active-active-active load sharing and redundancy.
In order to increase the scalability characteristics of the NSX architecture, a slicing

mechanism is utilized to ensure that all the controller nodes can be active at any given
time.
Should a controller(s) fail, data plane (VM) traffic will not be affected. Traffic will
continue. This is because the logical network information has been pushed down to the
logical switches (the data plane). What you cannot do is make add/moves/changes
without the control plane (controller cluster) in tact.

HOL-SDC-1603
Verify the existing controller setup
1. Click Installation
2. Click Management
Examine the NSX Controller nodes, you can see that there are three controllers
deployed. NSX Controllers are always deployed in odd numbers for high availability and
scalability.
HOL-SDC-1603
View NSX Controller VMs
To see the NSX Controllers in the virtual environment

2. Click on VMs and Templates
HOL-SDC-1603
You will see the 3 NSX Controllers
1. Expandthe "Data Center Site A" container

2. Expand the NSX Controllers folder
3. Highlight one of the NSX_Controllers
4. Selectthe Summary tab. Notice the esx host that this controller is connected to.
The other controllers may be on a different esx host in this lab environment. In a
production environment, each controller would reside on a different host in the
cluster with DRS anti-affinity rules set to avoid multiple controller failures due to a
single host outage.
Module 1 Conclusion
In this module we demonstrated the following key benefits of the NSX platform
The speed at which you can provision logical switches and interface them with virtual
machines and external networks
Platform scalability is demonstrated by the ability to scale the transport zones as well as
the controller nodes.
HOL-SDC-1603
Module 2 - Logical
Routing (60 min)
HOL-SDC-1603
Routing Overview
Lab overview
In the previous module you saw that users can create isolated logical switches/networks
with few clicks. To provide communication across these isolated logical layer 2 networks,
routing support is essential. In the NSX platform the distributed logical router allows you
to route traffic between logical switches. One of the key differentiating feature of this
logical router is that the routing capability is distributed in the hypervisor. By
incorporating this logical routing component users can reproduce complex routing
topologies in the logical space. For example, in a three tier application connected to
three logical switches, the routing between the tiers is handled by this distributed
logical router.
In this module you will demonstrate the following
1) How traffic flows when the routing is handled by an external physical router or NSX
edge services gateway.
2) Then we will go through the configuration of the Logical Interfaces (LIFs) on the
Logical router and enable routing between the App and DB tiers of the Application
3) Later we will configure dynamic routing protocols across the distributed logical router
and the NSX Edge services gateway. We will show how internal route advertisements to
the external router are controlled.
4) Finally you will see how various routing protocols, such as ECMP, can be used to scale
and protect the Edge service gateway.
This module will help you understand some of the routing capabilities supported in NSX
platform and also how to utilize these capabilities while deploying a three tier
application.
clipboard.
HOL-SDC-1603
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-SDC-1603
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
In the above picture, notice that the Application VM and the Database VM both reside on
the same physical host, which is the scenario in the lab. Without distributed routing, for
these two VM's to communicate, we can see the traffic flow noted by the red arrow
steps above. First we see the traffic leave the Application VM and because the
Database VM is not on the same network subnet, the physical host will send that traffic
to a layer 3 device. In the environment, this is the NSX (perimeter) Edge which resides
on the Management Cluster. The NSX Edge then sends the traffic back through to the
host where it finally reaches the Database VM.
At the end of the lab, we will again visit a similar traffic flow diagram to see how we
have changed this behavior after configuring distributed routing.
HOL-SDC-1603
Access vSphere Web Client
Bring up the vSphere Web Client via the icon on the desktop labeled,
Chrome.
Log into vSphere Web Client
Log into the vSphere Web Client using the Windows session authentication.
1. Click Use Windows session authentication - This will auto fill in the
credentials of administrator@corp.local / VMware1!
2. Click Login
Confirm 3 Tier Application Functionality
1. Open a new browser tab

2. Click favorite named 3-Tier Web App
HOL-SDC-1603
Click Advanced
Click on Advanced
HOL-SDC-1603
Proceed to web page
Click "Proceed to 172.16.10.11 (unsafe).
HOL-SDC-1603
Web Application Returning Database Information
Before you begin configuring Distributed Routing let us verify that the three tiered Web
Application is working correctly. The three tiers of the application (web, app and
database) are on different logical switches and NSX Edge providing routing between
tiers.
The web server will return a web page with customer information stored in the
database.
Removal of the App and Db Interfaces from the Perimeter

Edge
As you saw in the earlier topology the three logical switches or three tiers of the
application are terminated on the perimeter edge. The perimeter edge provides the
routing between the three tiers. We are going to change that topology by first removing
the App and DB interfaces from the perimeter edge. After deleting the interfaces, we will
move those on to the distributed edge. For saving the time of deploying a component,
the Distributed Router has been created for you.
HOL-SDC-1603
Return to the vSphere Web Client tab:
1. Click on the Networking & Security button
Select NSX Edge
1. Click on NSX Edges in the left navigation pane

2. Double click"edge-2 Perimeter-Gateway" to open the Perimeter-Gateway
configuration
HOL-SDC-1603
Select Interfaces from the Settings Tab to Display Current

Interfaces
1. Click on Manage Tab

2. Click on Settings
3. Click on Interfaces under the Settings navigation tab
You will see the currently configured interfaces and their properties. Information
includes the vNIC number, interface name, whether the interface is configured as
internal or an uplink and what the current status is, active or disabled.
HOL-SDC-1603
Delete the App Interface
1. Highlight "Internal_App" interface, the Actions bar will illuminate giving specific
options for the selected interface
2. Click the red"X" to delete the selected interface from the perimeter edge. A
warning box will pop-up asking us to confirm we want to delete the interface
3. Click"Ok" to confirm the deletion
HOL-SDC-1603
Delete the DB Interface
1. Highlight "Internal_DB" interface, the Actions bar will illuminate giving specific
options for the selected interface
2. Click the red"X" to delete the selected interface from the perimeter edge. A
warning box will pop-up asking us to confirm we want to delete the interface
3. Click"Ok" to confirm the deletion
HOL-SDC-1603
The Topology After the App and DB Interfaces are

Removed from the Perimeter Edge
HOL-SDC-1603
Navigate Back to the NSX Home Page
Now that you have removed the App and DB interfaces from the perimeter edge, you
need to navigate back to the edge device screen in order to access the distributed
edge.
Click the Networking & Security back button at the top left which takes us
back to the main Edge Services screen.
Add App and DB Interfaces to the Distributed Router
We will now begin configuring Distributed Routing by adding the App and DB interface to
the "Distributed Router".
Double click "edge-4" to configure the Distributed Router.
HOL-SDC-1603
Display the Interfaces on the Distributed Router
1. Click on Manage.
2. Click on Settings
3. Click on Interfaces to display all the interfaces currently configured on the
Distributed Router
HOL-SDC-1603
Add Interfaces to the Distributed Router
1. Click on the Green Plus sign to add a new interface

2. Name the interface App_Interface
3. Click Select on the Connected To section
HOL-SDC-1603
Specify the Network
1. Select the "App_Tier_01" radio button which will be the network this interface
will communicate on
2. Click OK
HOL-SDC-1603
Add Subnets
1. Click the Green Plus sign for Configure Subnets.

2. Click on the Primary IP Address box and enter 172.16.20.1 as the IP address
3. Enter 24 as the "Subnet Prefix Length"
4. Then click OK to complete the adding of the subnet
HOL-SDC-1603
Confirm that the App_Interface has Been Added
Once the system is done configuring and adding the interface, the main Interface page
will be displayed where we should see the App_Interface interface you just added.
Add the DB Interface
Complete the same steps this time adding the DB_Interface connecting it to
the DB_Tier_01 with address 172.16.30.1 with a subnet prefix length of 24.
Once the system completes adding and configuring the DB_Interface, the main interface
window will be displayed where we can confirm that both interfaces have now been
added.
HOL-SDC-1603
The New Topology after Moving the App and DB Interfaces

to the Distributed Router
After these interfaces are configured on the Distributed Router those interface
configurations are automatically pushed to each host in the environment. From here on
the Host's Distributed Routing (DR) Kernel loadable module handles the routing between
the App and DB interfaces. So if the two VMs connected to two different subnets are
running on the same host wants to communicate, the traffic will not take un-optimal
path as shown in the earlier traffic flow diagram.
HOL-SDC-1603
Return to Browser Tab with 3-Tier Web App
After making the changes, you will test that the 3 Tier Application access fails. The
reason it fails is while we setup the routing to be handled by the Distributed Router,
there is not currently a route between it and where the Web Servers are located.
Click on tab you previously had open named HOL - Multi-Tier App
Note : If you closed that tab in the previous steps, open a new browser tab and click
the 3-Tier Web App favorite
Verify that the 3 Tiered Application Stops Working
1. Click Refresh
The application will take a few seconds to actually time out, you may need to select the
red "x" to stop the browser. If you do see customer data, it may be cached from before
and you may need to close and re-open the browser to correct it.
Close the tab created to test connectivity to the web server. Next we will configure
routing to restore the service.
Note: If you do have to re-open the browser, after verifying the 3 tier
application is not working, click on the bookmark in the browser for vSphere
Web Client and login again with the credentials "root" password "VMware1!".
Then click on Networking and Security, Edge Appliances and finally double-
click on "Distributed-Router".
HOL-SDC-1603
Configure Dynamic Routing on the Distributed Router
Return to the vSphere Web Client Tab.
1. Click the Routing tab

2. Click Global Configuration
3. Click the Edit button next to Dynamic Routing Configuration
HOL-SDC-1603
Edit Dynamic Routing Configuration
1. Select the default router id which is the IP address of the Uplink interface, in this
case Edge_Uplink - 192.168.5.2
2. Click OK
Note: The router ID is important in the operation of OSPF as it indicates the

routers identity in an autonomous system. It is a 32 bit identifier denoted as
an IP address but can be specific to the subnets interesting to the specific
router. In our case, we are using a router ID that is the same as the IP address
of the uplink interface on the edge device which is acceptable although not
necessary. The screen will return to the main "Global Configuration" screen and again
the "Publish Changes" green dialog box appears.
Publish Changes
Click the "Publish Changes" button in the dialog box again to push the updated
configuration to the distributed-edge device.
HOL-SDC-1603
Configure OSPF Specific Parameters
We will be using OSPF as our dynamic routing protocol.
1. Select"OSPF" in the navigation tree under Routing to open the main OSPF
configuration page
2. Click"Edit" to the right of OSPF Configuration to open the "OSPF Configuration"
dialog box
HOL-SDC-1603
Enable OSPF
1. Click the "Enable OSPF" dialog box

2. Enter 192.168.5.3 in the "Protocol Address" box
3. Enter 192.168.5.2 in the "Forwarding Address" box
4. Verify that the "Enable Graceful Restart" dialog box is checked
5. Then click "OK"
NOTE: For the Distributed Router the "Protocol Address" field is required to send the
Control traffic to the Distribute router Control Virtual Machine. The Forwarding address is
where all the normal data path traffic will be sent. The screen will return to the main
"OSPF" configuration window. The green "Publish Changes" dialog box will be displayed.
NOTE: The separation of control plane and data plane traffic in NSX creates the
possibility of maintaining the routing instance's data forwarding capability while the
control function is restarted or reloaded. This function is referred to as "Graceful
Restart" or "Non-stop Forwarding".
DO NOT PUBLISH CHANGES YET!Rather than publishing changes at every step, we'll
continue though the configuration changes and publish them all at once.
Configure Area Definition
1. Click the Green Plus sign which will open the "New Area Definition" dialog box
2. Enter 10 into the "Area ID" box. You may leave the other dialog boxes at their
default settings
3. Click OK
HOL-SDC-1603
Note: The Area ID for OSPF is very important. There are several types of
OSPF areas. Be sure to check the correct area the edge devices should be in
to work properly with the rest of the OSPF configuration within the network.
HOL-SDC-1603
Area to Interface Mapping
1. Click the Green Plus sign under the "Area to Interface Mapping" area to open
the "New Area to Interface Mapping" dialog box
2. Select Edge_Uplink for Interface
3. Select 10 for the Area
4. Click OK
Publish Changes
HOL-SDC-1603
Confirm OSPF Routing is Enabled on the Distributed

Router
We can now confirm that we have enabled and configured OSPF on the distributed-
edge. Confirm all information displayed is correct.
Confirm Route Redistribution
Click on"Route Redistribution" to open the main configuration page for route
redistribution.
HOL-SDC-1603
Verify Route Redistribution
Verify that there is a check box next to OSPF. This is showing that route
redistribution for OSPF is enabled.
Configure OSPF Routing on the Perimeter Edge
Now we must configure the dynamic routing on the perimeter-edge device to restore
connectivity to our test 3 Tier Application.
Clicking on the "Networking & Security" back button to the upper left to take
us back to the main "Edge Services" page.
HOL-SDC-1603
Select the Perimeter Edge
From the main "NSX Edges" page, our configured edge devices are displayed.
Double-click the"Edge-2" (Perimeter-Gateway) to again open the main

configuration page for that device.
HOL-SDC-1603
Global Configuration for the Perimeter Edge
1. Click the Manage navigation tab

2. Select the Routing navigational button to get to the device routing configuration
page
3. Click on OSPF
You will notice that this Edge device has already been configured for Dynamic Routing
with OSPF. This routing configuration is set so that this Edge device can communicate
and distribute routes to the router running the overall lab. We will now continue on by
connecting this Edge device to the Logical Distributed Router. Because of this, all global
router and OSPF settings are already completed, similar to how you just did for the
Distributed Router.
Add Transit Interface to Area to Interface Mapping
We now just need to direct OSPF to communicate over the interface that will
communicate with the Distributed Routers.
1. Click the Green Plus Sign by "Area to Interface Mapping"
HOL-SDC-1603
2. Select Transit_Network under "vNIC"

3. Select 10 under "Area"
4. Click OK
Publish Changes
HOL-SDC-1603
Review New Topology
Taking a look at how the topology sits now, you can see how route peering is occurring
between the Distributed Router and the NSX Perimeter Edge device. Any network you
create under the Distribute Router will now be distributed up to the Edge, where at that
point you can control how it is routed into your physical network.
The next section will cover this in more detail.
HOL-SDC-1603
Verify Communication to the 3-Tier App
Now let's verify the routing is functional. The routing information from the Distributed
Router to the Perimeter-Gateway is now being exchanged, which has in turn restored
connectivity to the Web App. To verify this, we will once again test the Web App.
1. Click on the tab you had previously opened for the Web Application, it may say
"503 Service Temp..." in the tab from the previously failed test.
2. Refresh your browser to verify the 3-Tier webapp works again
Note: This might take a minute for route propagation, this time is due to the nested
environment.
Dynamic and Distributed Routing Completed
This completes the section on configuring Dynamic and Distributed routing. In the next
section we will review centralized routing with the Perimeter Edge.
HOL-SDC-1603
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 names README.txt. It
contains the CLI commands needed in the lab exercises. If you can't type
them you can copy and paste them into the putty sessions. If you see a
number with "french brackets - {1}" this tells you to look for that CLI
command for this module in the text file.
HOL-SDC-1603
Current Lab Topology
This diagram is the current lab topology, including the northbound link to the vPod
Router. You can see that OSPF is redistributing routes from the vPod router, all the way
down to the Distributed Logical 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.
HOL-SDC-1603
Confirm 3 Tier Application Functionality
Open a new browser tab.
Web Application Returning Database Information
Before you begin configuring Distributed Routing let us verify that the three tiered Web
Application is working correctly. The three tiers of the application (web, app and
database) are on different logical switches and NSX Edge providing routing between
tiers.
Click on "3-Tier Web App " bookmark.
The web server will return a web page with customer information stored in the
database.
HOL-SDC-1603
Go to vSphere Web Client
If you are not already logged in, go to vSphere Web Client.
Navigate to Perimeter-Gateway VM
Select VMs and Templates
Launch Remote Console
1. Expand the Datacenter Site A and Edges Folders
HOL-SDC-1603
2. Select Perimeter-Gateway
3. Select Summary Tab
4. Click Launch Remote Console
HOL-SDC-1603
Access Remote Console
When the VMRC window first opens, it will appear black. Click inside the window and
press enter a couple of times to make the console appear from the screensaver.
***NOTE*** To release your cursor from the window, press Ctrl+Alt keys
Login to Perimeter Gateway
Log into the perimeter gateway with the following credentials. Note that all Edge
devices are 12 character complex passwords.
Username :admin
Password : VMware1!VMware1!
HOL-SDC-1603
clipboard.
characters.
View OSPF Neighbors
The first thing we will do is look at the OSPF neighbors to the Perimeter Edge, which is in
the middle of the lab routing layer.
NOTE - Tab completion works on Edge devices in NSX.
Enter show ip ospf neighbor.
HOL-SDC-1603
show ip ospf neighbor
Reviewing Displayed OSPF Neighbor Information
Let's now review the content displayed and what it all means.
1. Neighbor ID 192.168.5.2 - This is the router ID of the logical distributed router

inside the NSX environment
2. Address 192.168.5.3 - This shows the address that OSPF on the Perimeter Edge
is talking to, this is the IP that we configured earlier in the lab.
3. Interface vNic_1 - If you look inside the interfaces on the Edge, this will
correlate to that, showing you which interface this peering communication is
occurring on. This is the southbound interface.
4. Neighbor ID 192.168.250.1 - This is the router ID of the vPod Router, the
virtual router that runs the entire lab. This is the router that the control center
and other components such as vCenter use to communicate.
5. Address 192.168.100.1 - This shows the address that OSPF on the Perimeter
Edge is talking to, this is one of the interfaces on the vPod Router.
6. Interface vNic_0 - If you look inside the interfaces on the Edge, this will
correlate to that, showing you which interface this peering communication is
occurring on. This is the northbound interface.
HOL-SDC-1603
Review Routes on Perimeter Edge and their Origin
Type "show ip route"
Press Enter
show ip route
HOL-SDC-1603
Review Route Information
Let's review the content of the routes displayed.
1. The first line shows our default route, which is originating from the vPod router
(192.168.100.1) and the O at the start of the lines shows it has been learned
via OSPF.
2. The second line is the Web-Tier logical switch and its interface. Since it is directly
connected to the Edge, there is a C at the beginning of the line noting as such.
3. The section noted with a 3 are the other two portions of our Web App, those
being the network segments for the App and DB layer. As noted in line 1, they
have an O at the start of the line to denote they were learned via OSPF via the
Distributed Router (192.168.5.2).
4. All of the network segments in section 4 are networks learned by the Perimeter
Edge from the vPod router (192.168.100.1) via OSPF. All of these networks
can be connected to from inside of the NSX virtual network and visa versa.
HOL-SDC-1603
Controlling OSPF Route Distribution
There could be a situation where you would only want OSPF routes to distribute inside of
the virtual environment, but not out into the physical world. We are able to control that
route distribution easily from the Edge interface.
Navigate to NSX in vSphere Web Client
**NOTE** You need to press Ctrl+Alt to leave VMRC Window of Perimeter-

Gateway
Return to vSphere Web Client

Click Home Icon, then select Networking and Security
HOL-SDC-1603
Access Perimeter Gateway
1. Click NSX Edges

2. Double-Click Edge-2
Access OSPF Routing Configuration
1. Select Manage Tab

2. Click Routing
3. Click OSPF in the left pane
HOL-SDC-1603
Remove Area Mapping to Northbound Interface
We will now remove the mapping of OSPF Area 10 from the Uplink interface. In doing
this, the Perimeter Gateway and vPod router will no longer be route peered.
1. Select Uplink vNIC

2. Click Red X to delete mapping
Confirm Delete
Click Yes
Publish Change
Click Publish Changes to push the configuration change.
Naivgate to Perimeter Gateway VMRC
Select Perimeter-Gateway in your taskbar
HOL-SDC-1603
Show OSPF Neighbors
**NOTE** Once the window appears, you may need to click inside and press
the enter key to get the screen to appear
1. Type "show ip ospf neighbor" and Press Enter
You will now see that the only neighbor is the Distributed Router (192.168.5.2) and
that the vPod Router (192.168.250.1) has dropped from the list.
Show Routes
1. Type "show ip route" and Press Enter
show ip route
Now you can see that the only routes being learned via OSPF is from the Distributed
Router (192.168.5.2)
Verify that the 3 Tiered Application Stops Working

Gateway
HOL-SDC-1603
Since no routes exist between you control center and the virtual networking
environment, the web app should fail.
1. Click on the HOL - Multi-Tier App Tab

2. Click Refresh.
The application may take a few moments to actually time out, you may need to select
the red "x" to stop the browser. If you do see customer data, it may be cached from
before and you may need to close and re-open the browser to correct it.
HOL-SDC-1603
Re-Establish Route Peering
Now let's get the route peering between the Perimeter Gateway and the vPod Router
back in place.
Navigate back to your vSphere Web Client
HOL-SDC-1603
Add Area to Interface Mapping Back in
1. Click the Green Plus Sign under Area to Interface Mapping

2. Select Uplink under vNIC
3. Select 10 under Area
4. Verify that Ignore Interface MTU setting is CHECKED - NOTE - This is something
that normally would not be set, but is done due some constraints in this lab
environment.
5. Click OK
Publish Change
HOL-SDC-1603
Naivgate to Perimeter Gateway VMRC
Select Perimeter-Gateway in your taskbar
Show OSPF Neighbors
**NOTE** Once the window appears, you may need to click inside and press
the enter key to get the screen to appear
1. Type "show ip ospf neighbor" and Press Enter
You will now see that both the Distributed Router (192.168.5.2) and that the vPod
Router (192.168.250.1) are shown as neighbors.
Review Routes on Perimeter Edge and their Origin
Type "show ip route"
show ip route
HOL-SDC-1603
Show Routes
All routes from the vPod Router (192.168.100.1) are now back in the list.
HOL-SDC-1603
Verify that the 3 Tiered Application Is Working

Gateway
With the routes back in place, the Web App should now be functional again.
1. Click on the HOL - Multi-Tier App Tab

2. Click Refresh.
This completes this section of the lab, we will now move on to ECMP and High
Availability with the NSX Edges.
HOL-SDC-1603
ECMP and High Availability

In this section, we will now add another Perimeter Edge 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 do an in place addition of an Edge device and
enable to ECMP.
Access NSX in vSphere Web Client
1. Check the box to Use Windows session authentication

2. Click Login
HOL-SDC-1603
Navigate to NSX in vSphere Web Client

Gateway
Return to vSphere Web Client.
1. Click Home Icon

2. Click Networking & Security

HOL-SDC-1603
Add Additional Perimeter Gateway Edge
Our first step is to add an additional perimeter edge device.
1. Click NSX Edges

2. Click Green Plus Sign

HOL-SDC-1603
Select and Name Edge
1. Click Edge Services Gateway for Install Type

2. Enter Perimeter-Gateway-2 under Name
3. Click Next
Set Password
1. Enter the password VMware1!VMware1!

2. Confirm the password VMware1!VMware1!
3. Check Enable SSH Access
4. Click Next

HOL-SDC-1603
NOTE - All passwords for NSX Edges are 12 character complex passwords.

HOL-SDC-1603
Add Edge Appliance
1. Click Green Plus Sign under NSX Appliances to make the Add NSX Edge
Appliance dialog box appear
2. Select Management & Edge Cluster for Cluster/Resource Pool
3. Select ds-site-a-nfs01 for Datastore
4. Select esx-04a.corp.local for Host
5. Select Edges for Folder
6. Click OK

HOL-SDC-1603
Continue Deployment
Click Next

HOL-SDC-1603
Add Uplink Interface
Click the Green Plus Sign to add the first interface

HOL-SDC-1603
Select Switch Connected To
We have to pick the northbound switch interface for this edge, which is a distributed
port group.
1. Click Select next to the Connected To field

2. Click Distributed Portgroup
3. Select vds_mgt_Uplink Network
4. Click OK
Name and Add IP
1. Enter Uplink under Name

2. Select Uplink under Type
3. Click the Green Plus Sign
4. Enter 192.168.100.5 under Primary IP Address

HOL-SDC-1603
5. Enter 24 under Subnet Prefix Length

6. Click OK

HOL-SDC-1603
Add Edge Transit Interface
Click the Green Plus Sign to add the second interface

HOL-SDC-1603
Select Switch Connected To
We have to pick the northbound switch interface for this edge, which is a VXLAN Backed
Logical Switch.
1. Click Select next to the Connected To field

2. Click Logical Switch
3. Select Edge_Transit_01_5000
4. Click OK
Name and Add IP
1. Enter Transit_Network under Name

2. Select Internal under Type
3. Click the Green Plus Sign
4. Enter 192.168.5.4 under Primary IP Address

HOL-SDC-1603
5. Enter 29 under Subnet Prefix Length - NOTE - This is 29, not 24! Please
make sure to enter the right number or the lab will not function.
6. Click OK

HOL-SDC-1603
Continue Deployment
IMPORTANT! Before continuing, review the information and tha the IP

Addresses and Subnet Prefix numbers are correct.
Click Next
Remove Default Gateway
We are removing the default gateway since we receive that information via
OSPF
1. UNCHECK Configure Default gateway

HOL-SDC-1603
2. Click Next

HOL-SDC-1603
Default Firewall Settings
1. CHECK Configure Firewall default policy

2. Select ACCEPT
3. Click Next

HOL-SDC-1603
Finalize Deployment
Click Finish to start deployment
Edge Deploying
It will take a couple of minutes for the Edge to deploy.
1. You will notice under status for Edge-5 that it says Busy, also it shows 1 item
installing. This means the deployment is in process.
2. You can click the refresh icon on the web client to speed up the auto refresh on
this screen.

HOL-SDC-1603
Once the status says Deployed you can move on to the next step.
Configure Routing on New Edge
We must now configure OSPF on the new Edge device before we can enable ECMP.
Double-Click the newly deployed Edge-5

HOL-SDC-1603
Routing Global Configuration
We must set the base configuration to identify the router to the network.
1. Click Manage tab

2. Click Routing tab
3. Select Global Configuration in the left pane
4. Click Edit next to Dynamic Routing Configuration
5. Select Uplink -192.168.100.5 for Router ID
6. Click OK
Publish Changes

HOL-SDC-1603
Enable OSPF
1. Select OSPF in the left pane

2. Click Edit next to OSPF Configuration
3. CHECK Enable OSPF
4. Click OK

HOL-SDC-1603
Add New Area
1. Click the Green Plus Sign by Area Definitions

2. Enter 10 for Area ID
3. Click OK

HOL-SDC-1603
Add Uplink Interface Mapping to
Similar to how we previously did in the last part of the lab, we need to do the area
mapping with OSPF to the Uplink interface.
1. Click the Green Plus Sign by Area to Interface Mapping

2. Select Uplink for vNIC
3. Select 10 for Area
4. Verify that Ignore Interface MTU setting is CHECKED - NOTE - This is something
that normally would not be set, but is done due some constraints in this lab
environment.
5. Click OK
Add Transit Interface Mapping
Now the same must be done for the downlink interface to the Distributed Router
1. Click the Green Plus Sign by Area to Interface Mapping

2. Select Transit_Network for vNIC
3. Select 10 for Area
4. Click OK

HOL-SDC-1603
NOTE - DO NOT check the Ignore Interface MTU, that is on the uplink only!
Publish Changes

HOL-SDC-1603
Enable OSPF Route Distribution
We must now enable OSPF route redistribution in order for the routes to be accessible
through this edge.
1. Click Route Redistribution in the left pane

2. Click Edit for Route Redistribution Status
3. Check OSPF
4. Check OK

HOL-SDC-1603
Route Distribution Table
1. Click the Green Plus Sign under Route Redistribution Table

2. Check Connected
3. Click OK
Publish Changes

HOL-SDC-1603
Enable ECMP
We are now going to enable ECMP on both the Distributed Router and the Perimeter
Gateways
Click Home Icon, then Networking and Security

HOL-SDC-1603
Access Distributed Router
We will first enable ECMP on the Distributed Router
1. Click NSX Edges

2. Double-Click Edge-4
Enable ECMP on DLR
1. Click Manage tab

2. Click Routing Tab
3. Click Global Configuration in left pane
4. Click ENABLE Button next to ECMP
5. Click OK

HOL-SDC-1603
Publish Change
Return to Edge Devices
Click the Networking & Security back button to return to the previous page.
Access Perimeter Gateway 1
Double Click Edge-2 (Perimeter Gateway 1)

HOL-SDC-1603
Enable ECMP on Perimeter Gateway 1
1. Click Manage tab

5. Click OK
Publish Change

HOL-SDC-1603
Double Click Edge-5 - Perimeter Gateway 2

HOL-SDC-1603
Enable ECMP on Perimeter Gateway 2
1. Click Manage tab

5. Click OK
Publish Change

HOL-SDC-1603
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.
Verify ECMP Functionality from Distributed Router
Let's now access the distributed router to ensure that OSPF is communicating and ECMP
is functioning.
Click Home Icon then select VMs and Templates

HOL-SDC-1603
Launch Remote Console
1. Click Refresh Icon

3. Select Distributed-Router-0
4. Select Summary Tab

HOL-SDC-1603
Access Remote Console
When the VMRC window first opens, it will appear black. Click inside the window and
press enter a couple of times to make the console appear from the screensaver.
Login to Perimeter Gateway
Log into the distributed router with the following credentials
Username : admin
Password : VMware1!VMware1!

HOL-SDC-1603
View OSPF Neighbors
The first thing we will do is look at the OSPF neighbors to the Distributed Router.
NOTE - Tab completion works on Edge devices in NSX.
Type show ip ospf neighbor and press Enter. (Remember to use SEND TEXT
option.)
What this now shows is where the Distributed Router only had a single peer previously,
it now has two. Those being both Perimeter-Gateway-1(192.168.100.3) and
Perimeter-Gateway-2 (192.168.100.5).
Review Routes on Perimeter Edge
Type show ip route and press Enter
show ip route

HOL-SDC-1603
Review Route Information
All routes should show up as above. If you notice, each network segment is able to
route via two different network addresses. Those addresses are the perimeter-gateway
routes 1 & 2.
Verify ECMP Functionality from vPod Router
Now we will look at ECMP from the vPod Router, which simulates a physical router in
your network.
Click the PuTTY icon on the Taskbar
Open SSH Session to vPod Router
1. Using the Scroll Bar, scroll down and select vPod Router

HOL-SDC-1603
2. Click Load
3. Click Open

HOL-SDC-1603
Log into vPod Router
Use the following credentials to log into the vPod Router
Username : root
Password : VMware1!

HOL-SDC-1603
Access OSPF Module
We must telnet into the module that controls OSPF in the vPod Router.
1. Enter telnet localhost 2604 and press Enter. (Remember to use the SEND
TEXT option.)
telnet localhost 2604
2. Enter the password VMware1!

HOL-SDC-1603
Show OSPF Neighbors
We must telnet into the module that controls OSPF in the vPod Router.
1. Enter show ip ospf neighbor and press Enter
You will see two neighbors, they are Perimeter-Gateway-1 (192.168.100.3)

and Perimeter-Gateway-2 (192.168.100.5)
Show Routes
1. Enter show ip ospf route and press Enter
show ip ospf route
2. In this section you notice that 172.16.10.0/24 only has one router listed, this is
because that network is direct connected to Perimeter-Gateway-1 (192.168.100.3)
and is not routable by Perimeter-Gateway-2
3. In this section you notice that 172.16.20.0/24 & 172.16.30.0/24 has two routers
listed, both Perimeter-Gateway 1 (192.168.100.3) and Perimeter-Gateway-2

HOL-SDC-1603
(192.168.100.5). This is because both of these routers are able to communicate to

those segments, through the Distributed Router.
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.
High Availability with ECMP
With ECMP 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.
Click on the Command Prompt Icon in the taskbar

HOL-SDC-1603
Ping db-01a Database Server
Type ping -t db-01a and press Enter
ping -t db-01a
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.

HOL-SDC-1603
Shutdown Perimeter Gateway 2
We will simulate a node going offline by shutting down Perimeter-Gateway-2
Return to your vSphere Web Client

2. Right-Click Perimeter-Gateway-2-0
3. Click Power
4. Click Shut Down Guest OS
Confirm Shutdown
Click Yes

HOL-SDC-1603
Return to Ping Test
On the taskbar, go back to your command prompt running your ping test.
Routing Change Occurs
With the routing changing due to the edge coming offline, you will see pings to the
database VM drop offline and then restart as the route reconverge.
**NOTE** - We are using default route timers in this lab to keep the lab
manual flowing quickly. You are able to reduce timers down to 2 seconds to
speed up convergence.
Access vPod Router PuTTY Session
Access the PuTTY session to your vPod Router on the taskbar, named
"192.168.100.1 - PuTTY"
Check Current Routes

HOL-SDC-1603
show ip ospf route
You will note all routes to the 172.16.x.xnetworks are only through the Perimeter-
Gateway-1 (192.168.100.3).
Leave this window open for the following steps.

HOL-SDC-1603
Power Up Perimeter Gateway 2
Return to your vSphere Web Client

2. Right-Click Perimeter-Gateway-2-0
3. Click Power
4. Click Power On

HOL-SDC-1603
Verify Perimeter-Gateway-2 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.
You can use the Refresh Icon to check for updates on the VMTools
Status.
Access vPod Router PuTTY Session
Access the PuTTY session to your vPod Router on the desktop, named
"192.168.100.1 - PuTTY

HOL-SDC-1603
Show Routes
Let's check the status of the routes on the vPod router since we powered the Gateway
back up.
show ip ospf route
In section 2, you will see the routes have returned to dual connectivity.
Final Note on ECMP
A final note on ECMP and HA in this lab. While we have you shutdown Perimeter-
Gateway-2, the result of of doing this on Perimeter-Gateway-1 would be the same.
The only caveat is that the Web App will not work if Perimeter-Gateway-1 is offline
since the web server VMs are directly connected. You could resolve this by moving the
Web-App down to the Distributed Router as you did the Database and App networks.

HOL-SDC-1603
With that complete, the web app would function no matter if gateway 1 or 2 were
offline.
NOTE - Doing the above will break other modules in this lab! This is the
reason it is not done as part of the manual. If you do not plan to work on the
other modules, you can attempt to do the above.

HOL-SDC-1603
Prior to Moving to Module 3 - 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
Return to vSphere Web Client

Click Home Icon, then Networking and Security

HOL-SDC-1603
Delete Edge-5
We need to delete the Edge we just created
1. Select NSX Edges

2. Select Edge-5
3. Click Red X to Delete
Confirm Delete
Click Yes to confirm deletion

HOL-SDC-1603
Disable ECMP on DLR and Gateway-1
Double-click Edge-4
Disable ECMP on Distributed Router
1. Click Manage tab

4. Click DISABLE Button next to ECMP

HOL-SDC-1603
Publish Change
Double-click Edge-2
Disable ECMP on Perimeter Gateway 1
1. Click Manage tab


HOL-SDC-1603
4. Click DISABLE Button next to ECMP
Publish Change
Conclusion
This now completes Module 2 on Logical Routing.
We hope that you have enjoying the routing portion of this lab and have found it helpful
in your understanding of NSX.

HOL-SDC-1603
Module 3 - Distributed
Firewall (60 min)

HOL-SDC-1603
Distributed Firewall East-West

Protection - Micro Segmentation
NSX Distributed Firewall (DFW). One component of NSX is a distributed firewall
kernel module. The distributed firewall is installed in each vSphere host to enable the
functionality. The Distributed Firewall is near line-speed and has the resilience of
vSphere's host platform. It is also user-identity aware and provides unique activity
monitoring tools.
In this module you will explore how the distributed firewall helps protect a 3-tier
application. We will also demonstrate the firewall rule creation process based on
security groups and identity rather than IP address based rules. IP Address based rules
impose hard limits on mobile VMs and reduces the flexibility of using resource pools.
This module is based on four guest VMs making up a common 3-tier application. The
web tier has two web servers (web-01a and web-02a). The web servers will be seen in
a load balanced pool later. The web tier communicates to a VM named app-01a that is
running an application software, acting as the application tier. The app tier VM in turn
communicates to a VM named db-01a running MySQL in the database tier.
Enforcement of access rules between the tiers is provided by NSX DFW Firewall.
The outline of this module is:
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

Verify that you can still ping Linux-01a even with reject rule due to lack of
VMtools discovered IP address
Enable IP discovery with Arp Snooping
Verify that the reject rule now takes effect and denies access to Linux-01a VM
Identity Firewall
Create security group based on Active Directory Group.

Modify firewall rule to include AD Group.
Demonstrate that user outside of AD Group is denied access to web application.
Demonstrate that user inside of AD Group is provided access to web application.

HOL-SDC-1603
Start the module from your desktop. The desktop is your Control center jumpbox in
the virtual environment. From this desktop you will access the vCenter Server
Appliance deployed in your virtual datacenter.
Special Note: On the desktop you will find a file names README.txt. It
contains the CLI commands needed in the lab exercises. If you can't type
them you can copy and paste them into the putty sessions. If you see a
number with "french brackets - {1}" this tells you to look for that CLI
command for this module in the text file.
Launch Browser and vSphere Web Client
Double click on Chrome icon on the desktop

HOL-SDC-1603
clipboard.
environment.

HOL-SDC-1603
Confirm DFW Enablement
First you will explore the NSX Distributed Firewall.
If you are not already logged into the vSphere Web Client.
Click on the Taskbar icon for Google Chrome. The home page should be the
vSphere Web Client.
Login by checking the "Use Windows Session Authentication" box

HOL-SDC-1603
Gain screen space by collapsing the right Task Pane
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-SDC-1603
Explore the new NSX Distributed Firewall
Open Installation
1. First click on Installation

2. Click on the Host Preparation tab. The table will show the clusters in the
virtual datacenter
Notice that NSX is installed at the Cluster level, meaning that installation, removal, and
updates all are a cluster level definition. If later a new physical host is added to the
cluster it will have NSX added automatically. This provides a cluster level of networking
and security without fear of a VM migrating to a host without NSX.

HOL-SDC-1603
Configure Rules for Web Application Access
You will now configure Distributed Firewall access to a 3-tier application. The application
has two web servers, and one each of an application and database server. There is also
a Load Balancer servicing the two web servers.
Test 3-tier VM to VM connectivity using Putty
Next you will test communication and access between the network segments and guest
VMs making up the 3-tier application. Your first test will be to open a console to web-
sv-01a and ping the other members.
1. Click on the PuTTY shortcut on the desktop taskbar

2. Select web-01a.corp.local
3. Click on Open

HOL-SDC-1603
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 and 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-SDC-1603
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 "3Tier-Web-App"
Click on Browser Advanced
Click on Advanced

HOL-SDC-1603
Proceed to web-app.corp.local (unsafe)
Click on Proceed to web-app.corp.local

HOL-SDC-1603
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.
The page will return which web server in the Load Balancer pool was contacted.
Refreshing your browser will Round-Robin a connection to another web server

in the Load Balancer pool.

HOL-SDC-1603
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.
Click the browser tab for the vSphere Web Client.

Select Firewall on the left. You will see the Default Section Layer3 on the
General Section.
Examine the Default Rules
1. Expand the section using the "twistie."
Notice the Rules have green check marks. This means a rule is enabled. Rules are
built in the typical fashion with source, destination, and service fields. Services are a
combination of protocols and ports.
The last Default Rule is a basic any-to-any-allow.

HOL-SDC-1603
Explore the Last Default Rule
Scroll to the right and you can see the Action choices for the Default Rule by placing the
cursor in the field for Action:Allow. This will bring up a pencil sign that allows you to
see the choices for this field.
Click on the Pencil Sign.
Change the Last Default Rule Action from Allow to Block
1. Select the Block action choice and select

2. Click OK

HOL-SDC-1603
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.
Select Publish Change to save your block rule.
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.
Web browser: Open the tab for the "SSL-Offload-web-A..." and refresh your
browser. You will get an error.
Create 3-Tier Security Groups
Click on the browser tab for vSphere Web Client then Click on Service
Composer.

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

HOL-SDC-1603
2. Select Next
3. Click Next to move to the "Select objects to include" section

HOL-SDC-1603
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-SDC-1603
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.
On the left hand menu, choose Firewall.
Add New Rule Section for 3-Tier Application
1. On the far right of the "Firewalling without VMTools (Rule1)" row click on Add
Section which looks like a folder
2. Name the section 3-tier App
3. Click OK

HOL-SDC-1603
Add Rule to New Section
On the row for the new "3-tier App" section click on the Add rule icon which is a
green plus-sign.
Edit New Rule
1. Click the "twistie" 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
3. Enter "Ext to Web" for the name
4. Click OK
Set Rule Source and Destination
Source:Leave the Rule Source set to any.
Hover the mouse pointer in the Destination field and select the Destination
pencil sign.

HOL-SDC-1603
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

HOL-SDC-1603
Set Rule Service
Again hover in the Service field and click on the pencil sign.
1. In the search field you can search for service pattern matches. Enter "https"and
press enter to see all services associated with the name https
2. Select the simple HTTPS service
3. Click on the top arrow
4. Note: Repeat the above steps 1-3 to find andadd SSH. (You will see later in
the module that we need SSH.)
5. Click OK
Note: This will cause the green bar with the option to publish or revert changes.
DO NOT Publish yet, as you have more rules to make.
Create Rule to Allow Web Security Group Access to App

Logical Switch
You will now add a second rule to allow the Web Security Group to access the App
Security Group via the App port.
1. Start by opening the pencil sign

HOL-SDC-1603
2. You want this rule to be processed below the previous rule so choose Add Below
from the drop down box
Create Second Rule Name and Source fields
1. As you did before hover the mouse over the Name field and click the plus-sign.
Enter "Web to App" for the name
2. Choose Web-tier Security Group for the Source field
Create Second Rule Destination field: Choose Logical

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

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

HOL-SDC-1603
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.
Click the plus sign for the Service field.
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-SDC-1603
Click OK
Click OK

HOL-SDC-1603
Create Third Rule: Allow Logical Switch App to Access

Logical Switch Database
Repeating the steps: On your own create the third and last rule giving access between
the App-tier and the Database-tier.
1. Create the final rule allowing the App Logical Switch to communicate
with the Database Logical Switch via the predefined service for MySQL. The
service is predefined so you will only have to search for it rather than create it.
2. Publish Changes

HOL-SDC-1603
Verify New Rule Allow 3-Tier Application Communication
Open your browser and return to the tab you used previously for the
Web App. Refresh the browser to show you are getting the data via the 3-tier
app.
NOTE : If you do not have a tab already open, or you closed the previous one. Use the
"Web-App Direct Connect" favorite in the favorite bar.

HOL-SDC-1603
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.
Note: Remember to use the SEND TEXT option.
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.

HOL-SDC-1603
Minimize Putty Session to web-01a.

HOL-SDC-1603
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-SDC-1603
Identity Based Firewalling

Identity Base Firewall Rules
The NSX suite now provides you the ability to create rules using Active Directory
Groups. This allows you to control the access of users to other security objects such as
networks, IP addresses, and other security groups.
Before you begin creating User based rules you need to link NSX to an Active Directory.
Explore Link between NSX and Active Directory
On the left go down to the NSX Managers. Notice it denotes only one.
Click on NSX Managers.

HOL-SDC-1603
Choose NSX Manager
Click on 192.168.110.15
Explore Domain Connector
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.
1. Click on Manage tab

2. Click on Domains tab
3. Click on corp.local
4. Click on Pencil to edit

HOL-SDC-1603
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
Provide LDAP Options
Here you will complete the configuration.
1. Enter 192.168.110.10 for the address of AD Server

2. Enter Administrator for the User name
3. Enter VMware1! for the password
4. Click Next
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

HOL-SDC-1603
3. Click Next

HOL-SDC-1603
Ready to Complete - Verify Settings
Now you would verify all your settings.
Click Finish

HOL-SDC-1603
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.
With a configured and synchronized AD connection you are ready to make use of the AD
Groups in your security policies.
Create a Security Object based on AD Groups
1. Click on Networking & Security. This is the history button

HOL-SDC-1603
Edit Ext to Web Rule
You are going to add a Domain Group to the Source field of the Ext to Web rule.
1. Click on Firewall
2. Hover on to source field and click on the pencil sign
3. Select Security Group in the Object Type pull-down
4. Click on New Security Group
Name New Security Group - AD Sales
1. Enter AD-Sales for the name

2. Click on Select objects to include
Select Objects to include
1. Select "Entity" from the drop-down

HOL-SDC-1603
2. Select "Belongs to"

3. Click to open "Select Entity" window
4. Select type "Directory Group"
5. Type "sales" in search box
6. Select "Sales"
7. Click on "OK"
8. Click on "Finish"

HOL-SDC-1603
Click Ok on Settings.
Click OK

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

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

2. Click on the VMs and Templates

HOL-SDC-1603
Open Console to win8-01a
Expand the containers "Hands on Labs" and "Discovered virtual machines" to find
win8-01a
1. Expand Misc VMs

2. Right Click on "win8-01a"
3. Click on "Open Console"

HOL-SDC-1603
Login in as NonSales
1. Send Ctrl-Alt-Del. Use the console button.

2. Click the Left Arrow
3. Choose Other user
4. Enter User name = nonsales
5. Password = VMware1!
6. Click on the arrow

HOL-SDC-1603
Open Internet Explorer
Start Internet Explorer from the Task Bar.
Click on the Favorite, "HOL-Multi-TierAPP"
User nonsales is not part of the AD-Sales Group an is blocked from accessing the 3-tier
application.

HOL-SDC-1603
Log Off as nonsales
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"

HOL-SDC-1603
Login as Sales1
1. Enter Sales1 for the User name. Password is VMware1!

2. Click on the arrow

HOL-SDC-1603
Use IE and access 3-tier Application
Open IE from the Taskbar.
1. Click on the "HOL - Muti-Tier App" Favorite

2. Accept the risk

HOL-SDC-1603
Verify Access
User Sales1 is a member of the AD-Sales group and allowing access to the 3-tier
application.
You can close the console to win8-01a

HOL-SDC-1603
Prepare Lab for the next section
Click on the browser tab for the vSphere Web Client
2. In the first rule hover over the Source field object AD-Sales. Click on the
red-X to delete the object and reset the field to "any"
Prepare the lab for the next section - Set Default Rule to
Allow
1. Set the Default Rule in the Default Section to have an Action of Allow
2. Publish Changes
This will allow the next section to function properly.

HOL-SDC-1603
Improved IP Discovery Mechanism for

Virtual Machines and SpoofGuard
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 even
without VMtools.
VM Linux-01a used in this exercise has no VMtools installed and therefore NSX
Distributed firewall can not discover IP addresses for objects without using the new
feature.
You will first test access to VM Linux-01a without VMtools and verify that pre-
configured reject rule does not prevent access to the VM. This is due to lack of
learned IP address as there are no VMtools installed
You wil then enable the new feature which will enable discovery of IP address for
Linux-01a without VMtools
Now the pre-configured reject rule that prevents access to Linux-01a will work
and you will not be able access the VM.
Review Existing Firewall Rules
1. Click on the Home Icon


HOL-SDC-1603
View the rules
2. Click on horizontal arrow to expand "Firewalling-without-VMTools"
section
Review rule that prevents communication to Linux-01a
The rule "Deny traffic TO Linux-01a" should prevent any traffic to Linux-01a, but in this
case it can not since the NSX Distributed Firewall does not know the IP address of VM
due to lack of VMware tools.
Verify that you can ping Linux-01a from your desktop

despite the "Reject" rule that should have prevented it.
Click on "c:\" icon on bottom bar of your desktop to open a command

window
Ping Linux-01a
Remember to use the SEND TEXT option.

HOL-SDC-1603
Type ping 192.168.100.221 and press "Return"
ping 192.168.100.221
As you can see, you are able to ping Linux-01a, even though the "Reject" rule should
have prevented it. This is because NSX Distributed Firewall does not have an IP address
of Linux-01a and therefore can not prevent the ping.
Enable IP address discovery via ARP Snooping
Go back to vSphere Web Client by clicking on "vSphere Web Client" tab of the browser.
1. Click on SpoofGuard
2. Click on Change

HOL-SDC-1603
Change IP detection type to ARP Snooping
Now we will enable IP address discovery with "ARP Snooping" instead of

VMware tools which are not installed on this VM
1. Check ARP Snooping

2. Click on OK
Ping Linux-01a again to verify that now the "reject" rule is

working
Click on minimized command window on the desktop bottom bar to open

it back up

HOL-SDC-1603
Ping Linux-01a again to test connectivity
Remember to use the SEND TEXT option.
Type ping 192.168.100.221 and press "Return". NOTE: You may have to ping twice to
see the rule enforced.
ping 192.168.100.221
Notice, you can no longer ping linux-01a. It is "rejected" by the firewall which is evident
by "host unreachable" in the response.
To conclude, you were able to ping Linux-01a VM at the beginning, even though there is
a rule that should have prevented it .This was the case because NSX firewall did not
know IP address of the VM due to lack of VMtools. After IP address learning was enabled
with ARP Snooping (NSX 6.2 feature), the "REJECT" rule took effect and you could no
longer ping Linux-01a VM.

HOL-SDC-1603
Verify that Linux-01a was discovered via ARP Snooping
1. Click on Default Policy

2. Pick Active Virtual NICs in the View dropdown
3. Enter "lin" and press enter to filter for Linux-01a
Notice that the Source Field denotes ARP for the address 192.168.100.221.
Disable Rule before proceeding.
Explore SpoofGuard
After synchronizing with the vCenter Server, NSX Manager collects the IP addresses of
all vCenter guest virtual machines from VMware Tools on each virtual machine. 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 by VMware Tools 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

HOL-SDC-1603
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

Manually Inspect and Approve All IP Assignments Before Use
This mode allows all traffic from your virtual machines to pass while building a table of
vNIC-to-IP address assignments. You can review this table at your convenience and
make IP address changes. This mode automatically approves all ipv4 and ipv6 address
on a vNIC.
This mode blocks all traffic until you approve 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 you add the network to an existing
policy or create a new policy for it.

HOL-SDC-1603
Edit Default SpoofGuard Policy
1. Click on Default Policy

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

2. Click Finish

HOL-SDC-1603
Locate Linux-01a VM
1. Enter "linux" in the vCenter Search field

2. Click on Linux-01a
Open Console on Linux-01a
Notice there are no VMware tools installed on this VM
1. Click on the "Summary" tab

2. Click on the "Console" to open up a console in new browser tab

HOL-SDC-1603
Login to Linux-01a
1. Login using root for the user

2. Password: VMware1!

HOL-SDC-1603
Change Linux-01a IP Address
You will change the IP Address to see the security enforcement of SpoofGuard.
1. Enter ipswap221-231. As you have seen Linux-01a's current IP Address

is 192.168.100.221. This Linux bash file will change the IP Address to
192.168.100.231.
ipswap221-231

HOL-SDC-1603
Test Linux-01a connectivity
Ping Edge Perimeter Gateway at 192.168.100.3
ping -c 2 192.168.100.3

HOL-SDC-1603
Return to Networking & Security
1. Click the Home Icon

2. Click Networking & Security
3. Click SpoofGuard

HOL-SDC-1603
Linux-01a IP Address of 192.168.100.231
1. Change the view to "Active Virtual NICs Since Last Publish".

2. Note that Linux-01a is now reported with the address of
192.168.100.231 and is Source as "Trusted On First Use-ARP"
(TOFUARP).

HOL-SDC-1603
Change Linux-01a IP
Open the console to Linux-01a.

Enter ipswap231-221 to change the IP Address back to 192.168.100.221.
ipswap231-221
You will see the IP change.

HOL-SDC-1603
Test Connectivity
Ping the Edge again.
ping -c 2 192.168.100.3
Now you will see that your ping fails.

HOL-SDC-1603
Approve Linux-01a new IP Address
1. Change the View to Virtual NICs IP Required Approval.

2. Enter "lin" in the Filter Field and press enter. You will see the IP Address
192.168.100.221 learned from ARP Snooping is now requiring Approval.
3. Click Approve.
Publish IP Approval
Click on Publish Changes
Verify IP Approval allows network connectivity
Ping Edge again to verify IP Approval
ping -c 2 192.168.100.3

HOL-SDC-1603
And now you see that your approval of 192.168.100.221 now allows network
connectivity.

HOL-SDC-1603
Module 4 - Edge Services

Gateway (30 min)

HOL-SDC-1603
DHCP Relay
This lab will cover the DHCP Relay functionality within NSX and will take approximately
15 minutes to complete.
In a network where there are only single network segments, DHCP clients can
communicate directly with their DHCP server. DHCP servers can also provide IP
addresses for multiple networks, even ones not on the same segment as themselves.
Though when serving up IP addresses for IP ranges outside its own, it is unable to
communicate with those clients directly. This is due to the clients not having a routable
IP address or a gateway that they are aware of.
In these situations a DHCP Relay agent is required in order to relay the received
broadcast from DHCP clients by sending it to the DHCP server in unicast. The DHCP
server will select a DHCP scope based upon the range the unicast is coming from,
returning it to the agent address which is then broadcasted back to the original network
to the client.
Areas to be covered in this lab:
Create a new network segment within NSX.

Enable the DHCP Relay agent on the new network segment.
Using a pre-created DHCP scope on a DHCP server that is on another network
segment, which that requires layer 3 communication.
Then network boot ( PXE ) a blank VM via DHCP scope options.
In this lab the following items have been pre-setup
Windows Server based DHCP Server, with appropriate DHCP scope and scope
options set.
TFTP server for the PXE boot files: This server has been installed, configured, and
OS files loaded.

HOL-SDC-1603
Lab Topology
This diagram lays out the final topology that will be created and used in this lab module.
Access vSphere Web Client
Bring up the vSphere Web Client via the icon on the desktop labeled,
GoogleChrome.

HOL-SDC-1603
Log into vSphere Web Client
Log into the vSphere Web Client using the Windows session authentication.
1. Click Use Windows session authentication - This will auto fill in the
credentials of administrator@corp.local / VMware1!
2. Click Login
Access NSX Through the Web Client
Access the Networking & Security section of the Web Client
Click Networking & Security in the left pane.
Create New Logical Switch
We must first create a new Logical Switch that will run our new 172.16.50.0/24 network.

HOL-SDC-1603
1. Select Logical Switches

2. Click the Green Plus Sign sign to create a new Logical Switch

HOL-SDC-1603
Enter New Switch Parameters
In order to configure the Logical Switch, we must set the name and transport zone.
Transport Zone, click Change

HOL-SDC-1603
Select Transport Zone
1. Select Local-Transport-Zone-A
2. Click OK

HOL-SDC-1603
Enter New Switch Parameters
1. Name = DHCP-Relay - The name does not specifically matter, but it is used to
help identify the switch.
2. Click OK

HOL-SDC-1603
Connect Logical Switch to Perimeter Gateway
We will now attach the logical switch to an interface on the Perimeter Gateway. This
interface will be the default gateway for the 172.16.50.0/24 network with an address of
172.16.50.1.
1. Click NSX Edges in the left pane.

2. Double Click edge-2 which is the Perimeter-Gateway in this lab.

HOL-SDC-1603
Add Interface
This section will attach the logical switch to an interface on the Perimeter Gateway.
1. Click Manage
2. Click Settings
3. Click Interfaces
4. Select vnic9
5. Click the Pencil Icon to edit interface

HOL-SDC-1603
Select What Logical Switch Interface is Connected to
We will select what Logical Switch the interface is connected to.
Click Select
Select Newly Created Logical Switch
Select the new Logical Switch that we just created in the previous steps.
1. Select DHCP-Relay Logical Switch

2. Click OK

HOL-SDC-1603
Add Interface IP Address
We will add a new IP Address.
Click the Green Plus Sign

HOL-SDC-1603
Configure Interface IP Address
We will assign the new interface an IP Address.
1. Primary IP address = 172.16.50.1

2. Subnet Prefix Length of = 24

HOL-SDC-1603
Complete Interface Configuration
Verify all information and complete the configuration
1. Change the name from vnic9 to DHCP Relay in order to make it easier to
identify later.
2. Click OK
Configure DHCP Relay
Staying inside of the Perimeter Gateway, we must do the global configuration of DHCP
Relay.

HOL-SDC-1603
1. Now click Manage tab

2. Click DHCP button
3. Click Relay section in the left pane
4. Click Edit
DHCP Global Configuration
Within the global configuration of DHCP is where you select the DHCP servers that will
respond to DHCP requests from your guest VMs.
There are three methods by which you can set DHCP Server IPs:
IP Sets
IP Sets are configured from the NSX Manager Global Configuration and allow you to
specify a subset of DHCP servers by creating a named grouping.
IP Addresses

HOL-SDC-1603
You can manually specify IP addresses of DHCP servers in this method.
Domain Names
This method allows you to specify a DNS name that could be a single or multiple DHCP
server addresses.
For the sake of this lab, we will be using a single IP address.
1. IP Addresses = 192.168.110.10 that is the IP of the DHCP server.

2. Click OK

HOL-SDC-1603
Configure DHCP Relay Agent
The DHCP Relay Agent will relay any DHCP requests from the gateway address on the
logical switch to the configured DHCP Servers. We must add an agent to the logical
switch / segment we created on 172.16.50.0/24.
Under the DHCP Relay Agents section, click the Green Plus Sign
Select Perimeter Gateway Interface
Select which interface on the Perimeter Gateway will have the relay agent.
1. Click the vNIC drop down, select the interface we created earlier, DHCP Relay
Internal
2. Click OK

HOL-SDC-1603
Publish Settings to DHCP Relay Settings
We now need to publish all of these changes to the distributed router.
Click Publish Changes
Create Blank VM for PXE Boot
We will now create a blank VM that will PXE boot from the DHCP server we are relaying
to.
1. Click the Home icon

2. Click on Hosts and Clusters

HOL-SDC-1603
Create New VM
1. Expand Datacenter Site A and expand Compute Cluster A

2. Right-click the host named esx-02a.corp.local
3. Select New Virtual Machine
4. Then click New Virtual Machine

HOL-SDC-1603
Configure the New VM
1. Select Create a New Virtual Machine

2. Click Next

HOL-SDC-1603
Name the VM
1. Name = PXE VM
2. Click Next

HOL-SDC-1603
Select Host
Click Next

HOL-SDC-1603
Select Storage
Leave this as default
Click Next

HOL-SDC-1603
Select Compatibility
Click Next

HOL-SDC-1603
Select Guest OS
1. Select Linux under Guest OS Family

2. Select Other Linux (64-bit) under Guest OS Version
3. Click Next

HOL-SDC-1603
Specify Hardware - Remove Hard Disk
We need delete the hard disk that comes default, since we are booting from the
network, the hard disk is not needed. This is because the PXE image is booting and
running completely within RAM.
Move the mouse cursor over New Hard Disk and the X will appear to the right.
Click this X to remove the hard drive.

HOL-SDC-1603
Specify Hardware - Choose Network
We will now select the VXLAN Backed Logical Switch we created earlier, DHCP-Relay.
You can select it here, or alternatively assign the VM to that logical switch. This is done
through the NSX Logical Switch menu by selecting the logical switch and clicking add.
1. Select the network with the words DHCP Relay in it. The entire UUID of the
logical switch may vary from the above screenshot, but only one will have the
DHCP-Relay in it.
2. Click Next

HOL-SDC-1603
Complete VM Creation
Click Finish.

HOL-SDC-1603
Access Newly Created VM
Next we will open a console to this VM, power it up and watch it boot from the PXE
image. It receives this information via the remote DHCP server we configured earlier.
1. Select PXE VM from the left pane

2. Select Summary tab
Power Up VM
Power up the new VM.
Click the Play button

HOL-SDC-1603
Obtaining DHCP from Remote Server
You will note the VM is now attempting to boot and obtain a DHCP address.

HOL-SDC-1603
Image Booting
This screen will appear once the VM has a DHCP address and is downloading the PXE
image from the boot server. This screen will take about 1-2 mins, please move on to the
next step.
Verify DHCP Lease
While we wait for the VM to boot, we can verify the address used in the DHCP Leases.
Go to the desktop of the Control Center, and double-click the icon DHCP.

HOL-SDC-1603
View Leases
We can look to see what address the VM took from the DHCP server.
1. Expand the sections by clicking on the arrows

2. Select Address Leases
3. You will see the address 172.16.50.10 which is in the range we created earlier
View Options
We can also see the scope options used to boot the PXE Image
1. Select Scope Options

2. You will note option 66 & 67 were used
You can now close DHCP.

HOL-SDC-1603
Access Booted VM
Return to the PXE VM console by selecting it from the taskbar.
Verify Address and Connectivity
The widget in the upper right corner of the VM will show statistics, along with the
IP of the VM. This should match the IP shown in DHCP earlier.

HOL-SDC-1603
Verify Connectivity
Because of the dynamic routing already in place with the virtual network, we have
connectivity to the VM upon its creation. You can verify this by pinging it from the
control center.
1. Click the Command Prompt Icon in the taskbar.
2. Type ping 172.16.50.10 and press enter. (Remember to use the SEND TEXT
option.)
ping 172.16.50.10
You will then see a ping response from the VM. You can now close this command
window.
Conclusion
In this lab we have completed the creation of a new network segment, then relayed the
DHCP requests from that network to an external DHCP server. In doing so we were able
to access additional boot options of this external DHCP server and PXE into a Linux OS.
This lab is now completed, thank you for completing the DHCP Relay lab.

HOL-SDC-1603
NSX Edge Services Gateway - Logical

Load Balancing
The NSX Edge Services Gateway can also provide load balancing functionality.
Employing a load balancer is advantageous as it can lead towards a more ideal
resource utilization scenario. Such a scenario includes a more efficient usage of network
throughput, shorter response times for applications, the ability to scale, and can also be
part of a strategy for service redundancy.
TCP, HTTP, or HTTP requests can be load balanced utilizing the NSX Edge Services
gateway, as it can provide load balancing up to Layer 7 of the Open Systems
Interconnection model (OSI).
In this section, you will be creating and configuring a new NSX Edge, then modifying a
pre-made one to perform two kinds of load balancing scenarios:
A "One-Armed" Load Balanced Topology for Web Servers.

Providing SSL Offload to minimize CPU utilization on backend Web Servers.
New Edge Services Gateway - Topology

HOL-SDC-1603
Login to vSphere web client
If you are not already logged into the vSphere Web Client.
Click on the Taskbar icon for Google Chrome. The home page should be the
vSphere Web Client.
1. Check the box for Use Windows session authentication

2. Click Login button

HOL-SDC-1603
Gain screen space by collapsing the right Task Pane.
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-SDC-1603
Open Networking & Security
Click on "Networking & Security"

HOL-SDC-1603
Creating a New Edge Services Gateway
You'll be configuring the one-armed load balancing service on a new Edge Services
Gateway, so to get started with that new Edge creation process, make sure you're in the
Networking & Securitysection of the vSphere Web Client,
1. Click on NSX Edges

2. Click the green plus sign icon

HOL-SDC-1603
Defining Name and Type
For your new NSX Edge Services Gateway, set the following configuration options
1. Enter Name: OneArm-LoadBalancer

2. Click the Next button

HOL-SDC-1603
Configuring admin account
1. Set the password as: VMware1!VMware1!

Defining Edge Size and VM placement
There are four different appliance sizes that one can choose for their Edge Service
Gateway, with the following specifications (#CPUs, Memory):
Compact: 1 vCPU, 512 MB

Large: 2 vCPU, 1024 MB

HOL-SDC-1603
Quad Large: 4 vCPU, 1024 MB

X-Large: 6 vCPU, 8192 MB
You'll be selecting a compact sized Edge for this new Edge Services Gateway, but it's
worth remembering that these Edge Service Gateways can also be upgraded to a larger
size after deployment. To continue with the new Edge Service Gateway creation:
Click thegreen plus sign icon to open the Add NSX Edge Appliance popup
window.

HOL-SDC-1603
Cluster/Datastore placement
1. Select Management and Edge Cluster for your Cluster/Resource Pool

placement
2. Select ds-site-a-nfs01 for your Datastore placement
3. Select a host esx-04-a.corp.local
4. Place in Edges folder
5. Click theOK

HOL-SDC-1603
Confirming Edge Size and Placement
Review your settings/selection of Hands on Labs is selected for the Datacenter

placement, Compact is the chosen size of this new Edge, and the Deploy NSX Edge
checkbox is checked. Once you have confirmed those settings, cl
Click the Next button to move on to giving this new Edge a network adapter.

HOL-SDC-1603
Placing a new network interface on the NSX Edge
Since this is a one-armed load balancer, it will only need one network interface. In this
section of the New NSX Edge process, you will be giving this Edge a new network
adapter and configure it.
Click the green plus sign icon.

HOL-SDC-1603
Configuring the new network interface for the NSX Edge
This is where you will be configuring the first network interface for this new NSX Edge.
1. Name the new interface the name of WebNetwork

2. Check "Internal" as a type
3. Clicking the Select link

HOL-SDC-1603
Selecting Network for New Edge Interface
This one-armed load balancer's interface will need to be on the same network as the
two web servers that this Edge will be providing Load Balancing services.
1. Select the Logical Switch tab to display all logical switches

2. Select the radio button for "Web-Tier-01 - 5001"
3. Click the OK button

HOL-SDC-1603
Configuring Subnets
Next, you'll be configuring an IP address for this interface
Click thesmall green plus sign icon.

HOL-SDC-1603
Configuring Subnets Popup
To add a new IP address to this interface:
1. Enter an IP address of 172.16.10.10

2. Enter a subnet prefix length of 24
3. Click OK

HOL-SDC-1603
Confirm List of Interfaces
Review your settings/selections
Click the Next button to continue
Configuring the Default Gateway
This next section of provisioning a new Edge allows you to configure the default
gateway for this Edge Services Gateway. To configure the gateway:
1. Enter a gateway IP of 172.16.10.1

HOL-SDC-1603

HOL-SDC-1603
Configuring Firewall and HA options
To save time later, you have the ability to configure some default Firewall options, as
well as enable an Edge Services Gateway to run in High Availability (HA) mode. Neither
feature is relevant to this particular section of the module, so to continue, configure the
following:
1. Check the checkbox for Configure Firewall default policy

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

HOL-SDC-1603
Review of Overall Configuration
Click the Finish button to submit your configuration to deploy a new Edge
Services Gateway.

HOL-SDC-1603
Monitoring Deployment
To monitor deployment of the Edge Services Gateway,
Click on the Installing button while the Edge is still being deployed to see the
progress of the installing steps.
Afterwards, you should see the progress of the Edge deployment.

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

Balancer
Double-click the edge-5 (OneArm-LoadBalancer)

HOL-SDC-1603
Navigating to New Edge's Management Page
1. Click Load Balancer sub-tab

2. Click Global Configuration
3. Click the Edit button to go to the Edit Load Balancer global configuration popup
window

HOL-SDC-1603
Edit Load Balancer Global Configuration
To enable the load balancer service;
1. Check the checkbox for Enable Load Balancer


HOL-SDC-1603
Creating a New Application Profile
An Application Profile is how you define the behavior of a typical type of network traffic.
These profiles are then applied to a virtual server (VIP) which then handles traffic based
on the values specified in the Application Profile.
Utilizing profiles can make traffic-management tasks less error prone and more efficient.
1. Click on Application Profiles

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

HOL-SDC-1603
Configuring a New Application Profile HTTPS
For the new Application Profile, configure the following options:
1. Name: OneArmWeb-01
2. Type: HTTPS
3. Check the checkbox for Enable SSL Passthrough This will allow HTTPS to
terminate on the pool server.
4. Click the OK button when you are done
Modify Default HTTP S monitor
Monitors ensure that pool members serving virtual server are up and working. The
default HTTPS monitor would simply do a "GET" at "/". We will modify the default
monitor to do a health check at application specific URL. This will help determine that
not only the pool member server is up and running but the application is as well.
1. Click on "Service Monitoring"

HOL-SDC-1603
2. Click and highlight "default_https_monitor"

3. Click on the pencil icon
4. {2} Type in "/cgi-bin/hol.cgi" for the URL
5. Click on "OK"

HOL-SDC-1603
Create New Pool
A group of servers of Pool is the entity that represents the nodes that traffic is getting
load balanced to. You will be adding the two web servers web-01a and web-02a to a
new pool. To create the new pool, first
1. Click on Pools
2. Click the green plus sign icon to bring up the Edit Pool popup window

HOL-SDC-1603
Configuring New Pool
For the settings on this new Pool, configure the following:
1. Name: Web-Tier-Pool-01
2. Monitors: default_https_monitor
3. Click thegreen plus sign icon
Add members to the pool
1. Enter web-01a as the name

2. Enter 172.16.10.11 as the IP Address
3. Enter 443 for the Port
4. Enter 443 for the Monitor Port
5. Click OK
Repeat above the process to add one more pool member using following
information

HOL-SDC-1603
Name: web-02a
IP Address: 172.16.10.12
Port: 443
Monitor Port: 443

HOL-SDC-1603
Save Pool Settings
Click OK

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

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

HOL-SDC-1603
Configure New Virtual Server
Please configure the following options for this new Virtual Server:
1. Name this Virtual Server Web-Tier-VIP-01.

2. Enter IP address of 172.16.10.10.
3. Select HTTPS as the protocol.
4. Select Web-Tier-Pool-01
5. Click the OK button to finish creating this new Virtual Server

HOL-SDC-1603
Test Access to Virtual Server
1. Click on a blank browser tab

2. Click on the Favorite Bookmark for "One-Arm Load Bala..."
3. Click on "Advanced"

HOL-SDC-1603
Ignore SSL error
Click on "Proceed to 172.16.10.10 (unsafe)"

HOL-SDC-1603
Test Access to Virtual Server
At this time, you should be successful in accessing the one-armed load balancer you just
configured!
Clicking the page refresh button will allow you to see the Round-Robin of the
two pool members.
You may have to click a few times to get the browser to refresh outside of the
browser cache.
Show Pool Statistics
To see the status of the individual pool members:
1. Click on Pools

HOL-SDC-1603
2. Click Show Pool Statistics.

3. Click on "pool-1"
You will see the each member's current status.
Close the window by clicking the X.

HOL-SDC-1603
Monitor (Health Check) Response Enhancement
To aid troubleshooting, now NSX 6.2 LoadBalancer "show ...pool" command will yield
informative description for pool member failures . We will create two different failures
and examine the response using show commands on LoadBalancer Edge Gateway.
Click on the vSphere Web Client brower tab.
1. Type "LoadBalancer" in upper right corner of vSphere Web Client search

box.
2. Click on "OneArm-LoadBalancer-0".
Open Console Load Balancer Console
1. Click on Summary Tab

2. Click on Launch Remote Console
Note: The console will open in new browser tab

HOL-SDC-1603
Login to OneArm-LoadBalancer-0
1. Login using user: admin and password VMware1!VMware1!

HOL-SDC-1603
clipboard.
environment.

HOL-SDC-1603
Examine pool status before failure
Login with username "admin" and password "VMware1!VMware1!"
Type show service loadbalancer pool (Remember to use the SEND TEXT
option.)
show service loadbalancer pool
Note: The status of Pool member web-sv-01a is shown to be "UP"
Start PuTTY
Click on the PuTTY shortcut on the Window's Launch Bar.
SSH to web-sv-01a
1. Scroll down to Web-01a.corp.local

HOL-SDC-1603
2. Select Web-01a.corp.local
3. Click Load
4. Click on Open
Shutdown HTTPD
We will shutdown HTTPS to simulate the first failure condition
Type service httpd stop to shutdown HTTPD.
service httpd stop

HOL-SDC-1603
Loadbalancer console
Type show service loadbalancer pool
Because the service is down, the failure detail shows the client could not establish SSL
session.
Restart HTTPD service
Switch back to the Putty SSH session to 172.16.10.11
{5} Type service httpd start
service httpd start

HOL-SDC-1603
Shutdown web-01a
1. In upper right corner search box of vSphere Web Client type "web-01a"
2. Click on web-01a
Power off web-01a
1. Click on Actions
2. Click on Power
3. Click on Power Off
Click on Yes to confirm.
Console in to LoadBalancer
Select the "OneArm-LoadBalancer" on the application bar.

HOL-SDC-1603
Check the Pool status
Type show service loadbalancer pool
Because now the VM is down, the failure detail shows the client could not establish L4
connection as oppose to L7 (SSL) connection in previous step.

HOL-SDC-1603
Power web-01a on.
Click back to the vSphere Web Client browser tab
1. Click Actions
2. Click Power
3. Click Power On

HOL-SDC-1603
NSX Edge Services Gateway - SSL

Offload on Logical Load Balancer
SSL Offload - Terminate the SSL session on the Load
Balancer
For this next section, you will be introduced to SSL termination into the load balanced
service. This will allow you to terminate the SSL session on the Load Balancer. This will
allow you to use HTTP between the Load Balancer and pool member servers.
You will configure the "edge-1".
1. Click on the Home icon


HOL-SDC-1603
Navigate to Management Page for Perimeter-Gateway
1. Click on NSX Edges

2. Double click on the "edge-2 Perimeter-Gateway" to enter that Edge's
management page
SSL Certificate Generation
You will need to first go through the process of generating a self-signed certificate. To
begin,
1. Click on the Settings button

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

HOL-SDC-1603
Generate Certificate Signing Request
For the parameters of this certificate signing request:
1. For the Common Name AND Organization Name, type in web-app.corp.local

2. Type in VMWorld for the Organization Unit
3. Type in San Francisco for Locality
4. CA for State
5. Select United States [US] for Country
6. Click the OK button to continue

HOL-SDC-1603
Self Sign the Certificate Signing Request
Next you will sign the certificate signing request we generated in the previous step.
1. Click on theActions
2. SelectSelf Sign Certificate
Set Certificate Life Span
1. Enter in 365 for the number of days for this self-signed certificate to be
valid
2. Click OK

HOL-SDC-1603
Verify Self Signed Certificate Creation
You will be able to observe an entry of type Self Signed issued to web-
app.corp.local.
Now that you have a certificate ready to use for SSL termination, it's time to assign this
certificate to a new Application Profile configured for SSL termination.
Create New Application Profile used for SSL Termination
There is an existing Load Balancer Application Profile for SSL-Passthrough listening on

the external Virtual Server. You will create a new Application Profile for SSL-Offload.
1. Click on the Load Balancer tab

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

HOL-SDC-1603
New Application Profile Configuration (SSL Termination)
For this new Application Profile, you will use the following settings:
1. Name: Web-SSL-Term-Profile-01
2. Type: HTTPS
3. Check the box for Configure Service Certificate. This makes the certificate
you created available.
Topology for In Line Load Balancer
To get a better understanding of what you'll be accomplishing, observe the above

topology. From the ControlCenter, you will visit a Virtual Server located at IP Address
192.168.100.4. The Edge Services Gateway at that address will handle SSL
Termination, and forward HTTP packets to web-sv-01a and web-sv-02a.

HOL-SDC-1603
Next, you'll be configuring a new Pool.

HOL-SDC-1603
Create New Pool
1. Click on Pools
2. Click on the green plus icon to bring up the new Pool popup

HOL-SDC-1603
New Pool Configuration
For this new Pool, configure the following parameters:
1. For a name, type in Web-Tier-Pool-02.

2. Click the green plus sign icon to bring up a pop up window where you'll select
the members for this pool.

HOL-SDC-1603
Add web-sv-01 and web-sv-02 as Pool Members
1. Enter web-01a as the name

2. Enter 172.16.10.11 as the IP Address
3. Enter 80 for the Port
4. Enter 80 for the Monitor Port
5. Click OK

HOL-SDC-1603
Save Pool Settings
1. Repeat the above process for:
Name: web-02a
IP Address: 172.16.10.12
Port: 80
Monitor Port: 80
2. Click OK

HOL-SDC-1603
Modify Existing Virtual server for SSL Offload
1. Click on Virtual Servers

2. Click on pencil sign to edit existing virtual server

HOL-SDC-1603
Edit Virtual Server Configuration
This will allow a external client to create an SSL session to be terminated on the Load
Balancer and complete the session using HTTP from the Load Balancer to the pool
member server.
Edit the Virtual Server settings:
1. Select Web-SSLTerm-Profile-01 for the Application Profile

2. Type in Web-Tier-SSL-01 for the name of this Virtual Server
3. Enter 192.168.100.4 for the IP Address
4. Select Web-Tier-Pool-02 for the Default Pool
5. Click the OK button when you're done. At this point you should be ready to test
load balancer functionality
Accept Security Certificate
Click on a blank tab in the browser.
1. Click on "SSL-Offload-Web..." bookmark

HOL-SDC-1603
2. Click on "Advanced"

HOL-SDC-1603
Proceed to the App screen
Click on "Proceed to web-app.corp.local (unsafe)

HOL-SDC-1603
Confirm Load Balancer Functionality
You will get a web page for multi-tier application

HOL-SDC-1603
Module 5 - Service
Insertion and Security
Policies (30 min)

HOL-SDC-1603
Service Composer
Service Composer is a built-in tool that defines a new model for consuming network and
security services; it allows you to provision and assign firewall policies and security
services to applications in real time in a virtual infrastructure. Security policies are
assigned to groups of virtual machines, and the policy is automatically applied to new
virtual machines as they are added to the group.
From a practical point of view, NSX Service Composer is a configuration interface that
gives administrators a consistent and centralized way to provision, apply and automate
network security services like anti-virus/malware protection, IPS, DLP, firewall rules, etc.
Those services can be available natively in NSX or enhanced by third-party solutions.
This module will show you how to dynamically identify and isolate a workload that has
violated PCI (Payment Card Industry) compliance by using Service Composer and native
NSX Data Security feature.
The module has 3 sections:
1. Service Composer
2. Service Insertion
3. Data Security
In Section 1 we will use Service Composer to build Security Groups and Security Policies.
You will learn the creation of Security Groups using both static inclusion and dynamic
inclusion. You will create 2 Security Groups and 2 sets of security policies attached to
the security groups as shown in the diagram below. Security Group "Non-CDE"
(Cardholder Data Environment - the credit card environment where all cardholder
information is processed) will be created by including a single VM "win8-01a". This VM
represents a VM which is not part of the CDE and should not contain any cardholder
data. You will then create a security group named "PCI-Violation" whose members will be
created using a security tag assigned dynamically by data security scan. You will also
create 2 security policies "Non-CDE Security Policy" allowing unrestricted access to/from
"win8-01a" VM and "PCI-Violation Security Policy" for isolating the VM if sensitive data
was found and restrict any communication to/from VM as it violates the PCI regulation.
In Section 2 we will modify the security policy "PCI-Violation Security Policy" to add Data
Security as a service
In Section 3 we will configure data pattern and scope of Data Security scan and
manually scan the VM "win8-01a". We have placed some sensitive information on the
VM. As a result of the scan the VM will be tagged with tag
"vmware.datasecurity.violating" which will match the criteria set for security group "PCI-
VIolation" security group.

HOL-SDC-1603
This module demonstrates the power of Service Composer and how it can be leveraged
to change security posture around a workload or group of workloads and isolates them
without changing the physical location or changing the infrastructure underneath. The
same principles in this module can be leveraged to insert advance security services
from 3rd party vendors.
Note: CDE=Card Data Environment
Scenario Explanation and Diagram

HOL-SDC-1603
Login into vCenter
Click Chrome on the Taskbar.
Login using the Use Windows session authentication checkbox.
Enlarge action pane
To enlarge action panes
1. Click on "x"
2. Click on "x"
3. Click on the pin

HOL-SDC-1603
Select Networking and Security
Click on Networking and Security

HOL-SDC-1603
Create Security Group for Non-CDE workload
1. Click on Service Composer

2. Click on Security Groups
3. Click on plus sign to create security groups
New Security Group (Static Inclusion)
First we will create a static security group that will contain VMs that are not part of card
data environment (CDE)
1. Type name of the security group

2. Optional: Enter the description or take note of the groups purpose.

HOL-SDC-1603
Select Object to include
1. Select Object Type dropdown

2. Scroll down and select Virtual Machine

HOL-SDC-1603
Select Virtual Machine
1. Select "win8-01a"
2. Move it to Selected Objects
3. Click on Finish

HOL-SDC-1603
Create Security Policy for Non-CDE
Click on Security Policies
Continue Creating Security Policy
Click to create a new policy.

HOL-SDC-1603
Continue Creating Security Policy
1. Type Non-CDE Security Policy for the name of the security policy.
2. Click on Firewall Rules.
Create Firewall Rules
Click the Green Plus sign

HOL-SDC-1603
Continue creating Firewall Rule
1. Type Name of the first firewall rule "Allow from Non-CDE to any"
2. Check Allow
3. Check Log
4. Click on "Change" to create allowed services

HOL-SDC-1603
Allow ICMP as a service
1. Check "Select services and service groups"

2. Type "ICMP Echo"in the filter field and press enter.
3. Check "ICMP Echo Reply"
4. Check "ICMP Echo"

HOL-SDC-1603
Allow SMB as a service
1. Type "SMB" in the filter field and press enter

2. Check "SMB"
3. Check "Server Message Block(SMB)"
4. Click OK

HOL-SDC-1603
Click OK to save configuration
Notice that you have (4 selected) from the previous step.
Click Ok.

HOL-SDC-1603
Create Second Firewall Rule
Click on the Green Plus sign to create second firewall rule

HOL-SDC-1603
Continue creating second firewall rule
1. Type the name "Allow ANY to Non-CDE"

2. Check Allow
3. Check Log
4. Click on Change

HOL-SDC-1603
Select Source
1. Check Any as source

2. Click OK

HOL-SDC-1603
Define Services
Click on Change

HOL-SDC-1603
Allow ICMP as a service
1. Check "Select services and service groups"

2. Type "ICMP Echo" in the filter field and press enter
3. Check "ICMP Echo Reply"
4. Check "ICMP Echo"

HOL-SDC-1603
Allow SMB as a service
1. Type "SMB" in the filter field and press enter

2. Check "SMB"
3. Check "Server Message Block (SMB)"
4. Click OK
5. Click OK again on the next screen to save the configuration

HOL-SDC-1603
Finish creating Firewall rules
Click Finish

HOL-SDC-1603
Apply the policy to Security Group
1. Click on Actions
2. Click on Apply Policy

HOL-SDC-1603
Apply policy to security group
1. Check "Non-CDE"
2. Click OK to finish applying
Verification of successful association of security policy to

security group
Verify "Sync Status" changed to "Successful"

Verify "Applied to 1"

HOL-SDC-1603
Return to Firewall
Click on Firewall
Rule creation verification continued
Expand the firewall section "Non-CDE Security Policy" and verify the
rules creation.

HOL-SDC-1603
Check the functioning of the firewall rules
Click on "Command Prompt"
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

HOL-SDC-1603
characters.

HOL-SDC-1603
Verify ICMP and SMB service working on win8-01a
1. Type ping win8-01a
ping win8-01a
2. Type net use x: \\win8-01a\c$
net use x: \\win8-01a\c$
3. Type dir x:
dir x:
Check successful "ping" to win8-01a and successful completion of "net use" command.
You can also see the content of directory mapped.

HOL-SDC-1603
Create Security Group for workloads violating PCI

compliance
Click on Service Composer

HOL-SDC-1603
Begin creating new security group
1. Click on Security Groups

2. Click on the Green Plus sign for creating a new security group

HOL-SDC-1603
Create new security group for isolating Non-CDE

workloads carrying sensitive data
1. Type Name "PCI-Violation"

2. Click Next

HOL-SDC-1603
Define dynamic membership
1. Click on drop down

2. Select option Security Tag

HOL-SDC-1603
Specify the name of the tag
1. Type the name of the tag "vmware.datasecurity.violating.PCI"

2. Click Finish
vmware.datasecurity.violating.PCI

HOL-SDC-1603
Create security policy for isolating workloads violating PCI
1. Click Security Policies

2. Click "Create Security Policy" icon
Create new security policy
1. Type Name "PCI-Violation Security Policy"

2. Click on Firewall Rules

HOL-SDC-1603
Begin Creating Firewall rules
Click on the Green Plus sign

HOL-SDC-1603
Create Firewall Rules
1. Type Name "Block PCI-Violation to ANY"

2. Check Block
3. Check Log
4. Click OK

HOL-SDC-1603
Create another Firewall rule
Click on Green Plus sign to create another firewall rule

HOL-SDC-1603
Define the firewall rule
1. Type the Name "Block ANY to PCI-Violation"

2. Click onBlock
3. Click on Log
4. Click on Change

HOL-SDC-1603
Select source for the rule
1. Click Any
2. Click OK

HOL-SDC-1603
Finalize the creation of firewall rule
Click OK to finish creating firewall rule

HOL-SDC-1603
Finish creating security policy
Click Finish
Verify the creation of Security Policy
1. Verify security policy creation PCI-Violation Security Policy

2. Verify Sync Status Successful

HOL-SDC-1603
Apply the security policy to security group
1. Click on Actions
2. Select Apply Policy

HOL-SDC-1603
Apply the security policy
1. Select "PCI-Violation"
2. Click OK
Verify the creation of firewall rules in global table
Click on Firewall

HOL-SDC-1603
Rule creation verification continued
Expand the firewall section "PCI Violation Security Policy" and verify the
rules creation
In this section we will not be able to check the security policy enforcement as there are
no workloads as of now that violate the PCI requirements.
In the next section we will use service insertion to enhance the security and insert Data
Security as a service to identify workloads which have violated PCI regulations.

HOL-SDC-1603
Service Insertion
NSX network virtualization platform provides L2-L4 stateful firewalling features to
deliver segmentation within virtual networks. In some environments, there is a
requirement for more advanced network security capabilities. In these instances,
customers can leverage VMware NSX to distribute, enable and enforce advanced
network security services. In this section we will insert the native Data Security service
which will help us identify credit card data in a Non-CDE(Card Data Environment)
workload. Data Security feature requires the installation of Guest Introspection and Data
Security Service VM's prior to identify sensitive information stored in virtual workloads.
In this section we will install Data Security Service VM and add NSX Data Security to the
Service Deployments making it available for use. Next you will be modifying the
existing Security Policy "Non-CDE Security Policy" which was created in previous section
and insert the Data Security as a service.
Add Data Security as Service Deployment
Go to the Installation tab to install Data Security.
1. Click on Installation
2. Click on Service Deployments
3. Click on Green Plus sign

HOL-SDC-1603
Select VMWare Data Security
1. Check the box for VMware Data Security

2. Click Next

HOL-SDC-1603
Select Cluster
1. Check the box for Compute Cluster B

2. Click Next

HOL-SDC-1603
Set Network for Management
1. Select "vds_site_a_Management Network"

2. Click Next
3. Click Finish
Confirm Data Security Deployment Success
It will take just a few minutes to deploy Data Security to your cluster. (approximately 3
minutes)

HOL-SDC-1603
Modify Security Policy to add Data Security
1. Click on "Service Composer"

2. Click on "Security Policies"
3. Select security policy "Non-CDE Security Policy"
4. Click the icon shown in screenshot to edit the security policy
Edit Security Policy and Insert Data Security Service
Click on "Guest Introspection Services"

HOL-SDC-1603
Add Guest Introspection Service
Click on the Green Plus sign

HOL-SDC-1603
Create the Guest Introspection Service
1. Name the Service "Data Security"

2. Set Enforce to Yes.
3. Click "OK".

HOL-SDC-1603
Verify creation of Data Security Service
Click "Finish"
That's all was required to insert the Data Security service. In the next section we will
configure the data pattern to look for in a workload and also the scope of the scan

HOL-SDC-1603
Data Security
VMware NSX Data Security scans and analyzes data on your Virtual Machines and will
report the number of violations detected, as well as what files violated your policy. It
essentially provides visibility into any sensitive data that is in your environment. Based
on the violations reported by NSX Data Security, you can ensure that sensitive data is
adequately protected and assess compliance with regulations around the world.To begin
using NSX Data Security, you create a policy that defines the regulations that apply to
data security in your organization and specifies the areas of your environment and files
to be scanned. A regulation is composed of content blades, which identify the sensitive
content to be detected. NSX supports PCI, PHI, and PII related regulations only.
When you start a Data Security scan, NSX analyzes the data on the virtual machines in
your vSphere inventory and reports the number of violations detected and the files that
violated your policy.In this section we will configure Data Security, select the pattern we
want to identify on the workload and also do a scan to determine any sensitive data
matching the pattern resident on the VM in our scenario which is "win8-01a". In our case
we have shown you a PCI example but you can select from a vast list of regulations as
well create your own custom patterns using wild cards.
Configure Data Security
1. Click on "Data Security"
Manage Data Security
1. Click on "Manage"

HOL-SDC-1603
2. Click on "Edit"
View All Regulatory Templates
Click "All" to view all the templates.
There are over 90 templates covering Regulations, States, and Countries.

HOL-SDC-1603
Filter for and Select PCI-DSS template
1. Enter "PCI" in the filter field and press enter (The filter field is case-
sensitive)
2. Check the box
3. Click "Next"

HOL-SDC-1603
Finish selecting the regulation and standard
Click on "Finish" to set the data pattern

HOL-SDC-1603
Publish the change
Click "Publish Changes".
Start the Data Security Scan
Click on the "Start" button.

HOL-SDC-1603
Monitor the Data Security Scan.
Notice the Status changes to "In Progress". Also "Stop" and "Pause" buttons show up
Click on "Monitor"

HOL-SDC-1603
Check the progress of security scan
Scan Status shows "In Progress" and also the color changed to turquoise.
A typical scan takes anywhere from 3-7 minutes depending on the scope of
scan.

HOL-SDC-1603
Scan completion
Once the scan is completed the color will change to purple. Notice under "View
Regulations Violated Report", it shows the violation type PCI-DSS and under "View VM's
Regulations Report", it shows the VM name that has violated the PCI regulations.

HOL-SDC-1603
Complete scan report
Click on Reports
See under "Regulations Violated" PCI-DSS and Count is 1. In order to see the files which
have violated the regulation click on the drop down menu "View Report"
View Report
Select Violating files

HOL-SDC-1603
Detailed Report
Selecting the "Violating files" option wil give detail about the violating workload, name
of the VM,cluster information,location of the file,when was the file modified etc.
Canvas View
Click on Service Composer
Violating VM show up in "PCI-Violation" security group
1. Click on "Canvas"
2. Under "PCI-Violation", click on icon as shown in the screenshot

HOL-SDC-1603
As a result of violation, the violating VM "win8-01a" shows up in "PCI-Violation" security

group. Next we will check the Tag enforcement on VM

HOL-SDC-1603
Checking the tag enforcement
1. Mouse over "home" icon

2. Click on "VMs and Templates"

HOL-SDC-1603
Verifying the tag enforcement on workload
1. Expand the view

2. Click on "win8-01a"
3. See in the "Security Tags" section enforcement of the tag

HOL-SDC-1603
Check the functioning of the firewall rules
Click on "Command Prompt"
Verify the functioning of security policy applied on PCI-

Violation security group
1. Type ping win8-01a
ping win8-01a
2. Enter net use Notice that the existing net use for X: still exists but,
net use
3. Enter dir x: You will see that nothing returns.
dir x:

HOL-SDC-1603
In the previous section you were able to ping win8-01a VM, after the violation ping is
blocked. Also the "net use" command errors out. This has happened as a result of
dynamic tag enforcement and using the tag to enforce security policy which restricts
access to the workload. In a real world scenario, you might want to allow administrative
access to the workload to do further forensics. To keep it simple we have restricted all
the access.
Possibilities around the NSX Service Composer are tremendous; you can create an
almost infinite number of associations between security groups and security policies to
efficiently automate the how security services will be consumed in the software-defined
data center.

HOL-SDC-1603
Module 6 - Monitoring
and Visibility (45 min)

HOL-SDC-1603
Traceflow
VMware NSX 6.2 brings new features to assist you in monitoring the virtual network as
well as increased visibility of the packet for troubleshooting. New to 6.2 is Traceflow
which allows you to follow a packet in its path from source to destination. Flow
monitoring will allow you to monitor flows between source and destination allowing you
to correlate to firewall rules. Activity Monitoring will allow you to monitor what
applications users are using in your virtual environment.
Launch web browser
Click on Chrome browser icon.
Login to vCenter
1. Check the Use Windows session authentication box

2. Click Login

HOL-SDC-1603
Open Networking & Security
Click on Networking & Security

HOL-SDC-1603
Launch Traceflow
From the Networking & Security section in the vSphere Web Client,
scroll down to Tools and select Traceflow.
Traceflow is a new feature in NSX 6.2 and allows for the ability to inject packets into the
vNIC without using the guest VM's OS and trace the packets through the network to the
destination vNIC again without using the destination OS. This enhances your
operational and troubleshooting capabilities by helping you to identify problems
between the virtual and physical network. It also allows for separation of duties as now
a network engineer can trace packets between a source and destination without the
need to have access to the guest VMs OS. Supporting both L2 and L3 traceflow you
can see where packets get dropped when troubleshooting connectivity problems. This
allows you to quickly identify problems and pinpoint an issue in the NSX data path.

HOL-SDC-1603
Setup a Traceflow process - Configure Source
1. Click on Select
2. Double click on web-01a as our source VM

HOL-SDC-1603
Setup a Trace process - Select vNIC
1. Click on web-01a's network adapter.

2. Click OK

HOL-SDC-1603
Setup a Traceflow process - Configure destination
1. Click on the Destination link "Select"

2. Click the radio button to Select Destination vNIC

HOL-SDC-1603
Select Destination VM
Double click on web-02a

HOL-SDC-1603
Destination Config (continued)
1. Highlight and select the vNIC associated with web-02 and click ok
2. Click ok again to complete this part of the config

HOL-SDC-1603
Complete Traceflow config using ICMP and Start Trace
1. Expand the Advanced Options section

2. From the Protocol dropdown, select ICMP
3. Click Trace

HOL-SDC-1603
Observe Traceflow output
The output shows the packet flow from the VMs vNIC, through the distributed firewall,
across the physical network from esx-01a to esx-03a back through the distributed
firewall and with the packet being delivered to the vNIC of the destination VM. Note:
There are no firewall rules configured yet, but the VM traffic flows through the Firewall
Module but is open at this point.
You can use control-C to stop the ping traffic in your Putty session. Keep the
Putty window open or minimize it for use in a follow on step.

HOL-SDC-1603
Create a Firewall Rule to block ICMP between

web-01a.corp.local and web-02a.corp.local
1. Navigate to the Firewall section of the Network & Security Section of

the Web Client and select Firewall
2. Expand the Default Section Layer 3 Section
3. Right click in the gray area of the Default Section Layer 3 area and
select Add rule
Firewall Rule Name Rule
1. Hover in the name field and click the pencil

2. Enter the name Traceflow Test for the rule name
3. Click OK

HOL-SDC-1603
Firewall Rule Select Source
1. For the Source, click the pencil icon

2. Select Virtual Machine as the object type
3. Select web-01a
4. Click the Right Arrow
5. Click OK
Set Firewall Rule Destination
Repeat the previous steps for the Destination, selecting web-02a
Firewall Rule Block ICMP traffic
Under the Service column in our Traceflow Test firewall rule, click the
Pencil (Edit) icon.
1. In the Filter box, type ICMP to limit the selection results

HOL-SDC-1603
2. Select all of the ICMP Objects except for the IPV6 Objects. (You can
select the first on and Shift+Click on the last)
3. Click on the right arrow to select these objects
4. Click OK

HOL-SDC-1603
Firewall Rule Specify Action
Note: You may need to scroll over in the Web Client Window so see all of the columns.
1. Select the pencil (Edit) icon in the Action column

2. Select the Block Action. Leave the rest of the settings as they are
3. Click OK

HOL-SDC-1603
Firewall Rule Publish Changes
Publish the Traceflow Test rule

HOL-SDC-1603
Repeat the Traceflow configuration steps above. Start a

new Trace
You will have to reconfigure Traceflow.
1. Click on Traceflow
2. Set the source to web-01a
3. Set the destination to web-02a
4. Select ICMP as the protocol
5. Start the Trace

HOL-SDC-1603
Traceflow Output with Distributed Firewall Rule in place
You can see here that the Firewall rule has blocked the ICMP traffic.

HOL-SDC-1603
Delete the Firewall Rule that was just created
1. Return to the Firewall section

2. Expand the Default Section Layer 3
3. Select the Pencil icon next to the 2 in the "Traceflow Test" rule, or right
click in that area and
4. Select Delete
5. Click OK to Delete the rule number 2
6. Click Publish Changes button and verify that the rule has been deleted
Traceflow Summary
Traceflow is a useful tool for tracing a packet through the NSX data path to determine
where packets may be dropped and to also quickly verify firewall rules.

HOL-SDC-1603
Flow Monitoring
Flow monitoring provides vNIC level visibility of VM traffic flows
Flow Monitoring is a traffic analysis tool that provides a detailed view of the traffic to
and from protected virtual machines. When flow monitoring is enabled, its output
defines which machines are exchanging data and over which application. This data
includes the number of sessions and packets transmitted per session. Session details
include sources, destinations, applications, and ports being used. Session details can be
used to create firewall allow or block rules.
You can view TCP and UDP connections to and from a selected vNIC. You can also
exclude flows by specifying filters.
Flow Monitoring can thus be used as a forensic tool to detect rogue services and
examine outbound sessions.

HOL-SDC-1603
Flow Monitor
Our goal is to determine some interesting data flows within the NSX environment and be
able to take action on the data being collected.
In this case we are interested in HTTP connections being made directly to our Web
Servers (web-01a and web-02a). This is because most traffic to our Web Servers should
be using SSL and should go through the Load Balancer VIP we setup in previous
exercise.
The first step is to Enable Flow monitoring. Then we will simulate HTTP traffic.
Simulate a large number of HTTP connections with Apache Bench by logging into the
console of web-01a and opening a Command Prompt
Select Networking & Security from the left pane of the vSphere Web
Client.

HOL-SDC-1603
Enable Flow Monitoring
1. Select Flow Monitoring

2. Click the Configuration tab
3. Click Enable to enable Flow Monitoring

HOL-SDC-1603
Flow Monitoring
You can see that Flow Collection is now enabled.
IPFix is the IETF's version of Cisco's proprietary Netflow. Navigate through the IPFix area
for your information. We will not be configuring collectors in this lab.
1. Click IPFix

HOL-SDC-1603
IPFix
The Edit button allows you to enable IPFix.

The Green Plus button allows you to configure IPFix Collector addresses. You can
send to multiple collectors and defined ports.
1. After reviewing the IPFix areas, Click Flow Exclusion.
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

HOL-SDC-1603
characters.

HOL-SDC-1603
Generate traffic
We will simulate a large number of HTTP connections by running the Apache Bench tool
from the Control Center to one of our web servers.
We are interested in HTTP connections being made directly to our web servers as they
should be primarily be receiving traffic on the Load Balancer VIP.
Open a command prompt on the Control Center by selecting the command prompt icon
on the bottom tool bar (lower left), and type the following command:
ab -n 12345 -c 10 -w http://172.16.10.11/
This will generate traffic to our web-01a VM.
**Minimize but keep this window open as we will run this same command in a
subsequent step.
Observe traffic flows
From the Networking & Security Section in the vSphere Web Client:
1. Select Flow Monitoring

2. Select the Dashboard tab
3. Select the Top Flows tab to see the top traffic flows
**Please note: It may take a few minutes in this nested lab environment for
the flows to show up in the dashboard. Refresh the browser that you are
running the vSphere Web Client in after a few minutes if you are not seeing
the new flows in the dashboard, or the Details By Service tab. You may also

HOL-SDC-1603
need to refresh the vSphere Web Client by clicking the refresh arrow at the
top of the screen**
HTTP Flows
Highlight the HTTP Service and it will highlight the corresponding line
on the graph.

HOL-SDC-1603
Details By Service
1. To gain more information about the specific protocol (HTTP) traffic

spike, open the Details By Service Tab and select Allowed Flows.1. FYI:
The Details are sorted by Service in descending order of Bytes but
clicking the Column Head will resort by that column or reverse the sort.
2. NOTE: If HTTP traffic does not show up, Click Refresh in the Web Client.
You may also need to refresh your browser.
3. Highlight the TCP - HTTP traffic line to gain more detailed information.
We see that most of the traffic to web-01a (172.16.10.11) is being generated by the
Control Center VM (192.168.110.10).
The Control Center system should not be sending large amounts of HTTP traffic to our
"Production" Web Servers.
We will add a firewall rule to prevent this unwanted flow until we can determine what is
going on and minimize any potential threat.
the flows to show up in the dashboard. Refresh the vSphere Web Client after a
few minutes if you are not seeing the new flows in the dashboard, or Details
By Service tab.**

HOL-SDC-1603
Add FW rule to block unwanted traffic
Select one of the rows with a Flow that has a destination of either web-
sv-01a or 172.16.10.11 as the Destination and click Add Rule.
Reject Traffic
Add a Firewall rule to Reject HTTP traffic to the web-sv-01a from 192.168.110.10. The
Source: 192.168.110.10 and Destination 172.16.10.11 and HTTP Service are pre-
populated for you.

HOL-SDC-1603
1. Enter "Reject HTTP to web-01a" for the name

2. Select the radio button to Reject traffic
3. Click OK
FYI, you can view and modify this rule from the Firewall management pane.

HOL-SDC-1603
Test Rule Command Prompt output
Now confirm that the rule we just added is successful in rejecting the HTTP traffic to our
Web Server.
Re-open the Command Prompt window previously minimized in a step above (or open a
new one) and run the Apache Bench command again:
(Note you can use the up arrow key)
ab -n 12345 -c 10 -w http://172.16.10.11/
(Remember to use the SEND TEXT option.)
This should now fail.
We are using Reject vs Block in this lab as Reject responds with an error message
showing that the traffic has been blocked. Using the Block option, the request will
simply time out
Flow Monitor Showing Blocked Traffic
few minutes if you are not seeing the new flows in the dashboard, or the
Details By Service tab.**
From the Flow Monitoring Section in the Web Client under Network & Security:
1. Navigate to Details By Service and select Blocked Flows

2. Highlight the TCP/HTTP Service and view the output on the bottom
section of the screen
You will see that our Firewall rule has successfully rejected (blocked) the unwanted
traffic.

HOL-SDC-1603
Flow Monitor is a great way to detect traffic anomalies in your environment and mitigate
issues quickly by leveraging the Distributed Firewall power of NSX.

HOL-SDC-1603
Live Flow
You can also use Live Flow to view traffic to/from a particular machine and vNIC.
1. Select the Live Flow tab while in the Flow Monitoring section
2. Click on the Browse link
3. Select web-01a and it's network adapter
4. Click OK

HOL-SDC-1603
Start Live Flow
Click Start
Start Traffic Generator
Open the Command Prompt window.

Press the "Up Arrow" key to replay the last command. In this case the
Apache Bench mark tool.

HOL-SDC-1603
Live Flow Output
You will see every few seconds the blocked HTTP traffic flow. Feel free to experiment
with the various Flow Monitoring options. Also note in the Command window above, that
the firewall rule is blocking the connection attempts.
few minutes if you are not seeing the new flows in the dashboard, or the
Details By Service tab.**
Remove Firewall Rule
1. From the vSphere web client Networking & Security menu select
Firewall
2. Expand Default Section Layer 3
3. Click the pencil for Rule 2
4. Select Delete

HOL-SDC-1603
Confirm Delete FW rule.
Click OK to confirm the deletion of the Firewall Rule.
Publish Changes.
Select Publish Changes and verify the rule was deleted by visually
inspecting the Default Section Layer 3 rules.
Flow Monitoring Summary
Flow monitoring provides us with vNIC level visibility of VM traffic flows
We used the Flow Monitoring traffic analysis tool to provide us with a detailed view of
the traffic to and from a production web virtual machine web-01a. We generated HTTP
traffic to this VM from our Control Center VM. We used Flow Monitoring to easily detect
anomalous traffic, and used it to quickly block the undesired traffic and protect the VM
by easily creating a Distributed Firewall rule.

HOL-SDC-1603
Activity Monitoring
Activity Monitoring provides visibility into your virtual network to ensure that security
policies at your organization are being enforced correctly.
A Security policy may mandate who is allowed access to what applications. The Cloud
administrator can generate Activity Monitoring reports to see if the IP based firewall rule
that they set is doing the intended work. By providing user and application level detail,
Activity Monitoring translates high level security policies to low level IP address and
network based implementation.
Value: Detailed visibility into Applications and Activity on a monitored Virtual

Machine through the Guest Introspection Service.
In order to leverage Activity Monitoring you need to do the following:
Successfully Install NSX and execute Host preparation.

Deploy the Guest Introspection Service to any cluster that will be monitored.
Have updated version of VMware Tools installed on Virtual Machines WITH VMCI
Guest Introspection drivers installed.
Use NSX Security Group Activity Monitoring Data Collection group
NOTE: The above steps have already been completed in our lab environment.
We will configure the following:
Configure data collection on Virtual Machines

Start Activity Monitoring

HOL-SDC-1603
Deploy Guest Introspection - Demonstration.
Guest Introspection Services has already been done for you in this lab on
Compute Cluster B.
-----NOTE: As a demonstration, here are the steps to deploy it for your

information--------
1. From the Networking & Security menu, select Installation

2. Navigate to the Service Deployments tab
3. Note that the Guest Introspection service has already been deployed to
Compute Cluster B
4. To see how Guest Introspection is deployed click onto the green +
5. Select the Guest Introspection check box
6. Click Next

HOL-SDC-1603
Guest Introspection Deployment - Select Clusters
1. At the Select Clusters step, select the check box next to Compute
Cluster A
2. Click Next

HOL-SDC-1603
Guest Introspection Deployment - Select Storage and

Management Network
Here we select the Datastore and Network for the Guest Introspection VM.
Click Next

HOL-SDC-1603
Guest Introspection Deployment - Review Settings
This is where you would review your settings.
----Click Cancel as we will not be deploying this to Compute Cluster A.

This was for illustration purposes only----

HOL-SDC-1603
VMtools is installed on target VMs.
Activity Monitoring requires Updated VMware Tools installed on the target

Virtual Machines and the VMCI Driver Guest Introspection must be installed.
NOTE: This is already completed for you in this lab environment as the
Windows 8 Virtual Machine in Compute Cluster B have updated VMware Tools
installed.
Search for win8-01a
1. Enter win8 in the upper right vCenter search box

2. Click on win8-01a
Enable Data Collection on the Win-08a VM
1. Click on Summary Tab

HOL-SDC-1603
2. Click on Edit in the NSX Activity Monitoring pane

3. Click Yes to Enable Activity Monitoring
Navigate to Networking & Security
1. Click on Home icon


HOL-SDC-1603
Configure Activity Monitoring on a Cluster Example
Note: While we are not configuring this here in this lab, for your additional
information, you can also Configure Activity Monitoring data collection for
Clusters and other groups by selecting objects to include in the Activity
Monitoring Data Collection Security Group in Service Composer.
1. Navigate to the Service Composer Section under the Networking &

Security menu
2. Select the Security Group tab
3. Right click on the Activity Monitoring Security Group.
4. Select Edit Security Group

HOL-SDC-1603
Add Compute Cluster A and B to Selected Objects Example

2. You will see that our win8-01a VM has been included because we
enabled Activity Monitoring on that specific VM
3. Click on the drop down under Object Type. Here you will see the various
Object Types that can be included into the Activity Monitoring Security
Group. For example you can select an entire Cluster, etc. Explore this
section for additional information.
4. ** Hit Cancel when done as this is just an example for your information.
This was for illustration purposes only. **
There are Security Policies already applied to this Security Group that will turn on
Activity Monitoring Data Collection for the member Objects

HOL-SDC-1603
Generate Activity from within the win8-01a VM
1. Click Start button

2. Open an RDP or console session

HOL-SDC-1603
Connect to win8-01a
1. Enter win8-01a.corp.local
2. Click Connect
win8-01a.corp.local
Login
Use the CORP\Administrator account.
Use VMware1! as the password.

HOL-SDC-1603
Launch Internet Explorer
Launch Internet Explorer and click onto the HOL - Multi-Tier-App tab
Accept Risk Warnings
1. Click Continue to this website (not recommended)

2. Click Yes
Open Multi-Tier App Page
You will see the output of our 3-Tier App
For purposes of demonstration of activity, by launching this app in the Win8-01a VM,
you are generating outgoing traffic that we can now monitor with Activity Monitor. You

HOL-SDC-1603
can use Activity monitor to view all activity to/from a given VM and view who is
generating the traffic. This helps you to determine if unwanted traffic is occurring.
1. Click the reduce button to return to desktop

HOL-SDC-1603
Start Activity Monitor
1. From the Networking & Security Section of the Web Client select Activity
Monitoring
2. Select the VM Activity tab
3. Click the Search button
4. Review the output. You can see that the user logged into win8-01a is
Administrator on the corp.local domain and view the activity.
Activity Monitoring Summary
In this section of our lab, we demonstrated how we can use the Activity Monitoring
function within NSX to monitor specific VM traffic to determine if there may be
unwanted traffic types occurring. Should we find traffic that does not meet our security
requirements, we can leverage the Distributed Firewall and Service Composer to protect
our VMs from insecure activities by user.

HOL-SDC-1603
Conclusion
Thank you for participating in the VMware Hands-on Labs. Be sure to visit
http://hol.vmware.com/ to continue your lab experience online.
Lab SKU: HOL-SDC-1603
Version: 20160523-075128

Yash Boss PDF

Încărcat de

Informații document

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

Yash Boss PDF

Încărcat de

Drepturi de autor:

Formate disponibile

HOL-SDC-1603

Lab Overview - HOL-

The Table of Contents can be accessed in the upper right-hand corner.

Lab Module List:

Module 1 - Melanie Spencer

Special Instructions for CLI Commands

First to send a CLI command to the lab console:

Activation Prompt or Watermark

This cosmetic issue has no effect on your lab.

Decoupled Logical Networks

This session/overview of the new technology represents no commitment from

Features are subject to change, and must not be included in contracts,

Technical feasibility and market demand will affect final delivery.

Pricing and packaging for any new technologies or features discussed or

These features are representative of feature areas under development. Feature

Controller Based VXLAN

3) The VXLAN to VLAN bridge function allows users to provide P to V communication as

Login to the vSphere Web Client

1. Login by checking the "Use Windows Session Authentication" box.

Navigate to the Networking & Security Section in the Web

1. Click to open the Networking & Security Section.

Verify the deployed components

The topology after the host is prepared with data path

VXLAN configuration can be broken down into three important steps

Configure Virtual Tunnel Endpoint (VTEP) on each host

View the VTEP configuration

1. Click Logical Network Preparation tab

Computer Cluster A is in 192.168.130.0/24 subnet

The topology after the VTEPs are configured across the

Segment ID and Multicast Group Address Configuration

The final step is defining the span of the logical networks

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

Create a new Logical Switch

1. Click Logical Switches on the left hand side

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

IP Discovery enables ARP Suppression.

Selecting Enable IP Discovery, activates ARP (Address Resolution Protocol) suppression.

Attach the new Logical Switch to the NSX Edge services

1. Highlight the newly created logical switch

Connect the Logical Switch to the NSX Edge

The Edge Services gateway which is named a "Perimeter-Gateway" provides

1. Click the radio button next to Perimeter-Gateway

The NSX Edge services gateway has ten interfaces. You

1. Click the radio button next to vnic5

Name the Interface and configure the IP address for the

1. Name the Interface: Prod_Interface

Assign an IP to the Interface

1. Enter the Primary IP Address 172.16.40.1 (Leave the Secondary IP Address

Complete the interface editing process

The topology after Prod_Logical_Switch is connected to the

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

1. Click to highlight the new Logical Switch that was created

Add Virtual Machines to attach to the new Logical Switch

1. Enter a filter to locate those VM's whose name start with"web"

Add VM's vNIC to Logical Switch

1. Select the vNiCs for the two VMs

Complete Add VMs to Logical Switch

The Topology after the Virtual Machines are connected to

Hosts and clusters view