Managed vs unmanaged switch: it's the traffic and the loops, not the device count

The call usually comes right after the switch quote does. A PLC, a few remote I/O racks, forty-some drives, and a line item for managed switches that never made it into the budget. Can we just go unmanaged? We did it on the last job and it was fine.

Sometimes it really was fine. The managed vs unmanaged switch call on a PLC network has very little to do with how many devices you plug in. It comes down to what kind of traffic is on the wire and whether anything can close a loop. Then there's the part people only start to value after the first bad night: being able to see inside the switch when a rack starts dropping out.

Below is how I sort it out, including the places where a managed switch causes its own trouble, and the mixed layout I end up with on most machines.

Managed vs unmanaged switch: the short version

On a PLC network	Unmanaged switch	Managed switch
Multicast (some I/O, produced and consumed tags)	Treated like broadcast, copied out of every port	IGMP snooping sends each stream only to the ports that joined it
A stray cable that closes a loop	Storm; the segment is down until someone pulls the cable	Spanning tree blocks the extra path
Rings (DLR, MRP)	Can't be a ring node	Ring-capable models join the ring or run it
Watching I/O traffic from a laptop	You only see traffic addressed to the laptop	Port mirroring copies any port to the laptop
Diagnostics	Link LEDs	Per-port diagnostics, SNMP, alarm relay; on Stratix, port status in Logix Designer
Speed and duplex	Auto-negotiate only	Can be fixed per port; the device must match
Security	Any device, any port	VLANs, port security, ACLs, depending on the model
Swapping a failed device	Plug it in	Plug it in, unless port security is holding the old MAC
Setup	None	IP address, password, config backup

 

Device count isn't a row in that table, and Rockwell's own conditions for an unmanaged switch don't mention it either. No I/O traffic on it at all, fine. With I/O on it, all three of these have to hold: the network isn't tied straight into the IT network, every node on it is a Rockwell device, and nothing on it can get buried in more traffic than it can handle. Whether the switch is industrial-rated is a separate question from managed, more on that further down.

The third condition is the one people skip. Multicast is usually what breaks it.

Where multicast goes on an unmanaged switch

Unicast is easy. Any switch, managed or not, learns which MAC address lives on which port and sends unicast frames only there. Multicast is where the managed vs unmanaged switch difference actually lives. Without IGMP, a switch handles a multicast packet the same way it handles a broadcast and repeats it out of every port.

Say a ControlLogix produces a tag that three other controllers consume over a multicast connection. Behind an unmanaged switch that stream also lands on the HMI, the engineering laptop, every drive, and a Modbus TCP gateway that has no use for it. Most devices drop it and move on. A device with a small network processor doesn't always keep up, and that's the one that starts throwing connection faults nobody can explain. I've pulled more than one "bad" drive that was just buried in traffic meant for someone else.

Current Logix defaults a new consumed tag to a unicast connection, and newer I/O like PointMax defaults to unicast as well. Multicast isn't gone, though. It's one unchecked box away on any consumed tag, and a ControlLogix redundancy system needs it outright: enable redundancy on a controller that has unicast connections in the project and the secondary won't qualify. Before anyone says "we're all unicast now," open the connection settings on the modules and tags that matter and look.

IGMP snooping, and the querier people forget

Snooping is what a managed switch does about all this. It listens to the join and leave messages devices send, builds a table of which ports want which multicast group, and forwards each stream only to those ports. Entries that stop getting refreshed get deleted.

That refresh is the catch. Devices re-report their memberships because something on the VLAN keeps asking them to, and that something is the IGMP querier. No querier, no fresh reports, and the table drains. On a Cisco Catalyst 2960-X, for example, snooping ships enabled on every VLAN and the snooping querier ships disabled. So a brand-new managed switch can have snooping switched on and nothing keeping it fed. Stratix Device Manager even has an Extended Flood option whose whole job is to stop the switch from dropping multicast when the querier drops out.

The querier belongs on the router if the network has one. No router, put it on one centrally located IGMP-capable switch, and write down which box it is.

There's a ceiling, too. A Stratix 5700 has room for 0.25K IGMP groups plus multicast routes, a couple of hundred in total, and it's the same figure in every memory template the switch offers. Go past a switch's multicast group limit and you get dropped traffic, intermittent performance, and poor handling of traffic bursts. On the floor that looks exactly like a flaky connection.

One multicast stream, two switches. Without IGMP snooping it's copied to every port; with snooping and a querier it reaches only the two controllers that joined the group.

The loop nobody planned

Every plant eventually gets one. A patch cable left hanging in a panel, and somebody plugs its free end into another port on the same switch to "make sure it's connected." On an unmanaged switch that's a loop, and Ethernet loops don't degrade gracefully. Broadcast and multicast frames keep circling, copies stack up, and the segment is unusable until someone finds the cable and pulls it.

