Hello, my friend,
In this article, we’ll continue the evaluation of the telemetry, which we can extract from the network functions using NETCONF. The focus will be on Nokia SR OS devices.
1 | No part of this blogpost could be reproduced, stored in a<br> retrieval system, or transmitted in any form or by any<br> means, electronic, mechanical or photocopying, recording,<br> or otherwise, for commercial purposes without the<br> prior permission of the author.<br> |
Disclaimer
This article isn’t standalone. It’s the continuation of the previous discussion, where we have reviewed telemetry from Cisco IOS XR. Please, refer to that article to get details about topology, lab setup and initial pre-checks.
Another point, just to recap, we are focusing currently on native vendor YANG modules. OpenConfig operational YANG modules will be discussed in a separated article.
Nokia SR OS // Operational YANG modules
In Nokia SR OS world, the modules, which contains operational data has keyword “state” in their name:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | $ ls -l Yang/nokia/SR16_YANG/ | grep 'state'<br> -rwxrw-rw-. 1 aaa aaa 40648 Jun 4 17:17 nokia-state-aaa.yang<br> -rwxrw-rw-. 1 aaa aaa 120487 Jun 4 17:17 nokia-state-bfd.yang<br> -rwxrw-rw-. 1 aaa aaa 9781 Jun 4 17:17 nokia-state-card-fp.yang<br> -rwxrw-rw-. 1 aaa aaa 51391 Jun 4 17:17 nokia-state-card.yang<br> -rwxrw-rw-. 1 aaa aaa 7328 Jun 4 17:17 nokia-state-cflowd.yang<br> -rwxrw-rw-. 1 aaa aaa 69518 Jun 4 17:17 nokia-state-chassis.yang<br> -rwxrw-rw-. 1 aaa aaa 94247 Jun 4 17:17 nokia-state-filter.yang<br> -rwxrw-rw-. 1 aaa aaa 28780 Jun 4 17:17 nokia-state-isa-video-group.yang<br> -rwxrw-rw-. 1 aaa aaa 9410 Jun 4 17:17 nokia-state-isa.yang<br> -rwxrw-rw-. 1 aaa aaa 17963 Jun 4 17:17 nokia-state-lag.yang<br> -rwxrw-rw-. 1 aaa aaa 226392 Jun 4 17:17 nokia-state-log.yang<br> -rwxrw-rw-. 1 aaa aaa 18717 Jun 4 17:17 nokia-state-mcast-cac.yang<br> -rwxrw-rw-. 1 aaa aaa 3653 Jun 4 17:17 nokia-state-mcast-mgmt.yang<br> !<br> ! FURTHER OUTPUT IS OMITTED<br> |
But comparing to Cisco IOS XR, there is a major difference in telemetry behaviour. The difference is that all the modules are collected by the end of the day in a single parent’s module called “nokia-state.yang”. Later on, you will see, how to we’ll call this module in the playbook.
As we are going to use the mentioned module, let’s discovery its structure with the help of “pyang”:
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 | $ pyang -f tree -p Yang/nokia/SR16_YANG/ Yang/nokia/SR16_YANG/nokia-state.yang | more<br> Yang/nokia/SR16_YANG/nokia-state-router-igmp.yang:12: error: circular dependency for module "nokia-state-router"<br> Yang/nokia/SR16_YANG/nokia-state-router-ldp.yang:14: error: circular dependency for module "nokia-state-router"<br> Yang/nokia/SR16_YANG/nokia-state-router-mpls.yang:12: error: circular dependency for module "nokia-state-router"<br> Yang/nokia/SR16_YANG/nokia-state-router-ospf3.yang:14: error: circular dependency for module "nokia-state-router"<br> Yang/nokia/SR16_YANG/nokia-state-router-rsvp.yang:11: error: circular dependency for module "nokia-state-router"<br> Yang/nokia/SR16_YANG/nokia-state-submgt-pcc-rule.yang:12: error: circular dependency for module "nokia-state-service"<br> Yang/nokia/SR16_YANG/nokia-state-subscriber-mgmt.yang:9: warning: imported module nokia-types-filter not used<br> Yang/nokia/SR16_YANG/nokia-state-svc-vprn.yang:23: error: circular dependency for module "nokia-state-service"<br> Yang/nokia/SR16_YANG/nokia-state-svc-vprn.yang:24: error: circular dependency for module "nokia-state-subscriber-mgmt"<br> Yang/nokia/SR16_YANG/nokia-state-system-security-tls.yang:10: error: circular dependency for module "nokia-state-system"<br> Yang/nokia/SR16_YANG/nokia-state-system-security-tls.yang:11: error: circular dependency for module "nokia-state-system-security"<br> module: nokia-state<br> +--ro state<br> +--ro aaa<br> | +--ro wpp<br> | | +--ro portal-group* [group-name]<br> | | +--ro group-name types-sros:named-item<br> | | +--ro controlled-router? types-sros:router-instance<br> | | +--ro enabled-interfaces? uint32<br> | | +--ro triggered-hosts? boolean<br> | | +--ro host* [address]<br> | | +--ro address types-sros:ipv4-unicast-address<br> | | +--ro state? enumeration<br> | | +--ro serial-number? uint32<br> | | +--ro request-id? uint32<br> | | +--ro remote-port? inet:port-number<br> | | +--ro local-address? types-sros:ipv4-unicast-address<br> | | +--ro user-name? types-sros:display-string<br> | | +--ro service? types-services:service-name<br> | | +--ro mac-address? yang:mac-address<br> | | +--ro is-triggered? boolean<br> | | +--ro track-srrp-instance? uint32<br> | | +--ro is-mcs-backup? boolean<br> | | +--ro active-portal<br> | | +--ro router-instance? types-sros:router-instance<br> | | +--ro name? types-sros:named-item<br> | +--ro radius-script-policy* [name]<br> | | +--ro name types-sros:named-item<br> | | +--ro primary-oper-state? types-sros:oper-state<br> | | +--ro secondary-oper-state? types-sros:oper-state<br> | +--ro radius-server-policy* [name]<br> | | +--ro name types-sros:named-item<br> | | +--ro blocked-state? enumeration<br> | | +--ro servers<br> | | | +--ro server* [server-index]<br> | | | +--ro server-index uint32<br> | | | +--ro oper-state? enumeration<br> | | | +--ro out-of-service-time? types-sros:time-duration<br> | | | +--ro overload-time? types-sros:time-duration<br> | | +--ro acct-on-off<br> | | +--ro oper-state? enumeration<br> | | +--ro session-id? types-sros:display-string-or-empty<br> | | +--ro trigger? enumeration<br> | | +--ro server-name? types-sros:named-item-or-empty<br> | | +--ro retry-count? uint32<br> | +--ro route-downloader* [name]<br> !<br> ! FURTHER OUTPUT IS OMITTED<br> |
The output of the modules is extremely long. It has 19996 lines.
In the same way, as we already discussed for Cisco IOS XR operational YANG modules, all the nodes have “ro” type, what stands for read-only.
Nokia SR OS // Model-driven telemetry algorithm
As we’ve just mentioned, all the possible telemetry information could be collected from the network function running on Nokia SR OS using single YANG module, so that we can simplify the algorithm for Cisco IOS XR:
- Construct XML message with proper YANG modules, which is “nokia-state.yang” to get data.
- Fetch telemetry data using NETCONF/YANG
- Parse data to extract some information
As you can see, we continue to use the same Ansible module “netconf_get”, which allows us to collect through NETCONF requested information. In the upcoming modules we’ll show how to use push-model with Kafka so that network functions sending the data themselves without NETCONF requests, but rather using gRPC/gNMI transport.
Nokia SR OS // Ansible playbook for telemetry collection
To implement the algorithm above, our playbook using roles has the following structure:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | +--ansible<br> +--136_lab.yml<br> +--group_vars<br> | +--cisco<br> | | +--cisco_host.yml<br> | +--nokia<br> | +--nokia_host.yml<br> +--roles<br> +--nokia<br> +--136_lab<br> +--tasks<br> | +--comapring_loop.yml<br> | +--main.yml<br> +--templates<br> | +--nokia_telemetry_interfaces.j2<br> | +--nokia_telemetry_routing_bgp.j2<br> | +--nokia_telemetry_routing_ospf.j2<br> +--vars<br> +--XR3_infra_profile.yml<br> |
Let’s refresh the content of the master Ansible playbook:
1 2 3 4 5 6 | $ cat 136_lab.yml<br> ---<br> - hosts: cisco<br> connection: netconf<br> roles:<br> - { role: cisco/136_lab } |
1 | <br> |
1 2 3 4 5 | - hosts: nokia<br> connection: netconf<br> roles:<br> - { role: nokia/136_lab }<br> ...<br> |
Same structure we have used more or less with all of our Ansible playbook with roles.
The “group_vars” for Nokia SR OS contains exactly the same set of parameters, as we have previously used in Cisco IOS XR:
1 2 3 4 5 6 7 | $ cat group_vars/nokia/nokia_host.yml<br> ---<br> ansible_network_os: sros<br> ansible_user: admin<br> ansible_pass: admin<br> ansible_ssh_pass: admin<br> ...<br> |
Now to infrastructure profile. Actually, we don’t need it to create the proper requests opposed to what we had in Cisco IOS XR, but we’ll need them later on, when we’d extract some data from telemetry output:
1 2 3 4 5 6 7 8 9 10 11 12 | $ cat roles/nokia/136_lab/vars/SR1_infra_profile.yml<br> ---<br> node:<br> hostname: SR1<br> vendor: nokia<br> os: sros<br> version: 16.0.R3<br> configuration_profiles:<br> - profile: interfaces<br> - profile: routing_ospf<br> - profile: routing_bgp<br> ...<br> |
Structure of “main.yml” playbook is tailored to the algorithm mentioned above, hence it’s deviating from the Cisco IOS XR one:
1 2 3 4 5 6 | $ cat roles/nokia/136_lab/tasks/main.yml<br> ---<br> - name: VERIFICATION // {{ inventory_hostname }} // IMPORTING INFRASTRUCTURE PROFILE<br> include_vars:<br> file: "{{ inventory_hostname }}_infra_profile.yml"<br> name: PROFILE |
1 | <code lang="yaml"> |
– name: VERIFICATION // {{ inventory_hostname }} // DELETE PREVIOUS TEST REPORT
file:
dest: /tmp/{{ inventory_hostname }}_test_report.txt
state: absent
ignore_errors: yes
1 | <code lang="yaml"> |
– name: VERIFICATION // {{ inventory_hostname }} // CREATING TEST REPORT
file:
dest: /tmp/{{ inventory_hostname }}_test_report.txt
state: touch
1 | <code lang="yaml"> |
– name: VERIFICATION // {{ inventory_hostname }} // FETCHING TELEMETRY DATA
netconf_get:
filter:
display: json
register: output_json
1 | <code lang="yaml"> |
– name: VERIFICATION // {{ inventory_hostname }} // SAVING TELEMETRY DATA
copy:
content: “{{ output_json.output | to_nice_json }}”
dest: /tmp/{{ inventory_hostname }}/{{ inventory_hostname }}_yang_telemetry.json
1 | <code lang="yaml"> |
– name: VERIFICATION // {{ inventory_hostname }} // MODIFIICATION OF COLLECTED TELEMETRY FOR PYTHON PROCESSING
replace:
path: /tmp/{{ inventory_hostname }}/{{ inventory_hostname }}_yang_telemetry.json
regexp: ‘-‘
replace: ‘_’
1 | <code lang="yaml"> |
– name: VERIFICATION // {{ inventory_hostname }} // IMPORTING COLLECTED TELEMETRY DATA
include_vars:
file: /tmp/{{ inventory_hostname }}/{{ inventory_hostname }}_yang_telemetry.json
name: COLLECTED
1 | <code lang="yaml"> |
– name: VERIFICATION // {{ inventory_hostname }} // COLLECTING TELEMETRY AND SEARCHING DATA
include_tasks: comparing_loop.yml
loop: “{{ PROFILE.node.configuration_profiles }}”
1 | <code lang="yaml"> |
– name: VERIFICATION // {{ inventory_hostname }} // COMPILING REPORT
shell: “cat /tmp/temp_report_136_{{ inventory_hostname }}_* > /tmp/{{ inventory_hostname }}_test_report.txt”
1 | <br> |
1 2 3 4 | - name: VERIFICATION // {{ inventory_hostname }} // REPORTING READINESS<br> debug:<br> msg: "Collection of telemetry data from {{ inventory_hostname }} is done."<br> ...<br> |
More details you can find in the previous article about telemetry with NETCONF/YANG in Cisco IOS XR.
The following list briefly recap what’s done in the playbook.:
- We import the file with variables, which contains configuration profiles to check
- We delete previous report (if it exists) and create empty file for the new one
- Using single NETCONF GET request we collect all telemetry data and save it
- We extract all the interesting data from telemetry and fill in predefined reports using additional playbook called “comparing_loop.yml”.
- We combine all the pieces into in a single report file
- We inform that job is done
Comparing loop plays important role here, that’s why we need to review its details:
1 2 3 4 5 6 7 8 | $ cat roles/nokia/136_lab/tasks/comparing_loop.yml<br> ---<br> - name: VERIFICATION // {{ inventory_hostname }} // COMPARING COLLECTED TELEMETRY TO REFERENCE // {{ item.profile }}<br> template:<br> src: nokia_telemetry_{{ item.profile }}.j2<br> dest: /tmp/temp_report_136_{{ inventory_hostname }}_{{ item.profile }}.txt<br> mode: 0755<br> ...<br> |
Well, this playbook is relatively easy, as we just call the appropriate template for each “configuration profile”.
The last important point, we need to take a look on before going to an execution of the playbooks, is to review the templates to extract information from telemetry. We start with the port level data:
1 2 3 4 | $ cat roles/nokia/136_lab/templates/nokia_telemetry_interfaces.j2<br> +------------------------------------------+<br> | Checking of the interfaces status |<br> +------------------------------------------+ |
{% for port_current in COLLECTED.data.state.port %}
Port: {{ port_current.port_id }}
Status: {{ port_current.oper_state }}
{% endfor %}
1 2 3 | ===========================================<br> Verification of interfaces is done<br> ===========================================<br> |
For OSPF routing protocol the following template is used:
1 2 3 4 | $ cat roles/nokia/136_lab/templates/nokia_telemetry_routing_ospf.j2<br> +------------------------------------------+<br> | Checking of the OSPF status |<br> +------------------------------------------+ |
{% for router_current in COLLECTED.data.state.router %}
{% if router_current.ospf is defined %}
Process OSPF {{ router_current.ospf.ospf_instance }} is configured within routing context {{ router_current.router_name }}
{% for ospf_iface in router_current.ospf.area.interface %}
{% if ospf_iface.neighbor_count != ‘0’ %}
Neighbor:
RID: {{ ospf_iface.neighbor_state.router_id }}
IP: {{ ospf_iface.neighbor_state.address }}
Connected to: {{ ospf_iface.interface_name }}
Status: {{ ospf_iface.neighbor_state.oper_state }}
{% else %}
There is no OSPF neighbors detected on interface {{ ospf_iface.interface_name }}
{% endif %}
{% endfor%}
{% else %}
There is no OSPF process configured within routing context {{ router_current.router_name }}
{% endif %}
{% endfor %}
1 2 3 | ===========================================<br> Verification of OSPF neighbors is done<br> ===========================================<br> |
We need to point out that it’s a bit more complicated than the template for Cisco IOS XR, as by default network functions running Nokia SR OS (SR 7750) has 2 routing context since 16.0.R1, one of which is “management”. It’s built in, but it isn’t something you configure.
The same logic, with looping over routing contexts is also applicable for BGP:
1 2 3 4 | $ cat roles/nokia/136_lab/templates/nokia_telemetry_routing_bgp.j2<br> +------------------------------------------+<br> | Checking of the BGP status |<br> +------------------------------------------+ |
{% for router_current in COLLECTED.data.state.router %}
{% if router_current.bgp is defined %}
Process BGP is configured within routing context {{ router_current.router_name }}
{% if router_current.bgp.neighbor is defined %}
Neighbor:
ID: {{ router_current.bgp.neighbor.ip_address }}
State: {{ router_current.bgp.neighbor.statistics.session_state }}
AFI/SAFI: {% for afi in router_current.bgp.neighbor.statistics.negotiated_family %}{{ afi }} {% endfor %}
{% else %}
There is no BGP neighbors detected
{% endif %}
{% else %}
There is no BGP process configured within routing context {{ router_current.router_name }}
{% endif %}
{% endfor %}
1 2 3 | ===========================================<br> Verification of BGP neighbors is done<br> ===========================================<br> |
If you have checked the article about model-driven telemetry with Cisco IOS XR, you might have spotted that we are checking exactly the same information, which is absolutely important if we speak about any kind of automation and network baselining.
Nokia SR OS // Collecting telemetry via NETCONF/YANG with Ansible
We have reached the most exciting and the most interesting part of the article: execution of our Ansible automation and verification of the results:
1 | $ ansible-playbook 136_lab.yml --limit=SR1 |
PLAY [cisco] ***********************************************************************************************************************************************************
skipping: no hosts matched
PLAY [nokia] ***********************************************************************************************************************************************************
TASK [Gathering Facts] *************************************************************************************************************************************************
ok: [SR1]
TASK [nokia/136_lab : VERIFICATION // SR1 // IMPORTING INFRASTRUCTURE PROFILE] *****************************************************************************************
ok: [SR1]
TASK [nokia/136_lab : VERIFICATION // SR1 // DELETE PREVIOUS TEST REPORT] **********************************************************************************************
changed: [SR1]
TASK [nokia/136_lab : VERIFICATION // SR1 // CREATING TEST REPORT] *****************************************************************************************************
changed: [SR1]
TASK [nokia/136_lab : VERIFICATION // SR1 // FETCHING TELEMETRY DATA] **************************************************************************************************
ok: [SR1]
TASK [nokia/136_lab : VERIFICATION // SR1 // SAVING TELEMETRY DATA] ****************************************************************************************************
changed: [SR1]
TASK [nokia/136_lab : VERIFICATION // SR1 // MODIFIICATION OF COLLECTED TELEMETRY FOR PYTHON PROCESSING] ***************************************************************
changed: [SR1]
TASK [nokia/136_lab : VERIFICATION // SR1 // IMPORTING COLLECTED TELEMETRY DATA] ***************************************************************************************
ok: [SR1]
TASK [nokia/136_lab : VERIFICATION // SR1 // COLLECTING TELEMETRY AND SEARCHING DATA] **********************************************************************************
included: /home/aaa/ansible/roles/nokia/136_lab/tasks/comparing_loop.yml for SR1 => (item={u’profile’: u’interfaces’})
included: /home/aaa/ansible/roles/nokia/136_lab/tasks/comparing_loop.yml for SR1 => (item={u’profile’: u’routing_ospf’})
included: /home/aaa/ansible/roles/nokia/136_lab/tasks/comparing_loop.yml for SR1 => (item={u’profile’: u’routing_bgp’})
TASK [nokia/136_lab : VERIFICATION // SR1 // COMPARING COLLECTED TELEMETRY TO REFERENCE // interfaces] *****************************************************************
ok: [SR1]
TASK [nokia/136_lab : VERIFICATION // SR1 // COMPARING COLLECTED TELEMETRY TO REFERENCE // routing_ospf] ***************************************************************
changed: [SR1]
TASK [nokia/136_lab : VERIFICATION // SR1 // COMPARING COLLECTED TELEMETRY TO REFERENCE // routing_bgp] ****************************************************************
changed: [SR1]
TASK [nokia/136_lab : VERIFICATION // SR1 // COMPILING REPORT] *********************************************************************************************************
changed: [SR1]
TASK [nokia/136_lab : VERIFICATION // SR1 // REPORTING READINESS] ******************************************************************************************************
ok: [SR1] => {
“msg”: “Collection of telemetry data from SR1 is done.”
}
1 2 | PLAY RECAP *************************************************************************************************************************************************************<br> SR1 : ok=16 changed=7 unreachable=0 failed=0<br> |
The whole playbook is successfully executed, what is definitely good sign. Now we can review some details. First of all, let’s check how the raw telemetry data looks like:
1 2 | $ ls -l /tmp/SR1/ | grep 'yang'<br> -rw-rw-r--. 1 aaa aaa 1396972 Oct 14 19:18 SR1_yang_telemetry.json<br> |
Wow. The raw text data with telemetry in YANG format from Nokia SR OS device (7750 SR-1 or VSR in this case) is almost 1,4. Megabytes. That’s huge amount of information.
Let’s take a look into details, what we have there:
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 71 72 73 | $ cat SR1_yang_telemetry.json<br> {<br> "data": {<br> "state": {<br> "aaa": {<br> "wpp": ""<br> },<br> "bfd": "",<br> "card": {<br> "available_mda_slots": "2",<br> "clock_source": "none",<br> "equipped_level": "he",<br> "equipped_type": "iom_1",<br> "fp": {<br> "fp_number": "1",<br> "generation": "fp4",<br> "ingress": "",<br> "statistics": {<br> "buffer_memory_error": "0",<br> "cam_error": "0",<br> "egress_fcs_error": "0",<br> "ingress_fcs_error": "0",<br> "internal_datapath_cell_error": "0",<br> "internal_datapath_error": "0",<br> "internal_memory_error": "0",<br> "memory_parity_error": "0",<br> "source_slots_egress_fcs_error": "",<br> "statistics_memory_error": "0"<br> },<br> "total_policy_accounting_in_use": "0"<br> },<br> "hardware_data": {<br> "alarm_state": "alarm_cleared",<br> "base_mac_address": "02:65:01:00:00:00",<br> "boot_code_version": "simulated",<br> "common_language_equipment_identifier": "Sim CLEI",<br> "contained_in": "Chassis 1",<br> "contains_temperature_sensor": "true",<br> "equipped_platform_type": "platform_7750",<br> "failure_reason": "",<br> "field_replaceable_unit": "true",<br> "firmware_code_version": "",<br> "firmware_revision_status": "acceptable",<br> "manufacturing_assembly_number": "01_2345_67",<br> "manufacturing_date": "01012003",<br> "manufacturing_deviations": "Sim MfgDeviation card_1",<br> "oper_state": "in_service",<br> "part_number": "f362a30add1e466d80a3607438c87d22",<br> "power_zone_location": "1",<br> "serial_number": "card_1",<br> "software_code_version": "TiMOS_B_16.0.R3 both/x86_64 Nokia 7750 SR Copyright (c) 2000_2018 Nokia.\nAll rights reserved. All use subject to applicab<br> le license agreements.\nBuilt on Wed Aug 29 12:48:09 PDT 2018 by builder in /builds/160B/R3/panos/main",<br> "software_image_source": "unknown",<br> "software_last_boot_time": "2018_10_14T14:19:26.0Z",<br> "temperature": "_128",<br> "temperature_threshold": "75"<br> },<br> "installed_mda_slots": "1",<br> "last_bootup_reason": "hard_reboot",<br> "licensed_bandwidth": "80",<br> "licensed_level": "he",<br> "mda": [<br> {<br> "access": {<br> "ingress": ""<br> },<br> "capabilities": "ethernet",<br> "channels_in_use": "0",<br> "equipped_ports": "6",<br> "equipped_type": "me6_100gb_qsfp28",<br> "hardware_data": {<br> !<br> ! FURTHER OUTPUT IS OMITTED<br> |
You remember, previously we told that the that YANG module we called here has almost 20 thousand lines of entries… And that’s just the YANG module, without multiple interfaces and so on. So you can imagine, how much information we have here. You can spend a lot of information reviewing what we have. But for now, we’ll check the status of our report, which includes:
- Status of the interfaces
- Status of the OSPF neighbors
- Status of the BGP peering
As we have merged everything together, let’s verify the final one:
1 2 3 4 | $ cat /tmp/SR1_test_report.txt<br> +------------------------------------------+<br> | Checking of the interfaces status |<br> +------------------------------------------+ |
Port: 1/1/c1
Status: up
Port: 1/1/c1/1
Status: up
Port: 1/1/c1/2
Status: down
Port: 1/1/c1/3
Status: down
Port: 1/1/c1/4
Status: down
Port: 1/1/c2
Status: up
Port: 1/1/c2/1
Status: down
Port: 1/1/c2/2
Status: down
Port: 1/1/c2/3
Status: down
Port: 1/1/c2/4
Status: down
Port: 1/1/c3
Status: down
Port: 1/1/c4
Status: down
Port: 1/1/c5
Status: down
Port: 1/1/c6
Status: down
Port: A/1
Status: up
Port: A/4
Status: down
===========================================
Verification of interfaces is done
===========================================
+——————————————+
| Checking of the BGP status |
+——————————————+
Process BGP is configured within routing context Base
Neighbor:
ID: 10.0.0.33
State: Established
AFI/SAFI: VPN_IPv4 VPN_IPv6
There is no BGP process configured within routing context management
===========================================
Verification of BGP neighbors is done
===========================================
+——————————————+
| Checking of the OSPF status |
+——————————————+
Process OSPF 0 is configured within routing context Base
There are no OSPF neighbors detected on an interface system
Neighbor:
RID: 10.0.0.33
IP: 10.11.33.33
Connected to: uplink1
Status: full
There is no OSPF process configured within routing context management
1 2 3 | ===========================================<br> Verification of OSPF neighbors is done<br> ===========================================<br> |
You see that some operational data (name of variables, I mean) deviates from Cisco IOS XR to Nokia SR OS. I can easily imagine that another vendor will have many different names. But what is important, we can match them on our own so that we can create a real visualization of our baseline.
Here you can find the playbooks from this lab: 138_lab.tar
Lessons learned
I must admit. I haven’t shown you everything I wanted. In the context of interfaces, I have shown the only status of the port (physical and data link layer), but I haven’t shown you the network layer, meaning IPv4/IPv6 addresses and so on. The reason for that I haven’t managed to create the proper template in Jinja2 or some bugs in Ansible / associated Python modules. The template I tried was quite similar to one I’ve used in OSPF:
1 2 3 | $ cat roles/nokia/136_lab/templates/nokia_telemetry_interfaces.j2<br> {% for router_current in COLLECTED.data.state.router %}<br> {% if router_current.interface is defined %} |
The following interfaces are configured within routing context {{ router_current.router_name }}
{% for iface in router_current.interface %}
Interface: {{ iface.interface_name }}
Status: {{ iface.if_oper_status }}
{% endfor %}
{% else %}
There are no interfaces configured within routing context {{ router_current.router_name }}
1 2 | {% endif %}<br> {% endfor %}<br> |
But during execution of the playbook, I was constantly getting error:
1 2 | TASK [nokia/136_lab : VERIFICATION // SR1 // COMPARING COLLECTED TELEMETRY TO REFERENCE // interfaces] *****************************************************************<br> fatal: [SR1]: FAILED! => {"changed": false, "msg": "AnsibleUndefinedVariable: 'unicode object' has no attribute 'interface_name'"}<br> |
I’ve found on some forums that there might be problems with importing long JSON structure and processing them as variables, but, of course, I might have made some mistakes. If anybody will try this template, let me know your results. As it hasn’t worked, I don’t include it in general package.
Conclusion
In this and in the previous article we have reviewed the telemetry information, which we can collect in vendor native models for Cisco IOS XR and Nokia (Alcatel-Lucent) SR OS respectively. Telemetry provides a lot of information, what we can use for building our business logic in the network. On the other hand, those require manual model creation per vendor. In the next article, we’ll take a look on OpenConfig modules again with the aim to get telemetry in a vendor-neutral manner. Take care and goodbye!
Support us
P.S.
If you have further questions or you need help with your networks, I’m happy to assist you, just send me a message (https://karneliuk.com/contact/). Also don’t forget to share the article on your social media, if you like it.
BR,
Anton Karneliuk
Hi, Its very good article . Can you please provide the link to download Nokia SR OS Yang files. I tried searching on Github and could not find.
Hey Syed,
You should contact Nokia colleagues, the may share the modules with you. For a legal reasons I’m not allowed to do it, sorry about that.
Cheers,
Anton
Hey Syed,
Finally Nokia published them: https://github.com/nokia/7x50_YangModels
Cheers,
Anton