Tại ArcBox Labs, văn phòng của chúng tôi sử dụng kết nối PPPoE tốc độ 5 Gbps phía sau cổng gateway UniFi, nhưng chúng tôi chưa bao giờ đạt được tốc độ gần với mức đó. Mẫu UDM Pro Max thậm chí đang bắt đầu quá tải và làm ảnh hưởng đến sự ổn định của hệ thống:
Điều này tương tự như hiện tượng mà nhiều người dùng UniFi khác gặp phải:
- https://community.ui.com/questions/a6f24f8c-6b83-4617-ad33-b5af0b32d8dc?replyId=2808b654-e4be-4ac2-b199-09c1b1a0fbac
- https://community.ui.com/questions/What-is-the-max-performance-for-PPPOE-on-UDM-Pro-With-Solution/67057f47-509e-4f8b-8edd-5dc29f380759
- https://www.reddit.com/r/Ubiquiti/comments/1dto912/story_time_investigating_slow_pppoe_speeds_on/
- https://forum.level1techs.com/t/unifi-and-bad-pppoe-speeds-any-solutions/224548
- https://community.ui.com/questions/ETA-on-bugfix-for-UDM-Pro-bad-PPPoE-performance/9119aa98-412f-41c7-9188-a30036c2e4c2
- https://www.reddit.com/r/Ubiquiti/comments/1buqkx1/max_speed_pppoe_on_udm_pro_with_10gbit_wan/
- https://www.reddit.com/r/Ubiquiti/comments/1hctxjk/efg_with_pppoe_uk_testing/
Đại đa số các gateway UniFi, từ UDM Pro/SE/Pro Max, UXG Pro cho đến EFG, đều sử dụng CPU không hỗ trợ tăng tốc phần cứng cho cả PPPoE lẫn NAT. Do đó, bất cứ khi nào bạn sử dụng kết nối mạng PPPoE đằng sau các thiết bị này, băng thông đều bị giảm nghiêm trọng và không bao giờ đạt tới tốc độ cam kết của nhà mạng. Điều này đã được ghi nhận rất nhiều trong cộng đồng UniFi.
Tóm lại, hiệu năng PPPoE trên các gateway UniFi khá thất vọng:
- UDM Pro/SE: Tốc độ đo được qua PPPoE thường chỉ đạt từ 1200 Mbps đến 1500 Mbps.
- UDM Pro Max: Thường đạt từ 1400 Mbps đến 1800 Mbps.
- EFG: Thường đạt từ 1400 Mbps đến 2400 Mbps.
- UCG Fiber: Nhờ trang bị SoC MediaTek Filogic 880 có hỗ trợ tăng tốc phần cứng PPPoE, tốc độ có thể vượt quá 5000 Mbps qua PPPoE.
PPPoE
PPPoE (Point-to-Point Protocol over Ethernet) là giao thức mạng đóng gói các khung PPP bên trong khung Ethernet; các nhà mạng (ISP) sử dụng giao thức này để xác thực và tính cước người dùng băng thông rộng. Mặc dù PPPoE thêm 6 byte header PPPoE và 2 byte header giao thức PPP giữa khung Ethernet và gói tin IP, nhưng 8 byte chi phí phát sinh đó là không đáng kể. Lý do thực sự khiến PPPoE làm suy giảm hiệu năng nằm ở chính bản chất của giao thức này.
Với kết nối PPPoE, router phải thêm header PPPoE vào mọi gói tin gửi đi và gỡ bỏ header PPPoE khỏi mọi gói tin nhận về. Với lưu lượng gói tin lớn, việc này đòi hỏi sức mạnh CPU rất cao hoặc phải có mạch tăng tốc phần cứng chuyên dụng (ASIC).
Đối với các router không có tăng tốc phần cứng PPPoE, mọi thứ còn tồi tệ hơn: hầu như tất cả các triển khai PPPoE hiện nay đều là đơn luồng (single-threaded). Ngay cả với CPU đa nhân, quá trình đóng/giải đóng gói PPPoE thường chỉ chạy trên một nhân duy nhất. Mặc dù tính năng if_pppoe của pfSense triển khai RSS độc lập với NIC và module pppoe của Linux kernel hỗ trợ RPS/XPS, nhưng những giải pháp này chỉ phát huy hiệu quả khi có nhiều phiên (session) PPPoE. Đối với một phiên PPPoE đơn lẻ (trường hợp phổ biến nhất của một đường truyền băng thông rộng), quá trình xử lý vẫn bị gán cố định vào một nhân CPU.
Tính đến tháng 4 năm 2026, chỉ có một vài gateway UniFi như UCG Fiber (với SoC MediaTek Filogic 880) là được tích hợp sẵn khả năng tăng tốc phần cứng PPPoE. Đáng mỉa mai là gateway UniFi càng cao cấp thì nền tảng OEM của nó lại càng ít hỗ trợ tăng tốc PPPoE: ví dụ như EFG sử dụng dòng chip Marvell OCTEON TX2 Infrastructure hoàn toàn không hỗ trợ tính năng này.
Do hầu hết gateway UniFi sử dụng nền tảng OEM thiếu tăng tốc phần cứng PPPoE, nên không bản cập nhật firmware nào có thể sửa triệt để vấn đề này. Và với định hướng kỹ thuật hiện tại của UniFi, ngay cả những tối ưu hóa PPPoE ở cấp độ phần mềm có thể làm được cũng bị bỏ ngỏ.
Tăng tốc PPPoE Half-Bridge ngoại vi
Đến năm 2026, rất nhiều ISP vẫn phụ thuộc vào PPPoE, bao gồm Bell Canada, AT&T Fiber, Xfinity tại Mỹ và đại đa số các nhà mạng ở Châu Âu, Châu Á. Nếu gateway UniFi không thể tự đáp ứng hiệu năng PPPoE, chúng ta có thể chuyển nhiệm vụ quay số PPPoE cho một thiết bị chuyên dụng. Thiết bị này sẽ quay số PPPoE, lấy địa chỉ IP công cộng, gỡ bỏ IP đó khỏi giao diện ảo PPPoE (như ppp0) và chuyển tiếp cho gateway UniFi thông qua DHCP. Gateway UniFi sẽ nhận địa chỉ IPv4 công cộng qua DHCP mà không phải gánh tải xử lý PPPoE, từ đó tập trung toàn bộ tài nguyên cho định tuyến, IDS/IPS và NAT.
Phiên PPPoE -> Cấp IPv4 công cộng
ISP <===============> [Tải PPPoE qua OpenWrt] ========================> [UniFi Gateway]
Không giữ IPv4 công cộng -> Giữ IPv4 công cộng từ DHCP WAN
Kỹ thuật này được gọi là PPPoE Half-Bridge (hoặc Zero IP Bridge). Thiết bị giảm tải PPPoE thực hiện quay số, tước địa chỉ IPv4 khỏi giao diện ảo, khởi chạy DHCP server trên giao diện vật lý và cấp địa chỉ IPv4 công cộng đó cho gateway UniFi phía sau qua DHCP. Bằng cách này, thiết bị ngoại vi xử lý PPPoE, còn gateway UniFi nhận IPv4 công cộng trực tiếp mà không tốn tài nguyên CPU.
Trong thực tế, một số modem ONU/ONT do nhà mạng cung cấp đã tích hợp tính năng này (như Advanced DMZ, IP Passthrough hoặc DMZplus). Khi bật lên, ONU/ONT (vốn đã có tăng tốc phần cứng PPPoE) sẽ tự quay số và chuyển IPv4 công cộng cho router phía sau. Tuy nhiên, rất nhiều modem nhà mạng không hỗ trợ tính năng này, buộc người dùng phải tự thiết lập.
Triển khai PPPoE Half-Bridge với OpenWrt
Tại đây, chúng tôi sử dụng cơ chế hotplug.d của OpenWrt để triển khai phương pháp tăng tốc PPPoE half-bridge. Mã nguồn đầy đủ và cấu hình mẫu được lưu trữ tại repository GitHub arcboxlabs/pppoe-half-bridge.
Thành phần cốt lõi của arcboxlabs/pppoe-half-bridge gồm hai tệp: 99-half-bridge và start-half-bridge.sh. Tệp 99-half-bridge nằm trong đường dẫn /etc/hotplug.d/iface/ và sẽ tự động kích hoạt mỗi khi quay số PPPoE thành công (khi OpenWrt tạo giao diện ảo ppp0); sau đó nó gọi start-half-bridge.sh để hoàn tất cấu hình. Tệp start-half-bridge.sh chứa logic thực thi và sẽ tiến hành các bước sau:
- Tắt NAT/MASQUERADE ở phía WAN của firewall OpenWrt.
- Đọc địa chỉ IPv4 vừa quay số từ giao diện ảo PPPoE (ví dụ: ppp0).
- Tính toán subnet /24 chứa địa chỉ IPv4 công cộng đó, sử dụng IP đầu tiên trong dải (ví dụ: x.x.x.1) làm gateway cho DHCP server của OpenWrt, đồng thời đặt offset chính xác để DHCP server cấp địa chỉ IPv4 công cộng (ví dụ: x.x.x.114) cho gateway UniFi.
- Thay thế route mặc định và bổ sung định tuyến theo chính sách (policy-based routing) để thực hiện "source-based routing": gửi gói tin ra giao diện ảo PPPoE tương ứng với IP nguồn. Điều này cho phép tăng tốc nhiều đường truyền PPPoE cùng lúc.
- Áp dụng các thông số gateway và offset vào cấu hình DHCP server của OpenWrt rồi khởi động lại dịch vụ DHCP.
- Khởi động lại giao diện vật lý trên OpenWrt (ifdown && ifup) để kích hoạt thay đổi trạng thái kết nối, buộc gateway UniFi gửi yêu cầu xin cấp mới IPv4 công cộng từ OpenWrt.
- Do lỗi triển khai ARP trên các gateway UniFi, cần thêm các bản ghi ARP tĩnh trên OpenWrt (ip neigh replace) để đảm bảo kết nối ổn định giữa OpenWrt và gateway UniFi.
Bạn có thể tham khảo tệp EXAMPLE.md trong kho lưu trữ GitHub arcboxlabs/pppoe-half-bridge. Trong thử nghiệm thực tế với Banana Pi BPI-R4 Pro chạy OpenWrt làm thiết bị giảm tải, tốc độ PPPoE đã vượt mốc 5000 Mbps.
