Come ottenere il routing multipath per pacchetto su Linux?

Il kernel Linux prima della 3.6 utilizzava la route roaching per eseguire il routing multipath IPv4, il che significava che il routing tra due linee / ISP separate era abbastanza semplice. Da 3.6 l'algoritmo è diventato pacchetto per pacchetto, il che significa che sono stati necessari alcuni trucchi marker tabella / route / iptables per ottenere le due linee / ISP.

Tuttavia, se si disponessero di due linee con lo stesso ISP in grado di instradare un singolo IP su entrambe le linee in base al pacchetto in modo bilanciato / failover, da 3.6 è possibile ottenere facilmente il collegamento di linea (a livello IP) a causa di il routing per pacchetto in entrambe le direzioni.

Da 4.4, il kernel è tornato al bilanciamento del carico basato sul flusso basato su un hash sugli indirizzi di origine e destinazione.

Attualmente sto eseguendo il kernel 4.4.36 e sto usando il routing multipath su connessioni PPPoE. Il mio traffico a valle dall'ISP viene instradato attraverso le due linee separate in base al pacchetto (un indirizzo IP viene instradato su entrambe le linee). Questo mi dà una velocità di download superiore alla velocità di una singola linea. Quasi la velocità di entrambe le linee sommate. Funziona davvero bene, video Skype, VoIP (UDP), YouTube ecc. Funzionano tutti alla grande.

A causa dell'esperienza così positiva a valle, voglio provarlo a monte ma il mio traffico a monte viene instradato secondo il più recente algoritmo basato sul flusso su entrambi i dispositivi ppp (che hanno lo stesso indirizzo IP). Ciò significa che non riesco a raggiungere una velocità di upload superiore alla velocità di una singola riga.

C'è un modo per configurare il kernel corrente per usare l'algoritmo per pacchetto? O qualche altro metodo per ottenere il routing multipath per pacchetto? Dovrei tornare a un kernel più vecchio (cosa che non voglio fare per vari altri motivi)?

Il mio ISP non supporta ppp multi-link.

Nel caso sia rilevante, sto attualmente eseguendo Arch Linux ARMv7 su un Raspberry Pi 3.

— bao7uo
fonte

Questa è una pessima idea. Il bilanciamento per pacchetto a L2 (cioè MLPPP) include una logica sufficiente per riassemblare i pacchetti in ordine. Eseguirlo su IP lascia un'enorme opportunità (se non una quasi certezza) per la consegna fuori ordine. Questo causerà un numero enorme di problemi con sessioni TCP lente, UDP del tutto rotto, problemi con qualsiasi tipo di streaming in tempo reale, ecc. L'altro problema è che anche se invii pacchetti round robin al tuo ISP c'è assolutamente nessun suggerimento che si bilancino allo stesso modo verso di te.

— rnxrx,

@rnxrx grazie per il tuo commento - hai modificato la domanda per fornire ulteriori dettagli. Dalla mia domanda: "il traffico a valle dell'ISP viene instradato attraverso le due linee separate in base al pacchetto". L'ISP fornisce un pannello di controllo: quando scelgo un IP da instradare su entrambe le linee, lo instradano round-robin perfettamente bilanciato in base al pacchetto. Funziona bene, a circa il 90% del totale delle velocità di entrambe le linee sommate e fornisce un failover istantaneo. Video Skype, chiamate VOIP, YouTube, streaming BBC ecc. Tutto fantastico - Un'esperienza così fantastica a valle mi fa venir voglia di provare a monte

— bao7uo

Ahh - capito ... Quindi al momento hai due IP univoci (uno per connessione) o stanno instradando verso un singolo IP (o una sottorete) sul tuo lato tramite due percorsi paralleli? Se stai eseguendo qualsiasi tipo di NAT è ovviamente fondamentale che si verifichi prima di questo bilanciamento. Ad ogni modo, hai dato un'occhiata a support.aa.net.uk/… ? Sta usando le estensioni di iptables per realizzare sostanzialmente ciò che stai descrivendo e come tale dovrebbe essere abbastanza coerente tra le versioni del kernel ragionevolmente moderne.

— rnxrx,

Grazie @rnxrx - sì, posso fare entrambe le opzioni (due IP univoci o un singolo IP tramite i percorsi paralleli). Ho preferito l'opzione IP singola in quanto sembrava avere più senso.

— bao7uo,

