Configure and manage Cisco devices through NETCONF/RESTCONF

Introduction

Lab workflow

• Connect to a list of NETCONF/RESTCONF compliant device
• Choose and and apply a YANG data model: Native, OpenConfig, IETF, ...
• Retrieves the operationnal status (up/down) of all devices interfaces
• Backup the down's interfaces configuration for later troubleshooting

Lab architecture

Lab ressources

https://github.com/xaviervalette/devnet

Yet Another Next Generation (YANG) - RFC 6020, RFC 7950

YANG is a network-centric data modeling language. This is what defines the structure of the network data, which is separated into configuration and operational data. There are several models for YANG, the biggest ones are IETF, OpenConfig, and Native (vendor specific).

Cisco Blogs is a great place to find high quality content. Indeed, when speacking about YANG model choice, here is a relevant article about this topic.

"When just starting out the IETF models can be great options to learn the protocols, features, and tooling for model driven programmability."

As the context of this lab is an introduction to Model-driven programmability, the IETF model will match this lab requirements.

This lab focus on the interface operationnal state. It will require the "ietf-interfaces" module of the IETF model to do so.

The following tree can be found on the IETF website (https://datatracker.ietf.org/doc/html/rfc8343#section-3).

If we go through it, we can see the targeted read only (because it is operational data) leaf called "oper-status" which is an enumeration. Then we can search for details about this leaf and find out all the possible values that it can take. By doing so, we can code robust and efficient scripts. This lab will focus on the "down" value.

Network Configuration Protocol (NETCONF) - RFC 4741, RFC 6241

NETCONF is a model-driven NETwork CONFiguration protocol, based on the following stack:

Enable NETCONF on a CSR1000V

Below are the steps to enable NETCONF on a Cisco IOS-XE device:

! ENABLE NETCONF SERVICE
csr1(config)# netconf-yang

! CREATE A USER FOR NETCONF ACCESS
csr1(config)# username <user> privilege 15 secret <pass>
        

Now that NETCONF should be enabled, let us send a hello message to get the device capabilities:

devnet@devnet:~$ ssh -p 830 -s [email protected] netconf


[email protected]'s password:

<?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>
        
        -- OMITTED OUTPUT --
        
      </capabilities>
    <session-id>23</session-id>
  </hello>
        

? NETCONF has been successfully enabled and tested.

Python script (https://github.com/xaviervalette/devnet)

Now, an automation script can be written. To do so, I will use Python and the NETCONF Client "ncclient" library, because of its simplicity and flexibility.

1 - Connect to a list of NETCONF compliant device

from ncclient import manager
import xmltodict

-- OMITTED DEVICE VARIABLE ASSIGNEMENT --

with manager.connect(host=host, port=port, username=username, password=password, hostkey_verify=False, device_params=device_params) as m: 
        

2 - Choose and and apply a YANG data model: Native, OpenConfig, IETF

  interfacesStateFilter = """ 
  <filter xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  ? ? <interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
  ? ? </interfaces-state>
  </filter>
  """
        

3 - Retrieves the operationnal status (up/down) of all devices interfaces

  c = m.get(interfacesStateFilter).data_xml
  cDict = xmltodict.parse(c)["data"]
        

4 - Backup the down's interfaces configuration

  for interface in cDict["interfaces-state"]["interface"]:  ? ? 
  ? ? if interface["oper-status"] == "down":
  ? ? ? ? singleInterfacesConfigurationFilter= f""" 
  ? ? ? ? <filter xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  ? ? ? ? ? ? <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
  ? ? ? ? ? ? ? ? <interface><name>{interface["name"]</name></interface>
  ? ? ? ? ? ? </interfaces>
  ? ? ? ? </filter>
  ? ? ? ? """

  ? ? ? ? data=m.get(singleInterfacesConfigurationFilter).data_xml
          print(data)
  
  ? ? ? ? with open(f'{host}_{interface["name"]}.xml', 'w') as f:
  ? ? ? ? ? ? f.write(data)
        

Output

Below is the output of the script:

Let us check the csr1 interface status using CLI:

The script is working as expected. Only GigabitEthernet2 has been backup. Later, a network engineer can check the configuration to troubleshoot the given interfaces.

REST Configuration Protocol (RESTCONF) - RFC 8040

RESTCONF is a model-driven RESTful CONFiguration protocol, based on the following stack:

Below are the steps to enable RESTCONF on a Cisco IOS-XE device:

! ENABLE RESTCONF SERVICE
csr1(config)# restconf

! ENABLE HTTPS SERVER
csr1(config)# ip http secure-server

! CREATE A USER FOR RESTCONF ACCESS
csr1(config)# username <user> privilege 15 secret <pass>        

Now that RESTCONF should be enabled, let us send a GET message:

devnet@devnet:~/Projects/devnet/restconf/requests$ curl -i -k -X "OPTIONS" "https://192.168.1.125:443/restconf/data/ietf-interfaces:interfaces" -H 'Accept: application/yang-data+json' -u 'devnet:devnet'
HTTP/1.1 200 OK        

? RESTCONF has been successfully enabled and tested.

Python script (https://github.com/xaviervalette/devnet)

Now, an automation script can be written. To do so, I will use Python and the HTTP(S) Client "requests" library, because of its simplicity and flexibility.

1 - Connect to a list of NETCONF compliant device

from requests.auth import HTTPBasicAuth
import requests
import xmltodict

-- OMITTED DEVICE VARIABLE ASSIGNEMENT --
        

2 - Choose and and apply a YANG data model: Native, OpenConfig, IETF

baseUrl = f'https://{host}:{port}/restconf/data'
interfaceStateUrl = f'{baseUrl}/ietf-interfaces:interfaces-state/'
        

3 - Retrieves the operationnal status (up/down) of all devices interfaces

headers = {
? ? 'Accept': 'application/yang-data+xml',
? ? 'Content-Type': 'application/yang-data+xml',
}

response = requests.get(url=interfaceStateUrl, auth=HTTPBasicAuth(username, password), headers=headers, verify=False)
        

4 - Backup the down's interfaces configuration

for interface in cDict["interfaces-state"]["interface"]:
  print (f'{interface["name"]} : {interface["oper-status"]}')
  
  if interface["oper-status"] == "down":
  ? ? ? ? response = requests.get(url=f'{baseUrl}/ietf-interfaces:interfaces/interface={interface["name"]}', auth=HTTPBasicAuth(username, password), headers=headers, verify=False)
  ? ? ? ? 
  with open(f'{host}_{interface["name"]}.xml', 'w') as f:
    f.write(response.text)
        

Output

The output of the RESTCONF script is exactly the same as the NETCONF one.

Conclusion

Going from NETCONF to RESTCONF and vice-versa is straightforward thanks to the YANG models. By using the same YANG data model for both NETCONF and RESTCONF workflows, the overall script logic does not change. Indeed, the way data are structured is exactly the same, which is decoupled from transport, protocol and encoding.

Also, in a multi-vendor lab, with many networking device, one script can do the same job on every single YANG compliant device, which consitute another key advantage of model-driven programmability.