PRP HSR, MRP and RSTP: Industrial Ethernet Redundancy Compared (2026)

A plant network does not fail the way an office network fails. When a forklift severs a fibre, nobody notices a slow web page; a drive loses its PROFINET connection, a protection relay misses a GOOSE trip message, and a line stops. The question is therefore not “do we have a redundant ring?” but “how many milliseconds of silence can this application survive, and which protocol guarantees fewer than that?” PRP HSR (the two zero-recovery-time protocols in IEC 62439-3) answer with duplication; MRP answers with a fast, managed ring; RSTP answers with a general-purpose spanning tree that was never designed for a 10 ms budget.

This matters now because Ethernet is carrying more of the control loop: PROFINET I/O, EtherNet/IP, substation process buses and, increasingly, TSN traffic. Picking the wrong redundancy mechanism is a decision you discover during the first cable-pull test, or worse, the first real fault.

You will leave with a mechanism-level understanding of each protocol, worked failover arithmetic, a decision matrix, runnable Python and Wireshark examples, and a list of the failure modes that defeat redundancy in practice.

What this covers: why redundancy is needed, how RSTP, MRP, DLR, PRP and HSR actually work at frame level, failover maths, RedBox and substation use, the link to TSN FRER (IEEE 802.1CB), monitoring, failure modes and a selection checklist.

Context and Background

Industrial Ethernet inherited its redundancy story from enterprise IT. The Spanning Tree Protocol (STP, IEEE 802.1D) breaks loops by blocking links, and when a link fails it unblocks a backup. The original STP needs tens of seconds to converge; its successor, the Rapid Spanning Tree Protocol (RSTP, standardised as IEEE 802.1w and later folded into IEEE 802.1D-2004 and IEEE 802.1Q), brought a direct-failure reconvergence down to the sub-second range (PingLabz comparison of STP and RSTP). For an office, that is excellent. For a servo axis with a 1 ms cycle, it is geological time.

Automation vendors responded with proprietary rings (Hirschmann’s HiPER-Ring dates to 1998 and is the direct ancestor of MRP, per Wikipedia’s MRP entry), then standardised the better ones. The result is the IEC 62439 family, “High availability automation networks”:

IEC 62439-1 defines general concepts and the calculation methods for recovery time.
IEC 62439-2 defines the Media Redundancy Protocol (MRP), a ring protocol with a single manager.
IEC 62439-3 defines both the Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR).
Further parts cover Cross-network Redundancy (CRP, part 4), Beacon Redundancy (BRP, part 5) and Distributed Redundancy (DRP, part 6), which see far less deployment.

The editions matter when you write a specification. According to the IEC webstore, IEC 62439-2 is available as a 2021 edition (edition 3.0) with a 2023 corrigendum, and IEC 62439-3 is available as a 2021 edition (edition 4.0), also with a 2023 corrigendum (IEC 62439-3:2021/COR1:2023). Cite the edition in procurement documents rather than “IEC 62439”, because the 2010 and 2012 PRP editions are not interoperable in all respects with later ones (more on that below).

Outside IEC, ODVA’s Device Level Ring (DLR) covers EtherNet/IP, and IEEE 802.1CB Frame Replication and Elimination for Reliability (FRER) brings PRP-style duplication to Time-Sensitive Networking. If you are deciding between the underlying real-time Ethernets first, read our PROFINET vs EtherCAT vs OPC UA FX comparison; redundancy choice follows from that decision rather than preceding it.

What “redundancy” has to mean in a control network

Two quantities define the requirement, and conflating them is the most common specification error.

Recovery time: the interval after a fault during which frames are lost or delayed. RSTP and MRP have a non-zero recovery time. PRP and HSR have, by design, a recovery time of zero because every frame already travels on two paths.
Application tolerance: how long the consumer can go without data. In PROFINET this is the watchdog (the cycle time multiplied by a watchdog factor); in IEC 61850 GOOSE it is the retransmission schedule; in a Modbus/TCP poll loop it is the timeout and retry policy.

A redundancy protocol is adequate only when worst-case recovery time is smaller than application tolerance with margin. Everything else in this article is about calculating and engineering that inequality.

Reference Architecture: Four Ways to Survive a Cable Cut

Direct answer: RSTP and MRP restore connectivity after a failure by reconfiguring a blocked path, so they lose frames for a recovery period. PRP and HSR never block a path; the sender transmits every frame twice over disjoint paths and the receiver discards the later copy, so a single failure costs no frames and no time. The price is doubled traffic and special end-node or RedBox hardware.

