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 commandDescription
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 (wink)

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






  • No labels