VMware NSX-T

Introduction

VMware NSX-T™ Data Center provides an agile software-defined infrastructure to build cloud-native application environments. NSX-T Data Center focuses on providing networking, security, automation, and operational simplicity for emerging application frameworks and architectures that have heterogeneous endpoint environments and technology stacks.

VMware NSX

VMware NSX is a network virtualization and security platform that enables the virtual cloud network, a software-defined approach to networking that extends across data centers, clouds and application frameworks.

VMware NSX is suitable for all infrastructure types:

• Multi-cloud environments
• On-premises data centers
• Bare metal servers
• Containerized workloads

Benefits of NSX-T

The main benefit is that NSX-T can be deployed in heterogeneous environments with many different components. NSX-T is not under the confines of the vCenter deployment. You can have multiple vCenter servers and use one NSX manager as a single pane of glass for controlling your virtual network. Or, you do not have to deploy a vCenter at all. Instead, you can choose ESXi as the operating system in the NSX-T GUI.

NSX-T Main Components:

The primary components of VMware NSX-T are:

• NSX-T Manager: provides graphical user interface (GUI) and RESTful API for creating, configuring, and monitoring NSX-T components, such as segments and gateways.

• NSX-T Controller: they are responsible for the programmatic deployment of virtual networks across the entire NSX-T architecture, and control the virtual networks and overlay transport tunnels.

• NSX-T Edges: provides routing services and connectivity to networks that are external to the NSX-T deployment.

• Logical Firewall: NSX-T handles traffic in and out of the network according to firewall rules.

• Logical Routers (Gateways): NSX-T Gateways provide North-South connectivity so that workloads can access external networks and East-West connectivity between different logical networks.

• Transport Zone: A transport zone defines a collection of hosts that can communicate with each other across a physical network infrastructure.

Prerequisites

• OpsRamp Classic Gateway 14.0.0 and above.
• OpsRamp Nextgen Gateway 14.0.0 and above.
  Note: OpsRamp recommends using the latest Gateway version for full coverage of recent bug fixes, enhancements, etc.

Hierarchy of NSX-T resources

NsxT Manager Cluster
    – NsxT Manager (i.e, nodes)
    – NsxT Edge Cluster
        – NsxT Logical Router
            – NsxT Firewall
    – NsxT Transport Zone
        – NsxT Transport Node (i.e, Host(ESXi) nodes & Edge nodes)
            – NsxT Edge Physical Network Interface
            – NsxT Host Physical Network Interface
            – NsxT Virtual Machine (i.e, Host & Edge VMs)
        – NsxT Logical Switch

Supported Metrics

Application Migration

1. Check for the gateway version as a prerequisite step - classic gateway-12.0.1 and above.
   Notes:

   • You only have to follow these steps when you want to migrate from sdk 1.0 to sdk 2.0.
   • For the first time installation below steps are not required.

2. Disable all configurations associated with sdk 1.0 adaptor integration application.

3. Install and Add the configuration to that sdk 2.0 application.
   Note: refer to Configure and Install the VMware NSX-T Integration & View the VMware NSX-T Details sections of this document.

4. Once all discoveries are completed with the sdk 2.0 application, follow any one of the approaches.

   • Direct uninstallation of the sdk 1.0 adaptor application through the uninstall API with skipDeleteResources=true in the post request
     
     End-Point: https://{{host}}/api/v2/tenants/{tenantId}/integrations/installed/{installedIntgId}
     
     Request Body:

         {
         "uninstallReason": "Test",
         "skipDeleteResources": true
         }

     
     
     (OR)
     
     
   • Delete the configuration one by one through the Delete adaptor config API with the request parameter as skipDeleteResources=true
     
     End-Point: https://{{host}}/api/v2/tenants/{tenantId}/integrations/installed/config/{configId}?skipDeleteResources=true.
     
     
   • Finally, uninstall the adaptor application through API with skipDeleteResources=true in the post request.
     
     End-Point: https://{{host}}/api/v2/tenants/{tenantId}/integrations/installed/{installedIntgId}
     
     Request Body:

         {
         "uninstallReason": "Test",
         "skipDeleteResources": true
         }

Default Monitoring Configurations

VMware-NSX-T has default Global Device Management Policies, Global Templates, Global Monitors and Global Metrics in OpsRamp. You can customize these default monitoring configurations as per your business requirement by cloning respective Global Templates and Global Device Management Policies. It is recommended to clone them before installing the application to avoid noise alerts and data.

1. Default Global Device Management Policies

   You can find the Device Management Policy for each Native Type at Setup > Resources > Device Management Policies. Search with suggested name in global scope. Each Device Management Policy follows below naming convention:

   {appName nativeType - version}

   Ex: vmware-nsx-t NsxT Manager Cluster - 2 (i.e, appName = vmware-nsx-t, nativeType = NsxT Manager Cluster, version = 2)

