![]() The access points save the last hour of data so now I request that once per hour instead. When I first created this script, I was requesting data from the access points every second which caused them to crash after a few hours of uptime. If the other sources increase then that shows we have an interference problem which may explain slow WiFi. The solid blue area on the graph is our WiFi traffic, whereas the red/green lines show other sources (other networks, interference, corrupted packets, etc). The data is in percent where 100% means that channel is fully utilised and can't handle any more traffic. The negative axis of this graph is 5GHz, and the positive axis is 2.4GHz. I can view a similar graph which shows the interference and utilisation of whatever channel the access points are using: Generally interference will cause the rate to drop. This is the first place I look when a WiFi device is slow. The WiFi access points expose the negotiated data rate for each client, so I can graph that in Grafana: I have also written various scripts to pull metrics from my WiFi access points, the router, network switch, ntopng, and suricata. Ntopng can also categorise traffic based on the protocol used so I can create a graph within Grafana showing bandwidth consumed by protocol, as shown below: ntopng also has native warnings for new MACs but can occasionally have false positives when a device is simply disconnected for weeks and then rejoins. The data gathered here includes every MAC address on the network so it is easy to detect when a new MAC address unexpectedly appears. Internal LAN traffic is combined with external WAN traffic in this view. This is a good tool to determine if any devices are consuming excessive amounts of data. This screenshot is a bar chart within Grafana which shows the daily data transfer by MAC: I am using this to provide Grafana with information such as the amount of bandwidth consumed by each device. In addition, it also exposes some information about devices on a per-MAC basis via an API. Ntopng has many other views and tools for monitoring the network. This VLAN doesn't have internet access so none of this traffic (except to/from my server) reaches anywhere. In addition, we can see UDP traffic on port 7999 from one of the cameras, and DNS queries for an unusual domain from another camera. This view makes it clear that regular communication is happening between the recording server at 192.168.2.1 and multiple IP cameras. This screenshot shows active connections on my CCTV VLAN within ntopng: This software can show detailed information about what each network device is doing on the network. A very important part of my network monitoring is ntopng.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |