Networking industrial switches is not finished once the cables are connected. Star, chain, and ring topologies determine which physical paths exist between devices, while switch functions and protocols determine which path the data actually takes. When choosing a solution, you should consider business traffic, the scope of fault impact, power supply locations, and maintenance conditions at the same time. In particular, you must not directly treat “connecting everything into a loop” as “the network has reliable redundancy capability.”
First, separate physical wiring from data forwarding
Physical topology is the connection shape of devices and lines. Logical forwarding path is the route that data actually passes through. Each port of a switch can receive Ethernet frames, which are a type of data unit transmitted over a network. Common Layer 2 switches decide where to forward based on MAC addresses. A MAC can be understood as an address that identifies an interface within a link, and it is not equal to the IP address used for internet access.
A switch learns “which address is in this port direction” from the source MAC address of received frames, and when sending, it looks up the port corresponding to the destination MAC. It does not learn the source device location through the destination address. When the destination location is unknown, or when frames such as broadcasts that need to be spread are received, the device may forward to multiple ports within the applicable range. This is also an important reason why closed loops must be controlled.
Star: branches are intuitive, but the center is critical
A star network connects multiple field devices or access switches separately to one aggregation location, shaped like spokes. If one branch breaks, it usually mainly affects the devices behind that branch, while other branches still have a path to the center, so cabling and fault locating are relatively intuitive.
However, if the central device, power supply, or uplink has a problem, the impact may cover multiple branches. Suppose four production units each upload data to the same server. The fact that each branch can operate independently does not prove that the shared uplink capacity is sufficient. You should check the peak traffic of each branch and the aggregation-side outlet, and when necessary partition different services or increase uplink capability. You cannot estimate only by average traffic.
Star also does not mean every terminal must have a cable pulled directly to the control room. Access devices can be placed in nearby areas and then uplinked through optical fiber. This reduces long-distance copper cables, but adds field switches and power points, and the maintenance list should include these newly added nodes.
Chain: follows the site, and also strings risks together
In long corridors, production lines, or stations along a route, connecting switches one by one into a chain can reduce some repeated cabling. Data from later stations passes through earlier switches to reach the aggregation point. The line path matches the site distribution and is relatively easy to understand during construction.
The cost is that a fault in a middle line segment or middle device may cause stations further back to lose their path to the aggregation point. Each device not only serves local terminals but also forwards data for subsequent stations, so links closer to the outlet carry aggregated traffic. You cannot evaluate this uplink segment using the rate of a single terminal, and you should not treat the fact that all devices have two optical ports as a guarantee of unlimited chaining.
Latency, buffering, and fault propagation should all be tested at the actual scale. There is no universal number for allowed chain length that applies to all models, services, and protocols. During design, first clarify whether backend devices going offline will affect production, then consider segmentation, backup paths, or changing critical nodes into independent branches.
Ring: backup physical paths require protocol management
Ring connections provide the possibility of bypassing a certain line segment, but in an ordinary Layer 2 network, if all ports continue forwarding, broadcast or unknown-destination frames may circulate repeatedly and form a large amount of duplicate traffic. Ethernet frames do not carry a hop-by-hop decreasing lifetime field like some network-layer packets, so you cannot expect forwarding to stop automatically after several times.
The basic idea of spanning-tree-type protocols is to establish an active forwarding path without loops from a physical connection that has loops. Under normal conditions, data forwarding on certain backup ports is restricted; after an applicable fault occurs, the available path is recalculated and enabled. Private industrial ring protocols may use different control mechanisms, and the specific roles, fault detection, and switching conditions need to be confirmed according to the model and protocol documentation.
Therefore, after a fault, the key is not “blocking the backup line again,” but coordinating so that the available backup path carries the communication that needs to be restored, while avoiding leaving a new forwarding loop. Recovery time is also not a uniform value for all industrial switches. Terminals re-establishing sessions, application timeouts, and service retries may be slower than the link switchover itself. Acceptance testing should test service recovery, not just look at indicator lights.
Managed does not necessarily mean all redundancy functions are present
Unmanaged devices usually provide basic switching functions, while managed devices may add configuration, monitoring, and control capabilities. But WEB management, VLAN, multicast control, spanning tree, and private ring networking are different functions. You cannot assume all are supported just because of the words “managed type.” Layer 2 switching and Layer 3 routing must also be separated. Whether cross-subnet access is handled by the device itself depends on Layer 3 capability and design.
Feichang Technology provides industrial switch categories such as DIN-rail and rack-mounted types. When selecting a model, first narrow the range by port count, the ratio of copper ports to optical ports, and installation location, then confirm the protocols supported by the target model. If the project plans to use a ring network, you need to check protocol compatibility, role settings, and firmware of the participating devices. You should not directly combine private functions with similar names from different vendors.
The management entrance itself also needs protection. Being able to configure a device in a browser does not mean the management page should be exposed to the public internet; you should set appropriate permissions, restrict access sources, and keep configuration and version records. Basic security measures are not decorative accessories of the network topology, but conditions for the long-term maintainability of the network.
How to choose for a production line is easier to explain clearly
If devices are concentrated in a few areas, star or hierarchical star usually makes it easier to divide the fault scope. If the distance along the route is long and stations are scattered, chain can reduce some cabling complexity, but you must accept the fact that an interruption may affect subsequent stations. If the business requires communication to continue after a single-segment fault, you can evaluate a ring or other backup structure that supports an applicable redundancy protocol.
This is not a ranking of “star is outdated, ring is advanced.” Whether there are two lines on site that can be laid independently, whether nodes have stable power, and whether maintenance personnel can understand the protocol may all be more important than the topology name. Two cables placed in the same easily damaged cable tray cannot be equivalent to completely independent fault paths.
During acceptance, test traffic and faults separately
Under normal conditions, use the planned business load to observe outlet utilization, error and discard counts, and confirm that terminals continue to work. Then, according to the approved test plan, simulate specified link or node faults, and record which terminals are affected, how the backup path changes, and how long the service takes to recover. Different directions and different fault locations should be checked separately. You cannot test only the one most likely to succeed.
Acceptance records include topology diagrams, device models, firmware, port purposes, protocol settings, and test conditions. Maintenance personnel should be able to use them to judge “if this breaks, who will be affected,” rather than guessing on site. A good networking solution not only lets data get through, but also makes fault impact explainable and the recovery process verifiable.
Verification materials:Cisco spanning tree principles;Feichang Technology industrial switch categories. The principle diagrams are used to explain general mechanisms and are not measured diagrams or wiring diagrams for specific models.
Translated from the Chinese technical article. Source first published: 2019-08-16. Source last revised: 2026-10-13T20:54:09+08:00. Read the Chinese source
