How to Troubleshoot a DLR Ring Fault

Back to Blog

First Checks: Read the Ring Supervisor

Start at the ring supervisor, because it is the node that monitors ring integrity and it already knows the ring's state. In a Device-Level Ring one node acts as the active ring supervisor, sending the beacon or check frames that detect whether the ring is intact. Its status tells you immediately whether the ring is currently closed (healthy, redundant) or open (faulted, running on the surviving path). This one read tells you whether you are chasing a real ring fault or something else entirely, before you touch any hardware. The concept is covered in the Device-Level Ring explainer.

Crucially, the supervisor often identifies where the break is. Because it monitors both directions of the ring, it can report the two nodes that bound the fault - the last node it hears from on each side. That narrows the physical break to one link between two named nodes, which is the difference between inspecting one cable and walking the whole ring. Capture that fault location from the supervisor before going to the field; it is the single most valuable piece of information in a DLR fault.

Locate the Break Between Two Nodes

With the two bounding nodes identified, inspect the link between them. A DLR break is a loss of connectivity on one segment of the ring, and the usual physical causes are ordinary: a disconnected or damaged cable, a loose or corroded connector, or a failed port on one of the two nodes. Check the link status on both facing ports - one or both will show the port down that corresponds to the break. A port that is down on one node and its neighbor points straight at the cable or connector between them.

If both facing ports report healthy but the supervisor still sees a break, suspect an intermittent link or a marginal cable that is dropping frames without a hard link-down, or a duplex or speed mismatch degrading one segment. These are harder because the ring may be flapping - opening and closing as the marginal link comes and goes - which the supervisor's history or fault counters will reveal. A flapping ring is a link on the edge of failure, and it deserves the same treatment as a hard break because a marginal segment is a latent second fault waiting to combine with the first.

Restore the Ring and Confirm Redundancy

Fix the identified break - reseat or replace the cable, clean or replace the connector, or address the failed port - and then confirm restoration at the supervisor, not just at the mended link. The pass condition is the ring supervisor reporting the ring closed again, meaning both paths are intact and the ring is once more able to survive a future single break. A link that looks fixed locally but does not close the ring at the supervisor is not actually restored, so the supervisor status is the authority.

The reason to insist on confirming redundancy is that a DLR runs perfectly well with one break, so it is entirely possible to think you have fixed the problem when you have only fixed one of two faults, leaving the ring still open. Confirming closed at the supervisor rules that out. This is the same principle as any redundant system: fixing a fault is not done until the redundancy it protects is demonstrably back, a theme shared with the redundant I/O network discussion.

When to Escalate

Escalate when the break cannot be localized, when the ring flaps intermittently without a clear physical cause, or when a node itself appears to be the fault rather than a cable. A node that intermittently drops out of the ring may have a failing port or internal fault that needs vendor support or replacement, and chasing it as a cabling problem wastes time. Bring in the network team or vendor support when the evidence points at a device rather than the media between devices.

Also escalate the process question, not just the fault: if a DLR ring fault sat unnoticed until you happened to look, the monitoring of ring health needs attention, because the whole value of a ring is lost if a single break goes undetected until the second one causes an outage. A monitoring platform such as Merobix can trend the ring-status and fault tags a controller exposes, so a ring going from closed to open becomes a visible, alarmable event rather than a silent loss of redundancy. Surfacing that transition is what turns DLR redundancy from a latent hope into a maintained protection.

Frequently Asked Questions