PRP (Parallel Redundancy Protocol)

ELI5

Imagine your office building has security guards who shout warnings to each other down the hallway when something goes wrong (that’s GOOSE). It works great — instant communication, everyone hears it at once.

But what happens if the hallway collapses? Silence. Every guard is isolated. The building has no backup path.

PRP builds two identical hallways. Every time a guard shouts, the message travels down both hallways simultaneously. If Hallway A collapses, Hallway B is already carrying the exact same message — the guards on the other end never even notice. They hear the shout at the same time they always would.

Meanwhile, the building manager gets an alert: “Hallway A is down.” They can send a repair crew while everything continues operating normally through Hallway B. The building never loses communication — and the manager knows something needs fixing before both hallways fail.

That’s PRP: two independent networks running in parallel, carrying identical traffic, so a single failure is detected but never disruptive.

Outsider’s Guide

PRP (Parallel Redundancy Protocol, IEC 62439-3) provides zero-switchover network redundancy for Ethernet-based protection and control systems. It is the standard network redundancy protocol for IEC 61850 GOOSE deployments where protection-grade reliability is required.

The problem PRP solves: GOOSE replaced copper interlock wiring with Ethernet messages. This is faster, more flexible, and cheaper — but it introduced a new single point of failure: the network. If a switch fails, a cable is cut, or a fiber link goes dark, GOOSE messages stop flowing and protection coordination is lost. With hardwiring, a cut wire affects one circuit. With GOOSE on a single network, a switch failure can affect dozens of protection signals simultaneously.

What PRP does: PRP eliminates the network as a single point of failure by building two completely independent networks — LAN-A and LAN-B. Every device that supports PRP (called a DANP — Dual Attached Node implementing PRP) has two Ethernet ports, one on each LAN. Every frame the device sends is duplicated: one copy goes on LAN-A, an identical copy goes on LAN-B. The receiving device accepts whichever copy arrives first and silently discards the duplicate.

Where PRP sits: PRP operates at Layer 2 (Ethernet), below GOOSE, MMS, Modbus TCP, or any other protocol. Applications are completely unaware that PRP exists. A GOOSE publisher sends one message — the PRP layer handles the duplication. A GOOSE subscriber receives one message — the PRP layer handles the duplicate discard.

What PRP replaces: RSTP (Rapid Spanning Tree Protocol, IEEE 802.1w). RSTP is the default Ethernet redundancy mechanism — it detects a link failure and reconverges the network by activating backup paths. The problem is that reconvergence takes 30-50ms. For monitoring protocols like Modbus TCP (500ms+ polling), this gap is invisible. For GOOSE protection signaling (under 10ms latency requirement), a 50ms gap means multiple missed heartbeats, subscriber timeouts, and fail-safe actions triggering across the system. PRP eliminates this gap entirely — there is no reconvergence because both networks are always active.

Why a prime contractor should care: PRP is an infrastructure decision, not a protocol decision. It doubles the network hardware budget (two switch planes, two fiber runs, two cable trays). But it eliminates the scenario where a single switch failure cascades into a protection system outage. On a data center critical power system with 20+ IEDs exchanging GOOSE for bus differential, breaker failure, and load shedding — the cost of PRP is small compared to the cost of a protection misoperation.

Red flags from a sub’s PRP proposal:

• No distinction between DANP and SAN devices — they treat every device as dual-attached without verifying which IEDs actually support PRP natively
• Single cable tray for both LAN-A and LAN-B fiber — defeats the purpose of independent networks (common-mode failure risk)
• No supervision frame monitoring — means a dead LAN goes undetected until the second LAN also fails
• RedBox in the protection path without acknowledging it as a single point of failure
• No fault injection test plan — PRP validation requires deliberately failing each LAN and verifying continuous operation
• RSTP configured as “backup” on PRP networks — RSTP and PRP serve different purposes and should not be mixed on the same VLAN without careful design

Visual Explanation

Where PRP Sits in a Data Center Critical Power System

+-------------------------------------------------------------+
|                     SCADA / HMI Layer                        |
|              (Operator displays, historians)                 |
+-----------------------------+-------------------------------+
                              |  TCP/IP (MMS, Modbus, DNP3)
                              |  (monitoring, metering)
                         +----+----+
                         | Gateway |  SAN (single-attached)
                         +--+-+--+-+  via RedBox
                            | |  |
