VMware Hands-on Labs - HOL-1903-03-NET


Lab Overview - HOL-1903-03-NET - VMware NSX: Operations and Visibility

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.

Welcome to the VMware NSX Operations and Visibility Lab. Within this lab we will guide you through all of the tools at your disposal to assist in not only troubleshooting, but also gaining additional operational visibility into your infrastructure. We start off by reviewing the NSX Content pack for vRealize Log Insight and the new dashboard functionality that it provides in vRealize Log Insight. We then look at tools natively built into NSX, which include Flow Monitoring, Traceflow and Central CLI. The complete Lab Module list is below and all modules are independent of each other, so you can freely move between different modules.

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.

 

 

Click once in active console window

 

In this example, you will use the Online Keyboard to enter the "@" sign used in email addresses. The "@" sign is Shift-2 on US keyboard layouts.

  1. Click once in the active console window.
  2. Click on the Shift key.

 

 

Click on the @ key

 

  1. Click on the "@ key".

Notice the @ sign entered in the active console window.

 

 

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.

 

 

Allow vmware-cip-launcher.exe

 

On occasion, the lab may be provisioned with Chrome settings reset to their default value. If this occurs, you may receive the dialog prompt shown above. Please perform the following steps to allow the launcher to run with the vSphere Web Client (Flash):

  1. Click to select Always open therse types of links in the associated app.
  2. Click to select Open vmware-cip-launcher.exe.

You may then proceed with the rest of the lab normally.

 

 

Minimize Recent Tasks and Recent Objects in vSphere Web Client

 

Due to the screen resolution of the Hands-On Labs desktop, some components of the NSX user interface may appear constrained or missing during this lab. In order to maximize usable screen space, it is recommended to minimize the Recent Objects and Recent Tasks panels in the vSphere Web Client (Flash). To do this, please complete the following:

  1. Click the pin icon in the top right of the Recent Objects panel.
  2. Click the pin icon in the top right of the Recent Tasks panel.

 

Module 1 - Log Insight Content Pack Review (15 minutes)

Introduction to vRealize Log Insight


Traditional log management tools are not suitable for a dynamic hybrid cloud environment.  This is due, in part, to the fact that traditional tools do not leverage logs and other machine data strategically to generate insights and troubleshoot IT infrastructure issues. In addition, machine-generated log data is massive in scale and difficult to capture and manage. Further, siloed approaches to virtual and physical infrastructure management lead to finger pointing and fire drills. Finally, other solutions may need additional piecemeal software in order to work with vSphere, and may not always support the latest version.


 

vRealize Log Insight Description

 

VMware vRealize Log Insight addresses these challenges and enables improved quality of service, operational efficiency and continuous compliance.  The following is a list of Log Insight's capabilities:

 

 

Installation of vRealize Log Insight

Log Insight is installed as a virtual appliance.  By default, the Log Insight virtual appliance has 4 vCPUs, 8 GB of virtual memory, and 530 GB of disk space provisioned. There are many different factors that can impact the sizing of the virtual appliance.  These discussions are beyond the scope of this lab.  A deeper discussion of the vRealize Log Insight platform can be found in the following labs:

HOL-1901-01-CMP - What's New in vRealize Operations Manager and vRealize Log Insight

HOL-1901-04-CMP - Monitor and Troubleshoot with vRealize Suite and Wavefront by VMware

HOL-1901-05-CMP - vRealize Operations Manager and vRealize Log Insight - Advanced Topics

The full documentation set can also be found at https://www.vmware.com/support/pubs/log-insight-pubs.html For the purposes of this lab, the Log Insight Appliance has already been installed.  In the next section, we will log in to the appliance and install the NSX Content Pack.

 

Install vRealize Log Insight Content Pack for NSX


In this module, we will install the Log Insight content pack for NSX. The content pack contains all of the dashboards related to NSX.


 

Launch the Google Chrome Browser

 

From the Control Center Desktop, open Google Chrome.

 

 

Log in to vRealize Log Insight

 

  1. Click on the vRealize Log Insight bookmark.
  2. Login with the following credentials:
Username: admin
Password: VMware1!

 

 

Install the vRealize Log Insight Content Pack for NSX

 

From the main Log Insight screen:

  1. Click on the drop-down in the top right of the window.
  2. Select Content Packs from the drop-down menu.

 

 

Import Content Pack

 

  1. In the top left corner of the menu, click on Import Content Pack.

The Marketplace Unavailable message can be safely ignored since the lab is not connected to the Internet. Through the Marketplace, an administrator can import various VMware as well as third-party content packs without leaving the Log Insight UI.

 

 

Select Content Pack

 

  1. Leave the box at defaults, and Click Browse.
  2. In the resulting file window, navigate to the Desktop > vRealize Log Insight NSX Content Pack 3.7 > VMware - NSX-vSphere  3.7.vlcp.
  3. Double-Click on the file name or select the file and Click Open.
  4. Click on Import to complete the installation of the content pack.

 

 

Complete the Installation

 

  1. Click OK.

Once the import is complete, we can begin to explore the dashboards and other widgets in vRealize Log Insight specific to NSX.

 

Module 1 Conclusion


In this module we installed the NSX Content Pack for vRealize Log Insight. In the next module, we'll look at some of the dashboards.


 

You've Finished Module 1

Congratulations on completing Module 1.

If you are looking for additional information on vRealize Log Insight, visit the following URL:

Proceed to any module below which interests you the most.

Lab Module List:

 Lab Captains:

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 2 - Log Insight Dashboards (15 minutes)

Introduction to vRealize Log Insight Dashboards


The NSX for vSphere Log Insight Content Pack provides powerful operational reporting and alerting visibility for all sources of log data within NSX. Each major NSX function (logical switching, routing, distributed firewalls, VXLAN gateways, and edge services) is represented in this content pack via custom dashboards, filters, and alerts. This graphically rich content pack is essential for analyzing and identifying NSX configuration, performance, security and trend related problems. The NSX dashboards are easily selectable with intuitive mouse clicks. NSX log data is quickly sorted based upon user defined time intervals, and within seconds the data is presented graphically via bar graphs, pie charts and raw data collection widgets.


 

Dashboard Overview

 

In this module we will look at the different dashboards available from the NSX content pack.

 

Install vRealize Log Insight Content Pack for NSX


In this lesson, we will install the Log Insight content pack for NSX. The content pack contains all of the dashboards related to NSX.

This section of Module 2 can be skipped if you completed the Content Pack installation in Module 1 and moved on to Module 2 without ending the lab. If you are starting a fresh lab with Module 2, please complete this section first.


 

Launch the Google Chrome Browser

 

From the control center desktop, open Google Chrome.

 

 

Log in to vRealize Log Insight

 

  1. Click on the vRealize Log Insight bookmark.
  2. Log in with the following credentials:

Username is admin

Password is VMware1!

 

 

Install the vRealize Log Insight Content Pack for NSX

 

From the main Log Insight screen:

  1. Click on the drop-down in the top right of the window.
  2. Select Content Packs from the drop-down menu.

 

 

Import Content Pack

 

  1. In the top left-hand corner of the menu, Click on Import Content Pack.

The Marketplace Unavailable message can be safely ignored since the lab is not connected to the Internet. Through the Marketplace, an administrator can import various VMware as well as third-party content packs without leaving the Log Insight UI.

 

 

Select Content Pack

 

  1. Leave the box at defaults, and Click Browse.
  2. In the resulting file window, navigate to the Desktop > vRealize Log Insight NSX Content Pack 3.7 > VMware - NSX-vSphere  3.7.vlcp.
  3. Double-Click on the file name or select the file and Click Open.
  4. Click on Import to complete the installation of the content pack.

 

 

Complete the Installation

 

  1. Click OK.

Once the import is complete, we can begin to explore the dashboards and other widgets in vRealize Log Insight specific to NSX.

 

Examine Various Dashboards


In this lesson we will explore various dashboards and reporting capabilities in Log Insight.


 

Adjust Browser Zoom

 

Due to the limited resolution available in the lab, please adjust browser zoom level to include more content in the screen:

  1. Click on the 3 dots to the right of the address bar in Google Chrome.
  2. In the drop-down menu, decrease the zoom level using - button.

 

 

VMware NSX for vSphere Content Pack

 

To get a full list of the widgets that are available in the Content Pack:

  1. Click on the drop-down in the top right of the window.
  2. Select Content Packs from the drop-down menu.
  3. Select VMware - NSX-vSphere.
  4. Select Dashboards at the top of the page to view a full list of the available widgets.

 

 

Navigate to Dashboards

 

  1. Click on Dashboards.
  2. Expand VMware - NSX-vSphere.
  3. Click on NSX-vSphere - Overview.

 

 

Select Custom Time Range

 

For the purposes of this lab, we will select a specific date to reflect the data we want to explore.

  1. Click on the drop down menu representing the time range.
  2. Select Custom time range.

 

 

Select the Dates

 

  1. Click on the Calendar icon.
  2. Select the following dates for start and end of custom time range:
2018-05-01 -- 2018-07-31

 

 

View Custom Time Range

 

  1. Once the dates are selected, click update to refresh the dashboard.

 

 

NSX for vSphere Dashboard

 

  1. Click on NSX-vSphere - Overview.
  2. Hover your mouse over the NSX for vSphere Edge system events by severity widget.
  3. Click on the "i" to show information about this widget.

The NSX-vSphere Overview is the main entry point. This dashboard displays all problems/alerts reflected in the entire content pack. Therefore, under normal operating circumstances the dashboard should not contain any data. Once a log appears in a widget, read the widget's information in order to navigate to the appropriate dashboard for a more detailed view of the information associated with the problem.

