cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
137
Views
0
Helpful
3
Replies

Open NX-OS Programmability AlwaysOn Netconf Issue

rubo_cisco
Level 1
Level 1

Hi,

I was playing around with this sanbox and ran into netconf issues.

Prior to that I was able to (all with the public/global credentials within the lab):
1) Login and browse Visore
2) Use the NX REST API with an API client
3) Login into the sandbox on the device and craft json-rpc and json queries (within the sandbox).

Using those same credentials I tried using an API client to reproduce (3). But this fails. The lab lists the same credentials for everything.

AI seems to suggest that, Basic realm="Secure Zone" suggests that Basic Auth credentials are rejected or the role on the Nexus is incorrectly set.

When I SSH in, and the run the operation, I see:
2025 May 14 22:44:13.116 nxos  %AUTHPRIV-3-SYSTEM_MSG: pam_aaa:Authentication failed from nginx - ker_process


Wondering if anyone has any ideas?

Also on a side note, when using REST the APIC-Cookie is like only for 5 minutes. Okay with Python, but annoying when using a client.


Here is the output from my client (insomnia)...forgive the formatting when pasting.

Request:

> POST /ins HTTP/2
> Host: sbx-nxos-mgmt.cisco.com
> content-type: application/json-rpc
> user-agent: insomnia/9.2.0
> authorization: Basic YWRtaW46QWRtaW5fMTIzNCEJ
> accept: */*
> content-length: 137

* TLSv1.2 (OUT), TLS header, Supplemental data (23):

| [
| {
| "jsonrpc": "2.0",
| "method": "cli",
| "params": {
| "cmd": "show version",
| "version": 1
| },
| "id": 1
| }
| ]

Response:

< HTTP/2 401
< server: nginx/1.13.12
< date: Thu, 15 May 2025 08:48:33 GMT
< content-type: text/html; charset=UTF-8
< www-authenticate: Basic realm="Secure Zone"
< strict-transport-security: max-age=31536000; includeSubDomains
< x-frame-options: SAMEORIGIN
< content-security-policy: block-all-mixed-content; base-uri 'self'; default-src 'self'; script-src 'self' 'nonce-qSRjjDOyO6B5oIosbUfC4t7XlXO9VULN'; style-src 'self' 'nonce-qSRjjDOyO6B5oIosbUfC4t7XlXO9VULN'; img-src 'self'; connect-src 'self'; font-src 'self'; object-src 'self'; media-src 'self'; form-action 'self'; frame-ancestors 'self';



 

3 Replies 3

As this is an always on and many people have admin access, it is possible something has changed here which is now causing you an issue. When did you notice the change here?

Please mark this as helpful or solution accepted to help others
Connect with me https://bigevilbeard.github.io

I only hopped onto this for the first time about 2 hours prior to making that post (was working my way through the NX Rest API, before tackling the NX CLI API). 

So I haven't experienced a functioning NX CLI API.

I tried just now and and same result. NX REST is fine, NX CLI rejecting me. NX REST counts on a post body having the AAA credentials, then subsequent requests use a Cookie. NX CLI relies on basic auth, so not sure if there is something further that needs to be done to hook the username admin to NX CLI on the NExus config side.

I used to Grok to dig in a bit further, and it says typically just the SSH credentials with the username command and correct role.

on the NExus itself:

username admin password XXXXXXX  role network-admin

Which looks good. Don't know if it needs a reboot. I might give the reserved version ago, been staying away from these as I run linux at home and don't wont to waste time troubleshooting openconnect should something go awry.

Thanks

OK i misread and thought you had used this in the past. There a good doc, walk over here https://nxos-devops.ciscolive.com/lab/pod6/postman/nx-api-rest - you might see some quirks with the always on devices, although they have global access something might be available and you might need to look at the reservation based on. If it is just one devices, then the option to run this in vagrant locally was always my choice. 

Please mark this as helpful or solution accepted to help others
Connect with me https://bigevilbeard.github.io