Make Your Life Easier with the NSX-T Central CLI

Now that VMware NSX-T Data Center is deployed in your environment and that you are consuming its network and security services such as switching, routing, firewalling or load balancing, what about day 2 operations?

Although I’m a big advocate of API and automation, there are some operations or some scenarios where it’s required (or more natural) to use a CLI (command-line interface). It turns out that each NSX-T component contains a CLI (which is documented here). The NSX-T CLI can be invoked as follows:

• NSX Manager, Controllers, Edges: CLI is launched by default when logged with admin privileges (on the console or through SSH).
• Fabric nodes (hypervisors or bare-metal): type nsxcli (need root privilege for KVM and bare-metal).

However, running separate command lines on different NSX-T components may be time-consuming and quickly dull. This is where the NSX-T Central CLI comes to the rescue to facilitate operations and troubleshooting. In a nutshell, this capability allows NSX-T administrators to:

• Run CLI commands from the Manager that get information from one or multiple cluster / fabric nodes (such as controllers, edges, fabric nodes).
• Run the same command on multiple nodes simultaneously.

NSX-T Central CLI Usage

The Central CLI is only mentioned quickly in the NSX-T Command-Line Interface reference. Notice the availability of the command: it’s a Manager only capability, meaning that although there is a CLI available on all NSX-T components, the Central CLI can only be executed from your NSX Manager.

The NSX-T Central CLI is triggered by the word on and follows this syntax: on <registered-node-uuid> exec [<command>].

To be able to execute central CLI commands, you need the nodes UUID towards you want to execute commands. You can, of course, retrieve them via the user interface, or via API, but the most comfortable and convenient way is to start by typing on and press TAB to get the complete list of nodes UUID.

In the example below, **I retrieve the logical routers from both edges **(nsxtedge-01a and nsxtedge-02a): on 1c6b14ff-7d12-4c7d-b6f2-ad895233e2bb 8de012d3-f3b7-47ef-9827-485cfe8f8656 exec get logical-routers.

Another cool capability is that you can pipe commands!

<code>nsxtmgr-01a> on 1c6b14ff-7d12-4c7d-b6f2-ad895233e2bb 8de012d3-f3b7-47ef-9827-485cfe8f8656 exec get logical-routers |
  count     Count number of entities
  find      Only show lines that contain regex pattern
  first     Show first N lines of output
  ignore    Ignore lines that contain regex pattern
  json      Show output in JSON format
  last      Show last N lines of output
  more      Show output one page at a time
  sort      Sort command output</code>

In the example below, I **retrieve the Tier-0 logical routers from my 2 edge nodes **using the find operator: on 1c6b14ff-7d12-4c7d-b6f2-ad895233e2bb 8de012d3-f3b7-47ef-9827-485cfe8f8656 exec get logical-routers | find TIER0.

Note: be aware that not all commands may be available in the central CLI.

NSX-T Central CLI Session Mode

Another option is to focus on a single NSX component by entering node specific commands directly. To access session mode, use the following command: on <registered-node-uuid> exec.

Once connected in session mode to an NSX Edge, I can enter in my Tier-0 Services Router (SR) VRF and get some information (for example).

Conclusion

The NSX-T Central CLI is very easy to use and facilitates operations and troubleshooting: I used it already several times to troubleshoot some connectivity issue with the physical network.

Finally, don’t forget that the NSX-T CLI should not be used to automate tasks; if you are automating tasks, consider using the API.