Site icon Karneliuk

Automation 4. Extracting and Exploring 6WING YANG Modules with NETCONF, Pyang and Ansible

Hello my friend,

Some time ago we’ve explained how to deploy a 6WING vRouter in a Linux environmennt, such as our Open Source Virtualised cloud with Debian Linux and ProxMox. One of the good things about 6WIND is that its configuration is entirely based on YANG modules and is exposable via NETCONF. Today you will learn how to get 6WIND YANG modules, how are they structured with Pyang and how to automate its extraction with Ansible.


1
2
3
4
5
No part of this blogpost could be reproduced, stored in a
retrieval system, or transmitted in any form or by any
means, electronic, mechanical or photocopying, recording,
or otherwise, for commercial purposes without the
prior permission of the author.

Why Is Everyone so Passionate about Model-Driven Automation and YANG?

All we love nice configuration files made in easy readable YANG or JSON, isn’t it? The beauty of working with them is that you don’t need to create a text string parsers, which is always a difficult task. One of the reasons, why it is so difficult to create parsers, is because of ever changing CLI structures and also values in the semi-formatted text, our ascii tables we see from network devices. Imagine you set the cofiguation of your device as a simple YAML file and the configuration is deployed, just like it is happening in cloud-native world of Kubernetes and Docker. Sounds intriguing, right? That’s why we are so obsessed by the Network Automation based on YANG with NETCONF or GNMI. And we want you to join us in this journey!

At our trainings, zero-to-hero network automation and automation with Nornir (2nd step after zero-to-hero network automation), we give you detailed knowledge of all the technologies relevant:

It was really nice to take the training. Now I’m able to put all pieces of network automation puzzle and start may journey.

Andrew Cervantes @ Senior Network Engineer, MSI Amerikas

Technologies themselves are good, but it is not good enough for us. Therefore, we put all of them in the context of the real use cases, which our team has solved and are solving in various projects in the service providers, enterprise and data centre networks and systems across the Europe and USA. That gives you opportunity to ask questions to understand the solutions in-depts and have discussions about your own projects. And on top of that, each technology is provided with online demos and you are doing the lab afterwards to master your skills. Such a mixture creates a unique learning environment, which all students value so much. Join us and unleash your potential.

Both trainings are available in live class and online formats. And more trainings coming soon!

Start your automation study today.

Brief Description

The YANG modules play a crucial role in the model-driven automation. In a nutshell, they answer the following questions:

At our Network Automation Training you will learn all you need to know about YANG. You will even learn how to create YOUR OWN YANG modules.

As you can imagine, it is vitally important to know answers to these questions in order to be able to configure network devices and also to know what to expect back as an operational data. So, the question is where to get YANG modules for 6WIND Turbo Router? And what’s inside?

Let’s find answers to these questions together.

Lab Topology

In today’s lab we’ll use exactly the same topology, as we created originally:

We continue focusing on the 6WIND vRouter and its communication with our management host S1, which we use to reach the 6wind1 network function via NETCONF. At the same time, as we are doing automation, we need some automation tools on our S1 host, which is running Debian Linux 11:

1. SSH to Manually Interact with 6WIND Turbo Router via NETCONF

One of the key ideas we teach all our students at Network Automation Trainings is that Automation is a optimisation of your knowledge and skills to do the job more efficient (quick and without errors). How is that related to this context? Before jumping straight to Ansible and start writing a code, we need to first understand what exactly we need to do.

Often, YANG modules by vendors are posted at GitHub. For example, You can find there:

However, we haven’t found 6WIND YANG modules across repositories in their official account. It’s not a big deal, though, as we have alternative paths to obtain them… directly from the network device!

NETCONF protocol has a functionality to obtain a list of all YANG modules, which network device supports, via a GET RPC to a netconf-state tree. Once this list is obtained, it is generally possible to retrieve the content of particular YANG module. This is the approach we’ll follow

It is worth to mention, that the second feature may be not implemented. For example, Nokia has embedded YANG modules in its SR OS only in the latest release 21.7.R1. Beforehand it was not possible to download modules from the device.

