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


Lab Overview - HOL-1826-01-NET - VMware NSX-T

Lab Guidance


Note: It will take more than 90 minutes to complete this lab. You should expect to only finish 2-3 of the modules during your time.  The modules are independent of each other so you can start at the beginning of any module and proceed from there. You can use the Table of Contents to access any module of your choosing.

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

[Lab Abstract:  Here you place your topic and introduce your VMW product.  Describe the general lab scenario]

Lab Module List:

 Lab Captains:

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

http://docs.hol.vmware.com

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

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


 

Location of the Main Console

 

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

 

 

Alternate Methods of Keyboard Data Entry

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

 

 

Click and Drag Lab Manual Content Into Console Active Window

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

 

 

Accessing the Online International Keyboard

 

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

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

 

 

Activation Prompt or Watermark

 

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

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

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

This cosmetic issue has no effect on your lab.  

 

 

Look at the lower right portion of the screen

 

Please check to see that your lab is finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes.  If after 5 minutes your lab has not changed to "Ready", please ask for assistance.

 

Module 1 - Introduction to NSX-T (15 minutes)

Introduction to NSX-T


In this module you will be introduced to NSX-T, its capabilities, and the components that make up the solution.


 

Lab Topology

 

 

 

What is NSX -T?

VMware NSX-T is designed to address emerging application frameworks and architectures that have heterogeneous endpoints and technology stacks. In addition to vSphere, these environments may also include other hypervisors (KVM), containers, and public clouds. NSX-T allows IT and development teams to choose the technologies best suited for their particular applications. NSX-T is also designed for management, operations and consumption by development organizations – in addition for IT

In much the same way that server virtualization programmatically creates, snapshots, deletes and restores software-based virtual machines (VMs), NSX-T network virtualization programmatically creates, snapshots, deletes, and restores software-based virtual networks.

With network virtualization, the functional equivalent of a network hypervisor reproduces the complete set of Layer 2 through Layer 7 networking services (for example, switching, routing, access control, firewalling, QoS) in software. As a result, these services can be programmatically assembled in any arbitrary combination, to produce unique, isolated virtual networks in a matter of seconds.

NSX-T works by implementing three separate but integrated planes: management, control, and data. The three planes are implemented as a set of processes, modules, and agents residing on three types of nodes: manager, controller, and transport nodes.

 

 

NSX-T Components (Part 1)

 

Data Plane

Performs stateless forwarding/transformation of packets based on tables populated by the control plane and reports topology information to the control plane, and maintains packet level statistics.

The data plane is the source of truth for the physical topology and status for example, VIF location, tunnel status, and so on. If you are dealing with moving packets from one place to another, you are in the data plane. The data plane also maintains status of and handles failover between multiple links/tunnels. Per-packet performance is paramount with very strict latency or jitter requirements. Data plane is not necessarily fully contained in kernel, drivers, userspace, or even specific userspace processes. Data plane is constrained to totally stateless forwarding based on tables/rules populated by control plane.

The data plane also may have components that maintain some amount of state for features such as TCP termination. This is different from the control plane managed state such as MAC:IP tunnel mappings, because the state managed by the control plane is about how to forward the packets, whereas state managed by the data plane is limited to how to manipulate payload.

 

Control Plane

Computes all ephemeral runtime state based on configuration from the management plane, disseminates topology information reported by the data plane elements, and pushes stateless configuration to forwarding engines.

The control plane is sometimes described as the signaling for the network. If you are dealing with processing messages in order to maintain the data plane in the presence of static user configuration, you are in the control plane (for example, responding to a vMotion of a virtual machine (VM) is a control plane responsibility, but connecting the VM to the logical network is a management plane responsibility) Often the control plane is acting as a reflector for topological info from the data plane elements to one another for example, MAC/Tunnel mappings for TEPs. In other cases, the control plane is acting on data received from some data plane elements to (re)configure some data plane elements such as, using VIF locators to compute and establish the correct subset mesh of tunnels.

The set of objects that the control plane deals with include VIFs, logical networks, logical ports, logical routers, IP addresses, and so on.

The control plane is split into two parts in NSX-T, the central control plane (CCP), which runs on the NSX Controller cluster nodes, and the local control plane (LCP), which runs on the transport nodes, adjacent to the data plane it controls. The Central Control Plane computes some ephemeral runtime state based on configuration from the management plane and disseminates information reported by the data plane elements via the local control plane. The Local Control Plane monitors local link status, computes most ephemeral runtime state based on updates from data plane and CCP, and pushes stateless configuration to forwarding engines. The LCP shares fate with the data plane element which hosts it.

Management Plane

The management plane provides a single API entry point to the system, persists user configuration, handles user queries, and performs operational tasks on all management, control, and data plane nodes in the system.

For NSX-T anything dealing with querying, modifying, and persisting user configuration is a management plane responsibility, while dissemination of that configuration down to the correct subset of data plane elements is a control plane responsibility. This means that some data belongs to multiple planes depending on what stage of its existence it is in. The management plane also handles querying recent status and statistics from the control plane, and sometimes directly from the data plane.

The management plane is the one and only source-of-truth for the configured (logical) system, as managed by the user via configuration. Changes are made using either a RESTful API or the NSX-T UI.

In NSX there is also a management plane agent (MPA) running on all cluster and transport nodes. Example use cases are bootstrapping configurations such as central management node address(es) credentials, packages, statistics, and status. The MPA can run relatively independently of the control plane and data plane, and to be restarted independently if its process crashes or wedges, however, there are scenarios where fate is shared because they run on the same host. The MPA is both locally accessible and remotely accessible. MPA runs on transport nodes, control nodes, and management nodes for node management. On transport nodes it may perform data plane related tasks as well.

Tasks that happen on the management plan include:

 

 

 

NSX-T Components (Part 2)

NSX Manager

NSX Manager provides the graphical user interface (GUI) and the REST APIs for creating, configuring, and monitoring NSX-T components, such as controllers, logical switches, and edge services gateways.

NSX Manager is the management plane for the NSX-T eco-system. NSX Manager provides an aggregated system view and is the centralized network management component of NSX-T. It provides a method for monitoring and troubleshooting workloads attached to virtual networks created by NSX-T. It provides configuration and orchestration of:

NSX Manager allows seamless orchestration of both built-in and external services. All security services, whether built-in or 3rd party, are deployed and configured by the NSX-T management plane. The management plane provides a single window for viewing services availability. It also facilitates policy based service chaining, context sharing, and inter-service events handling. This simplifies the auditing of the security posture, streamlining application of identity-based controls (for example, AD and mobility profiles).

NSX Manager also provides REST API entry-points to automate consumption. This flexible architecture allows for automation of all configuration and monitoring aspects via any cloud management platform, security vendor platform, or automation framework.

The NSX-T Management Plane Agent (MPA) is an NSX Manager component that lives on each and every node (hypervisor). The MPA is in charge of persisting the desired state of the system and for communicating non-flow-controlling (NFC) messages such as configuration, statistics, status and real time data between transport nodes and the management plane.

 

NSX Controller

NSX Controller is an advanced distributed state management system that controls virtual networks and overlay transport tunnels.

NSX Controller is deployed as a cluster of highly available virtual appliances that are responsible for the programmatic deployment of virtual networks across the entire NSX-T architecture. The NSX-T Central Control Plane (CCP) is logically separated from all data plane traffic, meaning any failure in the control plane does not affect existing data plane operations. Traffic doesn’t pass through the controller; instead the controller is responsible for providing configuration to other NSX Controller components such as the logical switches, logical routers, and edge configuration. Stability and reliability of data transport are central concerns in networking. To further enhance high availability and scalability, the NSX Controller is deployed in a cluster of three instances.

 

 Logical Switches

The logical switching capability in the NSX Edge platform provides the ability to spin up isolated logical L2 networks with the same flexibility and agility that exists for virtual machines.

A cloud deployment for a virtual data center has a variety of applications across multiple tenants. These applications and tenants require isolation from each other for security, fault isolation, and to avoid overlapping IP addressing issues. Endpoints, both virtual and physical, can connect to logical segments and establish connectivity independently from their physical location in the data center network. This is enabled through the decoupling of network infrastructure from logical network (i.e., underlay network from overlay network) provided by NSX-T network virtualization.

A logical switch provides a representation of Layer 2 switched connectivity across many hosts with Layer 3 IP reachability between them. If you plan to restrict some logical networks to a limited set of hosts or you have custom connectivity requirements, you may find it necessary to create additional logical switch

 

 

NSX-T Components (Part 3)

Logical Routers

NSX-T logical routers provide North-South connectivity, thereby enabling tenants to access public networks, and East-West connectivity between different networks within the same tenants.

A logical router is a configured partition of a traditional network hardware router. It replicates the hardware's functionality, creating multiple routing domains within a single router. Logical routers perform a subset of the tasks that can be handled by the physical router, and each can contain multiple routing instances and routing tables. Using logical routers can be an effective way to maximize router usage, because a set of logical routers within a single physical router can perform the operations previously performed by several pieces of equipment.

