Operating SDN-R with bash only

The chapter describes how you can get a first overview about a running SDN-R and its features and functionality just using ssh, bash, curl.

However you need the IP-Address or the fully-qualified-domain-name of the machine running CCSDK with SDN-R services.

Karaf Container

ssh to the system running an SDN-R node (CCSDK, OpenDaylight node).

^{ssh <user>@<system-ip>}

In case the karaf container is running within a docker container, please jump into the docker.

Please note that an ssh into the karaf using ssh -p 8101 karaf@<system-ip> will not work, because the port 8101 is usually not forwarded and the ssh client is not installed on the reduces system (alpine) used by ONAP CCSDK docker containers, reducing the entire ONAP footprint.

In order to jump into the docker container it is necessary to know the docker container id. The following command will list all the containers.

^{sudo docker ps}

Remember the docker container id you are interested in.

^{sudo docker exec -it <container-id> /bin/bash}

Now open the karaf console to check the CCSDK/OpenDaylight/Status and the running features.

^{$ODL_HOME/bin/status}

^{$ODL_HOME/bin/client}

The last command will prompt the karaf console. Please use the following commands to get familiar with the running system SDN-R.

karaf command	Description

karaf command	Description
^info	gives high level information about the karaf container
^log:list	shows the actual log settings
^{log:display \| grep " ERROR "}	shows all logged errors - it is expected that no errors occurred in an production environment.
^{feature:list \| grep sdnr}	All SDN-R features should have been started.

Please see karaf documentation for further information about the karaf commands: http://karaf.apache.org/manual/latest/#_commands

OpenDaylight RestConf

MDSAL OpenDaylight internal data

Most for the important data is stored in OpenDaylights Model-Driven-Service-Abstraction-Layer (MD-SAL). The entire data tree is accessible via the RestConf interface.

One of the main questions is: How many NetConf-Servers are configured and what it the connection-status to each NetConf-Server.

^#!/bin/bash

^{protocol=http # http or https}
^{fqdn=10.20.6.29 # This is a machine of OSNL (OpenSDN/NFV lab) used for testing the commands}
^{httpPort=8181}
^{odlAaaUserName=demx8as6}
^{odlAaaUserPassword=************}

^{login="-u $odlAaaUserName:$odlAaaUserPassword"}
^{header='--header "Content-Type: application/json"'}
^{baseUrl="$protocol://$fqdn:$httpPort"}

^{echo "List configured mountpoints"}
^{odlMountpointsUrl=$baseUrl/restconf/config/network-topology:network-topology}
^{curl $login $header $odlMountpointsUrl | python -m json.tool | grep node-id}
^echo

^{echo "List connection-status of mountpoints"}
^{odlMountpointsUrl=$baseUrl/restconf/operational/network-topology:network-topology}
^{curl $login $header $odlMountpointsUrl | python -m json.tool | grep connection-status}
^echo

Data from NetConf Sever (device, network function)

Via the OpenDaylight RestConf interface it is also possible to retrieve the data from NetConf Servers. Of cause you need to know the "node-id" - the OpenDaylight identifier for the NetConf-Server and the supported YANG Models.

The node-ids are known from the commands above. Please remember one

Now it is necessary to check the supported yang modules:

^{echo "View supported yang capabilities for a sleeted node (device, mountpoint, netconf-server)"}
^{nodeId=<node-id>}
^{odlMountpointsUrl=$baseUrl/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/$nodeId/available-capabilities}
^{curl $login $header $odlMountpointsUrl | python -m json.tool | grep capability\":}
^echo

^{echo "Show device data provided by the NetConf-Server"}
^{yangCapability="core-model:network-element"}
^{odlMountpointsUrl=$baseUrl/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/$nodeId/yang-ext:mount/$yangCapability}
^{curl $login $header $odlMountpointsUrl | python -m json.tool}
^echo

Data from a database

SDN-R (currently - there are activities to move such data into other databases) stores a couple of data in an elasticsearch cluster. The most important ones are related to NetConf Alarm notifications.

From such notifications SDN-R keeps a table up-to-date with all current alarms of the network. In addition received NetConf Notifications with faults are stored in a separate. EleasticSearch APIs (https://www.elastic.co/guide/en/elasticsearch/reference/2.2/search.html) can be used to retrieve the data.

Current alarms

^{echo "Show 100 current alarms"}
^{esUrl=$baseUrl/database/sdnevents/faultcurrent/_search}
^{curl --request POST $header -d '{"from":0,"size":100,"query":{"match_all":{}}}' $esUrl | python -m json.tool}
^echo

Alarm Log

echo "Show 100 alarm logs"

^{esUrl=$baseUrl/database/sdnevents/faultlog/_search}
^{curl --request POST $header -d '{"from":0,"size":100,"query":{"match_all":{}}}' $esUrl | python -m json.tool}
^echo