When it comes to network automation, NETCONF/YANG has become increasingly popular and is widely adopted. It is crucial to understand the importance of them and the underlying principles behind the NETCONF/YANG when planning for an automated network environment.
Network automation brings agility to an organization, minimizes human error, increases efficiency whilst providing a self-servicing capability to end-users. In order to cater these business requirements, it is necessary to have interactive business portals, intelligence, logics and communications layer with networks. All this requires a network automation platform to comprehensively understand end-to-end network infrastructure, network services offered and how inter-related network nodes are.
Traditional way of network management used SNMP protocol which is still being used by businesses around the world. However, SNMP has inherited limitations due to it’s basic constructs and therefore lacks the capability to perform network automation in real-world production environments. NETCONF addresses these limitations and brings out capabilities that enables networks to be programmed and automated in a much more reliable manner.
Before we move on to NETCONF/YANG, let us have a look at the basics of SNMP. SNMP is developed during late nineteen eighties and has been evolving since then. It’s an agent-server based protocol where agents run on network devices and the server runs on a network monitoring system. Communication between the two takes place over UDP. SNMP uses a data modeling language called SMI (Structured Management Information) and stores its data in a Management Information Base (MIB). Data within the MIBs are stored in a hierarchical manner and each object has an Object ID (OID). These OIDs represent parameters that needs to be monitored such as CPU utilization, memory, etc. When you want to monitor a certain parameter of a device through an NMS, you need to add the OID’s of the devices that you need to monitor. Since OIDs must be added manually it’s not possible for SNMP to automatically monitor and manage a device on its own.
With this understanding about SNMP, let’s try to identify how NETCONF overcomes these drawbacks to enable network automation.
As discussed earlier, network automation requires to visualize and manage end-to-end networks as opposed to managing individual devices. Although SNMP based tools are used to monitor networks, it was predominantly based on ‘device’ monitoring and not really network monitoring. On a broader level this was a primary requirement and NETCONF supports this by defining methods to manage networks not just devices. Therefore, NETCONF achieves one of its fundamental objectives through its technology stack to manage networks and network services than to focus on network devices.
Let’s now move on to NETCONF/YANG. Like SNMP, NETCONF is the network management protocol released by IETF where as YANG is the data modeling language used by NETCONF. NETCONF overcomes drawbacks of SNMP by making it suitable for network management and automation. NETCONF has a client-server architecture that communicates using remote procedure calls. NETCONF operations takes place in a configuration data-store and it defines three configuration data stores. Configuration data store is a conceptual location where configuration data is stored and accessed. Where NETCONF doesn’t restrict creation of any number of data stores, NETCONF defines three configuration data stores. That is ‘running’, ‘start-up’ and ‘candidate’. Out of which ‘running’ configuration data store is where the running configuration is stored and is compulsory. ‘start-up’ configuration data store is where the configurations get loaded by the devices when it boots up and ‘candidate’ configuration data store is where you can manipulate configurations and commit them to a running configuration after validation.
Now let’s look at how capabilities of NETCONF going to help network management and automation. Firstly, NETCONF can distinguish configuration data and state data which allows network administrators to monitor and compare deviations in network state. SNMP did not support this, and therefore it wasn’t possible to separately identify configuration data from the current operating state and statistics data. Due to this reason, a network engineer must manually log-in to a device to view the state or to identify deviations of the state when troubleshooting. Fundamental steps for network automation and intent-based networking is the awareness of current state and having distinguished configuration and state data allows this. This is a key advantage of using NETCONF for network management and automation.
One of the major benefits of NETCONF is its ability to run a transaction. This is a major drawback of SNMP and other CLI based configuration mechanisms which slowed down network automation. Unlike conventional protocols, NETCONF gives the capability to perform transactions such as provisioning, change management, testing and validation enabling network automation use-cases. This is one of the major breakthroughs of NETCONF over conventional management protocols. Transaction can be multiple lines of configurations across a single or multiple device. For instance, take a scenario of creating an L2VPN circuit across two routers, creating a VLAN on multiple L2 switches, assigning an IP to selected interfaces. Each scenario will have few configurations that should be pushed across nodes comprising of the selected network nodes. Ability to perform transactions mean the capability of NETCONF to push configurations on all devices without a fail. In case a failure occurs, it will not push configurations at all. This is called ‘atomic nature’ of transactions as it has a ‘all’ or ‘nothing’ approach. This will make devices to be in always known states. On the other hand, when the configurations are pushed, it doesn’t really matter the sequence of how it’s been pushed. This is called consistency and it means that performing A, B & then C is equivalent to performing B, A and C.
One of the elements that enable ‘transactions’ through NETCONF is it’s transport stack that use TCP. SNMP use UDP for transport where as NETCONF is based on TCP and the sessions are invoked using SSH. This enables ‘transactions’ as packets are transported reliably with two-way communication. Since NETCONF messages are encrypted through SSH, it also provides authenticity, integrity and confidentiality.
Another main capability of NETCONF is the ability to test configurations before the final commit or provisioning. This is made possible by usage of multiple data stores by NETCONF and commit function allows a configuration on the candidate data store to be copied to running data store after validation. This allows testing and validation or testing and rejection.
NETCONF also has an ability to back-up and store configurations. No proper standard mechanism was available with SNMP to back-up or restore configurations from network devices. This was another drawback addressed by NETCONF with which automated back-up and restore are made possible.
Like how SNMP use SMI as a data modeling language, NETCONF use YANG as its data modeling language. YANG data modeling language is used for both configuration data as well as state data. YANG is easy to use, human readable and it uses ‘modules’ to store data like how SNMP use MIBs.
In conclusion, NETCONF breaks away the barriers of SNMP and enables networks to be managed holistically fueling network automation and intent-based networking. Some of the key highlights of NETCONF mentioned here are the distinguished identification of configuration and state data, transaction capability, testing before commit and back-up restore capability which are key ingredients in making network automation possible. All in all, NETCONF is changing how routine tasks are executing and networks are managed for all the good reasons!