Resolving Duplicated MAC Address on CP1613 in S7-400 H Systems

Problem Description

A WinCC redundant server pair, communicating with redundant S7-400 Hot Standby CPUs through SIMATIC NET CP1613 PCI network cards, raises a "Duplicated MAC Address" error immediately after a project is duplicated from the primary server to the standby server. In a ring-topology switch installation (two managed switches interconnected with a redundancy ring), the duplicate MAC address propagates through both switches and forces the ring to fail. The switches require a manual restart before the network recovers.

Symptoms reported in the field:

• Windows event log on one or both WinCC servers reports MAC address conflict for the CP1613.
• Managed industrial switches (e.g., SCALANCE X-200/X-300) flag the port or break the ring.
• WinCC redundancy partner channel drops; S7 connections to the S7-400 H system go into fault.
• Both Station Configuration Editor (Station Configurator) and SIMATIC Manager NETPro appear to show unique MAC addresses, yet the duplicate is still observed on the wire.

Affected Components and Order Numbers

Refer to the SIMATIC NET CP 1613 device manual for the official hardware description and the S7-400H fault-tolerant systems manual for the redundancy rules governing redundant S7 connections.

Root Cause

The CP1613 exposes a configurable MAC address in addition to its factory-burned-in address. SIMATIC NET stores three MAC addresses per CP1613 instance in the PC station configuration database:

1. MAC_HW – the burned-in hardware MAC of the PCI card itself (read-only).
2. MAC_ISO – MAC used for ISO transport (S7 communication). This is the address seen by S7-400 H CPUs when establishing the S7 connection.
3. MAC_TCP – MAC used for TCP/IP-based protocols (OPC, S7 over TCP).

When WinCC project duplication is performed, the entire PC station configuration – including the configured CP1613 MAC addresses – is copied verbatim. If the project is downloaded to the second server without modifying the configured MAC_ISO/MAC_TCP values, both servers claim the same Layer-2 identity on the same broadcast domain.

The duplicate MAC is a layer-2 conflict, not a layer-3 (IP) conflict. Managed switches detect the same source MAC on two different ports and react according to their configuration:

• Disable the second-appearing port (most common).
• Log a MAC flap event and, in ring topologies managed by MRP/HRP, bring down the ring.
• Flood the duplicate-MAC notification as a broadcast, which propagates through the ring and causes both switches to enter a fault state.

Because the S7-400 H redundancy protocol uses the MAC_ISO of the partner CP1613 to identify the redundant connection, having two CPs with identical MAC_ISO values is doubly damaging: the H system cannot bind the connection to the correct WinCC server, and the network rejects the duplicate at layer 2.

Why the Station Configuration Editor and NETPro Appear Correct

A common point of confusion is that both PC stations, after duplication, show unique MAC addresses in the Station Configuration Editor. The reason is that the Station Configurator reads MAC_HW from the installed card at start-up and displays that value – which is genuinely different for each physical CP1613. The duplicate that breaks the network is MAC_ISO (and MAC_TCP), which is the address the S7 driver uses on the wire. The configured ISO/TCP MAC is set in the PC station's SCP1613.cfg and the S7ONLINE access point configuration, not in the Station Configurator's main display.

To inspect the active values, check the PC station's Configuration Console → SIMATIC NET Configuration → CP1613 → "MAC Addresses" tab, or query the registry/SIMATIC NET configuration database directly:

Diagnostic Procedure

1. Capture the duplicate MAC on the wire. Use Wireshark on a mirrored port or the switch's MAC address table to identify which two ports advertise the same MAC. Most managed switches (SCALANCE X, Cisco IE, Hirschmann RS) show this as a "MAC flap" or "MAC move" event.
2. Inspect the active ISO MAC on both servers. Open the SIMATIC NET "Configuration Console" on each PC station. Under CP1613 → "MAC Addresses", compare MAC_ISO and MAC_TCP. Identical values across the two servers confirm the diagnosis.
3. Verify the burned-in MAC is unique. In the Station Configuration Editor, the "MAC Address" field shows MAC_HW. Confirm this is different on each server.
4. Check the S7-400 H project. In NETPro, both WinCC PC stations must be configured with their respective unique MAC_ISO in the "S7 Connection" properties (redundant S7 connection). The H system will only accept the connection from the server whose MAC matches what is configured in the H station.
5. Review switch event log. SCALANCE switches log "Duplicate MAC detected" with a timestamp; this is authoritative confirmation that the conflict is layer-2.

