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). This 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!
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
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).
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.