Ok, quindi dopo aver avuto più tempo per indagare su questo ho trovato un modo per farlo usando Linux TEQL (True Link Equalizer). Ecco un link che ho seguito vagamente, ma con alcune modifiche.

http://lartc.org/howto/lartc.loadshare.html

Ecco come l'ho fatto funzionare su Arch Linux ARMv7 (Raspberry Pi 3)

All'avvio:

Il seguente comando dovrebbe essere eseguito all'avvio per caricare il modulo Kernel appropriato.

modprobe sch_teql

I seguenti comandi si eseguono anche all'avvio, supponendo che si desideri eseguire il NAT da una rete locale su eth0.

sysctl -w net.ipv4.ip_forward=1
iptables -A INPUT -i ppp+ -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ppp+ -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -o teql+ -j MASQUERADE

Il traffico di ritorno FORWARD è su ppp + e il MASCHERATO POSTROUTING su teql + perché il traffico in uscita si interrompe su teql e il traffico di ritorno su ppp.

Quando vengono visualizzati i collegamenti ppp:

Supponendo che i collegamenti per il bilanciamento del carico siano ppp, i seguenti comandi devono essere eseguiti in uno script in uno /etc/ppp/ip-up.d/script.

sysctl -w net.ipv4.conf.ppp1.rp_filter=2
sysctl -w net.ipv4.conf.ppp2.rp_filter=2
tc qdisc add dev ppp1 root teql0
tc qdisc add dev ppp2 root teql0
ip address add 1.1.1.1/32 dev teql0
# you can add additional public IP addresses teql0 if you need to
ip link set teql0 up
ip route replace default scope global dev teql0

Dov'è il 1.1.1.1tuo indirizzo IP pubblico rivolto all'ISP. È possibile assegnare IP pubblici aggiuntivi al dispositivo teql0, ma non è necessario assegnarli ai dispositivi ppp. Nella mia configurazione i due collegamenti ppp condividono lo stesso IP (negoziato da pppoe ecc.) Il collegamento teql assegnato manualmente come mostrato sopra. L'ISP deve inviare il traffico per l'IP in modo equo su entrambi i collegamenti.

Il percorso inverso ( rp_filter) è impostato su 2(sciolto) sia nello script sopra che in modo che i pacchetti di ritorno non vengano rilasciati a causa del loro ritorno sulle interfacce ppp piuttosto che teql0.

L'ho impostato in questo modo e funziona perfettamente. Molto facile! Quando i collegamenti falliscono, si verifica un failover continuo. Quando arrivano, iniziano a lavorare di nuovo. Sembra che non vi siano perdite di pacchetti o ritardi quando si verifica un errore, e nemmeno quando si verifica.

Inoltre, uno dei commentatori ha suggerito il seguente link che utilizza il routing delle politiche, con iptables per contrassegnare ogni altro pacchetto ecc., Ma tra qualche giorno proverò a vedere se funziona meglio di quanto sopra e fornirò un feedback qui di conseguenza.

http://support.aa.net.uk/Router_-_Linux_upload_bonding_using_policy_routing

— bao7uo
fonte

Non ho mai provato il routing delle politiche perché TEQL ha funzionato così bene. Se non è rotto ....

— bao7uo

Sto cercando di farlo funzionare. Ho il legame funzionante, posso usare l'interfaccia legata dal router. Tuttavia, non riesco a far funzionare il NAT, il traffico dalla mia LAN non sta andando giù il collegamento collegato :(

— andynormancx,

se pubblichi una nuova domanda su un errore del server e ti colleghi ad un commento, cercherò di capirlo. includere quante più informazioni possibili come la configurazione dell'interfaccia / ip, la tabella di routing, le regole di iptables, ecc. a meno che non sia possibile inserire tutte le informazioni qui nei commenti?

— bao7uo,

PS. ho appena notato un errore nella mia configurazione. ha detto sysctl -w net.ipv4.ip_forwardma dovrei dire sysctl -w net.ipv4.ip_forward=1che ho corretto sopra. Ciò impedirebbe sicuramente al traffico proveniente dalla LAN di scendere dal collegamento collegato.

— bao7uo,

Non penso che sia stato ciò che ha smesso di funzionare per me, avevo abilitato l'inoltro in sysctl. Ora sto cercando di capire se ci si aspetta l'enorme numero di pacchetti fuori servizio che sto vedendo.

— andynormancx,