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.
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?