Step #1.1. Connect to 6WIND Turbo Router via NETCONF with SSH

First of all, you need to establish NETCONF session towards the 6WIND Turbo Router network device. It is relatively easy, as you can use a standard SSH tool available by default in any Linux, MAC and even Windows distribution. You just need to connect to port 830/TCP and add a custom string netconf:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# ssh admin@192.168.101.21 -p 830 -s netconf
Interactive SSH Authentication
Type your password:
Password:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0</capability>
    <capability>urn:ietf:params:netconf:base:1.1</capability>
    <capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
!
! SOME OUTPUT IS TRUNCATED FOR BREVITY
!
    <capability>urn:6wind:vrouter/xvrf?module=vrouter-xvrf&revision=2019-04-05</capability>
  </capabilities>
  <session-id>126</session-id>
</hello>
]]>]]>

Join our Network Automation Training to learn how to automate networks with NETCONF by real-life use cases.

As 6WIND supports both RFC 6241 and RFC 6242 syntax, we’ll use the first one, as it is easier to use in CLI. We’ll send back a hello to 6wind1 network device to finalise the establishing of NETCONF session:


1
2
3
4
5
6
7
<?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>
    </capabilities>
</hello>
]]>]]>

NETCONF session is now established and we can start doing some useful activities.

Step #1.2. Collect the List of All Supported YANG modules

Now we need to collect the list of all supported YANG modules. We can achieve that by using GET RPC to an aforementioned path:


1
2
3
4
5
6
7
8
9
10
11
12
13
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
  <filter type="subtree">
    <netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
      <schemas>
        <schema/>
      </schemas>
    </netconf-state>
    </filter>
  </get>
</rpc>
]]>]]>

The response to this request contains the list of all the supported modules:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
      <schemas>
        <schema>
          <identifier>ietf-yang-metadata</identifier>
          <version>2016-08-05</version>
          <format>yang</format>
          <namespace>urn:ietf:params:xml:ns:yang:ietf-yang-metadata</namespace>
          <location>NETCONF</location>
        </schema>
        <schema>
          <identifier>ietf-yang-metadata</identifier>
          <version>2016-08-05</version>
          <format>yin</format>
          <namespace>urn:ietf:params:xml:ns:yang:ietf-yang-metadata</namespace>
          <location>NETCONF</location>
        </schema>
        <schema>
          <identifier>yang</identifier>
          <version>2017-02-20</version>
          <format>yang</format>
          <namespace>urn:ietf:params:xml:ns:yang:1</namespace>
          <location>NETCONF</location>
        </schema>
!
! SOME OUTPUT IS TRUNCATED FOR BREVITY
!
        <schema>
          <identifier>vrouter-xvrf</identifier>
          <version>2019-04-05</version>
          <format>yin</format>
          <namespace>urn:6wind:vrouter/xvrf</namespace>
          <location>NETCONF</location>
        </schema>
      </schemas>
    </netconf-state>
  </data>
</rpc-reply>]]>]]>

This output is very long; hence, we’ve truncated that a bit. What you are interested in here is the key identifier, which we need in order to retrieve the content of the YANG module.

Step #1.3. Obtain the Content of YANG Modules

The content of the YANG module you can obtain the using a GET-SCHEMA RPC providing as an argument the collected identifier:


1
2
3
4
5
6
7
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-schema xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
    <identifier>vrouter</identifier>
  </get-schema>
</rpc>
]]>]]>

The response to the GET-SCHEMA NETCONF request for the particular schema contains the content of the YANG module:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
<rpc-reply message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
module vrouter {
  yang-version 1.1;
  namespace "urn:6wind:vrouter";
  prefix vrouter;

  organization
    "6WIND";
  contact
    "6WIND support - <support@6wind.com>";
  description
    "6WIND vRouter data model.";

