Come implementare aggregazione like MLPPP?

[parabolino]

Come è noto, RouterOS non implementa il MLPPP lato server, cosa che tornerebbe molto utile...

Ho l'esigenza di dover aggregare (posso agire lato ISP) due o più linee xDSL (PPPoE, ma potrei fare diversamente, se necessario) in modo da avere un unico flusso totale pari alla somma delle singole linee presentandosi con un unico IP pubblico (o subnet pubblica) verso Internet.

CISCO implementa un balancing per packet e molti ISP risolvono in questo modo.
Ma preferirei non andare in questa direzione...

L'equivalente su ROS sarebbe di usare mangle rules e routing mark, tuttavia desideravo trovare una soluzione più elegante ed efficace, e soprattutto dinamica (le xDSL devono poter arrivare su più NAS in clustering L2).

Avete suggerimenti o spunti?
Potrei pensare di implementare un BGP (iBGP?) tra customer e NAS?

Grazie in anticipo

[figheras]

Una soluzione potrebbe essere (Se le connessioni partono dallo stesso ISP che gli annuncia le subnet), e gli garantisci anche un MTU pieno di 1500byte, quella di tracciare due link da punti diversi della rete e terminarli su di un router unico usando ECMP, ruotando quindi lato ISP la subnet assegnata con stessa distance su entrambi i percorsi, mentre lato client usando un gateway multiplo potendo assegnare peso maggiore ad un gateway rispetto l'altro, hai così il doppio vantaggio del bilanciamento/failover, credo che sia una soluzione pulita e veloce....
Per quanto riguarda MLPPP allo stato attuale mikrotik ancora non ha implementato questa feature...

[parabolino]

Una soluzione potrebbe essere (Se le connessioni partono dallo stesso ISP che gli annuncia le subnet), e gli garantisci anche un MTU pieno di 1500byte, quella di tracciare due link da punti diversi della rete e terminarli su di un router unico usando ECMP, ruotando quindi lato ISP la subnet assegnata con stessa distance su entrambi i percorsi, mentre lato client usando un gateway multiplo potendo assegnare peso maggiore ad un gateway rispetto l'altro, hai così il doppio vantaggio del bilanciamento/failover, credo che sia una soluzione pulita e veloce....
Per quanto riguarda MLPPP allo stato attuale mikrotik ancora non ha implementato questa feature...

Si, l'idea iniziale era proprio quella ECMP, IP o Subnet verso le due PtP (lato ISP) e ECMP lato CPE.... e mi andrebbe bene se avessi un unico NAS... purtroppo ho più NAS in cluster (oggi 2, domani non so...) e dovrei replicare (per avere il failover lato ISP) e/o forzare la configurazione su un solo NAS (perdendo il failover lato ISP)...

Per MLPPP Server ho trovato qualcosa per FreeBSD, devo provarla...

Il discorso MTU 1500 è per evitare frammentazione e che quindi i frammenti vadano su due linee differenti?

tnx

[figheras]

Si, l'idea iniziale era proprio quella ECMP, IP o Subnet verso le due PtP (lato ISP) e ECMP lato CPE.... e mi andrebbe bene se avessi un unico NAS... purtroppo ho più NAS in cluster (oggi 2, domani non so...) e dovrei replicare (per avere il failover lato ISP) e/o forzare la configurazione su un solo NAS (perdendo il failover lato ISP)...

Allora nel caso di due NAS e quindi di due connessioni parallele (dietro NAT) fare un ECMP è la cosa più sbagliata perchè l'algoritmo che lavora nella gestione del ECMP aggiorna la tabella di routing all'incirca ogni 10minuti, quindi sulle connessioni di tipo established/related potresti avere il problema di presentarti successivamente con un gateway differente e vederti tagliato fuori da quella sessione....
Quello che ti consigliavo io era di non passare attraverso i tuoi nas ma di attestare una eth/vlan su uno dei tuoi router/switch(managed/L3) presenti in un pop e di fare un link trasparente verso il cliente terminandolo sul router (CPE) che gli installerai, chiaramente per il failover devi poter riusciere a partire da un pop differente per garantirgli la contiunità.....

Il discorso MTU 1500 è per evitare frammentazione e che quindi i frammenti vadano su due linee differenti?

Per quanto riguarda il discorso MTU, era per avere un MTU pieno di 1500byte che non avresti nel caso di una connessione che attreversa un tunnel, nel tuo caso un tunnel pppoe che genera 8 byte di overhead e ti costringe a ridure il payload per compensare i 1500byte.