- English
- Deutsch
- Español
- Français
- Italiano
- Português
“Who is hogging my bandwidth?” This question keeps coming up regularly. The network is slow and you need to identify the root of the problem.
To determine how much bandwidth your devices and applications are using, you can use different protocols like SNMP, Flow or packet sniffing – depending on your network and hardware.
WMI WMI | SNMP SNMP | Packet Sniffer Packet Sniffer | Flow (IPFIX, NetFlow, sFlow, jFlow) Flow (IPFIX, NetFlow, sFlow, jFlow) | |
Setup | WMI Medium | SNMP Easy | Packet Sniffer Easy to complex (depending on filter rules used) | Flow (IPFIX, NetFlow, sFlow, jFlow) Can be complex (e.g., the switch must be configured) |
Traffic can be filtered | WMI | SNMP | Packet Sniffer | Flow (IPFIX, NetFlow, sFlow, jFlow) |
Differentiate bandwidth usage by protocol or IPs | WMI | SNMP | Packet Sniffer | Flow (IPFIX, NetFlow, sFlow, jFlow) |
PRTG can show Toplists (Top Talker, Top Connections, Top Protocols, custom) | WMI | SNMP | Packet Sniffer | Flow (IPFIX, NetFlow, sFlow, jFlow) |
Filter bandwidth usage by IP | WMI | SNMP | Packet Sniffer | Flow (IPFIX, NetFlow, sFlow, jFlow) |
Filter bandwidth usage by MAC address | WMI | SNMP | Packet Sniffer | Flow (IPFIX, NetFlow, sFlow, jFlow) |
Filter bandwidth usage by physical network port | WMI | SNMP | Packet Sniffer | Flow (IPFIX, NetFlow, sFlow, jFlow) |
Monitor network parameters other than bandwidth usage | WMI | SNMP | Packet Sniffer | Flow (IPFIX, NetFlow, sFlow, jFlow) |
CPU load on the machine running PRTG | WMI Medium | SNMP Low | Packet Sniffer Higher, depends on the amount of traffic | Flow (IPFIX, NetFlow, sFlow, jFlow) Higher, depends on the amount of traffic |
Excess bandwidth usage of monitoring | WMI Small | SNMP Small | Packet Sniffer None (except when monitoring switch ports are used) | Flow (IPFIX, NetFlow, sFlow, jFlow) Depends on the traffic |
Get full visibility with real-time dashboards, alerts, and customizable sensors
Before you can monitor the bandwidth of your IT infrastructure, PRTG has to “know” all your devices.
The monitored devices must be equipped with SNMP v1, v2c, or v3 (an SNMP-compatible software must be installed on the device).
Keep in mind that SNMP v1 and v2c are no secure protocols. You should not use these protocols if your PRTG installation is reachable via the internet.
SNMP needs to be enabled on the device and the machine running PRTG must have access to the SNMP interface.
Note: SNMP monitoring causes the least CPU load.
NetFlow and IPFIX export must be enabled on the monitored device and the router or switch needs to be configured to send Flow packets to the IP address of the PRTG probe system on which you set up the respective Flow sensor.
For choosing a suitable sensor, you also need to know what Flow version (NetFlow V5, NetFlow V9, jFlow, sFlow, or IPFIX) the router or switch sends.
Note: Flow is recommended for high traffic networks and for advanced users.
The router or switch must be configured to send a copy of all network packets to the IP address of the PRTG probe system on which you set up the Packet Sniffer sensor.
Note: Packet sniffing creates the highest CPU load on the system that runs PRTG.
DCOM must be enabled on the probe system and on the target system. You need to enter Windows credentials in the settings of the parent device or group.
The Remote Registry Windows service must run on the target system. There are a few other basic requirements for using WMI to monitor your network. For more information, see this Knowledge Base article.
Note: Monitoring bandwidth via WMI has a moderate impact on system performance.
With the Simple Network Management Protocol (SNMP), you can gather bandwidth usage data in a very basic way and port by port.
On a single host or server, we recommend that you use an SNMP Traffic sensor to measure the bandwidth used by this specific device.
On a switch or router, SNMP Traffic sensors show the bandwidth usage on a specific port. You need to set up one sensor per port.
As a general rule, we recommend that you
We recommend that you start with the default settings. You can change the settings later at any time.
Custom alerts and data visualization let you quickly identify and prevent all kinds of issues
Flow technologies (NetFlow, IPFIX, jFlow, sFlow) are best suited for Cisco, Juniper, HPE, and other enterprise-grade routers and switches. Flow monitoring is particularly made for larger networks where you need to identify bottlenecks and consumption broken down by IP address to identify the root cause of a bandwidth issue.
You need to add one Flow sensor for each protocol or IP address that you want to monitor.
If you only need to know about current and recent traffic by protocol or IP address, you can also add just one Flow sensor and enable the Toplist feature. For example, you can use the NetFlow v9 sensor to monitor the top talkers, top protocols and top connections on a switch or a router.
We recommend that you start with the default settings. You can change the settings later at any time.
You can find some additional information about monitoring via Flows in another
how-to guide.
For debugging NetFlow- and sFlow-based configurations, we offer specific test tools that simply dump the data of all Flow packets that a computer receives from an Flow-enabled router.
Packet sniffing is an option ...
To calculate the bandwidth usage, PRTG inspects every single network data packet
or
Windows Management Instrumentation (WMI) is a Microsoft technology with which you can monitor and manage Windows-based systems.
Although WMI is not originally intended for bandwidth monitoring, it can be used for this purpose.
The Windows Network Card sensor, for example, monitors bandwidth usage and traffic on a network interface via WMI.
We recommend that you start with the default settings. You can change the settings later at any time.
To easily visualize your critical monitoring data or to share monitoring results with colleagues or customers, use PRTG Maps to create dashboards for each interest group.
For example, you can create overview maps for management or detailed maps for administrators.
PRTG includes a powerful reporting engine for ad hoc report generation as well as scheduled report generation in HTML, PDF, CSV, and XML format. This means that you can run reports on demand or on a regular basis (for example, once a day or once a month).
Furthermore, you can create reports for a single sensor or for a whole range of sensors.
The content and layout of the report is controlled by the report template of your choice and is the same for all sensors in a report.
