03-26-2023 10:07 PM - edited 03-27-2023 12:03 AM
Hi guys,
I saw that NX-OS does not support a request via Netconf, without a filter.
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<rpc-error>
<error-type>protocol</error-type>
<error-tag>operation-not-supported</error-tag>
<error-severity>error</error-severity>
<error-message xml:lang="en">Request without filtering is an unsupported operation</error-message>
</rpc-error>
</rpc-reply>
Is there a possibility to get the whole running configuration via ncclient?
Normally you would do that with the get_config(source='running') method. How can I do that with NX-OS?
Thank you
Remo
03-27-2023 12:01 AM
Hi
Well, that is not cool - I wonder why they implemented this...
You can get the running-config via CLI rpc (Cisco-NX-OS-device), however the data is plain text and not structured, so probably not what you're looking for:
from ncclient import manager, xml_
username = "cisco"
password = "cisco"
device = "10.90.255.241"
payload = """
<cli xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
<mode>EXEC</mode>
<cmdline>show running-config</cmdline>
</cli>
"""
with manager.connect(host=device, port=830, username=username, password=password, hostkey_verify=False) as m:
res = m.rpc(xml_.to_ele(payload))
print(res)
Marcel
03-27-2023 12:21 AM
Hi Marcel,
Thank you for your answer. This is from the documentation:
Beginning with NX-OS 9.3(1), NETCONF get and get-config requests from the NETCONF client to the switch must contain an explicit namespace and filter. This requirement affects requests to the OpenConfig YANG and NETCONF Device models. If you see a message that is similar to the following, the requests are not carrying a namespace:
Request without namespace and filter is an unsupported operation
I assume that this has to do with the performance of the device. It would add a lot of load to the CPU when we get the whole running configuration.
I am wondering if there is a filter which I could use to get the running config.
Thanks
Remo
03-27-2023 12:38 AM
Yes I also saw this in the doc. I think this behaviour is actually violating the RFC:
https://www.rfc-editor.org/rfc/rfc6241#page-35
7.1 <get-config>
<SNIP>
filter: This parameter identifies the portions of the device
configuration datastore to retrieve. If this parameter is not
present, the entire configuration is returned.
<SNIP>
Hopefully someone from Cisco does have some insights. Maybe @bigevilbeard knows someone who can help?
03-27-2023 04:50 AM
Hey pal! Not in this space i do not, maybe @jcohoe might know someone.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide