Dos enllaços ascendents però un sol túnel: commutació, balanceig o agregació

Dues línies d’internet poden fer una VPN més disponible, i poden fer-la més ràpida per a algunes càrregues de treball, però el mecanisme decideix quina de les dues coses passa. Un encaminador amb dues rutes per defecte no està agregat, i un túnel que transporta milers de connexions internes continua sent un sol flux extern. Anomenar la promesa primer és la diferència entre un disseny i una decepció carregosa. La taula de sota separa les opcions segons què necessita cadascuna a l’extrem remot i què fa una pèrdua d’enllaç a una transferència.

Tres promeses, i només una necessita un soci

La commutació per fallada manté un camí disponible quan l’enllaç preferit desapareix. El balanceig per hash de flux reparteix fluxos independents entre tots dos enllaços ascendents. L’agregació d’un sol flux permet que una transferència faci servir tots dos enllaços alhora. Són productes diferents amb requisits diferents, i només l’últim necessita la cooperació d’alguna cosa més enllà del vostre encaminador.

Res d’aquesta taula no és un motiu per comprar una segona línia. El que fa és impedir que un disseny de commutació es valori com si fos agregació.

Per què un túnel sembla un sol flux per a l’encaminador

Un encaminador que balanceja la càrrega aplica un hash a les adreces d’origen i destí juntament amb els ports, i després envia tot el flux allà on apunta el hash. Un túnel VPN és un flux així des de la perspectiva de l’encaminador, passi el que passi a dins. Les connexions internes no arriben mai a la decisió del hash, perquè la capçalera externa ja ha decidit el camí. Per això un segon enllaç ascendent pot duplicar la capacitat total per a molts usuaris i no canviar res en una transferència gran d’un sol usuari.

Dos túnels separats us poden donar dos candidats, però encara necessiten una política intencionada que assigni el trànsit i mantingui les respostes pel camí que va portar la petició. L’encaminament asimètric és el resultat habitual de saltar-se aquest pas. El mínim és una política que anomeni el flux, l’enllaç preferit i l’enllaç de reserva.

L’agregació Ethernet no travessa proveïdors no relacionats, perquè l’extrem remot ha de participar en el protocol d’agregació. Una agregació entre dos proveïdors d’internet és un projecte de recerca tret que existeixi un punt final que hi cooperi.

Què necessita el TCP multipath a tots dos extrems

La documentació de Linux sobre Multipath TCP descriu diversos subfluxos que pertanyen a una connexió. El suport del nucli en un extrem no converteix res per si sol, ja que l’altre extrem també ha d’acceptar aquests subfluxos. Un proxy a l’altre costat és l’altra disposició habitual, i es converteix en un component amb la seva pròpia capacitat i disponibilitat que cal planificar. La mateixa lògica descarta una resposta fàcil per a WireGuard, el transport del qual és UDP: MPTCP fa créixer subfluxos TCP i no pot agregar aquest túnel sense alguna cosa més al disseny.

Comproveu si la funció del nucli està activada abans de dissenyar-hi al voltant, perquè moltes distribucions la lliuren desactivada. Aquestes tres ordres ho responen en un minut.

sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits show

Trieu per la càrrega de treball, no pel fullet

Si la càrrega de treball és moltes sessions independents, el balanceig per hash de flux pot afegir capacitat sense cooperació a l’extrem remot. Si és una transferència gran, només ajudarà un disseny d’agregació, i aquest disseny necessita un soci que hi cooperi. Si el requisit és que la feina continuï quan mor un enllaç, la resposta és la commutació per fallada i el cabal d’una sola transferència és irrellevant.

Escriviu el requisit en una frase amb un verb a dins: una còpia de seguretat acaba el doble de ràpid, o un enllaç caigut no acaba una sessió. Els objectius vagues produeixen dissenys que ningú no pot acceptar ni rebutjar. Després decidiu què pot ser l’extrem remot, perquè l’opció més barata sovint és la que no hi requereix res de nou. Aquesta restricció elimina la majoria d’afirmacions del fullet abans de la primera reunió.

Manteniu les tres promeses separades al document de requisits. Un disseny que afirma les tres normalment en lliura una i assumeix en silenci les altres. La secció següent prova quina es lliura de debò.

Proveu una transferència i moltes, i després traieu un enllaç

Compareu una transferència sostinguda amb diverses transferències paral·leles a la mateixa destinació, i anoteu la pèrdua, el retard i la utilització per enllaç de cadascuna. Un guany només amb sessions paral·leles apunta a la distribució de fluxos, no a l’agregació d’un sol flux. Proveu la pèrdua d’un enllaç ascendent per separat, perquè la capacitat mentre tots dos enllaços funcionen no diu res sobre la commutació per a una sessió establerta. Captureu la ruta, el sòcol i els comptadors de retransmissió abans i després de cada prova.

ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5

Quan la transferència única continua fent servir un sol enllaç ascendent, el disseny fa exactament el que implica un hash de flux. Quan les transferències paral·leles es reparteixen entre tots dos, el balanceig funciona i l’agregació no. Anoteu quina de les tres promeses manté realment el disseny, i la propera conversa sobre capacitat començarà amb proves en lloc d’una afirmació del proveïdor.