Complete Network Analyzer

Q: Does PRTG support IPv6?

Yes. Most sensor types work with IPv6. SNMP polling, Ping, and flow sensors included. Device polling via SNMP supports v1, v2c, and v3. One exception worth knowing: the Cisco IP SLA sensor is IPv4 only. If VoIP monitoring on your network relies on Cisco IP SLA, that sensor won't cover IPv6-only paths.

Monitor and troubleshoot your network traffic across protocols, devices, and locations from one platform.

Free download

PRODUCT OVERVIEW

What Does a Network Analyzer Actually Need to Cover to Be Useful in Practice?

A network analyzer answers three core questions: who is talking, what is consuming bandwidth, and where things are slowing down. The method depends on the environment. Some deployments rely on flow exports from routers and switches. Others need packet header inspection on local adapters, SNMP polling, or active probes like ping and DNS checks. Most real environments need more than one of these, because each method shows you something the others do not.

Paessler PRTG supports all of them from a single platform. Flow-based traffic breakdowns, interface-level device health, and availability checks share one interface, one alerting framework, and one historical data set. NetFlow, sFlow, IPFIX, jFlow, SNMP, Packet Sniffer, WMI. The full list of supported methods is further down the page.

Download PRTG Trial

PRTG is compatible with all major vendors, products, and systems

From Traffic Analysis to Multi-Site Visibility: What PRTG Covers

Pinpoint Bandwidth Consumers Across Your Network

PRTG picks up flow exports from your routers and switches and breaks traffic into Top Talkers, Top Connections, and Top Protocols views automatically. No manual log digging across multiple devices. When you need to identify which device, application, or IP address is driving utilization, the data is already there.

Traffic breaks down by IP address, protocol, and connection as flow data comes in. Real time. Top Talkers, Top Connections, Top Protocols.
NetFlow v5/v9, sFlow, IPFIX, jFlow: pick whichever your devices export. Custom channel definitions are available per sensor if the defaults don't fit.
From a user complaint to the data you need: minutes, not hours

Measure VoIP Quality With Objective Per-Path Data

Objective VoIP quality data makes escalations straightforward. PRTG's Cisco IP SLA sensor via SNMP and QoS Round Trip / One Way sensors give you per-path MOS scores, jitter readings, RTT, and packet loss, timestamped and stored. That gives you the evidence to show whether a quality issue sits on your network or the provider's side.

Note: Cisco IP SLA sensor supports IPv4 only. QoS (Quality of Service) Round Trip and One Way sensors require a PRTG probe at each measured endpoint.

Per-path VoIP metrics: MOS score, average/min/max jitter, and RTT measured per call path. Each path is measured separately, not averaged across the network
Timestamped, per-path data gives you objective evidence to present to management or the provider
Cisco IP SLA sensor via SNMP for Cisco devices; the SNMP Cisco CBQoS sensor adds QoS policy visibility

Back Your Capacity Requests With Months of Traffic Data

Traffic history turns capacity conversations into data-backed decisions. PRTG stores sensor data continuously across all monitored interfaces, with historical reports available per sensor for any time range, from one day to six months or more, delivered automatically on whatever schedule you configure.

Historical traffic data per interface: bandwidth trends over days, weeks, or months, not just current utilization
Reports can run automatically and go to whoever needs them, on whatever schedule they need
Show traffic growth trends and consistently overloaded interfaces instead of estimates. That's what gets a capacity request approved.

See Why IT Professionals Trust PRTG

Start monitoring your infrastructure in minutes. No professional services, no complex configuration, no risk.

Free download

PRODUCT OVERVIEW

One Central View Across All Your Remote Sites

PRTG remote probes give distributed environments consistent traffic visibility at every site without standing up separate tools at each location. The classic probe runs on Windows 10+; the multi-platform version covers Debian, Ubuntu, and RHEL. Either way, traffic data and local device metrics feed back to your central PRTG core server across firewalls and NAT. If you're running multiple independent PRTG instances, PRTG MultiBoard (available with PRTG Enterprise Monitor) pulls them into one view.

Note: The multi-platform probe supports core monitoring functions. Some sensor types available on the classic Windows probe are not currently supported on the Linux version.

