PRP and HSR Give You Zero-Gap Redundancy — and Hide a Dead LAN

The LAN that died three weeks ago

A substation gateway was polling fine. GOOSE was flowing, the HMI was green, nobody had a complaint. During an unrelated switch swap the technician noticed that one of the two redundant networks — LAN B — had been physically disconnected at a patch panel. For roughly three weeks the whole station had been running on a single network with no redundancy at all, and not one alarm had fired.

That is not a bug. That is exactly how PRP is supposed to behave, and it is the first thing you have to understand before you commission it. Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR), both defined in IEC 62439-3, give you failover with zero recovery time — no reconvergence, no dropped frame. The price is that a single failure is invisible to the application by design. If you don't monitor the redundancy itself, you find out it was gone only when the second path fails and everything stops at once.

Why RSTP and MRP aren't good enough here

The ring-redundancy article on this site covers RSTP and MRP, and for a plant control network they're usually fine. RSTP reconverges in a second or two; MRP gets you into the low hundreds of milliseconds. That's a real gap where frames are lost.

For a station bus carrying GOOSE and especially a process bus carrying IEC 61850-9-2 sampled values, that gap is unacceptable. Sampled values arrive at 4000 or 4800 samples/second and a protection function can't wait 200 ms for a spanning-tree recalculation. So IEC 62439-3 takes a different approach: don't recover from a failure — send everything twice, over two paths, all the time, and let the receiver throw away the copy it doesn't need. When one path dies there is nothing to recover, because the other copy already arrived.

PRP: two independent LANs, duplicate everything

A PRP node — a Doubly Attached Node, DANP — has two Ethernet ports connected to two completely independent networks, LAN A and LAN B. When it transmits, it sends the same frame out both ports. It appends a 6-byte Redundancy Control Trailer (RCT) before the FCS: a 16-bit sequence number, a 4-bit LAN identifier (0xA or 0xB), a 12-bit frame size, and the PRP suffix 0x88FB.

The receiver keeps a small table keyed by source MAC. The first copy of a given (source, sequence number) gets passed up to the application; the duplicate that arrives on the other LAN a few microseconds later is discarded. Entries age out after a short window (EntryForgetTime, on the order of 400 ms) so sequence numbers can wrap and reuse safely.

The two things that make PRP attractive in a retrofit:

• The two LANs are ordinary switched Ethernet. No special switches required. LAN A and LAN B can be any managed switches you already trust. The redundancy lives in the end nodes, not the fabric.
• The LANs don't have to be identical. Different latency, different topology, even different vendors — fine. PRP doesn't care which copy wins.

The one rule you cannot break: LAN A and LAN B must never touch each other. No trunk between them, no shared VLAN bridging them, no "we'll just link the two core switches for management." The moment you bridge them, duplicate frames loop between the networks and you get a broadcast problem that looks like a mystery until someone traces it back to that one uplink.

Devices that can't speak PRP — a laptop, a printer, an older IED — are Singly Attached Nodes (SANs) and hang off a RedBox (Redundancy Box), which does the duplication on their behalf. Behind a RedBox they appear on the network as VDANs (Virtual DANs).

HSR: the same idea folded into a ring

HSR trades the two-parallel-LAN topology for a single ring, which saves cabling. Each node (a DANH) has two ports and is part of the ring itself — it forwards traffic through, so you don't need external switches for the ring.

When an HSR node originates a frame it sends a copy in both directions around the ring, tagging each with a 6-byte HSR tag inserted right after the source MAC: HSR EtherType 0x892F, a path/size field, and a 16-bit sequence number. The two copies travel opposite ways around the ring; the destination takes the first and discards the second. A node also forwards frames that aren't for it, and drops a frame it recognizes as one it already forwarded (so a frame doesn't circle forever).

HSR is common on the process bus precisely because it's seamless and needs no dedicated switches, but it has real constraints: every device in the ring must be HSR-capable (a non-HSR device needs a RedBox), and each node adds a little forwarding latency, so very large rings aren't free. To join HSR rings together, or bridge an HSR ring to a PRP network, you use coupling nodes (QuadBox / RedBox).

The part people skip: monitor the redundancy, not just the traffic

Back to the dead LAN B. Because both PRP and HSR are bumpless, your normal monitoring — ping, poll success, tag quality — tells you nothing about redundancy health. Everything is green on one path. You have to watch the redundancy layer directly.

• PRP supervision frames. Every DANP and RedBox multicasts a PRP supervision frame roughly every 2 seconds (default LifeCheckInterval) to 01-15-4E-00-01-XX, announcing itself and which LANs it sees. A node that stops hearing a peer on one LAN knows that LAN is degraded for that peer. Get these into your monitoring — either a node's redundancy-status object or a network analyzer that counts them per LAN. If supervision traffic on LAN B drops to zero, LAN B is down, full stop.
• Per-LAN counters on the end nodes. Managed PRP devices expose "frames received on LAN A / LAN B" and "wrong-LAN" or discard counters. Equal-ish counts on both LANs is healthy. One LAN sitting at zero and climbing discards means you're running single-path.
• RedBox and switch link state on each LAN separately. Trend the two networks as two separate objects in your NMS. Don't collapse them into one "network OK" tag — that's how a dead LAN hides.

At commissioning, prove it the boring way: with the system live and passing traffic, pull the LAN A cable at one DANP and confirm no frame loss at the application (a running sampled-value or GOOSE subscriber shows no gap), then confirm an alarm actually appears somewhere for the lost LAN. Restore it, repeat on LAN B. If pulling a cable produces zero operator-visible symptom and zero alarm, you have redundancy that works and monitoring that doesn't — which is the same silent trap that hid LAN B for three weeks.

One more field check worth its two minutes: confirm the two LANs really are isolated. Put an analyzer on LAN A and look for any frame whose RCT LAN identifier says 0xB. If a LAN-B-tagged frame shows up on LAN A, the two networks are bridged somewhere they shouldn't be — find that link before it turns into a duplicate storm under load.