The page below is from the manual of PRTG, our quick-to-install and easy-to-use network monitoring software
Try PRTG now and see how it can make your job easier.
PRTG Manual: Monitoring Bandwidth via Flows
Using flow protocols, you can monitor the bandwidth usage of all packets going through a device. In PRTG, you can view Toplists for all xFlow (NetFlow, IPFIX, sFlow, jFlow) sensors.
Flows are a type of monitoring data pushed from network devices to PRTG. You can use it to monitor where data is traveling from and to, and how much. This way it determines which machine, protocol, and user is consuming bandwidth. PRTG currently supports the following flow types:
- NetFlow v5/v9 and IPFIX: Originally introduced by Cisco and supported by several vendors
- jFlow: Traffic sampling technology introduced by Juniper networks
- sFlow: Short for sampled flow, introduced by HP. sFlow uses statistical sampling of the traffic at defined intervals to achieve scalability for high volume interfaces.
You can also use packet sniffing for bandwidth monitoring if your hardware does not support any of these flow versions.
You can measure bandwidth usage by IP address or by application in a network, using one of the xFlow (including IPFIX) protocols. They are the best choice especially for networks with high traffic (connections with 100s of megabit or gigabits).
For xFlow monitoring, the router gathers bandwidth usage data (flows ), aggregates them, and sends information about these flows to PRTG using UDP packets. When you use sampling (mandatory for sFlow), only information about every n-th packet is sent to PRTG which reduces CPU load a lot. Because the switch already performs a pre-aggregation of traffic data, the flow of data to PRTG is much smaller than the monitored traffic. This makes xFlow the ideal option for high traffic networks that need to differentiate the bandwidth usage by network protocol and/or IP addresses.
The NetFlow (and IPFIX) protocol is mainly used by Cisco devices. Once configured, the router sends for each data flow a NetFlow or IPFIX packet to the monitoring system running on a PRTG probe. You can be filter and evaluate the data in PRTG. There are different NetFlow and IPFIX sensors available: The basic ones offer predefined channel definitions, the custom variants enable you to define your own channels.
The advantage of using NetFlow or IPFIX:
- Generates little CPU load on the router itself (according to Cisco 10,000 active flows create about 7% additional CPU load; 45,000 active flows account for about 20% additional CPU load).
- Generates less CPU load on the PRTG core system, compared to packet sniffer sensors.
You must enable NetFlow or IPFIX export on the device you want to monitor. The device must send a flow data stream to the IP address of the PRTG probe system on which you set up the NetFlow or IPFIX sensor.
You can monitor Juniper jFlow with the corresponding sensors as well. Basically they are adjusted NetFlow v5 sensors.
sFlow works similar to NetFlow monitoring. The router sends data flow packets to the monitoring system running on a PRTG probe. The most obvious difference between the two flow protocols: With sFlow, not all of the traffic is analyzed, but only every n-th packet. It is like having a river of traffic and you take a cup of water out of it ever so often and analyze it.
The advantage is clear: There is less data to analyze, there is less CPU load needed, and less monitoring traffic is generated. Nevertheless, you can get a good insight into your network bandwidth usage.
PRTG supports sFlow version 5.
Find details on how to set up the different flow sensors in the following sections:
- NetFlow V5 Sensor
- NetFlow V5 (Custom) Sensor
- NetFlow V9 Sensor
- NetFlow V9 (Custom) Sensor
- IPFIX Sensor
- IPFIX (Custom) Sensor
- sFlow Sensor
- sFlow (Custom) Sensor
- jFlow V5 Sensor
- jFlow V5 (Custom) Sensor
On a powerful 2008 PC (Dual Core, 2.5 Ghz), you can process about 100,000 flows per second for one xFlow stream. Using sampling, the number of actual flows can be much higher. When using complex filters, the value can be much lower. For example, with a router sending about 2,000 flows/second (which corresponds to mixed traffic at gigabit/second level without sampling) you can expect to configure up to 50 NetFlow sensors operating properly.
PRTG internally monitors its own NetFlow processing. You can see decreased values in the Health channels of the Core Health and Probe Health sensors as soon as NetFlow packets are not processed due to an overload (you find these sensors on the local probe device).
If you experience an overload, please consider using sampling or setting up multiple probes and distribute the NetFlow streams to them. We recommend that you do not add more than 50 NetFlow sensors per PRTG probe.
This sensor type cannot be used in cluster mode. You can set it up on a local probe or remote probe only, not on a cluster probe.
Flow sensors are not IPv6 compatible.
Video Tutorial: Bandwidth Monitoring With Flows and Packet Sniffing
Knowledge Base: Can I add custom channels to standard Packet Sniffer and NetFlow sensors?
Knowledge Base: What filter rules can be used for custom Packet Sniffing or xFlow (NetFlow/sFlow) sensors?
Knowledge Base: How do the channel definitions for custom Packet Sniffing or xFlow (NetFlow/sFlow) sensors work?
Knowledge Base: Does my Cisco device (Router/Switch) support NetFlow Export?
Knowledge Base: Do you have any configuration tips for Cisco routers and PRTG?
Knowledge Base: How to monitor Cisco ASA Firewalls using NetFlow 9 and PRTG?
Knowledge Base: How can I change the default groups and channels for xFlow and Packet Sniffer sensors?
Knowledge Base: What is the Active Flow Timeout in Flow sensors?
Tools: NetFlow Generator and NetFlow Tester
- Monitoring via SNMP
- Monitoring via WMI
- Monitoring via SSH
- Monitoring Bandwidth via Packet Sniffing
- Monitoring Bandwidth via Flows
- Bandwidth Monitoring Comparison
- Monitoring Quality of Service
- Monitoring Email Round Trip
- Monitoring Backups
- Monitoring Virtual Environments
- Monitoring Databases
- Monitoring Syslogs and SNMP Traps