topic Re: Trying to test restconf on Catalyst 8000 Always-On Sandbox-2025110 in DevNet Sandbox

Trying to test restconf on Catalyst 8000 Always-On Sandbox-20251104T08

__ToddR__ — Thu, 06 Nov 2025 11:36:39 GMT

Hello,

Trying to test restconf I can ssh to the lab. Works fine.

curl -k -u "<username>:<password>" host -v
* Host <>:443 was resolved.
* IPv6: (none)
* IPv4: 131.x.x.x
* Trying 131.x.x.x:443...

Seems like something else might be blocking it. I am aware that there are new VPN settings however I tried the ssh port to the host provided with the credentials given and it worked. So I assumed the 443 port would be open as well. If that's not the case that would explain it. Anyhow thanks for your help.

-Todd

Re: Trying to test restconf on Catalyst 8000 Always-On Sandbox-2025110

bigevilbeard — Thu, 06 Nov 2025 20:19:35 GMT

I’ve not tested it. But looking at the lab details

Cat8000v Host:

Public URL:devnetsandboxiosxec8k.cisco.com
RESTCONF port: 443
NETCONF port: 830
ssh port: 22

it should be open, there is no vpn and normal the security only allows the listed ports from the instructions. Have you check the configuration on the device itself to ensure restconf is set up, as this is a always on and shared device, something might not be configured correctly.

Re: Trying to test restconf on Catalyst 8000 Always-On Sandbox-2025110

__ToddR__ — Thu, 06 Nov 2025 21:26:39 GMT

From what I could tell it was enabled. It looks like I'm getting blocked prior to reaching the device on port 443. The following configurations were on the router

netconf-yang
restconf
yang-interfaces aaa authentication method-list netconf-authn
yang-interfaces aaa authorization method-list netconf-authz
end

ip http server
ip http server
ip http authentication local
ip http secure-server

# show ip http server status
HTTP server status: Enabled
HTTP server port: 80
HTTP server active supplementary listener ports: 21111
HTTP server authentication method: local
HTTP server auth-retry 0 time-window 0
HTTP server digest algorithm: md5
HTTP server access class: 0
HTTP server IPv4 access class: None
HTTP server IPv6 access class: None
HTTP server base path:
HTTP File Upload status: Disabled
HTTP server upload path:
HTTP server help root:
Maximum number of concurrent server connections allowed: 300
Maximum number of secondary server connections allowed: 50
Server idle time-out: 180 seconds
Server life time-out: 180 seconds
Server session idle time-out: 600 seconds
Maximum number of requests allowed on a connection: 25
Server linger time : 60 seconds
HTTP server active session modules: ALL
HTTP secure server capability: Present
HTTP secure server status: Enabled
HTTP secure server port: 443
HTTP secure server ciphersuite: rsa-aes-cbc-sha2 rsa-aes-gcm-sha2
dhe-aes-cbc-sha2 dhe-aes-gcm-sha2 ecdhe-rsa-aes-cbc-sha2
ecdhe-rsa-aes-gcm-sha2 ecdhe-ecdsa-aes-gcm-sha2 tls13-aes128-gcm-sha256
tls13-aes256-gcm-sha384 tls13-chacha20-poly1305-sha256
HTTP secure server TLS version: TLSv1.3 TLSv1.2
HTTP secure server client authentication: Disabled
HTTP secure server PIV authentication: Disabled
HTTP secure server PIV authorization only: Disabled
HTTP secure server trustpoint: TP-self-signed-3209586145
HTTP secure server peer validation trustpoint:
HTTP secure server ECDHE curve: secp256r1
HTTP secure server active session modules: ALL

So.... Just seems like maybe a ports needs opened? Maybe the device is in need of a reboot?? But I don't know. If there are others who aren't having the issue to this device as its a shared resource if they could chime in?? Then there could be a problem between my chair and the keyboard. Wouldn't be the first time. But at this point, that's all I got.

-Todd

$ curl -k -u "username:password" https://devnetsandboxiosxec8k.cisco.com/restconf/ -v
* Host devnetsandboxiosxec8k.cisco.com:443 was resolved.
* IPv6: (none)
* IPv4: 131.226.217.182
* Trying 131.226.217.182:443...

Re: Trying to test restconf on Catalyst 8000 Always-On Sandbox-2025110

__ToddR__ — Thu, 06 Nov 2025 21:50:53 GMT

I thought I replied to this earlier, but I don't see my update. Yea restconf appears to be enabled.

#sh run | inc restconf
restconf

# show ip http server status
HTTP server status: Enabled
HTTP server port: 80
HTTP server active supplementary listener ports: 21111
HTTP server authentication method: local
HTTP server auth-retry 0 time-window 0
HTTP server digest algorithm: md5
HTTP server access class: 0
HTTP server IPv4 access class: None
HTTP server IPv6 access class: None
HTTP server base path:
HTTP File Upload status: Disabled
HTTP server upload path:
HTTP server help root:
Maximum number of concurrent server connections allowed: 300
Maximum number of secondary server connections allowed: 50
Server idle time-out: 180 seconds
Server life time-out: 180 seconds
Server session idle time-out: 600 seconds
Maximum number of requests allowed on a connection: 25
Server linger time : 60 seconds
HTTP server active session modules: ALL
HTTP secure server capability: Present
HTTP secure server status: Enabled <<--
HTTP secure server port: 443 <<--
HTTP secure server ciphersuite: rsa-aes-cbc-sha2 rsa-aes-gcm-sha2
dhe-aes-cbc-sha2 dhe-aes-gcm-sha2 ecdhe-rsa-aes-cbc-sha2
ecdhe-rsa-aes-gcm-sha2 ecdhe-ecdsa-aes-gcm-sha2 tls13-aes128-gcm-sha256
tls13-aes256-gcm-sha384 tls13-chacha20-poly1305-sha256
HTTP secure server TLS version: TLSv1.3 TLSv1.2
HTTP secure server client authentication: Disabled
HTTP secure server PIV authentication: Disabled
HTTP secure server PIV authorization only: Disabled
HTTP secure server trustpoint: TP-self-signed-3209586145
HTTP secure server peer validation trustpoint:
HTTP secure server ECDHE curve: secp256r1
HTTP secure server active session modules: ALL

