Hol 1803 01 Net - PDF - en PDF

HOL-1803-01-NET
Table of Contents
Lab Overview - HOL-1803-01-NET - Getting Started with VMware NSX ............................ 2
Lab Guidance .......................................................................................................... 3
Module 1 - NSX Manager Installation and Configuration (15 Minutes) .............................. 9
Introduction........................................................................................................... 10
Hands-on Labs Interactive Simulation: NSX Installation and Configuration - Part
1............................................................................................................................ 12
Hands-on Labs Interactive Simulation: NSX Installation and Configuration - Part
2............................................................................................................................ 15
Module 1 Conclusion ............................................................................................. 16
Module 2 - Logical Switching (30 minutes) ..................................................................... 18
Logical Switching - Module Overview .................................................................... 19
Logical Switching .................................................................................................. 20
Scalability and Availability .................................................................................... 47
Module 2 Conclusion ............................................................................................. 51
Module 3 - Logical Routing (60 minutes)......................................................................... 53
Routing Overview .................................................................................................. 54
Dynamic and Distributed Routing ......................................................................... 56
Centralized Routing............................................................................................... 85
ECMP and High Availability.................................................................................. 104
Prior to moving to Module 4 - Please complete the following cleanup steps ....... 157
Module 3 Conclusion ........................................................................................... 163
Module 4 - Edge Services Gateway (60 minutes).......................................................... 165
Introduction to NSX Edge Services Gateway ....................................................... 166
Deploy Edge Services Gateway for Load Balancer .............................................. 167
Configure Edge Services Gateway for Load Balancer.......................................... 186
Edge Services Gateway Load Balancer - Verify Configuration ............................. 196
Edge Services Gateway Firewall.......................................................................... 209
DHCP Relay ......................................................................................................... 219
Configuring L2VPN .............................................................................................. 245
Native Bridging ................................................................................................... 303
Module 4 Conclusion ........................................................................................... 345
HOL-1803-01-NET Page 1
HOL-1803-01-NET
Lab Overview -
HOL-1803-01-NET -
Getting Started with
VMware NSX
HOL-1803-01-NET
Lab Guidance
Note: It will take more than 90 minutes to complete this lab. You should
expect to only finish 2-3 of the modules during your time. The modules are
independent of each other so you can start at the beginning of any module
and proceed from there. You can use the Table of Contents to access any
module of your choosing.
The Table of Contents can be accessed in the upper right-hand corner of the
Lab Manual.
VMware NSX is the platform for Network Virtualization. You will gain hands-on
experience with Logical Switching, Distributed Logical Routing, Dynamic Routing,
Distributed Firewall and Logical Network Services. This lab introduces the core
capabilities of VMware NSX in vSphere environments used to enable Network and
Security virtualization.
Lab Module List:
• Module 1 - Installation Walk Through (15 minutes) - Basic - This module will
walk you through a basic install of NSX including deploying the .ova, configuring
NSX Manager, deploying controllers and preparing hosts.
• Module 2 - Logical Switching (30 minutes) - Basic - This module will cover the
creation of logical switches and add virtual machines to the logical switches.
• Module 3 - Logical Routing (60 minutes) - Basic - This module will demonstrate
the dynamic and distributed routing capabilities supported on the NSX platform
by providing routes between a 3-tier application.
• Module 4 - Edge Services Gateway (60 minutes) - Basic - This module will
showcase the capabilities of the Edge Services Gateway by providing common
services such as DHCP, VPN, NAT, Dynamic Routing, Load Balancing and Physical
to Virtual Bridging.
Lab Captains:
• Module 1 - Michael Armstrong, Senior Systems Engineer, United

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

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

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

Installation and
Configuration (15
Minutes)
HOL-1803-01-NET
Introduction
VMware NSX is the leading network virtualization platform that delivers the operational
model of a virtual machine for the network. Just as server virtualization
provides extensible control of virtual machines running on a pool of server hardware,
network virtualization with NSX provides a centralized API to provision and configure
many isolated logical networks that run on a single physical network.
Logical networks decouple virtual machine connectivity and network services from the
physical network, giving cloud providers and enterprises the fexibility to place or
migrate virtual machines anywhere in the data center while still supporting layer-2 /
layer-3 connectivity and layer 4-7 network services.
Within this module we will be using an Interactive Simulation to focus on how to perform
the actual deployment of NSX within your environment. Within the lab environment the
actual deployment has already been completed for you.
In the Interactive Simulation, you will see how to:
• Deploying the NSX Manager OVA

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

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

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

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

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

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

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

2. Click Networking & Security.
View the deployed components
1. Click Installation.
2. Click Host Preparation.
HOL-1803-01-NET
You will see that the data plane components, also called network virtualization
components, are installed on the hosts in our clusters. These components include the
following: Hypervisor level kernel modules for Port Security, VXLAN, Distributed Firewall
and Distributed Routing.
Firewall and VXLAN functions are configured and enabled on each cluster after the
installation of the network virtualization components. The port security module assists
the VXLAN function while the distributed routing module is enabled once the NSX edge
logical router control VM is configured.
The topology after the host is prepared with data path

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

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

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

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

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

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

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

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

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

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

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

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

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

blank).
2. Enter 24 for the Subnet Prefix length.
3. Verify your settings are correct and click Next.
HOL-1803-01-NET
Complete the interface editing process
1. Click Finish.
HOL-1803-01-NET
The topology after Prod_Logical_Switch is connected to the

NSX Edge services gateway
After configuring the logical switch and providing access to the external network, it is
time to connect the web application virtual machines to this network.
HOL-1803-01-NET
Go to Hosts and Clusters
1. Click Home icon.

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

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

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

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

Prod_Logical_Switch
1. Click on the Home icon.

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

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

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

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

HOL-1803-01-NET
Expand the Clusters
• Expand RegionA01-COMP01 and RegionA01-COMP02. You should see that

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

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

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

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

ping by IP address.
If you see DUP! packets, that is due to the nature of VMware's nested lab environment.
This will not happen in a production environment.
Do not close your Putty Session. Minimize the window for later use.
HOL-1803-01-NET
Scalability and Availability

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

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

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

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

Kingdom
HOL-1803-01-NET
How to End Lab
To end your lab, click on the END button.
HOL-1803-01-NET
Module 3 - Logical
Routing (60 minutes)
HOL-1803-01-NET
Routing Overview
Lab Module Overview
In the previous module, we experienced the ease and convenience of creating isolated
logical switches/networks with a few clicks. To provide communication across these
isolated logical layer 2 networks, routing support is essential. In the NSX platform, the
distributed logical router allows you to route traffic between logical switches and the
routing capability is distributed in the hypervisor. By incorporating this logical routing
component, NSX can reproduce complex routing topologies in the logical space. For
example, a three-tier application will be connected to three logical switches and the
routing between the tiers handled by this distributed logical router.
This module will help us understand some of the routing capabilities supported in the
NSX platform and how to utilize these capabilities while deploying a three-tier
application.
In this module, we will be doing the following:
• Examine traffic flow when the routing is handled by an external physical router or
NSX Edge Services Gateway.
• Configure the Distributed Logical Router and it's Logical Interfaces (LIFs) to
enable routing between app-tier and db-tier of the 3-tier application.
• Configure dynamic routing protocols on the Distributed Logical Router and NSX
Edge Services Gateway and understand the control of internal route
advertisements to external router.
• Scale and protect the NSX Edge Services Gateway through the use of other
routing protocols such as ECMP (Equal Cost Multipath Routing).
HOL-1803-01-NET
Special Instructions for CLI Commands
Many of the modules will have you enter Command Line Interface (CLI) commands.
There are two ways to send CLI commands to the lab.
First to send a CLI command to the lab console:
1. Highlight the CLI command in the manual and use Control+c to copy to
clipboard.
2. Click on the console menu item SEND TEXT.
3. Press Control+v to paste from the clipboard to the window.
4. Click the SEND button.
Second, a text file (README.txt) has been placed on the desktop of the environment
allowing you to easily copy and paste complex commands or passwords in the
associated utilities (CMD, Putty, console, etc). Certain characters are often not present
on keyboards throughout the world. This text file is also included for keyboard layouts
which do not provide those characters.
The text file is README.txt and is found on the desktop.
HOL-1803-01-NET
Dynamic and Distributed Routing