+==========+================+=+==+=+========+=================+
| LAN-A    |    RedBox       | |  |         |       LAN-B     |
| (Primary)|    Bridge       | |  |         |    (Secondary)  |
+----------+--------+--------+-+--+---------+---------+-------+
                     |          |  |                   |
  +----------+  +---+------+  ++-++--+  +----------+  +----------+
  | Switch   |  | Switch   |  | DANP |  | Switch   |  | Switch   |
  | A-1      |  | A-2      |  |      |  | B-1      |  | B-2      |
  +----+-----+  +----+-----+  |Relay1|  +----+-----+  +----+-----+
       |              |        | (SEL)|       |              |
  +----+-----+  +----+-----+  ++-++--+  +----+-----+  +----+-----+
  | DANP     |  | DANP     |   | |     | DANP     |  | DANP     |
  | Relay 2  |  | Relay 3  |   | |     | Relay 2  |  | Relay 3  |
  | (SEL)    |  |(Woodward)|   | |     | (SEL)    |  |(Woodward)|
  +----------+  +----------+   | |     +----------+  +----------+
       |              |         | |          |              |
       LAN-A          LAN-A    | |        LAN-B          LAN-B
       port           port     | |        port           port
                               | |
          Each DANP has TWO    +-+  ports -- one on each LAN.
          Frames sent on both. Received on both. First kept, duplicate discarded.

How PRP Duplicate Handling Works

Publisher (DANP)                           Subscriber (DANP)
+-------------+                            +-------------+
|  Application|                            |  Application|
|  sends ONE  |                            |  receives   |
|  GOOSE frame|                            |  ONE frame  |
+------+------+                            +------+------+
       |                                          ^
       v                                          |
+------+------+                            +------+------+
|  PRP Layer  |                            |  PRP Layer  |
|  duplicates |                            |  accepts    |
|  the frame  |                            |  first,     |
+--+-------+--+                            |  discards   |
   |       |                               |  duplicate  |
   v       v                               +--+-------+--+
 LAN-A   LAN-B                               ^       ^
   |       |                                  |       |
   |  +----+----+----+----+----+              |       |
   |  | Switch  | Switch  |   |              |       |
   |  | plane B | plane B |   |              |       |
   |  +---------+---------+   |              |       |
   |                          +--- LAN-B ----+       |
   |                                                  |
   +-- LAN-A (independent switches) -----------------+

Frame on LAN-A: [Eth Header][GOOSE payload][RCT: seq=42, LAN=A]
Frame on LAN-B: [Eth Header][GOOSE payload][RCT: seq=42, LAN=B]

Subscriber receives seq=42 from LAN-A first --> ACCEPT
Subscriber receives seq=42 from LAN-B later --> DISCARD (duplicate)

RSTP vs PRP: What Happens When a Link Fails

RSTP (Single Network)                    PRP (Dual Network)
=====================                    ==================

GOOSE heartbeats (1s):                   LAN-A frames:
  ok  ok  ok  ok  ok  ok                   ok  ok  ok  ok  ok  ok

        LINK FAILS                               LAN-A FAILS
           |                                        |
           v                                        v
  ok  ok  --  --  --  ok  ok               ok  ok  --  --  --  --
        |<-------->|                             LAN-A dead
         30-50ms
         RSTP reconverge                   LAN-B frames (always sending):
                                             ok  ok  ok  ok  ok  ok
  During this window:                              ^
  X  GOOSE frames LOST                             | Already there!
  X  Subscriber may timeout                        No gap. No switchover.
  X  Fail-safe actions trigger
  X  Protection coordination               Subscriber sees:
     disrupted                              +  Continuous GOOSE stream
                                            +  Zero lost frames
                                            +  No fail-safe trigger
                                            +  Protection intact
                                            +  Alarm: "LAN-A down"
                                               (repair before LAN-B fails)

PRP Frame Structure

Standard Ethernet frame (unchanged -- switches forward normally):
+----------+----------+------+-----------------+-----+
| Dst MAC  | Src MAC  | Type | Payload         | FCS |
| 6 bytes  | 6 bytes  | 2B   | (GOOSE, MMS,    | 4B  |
|          |          |      |  TCP/IP, etc.)   |     |
+----------+----------+------+-----------------+-----+
                                                  |
                              Appended AFTER payload, BEFORE FCS:
                              +------+------+------+--------+
                              | SeqNr| LanId| LSDU | PRP    |
                              | 16b  | 4b   | Size | Suffix |
                              |      | A/B  | 12b  | 0x88FB |
                              +------+------+------+--------+
                              |<------- RCT: 6 bytes ------>|

SeqNr:  16-bit sequence number (0-65535, wraps around)
        Used by receiver to identify and discard duplicates
