Yes, you can test a copper link entirely from the switch, but only if you know which layer answers which question — port counters tell you the fault is physical, cable diagnostics tell you roughly where it sits, and DDM tells you whether the optics are still inside their budget.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
The three built-in layers map onto OSI layers one, two and three, and none of them replaces the others: a clean ping only proves the management plane is alive, not that the service is healthy.
TDR resolves a break to ±1-2 m and no finer. It reports distance, never cause.
DDM exposes five live values per module. One to two dB of disagreement with a handheld power meter is normal, so use DDM for trends and the meter for acceptance.
1,200 CRC errors an hour on a 1 G link works out near 1.4 x 10^-6 frame errors — three orders of magnitude above what the standard expects, and enough to make a video stream stutter without ever dropping the link.
Strip away the vendor menu names and three capabilities remain, one per OSI layer.
The physical layer is cable diagnostics and optical module self-check. TDR — time domain reflectometry — fires a pulse down the twisted pair and times the echo to compute distance. DDM reads five registers defined by SFF-8472 inside the transceiver.
Layer two is port counters and mirroring. Every port keeps ifInErrors and ifOutErrors counters, defined for MIB-II by RFC 1213, and CRC, alignment and discard events all land there. When you need the actual frames, mirror the port to a free one and attach a capture tool.
Layer three is the built-in ping and traceroute. ICMP comes from RFC 792, and traceroute builds its path by incrementing TTL hop by hop and collecting the time-exceeded replies.
The three are complementary, not interchangeable. A failed ping does not mean the link is down — ICMP may simply be filtered. A CRC counter climbing steadily while ping replies arrive on time is one of the most common patterns in the field.
Two inputs produce every TDR number: pulse propagation velocity and echo time.
distance = velocity x time ÷ 2
The division by two is there because the pulse travels out and back. Velocity in a twisted pair runs about 0.67 times the speed of light, roughly 2.0 x 10^8 m/s, and each vendor corrects it with an NVP (nominal velocity of propagation) parameter.
From those two inputs a diagnostic reports total length, the position of an open or a short, the length difference between pairs, and the point of impedance mismatch. That last one matters more than it sounds. A 100 M link only needs pairs 1-2 and 3-6, while 1000BASE-T needs all four pairs healthy — which is why the same cable passes at 100 M and fails at 1 G. The line in the report reading "pair length skew out of range" is usually the whole answer.
A TDR cable test also runs on a port with no link at all, which is what makes it useful before the far-end equipment is even installed: plug in the run, read the length, and you know whether the drum label was telling the truth.
Put the costs up front. Copper TDR accuracy is no better than ±1-2 m. When the far end is actively transmitting, the echo arrives mixed with the peer's signal and the reading drifts. And optical ports have no equivalent: a module reports TX and RX power, never the position of a break. Locating a fibre break needs an OTDR, which is a different instrument entirely.
If the question is simply how to test ethernet cable on a live port, this is the cheapest first move — it needs no unplugging and no extra hardware, and it narrows a 90 m run to a 2 m window.
DDM, also sold as DOM (digital diagnostic monitoring), is implemented per SFF-8472 and returns live physical quantities from inside the module:
Temperature — module case temperature. Above 70 °C usually points at cabinet airflow, not a failing module.
Supply voltage — the 3.3 V rail, tolerated to about ±5%. Running low usually points at the rack supply.
TX bias current — normal TX power with a bias current that has clearly risen is an early sign of laser ageing.
TX power and RX power — the two numbers that answer most optical questions directly.
The "module self-check" on a switch is nothing more than comparing those five values against the thresholds stored in the module. As a reference point, a 1310 nm single-mode 10 km module typically transmits somewhere between -9 and -3 dBm and has a receiver sensitivity around -20 dBm. On the PON side, ITU-T G.984.2 sets the Class B+ optical budget at 28 dB, with ONU receiver sensitivity down to roughly -27 dBm. Those numbers only become useful once you start calculating link margin, which comes later in this article.
The boundaries matter too. Some 100M modules never implemented DDM and return empty values. Absolute accuracy is limited — a 1-2 dB gap against a power meter is normal — which is fine for judging whether a value is out of range and not fine for formal acceptance testing.
A workshop switch feeds twelve cameras. One of them blacks out three to five times a day; the other eleven are fine. Port statistics show that port adding roughly 1,200 CRC errors an hour while every other port stays at zero.
Step one — classify. No discards (ifOutDiscards is zero), but CRC and alignment errors keep climbing. That means frames are already damaged before they arrive, so the fault is physical, not forwarding or configuration. This single observation shrinks the search from "the network" to "this cable and the two interfaces on its ends".
Step two — locate. Run cable diagnostics on that port. The report puts an impedance mismatch at 62 m, on a run that measures about 85 m. Running the TDR maths backwards: 62 m x 2 ÷ 2.0 x 10^8 m/s ≈ 620 ns, so the echo returns after 620 ns — consistent with what the switch reports.
Step three — size the problem. The link runs at 1 G. At line rate that is about 1.488 x 10^6 minimum-size frames a second; at an average frame length of 512 bytes, roughly 2.4 x 10^5 frames a second. Then 1,200 errors an hour is about 0.33 a second, a frame error rate near 1.4 x 10^-6 — far above the 10^-12 order a gigabit link is expected to hold. At that rate TCP never collapses outright, but the video stream retransmits often enough to look like random blackouts.
Step four — verify. Remake the patch lead and the RJ45 plug near the 62 m mark, clear the counters, and watch for 24 hours. If the count stays at zero, the case is closed. If it keeps climbing, run a margin calculation on the uplink optical port: a 1310 nm module transmitting at -6 dBm with -20 dBm sensitivity gives a 14 dB budget; measured RX is -14.2 dBm, so actual link loss is 8.2 dB and margin is about 5.8 dB. Reserve the customary 3 dB for ageing and 2.8 dB remains — workable, but with no room left to insert another splitter stage.
| Symptom | Start with | What it settles | What it cannot tell you |
|---|---|---|---|
| One port drops packets occasionally | Port counters (CRC / alignment) | Whether damage is physical or a forwarding drop | Which segment of the cable is at fault |
| The whole link is dead | Cable diagnostics (TDR) | Break position, length, open or short | Why it broke — impact, water, a bad crimp |
| Link lamp stays dark | TDR plus counters on the far port | Whether the pinout follows 568B, whether negotiation failed | Whether the peer device is itself damaged |
| Optical port shows errors | DDM TX and RX power | Whether loss exceeds what the module can tolerate | Where the fibre break is — that needs OTDR |
| Ping loss but the service is fine | Traffic generator plus mirrored capture | Whether ICMP is being rate-limited | — |
The field sequence that works is fixed: lamps and counters first, TDR second, optics and capture last. Doing it the other way round usually produces a stack of "device normal, link normal" readings and no conclusion.
| Reading | Usual range or threshold | What an out-of-range value means |
|---|---|---|
| Copper length | ≤100 m (IEEE 802.3 channel spec) | Over length always loses packets; keep PoE runs to ≤80 m |
| TDR accuracy | ±1-2 m | Locates a zone, never a connector |
| CRC / alignment | 0 under steady conditions | A rising count means physical-layer damage |
| RX optical power | At least 3 dB above module sensitivity | Within 3 dB of sensitivity, a temperature swing alone will flap the link |
| Module temperature | 70 °C as a common ceiling | Check cabinet airflow before swapping the module |
| Supply voltage | 3.3 V ±5% | A low rail points at the rack supply, not the module |
The CPU and the forwarding plane are separate. A switch generates ping replies on the control-plane CPU. Saturate that CPU with SNMP polling, logging and route calculation and ping starts dropping while the forwarding ASIC is perfectly healthy. The reverse also happens: microbursts may already be dropping service traffic while ping stays clean. So ping proves the management path, nothing more.
One-way faults. A misapplied ACL, a unidirectional optical loss or an MTU mismatch can all leave ping working while the service fails. Only mirrored capture or a round-trip traffic test separates those cases.
Paths that cross other devices. Traceroute will show you where the path changed, but queue drops inside transit equipment, uneven ECMP hashing and carrier-side policing never appear in any counter you can read.
Physical fibre defects. Switch self-check does not look at the glass. Breaks, tight bends and dirty connectors all need an OTDR and an optical power meter.
| Tool | What it is for | What it cannot replace |
|---|---|---|
| Switch CLI (illustrative only — commands differ by platform) | Cable diagnostics, DDM readings, counter resets | Accurate optical power measurement |
SNMP polling of ifInErrors / ifOutErrors | Scheduled collection of error trends | Frame-level analysis |
| Port mirroring plus a capture tool | Seeing real frames, spotting one-way loss | Physical-layer location |
| Traffic generator | Real throughput and loss figures | Optical power measurement |
| Optical power meter / OTDR | Optical acceptance and break location | Copper pinout checks |
| Handheld cable fault locator | Confirming a break when the port itself is dead | Switch-side counters and DDM |
The practice is unglamorous: record a baseline for every device — per-port error counters, optical TX and RX levels, module temperatures. When a fault appears, compare against the baseline instead of against a feeling.
Rayin's 8+4 port gigabit industrial switches (PoE optional) expose port statistics, cable diagnostics and SFP DDM readings in both the Web UI and the CLI, which is enough to turn this baseline sweep into a scheduled routine; the network design notes on the industrial switch page show how that fits into a plant topology. Devices on the PON side with optical ports report in the same units, and the PON access section covers that side of the network.
One caution worth repeating: no single one of these network diagnostics tools is a substitute for an instrument. What they buy you is a much smaller search area — counters push the problem to the physical layer, TDR pushes the position into a few dozen metres, and DDM pushes an optical problem down to two numbers. That usually saves one unnecessary teardown. Full device specifications and selection details sit in the Rayin company profile.
Can the switch's cable diagnostics test fibre? No. Cable diagnostics is TDR-based and works only on twisted pair, because it measures an electrical echo. An optical port can report DDM power levels and module temperature, but it cannot say where a fibre break is. Fibre faults need an optical power meter for loss and an OTDR for break and splice position — neither can be replaced by the switch.
Ping shows 5% loss. Does that prove the link is bad? Not necessarily. Ping replies come from the CPU, so aggressive SNMP polling, flooding logs or rapid ARP table churn can drop them while service traffic runs cleanly. Compare port counters: if CRC and discard counts on the service port are zero and only ping suffers, look at management-plane load before you touch the cable.
How far apart should DDM and a power meter reading be? One to two dB is normal. The calibration coefficients are fixed inside the module and readings drift with batch and temperature. Use the power meter for acceptance and treat DDM as an online trend: a 2-3 dB change on the same module between today and three months from now means something in the path or the module has moved.
Why does CRC climb on only one side of a link? CRC is counted on the receiving side — whoever receives the bad frame increments. One-sided growth means the problem lies between the transmitter and that receiver: a weak transmitter, a kinked patch lead, or reduced sensitivity at the receiving port. Swap the two modules; if the counter follows the module it is the module, if it follows the port it is the port. That comparison costs the least time of anything in this article.
With diagnostics built in, do I still need iperf and an OTDR? Yes, because they answer different questions. Built-in diagnostics tell you where something is wrong, a traffic generator tells you what the link can actually carry, and an OTDR tells you which metre of fibre is broken. Relying on switch self-check alone most often produces a verdict of "port normal, link normal" that explains nothing about the stutter the user is complaining about.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