  revision 2018-10-03 {
    description
      "Initial version.";
    reference
      "";
  }
!
! SOME OUTPUT IS TRUNCATED FOR BREVITY
!
  container state {
    config false;
    description
      "6WIND vRouter operational state data.";
    list vrf {
      key "name";
      description
        "Vrf list.";
      leaf name {
        type union {
          type enumeration {
            enum "main" {
              description
                "The main vrf.";
            }
          }
          type string;
        }
        description
          "The vrf name.";
      }
    }
  }
}
  </data>
</rpc-reply>
]]>]]>

Now we have all the components to collect the YANG modules on a NETCONF protocol level. As such, it is a right time to automate the collection of YANG modules with Ansible.

2. Ansible Role to Download YANG Modules

It is assumed that you have Ansible 2.10+ (better, Ansible 2.11 at the time of writing) installed or know how to do that. Join our Network Automation Training to learn how to do that.

Knowing how the overall process of YANG modules extraction works, You can compose the following structure of a role:


1
2
3
4
5
6
+--collector.yaml
+--roles
   +--yang_collection
      +--tasks
         +--main.yaml
         +--poll_yang_module.yaml

Here is a high level summary of files, You are about to create:

Step #2.1. Create collector.yaml Playbook

This playbook is a high level, which executes roles. As such, it is relatively simple:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
---
- name: CONFIGURATION OF 6WIND ROUTER
  hosts: device_roles_dci
  connection: ansible.netcommon.netconf

  vars:
    ansible_user: "{{ lookup('env', 'NETWORK_DEVICE_USERNAME') }}"
    ansible_password: "{{ lookup('env', 'NETWORK_DEVICE_PASSWORD') }}"
    ## Used for execution
    execution_timestamp: "{{ ansible_date_time.iso8601_basic }}"
   
  roles:
    - role: 200_poll_yang_modules
      tags: yang
...

At our Network Automation Training You will develop your Ansible skills in a Zero-to-Hero fashion.

The playbook is created using Ansible 2.10+ syntax and, therefore, it includes the name of the collection, which in this case is ansible.netcommon, and the module itself, which in this case is netconf. As a source for inventory we are using NetBox and credentials to connect to network devices come from the Linux environment, which is considered to be a secure location to store sensitive data.

Step #2.2. Create main.yaml Playbook within the Role

This is where You’d start interacting with the 6WIND Turbo Router virtual network device via NETCONF:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
---
- name: 10. CREATE TEMPORARY DIRECTORY
  delegate_to: localhost
  ansible.builtin.file:
    dest: "{{ output_directory.yang }}/{{ inventory_hostname }}"
    state: directory
    recurse: True

- name: 20. COLLECT LIST OF SUPPORTED YANG MODULES
  ansible.netcommon.netconf_get:
    display: json
    filter: <netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"><schemas><schema/></schemas></netconf-state>
    lock: never
  register: supported_yang_modules

- name: 30. SAVE LIST OF SUPPORTED YANG MODULES
  delegate_to: localhost
  ansible.builtin.copy:
    content: "{{ supported_yang_modules.output | to_nice_json }}"
    dest: "{{ output_directory.yang }}/{{ inventory_hostname }}/000_supported_yang_modules.txt"

- name: 40. COLLECT YANG MODULES
  loop: "{{ supported_yang_modules.output.data['netconf-state'].schemas.schema }}"
  ansible.builtin.include_tasks: poll_yang_module.yaml
...

In this playbook:

Step #2.3. Create poll_yang_module.yaml Playbook within the Role

This is a final playbook to collect the content of YANG module:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
---
- name: 40.10. POLL YANG MODULE FROM DEVICES
  ansible.netcommon.netconf_rpc:
    display: json
    rpc: get-schema
    xmlns: urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
    content:
      identifier: "{{ item.identifier }}"
  register: yang_module_content

- name: 40.20. SAVE YANG MODULE
  delegate_to: localhost
  ansible.builtin.copy:
    content: "{{ yang_module_content.output['nc:rpc-reply'].data }}"
    dest: "{{ output_directory.yang }}/{{ inventory_hostname }}/{{ item.identifier }}.yang"
...

The logo of the playbook is straightforward:

Step #2.4. Execute Created Ansible Playbook