Figure 1: The four redundancy families side by side. PRP uses two independent LANs, HSR uses a ring where every node forwards, MRP uses a ring with one blocked manager port, and RSTP uses an arbitrary mesh with elected blocked ports.

The figure separates two philosophies. On the left, reconvergence protocols (RSTP, MRP, DLR) keep one logical path active and activate the spare when a fault is detected. On the right, duplication protocols (PRP, HSR, FRER) keep both paths active at all times. Everything that follows, from failover time to cost, flows from that single design choice.

RSTP in a ring: general purpose, hard to bound

RSTP elects a root bridge, assigns every port a role (root, designated, alternate, backup) and keeps alternate ports in a discarding state. When a root port fails, the alternate port can transition to forwarding after a proposal/agreement handshake that needs roughly one BPDU round trip on a point-to-point link. That is why direct-failure convergence can be a few tens or hundreds of milliseconds in a small network.

The problem is the second sentence in the fine print. Hello BPDUs default to every 2 seconds, and a neighbour is declared dead after 3 missed hellos, around 6 seconds, when the loss is indirect (not signalled by loss of link on the local port). The same source quotes about 6 seconds for indirect failures (PingLabz). In a ring built from unmanaged segments, media converters or a “dumb” switch in the loop, a break is an indirect failure from the point of view of the bridges that matter.

Three further properties limit RSTP as a control-network ring:

Convergence depends on topology. Proposal/agreement propagates bridge by bridge, so a 30-switch ring converges more slowly than a 5-switch ring, and the relationship is not tightly specified.
Root placement changes behaviour. A root bridge in the wrong place yields paths that are long for the traffic that matters. Teams must pin the root and the backup root by priority.
Everything shares the broadcast domain. A topology change flushes MAC address tables, which makes switches flood unicast traffic temporarily and can briefly saturate slow links.

RSTP remains an excellent choice for the uplink tier, between distribution switches and the plant core, and for loop protection on ports that should never form a loop. It is a poor choice for the cell ring.

MRP: the PROFINET ring

The Media Redundancy Protocol (IEC 62439-2) is deliberately simple. A ring contains one Media Redundancy Manager (MRM) and any number of Media Redundancy Clients (MRCs). In normal operation the ring is “closed”: the MRM blocks one of its two ring ports for ordinary traffic so no loop forms, but it keeps sending test frames around the ring on both ring ports. MRP frames use EtherType 0x88E3 and a type-length-value encoding, and blocked ports still pass MRP control frames (Wikipedia: Media Redundancy Protocol).

When a link or switch fails, one of two things happens:

An MRC notices link-down on a ring port and sends a LinkChange (link down) frame to the MRM. The MRM opens its blocked port and sends a TopologyChange frame so clients flush their MAC tables.
Where the failure is invisible to link-state (a failed middle node behind a media converter), the MRM stops receiving its own test frames. After a configured number of missed tests, it declares the ring open, opens the blocked port and signals the change.

The ring is now “open”, a logical line, and traffic flows. When the fault clears, the MRM sees test frames return and restores the blocked port, again with a topology-change notification. This restore step can itself cost frames, which is why a repair can be as disruptive as the failure.

MRP specifies selectable maximum recovery times. According to the sources reviewed, rings of up to 50 switches use worst-case recovery profiles of 500 ms, 200 ms or 30 ms, while a 10 ms profile applies to rings of up to 14 switches (Wikipedia; Cisco’s industrial MRP guide). Product support varies: the Cisco IE 2000/4000/5000 guide states that the platforms it covers support only the 200 ms (default) and 500 ms profiles, not the 30 ms or 10 ms ones. Always check the datasheet of every switch in the ring, since the manager’s profile must be achievable by the slowest client.

Two MRP variants matter in practice. MRP interconnection lets two rings couple through a pair of interconnection ports with their own manager, so you can build rings of rings without a single point of failure. Media Redundancy Automanager (MRA), supported by some vendors, lets several candidate managers elect one by priority at startup, removing the need to hand-pick the manager.

PRP: two networks, nothing shared

The Parallel Redundancy Protocol (IEC 62439-3 clause 4) is the cleanest idea in the family. Build two completely independent LANs, LAN A and LAN B, with no connection between them. Every Doubly Attached Node (DAN, specifically a DANP) has one port on each LAN, with the same MAC and IP address on both.

