Selecting Managed vs Unmanaged Switches for EtherNet/IP

Seventy-five nodes on one controller is not a switch problem until you know where the packets originate and what forwarding behavior they demand. Follow the packet first. Five AENTR adapters, sixty drives on explicit messaging, and ten Modbus/TCP endpoints do not generate one kind of traffic — they generate three, and each one loads a different resource. Get the traffic model right and the switch decision falls out of it.

Where does each packet start and stop?

Three distinct conversations share the same copper.

Traffic	CIP class	Transport	Rate driver	Resource consumed
AENTR remote I/O	Class 1 implicit	UDP 2222, unicast or multicast	RPI, continuous	Class 1 connection + packets/sec on the controller's Ethernet module
VFD explicit messaging	Class 3 or unconnected	TCP 44818	MSG instruction trigger rate	Class 3 connection if cached; unconnected buffer if not
Modbus/TCP AOI	Not CIP	TCP 502 via socket services	AOI poll interval	Socket instance on the Ethernet module

The I/O traffic is the only continuous, deterministic stream. Each unicast Class 1 connection produces one producer frame and one consumer frame per RPI, so the load per connection is roughly 2 x (1000 / RPI_ms)packets per second. Sixty drives read and written every few seconds is arithmetic noise on the wire.

Check before moving on: total the Class 1 connections, Class 3 connections and socket instances, and compare them against the connection and packets-per-second figures in the technical data for your specific EtherNet/IP module. Sixty drives with a read MSG and a write MSG each is 120 messages; if you cache all of them, that is 120 Class 3 connections held open permanently, plus five I/O connections, plus ten sockets. That number, not the switch, is what usually stops a project this size. If it exceeds the module limit, either uncache the low-priority MSGs and sequence them so only a handful are in flight at once, or add a second Ethernet module and split the drives onto it.

Is the traffic unicast, or does it still flood?

This is the single technical question that separates "unmanaged is fine" from "unmanaged will bite you." EtherNet/IP Class 1 producer-to-consumer data was historically multicast so several consumers could subscribe to one producer. Current Logix controllers default the I/O connection to unicast, and if every connection on the network is unicast, an unmanaged switch forwards each frame out exactly one port after it has learned the MAC. No flooding, no problem.

The moment one device or one connection reverts to multicast, an unmanaged switch has no IGMP snooping and treats the multicast group like broadcast: every frame out every port, including the ports feeding your HMIs and any PC plugged into the panel. On a small machine that is invisible. Across sixty drives and five remote panels it turns into background load on every NIC, and the symptoms show up as intermittent I/O connection faults on whichever device has the weakest stack.

Snooping alone is not enough. IGMP snooping is a listener — something has to send periodic membership queries or the group memberships age out and the switch either floods again or blackholes the group. One IGMP querier per VLAN, enabled explicitly on a managed switch. That is a configuration item, not a checkbox you can ignore because the datasheet says "IGMP supported."

1. Open the module properties for each AENTR adapter and confirm the connection is set to unicast.
2. Confirm any third-party or legacy adapter on the same segment also negotiates unicast; older adapters may not offer the option.

What does layer one look like across five remote panels?

Five remote panels means five cable runs leaving the main enclosure. Layer one first: run the numbers before you argue about switch features.

• Copper segment length stays under 100 m end to end including patch leads. Anything longer, or anything crossing a building gap or a high-noise area, goes to fiber. Unmanaged switches with fiber uplinks exist; you are not forced into managed hardware to get fiber.
• Verify each link negotiates 100 Mbps or 1 Gbps full duplex. A duplex mismatch on a hard-set port produces late collisions and CRC errors that look exactly like a bad cable, and it is the most common cause of an I/O connection that drops once an hour.
• Bond and terminate shields per the panel's grounding scheme. Do not route Ethernet parallel to drive motor leads. Sixty VFDs is sixty PWM noise sources.

The diagnostic gap: on an unmanaged switch there is no way to read the per-port error counters. A cable with 0.1% CRC errors will keep passing traffic and keep faulting connections, and you will find it by swapping cables one at a time. On a managed switch you read the port statistics and know in thirty seconds which run is bad. That is the real value proposition, and it is worth more than VLANs on a plant floor.

Can a loop take this network down?

A layer 2 loop on an unmanaged network is unrecoverable without unplugging cables. Broadcast frames circulate at line rate, MAC tables thrash, and every device on the broadcast domain goes deaf. Five remote panels give five opportunities for a well-meaning technician to patch a spare port back to the trunk.

