UniFi Switch Uplinks and Link Aggregation: When SFP+, LACP, and 2.5GbE Actually Help

You probably think of link aggregation as a way to add two 1GbE ports together and get one 2Gbps pipe. However, an 802.3ad bond behaves more like a two-lane road with an officer at the on-ramp who assigns every car a lane and never lets it change.

Two lanes move more cars per hour. One car still travels at one lane's speed.

That is why so many UniFi racks end up with four bonded ports and the same file-copy number they had before. The bond was working correctly — it was answering a question about aggregate capacity while the operator was asking a question about single-flow throughput.

Three different tools get confused for each other here: LACP aggregation, a 10G SFP+ uplink, and 2.5GbE at the access edge. Each one fixes a different kind of congestion, and choosing the wrong one costs you ports, transceivers, and a trip to the closet.

A link aggregation group presents two to eight physical ports to the rest of the network as a single logical interface. What it cannot do is send consecutive frames of the same conversation down different members.

The reason is reordering. If frames from one TCP stream arrive out of sequence, the receiver reads the gaps as loss, and the resulting duplicate ACKs and retransmissions leave you slower than one clean link would have been.

So the switch does not round-robin packets. Instead it runs a hash over selected header fields of each frame — source and destination MAC at minimum, usually source and destination IP, and on some silicon the Layer 4 port numbers — and uses the result to select one member.

That hash is deterministic and stateless. The same pair of endpoints lands on the same member every time, for the life of the conversation.

Three consequences follow, and all three are load-bearing when you plan capacity:

• Aggregate throughput scales. The bond genuinely carries close to the sum of its members when the traffic is made of many independent conversations.
• Single-flow throughput does not. One SMB copy, one iSCSI session, one backup job to one target — each is a single flow, capped at one member's line rate no matter how many ports you add.
• Balance is lumpy. Distribution happens per flow rather than per byte, so a small number of heavy talkers can pile onto the same member while another sits idle.

Two nightly backup jobs hashing onto the same link is not a fault. That is the design working exactly as specified.

Keep in mind that member count interacts badly with a small talker count. With two members, one heavy flow occupies half your bond; with four, it occupies a quarter, but you have now spent four ports and four cables to get there.

UniFi Network also does not expose hash-policy tuning across its switch lineup the way an enterprise CLI would. You inherit the chipset default, which means you design around the distribution rather than tuning it after the fact.

Multi-stream tools complicate the picture in your favor. SMB Multichannel, parallel rsync, and iperf3 with -P all open several TCP connections with different source ports, and those can spread across members when the hash includes Layer 4 fields — verify that on your own hardware before you plan around it.

The rule worth carrying is simple. Aggregation buys capacity, and raising the ceiling for one conversation is a separate purchase.

None of that makes LACP a bad tool. It makes it a tool for one specific shape of traffic — many concurrent conversations crossing the same link at the same time.

The deployments that pay off are the ones with genuine flow diversity:

• Switch-to-switch trunks. An access switch feeding a floor of clients and a handful of access points produces hundreds of concurrent flows, which is precisely the condition the hash needs to spread traffic evenly.
• NVR and NAS hosts. Twenty cameras writing to one recorder are twenty separate conversations with twenty different source addresses, so they distribute well across members.
• Hypervisor hosts. Each virtual machine carries its own MAC and IP pair, so a bonded host NIC spreads VM traffic in a way a single VM never could on its own.

The candidates that never pay off are the single-purpose ones. A workstation that wants one fast copy, a two-host replication path, and a single-session iSCSI target all stay pinned to one member regardless of port count.

Resilience is often the better reason to build a bond in the first place. When a member fails, LACP removes it in well under a second and the logical link stays up with reduced capacity — no spanning tree reconvergence, no topology change, and nothing a user notices.

Be aware that this redundancy stops at the chassis. UniFi switches do not support multi-chassis aggregation, so every member port must live on the same physical switch, and that switch remains a single point of failure.

If you need to survive a switch failure rather than a cable failure, run two separate links into two switches and let RSTP block one until it is needed. You trade the capacity gain for a topology that survives the more likely event.

On the UniFi side, the mechanics are short but order-sensitive. Configure the aggregate port profile on both ends before you patch the second cable, because two live cables between two unconfigured switches is a loop and you are relying on RSTP to catch it.

Prefer LACP over a static bond. LACP negotiates with the far end and removes a member that stops answering at the protocol level, while a static bond will keep forwarding into a link that is electrically up and functionally dead.

Plan your patching around consecutive ports, since UniFi builds an aggregate from a starting port and the ports that follow it on most models. Tagging then applies to the logical interface rather than to each member, which is worth confirming against your UniFi VLAN design before you cut over.

One more boundary deserves stating plainly. A LAG on the access switch does nothing for traffic that hairpins to the gateway for inter-VLAN routing, and nothing at all for internet throughput, which is bounded by the WAN circuit and the gateway's forwarding capacity.

If north-south performance is the actual complaint, the fix lives in gateway selection and in your WAN failover design. No amount of bonding downstream changes it.

A 10G SFP+ uplink does the one thing a bond cannot. A single conversation gets ten gigabits instead of one, with no hash to reason about and no balance to hope for.

It also collapses your port count and your fault domain. Four bonded 1G ports become one port, one cable, and one thing to troubleshoot at two in the morning.