When a DAN sends a frame, its PRP layer appends a six-octet Redundancy Control Trailer (RCT) and sends one copy on each LAN. The RCT carries a 16-bit sequence number, a 4-bit LAN identifier (A or B), a 12-bit size field and the 16-bit suffix 0x88FB that marks the trailer. The receiver’s PRP layer accepts the first copy that arrives, strips the trailer and discards the second, recognising duplicates by the pair of source address and sequence number.

Figure 2: PRP frame handling. The sender duplicates the frame with a Redundancy Control Trailer, each LAN carries one copy, and the receiver forwards the first to the upper layers and discards the duplicate.

Three consequences follow from the design:

Zero recovery time. If LAN A loses a link, copies still arrive via LAN B. Nothing reconverges because nothing was ever blocked.
Switches are ordinary. The network infrastructure needs no PRP awareness. The LANs can even use different topologies, vendors or media, which is a strong argument for brownfield upgrades.
Single-attached devices still work. A Singly Attached Node (SAN) connects to just one LAN and treats the trailer as padding. Its availability is that of its one LAN. A RedBox (redundancy box) connects a SAN to both LANs and plays the DAN’s role on its behalf; a related VDAN is a virtual DAN, a SAN behind a RedBox as seen by the rest of the network.

The cost is straightforward: two parallel networks, two network ports per device, and doubled traffic on the wire. The RCT also lengthens a frame by six octets, which matters for frames near the maximum size; the sources reviewed advise that legacy devices should tolerate frames up to 1528 octets.

HSR: the ring that is the network

High-availability Seamless Redundancy (HSR, also IEC 62439-3, clause 5) applies the same duplicate-and-discard principle but removes the second LAN. Each HSR node has two ports and contains a small embedded switch, so nodes chain directly into a ring and no external switches are needed. When a node sends a frame, it inserts a six-octet HSR tag (EtherType 0x892F, carrying a path identifier, frame size and sequence number) after the source address and sends one copy out of each port, one clockwise and one counter-clockwise.

Each intermediate node forwards a frame to its other ring port unless it has already forwarded that frame (a duplicate, detected by source address and sequence number) or it is the originator, which removes its own frames from the ring. The destination receives two copies in a fault-free ring, hands the first to the application and drops the second. If a link breaks, the surviving direction still delivers the frame, with no reconvergence.

Figure 3: HSR node logic. A source tags and sends on both ports; every node checks the duplicate table, forwards new frames, delivers frames addressed to it once and discards repeats or its own frames.

The attractions are real: no switches, no recovery time, and per-hop latency that can be tiny if the hardware forwards cut-through. The HSR tag lets a node decide forwarding without waiting for the whole frame, and Wikipedia’s HSR entry quotes roughly 5 µs per hop at 100 Mbit/s with FPGA support (Wikipedia: HSR).

The limits are real too:

Load. In a plain ring, every multicast or unknown-destination frame circulates in both directions and each unicast frame is carried over both paths, so the nominal 100 or 1000 Mbit/s capacity is shared by duplicates. The same source notes that multicast bandwidth in an HSR ring is about half of what an RSTP ring offers, even though nominal bandwidth remains available. Traffic-reduction modes exist (mode U for unicast avoidance, port locking for ports facing absent nodes) but they trade away supervision or add configuration.
Ring size and latency. Worst-case latency grows with hop count. See the arithmetic below.
Hardware. HSR needs HSR-capable end devices or RedBoxes; a standard PC network card cannot join the ring without software support or an FPGA adapter.
Standard devices. A SAN cannot connect directly. It must sit behind a RedBox, and the RedBox is a single point of failure for that device.

PRP and HSR can be combined: a QuadBox (a four-port device) couples an HSR ring to two PRP LANs, giving a redundant interconnection with no single point of failure. The Wikipedia HSR entry confirms that the two networks can be joined without a single point of failure and that the same nodes can serve both; it does not describe the QuadBox by name, so the term here follows vendor usage.

DLR: EtherNet/IP’s answer

