Recientemente actualizamos un sitio remoto de una fibra de 10 / 10Mbps a un enlace de fibra de 20 / 20Mbps (es fibra al sótano, luego VDSL desde el sótano a la oficina, aproximadamente 30 metros). Hay copias regulares de archivos grandes (multi-concierto) entre este sitio y un sitio central, por lo que la teoría era que aumentar el enlace a 20/20 debería reducir a la mitad los tiempos de transferencia.
Para las transferencias para copiar archivos (p. Ej., robocopyPara copiar archivos en cualquier dirección, o la replicación de Veeam Backup and Recovery) se limitan a 10 Mbps.
Antes de la actualización:
Después de la actualización ( robocopy):
Casi idéntico (ignore la diferencia en el tiempo de la transferencia).
Las transferencias se realizan a través de un túnel IPSec entre un Cisco ASA5520 y un Mikrotik RB2011UiAS-RM .
Primeros pensamientos:
- QoS - no. Hay reglas de QoS pero ninguna que afecte este flujo. Inhabilité todas las reglas durante unos minutos para verificar de todos modos, y no cambié
- Límites definidos por software. La mayor parte de este tráfico es Veeam Backup and Recovery envío fuera del sitio, pero no hay límites definidos allí. Además, acabo de hacer una escalera
robocopyy vi exactamente las mismas estadísticas. - Hardware no capaz. Bueno, las cifras de rendimiento publicadas de un 5520 son 225Mbps de datos 3DES, y Mikrotik no publica números, pero superaría los 10Mbps. El Mikrotik tiene alrededor del 25% -33% de uso de CPU al hacer estas pruebas de transferencia. (Además, hacer una transferencia HTTP a través del túnel IPSec alcanza cerca de 20Mbps)
- ¿Latencia combinada con el tamaño de la ventana TCP? Bueno, tiene una latencia de 15 ms entre los sitios, por lo que incluso el peor de los casos de
32*0.015un tamaño de ventana de 32 KB es un máximo de 2.1 MB / seg. Además, las transferencias simultáneas múltiples solo suman hasta 10 Mbps, lo que no es compatible con esta teoría - ¿Quizás la fuente y el destino son una mierda? Bueno, la fuente puede impulsar lecturas secuenciales sostenidas de 1.6GB / seg, por lo que no es eso. El destino puede realizar escrituras secuenciales sostenidas de 200 MB / s, por lo que tampoco es eso.
Esta es una situación muy extraña. Nunca antes había visto nada manifiesto de esta manera.
¿Dónde más puedo mirar?
En una investigación adicional, confío en señalar el túnel IPSec como el problema. Hice un ejemplo artificial e hice algunas pruebas directamente entre dos direcciones IP públicas en los sitios, y luego hice exactamente la misma prueba usando las direcciones IP internas, y pude replicar 20Mbps a través de Internet sin cifrar, y solo 10Mbps en el IPSec lado.
La versión anterior tenía una pista falsa sobre HTTP. Olvídate de esto, este era un mecanismo de prueba defectuoso.
Según la sugerencia de Xeon y el eco de mi ISP cuando les pedí ayuda, establecí una regla de interrupción para eliminar el MSS para los datos de IPSec a 1422, según este cálculo :
1422 + 20 + 4 + 4 + 16 + 0 + 1 + 1 + 12
PAYLOAD IPSEC SPI ESP ESP-AES ESP (Pad) Pad Length Next Header ESP-SHA
Para caber dentro del 1480 MTU del ISP. Pero, por desgracia, esto no ha hecho una diferencia efectiva.
Después de comparar las capturas de Wirehark, la sesión TCP negocia un MSS de 1380 en ambos extremos ahora (después de ajustar algunas cosas y agregar un búfer en caso de que mis matemáticas apestan. Sugerencia: probablemente sí). 1380 también es el MSS predeterminado de ASA de todos modos, por lo que puede haber estado negociando esto todo el tiempo de todos modos.
Veo algunos datos extraños en la herramienta dentro del Mikrotik que he estado usando para medir el tráfico. No puede ser nada. No noté esto antes, ya que estaba usando una consulta filtrada, y solo vi esto cuando quité el filtro.
1394es la MTU más grande que pude atravesar.
