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?

3 comments:

  1. "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.
  2. I've checked and the "debug netconf" also shows confd related config changes.
    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

    router#
    *Apr 11 10:58:32.489: %DMI-5-CONFIG_I: F0: nesd: Configured from NETCONF/RESTCONF by cisco, transaction-id 152
    device#
    Replies
    1. Thank you. So maybe that was added into the code, or it could be that I was looking for more specific messages (I was somewhat spoiled by the old NETCONF agent which did produce the logs you'd expect from "debug * all" on Cisco IOS)
Add comment
Sidebar