Managed switches run RSTP and block the redundant path in under a second. They also log it: a syslog server — Graylog Open is free and adequate — gives you the correlation that turns a two-day hunt into a two-minute read.

Port and timestamp identify both the device and the person who was working there. Reverse the change and you are running again.

Check: after commissioning, deliberately patch two ports on the same switch together in a maintenance window and confirm one port blocks and the event is logged. If the network collapses instead, STP is not enabled or the edge ports are misconfigured.

One flat subnet, or a panel network and a plant network?

Separate the machine's device-level traffic from anything plant-wide. If the controller has two Ethernet ports, or you have a spare Ethernet module, use them: one interface faces the AENTR racks, drives and Modbus/TCP devices on a private device subnet; the other faces the HMIs and the plant. No routing required, no layer 3 switch, no VLAN configuration.

Requirement	Minimum switch class
All-unicast I/O, single flat device subnet, no loops	Unmanaged
Any multicast I/O connection	Managed with IGMP snooping + querier
Redundant or ring topology	Managed with RSTP or a vendor ring protocol
Per-port error counters, SNMP, syslog	Managed
VLAN separation of drives from controllers on one physical network	Managed layer 2
Routing between device and plant subnets	Managed layer 3
Remote access to drives from an engineering workstation	Managed, or a routed path

The controller-branded switches carry a price premium and are a rebadged enterprise platform underneath. Unless you need CIP Motion or the vendor's I/O-tree integration, Moxa, Hirschmann and Phoenix Contact deliver the same layer 2 feature set at a lower cost with DIN-rail form factors and 24 VDC redundant inputs.

What breaks with unmanaged, and how would you know?

Symptom	Likely cause	What unmanaged costs you
Intermittent I/O connection faults on one rack	CRC errors from a marginal cable or duplex mismatch	No port counters; found by cable swapping
Entire segment goes deaf, no single device faulted	Layer 2 loop	No STP, no logs; found by unplugging ports
General latency and CPU load rising as devices are added	Multicast flooding without IGMP snooping	No snooping; requires a capture to diagnose
MSG instructions timing out under load	Connection or socket exhaustion on the Ethernet module	Switch is not the cause; check module diagnostics
Unknown device appears on the network	Unauthorized laptop or added node	No port-to-MAC table, no way to locate it

Pitfall to avoid regardless of switch class: do not enable static MAC port security on drive ports. When a drive fails at 02:00 and maintenance swaps in a spare, the new MAC is not whitelisted and the replacement will not talk to the controller. You will be on the phone. Use port security only where the device population is stable and someone is on call to update it.

How do I commission this on a budget?

If managed switches were not in the original quote, spend selectively rather than going fully unmanaged.

1. Put a managed switch at the head end — the enclosure where the controller, its Ethernet modules and the HMIs land. This is where every packet passes, so this is where port counters, STP root and syslog matter most.
2. Feed the five remote panels from that head-end switch. Unmanaged switches inside the remote panels are acceptable if the traffic there is all unicast and each panel is a stub with no possible loop path.
3. Assign the head-end switch a fixed IP on the device subnet and record it in the panel drawings, since it will not appear in the controller's I/O tree unless you add it with a profile or EDS file.
4. Enable RSTP on the head-end switch, set edge/portfast on all device access ports, and confirm the switch is STP root.
5. Enable IGMP snooping and the querier on the device VLAN even if everything is currently unicast. It costs nothing and covers the day someone adds a multicast-only adapter.
6. Point SNMP traps and syslog at a collector. Free is fine.
7. Leave 20% of ports spare. You will add devices.

Cost the alternative honestly: days of network debugging with no port statistics is not in the budget either, and it lands during startup when the schedule has no float.

End-to-end verification

Run this sequence with the machine energized and the controller in RUN before you hand over.

1. Confirm every port shows the expected speed and full duplex, and that the MAC table maps each port to the device you expect.
2. Open the controller's Ethernet module diagnostics and read the connection count, socket count and CPU utilization against the module's published limits. Leave headroom for the drives you will add later.
3. Force a fault on one AENTR link: pull the cable, confirm the module status bit and the syslog port-down event both appear, reconnect, and confirm the I/O connection re-establishes without a controller fault.
4. Patch a deliberate loop in a maintenance window, confirm one port blocks and the event is logged, then remove it.
5. Trigger all 120 drive MSG instructions simultaneously and watch for MSG error codes and connection timeouts. If any appear, reduce the number of concurrent messages or uncache the low-priority ones and re-run.

FAQ