LanId:  4 bits -- 0xA for LAN-A, 0xB for LAN-B
        Receiver knows which LAN delivered this copy
LSDU:   12 bits -- size of the payload + RCT
        Used to locate the RCT in the frame
Suffix: 0x88FB -- PRP protocol identifier
        Marks this frame as PRP-tagged

Cheat Sheet

PRP at a Glance

Parameter	Value
Standard	IEC 62439-3 (Clause 4)
OSI Layer	Layer 2 (Data Link)
Redundancy type	Parallel (active-active on two independent LANs)
Switchover time	0 ms (zero — both LANs always active)
Topology	Dual star (two independent switch planes)
Node types	DANP (dual-attached), SAN (single-attached via RedBox)
Frame overhead	6 bytes (RCT appended to each frame)
Sequence number	16-bit (0-65535), wraps around
Supervision frame interval	Configurable, typically 2-10 seconds
Max frame size	Standard Ethernet MTU + 6 bytes RCT

RCT (Redundancy Control Trailer) — 6 Bytes

Offset	Size	Field	Values
0	16 bits	Sequence Number	0-65535 (wraps)
2	4 bits	LAN Identifier	0xA = LAN-A, 0xB = LAN-B
2.5	12 bits	LSDU Size	Payload + RCT size in bytes
4	16 bits	PRP Suffix	0x88FB (fixed)

DANP vs SAN vs RedBox

	DANP	SAN	RedBox
Ports	2 (one per LAN)	1 (one LAN only)	2+ (bridges LANs)
PRP-aware	Yes (native)	No	Yes
Redundancy	Full — both LANs direct	None — single LAN	Provides redundancy to SANs
Single point of failure	Device itself only	Device + its LAN	RedBox itself
Examples	SEL-4xx relays, Woodward controllers	HMI PCs, historians, cameras	Ruggedcom, Hirschmann RedBox units
Preferred for	Protection IEDs	Non-critical monitoring	Legacy devices without dual ports

Wireshark Filters

Filter	Purpose
eth.type == 0x88fb	PRP supervision frames
eth.trailer	Show RCT bytes appended to frames
frame.len > 64	Frames with RCT (slightly longer than minimum)

To decode PRP in Wireshark: Edit > Preferences > Protocols > PRP > Enable PRP dissector. Supervision frames use EtherType 0x88FB. Regular PRP-tagged frames use the standard EtherType of the payload (e.g., 0x88B8 for GOOSE) with the RCT appended before the FCS.

Network Infrastructure Checklist (per LAN)

• All DANP devices have dedicated port on this LAN
• Switch management IP accessible on this LAN
• VLANs match the other LAN exactly (same VLAN IDs, same port assignments)
• Trunk ports configured between all switches on this LAN
• IGMP snooping enabled (for GOOSE multicast filtering)
• Supervision frames observable on all switch ports with DANPs
• Cable labels identify LAN-A vs LAN-B at both ends
• Switch power supply is independent from the other LAN’s switches

Best Practices

1. Keep LAN-A and LAN-B on physically separate infrastructure Each LAN must have its own switches, its own cable trays, and its own fiber paths. The two LANs should share nothing — not power supplies, not cable conduits, not rack space if avoidable. Why: PRP’s zero-switchover guarantee assumes the two LANs fail independently. If both LANs share a cable tray and a contractor accidentally cuts the tray, both LANs go down simultaneously — a common-mode failure that PRP cannot survive. If you don’t: A single physical event (fire, cable cut, power outage) can take out both LANs at once. PRP provides no benefit if the two networks aren’t truly independent.

2. Use DANP wherever possible — avoid SANs and RedBoxes in the protection path Every device that participates in GOOSE protection signaling should be a DANP (dual-attached node). SANs connected through RedBoxes have a single point of failure: the RedBox itself. Why: A RedBox failure disconnects the SAN from one or both LANs. If a GOOSE publisher is behind a failed RedBox, all its subscribers lose communication. If a subscriber is behind a failed RedBox, it loses GOOSE and triggers fail-safe. If you don’t: You’ve introduced a shared component in the protection path. The RedBox becomes the weakest link — a single device whose failure can cascade into protection misoperation.

3. Align VLANs identically on both LANs The VLAN configuration on LAN-A must exactly mirror LAN-B — same VLAN IDs, same port assignments, same IGMP snooping settings. A GOOSE frame on VLAN 100 on LAN-A must reach the same subscribers via VLAN 100 on LAN-B. Why: PRP duplicates every frame and sends one copy on each LAN. If the VLANs don’t match, a frame might reach its subscriber on LAN-A but be dropped on LAN-B (wrong VLAN). The subscriber sees frames from one LAN only — it still works, but it has silently lost redundancy. If you don’t: Asymmetric VLAN configuration silently degrades PRP to single-LAN operation. No alarm, no error — just loss of redundancy you won’t discover until the working LAN also fails.