Note, if no data is displayed in the Log Insight web UI, return to Adjust Browser Zoom step and adjust the time range as described in the Custom Time Range step.

 

 

Distributed Firewall - Overview

 

  1. Click on Distributed Firewall - Overview.
  2. You can use the filters to narrow down the results displayed by Hostname, Firewall Rule ID or Firewall Rule Action. More filters can be added to narrow down the search.
  3. Firewall audit events by operation: Is a graphical representation of audit events by operation, such as create, delete or update.
  4. You can also take a quick look at the newly published firewall rules along with the timestamp, Source NSX manager, action, etc.

Distributed firewall dashboards provide widgets that contain many different views of firewall data. These visualizations are aggregated to show various slices of an NSX Datacenter environment at the hypervisor, VM, and application level.

 

 

New Dashboards in the NSX Log Insight Content Pack

 

Under VMware - NSX-vSphere, new dashboards have been introduced in the NSX for vSphere Content Pack 3.6 for edge load balancing services. These dashboards are available with NSX Manager 6.3 or later.

 

 

Guest Introspection

 

 

Under VMware - NSX-vSphere, you will also find Guest Introspection - Alerts dashboard, which displays the status of deployed guest introspection services.

Guest introspection is a service that is deployed from NSX Manager to offload security functions to a dedicated security appliance on each host; thus removing the need for an antivirus agent within the guest operating system.

Using the Guest Introspection driver baked into VMware Tools and a third-party service virtual machine, all virtual machines are protected by real-time antivirus and malware inspection as soon as they are powered on. This reduces administrative and guest memory overheads, whilst standardizing deployments.

 

Interactive Analytics


 

Interactive analytics allow interaction with logs in real time enabling the Administrator to select a specific event, show all the logs related to that event and then filter out the incidents.


 

Open vSphere Web Client

 

If you don't already have vSphere Web Client open:

  1. In Google Chrome, open a new tab and click on the Region A | RegionA vCenter link in the bookmarks bar.

 

 

Log in to the vSphere Web Client

 

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

 

 

Navigate to Networking & Security

 

  1. In the vSphere Web Client click the Home button.
  2. Click Networking & Security.

 

 

Create a Firewall Rule

 

  1. Under Networking & Security, click on Firewall.
  2. Click on the + icon to expand Default Section Layer3.
  3. Click on the 3 dots icon to the left of Default Section Layer3.
  4. Click Add Rule.

 

 

Define Values in the New Firewall Rule

 

We will now create a firewall rule to simulate a packet drop scenario.

  1. Use your mouse pointer to select and insert text into the Name field. Call it Fin Web to HR Web block
  2. Hover your mouse pointer over the Source column and click the pencil to edit the value.

 

 

Resultant Firewall Rule

 

This is what the rule should look like once configured. Use the following values to configure the rule:

 

 

 

Publish Firewall Rule

 

Go ahead and publish the rule to activate it.

  1. Click on Publish.

 

 

Verify Publish Operation Succeeded

 

  1. Verify that the publish operation has completed successfully (Please note the date of your publish will not be identical to the screenshot).

 

 

Test the New Distributed Firewall Rule

 

From the taskbar, open a new PuTTY window.

 

 

Open Saved SSH Session

 

  1. Under Saved Sessions, search for fin-web
  2. Select fin-web-01a.corp.local from the Saved Sessions.
  3. Click Open.

 

 

Test New Firewall Rule

 

Ping HR-web-01a (172.16.60.10):

ping -c 5 hr-web-01a

Firewall rule should drop the packets.

 

 

Navigate to vRealize Log Insight

 

If not already logged in to the vRealize Log Insight web interface:

  1. Open a new tab and click on the vRealize Log Insight bookmark.
  2. Use the following credentials to log in.

User name: admin

Password: VMware1!

 

 

Verify Result From Dashboards

 

  1. Click Dashboards.
  2. Click VMware - NSX-vSphere.
  3. Click Distributed Firewall - Overview.
  4. Select Latest hour of data as the time interval.
  5. In the Firewall actions widget, hover your mouse over the column. You should see the number of dropped packets. Click on the column.
  6. Select Interactive Analytics.

 

 

Interactive Analytics

 

  1. In this view, we should see five columns representing the number of packets dropped by the distributed firewall. When analyzing large sets of data, select the column that is the closest representation of the time that needs investigation to expand the column.
  2. In the filter section an administrator can dynamically extract any field from the data by providing a regular expression. The extracted fields can be used for selection, projection, and aggregation, similar to how the fields that are extracted at parse time are used.
  3. Fields section shows a list of data classifications and keywords that can be chosen to be shown or hidden. You can also choose to assign a specific value to further filter your results.
  4. The logged event shows that an ICMP packet between 172.16.60.20 (fin-web-01a) and 172.16.60.10 (hr-web-01a) was dropped by the distributed firewall rule ID 1007.

 

 

Add to Custom Dashboard

 

If the work done in Interactive Analysis might require additional follow-up, we can export this filtered view to custom dashboards.

  1. Click Add to Dashboard in the top right of the screen.
  2. Populate the fields using the following information:
    • Name: Fin Web to HR Web block
    • Notes: Chart showing dropped ICMP packets between: fin-web-01a.corp.local and hr-web-01a.corp.local
  3. Click ADD.

 

 

Review Custom Dashboards

 

  1. Click Dashboards.
  2. Click My Dashboards.
  3. Verify the custom dashboard shows the same events that we witnessed in the interactive analytics. Note: you may need to adjust the time range.

 

 

Delete Firewall Rule

 

Switch back to vSphere Web Client - Networking & Security

  1. Click on Firewall.
  2. Click on the + icon to expand Default Section Layer3
  3. Select the checkbox next to Fin Web to HR Web block rule.
  4. Click Delete. In the resultant window, confirm deletion of the rule by clicking YES.
  5. Click Publish.

 

 

Verify Publish Operation Succeeded

 

  1. Verify that the publish operation has completed successfully (Please note the date of your publish will not be identical to the screenshot).

 

Module 2 Conclusion


In this module, we looked at the different dashboards available in the NSX content pack for vRealize Log Insight. We focused on the distributed firewall dashboards.

Finally, we looked at interactive analytics and how we can monitor events live to help provide root cause analysis for incidents.


 

You've finished Module 2

Congratulations on completing Module 2.

If you are looking for additional information on vRealize Log Insight visit the URL below:

Proceed to any module below which interests you the most.

Lab Module List:

 Lab Captains:

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 3 - Flow Monitoring (30 Minutes)

Introduction to Flow Monitoring


Flow Monitoring is a traffic analysis tool that provides a detailed view of the traffic to and from virtual machines. When flow monitoring is enabled, its output defines which machines are exchanging data and over which application. This data includes the number of sessions and packets transmitted per session. Session details include sources, destinations, applications, and ports being used. Session details can be used to create firewall allow or block rules.

Flow Monitoring can thus be used as a forensic tool to detect rogue services and examine inbound and outbound sessions.


Tour of Flow Monitoring


Flow Monitoring is accessed from the Networking & Security tab in the vSphere Web Client.

 

Open Google Chrome browser from the taskbar or the desktop of main console.


 

Navigate to vCenter - Region A

 

  1. If the page does not automatically default to the vSphere Web Client page click on the Region A | RegionA vCenter link in the bookmarks bar.

 

 

Log in to vSphere Web Client

 

If you are not already logged in to the vSphere Web Client:

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

 

 

Navigate to Networking & Security

 

  1. In the vSphere Web Client click the Home button.
  2. Click Networking & Security.

 

 

Navigate to Flow Monitoring

 

  1. In the Networking & Security tab click on Flow Monitoring.

 

 

Flow Monitoring Tabs

 

There are four tabs available within Flow Monitoring :

  1. Dashboard - Displays Top Flows, Top Destinations and Top Sources. Time interval for displaying flow data can be modified on this page.
  2. Details by Service - Displays Allowed and Blocked Flows by service.
  3. Live Flow - displays live flows of a selected vNIC from the virtual infrastructure.
  4. Configuration - Enables Flow Monitoring and allows exclusion of certain flows.

 

 

Change the Time Interval

 

  1. Click on the Dashboard tab if not already selected.
  2. Change the time interval by clicking on the Calendar Icon. If the calendar icon is not visible, move the screen focus to the right by using the scroll bar.
  3. Select the time frame to view. Leave the default value of Last 15 minutes.
  4. Click OK to continue.

 

 

Flow Monitoring Dashboard

 

The Dashboard tab displays a list of flow information from the environment, which includes actual flows and statistical information around the percentage of flows allowed, blocked by rules, or blocked by spoofguard.

We can also view flows by Top Flows (Service), Top Destinations and Top Sources occurring within the environment.

 

 

Flow Monitoring Details by Service

 

  1. Click on Details By Service tab to view flow statistics based on services in the environment.
  2. Click on Allowed Flows if not already selected. Displayed are all flows within the environment that have been allowed by rules in the distributed firewall.

 

 

Add a Firewall Rule via Allowed Flows

 

If there is a flow within the environment that should be blocked or allowed we can add a rule to the Distributed Firewall. This step is to explore the functionality and no rule will be created as a result:

  1. Click on a flow of interest.
  2. Click on the Add Rule link to insert a new rule. Note: use the scroll bar to move the window to the right in order to see the Add Rule link.
  3. Enter the required information regarding the rule such as Name, Destination, Action, Enabled, Logging, Applied To and Section name.
  4. Click Cancel as we will not be modifying the firewall rules at this point.

 

 

Blocked Flows

 

  1. Click on Blocked Flows tab, which shows all flows that have been blocked by the distributed firewall.

 

 

