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?