Poll These Switch Points Before You Blame the PLC

An eight-second blip that wasn't the controller

A handful of analog tags on one remote I/O drop go bad quality for a few seconds, two or three times a shift. The PLC diagnostic buffer is clean. The SCADA driver logs a request timeout and recovers. Nobody can reproduce it on demand, so it gets written up as "comms glitch" and lives in the open-issues list for a month.

The switch knew. The copper port feeding that drop was collecting FCS errors, and the increments lined up with the big mixer starting — a drive with a badly terminated shield, coupling into a cable run that shared a tray with motor leads. None of that was visible in SCADA, because the switch was "IT equipment" and nobody had polled a single object off it.

That is the argument for putting switch health in the control system view. Not to replace packet captures or config backups, but so the first question after a bad-quality burst — process, controller, or network path? — has an answer on screen.

The short list worth polling

Resist importing the whole MIB. A hundred objects per switch across forty switches is a slow screen and an alarm list nobody trusts. Most of what matters comes from IF-MIB (RFC 2863) and EtherLike-MIB (RFC 3635):

What you want	Object
Link up/down	ifOperStatus — 1.3.6.1.2.1.2.2.1.8
Negotiated speed	ifSpeed / ifHighSpeed
Receive errors	ifInErrors — 1.3.6.1.2.1.2.2.1.14
FCS/CRC specifically	dot3StatsFCSErrors — 1.3.6.1.2.1.10.7.2.1.3
Buffer pressure	ifInDiscards / ifOutDiscards
Throughput	ifHCInOctets — 1.3.6.1.2.1.31.1.1.1.6
Port label	ifAlias — 1.3.6.1.2.1.31.1.1.1.18
Reboot detection	sysUpTime — 1.3.6.1.2.1.1.3

Add whatever the vendor exposes for power supply A/B, chassis temperature, and redundancy state — those live in enterprise MIBs and differ by make, so read the vendor MIB rather than guessing an OID.

ifAlias deserves a mention on its own. It is the port description configured on the switch, and it is the cheapest labelling trick available: set it to PLC-2 RIO drop / cabinet 14 on the switch, poll it, and your alarm text stops saying port 7. Do that once during commissioning and every future alarm inherits it.

For an ordinary endpoint port, one summary alarm per switch is enough. Uplinks, ring ports, and server ports get individual detail.

A total is not a symptom

ifInErrors is cumulative since the counter was last reset. Read once, it tells you nothing — 4,182 errors could be four years of nothing or four minutes of a failing SFP. Store the delta and show a rate: CRC errors per minute, discards per minute, link transitions per hour, minutes since the last ring topology change.

Two things break naive delta math:

Counter width. RFC 2863 is explicit that 32-bit counters are inadequate above roughly 20 Mbit/s and that 64-bit ones are required past 650 Mbit/s. The arithmetic is unforgiving: 2³² octets at line rate on a gigabit uplink wraps in about 34 seconds, and around 5.7 minutes on 100 Mbit/s. If you poll octets on a 60-second cycle from ifInOctets instead of ifHCInOctets, your utilization number is fiction. Use the high-capacity objects and SNMPv2c or v3, since 64-bit counters don't exist in v1.

Reboots. A switch restart zeroes the counters and your delta goes hugely negative, or hugely positive if you clamp it wrong. Poll sysUpTime alongside the counters and discard the delta whenever uptime moved backwards. That single check kills most false spikes.

I'd rather poll ten ports every 15 seconds than every port every 5 minutes. Flaps are short; a 5-minute poll interval mostly proves that the port was up when you looked.

Not every link-down deserves an operator alarm

Port role	What it should do
Ring or redundant uplink	Alarm on link down, speed change, or topology change
PLC / remote I/O	Alarm on link down and on sustained error-rate growth
HMI workstation	Alarm only if that station is production-critical
Engineering laptop port	Event history only — never an operator alarm
Disabled spare	Silent, but alarm if it unexpectedly goes active

That last row catches something worth catching: a spare port coming up means somebody plugged something in. On a segmented network under an IEC 62443-3-2 conduit definition, that is a change to the conduit, not a network curiosity.

Speed change is the row people skip and later regret. A fiber uplink that renegotiates 1000 → 100 after a bad clean, or a copper port that drops to 10 Mbit/s half-duplex because auto-negotiation failed against a fixed-speed device, will not raise a link-down alarm. It will just make everything slow and produce late-collision counts that look like nothing in particular.

Traps will lose you an event eventually

linkDown (1.3.6.1.6.3.1.1.5.3) is a single unacknowledged UDP datagram. If the receiver is restarting, the community or the SNMPv3 engine ID doesn't match, or a firewall rule changed last Tuesday, it's gone and nothing tells you.

So run both: traps for latency, polling for truth, plus a heartbeat so a dead SNMP path is itself an alarm. Keep the trap in event history even when the following poll shows the port already back up — the flap is the finding. A port that bounces for 300 ms twice an hour is exactly what produces those unexplained bad-quality bursts, and the poll will never see it.

ifIndex is not a stable key

RFC 2863 asks agents to keep ifIndex values persistent across reinitialization, but that promise doesn't survive everything. Add or remove a media module, upgrade firmware across a major version, or swap in a replacement switch with a different port layout, and index 7 can quietly become a different physical port. Your alarm keeps working and now describes the wrong cable.

Key your points on ifName or ifAlias and verify the mapping after any hardware or firmware change. While you're there, check that the poller is talking to the new management IP — polling the old address of a replaced switch is the single most common way monitoring goes dark without anyone noticing.

Keep the management path narrow

SCADA polling a switch does not mean every HMI needs SNMP reach. Poll from one or two approved hosts, restrict source IPs on the switch itself, and don't enable write access without a reason you could defend in a review.

Prefer SNMPv3 with authPriv where the hardware supports it — RFC 3414 for user authentication, RFC 3415 for restricting what those users can see. Mismatched auth/priv passphrases or protocols between switch and collector is a routine commissioning failure, and the symptom is silence rather than an error, so test it deliberately. Where only v2c exists, treat the community string as the password it effectively is: unique per site, never in a display configuration file, and scoped to the management VLAN.

Shake it before handover

Do this in a planned window, with real switch actions, not by trusting the configuration:

1. Confirm the displayed switch name and cabinet location match the physical device.
2. Unplug a non-critical test port; verify the correct port event appears with the right name.
3. Force a speed change on a spare device and confirm you see it.
4. Trigger a power supply or ring-state alarm with the vendor's supported method.
5. Reboot the switch and confirm counter-reset handling doesn't produce a spike.
6. Compare event timestamps against SCADA server time.
7. Check the alarm text names the affected PLC, server, or cabinet — not port 7.

Step 5 is the one that gets skipped, and it's the one that generates the 3am nuisance alarm six weeks later.

What the first screen has to answer

Operators don't need an SNMP browser. They need switch health by area or cabinet, critical link status, ring state, recent flaps, active error-rate alarms, and the time of the last successful poll — that last one because a stale poll time is the difference between "the network is fine" and "we stopped looking an hour ago."

Everything deeper belongs on an engineering page. If the operator screen can separate a process problem from a PLC problem from a network path problem, it has done its job; the counters can wait for whoever picks up the call.