4. Enable PRP supervision frame monitoring and alarm on loss PRP supervision frames are periodic multicast messages sent by every DANP to announce its presence on each LAN. If a DANP stops receiving supervision frames from a peer on one LAN, it knows that LAN path has failed. Why: Without supervision frame monitoring, a dead LAN goes undetected. The system continues operating on the surviving LAN, but nobody knows redundancy has been lost. This is the “lurking failure” scenario — everything looks fine until the second LAN also fails. If you don’t: You lose PRP’s key advantage: proactive failure detection. The first LAN failure is invisible. The second LAN failure is catastrophic. Supervision frames turn PRP from “survive one failure” into “detect and repair before the second failure.”

5. Label all cabling and switch ports with LAN identity (A/B) Every cable, every patch panel port, every switch port must be clearly labeled as LAN-A or LAN-B. Use color coding (e.g., blue for LAN-A, orange for LAN-B) on patch cables. Why: The most common PRP commissioning error is cabling both ports of a DANP to the same physical LAN. This defeats PRP entirely — the device sends duplicates on the same network and receives both copies with no redundancy. If you don’t: A cabling error during installation or maintenance can silently destroy PRP redundancy for one or more devices. The device appears to work (it receives frames) but has no failover capability.

6. Test each LAN independently before enabling PRP — verify GOOSE works on LAN-A alone and LAN-B alone During commissioning, bring up LAN-A with all PRP ports on LAN-B disconnected. Verify all GOOSE subscriptions work, all MMS clients connect, all Modbus TCP polls respond. Then repeat with LAN-B alone, LAN-A disconnected. Why: If a GOOSE subscription only works on one LAN (misconfigured VLAN, wrong multicast group, missing trunk port), PRP will mask the problem during normal operation — the working LAN delivers the frames. You won’t discover the asymmetry until the working LAN fails and the broken LAN can’t carry the traffic. If you don’t: PRP hides single-LAN problems. A subscription that works “with PRP” may actually only work on one of the two LANs. When that LAN fails, the subscriber loses GOOSE despite PRP being “enabled.”

Strengths, Weaknesses & When to Choose an Alternative

Strengths in Detail

Zero-switchover redundancy: PRP provides literally zero packet loss during a single LAN failure. Not “fast failover” — zero. The surviving LAN was already carrying the same traffic in parallel. No reconvergence, no brief outage, no missed heartbeats. For GOOSE protection signaling where a 50ms gap can trigger fail-safe actions across the system, this is the difference between “protection intact” and “nuisance trip across the plant.”

Lurking failure detection: PRP supervision frames continuously verify that both LANs are healthy. When a LAN fails, an alarm is raised immediately — while operations continue unaffected on the surviving LAN. This turns PRP from a passive redundancy scheme into an active monitoring system. The operator knows to dispatch a repair crew before the second LAN also fails. RSTP, by contrast, only reveals a failure when it disrupts traffic during reconvergence.

Protocol-agnostic: PRP operates at Layer 2 and carries any Ethernet traffic — GOOSE, MMS, Modbus TCP, DNP3, SNMP, NTP, LLDP. It doesn’t inspect payloads or require application-layer changes. One redundancy solution covers every protocol on the network.

Standard switches: Unlike HSR (which requires HSR-capable nodes arranged in a ring), PRP works with any managed Ethernet switch. The RCT is appended after the payload — switches see a normal Ethernet frame and forward it without modification. This means you can use proven, cost-effective industrial switches rather than specialized HSR hardware.

Mature standard with multi-vendor interoperability: IEC 62439-3 is well-defined, with conformance testing specified in Annex D. SEL, ABB, Siemens, GE, Woodward, and other major IED vendors support PRP natively on protection-grade devices.

Weaknesses in Detail

Double infrastructure cost: PRP requires two complete, independent switch planes. Two sets of switches, two fiber runs to every DANP, two cable trays (ideally physically separated). For a data center with 20+ IEDs, this can add significant hardware and installation cost.

DANP availability varies by vendor: Not all IEDs support dual Ethernet ports. Some relays, meters, and controllers are SANs by design — they have a single Ethernet interface and require a RedBox for PRP participation. RedBoxes add cost and introduce a shared component.

