Industrial Ethernet Reliability Starts With Fundamentals Most Plants Overlook

Industrial Ethernet reliability is decided less by the devices on the network than by three fundamentals: how switches are chosen and connected, how IP addresses are assigned, and whether subnet masks agree. Unmanaged switches, ad hoc addressing and mismatched masks all work at small scale, which is why they survive commissioning. As a plant adds equipment and connects it to SCADA, MES and remote access, they turn into intermittent, hard-to-diagnose downtime. Fixing them takes a managed, segmented architecture, a written addressing standard and one owner for the network.

Introduction

Seemingly minor OT networking decisions continue to be a leading contributor to production instability, delayed commissioning, and avoidable downtime. In many manufacturing environments, components such as unmanaged switches, IP addressing schemes, and subnet configuration are treated as settled details once initial connectivity is established. Devices respond, communication appears functional, and attention shifts to higher level system objectives.

This assumption does not hold over time. As production systems expand, integrate additional equipment, or connect to supervisory and enterprise platforms, these early decisions begin to constrain reliability. Networks that functioned adequately at small scale often fail to behave predictably under normal operating conditions. The resulting issues are rarely catastrophic at first. They surface as intermittent communication loss, unexplained device unavailability, or fragile behavior during routine changes.

Framing networking fundamentals as an operational concern

OT networking fundamentals should be viewed as operational risk controls rather than technical configuration details. Systems can appear healthy while remaining structurally fragile. Communication works until it does not. A laptop configuration changes, a second device is introduced, or a subnet boundary is crossed, and previously stable systems fail without clear indication of why.

From a leadership perspective, these failures are problematic not because they are complex, but because they are difficult to anticipate and diagnose. Responsibility becomes fragmented across engineering, maintenance, and IT teams. Recovery time increases, and confidence in the underlying system erodes.

Why this topic demands renewed attention

As manufacturing organizations pursue greater connectivity, the tolerance for foundational network ambiguity has effectively disappeared. Data driven operations, remote access, centralized monitoring, and cross site standardization all depend on consistent behavior at the control network level. When that foundation is built on undocumented assumptions or convenience driven decisions, modernization efforts slow, risk increases, and change becomes progressively harder to justify.

This article examines unmanaged switches, IP addressing, and subnet configuration through the lens of operational reliability. The objective is not to revisit networking theory, but to clarify why these fundamentals continue to determine whether production systems remain stable as complexity increases.

How unmanaged switches shape plant floor behavior

Why simplicity becomes a liability at scale

Unmanaged switches remove visibility and control at the exact moment systems begin to grow. In isolation, an unmanaged switch behaves exactly as most engineers expect. It forwards traffic, requires no configuration, and immediately solves the problem of limited Ethernet ports during commissioning or troubleshooting. In early stages, this simplicity feels efficient and appropriate. Unmanaged switches become the default solution the moment a laptop, a drive, and a controller all need to communicate at the same time.

The problem emerges when this temporary convenience becomes embedded in the production environment. Once unmanaged switches are left in place and additional devices are connected, the network begins to change in ways that are not observable. Traffic increases, broadcast behavior expands, and devices that were previously quiet now compete for attention. Because unmanaged switches offer no diagnostics, no traffic insight, and no indication of load, engineers lose the ability to understand what is happening on the wire. When communication degrades, teams are forced to guess whether the issue sits with a device, a cable, or the network itself. Reliability suffers not because the switch fails, but because the system becomes impossible to see.

Two technical behaviors make this worse than it sounds. First, an unmanaged switch has no way to manage multicast, so it treats multicast traffic like broadcast and floods it to every port. EtherNet/IP I/O connections can use multicast, so on a flat network every device receives traffic meant for a few. Second, most unmanaged switches have no loop protection. One extra patch cable between two switches creates a loop, broadcast frames circulate without end, and the resulting storm can take down every connection on the segment. The Converged Plantwide Ethernet design guide published by Rockwell Automation and Cisco describes both problems and recommends managed switches throughout the cell and area zone. Its comparison reduces to this:

Capability	Unmanaged switch	Managed switch	Why it matters on the plant floor
Configuration	None	Required at installation	Unmanaged is faster to install and replace; managed needs a saved configuration and someone who owns it
Diagnostics	None	Port status, error counters, traffic statistics	Without counters, every fault starts with guessing
Multicast management	Floods multicast like broadcast	IGMP snooping limits multicast to ports that asked for it	Unneeded traffic loads controllers and I/O adapters
Loop prevention	Usually none	Spanning tree or a ring protocol	One stray cable can cause a storm that stops the segment
Segmentation	None	VLANs	Without it, a fault or a scan anywhere reaches everything
Port mirroring	None	Copies traffic to an analysis port	Lets an engineer see what is on the wire during an incident
Security	None	Port security, access control	Any device plugged in joins the network