Flow Monitoring Configuration

 

  1. Click on the Configuration tab.
  2. Here we can Enable or Disable Flow Monitoring. Flow Monitoring is disabled by default and has been manually enabled for this lab.

 

 

Flow Exclusion

 

Within Flow Monitoring we can filter displayed data by specifying exclusion criteria. For example, we may want to exclude a proxy server to avoid seeing duplicate flows. Or if there is a Nessus scan running against virtual machines in the inventory, we may want to exclude the scan flows from being collected.  

  1. Click on Flow Exclusion.
  2. Click on one of the Exclusion filters. In this example we selected Collect Layer2 Flows.
  3. Here we can modify the collection policy of various flows.

 

 

IPFIX Configuration

 

We can also configure IPFIX to export flows to a NetFlow collector. In this lab, IPFIX has already been enabled to send flow data to vRealize Network Insight for advanced traffic analysis and security planning.

  1. Under Networking & Security click on IPFIX.
  2. Click Edit.

 

 

 

Edit IPFIX Configuration

 

  1. Explore IPFIX configuration and click Cancel.

 

 

Add IPFIX Collectors

 

  1. In Collector IPs section, click ADD in order to add a new IPFIX collector.
  2. In the blank row, enter the collector IP address and set the required UDP port.
  3. Click Revert, as this lab has already been configured to send IPFIX data to a vRealize Network Insight collector (192.168.110.103) for analysis. In the resulting window, confirm Revert IPFIX Configuration.

 

Monitoring Flows of a Virtual Machine


Now that we've walked through the configuration options available for Flow Monitoring, let's start monitoring some flows which will include allowed and blocked flows.


 

Enable Flow Monitoring Distributed Firewall rule

We first need to enable the distributed firewall rule that will block communication between web-01a.corp.local (172.16.10.11) and app-01a.corp.local (172.16.20.11) virtual machines. This will allow us to test Flow Monitoring and show the difference between an allowed and blocked flow.

 

 

Navigate to Networking & Security

 

  1. In the vSphere Web Client click the Home button.
  2. Click Networking & Security.

 

 

Navigate to Firewall

 

  1. Under Networking & Security, click on the Firewall tab.
  2. Click on the + to expand the section called Flow Monitoring & Trace Flow Rules - Disabled by Default.
  3. Flip the toggle switch to green to enable the Flow Monitoring and Traceflow Test rule.
  4. Verify that the Source VM is web-01a_corp.local, the Destination VMs are app-01a_corp.local AND web-02a_corp.local, and that the Service is Any.
  5. Click Publish to push the firewall rules down to the hypervisors.
  6. Verify that the publish operation has completed successfully (Please note the date of your publish will not be identical to the screenshot).

 

 

Navigate to Flow Monitoring

 

  1. Under Networking & Security, click on Flow Monitoring.
  2. Click on the Live Flow tab.
  3. Click the Select vNIC link to select a virtual machine network interface card to monitor.

 

 

Select the Virtual Machine

 

  1. In the search field type web-01 and press enter.
  2. Click on the web-01a_corp.local virtual machine.
  3. Click on the right arrow.

 

 

Select the vNIC

 

  1. Select web-01a_corp.local - Network adapter 1 vNIC to monitor.
  2. Click OK to confirm.

 

 

Start Live Flow Monitoring

 

  1. Click on Start to start monitoring flows to and from the vNIC.
  2. Optionally, change the Refresh Rate by clicking on the drop down menu and selecting a new refresh rate.

When traffic flows through the vNIC flow entries will be highlighted in different colors:

Flows will appear for X number of seconds depending on the refresh rate that has been selected, by default this is every 5 seconds.

 

 

Open a New Tab in Your Browser

 

  1. Click on the new tab icon in the browser to open a new tab.

 

 

Open Customer DB App

 

  1. Click on the Customer DB App bookmark, which will eventually display a 504 Gateway Time-out webpage because we blocked all access between web-01a.corp.local (172.16.10.11) and  app-01a.corp.local (172.16.20.11).
  2. Return to the vSphere Web Client tab where we should see some flows.

 

 

Viewing Active and Blocked flows

 

The green flows are showing active flows from the Main Console (192.168.110.10), which is where the Chrome browser is running, to web-01a.corp.local (172.16.10.11).

The red flows are showing blocked flows from web-01a.corp.local (172.16.10.11) to app-01a.corp.local (172.16.20.11) as these are being blocked by the NSX distributed firewall.

Note Rule ID 1006 associated with the blocked flow; this is the distributed firewall rule Flow Monitoring and Traceflow Test rule we enabled in an earlier step.

 

 

Refreshing the Customer DB App Web Page

 

To generate additional web traffic to the Customer DB App:

  1. Go back to the Customer DB App browser tab.
  2. Click on the browser refresh button.
  3. Switch back to the vSphere Web Client browser tab to continue observing live flows.

 

 

Filtering Flows

 

Since NSX release 6.2.3 we now have the ability to filter flows based on source or destination IP addresses. This allows us to easily focus on flows of interest and ignore all the unnecessary ones.

  1. While monitoring a vNIC, click on the Apply filter button.
  2. Select either Source IP or Destination IP and enter that address in the IP Address field.
  3. Click Apply.

This is just to display functionality, no need to add any filters.

When finished exploring Flow Monitoring, continue to the next step to clean up the lab environment.

 

 

Stop Flow Monitoring

 

  1. Click the Stop button to stop Flow Monitoring. Switching to another tab in Networking & Security would accomplish the same task.

 

 

Navigate to Firewall

 

  1. Under Networking & Security click on the Firewall tab.
  2. Click on the + to expand the section called Flow Monitoring & Trace Flow Rules - Disabled by Default.
  3. Flip the toggle switch to grey to disable the Flow Monitoring and Traceflow Test rule.
  4. Click Publish to push the firewall change down to the hypervisors.
  5. Verify that the publish operation has completed successfully (Please note the date of your publish will not be identical to the screenshot).

 

Application Rule Manager


Application Rule Manager (ARM) is a tool that was introduced in NSX 6.3. ARM greatly simplifies the process of securing an application through microsegmentation by automatically creating firewall rules and streamlining the process of configuring security groups for existing applications.       

There are three steps in the application rule manager workflow:  

  1. Select virtual machines (VMs) that form the application and need to be monitored. Once configured, all incoming and outgoing flows for a defined set of VNICs (Virtualized Network Interface Cards) on the VMs are monitored. There can be up to five sessions collecting flows at a time.
  2. Once monitoring is stopped, flows are then analyzed to reveal interaction between VMs. Flows can be filtered to bring the records to a limited working set.
  3. Rule Planning functionality is then used to review recommended firewall rules and create or modify grouping objects such as security groups, IP sets, services and service groups, as well as firewall rule actions.  

 

Navigate to Application Rule Manager

 

Before we can view and analyze flow data for VMs, we need to first gather the flows.

  1. Under Networking & Security, click on Application Rule Manager.
  2. Click the + Start Session to configure a new flow collection session.

 

 

Select Virtual Machines

 

  1. In the session name type New Fin App.
  2. For the Object Type, select Virtual Machine.
  3. Use Search to narrow down the results by typing fin
  4. Select the following VMs: fin-web-01a_corp.local, fin-app-01a_corp.local and fin-db-01a_corp.local
  5. Click on the right arrow.
  6. Click START.

 

 

Open Finance DB App

 

ARM is now collecting flow data between the three selected VMs. The more time it is left to collect data, the more information we will have for analysis. For lab purposes, we will leave it collecting flows for three minutes. To generate relevant data:

  1. Open a new tab in the web browser and click Finance DB App bookmark icon.

Please note that the number of flows may vary form one student to another.

 

 

Review Sources

 

Return to the vSphere Web Client browser tab.

  1. Click on Details to see a list of the vNICs being monitored.

 

 

Stop Data Collection

 

  1. Select the radio button to the left of New Fin App session.
  2. Click Stop to stop the collection. In the resultant window, confirm by clicking STOP.

 

 

Analyze Flows

 

  1. Make sure the New Fin App session is selected.
  2. Click Analyze.

 

 

Analyze Session

 

  1. In the resulting window, keep the defaults and click Analyze.

 

 

Review Session

 

Let's review the collected and analyzed flows.

  1. Wait for the Status to display Analysis complete.
  2. Click on the New Fin App link to open the analyzed content.

 

 

Review Collected Flows

 

  1. Click on the Flows tab.

Displayed are various flows observed during the session. Note the Direction, which indicates:

Please note that the number and type of flows observed may be different in your environment.

 

 

Review Recommended Rules

 

  1. Click on Rule Planning.

In this section we will review distributed firewall rules recommended by ARM. The recommended rules are based on observed flows during the session. The rules can be rearranged, renamed, or disabled before publishing to the firewall.

The Source or Destination fields can be modified to account for existing Security Groups defined in the NSX manager, or create new Security Groups to include VMs observed by ARM in the current session.

The Service, which has been automatically classified by ARM, can be narrowed down to the specific application running on the VM.

The Action (Allow, Block, or Reject) as well as the Log setting can be set based on the required security policy.

 

 

Publishing Recommended Rules to Firewall

 

We can publish the recommended firewall rules directly from the Application Rule Manager interface after making necessary changes.

  1. Click on Publish to Firewall.

 

 

Firewall Publish

 

  1. In the resulting window, type ARM in the Section Name field.
  2. Select Flow Monitoring & Traceflow Rules - Disabled By Default in Insert Above field.
  3. Click OK.

 

 

Verify the Firewall Rules Have Been Published

 

Verify that the last publish to firewall operation succeeded.

 

 

Verify Firewall Rules in NSX manager

 

