MRP Ring Network Design: Switch Requirements and Device Limits

Overview of Media Redundancy Protocol in PROFINET

Media Redundancy Protocol (MRP) is a redundancy management protocol defined in IEC 62439-2 for ring topologies using IEEE 802.3 / Ethernet as the physical layer. PROFINET networks standardized by PROFIBUS & PROFINET International (PI) adopted MRP as the primary method of achieving media redundancy for plant-floor and process automation segments. In an MRP ring, every node in the closed loop must be capable of recognizing and processing MRP frames; a single non-compliant device on the ring path will prevent the protocol from establishing a redundant path and will, in the worst case, break the ring into a linear segment.

The redundancy design hinges on one device being the MRM (MRP Manager) and every other device operating as an MRC (MRP Client). The MRM sends test frames in both directions; under normal operation it blocks one of its ring ports logically so that the ring behaves as a line. When a link fails, the MRM unblocks the alternate port, restoring connectivity in a deterministic time (typically 200 ms or 500 ms depending on the configured profile).

MRP Protocol Architecture (IEC 62439-2)

MRP specifies the behavior of bridges (switches) inside a redundancy domain. The protocol elements that must be implemented on every ring node are:

• MRP Manager (MRM): One per ring. Sends MRP_Test frames, MRP_LinkChange, MRP_LinkDown, MRP_TopologyChange, and MRP_InTest messages. Controls the state of its blocked ring port.
• MRP Client (MRC): Every other ring node. Forwards MRP frames transparently, reports link changes, and reacts to manager commands.
• MRP Auto-Manager (MRA): Optional. Takes over MRM function if the original MRM fails. Selected by priority during ring initialization.

The protocol state machine runs continuously while the ring is closed. Frame types and their EtherType values are standardized so that devices from different vendors interoperate. The default multicast destination MAC used by MRP test frames is 01:15:4E:00:00:01 for the manager and 01:15:4E:00:00:02 for clients; the frame payload carries the MRP UUID, the priority, and the current ring state.

MRP Ring Topology Requirements

An MRP ring must be physically wired as a closed loop. The minimum and maximum ring lengths are defined by the maximum number of MRP nodes and the cumulative cable delay. Per IEC 62439-2, a ring may contain up to 50 MRP devices, although PROFINET deployments typically cap the count at 16 to 32 devices per ring to keep the recovery time within the 200 ms / 500 ms envelope. The maximum number of hops depends on the configured recovery profile:

Each device in the ring must be a switch (or a device with an integrated Ethernet switch) that exposes two physical ring ports and that has MRP firmware support enabled. PROFINET IO devices such as ET 200S, ET 200MP, ET 200SP, SCALANCE switches, and many third-party PROFINET devices include built-in MRP support in their switch ASICs.

Managed vs Unmanaged Switches in MRP Rings

An MRP ring requires managed switches that support MRP on every ring port. Unmanaged switches cannot participate in the protocol because they lack the firmware hooks to:

1. Inspect MRP multicast frames.
2. Update the state of ring ports (forwarding / blocked / disabled) under MRM control.
3. Forward or originate MRP_Test and MRP_LinkChange messages.
4. Generate MRP topology change notifications to PROFINET controllers.

An unmanaged switch inserted in a ring path will not generate MRP frames and will not respond to MRM commands. The MRM will see the ring as broken because the MRP_Test frames do not return, and the ring will remain permanently in the "open" state — the redundancy is lost. Therefore:

Examples of switches that support MRP include:

• Siemens SCALANCE: XC-200, XB-200, XC-300, XR-300, XC-400, XR-500, XM-400, and the legacy X-200 / X-300 series. Firmware version must support MRP; for example SCALANCE XC-200 requires firmware ≥ V4.0 for full MRP interoperability, and SCALANCE X-200 requires firmware ≥ V4.5.
• Cisco Catalyst IE3x00 Rugged Series: IE3300, IE3400, IE3500. The MRP client and manager roles are configured in IOS-XE 17.4 and later. Refer to the Cisco IE3x00 Redundancy Protocol Configuration Guide, IOS-XE 17.4.
• Hirschmann (Belden) RS / RSP / OCTOPUS series: Industrial managed switches with HiOS or HiView support MRP client and manager.
• Schneider Electric ConneXium (TCSEFEC) and TCSESM series: Managed switches with MRP support.

Connecting Non-MRP Devices via Switch Ports

Non-MRP devices may exist in the same physical network but must be attached to a managed switch port that is not a ring port. In the typical topology:

1. Switches A, B, C, D form the closed ring; each is an MRP client, and switch A is the MRM.
2. Switch C has an extra Ethernet port (a "non-ring" port) where Device 3 (a non-MRP endpoint, e.g., a simple HMI panel, a laptop service tool, a third-party sensor without MRP firmware) is connected.
3. Because Device 3 is attached to a single non-ring port, the MRP protocol running on switch C continues uninterrupted. The MRP test frames pass through switch C's ring ports only; they are not forwarded to Device 3 in a way that requires its participation.

