PRTG – Flow Monitoring

I have a new favourite toy at work. It hasn’t quite overtaken ConfigMgr as my absolute favourite but it’s close. I’m having fun with it though, and that’s the main thing. Apart from, you know, its entire business function, but that’s minor, right? My new toy is called PRTG which is written by a company called Paessler. It’s a monitoring platform in the same vein as System Center Operations Manager, SolarWinds, Nagios, WhatsUp Gold et al.

One of the neat things that PRTG does is sFlow monitoring, where the platform takes an sFlow from a switch and presents a nice graphical analysis of the data it receives. sFlow is an analysis protocol which takes a sample of the traffic that your switch is processing, logs its source, destination, the port that it’s using and the size of the packet then passes it on to a collector. The collector then does clever things with it. This is a screenshot of the data being collected about one of our busier core switches:

However, the first time I installed one of these sensors on PRTG, I was quite disappointed with it. The amount of channels with different types of protocols that it was showing was minimal; it could distinguish HTTP(S), FTP, a couple of different email protocols, some IM protocols, NETBIOS, DNS, DHCP, SSH, RDP and Citrix. Everything else was lumped under “Various”.

The screenshot above is a “Custom sFlow Sensor”, where you can define your own channels for different protocols. That’s great for a one off, or where you want to look for specific types of traffic, but doing that for multiple sensors is rather labourious. It would be better if all of the channels you want are in the default sFlow sensor.

Luckily, PRTG provide you with a method of doing that. In the “%programfiles(x86)%\PRTG Network Monitor” folder, there is a file called FlowRules.osr, which is an XML file with the rules definition in it. Copy that file into one called CustomFlowRules.osr and open it in your favourite text editor (I like Notepad++ and Programmers Notepad. Now, in theory you could edit the FlowRules.osr file instead of the custom one, but Paessler recommend against it as your hard work will most likely be undone when PRTG gets updated.

You’ll see that the file is bog standard XML:

The structure is simple enough. The root element is called Groups. Underneath that, there is another element called Group, in which you’re supposed to group different types of channel together, so you could have a “File Services” Group with SMB, NFS and AppleTalk in it for example. You need to give the group a unique numerical ID and a name. There are a couple of attributes in Group element:

• Caption – A display name for the group (e.g. “File Access”)
• Help – A more detailed description of the group (e.g. “These protocols are used for accessing files on servers”)
• DefaultValue – This attribute tells PRTG whether to show all of the protocols in the group as one channel, to show each of the protocols in the group as their own channel or hide the group entirely. Values are:
  • 0 – Hide group entirely
  • 1 – Group protocols in one channel
  • 2 – Show all protocols as separate channels

You then define the channels for the protocols with the Channels and Channel elements. Each channel needs a separate element with a unique ID and name. In the Channel element, there’s an attribute called Rule where you define what the channel is looking for, so for SMB you would put:

There is full documentation on the filter rules at the PRTG website

Anyway, you can see from that file above that it’s rather limited. With that, the vast majority of traffic that passes my switches was lumped under “Various”, which ain’t especially helpful. I suspect PRTG put such a limited file in there because sFlow monitoring is rather computationally expensive and the more filters and rules it has to process, the harder it has to work. That said, there’s no reason why you shouldn’t try and push these things!

This is my CustomFlowRules.osr file:

I’ve done a few things here. I’ve renumbered the group and channel IDs as the ones in the default ones were tricky to keep track of. I’ve changed some of the groupings, Citrix no longer has a group to itself and has been put under Remote Control. I’ve added services like IPSEC, SMB, SIP, Kerberos, various streaming protocols for CCTV and more. It’s a lot more useful now.

One other interesting thing to take note of – when you send flows from multiple switches to the same collector, you have to be careful to set up your sensor properly, namely the Sender IP field. If you don’t the sensor will display data from all of the flows which are being sent to that collector. That in itself is an interesting exercise (In these lockdown times, the CCTV system by far the heaviest user of the network, followed by SMB, HTTP(S) and IPSEC) but might not what you’re trying to achieve.