RedBox as a shared component: A RedBox provides PRP access to SANs, but it is itself a single point of failure. If the RedBox fails, all SANs behind it lose network connectivity on one or both LANs, depending on the RedBox architecture.

No ring topology support: PRP requires a star or mesh topology (dual independent switch planes). If your physical infrastructure requires a ring topology (e.g., fiber along a linear corridor), you need HSR instead.

Commissioning complexity: Two parallel networks must be independently verified — correct VLAN configuration, correct multicast filtering, correct supervision frame operation — and then PRP behavior validated through deliberate fault injection on each LAN.

PRP vs HSR vs RSTP

Criteria	PRP	HSR	RSTP
Standard	IEC 62439-3 Cl.4	IEC 62439-3 Cl.5	IEEE 802.1w
Switchover time	0 ms	0 ms	30-50 ms typical
Topology	Dual star	Ring	Any (tree/mesh)
Switches required	Standard managed	None (node-to-node)	Standard managed
Bandwidth overhead	None per LAN	50% (ring carries both directions)	None
Infrastructure cost	High (double switches, double cabling)	Low (no switches)	Low (single network)
Node requirement	DANP (dual port)	HSR-capable	Standard Ethernet
Best for	Star topology with GOOSE/MMS	Ring topology, process bus	Non-critical, cost-sensitive
GOOSE gap on failure	None	None	30-50ms (multiple heartbeats lost)

Common Misconception

“PRP halves my network bandwidth.”

It doesn’t. Each LAN operates at full bandwidth independently. A 1 Gbps LAN-A and a 1 Gbps LAN-B each carry 1 Gbps of traffic. The duplication happens across two separate physical networks, not within a single network. PRP doubles your infrastructure cost, not your bandwidth consumption per link. The 6-byte RCT added to each frame is negligible overhead.

When to Choose PRP

Use PRP when:

• GOOSE protection signaling requires zero-switchover (bus differential, breaker failure, ZSI, fast load shedding)
• Your physical infrastructure supports star topology (typical for substations and data centers with structured cabling)
• You need redundancy for multiple protocols (GOOSE + MMS + Modbus TCP) on the same network
• RSTP’s 30-50ms reconvergence is unacceptable for your protection coordination scheme

Use HSR instead when:

• Your physical infrastructure requires ring topology (linear corridor, outdoor ring)
• You want to eliminate switches entirely (HSR nodes connect directly in a ring)
• Bandwidth halving is acceptable for your traffic load

Use RSTP instead when:

• The application is monitoring-only (Modbus TCP, DNP3, SNMP) with no protection-critical signaling
• Cost constraints prohibit dual infrastructure
• 30-50ms network reconvergence is acceptable for the application

Biggest Pitfalls

1. Both DANP ports cabled to the same physical switch The most basic PRP failure: a technician connects both Ethernet ports of a relay to the same switch (or to two switches on the same LAN). The device sends duplicate frames on the same network — it receives both copies, but has zero redundancy. Prevention: Color-code LAN-A and LAN-B cables. Label every switch port with its LAN identity. Verify during commissioning by checking supervision frames — a correctly connected DANP should show supervision frame reception on both LAN-A and LAN-B interfaces. Detection: The device’s PRP status page (if available) will show both ports on the same LAN. Wireshark on the switch will show duplicate frames with the same sequence number on the same LAN — both with LanId=A (or both with LanId=B).

2. Common-mode failure from shared infrastructure LAN-A and LAN-B cables run through the same conduit, or both switch planes are powered from the same UPS. A single physical event (cable tray damage, UPS failure, fire in the cable corridor) takes out both LANs simultaneously. Prevention: Route LAN-A and LAN-B cables through physically separate paths. Power each switch plane from a different UPS or power feed. During design review, trace the physical path of every LAN-A cable and every LAN-B cable — if they share any segment, route one differently. Detection: This is a design review issue, not a runtime detection. Once the cables are installed in the same conduit, there is no protocol-level detection. Walk the cable trays during commissioning and verify physical separation.

3. RedBox as single point of failure for SAN devices in the protection path A GOOSE publisher or subscriber that is a SAN (connected through a RedBox) loses both LAN paths if the RedBox fails. PRP provides no protection because the redundancy terminates at the RedBox, not at the end device. Prevention: Avoid placing SAN devices in the GOOSE protection path. If a device must be a SAN (no dual Ethernet port option), use redundant RedBoxes or accept the risk and document it in the protection coordination study. Ensure RedBoxes are enterprise-grade with redundant power supplies. Detection: Loss of supervision frames from the SAN’s MAC address on both LANs simultaneously indicates RedBox failure (rather than a LAN failure, where supervision would be lost on only one LAN).