This is the correct answer to the original question. Attaching a non-MRP device to a non-ring port of a switch that is part of the MRP ring does not break the redundancy. The non-MRP device simply behaves as a leaf node, like any PROFINET IO device or TCP/IP endpoint downstream of a managed switch.

Ring Port Configuration

When commissioning an MRP ring, configure each switch in three logical steps:

1. Designate ring ports. On the MRM, port 1 is typically the primary ring port and port 2 the secondary. The MRM blocks the secondary port under normal operation.
2. Assign MRP role. Set one device as MRM and the rest as MRC. In PROFINET terms, the role is configured in the device's Web Based Management (WBM) or TIA Portal topology editor. SCALANCE terminology: MRP Manager / MRP Client / MRP Auto-Manager.
3. Set recovery time profile. Choose 200 ms or 500 ms to match the application requirement. With more than 16 devices or long fiber runs, select 500 ms.

Configuration example for a SCALANCE XC-200 in the WBM:

Layer 2 > MRP > MRP Configuration
  Role:                MRP Manager
  Ring Port 1:         Port 1
  Ring Port 2:         Port 2
  Recovery Time:       200 ms
  MRP Domain UUID:     default (or per-project UUID)
  MRP Manager Priority: 1000 (lower value = higher priority)

For an MRC client on the same network:

Layer 2 > MRP > MRP Configuration
  Role:                MRP Client
  Ring Port 1:         Port 1
  Ring Port 2:         Port 2

MRP Client vs MRP Manager Role Selection

Only one device can be the MRM at a time. If the original MRM fails, an MRA (Auto-Manager) takes over based on the priority value configured. If no MRA is present, the ring will operate in a degraded state without redundancy. Selection rules:

• The manager priority is a 16-bit unsigned integer. Lower value = higher priority.
• If two devices claim the MRM role, the one with the lower priority value wins; ties are broken by MAC address (lower MAC wins).
• The MRP_AutoManager role is recommended for the second-most-capable device on the ring as a hot standby.

Recovery Time and Performance

The recovery time profile determines how long the network can be without a working path before the MRM reconfigures. The 200 ms profile is the default for PROFINET IO and is mandatory for PROFINET with motion (PROFIdrive) where the communication cycle is in the 1 ms range. The 500 ms profile is allowed for process automation where the bus cycle is 10 ms or longer. The maximum recovery time formula from IEC 62439-2:

T_recovery_max = 3 × T_max_frame_transfer + 3 × T_test_interval + T_reaction_MRM

Where T_max_frame_transfer is the maximum time a frame needs to traverse the ring, T_test_interval is the interval between MRP test frames (typically 20 ms), and T_reaction_MRM is the time the manager needs to detect the failure and unblock the alternate port.

Switch Models Supporting MRP

The following table summarizes representative industrial managed switches that are commonly deployed in MRP rings. Confirm the firmware version supports MRP before commissioning; some lower-tier managed switches disable MRP unless a feature license is enabled.

Configuration Example: Mixed Ring with Non-MRP Endpoint

Topology description:

• Switch 1 (SCALANCE XC208, MRM, priority 100)
• Switch 2 (SCALANCE XC208, MRC)
• Switch 3 (SCALANCE XC208, MRC) — has Device 3 attached to port 5 (non-ring port)
• Switch 4 (SCALANCE XC208, MRA, priority 1000)
• Device 3: Non-MRP HMI panel connected to port 5 of switch 3

Ring cable: Switch 1 port 1 → Switch 2 port 1 → Switch 2 port 2 → Switch 3 port 1 → Switch 3 port 2 → Switch 4 port 1 → Switch 4 port 2 → Switch 1 port 2 (closes the ring).

Result: MRP test frames circulate through the ring. The non-MRP HMI on switch 3 port 5 receives normal unicast/multicast traffic from the PROFINET controller but is not required to process MRP frames. The MRM (switch 1) blocks its ring port 2 under normal operation. If a cable is cut between switch 2 and switch 3, the MRM unblocks ring port 2 and the network re-converges within 200 ms. The HMI continues to communicate via switch 3's ring port 2, which is now forwarding on the alternate path.

Verification and Diagnostics

After commissioning, verify the MRP ring with the following checks:

1. WBM / Web interface status: Each switch should show "MRP ring closed" and the MRM should show "Secondary ring port: blocked".
2. Wireshark capture: Filter on the MRP multicast destination MAC 01:15:4E:00:00:01 to confirm the manager is sending MRP_Test frames at the configured interval (default 20 ms).
3. PROFINET diagnostics: In TIA Portal, open the Topology Editor and confirm the ring ports are highlighted as "ring port" and the redundancy role of each device matches the design.
4. PRONETA / SINEC NMS: Use Siemens PRONETA (free) or SINEC NMS (licensed) to scan the network and read MRP role / ring state from each device.
5. Failover test: Disconnect one ring cable and confirm that the network re-converges within the configured recovery time and that PROFINET IO devices do not drop out.

Troubleshooting Matrix

FAQ