With NSX-T it’s possible to create two-tier logical router topology: the top-tier logical router is Tier 0 and the bottom-tier logical router is Tier 1. This structure gives both provider administrator and tenant administrators complete control over their services and policies. Administrators control and configure Tier-0 routing and services, and tenant administrators control and configure Tier-1. The north end of Tier-0 interfaces with the physical network, and is where dynamic routing protocols can be configured to exchange routing information with physical routers. The south end of Tier-0 connects to multiple Tier-1 routing layer(s) and receives routing information from them. To optimize resource usage, the Tier-0 layer does not push all the routes coming from the physical network towards Tier-1, but does provide default information.

Southbound, the Tier-1 routing layer interfaces with the logical switches defined by the tenant administrators, and provides one-hop routing function between them. For Tier-1 attached subnets to be reachable from the physical network, route redistribution towards Tier-0 layer must the enabled. However, there isn’t a classical routing protocol (such as OSPF or BGP) running between Tier-1 layer and Tier-0 layer, and all the routes go through the NSX-T control plane. Note that the two-tier routing topology is not mandatory, if there is no need to separate provider and tenant, a single tier topology can be created and in this scenario the logical switches are connected directly to the Tier-0 layer and there is no Tier-1 layer.

A logical router consists of two optional parts: a distributed router (DR) and one or more service routers (SR).

A DR spans hypervisors whose VMs are connected to this logical router, as well as edge nodes the logical router is bound to. Functionally, the DR is responsible for one-hop distributed routing between logical switches and/or logical routers connected to this logical router. The SR is responsible for delivering services that are not currently implemented in a distributed fashion, such as stateful NAT.

A logical router always has a DR, and it has SRs if any of the following is true:

The NSX-T management plane (MP) is responsible for automatically creating the structure that connects the service router to the distributed router. The MP creates a transit logical switch and allocates it a VNI, then creates a port on each SR and DR, connects them to the transit logical switch, and allocates IP addresses for the SR and DR.

 

NSX Edge Node

NSX Edge Node provides routing services and connectivity to networks that are external to the NSX-T deployment.

With NSX Edge Node, virtual machines or workloads that reside on the same host on different subnets can communicate with one another without having to traverse a traditional routing interface.

NSX Edge Node is required for establishing external connectivity from the NSX-T domain, through a Tier-0 router via BGP or static routing. Additionally, an NSX Edge Node must be deployed if you require network address translation (NAT) services at either the Tier-0 or Tier-1 logical routers.

The NSX Edge Node connects isolated, stub networks to shared (uplink) networks by providing common gateway services such as NAT, and dynamic routing. Common deployments of NSX Edge Node include in the DMZ and multi-tenant Cloud environments where the NSX Edge Node creates virtual boundaries for each tenant.

 

Transport Zones

A transport zone controls which hosts a logical switch can reach. It can span one or more host clusters. Transport zones dictate which hosts and, therefore, which VMs can participate in the use of a particular network.

A Transport Zone defines a collection of hosts that can communicate with each other across a physical network infrastructure. This communication happens over one or more interfaces defined as Tunnel Endpoints (TEPs).

If two transport nodes are in the same transport zone, VMs hosted on those transport nodes can "see" and therefore be attached to NSX-T logical switches that are also in that transport zone. This attachment makes it possible for the VMs to communicate with each other, assuming that the VMs have Layer 2/Layer 3 reachability. If VMs are attached to switches that are in different transport zones, the VMs cannot communicate with each other. Transport zones do not replace Layer 2/Layer 3 reachability requirements, but they place a limit on reachability. Put another way, belonging to the same transport zone is a prerequisite for connectivity. After that prerequisite is met, reachability is possible but not automatic. To achieve actual reachability, Layer 2 and (for different subnets) Layer 3 networking must be operational.

A node can serve as a transport node if it contains at least one hostswitch. When you create a host transport node and then add the node to a transport zone, NSX-T installs a hostswitch on the host. For each transport zone that the host belongs to, a separate hostswitch is installed. The hostswitch is used for attaching VMs to NSX-T logical switches and for creating NSX-T logical router uplinks and downlinks

 

 

Glossary of Components

The common NSX-T concepts that are used in the documentation and user interface.

Control Plane

Computes runtime state based on configuration from the management plane. Control plane disseminates topology information reported by the data plane elements, and pushes stateless configuration to forwarding engines.

Data Plane

Performs stateless forwarding or transformation of packets based on tables populated by the control plane. Data plane reports topology information to the control plane and maintains packet level statistics.

External Network

A physical network or VLAN not managed by NSX-T. You can link your logical network or overlay network to an external network through an NSX Edge. For example, a physical network in a customer data center or a VLAN in a physical environment.

Fabric Node

Node that has been registered with the NSX-T management plane and has NSX-T modules installed. For a hypervisor host or NSX Edge to be part of the NSX-T overlay, it must be added to the NSX-T fabric.

Fabric Profile

Represents a specific configuration that can be associated with an NSX Edge cluster. For example, the fabric profile might contain the tunneling properties for dead peer detection.

Logical Router

NSX-T routing entity.

Logical Router Port

Logical network port to which you can attach a logical switch port or an uplink port to a physical network.

Logical Switch

API entity that provides virtual Layer 2 switching for VM interfaces and Gateway interfaces. A logical switch gives tenant network administrators the logical equivalent of a physical Layer 2 switch, allowing them to connect a set of VMs to a common broadcast domain. A logical switch is a logical entity independent of the physical hypervisor infrastructure and spans many hypervisors, connecting VMs regardless of their physical location. This allows VMs to migrate without requiring reconfiguration by the tenant network administrator.

In a multi-tenant cloud, many logical switches might exist side-by-side on the same hypervisor hardware, with each Layer 2 segment isolated from the others. Logical switches can be connected using logical routers, and logical routers can provide uplink ports connected to the external physical network.

Logical Switch Port

Logical switch attachment point to establish a connection to a virtual machine network interface or a logical router interface. The logical switch port reports applied switching profile, port state, and link status.

Management Plane

Provides single API entry point to the system, persists user configuration, handles user queries, and performs operational tasks on all of the management, control, and data plane nodes in the system. Management plane is also responsible for querying, modifying, and persisting use configuration.

NSX Controller Cluster

Deployed as a cluster of highly available virtual appliances that are responsible for the programmatic deployment of virtual networks across the entire NSX-T architecture.

NSX Edge Cluster

Collection of NSX Edge node appliances that have the same settings as protocols involved in high-availability monitoring.

NSX Edge Node

Component with the functional goal is to provide computational power to deliver the IP routing and the IP services functions.

NSX-T Hostswitch or KVM Open vSwitch

Software that runs on the hypervisor and provides physical traffic forwarding. The hostswitch or OVS is invisible to the tenant network administrator and provides the underlying forwarding service that each logical switch relies on. To achieve network virtualization, a network controller must configure the hypervisor hostswitches with network flow tables that form the logical broadcast domains the tenant administrators defined when they created and configured their logical switches.

Each logical broadcast domain is implemented by tunneling VM-to-VM traffic and VM-to-logical router traffic using the tunnel encapsulation mechanism Geneve. The network controller has the global view of the data center and ensures that the hypervisor hostswitch flow tables are updated as VMs are created, moved, or removed.

NSX Manager

Node that hosts the API services, the management plane, and the agent services.

Open vSwitch (OVS)

Open source software switch that acts as a hypervisor hostswitch within XenServer, Xen, KVM, and other Linux-based hypervisors. NSX Edge switching components are based on OVS.

Overlay Logical Network

Logical network implemented using Layer 2-in-Layer 3 tunneling such that the topology seen by VMs is decoupled from that of the physical network.

Physical Interface (pNIC)

Network interface on a physical server that a hypervisor is installed on.

Tier-0 Logical Router

Provider logical router is also known as Tier-0 logical router interfaces with the physical network. Tier-0 logical router is a top-tier router and can be realized as active-active or active-standby cluster of services router. The logical router runs BGP and peers with physical routers. In active-standby mode the logical router can also provide stateful services.

Tier-1 Logical Router

Tier-1 logical router is the second tier router that connects to one Tier-0 logical router for northbound connectivity and one or more overlay networks for southbound connectivity. Tier-1 logical router can be an active-standby cluster of services router providing stateful services.

Transport Zone

Collection of transport nodes that defines the maximum span for logical switches. A transport zone represents a set of similarly provisioned hypervisors and the logical switches that connect VMs on those hypervisors. NSX-T can deploy the required supporting software packages to the hosts because it knows what features are enabled on the logical switches.

VM Interface (vNIC)

Network interface on a virtual machine that provides connectivity between the virtual guest operating system and the standard vSwitch or vSphere distributed switch. The vNIC can be attached to a logical port. You can identify a vNIC based on its Unique ID (UUID).

