VMware Hands-on Labs - HOL-1803-01-NET


Lab Overview - HOL-1803-01-NET - Getting Started with VMware NSX

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:

Lab Captains:

 This lab manual can be downloaded from the Hands-on Labs Document site found here:

http://docs.hol.vmware.com

This lab may be available in other languages.  To set your language preference and have a localized manual deployed with your lab, you may utilize this document to help guide you through the process:

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Location of the Main Console

 

  1. The area in the RED box contains the Main Console.  The Lab Manual is on the tab to the Right of the Main Console.
  2. A particular lab may have additional consoles found on separate tabs in the upper left. You will be directed to open another specific console if needed.
  3. Your lab starts with 90 minutes on the timer.  The lab can not be saved.  All your work must be done during the lab session.  But you can click the EXTEND to increase your time.  If you are at a VMware event, you can extend your lab time twice, for up to 30 minutes.  Each click gives you an additional 15 minutes.  Outside of VMware events, you can extend your lab time up to 9 hours and 30 minutes. Each click gives you an additional hour.

 

 

Alternate Methods of Keyboard Data Entry

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

 

 

Click and Drag Lab Manual Content Into Console Active Window

You can also click and drag text and Command Line Interface (CLI) commands directly from the Lab Manual into the active window in the Main Console.  

 

 

Accessing the Online International Keyboard

 

You can also use the Online International Keyboard found in the Main Console.

  1. Click on the Keyboard Icon found on the Windows Quick Launch Task Bar.

 

 

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

 

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.

 

Module 1 - NSX Manager Installation and Configuration (15 Minutes)

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:


 

NSX Components

 

 

Hands-on Labs Interactive Simulation: NSX Installation and Configuration - Part 1


 

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.

 

*** 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.

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.

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:

Proceed to any module below which interests you the most:

Lab Module List:

Lab Captains:

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 2 - Logical Switching (30 minutes)

Logical Switching - Module Overview


In this module, we will explore the following components of VMware NSX:


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.

 

 

Navigate to Networking & Security in vSphere Web Client

 

  1. Click Home icon.
  2. Click Networking & Security.

 

 

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

 

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

 

 

Test connectivity between Web-03a & Web-04a

 

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).


 

NSX Controllers' Scalability and Availability

 

  1. Click Home icon.
  2. Click Networking & Security.

 

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:

Proceed to any of the following modules:

Lab Module List:

Lab Captains:

 

 

How to End Lab

 

To end your lab, click on the END button.  

 

Module 3 - Logical Routing (60 minutes)

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:


 

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.  

 

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

 

 

 

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

 

 

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.
  3. Click Networking & Security.

 

 

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.

 

 

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

 

 

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.

 

 

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.

  1. Click Back until we return to NSX Edges section.

 

 

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.

 

 

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.

  1. Click on HOL - Customer Database browser tab (this tab was opened in the 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).

 

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

 

The above diagram shows the current topology where OSPF is redistributing the routes between Perimeter Gateway and Distributed Router. In addition, we also see the northbound link from Perimeter Gateway to the vPod Router.

 

 

Look at OSPF Routing in Perimeter Gateway

First we will confirm the Web App is functional, then we will log into the NSX Perimeter Gateway to view OSPF neighbors and see existing route distribution.  This will show how the Perimeter Gateway is learning routes from not only the Distributed Router, but the vPod router that is running the entire lab.

 

 

Confirm 3 Tier Application Functionality

 

  1. Open a new browser tab.
  2. Click Customer DB App bookmark.

 

 

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.  

 

 

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.

 

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.


 

Navigate to NSX in vSphere Web Client

 

  1. Click vSphere Web Client browser tab.
  2. Click Home icon.
  3. Click Networking & Security.

 

 

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.

 

 

 

  1. Click Manage.
  2. Click Settings.
  3. Click Interfaces.
  4. Select vNIC 0.
  5. Click on the Edit pencil.

 

 

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.

 

 

