Posted: Sat Jun 06, 2020 1:43 Post subject: R8500 WAN Aggregation
So I'm struggling to get the 802.3ad LACP to properly detect on ports 3 & 4 when set to trunking mode. I can get internet using either of the ports 3 or 4, when plugged into the modem. I have attempted to enable port aggregation on my multi-gig modem and the trunking on the router in DD-WRT. However, the modem aggregation remains in an inactive state. The documentation says that if LACP support is not detected it will remain inactive. Is the trunking support for ports 3 & 4 still adhering to 802.3ad specifications?
Netgear documentation states to use Ethernet port 1 and port 2 on the router (they are marked aggregation on the back of the router) but as i gather, these were switched to ports 3 4 in the dd-wrt firmware?
Insights greatly appreciated, Anyone succeeded in getting a multi-gig router to actually enable WAN aggregation to an R8500 or similar router?
Link aggregation entirely in software would require some serious CPU hardware, and a dual ARM @ 1.4GHz is simply not enough. Think about it--it can't even do QoS at 1 Gbps WAN-to-LAN combined, and you are talking 2 Gbps full-duplex
Even with the stock firmware which presumably has hardware-assist in the driver to offload some of the work to the switch chip, performance isn't great.
That's actually better than most consumer-grade routers, NASes and "smart" switches that advertise LACP as a feature on the box but perform worse than a single gigabit port when it's used. It can still be useful if you are looking for failover capability rather than performance.
The only documentation on bonding in DD-WRT I see uses a failover example, and this question comes up occasionally but I've yet to see success.
Posted: Mon Jun 08, 2020 13:54 Post subject: R8500 WAN Aggregation
While I don't entirely agree with your assessment, I can understand that the processor might be taxed by the additional throughput. Any idea what logic lead to the switch from the native aggregation ports to ports 3 & 4? I can't really wrap my head around this one.
While I haven't actually tried the stock firmware in this case, I could try and roll back to test functionality and performance. QoS is much more demanding by nature as it qualifies the packets rather than just sending them through at twice the rate.