How to modify device capability at runtime

NETCONF
1

Hi,
Confd picks up all netconf enabled module urls and announce them in capability messages.

We can control which urls would be included in capability message at compile time by passing suitable --export flag.

I want to know whether the same can be done at runtime?

Regards,

2

Besides compiling the YANG model with the —export flag, you can also use the tailf:export statement in the YANG module. See ConfD UG Chapter “Hidden Data”. With NETCONF, the YANG 1.0 module is announced in the <hello> message, and the YANG 1.1 module is announced according to the RFC 8525 YANG Library.

If you need to hide/unhide a YANG module at runtime, you would need to do an in-service upgrade to apply changes of the above. See ConfD UG chapter “In-service Data Model Upgrade”.

3

Okay, so if I understand correctly, for any runtime control, we need to have two version of fxs files (one with netconf enabled, another without netconf) and then we can switch to particular version by in-service data model upgrade. (In our case we can even do this before starting confd for the first time)

There is no way to achieve the same with a single fxs file and then toggling export parameter via some maapi APIs. Right?

Our original problem is

  • Currently we use single set of fxs files in multiple platforms.
  • Transaction hooks gives error on any create/modify operation on a subtree depending on platform version at run time.
  • But northbound managers are using the capability information in hello message to discover supported services in the device.
  • So we are looking for any method to exclude those url lists from capability data. Is there any hook for the same within confd?

In CLI we can apply NACM reject rules to hide those subtrees from being rendered. I have not checked but I think that would not work with capability response.

4

You cannot load two versions of the same YANG modules/fxs files with the same namespace. So that won’t work.

RIght. When you change the database schema (YANG/fxs files) you need to upgrade to implement the changes, in-service at run-time, or by restarting ConfD.

Your set of YANG/FXS files, i.e. the database schema, needs to be in sync with your platform.