Troubleshooting Siemens IM151-8 PROFINET Remote IO Loss Over VLAN

Problem Overview

An ET200S station headed by an IM151-8 PN/PN interface module (catalog 6ES7151-8AB01-0AB0) stops responding on PROFINET while ICMP ping between the CPU and the IM remains successful. Topology in the field:

• CPU (e.g., S7-300, S7-400, S7-1200, S7-1500) connected to a managed industrial switch in the PLC control room
• Fibre uplink (single-mode or multi-mode SFP) to a second managed switch in the remote panel
• IM151-8 PN/PN terminating the PROFINET segment in the remote panel, with ET200S power modules and I/O behind it
• Both ends separated by an 802.1Q VLAN on the plant network

Symptom pattern observed: the device on the local side can be reached from TIA Portal / STEP 7 > Online > Accessible Nodes, but the device on the remote side cannot. From the remote panel switch's perspective, the situation is mirrored: the remote IM151-8 is visible but the CPU is not. Ping from either side succeeds in both directions, indicating Layer 3 is up while PROFINET Layer 2 discovery is broken in only one direction.

Affected Hardware and Firmware

PROFINET diagnostic LEDs on the IM151-8 front panel are the first confirmation of the failure mode:

• SF (red, solid) – Configuration error; check device name and PROFINET name assignment
• SF (red, flashing) – Diagnostic present; read with TIA Portal / STEP 7 or via the web server
• BF1 / BF2 (red, flashing) – No PROFINET IO controller connection / no link on the port
• BF (red, solid) – Physical link present but no PROFINET communication

Why Ping Succeeds but PROFINET Fails

ICMP echo and PROFINET IO communication use different mechanisms at Layer 2 and Layer 3, which is why a working ping is not a reliable indicator of PROFINET health.

• ICMP uses IP packets routed through the management VLAN; the switch forwards them if the VLAN ID is permitted on the trunk and a default gateway or directly connected route exists.
• PROFINET IO relies on Ethernet Type 0x8892 (PROFINET RT) frames using LLDP for neighbour detection and DCP (Discovery and Configuration Protocol, multicast MAC 01:0E:CF:00:00:00) for device-name assignment. These frames are not IP-routed and are sensitive to VLAN tagging, IGMP snooping, LLDP blocking, and broadcast/multicast filtering.

The mirror-image visibility (local device visible, remote device not) is the classic signature of an asymmetric VLAN or filter problem: DCP discovery packets can pass in one direction but are dropped on the return path, often because the destination MAC 01:0E:CF:00:00:00 is filtered on the receiving trunk port.

Root Cause Analysis Matrix

Prerequisites for the Fix

• TIA Portal V16 or later (V18 recommended for IM151-8 with firmware V3.x) installed on the engineering station
• STEP 7 V5.5 SP4 with HSPs if the project is a classic STEP 7 project
• PRONETA (free Siemens tool) for offline PROFINET diagnostics: PRONETA download (Siemens Support)
• Read/write access to the plant managed switch (e.g., SCALANCE XC, XB, or third-party Cisco/Stratix/Hirschmann)
• Backup of the project; the IM151-8 will be reset to factory defaults if the name is reassigned through DCP

Step-by-Step Diagnostic and Recovery Procedure

1. Confirm the failure mode physically. On the IM151-8, observe the LED pattern. If BF1 is flashing and SF is solid, the device is alive but the PROFINET AR is down. If only ON is lit, the backplane has no power or the IM is in a fault state.
2. Verify ping in both directions from the engineering station to the CPU and from the engineering station to the IM151-8, using each device's PROFINET interface IP address. A one-way ping loss indicates a routing or VLAN problem on the reverse path.
3. Open the IM151-8 web server by entering the IP address in a browser. The web server runs on TCP port 80/443 and shows PROFINET name, IP, port status, and the last diagnostic buffer. The web server itself is IP-based and only proves Layer 3, but it does reveal whether the IM is still configured.
4. Check the PROFINET device name in the project. If the IM151-8 has been re-assigned, a different name, or the name is empty, the IO controller will not establish an AR. Compare against the name in the project (right-click device > Properties > PROFINET interface > PROFINET name).
5. Lock the update time (most likely fix in the original case):
   1. In TIA Portal, right-click the IM151-8 in the device or network view
   2. Select Properties > PROFINET interface > Advanced options > Real-time settings
   3. Change Update time from Automatic to a fixed value (typical choices: 1 ms, 2 ms, 4 ms)
   4. Optionally set Send clock explicitly. The controller then negotiates the watchdogs based on these fixed values
   5. Compile and download to the CPU only (HW Config > right-click CPU > Compile and download)