ODVA’s Device Level Ring is the EtherNet/IP equivalent of MRP. A ring supervisor blocks traffic on one of its ring ports, sends beacon frames in both directions (default beacon interval 400 µs, minimum 100 µs) and sends announce frames once per second. Beacon-based nodes recover in about 3 ms on a 50-node ring and announce-based nodes in about 4 ms; ODVA’s guidelines recommend keeping rings below 50 nodes, require embedded-switch devices with two external ports, and forbid ordinary infrastructure switches inside the ring (use a DLR tap or a DLR-capable switch) (ODVA DLR guidelines, PUB00316). DLR handles only a single ring, not overlapping rings.

DLR is therefore much faster than MRP’s common 200 ms profile, because the supervisor is injecting beacons at sub-millisecond intervals and nodes detect link failure immediately. It is also much narrower: it only exists in the EtherNet/IP ecosystem. If you run PROFINET, think MRP; if you run EtherNet/IP, think DLR or PRP.

FRER: PRP’s idea inside TSN

IEEE 802.1CB-2017, Frame Replication and Elimination for Reliability, moves duplication into the bridges. A stream is assigned a sequence number at a replication point, copies travel over disjoint paths configured by the network (often alongside IEEE 802.1Qbv scheduling), and an elimination function at the merge point discards duplicates using a sequence recovery algorithm. Unlike PRP, FRER is per-stream rather than per-link, so you can protect only the streams that need it, and the intermediate bridges participate. That is both its strength (selective protection, topology freedom) and its cost (configuration, TSN-capable hardware). See our TSN reference architecture and the IEC/IEEE 60802 profile article for how FRER fits the converged industrial profile.

Practically, FRER is where industrial redundancy is heading for greenfield TSN networks. PRP and HSR remain the proven choice where a device ecosystem already exists, particularly in power utilities.

Deeper Analysis: Failover Arithmetic and the Decision Matrix

The inequality that decides the whole project is: worst-case network recovery time plus detection delay must be smaller than the application’s tolerance. The following numbers are illustrative worked examples built from the published parameters above and from the PROFINET convention that the watchdog equals the send clock times the reduction ratio times a watchdog factor. Always recompute with your own device settings.

Worked example 1: PROFINET over an MRP ring

Suppose an I/O controller exchanges data with a drive at an 8 ms update interval and the device uses a watchdog factor of 3. The device declares the connection lost after 24 ms of silence.

MRP profile	Worst-case recovery	Survives 24 ms watchdog?	Notes
500 ms	up to 500 ms	No	I/O connection aborts, drive faults, re-parameterisation required
200 ms	up to 200 ms	No	Same outcome; common default on many switches
30 ms	up to 30 ms	Marginal, no	30 ms exceeds 24 ms; raise factor or cycle
10 ms	up to 10 ms	Yes, with 14 ms margin	Only for rings of up to 14 switches

The conclusion is not “MRP is bad”. It is that MRP must be sized against the slowest watchdog in the ring. To keep a 200 ms ring viable, either lengthen watchdogs (a factor of 30 at an 8 ms update interval gives 240 ms), accept that devices drop and rejoin, or move the time-critical segment to a PRP or HSR design. PROFINET also has device and controller redundancy concepts (system redundancy with S2 and R1/R2 variants), but those protect devices and controllers and do not replace network redundancy. Siemens’ documentation is the right place to verify per-product behaviour.

Worked example 2: RSTP ring versus a 100 ms tolerance

Take a SCADA poll loop with a 1 s scan and a 3 s timeout. A direct link failure on an RSTP ring that converges in a few hundred milliseconds is invisible. An indirect failure that takes the 6 s the hello-timer arithmetic permits (three missed 2 s hellos) exceeds the 3 s timeout, so the master marks the outstation offline and raises an alarm. Remedies: shorten the hello time if the platform allows it, ensure link-loss is reported on all ring ports (no unmanaged devices in the loop), or choose MRP where the topology allows. RSTP is not wrong here; the application’s timeout and the failure type decide the outcome.

Worked example 3: HSR latency in a 25-node ring

For a ring of N = 25 nodes the farthest destination from a source is about 12 hops in the shorter direction. Take a maximum-length frame of 1518 octets plus preamble and inter-frame gap, which is 1538 octets, or 12,304 bits. At 100 Mbit/s that serialisation takes 12,304 / 100,000,000 = 123 µs.

Store-and-forward per hop: each of 12 hops adds about 123 µs of serialisation plus processing, so roughly 12 × 123 µs ≈ 1.5 ms for the longest frames.
Cut-through per hop: using the roughly 5 µs figure quoted for FPGA-based nodes at 100 Mbit/s, 12 hops add about 60 µs.
After a break: the shorter path may vanish and the surviving direction can be up to 24 hops, doubling the path. The frame still arrives, only later.

