SDS-3008 Ring: Match the Protocol, Not Just Cabling

The panel symptom is immediate: close the Ethernet loop and communication becomes unstable, switch pings drop, and the SDS-3008 management page becomes unreachable. That is a Layer 2 loop, not a bad management interface. The current devices do not show one common ring protocol across every inline node, so do not operate them as a closed ring until you select one supported protocol and architecture.

Read the symptoms first

Start here. Open one cable that closes the ring. If ping and management access recover, the redundant path is circulating Ethernet frames instead of remaining blocked or supervised.

Symptom	Most likely cause
Network fails only after the final link is connected	An uncontrolled Layer 2 loop is active.
Ping to the SDS-3008 becomes intermittent	Broadcast, multicast, or unknown-unicast traffic is consuming link and switch-processing capacity.
The management page stops responding	The management traffic is competing with recirculating frames; the web interface is not the root fault.
Both RSTP-facing ports remain forwarding	RSTP has not detected a valid redundant bridge path through the connected devices, or it is not active on every required path.
The network works with the ring open	The devices and addresses may be usable in a line topology, but loop control is missing from the closed topology.

Check port counters while the loop remains open. Record broadcast and multicast rates, link transitions, and error counters. Close the loop only for the shortest controlled test needed to prove the symptom, then open it again.

Separate RSTP from DLR

RSTP and DLR solve related redundancy problems with different control mechanisms. They are not interchangeable merely because both can be drawn as a ring.

• RSTP is a spanning-tree protocol between participating bridges. It calculates a loop-free forwarding topology and places a redundant path into a non-forwarding role.
• DLR supervises an EtherNet/IP device-level ring. The ring requires a supervisor, while compatible inline devices operate as ring nodes.

The AL1322 documentation cited for this installation identifies DLR support but does not identify RSTP or MRP support. The AL1342 documentation cited here does not identify DLR support. The SDS-3008 is configured for RSTP, but that does not convert attached products into RSTP bridges or DLR ring nodes.

An RSTP root bridge and a DLR ring supervisor are also different roles. Adding a device that performs one role does not complete a ring based on the other protocol.

Understand why both ports forward

RSTP blocks a redundant path only after its control messages establish that the path returns through participating or suitably transparent bridge interfaces. A two-port industrial device can forward ordinary Ethernet traffic without participating correctly in RSTP. It may also handle the protocol's control frames differently from normal application traffic.

If the SDS-3008 reports both ports as forwarding, treat that status literally: no port is currently protecting the network from the physical loop. Do not wait for the traffic storm to force a topology change. Opening a cable restores a tree because it removes the duplicate path physically.

DLR uses a different decision process. A supervisor monitors ring continuity and controls ring behavior. An inline product without documented DLR ring-node support must not be inserted into that ring path. A non-DLR product belongs on a spur connected through equipment approved to interface that spur with the DLR ring.

Prove the compatibility gap

1. Draw every physical connection, including both ports of each IO-Link master and both SDS-3008 ports used to close the loop.
2. Mark each device as an RSTP bridge, DLR supervisor, DLR ring node, non-ring endpoint, or unknown. Use the product manual's supported-protocol and topology sections, not the presence of two Ethernet connectors.
3. Check whether one protocol covers every device that sits inline in the proposed ring. For this hardware list, the stated documentation does not provide that common protocol.
4. For RSTP, inspect the SDS-3008 status with the loop open. Record the root identity, port roles, port states, and topology-change information. Confirm RSTP is enabled on both intended switch ports.
5. Connect one section at a time. If closing the final section leaves both switch ports forwarding, open the link immediately and reject that RSTP topology.
6. For a DLR design, locate the supervisor status and ring-node list. If no configured supervisor exists, or an inline device lacks documented DLR support, stop the DLR test.

Repeatedly changing IP addresses, replacing management browsers, or increasing ping timeouts wastes time when the network becomes unstable only after the loop closes. Those actions do not remove duplicate Layer 2 paths.

Build a supported topology

The immediate working configuration is a line or star with no closed loop. Keep one proposed ring link disconnected until the redundancy design is changed.

Choose one of these paths:

• Use RSTP: Build the redundant path from bridges whose manuals explicitly support the required RSTP operation. Validate that one redundant port enters a discarding or otherwise non-forwarding state before carrying production traffic. Move devices without a documented inline RSTP role to access spurs.
• Use DLR: Install a documented DLR supervisor and place only documented DLR ring nodes inline. The AL1322 can be considered for this path because DLR is stated for it. Do not place the AL1342 inline unless its applicable manual identifies DLR support.
• Attach a non-DLR device by a spur: Use a suitable three-port DLR tap, with two ports in the ring and one connected to the non-DLR device. A 1783-ETAP is an identified option for this arrangement and can provide the required ring role, but verify its selected role and compatibility in its product documentation before procurement or commissioning.

Do not join an RSTP segment and a DLR ring by connecting two parallel paths between them. The boundary design must expose only one active Layer 2 path unless equipment at that boundary explicitly coordinates the redundancy protocols.

Verify recovery without causing another storm

1. Start with the topology open and confirm stable pings to the SDS-3008 and both IO-Link masters.
2. Confirm that each management page remains reachable and that link states stay steady.
3. For RSTP, close the validated redundant path and confirm one port changes to the expected non-forwarding role. Both ring-facing ports must not remain forwarding when they form the only closed Layer 2 loop.
4. For DLR, confirm that the configured supervisor reports a normal ring and lists the intended ring nodes.
5. Disconnect one ring link. Confirm communication continues over the remaining path and the relevant protocol reports the break.
6. Reconnect the link and verify the topology returns to its normal state without persistent ping loss, repeated link transitions, or rapidly increasing traffic counters.

Run the failure test from each side of the ring. A design is not accepted merely because communication survives one conveniently chosen cable break.

Avoid recurring ring faults

• Do not interpret two Ethernet ports as proof of ring-protocol support.
• Do not mix DLR, RSTP, and MRP names as though they describe a common control plane.
• Do not treat a DLR-capable node as a DLR supervisor unless its documentation explicitly lists and configures that role.
• Do not leave an unprotected loop connected while troubleshooting application tags or IO-Link process data.
• Do not use successful operation in a line topology as proof that the same devices can form a managed ring.
• Do not accept a closed RSTP loop while both redundant ports report forwarding.

FAQ