You will first take a look at the configuration of distributed routing and see the benefits
of performing routing at the kernel level.
A look at the Current Topology and Packet Flow
The above picture shows this lab's environment where both Application VM and
Database VM reside on the same physical host. The red arrows show the traffic flow
between the two VMs.
1. The traffic leaves the Application VM and reaches the host.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

picture above.
Configure Route Redistribution

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

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

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

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

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

2. Click Home icon.
HOL-1803-01-NET
Launch Remote Console
1. Expand RegionA01.
2. Select Perimeter-Gateway-01-0.
3. Click on the Black Screen.
HOL-1803-01-NET
Access Remote Console
When the VM console launches in the browser tab, it will appear as a black screen. Click
inside the black screen and press Enter a few times to make the VM console appear
from the screensaver.
HOL-1803-01-NET
Login to Perimeter Gateway
Log into Perimeter-Gateway-01 with the following credentials:
1. Username: admin
2. Password: VMware1!VMware1!
Note: NSX Edge require a 12-character complex password.
HOL-1803-01-NET
clipboard.
View BGP Neighbors
Let's look at the BGP neighbors of Perimeter-Gateway-01.
1. Enter show ip bgp neighbors.
HOL-1803-01-NET
show ip bgp neighbors
Reviewing Displayed BGP Neighbor Information
Let's review the information on BGP neighbors.
1. BGP neighbor is 192.168.100.1 - This is the router ID of the vPod Router inside
the NSX environment.
2. Remote AS 65002 - This is the autonomous system number of the vPod Router's
external network.
3. BGP state = Established, up - This means the BGP neighbor adjacency is
complete and the BGP routers will send update packets to exchange routing
information.
Review Routes on Perimeter Edge and their Origin
Let's see the available routes on Perimeter-Gateway-01.
1. Enter show ip route.
show ip route
HOL-1803-01-NET
Review Route Information
Let's review the information on routes.
1. B indicates that this route is learned via BGP. This is also the default route and it
originates from the vPod Router (192.168.100.1).
2. C indicates that this route is directly connected to Perimeter-Gateway-01.
172.16.10.0/24 is the Web-Tier Logical Switch (network segment).
3. O indicates that this route is learned via OSPF from Distributed-Router-01
(192.168.5.2). 172.16.20.0/24 and 172.16.30.0/24 are the App-Tier Logical
Switch and DB-Tier Logical Switch (network segments).
Controlling BGP Route Distribution
There could be a situation where you would only want BGP routes to be distributed
inside of the virtual environment, but not with the physical world. We are able to control
that route distribution easily from the NSX Edge configuration.
HOL-1803-01-NET
Navigate to NSX in vSphere Web Client
Return to vSphere Web Client.
1. Click on the Home icon.

Access Perimeter Gateway
1. Click NSX Edges.

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

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

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

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

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

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

(NSX Edge).

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

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

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

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

HOL-1803-01-NET
ECMP and High Availability

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

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

2. Click Home icon.

HOL-1803-01-NET
Modify the Perimeter Gateway Edge
We first need to modify the existing Perimeter Gateway NSX Edge to remove the
secondary IP address:
1. Click NSX Edges.

2. Double-click Perimeter-Gateyway-01.
Modify the Uplink vNIC
1. Click Manage.
2. Click Settings.
4. Select vNIC 0.
5. Click on the Edit pencil.

HOL-1803-01-NET
Remove the Secondary IP Address
1. Highlight the Interface.

2. Click on the Edit pencil.
3. Click on the cross to delete the Secondary IP Addresses.
Confirm the Change
1. Click OK.
Go back to the NSX Edges
1. Keep clicking the Back button to go back to the NSX Edges.

HOL-1803-01-NET
Add Additional Perimeter Gateway Edge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Click Next.

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

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

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

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

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

(NSX Edge).

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

HOL-1803-01-NET
Add New Area

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

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

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

HOL-1803-01-NET
Publish Changes

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

HOL-1803-01-NET
Add New Neighbor

3. Enter 65002 as the Remote AS.
4. Click OK.
Publish Changes

(NSX Edge).

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

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

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

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

HOL-1803-01-NET
BGP Route Distribution Table

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

HOL-1803-01-NET

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


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

(NSX Edge).

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

HOL-1803-01-NET
Disable Firewall on Perimeter Gateway 01
1. Click Manage.
2. Click Firewall.
3. Click Disable.
Publish Change

(NSX Edge).

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

(NSX Edge).
1. Click Back.

HOL-1803-01-NET
1. Double-click Perimeter-Gateway-02
Disable Firewall on Perimeter Gateway 02
1. Click Manage.
2. Click Firewall.
3. Click Disable.

HOL-1803-01-NET
Publish Change

(NSX Edge).
Enable ECMP on Perimeter Gateway 02
1. Click Manage.
2. Click Routing.
4. Click Enable.

HOL-1803-01-NET
Publish Change

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

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


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

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

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

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

Router.
2. Login as root.

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

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

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

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

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

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

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

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

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

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

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

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

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

HOL-1803-01-NET
Prior to moving to Module 4 - Please

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


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

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

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

HOL-1803-01-NET

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

HOL-1803-01-NET
1. Click Manage.
2. Click Firewall.
3. Click Enable.
Publish Change

(NSX Edge).

HOL-1803-01-NET
Module 3 Conclusion
In this module, we covered the routing capabilities of NSX Distributed Logical Router and
Edge Services Gateways:
1. Migrated Logical Switches from Edge Services Gateway (ESG) to the Distributed
Logical Router (DLR).
2. Configured the dynamic routing protocol between ESG and DLR.
3. Review the centralized routing capabilities of ESG and dynamic route peering
information.
4. Demonstrated scalability and availablity of ESG by deploying a second ESG and
establishing route peering between the two ESGs via Equal Cost Multipath (ECMP)
route configuration.
5. Removed ESG2 and ECMP route configuration.
You've completed Module 3
Lab Module List:
Lab Captains:

Kingdom

HOL-1803-01-NET

How to End Lab

HOL-1803-01-NET
Module 4 - Edge Services

Gateway (60 minutes)

HOL-1803-01-NET
Introduction to NSX Edge Services

Gateway
NSX Edge provides network edge security and gateway services to isolate a virtualized
network. You can install an NSX Edge either as a logical (distributed) router or as a
services gateway.
The NSX Edge logical (distributed) router provides East-West distributed routing with
tenant IP address space and data path isolation. Virtual machines or workloads that
reside on the same host on different subnets can communicate with one another
without having to traverse a traditional routing interface.
The NSX Edge Gateway connects isolated, stub networks to shared (uplink) networks by
providing common gateway services such as DHCP, VPN, NAT, dynamic routing, and
Load Balancing. Common deployments of NSX Edges include the DMZ, VPN, Extranets,
and multi-tenant Cloud environments where the NSX Edge creates virtual boundaries for
each tenant.
In this module, we will be doing the following:
• Deploy Edge Services Gateway

• Configure Load Balancer on Edge Services Gateway
• Verify Load Balancer's configuration on Edge Services Gateway
• Modify Edge Services Gateway Firewall
• Configure DHCP Relay
• Configure L2VPN

HOL-1803-01-NET
Deploy Edge Services Gateway for

