When the CLI format is used at the NETCONF content layer, configuration changes and information retrieved are expressed as untagged (non-XML) CLI commands; for example, CLI script.
The script must be correctly ordered and has the same dependencies and behavior as CLI. The location of CR/LF (ENTER) within the CLI for an <edit-config> request is significant and affects the processing of the CLI commands, such as which CLI branch is considered the ‟working context”. In the following two examples the ‟working context” after the commands issued are different.
exit all [<-ENTER]
configure system time zone EST [<-ENTER]
exit all [<-ENTER]
configure [<-ENTER]
system [<-ENTER]
time [<-ENTER]
zone EST [<-ENTER]
After example 1, the CLI working context is the root, and immediately sending ‟dst-zone CEST” would return an error. After example 2, the CLI working context is config>system>time and sending ‟dst-zone CEST” would work as expected.
Configuration changes made using NETCONF trigger the same ‟change” log events (for example, tmnxConfigCreate) as a normal CLI user doing the same changes.
The <with-defaults> tag, as defined in RFC 6243, is not supported in a CLI content layer request.
The operator can get a full configuration, including defaults for a CLI content layer, using an empty <cli-info-detail>. The full configuration (equivalent to the CLI command admin display-config [detail]) can be obtained using a <get-config> request in a CLI content layer format with an empty <cli-info> or <cli-info-detail> tag inside a <config-format-cli-block>. The <report-all> tag is not supported.
The following post-processing commands are ignored: "| match" (pipe match), "| count" (pipe count) and ">" (redirect to file). CLI ranges are not supported for any command; for example, show card [1..5].
See CLI content layer examples for more information.