NETCONF Agent(s) on Cisco IOS XE 16.x
Evgeny made an interesting observation while testing the NETCONF client on IOS XE 16.x (see also this comment on my blog):
The most interesting part: for unknown reason IOS-XE gives different answers about capabilities on ports 830 and 22.
Einar quickly explained the mysterious behavior:
Port 22 hosts the legacy NETCONF agent on IOS-XE, which only supports NETCONF 1.0 with a Cisco-proprietary payload (same as all other vendors). Port 830, when netconf-yang is enabled, hosts the model-based agent.
Let me rephrase: Cisco IOS XE has not one but two NETCONF agents. One of them (accessible on port 22 and enabled with netconf ssh) is the old **** that we all love to hate, the other one (accessible on port 830 and enabled with netconf-yang) is really ConfD running on IOS XE.
As for “same as other vendors” part – Juniper didn’t have to include a second NETCONF agent in Junos to support IETF and OpenConfig data models. More details in this podcast.
Here are a few more fun facts:
- You configure the old agent with netconf configuration commands and the new agent with netconf-yang configuration commands;
- The old agent is debugged with debug netconf whatever and I found absolutely no way to debug the new agent;
The only thing I can’t figure out is whether this is an example of RFC 1925 rule 3 or rule 6a… what do you think?
It might also possibly rule 4. Try maintaining a 15 year old piece of software that is still used by millions.
The following change has been sent to the device over the confd netconf NBI.
router-day0#debug netconf all
All NETCONF debug flags are on
*Apr 11 10:58:32.489: %DMI-5-CONFIG_I: F0: nesd: Configured from NETCONF/RESTCONF by cisco, transaction-id 152