Pull a cable in a star-topology EtherNet/IP network and one device goes dark. Pull a cable in a properly designed DLR ring and the network recovers in less than 3 milliseconds — fast enough that the PLC scan does not even register the change. That recovery time is the whole reason DLR exists. Engineers building motion-control machines, robotic cells, and high-availability process equipment use DLR as the standard form of EtherNet/IP redundancy because nothing else on EtherNet/IP gets you ring topology recovery with that kind of speed.
This article walks through what DLR actually is, how the ring supervisor election works, what beacon frames carry, what happens during a fault, and what tends to go wrong in the field. For the broader EtherNet/IP and CIP context, see our CIP Protocol Complete Guide article.
Table of Contents
What DLR is in one paragraph
Device Level Ring (DLR) is a Layer 2 redundancy protocol defined by ODVA as part of the EtherNet/IP specification. It enables ring topologies where embedded two-port switches in the end devices themselves form the ring — no external ring switches required. A designated ring supervisor monitors the ring health using beacon frames sent in both directions. When a fault breaks the ring, the supervisor detects it within 3 milliseconds in well-designed networks and reconfigures the network to keep traffic flowing. DLR is media-redundant (one cable break = no traffic loss) but not bandwidth-redundant (it does not double throughput).
Why DLR exists
Standard Ethernet star topologies have a single point of failure for every device: the cable run to the switch. Pull that cable, drop that switch port, and that device disappears from the network. For a desktop PC, who cares. For a servo drive in the middle of a 12-axis motion sequence, that single point of failure is unacceptable.
Other redundancy approaches have problems for industrial use:
- RSTP (Rapid Spanning Tree Protocol) — works on any switch, but recovery takes hundreds of milliseconds to seconds. Too slow for industrial control.
- Per-vendor proprietary rings (Hirschmann HiPER-Ring, Moxa Turbo Ring, etc.) — fast but vendor-locked. A Hirschmann ring needs Hirschmann switches end to end.
- MRP (Media Redundancy Protocol) — fast (sub-200 ms typical, 30 ms in MRP IRT), but tied to PROFINET ecosystem and requires dedicated MRP-capable switches.
DLR solves the problem differently. Instead of adding ring switches around the perimeter, it builds the ring switching capability into the end devices themselves. A Stratix 5700, an Allen-Bradley 1734-AENTR Point I/O adapter, a Kinetix 5700 drive — all have two Ethernet ports with embedded switching. Daisy-chain them into a ring and you have a redundant network. No extra switches needed in most designs.
How the ring physically forms
A DLR network needs at least three nodes (technically two works, but offers no protection — a single cable break drops both nodes). In practice, rings run from 3 to about 50 nodes for high-performance designs, with up to about 230 nodes possible in larger lower-speed rings.
Every node needs two Ethernet ports with embedded switch hardware. These are physically separate ports (typically labeled Port 1 / Port 2 or A / B). Cables daisy-chain through each node:
Supervisor
/ \
Node A Node F
| |
Node B Node E
| |
Node C ------- Node DThe ring is one continuous loop. Frames can travel in either direction. The embedded switch in each node forwards frames out the other port while also delivering them to its own application layer (the CIP stack inside the device).
Standard non-DLR devices (a PC, a non-DLR I/O module) cannot sit inside the ring. They connect through an EtherNet/IP tap — a special device that hangs off the ring and provides a standard switch port for the non-DLR device. Rockwell’s 1783-ETAP is the most common example.
The ring supervisor
One node in every DLR ring must be configured as the active ring supervisor. Its job is to:
- Prevent traffic loops. A complete ring of forwarding switches would flood. The supervisor blocks one of its two ring ports (typically Port 2) so the ring behaves like a line under normal conditions.
- Monitor ring health by sending beacon frames in both directions every few microseconds.
- Detect faults when beacons stop arriving.
- Reconfigure the ring by unblocking its second port when a fault occurs.
- Restore normal operation when the fault is cleared.
In addition to the active supervisor, the protocol supports backup ring supervisors — additional nodes configured as supervisors with lower precedence. If the active supervisor fails, the backup with the highest precedence takes over. Most production designs configure at least one backup supervisor to avoid losing redundancy when the supervisor itself dies.
Supervisor election
When multiple devices are configured as ring supervisors, DLR selects the active one through a precedence-based election. The precedence value (0–255) is set per device via the Ring Supervisor Object. Higher values win.
Tiebreaker rules apply when precedence values match:
- Higher precedence wins outright
- If precedence is tied, the device with the lowest MAC address becomes active
For production designs, set explicit precedence values rather than relying on MAC tiebreakers. Operations engineers cannot easily predict which device will win on MAC ordering, and unexpected supervisor changes during commissioning create confusion.
Beacon frames — how DLR detects faults
The supervisor sends two beacon frame streams continuously:
- Beacon out Port 1 — travels around the ring clockwise (let us say)
- Beacon out Port 2 — travels counterclockwise
Under normal conditions, beacons sent out Port 1 should arrive back at the supervisor’s Port 2, and vice versa. Each beacon carries:
- Source MAC address (the supervisor’s)
- Ring state (Normal, Ring Fault, Unexpected Loop Detected, Partial Network Fault, Rapid Fault/Restore Cycle)
- Precedence value
- Sequence number
- Beacon interval and timeout values
The default beacon interval is 400 µs — the supervisor sends a beacon out each port every 400 microseconds. The default beacon timeout is 1960 µs — if no beacon arrives within that window, the supervisor declares a fault.
Faster beacon intervals (down to 100 µs) reduce recovery time but increase CPU load on the supervisor. Default 400 µs is the typical setting for most installations and yields recovery times below 3 ms.
What happens in 3 milliseconds when a cable breaks
Walk through the sequence engineers actually need to understand:
T = 0 — Cable between Node C and Node D is cut.
T = 0 to 1960 µs — Both directions of beacon traffic that pass through the cut stop arriving. Beacons sent out the supervisor’s Port 1 still reach Node C but cannot continue to D or back around. Beacons sent out Port 2 still reach Node D but cannot continue.
T ≈ 1960 µs — The supervisor’s beacon timeout expires for both directions. The supervisor declares a ring fault.
T ≈ 2 ms — The supervisor unblocks its Port 2 (which was previously blocking to prevent loops). Now traffic can flow out both supervisor ports, reaching every node that is still on the ring.
T ≈ 2 to 3 ms — Embedded switches in each node update their forwarding tables. Frames that were previously taking the broken path now route the other direction around the ring.
T < 3 ms — Communication is restored. The PLC’s RPI scan typically does not even notice. CIP connections do not drop. I/O remains live.
When the broken cable is repaired:
T = 0 — Cable reconnected.
T < 50 ms — The supervisor sees beacons again on both ports, detects the ring is whole, blocks Port 2 to restore the normal anti-loop state, and resumes normal operation.
The 3 ms convergence is the key number engineers quote. To hit it consistently, every node in the ring must support DLR natively (no external standard switches in the path) and the supervisor must be configured with default or faster beacon intervals.
The Ring Supervisor Object (CIP class 0x4E)
DLR is configured through the Ring Supervisor Object, a CIP class 0x4E that appears in every DLR-capable device. The key attributes:
| Attribute ID | Name | What it does |
|---|---|---|
| 1 | Network Topology | Current topology (Linear, Ring) |
| 2 | Network Status | Normal, Ring Fault, Unexpected Loop, Partial Fault, Rapid Fault/Restore |
| 3 | Ring Supervisor Status | Backup, Active, Normal Ring Node |
| 4 | Ring Supervisor Configuration | Enable supervisor function, precedence, beacon interval, beacon timeout |
| 5 | Ring Faults Count | Counter of detected ring faults |
| 6 | Last Active Node on Port 1 | MAC of last reachable node on Port 1 side |
| 7 | Last Active Node on Port 2 | MAC of last reachable node on Port 2 side |
| 8 | Ring Protocol Participants Count | Number of DLR-capable devices in the ring |
| 9 | Ring Protocol Participants List | Ordered list of participants |
| 10 | Active Supervisor Address | Currently elected supervisor’s MAC |
| 11 | Active Supervisor Precedence | Precedence value of the active supervisor |
| 12 | Capability Flags | What the device’s DLR implementation supports |
Engineers troubleshooting a misbehaving ring read these attributes through Studio 5000, RSLinx, or any CIP-capable tool. The Last Active Node on Port 1 / Port 2 attributes are particularly useful — they tell you exactly which node is at the edge of the fault, narrowing down where the break is.
Ring topology rules and limits
DLR has specific ring topology constraints. Violating them either prevents the ring from forming or degrades convergence time:
| Rule | Reason |
|---|---|
| Maximum 50 nodes for high-performance rings | More nodes = more beacon transit time = slower convergence |
| Up to 230 nodes for larger rings | Possible but convergence time degrades, typically 50+ ms |
| No standard Ethernet switches in the ring path | Standard switches forward beacons too slowly and can break the timing |
| All DLR ring nodes must have embedded switches | DLR depends on per-port switching at every node |
| No more than one ring supervisor active at a time | Election ensures this, but misconfiguration can cause “supervisor wars” |
| Maximum cable length per segment: 100 m (copper) | Standard Ethernet limit |
| Fiber acceptable for long ring segments | Some devices support fiber SFP modules |
| DLR rings cannot share nodes | A device can only participate in one ring at a time |
| Mixed copper/fiber acceptable | But cabling must be properly designed |
For high-performance applications (motion, safety), staying under 24 nodes per ring is a common rule of thumb. Production rings with 50+ nodes work but the worst-case convergence time grows.
Redundant gateway functionality
A more advanced topology uses redundant gateways — two Stratix switches (or equivalent) connecting the DLR ring to the rest of the plant network. If one gateway switch fails, the other takes over without dropping ring traffic.
Redundant gateway is a separate function from the ring supervisor role. A single switch can be both ring supervisor and gateway, or these roles can be split across multiple switches. Configuration is typically done through Studio 5000 or the switch’s web interface.
Redundant gateway is not available on every DLR-capable device — only on specific Stratix switch models and a few third-party EtherNet/IP switches. Plain DLR end devices (drives, I/O blocks, etc.) cannot serve as redundant gateways.
How DLR coexists with EtherNet/IP traffic
This is where DLR’s elegance shows. DLR is a Layer 2 protocol that operates independently of higher layers. The CIP traffic running on the ring does not know or care that DLR is there. Implicit messaging, explicit messaging, multicast I/O, unicast configuration — all of it runs as normal EtherNet/IP traffic on top of the DLR ring.
When a fault happens and DLR reconfigures the network, CIP connections do not need to re-establish. The Forward_Open connections stay intact. The producer-consumer multicast groups still deliver. The application sees a brief packet delay (a few hundred microseconds to 3 ms) but no connection drop.
This separation is the reason DLR works so well in production. The DLR layer handles physical-layer redundancy. The CIP layer handles application data. Neither has to know about the other.
For more on how the CIP layer establishes connections and exchanges I/O data, see our article on CIP Protocol Ports: How EtherNet/IP Uses Ports 44818 and 2222.
DLR vs other industrial Ethernet redundancy schemes
| Aspect | DLR | MRP | PRP / HSR | RSTP |
|---|---|---|---|---|
| Steward | ODVA | PI | IEC 62439 | IEEE |
| Native to | EtherNet/IP | PROFINET | Power utilities, IEC 61850 | Any Ethernet |
| Typical recovery time | < 3 ms | 30–200 ms | Bumpless (PRP) or < 1 ms (HSR) | Hundreds of ms to seconds |
| Topology | Ring | Ring | Parallel (PRP), Ring (HSR) | Any |
| Requires special hardware | Yes (embedded switches in nodes) | Yes (MRP-capable switches) | Yes (PRP/HSR-capable devices) | Standard managed switches |
| Bandwidth efficient | Yes | Yes | No (PRP doubles bandwidth) | Yes |
| Where it fits | Motion, robotics, high-availability machines | PROFINET plants needing media redundancy | Power utility substations | Generic Ethernet redundancy |
DLR’s main competitor in industrial Ethernet is MRP. Both deliver media redundancy. DLR recovers faster (3 ms vs ~30 ms typical), but MRP works on any PROFINET-capable infrastructure. For pure EtherNet/IP plants, DLR wins. For pure PROFINET plants, MRP is the only native option.
PRP and HSR are different beasts — they provide bumpless redundancy (zero packet loss on failure) by duplicating every frame onto two parallel networks. Much more expensive and only used where the milliseconds of DLR recovery still matter (mainly IEC 61850 substations).
For broader comparison context, see our PROFINET vs EtherCAT article.
Configuring DLR in Studio 5000
The basic configuration steps in Studio 5000 / Logix Designer:
Hardware setup. Wire the ring physically. Daisy-chain Port 1 → Port 2 → Port 1 → Port 2 around the ring. Connect the last node back to the first to close the ring.
Select supervisor candidates. Identify which devices will be ring supervisors. Typically a Stratix switch or a high-availability I/O adapter. At minimum one active supervisor plus one backup.
Configure precedence. In each candidate’s properties or via the Ring Supervisor Object, set the precedence value. Higher values for preferred active supervisors, lower for backups.
Enable supervisor function. Set the Ring Supervisor Object’s Enable bit on the candidates. Other devices stay as normal ring nodes (default).
Verify topology. After download, the Ring Supervisor Object’s Network Topology attribute should report “Ring” on the active supervisor. The Network Status should be “Normal”.
Document the active and backup supervisors. Operations and maintenance need this in the panel labels. A surprise supervisor change due to MAC tiebreaker is the most common “why is my ring acting weird” call.
Common DLR problems and what to check
| Symptom | Likely cause | What to check |
|---|---|---|
| Ring will not form | Wrong cabling order, broken cable, non-DLR device in ring path | Verify Port 1 / Port 2 daisy chain. Check cable continuity. Identify any non-DLR devices in the loop. |
| Supervisor reports “Unexpected Loop Detected” | Two active supervisors, or a parallel path exists | Only one supervisor should have Enable + highest precedence active. Look for spare cables creating shortcuts. |
| Recovery takes more than 3 ms | Standard switches in the ring path, or supervisor beacon interval too long | Verify all ring nodes are DLR-native. Check beacon interval (default 400 µs). |
| Ring works for hours then drops | Marginal cable, intermittent connector | Run a cable test. Check Ring Faults Count attribute — increments suggest the supervisor is detecting and recovering events you do not see. |
| Connection drops despite ring “working” | Convergence exceeds CIP connection timeout, or device has app-level fault unrelated to DLR | Check RPI vs ring convergence time. A 2 ms RPI with 3 ms ring recovery loses one cycle and may break very tight motion connections. |
| Cannot find the supervisor | Misconfigured precedence, no devices have Enable set | Read Ring Supervisor Status attribute on candidates. Verify Enable bit. |
| Ring node reports “Partial Network Fault” | Some nodes unreachable in one direction | One break has been detected. A second break would split the network. Find and repair before relying on redundancy. |
| Backup supervisor never activates | Backup has lower precedence than active (correct), but active never fails properly | Test by powering down the active supervisor during a maintenance window. |
| Last Active Node attributes do not match what I see | Stale cached values | Read the attribute fresh. Some tools cache for performance. |
When DLR is the right choice
- Motion control machines where 3 ms recovery is the difference between a glitch and a fault stop
- High-availability robotic cells where a single cable failure cannot shut down production
- Compact machines where star wiring back to a central switch wastes cable and panel space
- Existing EtherNet/IP installations where adding redundancy through DLR avoids re-architecting the network
- GuardLogix safety applications where the safety layer assumes high network availability
- Greenfield Rockwell installations designed around DLR-capable hardware
When DLR is not the right choice
- Distributed plants with long cable runs and scattered devices — DLR’s daisy-chain topology becomes unwieldy
- Mixed-vendor multi-protocol environments where DLR-capable devices are limited
- Pure PROFINET installations — use MRP instead
- Process plants with FOUNDATION Fieldbus or HART — different redundancy models apply
- Plants where standard star topology works fine — DLR adds complexity that needs justification
DLR security considerations
DLR itself does not have built-in authentication or encryption. It is a Layer 2 protocol that assumes the ring is a closed industrial network. The standard security advice applies:
- Treat the DLR ring as one segment in your IEC 62443 zone model
- Do not connect the ring directly to corporate IT
- Use a controlled gateway (Stratix switch with firewall rules, industrial DMZ device) between the ring and the rest of the plant
- Monitor the Ring Faults Count attribute — frequent fault/restore cycles can indicate physical tampering or marginal cabling
For the broader cybersecurity context, see our IEC 62443 foundational requirements article.
Frequently asked questions
What does DLR stand for?
DLR stands for Device Level Ring. It is a Layer 2 ring redundancy protocol defined by ODVA as part of the EtherNet/IP specification. It enables high-availability ring topologies using embedded switches in the end devices themselves.
How fast does DLR recover from a fault?
DLR is designed to recover in under 3 milliseconds in well-designed rings using default beacon intervals (400 µs). Actual recovery time depends on ring size, beacon interval configuration, and whether any non-DLR devices are in the path. Larger rings (50+ nodes) typically see longer recovery times.
How many devices can be in a DLR ring?
The DLR specification allows up to about 230 devices in a single ring. For high-performance applications (sub-3 ms recovery), most designs stay under 50 nodes, with 24 being a common practical limit for motion-control and safety applications.
What is a ring supervisor in DLR?
The ring supervisor is the device that monitors ring health using beacon frames and reconfigures the network when a fault occurs. Exactly one supervisor is active at a time. Most production designs configure a backup supervisor with lower precedence to take over if the active one fails.
Can a non-DLR device be part of a DLR ring?
Not directly in the ring path. A non-DLR device (a PC, an older I/O module without DLR support) must connect to the ring through an EtherNet/IP tap (such as Rockwell’s 1783-ETAP) that sits in the ring and provides a standard switch port for the non-DLR device.
What is the difference between DLR and MRP?
DLR is ODVA’s ring protocol for EtherNet/IP. MRP (Media Redundancy Protocol) is PI’s ring protocol for PROFINET. Both deliver media redundancy. DLR typically recovers faster (under 3 ms vs ~30 ms for MRP), but MRP is the native option on PROFINET networks. The protocols are not interoperable.
Does DLR require special cables?
No. DLR uses standard Cat5e or better Ethernet cabling, same as any EtherNet/IP network. The redundancy is implemented at the protocol and device level, not the cable level. Industrial M12 connectors are common but not required.
Can a single device be both ring supervisor and redundant gateway?
Yes, on capable devices (typically Stratix switches). The ring supervisor function and redundant gateway function are independent and can coexist on the same device or be split across multiple devices, depending on your topology and availability requirements.
Why does my DLR ring keep showing “Unexpected Loop Detected”?
This usually means two devices are simultaneously acting as active ring supervisors, or a physical cabling shortcut creates a parallel path that the supervisor sees as a loop. Check that only one device has the Enable flag set with the highest precedence, and verify there are no extra cables creating shortcuts in the ring.
Is DLR a safety protocol?
No. DLR is a network redundancy protocol — it keeps the network running when a cable fails. It is not a functional safety protocol. CIP Safety is the safety layer on EtherNet/IP, and it can run over a DLR ring to combine high availability with safety functions. See our CIP Safety Explained article for the safety side.