Why port availability drives architectural shortcuts

Physical port limitations often dictate network design more than intentional architecture. On the plant floor, decisions are frequently shaped by what is immediately available. A laptop has one Ethernet port. A drive has a single network connection. A controller exposes two ports, but only one is configured. In that moment, adding an unmanaged switch is the fastest way to move forward. In that scenario the switch exists not as a design choice but as a necessity to continue work.

Over time, these decisions accumulate. A switch added for commissioning remains after startup. Another is added when a second device is introduced. Eventually, the production network is built from a series of practical compromises rather than a defined structure. At that point, no one can clearly describe where traffic flows, how failures propagate, or which devices depend on one another. What began as a short term workaround becomes permanent infrastructure, and the network evolves without ownership or intent.

This is why many plants struggle to explain their network topology or identify failure domains when issues arise. The architecture was never consciously designed. It was assembled incrementally, driven by port availability and time pressure rather than long term reliability considerations.

Our companion piece on unmanaged switches and OT cybersecurity looks at the same devices from the security side.

IP addressing discipline as an industrial Ethernet reliability control

Why correct communication can still be fragile

Devices can respond correctly while the system remains structurally misconfigured. One of the most misleading aspects of IP based communication in OT environments is how easily a system can appear healthy. A device responds to a ping. A configuration tool connects without error. From the outside, everything looks correct. That apparent success often depends on very specific conditions that are accidental rather than intentional.

During commissioning, engineers confirm connectivity and move forward, assuming the addressing scheme is sound. In reality, the system may only be functioning because all devices happen to sit within a narrow and fragile configuration window. A single change to a laptop address, the addition of another device, or a modification to a subnet parameter can break communication entirely. When this happens, failures do not follow a clean pattern. Devices may drop in and out of reach, or respond in some tools but not others. For leadership teams, this is a particularly dangerous situation because it creates instability without obvious indicators of where the problem resides.

Why IP conflicts are rarely the real problem

Address conflicts are symptoms. Inconsistent standards are the root cause. When IP issues surface, they are often described as isolated conflicts that require quick resolution. An address is changed, communication is restored, and the incident is considered closed. This approach treats the symptom rather than the system. Without a consistent addressing strategy and clear documentation, every change introduces new assumptions that remain untested until the next failure occurs.

Over time, these incremental fixes create an environment where only a small number of individuals understand which address ranges are safe, which devices are sensitive to change, and which combinations should be avoided. This reliance on tribal knowledge increases operational risk and slows response during critical events. From an executive standpoint, the concern is not the presence of IP conflicts themselves, but the absence of shared rules governing how addresses are assigned and maintained. Without that discipline, reliability becomes dependent on memory rather than design.

What an addressing standard should define

An addressing standard does not need to be long. It needs to answer, in writing, the questions an engineer would otherwise answer from memory. Plant networks should draw from the private ranges defined in RFC 1918, and every rule below should be the same on every line.

Element	What the standard defines	What goes wrong without it
Range per line or cell	Which block of addresses belongs to each line, cell or machine	Two OEM skids arrive with the same default addresses
Subnet mask	One mask per network, used by every device on it	Devices disagree about who is local and fail intermittently
Reserved ranges	Addresses kept for laptops, commissioning tools and temporary devices	A technician’s laptop takes a controller’s address
Gateway convention	Which address is the gateway on every subnet	Devices cannot reach SCADA or the historian once routing is added
Assignment method	Static, or reserved through BOOTP or DHCP, per device type	A replaced device comes up with a different address, or none
Register and change process	One maintained list, and who approves a change	The only record is the last engineer’s memory

For a step-by-step treatment of the addressing itself, see our guide to IP addresses in industrial automation and OT networks.

Subnet masks as hidden failure multipliers

Why subnet mismatches cause disproportionate downtime

Subnet configuration errors produce failures that look random but are entirely deterministic. Subnet masks sit in an uncomfortable middle ground between physical infrastructure and application behavior. When they are misaligned, nothing about the failure feels intuitive. Cables are connected correctly. Devices are powered and healthy. IP addresses appear to be in the expected range. Yet communication fails completely. A device that was reachable moments earlier becomes unreachable after a seemingly minor change, even though nothing physical has changed.

