HOL-SDC-1625

VMware Hands-on Labs - HOL-SDC-1625

Lab Overview - HOL-SDC-1625 - VMware NSX Advanced

Lab Guidance

Welcome to the VMware NSX Advanced (HOL-SDC-1625) Hands-On Lab!

This lab will demonstrate many of the newer and advanced features provided by VMware NSX for vSphere. During the first three modules we show the new Cross-vCenter capabilities provided by NSX 6.2; module 4 and 5 describe NSX capabilities of doing L2 Bridging and L2VPN respectively. Module 6 provides insight on how to manage NSX using the new Central CLI, and in module 7 we show how to programmatically control NSX through RESTful APIs. Some of these modules might require a lot of time: do not expect to be able to complete the entire lab with a single session.

In order to achieve the best learning experience we suggest, If you don't have any previous hands-on experience on NSX, to start with the "VMware NSX Introduction" (HOL-SDC-1603) lab as it provides more basic content.

Thank you and enjoy the labs! 

Lab Module List:

Each module can be run independently from others. However, as both Module 2 and 3 have a dependency on the Multi-vCenter configuration done on Module 1, a Fast Forward script is provided and must be launched if you're planning to take Module 2 or 3 without having done Module 1. Additional details will be provided in the manual sections of Modules 2 and 3.

Lab Captains:

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

http://docs.hol.vmware.com/HOL-2016

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

 

Special Instructions for CLI Commands

 

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

First to send a CLI command to the lab console:

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

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

 

 

Activation Prompt or Watermark

 

When you first start your lab, you may notice a watermark on the desktop indicating that Windows is not activated.  

One of the major benefits of virtualization is that virtual machines can be moved and run on any platform.  The Hands-on Labs utilizes this benefit and we are able to run the labs out of multiple datacenters.  However, these datacenters may not have identical processors, which triggers a Microsoft activation check through the Internet.

Rest assured, VMware and the Hands-on Labs are in full compliance with Microsoft licensing requirements.  The lab that you are using is a self-contained pod and does not have full access to the Internet, which is required for Windows to verify the activation.  Without full access to the Internet, this automated process fails and you see this watermark.

This cosmetic issue has no effect on your lab.  

 

 

Screen Resolution

The Hands-On Labs environment should automatically adapt the screen resolution to the size of the browser window, to provide an optimal experience.

You can however manually modify the resolution from the Control Panel to fit you screen.

 

 

Disclaimer

This session may contain product features that are 
currently under development.

This session/overview of the new technology represents 
no commitment from VMware to deliver these features in 
any generally available product.

Features are subject to change, and must not be included in contracts, purchase orders, or sales agreements of any kind.

Technical feasibility and market demand will affect final delivery.

Pricing and packaging for any new technologies or features discussed or presented have not been determined.

 

Lab Topology

This lab consists in two separate sites (named Site A and Site B), each one with its own vCenter, dedicated vSphere 6.0 hosts, storage and network subnets. The vCenters share a common Platform Services Controller (PSC), that allow common Identity Management, Licensing and Application Interaction across sites.

Site A consists in two clusters:

The two clusters share a common Management subnet (192.168.110.0/24), as well as a vMotion (10.10.30.0/24) and an IP storage network (10.10.20.0/24).

Networks dedicated to NSX VTEPs (VXLAN Tunnel End Points) are separate, as "Management & Cluster Cluster" is using the 192.168.120.0/24 subnet, while "Compute Cluster A" is using 192.168.130.0/24. The VTEP subnets are routed together by an external router (vpodrouter).

Site B consists in a single cluster:

Site B has its own Management subnet (192.168.210.0/24), as well as separate vMotion (10.20.30.0/24), IP storage (10.20.20.0/24) and VTEP (192.168.230.0/24) networks.

Management, vMotion and VTEP networks are routed across the different sites to allow common management, Cross-vCenter vMotion and network extensibility (VXLAN).

All VTEP networks have a 1600 byte MTU configured, to allow VXLAN encapsulation to occur.

 

Virtual Environment Topology

 

The picture shows the vSphere hosts and how VMs are placed across the different clusters, as well as the Distributed Virtual Switches (DVS). VTEP IP addresses associated to the hosts are also displayed.

"Management & Edge Cluster" and "Compute Cluster A" are both managed by vCenter Server A (vcsa-01a.corp.local); "Compute Cluster B" is managed by vCenter Server B (vcsa-01b.corp.local). Both vCenters are connected to a common Platform Services Controller (psc-01a.corp.local) that resides on the management network of Site A.

NSX Transport Zone (TZ) configuration in the lab consists in the following:

Virtual Machine web-04a resides on the "Management & Edge Cluster" and is attached on a VLAN-backed Port Group on VLAN 101: it will be used to demonstrate the L2 bridging capabilities on NSX in Module 4.

 

 

Preconfigured Logical Network Topology

 

When first accessing the lab, the topology shown in the picture is already implemented. Three NSX Logical Switches are configured (Web-Tier-01, App-Tier-01, DB-Tier-01) and a 3-Tier Web Application is configured, with a Load Balancer configured in One-Arm mode on the web tier. The Logical Switches are attached to a Distributed Logical Router (DLR), which is in turn attached to an NSX Edge Services Gateway (ESG). OSPF Dynamic Routing guarantees route exchange information between the DLR and the ESG, while BGP is used for routing between the ESG and the external router.

A second ESG is already configured on the Site A Uplink subnet and will be used during the module exercises.

 

 

Final Logical Network Topology

 

Upon completition of Modules 1,2,3 and 4, the topology in the picture will be configured in the lab, as follows:

L2VPN Topology created in Module 5 is not shown.

 

Module 1 - Cross-vCenter NSX Networking

Cross vCenter NSX Overview

NSX 6.2 allows you to manage NSX environments containing multiple vCenter servers from a single primary NSX Manager.

Cross-vCenter NSX environments have many advantages:

 

How Cross-vCenter NSX Works

 

In a cross-vCenter NSX environment, you can have multiple vCenter Servers, each of which must be paired with its own NSX Manager. One NSX Manager is assigned the role of primary NSX Manager, and the others are assigned the role of secondary NSX Manager.

The primary NSX Manager is used to deploy a universal controller cluster that provides the control plane for the cross-vCenter NSX environment. The secondary NSX Managers do not have their own controller clusters.

The primary NSX Manager can create universal objects, such as universal logical switches. These objects are replicated to the secondary NSX Managers by the NSX Replicator Service. You can view these objects from the secondary NSX Managers, but you cannot edit them there. You must use the primary NSX Manager to manage universal objects. The primary NSX Manager can be used to configure any of the secondary NSX Managers in the environment.

On both primary and secondary NSX Managers, you can create objects that are local to that specific vCenter NSX environment, such as logical switches, and logical (distributed) routers. They will exist only within the vCenter NSX environment in which they were created. They will not be visible on the other NSX Managers in the cross-vCenter NSX environment.

NSX Managers can be assigned the standalone role. This is equivalent to pre-NSX 6.2 environments with a single NSX Manager and single vCenter.

 

 

Primary NSX Manager Configuration

The primary NSX Manager can create universal objects that are replicated to secondary NSX Managers.

There is only one primary NSX Manager in a Cross-vCenter NSX environment.

The primary NSX Manager is used to deploy a universal controller cluster that provides the control plane for the multi-vCenter NSX environment. The secondary NSX Managers do not have their own controller clusters.

The primary NSX Manager can:

 

 

Login in to the vSphere Web Client

 

*****This is a cross-site lab so always pay attention to which site you are working and performing tasks!*****

 

 

Login to vSphere Web Client

 

  1. Check the box to Use Windows session authentication.
  2. Click Login.

Note: If the "Use Windows Session Authentication" is not available, User name: CORP\Administrator with a Password: VMware1! can be used to login.

 

 

Navigate to the NSX Configuration

 

 

 

Verify the NSX Manager and Controller Configuration

 

  1. From the Network & Security navigation bar on the left side of the screen, select 'Installation'.
  2. Ensure that the 'Management' tab is selected.

 

 

Verify NSX Host Preparation

 

  1. Access the 'Host Preparation' frame via the tab row near the top of the screen.
  2. Ensure Primary NSX Manager 192.168.110.15 associated with Data Center A is selected to see the Clusters associated with this NSX Manager.
  3. Use the highlighted arrows to view the status of the NSX components on individual hosts.

 

 

Verify NSX VXLAN Transport Configuration

 

  1. Access the 'Logical Network Preparation' frame via the tab row near the top of the screen.
  2. Ensure that the 'VXLAN Transport' button is selected.
  3. Use the highlighted arrows to view the logical networking configuration of the hosts and clusters associated with the selected NSX Manager.
  4. The 'NSX Manager' drop down menu under the tabs atop the screen can be used to view the clusters attached to either of the two vCenter servers in this environment.

 

 

Verify the Segment ID Pool

 

  1. Select the 'Segment ID' button.
  2. Verify that there is an existing VXLAN Segment ID pool with the value '5000-5999'.

 

 

Verify the Local Transport Zone

 

  1. Select the 'Transport Zones' button.
  2. Verify that there is an existing transport zone with a 'Global' scope and 'Unicast' control plane mode.

 

 

Assign the Primary Role to NSX Manager

 

  1. Select 'Management' from the tabs at the top of the screen.
  2. Highlight the NSX Manager attached to vCenter vcsa-01a.corp.local (192.168.110.15).
  3. Select the 'Actions' icon.
  4. Select 'Assign Primary Role'.

 

 

Verify NSX Manager 192.168.110.15 is now Primary Role

 

Notice a new column has been added for Role.  You will see 192.168.110.15 is now Primary and 192.168.210.15 is Standalone.

 

 

Create a Universal Segment ID Pool

 

  1. Select the 'Logical Network Preparation' tab.
  2. Click on the 'Segment ID' button.
  3. Click on the 'Edit' button.
  4. Enter '200000-201000' for the Universal Segment ID pool value.
  5. Click OK.

 

 

Create a Universal Transport Zone

 

  1. Select the 'Transport Zones' frame.
  2. Ensure the Primary NSX Manager is selected. It's IP address will be followed by (Role: Primary)
  3. Click the green '+' in order to add a transport zone.
  4. Click the check box to make this transport zone a universal object (Mark the object for Universal Synchronization).
  5. Name the transport zone 'Universal-Transport-Zone'.
  6. Click the radio button next to 'Unicast' for Replication Mode.
  7. Select the check boxes next to both Compute Cluster A and the Management &Edge Cluster in order to join them to the transport zone.
  8. Press OK.

 

 

Verify Creation of Universal Transport Zone

 

You will see a new zone scope of Universal type named Universal-Transport-Zone.

 

 

Secondary NSX Manager Configuration

After a primary Multi-vCenter NSX Manager has been created, secondary NSX Managers can be created. Secondary NSX Managers are synced to receive control clusters that are configured and deployed by the primary NSX Manager. There can be seven secondary NSX Managers in a Multi-vCenter environment.

 

 

Registering a Secondary NSX Manager

 

  1. Select the 'Management' tab from the top of the screen
  2. Highlight the NSX Manager whose Role value is 'Primary' (192.168.110.15).
  3. Click on the 'Actions' icon.
  4. Select the 'Add Secondary NSX Manager' item.

 

 

Secondary NSX Manager Parameters

 

  1. Ensure that the NSX Manager 192.168.210.15 is selected in the drop down menu.
  2. The User Name is 'admin'
  3. The Password is 'VMware1!'
  4. Click OK.

 

 

Accept Certificate

 

 

 

Verify NSX Manager Roles in Cross-site

 

You now have two NSX Managers configured to work as one in a primary and secondary role.

 

 

Add Cluster B to the Universal Transport Zone

 

  1. Select the 'Logical Network' tab at the top of the frame.
  2. Choose NSX Manager '192.168.210.15 (Role: Secondary)' from the drop down menu.
  3. Select the 'Transport Zones' button from the row below the NSX Manager drop down menu.
  4. Highlight the 'Universal-Transport-Zone'
  5. Click the indicated icon to connect a cluster to a transport zone.
  6. Check the box to connect Compute Cluster B to the Universal-Trasport-Zone.
  7. Click OK.

 

Cross vCenter Logical Switching

Universal logical switches allow layer 2 networks to span multiple sites without having to purchase any additional physical network devices.

When you create a logical switch, if you select a universal transport zone, you create a universal logical switch. This switch is available on all clusters in the universal transport zone. The universal transport zone can include clusters in any vCenter in the multi-vCenter NSX environment.

There can be only one universal transport zone in a multi-vCenter NSX environment.

You must use a universal logical router to route between universal logical switches. If you need to route between a universal logical switch and a logical switch, you must use an Edge Services Gateway.

 

Create Universal Logical Switches

 

Both primary and secondary NSX Managers can have logical switches that are local to the environment in which they are created.

When you are adding logical switches, it is important to have in mind a particular topology that you are building. For example, the following simple topology shows two logical switches connected to a single distributed logical router (DLR). In this diagram, each logical switch is connected to a single VM. The two VMs can be on different hosts or the same host, in different host clusters or in the same host cluster. If a DLR does not separate the VMs, the underlying IP addresses configured on the VMs can be in the same subnet. If a DLR does separate them, the IP addresses on the VMs must be in different subnets (as shown in the example).

 

 

Create a Universal Transit Logical Switch

 

  1. Select 'Logical Switches' from the navigation menu on the left side of the screen.
  2. Select 192.168.110.15 (Role: Primary) NSX Manager.
  3. Select the green '+' icon to configure a new logical switch.
  4. In the 'Name:' field, enter 'ULS-Transit-Network-02'.
  5. Select 'Change' in order to select the 'Universal-Transport-Zone' which was previously created. Adding a logical switch to a trasport zone marked for universal synchronization will mark that switch for universal synchronization as well.
  6. Ensure the transport zone default of 'Unicast' replication is selected.
  7. Click OK.

 

 

Create Universal Logical Switches for a 3 Tier Application

 

Following the procedure in the previous step, create Web, App, and DB tier universal logical switches.

Segment ID numbers for the logical switches will be assigned in the order fo their creation.

 

 

Verify Cross vCenter Logical Switching

Now that the environment contains multiple universal logical switches, the operation of those logical switches will be verified both within a vCenter, and across vCenters.

 

 

Attach a VM to a Universal Logical Switch

 

  1. In the list, click on the 'ULS-Web-Tier-02' logical switch to highlight it.
  2. Select the 'Add Virtual Machine' icon.
  3. From the list, select the 'web-03a' VM.
  4. Use the right pointing arrow to assign it to the Selected Objects list on the right side of the dialog.
  5. Click 'Next'.
  6. On the next screen, select the check boxes representing the vNIC of the 'web-03a' VM and click 'Next' again.
  7. Click 'Finish'.

 

 

Select the vNIC

 

  1. Check the box for the only vNIC for web-03a.
  2. Click Next.

 

 

Finish adding web-03a to Logical Switch in Primary Site

 

 

 

Attach a VM in vCenter B to the Web Tier Universal Logical Switch

 

Attaching a VM in vCenter B to the Web Tier Universal logical switch will allow a test of connectivity across vCenter domains.

  1. Select '192.168.210.15 (Role: Secondary)' from the NSX Manager drop down menu.
  2. In the list, click on the 'ULS-Web-Tier-02' logical switch to highlight it.
  3. Select the 'Add Virtual Machine' icon.
  4. From the list, select the 'web-01b' VM.
  5. Be sure to use the right pointing arrow to assign them to the list on the right side of the dialog.
  6. Click 'Next'.

 

 

Select vNIC for web-01b

 

  1. Check the box for the only vNIC for web-01b.
  2. Click Next.

 

 

Finish adding web-01b to logical switch in Secondary Site

 

 

 

Open Hosts and Clusters

 

  1. Hover mouse over the Home icon.
  2. Select Hosts and Clusters.

 

 

Open a Console on Web-03a

 

  1. Expand the inventory trees.
  2. Select the 'web-03a' VM.
  3. Click Summary.
  4. Click on the link for 'Launch Remote Console'.

 

 

Test Connectivity Across vCenters

 

1.   In the open console command, login with the credentials root \ VMware1!

2.   Enter the following command to test cross vCenter connectivity on the ULS-Web-Tier-02 universal logical switch: ping -c 3 172.17.10.12  

ping -c 3 172.17.10.12

You are on web-03a with IP Address of 172.17.10.11.

(Remember to use the SEND TEXT option.)

This demonstrates connectivity between two VMs on the same universal logical switch managed by different vCenters.

 

Cross vCenter Logical Routing

Routing provides the necessary forwarding information between Layer 2 broadcast domains, thereby allowing you to decrease the size of Layer 2 broadcast domains and improve network efficiency and scale.

NSX extends this intelligence to where the workloads reside for East-West routing. This allows more direct VM-to-VM communication without the costly or timely need to extend hops. At the same time, NSX logical routers provide North-South connectivity, thereby enabling tenants to access public networks.

 

Attach Virtual Machines to the Universal Logical Switches

 

  1. Select the primary NSX Manager from the drop down menu.
  2. Select the 'ULS-App-Tier-02' logical switch from the list.
  3. Click the add VM to Logical Switch icon.
  4. Select the 'app-02a' VM and use the right facing arrow to move it to the selected objects menu.
  5. Click 'Next'.

 

 

Select the vNIC

 

  1. Check the box for the vNIC.
  2. Click Next.

 

 

Finish adding VM to Logical Switch

 

  1. Click Finish.
  2. Repeat this process to add 'db-02a' VM to the 'ULS-DB-Tier-02' logical switch.

 

 

Verify the VM Attachments to Logical Switches

 

  1. Click on Logical Switches.
  2. Choose a site:  In this case 192.168.110.15 Primary.
  3. Double-Click on ULS-Web-Tier-02.

 

 

Verify the VM Attachments

 

To verify the VMs attached to a given logical switch you have 2-options:

  1. Select 'Virtual Machines' from the box just below the name of the logical switch in the upper left section of the screen.
  2. This view can also be reached by selecting the 'Related Objects' tab and the 'Virtual Machines' button in the main panel.
  3. Click Virtual Machines.

Note: This view is site specific. You will only see the objects connected to the logical switch within the currently selected site in previous step.

 

 

Create a Universal Logical Distributed Router

Universal Logical (Distributed) Routers offer centralized administration and a routing configuration that can be customized at the universal logical router, cluster, or host level.

When you create a universal logical router you must choose whether to enable local egress, as this cannot be changed after creation. Local egress allows you to control what routes are provided to ESXi hosts based on the locale ID. If you do not enable local egress the locale ID is ignored and all ESXi hosts connected to the universal logical router will receive the same routes. Whether or not to enable local egress in a cross-vCenter NSX environment is a design consideration, but it is not required for all cross-vCenter NSX configurations.

 

 