4. Supervision frame monitoring disabled — dead LAN goes undetected PRP supervision frames are the only mechanism for detecting a single LAN failure. If supervision monitoring is not configured, the system continues operating on one LAN with no alarm. The operator has no idea that redundancy has been lost. Prevention: Configure every DANP to monitor supervision frames from its peers. Set up SNMP traps or relay alarms on supervision frame loss. Include supervision frame verification in the commissioning test procedure. Detection: If monitoring is disabled, you cannot detect the dead LAN until it’s too late. The first symptom is a total communication failure when the second LAN also fails — which could be months later.

5. VLAN mismatch between LAN-A and LAN-B GOOSE frames are tagged with a VLAN ID. If the VLAN configuration on LAN-A doesn’t match LAN-B (different VLAN IDs, different port assignments, or missing trunk ports on one LAN), GOOSE frames reach subscribers on one LAN but not the other. Prevention: Mirror the VLAN configuration exactly between LANs. Use a configuration template or script to ensure both switch planes are identically configured. Test by running each LAN independently (Best Practice #6). Detection: During commissioning, disconnect LAN-A and verify all GOOSE subscriptions work on LAN-B alone. Then disconnect LAN-B and verify on LAN-A alone. Any subscription that works on one LAN but not the other indicates a VLAN mismatch.

6. Asymmetric path delay exceeds duplicate discard window PRP uses a time-based window (EntryForgetTime) to match duplicate frames. If the path delay difference between LAN-A and LAN-B is too large, frames from the slower LAN may arrive outside the discard window. In extreme cases, both copies are accepted as unique — which wastes processing but doesn’t cause loss. More rarely, the discard logic may incorrectly drop a frame from the surviving LAN during a failure transition. Prevention: Keep path lengths similar between LANs. Avoid architectures where LAN-A has a direct connection but LAN-B routes through multiple switches. Verify duplicate discard counters during commissioning — a high discard count confirms PRP is working; zero discards on a DANP with traffic suggests misconfiguration. Detection: Monitor PRP duplicate discard counters on each DANP. If a node shows zero discards despite active traffic, it may not be receiving frames on one LAN. Check supervision frame counters per LAN interface.

Field Tips & Tools

Wireshark Setup for PRP Commissioning

Step 1 — Enable PRP dissector: Edit > Preferences > Protocols > PRP > check “Enable PRP dissector”

Step 2 — Supervision frame filter:

eth.type == 0x88fb

Supervision frames use EtherType 0x88FB. Each DANP sends supervision frames on both LANs. Capture on a LAN-A switch port and verify you see supervision frames from all expected DANPs.

Step 3 — Identify LAN source in RCT: With the PRP dissector enabled, Wireshark decodes the RCT and shows the LAN identifier (A or B) and sequence number. Compare captures from LAN-A and LAN-B — you should see matching sequence numbers with different LAN identifiers.

Step 4 — Verify duplicate discard: Capture on a DANP’s interface. You should see each frame once (the PRP layer discards the duplicate before it reaches the application). If you see duplicate frames with the same sequence number, the PRP discard logic is not functioning — check the DANP’s PRP configuration.

Essential Tools

Tool	Purpose	Platform
Wireshark	Capture and decode PRP supervision frames, verify RCT, check duplicate discard	All
Switch CLI / Web UI	Check port statistics, VLAN configuration, multicast group membership per LAN	Per vendor
Relay configuration software	SEL AcSELerator, Woodward ToolKit — configure DANP ports, PRP settings, supervision parameters	Windows
Network cable tester	Verify physical connectivity and label correctness for LAN-A vs LAN-B	Hardware
Managed switch with port mirroring	Mirror a DANP’s switch port to capture traffic without inline tap	Per vendor

Commissioning Sequence

1. Verify physical infrastructure independently: Bring up LAN-A switches only. Verify all LAN-A ports are active, correct VLANs assigned, trunk ports configured. Repeat for LAN-B with LAN-A powered off.

2. Verify GOOSE on each LAN independently: With only LAN-A active, confirm all GOOSE subscriptions work — publishers send, subscribers receive, state changes propagate. Repeat with only LAN-B active. Any subscription that works on one LAN but not the other must be fixed before enabling PRP.

3. Connect both LANs and enable PRP: Connect all DANP second ports. Verify supervision frames are visible from all DANPs on both LANs. Each DANP should report both LAN-A and LAN-B interfaces as active.

4. Verify duplicate discard: On each DANP, check the duplicate discard counter — it should be incrementing (confirms both LANs are delivering frames and duplicates are being correctly discarded). A zero count with active traffic indicates a problem.

5. Fault injection — LAN-A failure: Disconnect LAN-A at the switch level (or power off LAN-A switches). Verify:

   • All GOOSE subscriptions continue operating without interruption
   • No subscriber triggers GOOSE loss or fail-safe actions
   • Supervision frame alarm is raised for LAN-A loss
   • All MMS and Modbus TCP connections continue on LAN-B

6. Fault injection — LAN-B failure: Reconnect LAN-A, then disconnect LAN-B. Repeat the same verifications.

7. Restore and validate steady state: Reconnect both LANs. Verify supervision frames resume, duplicate discard counters increment, and no alarms persist.

8. Document results: Record supervision frame counts, duplicate discard counts, fault injection results, and any anomalies. This is the PRP acceptance test record.

Troubleshooting: “PRP Not Discarding Duplicates”

Duplicate discard counter is zero on a DANP?
|
+-- Is the DANP receiving traffic on BOTH LAN ports?
|   |
|   +-- NO --> Check physical cabling
|   |   +-- Both ports cabled to same LAN? (check LAN ID in RCT)
|   |   +-- Port link down? (check switch port status)
|   |   +-- Wrong VLAN on one port? (check VLAN config on both switches)
|   |
|   +-- YES --> Are sequence numbers matching between LANs?
|       |
|       +-- NO --> Different traffic on each LAN
|       |   +-- Check publisher -- is it a DANP sending on both LANs?
|       |   +-- Check for a non-PRP device generating different frames on each LAN
|       |
|       +-- YES --> PRP discard logic issue
|           +-- Check PRP firmware version on the DANP
|           +-- Check EntryForgetTime setting (too short?)
|           +-- Verify PRP is actually enabled (not just dual Ethernet without PRP)

Deep Dive

RCT Byte-Level Structure

The Redundancy Control Trailer (RCT) is 6 bytes appended to the Ethernet frame payload, before the Frame Check Sequence (FCS). It is the only PRP-specific modification to the frame — the rest of the Ethernet frame is unchanged.

Byte offset (from end of payload):

Bytes 0-1: Sequence Number (16 bits)
  +--------+--------+
  | SeqNr high byte  |  SeqNr low byte  |
  +--------+--------+
  Range: 0x0000 - 0xFFFF (0 - 65535)
  Wraps around. Incremented by 1 for each new frame.
  Same sequence number on both LAN-A and LAN-B copies.

Bytes 2-3: LAN ID (4 bits) + LSDU Size (12 bits)
  +----+----+--------+
  |LanId|   LSDU Size          |
  | 4b  |   12 bits            |
  +----+----+--------+
  LanId: 0xA = LAN-A, 0xB = LAN-B
  LSDU Size: Total size of payload + RCT in bytes
  Used by receiver to locate the RCT (frame_size - LSDU_size = start of RCT)

Bytes 4-5: PRP Suffix (16 bits)
  +--------+--------+
  |  0x88  |  0xFB  |
  +--------+--------+
  Fixed value. Identifies this frame as PRP-tagged.
  Note: This is NOT an EtherType -- it appears at the end of the frame, not after the source MAC.

Sequence Number Management

Each DANP maintains a per-source sequence counter. When sending a frame:

1. Increment the sequence counter
2. Append the RCT with the current sequence number, LAN-A ID on the LAN-A copy, LAN-B ID on the LAN-B copy
3. Send both copies simultaneously

When receiving a frame:

1. Read the sequence number and source MAC from the incoming frame
2. Look up the source MAC in the duplicate discard table
3. If this sequence number has been seen from this source within the EntryForgetTime window: discard (duplicate)
4. If this sequence number is new for this source: accept and record in the duplicate discard table

EntryForgetTime: The time window during which the receiver remembers a sequence number. After this window expires, a frame with the same sequence number would be accepted again. IEC 62439-3 specifies a default of 400ms, but this is configurable. Too short: frames from the slower LAN may be accepted as new (false accept). Too long: table memory grows unnecessarily.

Sequence number rollover: The 16-bit counter wraps from 65535 to 0. The duplicate discard algorithm handles this correctly as long as the sending rate doesn’t wrap the counter within the EntryForgetTime window — which would require sending over 160,000 frames per second per source (not realistic for typical IED traffic).

Supervision Frame Format

PRP supervision frames are periodic multicast frames sent by every DANP to announce its presence on each LAN. They serve two purposes:

1. Peer detection: DANPs build a table of known peers from supervision frames
2. Link monitoring: Loss of supervision frames from a peer on one LAN indicates a path failure

Supervision frames use:

• Destination MAC: 01:15:4E:00:01:XX (multicast, IEC 62439-3 defined)
• EtherType: 0x88FB (PRP supervision)
• Payload: Source MAC, DANP capability flags, sequence number
• RCT: Same as any PRP frame — appended with LAN ID and sequence number

Supervision interval: Configurable per DANP. Typical values: 2-10 seconds. Shorter intervals detect failures faster but generate more traffic. IEC 62439-3 specifies a default of 2 seconds with a LifeCheckInterval of 3x the supervision interval (6 seconds default) before declaring a peer lost.

Duplicate Discard Algorithm

The core PRP algorithm at the receiver:

on_frame_received(frame):
    src_mac = frame.source_mac
    seq_nr  = frame.rct.sequence_number
    lan_id  = frame.rct.lan_id

    if (src_mac, seq_nr) in discard_table:
        if discard_table[(src_mac, seq_nr)].age < EntryForgetTime:
            # Duplicate — discard
            increment duplicate_discard_counter
            return DROP
        else:
            # Entry expired — treat as new
            remove discard_table[(src_mac, seq_nr)]

    # New frame — accept
    discard_table[(src_mac, seq_nr)] = {
        timestamp: now(),
        lan_id: lan_id
    }
    increment frame_accept_counter
    deliver frame to application (without RCT)

The RCT is stripped before delivery to the application. GOOSE, MMS, and TCP/IP stacks never see the RCT — they receive a standard Ethernet frame. This is how PRP remains transparent to applications.

Cross-Vendor DANP Interoperability

IEC 62439-3 conformance testing (Annex D) covers individual DANP and RedBox devices, but does not test combinations of devices from different vendors. In practice, cross-vendor PRP interoperability issues are rare because the protocol is simple (append 6 bytes, discard duplicates), but they can occur:

• RCT placement: Some legacy implementations placed the RCT at a slightly different offset. Modern implementations following IEC 62439-3 Ed.2+ are consistent.
• Supervision frame interval: Different vendors may use different default intervals. Ensure all DANPs use the same supervision interval and LifeCheckInterval to avoid false peer-loss alarms.
• VLAN tagging and RCT: When GOOSE frames are VLAN-tagged (802.1Q), the RCT is appended after the GOOSE payload, not after the VLAN tag. This is consistent across vendors, but verify with Wireshark during commissioning.

Edge Cases

PRP and IGMP snooping: IGMP snooping manages multicast group membership on switches. GOOSE uses multicast — IGMP snooping controls which ports receive which GOOSE streams. PRP requires IGMP snooping to be configured identically on LAN-A and LAN-B switches. If IGMP snooping is enabled on one LAN but not the other, multicast forwarding behavior will differ, potentially causing asymmetric GOOSE delivery.

PRP and broadcast storms: A broadcast storm on one LAN can overwhelm switch CPU and cause frame drops. If the storm is confined to one LAN, PRP provides protection — the other LAN continues operating. But if a misconfigured RedBox or domain boundary leak causes a storm on both LANs simultaneously, PRP cannot help. Enable broadcast storm control on all switch ports as a defense-in-depth measure.

PRP and time synchronization: PTP (IEEE 1588) and IRIG-B are commonly used alongside PRP for time synchronization. PTP frames traverse PRP networks like any other Ethernet traffic — they are duplicated on both LANs and deduplicated at the receiver. However, PTP transparent clocks in the switches must be configured identically on both LANs to maintain accurate time correction. Asymmetric PTP correction can cause time drift between the two LAN paths.

Security Considerations

PRP itself has no authentication or encryption. Any device connected to either LAN can inject frames with arbitrary RCTs. In practice, PRP networks are protected by:

• Physical security: The LAN infrastructure is inside secured substations or data centers
• IEEE 802.1X: Port-based access control prevents unauthorized devices from connecting to switch ports
• VLAN segmentation: GOOSE traffic is isolated on dedicated VLANs, separate from corporate network traffic
• IEC 62351-6: Provides authentication for GOOSE frames (application layer, above PRP). Limited vendor support as of 2025.

PRP’s dual-LAN architecture actually provides a minor security benefit: an attacker must compromise both LANs to fully disrupt communication. Compromising one LAN causes an alarm (supervision frame loss) while the other LAN continues operating.