Ubiquiti Edge Router-X

[frakka]

Alla fine. a forza di insistere, un bel risultato è comunque venuto fuori:

[frakka]

Lo ammetto, non avevo idea di cosa fosse il "bufferbloat" e solo vagamente di cosa sia il QoS (e ancora meno lo "Smart Queue Management")...

Ravanando per il web alla ricerca di informazioni e tuning per questo router, mi sono imbattuto in un articolo che trattava di latenze in gaming articolo di blog che decantava miracoli dopo la configurazione del QoS (Quality of Service) ed in particolare di una specifica feature introdotta in una delle ultima release del software del router la "Smart Queue Management".

In sostanza, il QoS si occupa di istruire il router a dare priorità ad un determinato traffico piuttosto che ad un altro. Si possono quindi agevolare specifici flussi (magari come la videoconferenza o il traffico VoIP) a discapito di altri o fare in modo che lo schedulatore interno del router lavori meglio, passandogli specifici parametri e dicendogli e usare quelli per calibrare il proprio scheduler interno. Normalmente sarebbe in lavoro lungo e complesso perchè richiede parecchio tuning ma la "Smart Queue Management" dovrebbe proprio fare la gran parte del lavoro in maniera automatica, solo accendendola e impostando il valore di velocità atteso dalla connessione.

In particolare, si dovrebbero notare notevoli miglioramenti nella latenza complessiva per via di un problema noto con il nome di "bufferbloat" (di cui, onestamente, non avevo mai sentito parlare e che non sapevo di avere) e che è una delle cause del jitter (altra cosa che ho visto comparire in qualche test da di cui non sapevo molto):

Buffer Bloat, your router is pushing more data on the internet connection then your connection can handle. This will cause the buffers to overfill resulting in delays and high latency