For small control telegrams (say 100 octets, 8.3 µs at 100 Mbit/s per hop plus 0.96 µs inter-frame gap) store-and-forward adds roughly 10 µs per hop, so a 12-hop path lands near 110 µs. These are illustrative estimates; real device latencies come from datasheets and must be measured.

Worked example 4: PRP skew tolerance

PRP’s receivers accept the later copy only if it arrives within a window; the standard defines the duplicate-discard algorithm and the parameters, and the detail (entry forget times) is implementation-specific within bounds I could not verify here, so check the clause text. The engineering point is simple: the two LANs may differ in latency, and the effective latency seen by the application is that of the faster LAN while both are healthy and that of the surviving LAN after a fault. A LAN B that is much longer than LAN A therefore causes a visible latency step on failure of LAN A, even though no frames are lost.

Decision matrix

Criterion	RSTP ring	MRP (IEC 62439-2)	DLR (ODVA)	PRP (IEC 62439-3)	HSR (IEC 62439-3)	FRER (IEEE 802.1CB)
Recovery on single fault	Sub-second to seconds	10 to 500 ms profiles	About 3 to 4 ms (50 nodes)	Zero	Zero	Zero for protected streams
Topology	Mesh or ring	Single ring, rings of rings via interconnection	Single ring	Two independent LANs	Ring or ring of rings via QuadBox	Any with disjoint paths
Infrastructure	Standard managed switches	MRP-capable switches	DLR devices or taps	Standard switches, two copies	No switches, HSR nodes and RedBoxes	TSN bridges
Extra cabling	Minimal	Minimal	Minimal	Double network	One extra ring closure	Depends on paths
Bandwidth overhead	None	None	None	Duplicate traffic on each LAN	Duplicate traffic around the ring	Only protected streams
Typical ecosystem	IT backbone, uplinks	PROFINET	EtherNet/IP	IEC 61850, utilities, high-availability SCADA	IEC 61850 process bus, drives	TSN greenfield
Main weakness	Hard to bound	Fixed ring, repair also disrupts	Vendor ecosystem	Cost, cabling, two networks	Ring size, hardware, RedBoxes	Complexity, maturity

Use this table as a screening tool, not a verdict. Two networks at the same site often need different answers: PROFINET cell rings on MRP, a PRP backbone for the supervisory layer, and RSTP on the uplinks.

Substations: why PRP and HSR won

IEC 61850 substations are the textbook case for zero-recovery redundancy. Protection signalling is carried by GOOSE messages and, on the process bus, by sampled values, both mapped directly onto Ethernet at layer 2. A protection function tolerates only a few milliseconds of delay, and a reconverging network offers no guarantee against losing a trip or sample. Substation designs therefore commonly pair IEC 61850 with IEC 62439-3, using PRP on the station bus and HSR on process-bus rings (a common pattern, not a universal rule); the Wikipedia HSR entry also notes that the PTP Industry Profile in Annex C of IEC 62439-3 was adopted as IEC/IEEE 61850-9-3, with 1 µs accuracy over a 16-node ring. See our IEC 61850 GOOSE, MMS and Sampled Values primer for the application layer.

Putting it on a diagram: what each tier uses

A realistic plant combines the protocols by tier, which Figure 4 sketches. The cell tier uses MRP or DLR rings tied to the controllers. The distribution tier uses either an RSTP mesh or, if the control network crosses buildings, PRP LANs. The core uses redundant routed links. Zero-recovery protocols are reserved for the loops that cannot lose a frame.

Figure 4: A tiered plant design. Fast rings protect machine cells, PRP or RSTP protect the distribution tier, and routing protects the core, with PRP or HSR added only where zero recovery is required.

Mixing tiers raises a design question that catches teams out: where one redundancy domain hands over to another, the handover point is itself a single point of failure unless it is duplicated. MRP interconnection, redundant gateways and dual-homed RedBoxes exist for this reason.

Hands-On: Calculators, Simulators and Wireshark Filters

Three small tools make the arithmetic above repeatable. The first checks whether a recovery profile survives a PROFINET watchdog; the second simulates PRP duplicate discard; the third builds a PRP-style frame with Scapy so you can see the trailer in a capture.

Recovery budget calculator