A lightweight probe at each remote site feeds data back to your central PRTG core server, across firewalls and NAT
Classic Windows probe (Windows 10+) or multi-platform Linux probe (Debian, Ubuntu, RHEL), depending on what's running at each site
PRTG MultiBoard (available with PRTG Enterprise Monitor) connects multiple independent PRTG servers in one view. No need to log into each one separately.

Flow Analysis, SNMP, Alerting, and Reporting in One Platform

PRTG covers flow-based traffic analysis, SNMP device monitoring, availability checks, alerting, and reporting in one platform with one interface and one shared data set. All sensor data feeds the same alerting framework, so during troubleshooting you work from a single context rather than switching between tools to piece together what happened.

Flow analysis, packet inspection, SNMP polling, availability checks, and alerting in a single tool. No integration work between functions
All sensor data lives in one interface: flow, SNMP, VoIP, Ping. It all feeds the same alerting framework. During an incident, you're not toggling between tabs
PRTG's API lets you connect to other tools in your environment where needed
Sensor-count-based licensing with no separate module fees for alerting, reporting, or dashboards

How PRTG Analyzes Network Traffic

There's no single way to monitor network traffic. PRTG runs several methods in parallel because each one tells you something the others don't. Here's how each works.

VoIP and QoS

If your Cisco devices are already running IP SLA probes, they're already collecting quality data. The Cisco IP SLA sensor connects via SNMP and reads it out: average jitter, min/max latency, RTT, MOS, ICPIF. This sensor supports IPv4 only.

The QoS (Quality of Service) Round Trip sensor sends a series of UDP test packets between two PRTG probe systems and measures jitter, RTT, packet delay variation, MOS, and packet integrity, including packets that are corrupted, duplicated, lost, or arrive out of sequence. The QoS (Quality of Service) One Way sensor does the same for unidirectional path measurement. Both sensors require a PRTG probe at each endpoint.

Packet Traffic Classification

The Packet Sniffer sensor monitors headers of data packets passing a local network adapter. Headers only, not payload content. Traffic is classified into predefined protocol categories: infrastructure traffic (DHCP, DNS, ICMP, SNMP), NetBIOS, Citrix, and other protocols. The Packet Sniffer (Custom) sensor allows user-defined channel definitions for more specific classification.

This sensor has a very high performance impact. Use it selectively, and prefer flow sensors where routers or switches can export flow data. The Packet Sniffer sensor is most useful for local adapter-level visibility in segments where flow export isn't available.

SNMP Interface Monitoring

PRTG polls routers and switches directly via SNMP v1, v2c, or v3. What comes back: interface utilization, error rates, discards, operational status. This runs alongside flow collection, not instead of it. Flow data tells you what the traffic is and where it's going. SNMP tells you the state of the device carrying it. Interface load, error counts, discard rates. Both IPv4 and IPv6 device polling are supported.

Connectivity and Availability

Ping v2 sends ICMP echo requests to a target and reports back response time, packet loss, and round-trip time across min/max/average readings. Port availability, DNS resolution, and traceroute-based path analysis each run as their own dedicated sensors. These give you the availability baseline beneath traffic analysis: confirmation that devices are reachable and paths are functioning before you interpret flow or SNMP data.

Traffic Threshold Alerting

Each sensor channel gets its own warning and critical thresholds. Set 70% interface utilization as a warning and 90% as critical, with different notification recipients at each level if you need that. Notifications go out via email, SMS, push, or webhook. Flow, SNMP, Ping, VoIP quality. It all routes through the same alerting framework. Escalation routing directs alerts to the right person or team based on threshold level or device group.

free downLoad

Monitoring With and Without PRTG

FEATURE	Without PRTG Without PRTG	With PRTG With PRTG
Identify top bandwidth consumers	Without PRTG Manual log review across multiple devices	With PRTG Top Talkers view built into flow sensor data
VoIP path quality data	Without PRTG None, or a separate dedicated QoS tool	With PRTG Built-in Cisco IP SLA sensor + QoS (Quality of Service) Round Trip sensor
Historical traffic reports	Without PRTG Manual data export and spreadsheet assembly	With PRTG Scheduled, automated reports per interface
Multi-site visibility	Without PRTG Separate tool per site, or none	With PRTG Remote probes feeding one central dashboard
Traffic threshold alerts	Without PRTG Manual threshold configuration in firewall only	With PRTG Per-sensor alerting with escalation and routing

