SR OS YANG navigation - 101

Navigate and obtain state and configuration

Introduction

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.


Equipment and tools

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 started!

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.

  1. Ensure that all SR OS devices are configured to be running in model-driven mode
  2. Determine which configuration is of interest and check out the different formats the configuration can be displayed
  3. Determine the path required for collecting configuration
  4. Extract that specific configuration from SR OS devices using gNMI
  5. Navigate state information on the SR OS device
  6. Determine the path required for collecting state information
  7. Collect state information from SR OS device using gNMI


Ensure that SR OS is in model-driven mode

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-driven


Determine which configuration is of interest and check out the different formats the configuration can be displayed.

It 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>

Determine the path required for collecting configuration

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 xpath
Present Working Context:
/configure/router[router-name=Base]/bgp

Let'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 xpath
Present 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:

pwc
Present Working Context:
  configure
  port 1/1/c1/1
  ethernet
pwc xpath
Present Working Context:
/configure/port[port-id=1/1/c1/1]/ethernet
pwc model-path
Present Working Context:
/nokia-conf:configure/port=1%2F1%2Fc1%2F1/ethernet

Extract that specific configuration from SR OS devices using gNMI

Getting 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 --insecure
timestamp: 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] --insecure
timestamp: 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"
}


Navigate state information on the SR OS device

SR OS provides the possible to navigate through the state tree by providing access to YANG state models in the MD-CLI:

  • Easily navigate and display state with tree, info, ? help and command completion like you can for configuration
  • Integrate with telemetry automation with XPath and model-path output
  • Validate telemetry automation with the MD-CLI by comparing data
  • Display state info in structured output like JSON or XML

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
+-- updates

The 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"
}

Determine the path required for collecting state information

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 xpath
Present Working Context:
/state/router[router-name=Base]/bgp/neighbor[ip-address=10.10.10.1]/statistics/sent

From the [state router "Base" mpls statistics lsp-egress "to_A1" aggregate] context:

pwc xpath
Present Working Context:
/state/router[router-name=Base]/mpls/statistics/lsp-egress[lsp-name=to_A1]/aggregate


Collect state information from SR OS device using gNMI

Both 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 --insecure
update 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: true

Secondly 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 --insecure
update 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: true

Conclusion

With 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.

  • Displayed the configuration or sections of configuration in json and xml format
  • Displayed the specific configuration, data of interest back to the YANG modeled root in json and xml format
  • Determined the xpath required for collecting the configuration information of interest via gNMI
  • Used gNMI to retrieve the configuration based on the determined xpath
  • Navigated state information in the state tree on the SR OS device
  • Determined the xpath required for collecting the state information of interest via gNMI
  • Used gNMI to retrieve the state information based on the determined xpath

Author: MP

On this page