Clicky

PRTG | Network Monitoring Sensors

PRTG

Network Monitoring

PRTG Network Monitoring Sensors

Show Network Sensors
Overview
This is a partial list of PRTG sensors that can be used for network monitoring.

SNMP Traffic - Use to display live total traffic, traffic in, traffic out and optionally errors. Great way to detect how "busy" a circuit is.
Ping - Used to detect network latency (delay) to a particular destination address. Great way to determine how responsive a circuit is based upon a single or multiple destination address tests. Yes, ping isn't a perfect way.
Jitter - Loosely stated the variance of ping latency, important metric for phone calls (audio).
http - Used to detect web site availability and/or responsiveness.
http advanced - Good way to detect download bandwidth, use with discretion.
hops/traceroute - Good way to detect routing changes that impact site responsiveness.
SNMP RMON - Used to detect part statistics, see sensor for more information.
Flow data - Supports Netflow (Cisco) and SFlow (Sampled Flow data). Great way to look at current or historical top talking IP addresses and/or protocols.
Traffic
The SNMP Traffic sensor monitors traffic on a device using Simple Network Management Protocol (SNMP). You can create it on a device that provides traffic data, one traffic sensor for each individual port.
It can show the following:
  • Traffic in
  • Traffic out
  • Traffic total
You can also add additional channels:
  • Errors in and out
  • Discards in and out
  • Unicast packets in and out
  • Non unicast packets in and out
  • Multicast packets in and out
  • Broadcast packets in and out
  • Unknown protocols
Which channels the sensor actually shows might depend on the monitored device and the sensor setup.
snmp_traffic_zoom66

SNMP Traffic Sensor

Click here to enlarge: http://media.paessler.com/prtg-screenshots/snmp_traffic.png