Load Balancer
The NSX Edge Services Gateway can provide load balancing functionality. Employing a
load balancer is advantageous as it can lead to more efficient resource utilization.
Examples may include efficient usage of network throughput, shorter response times for
applications, the ability to scale, and can also be part of a strategy to ensure service
redundancy and availability.
TCP, UDP, HTTP, or HTTPS requests can be load balanced utilizing the NSX Edge Services
gateway. The Edge Services Gateway can provide load balancing up to Layer 7 of the
Open Systems Interconnection (OSI) model.
In this section, we will deploy and configure a new NSX Edge Appliance as a "One-
Armed" Load Balancer.
Validate Lab is Ready
• Lab status is shown on the Desktop of the Main Console Windows VM.
Validation checks ensure all components of the lab are correctly deployed and once
validation is complete, status will be updated to Green/Ready. It is possible to have a
Lab deployment fail due to environment resource constraints.

HOL-1803-01-NET
If you are not already logged into the vSphere Web Client:
(The home page should be the vSphere Web Client. If not, Click on the vSphere Web
Client Taskbar icon for Google Chrome.)
1. Type in administrator@vsphere.local into User name

2. Type in VMware1! into Password
3. Click Login

HOL-1803-01-NET
Gain screen space by collapsing the right Task Pane
Clicking on the Push-Pins will allow task panes to collapse and provide more viewing
space to the main pane. You can also collapse the left-hand pane to gain the maximum
space.

HOL-1803-01-NET
Navigate to Networking & Security in vSphere Web Client
1. Click Home icon.


HOL-1803-01-NET
Creating a New Edge Services Gateway
We will configure the one-armed load balancing service on a new Edge Services
Gateway. To begin the new Edge Services Gateway creation process, make sure you're
in the Networking & Security section of the vSphere Web Client:
1. Click NSX Edges.


HOL-1803-01-NET
Defining Name and Type
For the new NSX Edge Services Gateway, set the following configuration options
1. Enter OneArm-LoadBalancer as the Name.

2. Click Next.

HOL-1803-01-NET
Configuring Admin account

4. Click Next.
Note: All passwords for NSX Edges are 12-character complex passwords.