From an operational standpoint, this type of failure is especially damaging because it defies first level troubleshooting instincts. Teams naturally suspect cabling, ports, or hardware faults. Time is spent reseating connectors, swapping devices, or rebooting systems. Only later does the investigation move toward addressing and subnet logic. For executives, the key point is not the technical detail of subnet masks, but the impact on recovery time. These issues consume far more troubleshooting effort than their simplicity would suggest because they are invisible until someone looks in exactly the right place.

How a subnet mask decides who can talk

Every IP device holds an address and a subnet mask. The mask tells the device which addresses are on its own network, and therefore reachable directly, and which must be sent to a gateway. The notation in RFC 4632 writes this as a prefix: /24 means the first three numbers of the address identify the network. The important detail is that each device applies its own mask. If two devices disagree, they reach different conclusions about whether they can talk.

The cases below are illustrative, using a controller at 192.168.1.10 with a /24 mask (255.255.255.0).

Second device	Its address and mask	What happens	Why
Laptop, correctly set	192.168.1.50 /24	Communicates normally	Same network, same mask, both sides agree
Laptop on the wrong subnet	192.168.2.50 /24	Fails both ways	Each side sees the other as remote and there is no router
Laptop with a narrower mask	192.168.1.200 /25	Fails, although the address looks right	The controller sees the laptop as local, but the laptop sees the controller as remote and sends everything, including its replies, to a gateway
Drive with a wider mask	192.168.1.20 /16	Works today, fails when a routed subnet is added	The drive thinks every 192.168.x.x address is local and never uses the gateway

The last two rows explain many of the failures that “respond in some tools but not others”. Discovery tools that browse by broadcast can still see a device whose ordinary traffic is being sent to the wrong place, so the device appears in a list and then refuses a connection. Nothing is broken in the hardware. Two devices simply disagree about the shape of the network.

Why these failures erode confidence in systems

Subnet related issues undermine trust because they fail without warning and without clear indicators. Unlike component failures that present alarms or error states, subnet mismatches often provide no direct feedback. Devices simply stop responding. In complex environments, this creates doubt about the stability of the entire automation stack. Teams begin to question whether systems can be safely modified or expanded without unintended consequences.

This dynamic matters at a leadership level because it changes behavior. When teams lose confidence in the predictability of the network, they become more cautious about change. Improvements slow down. Modernization initiatives are delayed. What began as a basic configuration oversight becomes a cultural barrier to progress.

Why vendor specific configuration amplifies risk

Subnet changes often require device specific knowledge that is not consistently retained. Applying subnet modifications is rarely as simple as changing a value in one place. Changing a subnet often means adjusting several parameters and rebooting the device before the change takes effect. Each vendor implements this process differently. Drives, controllers, and network modules all expose subnet configuration in their own way, often buried deep in menus or parameter lists.

When this knowledge lives only with individuals rather than in documentation, the organization becomes fragile. Routine changes take longer. Mistakes are more likely. Recovery from issues slows dramatically when the person who last touched the configuration is unavailable. Over time, this creates extended downtime from problems that should be straightforward to resolve. The risk is not the complexity of the technology itself, but the lack of shared understanding around how these fundamental settings behave across the installed base.

Cascading unmanaged switches and architectural fragility

Why daisy chaining works until it does not

Extending unmanaged switches increases reach but collapses fault isolation. One pattern is extremely common on the plant floor. Communication fails when there is no physical path between devices, then immediately recovers once a second unmanaged switch is connected. From an engineering perspective, this reinforces the idea that the solution is valid. The system works again, production can continue, and attention moves elsewhere.

What is less visible is how each additional switch changes the behavior of the network. Every unmanaged switch expands the broadcast domain and removes another opportunity to understand where traffic is flowing. When a fault occurs, it no longer affects a single device or cable. It propagates across a wider portion of the system. Diagnosing the root cause becomes more difficult because there is no clear boundary between normal behavior and failure. The network still forwards traffic, but the system as a whole becomes harder to reason about.

From a business standpoint, this is a trade that favors speed over resilience. The architecture supports immediate needs but provides no margin as the system grows. When load increases, when devices age, or when new equipment is introduced, failures appear in places that seem unrelated to the original change.

How cascading designs increase operational risk

Cascaded unmanaged switches amplify the impact of small changes. In a simple network, a misconfigured device or failing cable affects a limited area. In a cascaded design, the same issue can disrupt communication across multiple machines or an entire line. Because there is no segmentation or visibility, teams often respond by restarting systems or rolling back recent changes without understanding the underlying cause.