Su questo sito si trova una rappresentazione grafica abbastanza chiara del problema: In pratica, nel router entra più traffico di quello che può uscire dalla connessione WAN (per via della connessione lenta ma anche magari per limiti computazionali dell'apparato) e questo genera il riempimento e l'overflow di un buffer interno del router che provoca una perdita di pacchetti che genera un lag interruzioni in quelli che sono, ad esempio, i flussi audio durante uno streaming o sessioni VoIP.

Aumentare la dimensione del buffer oltre quello che dovrebbe essere il suo dimensionamento "corretto" (una regola empirica, secondo Wikipedia, prevede di poter accomodare nel buffer 250millisecondi di traffico) porta ad avere molti dati da dover scodare nel caso in cui il buffer finisca per riempirsi e questo provoca altri rallentamenti e lag. Un router gigabit, ad esempio, secondo la regola sopra riportata dovrebbe avere un buffer di circa 32Mb il che significa 32Mb di dati da dover gestire quando il flusso si ripristina, prima di poter gestire nuove richieste.

Quindi:
- Buffer troppo piccolo -> Overflow e perdita di traffico nelle applicazioni realtime come il gaming e lo streaming;
- Buffer troppo ampio -> In caso si riempia, Troppi dati da dover scodare prima di poter soddisfare nuove richieste. Quindi lag e alte latenze;

Riprendendo la rappresentazione grafica riportata prima, quindi, la soluzione è quella di gestire il rubinetto del traffico in entrata per fare in modo da limitare al massimo l'accumulo di dati nel buffer, dando priorità al traffico importante e accettando che quello meno importante possa subire ritardi o prendersi addirittura delle pigne.


Nel mio caso specifico, la fibra in uscita sembrava garantire prestazioni migliori di quelle che possono essere ottenute dal router quindi non mi aspettavo particolare miglioramenti ma ho voluto provare lo stesso.

Con lo SQM disabilitato (default):



Con lo SQM abilitato, impostato a 300Mbit solo per l'upload:



Lo score del "bufferbloat" è passato da "C" ad "A+"...
Abilitarlo solo in upload è quello che mi ha dato i risultati migliori, anche se questi test verso internet possono essere influenzati da diversi fattori (oggi, ad esempio, non mi avvicino facilmente ai 500Mbit/s nei test) ma mi sto attrezzando...



Per dettagli, qui:
fixing-bufferbloat-in-ubiquiti-edgeos
Cake-and-FQ-PIE-compiled-for-the-EdgeRouter-devices
EdgeMAX-EdgeRouter-software-release-v1-7-0

[frakka]

Quando ho attivato la connettività su Open Fiber con l'operatore "Fibra.City" mi sono fatto attribuire l'IPv4 pubblico statico previsto dal mio pacchetto.

E' una storia lunga e tediosa ma, riassumendo:

• L'operatore prevede per l'assegnazione degli IP statici inclusi nei pacchetti una configurazione assolutamente legittima e, a posteriori, pure sensata dal suo punto di vista ma un po' esoterica;
• Non fornisce alcuna spiegazione chiara su come gestire questa configurazione e, a domande dirette poste sul suo forum di supporto, principalmente si limita a rilanciare il fatto che se questa conf non ti piace o il tuo router non la supporta puoi comprare la versione "tradizionale" al costo aggiuntivo di 10€/mese;
• La configurazione, nella sua versione corretta, non è supportata da praticamente nessun router consumer/soho, è necessario ricorrere a router di fascia decisamente diversa (e neppure tutti). Ovviamente, questa cosa non è scritta da nessuna parte;
• E' disponibile una versione "fallback" comunque accettabile e che dovrebbe funzionare sul 99% per router ed essere accettabile per il 99.5% dei casi ma non è la modalità "corretta" ed io ho la testa dura.

La modalità di fallback prevedere di usare sulla Wan del router la configurazione con la subnet /24 (255.255.255.0), l'IP ed il gateway che indicano. Fine del cinema: nel 99% dei casi questa configurazione funzionerà e non vi accorgerete mai di nulla. Se doveste avere problemi di navigazione immediatamente dopo la configurazione, provate a spegnere e ri-accedere dopo qualche minuto la ONT. L'unico side-effect è che non potrete in alcun modo raggiungere gli altri IP contigui al vostro che appartengono alla /24 che avete configurato nella WAN ma, essendo IP solitamente assegnati a utenze domestiche, non dovrebbe assolutamente essere un problema.

La modalità corretta, invece, prevede la configurazione di una connessione punto-punto tra l'IP e che vi hanno dato e quello del gateway. L'ubiquiti non supporta questa modalità da GUI ma, avendo un OS sostanzialmente basato su Debian, agendo dalla command line del router è abbastanza semplice ottenere il risultato inserendo manualmente le rotte statiche usando il comando "ip route add".

Per procedere alla configurazione su Edge Router-X è necessario, come prima cosa, togliere il gateway dalla configurazione del router nella tab "System" (lasciarlo proprio senza) e impostare l'IP pubblico che ci è stato assegnato come /32 nella configurazione della porta WAN. A questo punto, collegandosi alla cli del router e diventando root la configurazione delle route dovrebbe essere simile a questa:

root@EdgeRouter-X-5-Port:~# ip route
IP-statico dev porta-wan proto kernel scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
[...]

Impostare poi una route statica per specificare che il gateway indicato è raggiungibile sulla porta "WAN" su cui è configurato anche l'IP /32 e che quell'IP è il "default gateway":

root@EdgeRouter-X-5-Port:/etc/network# ip route add IP-Gateway dev porta-wan
root@EdgeRouter-X-5-Port:/etc/network# ip route add default via IP-Gateway dev porta-wan

La route risultante dovrebbe essere questa:

root@EdgeRouter-X-5-Port:~# ip route
default via IP-Gateway dev porta-wan
IP-Gateway dev porta-wan scope link
IP-statico dev porta-wan proto kernel scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
[...]

Provare un ping verso un host di internet dovrebbe ora dare un riscontro positivo.
Il problema è che questa configurazione non è persistente (cioè non sopravvive al riavvio del router) quindi per non doverla inserire a mano nel caso il router si dovesse spegnere l'ho inserita in un piccolo script depositato in una directory ad hoc del router, che viene eseguito automaticamente ad ogni avvio: La directory è la "/config/scripts/post-config.d/" ed il file, oltre ad essere eseguibile, deve terminare con l'estensione ".sh" altrimenti non viene processato. Il contenuto del file non sono altro che i due comandi "ip route add" lanciati prima:

#!/bin/sh
# Matteo 20200506
# Rendo persistenti le route necessarie per far funzionare
# il link di Fibr@.City usando la configurazione con la /32.
# Il file deve avere estensione .sh altrimenti non viene eseguito!!
#
# NON INSERIRE UN GATEWAY NELLA CONFIGURAZIONE "SYSTEM" DELLA DASHBOARD!
#
# Ref: https://forum.fibra.click/d/6603-rfc...-non-contigui/
#

/sbin/ip route add 185.178.92.5 dev eth1
/sbin/ip route add default via 185.178.92.5 dev eth1

exit

La GUI dovrebbe ora mostrare un paio di route di tipo "kernel" in più di prima:



Con questa configurazione, anche quel piccolo e remoto pertugio di internet che prima vi era precluso (gli altri IP della /24) adesso dovrebbe risultare raggiungibile!

Un altro problema è che smette di funzionare la modalità "hairpin NAT" ma ci guarderò appena avrò un po' di tempo per farlo.