PRTG & Troubleshooting
The following is an example of using a couple technologies working together to alert on a potential network problem and then investigating the problem source.
PRTG and Firewall Real World Troubleshooting
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 process sequence is exactly what I do to investigate abnormal traffic.
PRTG helps immensely to alert and assist in the process (coupled with historical charts). Additional detail is provided via a PAN Palo Alto Networks application aware firewall.
PRTG helps immensely to alert and assist in the process (coupled with historical charts). Additional detail is provided via a PAN Palo Alto Networks application aware firewall.
PRTG High Traffic 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.
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 NetFlow Reveal
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.
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.
PAN Firewall App Visibility
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.
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.
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.
Other PRTG Network Monitoring Sensors
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.
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.
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:
It can show the following:
- Traffic in
- Traffic out
- Traffic total
- 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
SNMP Traffic Sensor
Click here to enlarge: http://media.paessler.com/prtg-screenshots/snmp_traffic.png
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:
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)
SNMP RMON Sensor
Click here to enlarge: http://media.paessler.com/prtg-screenshots/snmp_rmon.png
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:
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)
NetFlow V9 Sensor
Click here to enlarge: http://media.paessler.com/prtg-screenshots/netflow_v9.png
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:
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 Sensor
Click here to enlarge: http://media.paessler.com/prtg-screenshots/ping.png
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:
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 ) )
This sensor shows the following:
- Statistical jitter value
- Execution time
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 Sensor
Click here to enlarge: http://media.paessler.com/prtg-screenshots/ping_jitter.png
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
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
Sample of a custom PRTG map (dashboard) showing some sensors.
About Us | Contact Us | Privacy Policy | EOL
© 2023 Altaware, Inc. | All rights reserved.
949-468-0020
CYBER SECURITY skills in ORANGE COUNTY, CA
Remote cyber security skills/services within the USA