Telemetry
Overview
The rXg supports the ingest of streaming telemetry data from three different sources: gRPC, MQTT, and Kafka. All of these ingest data types are used to get and analyze radio metrics and client metrics, which are presented in Radio Metric Graphs and the KPI dialog types.
Cisco 9800 (via gRPC) and Ruckus vSZ (via MQTT) operate with the rXg acting as a server.
OpenWiFi (via Kafka) operates with the OpenWiFi Kafka process as the server, also known as the broker in the Kafka terminology.
Individual Wi-Fi controllers may be instantiated locally on the rXg, running on the rXg virtualization host, or instantiated externally on some other virtualization platform, in an appliance, etc. In either case, the rXg is capable of receiving streaming telemetry from such devices and processing it locally.
Prerequistes
The WLAN Controller and the rXg MUST be time synchronized to the same epoch to avoid interpretation problems.
OpenWiFi Gateway via Kafka bus
The rXg automatically attempts to connect to the OpenWiFi Gateway (OWGW) on the Kafka bus on port 9094. If you have installed the OWGW using the image provided by RG Nets using the config template example, this communication path is established automatically.
Cisco 9800 WLC via gRPC
The Cisco 9800 Wireless Lan Controller (WLC) uses gRPC to stream telemetry data.
The Cisco 9800 WLC MUST have Netconf Yang enabled. This can be done with the netconf-yang
CLI directive or in the GUI via Administration>HTTP/HTTPS/Netconf/VTY
.
If you use the bootstrap script automatically generated from the rXg, that will
have the netconf-yang
directive in it, providing the simplest path to enable the streaming telemetry in this setup.
rXg Setup
To enable gRPC streaming, create a WLAN Controller record for your WLAN Controller if there is not one already. If the rXg supports gRPC streaming for your WLAN controller, a gRPC port input field will be available. Put in the port number that you want the rXg to listen on for this device's gRPC telemetry data.
It is critically important to have the port that the rXg is listening for telemetry data on be exactly the same port that the WLC is configured to send the telemetry data TO. If you wish to stream telemetry data from multiple WLCs to one rXg, each WLC must stream to a different port on that rXg.
Cisco 9800 Setup
The rXg provides a built in facility for building the exact script necessary to to create the streaming telemetry subscriptions on the Cisco 9800 WLC.
First scroll to the right of your WLAN device record to access the Bootstrap view.
Then click on Show to present the telemetry bootstrap configuration script.
Next click on Copy to Clipboard to copy this configuration.
Next paste the configuration into the Cisco 9800 WLC to run it:
NOTE: This will update existing low numbered subscriptions if you have any
Setup Confirmation
Next you may be wondering if your rXg is receiving the streaming telemetry data.
Check Access Point Radios on rXg
The easiest, fastest and simplest way to check if your Telemetry data is streaming in is to check if any Access Point Radios are now present. In the Network >> Wireless view of your rXg, scroll down to the Access Point Radios Scaffold and see if there are new ones:
Health Check on rXg
Another way to check is to make a "Cisco Telemetry Health Check" widget.
In order to do this, setup a new custom dashboard with the Cisco Telemetry health check widget on it. Widgets and dashboards and dashboard configuration is covered in the Archives >> Reports section of this manual, but here is an example of configuring such a widget.
Here is what the widget will look like when the data is being received.
NOTE: You will not receive data for client_oper_data_common_oper_data
,
client_oper_data_dot11_oper_data
or client_oper_data_traffic_stats
when no
clients are associated.
Health Check on Cisco 9800 WLC
The best way to check the status of the subscriptions on the Cisco 9800 WLC is with the
command show telemetry ietf subscription all detail
.
All the rest of the subscriptions should also say Connected
and Subscription Validated
as well.
Ruckus vSZ Setup
The rXg can receive telemetry data from the RUCKUS Virtual Smart Zone via the MQTT (Message Queuing Telemetry Transport) protocol.
rXg Setup
To enable MQTT streaming, we will need to create a local MQTT server. This can be done by browsing to Network >> Wireless >> WLAN Controllers and editing an existing vSZ WLAN Controller profile, or creating a new one if needed. A new vSZ WLAN Controller profile is needed even if the vSZ instance is running external to the rXg and the streaming telemetry data is intended to be collected and procsssed on the rXg.
The example below shows a vSZ WLAN Controller instance created for an external vSZ to collect the streaming telemetry data.
Scroll down to the RUCKUS section of the WLAN Controller profile and populate telemetry_username
and telemetry_password
fields.
Once the changes are saved, a local MQTT server will be created to receive the streaming data from the vSZ. You can see the MQTT server configuration under the Services >> Servers >> MQTT Server scaffold.
If the vSZ WLAN Controller VM is locally hosted on the rXg, the vSZ will automatically be configured to start sending telemetry data.
If the vSZ WLAN Controller VM is hosted off the rXg (in a private or public cloud, in an appliance, etc.), the vSZ streaming telemetry configuration needs to be modified manually, by creating a new profile in the Administration >> NB Streaming area of the vSZ WLAN controller, as shown below:
The profile configuration includes the following fields:
The Name field is an arbitrary string used to identify the portal. This string is used for identification purposes only.
The Server Host field is populated with the FQDN or the IP address of the WAN interface on the rXg system that is collecting the streaming telemetry data.
The Server Port field is populated with the port number of the MQTT server, as configured on the rXg side.
The User and Password fields are populated with the respective fields from the vSZ WLAN Controller as discussed before.
The System ID field is populated with the vSZ WLAN Controller ID value, which can be found by browsing in the rXg to Network >> Wireless >> WLAN Controllers and clicking "Show" on the scaffold for the previously configured WLAN controller. You will then scroll down to the bottom and find the ID field.
- The Data Type field allows to select which of the vSZ data points will be streamed from the vSZ WLAN Controller to the rXg, including the 4 primary groups, i.e., AP data, Client data, System data, and Switch data. Individual data groups have further data categories, when expanded.
Setup Confirmation
Check Access Point Radios
The easiest, fastest and simplest way to check if the telemetry data is streaming in is to check if any Access Point Radios are now present.
In the Network >> Wireless view of the rXg, scroll down to the Access Point Radios Scaffold and see if there are new WAPs:
Check Subscription in vSZ WLAN Controller (local or remote)
Another good place to check is in the vSZ itself. In Administration >> NB Streaming
you should be able to find your subscription. When it is working, you should see
Connected
to the right in the list view.
Check MQTT Server on rXg
In the Services >> Servers scaffold in the rXg, scroll down to MQTT Servers. Create or edit an MQTT Server with the following attributes:
active: true
tls version: 1.2
tls_port: 8883
infrastructure_devices: <YOUR vSZ>
In order for the rXg to create all the necessary firewall rules for the MQTT Server, you must have an active MQTT Server associated with your WLAN Controller via your WLAN Controller's MQTT Server attribute.
instrument_from
option.
The instrument_from
option tells the rXg to create and update
Access Points and Wireless Clients based on telemetry data if it is set to telemetry.
If you are running with config sync turned on, or monitoring turned on, your rXg
will be able to import infrastructure updates through the regular infrastructure
monitoring process, and you are recommended to run with instrument_from
set to 'integration'.
If you are not using monitoring or config sync and are just receiving telemetry
data from an infrastructure device, then you are recommended to run with instrument_from
set to 'telemetry'.