Three protocols carry three different jobs: NTP gives every device the same clock, Syslog writes down what happened, and a Trap pushes the events worth acting on right now. Mix them up and the alarm list fills with noise while the log timestamps run out of order — the exact symptom of a monitoring system nobody trusts.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
Here is what each protocol guarantees, how to set log severity so it stays useful, which events deserve a Trap, and what a 100-device site actually costs in bandwidth.
Many projects fold these together, and the result is alerts arriving out of sequence, logs full of noise, and a management platform that stalls whenever a Trap burst arrives.
Syslog is specified in RFC 5424, with the earlier BSD format in RFC 3164. It defaults to UDP 514, and some devices use 601. What it carries is a text event with a severity level — whatever the device did, written down. It is a process record: delivery is not guaranteed, order is not guaranteed, and there is no acknowledgement.
SNMP Trap belongs to the SNMP framework (structure in RFC 3411, operations in RFC 3416), with UDP 162 as the default destination and 161 on the agent. Its role is event-driven notification, complementary to polling: a poll cannot see an event that occurred and cleared between two cycles, but a Trap can.
NTP is specified in RFC 5905 and runs on UDP 123. It produces no events at all; it supplies a time reference. That sounds like the least important of the three and is in fact the least optional: internal device clocks drift by 1–5 ppm, and 10 ppm means 0.86 seconds a day, or 26 seconds a month. When two devices disagree by tens of seconds, "the switch lost its link" and "the PLC threw an error" can no longer be put in order.
| Dimension | Syslog | SNMP Trap | NTP |
|---|---|---|---|
| Standard | RFC 5424 / RFC 3164 | RFC 3411 / 3416 | RFC 5905 |
| Transport and port | UDP 514 (or 601) | UDP 162 | UDP 123 |
| Core role | Record the process, retroactively readable | Push an event immediately | Provide one shared time base |
| Delivery acknowledged | No | No for Trap; yes for Inform | Not needed |
| Authentication and encryption | None by default | SNMPv3 supports both (RFC 3414) | Symmetric key authentication available |
| Typical volume | Large, scales with log level | Small, concentrated in bursts | Tiny, periodic sync |
| Key configuration | Server address, severity threshold, facility | Destination, community or user, Trap types | Server address, sync interval |
The relationship between them is simple: NTP supplies the coordinate, Syslog supplies the process, Trap supplies the trigger. Without NTP the other two cannot be assembled into a timeline; without Syslog a Trap can only say something broke, not what it turned into; without Trap a recovered fault is just a line in a log that someone has to go and find.
Syslog levels run from 0 to 7, with Emergency (0) the highest and Debug (7) the lowest. They usually go wrong in one of two directions on site: everything set to Debug, which multiplies log volume tenfold and drowns the useful entries; or only Error and above, which loses link flaps and similar non-fatal but cumulative events entirely.
A workable severity policy:
Emergency / Alert / Critical (0–2). Device unavailable, both power inputs failed, CPU temperature out of range. Alert in real time and write the log.
Error (3). Ports repeatedly going down, optical receive power out of range, PoE overload protection. Retain 180 days or more — industrial fault reviews often reach back half a year.
Warning (4). Link flapping, STP topology changes, address conflicts. Retain 90 days.
Notice (5). Configuration changes, user logins, reboots. These carry the most value in accountability and audit, so retain 180 days.
Info / Debug (6–7). Protocol message detail, module loading. Enable temporarily during commissioning only; left on permanently they visibly raise device CPU load and the log server's burden.
The other setting that must be configured is the facility code. Putting device-originated events and user-action events into different facilities lets the log server filter by source, so a diagnosis does not mean scrolling through hundreds of thousands of lines. A logging platform that never had facilities configured is roughly as useful as no platform at all.
A Trap earns its place by telling you the moment something happens. Ranked by priority for an industrial network:
Link up / down. The most basic and most useful class. Ring convergence, optical module ageing and a loose patch cord all announce themselves here first.
Optical module DDM out of range. Receive power, temperature or supply voltage over threshold. This is the key to predicting a failure rather than reacting to one, and it is worth far more than waiting for the link to drop.
Dual power supply loss. Most industrial devices take two feeds; losing one does not stop operation, but you still need to know.
PoE overload and port restart. PoE ports carrying cameras are the most likely source of this class.
CPU, memory or temperature out of range. Points at the device itself and feeds capacity planning.
Configuration change. Who changed what, and when — which only stands up in an audit when paired with an NTP timestamp.
Distinguish Trap from Inform. A Trap is fire-and-forget: it is lost when the network jitters or the platform is busy. An Inform waits for the peer to acknowledge, so it is more reliable and more resource-hungry. The practical split: critical events (power, temperature, stacking state) go out as Inform; ordinary events (link flap, login) go out as Trap, with Syslog filling in the record behind them.
For diagnosis, millisecond accuracy on a LAN is entirely sufficient; across a WAN, synchronisation is affected by jitter and lands in the 10–50 ms range. That is more than enough to align logs, whose timestamps are themselves usually at second granularity.
Be clear that NTP is not a "synchronisation clock". Some industrial applications need microsecond or sub-microsecond determinism — multi-axis motion control, synchronised sampling, phasor measurement in power protection — and that is the territory of IEEE 1588 PTP, which reaches sub-microsecond accuracy through hardware timestamping. NTP runs through the software stack and is three to four orders of magnitude less precise. The two solve different problems: PTP guarantees that actions happen at the same instant, NTP guarantees that the timeline can be reconstructed afterwards. In an industrial network they coexist without conflict.
One deployment rule: do not point several hundred devices straight at a public NTP source. Stand up a local NTP server (synchronised to a Stratum 2 or 3 public source), point every device at it, and use a sync interval of 64–1024 seconds. That reduces dependence on the internet and keeps the egress link from filling with NTP requests.
The scenario: 100 devices (60 industrial switches plus 40 OLT/ONU units), all reporting Syslog and Trap, each producing 500 log entries a day at 200 bytes on average.
Step 1 — log volume. 100 x 500 x 200 bytes = 10 MB per day, 3.65 GB a year. Ninety days is about 900 MB; 180 days is about 1.8 GB. One ordinary server with an SSD covers this comfortably; distributed storage is unnecessary.
Step 2 — average bandwidth. 10 MB per day / 86,400 seconds ≈ 116 bytes per second, or 0.93 kbit/s. Negligible on a gigabit network, so log upload is never a bandwidth burden.
Step 3 — burst bandwidth. If a power cut restarts all 100 devices at once and they report within 60 seconds, the burst is 100 x 500 x 200 bytes = 10 MB, roughly 1.33 Mbit/s instantaneous. Still small, but the log server must absorb thousands of writes a second — disk IOPS, not the network, is the limit.
Step 4 — Trap storm. During ring convergence or a link flap, 200 devices each sending two Traps (link down plus link up) inside one second is 400 x 300 bytes = 120 KB, about 0.96 Mbit/s. Bandwidth is fine, but the management platform has to process 400 alerts in a second. Without deduplication and suppression rules, the interface floods and the alert table swells until it means nothing.
Step 5 — the cost of NTP drift. Assume a 10 ppm clock with no synchronisation: 0.864 seconds a day, 26 seconds a month. If a diagnosis needs the order of "the PLC stopped" and "the switch dropped its link", and the two clocks differ by 26 seconds, that judgement is worthless. With NTP configured at millisecond accuracy on the LAN, the error in that ordering drops from seconds to milliseconds.
Step 6 — the return on alert suppression. Without suppression, one ring convergence produces 400 alerts; at three convergences a shift that is 1,200 a day, of which perhaps two actually need action (one root cause and one recovery). Adding a rule that merges alerts of the same type from the same device inside a 5-minute window reduces effective alerts from 1,200 to roughly 10, cutting the attention cost by two orders of magnitude. This is the part of the trio most often skipped and the one that pays best.
The snippet uses generic syntax to show the options and their order; it is not a real command line from any vendor.
; Step 1: configure NTP first so later log timestamps are usable ntp-service enable ntp-service unicast-server 10.0.0.10 ntp-service source-interface Vlanif1 ; Step 2: configure the Syslog server and the reporting level (notice and above) info-center enable info-center loghost 10.0.0.20 channel 2 info-center source default channel 2 log level notice ; Step 3: configure an SNMPv3 user (authentication plus encryption) instead of v2c snmp-agent snmp-agent sys-info version v3 snmp-agent usm-user v3 opsuser group opsgroup snmp-agent group v3 opsgroup privacy ; Step 4: set the Trap destination and the event types to report snmp-agent target-host trap address udp-domain 10.0.0.30 params securityname opsuser v3 privacy snmp-agent trap enable linkdown linkup power temperature
NTP has to come first: timestamps in uploaded logs come from the local clock, so configuring the log server before the time source leaves the historical timeline scrambled. For the severity threshold in step 2, start wide and tighten later — a week at notice during commissioning, then decide from the actual noise whether to narrow it, is safer than starting at error and missing key events.
| Risk | Symptom | Mitigation |
|---|---|---|
| Syslog over UDP loses packets | Critical logs missing during a network glitch, unrecoverable afterwards | Use Inform for critical events, or Syslog over TLS (RFC 5425) on TCP 6514 |
| Logs can be forged | No authentication; anyone can send fake logs to port 514 | Restrict source subnets at the log server; enable TLS and signing for sensitive projects |
| Trap community string in clear text | An SNMPv2c community is plaintext in the packet, effectively a password | Move to SNMPv3 authentication plus encryption (RFC 3414) |
| Timezone confusion in timestamps | Devices on local time, server on UTC, cross-device comparison off by 8 hours | Store everything in UTC, convert for display only |
| Log volume inflation | Debug left on or a storm flooding the screen fills the disk | Retain by severity, and add alert suppression and deduplication |
| NTP source misconfigured | Pointed at an unreachable or wrong public source, whole site out of time | Run NTP internally; devices point only at internal addresses |
One engineering detail is worth watching: the log server is itself a device that needs monitoring. A platform that has crashed or filled its disk is more insidious than a network fault, because the equipment keeps running and nobody notices that logging has stopped. Giving the log server its own heartbeat log, reported over a separate channel, is the usual belt-and-braces fix.
NTP first. Run the server internally, point devices only at internal addresses, sync every 64–1024 seconds.
Log severity. Critical levels alert in real time and are retained long term; Notice for audit; Debug only during commissioning.
Separate facilities. Device events apart from user actions, so the platform can filter by source.
Trap selection. Inform for critical events, Trap for ordinary ones, Syslog as the record behind both.
Suppression rules. Merge same-type alerts from the same device over a 5-minute window and pin the root-cause alert to the top.
Security hardening. SNMPv3 authentication and encryption, source restriction on the log server, TLS where needed.
Self-monitoring. Heartbeat reporting for the logging and management platforms so neither fails silently.
Rayin's managed industrial switches and OLTs support CLI, Web and SNMP management, and can forward both Syslog and Trap to a single operations platform; the PON access solution and industrial switch solution pages list the management capabilities and specifications of each product line, so one set of alert rules can cover both.
Is Syslog alone enough for operations, without Trap? It covers passive diagnosis, not timely response. Syslog is asynchronous text, and hours can pass between an event and someone reading the log; link-flap volume is large and easy to drown in. What a Trap adds is pulling out the events that need to be known immediately and pointing straight at the fault site once NTP stamps them. Running both costs very little — Trap configuration is a destination and a list of event types.
What NTP sync interval is appropriate? With a local server, anything from 64 to 1024 seconds is reasonable. A short interval (64 s) is more accurate at the cost of more requests; a long one (1024 s) saves resources but recovers more slowly from a failed sync. For a few hundred devices, 256 or 512 seconds is a good balance. Industrial sites only need millisecond alignment, so there is no reason to synchronise every second.
How long should a log server retain logs? It depends on the project. An industrial control system is safer at 180 days, because fault reviews often reach back more than a quarter of operation; an ordinary campus network is fine at 90 days. Storage cost is low by the earlier arithmetic: 100 devices for 180 days is about 1.8 GB, and one ordinary server covers the same retention for more than a thousand devices. What drives storage is not the retention period but whether log levels are under control.
Syslog over UDP 514 drops packets — should it be moved to TCP? If the device supports Syslog over TLS (TCP 6514), critical logs should use it. On many industrial devices the TCP option is simply unavailable, and the more practical approach is to split by severity: critical events do not depend on Syslog but go out as SNMP Inform to guarantee delivery, while Syslog records the process and accepts minor loss. Betting every log on UDP while expecting zero loss is an unrealistic expectation.
Can NTP and PTP run at the same time? Yes. They use different ports and different message mechanisms, so they do not interfere. The common arrangement is PTP (IEEE 1588) for deterministic synchronisation and NTP for logging the system time. Be careful not to hang log timestamps off PTP — its output is typically a hardware time domain, and software reading the log may still see the local clock. Confirm which time source the logging module reads, or the system will look synchronised while the log timestamps still drift.
GPON Network Inspection Checklist: 5 Steps Before a Fault Happens
Optical Module DDM: How to Read Tx/Rx Power From Your Switch
About the author: Sara — Customer Manager at Shenzhen Rayin Technology Co., Ltd., 10+ years helping ISPs and integrators build industrial networks.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