TEP

Tunnel End Point. Tunnel endpoints enable hypervisor hosts to participate in an NSX-T overlay. The NSX-T overlay deploys a Layer 2 network on top of an existing Layer 3 network fabric by encapsulating frames inside of packets and transferring the packets over an underlying transport network. The underlying transport network can be another Layer 2 networks or it can cross Layer 3 boundaries. The TEP is the connection point at which the encapsulation and decapsulation takes place.

 

Module 2 - Host Preparation and Logical Switching (45 minutes)

Host Preparation and Logical Switching - Module Overview


The goal of this lab is to demonstrate how to prepare hosts for NSX-T and configure Logical Switching.


Preparing KVM Hosts for NSX-T


In this section we will be:

  1. Adding a KVM host to NSX-T
  2. Reviewing the configuration of Uplink Profiles
  3. Reviewing the configuration of IP Pools
  4. Reviewing the configuration of Transport Zones
  5. Creating a Transport Node for the KVM host
  6. Verifying TEP creation on the KVM host

 

Launch Google Chrome

 

 

 

Open NSX-T Web Interface

 

Unlike NSX-V, which uses a vSphere Web Client plugin for administering NSX, NSX-T leverages a separate web interface for administration.

 

 

Login to the NSX-T Web Interface

 

Login to the NSX-T web interface using the following steps:

  1. In the User name field type admin
  2. In the Password field type VMware1!
  3. Click Login

 

 

Navigate to Hosts in the NSX-T UI

 

 

 

Add KVM Host to NSX-T

 

 

 

Add KVM Host to NSX-T

 

Enter the following information into the Add Host window:

  1. In the Name field, enter kvm-02a.corp.local
  2. In the IP Addresses field, enter 192.168.110.62
  3. In the Operating System field, select Ubuntu KVM from the drop-down
  4. In the Username field, enter vmware
  5. In the Password field, enter VMware1!
  6. Click Save

 

 

Add KVM Host to NSX-T

 

After click Save in the previous step, an error will pop-up warning about an invalid thumbprint.

 

 

Add KVM Host to NSX-T

 

After a few minutes the installation of the NSX-T software on the KVM will complete and and the deployment status should say "Installation Successful"

 

 

 

  1. Under the Fabric section in the menu on the left side of the NSX-T user interface, click Profiles
  2. Under the Uplinks Profiles tab of the Profiles section, click nsx-default-uplink-hostswitch-profile

 

 

 

Note the following configuration of the nsx-default-uplink-hostswitch-profile Uplink Profile:

 

 

Verify IP Pool Configuration

 

  1. Click Inventory in the menu on the left side of the NSX-T user interface
  2. Under the Inventory menu, click Groups
  3. Click the IP Pools tab
  4. Under the IP Pools tab of the Groups section, click the checkbox next to TEP-KVM-POOL
  5. Click Edit

 

 

Verify IP Pool Configuration

 

Note the following configuration of the TEP-KVM-Pool IP Pool:

  1. Click Cancel

 

 

Verify Overlay Transport Zone Configuration

 

  1. Click Fabric in the menu on the left side of the NSX-T user interface
  2. Under the Fabric menu, click Transport Zones
  3. Under the Transport Zones tab, click TZ_OVERLAY
    • NOTE: Click the name of the Transport Zone, NOT the checkbox next to the name

 

 

Verify Overlay Transport Zone Configuration

 

Note the following configuration of the TZ_OVERLAY Transport Zone:

 

 

Create Transport Node for KVM Host

 

  1. Click Fabric in the menu on the left side of the NSX-T user interface
  2. Under the Fabric menu, click Nodes
  3. Click the Transport Nodes tab
  4. Click Add

 

 

Create Transport Node for KVM Host

 

Enter the following details in the Add Transport Node window:

  1. Name: KVM-TN2
  2. Node: Select kvm-02a.corp.local - 192.168.110.62
  3. Transport Zones: Selcect TZ_OVERLAY
  4. Host Switch Type: Select Standard

Continue to the next step to continue configuring the Transport Node.

 

 

Create Transport Node for KVM Host

 

Enter the following details in the Add Transport Node window:

  1. Host Switch Name: hostswitch1
  2. Uplink Profile: Select nsx-default-uplink-hostswitch-profile
  3. IP Assignment: Select Use IP Pool
  4. IP Pool: Select TEP-KVM-Pool
  5. Physical NICs: Select eth1 and uplink-1, respectively
  6. Click Save

 

 

Create Transport Node for KVM Host

 

Under the Transport Node tab, verify the new Transport Node has been added to the table and say Success under the State column:

 

 

Open Putty

 

  1. Click on the PuTTY icon in the Windows menu bar to open PuTTY

 

 

Open SSH session to kvm-02a

 

  1. Select kvm-02a.corp.local
  2. Click Open

 

 

Log into kvm-02a

 

Type vmware at the login prompt and press Enter

  1. login as: vmware

 

 

Verify TEP creation on kvm-02a

 

  1. Enter ifconfig nsx-vtep0.0 into the command-line on kvm-02a to see that the TEP interface has been created with an IP address of 192.168.130.62 and an MTU of 1600.
ifconfig nsx-vtep0.0

 

 

Verify connectivity between TEP interfaces of kvm-02a and kvm-01a

 

  1. The IP address of the TEP interface on kvm-02a is 192.168.130.62, and the IP address of kvm-01a is 192.168.130.61. To verify connectivity between these interfaces, ping the TEP interface of kvm-01a from kvm-02a by typing ping 192.168.130.61 -c 2 to only send two pings.
ping 192.168.130.61 -c 2

 

Logical Switching in NSX-T


In this lesson we will be:

  1. Creating a logical switch in NSX-T
  2. Attaching the logical switch to an NSX-T edge router
  3. Attaching an ESXi virtual machine to the logical switch
  4. Verifying connectivity to the ESXi virtual machine from the main console
  5. Attaching a KVM virtual machine to the logical switch
  6. Verifying connectivity to the KVM virtual machine from the main console
  7. Verifying connectivity between the ESXi and KVM virtual machines on the same logical switch

 

Create a new Logical Switch

 

From the NSX-T Manager web interface:

  1. Click Switching
  2. Click Switches
  3. Click Add

 

 

Create a new Logical Switch

 

Input the following details in the New Logical Switch window:

  1. Name: LS-WEB02
  2. Transport Zone: TZ_OVERLAY
  3. Admin State: Up
  4. Replication Mode: Hierarchical Two-Tier replication
  5. Click Save

 

 

Verify Logical Switch Creation

 

 

 

Attach new Logical Switch to a Logical Router

 

  1. Click Routing
  2. Click Routers
  3. Click LogicalRouter-Tier0

 

 

Attach new Logical Switch to a Logical Router

 

  1. Click Configuration
  2. Click Router Ports

 

 

Attach new Logical Switch to a Logical Router

 

  1. Click Add

 

 

Attach new Logical Switch to a Logical Router

 

Input the following details in the New Router Port window:

  1. Name: downlink-to-LS-WEB02
  2. Type: Downlink
  3. Logical Switch: LS-WEB02
  4. Logical Switch Port: Attach to new switch port
  5. Switch Port Name: Tier0-WEB02-Port
  6. IP Address/mask: 172.16.40.1/24
  7. Click Save

 

 

Verify Logical Router Port Creation

 

 

 

Open Command Prompt

 

Open the Command Prompt:

  1. Click the Start Menu icon
  2. Click Command Prompt

 

 

Verify Connectivity to LS-WEB02 Gateway

 

  1. In the Command Prompt window, ping the gateway previously created for the LS-WEB02 Logical Switch:
ping 172.16.40.1

 

 

Open vCenter Web Client

 

  1. Right Click vcsa-01a in the Bookmarks Bar in Chrome
  2. Click Open in new tab

 

 

Open vCenter Web Client

 

  1. Click vSphere Web Client (Flash)

 

 

Log In to vCenter Web Client

 

  1. For the username enter administrator@vsphere.local
  2. For the password enter VMware1!
  3. Click Login

 

 

Edit Virtual Machine Settings for web-03a

 

  1. Select web-03a
  2. Click Actions
  3. Click Edit Settings...

 

 

Connect web-03a to LS-WEB02

 

  1. From the dropdown for Network adapter 1, select LS-WEB02
  2. Click OK

 

 

Power On web-03a

 

  1. Click Actions
  2. Click Power
  3. Click Power On

 

 

Wait for web-03a to Power On

 

 

 

Verify Connectivity to web-03a

 

  1. Verify connectivity to web-03a by pinging its IP address from the command prompt window previously opened
ping 172.16.40.13

 

 

Open PuTTY

 

  1. Click the Start Menu icon
  2. Click PuTTY

 

 

Connect to kvm-02a

 

  1. Select kvm-02a.corp.local in the Saved Sessions in PuTTY
  2. Click Open

 

 