Navigate to the Edges Page

 

  1. After using the Home menu at the top of the vSphere Web Client screen to navigate to 'Networking & Security', select 'NSX Edges' from the navigation menu on the left side of the screen.
  2. Ensure that the primary NSX Manager is selected from the drop down menu near the top of the frame.
  3. Click on the green '+' to create a new edge.

 

 

Name and Description

 

  1. From the radio buttons, select 'Universal Logical (Distributed) Router'.
  2. Give this device the name 'Universal-Distributed-Router'.
  3. Ensure that the 'Deploy Edge Appliance' box is checked.
  4. Leave all other values at their defaults, and click 'Next'.

Note: The option labeled 'Enable Local Egress' will be discussed at the end of the Cross vCenter Logical Routing section. Please not its existence for now.

 

 

Settings

 

  1. The default User Name should be set to 'admin'. If it is not already, please enter that value.
  2. NSX Edges require complex passwords. Please use 'VMware1!VMware1!'
  3. Check the box labeled 'Enable SSH access'.
  4. Leave all other values set to the default, and press 'Next'.

 

 

Configure Deployment

 

  1. Please ensure that 'Datacenter Site A' is selected in this drop down menu.
  2. Click the green '+' icon to add an NSX Edge appliance for the Universal Logical (Distributed) Router control VM.
  3. Select the 'Management & Edge Cluster' from the first drop down menu.
  4. The Datastore drop down menu should only have one entry, please select it.
  5. Click 'OK'.
  6. Click 'Next'.

 

 

Configure Interfaces

 

 

  1. Click Select for Connected To:
  2. Click on Distributed Portgroup.
  3. Click the radio button for vds-mgt_Management Network.
  4. Click OK.

Note: Do not configure an IP address on the HA interface.

 

 

Add interface to new Edge

 

 

 

Name Interface

 

  1. Enter UDLR-Transit-Network as the name.
  2. Unsure Uplink is selected.
  3. Click Select to choose connection network.

 

 

Choose Logical Switch

 

  1. Click on radio button for ULS-Transit-Network-02.
  2. Click OK.

 

 

Add Interface IP

 

  1. Click the Green Plus sign to add an IP Address.
  2. Enter 192.168.5.10.
  3. Enter 29 for the Subnet Prefix Lenght (mask).
  4. Click OK.

 

 

Add Additional Interfaces.

 

  1. Repeat the process for the following three interfaces. Add these subsequent interfaces as 'Internal' interfaces:
    • Name: UDLR-Web-Tier - Type: Internal - Connected to: ULS-Web-Tier-02 logical switch - with Interface IP: 172.17.10.1/24.
    • Name: UDLR-App-Tier -  Type: Internal - Connected to: ULS-App-Tier-02 logical switch - with Interface IP: 172.17.20.1/24.
    • Name: UDLR-DB-Tier - Type: Internal - Connected to: ULS-DB-Tier-02 logical switch - with Interface IP: 172.17.30.1/24.
  2. Click 'Next'.

 

 

Default Gateway Settings

 

  1. Uncheck the box labeled 'Configure Default Gateway'
  2. Click 'Next'.

 

 

Ready to Complete

 

  1. Review the configuration and ensure it matches the instructions.
  2. Click 'Finish'.

 

 

Configure ULDR Routing

In this step, routing will be configured on the Universal Logical (Distributed) Router which was just created.

 

 

Configure the new Universal Distributed Router

 

Double-click the new Universal Distributed Router

 

 

Navigate to Routing Configuration

 

  1. Select the 'Manage' tab from the top of the frame.
  2. Select the 'Routing' button.

 

 

Global Configuration

 

  1. Select 'Global Configuration' from the navigation menu on the left.
  2. Click on the 'Edit' button in the 'Dynamic Routing Configuration' section.
  3. Select the 'UDLR-Transit-Network' interface (192.168.5.10) as the Router ID from the drop down menu.
  4. Click 'OK'.

 

 

Publish Changes

 

 

 

OSPF Configuration

 

  1. Select the 'OSPF' item in the navigation menu to the left.
  2. Click on the 'Edit' button in the 'OSPF Configuration' section.
  3. Check the 'Enable OSPF' box.
  4. Enter 192.168.5.11 in the 'Protocol Address' box. This will be the IP address of the OSPF process on the Universal Logical Router Control VM for OSPF neighbor relationship purposes.
  5. Enter 192.168.5.10 in the 'Forwarding Address' box. This is the IP address of the logical interface (LIF) on the uplink interface of the Universal Logical Router.
  6. Click 'OK'.
  7. Click on the 'Publish Changes' button.

 

 

Area Definition

 

  1. Create a new OSPF area by clicking on the green '+' icon in the 'Area Definitions' section.
  2. Enter '0' in the 'Area ID' field.
  3. Ensure that 'Normal' is selected in the 'Type' drop down menu.
  4. Click 'OK'.
  5. Click on the 'Publish Changes' button.

 

 

Area to Interface Mapping

 

  1. In order to map the new OSPF area to an interface, click on the green '+' icon in the 'Area to Interface Mapping' section.
  2. Ensure that the 'ULDR-Tranist-Network' interface is selected in the drop down menu.
  3. Select '0' in the 'Area' drop down menu. Leave all other values at their defaults.
  4. Click 'OK'.
  5. Click on the 'Publish Changes' button.

 

 

Route Redistribution

 

Verify that the OSPF process is permitted to learn any Connected prefixes as shown above.

 

 

Verify Connectivity Between Logical Switches

Now that a logical routing topology has been established, connectivity between VMs attached to different logical switches must be verified.

 

 

Open a Console on Web-01b

 

  1. Hover the cursor over the Home menu icon at the top of the screen.
  2. Select 'Hosts and Clusters'
  3. Expand the inventory trees for Site B.
  4. Click the 'web-01b' VM.

 

 

Open Console

 

 

 

Test Connectivity Between Web-01b and App-02a

 

Click in side console and press enter.

1.  In the open console command, login with the credentials root \ VMware1!

2.  Enter the following command to test cross vCenter connectivity on the ULS-Web-Tier-02 universal logical switch: ping -c 3 172.17.20.11 (Remember to use the SEND TEXT option.)

ping -c 3 172.17.20.11

This demonstrates connectivity between two VMs on the different universal logical switches managed by different vCenters.

 

 

Test Connectivity Between Web-01b and DB-02a

 

Enter the following command to test cross vCenter connectivity on the ULS-Web-Tier-02 universal logical switch: ping -c 3 172.17.30.11

ping -c 3 172.17.30.11

This confirms connectivity to the DB tier across vCenter environments.

 

 

Configure Perimeter Gateway Routing

In this step, OSPF routing will be configured on Perimeter-Gateway-02 in order to peer with Universal-Distributed-Router.

 

 

Navigate to Networking & Security

 

  1. Hover over Home icon.
  2. Click on Networking & Security.

 

 

Open Perimeter-Gateway-02

 

  1. Click on NSX Edges.
  2. Double-click on Perimeter-Gateway-02.

 

 

Open vNIC# 1 to edit configuration

 

  1. Click on Manage.
  2. Click on Settings.
  3. Click on Interfaces.
  4. Click on vNIC# 1.
  5. Click on the Pencil to edit.

 

 

Configure Interface

 

  1. Edit Name to be UDLR-Transit.
  2. Set Type to Internal.
  3. Click on Select to choose the Logical Switch.
  4. Click on Logical Switch tab.
  5. Click on the Radio button for ULS-Transit-Network-02.
  6. Click OK.

 

 

Connect the Perimeter Gateway 02 to the Universal Transit Network

 

In the 'NSX Edges' view, double-click on 'Perimeter-Gateway-02'.

  1. Click the Green Plus sign to add IP Address.
  2. Use an IP address of 192.168.5.9
  3. Set the Subnet prefix length of 29 for this interface.
  4. Click 'OK'.

 

 

General Configuration

 

  1. Click Manage.
  2. Select 'Routing'.
  3. Click on the 'General Configuration' item in the menu bar on the left side of the frame.
  4. Verify that the 'Router ID' value is 192.168.100.6. This is the IP address of the uplink interface of this edge.

 

 

OSPF Configuration

 

  1. From the left menu bar, select 'OSPF'.
  2. Click on the 'Edit' button in the 'OSPF Configuration' section.
  3. Check the box next to 'Enable OSPF'.
  4. Check the box to 'Enable Default Originate'.
  5. Click 'OK'.

 

 

Publish Changes

 

Publish Changes.

 

 

Area to Interface Mapping

 

As Area 0 is already configured on the Perimeter Gateway, configuration can proceed directly to mapping an interface to that area.

  1. Click on the green '+' icon in the 'Area to Interface Mapping' section.
  2. Select 'ULDR-Tranist' in the drop down menu.
  3. Select '0' in the 'Area' drop down menu. Leave all other values at their defaults.
  4. Click 'OK'.
  5. In the green box that appears at the top of the screen, click on the 'Publish Changes' button.

 

 

Add One-Armed Load Balancer to serve Three-Tiered Application Function in a Cross vCenter Environment

 

In order to enable a three tiered application across the cross vCenter infrastructure, a one-armed load balancer will be connected to the universal logical web tier. The functionality of the application will then be verified.

 

 

Connect a One-Armed Load Balancer to the Universal Web Tier

 

  1. From the 'Networking & Security' menu bar on the left side of the screen, select 'NSX Edges'.
  2. Ensure that the primary NSX manager is selected in the drop down menu at the top of the central frame.
  3. Double-click on the NSX edge named 'OneArm-LoadBalancer-02'.

 

 

Edit the Edge Interface Configuration

 

To access the interface configuration of the edge:

  1. Click on the 'Manage' tab at the top of the screen.
  2. Select the 'Settings' button from the row beneath the tabs.
  3. Click on the 'Interfaces' item in the navigation bar on the left.
  4. Highlight the configuration of vNIC #0 by clicking on it in the interface list.
  5. Click on the 'Edit' button, which is indicated by the pencil icon.

 

 

Modify the Uplink Interface Configuration

 

  1. Rename this interface 'Web-Tier-02'.
  2. Ensure that the type 'Uplink' is selected in the drop down menu.
  3. Use the 'Change' link to select the 'ULS-Web-Tier-02'
  4. Click 'OK'.

 

 

Verify Connectivity to the Three-Tiered Application

 

  1. Open a new browser tab.
  2. Click on the Favorites bar bookmark "3-Tier WebApp Universal".

Output in the format shown in the screenshot should be displayed.

Please note the IP address and hostname of the currently accessed web server from within the load balancer pool.

To further test the application, holding shift while clicking on the 'Refresh' button will bypass the cached entry and create a new session to the other web server as the pool uses the round-robin algorithm.

 

 

Egress Optimization

 

All sites in a multi-site cross-vCenter NSX environment can use the same physical routers for egress traffic. However, if egress routes need to be customized, the local egress feature must be enabled when the universal logical router is created. This allows you to customize routes at the universal logical router, cluster, or host level.

This example of a cross-vCenter NSX environment in multiple sites has local egress enabled. The edge services gateways (ESGs) in each site have a default route that sends traffic out through that site's physical routers. The universal logical router is configured with two appliances, one in each site. The appliances learn routes from their site's ESGs. The learned routes are sent to the universal controller cluster. Because local egress is enabled, the locale ID for that site is associated with those routes. The universal controller cluster sends routes with matching locale IDs to the hosts. Routes learned on the site A appliance are sent to the hosts in site A, and routes learned on the site B appliance are sent to the hosts in site B.

When you create a universal logical router you must choose whether to enable local egress, as this cannot be changed after creation. Local egress allows you to control what routes are provided to ESXi hosts based on the locale ID. If you do not enable local egress the locale ID is ignored and all ESXi hosts connected to the universal logical router will receive the same routes.

Each NSX Manager is assigned a Locale ID, which is set to the NSX Manager UUID by default. Using a sitespecificuplink, each site can have a local routing configuration. This allows NSX 6.2 to support up to eight sites with local egress.

You can override the locale ID at the following levels:

 

Module 2 - Cross-vCenter NSX Security

Universal IP/MAC Sets

Note: If you have not completed Cross-vCenter NSX Networking (module 1), execute the 'FastForward.ps1' script on the control center desktop by double-clicking on it.

Distributed Firewall in a cross-vCenter NSX environment allows centralized management of rules that apply to all vCenter Servers in your environment. It supports cross-vCenter vMotion which enables you to move workloads or virtual machines from one vCenter Server to another and seamlessly extends your software defined datacenter security.

As your datacenter needs scale out, the existing vCenter Server may not scale to the same level. This may require you to move a set of applications to newer hosts that are managed by a different vCenter Server. Or you may need to move applications from staging to production in an environment where staging servers are managed by one vCenter Server and production servers are managed by a different vCenter Server. Distributed Firewall supports these cross-vCenter vMotion scenarios by replicating firewall policies that you define for the primary NSX Manager on up to seven secondary NSX Managers.

Once you designate an NSX Manager as the primary Manager, you can create universal rules within a universal section. These rules are replicated on all secondary NSX Managers in your environment. Rules in other sections remain local to the appropriate NSX Manager.

The following Distributed Firewall features are not supported in a cross-vCenter NSX environment:

Service Composer is not supported in a cross-vCenter NSX environment, so you cannot use it to create distributed firewall rules in the universal section.

The following objects can be created and used as rule semantics within Distributed Firewall Rules in the universal section.

 

Creating  Universal IP Sets

In this section, multiple universal IP set objects will be created to serve as the basis of cross-vCenter Distributed Firewall Rules.

 

 

Fast Forward PowerShell Script - Please Skip if you have completed Module 1

 

Each module in this Hands On Lab 1625 is self contained, but Module 3 requires the successful completion of the previous Modules 1 and 2. Given the time constraints of Hand On Lab, we have provided a "Fast Forward" PowerShell script which automates the configuration steps in Module 1 and 2 so that you can continue with Module 3 standalone.

If you are starting Module 3 without previously successfully completing Module 1 and 2, please execute the FastForward.ps1 PowerShell script located on the windows desktop.

 

 

Run Fast Forward.ps1 Script with PowerShell

 

 

 

Wait until the Script Completes

 

The script itself is very simple and does minimal validation as the primary focus is to complete Fast Forward activities. Running the script multiple times will generate errors due to duplicate objects already exist, and possibly create multiple Universal Logical Switches but the lab will not "break". Future versions of this script will improve error checking and rely on API response codes instead of Sleep timers.

 

 

Validate Fast Forward script Completion

 

 

 

Login in to the vSphere Web Client

 

Open an web browser from the lab desktop, and open the bookmark labeled 'Site A Web Client'.

 

 

Login to vSphere Web Client

 

  1. Check the box to Use Windows session authentication.
  2. Click Login.

 

 

Navigate to the NSX Configuration

 

 

 

Navigate to the NSX Managers View

 

 

 

Add a new IP Set

 

  1. Select the Primary NSX Manager (192.168.110.15)
  2. Click on the 'Manage' tab.
  3. Click on the 'Grouping Objects' button.
  4. Select 'IP Sets'.
  5. Click on the green '+' icon to add a new IP set.

 

 

New IP Set Universal Web Servers

 

Create the following New IP Sets.

  1. Enter Universal Web Servers for the name.
  2. Enter 172.17.10.11-172.17.10.12 for the IP Addresses.
  3. Check the box for "Mark this object for Universal Synchronization".
  4. Click OK.

 

 

Add New IP Set for Universal App and DB

 

  1. Click the Green Plus Sign to add two more IP Sets:

 

 

Creating Universal Firewall Rules

It is now time to create Universal Firewall Rules based on the newly created Universal IP Set objects.

 

 

Navigate to the Firewall View

 

  1. Hover over the home menu icon.
  2. Select 'Networking & Security'
  3. Click on 'Firewall' in the left navigation menu.

 

 

Create a Universal Firewall Section

 

  1. Click on the 'Add Section' icon on the "Local Web Application (Rule 1-4) line.
  2. Enter the name 'Universal Firewall Section'.
  3. Check the box to 'Mark this section for Universal Synchronization'.
  4. Click 'OK'.

 

 

Create and Name a Universal Firewall Rule

 

  1. In the Universal Firewall Section, click on the 'Add Rule' icon (Green '+').
  2. In the newly created rule, click on the pencil icon to name the rule.
  3. Name the rule 'Web MicroSegmentation'.
  4. Click 'OK'.

 

 

Define the Source and Destination of the Rule

 

  1. Hover the cursor over the 'Source' field and click on the pencil icon that appears.
  2. Ensure that the 'IP Set' object type is selected in the drop down menu.
  3. Select the 'Universal Web Servers' object.
  4. Click on the arrow pointing right to select the object.
  5. Click 'OK'.

 

 

 

Set Destination

 

 

 

Set the Rule Action

 

  1. Hover the cursor over the 'Action' field of the firewall rule and click on the pencil icon that appears.
  2. Set the action in the drop down menu to 'Block'.
  3. Click 'OK'.
  4. Click on the 'Publish Changes' button to commit the new configuration.

 

 

Publish Rule

 

 

 

Create Another Firewall Rule

 

  1. Click on Rule #1.
  2. Click on the indicated green '+' icon to create another Universal Firewall Rule.
  3. Name: Allow Web Server Access - Source: any - Destination: Universal Web Server IP Set - Action: Allow.

 

 

Specify Firewall Rule Services for Allow Web Server Access.

 

  1. Hover the cursor over the 'Service' section of the firewall rule. Click on the pencil icon that appears.
  2. Enter https in the filter field and press Enter.
  3. Locate the services 'HTTPS'.
  4. Click on the right pointing arrow.
  5. Enter ssh in the filter field and press Enter.
  6. Locate the SSH service.
  7. Click the right pointing arrow.
  8. Click 'OK'.

 

 

Publish Changes

 

 

 

Navigate to Hosts and Clusters

 

  1. Hover over the Home Icon.
  2. Click on Hosts and Clusters.

 

 

Open a Console on Web-03a

 

  1. Expand out the tree for Datacenter Site A - Compute Cluster A.
  2. Select web-03a
  3. Click on Summary.
  4. Click on the link for 'Launch Remote Console'.

 

 

Test Micro Segmentation Rule Across vCenters

 

1.   In the open console command, login with the credentials root \ VMware1!

2.   Enter the following command to test cross vCenter connectivity on the ULS-Web-Tier-02 universal logical switch: ping -c 3 172.17.10.12  (Remember to use the SEND TEXT option.)

ping -c 3 172.17.10.12

