What to Write in the Ticket When a Network Port Flaps

"Port flapping" is the ticket that bounces. Up, down, up, down — with no timeline, no counters, and no isolation, the escalation engineer has to re-test everything from zero, and the usual reply is "please gather more data." A flapping port is almost always one of five things (cable, optic, speed/duplex, far-end, or dying port), and the ticket should prove which one. Here is the capture order and the note that closes it.

First: capture the flap, don't just watch it

• Timeline: note the exact time of 3–4 transitions (14:02 up, 14:03 down, 14:05 up…). A port that drops every 60 seconds is a different fault than one that drops twice a day.
• Counters first, clear never (yet): record input errors, CRC errors, runts, and collisions before you clear the interface. Rising CRCs alongside flaps point at layer-1 (cable/optic/port); clean counters with flaps point at negotiation or the far end.
• Both ends: speed/duplex and negotiation state on this port and the far end. A hardcoded 1000/full talking to an auto-negotiating peer flaps exactly like a bad cable — and a cable swap won't fix it.

The isolation order (one variable at a time)

1. Verify the ticket. Device, rack/U, port, and the far end. Confirm you are testing the flapping link, not its neighbor.
2. Check negotiation. Compare speed/duplex on both ends; if one side is hardcoded and the other is auto, fix the mismatch first — this is the cheapest root cause and it resets the clock on your isolation.
3. Known-good patch cable. Swap in a tested cable of the same type and length class. Note whether flapping stops and whether CRC counters stop rising.
4. Move the optic, not the port. On fiber, move the suspect optic/SFP (with the known-good cable) to a known-good port. Flapping follows the optic? The optic is bad — escalate with its serial.
5. Move the port, not the optic. Put the original cable+optic on a different switch port. If the new port is stable for 20 minutes, the original port hardware is dying — escalate for port replacement or device RMA, with the flap timeline attached.
6. Check the far end. If both sides swap clean, the fault may be the far-end device rebooting or its port dying. State the far-end checks or the escalation is incomplete.

A port-flap note that gets the fix approved

14:00 — Flapping: sw-c12-04 port 1/1/18 ↔ srv-1042 Eth1 (rack C12 U18).
Flap timeline: 14:02 up, 14:03 down, 14:05 up, 14:06 down (every ~90-120s).
Counters before clear: 412 CRC, 388 input errors, 0 collisions, 2h since boot.
Speed/duplex: both ends 10G full, auto-neg — matched, not the cause.
Test 1: known-good patch cable — flapping continues, CRC still rising.
Test 2: suspect SFP (PN 10G-SR, SN XXXXXXX) in known-good port 1/1/22 — stable,
0 errors in 20 min. Original port + known-good SFP — stable 20 min.
Conclusion: fault follows the SFP (PN 10G-SR, SN XXXXXXX).
Ask: approve spare SFP from stock; failed unit tagged to RMA bin?
Next update 15:00 or on approval.

The mistakes that get port-flap tickets bounced

• "Port flapping" with no timeline. Without timestamps and intervals, the engineer cannot tell a cable fault from a far-end reboot.
• Clearing counters first. Cleared counters erase the CRC evidence that separates layer-1 faults from negotiation faults. Capture first, clear after you record.
• Swapping cable and SFP together. Flapping stops and you learned nothing — the good SFP goes back in the drawer and the real culprit fails again on the next shift.
• Hardcoded speed on one side only. The most common self-inflicted flap. Check both ends before touching hardware.
• No far-end check. If the far end is rebooting (failing PSU, crash loop), no amount of local swapping fixes it.

See RackReady   Free sample   Ticket note examples

Support: support@hasherventures.com

Free tool: turn your checks into a structured ticket note with the RackReady Ticket Builder.