Device Programmability

Lessons Discussion
45

Hello Dominique

I consulted with @ReneMolenaar on this one, and there doesn’t seem to be a definite answer as there is no available explanation for it. The following explains why it is done like this:

From RFC8040 you’ll find the following explanation in section 4.1.1:

4.4.1. Create Resource Mode

If the target resource type is a datastore or data resource, then the
POST is treated as a request to create a top-level resource or child
resource, respectively. The message-body is expected to contain the
content of a child resource to create within the parent (target
resource). The message-body MUST contain exactly one instance of the
expected data resource. The data model for the child tree is the
subtree, as defined by YANG for the child resource.

This means that with a URL like this: https://10.65.90.105/restconf/data/ietf-interfaces:interfaces

We use a body like this:

{
      "ietf-interfaces:interface": {
          "name": "Loopback1",
          "description": "RESTCONF-TEST",
          "type": "iana-if-type:softwareLoopback",
          "enabled": true,
          "ietf-ip:ipv4": {
              "address": [
                  {
                      "ip": "1.1.1.1",
                      "netmask": "255.255.255.0"
                  }
              ]
          }
      }
  }

It is confusing, but as Rene mentioned to me, there’s no information that tells us why they came up with 4.4.1 as a requirement.

Although it is not a definitive answer, I hope this sheds some light on the subject!

Laz

46

Hello,
I’d like a suggestion of a downloadable platform (or software) where i can practice RESTCONF, REST API and NETCONF.
In case you don’t have something like this, could you give me a step-by-step to create this labs?
Preferably for Windows, but Linux is ok.
Thanks.

47

Hello Antonio

Take a look at this lesson here:

In the lesson, you’ll see how both NETCONF and RESTCONF are applied using various tools. In the lesson, a Linux device is used as the client in both cases. However, as stated in the lesson:

If you use Microsoft Windows, you can use Linux tools like curl through Windows Subsystem for Linux (WSL) or Docker.

Postman is also a good tool to use for working with APIs. You can find out more about it in the lesson linked above.

I hope this has been helpful!

Laz

48

HI

I’m starting practicing with netconf on my home lab.
I have a Cisco switch C35060-CG with IOS15 that seem to support Netconf.

But I can’t configure netconf like Rene because the switch not support netconf-yang command.

SW(config)#netconf-yang 
                        ^
% Invalid input detected at '^' marker.

SW(config)#netconf ?
  format        specify the format spec file to use
  lock-time     Limit time NETCONF can lock configuration
  max-message   maximum received message size
  max-sessions  Limit total number of NETCONF sessions
  ssh           Use SSH to establish NETCONF session

SW(config)#

So I configured netconf on ssh port (22) and I tested it with python scripts, it works but the switch raise time-out errors..

from ncclient import manager
import configparser

CiscoSW = configparser.ConfigParser()
CiscoSW.read('CiscoDevice.ini')

m = manager.connect(
    host=CiscoSW['CiscoDevice']['host'],
    port=CiscoSW['CiscoDevice']['port'],
    username=CiscoSW['CiscoDevice']['user'],
    password=CiscoSW['CiscoDevice']['psw'],
    hostkey_verify=False,
    look_for_keys=False
)

for capability in m.server_capabilities:
    print(capability)

m.close_session()
print("end")

It gives me the correct reply, but the script is not able to close the connection, ( I am not able to print ‘end’ at the end of the script)