So unless someone else who is currently using the box can chime in that restconf is working fine for them. Seems like either a port issue or the device in a enabled but operating in a degraded state and is not completing the tcp connection on port 443. Because its a shared resource I don't want to start messing with things that will disrupt others. Not sure what else I can provide or do at this point?

$ curl -k -u "<>:<>" https://devnetsandboxiosxec8k.cisco.com/restconf/ -v
* Host devnetsandboxiosxec8k.cisco.com:443 was resolved.
* IPv6: (none)
* IPv4: 131.226.217.182
* Trying 131.226.217.182:443... <-- Hanging

Thanks.

-Todd

Re: Trying to test restconf on Catalyst 8000 Always-On Sandbox-2025110

Torbjørn — Thu, 06 Nov 2025 22:08:13 GMT

I am seeing the same when I try to connect from my machine. The webserver is responding on port 443 when I test from the router itself, so there must be something wrong in the sandbox infrastructure(missing fw rule?)

Hiit_Batch49#show ip int br Interface IP-Address OK? Method Status Protocol GigabitEthernet1 10.10.20.148 YES NVRAM up up GigabitEthernet2 unassigned YES NVRAM administratively down down GigabitEthernet3 unassigned YES NVRAM administratively down down Hiit_Batch49#telnet 10.10.20.148 443 Trying 10.10.20.148, 443 ... Open ^CHTTP/1.1 400 Bad Request Server: openresty Date: Thu, 06 Nov 2025 22:01:53 GMT Content-Type: text/html Content-Length: 154 Connection: close <html> <head><title>400 Bad Request</title></head> <body> <center><h1>400 Bad Request</h1></center> <hr><center>openresty</center> </body> </html> [Connection to 10.10.20.148 closed by foreign host]

Re: Trying to test restconf on Catalyst 8000 Always-On Sandbox-2025110

__ToddR__ — Thu, 06 Nov 2025 22:43:00 GMT

I don't know whats going on with this post but I have replied twice and nothing seems to show up???

Re: Trying to test restconf on Catalyst 8000 Always-On Sandbox-2025110

Torbjørn — Thu, 06 Nov 2025 22:48:54 GMT

Is there any potentially sensitive information in there? When I first opened this post earlier there was one more post here, but when I returned to reply it had disappeared. I am guessing the replies you are missing are getting removed by a moderator.

Re: Trying to test restconf on Catalyst 8000 Always-On Sandbox-2025110

__ToddR__ — Thu, 06 Nov 2025 23:04:14 GMT

Gotcha.... Good to know. Thanks..

Re: Trying to test restconf on Catalyst 8000 Always-On Sandbox-2025110

Jesus Illescas — Fri, 07 Nov 2025 09:45:02 GMT

I'll ping the team. it seems there is an aaa error when using restconf

$ curl -X GET \ > -H "Accept: application/yang-data+json" \ > -H "Content-Type: application/yang-data+json" \ > -u yyyyy:xxxxx \ > --insecure \ > "https://devnetsandboxiosxec9k.cisco.com/restconf/data/Cisco-IOS-XE-native:native" { "ietf-restconf:errors": { "error": [ { "error-type": "protocol", "error-tag": "access-denied" } ] } }

*Nov 7 09:38:07.193: AAA/AUTHEN/LOGIN (00000000): Pick method list 'netconf-authn' *Nov 7 09:38:07.209: %DMI-5-AUTHENTICATION_FAILED: R0/0: dmiauthd: Authentication failure from 34.131.36.30:35000 for netconf over ssh.

Re: Trying to test restconf on Catalyst 8000 Always-On Sandbox-2025110

bigevilbeard — Fri, 07 Nov 2025 10:00:48 GMT

Yeah seems odd, I know on one version you had to disable restconf and re-enable this. As @Jesus Illescas noted the team will take a look, now they use dynamic usernames on this, could be a small update to the baseline configuration to allow this to happen.

Re: Trying to test restconf on Catalyst 8000 Always-On Sandbox-2025110

Jesus Illescas — Fri, 07 Nov 2025 10:17:46 GMT

I correct myself, I used the wrong URL (c9k instead of c8k) I see is timing out.

$ curl -X GET \ > -H "Accept: application/yang-data+json" \ > -H "Content-Type: application/yang-data+json" \ > -u yyyyyy:xxxxxxx \ > --insecure \ > "https://devnetsandboxiosxec8k.cisco.com/restconf/data/Cisco-IOS-XE-native:native" \ > -vv Note: Unnecessary use of -X or --request, GET is already inferred. * Host devnetsandboxiosxec8k.cisco.com:443 was resolved. * IPv6: (none) * IPv4: 131.226.217.182 * Trying 131.226.217.182:443...