A managed switch running spanning tree sees the second path and blocks it. That alone pays for the switch the first time maintenance fixes a network by adding cables.

A ring is the same loop, built on purpose. On a Device Level Ring the supervisor keeps one of its two ring ports blocked and only opens it when the ring breaks somewhere else. Without a supervisor configured, a ring is just an unmanaged loop, and closing it early can take the whole network down until one link is disconnected again. So I build every new ring as a straight line, set up the supervisor, and close the last link at the very end. PROFINET rings work the same way, with MRP and a redundancy manager doing the blocking.

Which is also why an unmanaged switch can't sit in the ring. Only DLR-capable devices connect directly to the ring. Everything else, unmanaged switches included, hangs off a non-ring port on a DLR-capable switch or off an EtherNet/IP tap like the 1783-ETAP.

A patch cable plugged into two ports of the same unmanaged switch is a loop. A DLR ring is a loop too, but the supervisor keeps one port blocked, and non-ring gear hangs off a 1783-ETAP instead of sitting in the ring.

What you're really paying for is being able to see

This is where managed vs unmanaged switch stops being a theoretical argument: a remote I/O rack drops its connection every few hours and nobody knows why. Plug a laptop into a spare port on an unmanaged switch and you'll see broadcasts, maybe some multicast, and none of the I/O you care about. That I/O is unicast, point to point, and the switch sends it only to the adapter's port. To capture it you'd have to put a tap inline, which means breaking the very connection you're trying to watch.

On a managed switch I mirror the PLC's port to my laptop and read the whole exchange in Wireshark without touching the machine. Every Stratix 5700 does port mirroring, Lite included. On top of that you get per-port diagnostics, SNMP for whatever monitoring system the plant runs, port and ring status you can check straight from Logix Designer, and an alarm relay that can trip on power supply, port, or environmental alarms. Wire that relay to a spare input and the PLC hears about a power supply alarm on the switch before anyone opens the panel.

Speed and duplex is the other trap, and this one bites on unmanaged switches. They only auto-negotiate. Hard-code a PLC or adapter port to 100 Mbps full duplex, plug it into one, and communication gets impaired, which means transmission errors. On an unmanaged switch, leave the device on auto-negotiate. A managed switch lets you fix the port, but then fix the device to the same setting. Both ends, every time.

Where a managed switch bites back

Managed switches cause their own downtime, and it's almost never the hardware.

Port security is the usual one. Someone locks each port to the MAC address of whatever is plugged into it, which looks great in a network audit. Then a drive fails, maintenance swaps in the identical model, and it won't talk. Different drive, different MAC, and to the switch an unknown MAC on a secured port is a security violation. The drive is fine, and the switch is doing exactly what it was set up to do. Third shift has no way of knowing either.

Then there's the login. A managed switch needs an IP address and credentials before any of its features are worth anything; on a Stratix that's the Express Setup step. If nobody wrote the password down, you own an expensive unmanaged switch until somebody factory-resets it, and the reset takes the configuration with it.

So if you go managed, spend the hour. Record the IP address and the password, which switch is the querier, which ports have security turned on, and keep a config backup where maintenance can actually find it. Skipping that hour is how managed switches got their reputation for trouble.

Managed vs unmanaged switch is one question, industrial rating is another

These get mixed up constantly. Industrial is about temperature, power input, vibration, and hazardous-location listings. Managed is about software. Any combination exists, and inside one family the numbers move around more than you'd guess.

	Stratix 2000, Series B (1783-US)	Stratix 5700 (1783-BMS)	ArmorStratix 5700 (1783-ZMS)
Management	Unmanaged	Managed, Lite or Full firmware	Managed
Operating temperature	-10 to +60 °C on 1783-US5T and 1783-US8T; -40 to +75 °C on the rest	-40 to +60 °C	-40 to +60 °C
Enclosure rating	IP30, open style	IP30, open style	IP66, IP67, and Type 4
Connectors	RJ45, fiber on some models	RJ45, SFP and combo ports	M12 D-code and X-code
Power input	12-48V DC or 18-30V AC	12-48V DC, two inputs	12-48V DC (9.6-60V DC on PoE models)
Alarm relay	None	Yes, 1 A at 30V DC	PoE models only
Hazardous locations	Class I, Div 2	Class I, Div 2	Industrial control equipment listing only
Where it goes	Inside a panel	Inside a panel	On the machine

 

Look at the first two columns again. A 1783-US16T/B, which is unmanaged, is rated for 75 °C surrounding air. The managed 5700 stops at 60 °C. If the reason for going managed is "that panel runs hot," you're paying for the wrong feature. On surplus units, check the series on the label as well: the older Series A 1783-US5T/A and 1783-US8T/A are rated 0 to 60 °C, and Series A units carry IP20 instead of IP30.