Verify that the new firewall rules have been published and are visible within the main firewall view.

  1. Under Networking & Security, select Firewall.
  2. Click on + to expand the ARM firewall section.
  3. Verify those are the same rules that were recommended by ARM and published in earlier steps.

ARM can greatly simplify creation of firewall rules that are application centric. After reviewing ARM and the new firewall rules, continue to the next step to clean up the lab environment.

 

 

Lab Clean Up

 

  1. Click the checkbox to select the ARM firewall section.
  2. Click Delete. In the subsequent window, confirm section deletion by selecting YES.

 

 

Publish and Confirm Firewall Changes

 

  1. Click Publish.
  2. Confirm the changes were successfully published.

 

Module 3 Conclusion


In this module we showed the various options that can be configured as part of Flow Monitoring as well as the ability to monitor allowed or denied flows to and from a virtual machine's network interface card. Flow monitoring tools are very useful in troubleshooting connectivity while Application Rule Manager helps secure the application by analyzing and configuring firewall rules, thus only allowing flows the application requires.


 

You've finished Module 3

Congratulations on completing Module 3.

If you are looking for additional information on Flow Monitoring visit the following URL:

Proceed to any module below which interests you the most.

Lab Module List:

 Lab Captains:

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 4 - Traceflow (15 Minutes)

Introduction to Traceflow


Traceflow is a feature that improves operational visibility and troubleshooting of NSX deployments in virtual environments. Traceflow injects a packet into a vNIC of a virtual machine, which has no reliance on the guest operating system, and follows it through the various network overlay components and distributed firewall rules all the way to the destination virtual machine. Traceflow supports both L2 and L3 destinations and enables administrators to quickly identify problems and pinpoint issues in the NSX data path.


Traceflow Between Two Virtual Machines


In this lesson we will perform a Traceflow between two virtual machines and analyze the results of dropped and successful traces.


 

Launch the Chrome Web Browser

 

Before we can perform a Traceflow we need to log in to the vSphere Web Client. Launch the Chrome browser from the desktop or the taskbar.

 

 

Open vSphere Web Client

 

  1. If the page does not automatically default to the vSphere Web Client page click on the Region A | RegionA vCenter link in the bookmarks bar.

 

 

Log in to the vSphere Web Client

 

If not already logged in to the vSphere Web Client:

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

 

 

Enable Traceflow Distributed Firewall rule

The first step that we need to complete is to enable the Distributed Firewall rule that will block communication between web-01a.corp.local (172.16.10.11) and web-02a.corp.local (172.16.10.12). This will allow us to see a dropped Traceflow between the two virtual machines on the same L2 segment due to a firewall rule.

 

 

Navigate to Networking & Security

 

  1. In the vSphere Web Client click the Home button.
  2. Select Networking & Security.

 

 

Enable Firewall Rule

 

  1. Under Networking & Security, click on Firewall.
  2. Click on the + to expand the section called Flow Monitoring & Trace Flow Rules - Disabled by Default.
  3. Flip the toggle switch to green to enable the Flow Monitoring and Traceflow Test rule.
  4. Verify that the Source VM is web-01a_corp.local, the Destination VMs are app-01a_corp.local AND web-02a_corp.local, and that the Service is Any.
  5. Click Publish to push the firewall rules down to the hypervisors.
  6. Verify that the publish operation completed successfully (Please note the date of your publish will not be identical to the screenshot).

 

 

Navigate to Traceflow

 

  1. Under Networking & Security click on Traceflow.

 

 

Select Traffic Type

 

  1. Under Traffic Type drop down menu there are options to select Unicast, L2 Multicast of L2 Broadcast traffic to simulate. Leave the option set as Unicast.

 

 

Select the Source Virtual Machine

 

  1. Click on Select link next to Source.
  2. In the filter field type web-01 and press enter.
  3. Click on the right arrow next to virtual machine web-01a_corp.local, which will be the source of Traceflow.

 

 

Select the Source vNIC

 

  1. Click on vNIC web-01a_corp.local that will be the source of the packet.
  2. Click OK to confirm the selection.

 

 

Select Destination

 

  1. Click on the Select link next to the Destination. The options are to perform a L2 or L3 Traceflow based on destination IP or MAC address or to select a particular virtual machine.

 

 

Select Destination Virtual Machine

 

  1. Check the option to Select Destination vNIC.
  2. Click on the right arrow next to the virtual machine that will be your destination, in this case web-02a_corp.local.

 

 

Select the Destination vNIC

 

  1. Click on the destination web-02a_corp.local vNIC.
  2. Click OK to confirm the selection.

 

 

Configure Advanced Options

 

We can configure additional settings for the packet injected into the Source vNIC under Advanced Options. Additional settings include Protocol, which can be either ICMP, TCP or UDP, Timeout, Frame Size, and TTL. Additional options are presented based on the protocol selected. In this example we will trace a TCP packet with Destination Port 80 and TCP SYN Flag set.

  1. Click on the arrow next to Advanced Options.
  2. Change the Protocol to TCP.
  3. Set the Destination Port to 80.
  4. Ensure the SYN TCP Flag is checked.
  5. Click Trace to inject the packet.

 

 

Long Running Task

 

  1. If you receive a message box advising that the current task is taking too long to complete and do you want to continue polling click Yes. This is due to the effects of nested virtualization environment which this lab is running in.

 

 

Review Traceflow Results

 

  1. Once the trace completes, the result will display that the packet was Dropped.
  2. We can follow the sequence and see that the packet was injected into the vNIC, received by the firewall and then dropped by Rule - 1006, which we enabled earlier. Note that the packet was dropped at the source VM firewall without traversing the infrastructure. If this was unexpected behavior then we could investigate rule 1006 to check if it should be in place or not.

 

 

Disable Traceflow Distributed Firewall Rule

In the next steps we will disable the Distributed Firewall rule to allow communication from web-01a.corp.local (172.16.10.11) to web-02a.corp.local (172.16.10.11) and perform Traceflow again to see a successful packet delivery.

 

 

Navigate to Firewall

 

  1. Under Networking & Security, click on Firewall.
  2. Click on the + to expand the section called Flow Monitoring & Trace Flow Rules - Disabled by Default.
  3. Flip the toggle switch to grey to disable the Flow Monitoring and Traceflow Test rule.
  4. Click Publish to push the firewall change down to the hypervisors.
  5. Verify that the publish operation completed successfully (Please note the date of your publish will not be identical to the screenshot).

 

 

Perform a Traceflow

 

  1. Under Networking & Security click on Traceflow.
  2. Trace Parameters from the previous trace attempt should still be in place. If not, repeat the steps to set the following parameters:
    • Traffic Type: Unicast
    • Source: web-01a_corp.local
    • Destination: Select Destination vNIC
    • Destination: web-02a_corp.local
    • Advanced Options - Protocol: TCP
    • Advanced Options - Destination Port: 80
  3. Click Trace.

 

 

 

Long Running Task

 

  1. If you receive a message box advising that the current task is taking too long to complete and do you want to continue polling click Yes. This is due to the effects of nested virtualization environment which this lab is running in.

 

 

Review Traceflow Results

 

  1. Once the trace completes, we should see the end result as Delivered.
  2. We can follow the packet and see that it was injected into the vNIC, passed through the distributed firewall on egress, encapsulated and delivered to the receiving host, and then passed through the distributed firewall on ingress.

Note that you may need to scroll down to see the full Traceflow information.

 

 

Filtering Results

 

  1. It is also possible to filter the results based on Observation Type, Component Type, Component Name and Host by clicking on the filter icon in the top right of the Trace Result section.
  2. Select the appropriate filter criteria, such as Component Type: Firewall.
  3. Click Apply to only display firewall-specific Traceflow components.

 

Module 4 Conclusion


In this module we showed how to perform a Traceflow between two virtual machines and the expected results from both a successful and failed delivery attempts. We also showed how additional options could be configured to perform a Traceflow based on ports rather than ICMP as well as filtering the results.


 

You've Finished Module 4

Congratulations on completing Module 4.

If you are looking for additional information on Traceflow visit the following URL:

Proceed to any module below which interests you the most.

Lab Module List:

 Lab Captains:

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 5 - Central CLI (30 minutes)

Introduction to Central CLI


In this module we will explore Central CLI, a tool which can assist in operational activities when working with NSX for vSphere.

Prior to Central CLI if an administrator wanted to expose details on constructs such as the NSX Edge Service 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:

With Central CLI one simply needs access to the console of the NSX Manager for obtaining such information, 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 troubleshooting of issues that may occur within an environment where NSX for vSphere is deployed.

Before going into more detail about what those commands are and the types of scenarios we will cover in this module, please proceed to the next step where we will SSH in to the NSX Manager (nsxmgr-01a.corp.local) using PuTTY.


 

Open PuTTY

 

  1. Click on the Putty icon located on the taskbar.

 

 

Configure NSX Manager SSH Connection in PuTTY

 

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

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

 

 

NSX Manager Command Prompt

 

  1. Enter VMware1! as the password.

 

 

NSX Centralized CLI Command List

 

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

list

There are a number of 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 Service Gateways, ESXi Hosts, or NSX Controllers.

  1. Scroll up in the PuTTY window to view the entire list of commands.

Please leave this PuTTY window open, and proceed to the next step, where we will look at commands for troubleshooting VXLAN connectivity.

 

 

Click and Drag Lab Manual Content Into Console Active Window

Please review how to click and drag text and Command Line Interface (CLI) commands directly from the Lab Manual into the active window in the Main Console.  

 

Troubleshooting Logical Switches


Prior to the Central CLI it was necessary to SSH/console into the NSX Manager, ESXi hosts, and NSX Controllers to get details about the following components:

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