6. Reassign the PROFINET device name and IP if the IM151-8 was ever factory-reset or replaced:
   1. Open Online > Accessible Nodes from the engineering station
   2. Right-click the IM151-8 > Assign PROFINET device name
   3. Select the configured name from the project (must match the IO system name in the CPU configuration)
   4. Confirm with the MAC address of the IM151-8 to avoid assigning to the wrong device
7. Validate VLAN configuration on both managed switches. Confirm:
   1. Trunk port carrying the PROFINET VLAN has both ends set to the same VLAN ID (commonly 100, 200, or whatever the plant standard is)
   2. Native (PVID) VLAN on the trunk is set to a black-hole VLAN, not the management VLAN
   3. MAC 01:0E:CF:00:00:00 (DCP) and Ethertype 0x8892 (PROFINET RT) are not filtered
   4. IGMP snooping does not strip the PROFINET multicast frames; for SCALANCE switches, use Multicast mode: Forwards all MAC multicast frames on PROFINET ports
   5. LLDP is enabled end-to-end (PROFINET requires LLDP for topology detection)
8. Cycle the IM151-8 by removing and re-inserting the PM-E power module, or by power-cycling the remote panel if a hard reset is acceptable. Observe the LED sequence: all LEDs on briefly, then BF1 flashing until the controller AR is established.

Recommended PROFINET Real-Time Settings

Verification Steps

1. From TIA Portal, Online > Accessible Nodes now lists both the CPU and the IM151-8 from either end
2. Open the IM151-8 online view; the status must read Connected (green) and Maintenance not required
3. Read the diagnostic buffer of the CPU. Entries 1, 2, 3 should be PROFINET IO: station failure / station return / IO device OK. No further re-connection events should appear
4. In the web server of the IM151-8, navigate to Diagnostics > PROFINET diagnostics; port state should be Link up, RT-Class 1 active
5. Force a fault test: pull one ET200S I/O module, confirm the SF LED on the IM151-8 lights, and the corresponding value in the CPU is flagged as a substitute/quality-code bad
6. Run a 24-hour soak with PRONETA's IO Test to verify no AR aborts and no discarded cyclic frames occur

VLAN and Switch Configuration Reference

For SCALANCE XC-200 / SCALANCE XR-500 switches, the relevant PROFINET-friendly configuration is:

// SCALANCE CLI (example)
configure terminal
vlan 100
 name PROFINET_VLAN
 exit
interface GigabitEthernet 1/1
 switchport mode trunk
 switchport trunk allowed vlan 100,200
 switchport trunk native vlan 1
 spanning-tree portfast trunk
 exit
// Allow DCP multicast and PROFINET RT EtherType
mac access-list extended PROFINET-PASS
 permit 010e.cf00.0000 0000.00ff.ffff any
 exit
// Disable IGMP snooping on PROFINET ports if frames are dropped
no ip igmp snooping
// Enable LLDP
lldp run

For Cisco Catalyst / IE3300 industrial switches, use mac access-list to allow MAC 010e.cf00.0000 and EtherType 8892 on the trunk ports. Never apply storm-control on PROFINET ports without raising the threshold above the cyclic frame rate.

Common Edge Cases and Field-Proven Caveats

• 15-day silent failure in the original case is consistent with a slow ARP/IGMP cache expiry plus a network-team VLAN change. The first AR aborts when the new ACL is pushed; the IO controller does not re-attempt until the next power cycle, project download, or watchdog time-out.
• Setting update time to Auto on an IM151-8 over a non-Siemens router (or any switch that drops PROFINET multicast) is a known cause of one-way AR failure. Always lock to a fixed value for non-Siemens infrastructure; Siemens SCALANCE switches handle Auto correctly.
• If the IM151-8 has been reassigned the IP of a previously used device (e.g., during commissioning), the new controller will not find it by DCP because the IP is checked together with the PROFINET name and the device's MAC must match the project record.
• ET200S IM151-8 does not support IRT, only RT-Class 1. The IO controller must not be configured for IRT on this device; otherwise the AR aborts immediately with "RT class mismatch" in the diagnostic buffer.
• MRP (Media Redundancy Protocol) clients on the IM151-8 must match the MRP manager port. If the ring was reconfigured by the network team, the IM may have been pushed out of the MRP domain and the controller sees the IM as a "non-MRP member" - ping still works because MRP is a Layer 2 mechanism separate from forwarding.

Preventive Hardening

• Document the PROFINET device names and IP addresses in the project and on a laminated card inside the remote panel
• Reserve the PROFINET VLAN and tag it on every trunk port as a permanent configuration; remove write access for general network admins
• Use PRONETA in "Network Analysis" mode during the annual plant shutdown to detect silent LLDP or DCP issues
• Enable SNMP traps for PROFINET port link-down and MRP state-change on the SCALANCE switches and forward to the control room alarm system
• Lock update time on all remote I/O stations in the project, even on Siemens switches, to make the configuration deterministic and portable

Quick-Reference Diagnostic Command List