Fixing S7-1215C High Network Traffic Caused by Default MRP

Problem Overview

A Siemens SIMATIC S7-1215C DC/DC/DC connected to a corporate LAN drives the link-activity LEDs on an unmanaged switch to a near-constant on state. Removing the S7-1215C patch cable causes the switch activity to drop to normal levels immediately. Swapping in an S7-1214C DC/DC/DC on the same cable and IP subnet does not reproduce the symptom. Putting the S7-1215C into STOP mode also has no effect on the broadcast rate, which rules out the user program as the source of the traffic.

This pattern is reproducible, persistent across program states, and tied to a hardware-level difference between the 1214C and 1215C CPUs. The most common cause is the Media Redundancy Protocol (MRP) client role that the 1215C activates by default at the PROFINET interface, combined with the absence of any MRP manager in the ring. The result is a continuous stream of MRP test frames emitted onto the segment, which is amplified when the segment is shared with office PCs, servers, and IT vulnerability scanners.

Root Cause: Default MRP Behavior on the S7-1215C

The S7-1215C is the first S7-1200 CPU to expose a two-port PROFINET switch with MRP support. The 1214C has a two-port switch but does not support MRP. When the 1215C powers up and there is no MRP manager in the topology, the CPU will, depending on firmware, fall back to one of two behaviors:

• Default redundancy role: Not device in the ring (the role TIA Portal sets when you first add the device). In this case the 1215C should not be emitting MRP test frames.
• Default redundancy role: Client (the role the 1215C will fall back to if the topology view in TIA Portal re-projects the device, or if the device is loaded with a configuration that does not explicitly set the role).

When the 1215C sits in a non-ring topology as an MRP Client, it still participates in MRP test-frame exchange by sending MRP_Test, MRP_TestMgrNAck, and MRP_LinkChange PROFINET frames. Without a manager to acknowledge them, the client keeps retransmitting. The default test interval is 50 ms, which produces roughly 20 frames per second per port, and the two-port switch on the CPU then floods them onto both ports, including the uplink to the office LAN.

Additional contributors that are commonly seen alongside MRP:

• LLDP frames emitted at the default 5-second interval.
• DCP (Discovery and Configuration Protocol) identify-all-multicast broadcasts from the CPU searching for PROFINET devices.
• S7 communication attempts from IT-side Port 102 scanners (nmap, Nessus, Rapid7) that the CPU must reject at the application layer.
• SNMP polls from network management tools against the CPU's default community strings, when SNMP is left enabled.

Affected Versions and Devices

The MRP role is a property of the PROFINET interface X1. The role is set in the device configuration of TIA Portal, not in the user program. Firmware V4.5 and later of the S7-1200 family still exhibit the default-Client behavior unless the role is explicitly set to Not device in the ring in the project.

Diagnostic Procedure

1. Capture the traffic. Mirror the switch port that connects to the S7-1215C using a managed switch with port mirroring, or attach a laptop running Wireshark with a tap on that segment. Filter on the CPU's MAC address (printed on the front of the CPU, format 00-0E-8C-xx-xx-xx or 8C-F3-19-xx-xx-xx on newer units).
2. Identify frame types. In Wireshark, apply the display filter mrp or pndcp or lldp and eth.src == <cpu_mac>. You should see MRP test frames from the CPU if the role is set to Client or Manager.
3. Quantify the load. Use Wireshark's Statistics > Conversations or I/O Graph to plot frames per second. MRP in steady state from a misconfigured 1215C typically generates 30 to 50 frames per second per port.
4. Verify STOP has no effect. Toggle the CPU to STOP from TIA Portal. Re-capture for 60 seconds. Frame rate should remain unchanged if MRP is the cause. This confirms the PROFINET stack is the source rather than the user program.
5. Check the project. In TIA Portal, open the device configuration of the 1215C, select the PROFINET interface X1, and open Properties > Media Redundancy. Note the current Role field. If it is blank or reads Not device in the ring, MRP is configured out, but the CPU may still be sending frames if the project was compiled before the field was set.
6. Check the online role. With the CPU online, right-click the device in the project tree, choose Online & Diagnostics > PROFINET interface > Media redundancy diagnostics. The online role should match the configured role. Mismatch means a partial download occurred.
7. Check the switch. Confirm the switch is unmanaged. Confirm no other device on the segment is acting as an MRP manager (typical candidates: SCALANCE XC/XB/XR managed switches, third-party PROFINET controllers). If a manager exists, the high traffic may indicate a ring break or duplicate manager.

Solution: Disable MRP in TIA Portal

The correct fix is to explicitly set the PROFINET interface role to Not device in the ring and recompile and download the project to the CPU. Do not rely on the default; the default may change between TIA Portal versions and project migrations.

1. In TIA Portal, open the 1215C device configuration.
2. Select the PROFINET interface_1 entry under the CPU in the device view.
3. Open Properties > General > Media Redundancy in the inspector window.
4. In the Role drop-down, set the value to Not device in the ring.
5. If the CPU is part of a ring topology that uses a SCALANCE switch as the MRP manager, set the role to Client instead, and confirm the manager's role is set to Manager on the SCALANCE configuration.
6. Compile the project (right-click the device > Compile > Hardware (rebuild all)).
7. Download to the CPU. Use Download to device > Hardware and software to ensure the interface configuration overwrites the live settings.
8. Power-cycle the CPU to ensure the new MRP role takes effect on cold start.

