The aim of this article is to provide a good starting place to learn more about navigating through SR OS and it provides the hooks required to help with your automation journey. The article will describe some concrete examples for determining the YANG path required for retrieving configuration and state information.
This article is written in the form of a tutorial. It assumes that you have access to one or more Nokia SR OS 7750/7950 routers (or vSIMs) and that you have a valid license for these products (if you need any of these, please contact your Nokia representative). It also assumes that you have access to a Linux machine from which to work (although it is possible to manage your SR OS devices from other host operating systems).
The following elements were used in this article:
| Item | Version |
|---|---|
| SR-OS | 20.10R1 |
| CentOS | 7.6 |
| gnmiClient (opensource tool) | 0.0.3 |
Let's get to it. There are a few steps we are going to run through in this intro to SR OS YANG navigation, steps for retrieving configuration and state information.
This article assumes your SR OS devices are already configured to operate in model-driven mode and have gNMI enabled. If your network devices are not currently set to model-driven mode and do not currently have gNMI enabled, this can be achieved by entering the following SR OS configuration statements (into the classic CLI).
Note
The example below uses a newly created gnmi user rather than the built-in admin user. You should set the permissions for this user appropriately for your network. In this example the gnmi user is a member of the administrative group so they can access all configurations and actions but you should be selective about access and permissions in a live network. In addition for testing purposes the connection is allowed to not use certificates. In production environments the connection should be secured with certificates.
/configure system security user "gnmi" access grpc
/configure system security user "gnmi" password nokia123
/configure system security user "gnmi" console member "administrative"
/configure system grpc allow-unsecure-connection
/configure system grpc no shutdown
/configure system grpc gnmi no shutdown
/configure system grpc gnmi auto-config-save
/configure system management-interface yang-modules nokia-modules
/configure system management-interface yang-modules no base-r13-modules
/configure system management-interface cli md-cli auto-config-save
/configure system management-interface configuration-mode model-drivenIt is possible to show the configuration in different output formats, using the info command.
Let's first obtain the BGP configuration. The output format json has been chosen as it fits nicely with the activity to collect the configuration via gNMI in a later section. For use-cases where you would like to use NETCONF it is possible to display configuration and state information in xml format.
Commands used info json and info xml.
From the [gl:configure router "Base" bgp] context:
info json{
"router-id": "1.1.1.2",
"nokia-conf:group": [
{
"group-name": "internal",
"family": {
"ipv4": true,
"vpn-ipv4": true
}
}
],
"nokia-conf:neighbor": [
{
"ip-address": "10.10.10.1",
"admin-state": "enable",
"group": "internal",
"type": "internal",
"peer-as": 65005
}
]
}info xml<router-id xmlns="urn:nokia.com:sros:ns:yang:sr:conf">1.1.1.2</router-id>
<bgp xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
<group>
<group-name>internal</group-name>
<family>
<ipv4>true</ipv4>
<vpn-ipv4>true</vpn-ipv4>
</family>
</group>
<neighbor>
<ip-address>10.10.10.1</ip-address>
<admin-state>enable</admin-state>
<group>internal</group>
<type>internal</type>
<peer-as>65005</peer-as>
</neighbor>
</bgp>For creating configuration templates or retrieving the complete configuration structure info provides the possibility to display the data back to the YANG modeled root using info full-context combined with json and xml.
From the [gl:configure router "Base" bgp] context:
info full-context json{
"nokia-conf:configure": {
"router": [
{
"router-name": "Base",
"router-id": "1.1.1.2",
"bgp": {
"group": [
{
"group-name": "internal",
"family": {
"ipv4": true,
"vpn-ipv4": true
}
}
],
"neighbor": [
{
"ip-address": "10.10.10.1",
"admin-state": "enable",
"group": "internal",
"type": "internal",
"peer-as": 65005
}
]
}
}
]
}
}info full-context xml<configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
<router>
<router-name>Base</router-name>
<router-id>1.1.1.2</router-id>
<bgp>
<group>
<group-name>internal</group-name>
<family>
<ipv4>true</ipv4>
<vpn-ipv4>true</vpn-ipv4>
</family>
</group>
<neighbor>
<ip-address>10.10.10.1</ip-address>
<admin-state>enable</admin-state>
<group>internal</group>
<type>internal</type>
<peer-as>65005</peer-as>
</neighbor>
</bgp>
</router>
</configure>The path can be determined by entering the configuration and using the present working context (PWC) option. Below an example that shows the appropriate PWC option for determining the path for the complete BGP configuration and a specific BGP neighbor.
The path can be determined by using the pwc command with the appropriate format (path option). In this case xpath that can be used by the external application/system to collect this configuration.
From the [gl:configure router "Base" bgp] context:
pwc xpathPresent Working Context:
/configure/router[router-name=Base]/bgpLet's try another one the specific BGP neighbor configuration.
From the [gl:configure router "Base" bgp neighbor "10.10.10.1"] context:
info json{
"admin-state": "enable",
"group": "internal",
"type": "internal",
"peer-as": 65005
}pwc xpathPresent Working Context:
/configure/router[router-name=Base]/bgp/neighbor[ip-address=10.10.10.1]As mentioned earlier in the section there are multiple output format available, different path options.. As a reference below just an overview which displays the differences.
pwc xpath can be used by external applications/systems to retrieve information via for example gNMI.
pwc model-path can be used when external systems/systems are using RESTCONF for their NBI and referencing the SR-OS YANG models, for example NOKIA NSP.
From the (gl)[configure port 1/1/c1/1 ethernet] context:
pwcPresent Working Context:
configure
port 1/1/c1/1
ethernetpwc xpathPresent Working Context:
/configure/port[port-id=1/1/c1/1]/ethernetpwc model-pathPresent Working Context:
/nokia-conf:configure/port=1%2F1%2Fc1%2F1/ethernetGetting back to the required step for extracting, retrieving the configuration. This step utilizes an opensource tool gnmiClient to demonstrate how the above determined path can be used to collect the configuration via gNMI.
First the complete BGP configuration, look at how the first line includes the path that was retrieved earlier.
gnmiClient -a 192.168.122.203:57400 --username admin --password admin get --path /configure/router[router-name=Base]/bgp --insecuretimestamp: 1591372253832072451
prefix:
alias:
configure/router[router-name=Base]/bgp: (*gnmi.TypedValue_JsonVal) {
"group": [
{
"family": {
"ipv4": true,
"vpn-ipv4": true
},
"group-name": "internal"
}
],
"neighbor": [
{
"admin-state": "enable",
"group": "internal",
"ip-address": "10.10.10.1",
"peer-as": 65005,
"type": "internal"
}
],
"router-id": "1.1.1.2"
}
Second, the specific BGP neighbor configuration.
gnmiClient -a 192.168.122.203:57400 --username admin --password admin get --path /configure/router[router-name=Base]/bgp/neighbor[ip-address=10.10.10.1] --insecuretimestamp: 1591372428438966619
prefix:
alias:
configure/router[router-name=Base]/bgp/neighbor[ip-address=10.10.10.1]: (*gnmi.TypedValue_JsonVal) {
"admin-state": "enable",
"group": "internal",
"ip-address": "10.10.10.1",
"peer-as": 65005,
"type": "internal"
}SR OS provides the possible to navigate through the state tree by providing access to YANG state models in the MD-CLI:
Let's first show the output of the tree command in the state tree. To avoid a long output, let's drill down in to showing the state options specifically available for sent statistics of a specific BGP neigbor. (state router "Base" bgp neighbor "10.10.10.1" statistics sent)
It provides the overview of which state items are available for that specific section.
From the [state router "Base" bgp neighbor "10.10.10.1" statistics sent] context:
tree+-- messages
+-- octets
+-- queues
+-- route-refresh
+-- updatesThe actual state information/values can be displayed as well, command to use info json or info xml.
From the [state router "Base" bgp neighbor "10.10.10.1" statistics sent] context:
info json{
"queues": "0",
"messages": "43137",
"octets": "819709",
"updates": "2",
"route-refresh": "0"
}info xml<queues xmlns="urn:nokia.com:sros:ns:yang:sr:state">0</queues>
<messages xmlns="urn:nokia.com:sros:ns:yang:sr:state">43137</messages>
<octets xmlns="urn:nokia.com:sros:ns:yang:sr:state">819709</octets>
<updates xmlns="urn:nokia.com:sros:ns:yang:sr:state">2</updates>
<route-refresh xmlns="urn:nokia.com:sros:ns:yang:sr:state">0</route-refresh>The possibility to display the YANG modeled back to the root via info full-context combined with json and xml.is also available for the state datastore.
From the [state router "Base" bgp neighbor "10.10.10.1" statistics sent] context:
info json full-context{
"nokia-state:state": {
"router": [
{
"router-name": "Base",
"bgp": {
"neighbor": [
{
"ip-address": "10.10.10.1",
"statistics": {
"sent": {
"queues": "0",
"messages": "43137",
"octets": "819709",
"updates": "2",
"route-refresh": "0"
}
}
}
]
}
}
]
}
}info xml full-context<state xmlns="urn:nokia.com:sros:ns:yang:sr:state">
<router>
<router-name>Base</router-name>
<bgp>
<neighbor>
<ip-address>10.10.10.1</ip-address>
<statistics>
<sent>
<queues>0</queues>
<messages>43137</messages>
<octets>819709</octets>
<updates>2</updates>
<route-refresh>0</route-refresh>
</sent>
</statistics>
</neighbor>
</bgp>
</router>
</state>
To continue to demonstrate the state navigation on the SR OS node let's do another one, getting the output for RSVP LSP statistics. (state router "Base" mpls statistics lsp-egress "to_A1" aggregate)
From the [state router "Base" mpls statistics lsp-egress "to_A1" aggregate] context:
info json{
"packets": "26",
"octets": "2964"
}The pwc command is available as well in the state tree which can be used to determine the state path and be used by a telemetry collector to subscribe to a path.
Let's use the command for the two different state items.
From the [state router "Base" bgp neighbor "10.10.10.1" statistics sent] context:
pwc xpathPresent Working Context:
/state/router[router-name=Base]/bgp/neighbor[ip-address=10.10.10.1]/statistics/sentFrom the [state router "Base" mpls statistics lsp-egress "to_A1" aggregate] context:
pwc xpathPresent Working Context:
/state/router[router-name=Base]/mpls/statistics/lsp-egress[lsp-name=to_A1]/aggregateBoth paths collection in the earlier section can be used by a telemetry collector. The below example utilizes an opensource tool gnmiClient to demonstrate how the above determined path can be used to subscribe to via gNMI.
First, let's get the BGP sent statistics. Look at how the first line includes the path that was retrieved earlier.
gnmiClient -a 192.168.122.203:57400 --username admin --password admin --insecure sub --path /state/router[router-name=Base]/bgp/neighbor[ip-address=10.10.10.1]/statistics/sent --insecureupdate received at 2020-06-05T17:55:53.437413325+01:00
{
"timestamp": 1591376152365601173,
"prefix": "state/router[router-name=Base]/bgp/neighbor[ip-address=10.10.10.1]/statistics/sent",
"updates": [
{
"Path": "queues",
"values": {
"queues": "0"
}
},
{
"Path": "messages",
"values": {
"messages": "43137"
}
},
{
"Path": "octets",
"values": {
"octets": "819709"
}
},
{
"Path": "updates",
"values": {
"updates": "2"
}
},
{
"Path": "route-refresh",
"values": {
"route-refresh": "0"
}
}
]
}
sync response: trueSecondly the MPLS LSP statistics.
gnmiClient -a 192.168.122.203:57400 --username admin --password admin --insecure sub --path /state/router[router-name=Base]/mpls/statistics/lsp-egress[lsp-name=to_A1]/aggregate --insecureupdate received at 2020-06-05T17:57:18.563775942+01:00
{
"timestamp": 1591376237491452836,
"prefix": "state/router[router-name=Base]/mpls/statistics/lsp-egress[lsp-name=to_A1]/aggregate",
"updates": [
{
"Path": "packets",
"values": {
"packets": "26"
}
},
{
"Path": "octets",
"values": {
"octets": "2964"
}
}
]
}
sync response: trueWith this introduction we have navigated through SR OS for state and configuration information and explored several commands which will help you with your automation journey.
Author: MP