NX-API performs authentication through a programmable authentication module (PAM) on the switch. Use cookies to reduce the number of PAM authentications and thus reduce the load on PAM.

Take these actions if NX-API is not responding:

• Make sure that NX-API is enabled by using the show feature | grep nxapi command.
• Make sure that HTTP or HTTPs is enabled by using the show nxapi command.
• Make sure that NX-API is listening on the expected port by using the show nxapi command.
• Check for a long running command. Currently NX-API runs on a single worker process and is single threaded. If one command takes a long time to complete, it will block other commands. NX-API caches the request. When the current request completes, the others will be served.
• Enable Bash. For instructions, see the Cisco Nexus 9000 Series NX-OS Programmability Guide.
• Check the /var/sysmgr_nxapi/logs/error.log to see if there are any errors.
• If NX-API is still not responding, enter the no feature nxapi and feature nxapi commands to restart NX-API. NX-API is stateless, and it is safe to restart.

Take these actions if the user cannot execute configuration commands:

• Make sure that the user has the correct privileges to execute the commands.

Take these actions if users receive a "Permission Denied" message for Bash:

• Make sure that Bash is enabled by using the show feature | grep bash command.

• Make sure that the current user has the correct privileges to access Bash.

• For more information on Bash, see the Cisco Nexus 9000 Series NX-OS Programmability Guide.

Take these actions if you cannot retrieve the output from the browser sandbox:

• When the output is large or the command execution takes a long time, the browser might not be able to handle the load and might time out. Try using the Python client to access the NX-API. For instructions, see the Cisco Nexus 9000 Series NX-OS Programmability Guide.

  Note	The recommended browser is Mozilla Firefox.

Take these actions if CLI command errors appear when the user runs multiple commands:

• Check to see how multiple commands are separated. Show and configure commands must be separated by a [space]. Bash commands must be separated by a semicolon (;).

For every request, a temporary file is created in /volatile to store the command output that is sent back to the client. If the chunk parameter on the request is 0, the file is deleted right before the command output is sent back to the client. If the request does have chunk = 1, the file is retained so that the chunks can be extracted from it and sent to the client. That file will be cleaned up on a periodic basis. Currently that cleanup is set to occur once every 100 requests. Files are cleaned up if they are not accessed within 60 seconds of being created or are not modified or their status is not updated within 600 seconds.

For requests where chunk = 1, if the sid is set to the same value, you will get the same chunk of the command output. This functionality allows for situations where a client requests a specific chunk and does not receive it in a timely manner because it is dropped or blocked somewhere in the network. The clients can request the same chunk again, and they will receive the correct data as long as the temporary file has not been cleaned up (as described in Temporary Files Are Disappearing).