Resolution Procedure

1. Power down the standby server (the one that was most recently built) to remove the duplicate MAC from the wire. The ring will reconverge.
2. On the original (now offline) standby server, open the Station Configuration Editor and remove the duplicated CP1613 entry. Re-insert the local CP1613 so the project binds to the physical card on this server.
3. Open SIMATIC NET Configuration Console on the standby server. Under the CP1613 module, change MAC_ISO and MAC_TCP to values unique within the broadcast domain. Convention: use the burned-in MAC_HW of the local card, which is guaranteed unique.
4. Update the S7-400 H project in NETPro so that the S7 connection to the standby WinCC server references the new MAC_ISO of the standby server's CP1613. Recompile and download the H station.
5. Re-export the WinCC project from the primary server using "Project Duplicator" or a clean export, ensuring the Station Configuration Editor's "PC station name" and the underlying CP1613 configuration are re-bound to the standby server's local hardware.
6. Bring up the standby server and verify that the ring remains stable, that both switches' MAC tables show a single port per MAC, and that the S7 connection to the H system comes up redundant.

Verification

After applying the resolution, verify the following:

• Switch MAC table: Each CP1613 MAC appears on exactly one port of each SCALANCE switch. Use the switch's web interface (Information → MAC Address Table) or CLI: show mac-address-table.
• Ring stability: No MAC flap or ring break events in the switch log for at least 24 hours.
• WinCC redundancy: WinCC Redundancy diagnostic tool shows both partners "Online" and the redundant S7 connection state is "Established (redundant)" in the S7-400 H diagnostic buffers.
• OPC / S7 channel: WinCC Channel Diagnosis shows no MAC-related error codes (e.g., 0x03000000 = "Connection partner not found").
• Persistent duplicate check: Run arp -a and a port-MAC walk on each switch; each MAC should be unique.

Prevention: Project Duplication Workflow

The proper sequence to avoid duplicate MAC addresses when adding a redundant WinCC server is:

1. Build and commission Server 1 fully. Note its CP1613 MAC_ISO and MAC_TCP.
2. When commissioning Server 2, do not download the exact project from Server 1. Instead, use the SIMATIC Manager PC station wizard to create a new PC station on Server 2 and bind it to its local CP1613.
3. If using a duplicated project, immediately after download to Server 2, open Configuration Console and reassign MAC_ISO/MAC_TCP to Server 2's burned-in hardware MAC.
4. Always update the S7-400 H NETPro project so each WinCC server's connection references its own CP1613 MAC.
5. Document both MACs in a project commissioning sheet to prevent future confusion during service or replacement.

Differentiating from Other MAC Conflicts

Firmware and Driver Notes

Use a current SIMATIC NET driver package, ideally matching the WinCC version (WinCC V7.5 SP2 → SIMATIC NET V15.1, WinCC V8.0 → SIMATIC NET V16). The CP1613 driver in older SIMATIC NET versions (pre-V13) handled MAC_ISO configuration differently and could allow the burned-in MAC to be silently overridden by the project's configured value. Updating to a current SIMATIC NET PC software version aligns the Configuration Console behavior and adds explicit MAC-edit warnings during project download.

For the S7-400 H system, the CPU firmware should be at V6.0 or later. Earlier firmware versions (V4.x, V5.x) accepted a single MAC for the redundant connection and were more tolerant of duplicates, which is why a system running 18 months without issue can suddenly expose the problem when a new WinCC server is added – the older H firmware masked the conflict.

Always check the SIMATIC NET CP 1613 release notes / compatibility list before commissioning a new redundant WinCC server pair against an existing S7-400 H installation.

Field Commissioning Checklist

• Both CP1613 burned-in MACs (MAC_HW) recorded in the project file.
• MAC_ISO and MAC_TCP for each server set to its own MAC_HW (or to a documented unique value).
• S7-400 H NETPro shows the correct MAC_ISO per WinCC server in each redundant S7 connection.
• Switch ring stable, no MAC flap events in log.
• WinCC Redundancy diagnostic: both servers "Online" with redundant S7 connection state OK.
• Failure test: pull Server 1's network cable, confirm Server 2 takes over without ring break.