Note: You may find it useful to increase or maximize the size of the PuTTY 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.

Note: Due to the dynamic nature of virtual environments, output from certain commands may be different than what is shown in the screenshot.


 

Cluster/Host/VM Details

Majority of the commands covered in this module require 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 show how to obtain those values. The specific IDs will be used in the later sections of this module, but this is how one would normally find those identifiers.  

 

 

List All Clusters

 

To list all clusters 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 RegionA01-COMP01. Continue to the next step to find out how to retrieve a list of hosts in that cluster.

 

 

Show All Hosts in a Cluster

 

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

show cluster domain-c26

Recall that domain-c26 was the value under the Cluster-ID column in the previous command, so that's what we used in this command to get a list of hosts in the RegionA01-COMP01 vSphere cluster.  The output received should look similar to the screenshot with columns for:

Perhaps in a troubleshooting scenario it is discovered that a VM which is lacking network connectivity happens to be on a host that isn't fully prepared for NSX, and the host is not listed as "Enabled" in the installation status of network virtualization components. This is a quick way to query hosts to find out this type of information without having to log in to the vSphere Web Client.

 

 

Specific Host Health (Healthy)

 

This command displays the health of a specific host. The command runs 30+ checks such as network configuration, VXLAN configuration and resource utilization.

show host host-31 health-status

The status will show either Healthy, Unhealthy or Critical depending on the severity of the errors.

Please note that due to resource constraints in this environment, the output may show hosts as Unhealthy. Examples of hosts in Unhealthy state are provided in the next step for your reference.

 

 

Specific Host Health (Unhealthy)

 

This output shows an unhealthy host, which has high memory as well as storage utilization.

 

In this example a host is in critical state; the VXLAN VMkernel (VMK) interface was removed from the host to produce the error.

 

 

Specific Host Details

 

To list the Virtual Machines (VMs) on each of the hosts in RegionA01-COMP01 cluster, run the following two commands:

show host host-29
show host host-31

The values host-29 and host-31 refer to the Host IDs of both esx-01a.corp.local and esx-02a.corp.local, respectively.  These values were used in the show host command to retrieve the following values about the VMs running on these hosts:

We will be working with virtual machine web-01a_corp.local, so the VM ID vm-225 will be used for other commands in this module.  To find out more about the vNIC details of web-01a_corp.local 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-225

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

 

 

Specific vNIC Details

 

To obtain additional information about the vNIC of the web-01a VM, enter in the following command. Please feel free to drag and drop the command from the manual into the console instead of typing the entire command:

show vnic 50082c51-03bb-8f21-d68b-f9d5445b4763.000 

The following details are displayed:

 

 

Logical Switch Commands

We will now look at the set of options available for the "show logical-switch" command to address the following scenarios:

In the next step we will list all logical switches within the NSX Manager Central CLI.

 

 

List all Logical Switches

 

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

show logical-switch list all

The values returned from this command are:

We will obtain additional details on logical switches specific to an ESXi host in the next step.  

 

 

Logical Switch Details On a Host - Verbose

 

To list additional details of all logical switches on a host, run the following command:

show logical-switch host host-29 verbose

This will display a lot of information regarding the logical switches running on the host, use the space bar to scroll through the output before getting the command prompt to display again. Some details worth noting here are:

Next, we will look at 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-29 statistics

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 for troubleshooting purposes.

 

 

List all Hosts With VMs on a specific VNI

 

To determine which hosts have VMs on a specific VXLAN Network Identifier (VNI), run the following command:

show logical-switch list vni 5000 host

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

 

 

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-1 vni 5000 vtep

It is possible that this command may not return any details, if that occurs, replace the controller-1 in the command above with either controller-2 or controller-3. The IP addresses shown 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 an NSX Controller, run the following command:

show logical-switch controller controller-1 vni 5000 arp

It is possible that this command may not return any details, if that occurs, replace the controller-1 in the command above with either controller-2 or controller-3.

 

 

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 an NSX Controller, input the following command:

show logical-switch controller controller-1 vni 5000 mac

If no results return, try again with one of the other two NSX Controllers.

 

 

Show Statistics for a specific VNI on a Controller

 

To display statistics pertaining to the VNI on an NSX Controller, run the following command:

show logical-switch controller controller-1 vni 5000 statistics

 

 

Show Slice Detail for Joined-VNIs on a Specific Host

 

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

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

In this command, controller-1 can be replaced with either controller-2 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.

This only covers some of the commands available for Logical Switches. In the next lesson, we will explore commands available for troubleshooting Distributed Logical Routers.

 

Troubleshooting Distributed Logical Routers


We will now look at some of the commands available for troubleshooting Distributed Logical Routers deployed in NSX for vSphere environment. First, let's review the unique identifiers that will be utilized for some of these commands and what objects they refer to. These are listed in the next step and can be referenced throughout the remainder of this lesson.


 

Object IDs

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

vSphere Clusters

RegionA01-MGMT01     :  domain-c141
RegionA01-COMP01     :  domain-c26
RegionA01-COMP02     :  domain-c201

 

ESXi Hosts

esx-01a.corp.local    :  host-29
esx-02a.corp.local    :  host-31

 

Virtual Machines

web-01a_corp.local    :  vm-225
web-02a_corp.local    :  vm-226
web-03a_corp.local    :  vm-227
app-01a_corp.local    :  vm-217
db-01a_corp.local     :  vm-218
hr-db-01a_corp.local  :  vm-223
fin-db-01a_corp.local :  vm-220
win-xp-01_corp.local  :  vm-228

In the next step, we will 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:

 

 

Show ESXi Hosts Where a Logical Router Exists

 

To display on which ESXi hosts a particular Distributed Logical Router exists, enter the following command:

show logical-router list dlr edge-3 host

The command will return the unique ID of the ESXi host, as well as the FQDN 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 a given ESXi host where a distributed logical router is deployed, run the following commands:

show logical-router host host-29 connection
show logical-router host host-31 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

 

The following command provides a quick way to obtain useful information regarding a DLR on a specific ESXi host:

show logical-router host host-29 dlr edge-3 verbose
show logical-router host host-31 dlr edge-3 verbose

Details such as the name of the DLR, the DLR ID, the number of LIFs, 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

 

Following is another useful command which can display the ARP table for a given DLR on an ESXi host:

show logical-router host host-29 dlr edge-3 arp
show logical-router host host-31 dlr edge-3 arp

Note that the same IP addresses are present across both ESXi hosts. These are the LIF IP addresses or the default gateways of each logical switch. Also of interest are the vMAC addresses of the LIFs, they are identical. The reason for this is simple - when a virtual machine vMotions from one ESXi host to another, the MAC and the IP addresses of the default gateway need to remain unchanged in order for existing flows not to be affected. This vMAC address is not exposed to the physical network.

 

 

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

 

To obtain the routing table for a given logical router on a specific ESXi host, run the following command. This command is especially useful, since there is no need to open a SSH session to each host to retrieve the information.

show logical-router host host-29 dlr edge-3 route
show logical-router host host-31 dlr edge-3 route

Note that the routing table for a particular DLR should be identical across ESXi hosts where that DLR is deployed, this is because the hosts share the same control plane.

 

 

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-1 dlr edge-3 interface

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

 

 

Show Brief Details on a Controller for a Specific Logical Router

 

Run the following command to obtain a summary of DLR configuration and its status on a specific controller:

show logical-router controller controller-1 dlr edge-3 brief

Information shown includes:

In the next lesson, we will explore the simplicity offered by the Central CLI when working with NSX Edge Service Gateways. Specifically, the ability to obtain information about NSX Edges without having to enable SSH on an Edge or having to use console for access.

 

Troubleshooting Edge Service Gateways


NSX Central CLI greatly simplifies the process of obtaining information from Edge Service Gateways (ESGs). ESG-specific information can be retrieved directly from the NSX Manager CLI, rather than having to open SSH sessions or use consoles to manage ESGs individually.

In this lesson we will cover some of the many CLI commands available for troubleshooting Edge Service Gateways.


 

Show all NSX Edge Service Gateways

 

To list all deployed ESGs for a given NSX Manager (this will not show ESGs across linked NSX Manager in a cross-vCenter deployment), run the following command:

show edge all

The values returned refer to the following:

This command helps identify the list of ESGs, as well as their unique identifier (the Edge ID value). In this lesson, we will be using edge-1 (Perimeter-Gateway-01) ESG. Continue to the next step to learn how to retrieve additional information about a specific ESG.

 

 

Show Details of a Specific NSX Edge

 

To get a quick view of what services are enabled on an ESG, input the following command:

show edge edge-1

Returned is the following data:

Note that the routing service is running based on the output of the above command. Let's take a look at some details about how routing is configured.

 

 

Show Routing Service Details on a Specific NSX Edge

 

To show high-level routing configuration of an ESG, run the following command:

show edge edge-1 configuration routing-global

Returned is a JSON message with various high-level details of the routing configuration.

 

 

Retrieve Flow Table for a Specific NSX Edge

 

To display the current flow table of a given ESG, enter the following command:

show edge edge-1 flowtable

Output will show the total number of flows currently active on the ESG and 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 a particular flow.

Use the space bar to scroll through the output or press q on the keyboard to return to the prompt.

 

 

Display BGP Details on a Specific NSX Edge

 

The following command shows dynamic routing information of a particular ESG. In this example BGP details are displayed:

show edge edge-1 ip bgp

In addition to the ability to display dynamic routing details, one can also show the routing table of a given Edge.  This is covered in the next step.

 

 

Display Routing Table Information on a Specific NSX Edge

 

To retrieve the routing table of a particular ESG,  use the following command:

show edge edge-1 ip route

 

 