2. Default Global Templates

   You can find the Global Templates for each Native Type at Setup > Monitoring > Templates. Search with suggested names in global scope. Each template follows below naming convention:

   {appName nativeType 'Template' - version}

   Ex: vmware-nsx-t NsxT Manager Cluster Template - 2 (i.e, appName = vmware-nsx-t, nativeType = NsxT Manager Cluster, version = 2)

3. Default Global Monitors

   You can find the Global Monitors for each Native Type at Setup > Monitoring > Monitors. Search with suggested name in global scope. Each Monitors follows below naming convention:

   {monitorKey appName nativeType - version}

   Ex: NsxT Manager Cluster Monitor vmware-nsx-t NsxT Manager Cluster 2 (i.e, monitorKey = NsxT Manager Cluster Monitor, appName = vmware-nsx-t, nativeType = NsxT Manager Cluster, version = 2)

Configure and Install the VMware NSX-T Integration

1. From All Clients, select a client.
2. Navigate to Setup > Account.
3. Select the Integrations tab.
4. The Installed Integrations page, where all the installed integrations are displayed. Click + ADD on the Installed Integrations page.
5. If you do not have any installed applications, you will be navigated to the Available Integrations page. The Available Integrations page displays all the available applications along with the newly created application with the version.
   Note: Search for the application using the search option available. Alternatively, use the All Categories option to search.
6. Click ADD in the VMware NSX-T application.
   Note: Select the version from the drop down menu.
7. In the Configurations page, click + ADD. The Add Configuration page appears.
8. Enter the following BASIC INFORMATION:

Notes:

• By default the Is Secure checkbox is selected.
• NSX-T Manager IP Address and Port should be accessible from Gateway.
• Select the following:
  • App Failure Notifications: If turned on, you will be notified in case of an application failure that is, Connectivity Exception, Authentication Exception.
  • Event/Alert Polling: Enables integrating third party alerts into OpsRamp using further configurations.
    • Below are the default values set for:
      • Alert On Root Resource: Alerts generated by on root resource, when checked.
        • Event/Alert Cleared Status: Possible values of Event/Alert Cleared Status configuration property are “ACKNOWLEDGED”,“SUPPRESSED”,“RESOLVED”.
        • Event/Alert Severity: Possible values of Event/Alert Severity configuration property are “CRITICAL”,“HIGH”,“MEDIUM”,“LOW”.
        • Event/Alert Severity Mapping: Possible values of Event/Alert Severity Mapping Filter configuration property are “CRITICAL”:“Critical”,“HIGH”:“Warning”,“MEDIUM”:“Warning”,“LOW”:“Info”.
  • API Timeouts: These are the maximum API Timeouts that the application can use to connect and get responses from the end device.
    • Connection Timeout in Secs: a time period in which a client should establish a connection with a server.
      Note: By default, 60 is selected.
    • Connection Request Timeout in Secs: a time period required to process an HTTP call: from sending a request to receiving a response.
      Note: By default, 10 is selected.
    • Socket Timeout in Secs: a maximum time of inactivity between two data packets when exchanging data with a server.
      Note: By default, 10 is selected.

9. Select the following Custom Attribute:

Note: The custom attribute that you add here will be assigned to all the resources that are created by the integration. You can add a maximum of five custom attributes (key and value pair).

10. In the RESOURCE TYPE section, select:
    • ALL: All the existing and future resources will be discovered.
    • SELECT: You can select one or multiple resources to be discovered.
11. In the DISCOVERY SCHEDULE section, select Recurrence Pattern to add one of the following patterns:
    • Minutes
    • Hourly
    • Daily
    • Weekly
    • Monthly
12. Click ADD.

Now the configuration is saved and displayed on the configurations page after you save it. From the same page, you may Edit and Remove the created configuration.

13. Under the ADVANCED SETTINGS, Select the Bypass Resource Reconciliation option, if you wish to bypass resource reconciliation when encountering the same resources discovered by multiple applications.

    Note: If two different applications provide identical discovery attributes, two separate resources will be generated with those respective attributes from the individual discoveries.

14. Click NEXT.

15. (Optional) Click +ADD to create a new collector by providing a name or use the pre-populated name.

16. Select an existing registered profile.

17. Click FINISH.

The application is installed and displayed on the INSTALLED INTEGRATION page. Use the search field to find the installed integration.

Modify the Configuration

• See Modify an Installed Integration or Application article.

  Note: Select the VMware NSX-T application.

View the VMware NSX-T Details

To discover resources for VMware NSX-T

1. Navigate to Infrastructure > Search > Software Defined Network > VMware NSX-T.
2. The VMWARE NSX-T page is displayed, select the application name.
3. The RESOURCE DETAILS page appears from the right.
4. Click the ellipsis (…) on the top right and select View details.
5. Navigate to the Attributes tab to view the discovery details.