By this time you should be ready to collect all the YANG modules. You just need to launch your playbook and chill for some time, as the collection will take some time:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ ansible-playbook collector.yaml -l 6wind1
!
! SOME OUTPUT IS TRUNCATED FOR BREVITY
!
TASK [poll_yang_modules : 40.10. POLL YANG MODULE FROM DEVICES] ***************************************
Saturday 06 November 2021  22:46:45 +0000 (0:00:00.566)       0:06:50.318 *****
ok: [6wind1]

TASK [poll_yang_modules : 40.20. SAVE YANG MODULE] *****************************************************
Saturday 06 November 2021  22:46:47 +0000 (0:00:01.294)       0:06:51.613 *****
ok: [6wind1 -> localhost]

PLAY RECAP *********************************************************************************************
6wind1           : ok=676  changed=114  unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Once the playbook is completed, you can see the list of all the YANG modules downloaded from 6WIND Turbo Router as well as list of them:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
$ ls .yang/6wind1/
000_supported_yang_modules.txt   ietf-yang-types.yang               vrouter-firewall-modules.yang    vrouter-ospf.yang
ext-netconf-server.yang          nc-notifications.yang              vrouter-firewall-types.yang      vrouter-ospf6.yang
extra-conditions.yang            network.yang                       vrouter-firewall.yang            vrouter-pbr.yang
fp.yang                          notifications.yang                 vrouter-firewall6.yang           vrouter-pm.yang
iana-crypt-hash.yang             product.yang                       vrouter-gre.yang                 vrouter-product.yang
iana-timezones.yang              sixwind-router.yang                vrouter-group.yang               vrouter-qos.yang
ietf-crypto-types.yang           sysrepo-monitoring.yang            vrouter-ha-conntrack.yang        vrouter-rip.yang
ietf-datastores.yang             sysrepo-plugind.yang               vrouter-ha-neigh.yang            vrouter-routing-types.yang
ietf-inet-types.yang             sysrepo.yang                       vrouter-ha.yang                  vrouter-routing.yang
ietf-keystore.yang               system.yang                        vrouter-hardware-flow-rule.yang  vrouter-sflow.yang
ietf-netconf-acm.yang            vrouter-aaa.yang                   vrouter-if-types.yang            vrouter-snmp.yang
ietf-netconf-monitoring.yang     vrouter-api.yang                   vrouter-ike.yang                 vrouter-ssh-server.yang
ietf-netconf-nmda.yang           vrouter-auth.yang                  vrouter-inet-types.yang          vrouter-svti.yang
ietf-netconf-notifications.yang  vrouter-bfd.yang                   vrouter-interface.yang           vrouter-system-loopback.yang
ietf-netconf-server.yang         vrouter-bgp-rpki.yang              vrouter-ip.yang                  vrouter-system.yang
ietf-netconf-with-defaults.yang  vrouter-bgp.yang                   vrouter-ipip.yang                vrouter-telegraf.yang
ietf-netconf.yang                vrouter-bridge.yang                vrouter-kpi.yang                 vrouter-tracker.yang
ietf-origin.yang                 vrouter-certificate.yang           vrouter-lag.yang                 vrouter-tunnel.yang
ietf-ssh-common.yang             vrouter-cgnat.yang                 vrouter-ldp.yang                 vrouter-types.yang
ietf-ssh-server.yang             vrouter-cloud-init.yang            vrouter-license.yang             vrouter-veth.yang
ietf-tcp-client.yang             vrouter-commands.yang              vrouter-linux.yang               vrouter-vlan.yang
ietf-tcp-common.yang             vrouter-dhcp.yang                  vrouter-lldp.yang                vrouter-vrrp.yang
ietf-tcp-server.yang             vrouter-dns.yang                   vrouter-logging.yang             vrouter-vxlan.yang
ietf-tls-common.yang             vrouter-embedded.yang              vrouter-loopback.yang            vrouter-xvrf.yang
ietf-tls-server.yang             vrouter-evpn.yang                  vrouter-nat.yang                 vrouter.yang
ietf-truststore.yang             vrouter-extensions.yang            vrouter-netconf-server.yang      yang.yang
ietf-x509-cert-to-name.yang      vrouter-fast-path-cgnat.yang       vrouter-network-ports.yang
ietf-yang-library.yang           vrouter-fast-path-statistics.yang  vrouter-nhrp.yang
ietf-yang-metadata.yang          vrouter-fast-path.yang             vrouter-ntp.yang