Log Into kvm-02a

 

  1. Log into kvm-02a with the username vmware. If prompted, use VMware1! as the password

 

 

Show virtual machines running on kvm-02a

 

  1. List the virtual machines running on kvm-02a using the following command:
virsh list

Note the name of the virtual machine listed on kvm-02a, web-04a

 

 

Get Interface ID of web-02a

 

  1. Get the interfaceid of web-04a by typing the following command into the shell:
virsh dumpxml web-04a | grep interfaceid

Note the value of the interface ID being returned: 0124748e-c05b-425e-8441-7e51d31ddb42

 

 

Connect web-04a to LS-WEB02 Logical Switch

 

From the NSX-T Manager web interface:

  1. Click Switching
  2. Click Ports
  3. Click Add

 

 

Connect web-04a to LS-WEB02 Logical Switch

 

Input the following details in the New Logical Port window:

  1. Name: web-04a
  2. Logical Switch: LS-WEB02
  3. Attachment Type: VIF
  4. Attachment ID: 0124748e-c05b-425e-8441-7e51d31ddb42 (select and drag the contents of the code block below into the window instead of typing out the entire value):
0124748e-c05b-425e-8441-7e51d31ddb42
  1. Click Save

 

 

Verify creating of web-04a Logical Switch Port

 

 

 

Verify connectivity to web-04a

 

  1. Verify connectivity to web-04a by pinging its IP address from the command prompt window previously opened
ping 172.16.40.14

 

 

Open PuTTY

 

  1. Click the Start Menu icon
  2. Click PuTTY

 

 

Connect to web-03a

 

  1. Select web-03a.corp.local in the Saved Sessions in PuTTY
  2. Click Open

 

 

Accept Security Alert

 

  1. If prompted, click Yes to accept the security alert when connecting to web-03a

 

 

Log into web-03a

 

  1. Log into web-03a with the username root

 

 

Verify Connectivity between web-03a and web-04a

 

  1. From the shell of web-03a, ping web-04a
ping 172.16.40.14 -c 2

 

Module 2 Conclusion


Congratulations on completing Module 2!


Module 3 - Logical Routing (60 minutes)

Logical Routing - Module Overview


The goal of this lab is to demonstrate the Logical Routing capabilities of NSX-T


 

Logical Routing Topology

 

 

Logical Routing of East-West Traffic


In this lesson we will configure Logical Routing of East-West traffic in NSX-T.


 

Open Google Chrome Browser

 

  1. From the Desktop, double-click on the Google Chrome icon to open the Chrome Browser

 

 

Open NSX-T Manager

 

  1. From the Bookmarks Toolbar, click nsxmgr-01a to open the NSX-T Manager

 

 

Log Into NSX-T Manager

 

Log Into the NSX-T Manager with the following credentials:

  1. User name: admin
  2. Password: VMware1!
  3. Click Login

 

 

 

  1. Click Routing
  2. Click Routers
  3. Click LogicalRouter-Tier0

 

 

 

  1. Click Configuration
  2. Click Router Ports

 

 

 

  1. Click the checkbox next to downlink-to-LS-APP
  2. Click the checkbox next to downlink-to-LS-DB
  3. Click the checkbox next to downlink-to-LS-WEB
  4. Click Delete

 

 

 

  1. Click Delete when prompted to confirm deleting these three Logical Router Ports

 

 

 

 

 

Create new Tier-1 Router

 

  1. Click the + (Plus) button
  2. Click Tier-1 Rotuer

 

 

Create new Tier-1 Router

 

  1. In the Name field, enter LogicalRouter-Tier1
  2. Click Save

 

 

Verify Creation of New Tier-1 Router

 

 

 

Connect Logical Switches to Tier-1 Router

 

  1. Click LogicalRouter-Tier1
  2. Click Configuration
  3. Click Router Ports

 

 

Connect Logical Switches to Tier-1 Router

 

  1. Click Add

 

 

Connect Logical Switches to Tier-1 Router

 

Enter the following information into the New Router Port window to create the router port for the Web network:

  1. Name: Tier1-Web
  2. Logical Switch: LS-WEB
  3. Switch Port Name: Tier1-Web-Port
  4. IP Address/mask: 172.16.10.1/24
  5. Click Save

 

 

Connect Logical Switches to Tier-1 Router

 

Repeat the previous step to create the router port for the App network with the following information:

  1. Name: Tier1-App
  2. Logical Switch: LS-APP
  3. Switch Port Name: Tier1-App-Port
  4. IP Address/mask: 172.16.20.1/24
  5. Click Save

 

 

Connect Logical Switches to Tier-1 Router

 

Repeat the previous step to create the router port for the DB network with the following information:

  1. Name: Tier1-DB
  2. Logical Switch: LS-DB
  3. Switch Port Name: Tier1-DB-Port
  4. IP Address/mask: 172.16.30.1/24
  5. Click Save

 

 

Verify Configuration of Logical Router Ports

 

 

 

Open vSphere Web Client

 

  1. Right-click vcsa-01a in the Bookmarks Toolbar
  2. Click Open in new tab

 

 

Open vSphere Web Client

 

  1. Click vSphere Web Client (Flash)

 

 

Log Into vSphere Web Client

 

Log into the vSphere Web Click with the following credential:

  1. User name: administrator@vsphere.local
  2. Password: VMware1!
  3. Click Login

 

 

Open Console of web-01a

 

  1. Select web-01a
  2. Click Actions
  3. Click Open Console

 

 

Verify Routing of East-West Traffic

 

  1. Log into web-01a with the following credentials:

 

 

Verify Routing of East-West Traffic

 

From the console of web-01a, ping the gateway IP addresses of the previously created Logical Router Ports:

  1. Ping the gateway of the Web network:
ping 172.16.10.1 -c 2
  1. Ping the gateway of the App network:
ping 172.16.20.1 -c 2
  1. Ping the gateway of the DB network:
ping 172.16.30.1 -c 2

NOTE: Press CTRL+ALT to remove keyboard and mouse focus from the VMware Remote Console

 

 

Verify Routing of East-West Traffic

 

From the console of web-01a, ping the other virtual machines in the 3-tier application:

  1. Ping web-02a
ping web-02a -c 2
  1. Ping app-01a
ping app-01a -c 2
  1. Ping db-01a
ping db-01a -c 2

 

 

Open Command Prompt

 

  1. Click the Start Menu icon in the task bar
  2. Click Command Prompt

NOTE: Press CTRL+ALT to remove keyboard and mouse focus from the VMware Remote Console

 

 

Test Connectivity From Main Console

 

From the Command Prompt, verify you are unable to ping the gateway IP addresses of the logical networks. Enabling these connections will be done in the next section:

  1. Ping the gateway of the Web network:
ping 172.16.10.1
  1. Ping the gateway of the App network:
ping 172.16.20.1
  1. Ping the gateway of the DB network:
ping 172.16.30.1

 

Logical Routing of North-South Traffic


In this lesson we will configure Logical Routing of North-South traffic.


 

 

  1. Click Fabric
  2. Click Profiles
  3. Click Uplink Profiles
  4. Click nsx-edge-uplink-hostswitch-profile

 

 

 

Verify the following configuration used for the Uplink Profile:

 

 

 

Verify Transport Zones Configuration

 

  1. Click Transport Zones
  2. Click TZ_VLAN

 

 

Verify Transport Zones Configuration

 

Verify the following configuration used by the Transport Zone TZ_VLAN:

 

 

Verify Edge Node Configuration

 

  1. Click Nodes
  2. Click Edges
  3. Click edge-01a.corp.local

 

 

Verify Edge Node Configuration

 

Verify the following configuration used by the Edge Node edge-01a.corp.local:

 

 

Verify Transport Node Configuration

 

  1. Click Transport Nodes
  2. Click the checkbox next to EDGE-TN1
  3. Click Edit

 

 

Verify Transport Node Configuration

 

Verify the following configuration used by the Transport Node EDGE-TN1:

Name: EDGE-TN1

Transport Zones:

Host Switch Type: Standard

hostswitch1:

 

 

Verify Transport Node Configuration

 

Verify the following configuration used by the Transport Node EDGE-TN1:

hostswitch2:

  1. Click Cancel

 

 

Verify Edge Cluster Configuration

 

  1. Click Edge Clusters
  2. Under the Transport Nodes column, click the number 1 for the Edge Cluster EdgeCluster1

 

 

Verify Edge Cluster Configuration

 

 

 

 

  1. Click Switching
  2. Click Switches
  3. Click LS-Uplink

 

 

 

Verify the following configuration of the Logical Switch LS-Uplink:

 

 

Verify BGP Configuration on Tier-0 Logical Router

 

  1. Click Routing
  2. Click Routers
  3. Click LogicalRouter-Tier0

 

 

