mario152475
Una prima premessa doverosa: in questo forum esistono già fiumi di discussioni che sviscerano i limiti architetturali dei dispositivi MikroTik in scenari PPPoE. Il collo di bottiglia principale è sempre lo stesso: l'assenza di hardware offloading dedicato che costringe la CPU a farsi carico di tutto via software (limite storicamente e giustamente evidenziato da utenti esperti come @mark129).
Seconda premessa: Leggendo vari thread, emerge un pattern ricorrente. Molti utenti subiscono il fascino del brand, attratti dall'interfaccia iper-tecnica (RouterOS) e da un'aura molto "prosumer". Spesso acquistano questi apparati sulla scia dell'entusiasmo, convinti di avere per le mani macchine senza limiti, per poi scontrarsi con la dura realtà dello scenario PPPoE italiano. A quel punto, testando le performance sul campo, scoprono (con non poca delusione) che apparati di brand cinesi molto più economici (come i GL.iNet), grazie a SoC MediaTek e acceleratori hardware nativi, offrono prestazioni di routing puro nettamente superiori.
Questa affermazione dimostra purtroppo una profonda incomprensione di cosa si stia realmente misurando. Uno speedtest lanciato dal router stesso non è affatto lo "scenario peggiore", ma l'esatto contrario: salta a piè pari la parte più complessa e faticosa del lavoro di rete.
È un test fuorviante e non dimostra la reale "potenza" del router nella vita quotidiana, poiché bypassa il NAT, il Firewall e il forwarding datapath, che rappresentano il vero "peso" del routing. Solo il test che si esegue con il PC è un test di "Routing Puro" (LAN-to-WAN), cioè in grado di certificare a quale velocità il router è capace di spingere il traffico fisicamente sul cavo in fibra solo dopo:
averlo preso da un dispositivo esterno e avergli fatto attraversare tutto lo stack di sicurezza (Firewall, NAT);
averlo incapsulato in PPPoE.
È questo l'unico banco di prova che riflette le prestazioni REALI della rete.
Il lavoro principale di un router non è scaricare file per se stesso (come avviene nel tuo test), ma fare da "casello autostradale" tra la rete di casa e Internet. Quando fai uno speedtest dal PC, il traffico entra nel router dalla rete locale (LAN). Il router deve prendere i pacchetti, ispezionarli con il Firewall (le regole di forwarding), applicare il NAT (Masquerading, per tradurre l'indirizzo IP privato del PC in quello pubblico dell'ISP), incapsularli nel PPPoE e infine spedirli. Quando lo speedtest viene fatto da dentro il router, il traffico nasce già sul confine di Internet (i pacchetti dati vengono "creati" dalla CPU del router e inviati verso la WAN). La fase di ispezione LAN-to-WAN, Firewall e NAT viene totalmente bypassata! Manca metà del lavoro.
In quel momento il tuo router sta agendo da "Client" e non da router:
Non deve applicare le regole del Firewall per difendere i dispositivi.
Non deve fare il NAT.
Non deve prendere i pacchetti e spedirli su un'altra interfaccia fisica.
Per dirla in termini di architettura OS: il tuo router non sta facendo forwarding LAN→WAN e non sta esercitando il forwarding datapath. Il traffico passa nella OUTPUT chain, non passa nel forwarding path e non sfiora nemmeno il conntrack/NAT path. Quindi devo darti una brutta notizia: tu non saturi minimamente la banda a 2.5 Gbps in download in uno scenario di routing PPPoE reale. Del resto, il tuo router monta un SoC IPQ-6010 che dispone di un chip switch per l'accelerazione hardware al livello 2 (switching locale tra le porte e gestione delle VLAN), ma – come la stragrande maggioranza dei MikroTik basati su architettura ARM – è del tutto sprovvisto di Hardware Flow Offloading dedicato per il protocollo PPPoE. Tutto il tremendo lavoro di imbustamento dei pacchetti PPPoE e il controllo del firewall ricade interamente sui quattro core della CPU principale, aiutata solo via software dall'algoritmo "FastTrack" di RouterOS. Se provassi ipoteticamente a forzare la sua unica porta 2.5G a fare sia da entrata che da uscita (usando le VLAN su uno switch gestito), la CPU imploderebbe. I test di routing puro della stessa MikroTik e della community confermano che, con una configurazione standard da casa (circa 25 regole di firewall attive), l'hAP ax³ crolla a una capacità di routing LAN-to-WAN di circa 1.1 - 1.9 Gbps al massimo.
mario152475 La gestione del PPPoE è single-thread, quindi hai il resto dei core per il resto delle "funzione avanzate".
Anche questo ragionamento pecca di eccessiva semplificazione e ignora come funziona il datapath del kernel. Ci sono numerose discussioni in questo forum che spiegano come, in assenza di hardware offload dedicato, il protocollo PPPoE venga gestito interamente dalla CPU tramite il datapath software. In questi scenari, quando si attivano contemporaneamente funzionalità avanzate (firewall stateful, NAT, QoS, VPN, ecc.), tali processi entrano inevitabilmente in competizione per le stesse risorse utilizzate per il forwarding del traffico LAN→WAN.
Senza un'unità di hardware flow offload specifica per PPPoE, ogni pacchetto proveniente dalla rete locale deve essere elaborato completamente via software: tracciamento della connessione (conntrack), traduzione NAT e incapsulamento PPPoE. Questo percorso di elaborazione non può essere parallelizzato in modo efficiente su più core per il singolo flow di forwarding (per evitare il packet reordering). Di conseguenza, anche in presenza di CPU multi-core, la sostenibilità del throughput PPPoE sotto traffico client reale resta pesantemente limitata. Avere core "liberi" non elimina il collo di bottiglia, poiché ogni pacchetto deve comunque attraversare la medesima strozzatura sequenziale. (Il medesimo problema si è presentato storicamente per molti gateway Ubiquiti, salvati poi solo dall'introduzione di offloading specifici).
Quindi, dedurre che avendo "core liberi" si abbiano risorse magiche per le funzioni avanzate senza impattare la velocità è concettualmente errato. Non tiene conto del fatto che il forwarding PPPoE LAN→WAN, in assenza di offload hardware dedicato, resta vincolato al medesimo datapath software per-flow.