The last thing You’d need to do in this scenario is to structure the content of the YANG modules and find some dependencies.

Pyang to Investigate YANG Modules Content

It is assumed that you have the latest version of Pyang installed or know how to do that. Join our Network Automation Training to learn how to do that.

Much like OpenConfig YANG modules, 6WIND decided to structure all their YANG modules in independent modules, rather than having one high level super-module, like Nokia did with SR OS modules. This is both good and bad simultaneously:

Step #3.1. Top-level YANG Module for 6WIND

The top module, where both configuration and operational data is stored is vrouter.yang. Let’s look into that with pyang:


1
2
3
4
5
6
7
8
$ pyang -f tree -p ${PWD}/.yang/6wind1/ .yang/6wind1/vrouter.yang
module: vrouter
  +--rw config
  |  +--rw vrf* [name]
  |     +--rw name    vrf-name
  +--ro state
     +--ro vrf* [name]
        +--ro name    union

An immediate observation you can make is that the same YANG module is used both for operational data and configuration, which is very handy.

Step #3.2. YANG Augmentation in 6WIND

Once you figured out in which YANG module to start, the next step is to add some more modules to see joint tree. The good suggestion would be to add module vrouter-interface.yang, containing information about interfaces, in the output of YANG modules:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
# pyang -f tree -p ${PWD}/.yang/6wind1/ .yang/6wind1/vrouter.yang .yang/6wind1/vrouter-interface.yang
module: vrouter
  +--rw config
  |  +--rw vrf* [name]
  |  |  +--rw name                            vrf-name
  |  |  +--rw vrouter-system:network-stack
  |  |  |  +--rw vrouter-system:bridge {per-vrf-bridge-call-filter}?
  |  |  |  |  +--rw vrouter-system:call-ipv4-filtering?   boolean
  |  |  |  |  +--rw vrouter-system:call-ipv6-filtering?   boolean
  |  |  |  +--rw vrouter-system:icmp
  |  |  |  |  +--rw vrouter-system:ignore-icmp-echo-broadcast?   boolean
  |  |  |  |  +--rw vrouter-system:rate-limit-icmp?              uint16
  |  |  |  |  +--rw vrouter-system:rate-mask-icmp?               bits
  |  |  |  +--rw vrouter-system:ipv4
  |  |  |  |  +--rw vrouter-system:forwarding?              boolean
  |  |  |  |  +--rw vrouter-system:send-redirects?          boolean
  |  |  |  |  +--rw vrouter-system:accept-redirects?        boolean
  |  |  |  |  +--rw vrouter-system:accept-source-route?     boolean
  |  |  |  |  +--rw vrouter-system:arp-announce?            enumeration
  |  |  |  |  +--rw vrouter-system:arp-filter?              boolean
  |  |  |  |  +--rw vrouter-system:arp-ignore?              enumeration
  |  |  |  |  +--rw vrouter-system:log-invalid-addresses?   boolean
  |  |  |  +--rw vrouter-system:ipv6
  |  |  |  |  +--rw vrouter-system:forwarding?                boolean
  |  |  |  |  +--rw vrouter-system:autoconfiguration?         boolean
  |  |  |  |  +--rw vrouter-system:accept-router-advert?      enumeration
  |  |  |  |  +--rw vrouter-system:accept-redirects?          boolean
  |  |  |  |  +--rw vrouter-system:accept-source-route?       boolean
  |  |  |  |  +--rw vrouter-system:router-solicitations?      int16
  |  |  |  |  +--rw vrouter-system:use-temporary-addresses?   enumeration
  |  |  |  +--rw vrouter-system:neighbor
  |  |  |  |  +--rw vrouter-system:ipv4-max-entries?   uint32
  |  |  |  |  +--rw vrouter-system:ipv6-max-entries?   uint32
  |  |  |  +--rw vrouter-system:conntrack
  |  |  |     +--rw vrouter-system:max-entries?                  uint32
  |  |  |     +--rw vrouter-system:tcp-timeout-close?            uint32
  |  |  |     +--rw vrouter-system:tcp-timeout-close-wait?       uint32
  |  |  |     +--rw vrouter-system:tcp-timeout-established?      uint32
  |  |  |     +--rw vrouter-system:tcp-timeout-fin-wait?         uint32
  |  |  |     +--rw vrouter-system:tcp-timeout-last-ack?         uint32
  |  |  |     +--rw vrouter-system:tcp-timeout-max-retrans?      uint32
  |  |  |     +--rw vrouter-system:tcp-timeout-syn-recv?         uint32
  |  |  |     +--rw vrouter-system:tcp-timeout-syn-sent?         uint32
  |  |  |     +--rw vrouter-system:tcp-timeout-time-wait?        uint32
  |  |  |     +--rw vrouter-system:tcp-timeout-unacknowledged?   uint32
  |  |  |     +--rw vrouter-system:udp-timeout?                  uint32
  |  |  |     +--rw vrouter-system:udp-timeout-stream?           uint32
  |  |  +--rw vrouter-interface:interface
  |  |     +--rw vrouter-interface:physical* [name]
  |  |        +--rw vrouter-interface:port                union
  |  |        +--rw vrouter-interface:name                vrouter-types:ifname
  |  |        +--rw vrouter-interface:mtu?                uint32
  |  |        +--rw vrouter-interface:promiscuous?        boolean
  |  |        +--rw vrouter-interface:description?        string
  |  |        +--rw vrouter-interface:enabled?            boolean
  |  |        +--rw vrouter-interface:rx-cp-protection?   boolean
  |  |        +--rw vrouter-interface:tx-cp-protection?   boolean
  |  |        +--rw vrouter-interface:ipv4
  |  |        |  +--rw vrouter-interface:address* [ip]
  |  |        |  |  +--rw vrouter-interface:ip      union
  |  |        |  |  +--rw vrouter-interface:peer?   vr-inet:ipv4-address
  |  |        |  +--rw vrouter-interface:enabled?    boolean
  |  |        |  +--rw vrouter-interface:neighbor* [ip]
  |  |        |  |  +--rw vrouter-interface:ip                    vr-inet:ipv4-address
  |  |        |  |  +--rw vrouter-interface:link-layer-address    vr-if:mac-address
  |  |        |  +--rw vrouter-interface:dhcp!
  |  |        |     +--rw vrouter-interface:enabled?                        boolean
  |  |        |     +--rw vrouter-interface:timeout?                        uint32
!
! FURTHER OUTPUT IS TRUNCATED FOR BREVITY

As You see, not only vrouter-interface.yang module was used, but also some others (e.g. vrouter-system.yang) were augmented as well.

With this approach, You can add more and more modules to the input of pyang tool, what would allow you to visualise the all possible elements in the YANG modules tree.

Examples in GitHub

You can find this and other examples in our GitHub repository.

Lessons Learned

In fact, this YANG modules extractor is suitable not only for 6WIND router, but for any device supporting NETCONF. Therefore, you can use for Cisco IOS XE, IOS XR, Nokia SR OS, Arista EOS, Juniper JUNOS and any other network device system. As such

And you can create your rock solid foundation in Ansible at our Network Automation Training.

Conclusion

YANG is the main driving power behind the model-driven automation. Before you can create any configuration on the network device, you need to know how do they look like and what is their content. With the described approach, you can collect the YANG modules from 6WIND or any other network device running NETCONF and explore, what you can configure and collect. In further articles we’ll see how to collect the data from 6WIND and how to configure them. Take care and good bye.

Support us





P.S.

If you have further questions or you need help with your networks, we are happy to assist you, just send us a message. Also don’t forget to share the article on your social media, if you like it.

BR,

Anton Karneliuk

Exit mobile version