The IP rating is worth a couple of sentences. IP30 keeps out objects 2.5 mm and up and gives no water protection at all, so it's a panel-interior rating and nothing more. On-machine gear goes to IP66 and IP67, and those are separate tests: 7 is temporary immersion, 6 is powerful water jets. A device marked only IP67 isn't promised to survive a washdown hose, which is why the ArmorStratix label carries both numbers.

The layout I end up using

Most of the time the honest managed vs unmanaged switch answer is both, in different places. Say you've got a ControlLogix, four remote I/O racks, about forty drives, and a couple of Modbus TCP devices. Here's roughly how I'd lay it out:

·       Unmanaged switches as collectors inside the machine, one per drive cabinet, carrying only that cabinet's unicast traffic. Every device on them stays on auto-negotiate.

·       One managed switch at the core, where the collectors land and the PLC connects. IGMP snooping on, a querier on this switch or on the router above it, one free port set aside for mirroring. The Modbus TCP devices go here too, which keeps every collector all-Rockwell.

·       Storm control on the core ports that feed the collectors, so a loop inside one cabinet gets capped at the core port instead of spilling into the rest of the machine.

·       Remote I/O racks straight onto managed ports if the port count allows. Those are the connections you'll want to mirror first.

·       A NAT device at the machine boundary when the OEM ships every machine with the same IP scheme. A 1783-NATR does 1:1 translation, and a few 5700 models, the 1783-BMS10CGN for one, have NAT built in.

·       Plant-side traffic, historians, MES, remote access, never touches the collectors.

The collectors cost little. The core switch is where the money goes, and it's the only box in the machine anyone will ever need to log into.

The layout that usually settles the managed vs unmanaged switch question: unmanaged collectors in the drive cabinets, a managed core that the PLC and remote I/O plug into, and NAT where the machine meets the plant.

Frequently asked questions

Can I use a managed switch as an unmanaged switch?

Plenty of people do: one managed model for every job, with only the features that job needs turned on. Just give it an IP address and a password you've written down on day one, since a managed switch nobody can log into gives you none of the benefits and all of the reset hassle. Check the multicast defaults while you're in there. Snooping on with no querier is how some switches ship.

How can you tell if a switch is managed or unmanaged?

Start with the faceplate. A managed industrial switch usually has a console port, a setup button, and alarm contacts next to the power terminals; a Stratix 5700 has all three plus two power inputs. An unmanaged Stratix 2000 has ports, LEDs, and a power terminal, and that's it. If it answers a ping or serves a web page, it's managed. On Allen-Bradley gear the catalog prefix settles it: 1783-US is the unmanaged Stratix 2000, 1783-BMS is the managed 5700.

Do I need a managed switch if I have a router?

They do different jobs. The router moves traffic between subnets, and it's often the right home for the IGMP querier. It has no say over what a multicast stream does inside the VLAN; that's the switch, through snooping. A router on top with unmanaged switches underneath still floods every multicast packet to every port below it.

Managed vs unmanaged switch for EtherNet/IP remote I/O: which one?

Managed, at least where the PLC and the racks meet. If every I/O connection is unicast and the network is isolated, an unmanaged switch will pass the traffic, but you give up port mirroring, and that's the tool you'll want the day a rack starts faulting. If any of that I/O is multicast, or it's a redundancy system, you need snooping and a querier, and that means managed.

Does the managed vs unmanaged switch choice depend on how many devices I have?

Less than people think. A dozen devices trading multicast on an unmanaged switch can cause more grief than sixty on isolated unicast. Count matters elsewhere: the multicast group ceiling on a managed switch, and ring size, where a DLR should stay at 50 nodes or fewer.

Does it have to be a Stratix on an Allen-Bradley network?

No. Any managed switch with IGMP snooping and a querier handles EtherNet/IP multicast; a Hirschmann RSPE, for one, does snooping and querier per VLAN and has EtherNet/IP and PROFINET profiles. What a Stratix adds is the Logix side, with port and ring status right inside Logix Designer. If nobody on site will use that, it isn't worth paying extra for.

Before you order switches for the next panel

Whichever way the managed vs unmanaged switch decision goes, we keep both kinds on the shelf at IQElectro. Unmanaged: Stratix 2000 units like the 1783-US5T and the 1783-US16T, and Phoenix Contact's FL SWITCH SFNB 5TX. Managed: Stratix 5700 in Lite and Full, including the 1783-BMS10CGP and the NAT-capable 1783-BMS10CGN, and Stratix 5200 like the 1783-CMS10P. Plus the pieces that go around them: the 1783-ETAP for hanging a device off a ring and the 1783-NATR for the machine boundary. Everything ships tested with a two-year warranty. Send the catalog number or a photo of the label and we'll confirm what's in stock before you order.