WR Switch: Basic Remote Monitoring (Deprecated)

THIS HOWTO IS DEPRECATED

This describes how basic remote monitoring of White Rabbit switches can be done by using simple command line tools and DIM as communication protocol.

Introduction

Switches provide an application wr_mon, which can be used for local monitoring, when logged on to a switch. The main idea is to convert wr_mon into a DIM server, which publishes the information to the standard network connected via the management port. An application implementing a DIM client, can subscribe to the DIM servers in the White Rabbit switches and display information or redirect it to logfiles or syslogs. Normal DIM services follow the publisher-subscriber-pattern "on-to-many". Hence, multiple subscribers are supported out of the box.

For now, a stripped version of wr_mon is used, to publish only primary information. Hence, it was renamed to wrs_umon_server (White Rabbit Switch Micro Monitor Server). This only demonstrates what can be done. In the future, not only the number and type of services, but also the functionality could be extended. As an example, one could add command services "many-to-one", such that remote control of switch features is available.

License is GPL. Use at your own risk.

DIM Services

wrs_umon_server publishes three services. All services are pre-fixed by an unique identifier SWITCH_ID, which could be a name, IP number or MAC address of a specific switch. As DIM is based on the concept of named services, SWITCH_ID must be different for all switches.

• SWITCH_ID/wrs_umon/version - version of wrs_umon_server
• SWITCH_ID/wrs_umon/syncState - some info on the sync state of a switch.
• SWITCH_ID/wrs_umon/portState - This is a 18 character string providing basic information on the ports, like S---MM---M-------M. A connected port is marked by S (in case this port is a White Rabbit PTP slave) or M in all other cases.

All services are only updated on-change, and clients receive only updates upon start-up or when the value is updated by the server, or when the connection to the server is lost.

Getting Started

Binaries are provided in the tarball (see "Download" below). gunzip and tar -xf the tarball.

Linux Box

If you are not familiar with DIM, it might be a good idea to look at the DIM website for more info on DIM. After setting environment variables and starting the DIM Names Server, try the "test_server" and "test_client" provided with the DIM binaries.

1. Make sure DIM is set up properly:
   1. include SOMEPATH/wrs_umon-0.01b/dim_old/linux in the environment variable "LD_LIBRARY_PATH"
   2. start the DIM name server dns. This server must just be started once on one machine somewhere in the same network segment. This machine can be different one, then the one where clients are started. Only one dns is required in the network.
   3. set the environment variable DIM_DNS_NODE to the machine where dns is now running. In tcsh, =setenv LD_LIBRARY_PATH /SOMEPATH/wrs_umon-0.01b/dim_old/linux:${LD_LIBRARY_PATH} =
   4. remark: this only needs to be done once.
2. start the wrs_umon_client, located in SOMEPATH=/wrs_umon-0.01b/binaries/linux by typing ./wrs_umon_client SWITCH_ID. Replace SWITCH_ID by the IP number of the management port of one of the White Rabbit switches (You could also use names like Asterix, Obelix, Miraculix or the hostname. The SWITCH_ID just need to be unique for each switch).

   lxabc123:~/SOMEPATH/wrs_umon-0.01b/binaries/linux> wrs_umon_client 192.168.20.4
   192.168.20.4 - umon: white rabbit switch micro monitor: client version 0.01b
   192.168.20.4 - umon: NOLINK 
   

3. The above example shows the expected behavior. Leave the client running.

White Rabbit Switch

The wrs_umon_server is just a userspace program. It can be installed on-the-fly on a running switch. Rebooting etc. is not required.

1. log on to the switch
2. set up DIM
   1. define the environment variable DIM_DNS_NODE. It should have the same value like on your linux box.
   2. modifying LD_LIBRARY_PATH is not required, as all libraries for wrs_umon_server are statically linked.
3. cd to /wr/bin .
4. using scp, copy wrs_umon_server from SOMEPATH/wrs_umon-0.01b/binaries/wr-switch
5. make sure, the hostname is set on the White Rabbit switch by typing hostname. If not, set it using hostname 111.222.333.444.
6. start the server #wrs_umon_server $(hostname). (You could also replace $(hostname) by Asterix, Obelix, Miraculix, or whatever. It just needs to be unique and match the SWITCH_ID that was used on the Linux box).

wrs-192.168.20.4#wrs_umon_server $(hostname)
white rabbit switch micro monitor: server version 0.01b
192.168.20.4 - umon: sync state: wr0
192.168.20.4 - umon: port state: S-----------------

1. The above example shows the expected behavior. Here, the White Rabbit switch has established a successful link to a WR PTP master, via port wr0. Only one port is connected at the switch, which is obviously the first point configured as WR PTP slave.

Monitoring Mulitple Switches

Back on the linux box, where the client is still running, the connection to the server should be established.

lxabc123:~/SOMEPATH/wrs_umon-0.01b/binaries/linux> wrs_umon_client 192.168.20.4
192.168.20.4 - umon: white rabbit switch micro monitor: client version 0.01b
192.168.20.4 - umon: NOLINK
192.168.20.4 - umon: established link to wrs_umon_server version 0.01b
192.168.20.4 - umon: port state: S-----------------
192.168.20.4 - umon: sync state: wr0

For monitoring multiple switches, a straight-forward solution is starting the monitor on the linux box for all White Rabbit switches and redirect the output to a log file.

lxabc123:~/SOMEPATH/wrs_umon-0.01b/binaries/linux> wrs_umon_client 192.168.20.1 >> umon.log &
lxabc123:~/SOMEPATH/wrs_umon-0.01b/binaries/linux> wrs_umon_client 192.168.20.2 >> umon.log &
lxabc123:~/SOMEPATH/wrs_umon-0.01b/binaries/linux> wrs_umon_client 192.168.20.3 >> umon.log &
lxabc123:~/SOMEPATH/wrs_umon-0.01b/binaries/linux> wrs_umon_client 192.168.20.4 >> umon.log &
lxabc123:~/SOMEPATH/wrs_umon-0.01b/binaries/linux> wrs_umon_client 192.168.20.5 >> umon.log &

Now, all activity like loosing or re-establishing a link to a White Rabbit master or (dis)connection of one of the ports is logged.

Another solution is just to use the generic tools provided by DIM itself like DID (DIM Information Display) and DIMTree.exe (Windows only). Binaries are not provided in the tarball, but one can get them via the DIM website.

Now, all messages from the switches will be redirected to umon.log. In case printing to the console is required as well, ">>" could be replaced by "| tee -a",

Issues

1. The installation on the White Rabbit switches described above is not boot-safe. Although the binary is on the flash file-system, settings environment variables and starting the server must be redone. Some start-up scripts would need to be modified if desired.
2. DIM has been cross-compiled in a straight forward manner. Usually, little-endian and big-endian conversions are handled inside DIM. This has not yet been checked. Eventually, I need to adjust the DIM makefiles a bit. Until then, only services of type "C" are used.
3. Stability: The servers and the clients as well as their connections seem to run stable on the time scale of one day. I don't have more statistics yet.
4. Scalability: This should scale very well: Even with the full number of White Rabbit switches required for the FAIR timing network exceeding 2000 White Rabbit nodes, this is just a small DIM domain.
5. This is just a proof of principle, not the release of a product.

Download and Links

• wrs_umon-0.01b.tar.gz: sources and binaries
• HOW-TO: Cross Compiling Hello World
• HOW-TO: Cross Compiling DIM
• http://www.ohwr.org

-- DietrichBeck - 01 Feb 2013