Stratix Switches and Plant Network Segmentation

Choosing a Stratix switch, when a non-Rockwell industrial switch is the better answer, and how to segment a plant network in a way that reflects how the plant actually runs.

Two decisions here: what switch, and how to divide the network. The second matters far more than the first and gets a fraction of the attention.

Choosing a Stratix, or not

Stratix is Cisco hardware and IOS with a Rockwell configuration layer that integrates with Studio 5000 and FactoryTalk.

Model	Position
Stratix 2000	Unmanaged. Only where a managed switch genuinely is not needed, which is rarer than it is specified
Stratix 5700 / 5800	Managed layer 2, the mainstream plant-floor choice. 5800 is current
Stratix 5400 / 5410	Managed with higher port counts and layer 3 capability, for distribution
Stratix 8000 / 8300	Earlier managed generations, widely installed

The genuine argument for Stratix is integration, not switching. The switch appears in the Logix project as a device, its diagnostics are visible to the controls team in tools they already use, and Add-On Profiles make configuration approachable for engineers who are not network specialists. On a plant floor where IT does not own the network, that is worth real money.

The genuine argument against is cost, and that a competently configured industrial switch from another vendor does the same job for less. If your IT group owns and administers the plant network with proper tooling, the integration benefit is smaller and the price premium is harder to justify.

The question that decides it: who will administer this switch in three years? If the answer is the controls team, Stratix earns its premium. If the answer is IT with existing standards and tooling, buy what fits those standards.

Segmentation: the part that matters

Segment around how the plant actually runs, not around an idealised architecture diagram.

The reference models divide a plant into zones and conduits, with a demilitarised zone between operations and enterprise. That model is correct and it is a destination, not a starting point. The starting point is usually a flat network with everything on one subnet, and moving to the model in one project is neither fundable nor safe.

Segment around how the plant actually runs. Map the real traffic first, because segmentation designed around an org chart forces traffic through a controller or a dual-homed PC.

The order we recommend:

1. Separate control traffic from everything else. Highest value, lowest risk. Control devices should not share a broadcast domain with office printers, guest wireless or the plant’s CCTV.

2. Separate by production area. A fault on line 3 should not be able to affect line 7. This is also what makes maintenance possible: a segment you can take down is a segment you can work on.

3. Control the boundary between operations and enterprise. A firewall, and a deliberate decision about what crosses it. This is where remote access belongs as a designed capability rather than the assortment of vendor VPNs and cellular modems most plants actually have.

4. Refine within the areas as the need appears, driven by an actual requirement.

Where segmentation goes wrong is designing it around the org chart or around a diagram in a standard, then discovering that a machine on line 3 legitimately needs to talk to a system on line 7, and the traffic ends up routed through a controller or a dual-homed PC because the segmentation did not match reality. Map the real traffic first.

Configuration that is routinely missed

IGMP snooping enabled, and a querier present. Snooping with no querier is not a working configuration, and this specific gap causes a lot of multicast problems on networks that were believed to be configured correctly. See EtherNet/IP and CIP
Spanning tree considered deliberately, particularly where a ring topology is in use
Port security and unused ports disabled. An open port in an unlocked panel is an access path
Default credentials changed. Still found in production more often than anyone would like
A saved, backed-up configuration for every switch. A managed switch nobody can restore is an unmanaged switch with extra steps
Documented port assignments. What is on which port, in a document that is updated

Physical layer

More faults originate here than anywhere else in the network, and they are the least glamorous:

Connectors terminated in the field without the right tooling, particularly on ruggedised connector types
Cable routed alongside drive power cable, which is a noise coupling problem that presents as intermittent packet loss
Bend radius violated in a tray or a panel duct
Copper runs beyond 100 metres, discovered after the fact
No labelling, so tracing a link means following it by hand

A network audit that does not include walking the physical layer has not audited the network.

What we do

We map the network as it actually is, including the parts nobody documented, and design segmentation against how production really runs. We specify switches on who will administer them, configure IGMP and VLANs properly, and validate under production load rather than on a quiet network. Where a plant has a flat network and no budget for a full redesign, we sequence the segmentation so the highest-value separation happens first.