This demonstrates that previously functional connectivity is being blocked by the Web MicroSegmentation rule.

 

Universal Security Groups

In this section, additional Universal Firewall Rules will be configured based on Universal Security Group objects.

 

Creating Additional Universal Firewall Rules

It is now time to create additional Universal Firewall Rules based on Universal Security Group objects.

 

 

Navigate to the Firewall View

 

  1. Hover over the home menu icon.
  2. Select 'Networking & Security'
  3. Click on 'Firewall' in the left navigation menu.

 

 

Create another Universal Firewall Rule

 

  1. Expand the Universal Firewall Section, then click on the green '+' icon to create a new rule.
  2. Name this rule 'Allow App Server Access'. Use the 'Universal Web Servers' IP Set object as the source of this rule.
  3. Highlight the destination field, and click on the pencil icon to edit it.
  4. Select 'Security Group' as the object type value in the drop down menu.
  5. Click on the 'New Security Group ...' link.

 

 

Add Security Group -  Name and Description

 

  1. Name the Security Group 'App Servers USG'.
  2. Click 'Next'.

 

 

Add a Security Group - Select Objects to Include

 

  1. Select 'IP Sets' in the object type drop down menu.
  2. Select the 'Universal App Servers' object from the list
  3. Use the right facing arrow to move it to the selected objects column.
  4. Click 'Finish'.
  5. Click 'OK' in the next dialog as well.

 

 

Create a Service

 

  1. Hover the cursor over the 'Service' section of the firewall rule. Click on the pencil icon that appears.
  2. Select the 'Service' object type from the drop down menu.
  3. Click on the 'New Service ...' link.

 

 

Define a New Service

 

  1. Name the service 'Tomcat'.
  2. Select 'TCP' from the protocol drop down menu.
  3. Enter '8443' as the destination port.
  4. Click 'OK'.
  5. Click 'OK' again in the next dialog box.

 

 

Create the Final Firewall Rule

 

Create the final Universal Firewall Rule in this environment. The rule is shown is the screenshot above.

  1. Once this is done, click on the 'Publish Changes' button.

 

 

Modify the Default Layer 3 Rule

 

Expand the 'Default Section Layer3' firewall section at the bottom of the frame.

  1. Change the action of the 'Default Rule' (the bottom rule in the list) to 'Block'.
  2. Click on the 'Publish Changes' button.

 

 

Verify Rule Synchronization

 

  1. Select the secondary NSX Manager from the drop down menu. Verify that the contents of the 'Universal Firewall Section' match those that were configured on the primary NSX Manager.
  2. Change the action of the 'Default Rule' in the 'Default Section Layer3' firewall section to 'Block'. This was also done on the primary NSX manager, however, the 'Default Section Layer3' cannot be marked for Universal Synchronization.
  3. Click 'Publish Changes'.

 

 

Open a Console on Web-03a

 

  1. Hover the cursor over the Home menu icon at the top of the screen.
  2. Select 'Hosts and Clusters'.
  3. Expand the inventory trees and select the 'web-03a' VM.
  4. Click on the link for 'Launch Remote Console'.

 

 

Check Connectivity Between the WebApp VMs

 

1.   In the open console command, login with the credentials root \ VMware1!

2.   Enter the following commands to test cross-vCenter connectivity between the VMs attached to the Universal Logical Switches:

ping -c 3 172.17.10.12
ping -c 3 172.17.20.11
ping -c 3 172.17.30.11

This demonstrates that previously functional connectivity is being blocked by the Universal Distributed Firewall Rules.

 

 

Verify Connectivity to the Three-Tiered Application

 

  1. Open a new browser window by clicking on a blank tab.
  2. Click on the favorite bookmark '3-Tier WebApp Universal'.

Please note the IP address and hostname of the currently accessed web server from within the load balancer pool.

3.     PressShift while clicking on the 'Refresh' button will bypass the cached entry and create a new session to the other web server as the pool uses the round-robin algorithm.

This concludes the cross-vCenter Security module.

 

 

Lab Clean up for next module

 

First you will set the Default Rule back to Allow on the Primary NSX Manager.

  1. Click on Firewall.
  2. Set the NSX Manager to Primary.
  3. Change the Default Rule to Allow.
  4. Publish Changes.

 

 

Change Default rule on Secondary NSX Manager

 

  1. Set the NSX Manager to Secondary.
  2. Change the Default Rule to Allow.
  3. Publish Changes.

Remember that rule synchronization does not apply to the Default Section.

 

Module 3 - Local and Universal Design Considerations

Routing

Module 3 will review routing considerations between networks connected via a Local Distributed Logical Router and between networks connected via Universal Distributed Logical Router.

Currently the Lab is configured so that the two 3-Tier Web Applications need to traverse individual North/South Edge Services Gateways to access each other requiring all traffic to traverse the common VLAN connecting the North/South Perimeter Edge Services Gateways to the core network.

In this lab, we will perform the following activities:

  1. Validate both the 3-Tier Local Application and 3-Tier Universal Application are functioning.
  2. Configure Equal Cost Multi Pathing (ECMP) across the Local and Universal Distributed Logical Routers and the North/South Perimeter Edge Services Gateways Perimeter-Gateway-01 and Perimeter-Gateway-02.
  3. Connect Transit-Network-01 Logical Switch to Perimeter-Gateway-02 and ULS-Transit-02 Universal Logical Switch to Perimeter-Gateway-01 demonstrating network connectivity between the two applications is now via the two Perimeter Edge Servies Gateways.

Notes:

ESG = Edge Services Gateway Used as Perimeter Routers and Load Balancers in this lab module.

DLR = Distributed Logical Routers. Used as kernel based routers in this lab module. Two types of DLR - A Local DLR (LDLR) is used within a single vCenter environment, and a Universal DLR (UDLR) is shared across multiple vCenter environments. We will use both a Local and Universal DLR in this lab module.

 

Network Topology Review for the 3-Tier Local Web Application

 

The 3-Tier Local Web Application is configured across a single data center with local NSX network objects. Web access is via the OneArm-LoadBalancer-01 configured with Domain Name htps://webapp.corp.local resolving to IP address 17.16.10.10.

 

 

Network Topology Review for 3-Tier Universal Web Application

 

The network topology for the 3-Tier Universal Web Application is shown. A Universal Distributed Logical Router connected to Universal Logical Switches provide L2 adjacency to Virtual Machines across two data centers.

Ingress and Egress are via the single North/South Edge Services Gateway named Perimeter-Gateway-02 located in Data Center Site A Management & Edge Cluster.

Web access is via the OneArm-LoadBalancer-02 configured with Domain Name https://webapp-universal.corp.local resolving to IP address 17.17.10.10.

 

 

Current Routing Configuration

 

As shown, routing between the two 3-Tier applications is through their respective Perimeter-Gateways via the core VLAN.

 

 

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.

 

 

Fast Forward PowerShell Script - Please Skip if you have completed Module 1

 

Each module in this Hands On Lab 1625 is self contained, but Module 3 requires the successful completion of the previous Module 1. Given the time constraints of Hand On Lab, we have provided a "Fast Forward" PowerShell script which automates the configuration steps in Module 1 so that you can continue with Module 3 standalone.

If you are starting Module 3 without previously successfully completing Module 1, please execute the FastForward.ps1 PowerShell script located on the windows desktop.

 

 

Run Fast Forward.ps1 Script with PowerShell

 

 

 

Wait until the Script Completes

 

The script itself is very simple and does minimal validation as the primary focus is to complete Fast Forward activities. Running the script multiple times will generate errors due to duplicate objects already exist, and possibly create multiple Universal Logical Switches but the lab will not "break". Future versions of this script will improve error checking and rely on API response codes instead of Sleep timers.

 

 

Validate Fast Forward script Completion

 

 

 

Validate the Local Web Application

In this exercise, we will validate the Local Web Application is functioning and correctly load balancing between the two web server VM's. If the application does not function, this indicates the previous Exercises miss-configured the lab or the lab did not start correctly. This application is configured to work from initial lab deployment.

 

 

Open Web Browser

 

 

 

Open the 3-Tier WebApp Local Link

 

 

 

Validate the 3-Tier Local Application and specific Web Server

 

  1. A new page should open called "Hands on Lab - Multi Tier Application"
  2. When you refresh the Load Balancing will select either web server web-01a or web-02a

The IP subnet if 172.16.10.X represents the Web-Tier-02 Logical Switch connected to the Universal-Distributed-Router with a gateway address of 172.16.10.1. Edge Services Gateway Load Balancer is on 172.16.10.10 and is configured to load balance between VM's web-01a and web-02a.

 

 

Validate Universal Web Application

The Universal Web Application is a 3-Tier application connected to Universal Logical Switches and a Universal Logical Router with VM's split between two data centers.

In this exercise, we will validate the Universal Web Application is functioning and correctly load balancing between two web servers.

Note: If the application does not function, this indicates a failure for the Lab to deploy, the previous Module 1 steps were not performed correctly, or the PowerShell Fast Forward script did not complete correctly. Redeploying the lab and using the Fast Forward script is likely the fastest path to resolution.

 

 

Open the 3-Tier WebApp Universal Link

 

 

 

Validate the 3-Tier Universal Application and specific Web Server

 

  1. A new page should open called "Hands on Lab - Multi Tier Application"
  2. Load Balancing will select either web server web-03a or web-01b

If your attempt to bring up the web page fails shortly after the Fast Forward PowerShell script has completed, Universal Distributed Logical Router and associated Edge appliance deployment may not have completed populating the routing table. Wait a minute and try again.

The IP subnet if 172.17.10.X represents the ULS-Web-Tier-02 Logical Switch connected to the Universal-Distributed-Router with a gateway address of 172.17.10.1. Edge Services Gateway Load Balancer is on 172.17.10.10 and is configured to load balance between VM's web-03a and web-01b.

 

 

Reload the Browser Window

 

 

 

Validate 3-Tier Universal Application uses new Web Server

 

This demonistrates the application and universal network objects are correctly configured and functioning together with an NSX Edge Services Gateway configured to provide load balancing for the application web tier.

 

 

Validate Topology and Routing Tables before Configuration Changes

In this step, we will use the NSX Manager CLI interface to validate the routing configuration on Edge Perimeter-Gateway-01 and Perimeter-Gateway-02. Perimeter-Gateway-01 will only know about the routes associated with the Local Distributed Logical Router (172.16.X.X) and Perimeter-Gateway-02 will only know about the routes associated with the Universal Distributed Logical Router (172.17.X.X).

 

 

Start Putty to ssh to nsxmgr-01a

 

 

 

SSH to NSX Manager nsxmgr-01a

 

  1. Scroll until you find the entry for nsxmgr-01a.corp.local.
  2. Click on nsxmgr-01a.corp.local.
  3. Click on the Open Button.

 

 

Show Routing Table on Perimeter-Edge-1

 

 

 

Increase the Window Size

 

 

 

Display NSX Edge List

 

  1. At the command prompt, use the SEND TEXT or enter the command below:
show edge all

The active Edges in the NSX environment are displayed.

 

 

Show Routing Table on Perimeter-Gateway-01

 

  1. At the command prompt, use the SEND TEXT or enter the command below:
show edge edge-3 ip route

The routing table from edge-3 Perimeter-Gateway-01 is displayed. Note the routes from the Local Distributed Logical Router (172.16.X.X) are displayed only. Access to the networks connected to the Universal Distributed Logical Router (172.17.X.X) are via the core network via the default route 0.0.0.0/0.

 

 

Show Routing Table on Perimeter-Gateway-02

 

  1. At the command prompt, use the SEND TEXT or enter the command below:
show edge edge-5 ip route

The routing table from edge-5 Perimeter-Gateway-02 is displayed. Note the routes from the Universal Distributed Logical Router (172.17.X.X) are displayed only. Access to the networks connected to the Local Distributed Logical Router (172.16.X.X) are via the core network via the default route 0.0.0.0/0.

 

 

Close Putty to nsxmgr-01a

 

  1. Click on the Close box to close the Putty Window.
  2. Click on the OK Button to Confirm.

 

 

Configure ECMP on ESG Perimeter-Gateway-01 Supporting Local DLR and 3-Tier Local Application

Equal Cost Multi Pathing is now going to be enabled across two Perimeter Edge Services Gateways and the Local and Universal Distributed Logical Routers in preparation for some multi pathing changes. We will start with ESG Perimeter-gateway-01.

 

 

Open a new Browser Tab

 

 

 

Open the Site A Web Client

 

 

 

Login to vCenter vcsa-01a.corp.local

 

  1. Enter User name: CORP\Administrator
  2. Enter Password: VMware1!
  3. Click on the "Login" button.

Optionally, click on the Use Windows session authentication box then click Login. You will be logged on to the Site A vSphere Web Client using the credentials of the Control Center Windows machine. (Corp\Administrator).

 

 

Navigate to NSX Networking & Security Menu

 

 

 

Navigate to NSX Edge Menu

 

 

 

Validate NSX Manager is the Primary Manager

 

 

 

Edit the ESG edge-3 Perimeter-Gateway-01

 

 

 

Enable ECMP

 

  1. Click on Manage.
  2. Click on Routing.
  3. Click on Global Configuration.
  4. Click on the Enable ECMP button to enable ECMP for this Edge.

 

 

Publish Changes

 

 

 

Return to the NSX Edge Menu

 

 

 

Configure ECMP on ESG Perimeter-Gateway-02  Supporting Universal DLR and 3-Tier Universal Application

 

 

Validate NSX Manager is the Primary Manager

 

 

 

Edit the ESG edge-5 Perimeter-Gateway-02

 

 

 

Enable ECMP

 

  1. Click on Manage.
  2. Click on Routing.
  3. Click on Global Configuration.
  4. Click on the ECMP: Enable button to enable ECMP for this Edge.

 

 

Publish Changes

 

 

 

Return to the NSX Edge Menu

 

 

 

Configure ECMP on the Local DLR Local-Distributed-Router Supporting the 3-Tier Local Application

The menu options are very slightly different between Local Distributed Logical Routers and Edge Services Gateways so we will step through the sequence. Feel free to click ahead.

 

 

Validate NSX Manager is the Primary Manager

 

 

 

Edit the Local Distributed Logical Router Local-Distributed-Router edge-2

 

 

 

Enable ECMP

 

  1. Click on the Routing tab.
  2. Click on the Global Configuration tab. This will allow you to configure routing global configuration options.
  3. Click Enable.

 

 

Publish Changes

 

 

 

Return to NSX Edges

 

 

 

Configure ECMP on ULDR Universal-Distributed-Router  Supporting 3-Tier Universal Application

The menu options are only very slightly different between Local Distributed Logical Routers and Universal Distributed Logical Routers, so we will step through the sequence.

 

 

Validate NSX Manager is the Primary Manager

 

 

 

Edit the Universal DLR named edge-e03... Universal-Distributed-Router

 

Note that the id of the edge may not match the screen image due to a unique UUID is created when the edge is created.

 

 

Open the Manage Tab for UDLR Universal-Distributed-Router

 

  1. Click on the Manage Tab.
  2. Click Routing.
  3. Click Global Configuration.

 

 

Edit Routing Configuration

 

 

 

Enable ECMP

 

  1. Click on the Enable ECMP Tick Box.
  2. Click on the OK Button.

 

 

Publish Changes

 

 

 

Return to the NSX Edge Menu

 

 

 

Summary of Equal Cost Multi Pathing Changes

Although ECMP is now enabled on the Local and Universal DLR's and two Perimeter ESG's supporting the DLR's, we have not introduced multiple paths into the environment, so there is no change to the current routing configuration. The environment is now prepared for equal cost multi pathing.

 

 

Preview of ECMP Topology using the Two Perimeter Edge Services Gateways

 

This is one example of an ECMP network topology. There are others.

 

 

Add Interface on ESG Perimeter-Gateway-01 to Universal Logical Switch ULS-Transit-Network-02

 

 

 

Navigate to NSX Edge Menu

 

 

 

Validate NSX Manager is the Primary Manager

 

 

 

Edit the ESG edge-3 Perimeter-Gateway-01

 

 

 

Configured an Unused Interface

 

  1. Click on Manage.
  2. Click on Settings.
  3. Click on Interfaces.
  4. Highlight the unused vnic2 on the ESG.
  5. Click the "Pencil" to edit the vNIC settings.

 

 

Maximize Browser Window

 

The ESG interface configuration screen needs the full screen to see the buttons at the bottom of the window. Maximizing the browser window will allow you to drag the screen so that you can click on the OK button.

 

 

Drag the Edit NSX Edge Interface Menu to the top of the screen

 

The ESG interface configuration screen needs the full screen to see the buttons at the bottom of the window. Dragging the Edit Interface window will allow you to drag the screen so that you can click on the OK button.

 

 

Connect the interface to the Universal Logical Switch ULS-Transit-Network-02

 

  1. Enter ULS-Transit-Network-02 for the name.
  2. Click Select to Select a Logical Switch.
  3. Click on the Radio Button to select ULS-Transit-Network-02.
  4. Click the OK box.

 

 

Configure the IP Address for the vNIC Interface

 

  1. Click the "+" to edit the vNIC interface IP address.
  2. Enter 192.168.5.14.
  3. Enter a prefix length of 29.
  4. Click the OK box.

 

 

Summary of vNIC Interface Change

 

This successfully added a new interface to the ESG Perimeter-Edge-01. Not that on the 192.168.5.8/29 network, the existing Perimeter-Edge-02 is 192.168.5.9/29 and the UDLR universal-logical router is 192.168.5.10-11/29.

 

 

Configure OSPF on the new vNIC Interface

 

  1. Click on the Routing Tab.
  2. Click on the OSPF Line Item.

 

 

Make room to see the Area to interface Mapping

 

Towards the bottom of the screen you have the Area to Interface Mapping.

  1. You may need to drag the "Recent Tasks" window lower to see the Area to Interface Mapping box.
  2. You may need to close the "Recent Tasks" window to see the Area to Interface Mapping box.

In the next step, I have closed the "Recent Tasks" window.

 

 

Apply OSPF to Interface Mapping

 

  1. Click "+" to Add an OSPF to Interface Map
  2. Select the Interface "ULS-Transit-Network-02".
  3. Select Area 0.
  4. Enter a Cost of 1.
  5. Click the OK Box.

OSPF Dynamic Routing has now been configured on the new interface.

 

 

Publish the Routing Changes

 

 

 

Return to the NSX Edge Menu

 

 

 

Add Interface on ESG Perimeter-Edge-02 to Local Logical Switch Transit-Network-01

 

 

Edit the ESG edge-5 Perimeter-Gateway-02

 

 

 

