Firefox https://cll-ng.cisco.

com/content/xtrac/1

Task 1: Use NETCONF Via SSH

In this task, you connect to the NETCONF server on the IOS XE (Cisco CSR 1000v) device in the training lab. You also see the initial capabilities response, which indicates that NETCONF is functioning
correctly.

Step 1:
Access the NETCONF SSH server for the Cisco CSR 1000v device from a terminal. The password is cisco.
ssh -p 830 cisco@csr1kv -s netconf
Enter the following information (password = cisco).

Step 2:
Examine the NETCONF capabilities for the Cisco CSR 1000v. Use the scroll bar on the right portion of the page to view all available content.
Review the information:

The first set of capabilities that you see are the capabilities of the NETCONF protocol functions of the device. These capabilities will look like the following:
<capability>urn:ietf:params:netconf:base:1.1</capability>

The response will be the NETCONF capabilities supported by the device. Seeing these capabilities tells you that NETCONF is working on that device. The capabilities start with the following output:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
The capabilities concept is introduced in Section 1 of RFC 6241, Network Configuration Protocol (NETCONF), which says: “NETCONF allows a client to discover the set of protocol extensions supported by
a server. These ‘"capabilities’" permit the client to adjust its behavior to take advantage of the features exposed by the device. The capability definitions can be easily extended in a non-centralized manner.
Standard and non-standard capabilities can be defined with semantic and syntactic rigor. Capabilities are discussed in Section 8 of this document.”
As a developer, you may recognize NETCONF capabilities as a form of introspection, which is the ability of a program to examine the type or properties of an object at run time.
The first two capabilities are the NETCONF 1.0 and 1.1 capabilities. These capabilities refer to the original, RFC 4741 which is NETCONF 1.0, and RFC6241, which makes RFC 4741 obsolete and is
NETCONF 1.1. The NETCONF-specific URNs are defined in IANA document Network Configuration Protocol (NETCONF) Capability URNs.
The list of capabilities is more than 100 lines long, and gets longer with each release that adds more capabilities. The full list of capabilities for Cisco IOS XE Release 16.03.01 can be found in the
xe_16.03.01_capabilities.xml file.

Step 3:
Examine the vendor-specific capabilities for the Cisco CSR 1000v. Use the scroll bar on the right portion of the page to view all available content.
Note
Vendor-specific capabilities represent the bulk of the NETCONF capabilities of a device. These capabilities differ from one device to another depending on how its NETCONF server was implemented, and
the intrinsic capabilities of the network operating system.
Vendor-specific capabilities can be identified by name space references such as http://tail-f.com/ns, or http://cisco.com/ns/yang/, or urn:cisco:params:xml:ns:yang, for example:
://cisco.com/ns/yang/, or urn:cisco:params:xml:ns:yang, for example:
<capability>http://tail-f.com/ns/mibs/SNMP-NOTIFICATION-MIB/200210140000Z?module=SNMP-NOTIFICATION-MIB&amp;revision=2002-10-14</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-memory-stats?module=cisco-memory-stats&amp;revision=2015-04-09</capability>
<capability>urn:cisco:params:xml:ns:yang:cisco-acl-oper?module=cisco-acl-oper&amp;revision=2016-03-30</capability>
<capability>http://cisco.com/ns/yang/Cisco-IOS-XR-tunnel-gre-cfg?module=Cisco-IOS-XR-tunnel-gre-cfg&amp;revision=2016-05-25</capability>

The candidate configuration capability is described in Section 8.3 of RFC 6241, which says: “The candidate configuration capability,: candidate, indicates that the device supports a candidate configuration
datastore, which 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. A <commit> operation MAY be performed at any
time that causes the device's running configuration to be set to the value of the candidate configuration.”
The confirmed commit capability is described in Section 8.4 of RFC 6241, which says: “The: confirmed-commit:1.1 capability indicates that the server will support the <cancel-commit> operation and the
<confirmed>, <confirm-timeout>, <persist>, and <persist-id> parameters for the <commit> operation.”
This mechanism reverts configuration changes that are not committed within a given period, by default 600 seconds. This capability is especially useful if you make a change to connectivity parameters that
inadvertently cause you to be disconnected from a device. If you are disconnected and you cannot commit the configuration changes, the changes will be reverted and connectivity will thus be restored.
The candidate and confirmed that commit capabilities are not present in IOS XE Software, which instead has the following, which is not present in IOS XR Software:
<capability>urn:ietf:params:netconf:capability:notification:1.0</capability>
Event notification capability is defined in RFC 5277, NETCONF Event Notifications, which say: “… a mechanism whereby the NETCONF client indicates interest in receiving event notifications from a
NETCONF server by creating a subscription to receive event notifications. The NETCONF server replies to indicate whether the subscription request was successful and, if it was successful, begins sending
the event notifications to the NETCONF client as the events occur within the system. These event notifications will continue to be sent until either the NETCONF session is terminated or the subscription
terminates for some other reason.”
IOS XE Software has this capability as its NETCONF implementation uses SNMP traps as the basis for notifications.

Task 2: Get the YANG Schema