Display Top 10 Flows per Firewall Rule on a Specific NSX Edge

 

For additional details regarding the firewall configured on an ESG and associated top flows matching a particular firewall rule, use the following command:

show edge edge-1 firewall flows topN 10

Use the space bar to scroll through the output or press q on the keyboard to return to the prompt.

In the next lesson, we will look at the Central CLI commands available for obtaining information about the Distributed Firewall.

 

Troubleshooting Distributed Firewall


As we complete this module, we will look at the available Central CLI commands to use with the Distributed Firewall (DFW).


 

Object IDs

Similarly to the logical switch and logical routing commands, there are a number of unique identifiers that will be referenced while running the DFW commands in the NSX Central CLI.  References follow.

vSphere Clusters

RegionA01-MGMT01     :  domain-c141
RegionA01-COMP01     :  domain-c26
RegionA01-COMP02     :  domain-c201

 

ESXi Hosts

esx-01a.corp.local    :  host-29
esx-02a.corp.local    :  host-31

 

Virtual Machines

web-01a_corp.local    :  vm-225
web-02a_corp.local    :  vm-226
web-03a_corp.local    :  vm-227
app-01a_corp.local    :  vm-217
db-01a_corp.local     :  vm-218
hr-db-01a_corp.local  :  vm-223
fin-db-01a_corp.local :  vm-220
win-xp-01_corp.local  :  vm-228

In the next step, we will learn how to obtain a list of all deployed distributed logical routers.

 

 

Launch the Chrome Web Browser

 

Launch the Chrome browser from the desktop or the taskbar.

 

 

Open vSphere Web Client

 

  1. If the page does not automatically default to the vSphere Web Client page click on the Region A | RegionA vCenter link in the bookmarks bar.

 

 

Log in to the vSphere Web Client

 

If you are not already logged in to the vSphere Web Client:

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

 

 

Enable Traceflow Distributed Firewall Rule

We will first enable the Distributed Firewall rule that blocks communication between web-01a.corp.local (172.16.10.11) and web-02a.corp.local (172.16.10.12). This will allow us to observe the rule as it is applied to the web-01a_corp.local VM. We will use the NSX Central CLI to look at this firewall rule.

 

 

Navigate to Networking & Security

 

  1. In the vSphere Web Client click the Home button.
  2. Click Networking & Security.

 

 

Navigate to Firewall

 

  1. Under Networking & Security click on Firewall.
  2. Click on the + to expand the section called Flow Monitoring & Trace Flow Rules - Disabled by Default.
  3. Flip the toggle switch to green to enable the Flow Monitoring and Traceflow Test rule.
  4. Verify that the Source VM is web-01a_corp.local, the Destination VMs are app-01a_corp.local AND web-02a_corp.local, and that the Service is Any.
  5. Click Publish to push the firewall rules down to the hypervisors.
  6. Verify that the publish operation has completed successfully (Please note the date of your publish will not be identical to the screenshot).

 

 

Show Distributed Firewall Status on all vSphere Clusters

 

Return to the PuTTY session window.

To show the current status of the Distributed Firewall on all clusters, run the following command:

show dfw cluster all

The command output provides the following:

 

 

Show Distributed Firewall Status on a Specific vSphere Cluster

 

Issue the following command to show installation status of the Distributed Firewall service on all hosts in a given vSphere cluster (domain-c26 RegionA01-COMP01 is used in the example):

show dfw cluster domain-c26

The command will return the following details:

 

 

Show Virtual Machines Running on a Host

 

Run the following commands to show the virtual machines running on a particular host (host-29 esx-01a.corp.local and host-31 esx-02a.corp.local are used in the example):

show dfw host host-29
show dfw host host-31

This will provide the following details:

Continue to the next step to gather additional information about the DFW at the VM level.

 

 

Show Distributed Firewall Details for a Specific VM

 

To enumerate the specific DFW filters and the vNICs connected to that VM, run the following command (vm-225 web-01a_corp.local is used in this example):

show dfw vm vm-225

The command output provides the following details:

Important note: the Filter Name nic-69604-eth0-vmware-sfw.2 within your pod may differ from the one in the screenshot or within the rest of the examples this manual. Please use the Filter Name returned within your pod for the remainder of this manual, specifically where <FILTER-NAME> is called out in the CLI commands.

The filter name will be used to obtain additional details pertaining to the DFW rules applied to VM's vNIC in the following steps.

 

 

Generate Traffic to web-01a.corp.local

 

Before continuing we need to generate traffic to web-01a.corp.local, otherwise there may not be any results to review with a No Records Found message.

  1. Open a new tab in the web browser.
  2. Click on the Customer DB App bookmark a few times; five times should be sufficient. This will generate traffic to web-01a.corp.local and the web page will eventually display a 504 Gateway Time-out message because of the firewall rule we enabled earlier.

 

 

Show Rules on a Specific Virtual Machine vNIC

 

Return to the PuTTY session window.

To display the firewall rules associated with a specific filter and attached to a VM's vNIC, run the following command (Filter attached to the vNIC of web-01a VM is used in this example):

show dfw host host-31 filter <FILTER-NAME> rules

Note: Please verify that the Filter Name in this step matches the filter name from step "Show Distributed Firewall Details for a Specific VM"

Notice rule 1006 entry in the output of the command. This is the firewall rule Flow Monitoring and Traceflow Test rule we enabled in the beginning of the lesson; it blocks traffic between Source VM: web-01a_corp.local and Destination VMs: app-01a_corp.local AND web-02a_corp.local, Service: Any.

 

In order to determine the address sets addrset listed in the the firewall rule entry and subsequently used in the filter, run the following command:

show dfw host host-31 filter <FILTER-NAME> addrsets

Note: Please verify that the Filter Name in this step matches the filter name from step "Show Distributed Firewall Details for a Specific VM"

The combined output of the two previous commands confirms the firewall rule we enabled in an earlier step and that:

ANY from addrset ip-vm-225 (172.16.10.11) to addrset dst1006 (172.16.10.12, 172.16.20.11) drop

Where IP addresses 172.16.10.11, 172.16.10.12, and 172.16.20.11 are web-01a, web-02a, and app-01a Virtual Machines, respectively.

 

 

Show Distributed Firewall Statistics for a Specific Virtual Machine vNIC

 

To show usage statistics for a given DFW filter, run the following command (the filter applied to the vNIC of web-01a VM is used here):

show dfw host host-31 filter <FILTER-NAME> stats

Note: Please verify that the Filter Name in this step matches the filter name from step "Show Distributed Firewall Details for a Specific VM"

Displayed are the number of times a particular DFW rule has seen a match. To obtain additional information regarding each flow that matches a given filter, continue to the next step.

 

 

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-31 filter <FILTER-NAME> flows

Note: Please verify that the Filter Name in this step matches the filter name from step "Show Distributed Firewall Details for a Specific VM"

In the above example there are Active flows from the main console (192.168.110.10) going to web-01a (172.16.10.11). There is also a Dropped flow from web-01a (172.16.10.11) going to app-01a (172.16.20.11) over port 8443. Note that in order to see the Dropped flow, switch back to the browser window tab, refresh Customer DB App page and run the above command again in the PuTTY session.

When finished exploring Central CLI, continue to the next step to clean up the lab environment.

 

 

Navigate to Firewall

 

  1. In the vSphere Web Client under Network & Security, click on Firewall.
  2. Click on the + to expand the section called Flow Monitoring & Trace Flow Rules - Disabled by Default.
  3. Flip the toggle switch to grey to disable the Flow Monitoring and Traceflow Test rule.
  4. Click Publish to push the firewall change down to the hypervisors.
  5. Verify that the publish operation has completed successfully (Please note the date of your publish will not be identical to the screenshot).

 

Module 5 Conclusion


In this module we used the NSX Central CLI commands to gather information about Logical Switches, Distributed Logical Routers, Edge Service Gateways, and the Distributed Firewall. Information we have gathered can help with troubleshooting NSX for vSphere deployments.


 

You've Finished Module 5

Congratulations on completing Module 5.

If you are looking for additional information on Central CLI visit the URL below:

Go to https://tinyurl.com/y9ezapa9

Proceed to any module below which interests you the most.

Lab Module List:

 Lab Captains:

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 6 - Endpoint Monitoring (15 minutes)

Introduction to Endpoint Monitoring


In this module we will look at the functionality offered by Endpoint Monitoring, a feature that was introduced in NSX for vSphere 6.3.

Endpoint Monitoring profiles applications inside the Virtual Machine and enables administrators to map specific processes inside the guest OS to the network connections the processes are using.


Endpoint Monitoring Data Collection


A set of VMs that represent an application are selected for profiling using Endpoint Monitoring. The result of the analysis is displayed in the NSX for vSphere UI and includes information about network flows internal and external to the application and the associated processes initiating the flows.


 

Prerequisites

Prerequisites for Endpoint Monitoring:

  1. Supported Guest OS: Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 2008, Windows 2008 R2, Windows 2012, Windows 10, and Windows 2016.
  2. VMware Tools must be running and installed with guest introspection drivers.
  3. Guest Introspection Services deployed through NSX Manager.
  4. Security Groups with 20 or fewer VMs representing an application.  

 

 

Launch the Chrome Web Browser

 

Launch the Chrome browser from the desktop or the taskbar.

 

 

Open vSphere Web Client

 

  1. If the page does not automatically default to the vSphere Web Client page, click on the Region A | RegionA vCenter link in the bookmarks bar.

 

 

Log in to the vSphere Web Client

 

If you are not already logged in to the vSphere Web Client:

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

 

 

Navigate to Networking & Security

 

  1. In the vSphere Web Client click the Home button.
  2. Click Networking & Security.

 

 