Verify BGP Configuration on Tier-0 Logical Router

 

  1. Click Routing
  2. Click BGP

 

 

Verify BGP Configuration on Tier-0 Logical Router

 

Note the current configuration on the Tier-0 Logical Router for BGP:

 

 

Connect Tier-1 Logical Router to Tier-0 Logical Router

 

  1. Click the checkbox next to LogicalRouter-Tier1
  2. Click Actions
  3. Click Connect to Tier-0 Router

 

 

Connect Tier-1 Logical Router to Tier-0 Logical Router

 

  1. Selection LogicalRouter-Tier0 from the dropdown menu
  2. Click Connect

 

 

Verify Connection Between Tier-1 Logical Router and Tier-0 Logical Router

 

 

 

Verify Connection Between Tier-1 Logical Router and Tier-0 Logical Router

 

  1. Click LogicalRouter-Tier0
  2. Click Configuration
  3. Click Router Ports

 

 

Verify Connection Between Tier-1 Logical Router and Tier-0 Logical Router

 

 

 

Advertise Routes Between Tier-1 Logical Router and Tier-0 Logical Router

 

  1. Click LogicalRouter-Tier1
  2. Click Routing
  3. Click Route Advertisement

 

 

Advertise Routes Between Tier-1 Logical Router and Tier-0 Logical Router

 

  1. Click Edit

 

 

Advertise Routes Between Tier-1 Logical Router and Tier-0 Logical Router

 

  1. Set Status to Enabled
  2. Set Advertise All NSX Connected Routes to Yes
  3. Click Save

 

 

Advertise Routes Between Tier-1 Logical Router and Tier-0 Logical Router

 

 

 

Redistributed NSX Static Routes on Tier-0 Logical Router

 

  1. Click LogicalRouter-Tier0
  2. Click Routing
  3. Click Route Redistribution

 

 

Redistributed NSX Static Routes on Tier-0 Logical Router

 

 

 

Open Command Prompt

 

  1. Click the Start Menu icon in the Windows Task Bar
  2. Click Command Prompt

 

 

Verify Connectivity from Main Console to Virtual Machines

 

  1. Verify connectivity to web-01a by trying to ping it in the command prompt:
ping web-01a
  1. Verify connectivity to app-01a by trying to ping it in the command prompt:
ping app-01a
  1. Verify connectivity to db-01a by trying to ping it in the command prompt:
ping db-01a

 

High Availability (HA)


In this lesson we will configure High Availability (HA) for Logical Routers in NSX-T.


 

Locate edge-02a.corp.local in NSX-T Manager

 

  1. Click Fabric
  2. Click Nodes
  3. Click Edges
  4. Locate edge-02a.corp.local
    • Note the current MPA Connectivity state of Down

 

 

Power On edge-02a Virtual Machine

 

In the vSphere Web Client:

  1. Select edge-02a
  2. Click Actions
  3. Click Power
  4. Click Power On

 

 

Verify MPA Connectivity of edge-02a.corp.local

 

It may take a few minutes for edge-02a.corp.local to connect to the NSX-T Manager. To verify it has connected:

  1. Click the refresh button at the bottom of the page for the Edges

 

 

Create Transport Node

 

  1. Click Transport Nodes
  2. Click Add

 

 

Create Transport Node

 

Enter the following details into the Add Transport Node window:

  1. Name: EDGE-TN2
  2. Node: edge-02a.corp.local - 192.168.110.38
  3. Transport Zones:
    • TZ_OVERLAY
    • TZ_VLAN

Continue to the next step to continue adding additional configuration parameters.

 

 

Create Transport Node

 

Enter the following details into the Add Transport Node window:

  1. Edge Switch Name: hostswitch1
  2. Uplink Profile: nsx-edge-uplink-hostswitch-porfile
  3. IP Assignment: Use IP Pool
  4. IP Pool: TEP-ESX-Pool
  5. Virtual NICs:
    • fp-eth0
    • uplink-1
  6. Click Add New Node Switch

Continue to the next step to continue adding additional configuration parameters.

 

 

Create Transport Node

 

Enter the following details into the Add Transport Node window:

  1. Edge Switch Name: hostswitch2
  2. Uplink Profile: nsx-edge-uplink-hostswitch-porfile
  3. Virtual NICs:
    • fp-eth1
    • uplink-1
  4. Click Save

Continue to the next step to continue adding additional configuration parameters.

 

 

Verify Createion of Edge Transport Node

 

 

 

Add Transport Node to Edge Cluster

 

  1. Click Edge Clusters
  2. Select the checkbox next the EdgeCluster1
  3. Click Edit

 

 

Add Transport Node to Edge Cluster

 

  1. Click Edit...

 

 

Add Transport Node to Edge Cluster

 

  1. Select the checkbox next to EDGE-TN2
  2. Click the arrow the add EDGE-TN2 to the list of selected Transport Nodes
  3. Click Ok

 

 

Add Transport Node to Edge Cluster

 

  1. Verify the list of Transport Nodes includes both EDGE-TN1 and EDGE-TN2
  2. Click Save

 

 

Verify Configuration Status of edge-02a.corp.local

 

  1. Click Edges

 

 

 

  1. Click Routing
  2. Click Routers
  3. Click LogicalRouter-Tier0

 

 

 

  1. Click Configuration
  2. Click Router Ports

 

 

 

  1. Click Add

 

 

 

Enter the following parameters into the New Router Port window:

  1. Name: Uplink2
  2. Type: Uplink
  3. Transport Node: EDGE-TN2
  4. Logical Switch: LS-Uplink
  5. Logical Switch Port:
    • Attach to new switch port
    • Switch Port Name: uplink2-port
  6. IP Address/mask: 192.168.100.4/24
  7. Click Save

 

 

 

 

 

Open PuTTY

 

  1. Click the Start Menu button in the Windows Task Bar
  2. Click PuTTY

 

 

Connect to edge-02a.corp.local

 

  1. Select edge-02a.corp.local from the Saved Sessions list in PuTTY
  2. Click Open

 

 

Log Into edge-02a.corp.local

 

Log into edge-02a.corp.local with the following credentials:

  1. Username: admin
  2. Password: VMware1!

 

 

List Logical Routers Connected to edge-02a.corp.local

 

  1. Get a list of Logical Routers connected to edge-02a by running the following command:
get logical-routers
  1. Note the vrf number of the Logical Router of type SERVICE_ROUTER_TIER0

NOTE: The vrf number of SERVICE_ROUTER_TIER0 may be different from what's in the screenshot.

 

 

Verify BGP Neighbor Relationship with Upstream Router

 

  1. Enter the vrf routing context on the edge by entering the following command (NOTE: Replace "3" in the command below with the vrf number found in the previous step):
vrf 3
  1. Get the BGP neighbor status by running the following command:
get bgp neighbor
  1. Verify the neighbor relationship with 192.168.100.1 is showing a status of Established, up

 

Equal Cost Multi-Pathing (ECMP)


In this lesson we will configure Equal Cost Multi-Pathing (ECMP).


 

Delete Unused Logical Routers Connected to LogicalRouter-Tier0

 

  1. Click Routing
  2. Click Routers
  3. Select the checkboxes next to the three Logical Routers whose names start with "k8s-c1-lr-"
  4. Click Delete

 

 

Disconnect Tier-1 Logical Router from Tier-0 Logical Router

 

  1. Select the checkbox next to LogicalRouter-Tier1
  2. Click Actions
  3. Click Disconnect from Tier-0 Router

 

 

Disconnect Tier-1 Logical Router from Tier-0 Logical Router

 

 

 

Delete LogicalRouter-Tier0

 

  1. Select the checkbox next to LogicalRouter-Tier0
  2. Click Delete

 

 

Delete LogicalRouter-Tier0

 

 

 

Verify Deletion of Tier-0 Logical Router

 

 

 

Add Active-Active Tier-0 Logical Router

 

  1. Click Add
  2. Click Tier-0 Router

 

 

Add Active-Active Tier-0 Logical Router

 

Enter the following configuration parameters in the New Tier-0 Router window:

  1. Name: LogicalRouter-Tier0-ECMP
  2. Edge Cluster: EdgeCluster1
  3. High Availability Mode: Active-Active
  4. Click Save

 

 

Add Ports to Tier-0 Logical Router

 

 

 

Add Ports to Tier-0 Logical Router

 

  1. Click Configuration
  2. Click Router Ports

 

 

Add Ports to Tier-0 Logical Router

 

 

 

Add Ports to Tier-0 Logical Router

 

Enter the following configuration details in the New Router Port window:

  1. Name: Uplink1
  2. Type: Uplink
  3. Transport Node: EDGE-TN1
  4. Logical Switch: LS-Uplink
  5. Logical Switch Port: Attach to existing switch port
    • Switch Port Name: uplink1-port
  6. IP Address/mask: 192.168.100.3/24
  7. Click Save

 

 

Add Ports to Tier-0 Logical Router

 