Configured an unused Interface

 

  1. Click on Manage.
  2. Click on Settings.
  3. Click on Interfaces.
  4. Highlight the unused vnic2 on the ESG.
  5. Click the "Pencil" to edit the vNIC settings.

 

 

Drag the Edit NSX Edge Interface Menu to the top of the screen

 

The ESG interface configuration screen needs the full screen to see the buttons at the bottom of the window. Dragging the Edit Interface window will allow you to drag the screen so that you can click on the OK button.

 

 

Connect the interface to the Universal Logical Switch Transit-Network-01

 

  1. Enter Transit-Network-01 for the name.
  2. Click on Select to pick a Logical Switch to connect.
  3. Click on the Radio Button to select Transit-Network-01.
  4. Click the OK box.

 

 

Configure the IP Address for the vNIC Interface

 

  1. Click the "+" to edit the vNIC interface IP address.
  2. Enter 192.168.5.6.
  3. Enter a prefix length of 29.
  4. Click the OK box.

 

 

Summary of vNIC Interface Change

 

This successfully added a new interface to the ESG Perimeter-Edge-02. Note that on the 192.168.5.0/29 network, the existing Perimeter-Edge-01 is 192.168.5.1/29 and the LDLR local-logical router is 192.168.5.2-3/29.

 

 

Configure OSPF on the new vNIC Interface

 

  1. Click on the Routing Tab.
  2. Click on the OSPF Line Item.

 

 

Make room to see the Area to interface Mapping

 

Towards the bottom of the screen you have the Area to Interface Mapping.

  1. You may need to drag the "Recent Tasks" window lower to see the Area to Interface Mapping box.
  2. You may need to close the "Recent Tasks" window to see the Area to Interface Mapping box.

In the next step, I have closed the "Recent Tasks" window.

 

 

Apply OSPF to Interface Mapping

 

  1. Click "+" to Add an OSPF to Interface Map
  2. Select the Interface "Transit-Network-01"
  3. Select Area 0.
  4. Enter a Cost of 1.
  5. Click the OK Box.

OSPF Dynamic Routing has now been configured on the new interface.

 

 

Publish the Routing Changes

 

 

 

Return to the NSX Edge Menu

 

 

 

Summary of Equal Cost Multi Pathing Changes

The Local Distributed Logical Router is connected to both Perimeter Edges via its Local Logical Switch Transit-Network-01 subnet 192.168.5.0/29.

The Universal Distributed Logical Router is connected to both Perimeter Edges via its Universal Logical Switch ULS-Transit-Network-02 subnet 192.168.5.8/29.

All routing between the Local DLR and Universal DLR is via the Perimeter Edges and not the core network.

 

 

Special Instructions for Commands and Configuration

 

The following exercises will require you enter commands and/or configuration. The text boxes within the lab manual such as the example below combined with the SEND TEXT function, allow you to copy and paste commands and configuration into the lab.

As an example only, the steps to use the SEND TEXT function are as follows:

  1. Click to place your curser where you need text pasted.
  2. Click on SEND TEXT function of the Hands On Lab.
  3. Copy the text (Ctrl-C/Command-C) from the text box below and paste (Ctrl-V/Command-V) into the SEND TEXT TO CONSOLE box.
  4. Press the SEND TEXT TO CONSOLE "SEND" button.
ls -l | grep test

 

 

Validate Topology and Routing Tables after Configuration Changes

In this step, we will use the NSX Manager CLI interface to validate the routing configuration on Edge Perimeter-Gateway-01 Perimeter-Gateway-02.

 

 

Start Putty to ssh to nsxmgr-01a

 

 

 

SSH to NSX Manager nsxmgr-01a

 

  1. Scroll until you find the entry for nsxmgr-01a.corp.local.
  2. Click on nsxmgr-01a.corp.local.
  3. Click on the Open Button.

 

 

Show Routing Table on Perimeter-Edge-1

 

 

 

Increase the Window Size

 

 

 

Display NSX Edge List

 

  1. At the command prompt, use the SEND TEXT or enter the command below:
show edge all

The active Edges in the NSX environment are displayed.

 

 

Show Routing Table on edge-3 Perimeter-Gateway-01

 

  1. At the command prompt, use the SEND TEXT or enter the command below:
show edge edge-3 ip route

The routing table from edge-3 Perimeter-Gateway-01 is displayed. Note the routes from the Local Distributed Logical Router (172.16.X.X) and the Universal Distributed Logical Router (172.17.X.X) are displayed showing connectivity from this Edge to both the Local and Universal Distributed Logical Routers.

 

 

Show Routing Table on edge-5 Perimeter-Gateway-02

 

  1. At the command prompt, use the SEND TEXT or enter the command below:
show edge edge-5 ip route

The routing table from edge-5 Perimeter-Gateway-02 is displayed. Note the routes from the Local Distributed Logical Router (172.16.X.X) and the Universal Distributed Logical Router (172.17.X.X) are displayed showing connectivity from this Edge to both Local and Universal Distributed Logical Routers.

 

 

Summary

 

With the changes to the Perimeter Gateways, we now have routing between the Local Distributed Logical Router and Universal Distributed Logical Router via the Perimeter Gateways using Equal Cost Multi Pathing without requiring traffic to traverse the core network.

Universal and Local Distributed Logical Routers are a powerful capability of NSX allowing for Layer 2 and Layer 3 network extensibility across multiple vCenter environments. Combined with other VMware technologies, such as vSphere Site Recovery Manager, multisite BC/DR solutions and VM mobility are easily accomplished with NSX for network virtualization.

 

Migration

Module 3 will review routing considerations between networks connected via a Local Distributed Logical Router and between networks connected via Universal Distributed Logical Router.

Currently the Lab is configured so that the two 3-Tier Web Applications need to traverse individual North/South Edge Services Gateways to access each other requiring all traffic to traverse the common VLAN connecting the North/South Perimeter Edge Services Gateways to the core network.

In this lab, we will perform the following activities:

  1. Validate both the 3-Tier Local Application and 3-Tier Universal Application are functioning.
  2. Configure Equal Cost Multi Pathing (ECMP) across the Local and Universal Distributed Logical Routers and the North/South Perimeter Edge Services Gateways Perimeter-Gateway-01 and Perimeter-Gateway-02.
  3. Connect Transit-Network-01 Logical Switch to Perimeter-Gateway-02 and ULS-Transit-02 Universal Logical Switch to Perimeter-Gateway-01 demonstrating network connectivity between the two applications is now via the two Perimeter Edge Servies Gateways.

Notes:

ESG = Edge Services Gateway Used as Perimeter Routers and Load Balancers in this lab module.

DLR = Distributed Logical Routers. Used as kernel based routers in this lab module. Two types of DLR - A Local DLR (LDLR) is used within a single vCenter environment, and a Universal DLR (UDLR) is shared across multiple vCenter environments. We will use both a Local and Universal DLR in this lab module.

 

Network Topology Review for the 3-Tier Local Web Application

 

The 3-Tier Local Web Application is configured across a single data center with local NSX network objects. Web access is via the OneArm-LoadBalancer-01 configured with Domain Name htps://webapp.corp.local resolving to IP address 17.16.10.10.

 

 

Network Topology Review for 3-Tier Universal Web Application

 

The network topology for the 3-Tier Universal Web Application is shown. A Universal Distributed Logical Router connected to Universal Logical Switches provide L2 adjacency to Virtual Machines across two data centers.

Ingress and Egress are via the single North/South Edge Services Gateway named Perimeter-Gateway-02 located in Data Center Site A Management & Edge Cluster.

Web access is via the OneArm-LoadBalancer-02 configured with Domain Name htps://webapp-universal.corp.local resolving to IP address 17.17.10.10.

 

 

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.

 

 

Validate the Local Web Application

In this exercise, we will validate the Local Web Application is functioning and correctly load balancing between the two web server VM's. If the application does not function, this indicates the previous Exercises miss-configured the lab or the lab did not start correctly. This application is configured to work from initial lab deployment.

 

 

Open Web Browser

 

 

 

Open the 3-Tier WebApp Local Link

 

 

 

Validate the 3-Tier Local Application and specific Web Server

 

  1. A new page should open called "Hands on Lab - Multi Tier Application"
  2. Load Balancing will select either web server web-01a or web-02a

The IP subnet if 172.16.10.X represents the Web-Tier-02 Logical Switch connected to the Universal-Distributed-Router with a gateway address of 172.16.10.1. Edge Services Gateway Load Balancer is on 172.16.10.10 and is configured to load balance between VM's web-01a and web-02a.

 

 

Validate Universal Web Application

The Universal Web Application is a 3-Tier application connected to Universal Logical Switches and a Universal Logical Router with VM's split between two data centers.

In this exercise, we will validate the Universal Web Application is functioning and correctly load balancing between two web servers.

If the application does not function, this indicates a failure for the Lab to deploy, the previous Exercises were not performed correctly, or the PowerShell Fast Forward script did not complete correctly.

 

 

Open the 3-Tier WebApp Universal Link

 

 

 

Validate the 3-Tier Universal Application and specific Web Server

 

  1. A new page should open called "Hands on Lab - Multi Tier Application"
  2. Load Balancing will select either web server web-03a or web-01b

If your attempt to bring up the web page fails shortly after the Fast Forward PowerShell script has completed, Universal Distributed Logical Router and associated Edge appliance deployment may not have completed populating the routing table. Wait a minute and try again.

The IP subnet if 172.17.10.X represents the ULS-Web-Tier-02 Logical Switch connected to the Universal-Distributed-Router with a gateway address of 172.17.10.1. Edge Services Gateway Load Balancer is on 172.17.10.10 and is configured to load balance between VM's web-03a and web-01b.

 

 

Reload the Browser Window

 

 

 

Validate 3-Tier Universal Application uses new Web Server

 

This demonistrates the application and universal network objects are correctly configured and functioning together with an NSX Edge Services Gateway configured to provide load balancing for the application web tier.

 

 

Create a new Universal Distributed Logical Switch ULS-Web-Tier-01

A new Universal Logical Switch is required to support the migration of VMs from a Local Logical Switch

 

 

Open a new Browser Tab

 

 

 

Open the Site A Web Client

 

 

 

Login to vCenter vcsa-01a.corp.local

 

  1. Enter User name: CORP\Administrator
  2. Enter Password: VMware1!
  3. Click on the "Login" button.

Optionally, click on the Use Windows session authentication box then click Login. You will be logged on to the Site A vSphere Web Client using the credentials of the Control Center Windows machine. (Corp\Administrator).

 

 

Navigate to NSX Networking & Security Menu

 

 

 

Create a new Switch

 

  1. Click on Logical Switches.
  2. Set the NSX manager to Primary.
  3. Click "+" on the Switch List screen to create a new Logical Switch.

 

 

Enter Switch Name and Select the Universal Transport Zone

 

  1. Enter the name: ULS-App-Tier-01
  2. Click Change
  3. Select Universal-Transport-Zone.
  4. Click OK.
  5. Click the OK button.

A new Universal Logical Switch will be created.

 

 

Move VM app-01a to Universal Logical Switch ULS-App-Tier-01

 

  1. Right hand Mouse Click ULS-App-Tier-01 to bring up the Actions menu.
  2. Click Add VM.

 

 

Select app-01a VM

 

  1. Click on the app-01a VM.
  2. Click on the Arrow to select the VM
  3. VM should now be listed.
  4. Click on the Next box.

 

 

Select the VM vNIC

 

  1. Click on the Tick box to select the VM vNIC.
  2. Click on the Next box.

 

 

Complete the VM to Switch Patching

 

The app-01a VM is now disconnected from App-Tier-01Logical Switch and connected to the new ULS-App-Tier-01Universal Logical Switch.

 

 

Remove Interface from LDR edge-2 Local-Distributed-Router

We will now remove the existing Gateway address for the App-Tier network from the Local DLR.

 

 

Edit the LDR Router edge-2 Local-Distributed-Router

 

  1. Click on NSX Edges.
  2. Double Click on edge-2 Local-Distributed-Router. This will take you to the menu screen for this LDR.

 

 

Select Setting Tab and Interface Configuration

 

  1. Click on Manage.
  2. Click on the Settings button.
  3. Click on the Interfaces Tab.
  4. Highlight the App-Internal 172.16.20.1 interface.
  5. Click on the "x" button to delete this interface.

 

 

Confirm the Interface Delete

 

 

 

Return to the NSX Edge Menu

 

 

 

Edit the Universal DLR edge-xxx... Universal-Distributed-Router

 

Note that the id of the edge may not match the screen image due to a unique UUID is created when the edge is created.

 

 

Select Setting Tab and Interface Configuration

 

  1. Click the Settings button.
  2. Click the Interfaces Tab.
  3. Click the "+" button to add a new interface.

 

 

Enter Interface Configuration Details

 

  1. Enter the name ULS-App-Tier-01 to match the Logical Switch name.
  2. Click on the Interface Type Internal button.
  3. Click "Change"
  4. Select ULS-App-Tier-01 Universal Logical Switch.
  5. Click the Green Plus sign.
  6. Enter the IP Address: 172.16.20.1
  7. Enter a Prefix Length: 24
  8. Click the OK button.

This will create a new interface in the Universal Distributed Logical Router connected to the Universal Logical Switch.

 

 

Return to the NSX Edge Menu

 

 

 

Validate the Local Web Application

In this exercise, we will validate the Local Web Application is functioning and correctly load balancing between the two web server VM's. If the application does not function, this indicates the previous Exercises miss-configured the lab or the lab did not start correctly. This application is configured to work from initial lab deployment.

 

 

Open the 3-Tier WebApp Local Link

 

  1. Open a blank browser tab.
  2. From the saved links bar, Click on the Link to the 3-Tier WebApp Local Application. If successful, the browser window will open to the application.

 

 

Validate the 3-Tier Local Application and specific Web Server

 

  1. A new page should open called "Hands on Lab - Multi Tier Application"
  2. Load Balancing will select either web server web-01a or web-02a

The IP subnet if 172.16.10.X represents the Web-Tier-02 Logical Switch connected to the Universal-Distributed-Router with a gateway address of 172.16.10.1. Edge Services Gateway Load Balancer is on 172.16.10.10 and is configured to load balance between VM's web-01a and web-02a.

 

 

Summary

 

Local Logical Switches are connected to Local Distributed Logical Routers and Universal Logical Switches are connected to Universal Distributed Logical Routers.

The migration of VM's between Local and Universal Logical Switches is no more than a step by step process via the vSphere Web UI or via NSX REST API.

 

Module 4 - NSX L2 Bridging

Native Bridging Enhancements

NSX provides in-kernel software L2 Bridging capabilities , that allow organizations to seamlessly connect traditional workloads and legacy VLANs to virtualized networks. L2 Bridging is widely used in brownfield environments, to simplify the introduction of logical networks, as well as other scenarios that involve physical systems that require L2 connectivity to virtual machines.

This module will guide you through the configuration of a L2 Bridging instance between a traditional VLAN and a NSX Logical Switch.

In NSX-V 6.2 this function has been enhanced, by allowing bridged Logical Switches to be connected to Distributed Logical Routers. This operation was not permitted in previous versions of NSX.

 

Introduction

 

The picture above shows the L2 Bridging enhancements provided in NSX 6.2:

You will now configure NSX L2 Bridging with NSX 6.2 in the newly supported configuration.

 

 

Access vSphere Web Client

You will now access the vSphere Web Client with a browser (either Mozilla Firefox or Google Chrome) from the ControlCenter, in order to do the necessary configurations for this module.

 

 

Open the Browser

 

 

 

Access the vSphere Web Client

 

 

 

Logon to the Web Client

 

  1. Click on the box "Use Windows session authentization", to login as "CORP\Administrator".
  2. Click Login and wait for the client to be loaded.

 

 

Minimize the lateral windows

 

 

 

Verify Initial Configuration

 

You can now verify the initial configuration. The environment comes with a Port Group on the Management & Edge cluster, named "vds-mgt_Bridge Network", configured on VLAN ID 101. A web server VM, named "web-04a", is attached to this Port Group which, at the moment, is isolated from the network. The picture shows the topology.

 

 

Access the vSphere Networking Configuration

 

  1. Click on the Home icon.
  2. Click on "Networking" to access the vSphere Networking configuration interface.

 

 

Open Port Group

 

  1. Expand the object tree ("vcsa-01a.corp.local", "Datacenter Site A", "vds-mgt-edge")
  2. Click on the "vds-mgt_Bridge Network" Port Group in the list.

 

 

Verify VLAN ID

 

Verify that the Port Group is configured on physical VLAN ID 101.

 

 

Verify Connected VMs

 

  1. Click on the "Related Objects" tab and verify that "web-04a" is Powered On and connected to the "vds-mgt_Bridged Network" Port Group.
  2. Click on the VM "web-04a" to be redirected to the Virtual Machine's"Getting Started" page.

 

 

Open VM Console

 

  1. Click on the "Summary" tab and verify that the VM has a 172.16.10.14 IP address.
  2. Click on the Console image to connect to the VM console.

 

 

Verify that VM is isolated

 

Once the console window is open, click in the middle of the screen and type any key to make the screen blanker go away.

  1. Login as "root", with password "VMware1!" (no brackets in username or password)
  2. Enter ping -c 3 172.16.10.1     (Remember to use SEND TEXT tool)
ping -c 3 172.16.10.1

Wait until the ping times out: you have verified that the VM is isolated, as there are no other devices on VLAN 101 and the L2 Bridging is not configured yet.

 

 

Configure NSX L2 Bridging

 

You will now enable NSX L2 Bridging between VLAN 101 and the Web-Tier-01 Logical Switch, so that VM "web-04a" will be able to communicate with the rest of the network. With NSX-V 6.2 is now 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, as well as the migration from legacy to virtual networking.

 

 

Return to the Web Client

 

Do not close the "web-04a" console tab as you will need it later.

 

 

Access the NSX configuration page

 

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

 

 

Open Logical Router configuration page

 

NSX Bridging is implemented in the hypervisor and is configured in the Logical Router configuration page. You will configure L2 Bridging on the Logical Router that is already deployed in the environment ("Local-Distributed-Router").

  1. From the Navigator menu on the left, click on "NSX Edges" and wait until the list of NSX Edges is loaded.
  2. Double-click on "edge-2" , named "Local-Distributed-Router" to access its configuration page.

 

 

Create a new L2 Bridge

 

  1. Click on the "Manage" tab.
  2. Then click on the "Bridging" tab.
  3. Verify that there are no configured bridging instances in the list, then click on the green plus icon to add one.

 

 

Enter Bridge Name

 

  1. Enter "Bridge-01" in the "Name" input field.
  2. Then click on the icon to select a Logical Switch to enable bridging on.

 

 