This dynamic increases mean time to recovery and creates hesitation around making improvements. Each change carries the fear of unintended consequences, even when the change itself is minor.

The remedy is segmentation: split the network into zones, usually one per line or cell, with a managed switch and VLANs at the boundary so a fault or a storm stays where it started. CISA’s segmentation guidance makes the same case for security reasons, and the two goals reinforce each other. Our guide to OT network segmentation in brownfield plants covers how to introduce it without a shutdown.

Why these designs persist in production

Lack of architectural ownership allows temporary solutions to become permanent. Once production stabilizes, there is rarely a forcing function to revisit network design. The system works well enough, and the risk of disruption discourages change. Over time, the original context of why switches were added is lost. Documentation lags behind reality, and the architecture becomes something the organization inherits rather than chooses.

It is only after a major outage that the cost of this approach becomes visible. At that point, redesigning the network requires downtime, coordination, and capital that could have been avoided with earlier intervention. The persistence of these designs is not a technical failure. It is an organizational one, rooted in the absence of clear ownership over how the control network should evolve as the plant grows.

Frequently asked questions about industrial Ethernet reliability

What causes industrial Ethernet networks to become unreliable?

Most unreliability comes from fundamentals rather than exotic faults: unmanaged switches cascaded until the whole line is one broadcast domain, IP addresses assigned without a plan, and subnet masks that differ between devices. Each works at small scale. As devices are added, traffic grows, faults stop having boundaries, and failures appear intermittent and unrelated to their cause, which makes recovery slow.

Are unmanaged switches bad for industrial networks?

Not in every case. An unmanaged switch is acceptable for a small, isolated machine network that will not grow. It becomes a liability when it carries production traffic between machines or is cascaded with others, because it offers no diagnostics, no segmentation, no loop protection and no multicast control. Rockwell Automation and Cisco’s CPwE design guide recommends managed switches throughout the cell and area zone.

Why can a laptop reach a PLC in one tool but not another?

The usual cause is a subnet mask mismatch. Each device decides whether another address is local using its own mask. If the laptop and the PLC disagree, one side treats the other as local and the other sends traffic to a gateway that may not exist. Broadcast-based discovery tools still list the device, but connections fail, with no alarm to explain why.

How do subnet masks affect PLC communication?

A subnet mask tells a device which addresses it can reach directly and which must go through a router. Devices on the same subnet with matching masks talk directly. A device with a different mask, or an address outside the subnet, cannot reach the others without a correctly configured gateway. Because nothing physical changes, mask errors look like random failures and send troubleshooting toward cables and hardware first.

What is a broadcast storm and how does it stop a line?

A broadcast storm happens when broadcast frames loop endlessly between switches, usually because a cable creates a second path between two switches that have no loop protection. The frames multiply until switches and end devices spend their capacity processing them, and controllers lose their I/O connections. On a flat network built from cascaded unmanaged switches, one storm can stop every machine at once.

Industrial Ethernet reliability is built on fundamentals

Fundamentals determine whether modernization succeeds

Advanced platforms cannot compensate for weak network foundations. This is a reality that is easy to overlook when organizations focus on new tools, analytics platforms, or automation software. Most OT network failures do not originate from sophisticated cyber attacks or advanced software defects. They originate from unmanaged growth, inconsistent IP addressing, and subnet behavior that is poorly understood or undocumented. These issues persist because systems often appear functional until they are placed under pressure. When that pressure arrives, the failures are abrupt, disruptive, and difficult to explain.

As manufacturing systems become more connected, the consequences of these fundamentals grow. Connectivity increases dependency. Dependency reduces tolerance for ambiguity. A network that once supported a single controller and drive must now reliably carry supervisory traffic, diagnostics, and data flows beyond the machine. If the foundation is fragile, every additional connection increases risk rather than value.

Treating networking fundamentals as strategic infrastructure

Organizations that approach OT networking as strategic infrastructure create the conditions for confident modernization. This does not require excessive complexity or overengineering. It requires clarity. Clear addressing standards. Clear ownership of network design decisions. Clear understanding of how unmanaged components behave as systems scale. When these fundamentals are treated with the same discipline as safety systems or critical assets, teams gain confidence in their ability to change, expand, and improve.

Modernization succeeds when systems behave predictably under change. That predictability is not created by advanced technology alone. It is created by disciplined fundamentals that allow advanced technology to perform as intended.

If you are not sure how your own network measures up, our OT network assessment maps the switches, addressing and segmentation as they really are, and our OT networks page explains how we design them.