Add an additional port using the following configuration details in the New Router Port window:

  1. Name: Uplink2
  2. Type: Uplink
  3. Transport Node: EDGE-TN2
  4. Logical Switch: LS-Uplink
  5. Logical Switch Port: Attach to existing switch port
    • Switch Port Name: uplink2-port
  6. IP Address/mask: 192.168.100.4/24
  7. Click Save

 

 

Verify Creation of Logical Router Ports

 

 

 

Configure BGP on Tier-0 Logical Router

 

  1. Click Routing
  2. Click BGP

 

 

Configure BGP on Tier-0 Logical Router

 

 

 

Configure BGP on Tier-0 Logical Router

 

Enter the following configuration details in the Edit BGP Configuration window:

  1. Status: Enabled
  2. ECMP: Enabled
  3. Local AS: 65001
  4. Click Save

 

 

Configure BGP on Tier-0 Logical Router

 

  1. Verify BGP and ECMP are set to Enabled and that the Local AS is set to 65001
  2. Click Add

 

 

Configure BGP on Tier-0 Logical Router

 

Enter the following configuration details in the New Neighbor window:

  1. Neighbor Address: 192.168.100.1
  2. Remote AS: 65002
  3. Click Add
  4. State: Enabled
  5. Click Save

 

 

Verify BGP Configuration on Tier-0 Logical Router

 

  1. Verify the configuration of the new BGP neighbor
  2. Click Routing
  3. Click Route Redistribution

 

 

Configure Route Redistribution on Tier-0 Logical Router

 

 

 

Configure Route Redistribution on Tier-0 Logical Router

 

  1. Set Status to Enabled
  2. Click Save

 

 

Configure Route Redistribution on Tier-0 Logical Router

 

  1. Verify Status is set to Enabled
  2. Click Add

 

 

Configure Route Redistribution on Tier-0 Logical Router

 

Enter the following configuration details into the New Redistribution Criteria window:

  1. Name: RouteDistro
  2. Sources: NSX Static
  3. Click Save

 

 

Verify Route Redistribution Configuration on Tier-0 Logical Router

 

  1. Verify the configuration of the Route Redistribution Criteria
  2. Click the X in the upper right corner of the panel

 

 

Connect Tier-1 Logical Router to Tier-0 Logical Router

 

  1. Select the checkbox next to LogicalRouter-Tier1
  2. Click Actions
  3. Click Connect to Tier-0 Router

 

 

Connect Tier-1 Logical Router to Tier-0 Logical Router

 

  1. Select LogicalRouter-Tier0-ECMP from the dropdown list
  2. Click Connect

 

 

Verify Connection Between Tier-0 and Tier-1 Logical Routers

 

 

 

Locate Tier-0 Router ID in NSX-T Interface

 

  1. Click LogicalRouter-Tier0-ECMP
  2. Click Summary
  3. Note the ID listed under the Summary. You will need to reference this in a later step

NOTE: The ID listed will NOT match the ID shown in the picture

 

 

Open PuTTY

 

  1. Click the Start Menu icon in the Windows Task Bar
  2. Click PuTTY

 

 

Connect to esx-01a.corp.local

 

  1. Select esx-01a.corp.local from the Saved Sessions list in PuTTY
  2. Click Open

 

 

Launch the NSX CLI from esx-01a.corp.local

 

You shold automatically be logged into esx-01a.corp.local. If you are not automatically logged in, use the following credentials to log in:

  1. Launch the NSX CLI from the command line by entering the following command:
nsxcli
  1. Maximize the window by clicking the square in the upper right hand corner of the window.

 

 

Verify ECMP Configuration on esx-01a.corp.local

 

  1. Enter the following command to get a list of the Logical Routers connected to esx-01a.corp.local:
get logical-router
  1. Locate the Router ID of the Tier-0 Logical Router found in a previous step, then select the Router ID in PuTTY to copy it to your clipboard
  2. Enter the following command to get the routes associated with the Tier-0 Logical Router, using the right mouse button to paste the Router ID from the clipboard into the command:
get logical-router <Router ID> routes
  1. Note the presences of two default routes in the routing table. Each route is being sourced from a different edge transport node in the Edge Cluster. Also note the E listed under the Flags column, which indicates these routes are using ECMP.

 

Module 3 Conclusion



 

You've finished Module 3

 

Congratulations on completing  Module 3.

 

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 4 - DHCP and NAT (30 minutes)

DHCP and NAT - Module Overview



 

DHCP and NAT with NSX-T

The goal of this lab is to demonstrate the DHCP server and NAT capabilities.

 

Configuring Dynamic Host Configuration Protocol (DHCP)



 

Getting started with DHCP

 

If you still have your browser open to the NSX Manager please skip the following steps. Otherwise perform the following steps.

  1. Click on the Google Chrome link on the desktop

 

 

Select Favorite for NSX Manager

 

  1. Click on the nsx-mgr-01a link in the bookmark bar

 

 

NSX Manager Login

 

Enter the following login credentials for the NSX Manager.

  1. User name: admin
  2. Password: VMware1!
  3. Click on Login

 

 

Create new Logical Switch

 

