When a single cable between two industrial switches is not enough, either because it cannot carry the traffic or because you cannot afford to lose it, you can run several cables and make them behave as one. That technique is link aggregation, and the bundle it creates is called a LAG. It gives a switch-to-switch connection both more bandwidth and a form of redundancy at the same time, using ordinary ports and cables. This page explains what link aggregation is, how LACP negotiates and manages the bundle, how it differs from ring redundancy, and when a busy SCADA backbone actually needs it.
Link aggregation in one line: Link aggregation is the bundling of two or more physical Ethernet links between the same pair of switches into a single logical link, called a LAG or port channel, so that they share traffic and act as one connection. It raises the total bandwidth available between the switches and provides redundancy, because if one member link in the bundle fails the others keep carrying traffic with only a proportional loss of capacity. It is usually negotiated automatically with LACP, and it applies specifically to a point-to-point connection between two switches, which is what distinguishes it from a ring that spans many switches.
Link aggregation takes several physical links running between the same two switches and combines them so that the switches, and everything above them, treat the bundle as a single logical link. The individual cables still exist and still each carry frames, but the switch spreads traffic across all the members and presents them upward as one connection with the combined bandwidth. Two one-gigabit links aggregated together, for example, form a single logical link that can carry substantially more traffic than either cable alone, without needing a faster and more expensive single port on each switch.
The switch decides which member link carries a given flow using a hashing scheme, typically based on source and destination addresses, so that all the frames of a single conversation take the same member link and arrive in order, while different conversations are spread across the members. This is why aggregation is best thought of as adding capacity for many flows rather than making one flow faster: a single large transfer still rides one member link, but the sum of all the traffic between the switches can use the full bundle. For a backbone carrying many devices' worth of traffic, that distribution across members is exactly the behaviour you want.
Because the bundle is one logical link, it also solves a loop problem cleanly. If you simply cabled two switches together with several parallel cables without aggregation, you would create loops that spanning tree would have to block, leaving all but one cable idle. Aggregation instead tells the switches that these parallel cables are deliberately one link, so spanning tree treats the whole bundle as a single connection and all the members carry traffic at once. That is how link aggregation delivers both extra bandwidth and standby-free redundancy from the same set of cables, rather than the block-one-path behaviour of ordinary redundant links.
Aggregation can be configured statically, where you simply tell each switch that a set of ports form a bundle, but the more robust approach uses LACP, the Link Aggregation Control Protocol, in which the two switches exchange messages to negotiate and continuously verify the bundle. With LACP, each switch confirms that the ports on the far end really do belong to the same partner and are willing to aggregate, and only then does it activate them as a group. This handshake catches miscabling, because if a member is patched to the wrong switch or a link is not actually a valid partner, LACP will not fold it into the bundle, which prevents the mistakes that a purely static configuration can silently create.
The ongoing value of LACP is in how it handles member failures and recoveries. It monitors each member with its periodic messages, so when a member link goes down, LACP removes it from the bundle and the remaining members keep carrying the traffic, with the connection surviving at reduced capacity rather than dropping entirely. When the failed link is repaired and comes back, LACP re-admits it and the full bandwidth returns. All of this happens without disturbing the logical link that the rest of the network sees, so devices above the LAG never know a member came or went; they simply experience a connection that stayed up.
For this to work, both ends must agree, which is a practical constraint worth remembering: aggregation is a two-switch agreement, so both switches have to support it and both have to be configured for the same bundle, and the members must generally be like links running at the same speed. This is a managed-switch feature; unmanaged switches cannot run LACP or form a proper LAG, which is another reason a backbone that needs aggregated uplinks is built on managed industrial switches. Because the LAG and its members are visible to the switch's diagnostics, the health of the bundle, how many members are up and how loaded they are, can be reported to a monitoring platform, so staff can see when a bundle has quietly dropped to running on a single member.
It is easy to confuse link aggregation with ring redundancy because both provide resilience, but they solve different problems at different scopes. A LAG protects and fattens a single connection between two specific switches; it is a point-to-point mechanism, and it does nothing for the path between switches that are not directly bundled. A ring, by contrast, cables many switches into a loop so that the whole network survives any single link or switch failure by rerouting around it; it is a network-wide topology, and its purpose is resilience across the whole backbone rather than the capacity of one link. The two are complementary, not alternatives: a network can use a ring to survive the loss of any switch and use LAGs on the individual high-traffic links within or feeding that ring to give those links more bandwidth and member-level redundancy.
The distinction in what they protect against also matters. Ring redundancy protects against a switch or a link failure anywhere in the loop but generally does not add bandwidth, since the ring runs on single links with one path blocked in reserve. Link aggregation adds bandwidth on the link it covers and tolerates the loss of individual member cables, but it does not protect against the loss of either switch it connects, because a LAG has a switch at each end and losing one of those switches takes the whole bundle down. So a designer reaches for a ring when the concern is any-switch survival across the backbone and reaches for a LAG when the concern is a specific link that is either too busy for one cable or too important to run on one cable.
A SCADA backbone needs link aggregation when a particular connection becomes a bottleneck or a chokepoint. On a plant network, the uplink from an aggregation switch back to the core often carries the summed traffic of everything beneath it, and as historians pull large volumes of data, video streams are added, or many controllers report at once, that single uplink can be the busiest link in the building; aggregating it gives it headroom without a forklift upgrade to faster ports. The redundancy benefit is often the stronger motivation on control networks, because a single uplink cable is a single point of failure for everything behind it, and folding a second cable into a LAG means a damaged patch lead or a failed transceiver on that path no longer isolates a whole section of the plant. Smaller, quiet control networks with light uplink traffic and adequate ring protection frequently do not need aggregation at all, so like most backbone features it is driven by the specific load and criticality of the link in question rather than applied everywhere by default.
No, and this is the most common misunderstanding. A LAG spreads different conversations across its member links, but the switch keeps all the frames of any one flow on a single member so they stay in order, so a single large transfer still rides one member link at that link's speed. What aggregation increases is the total capacity available to the many flows crossing the link at once, which is exactly what a busy backbone carrying traffic from many devices needs. If you need one flow to be faster, you need a genuinely faster single link, not aggregation.
Yes. Forming a LAG, and especially running LACP to negotiate and monitor it, is a managed-switch capability, so both switches at the ends of the bundle must be managed and configured for the same aggregation. Unmanaged switches cannot participate, and simply running parallel cables between unmanaged switches creates loops rather than a bundle. This is one more case where a backbone requirement, here aggregated uplinks, forces the use of managed industrial switches, which also gives you diagnostics on the bundle's health.
No, they cover different failures. A LAG protects one connection between two specific switches and tolerates the loss of individual member cables, but if either switch at the ends of the bundle fails, the whole LAG goes down. A ring protects the whole backbone against the loss of any single switch or link by rerouting around it. Good designs often use both together, a ring for network-wide survival and LAGs on the busy or critical individual links within it, so they are complementary tools rather than substitutes for each other.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.