Select Logical Switch

 

  1. Select the "Web-Tier-01" Logical Switch.
  2. Click OK.

 

 

Open Distributed Port Group selection dialog

 

 

 

Select Distributed Port Group

 

  1. Select the "vds-mgt_Bridged Network" Distributed Port Group.
  2. Click OK.

 

 

Confirm Bridge configuration

 

 

 

Publish Changes

 

 

 

Verify that routing is enabled

 

Verify the published configuration. You will notice the "Routing Enabled" message: it means that this L2 Bridge is also connected to a Distributed Logical Router, which is an enhancement in NSX-V 6.2.

 

 

Verify L2 Bridging

NSX L2 Bridging has been configured. You will now verify L2 connectivity between the "web-04a" VM, attached on VLAN 101, and the  machines connected "Web-Tier-01" Logical Switch. You will also reconfigure the NSX Load Balancer to add "web-04a" to the pool.

 

 

Verify Default Gateway Connectivity

 

  1. Open the "web-04a" console tab on the browser, and try to ping the default gateway again:
  2. Enter ping -c 3 172.16.10.1
ping -c 3 172.16.10.1

The ping is now successful: you have verified connectivity between a VM attached on VLAN 101 and the Distributed Logical Router that is the default gateway of the network, through a L2 Bridge provided by NSX!

Note: you might experience "duplicate" pings during this test (responses appearing as DUPs): this is due to the nature of the Hands-On Labs environment and is not going to happen in a real scenario.

 

 

Return to the Web Client

 

 

 

Return to the NSX Edges list

 

You will now add "web-04a" to the existing NSX Load Balancer pool.

 

 

Open Edge Services Gateway configuration page

 

 

 

Edit Load Balancer Pool

 

  1. Click to the "Load Balancer" tab to access the LB configuration page.
  2. From the left menu, click on "Pools".
  3. Click on the pencil icon to edit the web server pool "pool-1" (Web-Tier-Pool-01).

 

 

Add a new Pool member

 

You'll notice that there are currently 2 web servers in the pool: web-01a (172.16.10.11) and web-02a (172.16.10.12).

 

 

Enter New Member information

 

In the dialog box, type the new member information as follows:

  1. Name: web-04a
  2. IP Address / VC Container: 172.16.10.14
  3. Port: 443
  4. Then click OK to confirm.

 

 

Confirm Pool configuration

 

  1. Verify that the "web-04a" is added in the members list and click OK.

 

 

Verify Pool Statistics

 

  1. Click on "Show Pool Statistics" to load the Pool and Member Status window.  Once the window is loaded, verify that the Pool status is UP.
  2. Then click on "pool-1" to load the Member Status information.
  3. Verify that "web-04a" is UP. This means that the NSX Load Balancer was able to connect via HTTPS to web-04a through the L4 Bridge.
  4. Close the Status window.

 

 

Verify 3-Tier Application

 

  1. Open a new browser tab.
  2. Click on the "3-Tier WebApp Local" web application via the Bookmark.
  3. Verify that the application is responding.

 

 

Refresh the page

 

  1. Press and hold Shift+Refresh the web page a few times, until the request gets forwarded by the Load Balancer to "web-04a" (172.16.10.14).

You have now verified that "web-04a" is accessible through the Load Balancer, and is also able to communicate to the application server ("app-01a", 172.16.20.11) on another subnet via the NSX Distributed Logical Router (otherwise the application wouldn't work).

 

 

Configure Microsegmentation

 

Now that network configuration is verified, you can configure the Distributed Firewall (DFW) to enable Microsegmentation on the web tier network for the bridged VM as well.

At the moment, VLAN 101 is bridged with "Web-Tier-01" Logical Switch, so that the VMs "web-04a" (172.16.10.14) , "web-01a" (172.16.10.11) and "web-02a" (172.16.10.12) share the same L2 segment.

NSX Distributed Firewall filters traffic on the Virtual Machine Network Interface Card (vNIC), thus applies on VMs attached both on Logical Switches and Distributed Port Groups.

The current DFW configuration has a "block" rule that inhibits communications between web-01a and web-02a. You will add web-04a to a Security Group and verify that Microsegmentation can be achieved on VMs connected through L2 Bridging as well.

 

 

Verify Existing Policy

 

Initially, there is no policy that restricts "web-04a" communication.

  1. Open the "web-04a" console tab in the browser and verify that it can reach "web-01a" by using the ping command:
  2. ping -c 3 web-01a
ping -c 3 web-01a

The ping is successful, meaning that the Distributed Firewall allows the communication.

Note: you might experience "duplicate" pings during this test (responses appearing as DUPs): this is due to the nature of the Hands-On Labs environment and is not going to happen in a real scenario.

 

 

Return to the Web Client

 

 

 

Access the NSX configuration page

 

  1. Click on the Home icon
  2. Click "Networking & Security" from the menu.

 

 

Verify Distributed Firewall Configuration

 

  1. Click on "Firewall".
  2. Expand the "Local Web Application" firewall section, and examine the rules.

You will notice there is a "Web Tier Micro-segmentation" rule that blocks intra-group traffic within the "Local_Web_Tier" Security Group.

 

 

Verify Security Group

 

As previously observed, this rule does not prevent "web-04a"  to ping "web-01a" as the former VM is not in the "Local_Web_Tier" Security Group.

 

 

Edit Security Group

 

  1. Click on "Service Composer". The page will open on the "Security Groups" tab.
  2. Expand the "Name" column to clearly see the Security Group names
  3. Right-click on the "Local_Web_Tier" Security Group.
  4. Choose "Edit Security Group" from the menu.

 

 

Add web-04a Virtual Machine

 

  1. Click on Select objects to include.
  2. Choose Virtual Machine from the Object Type pulldown.
  3. Click on web-04a.
  4. Click on the Right Arrow to move web-04a to Selected Objects pane.
  5. Click Finish.

 

 

Verify Security Group

 

Verify that "web-04a" is now part of the Security Group and close the popup window

 

 

Run ping test

 

Now verify that the Micro-segmentation rule is enforced on "web-04a" as well.

  1. Open the "web-04a" console tab in the browser and confirm that connections to "web-01a" are now blocked by using the ping command again:
  2. ping -c 3 web-01a
ping -c 3 web-01a

The ping is not successful, meaning that the Distributed Firewall is correctly blocking the communication. Microsegmentation is enabled on all web VMs, either connected to a Distributed Port Group on a VLAN, or to a Logical Switch, even when L2 Bridging is enabled between the two.

 

 

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.

 

 

Return to the Web Client

 

 

 

Access the NSX configuration page

 

  1. Click on the Home icon.
  2. Click "Networking & Security" from the menu.

 

 

Open Logical Router configuration page

 

  1. From the Navigator menu on the left, click on "NSX Edges" and wait until the list of NSX Edges is loaded.
  2. Double-click on "edge-2" , named "Local-Distributed-Router" to access its configuration page.

 

 

Delete Bridge Instance

 

  1. Click on the "Manage" tab, if not already selected.
  2. Then click on the "Bridging" tab, if not already selected.

You will see only the "Bridge-01" instance that you created before, which is highlighted by default.

 

 

Publish Changes

 

 

 

Verify Bridge Cleanup

 

Verify that the Bridge instance has been deleted.

Congratulations, you have successfully completed the NSX L2 Bridging module!

 

Module 5 - NSX L2VPN

Configuring NSX L2VPN

 

Introduction

 

In this module you will be utilizing the L2VPN capabilities of the NSX Edge Gateway to extend a L2 boundary between two separate vSphere sites. To demonstrate a use case based on this capability, you will be placing a VM located on Site B of your lab environment within the pool of load balanced servers that are balanced by the Edge Gateway "OneArm-LoadBalancer-01." The topology diagram above gives a simplified picture of the environment you will end up with at the end of this section.

Move to the next step to continue and validate whether your lab environment is ready.

 

 

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.

 

 

Getting Access to the vSphere Web Client

 

 

Opening Google Chrome and Navigating to the vSphere Web Client

 

 

 

Usability Tip - Decreasing Web Browser Zoom to 90%

 

Given the amount of data being shown within the vSphere Web Client, one might find it advantageous to slightly lower the zoom of the Google Chrome Browser in the Control Center to increase the viewing area within the vSphere Web Client.  To decrease the Zoom:

  1. Click on the Preferences button in Google Chrome.
  2. Click on the minus sign "-" once to lower the zoom to 90%.

 

 

Set Windows Session Authentication and Login

 

  1. Click on "Use Windows session authentication"
  2. Click on the "Login" button.

You will be logged on to the Site A vSphere Web Client using the credentials of the Control Center Windows machine. (Corp\Administrator).

 

 

Navigating to the Networking & Security Section of the vSphere Web Client

 

 

 

Creating the NSX Edge Gateway for the L2VPN-Server

 

To create the L2VPN Server service, you must first deploy an NSX Edge Gateway for that service to run on.  

  1. Click on NSX Edges.
  2. Click on the Green Plus sign to create a new Edge.

 

 

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-Serverfor theName.
  2. Click Next.

 

 

Configure Settings for New NSX Edge Gateway : L2VPN-Server

 

In the Settings section of the New NSX Edge Wizard, perform the following actions:

  1. Enter "VMware1!VMware1!" for the Password and Confirm Password fields, and leave all other options at their defaults.
  2. Click the Next button to continue.

 

 

Adding the New NSX Edge Appliance : L2VPN-Server

 

In the "Add NSX Edge Appliance" modal popup window that appears, enter in the following values:

  1. Click the Green Plus sign to create NSX Edge Appliance.
  2. Set Cluster/Resource Pool:  Management & Edge Cluster.
  3. Set Datastore: ds-site-a-nfs01.
  4. Set Host: esxmgt-01a.corp.local.
  5. Set Folder: NSX Edges.
  6. Click the OK button to submit this configuration.

 

 

Back to Configure Deployment for new NSX Edge Gateway : L2VPN-Server

 

 

 

Add Interface

 

 

 

Adding a new Interface to the NSX Edge Gateway : L2VPN-Server

 

  1. Enter "L2VPNServer-Uplink" for the Name field.
  2. Select "Uplink" for the type.
  3. Click the green plus sign (+) icon to list the fields for a new Primary IP Address.
  4. Enter "192.168.5.5" for the IP address.
  5. Enter "29" for the Subnet Prefix Length.
  6. Click the link labelled "Select" next to the text box named "Connected To".

 

 

Connecting the new Interface to a Logical Switch

 

Ensure that the Logical Switch tab is selected, and perform the following actions:

  1. Click the radio button for the logical switch named "Transit-Network-01 - 5000".
  2. Click the OK button to continue.

 

 

Confirming new Interface Configuration : L2VPN-Server

 

Before continuing, review the following settings:

 

 

Continuing the new NSX Edge Gateway Configuration : L2VPN-Server

 

 

 

Configuring Default Gateway Settings for new NSX Edge : L2VPN-Server

 

  1. Enter 192.168.5.1 for the Gateway IP.
  2. Click Next.

 

 

Configuring Firewall and HA Settings for new NSX Edge Gateway : L2VPN-Server

 

For the Firewall and HA section, configure the following properties:

  1. Click the checkbox for "Configure Firewall default policy."
  2. Set the Default Traffic Policy setting to "Accept."
  3. Click the Next button to continue.

 

 

Review new NSX Edge Gateway Deployment and Complete : L2VPN-Server

 

 

 

Preparing L2VPN-Server NSX Edge for L2VPN Connections

Before you configure the newly deployed NSX Edge for L2VPN connections, a number of preparatory steps will need to be taken first, including:

1.) Removing the Logical Interface (LIF) from the DLR "Local-Distributed-Router" that represents the IP address of 172.16.10.1.

2.) Adding a Trunk Interface to the L2VPN-Server Edge Gateway.

3.) Adding a Sub Interface to the L2VPN-Server Edge Gateway.

4.) Configuring dynamic routing (OSPF) on the L2VPN-Server Edge Gateway.

The next set of steps will have you walking through these four actions.  Continue to the next step to begin with removing the LIF from the existing "Local-Distributed-Router"

 

 

Navigating to the Management Area of the  Local-Distributed-Router

 

Navigate to the list of NSX Edges again - and make sure the dropdown list next to NSX Manager at the top is set to "192.168.110.15 (Role: Primary)".

 

 

Removing the Logical Interface from the Local-Distributed-Router

 

To remove the LIF representing the IP address of "172.16.10.1," perform the following actions:

  1. Click on Manage.
  2. Click on Settings.
  3. Click on Interfaces.
  4. Select the vNIC with the ID of 10, and IP address of "172.16.10.1."
  5. Click on the red X icon.
  6. Click OK to confirm the deletion to remove the LIF.

Now that the LIF is removed, you will be configuring a Trunk Interface on the L2VPN-Server Edge Gateway, and a Sub Interface on that Trunk interface to take the place of the LIF you just removed.

 

 

Getting Back to the list of NSX Edges

 

 

 

Configuring the L2VPN-Server NSX Edge

 

 

 

Adding the Trunk Interface

 

  1. Click on the "Manage" tab.
  2. Click on "Settings" tab.
  3. Click on  "Interfaces" item.
  4. Select the vNIC with the number "1" and name of "vnic1" as shown in the screenshot.
  5. Click on the pencil icon to bring up the "Edit NSX Edge Interface" wizard.

 

 

Configuring the Trunk Interface

 

In the Edit NSX Edge Interface window that comes up, enter the following values:

  1. Enter "L2VPN-Server-Trunk" for the name.
  2. Set Type:Trunk
  3. Click on the "Select" link next to the text box for "Connected To".

 

 

Selecting the Trunk Port Group

 

In the "Connect NSX Edge to a Network" popup, perform the following actions:

  1. Click on Distributed Portgroup.
  2. Click on the radio button for "vds-mgt_Trunk Network."
  3. Click on the OK button.

 

 

Adding a Sub Interface to the Trunk Interface

 

 

 

Configuring the Sub Interface

 

In the "Add Sub Interface" popup, enter in the following values.

  1. Name: L2VPN-Server-SubInterface
  2. Tunnel Id: 1
  3. Backing Type: Network
  4. Click the green plus sign (+) icon.
  5. Enter in "172.16.10.1" in the Primary IP Address field
  6. Enter "24" for the Subnet Prefix Length.
  7. Click the link for "Select" next to the Connected To.

 

 

Attaching the Sub Interface to a Logical Switch

 

  1. Ensure that the "Logical Switch" tab is selected.
  2. Click on the radio button for "Web-Tier-01 - 5001".
  3. Click on the OK button.

 

 

Confirming the Sub Interface Configuration

 

 

 

Confirming the new NSX Edge Interface Configuration

 

 

 

Setting the Router ID for this NSX Edge

 

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

  1. Click on the "Routing" sub-tab of this Edge Gateway,
  2. Click on "Global Configuration" in the left-hand nav bar.
  3. Click the "Edit" button in the "Dynamic Routing Configuration" section.  This will bring up a popup window where you can configure what the Router ID will be.

 

 

Add L2VPNServer-Uplink

 

  1. Click OK.

 

 

Publish Changes to set Router ID

 

 

 

Configuring OSPF on the L2VPN-Server NSX Edge

 

Stay within the Routing sub-tab, and

  1. Click on the item "OSPF" in the left-hand nav bar.  
  2. Click on the green plus sign (+) icon under the section for "Area to Interface Mapping."

 

 

Configuring Area to Interface Mapping

 

In the popup for "New Area to Interface Mapping," configure the following values:

  1. vNIC: L2VPNServer-Uplink
  2. Area: 0  
  3. Click the OK button.

 

 

Enabling OSPF on the L2VPN-Server NSX Edge

 

  1. To enable the OSPF configuration on this Edge Gateway, click the Edit button in the "OSPF Configuration" section.
  2. Check the checkbox for "Enable OSPF".
  3. Click "OK" button.

 

 

Publish Changes for the L2VPN-Server NSX Edge

 

 

 

Enable OSPF Route Redistribution

 

  1. Click on "Route Redistribution".
  2. Click the "Edit" button for the Route Redistribution status.
  3. Check box for OSPF to enable OSPF.
  4. Click the OK button.

 

 

Add Route Redistribution Table Entry

 

 

 

Configure Route Redistribution Table Entry

 

In the "New Redistribution criteria" popup, configure the following values:

  1. Click the checkbox for "Connected" and leave all other checkboxes unchecked.
  2. Click the OK button.

 

 

Publish Changes

 

Once complete, all pre-requisites have been performed to continue on with configuring the L2VPN service on this Edge Gateway.

 

 

Configuring L2VPN Service on L2VPN-Server NSX Edge

Now that the 172.16.10.1 address belongs to the L2VPN-Server Edge Gateway, and it is now distributing its routes dynamically via OSPF, you will begin to 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 on the VPN tab.
  2. Click on the L2 VPN selection in the left-hand navigational bar.
  3. Click on the "Change" button as shown in the screenshot.

 

 

Configuring the L2VPN Server Settings

 

In the L2 VPN server settings, configure the following values:

  1. Set the Encryption Algorithm: AES256-SHA
  2. Click the OK button to continue.

 

 

Add a new Site Configuration

 

 

 

Configuring a new L2VPN Site

 

  1. Check the checkbox for Enable Peer Site.
  2. Enter "HOLSite1" in the name field.
  3. User ID:  siteadmin
  4. Password: VMware1!  
  5. Click on the link for "Select Sub Interfaces"

 

 

Selecting a Sub Interface

 

In the "Select Object" popup, perform the following actions:

  1. Select the "L2VPN-Server-SubInterface" object.
  2. Click the right-facing arrow to move it to the "Selected Objects" list.
  3. Click the OK button.

 

 

Confirming New Site Configuration

 

 

 

Publish Changes for L2VPN Configuration

 

  1. Before clicking the Publish Changes button, ensure that the L2VPN Mode is set to "Server."
  2. Click the Publish Changes button to submit the L2 VPN server configuration.

 

 

Enable L2VPN Server Service

 

  1. Lastly, to enable the L2 VPN server service, click the "Enable" button as shown in the screenshot.  
  2. Click Publish Changes.

That conludes the configuration for the L2 VPN.  Next, you will be deploying another new NSX Edge Gateway on the vSphere installation on Site B, which will act as the L2 VPN client.

 

 

Deploying the L2VPN-Client NSX Edge Gateway on Site B

Now that the server side of the L2VPN is configured, you will move on to deploying another NSX Edge Gateway to act as the L2 VPN client.

 

 

Return to Networking & Security menu

 

 

 