The clearest way to size it is the oversubscription ratio — total access-port capacity divided by uplink capacity. A 24-port gigabit switch with two 10G SFP+ uplinks puts 24G of access against 20G of uplink, close enough to non-blocking that the uplink will never be the thing you are chasing.

Move to 2.5GbE access ports on a 48-port switch and those same two uplinks now face 120G of access capacity, a 6:1 ratio. That remains comfortable for an office floor and gets genuinely tight on a floor running sustained transfers.

Most current UniFi Pro and Enterprise switches ship with a pair of SFP+ ports for exactly this role, and the Aggregation models exist to be the fiber core those uplinks terminate into. Choosing the uplink before the switch is the correct order of operations, which is the argument made in detail in how to choose a UniFi switch.

The media choice matters more than most people expect, mostly for power and heat:

• DAC inside the rack. Direct attach copper is the cheapest and lowest-power option for switch-to-switch runs of a few meters, with no optics to fail and nothing to clean.
• Multimode fiber between rooms. A pair of SFP+ transceivers over OM3 or OM4 covers building-scale distances and keeps the two closets electrically isolated from each other.
• 10GBASE-T modules as a last resort. They let you reach an RJ45 10G device from an SFP+ cage, but they draw noticeably more power and run hot enough that some switches restrict how many can sit in adjacent cages.

Also worth knowing: an SFP+ cage accepts 1G SFP optics. A closet that only needs a gigabit of fiber today can terminate into the same port you will upgrade later, which makes the uplink decision cheaper to defer than the switch decision.

The gateway is the other place a fast uplink stops being free. If your Dream Machine terminates its LAN on a single 10G SFP+ port, everything routed between VLANs shares that port regardless of how fast the switch fabric behind it runs.

Both of the previous tools live upstream of the client. Neither raises the ceiling for a device plugged into a gigabit access port, because that port is the constraint.

That is the specific gap 2.5GbE fills. It is the only one of the three that changes what a single ordinary endpoint can achieve.

The most common trigger is wireless. A Wi-Fi 6E or Wi-Fi 7 access point can move more than a gigabit of aggregate client traffic under good conditions, and feeding it from a 1GbE switch port makes the cable the bottleneck instead of the air.

Start with Wi-Fi 7 and MLO for what that airtime capacity realistically looks like, then check how to choose a UniFi access point for which models expose a multi-gig port at all. An AP with a gigabit-only uplink port gains nothing from a multi-gig switch.

The same logic applies to wired endpoints that actually move data — a floor NAS, an editing workstation, a build machine. Those are single-flow devices by nature, which is exactly the case aggregation cannot help.

Cabling is usually not the obstacle. 2.5GBASE-T was designed to run over installed Cat5e at normal horizontal-run lengths, so the upgrade is typically a switch swap rather than a re-pull.

Marginal terminations, mid-span splices, and heavy interference will still negotiate down to gigabit, and the port will tell you so. Check the negotiated link speed in UniFi Network before you blame the access point.

Keep the power budget inside the same calculation. Multi-gig PoE switches carry real but finite budgets, and a mix of PoE++ access points and cameras consumes them faster than the port count suggests — run the arithmetic in PoE budget planning before you commit to a model.

The shape that ages best right now is 2.5GbE at the access edge with 10G SFP+ uplinks behind it. Clients get real multi-gig, the uplink stays comfortably ahead of them, and nobody ever has to reason about a hash policy.

Sizing is arithmetic rather than intuition, and every input is already available to you. The trick is measuring sustained load instead of imagining peak load.

Start with the cameras, because they are the one workload with a knowable steady rate. UniFi Protect exposes the target bitrate for each camera at its configured resolution and quality setting, so add those up rather than estimating from resolution alone.

That sum is your write load onto the recorder, and it runs continuously rather than in bursts. It is also smaller than most people expect, because recording is rarely what saturates an uplink.

Reading is what saturates it. Every live wall display, every playback scrub, and every export pulls a separate stream back out of the recorder, and remote viewing adds a trip through the gateway on top of that.

Size for the worst realistic concurrency, not the daily average. Twelve simultaneous playback sessions during an incident review is the number that matters, and both Protect storage sizing and your camera placement plan feed directly into it.

Before buying anything, look at the topology. Putting the cameras and the recorder on the same switch keeps every camera write off the uplink entirely, which is the highest-leverage change available and costs nothing beyond patch panel labor.

For general client traffic, resist multiplying port count by port speed. Forty-eight gigabit ports do not generate 48Gbps of demand, and sizing to that number buys hardware nobody will ever load.

Measure instead. UniFi Network retains per-port and per-client traffic history, and the 95th percentile across a full business week is a far better planning input than the peak, which is almost always one backup window.

Two signals should move you from monitoring to buying:

• Sustained utilization. An uplink averaging above roughly half its capacity during business hours has no headroom left for the day something unusual happens.
• Discards on the uplink port. Utilization graphs average microbursts away and the discard counter does not, so a climbing discard count is the honest evidence that the link is undersized.

As a starting frame, 4:1 to 8:1 oversubscription is comfortable for office and Wi-Fi traffic that is mostly small and bursty. Tighten toward 2:1 when the switch feeds recorders, hypervisors, or workstations running sustained multi-gig transfers.

Then let the sizing pick the hardware rather than the other way around. If the numbers point at multi-gig access with 10G uplinks, the current UniFi switch lineup is where to start, and how to choose a UniFi switch walks the model-by-model tradeoffs against exactly these constraints.