Di recente abbiamo aggiornato un sito remoto da una fibra da 10/10 Mbps a un collegamento in fibra da 20/20 Mbps (è fibra al seminterrato, quindi VDSL dal seminterrato all'ufficio, a circa 30 metri). Esistono regolari copie di file di grandi dimensioni (multi-concerto) tra questo sito e un sito centrale, quindi la teoria era che l'aumento del collegamento a 20/20 avrebbe dimezzato i tempi di trasferimento.
Per i trasferimenti per la copia di file (ad es. Utilizzo robocopyper copiare i file in entrambe le direzioni o per la replica di Veeam Backup and Recovery) sono limitati a 10 Mbps.
Prima dell'aggiornamento:
Dopo l'aggiornamento ( robocopy):
Quasi identico (ignora la differenza di durata del trasferimento).
I trasferimenti vengono effettuati su un tunnel IPSec tra un Cisco ASA5520 e un Mikrotik RB2011UiAS-RM .
Primi pensieri:
- QoS - no. Esistono regole QoS ma nessuna che dovrebbe influire su questo flusso. Ho disabilitato tutte le regole per alcuni minuti per controllare comunque, e nessuna modifica
- Limiti definiti dal software. La maggior parte di questo traffico è rappresentato dalla spedizione Veeam Backup and Recovery fuori sede, ma non vi sono limiti definiti. Inoltre, ho appena fatto una scala
robocopye ho visto esattamente le stesse statistiche. - Hardware non in grado. Bene, i dati sulle prestazioni pubblicati di un 5520 sono 225 Mbps di dati 3DES, e Mikrotik non pubblica numeri ma sarebbe ben più di 10 Mbps. Mikrotik ha circa il 25% -33% di utilizzo della CPU durante questi test di trasferimento. (Inoltre, eseguire un trasferimento HTTP sul tunnel IPSec raggiunge quasi i 20 Mbps)
- Latenza combinata con le dimensioni della finestra TCP? Beh, è una latenza di 15 ms tra i siti, quindi anche nel caso peggiore una dimensione della finestra di 32 KB
32*0.015è un massimo di 2,1 MB / sec. Inoltre, più trasferimenti simultanei aggiungono solo fino a 10 Mbps, il che non supporta questa teoria - Forse la fonte e la destinazione sono entrambe merda? Bene, la fonte può inviare letture sequenziali sostenute da 1,6 GB / sec, quindi non è così. La destinazione può eseguire scritture sequenziali prolungate di 200 MB / sec, quindi non è nemmeno quello.
Questa è una situazione molto strana. Non ho mai visto nulla manifestare in questo modo prima d'ora.
Dove altro posso cercare?
Su ulteriori indagini, sono sicuro di indicare il problema con il tunnel IPSec. Ho fatto un esempio inventato e fatto alcuni test direttamente tra due indirizzi IP pubblici sui siti, e poi fatto lo esatto stesso test utilizzando gli indirizzi IP interni, e sono stato in grado di replicare 20Mbps su internet in chiaro, e solo a 10 Mbps sul IPSec lato.
La versione precedente aveva un'aringa rossa su HTTP. Dimentica questo, questo era un meccanismo di test difettoso.
Secondo il suggerimento di Xeon ed echeggiato dal mio ISP quando ho chiesto loro il supporto, ho impostato una regola mangle per far cadere MSS per i dati IPSec a 1422, sulla base di questo calcolo :
1422 + 20 + 4 + 4 + 16 + 0 + 1 + 1 + 12
PAYLOAD IPSEC SPI ESP ESP-AES ESP (Pad) Pad Length Next Header ESP-SHA
Per adattarsi all'interno dell'ISP 1480 MTU. Ma purtroppo questo non ha fatto alcuna differenza.
Dopo aver confrontato le acquisizioni di WireShark, la sessione TCP negozia un MSS di 1380 su entrambe le estremità (dopo aver modificato alcune cose e aggiunto un buffer nel caso in cui la mia matematica faccia schifo. Suggerimento: probabilmente lo fa). 1380 è anche l'MSS predefinito dell'ASA, quindi potrebbe averlo negoziato comunque tutto il tempo.
Sto vedendo alcuni dati strani nello strumento all'interno del Mikrotik che ho usato per misurare il traffico. Potrebbe non essere niente. Non l'avevo notato prima mentre stavo usando una query filtrata e l'ho visto solo quando ho rimosso il filtro.
1394è il più grande MTU che sono stato in grado di superare.