Add Additional Perimeter Gateway Edge

 

 

 

Select and Name Edge

 

  1. Select Edge Services Gateway as Install Type.
  2. Enter Perimeter-Gateway-02 as Name.
  3. Click Next.

 

 

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.

 

 

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.

 

 

Continue Deployment

 

  1. Click Next.

 

 

 

  1. Click Green Plus icon. This will add the first interface.

 

 

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.

 

 

Name and Add IP

 

  1. Enter Uplink as Name.
  2. Select Uplink as Type.
  3. Click Green Plus icon.
  4. Enter 192.168.100.4 as Primary IP Address.
  5. Enter 24 as Subnet Prefix Length.
  6. Click OK.

 

 

Add Edge Transit Interface

 

  1. Click Green Plus icon. This will add the second interface.

 

 

Select Switch Connected To

 

We have to pick the northbound switch interface (VXLAN Backed Logical Switch) for this Perimeter Gateway.

  1. Click Select under Connected To.
  2. Click Logical Switch.
  3. Select Transit_Network_01_5006.
  4. Click OK.

 

 

Name and Add IP

 

  1. Enter Transit_Network_01 as Name.
  2. Select Internal as Type.
  3. Click Green Plus icon.
  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.

 

 

Continue Deployment

 

Ensure the IP Addresses and Subnet Prefix Length information are the same as the picture.

  1. Click Next.

 

 

Remove Default Gateway

 

We are removing the default gateway since information is received via OSPF.

  1. Uncheck Configure Default Gateway.
  2. Click Next.

 

 

Default Firewall Settings

 

  1. Check Configure Firewall default policy.
  2. Select Accept as the Default Traffic Policy.
  3. Click Next.

 

 

Finalize Deployment

 

  1. Click Finish. This will start the deployment.

 

 

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.

  1. Double-click Perimeter-Gateway-02.

 

 

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.

 

 

Topology Overview

 

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

 

 

Verify ECMP Functionality from Distributed Router

 

Let's now access the distributed router to ensure that OSPF is communicating and ECMP is functioning.

  1. Click Home icon.
  2. Click VMs and Templates.

 

 

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.

 

 

Shutdown Perimeter Gateway 01

 

We will simulate a node going offline by shutting down Perimeter-Gateway-01.

Return to vSphere Web Client browser tab.

  1. Expand RegionA01.
  2. Right-click Perimeter-Gateway-01-0.
  3. Click Power.
  4. Click Shut Down Guest OS.

 

 

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.

 

 

Access Distributed Router VM Console

 

  1. Click Distributed-01-0 browser tab.

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.

 

 

Power Up Perimeter Gateway 01

 

Return to vSphere Web Client browser tab.

  1. Expand RegionA01.
  2. Right-click Perimeter-Gateway-01-0.
  3. Click Power.
  4. Click Power On.

 

 

Return to Ping Test

 

 

 

Access Distributed Router VM Console

 

  1. Click Distributed-01-0 browser tab.

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.

 

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

 

Return to vSphere Web Client browser tab.

  1. Click Home icon.
  2. Click Networking & Security.

 

 

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

 

  1. Double-click Distributed-Router-01.

 

 

Disable ECMP on Distributed Router

 

  1. Click Manage.
  2. Click Routing.
  3. Click Global Configuration.
  4. Click Disable.

 

 

Publish Change

 

  1. Click Publish Changes to push the configuration change.

 

 

Return to Edge Devices

 

  1. Click Back until we return to NSX Edges section.

 

 

Access Perimeter Gateway 01

 

  1. Double-click Perimeter-Gateway-01.

 

 

Disable ECMP on Perimeter Gateway 01

 

  1. Click Manage.
  2. Click Routing.
  3. Click Global Configuration.
  4. Click Disable.

 

 

Publish Change

 

  1. Click Publish Changes to push the configuration change.

 

 

Enable Firewall on Perimeter Gateway 01

 

  1. Click Manage.
  2. Click Firewall.
  3. Click Enable.

 

 