Deploy Guest Introspection

 

  1. Under Networking & Security select Installation and Upgrade.
  2. Select Service Deployment tab.
  3. Click + ADD icon to deploy Guest Introspection.

 

 

Guest Introspection Wizard - Select Service

 

  1. Select Guest Introspection service.
  2. Click Next.

 

 

Guest Introspection Wizard - Select Cluster

 

  1. Select RegionA01-COMP01 Cluster.  
  2. Click Next.

 

 

Guest Introspection Wizard - Select Storage and Network

 

  1. Leave default values for the Datastore, Network, and IP Assignment method.
  2. Click Next.

 

 

Guest Introspection Wizard - Review

 

Review setting before finishing the wizard.

  1. Click Finish.

 

 

Verify Installation

 

Wait for the installation to complete. This may take some time.

  1. Click Refresh to update vSphere Web Client UI.
  2. Confirm Installation Status Succeeded and Service Status is Up.

If the Service Status returns Warning, wait an additional few minutes and refresh the vSphere Web Client.

Due to limited resources in the lab, the Service deployment may return a Failed status. In this case proceed to the next step.

 

 

Addressing a Failed Deployment

 

Complete this step ONLY if the service deployment Failed in the previous step, otherwise proceed to the next step.

  1. Select the radio button next to Guest Introspection.
  2. Click Delete. In the resulting window, confirm service deletion by clicking on DELETE.
  3. Wait a few minutes and click the Refresh button in the vSphere Web Client to verify that the service is no longer listed.

Return to Deploy Guest Introspection step to reinstall the Guest Introspection service.

 

 

Verify Guest Introspection Service VMs

 

We will now verify the Guest Introspection Service VM deployment in the Region-A01-COMP01 vSphere cluster.

  1. Click the Home icon in the vSphere Web Client.
  2. Click Hosts and Clusters.

 

 

Verify Guest Introspection VM IP Address

 

  1. Expand the RegionA01-COMP1 cluster.
  2. Expand the ESX Agents resource pool.
  3. Verify Guest Introspection VMs have been deployed on each host. Select Guest Introspection(esx-01.corp.local) VM.
  4. Click on Summary tab.
  5. Click on View all IP addresses link and verify both Guest Introspection VMs have an IP address assigned in the 192.168.100.0/24 range.

 

 

Navigate to Networking & Security

 

  1. In the vSphere Web Client click the Home button.
  2. Click Networking & Security.

 

 

Access Service Composer

 

We will create a Security Group which will be later used for Endpoint Monitoring.

  1. Under Networking & Security click on Service Composer.
  2. Select Security Groups tab.
  3. Click on + ADD icon.

 

 

Create Security Group - Endpoint Windows XP

 

  1. Type Endpoint - Windows XP in the Name field.
  2. Click on Select Objects to Include.

 

 

Create Security Group - Objects to Include

 

  1. Under Object Type, select Virtual Machine.
  2. Use Search function to narrow down results by typing in XP.
  3. Select the check box next to win-xp-01_corp.local.
  4. Click the Right Arrow button to move the VM to Selected Objects window.
  5. Click Finish.

 

 

Start Collecting Data

 

After deploying Guest Introspection and configuring a Security Group we can start collecting data in Endpoint Monitoring.

  1. In the Tools section under Networking & Security, click Endpoint Monitoring.
  2. Click Start Collecting Data in the top right of the screen.

 

 

Select Security Group

 

  1. In the resulting window, click Select your security group here.
  2. In the Select Security Group window, select Endpoint - Windows XP.
  3. Click OK.
  4. Make sure to switch Data Collection to ON.
  5. Click OK.

 

 

Navigate to Hosts and Clusters

 

We will now connect to the win-xp-01_corp.local VM console and generate network traffic.

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

 

 

Open Virtual Machine Console

 

  1. Under RegionA01-COMP01 locate win-xp-01_corp.local VM.
  2. Right-click the win-xp-01_corp.local VM.
  3. Select Open Console.

 

 

Log in to the Virtual Machine Console

 

  1. In the VM's console window, click Send Ctrl+Alt+Delete to open log in prompt.
  2. In the log in screen, provide user name: Administrator and Password: VMware1!
  3. Click OK.

 

 

Generate SSH Traffic

 

  1. Open putty terminal from the desktop of the win-xp-01 VM.
  2. Use 172.16.60.20 as host IP address.
  3. Click Open.

In the resultant session window, accept certificate security alert by clicking Yes and log in as root with password VMware1!

 

 

Generate Web Traffic

 

  1. Open Mozilla Firefox web browser window from the desktop of the win-xp-01 VM.
  2. Open Customer DB-App, Finance-App, HR-App bookmarks from the bookmarks bar.

 

 

Endpoint Monitoring Results

Now that we have generated web and SSH traffic from the Virtual Machine, we can review the summary of collected flows and look at the flow to process mapping.  

If you haven't already, switch back to the vSphere Web Client tab in the web browser.

 

 

Navigate to Networking & Security

 

  1. In the vSphere Web Client click the Home button.
  2. Click Networking & Security.

 

 

Stop Endpoint Monitoring Data Collection

 

  1. In the Tools section under Networking & Security, click Endpoint Monitoring.
  2. Click Stop Collecting Data in the top right of the screen.
  3. Click Yes to confirm that you want to stop the collection process.

 

 

Review Endpoint Monitoring Summary

 

  1. On the Summary tab, Virtual Machine Running section lists the number of VMs we analyzed - one in our case. Also, the summary tab lists the number of Processes Generating Traffic, which are processes generating network traffic. Finally, Flows section shows distribution of flows within and leaving the security group defined in data collection.
  2. Click on the VM Flows tab.

 

 

Endpoint Monitoring VM Flows

 

VM Flows tab displays VMs and associated flows to various destinations. Flows are characterized by whether they are internal or external to the Security Group analyzed by Endpoint Monitoring . This is useful when profiling a set of Virtual Machines as a single application.

  1. Click on win-xp-01_corp.local to display a diagram with the selected VM (blue bubble) as a source of flows and various destinations. Clicking on the line between the bubbles will show additional information about the flow.
  2. Scroll down to display additional portions of the diagram.
  3. Click on Process Flows tab.

 

 

Endpoint Monitoring Process Flows

 

The Process Flows tab shows each process on different VMs generating network traffic, along with process and flow details.

  1. Click on the Process Name firefox.exe to display a flow diagram.
  2. Click on the line connecting the two bubbles

 

 

Process Flow Details

 

The Process Flow Details window provides additional information about each flow, such as the source or destination IP addresses, protocol, and port. Note the destination IP addresses 172.16.10.11, 172.16.60.10, and 172.16.60.20 are web server VMs web-01a, hr-web-01a, and fin-web-01a, respectively.

  1. Click Close.

 

Module 6 Conclusion


In this module we took a brief look at Endpoint Monitoring. We described how it works, went through the prerequisites, and configured an Endpoint Monitoring data collection session for a VM. Endpoint Monitoring enables administrators to profile applications inside the guest OS including visibility into specific processes and their associated network connections.


 

You've Finished Module 6

Congratulations on completing Module 6.

If you are looking for additional information on Endpoint Monitoring visit the following URL:

Proceed to any module below which interests you the most.

Lab Module List:

 Lab Captains:

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 7 - vRealize Network Insight (15 minutes)

Introduction to vRealize Network Insight


 

In this module, we will look at vRealize Network Insight functionality. vRealize Network Insight (vRNI) delivers intelligent operations for software-defined networking and security and helps build an optimized, highly-available, and secure network infrastructure across multi-cloud environments. This platform accelerates microsegmentation planning and deployment, enables visibility across virtual and physical networks, and provides operational views to manage and scale VMware NSX deployments.


 

Use Case: Advanced NSX Operations

 

vRealize Network Insight simplifies NSX operations with intuitive UI and natural language search to quickly pinpoint and troubleshoot issues, as well as best practices for deployment and compliance recommendations.

 

 

Use Case: Security Planning

 

vRealize Network Insight takes the guesswork out of deploying microsegmentation with comprehensive NetFlow assessment to model security groups and firewall rules, actionable recommendations for implementing microsegmentation, and monitoring compliance postures over time. vRealize Network Insight also improves performance and availability with converged visibility across physical and virtual networks.

 

 

Use Case: 360-Degree Visibility

 

vRealize Network Insight provides converged visibility across overlay and underlay, virtual and physical, and private and public clouds. vRNI enables troubleshooting for SDDC environments by integrating deeply with virtual (NSX) and physical layers (physical switches, routers, firewalls), and connecting the dots between the two layers across vendors and clouds.

 

Using vRealize Network Insight to Manage the SDDC


In this lesson, we will briefly cover the three primary use cases for vRealize Network Insight:

Please note that due to the dynamic nature of virtualized environment, screenshots used in examples throughout this lesson may not be identical to what you see in your pod.


 

Open Google Chrome

 

From the control center desktop, launch Google Chrome.

 

 

Open vRealize Network Insight

 

  1. Click on the vRealize Network Insight bookmark in the bookmarks bar.

 

 

Log in to vRealize Network Insight

 

  1. For login credentials, use admin@local as the user name and VMware1! as password.
  2. Click Login.

 

 

vRNI Main Page Overview

 

The main page of vRNI provides a contextual overview of all objects monitored by vRNI.

  1. vRNI provides an advanced, but easy to use Search functionality to help investigate any object or flow monitored by the platform.
  2. From the Plan section, an administrator can easily launch security planning dashboards.
  3. Operate & Troubleshoot section lists existing virtual infrastructure objects.
  4. Open Problems widget shows infrastructure problems recently detected by vRNI.
  5. What's Happening widget provides a quick overview of flows, security group changes, and status of NSX deployments.
  6. Hover your mouse over left side of the screen to open a detailed view of all objects and functionality offered by vRNI.
  7. Click on VMware NSX Manager under Operate & Troubleshoot section.

 

 