#!/usr/bin/env python3
"""Check whether a redundancy protocol's worst-case recovery fits an application watchdog."""
from dataclasses import dataclass

# Worst-case recovery in milliseconds. MRP profiles per IEC 62439-2 as summarised in public
# sources; RSTP figure is a planning assumption, not a spec value. Replace with datasheet values.
RECOVERY_MS = {
    "mrp-500": 500.0,
    "mrp-200": 200.0,
    "mrp-30": 30.0,
    "mrp-10": 10.0,
    "dlr-50node": 4.0,       # about 3-4 ms for 50 nodes per ODVA guideline
    "rstp-direct": 500.0,    # planning assumption, measure in your own network
    "rstp-indirect": 6000.0, # 3 missed 2 s hellos
    "prp": 0.0,
    "hsr": 0.0,
}

@dataclass
class Application:
    name: str
    update_ms: float
    watchdog_factor: int

    @property
    def watchdog_ms(self) -> float:
        return self.update_ms * self.watchdog_factor

def check(app: Application, proto: str, margin: float = 0.5) -> str:
    rec = RECOVERY_MS[proto]
    ok = rec <= app.watchdog_ms * margin
    return (f"{app.name:<18} {proto:<14} recovery={rec:>7.1f} ms "
            f"watchdog={app.watchdog_ms:>7.1f} ms -> {'OK' if ok else 'FAIL'}")

if __name__ == "__main__":
    drive = Application("servo-drive", update_ms=8, watchdog_factor=3)
    scada = Application("scada-poll", update_ms=1000, watchdog_factor=3)
    for proto in RECOVERY_MS:
        print(check(drive, proto))
    print()
    for proto in ("rstp-direct", "rstp-indirect", "mrp-200", "prp"):
        print(check(scada, proto))

The margin parameter encodes engineering judgement: requiring recovery to fit within half the watchdog leaves room for detection jitter and for a second event. Use real figures from vendor datasheets before you rely on any result.

PRP duplicate-discard simulator

#!/usr/bin/env python3
"""Simulate PRP receiver duplicate discard with two LANs of different latency."""
import heapq
import random

def simulate(n_frames=10, lan_a_ms=1.0, lan_b_ms=1.6, drop_a_after=5, seed=1):
    random.seed(seed)
    events = []            # (arrival_time, lan, seq)
    t = 0.0
    for seq in range(n_frames):
        t += 2.0           # one frame every 2 ms
        if not (seq >= drop_a_after):          # LAN A fails after drop_a_after frames
            heapq.heappush(events, (t + lan_a_ms + random.random() * 0.1, "A", seq))
        heapq.heappush(events, (t + lan_b_ms + random.random() * 0.1, "B", seq))
    seen, delivered = set(), []
    while events:
        at, lan, seq = heapq.heappop(events)
        if seq in seen:
            print(f"{at:7.2f} ms  seq={seq:2d} LAN {lan}: duplicate, discarded")
            continue
        seen.add(seq)
        delivered.append((seq, lan, at))
        print(f"{at:7.2f} ms  seq={seq:2d} LAN {lan}: delivered")
    lost = set(range(n_frames)) - seen
    print(f"\nframes sent={n_frames} delivered={len(seen)} lost={len(lost)}")
    return delivered

if __name__ == "__main__":
    simulate()

Run it and you will see the first five frames delivered via the faster LAN A with LAN B’s copies discarded, then frames six onward delivered via LAN B after LAN A fails, with a small latency step and zero loss. A real PRP implementation keys duplicates by source MAC and sequence number and bounds the table with a time window, which this sketch omits.

Building a PRP-style frame with Scapy

#!/usr/bin/env python3
"""Append a PRP Redundancy Control Trailer to an Ethernet frame (lab use only)."""
import struct
from scapy.all import Ether, IP, UDP, Raw, sendp

def rct(seq: int, lan_id: int, lsdu_size: int) -> bytes:
    """6-octet RCT: 16-bit seq, 4-bit LAN id, 12-bit size, 16-bit suffix 0x88FB."""
    lan_and_size = ((lan_id & 0xF) << 12) | (lsdu_size & 0x0FFF)
    return struct.pack("!HHH", seq & 0xFFFF, lan_and_size, 0x88FB)