Creating the new NSX Edge Gateway to be the L2VPN-Client

 

  1. Set NSX Manager focus to 192.168.210.15 (Role: Secondary).
  2. Click the green plus sign (+) icon to open the New NSX Edge wizard.

 

 

L2VPN-Client NSX Edge Name and Description

 

For the options here, select the following values:

  1. Install Type: Edge Services Gateway
  2. Hame: L2VPN-Client
  3. Ensure that "Deploy NSX Edge" is checked, and click the Next button to continue.

 

 

Configuring NSX Edge Settings

 

For the Settings section, configure the following values:

  1. User Name: admin
  2. Password and confirm password: VMware1!VMware1!
  3. Click the Next button to continue.

 

 

Configure Placement of NSX Edge

 

In the "Add NSX Edge Appliance" popup, configure the following values:

  1. Click the Green Plus sign to create NSX Edge Appliance.
  2. Cluster/Resource Pool: Compute Cluster B.
  3. Datastore: ds-site-b-nfs01.
  4. Host: esx-01b.corp.local.
  5. Folder: NSX Edges.
  6. Click the OK button to submit this Edge VM placement config.

 

 

Confirm NSX Edge Deployment

 

 

 

Configure Interfaces for the L2VPN-Client NSX Edge

 

 

 

Add new Interface

 

For the parameters on this interface, enter in the following values:

  1. Name: L2VPN-Client-Uplink
  2. Type: Uplink
  3. Click the Green Plus sign (+) icon to add a new IP address.
  4. Enter "192.168.200.5" for the Primary IP Address.
  5. Enter "24" for the Subnet Prefix Length.
  6. Click on the "Select" link next to the "Connected To" text box to bring up the list of networks to choose where this interface will be attached to.

 

 

Connect Interface to Site B Uplink Distributed Port Group

 

In the "Connect NSX Edge to a Network" popup, perform the following actions:

  1. Click on the "Distributed Portgroup" tab.
  2. Click on the radio button for "vds-site-b_Uplink Network."
  3. Click the OK button to continue.

 

 

Confirm Interface Configuration

 

 

 

Click Next

 

 

 

Configure Default Gateway

 

In the Default Gateway Settings section, configure the following values:

  1. Gateway IP: 192.168.200.1
  2. Click the Next button to continue.

 

 

Firewall and HA Settings

 

In the "Firewall and HA" section, perform the following actions:

  1. Check the checkbox for "Configure Firewall default policy."
  2. Click the radio button for "Accept" for "Default Traffic Policy."
  3. Click the Next button to continue.

 

 

Confirm New NSX Edge Configuration

 

 

 

Configuring the L2VPN-Client NSX Edge Gateway on Site B

 

 

 

Adding the Trunk Interface

 

Just like with the L2VPN-Server Edge Gateway, there is also a need to add a Trunk interface to this Edge. To bring up the configuration window for the new interface, perform the following actions:

  1. Click on the Manage tab.
  2. Click on the Settings sub-tab.
  3. Click on the Interfaces selection on the left-hand nav bar.
  4. Select the interface labelled "vnic1" under the Name column.
  5. Click on the pencil icon to bring up the configuration area for this interface.

 

 

Configuring the Trunk Interface

 

In the Edit NSX Edge Interface popup, enter the following values:

  1. Name: L2PVN-Client-Trunk
  2. Type: Trunk
  3. Click the "Select" link next to "Connected To" to bring up the list of available vSphere networks to attach this interface to.

 

 

Connecting to the Trunk Network Distributed Port Group

 

  1. Click the "Distributed Portgroup" tab.
  2. Select the radio button for "vds-site-b_Trunk Network".
  3. Click the OK button.

 

 

Configuring Sub Interface

 

Configure the Sub Interface with the following values:

  1. Click the Green Plus sign to add Sub Interface.
  2. Name: L2VPN-Client-SubInterface.
  3. Tunnel ID: 1
  4. Backing Type: Network
  5. Click the green plus sign (+) icon.
  6. Enter "172.16.10.1" for the Primary IP Address.
  7. Enter "24" for the Subnet Prefix Length.
  8. Click "Select" next to the Network text box to bring up the list of networks available to attach this Sub Interface to.

 

 

Connect Sub Interface to Site B VM Network

 

  1. Select the "Distributed Portgroup" tab.
  2. Check the radio button for "vds-site-b_VM Network."
  3. Click the OK button.

 

 

Confirm Sub Interface Configuration

 

 

 

Confirm Addition of Trunk & Sub Interface

 

 

 

Configure L2VPN Client Services

 

To begin configuring the L2VPN client, perform the following actions:

  1. Click on the VPN sub-tab.
  2. Click on the L2 VPN selection in the left-hand navigational bar.
  3. Click on the radio button for "Client" in the "L2VPN Mode" area.
  4. Click on the "Change" button in the Global Configuration Details area.

 

 

L2VPN Client Settings

 

For the client settings, enter in the following values:

  1. Server Address: 192.168.5.5
  2. Encryption algorithm: AES256-SHA
  3. For user details, enter in "siteadmin" for the User ID,
  4. Enter "VMware1!" for the Password and Confirm Password fields.
  5. Click on the Select Sub Interfaces link to bring up the available list of Sub Interfaces to attach to the service.

 

 

Add Sub Interface

 

To add a new Sub Interface to the L2 VPN service, perform the following actions:

  1. Select the "L2VPN-Client-SubInterface" object from the list of available objects on the left.
  2. Click the right-facing arrow to move the object to the "Selected Objects" list.
  3. Click the OK button.

 

 

Confirm L2VPN Client Settings

 

 

 

Enable L2VPN Client Service

 

To enable the L2VPN Client service, click the Enable button here as shown in the screenshot.

 

 

Publish Changes

 

 

 

Fetch Status of L2VPN

 

  1. Once enabled, click on the button labelled "Fetch Status." You may need to click on this a couple of times after the service is enabled.
  2. You should eventually see the status turn to "Up" as seen in the screenshot above.

Now that the L2VPN is currently up, it's time to add the web-02b VM to the Load Balancer pool on the OneArm-LoadBalancer-01 Edge Gateway on Site A.

 

 

Verify Tunnel

 

  1. In the upper right of the web client enter web-02b in the search field and press enter.
  2. Click on web-02b.

 

 

Open console

 

 

 

Ping other members of Load Balancer Pool

 

ping -c 3 172.16.10.10
ping -c 3 172.16.10.11
ping -c 3 172.16.10.1

Once you're done, go back to the list of NSX Edges within the Networking & Security section of the vSphere Web Client.

 

 

Adding a Site B VM to the Load Balancer Pool on Site A

 

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

 

 

Go back to the view of NSX Edges on Site A

 

  1. Click on NSX Edges.
  2. Set the NSX Manager view to 192.168.110.15 (Role: Primary).
  3. Double-click on the "edge-4" OneArm-LoadBalancer-01 NSX Edge Gateway.

 

 

Enter the Configuration Area for NSX Edge "OneArm-LoadBalancer-01"

 

  1. Click on the Manage tab.
  2. Click on the Load Balancer sub-tab
  3. Click on "Pools" in the left-hand navigational bar.  
  4. Click on the Pool ID "pool-1".
  5. Click the pencil icon to bring up the "Edit Pool" window.

 

 

Edit the Load Balancing Pool

 

In the Edit Pool window, you are going to simply add one more member for the load balancing pool - web-02b which is located at the IP address of 172.16.10.13.

 

 

Enter Details for New Pool Member

 

Enter in the following values for the "New Member' window:

  1. Name: web_02b
  2. P Address / VC Container: 172.16.10.13 (Do not click the select link, just type the IP Address).
  3. Port: 443
  4. Monitor Port: 443
  5. Click the OK button.

 

 

Finish Pool Member

 

 

 

3-Tier WebApp Local

 

  1. Open a new browser tab.
  2. Click the bookmark entry for "3-Tier WebApp Local" in the bookmarks bar.

 

 

Refresh until you observe the page being served from web-02b

 

You may need to click the refresh button a couple of times, but you should eventually see that the page is also being served by the VM web-02b on IP address 172.16.10.13, successfully demonstrating the addition of a new Load Balanced Pool member from another site via a L2VPN connection!

 

 

Cleaning up to get ready for the next section

 

For the next section, you'll be deploying a standalone Edge Gateway specifically for the purpose of acting as a L2VPN client. This is to simulate the use case of connecting a L2VPN to a remote site that has a vSphere instance that is not managed by NSX.  That means you'll need to remove your L2VPN-Client NSX Edge Gateway.

 

 

Deleting the L2VPN-Client NSX Edge Gateway

 

  1. Click on NSX Edges.
  2. Set the NSX Manager to 192.168.210.15 (Role: Secondary).
  3. Click on "edge-1" L2VPN-Client.
  4. Click on the Red X to delete.
  5. Click on Yes to confirm the deletion.

 

Standalone L2VPN Edge Client

 

Introduction

 

In the previous section, you had deployed two separate NSX Edge Gateways - one on Site A which acted as the L2VPN server (aptly named "L2PVPN-Server"), and one on Site B which acted as the L2VPN client. The goal of that exercise was to be able to show how one could extend a L2 domain across two separate sites, and demonstrate that by including a VM on Site B in the Load Balancer pool of a Load Balancer service hosted by an Edge Gateway on Site A.  

At the end of that section, you were told to delete the L2VPN-Client Edge Gateway.  In this section, you will be simulating the same use case as the previous section, but this time, the assumption is that Site B does not have NSX deployed, so instead you will have to deploy what is called a "Standalone Edge."  This is an OVF file that represents an Edge Gateway, but has the specific purpose of acting as a L2VPN client to be deployed on a vSphere instance that is not managed by NSX.  By the end of this section, you will have replicated the same service functionality of the previous section, and return L2 connectivity between both sites and the three Web VMs shown above in the topology.

 

 

Deploying the Standalone Edge OVF

 

  1. Click on the Home Icon.
  2. Click Hosts and Clusters.

 

 

Starting the Deploy OVF Wizard

 

Next, perform the following actions:

  1. Expand the vCenter "vcsa-01b.corp.local," the Datacenter "Datacenter Site B," and the vSphere cluster "Compute Cluster B."
  2. Right click on the host "esx-01b.corp.local."
  3. Select the option for "Deploy OVF Template..." to open the OVF Deployment Wizard.

 

 

Selecting the OVF Source

 

  1. Click on the radio button for "Local file".
  2. Click on the button "Browse...".

 

 

Open Desktop and folder

 

  1. Click on the Desktop shortcut.
  2. Double-click on the folder NSX-l2vpn-client.

 

 

Selecting the L2VPN-Client OVF File

 

In the window that comes up, perform the following actions:

  1. Select the file named "NSX-l2vpn-client.ovf."
  2. Click the Open button.  
  3. Then click Next to continue to the "Review details" section of the OVF deployment wizard.

 

 

Review OVF Details

 

In the "Review details" section, perform the following actions:

  1. Click the checkbox for "Accept extra configuration options."
  2. Click the Next button to continue.

 

 

Selecting OVF Placement Location

 

In the "Select name and folder" section of the OVF deployment wizard, perform the following actions:

  1. Expand the listing for Datacenter Site B.
  2. Select the folder named "NSX Edges."
  3. Click the Next button.

 

 

Selecting Storage

 

In the "Select storage" section of the OVF deployment wizard, perform the following actions:

 

 

Setup Networks

 

At this point, you'll start to notice that this is starting to look like the configuration of how you configured the NSX Edge Gateway earlier to act as the L2VPN client, and that's  a very astute observation.  Here you will be configuring which of the two Standalone Edge network interfaces acts as the Public connectivity interface, and which acts as the Trunk interface.  Perform the following actions:

  1. Select "vds-site-b_Uplink Network" for the Public interface.
  2. Select "vds-site-b_Trunk Network" for the Trunk interface.
  3. Click the Next button to continue.

 

 

Customize Template - Setting CLI Passwords

 

*Note: In a production environment, one would set these three passwords to be something different, but please keep in mind that they need to be at least twelve characters in length.

Next, you will be configuring the credentials for the Standalone Edge as follows:

  1. For the CLI "admin" User Password - enter the password of "VMware1!VMware1!" and enter it again in the "Confirm password" field.
  2. For the CLI "enable" User Password - enter the password of "VMware1!VMware1!" and enter it again in the "Confirm password" field.
  3. For the CLI "root" User Password - enter the password of "VMware1!VMware1!" and enter it again in the "Confirm password" field.
  4. Expand the settings for "Uplink Interface" by clicking on the right-facing arrow as shown in the screenshot.

 

 

Customize Template - Configuring Uplink Interface

 

Configure the Uplink Interface as follows:

  1. IP Address:  192.168.200.5
  2. Prefix Length: 24
  3. Default Gateway: 192.168.200.1
  4. Next, expand the settings for "L2VPN" to continue.

 

 

Customize Template - L2VPN Settings

 

For the L2VPN settings, enter in the following values:

  1. Ciphers:  Select "AES256-SHA" from the dropdown menu. (Remember, this is the cipher configured on the L2VPN server).
  2. Server Address: 192.168.5.5
  3. Server Port: 443
  4. Username: siteadmin
  5. Password: VMware1!
  6. Next, expand the settings for Sub Interfaces.

 

 

Customize Template - Sub Interfaces

 

*Note - You will be changing the VLAN of the VM Network port group on Site B to VLAN 103 later in this section. The number 1 in parentheses represents the Tunnel ID of 1.

For the Sub Interfaces settings, enter in the following values:

  1. Sub Interfaces VLAN (Tunnel ID):  103(1)
  2. Click the Next button to continue.

 

 

Review OVF Settings and Complete OVF Deployment

 

In the "Ready to complete" section of the OVF deployment wizard, perform the following actions:

  1. Review the settings that you have configured in the previous steps. They should look the same as what is shown in the screenshot.
  2. Click the checkbox for "Power on after deployment."
  3. Click the Finish button to conclude the wizard, and begin the actual OVF deployment.

 

 

Monitor Deployment Status

 

Monitor the progress of the OVF being deployed.  Once it has finished and powered on, continue to the next step.

 

 

Modifying VDS Port Groups to Support Standalone Edge Backed L2VPN Client

When utilizing an Edge Gateway deployed directly from NSX that acts as the L2VPN client, the below steps aren't needed, but because we're simulating a remote site that is *not* managed by NSX, one will need to modify some settings on the Distributed Virtual Switch, as well as the Trunk port group on Site B. Continue to to the next step to begin that process.

 

 

Establishing an SSH Connection to esx-01.corp.local

 

Open the PuTTY application, and perform the following actions in the PuTTY configuration window:

  1. Locate the saved session named "esx-01b.corp.local" and click on it.
  2. Click the Open button.

 

 

Obtaining the dvport number of the Standalone Edge interface on the Trunk

 

Part of getting the Trunk port group on the Distributed Virtual Switch ready is obtaining the DVPort ID for the interface of the Standalone Edge that's on the Trunk Port group.  The interface will always be the "eth1" interface, and one should look for the corresponding DVPort ID for that interface by running the following command after SSH'd to ESXi host "esx-01b.corp.local."

Remember you can the SEND To Console CLI commands.

esxcfg-vswitch -l

Make a note of that DVPort ID for the next step.  In the screenshot above it's ID 65, but it may be different for your lab once you reach this step.

 

 

Enabling the Sink Port on the Trunk Port Group

 

To enable the sink port on the Trunk port group, run the following command in the same SSH session you have open for esx-01b.corp.local:

Where <DVPortID> is listed, replace it with the DVPort ID obtained from the previous step.  For example, based on the screenshot from the previous step, the command given would be:

net-dvs --enableSink 1 -p 65 vds-site-b
net-dvs -l | grep "port\ [0-9]\|SINK\|com.vmware.common.alias"

Which should return something like the screenshot shown here.  You may close this SSH session and continue to the next step now.

 

 

Navigating to the Networks list for Site B in the vSphere Web Client

 

  1. Click the Home icon.
  2. Click on "Networking."

 

 

Edit Settings for the Trunk Port Group

 

  1. Expand the listing for vcsa-01b.corp.local, then Datacenter Site B, and then vds-site-b.
  2. Right click on the port group "vds-site-b_Trunk Network".
  3. Select "Edit Settings..."

 

 

Edit VLAN Settings for Trunk Port Group

 

  1. Click on the VLAN section.
  2. Select "VLAN trunking" from the VLAN type dropdown list.
  3. Enter "103" for the VLAN trunk range.
  4. Click on Security.

 

 

Edit Security Settings for the Trunk Port Group

 

  1. Change the selection for "Forged transmits" to "Accept".
  2. Click the OK button to submit the changes for this port group.

 

 

Edit Settings for the VM Network Port Group

 

  1. Next, you'll be changing the VLAN of the vds-site-b_VM Network portgroup.  To accomplish that, first right click the "vds-site-b_VM Network" port group.
  2. Select "Edit Settings..."

 

 

Edit VLAN Settings for the VM Network Port Group

 

To edit the VLAN of the VM Network Port Group...

  1. Click on "VLAN" in the left side bar.
  2. Select "VLAN" in the dropdown menu for "VLAN type."
  3. Enter "103" for the VLAN ID.
  4. Click the "OK" button to submit the change.

That concludes the changes needed for the distributed port groups to submit the Standalone Edge's L2VPN client. At this point, connectivity should be restored between the VM "web-02b" and the other VMs on the 172.16.10.0/24 network that are on Site A. Continue to the next step to confirm that connectivity.

 

 

Confirming Connectivity

 

ping 172.16.10.13

If the pings return, then connectivity should be restored, and you can now open up a web browser and attempt to see if the VM "web-02b" is still reachable from the Load Balancer configured in the previous section.

 

 

Loading the 3-Tier WebApp Local Site

 

After opening the Google Chrome web browser, perform the following actions:

  1. Open a new brower tab.
  2. Click on the "3-Tier WebApp Local" bookmark in the bookmark bar.
  3. Click the reload button again until the site is showing that it's being delivered from "172.16.10.13 web-02b".

Congratulations! You have completed the module for the L2VPN service in this lab.  Next up - you will be learning about the new centralized CLI commands available from the NSX Manager.

 

Module 6 - NSX Operations Central CLI

Introduction to NSX Operations Central CLI

In this module, you will be exploring a terrific new feature to assist in operational activities when working with NSX for vSphere, the new NSX Operations Central CLI.

In previous versions, if an administrator wanted to gain details on constructs such as the NSX Edge Gateways (as well as the services running on them), Distributed Logical Routers, and Logical Switches, they would require console access to one or more of the following:

In NSX for vSphere version 6.2, one can simply gain access to the console of the NSX Manager for gaining such details, rather than jumping between multiple console/SSH sessions.  This provides administrators with a more streamlined path for accessing operational data, and can help speed up the troubleshooting of issues that may occur within an environment where NSX for vSphere is deployed.  