Publish Change

 

  1. Click Publish Changes to update the configuration on Perimeter-Gateway-01 (NSX Edge).

 

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

Congratulations on completing Module 3!

If you are keen to learn more about NSX, please visit the NSX 6.3 Documentation Center via the following URL:

Proceed to any of the following modules:

Lab Module List:

Lab Captains:

 

 

How to End Lab

 

To end your lab, click on the END button.  

 

Module 4 - Edge Services Gateway (60 minutes)

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

 

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.

 

 

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.

 

 

Navigate to Networking & Security in vSphere Web Client

 

  1. Click Home icon.
  2. Click Networking & Security.

 

 

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.
  2. Click Green Plus icon.

 

 

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.

 

 

Configuring Admin account

 

  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.

 

 

Defining Edge Size and VM placement

 

There are four different appliance sizes for Edge Service Gateway. The specifications (#CPUs, Memory) are as follows:

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.

 

 

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.

 

 

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.

  1. Click Green Plus icon.

 

 

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.

 

 

Selecting Network for New Edge Interface

 

This one-armed load balancer's interface will need to be on the same network as the two web servers that this Edge will be providing Load Balancing services.

  1. Click Logical Switch.
  2. Select Web_Tier_Logical_Switch (5000).
  3. Click OK.

 

 

Configuring Subnets

 

  1. Click Green Plus icon. This will configure the IP address of this interface.

 

 

Configuring Subnets Popup

 

To add a new IP address to this interface:

  1. Enter 172.16.10.10 as the Primary IP Address.
  2. Enter 24 as the Subnet Prefix Length.
  3. Click OK.

 

 

Confirm List of Interfaces

 

Ensure the IP Addresses and Subnet Prefix Length information are the same as the picture above.

  1. Click Next.

 

 

Configuring the Default Gateway

 

  1. Enter 172.16.10.1 as the Gateway IP.
  2. Click Next.

 

 

Configuring Firewall and HA options

 

  1. Check Configure Firewall default policy.
  2. Select Accept as the Default Traffic Policy.
  3. Click Next.

 

 

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.

  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.

 

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.

 

 

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.
  3. Click Global Configuration.
  4. Click Edit to change Load Balancer global configuration.

 

 

Edit Load Balancer Global Configuration

 

To enable the Load Balancer service:

  1. Check Enable Load Balancer.
  2. Click OK.

 

 

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.

 

 

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.

 

 

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.

 

 

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:

  1. Enter Web-Tier-Pool-01 as the Name.
  2. Select default_https_monitor as the Monitors.
  3. Click Green Plus icon.

 

 

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:

 

 

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
  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.
  2. Enter 172.16.10.10 as the IP Address.
  3. Select HTTPS as the Protocol.
  4. Select Web-Tier-Pool-01.
  5. Click OK.

 

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.

 

 

Ignore SSL error

 

  1. Click on Proceed to 172.16.10.10 (unsafe).

 

 

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.  

 

 

Show Pool Statistics

 

Return to vSphere Web Client browser tab.

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.

  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.

 

 

Login to OneArm-LoadBalancer-0

 

  1. Login as admin.
  2. Enter VMware1!VMware1! as password.

 

 

Special Instructions for CLI Commands

 

Many of the modules will have us enter Command Line Interface (CLI) commands.  There are two ways to send CLI commands to the lab.

First to send a CLI command to the lab console:

  1. Highlight the CLI command in the manual and use Control+c to copy to clipboard.
  2. Click on the console menu item SEND TEXT.
  3. Press Control+v to paste from the clipboard to the window.
  4. Click the SEND button.

Second, a text file (README.txt) has been placed on the desktop of the environment providing you with all the user accounts and passwords for the environment.

 

 

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.

 

 

SSH to web-01a.corp.local

 

  1. Scroll down to web-01a.corp.local.
  2. Select 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

 

 

Loadbalancer console

 

  1. Enter show service loadbalancer pool.
show service loadbalancer pool

Because the service is down, the failure detail shows the client could not establish SSL session.

 

 

Start Nginx Service

 

Switch back to the Putty SSH session for web-01a.

1. Enter systemctl start nginx.

systemctl start nginx

 

 

Shutdown web-01a

 

Return to vSphere Web Client browser tab.

  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.

 

 

Check the Pool status

 

  1. Enter show service loadbalancer pool.
show service loadbalancer pool

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.

 

 

Power web-01a on

 

Return to vSphere Web Client browser tab.

  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.

 

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.

 

 

Open Network & Security

 

  1. Click Home icon.
  2. Click Networking & Security.

 

 

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.

  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.

  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

 

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

 

  1. Click Publish Changes to update the configuration on Perimeter-Gateway-01 (NSX Edge).

 

 

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:

  1. Open a new browser tab.
  2. Click Customer DB App bookmark.

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

 

Return to vSphere Web Client browser tab.

  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

 

  1. Click Publish Changes to update the configuration on Perimeter-Gateway-01 (NSX Edge).

 

 

Confirm Access to Customer DB App

 

Return to Customer DB App browser tab.

  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

 

  1. Click Publish Changes to update the configuration on Perimeter-Gateway-01 (NSX Edge).

 

 

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.

 

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:

In this lab, the following items have been pre-setup


 

Lab Topology

 

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

 

 

Access NSX Through the vSphere Web Client

 

  1. Click Home icon.
  2. Click Networking & Security.

 

 

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.

 

 

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.
  2. Double-click Perimeter-Gateway-01.

 

 

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.

 

 

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.
  2. Click Hosts and Clusters.

 

 

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.

 

 

Verify DHCP Lease

 

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.

 

 

Access Booted VM

 

  1. Click PXE VM browser tab.

 

 

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.

 

 

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.

 

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).

 

 

