What is router link aggregation for? Bundling two gigabit ports together, single-threaded still at 110MB/s

cousin came to my house last weekend to copy a 4K original drive. He squatted by the weak current box and saw two network cables plugged into the back of my Feiniu NAS. He turned to me and asked, "Bro, if you tie these two gigabit ports together, can you run 2G?"

I didn't reply directly; I pushed the keyboard over and let him copy it himself. A 58GB Blu-ray original disc, dragged it in, and the Task Manager checked the speed: a solid 110MB/s, just like their single-cable cable. He stared at me for a long time and said, "So aren't these two wires for nothing?"

really isn't a free insert, but the trick behind it deserves a separate article explaining. Two years ago, when I was researching dual broadband, link aggregation was the first solution I crossed out. Today, I'm picking it up and discussing it in detail.

aggregation bundles 'logical channels,' and traffic distribution is calculated by 'connections,' not by lines

so first clarify the concept. Link aggregation (standard 802.3ad, now classified as 802.1ax, negotiated via the LACP protocol) does by bundling two or even more physical network cables into one "logical cable." Externally, it looks like a network port and an IP, but DHCP only sends it an address , but beneath it lie two paths.

key lies in how traffic is split into two paths. Imagine a supermarket turning two manual checkout counters into a "joint aisle": the signs are put up, but each customer can only walk through one line from the moment they queue until checkout. If you push ten carts of goods by yourself, sorry, it's still a team that builds up slowly; Only when two people buy at the same time can each take up a team, doubling the overall turnover.

the same principle on the internet side. When a device receives a five-tuple of a connection—source IP, destination IP, source port, destination port, protocol number—hash it and calculates which line it lands on, and that connection follows from start to finish. Why be so rigid? Because if packets are sent in turn (one from this file, one from that file), packets from the same file will arrive out of order. TCP treats the disordered packet as a packet loss, retransmitting and slowing down the process, which actually makes it slower. Therefore, mainstream device aggregation is distributed by "stream," not by "package."

following this logic, a byproduct can be developed: the download tool enables multithreading, which means multiple connections are opened simultaneously. If the hash spreads out, it can fill both lines. Keep this in mind; you'll need it for future testing.

single-threaded copy test: two wires and one wire look the same

my cousin's house is a ready-made testing ground. For that second-hand four-port Synology switch, he specifically bought a second-hand managed gigabit switch—two NAS ports, two switch ports, and both sides had set up aggregation groups, using 802.3ad protocols. The machine is assembled; all that's left is to run the numbers.

the first round, Explorer directly dragged a 58GB original disk from the computer to the NAS: 110MB/s, not a single move occurred. I took a photo of my cousin's expression at that moment. The second rotation is my usual copy tool, still 110 swinging up and down. In the third round, I ran Xunlei on the same resource and maxed out multi-threading—this time, both ports were active. On the switch management page, real-time traffic was shown: each port ran 700-800MB, totaling around 1.6Gbps. Single connection for the tumbling and multiple connections for takeoff perfectly follow the principle of the previous section.

By the way, here's a way to read data: the aggregation group is just a network card in the system, and the task manager can't see how much traffic each line carries. To see the actual load on each line, you have to go into the managed switch's backend to check the real-time speed of each port. That's why people who use aggregation basically have a managed switch.

the real advantage is the traffic "squeezed at the same time"

who exactly uses that aggregation? It's used for scenarios where 'there are many connections at the same time.'

cousin's NAS is like this: qBittorrent keep a protected year-round, with dozens of megabytes of uplink and download all year round; Evening album automatically backs up and writes up; His wife streamed the video library on the living room TV. Back when I used to have a single port, whenever I copied a large file, the port would be filled with copying, the downloaded peer wouldn't connect, the TV would start spinning, and the three tasks at home would be queued up through one door. After aggregation, copying is a single connection running a single line; downloads, streaming, and backup are independent connections, and hashes are likely scattered to another line—not the precise isolation of QoS, where aggregation has no prioritization concept, purely "two doors when there are more people," but for their three-way concurrent scenario, it's sufficient. During the copying session, the TV stopped freezing—this was his own exact words. Another benefit

easily overlooked is redundancy. Even if you don't need double throughput, if one of the two cables is loose or one NAS port has poor contact, the network is uninterrupted and the business still runs. Synology and Linux also have dedicated active-backup modes, where only one is used and the other is purely standby. The goal is to ensure stability.

the time I failed to build my own and got stuck on that foolproof switch in the middle

I'll share my experience of failure, and give a warning to those who want to copy homework. I bought a dual-port gigabit network card for just over 200 yuan, plugged into an N100 main unit to use as a NAS, and was very ambitious to build an 802.3ad. But when the aggregation group was set up, the network was inconsistent, half the ping was lost, and after checking for nearly half the night, the root problem was that eight-port gigabit foolproof switch in my weak current box unmanaged switches don't even understand the LACP protocol. The negotiation messages sent by NAS went blank, and the two sides couldn't communicate, so this was the only outcome. At the time, I was puzzled—both the network card and NAS clearly showed support for aggregation, so why didn't they work? Later, after checking the switch's manual, I realized: it doesn't have a 'management' function, and the four letters LACC don't appear in its dictionary.

So, when it comes to assembling a group, you have to go through three gates, not a single one less:

The NAS side has its own choices. To put it plainly: Synology's "802.3ad" and "Balance TCP" both require switches to enable LACP; "Balance SLB" does not require a switch and distributes sessions automatically, making it the most convenient level. The bond mode under Linux is similar: Mode 4 is a legitimate LACC for switches, while Mode 1 is for master-backup and modes 5/6, which are all switch-friendly. In the end, I chose active-standby mode—since I'm the only heavy user at home, single-threaded threading is 110 Mbps, so redundancy is needed, not fake speedup.

say one more word on the other end of the router. My AX3000T specs page says it supports dual LAN aggregation , but very few home routers have this feature, and aggregation is a matter at both ends. If the router is assembled but the NAS is not, or there's a foolproof switch in between, it's still a waste. In fact, most people focus on the "NAS to switch" phase, so the router can safely serve as its gateway.

aggregation or 2.5G? Taking the issue first

paying again, the conclusion is clear: aggregation provides "concurrent splitting plus redundancy," not "doubling per file." If you want to copy a file quickly, the proper way is to swap the link for 2.5G. I've calculated before: a 2.5G port switch plus network card costs over 200 yuan, single-thread is directly 290MB/s, cheaper than fuzzing aggregation, and you don't need to configure both ends.

Here's the order for wrapping up: first ask yourself whether you want speed or stability—if you want to be fast, go straight for 2.5G and don't waste time on aggregation; if you want concurrent splitting, first check if the middle switch is managed; if not, switch to it first and then build a group at both ends; don't bother with that, plug in two wires in master-standby mode, disconnect one, and then consider both cables worthwhile.

cousin asked me before leaving that day, asking if all his efforts had been for nothing. I said no, your three-lane concurrent is a real need, and the aggregation wasn't a wasted group—I was the one who wasted effort. Two cables were plugged in for two years, and the main backup was always running.