Select NSX Manager

 

When monitoring multiple NSX Managers using a single vRNI deployment, the NSX managers and associated information would be listed on this screen. This simple interface can provide a lot of useful information for troubleshooting and planning purposes. Note the following attributes displayed in the example.

  1. Search bar automatically populated with the object displayed, nsx in this example.
  2. vCenter Server this NSX Manager is connected to.
  3. Role of the NSX Manager. Values can show Primary, Secondary, Standalone, or Transit depending on the NSX deployment type or status.
  4. Version of the NSX manager.
  5. Segment Ranges indicates the VNI ranges assigned to this NSX Manager.
  6. Number of detected alerts or configuration issues reported next to Problems.
  7. Click on the 192.168.110.42 NSX Manager.

 

 

Advanced NSX Operations

 

Let's briefly review the NSX Manager advanced operations screen. Note the following attributes:

  1. Search bar automatically populated with the object displayed, NSX-V Manager '192.168.110.42' in this example.
  2. Timeline can be adjusted to show longer time range and displays configuration changes or issues detected on this NSX Manager as color-coded bars on the timeline.
  3. Key Properties of the selected NSX Manager such as software version, VNI segment range, Transport Zone, Backups, etc.
  4. NSX Checklist Rules displays a list of configuration best practices that all deployed components of this NSX Manager are checked against.
  5. Infrastructure Problems lists any detected infrastructure issues, which may result from misconfiguration or failures.
  6. Non Infrastructure Problems lists any detected non-infrastructure issues, which may result from misconfiguration or failures.
  7. Topology displays deployed NSX component, associated entities (such as vCenter, hosts, and clusters) and any Problems triggered for any of the components.
  8. Click on Firewall in the Topology widget.

 

 

Firewall Service Status

 

The resultant window shows an overview of the NSX Firewall service deployment. Note 1 Problem is being detected by vRNI. This problem is a result of vRNI running NSX Checklist Rules against this NSX Manager configuration and determining that All traffic allowed by default firewall rule warning should be triggered, because the Default Any-Any distributed firewall rule is set to Allow.

  1. Click on the X in the top right of the informational window to close it.

After exploring NSX Manager advanced operations, continue to the next step to learn about 360-Degree visibility.

 

 

360-Degree Visibility - Path Selection

 

In the next steps, we will take a brief look at path information between two Virtual Machines.

  1. Move the mouse to the left side of the screen for the slide-out menu. Hover the mouse pointer over Path and Topology until the submenu appears.
  2. Click on Path.

 

 

360-Degree Visibility - Virtual Machines Selection

 

In the Path window, set the following values:

  1. For Source, use the drop-down box to select web-01a_corp.local. Note: vRNI has a very intuitive interface, start typing the name of the VM in the drop-down box to filter results.
  2. For Destination, use the drop-down box to select app-01a_corp.local. Start typing the name of the VM in the drop-down box to quickly filter results.
  3. Click Submit.

Note in this screen, there is an option to select Custom Time; this is useful in troubleshooting scenarios where communication between two VMs was affected after a particular event, for example after a vMotion. Comparing paths before and after such events using Custom Time can greatly help in root cause analysis.

 

 

360-Degree Visibility - View Path

 

Path between the selected VMs is shown in the resultant VM Path Topology window. Of interest are the following elements:

  1. Search bar automatically populated with the path selected, VMware VM 'web-01a_corp.local' to VMware VM 'app-01a_corp.local' in this example.
  2. All objects provide contextual information by hovering the mouse over the object or clicking on the object.
  3. In this example, we have selected VMs connected to two different NSX logical switches with a NSX Edge Services Gateway routing between the logical switches. These objects are displayed in the path topology.
  4. The three boxes in the VM Path Topology widget are ESXi hosts where the Virtual Machines and the ESG reside.
  5. Scroll down using the scroll bar. To explore additional submenus, such as Events, Flows, Metrics, etc.

Note, because this is a nested virtual environment, no physical routers or switches are displayed. In production vRNI deployments, these components would be visible and part of the VM Path Topology and VM Underlay widgets, if added to vRNI as data sources.

After exploring Path Topology between the two VMs, continue to the next step to learn about microsegmentation planning in vRNI.

 

 

Navigate to Plan Security

 

In the next steps, we will take a brief look at the security planning functionality available in vRNI.

  1. Move the mouse to the left side of the screen for the slide-out menu. Hover the mouse pointer over Security until the submenu appears.
  2. Click on Plan Security.

 

 

Plan Security - Scope

 

In Plan Security you have the option to set the scope (vSphere Cluster, NSX Security Group, AWS VPC, etc.) and the time range for collected IPFIX data to be used in the analysis.

  1. Keep the defaults and click Analyze.

 

 

Plan Security

 

Note the following widgets and attributes in the Plan Security page:

  1. The Search bar automatically populated with plan security in last 24 hours in this example.
  2. Traffic Distribution (by Total Bytes) widget displays distribution of traffic as it relates to the selected scope. Of note is the East-West tile - showing flows that stayed inside the datacenter and Internet/North-South tile, which describes traffic leaving the datacenter.
  3. Top Ports by Bytes highlights most utilized ports by bytes in the selected scope.
  4. Micro-Segments widget visually represents flows among various groups in a pie chart.
  5. Group By allows administrators to choose the grouping mechanism (VLAN/VXLAN, Application, Security Group, etc.) on how to display the widget. By modifying Flow Type, administrators can identify flows based on whether they were allowed, blocked, protected, or unprotected by the Distributed Firewall.
  6. Hover the mouse pointer over App_Tier_Logical_Switch. Note the color-coded lines, which represent direction of the flow, and identify connections to DB_Tier_Logical_Switch and from Web_Tier_Logical_Switch.
  7. Click on Keep Focus below App_Tier_Logical_Switch pop-up menu to help keep the flows in the widget from shifting to other groups.
  8. Click on the Yellow Line, which connects Web_Tier_Logical_Switch and App_Tier_Logical_Switch.

 

 

Flows Between Web Tier and App Tier Logical Switches

 

In this example we can see all flows observed by vRNI between the two logical switches as well as flow information, such as count of flows and bytes transferred.

  1. Click on Recommended Firewall Rules.

 

 

 

Based on IPFIX flow data sent by various sources, such as vSphere Distributed Switches, NSX Distributed Firewall, and physical equipment capable of generating NetFlow metadata, vRNI can analyze the flows and produce recommended firewall rules, which can then be implemented.

  1. Click on the + to the right of the recommended firewall rule to expand the recommendation and and check whether a matching rule already exists in the NSX Distributed Firewall. The only matching rule in this example is the Default Rule, which allows all traffic.
  2. Click on the X in the top right of the Flows window to close it.

 

 

Plan Security for App Tier Logical Switch

 

  1. In the Micro-Segments widget, click on the App_Tier_Logical_Switch slice.

 

 

App Tier Services

 

In this window, we can identify the services provided by VMs within the selected group and the following details:

  1. Service Endpoints displays the VM name, associated IP address as well as the Layer 4 port number of the service.
  2. Count of Flow shows the number of flows accessing this service.
  3. Sum of Bytes provides the summation in bytes of data transferred over the selected time period.
  4. Max of Traffic Rate shows the highest traffic rate for the service.
  5. Click on the number below External Services Accessed.

 

 

App Tier External Services

 

In this window, we can identify external services accessed by VMs from the selected group.

  1. Service Endpoints displays the VM name, associated IP address as well as the Layer 4 port number of the external service. Note that if the service is not a VM, only the IP address is displayed.
  2. Count of Flow shows the number of flows accessing this service.
  3. Sum of Bytes provides the summation in bytes of data transferred over the selected time period.
  4. Max of Traffic Rate shows the highest traffic rate for the external service.
  5. Click on the number below Flows (Incoming and Outgoing).

 

 

App Tier Flows

 

The Incoming and Outgoing Flows window shows all flows entering and leaving the selected scope over the specified time period in a visual format while displaying the direction of the flow as well as the service.

  1. Hover the mouse pointer over the graph to display time-specific information for traffic rate and bytes transferred.
  2. Click on the + to the right of the flow summary to display additional information about the flow.
  3. Click on the number below Recommended Firewall Rules.

 

 

 

Based on IPFIX flow data generated by various sources, such as vSphere Distributed Switches, NSX Distributed Firewall, and physical equipment capable of generating NetFlow metadata, vRNI can analyze the flows and produce recommended firewall rules which can then be implemented.

  1. Click on the + to the right of each recommended firewall rule to expand the section. This is also a way to check whether a matching rule already exists in the NSX Distributed Firewall.
  2. Click on the X in the top right of the Services and Flows window to close it.

We have briefly covered capabilities and use cases for vRealize Network Insight. For a much deeper exploration of vRNI, visit the following lab:

HOL-1902-02-CMP Network Insight - Getting Started

 

Module 7 Conclusion


In this module, we briefly looked at the capabilities offered by vRealize Network Insight. The specific use cases we covered included Advanced NSX Operations, 360-Degree Visibility into virtual and physical networking and security stacks, as well as the Security Planning capabilities.


 

You've Finished Module 7

Congratulations on completing Module 7.

If you are looking for additional information on vRealize Network Insight visit the following URL:

Proceed to any module below which interests you the most.

Lab Module List:

 Lab Captains:

 

 

How to End Lab

 

To end your lab click on the END button.  

 

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-1903-03-NET

Version: 20181104-103459