very DANH on an HSR ring operates in one of six defined modes. They control how the node handles frame forwarding, tagging, and traffic removal. One is mandatory. The rest are optional. If you’re commissioning, testing, or troubleshooting an HSR network, knowing what each mode does — and what it breaks when misapplied — matters.
Table of Contents
The Short Version
| Mode | Name | Mandatory | What it does |
|---|---|---|---|
| H | HSR-tagged forwarding | Yes (default) | Standard ring operation |
| N | No forwarding | No | Disables port-to-port forwarding |
| T | Transparent forwarding | No | Strips HSR tag before forwarding |
| M | Mixed forwarding | No | Handles tagged and untagged frames on same ring |
| U | Unicast forwarding | No | Forwards frames even when it’s the unique destination |
| X | Counter-duplicate suppression | No | Suppresses redundant multicast traffic |
All modes are changeable at runtime using management commands.
Mode H — HSR-Tagged Forwarding (Mandatory, Default)
This is the standard operating mode. Every node on a functioning HSR ring runs Mode H unless explicitly configured otherwise.
What it does:
The DANH inserts the HSR tag on behalf of its host and forwards ring traffic from port A to port B and vice versa, with three exceptions — it does not forward frames it sent itself, it discards duplicate frames, and it does not forward frames for which it is the unique destination.
Those three exceptions are what make the ring work. The source node recognizes its own frames by source MAC address and sequence number, and removes them when they come back around the ring. Duplicates are discarded using the same source MAC + sequence number pair. And unicast frames are absorbed by the intended destination rather than continuing to circulate.
What breaks if you get it wrong:
If a node is left in a non-forwarding mode unintentionally, it silently breaks the ring for all downstream nodes. Supervision frames will still circulate on the intact segment, but nodes beyond the non-forwarding node become unreachable. The Nodes Table will flag missing duplicates, which is your first indicator.
Mode N — No Forwarding (Optional)
In Mode N, the node behaves like Mode H in all respects except one: it does not forward ring traffic from port to port.
What it’s for:
Testing and maintenance. If you need to isolate a segment of the ring without physically disconnecting cables, Mode N lets you do that in software. It’s also used when inserting a new node into a ring — you bring it up in Mode N, verify configuration, then switch to Mode H.
What to watch:
Mode N effectively breaks the ring at that node. Every other node downstream of it loses the duplicate path. This is intentional during testing but catastrophic if left in place on a production ring. The standard is explicit that Mode N is not for normal operation.
Mode T — Transparent Forwarding (Optional)
Mode T is the least intuitive of the six. In this mode, the DANH removes the HSR tag before forwarding the frame to the other port, and sends frames from its host to both ports untagged and without HSR redundancy handling.
What it’s for:
Connecting non-HSR devices or legacy equipment into a segment of the ring where standard Ethernet frames need to pass through. The node acts as a transparent bridge — HSR-tagged traffic is stripped and forwarded as plain Ethernet. This allows non-HSR-aware devices sitting in the ring path to pass traffic without being confused by the HSR tag.
The PICS description puts it clearly: Mode T bridges non-tagged HSR traffic between its HSR ports.
What to watch:
Because Mode T strips the HSR tag and doesn’t discard duplicates, a node in Mode T will forward both copies of every frame to its host. The application or higher layer must be prepared to handle duplicates — the LRE is not performing duplicate discard in this mode. Mode T also doesn’t provide the ring protection that Mode H does. It’s a compatibility mode, not a redundancy mode.
Mode M — Mixed Forwarding (Optional)
Mode M handles both HSR-tagged and non-HSR-tagged traffic on the same ring segment.
What it does:
When injecting frames from the host into the ring, the DANH inserts the HSR tag depending on local criteria — essentially, it decides per-frame whether to tag or not. HSR-tagged frames arriving from ring ports are handled according to Mode H rules. Non-HSR-tagged frames arriving from ring ports are handled according to IEEE 802.1D standard bridging rules.
What it’s for:
Mixed environments where the ring carries both HSR traffic and standard Ethernet traffic simultaneously. This is most relevant in transitional deployments where not all devices on the ring are HSR-capable, or where legacy traffic needs to coexist with HSR traffic on the same physical ring.
What to watch:
Mode M adds complexity to frame handling and to network analysis. Standard bridging behavior — MAC learning, filtering — applies to non-tagged frames, and spanning tree mechanisms may interact if enabled in the network. Mixing tagged and untagged traffic on the same ring requires careful VLAN planning and increases the risk of unexpected frame forwarding behavior. Use Mode M deliberately, not as a workaround.
Mode U — Unicast Forwarding (Optional)
In Mode H, a node that is the unique destination of a unicast frame absorbs it — the frame stops there and is not forwarded further around the ring. Mode U removes this behavior.
What it does:
The node behaves as in Mode H, except it also forwards frames for which it is the unique destination. Both copies continue circulating around the full ring.
What it’s for:
Two use cases. First, network monitoring — a monitoring tool can operate in Mode U to observe all ring traffic, including unicast frames addressed to it, without interrupting normal ring operation. Second, redundant node configurations where two nodes share the same MAC address and both need to receive the same unicast frames.
What to watch:
Mode U increases ring traffic. Every unicast frame addressed to this node traverses the full ring instead of stopping at the destination. On a busy ring this adds load. Don’t leave Mode U enabled on production nodes unless the use case specifically requires it.
Mode X — Counter-Duplicate Suppression (Optional)
Mode X reduces multicast traffic on the ring by suppressing forwarding of frames that have already arrived from the opposite direction.
What it does:
The node behaves as in Mode H, except that a port will not forward a frame that is a duplicate of a frame it already received completely and correctly from the opposite direction. In other words — if port B already received the A-frame, port B does not also forward the B-frame when it arrives, because the destination already has it.
What it’s for:
Reducing the volume of multicast traffic circulating on a busy ring. In Mode H, both copies of every multicast frame traverse the full ring. In Mode X, once a node has confirmed receipt from one direction, it stops the redundant copy from the other direction. This halves the multicast load on ring segments downstream of each Mode X node.
Critical exception: Mode X is not applicable to PTP messages or supervision frames. Both must always traverse the full ring in both directions. If Mode X suppressed supervision frames, nodes would lose the ability to detect path failures. If it suppressed PTP Sync messages, clock synchronization would be disrupted. Any implementation of Mode X must explicitly exclude these frame types.
What to watch:
Mode X only makes sense if VLAN or multicast filtering is also in use. Without filtering, the traffic reduction benefit is limited. Mode X must be carefully implemented to ensure that suppression does not interfere with fault tolerance mechanisms. Verify your fault detection behavior is not affected before enabling Mode X in production.
Combining Modes
The modes are not all mutually exclusive. Mode X is an extension of Mode H — it adds counter-duplicate suppression on top of standard Mode H behavior. Mode U is similarly an extension — it modifies only the unique-destination handling. In practice, a node can implement Mode H as its base and layer Mode X or Mode U behavior on top.
Modes N, T, and M are distinct operating states that replace Mode H behavior rather than extending it. A node cannot be in Mode H and Mode T simultaneously — they define fundamentally different forwarding behavior.
When to Use Each Mode — Quick Reference
Normal operation: Mode H on all nodes, always.
Testing a new node before inserting into production ring: Mode N — bring up the node silently, verify config, then switch to Mode H.
Network monitoring / traffic capture on the ring: Mode U — lets a monitoring node receive all unicast traffic addressed to it without stopping it on the ring.
Multicast-heavy rings where bandwidth is a concern: Mode X — reduces duplicate multicast load, but only with proper multicast filtering in place.
Legacy or mixed-protocol ring segments: Mode T or Mode M — use T for fully transparent pass-through, M for mixed HSR and standard Ethernet on the same ring.
Any production ring that isn’t one of the above: Mode H. Default. Don’t change it without a specific reason.
Reboot Behavior
One more thing worth knowing: when a node reboots, it shall remain silent on its HSR ports for a minimum of 500 ms before transmitting. It should then start by sending a supervision frame. This prevents a rebooting node from injecting stale or incorrectly sequenced frames into the ring during startup.
Conclusion
The six modes give you precise control over how each node participates in the ring — but that flexibility comes with responsibility. Mode H is the only mode that should be running on a production ring under normal conditions. Every other mode exists for a specific purpose: testing, monitoring, legacy compatibility, or traffic optimization.
The most common mistakes are leaving a node in Mode N after commissioning, enabling Mode X without multicast filtering in place, or using Mode T without accounting for the fact that the host will receive duplicate frames. None of these are obvious failures — the ring keeps running, but not the way you expect.
Know what mode each node is in. Verify it during commissioning. Check it again during troubleshooting before assuming the fault is elsewhere.