• Click the Metrics tab to view the metric details for VMware NSX-T.

Resource Filter Input Keys

VMware NSX-T application resources are filtered and discovered based on below keys:

Supported Alert Custom Macros

Customize the alert subject and description with below macros then it will generate alert based on customisation.
Supported macros keys:

Risks, Limitations And Assumptions

• Application can handle Critical/Recovery failure notifications for below two cases when user enables App Failure Notifications in configuration
  • Connectivity Exception
  • Authentication Exception
• Application will send any duplicate/repeat failure alert notification for every 6 hours.
• The unique ID for the firewall has been changed from the Manager API to the Policy API. Consequently, during the migration of NSX-T devices from manager to policy mode, existing firewalls created using the Manager API will be removed, and new firewalls utilizing the Policy API will be created.
• Application cannot control monitoring pause/resume actions based on above alerts. Metrics can be used to monitor the resources and can generate alerts based on the threshold values.
• vmware-nsx-t Event/Alert polling will be started only if the user enables Event/Alert Polling in configuration.
  Notes:
  • Here Event/Alert polling support is given for vmware-nsx-t Alarms only.
  • When a status value which presents in Event/Alert Cleared Status field occurs, OpsRamp will create an Ok alert accordingly. Otherwise, OpsRamp will create an alert based on Event/Alert Severity Filter & Event/Alert Severity Mappings of the Event/Alert Polling configurations.
• Application will publish event polling alerts on root resource if Alert on root resource is checked in the configuration, else alert will be published on respective resource.
• Default values of Event/Alert Cleared Status configuration field are: ACKNOWLEDGED, SUPPRESSED, RESOLVED.
• Possible vmware-nsx-t status values are OPEN, ACKNOWLEDGED, SUPPRESSED, RESOLVED.
• Default/Possible values of Event/Alert Severity Filter configuration are CRITICAL, HIGH, MEDIUM, LOW.
• We have provided default mappings to map vmware-nsx-t Severity with OpsRamp Severities as part of Event/Alert Severity Mapping configuration.
• Users can modify them as per their use-case at any point of time from the application configuration page. Possible OpsRamp Severities are Critical, Warning, Ok, Info.
• No support of showing activity logs.
• The Template Applied Time will only be displayed if the collector profile (Classic and NextGen Gateway) is version 18.1.0 or higher.
• This application supports both Classic Gateway and NextGen Gateway.
• Below are the possible reasons for tunnel status related metrics of Transport Node can go missing:
  • Transport nodes which are connected to only VLAN transport zones wont have tunnel status metrics.
  • Tunnels are not setup when no NSX backed/ overlay VM is connected to the host.
  • BFD module could be errored and wiped all BFD tunnel related information.
    Transport node tunnel status related metrics

    nsxt_transportNode_TunnelStatus nsxt_transportNode_TunnelUpCount nsxt_transportNode_TunnelDownCount nsxt_transportNode_BfdAdminDownCount nsxt_transportNode_BfdDownCount nsxt_transportNode_BfdInitCount nsxt_transportNode_BfdUpCount nsxt_transportNode_BfdNoDiagnosticCount nsxt_transportNode_BfdControlDetectionTimeExpiredCount nsxt_transportNode_BfdEchoFunctionFailedCount nsxt_transportNode_BfdForwardPlaneResetCount nsxt_transportNode_BfdPathDownCount nsxt_transportNode_BfdConcatenatedPathDownCount nsxt_transportNode_BfdAdministrativeDownCount nsxt_transportNode_BfdReverseConcatenatedPathDownCount nsxt_transportNode_BfdNeighbourSignalledSessionDownCount
• Latest snapshot metric support from Gateway 14.0.0.

Troubleshooting

Before troubleshooting, ensure all prerequisites prerequisites are met.

If VMware NSX-T integrations fails to discover or monitor, troubleshoot using the following steps:

• Check if any alerts have been generated on the NSX-T resource or gateway, or if there are any error logs in vprobe.
• If there is an error or alert related to the end device connectivity or authentication, try checking the reachability of the end device from the gateway with the following commands:
  • to ping the IP address provided in the configuration: {ping <IP Address>}
  • to try telnet: {telnet <IP Adress> <Port>}
  • To run an API:

    • Prepare the request payload by using below sample request: { “apiVersion”: “debug/v1”, “module”: “Debug”, “app”: “poly-trio”, “action”: “Reachability”, “payload”: { “ipAddressOrHostName”: “”, “protocol”: “https”, “port”: 443, “requestPath”: “”,

      “version”:“v1”,

      “requestMethod”:"<get/post>", “userName”: “”, “password”: “” } }

    • Encode the request payload to base64

    • Log in to the gateway concole and connect to the GCLI terminal using the below command: {## gcli}

    • Run the command using the previously generated base64 encoded string {## sdkappdebug <base64 encoded string>}

Version History