netconf-get-capabilities.py
urn:ietf:params:netconf:base:1.0
urn:ietf:params:netconf:capability:writeable-running:1.0
urn:ietf:params:netconf:capability:rollback-on-error:1.0
urn:ietf:params:netconf:capability:startup:1.0
urn:ietf:params:netconf:capability:url:1.0
urn:cisco:params:netconf:capability:pi-data-model:1.0
urn:cisco:params:netconf:capability:notification:1.0
Traceback (most recent call last):
  File "/home/giova/Documents/GitKrakenRepo/network-automation-orchestration/netconf/netconf-get-capabilities.py", line 25, in <module>
    m.close_session()
  File "/home/giova/.local/lib/python3.9/site-packages/ncclient/manager.py", line 246, in execute
    return cls(self._session,
  File "/home/giova/.local/lib/python3.9/site-packages/ncclient/operations/session.py", line 27, in request
    ret = self._request(new_ele("close-session"))
  File "/home/giova/.local/lib/python3.9/site-packages/ncclient/operations/rpc.py", line 381, in _request
    raise TimeoutExpiredError('ncclient timed out while waiting for an rpc reply.')
ncclient.operations.errors.TimeoutExpiredError: ncclient timed out while waiting for an rpc reply.

Can you help me?

Update

The problem was related to the firmware that was outdated, an update solved the error, but netconf-yang is still not recognized from IOS.
Anyway, I didn’t understand how to write xmls rpc using netconf.
Are there related with the XML tags in the running-config?

For example, I will not be able to run the netconf-get-running-configuration-filter.py script because XML tags on my switch are different than CSR1000V used by Rene (I think), but if so, how can I write new netconf rpc for my scripts?

49

Hello Giovanni

Thanks for the update to your problem, it is useful for everyone reading the forum! Now, in order to get these concepts straithinged out, let’s take a look at the various components involved. We have three things:

  1. netconf
  2. yang
  3. SSH

The first is a network managment and configuration protocol. It uses RPC for communication and XML for configuration data and messages.

The second is a data model.

The third is a transport protocol.

Now Netconf doesn’t have its own transport (like SNMP for example, which does), so it relies on SSH for transport.

Now since your device doesn’t support netconf-yang, the scripts will be different. Rene in the lesson uses YANG which means that the structure and the script will be different. To find out more about RPCs you can create using XML for your device, you’ll have to do a little research online. The following is a good place to start, as it has various examples as well:

You’ll have to research your particular IOS version and platform.

I hope this has been helpful!

Laz

51

I see in the lesson it mentions a script on gitlab to add a loopback interface (netconf-edit-config-add-loopback.py) but I’m not seeing that script available.

It’s one of the only NETCONF actions, adding a new interface, that I can’t get working on my setup, I tried changing the operation in the interface tag to all the operations I know of, but the script always just errors out saying:

ncclient.operations.rpc.RPCError: /if:interfaces/interface[name='Loopback12']/type is not configured

Modifying or deleting an existing loopback all works fine, I just can’t create a new one. Thanks

52

Hello Dustin

The particular error you see here simply states that the Looback12 is non-existent. Take a look at this Cisco documentation that further explains this:

Now the question remains, why would such a message appear for an interface that doesn’t exist when you are attempting to create it? Well, can you share with us some of your code so that we can help you out in the troubleshooting process?

I hope this has been helpful!

Laz

53

Hi Guys
it should be ‘NETCONF uses XML for data encoding and SSH for transport.’ in conclusion instead of ‘NETCONF uses XML for data encoding and RPC for transport.’

54

Hello Kamaldeep

Thanks for pointing this out, I’ll let Rene know to take a look and make any necessary changes.

Laz

55

I am able to use restconf fine on Cisco IOS XE Software, Version 17.09.03a. I saved the running-config and noted restconf was at the very end. However, after the device reboots, restconf is no longer at the end of the config and it is not running. I have to go into config mode and enter restconf again to get it to come back up. How do I persist this so restconf starts automatically?

56

Hello Justin

At the risk of sounding obvious, the first thing I will mention is, are you sure you’re saving your configuration before rebooting? I just mentioned that for completeness, I believe you’ve already checked that.

Other than that, if the restconf command is in the startup-config, it should run normally. When you enable restconf, and before the reboot, does it function correctly as expected? Does your version support it? Restconf also depends upon the HTTP/HTTPS server being enabled, is that up and running?

Also you mention that you see the restconf command in the config, but when you reboot it is gone? Is this in the startup config?

If there is still a problem after checking all of these, it tends to sound like a bug. Check these things out and let us know…

I hope this has been helpful!

Laz

57

Hello, everyone.

Here is my code to retrieve interface information from a device. I have some questions about it.

import requests
from rich import print as rprint

device_url = "https://192.168.170.200:443/restconf/data/ietf-interfaces:interfaces"

headers = {
    "Accept": "application/yang-data+json"
}

response = requests.get(url=device_url, headers=headers, auth=("admin", "cisco"), verify=False)

rprint(response.json())

This returns the following output:

{
    'ietf-interfaces:interfaces': {
        'interface': [
            {'name': 'GigabitEthernet1', 'type': 'iana-if-type:ethernetCsmacd', 'enabled': True, 'ietf-ip:ipv4': {'address': [{'ip': '192.168.170.200', 'netmask': '255.255.255.0'}]}, 'ietf-ip:ipv6': {}},
            {'name': 'GigabitEthernet2', 'type': 'iana-if-type:ethernetCsmacd', 'enabled': False, 'ietf-ip:ipv4': {}, 'ietf-ip:ipv6': {}},
            {'name': 'GigabitEthernet3', 'type': 'iana-if-type:ethernetCsmacd', 'enabled': False, 'ietf-ip:ipv4': {}, 'ietf-ip:ipv6': {}},
            {'name': 'GigabitEthernet4', 'type': 'iana-if-type:ethernetCsmacd', 'enabled': False, 'ietf-ip:ipv4': {}, 'ietf-ip:ipv6': {}},
            {'name': 'Loopback1', 'type': 'iana-if-type:softwareLoopback', 'enabled': True, 'ietf-ip:ipv4': {'address': [{'ip': '1.1.1.1', 'netmask': '255.255.255.255'}]}, 'ietf-ip:ipv6': {}}
        ]
    }
}

My question is, why doesn’t the .json() function work if I don’t specify an accept header? It just returns an error but the code works if I remove it. Does the device not return the data in a JSON format if I don’t specify the header?

My second question is this. Say that I want to configure another loopback. In the output above, we can see that this configuration is located under ietf-interfaces in the interfaces container and the leaf-list that contains these interfaces is called interface. So I edited my configuration to look like this:

import requests
from rich import print as rprint

device_url = "https://192.168.170.200:443/restconf/data/ietf-interfaces:interfaces/interface"

headers = {
    "Accept": "application/yang-data+json",
    "Content-Type": "application/yang-data+json"
}

payload = {
    'ietf-interfaces:interface': [
        {'name': 'Loopback2', 'type': 'iana-if-type:softwareLoopback', 'enabled': True, 'ietf-ip:ipv4': {'address': [{'ip': '2.2.2.2', 'netmask': '255.255.255.255'}]}, 'ietf-ip:ipv6': {}}
    ]
}

response = requests.post(url=device_url, headers=headers, json=payload, auth=("admin", "cisco"), verify=False)

rprint(response.json())

Yet I keep getting this error
{'errors': {'error': [{'error-message': 'POST on list must be on list element', 'error-path': '/ietf-interfaces:interfaces/interface', 'error-tag': 'malformed-message', 'error-type': 'application'}]}}

If I change the url from
device_url = https://192.168.170.200:443/restconf/data/ietf-interfaces:interfaces/interface
to
device_url = https://192.168.170.200:443/restconf/data/ietf-interfaces:interfaces

It works… and I don’t quite get why. The interfaces reside under ietf-interfaces:interfaces/interface - inside the interface list. Yet I cannot send any POST requests to it, I must go a step back and refer to the container as a whole… why? It’s a little confusing.

Thank you.
David

58

Hello David

It fails because if the accept header is omitted, the Cisco IOS XE device defaults to XML. The .json() method then fails because it attempts to parse an XML response as JSON, resulting in a parsing error.

For your second question, yes it can get confusing! Let me try to clarify. The ietf-interfaces model defines two things. The container named interfaces, which is the parent container, and the list named interface, which is a child list where each interface is a list entry.

So, to interact with YANG lists, to reference the entire list, we use /restconf/data/ietf-interfaces:interfaces, and to interact with a list member, we use /restconf/data/ietf-interfaces:interfaces/interface={name} for a specific interface.

So when you used the original URL, it pointed to interfaces/interface, which is not valid for creating a new member. To add a new entry to a list, you must post to the list’s parent container, not the list itself.

So by using the container-level endpoint (…/ietf-interfaces:interfaces), the RESTCONF service knows you’re adding a new item to the interface list. When you try /ietf-interfaces:interfaces/interface with a POST, the server sees you’re hitting the list itself and expects a specific list key or a different method (e.g., PUT). Hence the malformed-message error.

I hope this has been helpful!

Laz