HOL-1803-01-NET
Defining Edge Size and VM placement
There are four different appliance sizes for Edge Service Gateway. The specifications
(#CPUs, Memory) are as follows:
• Compact: 1 vCPU, 512 MB

• Large: 2 vCPU, 1024 MB
• Quad Large: 4 vCPU, 1024 MB
• X-Large: 6 vCPU, 8192 MB
We will 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:
1. Click Green Plus icon. This will open the Add NSX Edge Appliances pop-up
window.

HOL-1803-01-NET
Cluster/Datastore placement
1. Select RegionA01-MGMT01 as Cluster/Resource Pool.

2. Select RegionA01-ISCSI01-COMP01 as Datastore.
3. Select esx-05a.corp.local as Host.
4. Select Discovered virtual machine as Folder.
5. Click OK.

HOL-1803-01-NET
Configure Deployment
1. Click Next.
Placing a new network interface on the NSX Edge
Since this is a one-armed load balancer, it will only need one network interface.

HOL-1803-01-NET
Configuring the new network interface for the NSX Edge
We will be configuring the first network interface for this new NSX Edge.
1. Enter WebNetwork as the Name.

2. Select Internal as the Type.
3. Click Select.

HOL-1803-01-NET
Selecting Network for New Edge Interface
This one-armed load balancer's interface will need to be on the same network as the
two web servers that this Edge will be providing Load Balancing services.

2. Select Web_Tier_Logical_Switch (5000).
3. Click OK.

HOL-1803-01-NET
Configuring Subnets
1. Click Green Plus icon. This will configure the IP address of this interface.

HOL-1803-01-NET
Configuring Subnets Popup
To add a new IP address to this interface:

3. Click OK.

HOL-1803-01-NET
Confirm List of Interfaces
Ensure the IP Addresses and Subnet Prefix Length information are the same as the
picture above.
1. Click Next.

HOL-1803-01-NET
Configuring the Default Gateway
1. Enter 172.16.10.1 as the Gateway IP.

2. Click Next.

HOL-1803-01-NET
Configuring Firewall and HA options

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

HOL-1803-01-NET
Review of Overall Configuration and Complete
1. Click Finish. This will start the deployment.
Monitoring Deployment
It will take a couple of minutes for the NSX Edge to deploy.

HOL-1803-01-NET
1. The NSX Edges section will show that there is 1 Installing while OneArm-
LoadBalancer is being deployed.
2. The status for OneArm-LoadBalancer will indicate that it is Busy. This means the
deployment is in process.
3. Click refresh icon on the vSphere Web Client to see the deployment status of
OneArm-LoadBalancer.
Once the status for OneArm-LoadBalancer indicates that it is Deployed, we can move on
to the next step.

HOL-1803-01-NET
Configure Edge Services Gateway for

Load Balancer
Now that the Edge Services Gateway is deployed, we will now configure load balancing
services.
Configure Load Balancer Service
The above depicts the eventual topology we will have for the load balancer service
provided by the NSX Edge Services Gateway we just deployed. To get started, from
within the NSX Edges area of the Networking & Security plug-in for the vSphere Web
Client, double click on the Edge we just made to go into its management page.

HOL-1803-01-NET
Configure Load Balancer Feature on OneArm-Load

Balancer
1. Double-click OneArm-LoadBalancer.
Navigate to New NSX Edge
1. Click Manage.
2. Click Load Balancer.
4. Click Edit to change Load Balancer global configuration.

HOL-1803-01-NET
Edit Load Balancer Global Configuration
To enable the Load Balancer service:
1. Check Enable Load Balancer.

2. Click OK.

HOL-1803-01-NET
Creating a New Application Profile
An Application Profile is how we define the behavior of a typical type of network

traffic. These profiles are applied to a virtual server (VIP) which handles traffic based on
the values specified in the Application Profile.
Utilizing profiles can make traffic-management tasks less error-prone and more efficient.
1. Click Application Profiles

2. Click Green Plus icon. This will open the New Profile pop-up window.

HOL-1803-01-NET
Configuring a New Application Profile HTTPS
For the new Application Profile, configure the following:
1. Enter OneArmWeb-01 as Name.

2. Select HTTPS as Type.
3. Check Enable SSL Passthrough. This will allow HTTPS to terminate on the pool
server.
4. Click OK.

HOL-1803-01-NET
Modify Default HTTPS monitor
Monitors ensure that pool members serving virtual servers are up and working. The
default HTTPS monitor will 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 servers are up and running but the application is as well.
1. Click Service Monitoring.

2. Click monitor-3 (default_https_monitor).
3. Click Pencil icon.
4. Type "/cgi-bin/app.py" for the URL.
5. Click OK.

HOL-1803-01-NET
Create New Pool
A group of servers of Pool is the entity that represents the nodes that traffic is getting
load balanced to. We will be adding the two web servers web-01a and web-02a to a new
pool. To create the new pool:
1. Click Pools.
2. Click Green Plus icon. This will open the New Pool pop-up window.
Configuring New Pool
For the settings on this new Pool, configure the following:

HOL-1803-01-NET
1. Enter Web-Tier-Pool-01 as the Name.

2. Select default_https_monitor as the Monitors.
Add members to the pool
1. Enter web-01a as the Name.

2. Enter 172.16.10.11 as the IP Address / VC Container.
3. Enter 443 for the Port.
4. Enter 443 for the Monitor Port.
5. Click OK.
Repeat above the process to add one more pool member using the following
information:
• Name: web-02a
• IP Address: 172.16.10.12
• Port: 443
• Monitor Port: 443

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

HOL-1803-01-NET
2. Click Green Plus icon. This will open the New Virtual Server pop-up window.
Configure New Virtual Server
Please configure the following options for this new Virtual Server:
1. Enter Web-Tier-VIP-01 as the Name.

3. Select HTTPS as the Protocol.
4. Select Web-Tier-Pool-01.
5. Click OK.

HOL-1803-01-NET
Edge Services Gateway Load Balancer -

Verify Configuration
Now that we have configured the load balancing services, we will verify the
configuration.
Test Access to Virtual Server
1. Open new browser tab.

2. Click on 1-Arm LB Customer DB bookmark.
3. Click on Advanced.

HOL-1803-01-NET
Ignore SSL error
1. Click on Proceed to 172.16.10.10 (unsafe).

HOL-1803-01-NET
Test Access to Virtual Server
We should be successful in accessing the one-armed Load Balancer if it was configured

correctly.
1. Click refresh icon. This will allow you to see the Round-Robin of the two pool
members.
Note: You may have to click a few times to get the browser to refresh outside of the
browser cache.

HOL-1803-01-NET
Show Pool Statistics
To see the status of the individual pool members:
1. Click on Pools.
2. Click Show Pool Statistics.
3. Click on "pool-1". We will see each member's current status.
4. Close the window by clicking the X.
Monitor (Health Check) Response Enhancement
To aid troubleshooting, NSX Load Balancer "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 Load Balancer Edge Gateway.

HOL-1803-01-NET
1. Enter LoadBalancer in the search box. The search box is located at the top right
corner of vSphere Web Client.
2. Click on "OneArm-LoadBalancer-0".
Open Console Load Balancer Console
1. Click on Summary.
2. Click on VM console.

HOL-1803-01-NET
Login to OneArm-LoadBalancer-0
1. Login as admin.
2. Enter VMware1!VMware1! as password.

HOL-1803-01-NET
Many of the modules will have us enter Command Line Interface (CLI) commands.
clipboard.
providing you with all the user accounts and passwords for the environment.

HOL-1803-01-NET
Examine pool status before failure
1. Enter show service loadbalancer pool.
show service loadbalancer pool
Note: The status of pool members, web-01a and web-02a are shown to be "UP".
Start PuTTY
1. Click on PuTTY on the taskbar.

HOL-1803-01-NET
SSH to web-01a.corp.local
1. Scroll down to web-01a.corp.local.

3. Click Load.
4. Click Open.
Stop Nginx Service
We will shutdown HTTPS to simulate the first failure condition
1. Enter systemctl stop nginx.
systemctl stop nginx

HOL-1803-01-NET
Loadbalancer console
Because the service is down, the failure detail shows the client could not establish SSL
session.
Start Nginx Service

HOL-1803-01-NET
Switch back to the Putty SSH session for web-01a.
1. Enter systemctl start nginx.
systemctl start nginx
Shutdown web-01a
1. Enter web-01a in the search box. The search box is located at the top right
corner of vSphere Web Client.
2. Click on web-01a.
Power off web-01a
1. Click Actions.
2. Click Power.
3. Click Power Off.
4. Click Yes.

HOL-1803-01-NET
Check the Pool status
Because the VM is currently down, the failure detail shows that the client could not
establish L4 connection as oppose to L7 (SSL) connection in previous step.

HOL-1803-01-NET
Power web-01a on
1. Click Actions.
2. Click Power.
3. Click Power On.
Conclusion
In this lab, we have deployed and configured a new Edge Services Gateway and enabled
load balancing services for the 1-Arm LB Customer DB application.
This concludes the Edge Services Gateway Load Balancer lesson. Next, we will learn
more about the Edge Services Gateway Firewall.

HOL-1803-01-NET
Edge Services Gateway Firewall

The NSX Edge Firewall monitors North-South traffic to provide perimeter security
functionality including firewall, Network Address Translation (NAT) as well as site-to-site
IPSec and SSL VPN functionality. Firewall settings apply to traffic that does not match
any of the user-defined firewall rules. The default Edge firewall policy blocks all
incoming traffic.
Working with NSX Edge Firewall Rules
We can navigate to an NSX Edge to see the firewall rules that apply to it. Firewall rules
applied to a Logical Router only protect control plane traffic to and from the Logical
Router control virtual machine. They do not enforce any data plane protection. To
protect data plane traffic, create Logical Firewall rules for East-West protection or rules
at the NSX Edge Services Gateway level for North-South protection.
Rules created on the Firewall user interface applicable to this NSX Edge are displayed in
a read-only mode. Rules are displayed and enforced in the following order:
1. User-defined rules from the Firewall user interface (Read Only).

2. Auto-plumbed rules (rules that enable control traffic to flow for Edge services).
3. User-defined rules on NSX Edge Firewall user interface.
4. Default rule.

HOL-1803-01-NET
Open Network & Security
1. Click Home icon.


HOL-1803-01-NET
Open an NSX Edge
1. Click NSX Edges.

2. Double-click Perimeter Gateway-01.
Open Manage Tab
1. Click Manage.
2. Click Firewall.
3. Click Default Rule.
4. Click Plus icon under Action column.
5. Click Deny from Action.
Publish Changes
We will not be making permanent changes to the Edge Services Gateway Firewall
setting.

HOL-1803-01-NET
1. Click Revert to roll back changes.
Adding Edge Services Gateway Firewall Rule
Now that we are familiar with editing an existing Edge Services Gateway firewall rule,
we will add a new edge firewall rule that will block the Control Center's access to the
Customer DB Application.
1. Click Green Plus icon to add a new firewall rule.

2. Hover mouse over the upper right corner of the Name column and click the Plus
icon.
3. Enter Main Console FW Rule as the Rule Name.
4. Click OK.
Specify Source
Hover mouse in the upper right corner of the Source column and click Pencil icon.

HOL-1803-01-NET
1. Click Object Type drop down menu and select IP Sets.

2. Click New IP Set... hyperlink.
3. Enter Main Console as the Name.
4. Enter 192.168.110.10 as the IP address.
5. Click OK.
Confirm Source
1. Confirm Main Console is in Selected Objects.

2. Click OK.
Specify Destination

HOL-1803-01-NET
Hover mouse in the upper right corner of the Destination column and click Pencil icon.
1. Click Object Type drop down menu and select Logical Switch.
2. Click Web_Tier_Logical_Switch.
3. Click right arrow. This will move the Web_Tier_Logical_Switch to Selected
Objects.
4. Click OK.
Configure Action
1. Click Plus icon under Action column.

2. Click Deny from Action.
3. Click OK.
Publish Changes

(NSX Edge).

HOL-1803-01-NET
Test New FW Rule
Now that we have configured a new FW rule that will block the Control Center from
accessing the Web Tier logical switch, let's run a quick test:

Verify the Main Console cannot access the Customer DB App. We should see a
browser page that states the web site cannot be reached. Now, lets modify the FW rule
to allow the Main Console access to the Customer DB App.
Change the Main Console FW Rule to Accept

HOL-1803-01-NET
1. Click Plus icon in the upper right corner of the Action column of the Main Console
FW Rule.
2. Click Accept under Action.
3. Click OK.
Publish Changes

(NSX Edge).
Confirm Access to Customer DB App
Return to Customer DB App browser tab.

HOL-1803-01-NET
1. Click Refresh icon.
Since the Main Console FW rule has been changed to "Accept", the Main Console can
now access the Customer DB App.
Delete Main Console FW Rule
1. Click Main Console FW Rule.

2. Click red X to delete the firewall rule.
3. Click OK.
Publish Changes

(NSX Edge).

HOL-1803-01-NET
Conclusion
In this lab, we learned to modify an existing Edge Services Gateway Firewall rule and
configure a new Edge Services Gateway Firewall rule that blocks external access to the
Customer DB App.
This concludes the Edge Services Gateway Firewall lesson. Next, we will learn more
about Edge Services Gateway managing DHCP services.

HOL-1803-01-NET
DHCP Relay
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 segments 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 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 broadcast back to the original network to
the client.
Areas to be covered in this lab:
• Create a new network segment within NSX

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

HOL-1803-01-NET
This diagram lays out the final topology that will be created and used in this lab module.
Access NSX Through the vSphere Web Client
1. Click Home icon.


HOL-1803-01-NET
Create New Logical Switch
We must first create a new Logical Switch that will run our new 172.16.50.0/24 network.
1. Click Logical Switches.

2. Click Green Plus icon to create a new Logical Switch.
Enter New Switch Parameters

HOL-1803-01-NET
1. Enter DHCP-Relay as Name.

2. Select RegionA0-Global-TZ as Transport Zone.
3. Click OK.
Connect Logical Switch to Perimeter Gateway
We will now attach the logical switch to an interface on the Perimeter Gateway. This
interface will be the default gateway for the 172.16.50.0/24 network with an address of
172.16.50.1.
1. Click NSX Edges.


HOL-1803-01-NET
Add Interface
This section will attach the logical switch to an interface on the Perimeter Gateway.
1. Click Manage.
2. Click Settings.
4. Select vnic9.

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

HOL-1803-01-NET
Enter New Interface Parameters
1. Enter DHCP Relay as the Name.

3. Enter 172.16.50.1 as the Primary IP address.
5. Click OK.

HOL-1803-01-NET
Configure DHCP Relay
Staying inside of the Perimeter Gateway, we must do the global configuration of DHCP
Relay.
1. Click Manage.
2. Click DHCP.
3. Click Relay.
4. Click Edit.

HOL-1803-01-NET
DHCP Global Configuration
Within the global configuration of DHCP is where we select the DHCP servers that will
respond to DHCP requests from our guest VMs.
There are three methods by which we can set DHCP Server IPs:
IP Sets
IP Sets are configured from the NSX Manager Global Configuration and allow us to
specify a subset of DHCP servers by creating a named grouping.
IP Addresses
We can manually specify IP addresses of DHCP servers in this method.
Domain Names
This method allows us to specify a DNS name that could be a single or multiple DHCP
server addresses.

HOL-1803-01-NET
For the sake of this lab, we will be using a single IP address.
1. Enter 192.168.110.10 in IP Addresses text-box.

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

2. Select DCHP-Relay as vNIC.
3. Click OK.
Publish Settings to DHCP Relay Settings
1. Click Publish Changes.

HOL-1803-01-NET
Create Blank VM for PXE Boot
We will now create a blank VM that will PXE boot from the DHCP server we are relaying
to.
1. Click Home icon.


HOL-1803-01-NET
Create New VM
2. Right-click esx-02a.corp.local.
3. Click New Virtual Machine.
4. Click New Virtual Machine....

HOL-1803-01-NET
Configure the New VM
1. Select Create a New Virtual Machine.

2. Click Next.

HOL-1803-01-NET
Name the VM
1. Enter PXE VM.

2. Click Next.

HOL-1803-01-NET
Select Host
1. Click Next.

HOL-1803-01-NET
Select Storage
1. Click Next.
Select Compatibility

HOL-1803-01-NET
1. Click Next.
Select Guest OS
1. Select Linux under Guest OS Family.

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

HOL-1803-01-NET
Specify Hardware - Remove Hard Disk
We need to delete the default hard disk. 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.
1. Hover over New Hard Disk and click X.

2. Select DHCP Relay network. The UUID of the logical switch may vary from the
screenshot, but there is only one network named DHCP-Relay. If you cannot find
the network, click "show more networks".
3. Click Next.

HOL-1803-01-NET
Complete VM Creation
1. Click Finish.

HOL-1803-01-NET
Power on VM
1. Click PXE VM.

2. Click Power.
3. Click Power On.

HOL-1803-01-NET
Access Newly Created VM
Next we will open a console to this VM and watch it boot from the PXE image. It receives
this information via the remote DHCP server we configured earlier.
1. Click PXE VM.

2. Click Summary.
3. Click VM Console.
Obtaining DHCP from Remote Server
Note the VM is now attempting to boot and obtain a DHCP address.

HOL-1803-01-NET
Image Booting
This screen will appear once the VM has a DHCP address and is downloading the PXE
image from the boot server. This screen will take about 1-2 mins, please move on to the
next step.
Verify DHCP Lease

HOL-1803-01-NET
While we wait for the VM to boot, we can verify the address used in the DHCP Leases.
1. Go to the desktop of the Main Console and double-click DHCP icon.
View Leases
We can view the DHCP server to identify the IP address taken by the VM.
1. Expand controlcenter.corp.local.
2. Expand IPv4.
3. Expand Scope [172.16.50.0] NSX_ESG_Relay_Lab.
4. Select Address Leases.
We will see the address 172.16.50.10 which was in the range created earlier.

HOL-1803-01-NET
View Options
We can also see the scope options used to boot the PXE Image
1. Click Scope Options
We will notice that 066 Boot Server Host Name and 67 Bootfile Name were used.
We can now close DHCP.
Access Booted VM
1. Click PXE VM browser tab.

HOL-1803-01-NET
Verify Address and Connectivity
The widget in the upper-right corner of the VM will show statistics, along with the IP of
the VM. This should match the IP shown in DHCP earlier.
Verify Connectivity
As the dynamic routing is already in place with the virtual network, we will have
connectivity to the VM upon its creation. We can verify the connectivity by pinging the
VM from the Main Console.

HOL-1803-01-NET
1. Click Command Prompt icon in the taskbar.

2. Enter ping 172.16.50.10.
ping 172.16.50.10
We will see a ping response from the VM. After which, we can now close this command
prompt window.
Conclusion
In this section, 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.
Next, we will explore Edge Services Gateway L2VPN services.

HOL-1803-01-NET
Configuring L2VPN
In this section, we will be utilizing the L2VPN capabilities of the NSX Edge Gateway to
extend a L2 boundary between two separate vSphere clusters. To demonstrate this
capability, we will deploy an an NSX Edge L2VPN Server on the RegionA01-MGMT01
cluster and an NSX Edge L2VPN Client on the RegionA01-COMP01 cluster and finally test
the tunnel status to verify a successful configuration.
Opening Google Chrome and Navigating to the vSphere

Web Client
1. Open the Google Chrome web browser from the desktop (if not already open).

HOL-1803-01-NET
Navigate to Networking & Security Section of the vSphere

Web Client
1. Click Home icon.


HOL-1803-01-NET
Creating the NSX Edge Gateway for the L2VPN-Server
To create the L2VPN Server service, we must first deploy an NSX Edge Gateway for that
service to run on.
1. Click on NSX Edges.

2. Click on Green Plus icon.
Configuring a new NSX Edge Gateway: L2VPN-Server

HOL-1803-01-NET
The New NSX Edge wizard will appear, with the first section "Name and Description"
displayed. Enter in the following values corresponding to the following numbers. Leave
the other fields blank or at their default values.
1. Enter L2VPN-Server for the Name.

2. Click Next.
Configure Settings for New NSX Edge Gateway: L2VPN-

Server

4. Click Next.

HOL-1803-01-NET
Adding the New NSX Edge Appliance: L2VPN-Server

2. Select RegionA01-MGMT01 as Cluster/Resource Pool.
3. Select RegionA01-ISCSI01-MGMT01 as Datastore.
6. Click OK.

HOL-1803-01-NET
Back to Configure Deployment for new NSX Edge Gateway:

L2VPN-Server
1. Click Next.
Add Interface

HOL-1803-01-NET
Adding a new Interface to the NSX Edge Gateway: L2VPN-

Server
1. Enter L2VPNServer-Uplink as Name.

2. Select Uplink for Type.
5. Enter 29 for the Subnet Prefix Length.
Connecting the new Interface to a Logical Switch

HOL-1803-01-NET
1. Select Transit_Network_01 (5007).

2. Click OK.
Confirming new Interface Configuration: L2VPN-Server
1. Click OK.

HOL-1803-01-NET
Continuing the new NSX Edge Gateway Configuration:

L2VPN-Server
1. Click Next.

HOL-1803-01-NET
Configuring Default Gateway Settings for new NSX Edge:

L2VPN-Server

2. Click Next.

HOL-1803-01-NET
Configuring Firewall and HA Settings for new NSX Edge

Gateway: L2VPN-Server

2. Select Accept for Default Traffic Policy.
3. Click Next.

HOL-1803-01-NET
Review new NSX Edge Gateway Deployment and

Complete: L2VPN-Server
1. Click Finish.
Preparing L2VPN-Server NSX Edge for L2VPN Connections
Before we configure the newly deployed NSX Edge for L2VPN connections, we need to
complete the following preparatory steps:
1. Adding a Trunk Interface to the L2VPN-Server Edge Gateway.

2. Adding a Sub Interface to the L2VPN-Server Edge Gateway.
3. Configuring dynamic routing (OSPF) on the L2VPN-Server Edge Gateway.

HOL-1803-01-NET
Configuring the L2VPN-Server NSX Edge
1. Double-click L2VPN-Server.
Adding the Trunk Interface
1. Click Manage.
2. Click Settings.
4. Click vnic1.

HOL-1803-01-NET
Configuring the Trunk Interface
1. Enter L2VPN-Server-Trunk as the Name.

2. Select Trunk as the Type.
3. Click Select under Connected To. This will open the Connect NSX Edge to a
Network pop-up window.
Selecting the Trunk Port Group

2. Select Trunk-Network-regionA0-vDS-MGMT.
3. Click OK.

HOL-1803-01-NET
Adding a Sub Interface to the Trunk Interface
1. Click Green Plus icon. This will open the Add Sub Interface pop-up window.
Configuring the Sub Interface
1. Enter L2VPN-Server-SubInterface as the Name.

2. Enter 1 as the Tunnel Id.
3. Select Network as the Backing Type.

HOL-1803-01-NET
Attaching the Sub Interface to a Logical Switch

2. Select Web_Tier_Logical_Switch (5000).
3. Click OK.

HOL-1803-01-NET
Reviewing the Sub Interface Configuration
Ensure the Sub Interface configuration is the same as the picture above.
1. Click OK.

HOL-1803-01-NET
Reviewing the Trunk Interface Configuration
Ensure the Trunk Interface configuration is the same as the picture above.
1. Click OK.

HOL-1803-01-NET
Setting the Router ID for this NSX Edge
Next, we will be configuring dynamic routing on this Edge Gateway.
1. Click Routing.
Add L2VPNServer-Uplink
1. Click OK.

HOL-1803-01-NET
Publish Changes to set Router ID

HOL-1803-01-NET
Configuring OSPF on the L2VPN-Server NSX Edge
1. Click OSPF.
2. Click Green Plus icon under Area to Interface Mapping.

HOL-1803-01-NET
Configuring Area to Interface Mapping
1. Select L2VPNServer-Uplink as the vNIC.

2. Enter 0 as the Area.
3. Click OK.
Enabling OSPF on the L2VPN-Server NSX Edge
1. Click Edit to change OSPF Configuration.

3. Click OK.

HOL-1803-01-NET
Publish Changes for the L2VPN-Server NSX Edge
Enable OSPF Route Redistribution

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

HOL-1803-01-NET
Add Route Redistribution Table Entry
1. Click Green Plus icon under Route Redistribution Status.
Configure Route Redistribution Table Entry

HOL-1803-01-NET
1. Check Connected.
2. Click OK.
Publish Changes
We have performed all prerequisites and will now configure the L2VPN service on this
Edge Gateway.
Configuring L2VPN Service on L2VPN-Server NSX Edge
The 172.16.10.1 address belongs to the L2VPN-Server Edge Gateway and routes are
being distributed dynamically via OSPF. Next, we will configure the L2VPN service on this
Edge Gateway so that the Edge acts as "Server" in the L2VPN.
Navigating to VPN Services Area on L2VPN-Server NSX

Edge
1. Click VPN.
2. Click L2 VPN.
3. Click Change to edit Global Configuration Details.

HOL-1803-01-NET
Configuring the L2VPN Server Settings
For the L2 VPN server settings, configure the following values:
1. Select ECDHE-RSA-AES256-GCM-SHA384 as the Encryption Algorithm.

2. Click OK.

HOL-1803-01-NET
Add a new Site Configuration

HOL-1803-01-NET
Configuring a new L2VPN Site
1. Check Enable Peer Site.

2. Enter HOLSite1 as the Name.
3. Enter siteadmin as the User Id.
4. Enter VMware1! as the password.
5. Click Select Sub Interfaces. This will open the Select Object pop-up window.

HOL-1803-01-NET
Selecting a Sub Interface
1. Select L2VPN-Server-SubInterface object.

2. Click Right-facing Arrow. This will move the object to Selected Objects.
3. Click OK.
Confirming New Site Configuration
1. Click OK.

HOL-1803-01-NET
Publish Changes for L2VPN Configuration
1. Select Server as the L2VPN Mode.

Enable L2VPN Server Service
1. Click Enable for L2VPN Service Status. This will enable L2VPN-Server service.
We have completed the configuration for the L2 VPN Server. Next, we will be deploying a
new NSX Edge Gateway to act as the L2 VPN Client.

HOL-1803-01-NET
Deploying the L2VPN-Client NSX Edge Gateway
Now that the server side of the L2VPN is configured, we will move on to deploying a new
NSX Edge Gateway to act as the L2 VPN client. Before deploying the NSX Edge Gateway
L2VPN Client, we need to configure the Uplink and Trunk distributed port groups on the
distributed virtual switch.
Configure Uplink and Trunk Port Groups
1. Click Home icon.

2. Click Networking.

HOL-1803-01-NET
Configure Uplink distributed port group
1. Select RegionA01-vDS-COMP.
2. Click Create a new port group.

HOL-1803-01-NET
Name New Distributed Port Group
1. Enter Uplink-RegionA01-vDS-COMP as the Name.

2. Click Next.

HOL-1803-01-NET
Configure Settings
1. Click Next. Leave the settings as default.

HOL-1803-01-NET
Ready to Complete
1. Click Finish.
We will need to configure another distributed port group which is named as Trunk-
Network-RegionA01-vDS-COMP. Repeat the same steps to create Trunk-Network-
RegionA01-vDS-COMP.

HOL-1803-01-NET
Completed vDS Configuration
1. When completed, we should see the newly created distributed port groups.
2. Click Back.

HOL-1803-01-NET
Return to Networking & Security
1. Click Home icon.


HOL-1803-01-NET
Creating the new NSX Edge Gateway to be the L2VPN-

Client
1. Click NSX Edge.

2. Click Green Plus icon. This will open the New NSX Edge pop-up window.
L2VPN-Client NSX Edge Name and Description
1. Select Edge Services Gateway as the Install Type.

2. Enter L2VPN-Client as the Name.

HOL-1803-01-NET
3. Click Next.
Configuring NSX Edge Settings
1. Enter admin as User Name.

2. Enter VMware1!VMware1! as the Password.
3. Enter VMware1!VMware1! as the Confirm password.
4. Click Next.

HOL-1803-01-NET
Configure Placement of NSX Edge
1. Click Green Plus icon. This will open the Add NSX Edge Appliance pop-up
window.
2. Select RegionA01-COMP02 as Cluster/Resource Pool.
3. Select RegionA01-ISCSI01-COMP01 as Datastore.
6. Click OK.

HOL-1803-01-NET
Confirm NSX Edge Deployment
1. Click Next.
Configure Interfaces for the L2VPN-Client NSX Edge

HOL-1803-01-NET
Add new Interface
1. Enter L2VPN-Client-Uplink as the Name.

2. Select Uplink as the Type.
3. Click Green Plus icon to add a new IP address.
Connect Interface to Distributed Port Group

HOL-1803-01-NET
2. Select Uplink-RegionA01-vDS-COMP.
3. Click OK.
Confirm Interface Configuration
1. Click OK.

HOL-1803-01-NET
Click Next
1. Click Next.

HOL-1803-01-NET
Configure Default Gateway

2. Click Next.

HOL-1803-01-NET
Firewall and HA Settings

2. Select Accept for Default Traffic Policy.
3. Click Next.

HOL-1803-01-NET
Confirm New NSX Edge Configuration
1. Click Finish.
Configuring the L2VPN-Client NSX Edge Gateway
1. Double-click L2VPN-Client.

HOL-1803-01-NET
Adding the Trunk Interface
Similar to the configuration for L2VPN-Server Edge Gateway, we will also need to add a
Trunk interface to this Edge:
1. Click Manage.
2. Click Settings.
4. Click vnic1.
Configuring the Trunk Interface
1. Enter L2PVN-Client-Trunk as the Name.

2. Select Trunk as the Type.

HOL-1803-01-NET
Connecting to the Trunk Network Distributed Port Group

2. Select Trunk-Network-RegionA01-vDS-COMP.
3. Click OK.
Configuring Sub Interface
Configure the Sub Interface with the following values:

2. Enter L2VPN-Client-SubInterface as the Name.
3. Enter 1 as the Tunnel Id.
4. Select Network as the Backing Type.

HOL-1803-01-NET

8. Click Select under Network.
Connect Sub Interface to VM Network

2. Select VM-RegionA01-vDS-COMP.
3. Click OK.

HOL-1803-01-NET
Confirm Sub Interface Configuration
1. Click OK.
Ensure the Sub Interface configuration is the same as the picture above.

HOL-1803-01-NET
Confirm Addition of Trunk & Sub Interface
1. Click OK.
Ensure the Trunk Interface configuration is the same as the picture above.

HOL-1803-01-NET
Configure L2VPN Client Services
1. Click VPN.
2. Click L2 VPN.
3. Select Client as the L2VPN Mode.
4. Click Change to edit the Global Configuration Details.

HOL-1803-01-NET
L2VPN Client Settings
1. Enter 192.168.5.5 as the Server Address.

2. Select ECDHE-RSA-AES256-GCM-SHA384 as the Encryption algorithm.
3. Enter siteadmin as the User Id.
4. Enter VMware1! for Password and Confirm Password.
5. Click Select Sub Interfaces.

HOL-1803-01-NET
Add Sub Interface
1. Select L2VPN-Client-SubInterface object.

2. Click Right-facing Arrow. This will move the object to Selected Objects.
3. Click OK.

HOL-1803-01-NET
Confirm L2VPN Client Settings
1. Click OK.

HOL-1803-01-NET
Enable L2VPN Client Service
1. Click Enable for L2VPN Service Status. This will enable L2VPN-Client service.
Publish Changes

HOL-1803-01-NET
Fetch Status of L2VPN
1. Click Fetch Status.

2. Expand Tunnel Status.
Ensure that the Status is shown as "Up" after the service has been enabled. We may
need to click Fetch Status a few times to get the updated status.
Congrats! We've successfully configured the NSX L2VPN service. This concludes the
lesson for configuring NSX Edge Services Gateway L2VPN services.

HOL-1803-01-NET
Native Bridging
NSX provides in-kernel software L2 Bridging capabilities that allow organizations to
seamlessly connect traditional workloads and legacy VLANs to virtualized networks
using VXLAN. L2 Bridging is widely used in brownfield environments to simplify the
introduction of logical networks and other scenarios involving physical systems that
require L2 connectivity to virtual machines.
The logical routers can provide L2 bridging from the logical networking space within NSX
to the physical VLAN-backed network. This allows for the creation of a L2 bridge
between a logical switch and a VLAN, which enables the migration of virtual workloads
to physical devices with no impact on IP addresses. A logical network can leverage a
physical L3 gateway and access existing physical networks and security resources by
bridging the logical switch broadcast domain to the VLAN broadcast domain. From NSX-
V 6.2 onwards, this function has been enhanced as bridged Logical Switches can be
connected to Distributed Logical Routers. This operation was not permitted in previous
versions of NSX.
This module will guide us through the configuration of a L2 Bridging instance between a
traditional VLAN and an Access NSX Logical Switch.
Introduction
The picture above shows the L2 Bridging enhancements provided in NSX 6.2 onwards:
• In NSX 6.0 and 6.1, it was not possible to bridge a Logical Switch that was
connected to a Distributed Logical Router. The Logical Switch has to be connected
to an Edge Services Gateway.

HOL-1803-01-NET
• In NSX 6.2 onwards, it is possible to bridge a Logical Switch that was connected
to a Distributed Logical Router. This provides optimized East-West traffic flows.
We will configure the newly supported NSX L2 Bridging.
1. Highlight the CLI command in the manual and use Control+c to copy to clipboard.

HOL-1803-01-NET
Access vSphere Web Client
• Bring up the vSphere Web Client via the icon on the desktop labeled, Chrome.
Log into vSphere Web Client
1. Enter administrator@vsphere.local as User name.

2. Enter VMware1! as Password.
3. Click Login.
Verify Initial Configuration
We will verify the initial configuration as shown in the picture above. The environment
comes with a Port Group on the Management & Edge cluster, named "Bridged-Net-
RegionA0-vDS-MGMT". The web server VMs, named "web-01a", and "web-02a" are

HOL-1803-01-NET
attached to the Web-Tier-01 Logical Switch. The Web-Tier-01 Logical Switch is isolated
from the Bridged-Net.
Access the vSphere Networking Configuration
1. Click Home icon.


HOL-1803-01-NET
Open Port Group
1. Expand vcsa-01a.corp.local.
3. Expand RegionA01-vDS-MGMT.
4. Click Bridged-Net-RegionA0-vDS-MGMT.
Edit Bridge Net Setting
1. Click Summary.

HOL-1803-01-NET
2. Click Actions.
3. Click Edit Settings.
Note: We are going to set the VLAN to allow for the presentation of the Bridged-Net to
the Distributed Router for L2 Bridging.
Edit VLAN Settings
1. Click VLAN.
2. Select VLAN as the VLAN type.

HOL-1803-01-NET
Add VLAN 101 to the Bridge Net
1. Enter 101 as the VLAN ID.

2. Click OK.

HOL-1803-01-NET
Verify VLAN ID
1. Click Summary.
Ensure VLAN ID is configured as 101.

HOL-1803-01-NET
Migrate Web-01a to RegionA01-MGMT01 Cluster
1. Click Home icon.


HOL-1803-01-NET
Migrate Web-01a
3. Right-click web-01a.corp.local.
4. Click Migrate.

HOL-1803-01-NET
Select Migration type
1. Click Change both compute resources and storage.

2. Click Select compute resource first.
3. Click Next.

HOL-1803-01-NET
Select Compute Resource
3. Expand RegionA01-MGMT01.
4. Select esx-04a.corp.local.
5. Click Next.

HOL-1803-01-NET
Select Storage
1. Select RegionA01-ISCSI01-MGMT01.
2. Click Next.

HOL-1803-01-NET
Select Destination Network
1. Click Destination Network.

2. Click Browse.

HOL-1803-01-NET
Select Bridged-Net-RegionA0-vDS-MGMT
1. Select Bridged-Net-RegionA0-vDS-MGMT as the network.

2. Click OK.

HOL-1803-01-NET
Click Next for Destination Network
1. Click Next.

HOL-1803-01-NET
Click Next for vMotion Priority
1. Click Next.

HOL-1803-01-NET
Click Finish
1. Click Finish.

HOL-1803-01-NET
View Connected VMs
1. Click Home icon


HOL-1803-01-NET
View Related Objects to the Bridged Net
1. Select Bridged-Net-RegionA0-vDS-MGMT.
2. Select VMs.
3. Select Virtual Machines. web-01a.corp.local should appear on the list.
4. Click web-01a.corp.local.
Open VM Console
1. Click Summary.
2. Click on the Black Screen. This will open up the VM console.
Ensure that web-01a.corp.local has a IP address of 172.16.10.11.

HOL-1803-01-NET
Verify that VM is isolated
1. Login as root.
2. Enter VMware1! as password.
3. Enter ping -c 3 172.16.10.1.
ping -c 3 172.16.10.1
There are no other devices on VLAN 101 and the L2 Bridging has not been configured
yet. Wait until the ping times out to verify that the VM is isolated.

HOL-1803-01-NET
Migrate Web_Tier_Logical_Switch to Distributed Logical

Router
1. Click Home icon.

2. Click Network & Security.

HOL-1803-01-NET
Remove Web-Tier from Perimeter Gateway
1. Click NSX Edges.

Remove Web-Tier Interface
1. Click Manage.
2. Click Settings.
4. Click Web_Tier.
5. Click Red "X" to delete Web_Tier Logical Switch.

HOL-1803-01-NET
Click OK
1. Click OK.
Go back to Edges
1. Click Back.
Select Distributed Router
1. Double-click the Distributed-Router-01.

HOL-1803-01-NET
Add the Web-Tier Logical Switch
1. Click Manage.
2. Click Settings.
4. Click Green Plus icon to add the Web-Tier Logical Switch.
Add the Web-Tier
1. Enter Web-Tier as the Name.

2. Click Select next to Connected To field.

HOL-1803-01-NET
Select the Web-Tier Logical Switch
1. Select Web_Tier_Logical_Switch.
2. Click OK.
Add Primary IP Address

HOL-1803-01-NET

4. Click OK.
Confirm Logical Switch addition to Distributed Logical

Router
Ensure the Web-Tier Logical Switch is added.
Configure NSX L2 Bridging
We will enable NSX L2 Bridging between VLAN 101 and the Web-Tier-01 Logical Switch,
so that web-01a.corp.local will be able to communicate with the rest of the network.

HOL-1803-01-NET
From NSX-V 6.2 onwards, it is possible to have a L2 Bridge and a Distributed Logical
Router connected to the same Logical Switch. This represents an important
enhancement as it simplifies the integration of NSX in brownfield environments and the
migration from legacy to virtual networking.
Create a new L2 Bridge
1. Click Bridging.
Enter Bridge Name
1. Enter Bridge-01 as the Name.

2. Click Logical Switch icon.

HOL-1803-01-NET
Select Logical Switch
1. Select Web_Tier_Logical_Switch.
2. Click OK.
Open Distributed Port Group selection dialog
1. Click Distributed Port Group icon.

HOL-1803-01-NET
Select Distributed Port Group
1. Select Bridged-Net-RegionA0-vDS-MGMT.
2. Click OK.
Confirm Bridge configuration
1. Click OK.

HOL-1803-01-NET
Publish Changes
Verify that routing is enabled
Ensure the configuration are correct.
Routing Enabled means that the L2 Bridge is connected to a Distributed Logical

Router.
Verify L2 Bridging
NSX L2 Bridging has been configured. You will now verify L2 connectivity between the
"web-01a" VM, attached on VLAN 101, and the machines connected "Web-Tier-01"
Logical Switch

HOL-1803-01-NET
Verify Default Gateway Connectivity
1. Open web-01a.corp.local browser tab.

2. Enter ping -c 3 172.16.10.1
ping -c 3 172.16.10.1
The ping is now successful. We have verified connectivity between a VM attached on

VLAN 101 and the Distributed Logical Router which is the default gateway of the
network. This is achieved through a L2 Bridge provided by NSX.
Note: We might experience "duplicate" pings during this test (responses appearing as
DUPs). This is due to the nature of the Hands-On Labs environment and will not happen
in a production environment.
L2 Bridging Module Cleanup
If you want to proceed with the other modules of this Hands-On Lab, make sure to follow
the following steps to disable the L2 Bridging, as the example configuration realized in
this specific environment could conflict with other sections, such as L2VPN.

HOL-1803-01-NET
Return to the Web Client
Access the NSX configuration page
1. Click Home icon.


HOL-1803-01-NET
Open Logical Router configuration page
1. Click NSX Edges.

Delete Bridge Instance
1. Click Manage.
2. Click Bridging.
3. Click Red Cross icon.
Note: There should one instance, Bridge-01, which was created earlier.
Publish Changes

HOL-1803-01-NET
Verify Bridge Cleanup
Ensure the Bridge instance has been deleted.
Migrate Web-01a back to RegionA01-COMP01 Cluster

HOL-1803-01-NET
1. Click Home icon.

Migrate Web-01a
3. Right-click web-01a.corp.local.
4. Click Migrate.

HOL-1803-01-NET
Select Migration type
1. Click Change both compute resources and storage.

2. Click Select compute resource first.
3. Click Next.

HOL-1803-01-NET
Select Compute Resource
4. Select esx-01a.corp.local.
5. Click Next.

HOL-1803-01-NET
Select Storage
1. Select RegionA01-ISCSI01-COMP01.
2. Click Next.

HOL-1803-01-NET
Select Destination Network
1. Click Destination Network.

2. Click vxm-dvs-43-virtualwire-1-sid-5000-Web_Tier_Logical_Switch. The
UUID of the Web Tier Logical Switch may differ.

HOL-1803-01-NET
Click Next for vMotion Priority
1. Click Next.

HOL-1803-01-NET
Click Finish
1. Click Finish.
Conclusion
Congratulations, you have successfully completed the NSX L2 Bridging module! In this
module we configured and tested the bridging from a traditional VLAN-backed PortGroup
to an NSX VXLAN Logical Switch.

HOL-1803-01-NET
Module 4 Conclusion
In this module, we touched on the advanced features of NSX Edge Services Gateway:
1. Deployed a new Edge Services Gateway (ESG) and configured it as a one-arm

load balancer.
2. Modified and created firewall rules on the existing ESG.
3. Configured DCHP Relay via ESG.
4. Configured L2VPN via ESG.
You've completed Module 4
Lab Module List:
Lab Captains:

Kingdom

HOL-1803-01-NET
How to End Lab

HOL-1803-01-NET
Conclusion
Thank you for participating in the VMware Hands-on Labs. Be sure to visit
http://hol.vmware.com/ to continue your lab experience online.
Lab SKU: HOL-1803-01-NET
Version: 20180413-130034

Hol 1803 01 Net - PDF - en PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Hol 1803 01 Net - PDF - en PDF

Încărcat de

Drepturi de autor:

Formate disponibile

HOL-1803-01-NET

Lab Module List:

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

Location of the Main Console

Alternate Methods of Keyboard Data Entry

Click and Drag Lab Manual Content Into Console Active

Accessing the Online International Keyboard

Click once in active console window

1. Click once in the active console window.

Click on the @ key

1. Click on the "@ key".

Notice the @ sign entered in the active console window.

Activation Prompt or Watermark

This cosmetic issue has no effect on your lab.

Look at the lower right portion of the screen

Module 1 - NSX Manager

In the Interactive Simulation, you will see how to:

• Deploying the NSX Manager OVA

Hands-on Labs Interactive Simulation:

Hands-on Labs Interactive Simulation:

You've finished Module 1

Congratulations on completing Module 1.

Proceed to any module below which interests you the most:

Lab Module List:

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

How to End Lab

To end your lab click on the END button.

Logical Switching - Module Overview

1. Confirm the configuration readiness of the hosts.

Launch Google Chrome

Login to the vSphere Web Client

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

Navigate to Networking & Security in vSphere Web Client

1. Click Home icon.

View the deployed components

The topology after the host is prepared with data path

View the VTEP configuration

1. Click Logical Network Preparation tab.

VXLAN configuration can be broken down into three important steps:

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

The topology after the VTEPs are configured across the

The three modes of control plane configuration are:

Segment ID and Multicast Group Address Configuration

Defining Transport Zone settings

1. Click Transport Zones.

Confirm Clusters as members of Local Transport Zone

Confirm all 3 clusters are present in the Transport Zone.

The topology after the Transport Zone is defined

Go back to Networking & Security Menu

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

Create a new Logical Switch

1. Click Logical Switches on the left hand side.

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

Attach the new Logical Switch to the NSX Edge Services

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

Connect the Logical Switch to the NSX Edge

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

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

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

Attach logical switch to NSX Edge

1. Click the radio button next to vnic7.

Name the Interface

1. Name the Interface: Prod_Interface.