def prp_frames(payload: bytes, seq: int):
    base = Ether(dst="02:00:00:00:00:02", src="02:00:00:00:00:01") / \
           IP(dst="192.0.2.2", src="192.0.2.1") / UDP(sport=5000, dport=5000) / Raw(payload)
    size = len(bytes(base)) - 14           # LSDU size excludes the Ethernet header
    # LAN identifiers 0xA and 0xB are the commonly documented values; verify against the standard.
    a = bytes(base) + rct(seq, 0xA, size)
    b = bytes(base) + rct(seq, 0xB, size)
    return a, b

if __name__ == "__main__":
    fa, fb = prp_frames(b"hello-redundant-world", seq=1)
    sendp(Ether(fa), iface="eth0", verbose=False)   # LAN A interface
    sendp(Ether(fb), iface="eth1", verbose=False)   # LAN B interface

This is a lab exercise: real stacks pad to the minimum frame length before adding the trailer, and the exact LAN identifier and size encoding must be validated against IEC 62439-3 before you use it for anything other than a packet-capture demonstration.

Wireshark display filters

Capture on a mirror port or a test access point. The EtherType-based filters below work without any dissector:

eth.type == 0x88e3            # MRP control frames (test, topology change, link change)
eth.type == 0x892f            # HSR-tagged frames
eth.trailer                   # frames with trailing bytes; PRP RCT ends in 88 FB
eth.dst == 01:15:4e:00:01:00  # PRP supervision frames (commonly documented address)
eth.dst == 01:15:4e:00:01:01  # HSR supervision frames (commonly documented address)
lldp                          # neighbour discovery, useful for ring topology audits

Wireshark also ships dissectors for these protocols whose field names differ between versions, so confirm names in the display filter reference for your version. A reliable validation pattern: pull one ring cable, filter on the relevant control frames and measure the gap between the last frame before the fault and the first frame after it. For PRP and HSR the gap should show nothing; for MRP it should fit the configured profile.

Monitoring: latent faults are the real enemy

Zero-recovery redundancy has a subtle trap. Because the application never notices a first failure, a broken LAN B can sit undetected for months until LAN A also fails. Both PRP and HSR therefore have supervision frames (sent periodically, per node) that let monitoring systems learn each node’s state, and SNMP or management objects expose per-port duplicate and error counters. Alert on three things: a node whose supervision frames arrive on only one LAN, a rising count of single-copy deliveries, and any asymmetry between LAN counters. Treat a single-LAN node as an incident, not an informational message.

For MRP, monitor the manager’s ring state (closed or open), the count of topology changes per day and the manager’s identity. A ring that is “open” at 3 a.m. is still working, just unprotected.

Trade-offs, Gotchas, and What Goes Wrong

Redundancy fails most often at the seams the design diagram does not draw. Common failure modes:

Common-cause failures. Two PRP LANs routed through the same cable tray, powered by the same UPS, or fed from the same cabinet fan share a fate. Independence must be physical: separate routes, separate power feeds, separate switches. The same applies to both directions of an HSR ring that run through one conduit.
Latent faults. As discussed, undetected degradation turns a single failure into an outage. Redundancy without monitoring is a delayed failure.
Unmanaged devices in the loop. A single unmanaged switch or media converter in an MRP or RSTP ring hides link-down events, so the protocol relies on slow timeouts. ODVA explicitly prohibits non-DLR infrastructure switches inside a DLR ring for a similar reason.
Wrong manager or root. An RSTP root that drifts to an access switch, or an MRP ring with two managers (a misconfiguration) produces loops or blocked rings. Pin roles in configuration, use MRA only where you understand the election.
Mixed profiles. Setting a 30 ms manager profile on a ring whose clients support only 200 ms yields recovery timing nobody guaranteed. Validate every device against the profile.
Repair events. Restoring a failed MRP link can briefly disrupt traffic, as the blocked port re-blocks. Schedule maintenance and test the restoration, not only the failure.
Duplicate-sensitive applications. PRP and HSR hide duplicates from the application, but devices that bypass the redundancy layer, mirror ports, capture appliances or IDS sensors will see both copies. Size monitoring for double the traffic.
Broadcast storms at integration points. Cross-connecting two protocols (an MRP ring dual-homed into an RSTP mesh without MRP interconnection) can create loops. Cisco notes that MRP ports drop STP BPDUs and that MRP cannot share an interface with REP, STP, Flex Links or Dot1x on its platforms; check the equivalent restrictions on yours.
Cybersecurity is a separate problem. Redundancy raises availability but does nothing against a malicious actor who can inject MRP topology-change frames or spoof supervision frames. Segment control networks, restrict management access and apply the IEC 62443 zone and conduit model. For protocol-level authentication on top, see our OPC UA security guide.
Wireless segments are not covered. Radios in the loop reintroduce roaming gaps that no wired standard fixes. Our private 5G, Wi-Fi 7 and TSN comparison covers what wireless can and cannot promise.

