Integrated Tools
ReSTNSX Features
Quick and Easy ReSTNSX provides an exceptional experience for NSX automation and day 2 operations for both NSX-v and NSX-T. In addition to these core capabilities, ReSTNSX also has numerous integrated tools for enhanced troubleshooting and 3rd party integrations. Each tool was designed with the user experience in mind - eliminating the need for multiple 3rd party tools and scripting.
One of design principles of ReSTNSX is to integrate processes and tools into a single, unified platform for NSX provisioning, day 2 operations and troubleshooting. Many tools are natively incorporated into the management function for a given device, object or policy. One example of an integrated troubleshooting function is shown below were ESG NAT troubleshooting commands are quickly and easily launched from the management dashboard with a single click. This alleviates the need for jumping into another application just to see the status of this feature. ReSTNSX will execute the appropriate commands to get the user the information needed relative to their location in the application. In this example, "show edge <edge-id> nat" was run via Central CLI on behalf of the user for a given ESG (ESG-2).
In addition to the object and device-level tools, ReSTNSX also provides a series of standalone tools within the application to perform actions that would normally be purchased or developed separately. By doing so, ReSTNSX becomes your single management point for NSX. Below are just a few examples of these tools.
vRNI Flow Analyzer
Firewall Conversion
Central CLI
API Scout
Policy Engine
Rule Analyzer
Cloud Check
vRealize Network Insight (vRNI) Flow Analyzer
VMware's vRNI is one source for gathering application flows in preparation for developing NSX dFW rules as it has visibility into both physical and virtual IPFIX data. Unfortunately, with NSX or vRNI, there is no easy or automated method to filter, combine, edit and publish rules to NSX.
ReSTNSX's Security Planner for vRNI addresses all of these limitations with a simple 3 step process to transform live flow data to NSX policy.
Step 1: Define flow collection criteria
In this step, users can select the source (vCenter cluster) as defined by vRNI. Addition options include:
- Max results
- Flow type (North/South, East/West or Both)
- Rule optimization options for auto combining flows with like IP Destinations, IP Sources or TCP/UDP Destinations (Services)
- Date Range for flows to collect (up to 30 days)
- Exclusions to filter flows for specific IP, TCP/UDP ports from the collection
In this example, the user has chosen to collect East-West flows from the 'Demo' cluster while auto combining flows that share the same IP Destination for the last 30 days
The user has also applied an exclusion filter to omit flows that contain destination TCP or UDP port not equaling 123. Up to 5 criteria may be added per collection.
Step 2: Review and Edit Suggested Rules
Once executed, ReSTNSX will reach out to vRNI in real-time to collect the requested data, analyze and optimize based upon the user settings. A dashboard is presented to show all the collected flows and the status of the current collection. When the collection and analysis is done, the user can click the magnifying glass to inspect the results.
Let's go look at the collected flows. Here we can see the optimizations that occurred (10 flows reduced to 5 based upon combining like destinations) and any removed duplicate flows if present.
During this step, the user can further manipulate the data prior to publishing - including merging raw IPs into NSX IP Sets; merging rules together and resolving the IPs to VM-ID.
Step 3: Publish to NSX
Once the rule sets have been verified, the user can do a one-click publish to the active NSX-v or NSX-T data source. Note: these same rule sets can be published against multiple NSX Managers.
Verify in ReSTNSX and NSX Manager
3rd Party Firewall Rule Conversion
If you are you trying to migrate security policy from another vendor to NSX you have likely noticed that it is not an easy task. Although rule anatomies are similar across vendors, the referenced objects and options are vastly different. Normalizing policy that can be migrated to NSX is difficult, time consuming and an entirely manual effort. Even with scripting, transformation logic is needed to convert these policy and objects.
ReSTNSX's Security Planner for Firewall Rule Conversion has you covered. Similar to other ReSTNSX tools, it is a 3 step process to migrate your configs.
Step 1: Import Firewall Configuration File
In this example, we will convert a Cisco ASA 9.2 firewall rule set to NSX-v. The user captures a "show run" from the ASA and saves it to a text file for upload.
Sample ASA config snippet
Step 2: Review and Edit Suggested Rules
Similar to the vRNI Planner, ReSTNSX provides a dashboard of all imported configs where the user can drill down further to see the conversion.
Sample conversion showing network and service objects, object groups being staged for creation in NSX
Step 3: Publish to NSX
Select one or many rules to publish to NSX. Note: each rule name is created as a dFW section for easy grouping of like rules. Once the user clicks publish, ReSTNSX creates all dependent objects (IP Sets, Services, Service Groups) as needed and associates them to the respective rules. For any service not defined in NSX, ReSTNSX will create using the IANA defined protocol and port numbers.
Publishing to the following destinations is supported:
- NSX-v: dFW, Edge Service Gateways
- NSX-T: dFW, Tier 0s, Tier 1s
Central CLI
Command Line Interfaces (CLI) are extremely powerful when looking at details of an environment or when troubleshooting a problem. Just like most vendors, NSX provides CLI access to NSX components using their own command syntax. As a result, users must learn the vendor specific commands. In a troubleshooting situation, users must navigate between CLI windows and the NSX UI to get a complete picture of the environment.
ReSTNSX's Central CLI enables these commands through the web interface while providing a point and click feature that alleviates the need for memorizing command syntaxes. With this approach, users do not need to open up separate Telnet/SSH sessions to access the NSX CLI.
Easy buttons
A series of pre-defined CLI command buttons are provided to the user for the most common commands. Users can also save any call to their favorites list.
In this example, the user clicked the "Logical Switches" button and ReSTNSX ran the command "show logical-switch list all"
ReSTNSX also provides intelligent hyperlinks to drill down further for information.
Intelligent Hyperlinks
Throughout the ReSTNSX Central CLI experience, the user is clicking their way to information without needing to type a command. CLI input is also available for the die-hard CLI users.
API Scout
For those of you who script or provision / monitor NSX components through API understand the complexities of the different authentication requirements and variations in API calls. NSX-v, NSX T and vCenter all have different requirements for connectivity that can be cumbersome to manager.
ReSTNSX enables users to execute GET, POST and PUT API calls against any of the defined data sources without needing to worry about auth tokens or the URI for the most common calls. These calls are executed against the active data source selected in ReSTNSX. Options within the tool also include the ability to define per-user favorites for NSX and vCenter along with per-user URI history.
GET IP Sets selected from the Favorites list. No URI knowledge needed.
For JSON responses, prettified responses with expandable/collapsable sections and color coded attributes
Policy Engine
When it comes to security, consistent policy enforcement is paramount where workloads can dynamically move between environments. As workloads move, enforcing security can be difficult - often requiring manual intervention or custom scripting.
Policy Engine can copy sections, rules, objects (NS Groups, Services) from one NSX domain to another. Options include NSX-v to NSX-v, NSX-T to NSX-T, NSX-T to VMware Public cloud. ReSTNSX policies can be used for a one time copy (migration) or provide ongoing updates to keep non-cross vCenter (NSX-v) or non-Federated (NSX-T) environments up to date
ReSTNSX's Policy Engine allows a global view of policy enforcement across multiple NSX-v and/or NSX-T environments.
Step 1: Define the basics of a policy
In this step, users provide a policy name, description and interval for how often to run the job.
Step 2: Add Source(s), Destination(s) and Object(s) for synchronization
This step defines what object(s) to sync and in which direction. In this example, we are defining NSX 6.4 - Security Group '1-Source' as a source Security Group and NSX 6.3 Security Group '1-Destination Group' as the destination.
Policy direction can be set to:
Push Only: The NSX Manager will only send out the select objects to the configured destination(s)
Pull Only: The NSX Manager will only receive the select objects from the configured source(s)
Bi-Direction: The NSX Manager will send and receive the selected objects from the configured source(s) and destination(s)
Additionally, we have selected the Synchronization Method as 'Effective Members' for the maximum flexibility. In this mode, the effective members of the source Security Group(s) are extracted and a master IP Set is created and maintained. Once that has been calculated, the IP Set is added to each destination Security Group. The result is a consistent Security Group membership list - regardless of if the object in question resides in the local inventory.
Note: The policy will not execute until it is manually enabled, even if the interval criteria has been met.
Step 3: Enable Policy
Once enabled, the countdown starts from the configured interval setting. In the example, the interval was set to 30 minutes. Optionally, a manual sync is available for immediate policy enforcement. To see the results immediately, the user in this situation manually sync'ed the policy. As a result, the NSX 6.3 Manager was updated with the effective members of the 6.4 Security Group via an IP Set membership. Now both sites has the same exact policy if this Security Group was referenced in a dFW rule.
Policy Deletion
Upon policy deletion, the user is prompted to delete the dynamically created objects (destination IP Sets in this example) to revert back to the state prior to the policy definition.
Rule Analyzer
Not knowing if your firewall rule set is still relevant is frustrating and often requires third party tools to gain visibility into the metrics for rule analysis.
ReSTNSX's Rule Analyzer provides section-by-section and rule-by-rule views of policy data for NSX-v and/or NSX-T environments. This data includes a rule break-down of source/destination types, hit counts, bandwidth* and other Top N Charts.
*NSX-T only
Step 1: Per NSX Manager dFW Overview
Step 2: Select a specific section for more details, including raw rule statistics, stale rule analysis and Top N Charts
Cloud Check
If you are moving a workload to the cloud or just not sure what dependencies exist between your application and other resources, ReSTNSX' Cloud Check provides visibility into traffic to and from a Virtual Machine. By leveraging vRNI or dFW flow data, users can easily determine these dependencies.
Step 1: Select one or more Virtual Machines to be monitored. Options for the flow source include vRNI and dFW (NSX-v).
In this example, we will select dFW as the source for flow information and VM with IP 192.168.1.224 with data collection period for 1 minute. Collection intervals for real-time analysis (dFw or vRNI) range from 1 minute to 24 hours. One of the benefits of selecting dFW as the source is that all packets are seen as compared to IPFIX/Netflow collection (vRNI method). IPFIX/Netflow is known to provide blind spots in traffic flows as the data is sampled.
If vRNI is selected, historical data can also be analyzed for up to 30 days in the past.
Step 2: Watch the collection and analysis in real-time.
ReSTNSX is fetching and analyzing the data on a 5 second interval. In this example, new flows are detected and presented in charts, tables and relationship diagrams. Once the collection is finished, the data will remain in the data base for future review until removed by the user on the collection dashboard.
Flow Relationship Diagram
That's it! Full visibility into flow data for planning your workload migration with ReSTNSX's Cloud Check.