RMON
The SNMP RMON sensor monitors traffic on a device using the Remote Monitoring (RMON) standard via Simple Network Management Protocol (SNMP). You can create it on an SNMP compatible device that provides traffic data via RMON. Depending on the data returned by your device, traffic data for each port can be displayed in different channels, allowing detailed analysis. If available, the sensor queries 64-bit counters.
For each port, the sensor can show, for example:
  • Transmitted kbit/s
  • Packets (#/s)
  • Broadcast Packets (#/s)
  • Multicast Packets (#/s)
  • CRC Errors (#/s)
  • Undersize Packets (#/s)
  • Oversize Packets (#/s)
  • Fragments (#/s)
  • Jabbers (#/s)
  • Collisions (#/s)
  • Packets <= 64 Byte (#/s)
  • Packets 65 - 127 Bytes (#/s)
  • Packets 128 - 255 Bytes (#/s)
  • Packets 256 - 511 Bytes (#/s)
  • Packets 512 - 1023 Bytes (#/s)
  • Packets 1024 - 1518 Bytes (#/s)
  • Drop Events (#/s)
     
Which channels the sensor actually shows might depend on the monitored device and the sensor setup.  
snmp_rmon_zoom66

SNMP RMON Sensor

Click here to enlarge: http://media.paessler.com/prtg-screenshots/snmp_rmon.png

Flow
The NetFlow V9 sensor receives traffic data from a NetFlow V9 compatible device and shows the traffic by type. Please make sure the sensor matches the NetFlow version your device is exporting! There are several filter options available to divide traffic into different channels.
This sensor can show the following traffic types in kbit per second:
  • Chat (IRC, AIM)
  • Citrix
  • FTP/P2P (file transfer)
  • Infrastructure (network services: DHCP, DNS, Ident, ICMP, SNMP)
  • Mail (mail traffic: IMAP, POP3, SMTP)
  • NetBIOS
  • Remote control (RDP, SSH, Telnet, VNC)
  • WWW (web traffic: HTTP, HTTPS)
  • Total traffic
  • Other protocols (other UDP and TCP traffic)
Which channels the sensor actually shows might depend on the monitored device and the sensor setup.
netflow_v9_zoom63

NetFlow V9 Sensor

Click here to enlarge: http://media.paessler.com/prtg-screenshots/netflow_v9.png

Ping
The Ping sensor sends an Internet Control Message Protocol (ICMP) echo request ("Ping") from the computer running the probe to the device it is created on to monitor the availability of a device. Default is 5 pings per scanning interval.
It can show the following:
  • Ping time
  • Minimum ping time when using more than one ping per interval
  • Maximum ping time when using more than one ping per interval
  • Packet loss in percent when using more than one ping per interval
     
ping_zoom75

Ping Sensor

Click here to enlarge: http://media.paessler.com/prtg-screenshots/ping.png

Jitter
The Ping Jitter sensor sends a series of  Internet Control Message Protocol (ICMP) echo requests ("Pings") to the given URI to determine the statistical jitter.
This sensor shows the following:
  • Statistical jitter value
  • Execution time
     
The Real Time Jitter value is updated every time a packet is received using the formula described in RFC 1889:
Jitter = Jitter + ( abs( ElapsedTime – OldElapsedTime ) – Jitter ) / 16
The Statistical Jitter value is calculated on the first x packets received using the statistical variance formula:
Jitter Statistical = SquareRootOf( SumOf( ( ElapsedTime[i] – Average) ^ 2 ) / ( ReceivedPacketCount – 1 ) )
 
ping_jitter_zoom66

Ping Jitter Sensor

Click here to enlarge: http://media.paessler.com/prtg-screenshots/ping_jitter.png

Other
Other sensors:

QoS - Quality of Service
Traceroute - To determine hop count to a destination
http advanced - To determine download bandwidth (use with caution)
Syslog receiver - Not to replace syslog, but log for existence or not of certain messages
Other customer SNMP:
- Firewall examples: Sessions
Map
Sample of a custom PRTG map (dashboard) showing some sensors.
prtg-map

PRTG Real World Troubleshooting

Show Example
This example shows a combination of items. It starts with an example of a circuit use notification setting and then some investigative work. This was cobbled together from a couple different samples to protect the innocent, but the general process is an exactly what I do to investigate abnormal traffic and how PRTG helps immensely to alert and assist in the process.
PRTG - Proactive Alert
Below is an example of a proactive traffic threshold alert setting. This will send an Email (or other) notification that the circuit has been busy for a period of time. That's the first clue that something unusual might be happening.

NOTE: While not shown, I could have additionally used a traffic chart to visually confirm the traffic spike and known the duration.

Result: From this we know that the circuit was busy for some period of time. We know the date/time, but not much else. Further investigation is warranted, but I prefer the system telling me versus getting a user complaint.
prtg traffic alert
Using Flow Data
Now that we know when, we'll use flow data to determine what devices and basic protocol information.

Flow data can show the source/destination IP addresses involved as well as the protocol. It's enough to potentially resolve the investigation. However, sometimes we need more.

Result: From this we know what type of protocol was involved and while not shown on the sample we would also know the source/destination address. That's good, but we don't yet know who as in user and we don't know a lot about the protocol.

NOTE: Network flow sensors are included with PRTG. You do need devices that can provide flow data to PRTG or use a span/mirror port.
Show Flow Data
PRTG flow example
Using a Next Gen Firewall - Part 1
The previous data got me curious to know more. In this case we're showing the results from a next generation firewall to show more information.

NOTE: While PRTG provided the bread crumbs, we're using a next generation firewall to get more information beyond general ip address, protocol and date/time. At this point, we're looking at internal tools to further compliment what PRTG has alerted us to.

Result: This is good, we have confirmation now on the firewall of the observed traffic. I'm starting to feel relieved as now I know it was an apple update that occurred on one of my servers during the early morning hours.
Show NextGen FW data
Nextgen-Firewall-1
Using a Next Gen Firewall - Part 2
I feel relatively confident, but I want more data, so this confirms now the application, source and destination address (along with countries). Since this was a server versus a user, the source user isn't known, but isn't applicable.

I can now feel confident this was legitimate traffic.

We went from getting an abnormal traffic alert to learning what device was involved, when it was involved, what application generated it along with where it went.

We can now close this incident.
Show NextGen FW data
Nextgen-firewall-2
© 2017 Altaware, Inc. All rights reserved. | Cyber security reseller/VAR Orange County, CA | 866-833-4070

PRTG | Network Monitoring Sensors