In this task, you retrieve YANG schema directly from the device in a NETCONF SSH session. You will use operations that are defined in RFC 6022, the YANG Module for NETCONF Monitoring.
You will also see how the differences in the support base capabilities for NETCONF affect the client response and message encoding, as described in Section 4, Using NETCONF over SSH, of RFC 6242,
Using the NETCONF Protocol over Secure Shell (SSH).

1 din 6 27.05.2020, 09:55

Firefox https://cll-ng.cisco.com/content/xtrac/1

The messages that you will need to send to the server are defined in the ~/git/code_files/netconf_ssh_messages.xml file. You can copy-and-paste from that file to the terminal window where you have your
NETCONF SSH session with the device.

Say hello to the Cisco CSR 1000v NETCONF server over SSH, as defined in Section 3.1 of RFC 6242.
Before you can send RPCs to the NETCONF server, you must say hello to the server and complete the capabilities exchange. This exchange is defined in Section 3.1 of RFC 6242.
As a reminder, you started the NETCONF SSH session with the Cisco CSR 1000v with this command at the Linux CLI: $ ssh -p 830 cisco@csr1kv -s netconf
After you see the end of the initial hello message from the server, you must respond with a hello message from the client, that is, your SSH session in your terminal. The following is an example of the end of
the hello message from the server:
…
</capabilities>
<session-id>17511</session-id></hello>]]>]]>
Note
The ]]>]]> character sequence, which is the message separator defined in RFC 6242 for the base 1.0 capability. After you see that character sequence, you, the client, must respond with a message like the
following. A sample message that you can copy -and -paste is in the netconf_ssh_messages.xml file under the heading: Hello message from client to server for CSR1Kv.

Step 1:
Open the File Explorer from the left task bar, and select the git directory by double-clicking the git directory icon.
Make the following selections:

Step 2:
Double-click the code_files directory.
Make the following selections:

Step 3:
Right-click the netconf_ssh_messages.xml file and select Open With.. > gedit.
Make the following selections:

2 din 6 27.05.2020, 09:55

Firefox https://cll-ng.cisco.com/content/xtrac/1

Step 4:
Select the contents under the heading “Hello message from client to server for CSR1Kv” to highlight it.
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>]]>]]>
Make the following selections:

Step 5:
Right-click the highlighted content and select Copy from the pop-up menu.
Make the following selections:

Step 6:
Return to the terminal window, right-click on the window and paste the contents into the terminal window.
Make the following selections:

3 din 6 27.05.2020, 09:55

Firefox https://cll-ng.cisco.com/content/xtrac/1

The client response that is shown here will work for the Cisco CSR 1000v IOS XE device, which supports the base 1.0 and base 1.1 NETCONF capabilities.
After you send the appropriately formatted hello to the respective devices, you can send additional RPCs, which you will do in the next steps.

Next, you will use a get message to see the available schemas for the Cisco CSR 1000v, as illustrated in Section 4.1 of RFC 6022.
To properly request a given schema, you must first determine which schemas are actually available to see all the schema names and versions. Having said hello in the previous step, you can now send a get
message.
The following is an example of the message format for IOS XE Software. A sample message that you can copy and paste is in the netconf_ssh_messages.xml file under the heading: Get schema message
from client to server for CSR1Kv. Note that you are using the NETCONF <get> operation here.

Step 7:
Return to the Text Editor by selecting the icon in the left navigation pane.
Make the following selection:

4 din 6 27.05.2020, 09:55

Firefox https://cll-ng.cisco.com/content/xtrac/1

Step 8:
From the netconf_ssh_messages.xml file. Select the contents under the heading “Hello message from client to server for CSR1Kv” to highlight it.
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<netconf-state xmlns= "urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<schemas/>
</netconf-state>
</filter>
</get>
</rpc>]]>]]>
Make the following selection:

Step 9:
Right-click the highlighted content and select Copy from the pop-up menu.
Make the following selections:

5 din 6 27.05.2020, 09:55

Firefox https://cll-ng.cisco.com/content/xtrac/1

Step 10:
Once again, return to the terminal window, right-click on the window and paste the contents into the terminal window.
The response will be a long list of schemas. In practice, you would need to copy and paste that list into a separate document and edit it to be able to see it properly. For your reference, the full list of schemas
for the Cisco CSR 1000vIOS XE Release 16.03.1 can be seen in the xe_16.03.1_schema.xml file.

The client response that is shown here will work for the Cisco CSR 1000v IOS XE device, which supports the base 1.0 and base 1.1 NETCONF capabilities.
After you send the appropriately formatted hello to the respective devices, you can send additional RPCs, which you will do in the next steps.
Step 11:
Press the Enter key to end this lab.

Summary and Next Steps

In this discovery lab, you used an SSH session to interact directly with the NETCONF servers on a device. You saw how the client and server exchanged capabilities, and how that exchange affects which
message formats the server will accept. You also saw how to examine capabilities for deviations, and how to query for the schema that defines those deviations.
You have also seen that although you exchange messages over the SSH session, it is a detailed and potentially error-prone process. There is also much more that you would need to do to make this process
effective in development. For those myriad other development tasks, and to use code that has been tested to process message exchanges properly, you have the ncclient library, which is discussed in another
topic in this course.

6 din 6 27.05.2020, 09:55