Beruflich Dokumente
Kultur Dokumente
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
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.
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:
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:
HOL-SDC-1603 Page 4
HOL-SDC-1603
Many of the modules will have you enter Command Line Interface (CLI)
commands. There are two ways to send CLI commands to the lab.
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.
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.
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
Disclaimer
This session may contain product features that are currently under
development.
HOL-SDC-1603 Page 7
HOL-SDC-1603
Module 1 - Logical
Switching (30 min)
HOL-SDC-1603 Page 8
HOL-SDC-1603
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.
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
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. 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 Page 11
HOL-SDC-1603
In the next step, you will look at the VXLAN related configuration steps by selecting the
Logical Network Preparation Tab.
HOL-SDC-1603 Page 12
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)
HOL-SDC-1603 Page 13
HOL-SDC-1603
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 Page 14
HOL-SDC-1603
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.
HOL-SDC-1603 Page 15
HOL-SDC-1603
Click on the Manage tab to show the clusters that are part of this Transport
Zone.
HOL-SDC-1603 Page 16
HOL-SDC-1603
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 Page 17
HOL-SDC-1603
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 Page 18
HOL-SDC-1603
HOL-SDC-1603 Page 19
HOL-SDC-1603
HOL-SDC-1603 Page 20
HOL-SDC-1603
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.
In this example, you are going to connect the logical switch to the NSX Edge services
gateway (Perimeter-Gateway).
HOL-SDC-1603 Page 21
HOL-SDC-1603
HOL-SDC-1603 Page 22
HOL-SDC-1603
HOL-SDC-1603 Page 23
HOL-SDC-1603
HOL-SDC-1603 Page 24
HOL-SDC-1603
1. Click Finish (You will see your new logical switch show up in the logical switch
list)
HOL-SDC-1603 Page 25
HOL-SDC-1603
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 Page 26
HOL-SDC-1603
HOL-SDC-1603 Page 27
HOL-SDC-1603
HOL-SDC-1603 Page 28
HOL-SDC-1603
1. Click Finish
HOL-SDC-1603 Page 29
HOL-SDC-1603
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 Page 30
HOL-SDC-1603
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 Page 31
HOL-SDC-1603
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 Page 32
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 Page 33
HOL-SDC-1603
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 Page 34
HOL-SDC-1603
Note: If you encounter difficulties connecting to web-03a, please review your previous
steps and verify they have been completed correctly.
HOL-SDC-1603 Page 35
HOL-SDC-1603
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 Page 36
HOL-SDC-1603
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 Page 37
HOL-SDC-1603
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.
HOL-SDC-1603 Page 38
HOL-SDC-1603
HOL-SDC-1603 Page 39
HOL-SDC-1603
There are three Options to complete the Bridge. Name the bridge, select the Logical
switch that you want to Bridge onto the Physical Network, then Select the Distributed
Virtual Port Group that is tied to the VLAN you would like to Bridge into Logical space.
4. Click Cancel here as the configuration is not supported in this lab environment.
The configuration is straight forward where we just have to select the logical switch and
a VLAN.
In 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.
HOL-SDC-1603 Page 40
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.
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 Page 41
HOL-SDC-1603
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 Page 42
HOL-SDC-1603
HOL-SDC-1603 Page 43
HOL-SDC-1603
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 Page 44
HOL-SDC-1603
Module 2 - Logical
Routing (60 min)
HOL-SDC-1603 Page 45
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.
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.
Many of the modules will have you enter Command Line Interface (CLI)
commands. There are two ways to send CLI commands to the lab.
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.
HOL-SDC-1603 Page 46
HOL-SDC-1603
Second, a text file (README.txt) has been placed on the desktop of the
environment allowing you to easily copy and paste complex commands or
passwords in the associated utilities (CMD, Putty, console, etc). Certain
characters are often not present on keyboards throughout the world. This
text file is also included for keyboard layouts which do not provide those
characters.
HOL-SDC-1603 Page 47
HOL-SDC-1603
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 Page 48
HOL-SDC-1603
Bring up the vSphere Web Client via the icon on the desktop labeled,
Chrome.
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
HOL-SDC-1603 Page 49
HOL-SDC-1603
Click Advanced
Click on Advanced
HOL-SDC-1603 Page 50
HOL-SDC-1603
HOL-SDC-1603 Page 51
HOL-SDC-1603
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.
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 Page 52
HOL-SDC-1603
HOL-SDC-1603 Page 53
HOL-SDC-1603
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 Page 54
HOL-SDC-1603
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 Page 55
HOL-SDC-1603
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 Page 56
HOL-SDC-1603
HOL-SDC-1603 Page 57
HOL-SDC-1603
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.
We will now begin configuring Distributed Routing by adding the App and DB interface to
the "Distributed Router".
HOL-SDC-1603 Page 58
HOL-SDC-1603
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 Page 59
HOL-SDC-1603
HOL-SDC-1603 Page 60
HOL-SDC-1603
1. Select the "App_Tier_01" radio button which will be the network this interface
will communicate on
2. Click OK
HOL-SDC-1603 Page 61
HOL-SDC-1603
Add Subnets
HOL-SDC-1603 Page 62
HOL-SDC-1603
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.
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 Page 63
HOL-SDC-1603
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 Page 64
HOL-SDC-1603
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
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 Page 65
HOL-SDC-1603
HOL-SDC-1603 Page 66
HOL-SDC-1603
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
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 Page 67
HOL-SDC-1603
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 Page 68
HOL-SDC-1603
Enable OSPF
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.
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 Page 69
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 Page 70
HOL-SDC-1603
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
Click the "Publish Changes" button in the dialog box again to push the updated
configuration to the distributed-edge device.
HOL-SDC-1603 Page 71
HOL-SDC-1603
We can now confirm that we have enabled and configured OSPF on the distributed-
edge. Confirm all information displayed is correct.
Click on"Route Redistribution" to open the main configuration page for route
redistribution.
HOL-SDC-1603 Page 72
HOL-SDC-1603
Verify that there is a check box next to OSPF. This is showing that route
redistribution for OSPF is enabled.
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 Page 73
HOL-SDC-1603
From the main "NSX Edges" page, our configured edge devices are displayed.
HOL-SDC-1603 Page 74
HOL-SDC-1603
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.
We now just need to direct OSPF to communicate over the interface that will
communicate with the Distributed Routers.
HOL-SDC-1603 Page 75
HOL-SDC-1603
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 Page 76
HOL-SDC-1603
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.
HOL-SDC-1603 Page 77
HOL-SDC-1603
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.
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 Page 78
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 Page 79
HOL-SDC-1603
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.
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 Page 80
HOL-SDC-1603
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.
HOL-SDC-1603 Page 81
HOL-SDC-1603
Navigate to Perimeter-Gateway VM
HOL-SDC-1603 Page 82
HOL-SDC-1603
2. Select Perimeter-Gateway
3. Select Summary Tab
4. Click Launch Remote Console
HOL-SDC-1603 Page 83
HOL-SDC-1603
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
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 Page 84
HOL-SDC-1603
Many of the modules will have you enter Command Line Interface (CLI)
commands. There are two ways to send CLI commands to the lab.
1. Highlight the CLI command in the manual and use Control+c to copy to
clipboard.
2. Click on the console menu item SEND TEXT.
3. Press Control+v to paste from the clipboard to the window.
4. Click the SEND button.
Second, a text file (README.txt) has been placed on the desktop of the
environment allowing you to easily copy and paste complex commands or
passwords in the associated utilities (CMD, Putty, console, etc). Certain
characters are often not present on keyboards throughout the world. This
text file is also included for keyboard layouts which do not provide those
characters.
The 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.
HOL-SDC-1603 Page 85
HOL-SDC-1603
Let's now review the content displayed and what it all means.
HOL-SDC-1603 Page 86
HOL-SDC-1603
Press Enter
show ip route
HOL-SDC-1603 Page 87
HOL-SDC-1603
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 Page 88
HOL-SDC-1603
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.
HOL-SDC-1603 Page 89
HOL-SDC-1603
HOL-SDC-1603 Page 90
HOL-SDC-1603
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.
Confirm Delete
Click Yes
Publish Change
HOL-SDC-1603 Page 91
HOL-SDC-1603
**NOTE** Once the window appears, you may need to click inside and press
the enter key to get the screen to appear
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
show ip route
Now you can see that the only routes being learned via OSPF is from the Distributed
Router (192.168.5.2)
HOL-SDC-1603 Page 92
HOL-SDC-1603
Since no routes exist between you control center and the virtual networking
environment, the web app should fail.
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 Page 93
HOL-SDC-1603
Now let's get the route peering between the Perimeter Gateway and the vPod Router
back in place.
HOL-SDC-1603 Page 94
HOL-SDC-1603
Publish Change
HOL-SDC-1603 Page 95
HOL-SDC-1603
**NOTE** Once the window appears, you may need to click inside and press
the enter key to get the screen to appear
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.
show ip route
HOL-SDC-1603 Page 96
HOL-SDC-1603
Show Routes
All routes from the vPod Router (192.168.100.1) are now back in the list.
HOL-SDC-1603 Page 97
HOL-SDC-1603
With the routes back in place, the Web App should now be functional again.
This completes this section of the lab, we will now move on to ECMP and High
Availability with the NSX Edges.
HOL-SDC-1603 Page 98
HOL-SDC-1603
HOL-SDC-1603 Page 99
HOL-SDC-1603
Set Password
NOTE - All passwords for NSX Edges are 12 character complex passwords.
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
Continue Deployment
Click Next
We have to pick the northbound switch interface for this edge, which is a distributed
port group.
We have to pick the northbound switch interface for this edge, which is a VXLAN Backed
Logical Switch.
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
Continue Deployment
Click Next
We are removing the default gateway since we receive that information via
OSPF
2. Click Next
Finalize Deployment
Edge Deploying
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.
Once the status says Deployed you can move on to the next step.
We must now configure OSPF on the new Edge device before we can enable ECMP.
We must set the base configuration to identify the router to the network.
Publish Changes
Click the "Publish Changes" button in the dialog box again to push the updated
configuration to the distributed-edge device.
Enable OSPF
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.
Now the same must be done for the downlink interface to the Distributed Router
NOTE - DO NOT check the Ignore Interface MTU, that is on the uplink only!
Publish Changes
Click the "Publish Changes" button in the dialog box again to push the updated
configuration to the distributed-edge device.
We must now enable OSPF route redistribution in order for the routes to be accessible
through this edge.
Publish Changes
Click the "Publish Changes" button in the dialog box again to push the updated
configuration to the distributed-edge device.
Enable ECMP
We are now going to enable ECMP on both the Distributed Router and the Perimeter
Gateways
Publish Change
Click the Networking & Security back button to return to the previous page.
Publish Change
Click the Networking & Security back button to return to the previous page.
Publish Change
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.
Let's now access the distributed router to ensure that OSPF is communicating and ECMP
is functioning.
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
Username : admin
Password : VMware1!VMware1!
The first thing we will do is look at the OSPF neighbors to the Distributed Router.
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).
show ip route
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.
***NOTE*** To release your cursor from the window, press Ctrl+Alt keys
Now we will look at ECMP from the vPod Router, which simulates a physical router in
your network.
1. Using the Scroll Bar, scroll down and select vPod Router
2. Click Load
3. Click Open
Username : root
Password : VMware1!
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.)
We must telnet into the module that controls OSPF in the vPod Router.
Show Routes
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
At this point, any traffic connected to the distributed router can egress out either of the
perimeter gateways 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.
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.
Confirm Shutdown
Click Yes
On the taskbar, go back to your command prompt running your ping test.
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 the PuTTY session to your vPod Router on the taskbar, named
"192.168.100.1 - PuTTY"
You will note all routes to the 172.16.x.xnetworks are only through the Perimeter-
Gateway-1 (192.168.100.3).
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 the PuTTY session to your vPod Router on the desktop, named
"192.168.100.1 - PuTTY
Show Routes
Let's check the status of the routes on the vPod router since we powered the Gateway
back up.
In section 2, you will see the routes have returned to dual connectivity.
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.
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.
Delete Edge-5
Confirm Delete
Double-click Edge-4
Publish Change
Click the Networking & Security back button to return to the previous page.
Double-click Edge-2
Publish Change
Conclusion
We hope that you have enjoying the routing portion of this lab and have found it helpful
in your understanding of NSX.
Module 3 - Distributed
Firewall (60 min)
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.
Identity Firewall
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.
Many of the modules will have you enter Command Line Interface (CLI)
commands. There are two ways to send CLI commands to the lab.
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.
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.
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.
Open Installation
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.
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.
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.
First you will show that web-01a can Ping web-02a by entering
ping -c 2 172.16.10.12
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.)
Using a browser you will access the 3-tier application to demonstrate the function
between the 3 parts.
Click on Advanced
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.
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.
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.
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.
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.
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.
Click on the browser tab for vSphere Web Client then Click on Service
Composer.
Service Composer defines a new model for consuming network and security services in
virtual and cloud environments. Polices are made actionable through simple
visualization and consumption of services that are built-in or enhanced by 3rd party
solutions. These same polices can be made repeatable through export/import
capabilities, which would help make it easier to stand up and recover an environment
when there is an issue. One of those objects for repeatable use is a Security Group.
2. Select Next
3. Click Next to move to the "Select objects to include" section
Note: As a shortcut you can double-click the VMs on the left and they will move to the
right in this one step.
You have created a security group named Web-tier having 2 VMs assigned.
Next you will add new rules to allow access to the web vm and then set up access
between the tiers.
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
On the row for the new "3-tier App" section click on the Add rule icon which is a
green plus-sign.
Hover the mouse pointer in the Destination field and select the Destination
pencil sign.
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
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.
You will now add a second rule to allow the Web Security Group to access the App
Security Group via the App port.
2. You want this rule to be processed below the previous rule so choose Add Below
from the drop down box
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
In the first rule you used the Web-tier security group as the destination. You could
proceed with the remaining rules in the same fashion. But as you see from the drop-
down you can use several vCenter objects already defined. A powerful time saving
aspect of the integrated vSphere with NSX Security is you can use existing virtual
datacenter objects for your rules rather having to start from scratch. Here you will use a
VXLAN Logical Switch as the destination. This allows you to create a rule to be applied
to any VM attached to this network.
1. Scroll down in the Object Type drop-down and click on theLogical Switch
choice
2. SelectApp_Tier-01
3. Click on the top arrow to move the object to the right
4. Click OK
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 OK
Click OK
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
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.
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.
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.
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.
On the left go down to the NSX Managers. Notice it denotes only one.
Click on 192.168.110.15
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.
For the name field you would enter a name. You would next enter the NetBIOS name
for the domain.
1. Click Next
3. Click Next
Click Finish
AD Synchronization
With a configured and synchronized AD connection you are ready to make use of the AD
Groups in your security policies.
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
Click Ok on Settings.
Click OK
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
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.
Expand the containers "Hands on Labs" and "Discovered virtual machines" to find
win8-01a
Login in as NonSales
User nonsales is not part of the AD-Sales Group an is blocked from accessing the 3-tier
application.
Login as Sales1
Verify Access
User Sales1 is a member of the AD-Sales group and allowing access to the 3-tier
application.
1. Click on Firewall
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
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.
1. Click on Firewall
2. Click on horizontal arrow to expand "Firewalling-without-VMTools"
section
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.
Ping Linux-01a
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.
Go back to vSphere Web Client by clicking on "vSphere Web Client" tab of the browser.
1. Click on SpoofGuard
2. Click on Change
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.
Notice that the Source Field denotes ARP for the address 192.168.100.221.
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
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.
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.
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.
Enable SpoofGuard
Locate Linux-01a VM
Login to Linux-01a
You will change the IP Address to see the security enforcement of SpoofGuard.
ipswap221-231
ping -c 2 192.168.100.3
Change Linux-01a IP
ipswap231-221
Test Connectivity
ping -c 2 192.168.100.3
Publish IP Approval
ping -c 2 192.168.100.3
And now you see that your approval of 192.168.100.221 now allows network
connectivity.
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.
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.
Lab Topology
This diagram lays out the final topology that will be created and used in this lab module.
Bring up the vSphere Web Client via the icon on the desktop labeled,
GoogleChrome.
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
We must first create a new Logical Switch that will run our new 172.16.50.0/24 network.
In order to configure the Logical Switch, we must set the name and transport zone.
1. Select Local-Transport-Zone-A
2. Click OK
1. Name = DHCP-Relay - The name does not specifically matter, but it is used to
help identify the switch.
2. Click OK
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.
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
Click Select
Select the new Logical Switch that we just created in the previous steps.
1. Change the name from vnic9 to DHCP Relay in order to make it easier to
identify later.
2. Click OK
Staying inside of the Perimeter Gateway, we must do the global configuration of DHCP
Relay.
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
Domain Names
This method allows you to specify a DNS name that could be a single or multiple DHCP
server addresses.
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 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
We will now create a blank VM that will PXE boot from the DHCP server we are relaying
to.
Create New VM
Name the VM
1. Name = PXE VM
2. Click Next
Select Host
Click Next
Select Storage
Click Next
Select Compatibility
Click Next
Select Guest OS
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.
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
Complete VM Creation
Click Finish.
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.
Power Up VM
You will note the VM is now attempting to boot and obtain a DHCP address.
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.
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.
View Leases
We can look to see what address the VM took from the DHCP server.
View Options
We can also see the scope options used to boot the PXE Image
Access Booted VM
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.
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.
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.
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:
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.
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.
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,
For your new NSX Edge Services Gateway, set the following configuration options
There are four different appliance sizes that one can choose for their Edge Service
Gateway, with the following specifications (#CPUs, Memory):
You'll be selecting a compact sized Edge for this new Edge Services Gateway, but it's
worth remembering that these Edge Service Gateways can also be upgraded to a larger
size after deployment. To continue with the new Edge Service Gateway creation:
Click thegreen plus sign icon to open the Add NSX Edge Appliance popup
window.
Cluster/Datastore placement
Click the Next button to move on to giving this new Edge a network adapter.
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.
This is where you will be configuring the first network interface for this new NSX Edge.
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.
Configuring Subnets
This next section of provisioning a new Edge allows you to configure the default
gateway for this Edge Services Gateway. To configure the gateway:
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:
Click the Finish button to submit your configuration to deploy a new Edge
Services Gateway.
Monitoring Deployment
Click on the Installing button while the Edge is still being deployed to see the
progress of the installing steps.
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.
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. 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
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.
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
1. Name: Web-Tier-Pool-01
2. Monitors: default_https_monitor
3. Click thegreen plus sign icon
Repeat above the process to add one more pool member using following
information
Name: web-02a
IP Address: 172.16.10.12
Port: 443
Monitor Port: 443
Click OK
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
Please configure the following options for this new 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.
1. Click on Pools
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.
Login to OneArm-LoadBalancer-0
Many of the modules will have you enter Command Line Interface (CLI)
commands. There are two ways to send CLI commands to the lab.
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.
Type show service loadbalancer pool (Remember to use the SEND TEXT
option.)
Start PuTTY
SSH to web-sv-01a
2. Select Web-01a.corp.local
3. Click Load
4. Click on Open
Shutdown HTTPD
Loadbalancer console
Because the service is down, the failure detail shows the client could not establish SSL
session.
Shutdown web-01a
1. In upper right corner search box of vSphere Web Client type "web-01a"
2. Click on web-01a
1. Click on Actions
2. Click on Power
3. Click on Power Off
Console in to LoadBalancer
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.
1. Click Actions
2. Click Power
3. Click Power On
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 need to first go through the process of generating a self-signed certificate. To
begin,
Next you will sign the certificate signing request we generated in the previous step.
1. Click on theActions
2. SelectSelf Sign Certificate
1. Enter in 365 for the number of days for this self-signed certificate to be
valid
2. Click OK
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.
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.
4. Click the OK button
1. Click on Pools
2. Click on the green plus icon to bring up the new Pool popup
Name: web-02a
IP Address: 172.16.10.12
Port: 80
Monitor Port: 80
2. Click OK
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.
2. Click on "Advanced"
Module 5 - Service
Insertion and Security
Policies (30 min)
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.
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.
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.
1. Click on "x"
2. Click on "x"
3. Click on the pin
First we will create a static security group that will contain VMs that are not part of card
data environment (CDE)
1. Select "win8-01a"
2. Move it to Selected Objects
3. Click on Finish
1. Type Non-CDE Security Policy for the name of the security policy.
2. Click on Firewall Rules.
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
Click Ok.
Select Source
Define Services
Click on Change
Click Finish
1. Click on Actions
2. Click on Apply Policy
1. Check "Non-CDE"
2. Click OK to finish applying
Return to Firewall
Click on Firewall
Expand the firewall section "Non-CDE Security Policy" and verify the
rules creation.
Many of the modules will have you enter Command Line Interface (CLI)
commands. There are two ways to send CLI commands to the lab.
1. Highlight the CLI command in the manual and use Control+c to copy to
clipboard
2. Click on the console menu item SEND TEXT
3. Press Control+v to paste from the clipboard to the window
4. Click the SEND button
Second, a text file (README.txt) has been placed on the desktop of the
environment allowing you to easily copy and paste complex commands or
passwords in the associated utilities (CMD, Putty, console, etc). Certain
characters are often not present on keyboards throughout the world. This
text file is also included for keyboard layouts which do not provide those
characters.
ping win8-01a
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.
vmware.datasecurity.violating.PCI
1. Click Any
2. Click OK
Click Finish
1. Click on Actions
2. Select Apply Policy
1. Select "PCI-Violation"
2. Click OK
Click on Firewall
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.
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.
1. Click on Installation
2. Click on Service Deployments
3. Click on Green Plus sign
Select Cluster
It will take just a few minutes to deploy Data Security to your cluster. (approximately 3
minutes)
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
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.
1. Click on "Manage"
2. Click on "Edit"
1. Enter "PCI" in the filter field and press enter (The filter field is case-
sensitive)
2. Check the box
3. Click "Next"
Notice the Status changes to "In Progress". Also "Stop" and "Pause" buttons show up
Click on "Monitor"
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.
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.
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
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
1. Click on "Canvas"
2. Under "PCI-Violation", click on icon as shown in the screenshot
ping win8-01a
2. Enter net use Notice that the existing net use for X: still exists but,
net use
dir x:
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.
Module 6 - Monitoring
and Visibility (45 min)
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.
Login to vCenter
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.
1. Click on Select
2. Double click on web-01a as our source VM
Select Destination VM
1. Highlight and select the vNIC associated with web-02 and click ok
2. Click ok again to complete this part of the config
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.
Under the Service column in our Traceflow Test firewall rule, click the
Pencil (Edit) icon.
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
Note: You may need to scroll over in the Web Client Window so see all of the columns.
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
You can see here that the Firewall rule has blocked the ICMP traffic.
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.
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.
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.
Flow Monitoring
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
IPFix
Many of the modules will have you enter Command Line Interface (CLI)
commands. There are two ways to send CLI commands to the lab.
1. Highlight the CLI command in the manual and use Control+c to copy to
clipboard
2. Click on the console menu item SEND TEXT
3. Press Control+v to paste from the clipboard to the window
4. Click the SEND button
Second, a text file (README.txt) has been placed on the desktop of the
environment allowing you to easily copy and paste complex commands or
passwords in the associated utilities (CMD, Putty, console, etc). Certain
characters are often not present on keyboards throughout the world. This
text file is also included for keyboard layouts which do not provide those
characters.
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/
**Minimize but keep this window open as we will run this same command in a
subsequent step.
From the Networking & Security Section in the vSphere Web Client:
**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
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.
Details By Service
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.
**Please note: It may take a few minutes in this nested lab environment for
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.**
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.
FYI, you can view and modify this rule from the Firewall management pane.
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:
ab -n 12345 -c 10 -w http://172.16.10.11/
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
**Please note: It may take a few minutes in this nested lab environment for
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 the
Details By Service tab.**
From the Flow Monitoring Section in the Web Client under Network & Security:
You will see that our Firewall rule has successfully rejected (blocked) the unwanted
traffic.
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.
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
Click Start
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.
**Please note: It may take a few minutes in this nested lab environment for
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 the
Details By Service tab.**
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
Publish Changes.
Select Publish Changes and verify the rule was deleted by visually
inspecting the Default Section Layer 3 rules.
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.
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.
NOTE: The above steps have already been completed in our lab environment.
Guest Introspection Services has already been done for you in this lab on
Compute Cluster B.
1. At the Select Clusters step, select the check box next to Compute
Cluster A
2. Click Next
Here we select the Datastore and Network for the Guest Introspection VM.
Click Next
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.
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.
There are Security Policies already applied to this Security Group that will turn on
Activity Monitoring Data Collection for the member Objects
Connect to win8-01a
1. Enter win8-01a.corp.local
2. Click Connect
win8-01a.corp.local
Login
Launch Internet Explorer and click onto the HOL - Multi-Tier-App tab
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
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. 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.
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.
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.
Version: 20160523-075128