Send RPC and Action commands (NETCONF)

NETCONF defines several standard RPC commands such as get, get-config and edit-config. The protocol also allows defining new RPC commands in any IETF or vendor defined YANG modules.

Send NETCONF standard get, get-config and edit-config RPC commands

We have covered how to send NETCONF’s built-in <get>, <get-config>, and <edit-config> etc. See Editing Configuration (NETCONF) or Retrieving Configuration Data (NETCONF).

Send RPCs and Actions in any YANG modules

There can be many RPC and Action commands defined in either standard or proprietary YANG modules.

That is, you want to send RPCs that are not NETCONF built-in commands like <get>, <get-config>, <edit-config>….

It is pretty easy in NETCONFc to send these commands.

You just need to expand the module tree to locate the RPC command, click the Value cells to enter values for input parameters (if there is any) required, and right click to choose sending the RPC command!

If the input parameters include list or leaf-list, you can also build a single RPC with multiple list or leaf-list entries, just like building an <edit-config>. See Create multiple list or leaf-list instance entries in a single request .

_images/add_to_built_rpcs.png

The following example sends a system-restart RPC defined in ietf-system@2014-08-16 module.

_images/send_a_rpc.png

How to specify input parameter value with a namespace?

Let’s look at the <get-schema> RPC defined in RFC6022 ietf-netconf-monitoring module. This RPC defines three input parameters. The optional third format parameter is an identityref type. The value should be identities such as yang, yin, etc. as defined in the namespace “urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring”.

The way you specify such an identityref value is to use module-name:identity form or prefix:identity form. If you use ``module-name:identity``NECONFc will automatically convert it to an appropriate prefix encoding.

In an older NETCONFc release, you may have to use prefix:identity form. If you are required to use prefix:identity form then how do we know what prefix to use?

In NETCONFc, you can view all known prefix/namespace mappings by right-clicking on a node, and select “View prefix-namespace mapping”

_images/get_schema_namespace.png

In the dialog popped up, find the prefix that is mapped to the namespace “urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring” and use the to specify format value.

_images/prefix-namespace-mapping.png

In this case the value for yang format must be given as ncm:yang as shown below:

_images/send_get_schema.png

Kill session

You need to kill a session that may be unexpectely holding the datastore lock.

To invoke NETCONF kill-session RPC, click the kill-session toolbar button.

_images/kill_session.png

You need to enter the session ID you want to kill. One way to find the sesion ID is by looking at netconf-monitoring module as shown below:

_images/find_session_id.png

Validate config

If Validate capability is advertised, the device supports the <validate> protocol operation and checks at least for syntax errors for the config data supplied.

To invoke NETCONF <validate> opertion, click the validate config toolbar button.

_images/validate_config.png

copy-config, backup and restore

To invoke NETCONF copy-config opertion, click the copy-config button.

_images/copy_config.png

The running config can be saved into a file as a checkpoint before updating it. If updating fails, it can be restored by reloading the checkpoint file.

The checkpoint file can be created by using a file url as the target. Example:

Target:  file://localhost/checkpoint.conf, or if host name is omitted,

Target:  file:///checkpoint.conf, (note it has three ‘/’ here!)

To restore the checkpoint file, reverse the <source> and <target> parameters

A with-defaults option can also be selected. However the <copy-config> operation is only affected by the <with-defaults> parameter if the target of the operation is specified with the <url> parameter.