Navigate to Networking & Security Section of the vSphere Web Client

 

  1. Click Home icon.
  2. Click Networking & Security.

 

 

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

 

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

 

  1. Enter VMware1!VMware1! as Password.
  2. Enter VMware1!VMware1! for Confirm password.
  3. Check Enable SSH access.
  4. Click Next.

 

 

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.

 

 

Setting the Router ID for this NSX Edge

 

Next, we will be configuring dynamic routing on this Edge Gateway.

  1. Click Routing.
  2. Click Global Configuration.
  3. Click Edit to change Dynamic Routing Configuration.

 

 

Configuring OSPF on the L2VPN-Server NSX Edge

 

  1. Click OSPF.
  2. Click Green Plus icon under Area to Interface Mapping.

 

 

Enable OSPF Route Redistribution

 

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

 

 

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.

 

 

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.

 

 

Configuring the L2VPN-Client NSX Edge Gateway

 

  1. Double-click L2VPN-Client.

 

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:

We will configure the newly supported NSX L2 Bridging.

 

 

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.  

 

 

Access vSphere Web Client

 

 

 

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 attached to the Web-Tier-01 Logical Switch. The Web-Tier-01 Logical Switch is isolated from the Bridged-Net.

 

 

Migrate Web-01a to RegionA01-MGMT01 Cluster

 

  1. Click Home icon.
  2. Click VMs and Templates.

 

 

View Connected VMs

 

  1. Click Home icon
  2. Click Networking.

 

 

Migrate Web_Tier_Logical_Switch to Distributed Logical Router

 

  1. Click Home icon.
  2. Click Network & Security.

 

 

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

 

 

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

 

 

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.

 

 

Migrate Web-01a back to RegionA01-COMP01 Cluster

 

  1. Click Home icon.
  2. Click VMs and Templates.

 

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

Congratulations on completing Module 4!

If you are keen to learn more about NSX, please visit the NSX 6.3 Documentation Center via the following URL:

Proceed to any of the following modules:

Lab Module List:

Lab Captains:

 

 

How to End Lab

 

To end your lab, click on the END button.  

 

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