There is also an economic trade-off. PRP doubles switches and cabling; HSR trades switches for more capable end nodes and a hard ceiling on ring size; MRP is cheap but has a non-zero outage. The cost of downtime per minute at your site is the number that settles it.

Practical Recommendations

Choose by the application’s tolerance, then by ecosystem, then by cost, in that order.

If the consumer tolerates hundreds of milliseconds (SCADA polling, historians, HMI), use RSTP in the distribution tier and keep the ring small, with managed devices only.
If the plant runs PROFINET and loses I/O at 24 to 50 ms, use MRP with the fastest profile all ring devices support, keep the ring under the limit for that profile, and size watchdogs deliberately.
If you run EtherNet/IP, use DLR for cell rings and keep it free of ordinary switches.
If a single lost frame is unacceptable (protection, interlocks, safety-adjacent signalling), use PRP for a switched network or HSR for a switchless ring, plus supervision monitoring.
If you are building a new TSN network, evaluate FRER for the specific streams that need it.

A short design checklist:

Write the application’s tolerance in milliseconds before choosing a protocol.
Compute worst-case recovery including detection delay and compare with margin.
Confirm every device supports the chosen profile and edition of the standard.
Make redundant paths physically independent (route, power, enclosure).
Monitor supervision frames, ring state and per-LAN counters, and alert on single-path operation.
Pull cables, power off switches and restore them during commissioning; record the measured gap.
Document the handover between redundancy domains and duplicate it.
Retest after every firmware update, since timing behaviour can change.

Frequently Asked Questions

What is the difference between PRP and HSR?

Both are defined in IEC 62439-3 and use the same duplicate-and-discard principle, so both have zero recovery time. PRP uses two independent parallel LANs built from ordinary switches, with a trailer added to each frame. HSR places the nodes themselves in a ring, with a tag inserted in the header, and needs no external switches. PRP costs more cabling and switches; HSR needs HSR-capable devices and limits ring size and load.

Is MRP faster than RSTP?

Yes, in the worst case. MRP (IEC 62439-2) defines recovery profiles of 500, 200, 30 and 10 ms, the shortest for rings of up to 14 switches, whereas RSTP is typically sub-second for direct link failures and can take several seconds when a failure is detected only through missed hello BPDUs. MRP also bounds the result, while RSTP depends on topology. In practice, check which MRP profile your switches actually support, because many support only 200 or 500 ms.

Can PRP and HSR be used together?

Yes. The standard describes coupling an HSR ring to PRP LANs so that no single device failure disconnects them. A four-port device, commonly called a QuadBox, connects the ring to both LANs. This is common in substations, where HSR rings on a process bus connect upward to a PRP station bus. Plan the coupling devices as redundant pairs, since a single coupler would reintroduce a single point of failure.

Which redundancy protocol does PROFINET use?

PROFINET networks normally use MRP (IEC 62439-2) for ring redundancy, with the I/O controller or a designated switch as the manager. The ring recovery time must be shorter than the device watchdog, or devices will drop and re-establish their connections. PROFINET also supports other options, including PRP in some deployments, and has separate controller and device redundancy concepts. Confirm per-product support in the vendor documentation.

Do PRP and HSR protect against cyberattacks?

No. They protect against random physical faults: cable cuts, port failures, power loss to a switch. An attacker with network access can still flood both LANs, inject spoofed supervision or control frames, or compromise an endpoint. Pair redundancy with network segmentation, access control and monitoring following IEC 62443, and treat redundancy and security as separate layers with separate tests.

How do I measure real failover time?

Use a capture on a mirror port or test access point, keep a continuous traffic stream with sequence numbers or timestamps, and physically pull a ring cable or power off a switch. The gap between the last frame before the fault and the first after it is your measured outage. Repeat for several fault positions, and also test restoring the link, because repair can disrupt traffic. For PRP and HSR you should see no gap.

Industrial Ethernet Redundancy: PRP, HSR, MRP and RSTP Ring Topologies Compared (2026)