Network Segmentation Strategy

Even with MRP disabled, the S7-1200 CPU will continue to emit LLDP, DCP, and ARP traffic. If the CPU is on the same physical or logical segment as office PCs, vulnerability scanners, and shared servers, the network will continue to see elevated baseline traffic. The proper architecture is to keep the PLC on an isolated OT segment with controlled gateway access.

Recommended Siemens components for the OT segment are listed in the Siemens Industrial Ethernet networking catalog. A SCALANCE XC-200 series switch with PROFINET diagnostics provides a per-port MRP status display and built-in LLDP filtering.

Managed Switch Configuration Notes

If a managed switch is introduced to replace the existing unmanaged switch, the following baseline configuration reduces PLC-induced traffic exposure to the wider network:

• Disable LLDP forwarding on the PLC uplink port if the office side does not need PROFINET topology information. LLDP frames are still emitted by the CPU every 5 seconds.
• Enable broadcast storm control with a threshold of approximately 100 frames per second per port. This protects the office LAN if a misconfiguration reintroduces MRP storms.
• Filter DCP identify-all-multicast (Ethernet type 0x8892) on the uplink port. DCP is required inside the OT segment for PROFINET device discovery but should not leak to the office network.
• Enable port security on the PLC port to bind the port to the CPU's MAC address. This prevents accidental cable swaps and rogue devices from injecting traffic.
• Enable SNMPv3 on the switch with read-only access for the network management station, and disable SNMPv1/v2c community strings.

Verification

1. After applying the TIA Portal change and power-cycling the CPU, re-capture traffic on the PLC port for 5 minutes. MRP frame count should drop to zero.
2. Check the switch activity LEDs. They should return to a normal blink rate (intermittent flashes driven by legitimate traffic).
3. Confirm any other systems on the LAN that previously lost communications (HMI panels, SCADA servers, drives) have resumed normal polling.
4. From the office network, perform a controlled ping to the CPU's IP address and a TCP port 102 connection attempt from a single test workstation. Both should succeed via the firewall but should not generate PLC-originated traffic back to the office.
5. Run a 24-hour baseline capture and compare to the pre-fix baseline. The CPU should now contribute less than 1% of the segment's broadcast frame count.

Long-Term Architectural Hardening

For sites where the PLC must remain accessible from the IT side, the following additions harden the architecture against repeat incidents:

• Deploy a dedicated OT firewall (e.g. SCALANCE S615, SCALANCE SC-600) between the OT switch and the IT core. The S615 supports stateful inspection and PROFINET-aware filtering, and ships with default rule sets that block DCP, LLDP, and MRP from crossing zones.
• Use a S7-1500 CPU as a perimeter router if the S7-1215C is the only controller. The S7-1500 supports static IP routing and access lists, allowing you to filter traffic at the controller boundary.
• Lock down the CPU's integrated security features. In TIA Portal, enable Access protection under Properties > Protection > Connection mechanisms, configure a CPU password, and restrict PUT/GET access to known partners only. This stops IT-side Port 102 scanners from triggering reject traffic at the application layer.
• Document the OT subnet and CPU MAC addresses in a network register. TIA Portal's Project tree > Devices & Networks > Network view > Topology provides an exportable view that should be kept under version control.
• Schedule periodic MRP audits. After every TIA Portal upgrade or project migration, verify the media-redundancy role on every 1215C/1217C CPU remains set to Not device in the ring unless intentionally configured as Client or Manager.

Related Settings to Audit on the Same CPU

While addressing MRP, the following related PROFINET interface settings on the 1215C are commonly misconfigured and worth a single-pass review:

Field-Proven Caveats

• Firmware upgrades do not reset MRP role. Updating the CPU firmware from V4.4 to V4.6 retains whatever role was last compiled into the project. The role is a project setting, not a firmware default.
• Topology view can override the role. Drawing a ring in the TIA Portal Topology view automatically assigns the appropriate MRP role to each device. If the project was originally built with the topology view open and a ring drawn, the 1215C may be set to Client even if the device properties show Not device in the ring. Open the Topology view, delete the ring connections, recompile, and re-download.
• Replacing a 1214C with a 1215C preserves project data but not interface defaults. When the CPU type is changed in the device configuration, the new CPU inherits IP address and subnet mask from the old one, but the PROFINET interface role resets to whatever the new device's type default is. Always re-audit the interface after a CPU swap.
• MRP manager storms are silent. If a SCALANCE switch on the same segment is configured as MRP Manager and the manager loses its MRP partner, the manager can flood the segment with MRP_TestMgrNAck frames at 10 ms intervals. The fix is to enable the manager only on the intended ring ports and disable it on uplink ports.

Documentation References

For further detail, refer to the following Siemens documentation:

• SIMATIC S7-1200 Programmable Controller System Manual (entry ID 109751634) — Chapter on PROFINET interface and media redundancy.
• SIMATIC PROFINET with STEP 7 V17 Function Manual (entry ID 49948856) — MRP configuration in TIA Portal.
• Media Redundancy Protocol (MRP) application note (entry ID 109739461) — Behavior of MRP clients in non-ring topologies.
• SCALANCE XC-200 Operating Instructions (entry ID 109751615) — Port mirroring and broadcast storm control configuration.
• IEC 62439-2:2016 — Industrial communication networks: High availability automation networks, Part 2: Media Redundancy Protocol (MRP).

FAQ