PRTG - Bandwidth monitoring
with SNMP and WMI (EN)

Transcript - PRTG Bandwidth Monitoring

The 4 methods that PRTG offers for monitoring bandwidth. A couple of common questions about monitoring bandwidth, and how you can answer those questions using PRTG.

4 Methods for Bandwidth monitoring:

PRTG offers 4 main ways to monitor bandwidth: We're going to see concrete examples of all 4 of these today

List of all bandwidth sensors We're going to use these sensors to answer two common questions: How can I determine who is hogging my bandwidth? How can I determine if I'm getting the bandwidth I paid for? (e.g I'm paying for an 8 MEG line - am I really getting 8 MEG?)


We start by looking at the SNMP based sensors: SNMP traffic sensor and SNMP RMON sensor. SNMP Traffic sensor

This is your first line of attack. Go through Settings page

How to include additional channels for errors, broadcasts, ...

Connection Status Handling SNMP RMON sensor o For both SNMP traffic and SNMP RMON sensors:

What if my interface port names keep changing?

At device level: SNMP Compatibility options

Will apply to all SNMP sensors for that device

Now let's look at the Windows network card sensor, which uses Performance Counters and WMI

Shows less detail than the SNMP sensors

We try performance counters first, because that's more efficient. And if we don't get an answer, then we use WMI. If you'd like to change this behavior, there's a Windows Compatibility Options, just like we had an SNMP Compatibility options above. This is also at the DEVICE level, so it will apply to all WMI sensors for that device So, the SNMP traffic sensors show more detail that the WMI traffic sensors. Whenever you have a choice between using SNMP and using WMI, we would always recommend using SNMP, because it's much more efficient and puts less load on both PRTG and your target systems. However, sometimes your corporate policies won't permit you to use SNMP, and then you have no choice but to use WMI. Once you have these traffic sensors set up, you will probably want to define limits or thresholds for your sensors, so that you can receive an alert when the bandwidth goes too high. To do this, go into the sensor, to the channel where you want to set some limits, and click on the little gear symbol to open up the settings window. At the bottom, under Limits, enable Limits. Now you can enter the upper and lower warning and error limits, and a message if you'd like. Please note that if you'd like to change the scaling on the graphs, which is a request that comes up often, then you can set the minimum and maximum for the vertical axis here, too. Once you have limits set, you can set triggers for your sensors so that you get notifications about these sensors. So, to set up notifications, you need to switch to the notifications tab Inherited through tree In SNMP sensor, show NOTIFICATIONS tab

For traffic sensors, you have three choices on how to trigger State Speed volume So we've seen how we can monitor and get alerts about the amount of traffic we have. Let's go back to one of our two original questions: how do I tell who's hogging my bandwidth.

We've just seen the SNMP and WMI based traffic sensors, which were the ones of the left hand side of our table.

Can we answer "who's hogging my bandwidth" with only these sensors?

Not easily...

You could look at every single sensor to see if one is particularly high, but that's a real pain

So, we need a new plan. And our new plan, is the netflow and packet sniffer sensors. netflow and packet sniffer sensors

Reminder: main difference between SNMP & WMI sensors and the netflow & packet sniffer sensors: SNMP and WMI show amount of traffic, but not what's in the traffic. Netflow & packet sniffer let you see what type of traffic it was, based on port number or protocol.

PRTG supports different versions of flow, including netflow v5 and v9, IPFIX which is sort of Netflow 10, jFlow from Juniper and sFlow from HP, Extreme, and a number of other vendors.

I'm going to show a netflow v9 sensor today, but the others look exactly the same.

NETFLOW SENSOR To set up a netflow sensor, the very first step is to configure netflow on your switch. Unfortunately, since every switch vendor has a different user interface, I can't show you exactly how to do this. You'll need to check each vendor's documentation for how to configure flow on that switch. At some point in the configuration, you'll need to enter the destination address for where the switch should send the flows. At that point, enter the PRTG server. Then you can set up a flow sensor inside PRTG.

It's important to know ahead of time what version of flow your switch will send, because you must use the corresponding sensor type.

Once the flow sensor is receiving data, the result will look like this:

By default, toplist include 100 entries. So, positions 1-99 are shown individually, and positions 100 on wards are summarized into "other".

If you have a lot of "other" and you'd like to see more detail, then increase the 100 entries, to say, 150. Or you could shorten the time period that this top list covers.

Where? channel settings for that toplist Go through the settings page Sampling is a good idea!

Custom channels in a netflow sensor

Custom netflow sensors

Same types of notification triggers possible: state, speed or volume

What gets saved to disk? Only what remains after processing the filters and the toplists. Only save what was in the toplists

An aside: good blog article about collecting netflow from the virtual switches inside VMWare

PACKET SNIFFER SENSOR Functionality cannot be compared to wireshark. Wireshark good for detailed analysis and debugging. PRTG good for collecting historical data.

Packet Sniffer results are very similar to the netflow sensor - main difference is how PRTG gets the data. With the flow sensors, your switches are generating data about the flows and then sending the results to PRTG

With PRTG, we have to sniff all the traffic, and then create the flow data ourselves. This is why the packet sniffer is very heavy for PRTG. Since PRTG can only sniff the traffic that's going through PRTG, you need to somehow get all the traffic to PRTG so we can sniff it.

Usually, this means you need to mirror or span the traffic from your switches to the PRTG server. If you want to use the packet sniffer with multiple switches, then you'll need additional hardware that can aggregate all the mirrored traffic into a single stream.

Please be very careful with how much traffic you send to the PRTG server. Please keep in mind that your switches are multi-port switches, with specialized hardware for traffic switching. But your PRTG server is only a windows server running software.

As a rule of thumb, the PRTG packet sniffer can handle about 100Mb of traffic. That's not very much when you consider how much traffic just one of your switches can handle.

So you can see that the PRTG packet sniffer is really meant for use in very small networks, that are too small to have flow-capable switches.

But let's look at a packet sniffer sensor in detail. Same toplists as with flow sensor Similar settings, similar notification triggers Similar custom channels There are also custom packet sniffers, analog to the custom netflow sensors, where you can define the channels yourself. What do we save: Similar to netflow, only save the toplists.


Both are fairly heavy for the switch and for PRTG. Netflow is easier on PRTG than packet sniffing Recommend max 50 netflow sensors per probe. If you have 2000 flows/second, which would be typical mixed 1Gbit traffic, then PRTG can handle around 50 netflow sensors.
If you need significanty more flow sensors than that, or if you have well over 2000 flows/second, then you should consider a more specialized netflow tool than PRTG.

Who's hogging my bandwidth? We can now see this in the toplists. Or, if you're interested in one specific IP address, you can use filters in the netflow or packet sniffer sensors to see traffic to/from that one IP address. Am I getting the bandwidth I'm paying for? Filling the line for the test blocks the line for real traffic need to measure at exactly the two endpoints, or you're indirectly measuring the rest of the infrastructure too. There may also be caches or WAN optimizers in between that affect the results Recommendation: use a sensor that downloads a largeish file (eg 500K) every 5 minutes, and measure how long it takes to download the file. Let this run for a while and check the results. Remember there will be a bit of jitter.

For better results, download, say, 3 files from 3 different locations, so you can compare results. And then you need to do some math: If you have a 4 Meg line, downloading a 500K file should take 1000ms, or 1 second But we have a slightly easier option for you. There's a sensor called the HTTP Full Web Page sensor that measures the download time for an entire webpage. You could set this up to download a large page with a known size.

Possible questions for the end: How to set up netflow sensors in a PRTG cluster? Put the sensors on a remote probe, so the RP can send toplists to all cluster nodes. At the device level (not sensor level), under Settings, way down under "Channel Unit Configuration"

Flexible netflow: only partial support for flexible netflow. We analyse only the standard fields - we do not analyse custom defined fields.

Host sFlow: no support for host sFlow. What is host sFlow? an open source project to generate netflow flows on end hosts such as servers.

Netflow lite: not tested. We don't have any devices in house that can send netflow lite. Probably no support.

If you're already running flow or packet sniffer sensors and have performance problems, try. Sampling on the switch (and correspondingly on PRTG). Move the sensors onto remote probes to offload the core server. Choose shorting polling intervals (because the toplists are stored in RAM while they're being created). Avoid complicated toplists, especially when you have very diverse traffic.

Tips for setting up flow sensors: FIRST with no filters! Check that flows are even arriving before setting up any filters If no flows arriving: could be 3 reasons: 1) switch not configured to send flows correctly 2) something between switch and PRTG server is blocking flows 3) PRTG server or sensor not receiving the flows properly Tools to try: Wireshark, Paessler NetFlow Generator. Paessler netflow generator sends fake data.