NETCONF & YANG Configuration

Network Automation
1

Hello, everyone

As mentioned in my previous post, I was planning to include this under the Device Programmability lesson since it covers APIs, RESTCONF, NETCONF, etc, but I actually have rather long questions about every individual protocol and having it all in 1 post would be hard to read and very long, so I decided to separate them this way.

My first question regarding NETCONF is… how do you guys configure it? What are the best practices? I feel it’s quite complex to actually open up and go through all the YANG models and figure out what container to use, what to configure, etc. A lot of resources use ietf-interfaces as example because it’s short and easy to use, but the others aren’t very easy to work with.

obrázok
obrázok548×645 77.3 KB

What I usually do is I create one loopback as a test and then retrieve the running configuration. I then use the relevant tags to create the other ones.

In YANG terms, what exactly is a key? I see that every list has one.

bgp-yang-img2
bgp-yang-img21200×541 58.4 KB

Here comes the NETCONF part.

from ncclient import manager
from xml.dom import minidom

device = {
    "host": "192.168.170.200",
    "port": 830,
    "username": "admin",
    "password": "cisco",
    "hostkey_verify": False
}

ospf_config= """
<config>
    <native>
        <router operation="merge">
            <router-ospf>
                <ospf>
                    <process-id>
                            <id>110</id>
                            <network>
                                <ip>0.0.0.0</ip>
                                <wildcard>255.255.255.255</wildcard>
                                <area>0</area>
                                </network>
                    </process-id>
                </ospf>
            </router-ospf>
        </router>
    </native>
</config>
"""

with manager.connect(**device) as netconnect:
    result = netconnect.edit_config(target="running", config=ospf_config).xml
    print(minidom.parseString(result).toprettyxml())

This configuration on its own refuses to work unless I do this with the ospf_config variable

ospf_config= """
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
        <router operation="merge">
            <router-ospf xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-ospf">
                 <ospf>
                    <process-id>
                        <id>110</id>
                        <network>
                             <ip>0.0.0.0</ip>
                                <wildcard>255.255.255.255</wildcard>
                                <area>0</area>
                                </network>
                    </process-id>
                </ospf>
            </router-ospf>
        </router>
    </native>
</config>
"""

Basically, the <config> part has xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" added and native plus router-ospf also have an xmlns that refers to the YANG model they come from

Is this part absolutely necessary for the code to work? Without it, the device doesn’t get configured.

That’s all, thank you.
David

2

Hello David

Indeed, the learning curve for the use of NETCONF is somewhat steep, especially for networking engineers who typically don’t have extensive experience in coding and scripting. I believe that the most important approach is to gain experience. As you perform the labs that appear in NetworkLessons and modify them for your own purposes, and as you research to determine the most appropriate commands and syntax to use for specific implementations, you will gain the appropriate experience to know how to approach each problem. Your process of creating a loopback as a test and retrieving the running config are always good steps to start. You can then always build from there. Ultimately, it is a matter of experience.

In YANG, a key is an element (or set of elements) that uniquely identifies an entry in a list. The key must be provided when creating, retrieving, or modifying list entries. You can think of it as a primary key in a database table.

Yes, this part is necessary. NETCONF is XML-based, and YANG models are mapped to XML namespaces. When you send a configuration, without any namespaces, the device doesn’t know what model you’re referring to. It might treat it as an unqualified element, and the parser can’t resolve it against any known YANG module.

I hope this has been helpful!

Laz