Before going into more detail about what those new commands are, and the types of scenarios you will be going through in this module, please proceed to the next step where you will be performing a number of setup steps to get logged into the primary NSX Manager.

 

 

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

 

 

Setup

You will be performing a number of commands on the primary NSX Manager (nsxmgr-01a.corp.local) via the Windows SSH client PuTTY.

 

 

Opening PuTTY

 

 

 

Configuring NSX Manager SSH Connection in PuTTY

 

Within the PuTTY Configuration window, to load the connection details for the primary NSX Manager (nsxmgr-01a.corp.local)...

  1. Search for the session labelled "nsxmgr-01a.corp.local" under the Saved Sessions list, and click on it.
  2. Click the Open button.

This will open a new SSH session with the admin user to the primary NSX Manager.  In the window that comes up, you will be prompted for the password of the admin user.  Enter in the password VMware1! and press the enter key to continue.

 

 

NSX Manager Command Prompt

 

 

 

NSX Centralized CLI Command List

Before continuing, it is worth taking a look at a list of the available commands in the NSX Manager in NSX for vSphere version 6.2.  To do so, type in the following command at the command prompt:

list

As you can see, there are quite a few new options available for obtaining information from the NSX Manager CLI, including options that used to require an administrator to gain console access to individual NSX Edge Gateways, ESXi Hosts, or NSX Controllers.  Specifically, you'll be looking at the commands for dealing with the following situations:

  1. Troubleshooting VXLAN Connectivity
  2. Troubleshooting Distributed Logical Routers
  3. Obtaining Details on NSX Edge Gateways and their associated services
  4. Obtaining Details on the Distributed Firewall

Please leave this PuTTY window open, and proceed to the next step, where you will start with taking a look at some commands that will help out in troubleshooting VXLAN connectivity.

Note: All commands mentioned in this module are written in their entirety in the file "README.txt" on the Control Center desktop, in case you would like to simply copy and paste the commands.

 

Troubleshooting Logical Switches using the Central CLI

In the previous versions of NSX for vSphere, it was necessary to SSH/console into the NSX Manager, ESXi hosts, and NSX Controllers to get troubleshooting information for constructs like:

In this section, you will be exposed to a number of new commands available from the NSX Manager CLI to allow an administrator to gather details regarding the above in one place.  Continue to the next step to start gathering details about the vSphere Clusters, ESXi Hosts, and Virtual Machines on matters pertaining to network virtualization.

Note: You may find it useful to increase the width of the PuTTY window, or maximize the size of the window before proceeding as some of the output from the following commands may run over more than one line, which may make it difficult to read.

 

Cluster/Host/VM Details

For a majority of the commands covered in this module, it's required to know a specific Host-iD (ESXi Host), Domain-ID (vSphere Cluster), VM-ID (Virtual Machine), and/or vNIC-ID (Virtual NIC on Virtual Machine).  The following commands will walk you through how to obtain those values.  The specific IDs will be mentioned in the later sections of this module, but this is how one would normally find those identifiers.  

 

 

Listing all clusters

 

To list all clusters, for NSX Manager-01a found in Site A, run the following command:

show cluster all

The output received should be similar to the screenshot above.  With columns for:

Let us find out more information about "Compute Cluster A," so continue to the next step to find out how to retrieve a list of hosts for that cluster.

 

 

Showing all hosts in a cluster

 

To list the set of hosts in a vSphere cluster, run the following command:

show cluster domain-c33

You will remember that "domain-c33" was the value under the "Cluster-ID" column for the previous command run, so that's what will be passed into this command to get a list of hosts in the "Compute Cluster A" vSphere cluster.  The output received should look like what's shown in the screenshot, with columns for:

Perhaps in a troubleshooting scenario it's found that a VM that's lacking connectivity happens to be a host that isn't fully prepared for NSX, and does not have a status of "Ready" for it's installation status of network virtualization components? Now you know an quick way to query hosts to find out without having to log into the vSphere Web Client.

You will find out more about the VMs on the two hosts in this cluster in the following step.

 

 

Specific Host Details

 

To list the Virtual Machines (VMs) on each of the hosts, run the following two commands:

show host host-28
show host host-32

The values "host-28" and "host-32" refer to the Host IDs of both esx01a.corp.local and esx02a.corp.local, respectively.  These values will be passed into the "show host" command to retrieve the following values about the VMs running on these hosts:

Going forward, you will be singling out the virtual machine "app-01a", so the VM ID  "vm-217" will be used quite often for other commands used in this module.  To find out more about the vNIC details of "app-01a," proceed to the next step.

 

 

Specific VM Details

 

Enumerating the vNIC details of a VM can be performed with the following command

show vm vm-217

Here, we are passing the VM ID of "vm-217" which is referring to the VM "app-01a."  The output received should be similar to the screenshot shown, with the following properties:

Next, to gather more details regarding that specific vNIC.

 

 

 

Specific vNIC Details

 

To obtain further details about the vNIC of a VM, use the command "show vnic <vNIC ID>."  For the vNIC of the "app-01a" VM, enter in the following command:

show vnic 502e8300-5e65-8aa6-8593-49472d923190.000

In the results, you will notice the following details being returned:

Now that you have been introduced to some preliminary commands to gather information such as the VM ID, vNIC ID, Host ID, and Cluster ID, you will be using those to dive into some additional details about the Logical Switches themselves in the next section.

 

 

Logical Switch Commands

Next up, you'll be going through the set of options available in the "show logical-switch" command.  Specifically, you'll be going through the following scenarios:

Continue to the next step to learn about how to list all logical switches within the new NSX Manager Central CLI.

 

 

List all Logical Switches

 

To list all the Logical Switches under the management of this NSX Manager, run the following command

show logical-switch list all

If the command has been run successfully, you should see results similar to the screenshot here.  The values you should observe returned from this command are:

Next, you'll be obtaining some additional details on logical switches specific to an ESXi host.  

 

 

Logical Switch Details On a Host - Verbose

 

To list the verbose details of all logical switches on a host, run the following command (you may replace host-28 with host-32 to view details for the other host):

show logical-switch host host-28 verbose

This will display quite a lot of information regarding the logical switches running on the host, and you will need to use the Space key to fully scroll through all of it before getting the command prompt to come back up again.  Some details worth noting here are:

Next, you wil observe some statistics pertaining to logical switches on a particular ESXi host.

 

 

Logical Switch Details On a Host - Statistics

 

To obtain statistics regarding logical-switches on a host, run the following command:

show logical-switch host host-28 statistics

The value "host-28" here can be replaced with "host-32" to obtain statistics for the second host. In the case of a lack of L2 traffic between VMs on the same Logical Switch on different ESXi hosts, the counters here would be of use to watch for troubleshooting purposes.

 

 

List all Hosts With VMs on a specific VNI

 

If you wanted to know what hosts have VMs on a specific VXLAN Network Identifier (VNI), you can run the following command:

show logical-switch list vni 5002 host

Here, we're displaying all ESXi hosts that currently have VMs on a specific VNI. The details shown are:

1.) ID - This is specifically referring to the Host ID, a unique identifier for the ESXi host.

2.) HostName - The fully qualified domain name for the ESXi host.

3.) VdsName - The Distributed Virtual Switch that the ESXi host resides on with the associated logical switch/VNI.

 

 

List VTEP IP Addresses and MAC Addresses on a Controller Slice for a specific VNI

 

To determine if a particular VNI has VTEP/MAC Table information on a NSX Controller, perform the following command:

show logical-switch controller controller-2 vni 5002 vtep

It's possible that this command may not return any details, so if that occurs, replace the "controller-2" in the command above with either "controller-1" or "controller-3".  The IP addresses shown here refer to the VTEP IP addresses on the ESXi hosts.

 

 

List ARP Table Entries on a Controller Slice for a specific VNI

 

To list ARP Table entries for a specific VNI on a NSX Controller, run the following command:

show logical-switch controller controller-2 vni 5002 arp

As before, it's possible that this command may not return any details, so in the event of that occurring, try replacing "controller-2" in the command above with either "controller-1" or "controller-3".  The IP address shown here belongs to a VM.

 

 

List MAC/VTEP Table Entries on a Controller Slice for a specific VNI

 

To display the MAC Address/VTEP table for a given VNI on a NSX Controller, input the following command:

show logical-switch controller controller-2 vni 5002 mac

If no results return, try again with one of the other two NSX Controllers (controller-1 and controller-3).  You may also notice that the MAC address shown here belongs to the IP address 172.16.20.11, as per the previous command.

 

 

Show Statistics for a specific VNI on a Controller

 

To display a number of statistics pertaining to the VNI on a NSX Controller, run the following command:

show logical-switch controller controller-2 vni 5002 statistics

Try swapping out "controller-2" in the command above with either "controller-1" or "controller-3".

 

 

Show Slice Detail for Joined-VNIs on a Specific Host

 

To show details pertaining to joined VNIs for a specific host on a NSX Controller, provide the command:

show logical-switch controller controller-2 host 192.168.110.51 joined-vnis
show logical-switch controller controller-2 host 192.168.110.52 joined-vnis

In this command, "controller-2" can be replaced with either "controller-1" or "controller-3", and the host IP referenced here is for ESXi host's VTEP IP address.  In the screenshot above, the VTEP IP addresses for hosts "esx-01a.corp.local" (192.168.110.51) and "esx-02a.corp.local" (192.168.110.52) are provided.

That only covers some of the new commands available regarding Logical Switches. In the next part, you'll be exploring what's available for troubleshooting Logical Routers.

 

Troubleshooting Distributed Logical Routers using the Central CLI

Next, you will learn about some of the commands available to troubleshoot the distributed logical routers you have deployed in your NSX for vSphere environment.  Before we jump into the commands themselves, take a look at the next page to get a refresher on some of the unique identifiers that will be utilized for some of these commands, and what they refer to.  Feel free to come back to that page during the rest of the steps in this section if you want.

 

Reference IDs

As with the logical switch commands, there are a number of unique identifiers to be referenced when running some of the new logical-router commands in the NSX Manager CLI.  These are provided here for ease of reference:

vSphere Clusters

Management & Edge Cluster :  domain-c41

Compute Cluster A :  domain-c33

 

ESXi Hosts

esx-01a.corp.local : host-28

esx-02a.corp.local : host-32

 

Virtual Machines

web-01a: vm-216

web-02a: vm-219

web-03a: vm-223

app-01a: vm-217

app-02a: vm-264

db-01a: vm-218

db-02a: vm-266

 

 

 

 

Logical Router Commands

Now that you have gotten a refresher on some of the identifiers for the objects you will be looking at, move on to the next step to learn how to obtain a list of all deployed distributed logical routers.

 

 

List all Logical Routers

 

To list all distributed logical routers, run the following command:

show logical-router list all

The following values will be returned:

Note - The router with the ID of 30d40 will only appear if you have gone through the steps in the previous modules to create a Universal Distributed Logical Router.  If you have not, that is ok, and you may continue with the lab.

 

 

 

Show ESXi Hosts where a Logical Router Exists

 

To display what ESXi hosts a specific Distributed Logical Router exists, enter the following commands:

show logical-router list dlr 1388 host

That will return the unique ID of the ESXi host, as well as the "friendly" host name of the ESXi host where a given DLR is recognized.

 

 

Show Logical Router Connection Details on a specific ESXi Host

 

To display physical network connection information for given ESXi host where a distributed logical router is deployed at, run the following commands:

show logical-router host host-28 connection
show logical-router host host-32 connection

This will display information regarding the Distributed Virtual Switch that the logical routers on the ESXi host utilize, as well as the number of logical interfaces (LIFs).

Additionally, information regarding the uplinks used by the DVS, and statistics regarding the number of packets dropped, replaced, and skipped are shown.

 

 

Show Verbose Information for a specific Logical Router on a specific ESXi Host

 

A good quick way to obtain useful information regarding a DLR on a specific ESXi host can be to run the following command (shown here for two hosts):

show logical-router host host-28 dlr 1388 verbose
show logical-router host host-32 dlr 1388 verbose

Details such as the name of the DLR, the DLR ID, the number of LIFs and routes, the type of DLR (global or universal), and the NSX Controller owning the slice pertaining to this DLR are shown.

 

 

Show ARP Table Entries for a specific Logical Router on a specific ESXi Host

 

Another useful command which can display the ARP table for a given DLR on an ESXi host is the following (once again, shown for two different hosts):

show logical-router host host-28 dlr 1388 arp
show logical-router host host-32 dlr 1388 arp

One will notice that some of the IP addresses appear on both hosts, that would be because these are the interfaces of the logical-routers themselves (which would exist on all hosts).

 

 

Show Routing Table Entries for a specific Logical Router on a specific ESXi Host

 

It is definitely useful to be able to obtain routing table information for a given logical-router, and rather than SSH'ing to every host to obtain that information, one can run the following command within the NSX Manager:

show logical-router host host-28 dlr 1388 route
show logical-router host host-32 dlr 1388 route

 

 

 

Show Routing Table Entries on a Controller for a specific Logical Router

 

If one was curious to find out what the routing table entries for a given DLR are for on the controller which own's that DLR's slice, they could run the following command:

show logical-router controller controller-2 dlr 1388 route

The previous command around obtaining verbose information for a Distributed Logical Router can be used to obtain the IP address for the controller that should be used in the above command.  If the above command comes back with no results, try replacing "controller-2" with "controller-1" or "controller-3".

 

 

Show LIF Configuration on a Controller for a specific Logical Router

 

To display the Logical Interface (LIF) configuration present on a controller for a given DLR, run the following command:

show logical-router controller controller-3 dlr 1388 interface

The IP address of the LIF will be shown, as well as the unique ID for the LIF (see the column "Id").  If the command does not return anything, try replacing "controller-3" with "controller-1" or "controller-2".

 

 

Show Brief Details on a Controller for a specific Logical Router

 

Rather than running the aforementioned verbose command, one can obtain a smaller subset of information for a given DLR on a specific controller by running the following command (commands shown below for DLR-IDs 30d40 and 1388):

show logical-router controller controller-3 dlr 1388 brief

Information shown includes:

Next up, you will learn about one of the biggest time savers the Central CLI offers - the ability to obtain information about NSX Edge Gateways, all without having to enable SSH on an Edge (or console into one)!

 

Troubleshooting Edge Service Gateways using the Central CLI

Remember when one had to enable SSH or utilize a VMRC session to get access to an Edge Gateway and obtain details about the services running on it?  

Those days are gone, welcome to the age of the Central CLI!

This section will go over some of the *many* options available to the NSX Administrator with regards to the Edge Gateways.  Provided in the next step are a set of Reference IDs for the vSphere clusters, ESXi hosts, and Virtual Machines in the environment for easy reference.  After that, you will jump right in to going over some of the Edge Gateway related commands available in the Central CLI located on the NSX Manager.

 

Reference IDs

These are provided here for ease of reference:

vSphere Clusters

Management & Edge Cluster :  domain-c41

Compute Cluster A :  domain-c33

 

ESXi Hosts

esx-01a.corp.local : host-28

esx-02a.corp.local : host-32

 

Virtual Machines

web-01a: vm-216

web-02a: vm-219

web-03a: vm-223

app-01a: vm-217

app-02a: vm-264

db-01a: vm-218

db-02a: vm-266

 

 

NSX Edge Gateway Commands

As mentioned before, feel free to come back to the Reference-IDs section if you happen to forget how to obtain any of the unique identifiers for objects like clusters, hosts, or VMs.  Next up, you'll learn how to obtain a list of all deployed NSX Edge Gateways in an environment.

 

 

Show all NSX Edge Gateways

 

To list all deployed NSX Edge Gateways for a given NSX Manager (this will *not* show Edge Gateways across multiple sites), run the following command

show edge all

The values returned refer to the following:

Now that you're able to identify the list of NSX Edge Gateways, as well as their unique identifier (the "Edge ID" value), continue to the next step to learn how to show more details about a specific Edge Gateway.

 

 

Show Details of a specific NSX Edge Gateway

 

To get a quick view of what services are enabled on an Edge Gateway, as well as some other miscellaneous information, input the following command (edge-4, the OneArm-LoadBalancer-01 Edge is used here):

show edge edge-4

Returned is the following data...

Given that one can tell the Load Balancer service is running from the above command, let's take a look at some more details about how the load balancer is configured.

 

 

Show Load Balancer Service Details on a specific NSX Edge Gateway

 

To show the Load Balancer configuration of an Edge Gateway (if the service is configured), run the following command:

show edge edge-4 configuration loadbalancer

What will be returned is a JSON message detailing the various details of the Load Balancer configuration.  What if you wanted to be able to see if there has been any errors on the load balancing service? On the next step, you will find how how to obtain that information.

 

 

Show Load Balancer Service Error Details on a specific NSX Edge Gateway

 

To retrieve the list of errors for the Load Balancer service on the OneArmed-LoadBalancer-01 Edge Gateway, perform the following command:

show edge edge-4 service loadbalancer error

The total number L7 Request/Response errors seen by the load balancer service will be displayed.  In a troubleshooting scenario, it may be also worth looking at some details with regards to the flows running on an Edge Gateway.  Continue to the next step to learn how.

 

 

Retrieve Flow Table for a specific NSX Edge Gateway

 

To display the current flowtable of a given NSX Edge Gateway (edge-4 is used in this example), enter the following command:

show edge edge-4 flowtable

Returned will be the total number of flows currently active on the Edge Gateway, showing details such as the protocol in use, the source/destination IP addresses, the source/destination ports, and the number of packets and bytes seen for the particular flow.

 

 

Display OSPF Details on a specific NSX Edge Gateway

 

Displaying dynamic routing information quickly for any Edge Gateway is a huge benefit of the new Central CLI, and in this example you'll be taking a look at the OSPF details for the Edge Gateway "Perimeter-Gateway-01".  To do so, enter the command:

show edge edge-3 ip ospf

In addition to the ability to display dynamic routing details, one can also show the routing table of a given edge.  Continue to the next step to learn how to do so.

 

 

Display Routing Table Information on a specific NSX Edge Gateway

 

To retrieve the routing table of a particular Edge Gateway,  type the following command in (once again, the Edge Gateway "Perimeter-Gateway-01" is used here):

show edge edge-3 ip route

This command will show all static and dynamically obtained routes for the Edge Gateway.

 

 

Display Top 10 Flows per Firewall Rule on a specific NSX Edge Gateway

 

In case you also wanted to be able to obtain more details regarding the firewall on the Edge Gateway, such as the top flows matching for any particular firewall rule, the following command can be utilized:

show edge edge-4 firewall flows topN 10

In the example within the screenshot, you'll notice flows matching Firewall rules "131074," as well as "131073."

Next, you'll learn about some of the Central CLI commands available for obtaining information about the Distributed Firewall.

 

 

Troubleshooting Distributed Firewall using the Central CLI

In this last section of the module for exploring the Central CLI, you'll be looking at some of the commands available to deal with the Distributed Firewall (DFW).  As in previous sections, the next step will include a list of Reference IDs for objects such as vSphere clusters, ESXi Hosts, and VMs for quick reference.

 

Reference IDs

These are provided here for ease of reference:

vSphere Clusters

Management & Edge Cluster :  domain-c41

Compute Cluster A :  domain-c33

 

ESXi Hosts

esx-01a.corp.local : host-28

esx-02a.corp.local : host-32

 

Virtual Machines

web-01a: vm-216

web-02a: vm-219

web-03a: vm-223

app-01a: vm-217

app-02a: vm-264

db-01a: vm-218

db-02a: vm-266

 

 

Distributed Firewall Commands

Feel free to come back to those Reference IDs if needed to get a quickly reference some of the unique identifiers used in the steps coming up.  Next, you will learn how to show the current status of the Distributed Firewall on all vSphere clusters managed by a particular NSX Manager.

 

 

Show Distributed Firewall Status on all vSphere Clusters

 

To show the current status of the Distributed Firewall on a cluster, run the following command:

show dfw cluster all

This will provide the following details:

In case there's a particular host in a cluster for which you are noticing some issues pertaining to the DFW on, the next command may come in handy.

 

 

Show Distributed Firewall Status on a specific vSphere Cluster

 

To show the installation status of the Distributed Firewall service on all hosts for a given vSphere cluster, issue the following command (Compute Cluster A is used below):

show dfw cluster domain-c33

This will provide the following details:

To drill down even further to the Virtual Machine level, continue on to the next step.

 

 

Show Virtual Machine Distributed Firewall Details for a specific VM

 

To enumerate the specific DFW filters on a specific Virtual Machine (VM), as well as the vNICs on that VM, run the following command (app-01a is used here as an example):

show dfw vm vm-217

Worth mentioning are the following returned details:

You can take the values from the list of filters and vNICs to obtain more details pertaining to the Distributed Firewall and how it's applied to a VM. Continue to the next step to learn how.

 

 

Show Rules on a specific Virtual Machine vNIC

 

To displays the firewall rules attached to any specific filter attached to a Virtual Machine's vNIC, run the following command (the vNIC for app-01a is used in this example):

show dfw host host-32 filter nic-37844-eth0-vmware-sfw.2 rules

What will be output are the actual rules for the specific filter passed with the command.  It's worth noting the rule numbers "rule 1001-rule 1008" as they'll be referenced in the next command, which will help show some statistics for each of the rules.

 

 

Show Distributed Firewall Statistics for a specific Virtual Machine vNIC

 

To show usage statistics for a given DFW filter, perform the following command (once again, the filter applied to the vNIC for app-01a is used here):

show dfw host host-32 filter nic-37844-eth0-vmware-sfw.2 stats

Displayed will be the number of times a particular DFW rule has been utilized for the given vNIC's filter passed to the command.  To obtain further details regarding each flow that matches a given filter, continue to the last step of this section.

 

 

Show Distributed Firewall Flow Details for rules applied to a specific Virtual Machine vNIC

 

To display flow details for a given DFW filter, use the following command:

show dfw host host-32 filter nic-37844-eth0-vmware-sfw.2 flows

In the above example, there are no flows currently retrieved for this filter, but as you may notice, the number of flows will be shown with regards to active (L3/L4), active (L2), and dropped (L2, L3, L4) flows.

 

 

Conclusion

That concludes the section of this Hands on Lab covering the new commands available for troubleshooting purposes on the NSX Manager CLI.  Next up, learn about the RESTful API that's available with NSX for vSphere, and some of the actions one can perform with it!

 

Module 7 - NSX Automation

NSX RESTful API

NSX is designed ground up with a RESTful API. The NSX REST API can be used to both configure NSX and to provision NSX logical network services. The NSX REST API can be called directly or indirectly from various programing languages. Many orchestration and automation tools such as vRealize Automation via vRealize Orchestrator can call the NSX REST API to perform Layer 2 through Layer 7 network orchestration and automation.

To demonstrate NSX RESTful API calls, you will be using the RESTClient extension to the Mozilla Firefox browser. RESTClient is a debugger for RESTful Web Services and is a useful tool when working with various REST API's.

 

Introduction to REST API's

 

A REpresentational State Transfer (REST) API defines a set of simple principles which are loosely followed by most API implementations.

REST leverages the strength of HTTP to send data (Headers and Bodies) between Clients and Servers.

The term Uniform Resource Locator (URL) and Uniform Resource Identifier (URI) can be used interchangeably when working with REST. Although the Mozilla Firefox RESTClient uses a field called URL, it is in fact a URI field.

Resources (building blocks) are linked together by embedded hyperlinks in HTML documents or URI references, and resources can expose the state via representations containing both metadata (such as size, media type, or character set) and content (binary image or text document).

 

 

REST Request Methods

 

REST Clients specify the desired interaction (HTTP request message as defined by RFC 2616). Each HTTP method has specific, well-defined semantics within the context of a REST API’s resource model:

 

 

REST Response Status Codes

 

The REST APIs use a HTTP response message to inform clients of their request’s result (as defined in RFC 2616). Five categories are defined:

§HTTP response message to inform clients of their request’s result (As Defined in RFC 2616):

 

 

HTTP Request Headers for the NSX RESTful API

 

When configuring RESTful API's to provision NSX services, the following are a list of the important request headers:

  1. Authorization: The user and password credential in Base64 encoded format.
  2. Content-Type:"application/xml". Says that the request body/payload is in xml format.

 

 

HTTP Requests for the NSX RESTful API

 

  1. Method/Verb: GET/PUT/POST/DELETE : Action on the resource
  2. URL: Resource
  3. Headers: Authorization and Content-Type
  4. Body: XML Payload
  5. Status Code: 2xx For Success and 4xx and 5xx for Failures

 

 

Using the Mozilla Firefox RESTClient to demonstrate the NSX REST API

 

Mozilla Firefox provides an extension called RESTClient. This extension has been installed into Mozilla Firefox within the lab environment so no download or configuration is required. The RESTClient is a useful tool for testing all RESTful API's.

 

 

REST API Calls are directed at NSX Manager

 

 

 

Open the Mozilla Firefox Browser

 

 

 

Open the RESTClient

 

 

 

Configure NSX API HTTP Request Headers

HTTP Request Headers are required to ensure correct use of the NSX API

 

 

Set Header Authentication Type - Basic Authentication

 

  1. Click Authentication
  2. Click Basic Authentication

 

 

Enter Basic Authentication Credentials

 

  1. Enter Username: admin
  2. Enter Password: VMware1!
  3. Click on the Remember Me box. This will ensure the header is saved for future use.
  4. Click on the Okay button.

 

 

Validate the Header is visible in RESTClient Window

 

 

 

Set Header Content Type - Application/XML by Selecting Custom Header

 

  1. Click on Headers
  2. Click on Custom Header

 

 

Enter Custom Header - Content-Type application/xml

 

  1. Enter Name: Content-Type
  2. Enter Value: application/xml - Be careful that you do not accept the default of application/json.
  3. Click on Save to Favorite - This will ensure the header is saved for future use.
  4. Click on the Okay button.

 

 

Validate the Header is visible in the RESTClient window

 

 

 

How to Delete Incorrect Headers

 

If you accidentally enter the Header details incorrectly, Headers can be deleted by clicking on the "x" next to the Header entry. In this example, Content-Type: application/json was incorrectly entered.

As an example only, bad headers can be deleted by clicking on the "x".

 

 

Special Instructions for Commands and Configuration

 

The following exercises will require you enter commands and/or configuration. The text boxes within the lab manual such as the example below combined with the SEND TEXT function, allow you to copy and paste commands and configuration into the lab.

As an example only, the steps to use the SEND TEXT function are as follows:

  1. Click to place your curser where you need text pasted.
  2. Click on SEND TEXT function of the Hands On Lab.
  3. Copy the text (Ctrl-C/Command-C) from the text box below and paste (Ctrl-V/Command-V) into the SEND TEXT TO CONSOLE box.
  4. Press the SEND TEXT TO CONSOLE "SEND" button.
ls -l | grep test

 

 

Use the NSX API to Query NSX Controller ID's

NSX REST API Exercise 1, we will Query the currently controller configuration to learn their running id's. This will allow you to then perform additional NSX REST API requests against the configured id. This demonstrates no prior knowledge of the controller configuration is needed. Programmatically, performing various queries against a running NSX system will allow information to be gathered to then allow changes to be made.

 

 

In Firefox RESTClient, Enter GET Request and URL to obtain Controller Configuration

 

  1. Select the REST Method GET from the drop-down box.
  2. Using SEND TEXT, Copy and Paste the URL below into the URL Field.
  3. Press the SEND button.
 https://nsxmgr-01a.corp.local/api/2.0/vdn/controller

 

 

Validate the GET request was successful by reviewing the Response Header

 

  1. Click on the Response Header Tab
  2. Validate the GET generated a status code of 200. This means the NSX API GET was successful.

 

 

Review the data generated by the GET request by reviewing the Response Body (Highlight)

 

  1. Click on the Response Body (Highlight) Tab
  2. Scroll down to review the response to the NSX GET Controller API call. Note the id of each controller. The configuration of all three controllers will be listed.

Of importance is the id of each controller identified by the XML <id>controller name</id>. In this environment, the three controllers are known as controller-1, controller-2, controller-3, but this could be different. Programming languages can parse the XML response and pass specific fields to subsequent calls enabling complex actions to be performed via API.

 

 

Use the NSX REST API to Delete Syslog Configuration from Controller id controller-1

NSX REST API Exercise 2, we will assume there is existing NSX Controller Syslog configuration on controller-1 and we will proceed to delete the perform the following actions via the NSX REST API.

 

 

In Firefox RESTClient, Enter DELETE Request and URL to delete Controller Configuration for Controller-1

 

  1. Select the REST Method DELETE from the drop-down box
  2. Using SEND TEXT, Copy and Paste the URL below into the URL Field.
  3. Press the SEND button.
 https://nsxmgr-01a.corp.local/api/2.0/vdn/controller/controller-1/syslog

 

 

Validate the DELETE request was successful by reviewing the Response Header

 

  1. Click on the Response Header Tab
  2. Validate the DELETE generated a status code of 200. This means the NSX API DELETE request was successful.

The NSX API DELETE will not generate any additional data so the Response Body (Highlight) tab will be empty.

 

 

Use the NSX REST API to Query the Syslog configuration from Controller id controller-1

NSX REST API Exercise 3, we will now query the current Syslog configuration of controller-1. Given that we have just deleted the Syslog configuration, we would expect to receive a response to indiciate there is no configuration.

 

 

In Firefox RESTClient, Enter GET Request and URL to obtain current Syslog configuration for Controller-1

 

  1. Select the REST Method GET from the drop-down box.
  2. There should be no change to the URL from the previous exercise. Validate it is correct.
  3. Press the SEND button.

 

 

Validate the GET request was successful by reviewing the Response Header

 

  1. Click on the Response Header Tab
  2. Validate the GET generated a status code of 500. This means the NSX API GET was unsuccessful. This is an expected result.

 

 

Review the data generated by the GET request by reviewing the Response Body (Highlight)

 

  1. Click on the Response Body (Highlight) Tab
  2. Scroll down to review the response to the NSX GET Syslog Configuration API call. Note the "404 Not Found" status.

You have identified there is no Syslog configuration and this is an appropriate response given we deleted the Syslog configuration in the previous Exercise.

 

 

Use the NSX REST API to Add Syslog Configuration to Controller id controller-1

In the previous exercise, we validated no Syslog configuration exists for controller-1. NSX REST API Exercise 4, we will add Syslog configuration to controller-1. Note, no change to the URL or Headers is required as we are working with the same REST object.

 

 

In Firefox RESTClient, Enter POST Request and Configuration to add/update Syslog configuration for Controller-1

 

  1. Select Method POST from the drop-down box.
  2. There should be no change to the URL from the previous exercise. Validate it is correct.
  3. Using SEND TEXT, Copy and Paste the XML below containing the Syslog configuration into the Request Body Field.
  4. Press the SEND button.
<controllerSyslogServer>
<syslogServer>192.168.110.24</syslogServer>
<port>514</port>
<protocol>UDP</protocol>
<level>INFO</level>
</controllerSyslogServer>

 

 

Validate the POST request was successful by reviewing the Response Header

 

  1. Click on the Response Headers Tab
  2. Validate the POST request generated a status code of 200. This means the NSX API request was successful.

The NSX API POST request will not generate any additional data so the Response Body (Highlight) tab will be empty.

 

 

Use the NSX API GET request to Query Syslog configuration from Controller id controller-1

NSX REST API Exercise 5, we will now query the current Syslog configuration of controller-1. The previous exercise configured Syslog so this query request should return the current configuration. Note, no change to the URL or Headers is required as we continue to work with the same REST object.

 

 

In Firefox RESTClient, Enter GET Request and Configuration to review current Syslog configuration for Controller-1

 

  1. Select Method GET from the drop-down box.
  2. There should be no change to the URL from the previous exercise. Validate it is correct.
  3. Although Request Body is still populated from the previous POST request, this will be ignored by the GET request. Optionally, you can clear this field.
  4. Press the SEND button.

 

 

Validate the GET request was successful by reviewing the Response Header

 

  1. Click on the Response Header Tab
  2. Validate the GET generated a status code of 200. This means the NSX API POST request was successful.

 

 

Review the data generated by the GET request by reviewing the Response Body (Highlight)

 

  1. Click on the Response Body (Highlight) Tab
  2. Scroll down to review the response to the NSX GET Syslog Configuration API call. Note the configuration matches what was set in the previous Exercise.

You have now successfully used the NSX API to change the NSX configuration:

 

 

Use the NSX REST API to Create a new Logical Switch

NSX network constructs including Switches, Routers, and Firewall rules can be created with the NSX REST API. Automation software such as vRealize Automation combined with vRealize Orchestrator will leverage the NSX REST API to create network objects in Multi Machine application blueprints. NSX REST API Exercise 6 will demonstrate the creation of a new Logical Switch.

Logical Switches are subordinate to a NSX Transport Zone so the first step before a switch can be created is identify the name of the Transport Zone or "vdnscope". Once we know the name of the vdnscope, we can use this name in the request to create a Logical Switch.

 

 

In Firefox RESTClient, Enter GET Request to obtain vdn/scopes (Transport Zones)

 

  1. Select Method GET from the drop-down box.
  2. Using SEND TEXT, Copy and Paste the URL below into the URL Field.
  3. Press the SEND button.
https://nsxmgr-01a.corp.local/api/2.0/vdn/scopes

 

 

Validate the GET request was successful by reviewing the Response Header

 

  1. Click on the Response Header Tab
  2. Validate the GET generated a status code of 200. This means the NSX API GET request was successful.

 

 

Review the data generated by the GET request by reviewing the Response Body (Highlight)

 

  1. Click on the Response Body (Highlight) Tab
  2. Scroll down to review the response to the NSX GET vdnscopes API call. Note the "<objectId>vdnscope-1</objectId>".

You have identified the id of the Global Transport Zone is vdnscope-1. With this information, you can now create Logical Switches using this id. This demonstrates how the configuration of the transport zones can be discovered so that new logical switches can be programmatically added to the correct transport zone as part of an orchestration workflow.

 

 

In Firefox RESTCLient, Enter POST Request and URL to create a new Logical Switch

 

  1. Select Method POST from the drop-down box.
  2. Using SEND TEXT, Copy and Paste the URL below into the URL Field.
 https://nsxmgr-01a.corp.local/api/2.0/vdn/scopes/vdnscope-1/virtualwires

 

 

In Firefox RESTCLient, Enter BODY Request to create a new Logical Switch

 

  1. Using SEND TEXT, Copy and Paste the XML below for the new Logical Switch Definition into the Request Body Field.
  2. Press the SEND Button. 
<virtualWireCreateSpec>
<name>Test-Logical-Switch-01</name>
<description>Created by REST API</description>
<tenantId>virtual wire tenant</tenantId>
<controlPlaneMode>UNICAST_MODE</controlPlaneMode>
</virtualWireCreateSpec>

 

 

Validate the POST request was successful by reviewing the Response Header

 

  1. Click on the Response Headers Tab
  2. Validate the POST request generated a status code of 201. This means the NSX API request was successful.

The NSX API POST request will also generate a name for the new logical switch.

 

 

Review Response Body (Highlight) to identify the new Logical Switch ID

 

  1. Click on the Response Body (Highlight) Tab
  2. Scroll down to review the response to the NSX POSTAPI call. Note the name given to the virtual wire.

You have identified the id of the new Logical Switch. With this id, programmatically you can connect this new Logical Switch to a Distributed Router and/or VM's. Note: The above virtualwire id may be different.

 

 

Review Logical Switches in the vSphere Web Client

Logical Switches created by API are no different to Logical Switches created using the vCenter Web UI. We will now review the vCenter Web UI and validate we can see the new Logical Switch.

 

 

Open a new Tab in the Firefox Browser

 

 

 

Open the vCenter Web Client

 

 

 

Logon to the Web Client

 

  1. Click on the box "Use Windows session authentication".
  2. Click Login

 

 

From the vSphere Web Client Main Menu, select Networking & Security

 

 

 

From Networking & Security, select Logical Switches

 

  1. Click on Logical Switches. The screen to the right of the tab will populate with a list of Logical Switches. You may need to use the scroll bars to scroll down to see all the switches defined.
  2. Note the Test-Logical-Switch-01. This is the Logical Switch created by API.

 

 

Scroll Right to see Switch Descriptions

 

  1. Use the Scroll Bar at the bottom of the list of Logical Switches to scroll right.
  2. Note the description "Created via REST API". This matches the description set in the REST POST API call.

 

 

Summary

 

The NSX REST API is a full function API that allows all capabilities of NSX to be consumed programatically. The NSX REST API is commonly used with orchestration engines such as vRealize Automation via vRealize Orchestrator to provision network services as part of a multi tier application blueprint. With the NSX Manager DNS/IP address and credentials, the complete network topology of a NSX-vSphere environment can be learned via the NSX REST API.

As part of the NSX Documentation library, the REST API is fully documented allowing any aspect of NSX to be orchestrated and automated.

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-SDC-1625

Version: 20150914-105335