Introduction to NETCONF
With YANG being the data model representation of network devices, there is a need for a transport mechanism to push configuration changes or read network device configuration. The Network Configuration Protocol, or NETCONF, is the network management protocol application programming interface (API) used with YANG to manage network devices. In fact, it is within the YANG RFCs that NETCONF is specified to be used as the transport protocol as NETCONF actually does not define content or data models. Network vendors have adopted NETCONF as a service or agent on their platforms, normally having to be explicitly configured to be enabled. Once enabled, this allows for client/server communication.
The NETCONF protocol makes use of remote procedure calls (RPCs) between the client side device and the server side device, i.e. the network device. These RPCs are sent over a secure and connection-oriented session. Through the IETF, this session has come to use SSH. The default listening port on NETCONF enabled network devices is port 830. Each RPC made from the client is typically encoded in Extensible Markup Language or XML. Likewise, each reply from the server (network device), is typically encoded in XML. Thus, whether NETCONF is being used to push configuration changes or query for configuration using YANG, the configuration is represented as structured-date in XML.
It is important to ensure one understands the information above and how the transport protocol and data model work together. The graphic below is a high-level representation of the TCP/IP frame format for an RPC:
NETCONF Protocol Stack
The proceeding information above can be defined as the NETCONF Protocol Stack, also called the NETCONF Protocol Layers. This stack establishes the logical connection between the network administrator or the network administering application and the network device. Conceptually, the NETCONF stack can be divided into four layers. These layers are Transport, Messages, Operations, and Content. As shown in the following graphic, the Transport layer provides the communication socket between the client and server. The Messages layer defines the RPC encoding mechanism; in this case we're examining XML- encoding. The Operations layer defines a set of operations part of the protocol that can be invoked via RPCs. Some of these operations will modify the configuration, while others will read the entire or portions of the configuration. The Content layer is, again, where the tie in is with YANG data models. YANG represents the data.
NETCONF Capabilities
The first action you must take is to connect to the NETCONF enabled network device via SSH using normal authentication means, but remember, by default the NETCONF service is listening on port 830. Upon successful connection to the device, your client and the server will exchange hello messages that contain each's respective NETCONF capabilities. Throughout this lab, you will explore various methods and tools in which to obtain a devices capabilities non-programmatically and programmatically. One such non-programmable method is to visit the GitHub repository and browsing under the Cisco vendor directory: https://github.com/YangModels/yang/tree/master/vendor/cisco
NETCONF Operations
The NETCONF operations can be found in the table below. As previously mentioned, you can get all or parts of a device configuration or you can modify or edit the network device's configuration, amongst other operations. In subsequent sections of this lab, you are going to work with the majority of these operations.
NETCONF Data Stores
NETCONF defines the existence of one or more configuration datastores and allows configuration operations on them. A configuration
datastore is defined as the complete set of configuration data that is required to get a device from its initial default
state into a desired operational state. The running configuration datastore holds the complete configuration currently
active on the network device. Only one configuration datastore of this type exists on the device, and it is always present.
NETCONF protocol operations refer to this datastore using the
