As an ntopng developer, I often hear from users who are confused about the building blocks of network monitoring. Today, I’ll explain three fundamental concepts that will help you understand what your monitoring tools are actually showing you.
Introduction
If you’ve ever looked at ntopng’s flow reports and wondered “What exactly am I looking at?” or “Why does this tool show me different information than my packet capture?”, you’re not alone.
Network monitoring gives us two primary ways to observe traffic, each with its own strengths. Think of it like watching a city:
- Packet-based analysis is like following individual cars through the streets, recording every detail about each vehicle’s journey
- Flow-based analysis is like looking at traffic statistics—how many cars passed through, where they entered and exited, and what routes they took
Both are valuable, but they serve different purposes. Let’s dive into the details.
Part 1: What is a Flow Export? (NetFlow, IPFIX, sFlow)
Before we can understand what flows tell us, we need to understand what they are and how they’re created.
The Flow Concept
A flow is a sequence of packets sharing common characteristics that pass through a network device . In simple terms, it’s a conversation between two endpoints. When your laptop talks to a web server, all those packets back and forth form a single flow.
Network devices like routers and switches can be configured to export records of these flows to a collector like ntopng . This follows a simple architecture:
text
┌─────────┐ ┌──────────┐ ┌──────────┐ │ Exporter│────▶│ Collector│────▶│ Analyzer │ │(Router) │ │ (ntopng) │ │ (You) │ └─────────┘ └──────────┘ └──────────┘
The Three Main Flow Protocols
NetFlow
NetFlow was pioneered by Cisco and has become the de facto standard for flow export . It comes in several versions:
- NetFlow v5: The old reliable—fixed field format, widely supported, but no IPv6
- NetFlow v9: Template-based, flexible, supports IPv6
A NetFlow record typically contains :
- Source and destination IP addresses
- Source and destination ports
- IP protocol (TCP, UDP, ICMP, etc.)
- Packet and byte counts
- Start and end timestamps
- Interface information
- Next-hop IP addresses
IPFIX
IPFIX (IP Flow Information Export) is the IETF-standardized evolution of NetFlow v9 . Think of it as “NetFlow done right”—it uses the same template mechanism but with standardized field definitions that work across vendors .
The key advantage? Interoperability. An IPFIX export from a Juniper router looks the same as one from a Cisco router, making life much easier for collectors .
sFlow
sFlow takes a completely different approach. Instead of tracking complete flows, it uses statistical sampling . The device captures one out of every N packets (say, 1 in 1,000) and sends those samples to the collector .
This makes sFlow incredibly lightweight and scalable—perfect for high-speed networks where tracking every flow would overwhelm the device . The trade-off? You lose some precision, especially for small, short-lived flows .
| Feature | NetFlow v5 | NetFlow v9 | IPFIX | sFlow |
|---|---|---|---|---|
| Data model | Complete flows | Complete flows | Complete flows | Packet samples |
| IPv6 support | No | Yes | Yes | Yes |
| MAC addresses | No | Sometimes | Sometimes | Yes |
| Payload | No | No | No | Yes (headers) |
| Resource usage | Moderate | Moderate | Moderate | Very low |
Part 2: Next Hop, Input, and Output Interfaces Explained
Now let’s tackle the fields that often confuse newcomers. When you look at a flow record in ntopng, you’ll see references to “next hop,” “input interface,” and “output interface.” What do these actually mean?
Input and Output Interfaces
Every flow record includes two interface identifiers :
- Input Interface: The interface on the router where the packets entered
- Output Interface: The interface where the packets left
Think of a router as a train station. The input interface is the track the train arrives on; the output interface is the track it departs on. If packets are not routed or the interfaces is unknown, 0 is used as identifier.
┌─────────────────────┐
│ │
Packet ─┼─► Input Interface │
│ │
│ Router │
│ │
│ Output Interface ──┼─► Packet
│ │
└─────────────────────┘
These interface identifiers are typically SNMP interface indexes , which map to specific physical or logical interfaces on the device. In ntopng, we resolve these to human-readable names (like “GigabitEthernet0/1”) so you know exactly which link carried the traffic.
Why this matters: By tracking input and output interfaces, you can understand traffic paths through your network. If traffic enters on interface A and exits on interface B, you know exactly which links are being used .
Next Hop
The next hop field tells you the IP address of the next router the packet will be sent to . It’s like a signpost pointing to the next leg of the journey.
text
[Host A] ────► [Router 1] ────► [Router 2] ────► [Host B]
│ │
Next Hop = Next Hop =
Router 2 IP Host B IP
In this example, when Router 1 exports a flow for traffic from Host A to Host B, the next hop field would contain Router 2’s IP address .
Why this matters: Next hop information helps you understand routing paths and detect routing anomalies. If traffic suddenly starts taking a different path, you’ll see it in the next hop field .
Note that the next hop if filled by routers who have routing table visibility, whereas nProbe capturing packets and transforming them into flows might not have this information available hence the next hop and interface Ids might be empty.
Real-World Example
Let’s walk through a concrete example. Imagine a packet traveling from your laptop (192.168.1.100) to a web server (203.0.113.10):
- The packet enters your router on interface eth0 (connected to your LAN)
- The router looks up the destination in its routing table
- It determines the next hop is 203.0.113.1 (the ISP’s router)
- It forwards the packet out interface eth1 (connected to the internet)
The flow record exported by your router would include:
- Input interface:
eth0(where traffic entered) - Output interface:
eth1(where traffic left) - Next hop:
203.0.113.1(the next router along the path)
This tells you the complete forwarding decision made by your router .
Part 3: Packet-Based vs. Flow-Based Analysis
Now for the big question: what’s the difference between looking at packets versus looking at flows, and when should you use each?
Packet-Based Analysis: The Microscope
Packet-based analysis (also called packet capture or “packet sniffing”) involves capturing actual packets from the network . Tools like Wireshark or ntopng’s packet inspection capabilities work this way.
What you get:
- Complete packet contents (including payload data)
- Every single packet, in order
- Full protocol details and application data
The trade-offs:
- Massive storage requirements: Capturing everything on a 10 Gbps link generates over 100 TB per day
- Processing overhead: High CPU load on the monitoring system
- Privacy concerns: You’re capturing actual user data
Best for:
- Deep forensic analysis
- Application debugging
- Protocol development
- Short-term, targeted investigations
Flow-Based Analysis: The Telescope
Flow-based analysis looks at metadata about conversations rather than the actual packets . This is what ntopng does when receiving NetFlow, IPFIX, or sFlow data.
What you get:
- Summarized conversation records
- Who talked to whom, when, and how much
- Long-term historical data (weeks or months)
- Aggregated statistics
The trade-offs:
- No payload data: You can’t see what was said, only that a conversation happened
- Potential sampling errors: Especially with sFlow, small flows might be missed
- Delayed visibility: Flows are often exported after they complete
Best for:
- Capacity planning
- Security monitoring (detecting patterns)
- Long-term trend analysis
- High-speed network monitoring
Side-by-Side Comparison
Here’s how the two approaches stack up :
| Aspect | Packet-Based | Flow-Based |
|---|---|---|
| Data granularity | Every packet, full details | Summarized conversations |
| Storage needs | Massive (TB/day) | Moderate (GB/day) |
| Retention period | Hours or days | Weeks or months |
| Real-time capability | Good for immediate capture | Depends on export intervals |
| Privacy impact | High (captures content) | Low (metadata only) |
| Resource usage | High on collector | Distributed (device does work) |
| Best use case | Deep dive troubleshooting | Ongoing monitoring and trends |
The Hybrid Approach: Getting the Best of Both
In practice, most organizations use both approaches . Here’s a common strategy:
- Use flow monitoring everywhere for continuous visibility, capacity planning, and baseline establishment
- Deploy packet capture selectively on critical links or during incident investigation
- Correlate both sources when you need deeper insight into suspicious flows
At ntopng, we’ve designed our tools to support this hybrid model. You can receive flow exports from routers across your entire network while also performing deep packet inspection on specific interfaces when needed.
Conclusion: Choosing the Right Tool for the Job
Understanding the differences between flow-based and packet-based analysis helps you use ntopng more effectively:
- Use flow exports (NetFlow/IPFIX/sFlow) when you need broad visibility, long-term trends, and efficient monitoring of large networks
- Use packet inspection when you need deep application insight, forensic details, or to debug specific issues
- Pay attention to interface and next-hop fields—they tell you not just what happened, but where it happened in your network topology
Remember the telescope and microscope analogy: flows give you the big picture of your network galaxy, while packet captures let you examine individual stars. Both are essential tools in the network operator’s kit.
Enjoy !