Yangcli Operations
Establish Connection
These are the steps to establish a connection between the NetConf client and the server running on the device.
# yangcli server=<ip_address> user=<user_name> password=<password>
ip_address: Address of the device to be managed
user_name & password: User account detail for authentication
The interactive version of this command is shown below:
# yangcli yangcli> connect
Enter string value for leaf <user>
yangcli:connect> <user_name>
Enter string value for leaf <server>
yangcli:connect> <ip_address>
Enter string value for leaf <password>
yangcli:connect> <password>
The OcNOS NetConf server supports both IPv4 and IPv6 connections.
Note: In NETCONF (Network Configuration Protocol), the maximum number of sessions over SSH is indeed a configurable parameter that can be defined in the netconfd.yang module.
Here’s a generalized example of how such a parameter might be defined in a netconfd.yang file
leaf max-sessions {
description
"Specifies the maximum number of sessions
that can be accepted.";
type uint32;
default 1024;
}
At present, the netconfd software is utilizing the default setting of 1024 for the max-sessions parameter. Consequently, the maximum number of concurrent NETCONF sessions is restricted to 1023 due to this default configuration.
Attempting to create the 1024th session in the netconfd deletes the oldest session with session-id 1 and creates a new session with session-id 1.
Note: Enabling the OpenConfig Translation feature causes the NETCONF server to restart, necessitating the NETCONF client to reconnect and establish a new session. When enabling the OpenConfig Translation feature, you must specify the namespace to ensure the NETCONF server operates within the correct context.
Configure the Device
Configuration details are placed in an XML file and sent to the netconfd server. You must refer to the OcNOS NetConf Command Reference to prepare the XML based configuration file with the correct hierarchy. If the hierarchy is not correct, yangcli throws an error.
One portion of the BGP protocol module Yang model is presented below. This module is a submodule for the parent OcNOS yang module.
submodule ipi-bgp-peer {
yang-version 1.1;
belongs-to ipi-bgp { prefix ipi-bgp; }
import feature-list {
prefix feature-list;
revision-date 2021-05-03;
}
import cml-data-types {
prefix cml-data-types;
revision-date 2021-05-03;
}
import ipi-bgp-types {
prefix ipi-bgp-types;
revision-date 2021-05-27;
}
revision "2021-06-11" {
description "Added dependency constraint between name and direction attrs for the distribute-list, prefix-list, filter-list and route-map CLI's";
reference " 0.5.4.";
}
grouping peer-grouping {
description
"List of BGP neighbors configured on the local system, uniquely
identified by peer IPv[46] address";
list peer {
when " /bgp/bgp-instance/peer/config/peer-as or /bgp/bgp-instance/peer/config/mapped-peer-group-tag ";
key "peer-address";
description
"List of BGP neighbors configured on the local system, uniquely identified by peer IPv[46] address";
leaf peer-address {
type leafref {
path "../config/peer-address";
}
description "Reference to the address of the BGP peer used as a key in the peer list";
} // END of peer-address definition.
list bgp-password {
when " /bgp/bgp-instance/peer/config/peer-as or /bgp/bgp-instance/peer/config/mapped-peer-group-tag ";
key "password auth-key-encrypt";
max-elements 1;
description
"list for BGP password";
leaf password {
type leafref {
path "../config/password";
}
description "Use this attribute to enable authentication-key";
} // END of password definition.
Based on the hierarchy in the Yang module, the following XML file named bgp.xml is created with the configuration data. The bgp.xml file is referenced in the edit-config operation specified below.
<bgp xmlns="http://www.ipinfusion.com/yang/ocnos/ipi-bgp">
<bgp-instance>
<bgp-as>100</bgp-as>
<config>
<bgp-as>100</bgp-as>
</config>
<timers>
<config>
<hold-time>9</hold-time>
<keep-alive>3</keep-alive>
</config>
</timers>
</bgp-instance>
</bgp>
Use this command to globally set or reset the keepalive and holdtime values for all the neighbors.
yangcli ocnos@10.12.45.253> edit-config config=@/root/bgp.xml
Filling container /edit-config/input/target:\
RPC OK Reply 15 for session 1:
OcNOS supports hitless NetConf merge operation. The hitless feature blocks southbound calls to configure the provisioned configuration if it was already configured. Because of this feature, errors like “QOS already enabled” are not reported when you try to enable QoS again/repeatedly. Also, southbound calls are blocked when you try to delete/unset a non-existing configuration.
Configuration objects are merged while provisioning configuration incrementally (different/same attributes) for the same object. However this cannot be done for attributes or objects having RANGE (such as VLAN range) and MULTIPLE values (such as OSPF passive interface address) type attributes, therefore they are treated as different objects and southbound calls are allowed for every individual object. As per hitless functionality, all these objects are supposed to be merged, and a single object is expected to be sent southbound to do the configuration/un-configuration. But there will be duplicate calls southbound as was present in earlier releases. This limitation is planned to be addressed in upcoming releases.
Note: List of payloads required to configure the switch is documented in OcNOS NetConf Command Reference guide.
To disable QoS, use edit-config's MERGE operation (default-operation=merge) with the below payload:
<qos xmlns="http://www.ipinfusion.com/yang/ocnos/ipi-qos">
<global>
<config>
<enable-qos operation="delete"/>
</config>
</global>
</qos>
Limitations
edit-config Operation
When using the edit-config operation with the create action and providing only key attributes to create a YANG list that references another YANG list, it will not result in the creation of any new configuration. This is because the referenced list already exists, and only key attributes are specified.
For instance, consider the following payload:
<isis xmlns="http://www.ipinfusion.com/yang/ocnos/ipi-isis">
<interfaces>
<interface operation="create">
<name>eth1</name>
<config>
<name>eth1</name>
</config>
</interface>
</interfaces>
</isis>
In this example, the leaf node /isis/interfaces/interface/config/name serves as a leafref reference to interfaces/interface/name. Essentially, it means that the interface list within the isis module is referring to the interface list in the interface module. The provided payload contains only the key attribute for the interface list, indicating an intention to create a new interface list. However, since the referenced interface already exists, this configuration has no impact.
To make a valid and meaningful configuration change, setting other non-key attributes of the referenced interface list is necessary. For instance, the following payload is both valid and purposeful:
<isis xmlns="http://www.ipinfusion.com/yang/ocnos/ipi-isis">
<interfaces>
<interface operation="create">
<name>eth1</name>
<config>
<name>eth1</name>
<minimal>level-1-only</minimal>
</config>
</interface>
</interfaces>
</isis>
This payload not only specifies the key attribute but also includes additional non-key attributes for the referenced interface list, allowing for a meaningful configuration update.
Default-Operations
1. merge and replace is supported as default-operation.
2. delete, and replace is supported as operations at container and leaf level. (operation="delete"), (operation="replace")
3. create is supported as operation at container level. Create operation is not supported at leaf level. (operation="create").
4. remove is supported as operation at container and leaf level (operation="remove").
Table 3-1: Edit-config operations
| | Default operation |
|---|
| | Merge | Replace | None |
Create | Object | Y | Y | |
Leaf | | | |
Delete | Object | Y | Y | |
Leaf | Y | Y | |
Merge | Object | Y | Y | |
Leaf | Y | Y | |
Replace | Object | Y | Y | |
Leaf | Y | Y | |
Remove | Object | Y | Y | |
Leaf | Y | Y | |
Legend: | Y | Supported |
| Blank | Not supported; error will be returned |
Retrieve Candidate Configuration
Candidate configuration datastore is used to hold configuration data that can be manipulated without impacting the device's current configuration. The candidate configuration is a full configuration data set that serves as a work place for creating and manipulating configuration data. Additions, deletions, and changes can be made to this data to construct the desired configuration data.
Note: All NetConf clients share the single candidate configuration store.
>sget-config /bgp source=candidate
Filling list /bgp:
RPC Data Reply 1 for session 2:
rpc-reply {
data {
bgp {
bgp-instance 100 {
bgp-as 100
config {
bgp-as 100
}
timers {
config {
hold-time 9
keep-alive 3
}
}
}
}
}
Commit Candidate Configuration
A <commit> operation can be performed at any time that causes the device's running configuration to be set to the value of the candidate configuration.
yangcli ocnos@10.12.45.253> commit
RPC OK Reply 16 for session 1
Retrieve Running Configuration
Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state. You can use the get-config operation to fetch the running configuration data.
>sget-config /bgp source=running
Filling list /bgp:
RPC Data Reply 1 for session 2:
rpc-reply {
data {
bgp {
bgp-instance 100 {
bgp-as 100
config {
bgp-as 100
}
timers {
config {
hold-time 9
keep-alive 3
}
}
}
}
}
}
Retrieve Running Configuration and State Data
State data is the additional data on a system that is not configuration data such as read-only status information and collected statistics. You can use the get operation to fetch a protocol module's running configuration and state data.
>sget /bgp rpc-reply {
data {
bgp {
bgp-instance 100 {
bgp-as 100
config {
bgp-as 100
}
state {
bgp-as 100
scan-remain-time 8
router-run-time-ip-address 0.0.0.0
total-prefixes 0
table-version 1
version 4
}
timers {
config {
hold-time 9
keep-alive 3
}
state {
hold-time 9
keep-alive 3
}
}
}
}
}
}
Copy Running Configuration to Startup
> copy-config source=running target=startup
The equivalent OcNOS command is:
# write
YANG Unique Datamodel Support
The key attributes in YANG datamodels are unique and it considers a combination of all its attributes as unique. For example, if the unique attributes are ‘IP’ and ‘Port’, the combination IP/Port is unique but each of these attributes can be repeated as long as it is combined with a different attribute. The check for uniqueness of the key attributes is already enforced in datamodel check and the validation of CLI / NetConf configurations is done by CML validation layer.
However, sometimes even some non-key attributes need to be unique within a list. With the unique datamodel support, the uniqueness in YANG lists with non-key attributes is also checked by a CML validation layer. The check is defined in the CML datamodel XML, validated by the CMLd. Without a validation for this uniqueness in CML layer, the commits pass on to backend modules and it failst the back-end check resulting in an unsuccessful commit dry-run functionality. This feature ensures that the non-key attributes which need to be unique are also checked in CML validation layer before the commit operation starts.
Example
Consider the following configuration:
ip vrf TEST1000
rd 173.200.0.101:1000
route-target both 0:1000
ip vrf TEST1001
rd 173.200.0.101:1000
route-target both 0:1001
Here, rd, which is not a key attribute, must be unique across the VRFs. The VRFs are listed using key of vrf-name, but it does not ensure that some attributes in the list entry are unique. The 'unique' keyword is used to ensure that.
Limitations
• The following IP addresses do not support unique attribute validation:
• Secondary IP address
• IPv6 address
• If an L3 interface is moved to a part of the member ports, the IP address configured on that member port cannot be set on the aggregated port in a single commit transaction, i.e., if the physical interface and the newly created PO interface have the same IP address, an error will occur. The configuration must be done using separate commit transactions as shown below:
interface eth1
ip address 10.1.1.1/24
!
OcNOS(config)#interface po1
OcNOS(config-if)#exit
OcNOS(config)#interface eth1
OcNOS(config-if)#channel-group 1 mode active
OcNOS(config-if)#commit
OcNOS(config-if)#exit
OcNOS(config)#show running-config interface eth1
!
interface eth1
channel-group 1 mode active
!
OcNOS(config)#show running-config interface po1
!
interface po1
!
OcNOS(config)#interface po1
OcNOS(config-if)#ip address 10.1.1.1/24
OcNOS(config-if)#commit
OcNOS(config-if)#exit
OcNOS(config)#
OcNOS(config)#show running-config interface eth1
!
interface eth1
channel-group 1 mode active
!
OcNOS(config)#show running-config interface po1
!
interface po1
ip address 10.1.1.1/24
!
OcNOS(config)#
Error Messages
NetConf operations return protocol, management layer, and protocol module errors. The example below depicts an error returned by a protocol module.
Copy the content below into bgp_err.xml.
<bgp xmlns="http://www.ipinfusion.com/yang/ocnos/ipi-bgp">
<bgp-instance>
<bgp-as>200</bgp-as>
<config>
<bgp-as>200</bgp-as>
</config>
<timers>
<config>
<hold-time>9</hold-time>
<keep-alive>3</keep-alive>
</config>
</timers>
</bgp-instance>
</bgp>
Execute the following command and commit the changes:
yangcli tbyran@10.12.45.253> edit-config config=@/root/bgp_err.xml
Filling container /edit-config/input/target: RPC OK Reply 12 for session 1:
yangcli tbyran@10.12.45.253> commit
mgr_rpc: got invalid reply on session 1 (invalid XPath expression syntax) RPC Error
Reply 13 for session 1:
rpc-reply {
rpc-error {
error-type application
error-tag operation-failed
error-severity error
error-app-tag general-error
error-path /bgp/bgp-instance[bgp-as='200']/config
error-message '%% BGP is already running, AS is 100'
error-info {
error-number 127
}
}
rpc-error {
error-type application
error-tag operation-failed
error-severity error
error-app-tag general-error
error-path /bgp/bgp-instance[bgp-as='200']/timers/config
error-message '%% AS number mismatch'
error-info {
error-number 4294962321
}
}
}
Warning Messages
NetConf operations return protocol module warnings. The example below depicts a warning returned by a protocol module.
Copy the content below into intf_warn.xml
<interfaces xmlns="http://www.ipinfusion.com/yang/ocnos/ipi-interface">
<interface>
<name>ce1/1</name>
<config>
<name>ce1/1</name>
<vrf-name>management</vrf-name>
</config>
<ipv4 xmlns="http://www.ipinfusion.com/yang/ocnos/ipi-if-ip">
<config>
<primary-ip-addr>100.12.23.3/24</primary-ip-addr>
</config>
</ipv4>
</interface>
</interfaces>
To receive warnings, NetConf client must subscribe to receive notifications.
yangcli ocnos@127.1> create-subscription
RPC OK Reply 3 for session 1:
Execute the following command and commit the changes:
yangcli ocnos@127.1> edit-config config=@/home/ocnos/intf_warn.xml
Filling container /edit-config/input/target:
RPC OK Reply 4 for session 1:
yangcli ocnos@127.1> commit
RPC OK Reply 6 for session 1:
Incoming notification:
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2021-07-07T14:03:39Z</eventTime>
<severity>info</severity>
<eventClass>config</eventClass>
<warning-notification xmlns="http://ipinfusion.com/ns/zebmcli">
<warningMsg>%% IP address removed due to enabling VRF management</warningMsg>
</warning-notification>
</notification>
Note: RFC 6241 is not detailed enough about how a NetConf server reports warnings. Therefore, OcNOS uses this warning reporting method.
Candidate Configuration store lock
Candidate configuration store is shared across all the NetConf clients. Client application must acquire lock if they want to provision the device without other client's hindrance
NetConf Client 1: locks candidate configuration store.
yangcli ocnos@127.1> lock target=candidate
RPC OK Reply 1 for session 4:
NetConf Client 2: attempts to acquire the lock now, which leads to an access-denied error.
yangcli ocnos@127.1> lock target=candidate
RPC Error Reply 1 for session 5:
rpc-reply {
rpc-error {
error-type protocol
error-tag lock-denied
error-severity error
error-app-tag no-access
error-message 'lock denied'
error-info {
session-id 0
error-number 268
}
}
}
Now error “access-denied” is received by NetConf client 2 when it attempts to provision the device.
yangcli ocnos@127.1> edit-config config=@/home/ospf_payload.xml
Filling list /ospfv2:
RPC Error Reply 3 for session 4:
rpc-reply {
rpc-error {
error-type application
error-tag in-use
error-severity error
error-app-tag no-access
error-path /nc:rpc/nc:edit-config/nc:config
error-message 'config locked'
error-info {
error-number 301
}
}
}
NetConf client 1 releases the lock
yangcli ocnos@127.1> unlock target=candidate
RPC OK Reply 2 for session 4:
NetConf client 2 can acquire the lock now, since no other client is holding the lock.
yangcli ocnos@127.1> lock target=candidate
RPC OK Reply 2 for session 5:
Startup configuration store lock
NetConf client 1 locks startup configuration store
yangcli ocnos@127.1> lock target=startup
RPC OK Reply 14 for session 4:
NetConf client 2 trying to modify the configuration store leads to error.
yangcli ocnos@127.1> copy-config source=running target=startup
RPC Error Reply 10 for session 5:
rpc-reply {
rpc-error {
error-type protocol
error-tag in-use
error-severity error
error-app-tag no-access
error-message 'config locked'
error-info {
error-number 301
}
}
}
Running configuration store lock
Running configuration lock handling across multiple NetConf clients is not supported. But across command line interface and NetConf clients is supported. Hence this section documentation is skipped for now.
Force unlock
Admin user has provision to forcibly release the lock held by other users on running configuration store. This command is not supported for candidate and startup configuration stores.
NetConf client 1 locks the running configuration store
yangcli ocnos@127.1> lock target=running
RPC OK Reply 6 for session 6:
Netconf client 2 tries to acquire running configuration store leads to an error.
yangcli ocnos@127.1> lock target=running
RPC Error Reply 21 for session 4:
rpc-reply {
rpc-error {
error-type protocol
error-tag lock-denied
error-severity error
error-app-tag no-access
error-message 'lock denied'
error-info {
session-id 6
error-number 268
}
}
}
NetConf client 2 (network-admin) decides to acquire the lock forcibly.
yangcli ocnos@127.1> force-unlock target=running
RPC OK Reply 22 for session 4:
yangcli ocnos@127.1> lock target=running
RPC OK Reply 23 for session 4:
Force unlock shall be issued with a timer value “after=<0-600> seconds” this command would inform existing lock holder about his lock expiry timeline.
Neconf client 2 (only network-admin) issues force-unlock command with a timer value of 60 seconds. Now after 60 seconds any other user is allowed to lock the running configuration store.
yangcli ocnos@127.1> force-unlock target=running after=60
RPC OK Reply 10 for session 6:
After 60 or more seconds, client shall issue lock command.
yangcli ocnos@127.1> lock target=running
RPC OK Reply 12 for session 6:
NetConf client 1 receives below notification about his lock expiry. To receive yangcli ocnos@127.1>
Incoming notification:
notification {
eventTime 2017-09-20T19:51:09Z
force_unlock {
message '% Session running config store lock will be released in 60 seconds'
}
}
Sys-reload
Use this RPC to cold restart the device.
Example:
yangcli ocnos@10.12.39.115> sys-reload
Enter boolean value for leaf <save-config>
yangcli ocnos@10.12.39.115:sys-reload>
false true
yangcli ocnos@10.12.39.115:sys-reload> true
RPC OK Reply 1 for session 4:
Sys-shutdown
Use this RPC to shut down the device.
Example:
yangcli ocnos@10.12.39.115> sys-shutdown
Enter boolean value for leaf <save-config>
yangcli ocnos@10.12.39.115:sys-shutdown>
false true
yangcli ocnos@..39.115:sys-shutdown>true
Custom RPC Support in OcNOS
CLI-based Configuration RPC
Load configuration RPC
The cmlsh provides the load-config CLI command to merge a specified configuration file directly to the running configuration.
To perform this operation via NetConf, two RPCs are available, depending on the source of the configuration file.
load-config-filepath
The load-config-file path RPC is used to load a CLI-style configuration file from the local file system on the device and apply it to the running configuration. This operation follows a merge strategy, where configuration lines are processed sequentially, similar to pasting commands directly into the CLI.
RPC:
rpc load-config-filepath {
description "This RPC will load the backup configuration in the source attribute via cli";
input {
leaf source {
type string;
description "Name of the source backup file to be restored into running-config";
}
leaf operation-type {
type enumeration {
enum continue-on-error {
description "Continue to process configuration data on error(default)";
}
enum rollback-on-error {
description "Initiate rollback when it receives error";
}
}
description "control the behavior of configuration changes when an error occurs during a transaction or commit operation";
}
}
output {
leaf show-cli-status {
type string;
description "Show the result of cli execution";
}
leaf show-failed-cli {
type string;
description "Show the list of cli Failed";
}
}
}
Example:
yangcli ocnos@127.1> load-config-filepath source=/home/config.txt
RPC OK Reply 1 for session 1:
yangcli ocnos@127.1>
load-config-server
The load-config-server RPC performs the same operation, but the configuration file is fetched from a remote server using supported protocols such as SCP or FTP.
rpc load-config-server {
description "This RPC will apply the backup configuration in the source attribute";
input {
leaf mode {
type enumeration {
enum scp {
description "Download files via scp";
}
enum tftp {
description "Download files via tftp";
}
enum ftp {
description "Download files via ftp";
}
enum sftp {
description "Download files via sftp";
}
}
description "Load-config download file mode";
}
leaf source {
type string;
description "Name of the source backup file to be restored into running-config Enter URL scp:[//server][/path/ filename]"; }
leaf vrf {
type string;
description "VRF Name";
}
leaf operation-type {
type enumeration {
enum continue-on-error {
description "Continue to process configuration data on error(default)";
}
enum rollback-on-error {
description "Initiate rollback when it receives error";
}
}
description "control the behavior of configuration changes when an error occurs during a transaction or commit operation";
}
}
output {
leaf show-cli-status {
type string;
description "Show the result of cli execution";
}
leaf show-failed-cli {
type string;
description "Show the list of cli Failed";
}
}
}
Example:
yangcli ocnos@127.1> load-config-server source=scp://root:root123@10.16.99.116/home/2.txt mode=scp vrf=management
RPC Data Reply 1 for session 2:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<show-cli-status xmlns="http://ipinfusion.com/ns/zebmcli">Success<show-failed-cli xmlns="http://ipinfusion.com/ns/zebmcli"/>
</rpc-reply>
The load-config RPCs return execution results through two output fields:
• show-cli-status
• show-failed-cli
The show-cli-status field provides a summary of the overall status of the CLI execution, including any errors during the commit phase. This helps identify if the configuration was partially or fully applied.
The show-failed-cli field lists specific CLI commands that failed validation due to issues such as invalid input, incorrect value ranges, or unsupported commands. These outputs facilitate troubleshooting and correction of configuration errors during automated provisioning via NetConf.
Example:
yangcli ocnos@127.1> load-config-server source=scp://root:root123@10.16.99.116/home/2.txt mode=scp vrf=management
RPC Data Reply 1 for session 2:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<show-cli-status xmlns="http://ipinfusion.com/ns/zebmcli">% ' /profiles/hardware-profile/statistics/config/ingress-acl' % configuration not found
% ' /dns/vrfs/vrf[vrf-name='default']/config/lookup-enabled' % configuration not found</show-cli-status>
<show-failed-cli xmlns="http://ipinfusion.com/ns/zebmcli"/>
</rpc-reply>
Copy-text configuration
The copy-text-config RPC provides a way to replace the entire configuration on a device using a CML (Command Line Model) formatted text configuration file. It applies to both the running-config and startup-config and supports file transfers via standard protocols or local file access.
This feature is functionally similar to copy-config but is intended specifically for CML-based configurations (as used in CLI) rather than full XML data stores. It is especially useful for operators familiar with CLI-style configurations who want to load complete system configurations in one operation.
copy-text-config RPC
Syntax:
rpc copy-text-config {
description "This RPC will replace the current config with the configuration in the source attribute";
input {
leaf mode {
type cml-data-types:cml_remote_mgmt_t;
mandatory true;
description "copy-text-config download file mode";
}
leaf target {
type enumeration {
enum running-config {
description "running config-store";
}
enum startup-config {
description "startup config-store";
}
}
mandatory true;
description "Type of config store";
}
leaf source {
type string;
mandatory true;
description "Name of the source backup file to be restored into running-config Enter URL <source>:[//server][/path/ filename]"; }
leaf vrf {
type string;
description "VRF Name";
}
}
output {
leaf show-cli-status {
type string;
description "Show the result of cli execution";
}
}
}
Parameter | Description |
mode | Transfer protocol (scp, sftp, ftp, tftp, filepath) |
source | Full path or URL of the source configuration file |
target | Destination config (only running-config or startup-config) |
vrf | VRF name for routing transfer traffic (required for remote URLs) Note: Not mandatory when using the default VRF. |
Example:
Using SCP with Management VRF
yangcli ocnos@127.1> copy-text-config
mode=scp
source=scp://user:pass@host/path/config.txt vrf=management
Enter enumeration value for leaf <target>
yangcli ocnos@127.1:copy-text-config> running-config
RPC Data Reply 1 for session 1:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<show-cli-status xmlns="http://ipinfusion.com/ns/zebmcli">Success</show-cli-status>
</rpc-reply>
yangcli ocnos@127.1> copy-text-config mode=scp source=scp://root:root123@10.16.99.116/home/178B.txt target=running-config vrf=management
2025 Jun 13 11:56:52.424 : 7020 : CML : ALERT : [CML_1]: Applying bulk configuration, performance may be impacted by high CPU usage Please consider limiting CPU usage by using the command 'cml bulk-config limit cpu enable' Limiting CPU usage may impact commit time, but will preserve overall node performance
2025 Jun 13 11:56:52.431 : 7020 : CML : CRITI : Validating: 50% [||||||||||||||||||||||||| ] ETA: 00:12:10
RPC Data Reply 2 for session 1:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<show-cli-status xmlns="http://ipinfusion.com/ns/zebmcli">Success</show-cli-status>
</rpc-reply>
yangcli ocnos@127.1>
Using SCP with Default VRF
yangcli ocnos@127.1> copy-text-config
mode=scp
source=scp://user:pass@host/path/config.txt
Enter enumeration value for leaf <target>
yangcli ocnos@127.1:copy-text-config> running-config
RPC Data Reply 1 for session 1:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<show-cli-status xmlns="http://ipinfusion.com/ns/zebmcli">Success</show-cli-status>
</rpc-reply>
Using Local File Path
yangcli ocnos@127.1> copy-text-config
mode=filepath
source=/home/ocnos/config.txt
Enter enumeration value for leaf <target>
yangcli ocnos@127.1:copy-text-config> startup-config
RPC Data Reply 1 for session 1:
rpc-reply {
show-cli-status 'System reboot is required to load this startup-config
Copy Success'
}
yangcli ocnos@127.1>
Custom show RPC
custom-cmlsh-show-rpc
The custom-cmlsh-show-rpc retrieves outputs of CLI show commands via NetConf.
Note: The CLI command provided as input to this RPC must always start with the keyword “show” other command types are not supported.
RPC:
rpc custom-cmlsh-show-rpc {
description "This RPC will execute the cmlsh show command";
input {
leaf source {
type string;
description "source indicate the cli which need to be executed via cmlsh";
}
}
output {
leaf show-cli-status {
type string;
description "Show the result of cli execution";
}
}
}
source = Enter the show command to be executed within “ “(double quotes)
Example 1:
show techsupport cli
yangcli root@127.1> custom-cmlsh-show-rpc source="show techsupport status"
RPC Data Reply 1 for session 1:
rpc-reply {
show-config-file-status 'Tech-Support Command Needs To Be Executed
Tar File is generated at and file name begins with '''
}
yangcli root@127.1> custom-cmlsh-rpc source="show techsupport bgp"
RPC Data Reply 2 for session 1:
rpc-reply {
show-config-file-status 'This command may take a while to complete and may cause slowness in response.
Tar File is generated at /var/log and file name begins with 'OcNOS_tech_support_bgp''
}
yangcli root@127.1> custom-cmlsh-show-rpc source="show techsupport all"
RPC Data Reply 4 for session 1:
rpc-reply {
show-config-file-status 'Tech-support is in progress, please wait a moment...
Previous command is still in execution. Please wait....'
}
yangcli root@127.1> custom-cmlsh-show-rpc source="show techsupport status"
RPC Data Reply 5 for session 1:
rpc-reply {
show-config-file-status 'Tech Support Command Execution Is In Progress
Protocol Id : nsm is success
Protocol Id : ripd is success
Protocol Id : ripngd is success
Protocol Id : ospfd is success
Protocol Id : ospf6d is success
Protocol Id : isisd is success
Protocol Id : hostpd is success
Protocol Id : ldpd is success
Protocol Id : rsvpd is success
Protocol Id : mribd is success
Protocol Id : pimd is success
Protocol Id : authd is success
Protocol Id : mstpd is success
Protocol Id : imi is success
Protocol Id : onmd is success
Protocol Id : oamd is success
Protocol Id : vlogd is success
Protocol Id : vrrpd is success
Protocol Id : ribd is success
Protocol Id : bgpd is success
Protocol Id : l2mribd is success
Protocol Id : lagd is success
Protocol Id : sflow is success
Protocol Id : udld is success
Protocol Id : cmld is success
Protocol Id : cmld is success
Protocol Id : pserv is success
Protocol Id : pcepd is success
/var/log/OcNOS_tech_support_bgp_28_Apr_2024_17_19_55.tar.gz_tmp
Tar File is generated at /var/log and file name begins with 'OcNOS_tech_support_bgp''
}
yangcli root@127.1>
Example 2:
yangcli ocnos@127.1>
yangcli ocnos@127.1> custom-cmlsh-show-rpc source="show running-config"
RPC Data Reply 1 for session 1:
rpc-reply {
show-cli-status '!
feature netconf-ssh vrf management
feature netconf-tls vrf management
no feature netconf-ssh
no feature netconf-tls
!
service password-encryption
!
snmp-server enable traps link linkDown
snmp-server enable traps link linkUp
!
hardware-profile statistics voq-full-color enable
hardware-profile statistics cfm-ccm enable
!
qos enable
!
tfo Disable
errdisable cause stp-bpdu-guard
no feature telnet vrf management
no feature telnet
feature ssh vrf management
no feature ssh
feature dns relay
ip dns relay
ipv6 dns relay
feature ntp vrf management
ntp enable vrf management
!
ip vrf --1234567890ABCDE__abcde
!
ip vrf 28dx_5b_36d_5b
rd 40:40
route-target both 40:40
!
ip vrf __0987654321--ABCDE__abcde--XY__
!
ip vrf management
rd 51:51
route-target both 40:40
!
ip vrf netconf_tst
rd 3:3
route-target both 1:1
!
ip vrf newvrf1
!
ip vrf s2_vrf
!
ip vrf site1
rd 2.2.2.2:2
route-target both 1:1
route-target both 40:40
!
ip vrf snmp-vrf
!
ip vrf snmpvrf2
!
ip vrf teslnet_test
rd 2:2
route-target both 1:1
!
ip vrf vrf1
!
ip vrf vrf2
!
ip vrf vrf30
!
ip vrf vrf_A
!
ip vrf vrf_B
!
mac vrf newmacvrf
rd 300:1
route-target both evpn-auto-rt
!
mac vrf object-test3
router-id 102.143.73.1
!
mac vrf thisismacvrf
rd 999:1
route-target both evpn-auto-rt
!
mac vrf vrfmac-new
rd 1:2
route-target both 33:33
!
router ldp
router-id 2.2.2.2
transport-address ipv4 2.2.2.2
!
interface ce64
!
interface ce65
!
interface ce66
!
interface ce67
!
interface ce68
!
interface ce69
!
interface ce70
!
interface ce71
!
interface eth0
ip vrf forwarding management
ip address dhcp
!
interface lo
ip address 127.0.0.1/8
ipv6 address ::1/128
!
interface lo.management
ip vrf forwarding management
ip address 127.0.0.1/8
ipv6 address ::1/128
!
interface tengig64
!
interface tengig65
!
interface xe0
!
interface xe1
!
interface xe2
!
interface xe3
!
interface xe4
!
exit
!
router ospf 1
ospf router-id 20.20.20.20
network 1.2.3.0/24 area 0.0.0.0
network 2.2.2.2/32 area 0.0.0.0
network 10.10.10.0/24 area 0.0.0.0
network 172.22.3.0/24 area 0.0.0.0
network 172.25.1.0/24 area 0.0.0.0
!
router bgp 100
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source 2.2.2.2
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 update-source 2.2.2.2
!
address-family vpnv4 unicast
neighbor 1.1.1.1 activate
neighbor 5.5.5.5 activate
exit-address-family
!
address-family vpnv6 unicast
neighbor 5.5.5.5 activate
exit-address-family
!
address-family ipv4 vrf 28dx_5b_36d_5b
redistribute connected
exit-address-family
!
address-family ipv4 vrf netconf_tst
redistribute connected
exit-address-family
!
address-family ipv4 vrf site1
redistribute connected
exit-address-family
!
address-family ipv4 vrf teslnet_test
redistribute connected
exit-address-family
!
address-family ipv6 vrf 28dx_5b_36d_5b
redistribute connected
exit-address-family
!
exit
!
!
end
!
! Software version: UFI_S9600-72XC-OcNOS-SP-PLUS-6.6.1.136-MR 06/25/2025 01:57:03
!
! Last configuration change at 17:05:42 UTC Thu May 29 2025 by root'
}
yangcli ocnos@127.1>
Candidate Difference RPC
netconf-config-diff RPC
The netconf-config-diff RPC compares the candidate configuration with the running configuration and returns their differences in a structured format (XML or JSON). This allows operators or automation systems to preview configuration changes before committing them.
RPC: netconf-config-diff
yang RPC:
rpc netconf-config-diff {
description "This RPC will comparing two NETCONF datastores (e.g., candidate vs. running) and display the diff-generated";
input {
leaf diff-format {
type enumeration {
enum xml {
description "Output diff format is xml(default)";
}
enum json {
description "Output diff format is json";
}
}
description "The diff format represents the format in which differences are displayed";
}
}
output {
leaf show-diff {
type string;
description "Show the result of diff";
}
}
}
Example RPC Request - JSON Format
Example:
JSON format:
yangcli ocnos@0> edit-config config=@/home/ospf.xml
Filling container /edit-config/input/target:
RPC OK Reply 1 for session 1:
yangcli ocnos@0> netconf-config-diff diff-format=json
RPC Data Reply 2 for session 1:
rpc-reply {
show-diff '--- /root/.yuma/running.conf 2025-01-05 18:05:21.636195650 +0000
+++ /root/.yuma/candidate.conf 2025-01-05 18:05:21.344195650 +0000
@@ -243,6 +243,19 @@
}
}
},
+ "ospfv2":{
+ "processes":{
+ "process":[
+ {
+ "ospf-id":"1",
+ "config":{
+ "ospf-id":"1",
+ "vrf-name":"default"
+ }
+ }
+ ]
+ }
+ },
"trigger-failover":{
"config":{
"admin-status":"disable"'
}
Example RPC Request - XML Format
yangcli ocnos@0> netconf-config-diff diff-format=xml
RPC Data Reply 3 for session 1:
rpc-reply {
show-diff '--- /root/.yuma/running.conf 2025-01-05 18:05:54.589195650 +0000
+++ /root/.yuma/candidate.conf 2025-01-05 18:05:54.301195650 +0000
@@ -232,6 +232,17 @@
</error-disable>
</global>
</interfaces>
+<ospfv2 xmlns="http://www.ipinfusion.com/yang/ocnos/ipi-ospf">
+ <processes>
+ <process>
+ <ospf-id>1</ospf-id>
+ <config>
+ <ospf-id>1</ospf-id>
+ <vrf-name>default</vrf-name>
+ </config>
+ </process>
+ </processes>
+</ospfv2>
<trigger-failover xmlns="http://www.ipinfusion.com/yang/ocnos/ipi-tfo">
<config>
<admin-status>disable</admin-status>'
}
yangcli ocnos@0>
Backup-configuration
create-backup-configuration
The create-backup-configuration RPC creates a backup of the current running configuration.
Syntax:
rpc create-backup-configuration {
description "This RPC will create a backup based on the current running-config";
}
Example
yangcli ocnos@10.12.44.177> create-backup-configuration
RPC OK Reply 1 for session 1:
yangcli ocnos@10.12.44.177>
show-backup-configurations
The backup configuration can be checked with the following RPC command:
Syntax:
rpc show-backup-configurations {
description "This RPC will retrieve all backup file names from the system";
output {
leaf show-backup-configurations {
type string;
description "Shows available backup config file names";
}
}
}
Example:
yangcli ocnos@10.12.44.177> show-backup-configurations
RPC Data Reply 2 for session 1:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<show-backup-configurations xmlns="http://ipinfusion.com/ns/zebmcli">Filename Created-on
OcNOS_1669930083.conf Dec-01, 2022, 21:28:03 UTC</show-backup-configurations>
</rpc-reply>
restore-backup-configuration
To restore a backup configuration, use the following RPC:
rpc restore-backup-configuration {
description "This RPC will restore the backedup configuration in the source attribute";
input {
leaf source {
type string;
description "Name of the source backup file to be restored into running-config";
}
}
}
Example:
yangcli ocnos@10.12.44.177> restore-backup-configuration source=OcNOS_1669930083.conf
RPC OK Reply 3 for session 1:
Feature-netconf
set-feature-netconf-status
The set-feature-netconf-status RPC enables or disables the NetConf feature.
rpc set-feature-netconf-status {
description "Enable/Disable NetConf feature";
input {
leaf status {
type enumeration {
enum disable {
value 0;
description "Disable netconf feature to restrict client to connect";
}
enum enable {
value 1;
description "Enable netconf feature to allow client to connect";
}
}
mandatory true;
description "Provide input value to enable/disable feature";
}
}
}
Example:
yangcli ocnos@127.1> set-feature-netconf-status
Enter enumeration value for leaf <status>
yangcli ocnos@127.1:set-feature-netconf-status> disable
RPC OK Reply 5 for session 2:
yangcli ocnos@127.1> get-feature-netconf-status
RPC Data Reply 6 for session 2:
rpc-reply {
status disable
}
yangcli ocnos@127.1>
get-feature-netconf-status
The get-feature-netconf-status RPC retrieves the current status of the NetConf feature.
rpc get-feature-netconf-status {
description "This RPC will display the netconf feature status";
output {
leaf status {
type enumeration {
enum disable {
value 0;
description "Disable netconf feature to restrict client to connect";
}
enum enable {
value 1;
description "Enable netconf feature to allow client to connect";
}
}
description "Leaf to display status of the feature";
}
}
}
Example:
yangcli ocnos@127.1> get-feature-netconf-status
RPC Data Reply 4 for session 2:
rpc-reply {
status enable
}
yangcli ocnos@127.1>
Transaction-limit
set-transaction-limit
OcNOS supports transaction-oriented configuration management, where each configuration change is treated as part of an implicit transaction initiated by edit-config operations. These transactions are finalized using either a commit or discard-changes operation, ensuring reliable and atomic updates.
By default, OcNOS supports up to 5,000 configuration changes per transaction, but this limit can be increased by the user as needed using this RPC:
rpc set-transaction-limit {
description "This RPC will allow user to set number of transactions allowed per commit";
input {
leaf transaction-limit {
type uint32 {
range "0..300000";
}
mandatory true;
description "Number of operation in single netconf transaction set 0 for no limit";
}
}
}
Example:
yangcli ocnos@127.1> set-transaction-limit
Enter uint32 value for leaf <transaction-limit>
yangcli ocnos@127.1:set-transaction-limit> 70000
RPC OK Reply 7 for session 2:
yangcli ocnos@127.1>
show-transaction-limit
The show-transaction-limit RPC displays the current transaction limit per commit.
rpc show-transaction-limit {
description "This RPC will display the transaction limit per commit";
output {
leaf transaction-limit {
type string;
description " Displays number of transaction-limit";
}
}
}
Example:
yangcli ocnos@127.1> show-transaction-limit
RPC Data Reply 8 for session 2:
rpc-reply {
transaction-limit 'Max-Transaction Limit is 70000'
}
yangcli ocnos@127.1>
Auto-config-sync
The auto-config-sync (enable|disable) is used to enable or disable the auto-config-sync after each commit.
rpc auto-config-sync {
description "This RPC will allow the user to enable or disable auto config sync";
input {
leaf status {
type enumeration {
enum disable {
description "disable config auto sync";
}
enum enable {
description "enable config auto sync";
}
}
description "Enable or disable auto config sync. Once enabled config sync operation will be started whenever any
nfiguration is performed";
}
}
}
Example:
yangcli ocnos@127.1> auto-config-sync status=enable
RPC OK Reply 10 for session 2:
yangcli ocnos@127.1>