free downLoad

“I would recommend PRTG because it has helped us significantly improve service uptime by highlighting important alerts that would otherwise result in a system failure or service disruption if action was not taken. Thanks to PRTG, we can ensure that The Ritz London’s network and IT systems are five-star, just like the hotel.”

Richard Isted, IT Manager

The Ritz London

”GESAC increasingly focuses on innovation to improve the quality of services offered and the experience of passengers handled every day by Naples Airport. Thanks to PRTG, we finally have unified, automatic, and continuous monitoring of the airport network and can guarantee quick and timely interventions.”

Domenico Ciervo, GESAC ICT Manager

Naples International Airport

”As an international company, PRTG is ideal for us. If something went down half way across the world, we wouldn’t be woken up – we can rely on PRTG to identify the problem and alert us before it occurs – enabling the right person, in the right time zone to resolve the problem. At the end of the day, if we’re to provide an internal network experience for our employees that meets expectations, we need a tool like PRTG to be successful.”

Barry Kelly, Systems Engineer

Skyscanner

Paessler PRTG Network Monitor licenses & pricing

Choose the PRTG Network Monitor subscription that's best for you.

License Name	Price	License Details	Get started	Pricing Details
PRTG 500	^$200	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 50 devices
PRTG 1000	^$358	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 100 devices
PRTG 2500	^$742	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 250 devices
PRTG 5000	^$1,300	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 500 devices
PRTG 10000	^$1,642	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 1000 devices

Over 100,000 Customers Worldwide Love Paessler

Network Analyzer: Frequently Asked Questions

What is a network analyzer?

A network analyzer captures traffic data on a computer network and tells you what's happening on it. Which devices are talking, what's consuming bandwidth, and whether network parameters like latency or packet loss are creeping out of range. How network analysis works depends on the tool: some rely on flow exports from routers and switches (NetFlow, sFlow, IPFIX), some use packet header inspection on a local adapter, some poll network devices directly via SNMP. Most real deployments use more than one of these. The point is giving IT teams enough data to troubleshoot problems, make better capacity calls, and not find out about issues from a user ticket.

Does PRTG support IPv6?

Yes. Most sensor types work with IPv6. SNMP polling, Ping, flow sensors included. Device polling via SNMP supports v1, v2c, and v3.

One exception worth knowing: the Cisco IP SLA sensor is IPv4 only. If VoIP monitoring on your network relies on Cisco IP SLA, that sensor won't cover IPv6-only paths.

Can PRTG monitor WiFi networks?

PRTG monitors WiFi access points and connected devices via SNMP. That means availability status, traffic on WiFi interfaces, and connected device counts on access points that actually expose this data. Flow data from traffic passing through WiFi segments is also supported, handled the same way as wired LAN.

What isn't covered: RF spectrum analysis and signal strength mapping. Interference detection falls outside this too. Those need dedicated wireless tools. What PRTG does here is infrastructure monitoring: device up/down and traffic data, not wireless signal analysis.

What protocols does PRTG's network analyzer support?

On the flow side: NetFlow v5/v9, sFlow, IPFIX, jFlow. Device polling runs via SNMP v1/v2c/v3 and WMI. The Packet Sniffer sensor handles header-based local traffic classification. Connectivity monitoring has its own set of sensors covering Ping/ICMP, open port checks, DNS, traceroute, and SSH. Each runs as a separate sensor type.

If your environment includes OT and IoT alongside IT, PRTG also supports OPC UA, MQTT, and Modbus. Useful if you're monitoring industrial or mixed IT/OT networks from one platform.

Is PRTG open-source?

No. PRTG is a commercial product. There's a time-limited free trial with full functionality. There's also a permanent free tier capped at 100 sensors, which is enough for smaller environments or for actually testing the platform before committing to a license.

Open-source tools give you more flexibility at the protocol and scripting level. What that flexibility costs is setup time and the integration work of connecting components that weren't built to talk to each other. For teams that need broad monitoring coverage without that overhead, PRTG is faster to get running. One interface, everything included.