Network element configuration, information retrieval and event notification are the major tasks in network management. Network configurations were till now done using either the command line interface or SNMP or CORBA. NETCONF or network configuration protocol (RFC 6241) came as an alternative and more preferred mechanism for network configuration. It provides a document oriented (XML/YANG) approach to configure and retrieve network element configuration. It also provides locking mechanism.
This seminar will cover:
- NETCONF protocol.
- NETCONF vs SNMP.
- NETCONF datastores – running, candidate and startup.
- NETCONF operations.
- Capabilities in NETCONF
- NETCONF over SSH (RFC 6242)
- Introduction to events in netconf.
- Introduction to Yang data model.
NETCONF is a session-based network management protocol, which uses XML-encoded remote procedure calls (RPCs) and configuration data to manage network devices. The mandatory transport protocol for NETCONF is The Secure Shell Transport Layer Protocol (SSH), and the details for implementing this transport mapping are defined in RFC 4742. The default TCP port assigned for this mapping is 830. A NETCONF server implementation must listen for connections to the 'netconf' subsystem on this port.
All NETCONF operations are carried out within a session, which is tied to the transport layer connection. There is no standard security model for NETCONF yet, but it is assumed that a session represents a particular user with some set of access rights (assigned by an administrator). The NETCONF server is required to authenticate the entity requesting a session before processing any requests from the client. NETCONF messages are encoded in XML, using the UTF-8 character set. For SSH, a special message termination sequence of 6 characters is used to provide message framing.
The NETCONF PRC operations operate on configuration data stores. configuration is a conceptual place to store and access information. A configuration might be implemented, for example, using files or a database. There are three standard configuration data stores, running, candidate, and start up.
A configuration data store holding the complete configuration currently active on the device. The running configuration data store always exists. If the server supports writing to the <running> configuration directly, the writable running capability will normally be advertised by the server. Otherwise the server must support writing to the candidate configuration.
A configuration data store that can be manipulated without impacting the device’s current configuration and that can be committed to the running configuration data store. Not all devices support a candidate configuration data store. This configuration is available if the :candidate capability is advertised by the server. A client can edit candidate configuration and commit the changes to the running configuration. Any changes made to the candidate configuration do not take effect until they are committed.
This is the device’s active running config data store. Care must be taken (e.g. use locks or partial locks) to make sure multiple sessions do not edit the <candidate> configuration at the same time. A server which supports the :candidate capability usually do not at the same time supports the writable running capability.
The startup configuration data store holds the configuration loaded by the device when it boots. Only present on devices that separate the start up configuration data store from the running configuration data store. This database is available if the start up capability is supported by the server. If this configuration is present, the server will not automatically save changes made to the <running> configuration across device reboot. Instead, a <copy-config> operation is needed to update the contents of the start up configuration so the changes will be effective after next reboot.