{"id":1421,"date":"2022-06-14T08:30:32","date_gmt":"2022-06-14T08:30:32","guid":{"rendered":"https:\/\/excentiscom.webhosting.be\/blog\/\/"},"modified":"2022-11-24T15:04:21","modified_gmt":"2022-11-24T14:04:21","slug":"an-easy-dashboard-for-docsis-and-network-traffic","status":"publish","type":"post","link":"https:\/\/www.excentis.com\/blog\/an-easy-dashboard-for-docsis-and-network-traffic\/","title":{"rendered":"An easy dashboard for DOCSIS and network traffic"},"content":{"rendered":"

Have you ever noticed how a significant portion of your time is lost switching between different tools<\/strong>? Take a modem test, for example. The DOCSIS stats are found on one console-terminal, the traffic generator has a GUI, and probably a few more dashboards or admin panels. While each of these makes perfect sense on their own, each individual interface switch costs a bit of your precious attention, which comes at the expense of solving the problem at hand.<\/p>\n

This inefficiency is a rather annoying and devious problem that we face frequently here at Excentis.<\/p>\n

More dashboards, less fragmentation!<\/h2>\n

We used one of our ongoing projects to improve our way of working. This time it was a DOCSIS project. Don\u2019t worry if this isn\u2019t your cup of tea, the general idea applies to other technologies, so we\u2019ll try adding analogies where necessary and we might even add a different Wi-Fi example later on.<\/p>\n

The Project<\/h2>\n

The goal was to find the effect of the signal quality on the network traffic:
\nCan we detect a degradation of any customer service from DOCSIS monitoring?<\/strong><\/p>\n

Some might recall a similar question we asked in the past for a Wi-Fi environment, we wrote this article on W-FI\/RSSI\u00a0Error! Hyperlink reference not valid.What makes this different, though, is that DOCSIS offers much more than merely RSSI. Parameters such as Signal to Noise Ratio (SNR) and the Codeword Error Rate (CER) are readily available. These metrics reflect the conditions in the network well, in particular additional noise that disturbs communication will also degrade the SNR and CER. It\u2019s no surprise that these values are often included in the KPIs to monitor, both in the field as in testing.<\/p>\n

The parameters above are DOCSIS metrics. This is our first tool to use. As is tradition, they can be retrieved using SNMP. From where can they be retrieved, you may ask? From both sides of the coax! The codeword error rate for instance requires combining multiple values from the CMTS, a calculation that we described in this blog post<\/span>.<\/p>\n

Monitoring SNMP data is something most network tools support. In order get a good overview, however, a bit more is required: being able to easily process the results or even combine them with other data. These features are somewhat harder to find. To this end we investigated a new approach (well, new to us), and this is where Prometheus came into play.<\/p>\n

Enter Prometheus and Grafana<\/h2>\n

\"\"\"\"<\/p>\n

Prometheus is a time-series database.<\/strong> It\u2019s often used together with Grafana that provides the graphical frontend. Compared to traditional network monitoring tools, it\u2019s a much more generic solution, but that might just be what we need.<\/p>\n

Most tests require some development either way, if with a bit of extra work the specific tools could be combined into a single solution that works well with DOCSIS, or with Wi-Fi; that would be great. And even better woud be if we could also interface our Traffic generator and our DOCSIS sniffer.<\/p>\n

This is how we got started. And how did it go? Let\u2019s find out.<\/h2>\n

Prometheus and Grafana are open-source tools, installing and configuring the software went smoothly, as expected. It helps, of course, for the default configuration to make sense and the online documentation being very helpful. What is off the beaten path is adding the appropriate OID from the DOCSIS MIB. For this project, we required the ones from earlier mentioned blogpost (docsIfSigQUncorrectables, docsIfSigQCorrecteds, …).<\/p>\n

Still, navigating through these can be somewhat daunting, that\u2019s why we tend to spend a significant amount of time to it during our training sessions<\/a>.<\/p>\n

Blowing bytes<\/h2>\n

The DOCSIS parameters are only part of the exercise. For this test,\u00a0we wanted to see the effect of the signal quality onto CER. Measuring this required sending network traffic. This can be done using our second tool, the ByteBlower<\/a>.<\/p>\n

Configuring the traffic is rather easy in this case. A single traffic flow in the GUI can be configured to all the modems in the test. Where we wanted to add Prometheus was in the monitoring this generated network traffic.<\/p>\n

Getting test result data<\/h2>\n

To get results out of the ByteBlower GUI, there are 3 possible methods:<\/p>\n