The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes how to use the XML management interface to configure devices.
Feature Name |
Releases |
Feature Information |
---|---|---|
XML Management Interface |
7.3(0)N1(1) |
Added the following NetConf enhancements: |
You can use the XML management interface to configure a device. The interface uses the XML-based Network Configuration Protocol (NETCONF), which allows you to manage devices and communicate over the interface with an XML management tool or program. The Cisco NX-OS implementation of NETCONF requires you to use a Secure Shell (SSH) session for communication with the device.
NETCONF is implemented with an XML Schema (XSD) that allows you to enclose device configuration elements within a remote procedure call (RPC) message. From within an RPC message, you select one of the NETCONF operations that matches the type of command that you want the device to execute. You can configure the entire set of CLI commands on the device with NETCONF. For information about using NETCONF, see the Creating NETCONF XML Instances and RFC 4741.
For more information about using NETCONF over SSH, see RFC 4742 .
This section includes the following topics:
The following are the NETCONF layers:
Layer |
Example |
---|---|
Transport protocol |
SSHv2 |
RPC |
rpc, rpc-reply |
Operations |
get-config, edit-config |
Content |
show or configuration command |
The following is a description of the four NETCONF layers:
The device software provides an SSH service called xmlagent that supports NETCONF over SSH Version 2.
Note | The xmlagent service is referred to as the XML server in Cisco NX-OS software. |
NETCONF over SSH is initiated by the exchange of a Hello message between the client and the XML server. After the initial exchange, the client sends XML requests, which the server responds to with XML responses. The client and server terminate requests and responses with the character sequence >. Because this character sequence is not valid in XML, the client and the server can interpret when messages end, which keeps communication synchronized.
The XML schemas that define XML configuration instances that you can use are described in Creating NETCONF XML Instances .
Product |
License Requirement |
---|---|
Cisco NX-OS |
The XML management interface requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS image and is provided at no extra charge to you. For a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide . |
The XML management interface has the following prerequisites:
Note | Use the XML management interface with the default settings on the device. |
By default, the SSH server is enabled on your device. If you disable SSH, you must enable it before you start an SSH session on the client PC.
You can configure XML server options to control the number of concurrent sessions and the timeout for active sessions. You can also enable XML document validation and terminate XML sessions.
Note | The XML server timeout applies only to active sessions. |
For more information about configuring SSH, see http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/nx-os/security/configuration/guide/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_7-x.html.
For more information about the XML commands, see http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus7000/sw/system-management/guide/b_Cisco_Nexus_7000_Series_NX-OS_System_Management_Configuration_Guide-RI.html.
The following example shows how to configure SSH and XML server options through the CLI:
switch# configure terminal switch(config)# xml server validate all switch(config)# xml server terminate 8665 switch(config)# no feature ssh switch(config)# feature ssh server switch(config)# xml server max-session 6 switch(config)# xml server timeout 2400 switch(config)# copy running-config startup-config
You can start an SSHv2 session on a client PC with the ssh2 command similar to the following:
ssh2 username@ip-address -s xmlagent
Enter the login username, the IP address of the device, and the service to connect to. The xmlagent service is referred to as the XML server in the device software.
Note | The SSH command syntax might differ based on the SSH software on the client PC. |
If you do not receive a Hello message from the XML server, verify the following conditions:
You must advertise your capabilities to the server with a Hello message before the server processes any other requests. When you start an SSH session to the XML server, the server responds immediately with a Hello message that informs the client of the server’s capabilities. The XML server supports only base capabilities and in turn expects support only for these base capabilities from the client.
The following are sample Hello messages from the server and the client:
Note | You must end all XML documents with ]]>]]> to support synchronization in NETCONF over SSH. |
<?xml version="1.0"?> <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability> </capabilities> <session-id>25241</session-id> </hello>]]>]]>
<?xml version="1.0"?> <nc:hello xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <nc:capabilities> <nc:capability>urn:ietf:params:xml:ns:netconf:base:1.0</nc:capability> </nc:capabilities> </nc:hello>]]>]]>
Step 1 | From your
browser, navigate to the Cisco software download site at
http://software.cisco.com/download/navigator.html The Download Software window opens. |
Step 2 | From the list of products displayed, choose Switches > Data Center Switches > platform > model . |
Step 3 | If you are not already logged in as a registered Cisco user, you are prompted to log in now. |
Step 4 | From the Select a Software Type list, choose NX-OS XML Schema Definition. |
Step 5 | Find the desired release and click Download. |
Step 6 | If you are
requested to, follow the instructions to apply for eligibility to download
strong encryption software images.
The Cisco End User License Agreement is displayed. |
Step 7 | Click Agree and follow the instructions to download the file to your PC. |
To send an XML document to the XML server through an SSH session that you opened in a command shell, copy the XML text from an editor and paste it into the SSH session. Although typically you use an automated method to send XML documents to the XML server, you can verify the SSH connection to the XML server through this copy-paste method.
Following are the guidelines to send the XML document to the XML Server:
You can create NETCONF XML instances by enclosing the XML device elements within an RPC tag and NETCONF operation tags. The XML device elements are defined in feature-based XML schema definition (XSD) files, which enclose available CLI commands in an XML format.
The following are the tags used in the NETCONF XML request in a framework context. Tag lines are marked with the following letter codes:
X <?xml version="1.0"?> R <nc:rpc message-id="1" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" R xmlns="http://www.cisco.com/nxos:1.0:nfcli”> N <nc:get> N <nc:filter type="subtree"> D <show> D <xml> D <server> D <status/> D </server> D </xml> D </show> N </nc:filter> N </nc:get> R </nc:rpc>]]>]]> |
Note | You must use your own XML editor or XML management interface tool to create XML instances. |
All NETCONF XML instances must begin with the RPC request tag <rpc>. The <rpc> element has a message-id attribute. This message-id attribute is replicated in the <rpc-reply> and can be used to correlate requests and replies. The <rpc> node also contains the following XML namespace declarations:
<nc:rpc message-id="315" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns=http://www.cisco.com/nxos:1.0:nfcli"> ... </nc:rpc>]]>]]>
<?xml version="1.0"?> <nc:rpc message-id="16" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0:if_manager"> <nc:edit-config> <nc:target> <nc:running/> </nc:target> <nc:config> <configure> <__XML__MODE__exec_configure> <interface> <ethernet> <interface>2/30</interface> <__XML__MODE_if-ethernet> <__XML__MODE_if-eth-base> <description> <desc_line>Marketing Network</desc_line> </description> </__XML__MODE_if-eth-base> </__XML__MODE_if-ethernet> </ethernet> </interface> </__XML__MODE__exec_configure> </configure> </nc:config> </nc:edit-config> </nc:rpc>]]>]]>
Note:
__XML__MODE tags are used internally by the NETCONF agent. Some tags are present only as children of a certain __XML__MODE. By examining the schema file, you should be able to find the correct mode tag that leads to the tags representing the CLI command in XML.
NETCONF provides the following configuration operations:
NETCONF Operation |
Description |
Example |
---|---|---|
close-session |
Closes the current XML server session. |
NETCONF Close Session Instance |
commit |
Sets the running configuration to current contents of candidate configuration. |
NETCONF Commit Instance - Candidate Configuration Capability |
confirmed-commit |
Provides the parameters to commit the configuration for a specified period of time. If this operation is not followed by a commit operation within the confirm-timeout period, the configuration will be reverted to the state prior to the confirmed-commit operation. |
NETCONF Confirmed Commit Instance |
copy-config |
Copies the content of source configuration datastore to the target datastore. |
NETCONF Copy Config Instance |
delete-config |
Operation not supported. |
— |
edit-config |
Configures features in the running configuration of the device. You use this operation for configuration commands. Starting Release 7.3(0)D1(1), support is added for actions - create, delete and merge; rollback-on-error, continue-on-error, stop-on-error. |
NETCONF Edit Config Instance NETCONF Rollback-On-Error Instance |
get |
Receives configuration information from the device. You use this operation for show commands. The source of the data is the running configuration. |
Creating NETCONF XML Instances |
get-config |
Retrieves all or part of a configuration |
NETCONF Get Config Instance |
kill-session |
Closes the specified XML server session. Note that you cannot close your own session. |
NETCONF Kill Session Instance |
lock |
Allows the client to lock the configuration system of a device. |
NETCONF Lock Instance |
unlock |
Releases the configuration lock issued by the session earlier. |
NETCONF Unlock Instance |
validate |
Checks a candidate configuration for syntactical and semantic errors before applying the configuration to the device. |
NETCONF Validate Capability Instance |
The XML device elements represent the available CLI commands in XML format. The feature-specific schema files contain the XML tags for CLI commands of that particular feature. See Obtaining XML Schema Definition (XSD) Files.
Using this schema, it is possible to build an XML instance. For example, the relevant portions of the nfcli.xsd schema file that was used to build the NETCONF instances (Creating NETCONF XML Instances) is shown in the following examples.
<xs:element name="show" type="show_type_Cmd_show_xml"/> <xs:complexType name="show_type_Cmd_show_xml"> <xs:annotation> <xs:documentation>to display xml agent information</xs:documentation> </xs:annotation> <xs:sequence> <xs:choice maxOccurs="1"> <xs:element name="xml" minOccurs="1" type="xml_type_Cmd_show_xml"/> <xs:element name="debug" minOccurs="1" type="debug_type_Cmd_show_debug"/> </xs:choice> </xs:sequence> <xs:attribute name="xpath-filter" type="xs:string"/> <xs:attribute name="uses-namespace" type="nxos:bool_true"/> </xs:complexType>
<xs:complexType name="xml_type_Cmd_show_xml"> <xs:annotation> <xs:documentation>xml agent</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="server" minOccurs="1" type="server_type_Cmd_show_xml"/> </xs:sequence> </xs:complexType> <xs:complexType name="server_type_Cmd_show_xml"> <xs:annotation> <xs:documentation>xml agent server</xs:documentation> </xs:annotation> <xs:sequence> <xs:choice maxOccurs="1"> <xs:element name="status" minOccurs="1" type="status_type_Cmd_show_xml"/> <xs:element name="logging" minOccurs="1" type="logging_type_Cmd_show_logging_facility"/> </xs:choice> </xs:sequence> </xs:complexType>
<xs:complexType name="status_type_Cmd_show_xml"> <xs:annotation> <xs:documentation>display xml agent information</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="__XML__OPT_Cmd_show_xml___readonly__" minOccurs="0"> <xs:complexType> <xs:sequence> <xs:group ref="og_Cmd_show_xml___readonly__" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:group name="og_Cmd_show_xml___readonly__"> <xs:sequence> <xs:element name="__readonly__" minOccurs="1" type="__readonly___type_Cmd_show_xml"/> </xs:sequence> </xs:group> <xs:complexType name="__readonly___type_Cmd_show_xml"> <xs:sequence> <xs:group ref="bg_Cmd_show_xml_operational_status" maxOccurs="1"/> <xs:group ref="bg_Cmd_show_xml_maximum_sessions_configured" maxOccurs="1"/> <xs:group ref="og_Cmd_show_xml_TABLE_sessions" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType>
Note | “__XML__OPT_Cmd_show_xml___readonly__” is optional. This tag represents the response. For more information on responses, see RPC Response Tag. |
You can use the | XML option to find the tags that you should use to execute a <get> operation. The following is an example of the | XML option.
The following example shows you that the namespace defining tag used to execute operations on this device is http://www.cisco.com/nxos:1.0:nfcli and that the nfcli.xsd file can be used to build requests.
You can enclose the NETCONF operation tags and the device tags within the RPC tag. The </rpc> end-tag is followed by the XML termination character sequence.
Switch#> show xml server status | xml <?xml version="1.0" encoding="ISO-8859-1"?> <nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0:nfcli"> <nf:data> <show> <xml> <server> <status> <__XML__OPT_Cmd_show_xml___readonly__> <__readonly__> <operational_status> <o_status>enabled</o_status> </operational_status> <maximum_sessions_configured> <max_session>8</max_session> </maximum_sessions_configured> </__readonly__> </__XML__OPT_Cmd_show_xml___readonly__> </status> </server> </xml> </show> </nf:data> </nf:rpc-reply> ]]>]]>
Cisco NX-OS supports an <rpc> operation named <exec-command>. The operation allows client applications to send CLI configuration and show commands and to receive responses to those commands as XML tags.
The following is an example of the tags used to configure an interface. Tag lines are marked with the following letter codes:
The following table provides a detailed explanation of the operation tags:
Tag |
Description |
---|---|
<exec-command> |
Executes a CLI command. |
<cmd> |
Contains the CLI command. A command can be a show or configuration command. Multiple configuration commands should be separated by a semicolon (;). Multiple show commands are not supported. You can send multiple configuration commands in different <cmd> tags as part of the same request. For more information, see the Example on Configuration CLI Commands Sent Through <exec-command> . |
Replies to configuration commands that are sent through the <cmd> tag are as follows:
The show command must be sent in its own <exec-command> instance as shown in the following example:
X <?xml version="1.0"?> R <nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="3"> EO <nxos:exec-command> EO <nxos:cmd>conf t ; interface ethernet 2/1 </nxos:cmd> EO <nxos:cmd>channel-group 2000 ; no shut; </nxos:cmd> EO </nxos:exec-command> R </nf:rpc>]]>]]>
The following is the response to the send operation:
<?xml version="1.0" encoding="ISO-8859-1"?> <nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="3"> <nf:ok/> </nf:rpc-reply> ]]>]]>
The following example shows how the show CLI commands that are sent through the <exec-command> can be used to retrieve data:
<?xml version="1.0"?> <nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="110"> <nxos:exec-command> <nxos:cmd>show interface brief</nxos:cmd> </nxos:exec-command> </nf:rpc>]]>]]>
<?xml version="1.0" encoding="ISO-8859-1"?> <nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" xmlns:mod="http://www.cisco.com/nxos:1.0:if_manager" message-id="110"> <nf:data> <mod:show> <mod:interface> <mod:__XML__OPT_Cmd_show_interface_brief___readonly__> <mod:__readonly__> <mod:TABLE_interface> <mod:ROW_interface> <mod:interface>mgmt0</mod:interface> <mod:state>up</mod:state> <mod:ip_addr>172.23.152.20</mod:ip_addr> <mod:speed>1000</mod:speed> <mod:mtu>1500</mod:mtu> </mod:ROW_interface> <mod:ROW_interface> <mod:interface>Ethernet2/1</mod:interface> <mod:vlan>--</mod:vlan> <mod:type>eth</mod:type> <mod:portmode>routed</mod:portmode> <mod:state>down</mod:state> <mod:state_rsn_desc>Administratively down</mod:state_rsn_desc> <mod:speed>auto</mod:speed> <mod:ratemode>D</mod:ratemode> </mod:ROW_interface> </mod:TABLE_interface> </mod:__readonly__> </mod:__XML__OPT_Cmd_show_interface_brief___readonly__> </mod:interface> </mod:show> </nf:data> </nf:rpc-reply> ]]>]]>
<?xml version="1.0"?> <nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="3"> <nxos:exec-command> <nxos:cmd>configure terminal ; interface ethernet2/1 </nxos:cmd> <nxos:cmd>ip address 1.1.1.2/24 </nxos:cmd> <nxos:cmd>no channel-group 2000 ; no shut; </nxos:cmd> </nxos:exec-command> </nf:rpc>]]>]]> <?xml version="1.0" encoding="ISO-8859-1"?> <nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="3"> <nf:rpc-error> <nf:error-type>application</nf:error-type> <nf:error-tag>invalid-value</nf:error-tag> <nf:error-severity>error</nf:error-severity> <nf:error-message>Ethernet2/1: not part of port-channel 2000 </nf:error-message> <nf:error-info> <nf:bad-element>cmd</nf:bad-element> </nf:error-info> </nf:rpc-error> </nf:rpc-reply> ]]>]]>
As a result of a command's execution, the IP address of the interface is set, but the administrative state is not modified (the no shut command is not executed) because the no port-channel 2000 command results in an error.
The <rpc-reply> as a result of a show command that is sent through the <cmd> tag contains the XML output of the show command.
You cannot combine configuration and show commands on the same <exec-command> instance. The following example shows config and show commands combined in the same instance.
<?xml version="1.0"?> <nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="110"> <nxos:exec-command> <nxos:cmd>conf t ; interface ethernet 2/1 ; ip address 1.1.1.4/24 ; show xml server status </nxos:cmd> </nxos:exec-command> </nf:rpc>]]>]]> <?xml version="1.0" encoding="ISO-8859-1"?> <nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="110"> <nf:rpc-error> <nf:error-type>application</nf:error-type> <nf:error-tag>invalid-value</nf:error-tag> <nf:error-severity>error</nf:error-severity> <nf:error-message>Error: cannot mix config and show in exec-command. Config cmds before the show were executed. Cmd:show xml server status</nf:error-message> <nf:error-info> <nf:bad-element>cmd</nf:bad-element> </nf:error-info> </nf:rpc-error> </nf:rpc-reply> ]]>]]>
<?xml version="1.0"?> <nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="110"> <nxos:exec-command> <nxos:cmd>show xml server status ; show xml server status </nxos:cmd> </nxos:exec-command> </nf:rpc>]]>]]> <?xml version="1.0" encoding="ISO-8859-1"?> <nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="110"> <nf:rpc-error> <nf:error-type>application</nf:error-type> <nf:error-tag>invalid-value</nf:error-tag> <nf:error-severity>error</nf:error-severity> <nf:error-message>Error: show cmds in exec-command shouldn't be followed by anything </nf:error-message> <nf:error-info> <nf:bad-element><cmd></nf:bad-element> </nf:error-info> </nf:rpc-error> </nf:rpc-reply> ]]>]]>
For every XML request sent by a client, the XML server sends an XML response enclosed in the RPC response tag <rpc-reply>.
The following example shows the RPC response tag <rpc-reply>.
<nc:rpc-reply message-id=”315” xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns=http://www.cisco.com/nxos:1.0:nfcli"> <ok/> </nc:rpc-reply>]]>]]>
The elements <ok>, <data>, and <rpc-error> can appear in the RPC response. The following table describes the RPC response elements that can appear in the <rpc-reply> tag.
Element |
Description |
---|---|
<ok> |
The RPC request completed successfully. This element is used when no data is returned in the response. |
<data> |
The RPC request completed successfully. The data associated with the RPC request is enclosed in the <data> element. |
<rpc-error> |
The RPC request failed. Error information is enclosed in the <rpc-error> element. |
The device tags encapsulated in the <data> tag contain the request, followed by the response. A client application can safely ignore all the tags before the <readonly> tag. The following is an example:
<?xml version="1.0" encoding="ISO-8859-1"?> <nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0:if_manager"> <nf:data> <show> <interface> <__XML__OPT_Cmd_show_interface_brief___readonly__> <__readonly__> <TABLE_interface> <ROW_interface> <interface>mgmt0</interface> <state>up</state> <ip_addr>xx.xx.xx.xx</ip_addr> <speed>1000</speed> <mtu>1500</mtu> </ROW_interface> <ROW_interface> <interface>Ethernet2/1</interface> <vlan>--</vlan> <type>eth</type> <portmode>routed</portmode> <state>down</state> <state_rsn_desc>Administratively down</state_rsn_desc> <speed>auto</speed> <ratemode>D</ratemode> </ROW_interface> </TABLE_interface> </__readonly__> </__XML__OPT_Cmd_show_interface_brief___readonly__> </interface> </show> </nf:data> </nf:rpc-reply> ]]>]]>
Note | <__XML__OPT.*> and <__XML__BLK.*> appear in responses and are sometimes used in requests. These tags are used by the NETCONF agent and are present in responses after the <__readonly__> tag. They are necessary in requests, and should be added according to the schema file to reach the XML tag that represents the CLI command. |
This section provides examples of the following XML instances:
The following examples show the close-session request, followed by the close-session response:
<?xml version="1.0"?> <nc:rpc message-id="101" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0"> <nc:close-session/> </nc:rpc>]]>]]>
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0" message-id="101"> <nc:ok/> </nc:rpc-reply>]]>]]>
The following examples show the kill session request, followed by the kill-session response:
<nc:rpc message-id="101" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0"> <nc:kill-session> <nc:session-id>25241</nc:session-id> </nc:kill-session> </nc:rpc>]]>]]>
<?xml version="1.0"?> <nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0" message-id="101"> <nc:ok/> </nc:rpc-reply>]]>]]>
The following examples show the copy config request, followed by the copy config response:
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <copy-config> <target> <running/> </target> <source> <url>https://user@example.com:passphrase/cfg/new.txt</url> </source> </copy-config> </rpc>
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
The following examples show the use of NETCONF edit config:
<?xml version="1.0"?> <nc:rpc message-id="16" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0:if_manager"> <nc:edit-config> <nc:target> <nc:running/> </nc:target> <nc:config> <configure> <__XML__MODE__exec_configure> <interface> <ethernet> <interface>2/30</interface> <__XML__MODE_if-ethernet> <__XML__MODE_if-eth-base> <description> <desc_line>Marketing Network</desc_line> </description> </__XML__MODE_if-eth-base> </__XML__MODE_if-ethernet> </ethernet> </interface> </__XML__MODE__exec_configure> </configure> </nc:config> </nc:edit-config> </nc:rpc>]]>]]>
<?xml version="1.0"?> <nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0:if_manager" message-id="16"> <nc:ok/> </nc:rpc-reply>]]>]]>
The operation attribute in edit config identifies the point in configuration where the specified operation will be performed. If the operation attribute is not specified, the configuration is merged into the existing configuration data store. The operation attribute can have the following values:
The following example shows how to delete the configuration of interface Ethernet 0/0 from the running configuration:
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <default-operation>none</default-operation> <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"> <top xmlns="http://example.com/schema/1.2/config"> <interface xc:operation="delete"> <name>Ethernet0/0</name> </interface> </top> </config> </edit-config> </rpc>]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>]]>]]>
The following examples show the use of the NETCONF get-config:
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-config> <source> <running/> </source> <filter type="subtree"> <top xmlns="http://example.com/schema/1.2/config"> <users/> </top> </filter> </get-config> </rpc>]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <top xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>root</name> <type>superuser</type> <full-name>Charlie Root</full-name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> <!-- additional <user> elements appear here... --> </users> </top> </data> </rpc-reply>]]>]]>
The following examples show a lock request, a success response and a response to an unsuccessful attempt:
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <lock> <target> <running/> </target> </lock> </rpc>]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> <!-- lock succeeded --> </rpc-reply>]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rpc-error> <!-- lock failed --> <error-type>protocol</error-type> <error-tag>lock-denied</error-tag> <error-severity>error</error-severity> <error-message> Lock failed, lock is already held </error-message> <error-info> <session-id>454</session-id> <!-- lock is held by NETCONF session 454 --> </error-info> </rpc-error> </rpc-reply>]]>]]>
The following examples show the use of NETCONF unlock operation:
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <unlock> <target> <running/> </target> </unlock> </rpc>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
The following examples show the commit operation and the commit reply:
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/> </rpc>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
The following examples show a confirmed-commit operation and a confirmed-commit reply:
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit> <confirmed/> <confirm-timeout>120</confirm-timeout> </commit> </rpc>]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>]]>]]>
The following examples show the how to configure rollback on error and the response to this request.
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <error-option>rollback-on-error</error-option> <config> <top xmlns="http://example.com/schema/1.2/config"> <interface> <name>Ethernet0/0</name> <mtu>100000</mtu> </interface> </top> </config> </edit-config> </rpc>]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>]]>]]>
The following examples show the use of NETCONF validate capability that is identified by the string urn:ietf:params:netconf:capability:validate:1.0:
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <validate> <source> <candidate/> </source> </validate> </rpc>]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>]]>]]>
This section provides additional information related to implementing the XML management interface.
Standards |
Title |
---|---|
No new or modified standards are supported by this feature. Support for existing standards has not been modified by this feature. |
— |
RFCs |
Title |
---|---|
NETCONF Configuration Protocol |
|
Using the NETCONF Configuration Protocol over Secure Shell (SSH) |