We need to create a new Logical Switch for this lab that will leverage the DHCP server we create later.  To create a new logical switch, perform the following tasks.

  1. Click on Switching
  2. Click on Switching (if it doesn't default to that tab)
  3. Click on the +Add link.

 

 

New Logical Switch

 

Now to name the switch and pick the Transport Zone.  Perform the following.

  1. Name:  LS-NAT-Web
  2. Transport Zone: Select TZ_Overlay
  3. Click on the Save button

 

 

New LS created

 

 

 

DHCP server

 

Now to create a new DHCP server

  1. Click on DHCP on the left hand side
  2. Click on Server Profiles if not defaulted to that tab
  3. Click on the +Add button

 

 

Creating DHCP Server Profile

 

Now to provide details on the DHCP server profile.

  1. Name: DHCP Profile
  2. Edge Cluster: Select EdgeCluster1
  3. Click on the Save button

 

 

Validate DHCP Server Profile created

 

  1. You will now see your newly created DHCP Profile listed.  Notice that server number is 0. We will change that in the next steps.

 

 

DHCP Server Creation

 

We will now create a new DHCP server.

  1. Click on the Servers tab
  2. Click on the +Add link

 

 

DHCP Server Settings

 

Fill in the following information.

  1. In the pop-­up, enter name: NAT-­Web DHCP Server
  2. IP Address/mask: 172.16.50.2/24
  3. Profile, select: DHCP Profile
  4. Domain Name: corp.local
  5. Default Gateway: 172.16.50.1
  6. DNS Server: 192.168.110.10
  7. Subnet Mask: 255.255.255.0
  8. Click Save

 

 

DHCP server created

 

You now see your newly created DHCP Server.   Now to add IP pools.

  1. Click on your newly created DHCP Server - NAT-Web DHCP Server

 

 

DHCP Pools

 

On the summary pop up you will find information about the DHCP server you created.  We need to add an IP Pool to the server.

  1. Click on the arrow next to IP Pool to open up that section
  2. Click on the +Add link

 

 

DHCP IP Pool Info

 

Now to provide IP Pool information.

  1. Name: NAT-Web Pool1
  2. IP Ranges: 172.16.50.101-172.16.50.110
  3. Default Gatway: 172.16.50.1
  4. Click on Save

 

 

Validate your new IP Pool

 

The newly created IP Pool will now show up in the IP Pools section of your DHCP server

 

 

Attach DHCP Server to Logical Switch

 

Now, you are going to attach the new DHCP server to the Logical switch you created earlier.

  1. Click on Switching on the left hand side
  2. Click on the Switches Tab if not defaulted to it
  3. Select the LS-NAT-Web logical switch
  4. Click on Actions
  5. Click on Attach DHCP Server

 

 

Attach DHCP Server selecting

 

  1. Select the NAT-Web DHCP server from the pull down list.
  2. Click Save

 

 

Log into vCenter

 

We now need to go into vCeneter.

  1. Click to open a new tab
  2. Click on vcsa-01a

 

 

vCenter Flash Client

 

  1. Click on the vSphere Web Client (Flash)

 

 

Login to vCenter

 

  1. Select the "Use Windows session authentication"
  2. Click Login

 

 

Edit settings of web-03a

 

We are now going to attach the new Logical switch that is attached to the DHCP server. In order to attach the guest to the logical switch.

  1. Select web-03a
  2. Click on Actions
  3. Select Edit Settings

 

 

Change the network settings

 

  1. If showing connected, uncheck the Connect button next to Network adapter 1
  2. Change the attached network for Network Adapter 2 to LS-NAT-WEB (nsx-LogicalSwitch)
  3. Click on the Connect check box
  4. Click OK

 

 

Power on Web-03a

 

Now that you are back on the VM Summary page, lets power on the VM.

  1. First, make sure that LS-NAT-Web is showing as the network connected to Network Adapter 2
  2. Click on Power on VM
  3. Click on the Remote Console icon to open remote console to the machine

 

 

Login to web-03a

 

We will now log into the VM and test if DHCP works.

  1. Login name: root Password: VMware1!
  2. Type
ifconfig

This will list all of the interfaces on the VM. Look for eth1. You should see that the IP on the VM is 172.16.50.101.

This means that DHCP is working as planned.

If eth0 shows up in the list, we need to shut it down.  

 

 

Shutting down eth0 if needed

 

  1. If eth0 showed up in the list of interfaces, type the following command
ifconfig eth0 down
  1. To verify that it worked type
ifconfig

You should not see eth0 in the list any more.

Next we will cover NAT with NSX-T.

 

Configuring Network Address Translation (NAT)


In this chapter, we will create a new Router and enable and configure NAT. This NAT will allow access to the internal web servers from a Natted address.


 

New Tier-1 Router

 

Click back to your NSX Manager Tab

  1. Click on Routing on the left hand side
  2. Click on Routers if you don't default to that screen
  3. Click on the +Add link
  4. Click on Tier-1 Router

 

 

Tier-1 Router config

 

Enter the following information:

  1. Name: LogicalRouter-T1-NAT
  2. Tier-0 Router: Select LogicalROuter-Tier0
    • NOTE: If you already completed the ECMP lesson of Module 3 - Logical Routing, select "LogicalRouter-Tier0-ECMP" instead.
  3. Edge Cluster: EdgeCluster1
  4. Edge Cluster Members: Edge-TN1
  5. Preferred Member: Edge-TN1
  6. Click Save

 

 

Check for your new Router

 

You will now see you new Logical Router in the list.

  1. Select your new router: LogicalRouter-T1-NAT

 

 

Router Ports

 

With the LogicalRouter-T1-NAT selected perform the following tasks:

  1. Click on the Configuration tab
  2. Click on Router Ports

 

 

Adding a port

 

You can see that the router is already pre-configured to the uplink to the Tier0 router

  1. Click on the +Add link to add a new port to your LogicalRouter-t1-NAT

 

 

Router Port

 

Now enter the following information and configuration items for the router port:

  1. Name: Connection-to-NAT-Web
  2. Logical switch:  LS-NAT-Web
  3. Logical Switch Port: Attach to new switch port
  4. Switch Port Name: NAT-Web-Port
  5. IP Address/mask: 172.16.50.1./24
  6. Click Save

 

 

New Port created

 

You will now see your new port and the settings that are configured for it.

 

 

NAT rule addition

 

  1. Click on the NAT tab
  2. Click on the +Add link to add a new NAT rule

 

 

NAT Settings

 

  1. Make sure Action is set to SNAT
  2. For Source IP enter: 172.16.50.101
  3. For Translated IP enter: 80.80.80.1
  4. Click Save

 

 

Now to add the DNAT rule

 

  1. Click on the +Add link to add a new NAT rule

 

 

DNAT Settings

 

  1. Make sure Action is set to DNAT
  2. For Destination IP enter: 80.80.80.1
  3. For Translated IP enter: 172.16.50.101
  4. Click Save

 

 

Review NAT

 

Now you see your DNAT and SNAT rules. Make sure they are correct.

Now to change the Route Advertisement

  1. Click on the Routing Tab
  2. Click on Route Advertisement

 

 

Change Route Advertisement

 

Now to change the route advertisement.

  1. Click on Edit

 

 

Change advertisement

 

Change the the following

  1. Status change to Enabled
  2. Advertise NAT Routes: Yes
  3. Click Save

 

 

Review changes

 

You should now see the changes that were made,

Review and make sure Status is now Enabled

  1. Click the X to close the window

 

 

Select Teir-0 Router

 

We now need to update the Tier-0 router for proper route redistribution

  1. Select LogicalRouter-Tier0

 

 

Route Redistribution

 

  1. Click on the Routing Tab
  2. Click on Route Redistribution

 

 

Route Distro settings

 

  1. Select RouteDistro
  2. Click on Edit

 

 

Route Distro change

 

  1. Select the new Tier-1 NAT in the Sources section
  2. Click Save

 

 

Testing the NAT

 

Now, let us test to see if the NAT rule is working.

  1. Click on the Windows Start icon
  2. Click on Command Prompt

 

 

Ping Test

 

  1. Perform the following ping test. Type the following in the command prompt window
ping 80.80.80.1

You should get a successful ping test

 

 

Web Browser Test

 

Now to perform a web test.

  1. Open a new tab
  2. Enter the following in the url window
http://80.80.80.1

You will see the successful web site message

 

Module 4 Conclusion


In thse module you learned about how DHCP and NAT can be deployed in NSX-T


 

You've finished Module 4

 

Congratulations on completing  Module 4.

Proceed to any module below which interests you most. [Add any custom/optional information for your lab manual.]

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 5 - Distributed Firewall, Spoof Guard, and Tools (45 minutes)

Distributed Firewall, Spoof Guard, and Tools - Module Overview



 

DFW, Spoof Guard, and Tools

The goal of this module is to demonstrate how the distributed firewall, Spoof Guard, and operational tools within NSX-T function and are configured.

 

Distributed Firewall


In this section, we will review and implement the Distributed Firewall (DFW) in our lab environment and see how it works on both KVM and ESXi hosts.


 

Testing for connectivity

 

First, we will connect to one of our Web VMs and test its connectivity to other VMs. Perform the following steps:

  1. Click on the Putty icon on the task bar.

 

 

Putty to web-01a

 

  1. Find and select web-01a.corp.local in the list
  2. Click on Open

 

 

Look up ifconfig information

 

Login as root.  You will not need a password.

  1. Type the following command:   
ifconfig eth0

This will respond with the address of web-01a of 172.16.10.11.   Next we will perform ping tests to multiple VMs to sure we have  connectivity.

 

 

Web ping test

 

 

  1. Ping the other web server :
ping web-02a -c 2
  1. Ping the app server:
ping app-01a -c 2
  1. Ping the database server:
ping db-01a -c 2

You will receive successful pings for each VM.

As you can see, we have the following IP addresses in use:

 

 

Web page test

 

Now to see if the website is working.

  1. Minimize your Putty session and click on the Google Chrome icon on the desktop

 

 

Website review

 

  1. Click on the web-01a link on the bookmark bar

This will take you to the web page and verify that connectivity is working between all the parts of the website.

 

 

NSX Manager

 

We need to log into the NSX Manager to configure the DFW. Perform the following steps

  1. Click on the nsx-mgr-01a link in the bookmark bar
  2. For User Name enter: admin
  3. For Password enter: VMware1!
  4. Click on Login

 

 

NSX IP Sets

 

In order for our DFW to know which machines it needs to protect, we will add the IPs of the web VMs to an IP Sets (Grouping of objects).

  1. Click on Inventory
  2. Click on Groups
  3. Click on IP Sets
  4. Click on Add

 

 

New IP Set

 

Now to name the IP set and provide the IPs of the web VMs

  1. For Name type: Web-VMs
  2. For Members enter the following 2 IPs: 172.16.10.11 & 172.16.10.12

 

 

New App and DB IP Set

 

 

Now repeat the previous steps and create IP Sets for App and DB VM: Here is the info you will need.

App-VMs with IP of 172.16.20.11

DB-VMs with IP of 172.16.30.11

 

 

Control Center IP Set

 

Lastly, we need to create a IP Set group for the Control Center machine. This is the VM from which you have been performing your work from. Here is the information you need.

Name: ControlCenter

Members: 192.168.110.10

 

 

Review the IP Sets

 

After creating all of the IP Sets, you should see your list which now include 4 different IP Sets. Double check that you have all of them created.

 

 

Firewall rule

 

The default DFW rule is to allow all traffic. Now, lets change this to deny all traffic. To perform this, perform the following steps.

  1. Click on the Firewall link on the left hand side
  2. Click on the General tab (unless you are already on that tab)
  3. Click on the lock icon
  4. Click on the Allow under Action section of the DFW rule set

 

 

Change action

 

Now to change the action of the rule. Perform the following.

  1. Under Action, click on the pull down menu and select Drop
  2. Click Ok

 

 

Save the change

 

Now to save the firewall rule change.

  1. Click on Save

 

 

Check the web site access.

 

To validate that firewall rules are working, perform the following steps.

  1. Click to open a new Tab
  2. Click on the web-01a link in the address bar

This should respond with a "This site can't be reached" error.

 

 

Create a new DFW section

 

We need to create a new section for our rules.  

Go back to the NSX Manager

  1. In the DFW firewall section,  click on the gear icon next to Default Layer3 Section
  2. Click on Insert Section Above

 

 

New DFW section config

 

Fill in the form with the following information.

  1. Section Name: Global Policy
  2. Type:  Select Logical Switch
  3. Select Logical switch LS-APP, LS-DB, LS-WEB
  4. Click on the Right arrow to move the selected Logical switches to the Selected side of the page
  5. Click Save

 

 

Add a Rule

 

Now that we have a section and logical switches that this will be applied to. We need to add a rule to the section.

  1. In the DFW firewall section,  click on the gear icon next to new Global Policy Section you just created
  2. Click on Add Rule

 

 

Filling in the Rule

 

After click on the Add Rule link, a new area of the DFW has been created. Now to fill it in.

  1. Click on the pencil icon in the Name Section

 

 

Section name

 

Fill in the following for Rule Name.

  1. Rule Name: AccessFrom.ControlCenter
  2. Click on OK

 

 

Sources

 

Now to fill in the Sources.

  1. Click on the Pencil icon in the Sources section

 

 

Sources selection

 

Selecting the sources that the firewall rule will use.

  1. Make sure that the Type is set to IP Set
  2. Select ControlCenter from the list
  3. Click on the right Arrow to move ControlCenter to the right hand side
  4. Click Ok

 

 

Destinations

 

Moving to the Destinations section of the firewall rule

  1. Click on the Pencil icon in the Destinations section of the firewall rule

 

 

Destination selection

 

Selecting the firewall rule destination.  

  1. Make sure the Type is set to IP Set
  2. Select App-VMs, DB-VMs, and Web-VMs from the list
  3. Click on the right arrow to move the selected section
  4. Click OK

 

 

Services

 

Selecting the Services

  1. Click on the Pencil icon in the Services section of the firewall rule

 

 

Select SSH from the list

 

  1. Click the arrow to navigate to the second page of available services.
  2. Scroll through the list until you find the SSH service.
  3. Click on the right arrow to move SSH to the Selected section.
  4. Click OK.

 

 

 

Saving the rule

 

Now to save the rule

  1. Click on Save

 

 

 

Application Section

 

Now to create a section for the application firewall rules

  1. Click on the Gear Icon next to the Global Policy section you just created
  2. Click on Insert Section Below

 

 

Application Section selection

 

Fill in the form with the following information.

  1. For Section Name enter: Application Policy  
  2. Select Logical Switch for Type
  3. Select LS-APP, LS-DB, and LS-WEB
  4. Click the Right arrow to move the selections to the right hand side (Selected section)
  5. Click Save

 

 

Create firewall rules

 

On your own, create rules that will meet the below requirements.

  1. Any traffic over HTTP and HTTPS to web-01a and web-02a
  2. Allow any traffic from Web-01a and web-02a to App VM
  3. Allow any traffic from AppVM to DB VM

Once this is done you need to save the rules.

  1. Click Save

 

 

Confirm save

 

  1. Click Save when prompted

 

 

Test Web site

 

Now to test to see if the firewall rules work.

  1. Go back to your web-01a tab. If you have closed it, open a new tab and click on the web-01a link in the address bar
  2. Click on Refresh

You should now have a working web site.   This is because we have now allowed traffic between the different VMs, even with the VMs being on both ESXi and KVM hosts.

 

 

Change the default DFW rule

 

Before moving on to the next section, change the default rule back to Allow.

  1. Find the Default Layer3 Section Action location and change the action back to Allow
  2. Click Save

 

Spoof Guard


Now, we are going to leverage Spoof Guard to provide another level of protect for our workloads. Spoof Guard allows NSX to map MAC addresses of VMs to IPs, and blocks any traffic from any workload that does not mapped correctly.  This helps prevent an unauthorized VM from accessing the network, or from someone changing their MAC address in order to get around security controls.


 

Selecting the switch

 

If you have closed the NSX Manager, please reopen and log in. Once logged in, we need to find the logical switch called LS-Web.   Perform the following steps.

  1. Click on Switching on the left hand side
  2. Click on the Switches Tab (unless you are already there)
  3. Click on LS-WEB switch link

 

 

Address Bindings

 

We now are going to bind specific addresses to the switch.

  1. Click on the arrow of the Address Bindings section to open the section up
  2. Click on the +Add link

 

 

Adding a binding

 

We will now bind the address and MAC address of web-01 to the logical switch.  Fill in the form with the following information.

  1. MAC Adress: 00:50:56:88:f6:b3
  2. IP Address:   172.16.10.11
  3. Click Save

 

 

 

Binding review

 

You will now see your newly binded address and MAC in the Address Bindings section.

 

 

Switching Profiles

 

We have the address bound, but now we need to change the switching profile to take advantage of this information.

  1. Click on the Switching Profiles Tab
  2. Click on the +Add link

 

 

Switch Profiles add

 

Now to create a Spoof Guard profile on the switch. Perform the following tasks.

  1. For Name enter: SpoofGuard
  2. For Type, select Spoof Guard from the pull down menu
  3. Click on Switch Bindings + symbol to make it turn to a check
  4. Click Save

 

 

SpoofGuard profile

 

You will now see your newly created switching profile

 

 

Applying the profile

 

We now need to apply the new profile to the LS-WEB switch.

  1. Click on the Switches Tab
  2. Click on LS-WEB

 

 

Managing the switch

 

  1. From the switch summary page, click on the Manage Tab
  2. Select Spoof Guard from the list.

 

 

Change Spoof Guard Profile

 

We need to switch the profile that the Spoof Guard feature is leveraging.

  1. Click on the Change link

 

 

Selecting the new profile

 

  1. From the pull down list, select your newly created profile call SpoofGuard
  2. Click save

 

 

Profile review

 

Notice that the profile is changed to SpoofGuard

Notice that the White List Providers is set to Switch Bindings

 

 

Command prompt

 

We will now open the command prompt and test if Spoof Guard is working.

  1. Click on the command prompt icon in the task bar

 

 

Ping Test

 

Pinging web-01a, whose address and MAC is bound, and web-02a, whose address is not bound, we get two different results.  

  1. Test this yourself by performing the following command to test web-01a
ping web-01a
  1. Test web-02a with the following command
ping web-02a

The bound address is reachable while the unbound is not.

 

 

Adding web-02a

 

Return to the NSX Manager to add the IP and MAC address of web-02a.

  1. Within LS-WEB switch, click on Summary
  2. Click on the +Add link under Address Bindings

 

 

Web-02a binding

 

We will now bind the address and MAC address of web-02 to the logical switch.  FIll in the form with the following information.

  1. MAC Adress: 00:23:20:43:72:e6
  2. IP Address:   172.16.10.12
  3. Click Save

 

 

Updated bindings

 

Review the bindings to see both VMs.

 

 

Ping Test #2

 

  1. Perform a ping of web-02a and you will now receive a success response.

 

Tools


NSX-T provides a variety of tools to make operations and troubleshooting easier. In this chapter, we will explore some of these tools and review their function.


 

Port Connection

 

The first tool we are going to look at is called Port Connection.  The port Connection Tool is used to troubleshoot port connectivity issues in the network infrastructure. The topology view shows the connectivity across the logical and physical components including the overlay tunnel health

  1. Within the NSX Manager, click on Tools on the left hand side
  2. If not default to Port Connection, click on the link for it
  3. For Source Virtual Machine, select web-01a
  4. For Destination Virtual Machine, select db-01a
  5. Click Go

 

 

Port Connection map

 

After you click Go, NSX-T will process the request and respond back with a map detailing the connection between the two VMs.

 

 

Map Icons

 

  1. Click on the different icons to see the information the is returned.  

Feel free to explore and click on the different icons and also try different source and destination VMs.

When you are done, move to the next step

 

 

Traceflow

 

Traceflow traces the transport node-­level path of a packet injected at a logical port.  Traceflow supports L2 and L3 and is supported across ESXi, KVM Edge (including NAT).   Using details provided by the user, a Traceflow packet will be created and inserted into the source logical port. When this packet travel from source to destination, all the logical network entities will report the observations. These observations are consolidated and shown in UI.

  1. Click on TraceFlow on the left hand side
  2. Scroll through the Source pull down menu to find web-01a
  3. Scroll through the Destination pull down menu to find db-01a
  4. Enter the IP address of db-01a: 172.16.30.11
  5. Click Trace

 

 

Traceflow Results

 

Once the trace has started,, NSX-T Traceflow will provide back a map along with information that the packet took, from one end to another.  

Review the results and try your own traceflows.

 

 

 

One of the most helpful new features in NSX-T is the search function. The search function can be used to find port, groups, or whatever you are looking for.  Lets test it out.

  1. Click on the search icon at the top of the page on the right hand side.
  2. Start typing the word "web"

As you see, the system will start to populate the results as you type.  

Test the search function as you please

 

Module 5 Conclusion


In this module you learned about DFW, Spoof Guard, and Tools that can be deployed and used in NSX-T


 

You've finished Module 5 and the lab

 

Congratulations on completing  Module 5 and this lab.

We hope you have enjoyed the lab.

 

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Conclusion

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

Lab SKU: HOL-1826-01-NET

Version: 20180129-122109