If your network only gets attention when something breaks, you need network monitoring. It means watching devices, links and services continuously, so problems show up in your data before users report them.
| Item | Value |
|---|---|
| SNMP requests arrive at | UDP port 161 |
| SNMP trap messages arrive at | UDP port 162 |
| Message length an implementation need not exceed accepting | 484 octets |
| Original SNMP specification (RFC 1157) | May 1990 |
| SNMP management architecture (RFC 3411) | December 2002 |
These figures come from RFC 1157 and RFC 3411. Standards get updated, so check the source before you rely on them.
What network monitoring actually is
Network monitoring is the routine collection and review of data about the health of your network. A monitoring system asks devices how they are doing, records the answers, compares them with what you expect and tells a person when something drifts.
The goal is simple: know about trouble before your users do. A good setup also answers harder questions, such as whether a slow application is a network issue at all, or whether a link will run out of capacity next quarter.
Monitoring is not the same as management. Management changes things: configuring devices, pushing updates, provisioning ports. Monitoring observes. In practice the two overlap, and many products do both, which is why the choice of network management software shapes what monitoring you can do.
What you should watch
Start with what you depend on. A small office may care about its internet link, a switch and a Wi-Fi controller. A larger site adds routers, firewalls, servers, storage and cloud connections.
Most teams end up with a layered list:
- Availability: is the device or service reachable at all?
- Performance: how fast and how consistently does traffic move?
- Capacity: how full are links, CPU, memory and disks?
- Errors: interface errors, discards and retransmissions that hint at faulty cables or misconfiguration.
- Environment: temperature, fans and power supplies on network hardware.
- Change: configuration differences, new devices and topology shifts.
The specific measurements behind these categories are covered in our guide to network monitoring metrics. For now, remember that a small set of well-chosen measurements beats a huge set that nobody reads.
How data is collected
There is no single method. Each technique answers a different question, and mature setups combine several.
Polling with SNMP
The most common method is polling. A monitoring server asks each device for values at a fixed interval, and the device answers from its own counters. The protocol for this is covered in our SNMP hub.
The SNMPv1 specification, RFC 1157, was published in May 1990. It says a protocol entity receives messages at UDP port 161, apart from those that report traps. The later architecture document, RFC 3411, from December 2002, describes an engine with a message processing subsystem, a security subsystem and an access control subsystem.
The practical lesson: polling is simple and universal, but your poll interval sets how fast you can notice a change. A transient problem can be missed if it leaves no persistent counter or event record.
Traps and notifications
Devices can also speak first. In SNMP, a trap is an unsolicited message sent when something notable happens, such as a link going down. RFC 1157 states that messages reporting traps should be received on UDP port 162.
Traps give you faster notice than polling. They are not a replacement for it, because a lost trap is never retried by default, so you would never learn it was missed. Use traps as a fast signal and polling as the safety net.
Flow data, logs and active tests
Flow records summarise who talked to whom, over which ports and how much. They are the main way to find out which application or host is filling a link, and they feed bandwidth monitoring.
Syslog messages add the story behind an event, for example why an interface flapped. Active tests, such as pings and synthetic transactions, measure what a user would actually experience. They catch problems that device counters never admit to.
Passive versus active monitoring
It helps to separate two ideas. Passive monitoring reads what the network is already doing: counters, flow records, logs and mirrored traffic. It adds almost no load and shows real usage.
Active monitoring generates test traffic on purpose. It tells you about paths and services even when nobody is using them, for example at night. The cost is a small amount of extra traffic and some setup effort.
A reasonable pattern is passive collection everywhere and active tests for the few paths that matter most: your internet edge, your key branch links and your critical applications.
Turning raw data into insight
Collecting numbers is the easy part. The value comes from three habits that you can start with any tool.
- Establish what normal looks like. Record a network baseline over a representative period, including busy and quiet times.
- Compare against it. A link at high utilisation might be routine on Monday morning and alarming on Sunday night.
- Act on the difference. Decide in advance who looks at which signal and what they do about it.
Without a baseline, every alert is a guess. With one, you can tell a genuine change from a regular pattern.
The signals that matter most for users
Users do not complain about interface counters. They complain that calls sound robotic or pages hang. Three measurements map most closely to that experience.
- Network latency: how long a packet takes to get there and back.
- Jitter: how much that delay varies from packet to packet.
- Packet loss: the share of packets that never arrive.
Looking at all three together is the idea behind network performance monitoring, which focuses on how the network feels to its users rather than only whether devices are up.
Alerting without alert fatigue
An alert is a request for a human to stop what they are doing. Each one that turns out to be meaningless teaches people to ignore the next. Treat that trust as a limited resource.
Good practice, in brief:
- Alert on symptoms users would feel, and record causes as supporting detail.
- Require a condition to persist for a few polls before firing, which filters one-off blips.
- Use severity levels so that only urgent items wake someone.
- Suppress child alerts when a parent device is down. One failed switch should not produce a flood of messages about the devices behind it.
- Review noisy alerts regularly and fix or delete them.
The design of thresholds, escalation and notification channels is worth its own study; see network alerting for the details.
Using monitoring to find faults
When something does go wrong, monitoring history is your best evidence. It shows when the problem began, what else changed at that moment and whether it has happened before.
A typical sequence is to check availability first, then errors and utilisation on the affected path, then recent changes and logs. Narrowing the scope this way is the core of network troubleshooting, and it works far better when you already have historical data to compare with.
Keep notes after each incident. A short record of the symptom, the cause and the fix turns one outage into a lesson the whole team can reuse.
Choosing a monitoring approach
Tools range from free, community-built systems to commercial platforms and cloud services. Rather than comparing products, compare your own needs. This site is independent and does not endorse any product, so use the questions below as a checklist.
- Coverage: does it support the device types, protocols and cloud services you run?
- Scale: can it poll your whole estate at the interval you want?
- Discovery: can it find devices and map links automatically, or will you enter them by hand?
- Alerting: can you shape thresholds, dependencies and notification routes?
- History: how long does it keep data, and at what resolution?
- Effort: who will maintain it, and how much time can they spare?
Be wary of any tool that promises to need no tuning. Every network is different, and some tuning is the price of useful alerts.
Security and housekeeping for your monitoring system
A monitoring server holds credentials for nearly every device you own. Protect it accordingly.
The architecture in RFC 3411 puts security and access control in their own subsystems for a reason: reading a device’s data and changing it should not be the same permission. Where your devices support it, prefer the newer authenticated and encrypted SNMP options over community strings sent in clear text, and give the monitoring account read-only rights.
- Restrict which hosts may query devices, using access lists.
- Keep the monitoring software itself patched.
- Back up its configuration, since rebuilding thresholds from memory is painful.
- Prune old devices so that retired equipment does not trigger false alarms.
Monitoring different parts of the network
The same ideas apply everywhere, but each environment has its own quirks. Knowing them saves you from chasing false problems.
Switches and routers
Core devices are the backbone of your picture. Watch interface status, utilisation, error and discard counters, and device health such as CPU and memory. Errors on a single port often point to a bad cable or a duplex mismatch, which is easy to fix once you can see it.
Wireless networks
Wi-Fi problems are often invisible from the wired side. Track the number of connected clients per access point, signal quality, channel use and authentication failures. A crowded access point can feel like a slow internet link to the people connected to it.
Branch offices and WAN links
Remote sites depend on links you may not own. Active tests from the branch toward headquarters show what staff really experience, and they give you evidence when you need to raise a case with a service provider.
Servers and applications
Many network complaints are really application problems. Including server load and service checks in the same view lets you rule the network in or out quickly, instead of debating it in a meeting.
Cloud and virtual networks
Virtual networks often cannot be polled like physical switches. Cloud platforms usually expose their own metrics and logs, so plan to pull those into the same dashboards you use for on-site equipment.
Dashboards, reports and capacity planning
Dashboards serve people who need an answer in seconds. A good one shows overall status, the busiest links and the active alerts, and nothing more. If a panel never changes anyone’s decision, remove it.
Reports serve a different purpose. They show trends over weeks and months, which is how you spot a link that is slowly filling up. That early warning lets you plan an upgrade calmly instead of reacting to a slowdown.
Capacity planning is the main payoff of keeping history. If utilisation climbs steadily, you can estimate when it will become a problem and budget for it. Without history, you only learn about the limit when users complain.
Reports also help you communicate. Managers rarely care about interface counters, but they respond to a simple chart showing that a branch link has been saturated every afternoon for a month.
Common mistakes to avoid
Most monitoring projects stumble on the same few points. Watching for them early is cheaper than fixing them later.
- Monitoring everything at once. A flood of data and alerts buries the signals you need.
- Setting thresholds from guesses. Numbers taken from a blog post rarely fit your network. Use your own baseline.
- Ignoring the monitoring system itself. If the server fails silently, you have no monitoring and no warning about it. Arrange a simple outside check on the monitor.
- Relying only on polling. Short problems fall between polls, so add flow data or active tests for critical paths.
- Leaving alerts without owners. An alert nobody is responsible for will be ignored.
- Skipping documentation. Record what each alert means and what to do first, so the next person on call is not starting from nothing.
Each of these is a process problem rather than a tool problem. Even the best software cannot compensate for unclear ownership.
Keeping monitoring useful over time
A network that never changes does not exist. New sites, replaced switches and retired servers all alter what you should be watching. Build the review into normal change work: when equipment is added, it is added to monitoring in the same task.
Schedule a regular review of alerts. Look at which ones fired most often, which were acted on and which were ignored. The ignored ones are candidates for retuning or deletion, and the missing ones show gaps that an incident exposed.
Finally, test your alerts. Deliberately disconnecting a lab link or stopping a test service proves that the whole chain works, from detection through notification to the person who must respond. An alert path that has never been tested is only an assumption.
Who should look at the data
Monitoring only helps when someone reads it. Decide early who watches live status, who receives alerts and who reviews trends. In a small team these may be the same person, but the roles are still different jobs.
Live status needs quick, simple views and clear colours. Alert handling needs a defined route, including a backup when the first person is unavailable. Trend review needs time set aside, because nobody studies a long chart in the middle of an incident.
Share the data beyond the network team where it helps. Helpdesk staff who can see that a site link is down will stop opening duplicate tickets, and application owners who can see healthy network graphs will look for the cause elsewhere. That shared view shortens every investigation.
Agree on wording as well. If a term like “degraded” means different things to different people, alerts will cause arguments instead of action. A short glossary kept next to the dashboards solves most of that.
A simple plan to start
You do not need to monitor everything on day one. A staged approach works better and keeps the noise down.
- List your critical services and the devices and links they rely on.
- Monitor availability and basic utilisation for those items first.
- Add error counters and latency tests on the most important paths.
- Collect data for a few weeks to form a baseline before you set thresholds.
- Turn on alerts for a small number of symptoms, then expand slowly.
- Review the setup after each incident and each network change.
Treat the system as a living project. Networks change, and monitoring that is never updated slowly stops describing the network you really have.
Frequently asked questions
What is the difference between network monitoring and network management?
Show answer
Monitoring observes and reports on the state of the network. Management changes it, through configuration, provisioning and updates. Many products combine both.
Which ports does SNMP use?
Show answer
According to RFC 1157, requests are received at UDP port 161 and trap messages at UDP port 162. Firewalls between your monitoring server and devices must allow this traffic.
How often should devices be polled?
Show answer
It depends on how quickly you need to notice a change. Shorter intervals catch brief problems but create more load and more data, so use short intervals for critical links and longer ones for slow-changing items.
Do I need a baseline before setting alerts?
Show answer
You can start with simple up or down alerts straight away. For utilisation and performance thresholds, a baseline helps you avoid alerts on normal patterns.
Is passive or active monitoring better?
Show answer
Neither wins alone. Passive data shows real usage at little cost, and active tests show how paths and services behave even when quiet. Most networks benefit from both.
