@Clive_A  

First of all, this thread refers to ER8411 model . I don't know why so many people are asking for different models .

Second of all , I don't think anybody here is asking for LAG to be able to connect to a PC . This is a small business router, its not like you're gonna put it on the desk and run cables to more NICs to the pc to have more bandwith.  For that, the second SFP+ port can be used to get 10G to a pc. 

There are so many (other) cases where LAG is needed.

Final question is: Are you or are you not considering the implementation for LAG feature in the upcoming releases ? 

@Clive_A

I have to say I’m really frustrated by how dismissive this thread has become. Your responses keep steering back to “consider another product” or “no roadmap,” without ever engaging the actual use case or technical reality here. A few points that still haven’t been addressed:

1. You’re conflating LAG with PC-side NIC bonding.
   Nobody is asking to bond ports to a desktop (read through the thread again); we’re asking for router↔switch link aggregation—an entirely Layer 2 function defined by IEEE 802.3ad, not some Layer 4 trick. Suggesting that we “only get speed increases on PCs” shows a fundamental misunderstanding of how LAG works in practice. Spine bandwidth/availability is not the same as PC link speed, its the aggregation of network traffic to prevent colission and bottle necks on the switch level. Has nothing to do with doubling speed for end user devices. This should be your focus use case. Its either that or design a business class router that has 2.5g or 10g switch ports and not just WAN ports.

2. LAG is about more than raw throughput.
   Yes, it can increase capacity, but its primary value in a business network is active load-sharing plus seamless failover at the access/aggregation layer. STP/RSTP simply blocks backup links until a failure, whereas true static or LACP trunks spread traffic across all available links continuously. Lets just ignore the link speed aspect for a moment since you say TP-link doesn't support that.

3. “No roadmap” with zero context isn’t an answer.
   If there’s a genuine blocker, spell it out so integrators like me can plan, talk to your devs about the technical aspects of this and let us know, I'm sure most of us will be able to grasp the technical bits of this. If there isn’t one (such as "They just don't want to becuase they are focused on new products), then please escalate this back to your developers. There is clearly a demand for it here, simply saying its not a priority is not an answer.

Frankly, telling your users to “buy something else” rather than explaining the barrier feels like poor customer service—and it’s driving customers away. We want to stay in the TP-Link ecosystem, but we need transparency. Please give us a real technical explanation or a clear commitment to revisit this feature, rather than stonewalling us again.

I will be filing a complaint with TP-link corporate over your attitude in responses and your incompetence. If you can't regulate your emotions, find a different job.

  @NickTracy 

I am really glad you chose to push back and cut through the BS that keeps going on here. I am also very frustrated becasuse of the fact that there is nothing in the product feature or info anywhere for these product that are classified as "business classs" that shows before we bought these product of lack of BASIC features. like the the lack of LAG on gateways to link to core switches discussed here, or lack of ip-port ACL rules on the gateway or etc. etc..

Tplink just decided that they focus on new products to scam more potential customers into the eco-system the same way we were scammed into it. I am sure many of us were neck deep into this eco-system before they realized that they just can not return or swap to a new product. But it is easy to say for for people like the mods on this forum to say go buy a new product. Its like how excatly a thief would treat you after getting your money.

All BASIC ESSENTIAL feature requests that has been brushed off and waiting for AGES not being implemented should have a clear reason why they have not been implemented yet. SPECIALLY if alot of people requesting it.

  @Alex_UTS Do any routers support LAG like ER707-M2?

+1 for this feature request. Particularly with a business-class device line as this claims to be, LAG and LACP should be a minimum standard to be included for redundancy and load balancing, as the environments these devices are intended for use within absolutely require this functionality. I've had great luck with Omada switches and was close to ordering several of the ER707-M2 gateways for our branch locations and wound up pivoting to a different manufacturer's solution when I found that LAGs would not be possible. The fact that the feature was included with the switches but omitted from the next logical hop with the gateways just confounds me. This is not a new concept by any means. Listen to your customers TP-link if you want us to take your products seriously and to continue purchasing them - please add this functionality!

ibskyde wrote

if you want us to take your products seriously and to continue purchasing them

Honestly... I used to love TP-Link, but between bugs and simply not listening to customers, I've moved to Ubiquiti. Hate to say it, but it's much better now.