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:
- Data encoding (free-text, XML, JSON, YAML, Protobuf)
- Model-driven network automation with YANG, NETCONF, RESTCONF, GNMI.
- Full configuration templating with Jinja2 based on the source of truth (NetBox).
- Best automation programming languages (Python, Bash), configuration management tools (Ansible) and automation frameworks (Nornir).
- Network automation infrastructure (Linux, Linux networking, KVM, Docker).
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!
Brief Description
The YANG modules play a crucial role in the model-driven automation. In a nutshell, they answer the following questions:
- What are the all possible keys existing in the configurational or operational context?
- What are the mandatory keys shall be communicated in various messages (via NETCONF, RESTCONF or gNMI) all the time?
- What are the associated data types with various keys?
- What are further validations (e.g., particular patterns for strings, or ranges of allowed values for integers) associated with data types?
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:
- Python 3 (we used Python 3.9)
- Ansible 4.* (Ansible Core 2.11)
- Latest version of Pyang
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:
- Cisco IOS XE YANG modules
- Cisco IOS XR YANG modules
- Cisco NX OS YANG modules
- Juniper JUNOS YANG modules
- Arista EOS YANG modules
- Nokia SR OS YANG modules
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&amp;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 - &lt;support@6wind.com&gt;";
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:
- collector.yaml is a main playbook, which executes the role
- The role yang_collection has a single directory with tasks
- Within the role’s tasks, the main.yaml playbook collects all the schemas and triggers in a loop the playbook poll_yang_module.yaml to extract all the YANG modules
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:
- First of all, You will create a local directory per the network device to store YANG modules using module file from ansible.builtin collection.
- Afterwards, You will obtain the list of YANG modules using module netconf_get from ansible.netcommon collection, and save it locally for further reference using module copy from ansible.builtin collection.
- Finally, You launch looped the nested playbook to collect information for each module using module include_tasks from ansible.builtin collection.
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:
- Using module netconf_rpc from ansible.netcommon collection poll the content of each YANG module based on its identifier.
- Using module copy from ansible.builtin collection save the collected YANG module locally.
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:
- It is good, because there will be definitely much less circular dependency errors.
- It is bad, because You don’t necessary know, where to start. But we’ll help You.
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