Solución de problemas de bajo rendimiento TCP Ethernet de Metro

14

La puesta en marcha

Hemos alquilado algunas líneas arrendadas que se presentan como una red de capa 2, es decir, tiene una tubería grande en el centro de datos y los sitios remotos tienen tuberías más pequeñas. Dentro de la red de capa 2 puedes hacer lo que quieras. Probablemente usan 802.1ad para dar a cada cliente su red separada dentro de su red. AFAICS la mayoría de los sitios están conectados a través de VDSL simple.

Decidimos poner un enrutador en cada sitio y darle a cada sitio su propia VLAN. El cortafuegos en el DC tiene tantas VLAN definidas como sitios. Cada sitio utiliza su rango de direcciones en su propia VLAN.

Diagrama de Red:

diagrama de Red

El problema

Ahora, nos enfrentamos con problemas de rendimiento:

  • Ejecutar una transferencia FTP desde el sitio a DC funciona bien a aproximadamente 10Mb / s, que es la velocidad de la línea.
  • Ejecutar una transferencia FTP desde DC al sitio no funciona bien a 6Mb / so menos.

No importa qué lado inicie la transferencia. Lo único consistente es que una dirección no funciona bien. Lástima que sea la dirección hacia el sitio porque ese sería el ancho de banda que más necesitamos, ya que nos gustaría utilizar clientes de servidor de terminal.

Aproximadamente 10 segundos en la transferencia, el rendimiento disminuye. Vemos DUP ACKs al oler. ¿Qué tal vez me lleve a limitar la tasa al final del proveedor? (Actualmente, no tienen ni idea, y me gusta asegurarme de que no tenemos la culpa antes de escalar)

NOTA Los sitios remotos están limitados a 10Mb de alguna manera. Configurar el cambio a puerto Metro a 10Mb tampoco ayuda. De hecho, es lo peor entonces (máx. 30 KB / s). Establecer 100Mb funciona bien pero ya comienza a producir el problema descrito. Lo mismo para 1G.

Las capturas del problema se pueden descargar aquí:

* http://178.63.11.6/dc-to-remote_dc-side.pcapng
* http://178.63.11.6/dc-to-remote_remote-side.pcapng

Diagnósticos

En la imagen, verá el gráfico de IO de Wireshark con algunos detalles de error:

  • a la izquierda: transferencia FTP desde DC al sitio
  • a la derecha: transferencia FTP del sitio a DC

Acks duplicados

En el caso de que el otro lado inicie la transferencia (es decir, desde DC, en lugar de obtener desde remoto), el problema no cambia.

Por favor, complaceme con lo que crees que podría ser el problema aquí.

ACTUALIZACIÓN # 1 (integrado arriba)

ACTUALIZACIÓN # 2 ( ACTUALIZADO )

Esto debe ser una cosa de control de congestión.

Tenga en cuenta que desde DC al control remoto tenemos enlaces 10G-> 1G-> 100M-> 10M-> 1G. <- no funciona

En la otra dirección tenemos el inverso: 1G-> 10M-> 100M-> 1G-> 10G. <- bien

El primer "1G-> 10M" es el 10M "invisible" en el sitio remoto, donde todo, incluida la velocidad del puerto de enlace ascendente, se establece en 1G, a pesar de que solo hay 10M detrás (se vende).

Sin embargo, los 100Mbps en DC son 100Mbps reales, la interfaz está configurada a 100Mbps en la capa física.

Ahora usé iperf:

  • Las pruebas TCP funcionan bien solo en una dirección (cliente = DC, servidor = remoto)
./iperf -c 192.168.x -i2 -t 60 -r
-------------------------------------------------- ----------
Servidor escuchando en el puerto TCP 5001
Tamaño de ventana TCP: 85,3 KByte (predeterminado)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Cliente que se conecta a 192.168.x, puerto TCP 5001
Tamaño de ventana TCP: 16.0 KByte (predeterminado)
-------------------------------------------------- ----------
[3] puerto local 10.x 38195 conectado con el puerto 192.168.x 5001
[3] 0.0- 2.0 seg 1.44 MBytes 6.03 Mbits / seg
[3] 2.0- 4.0 seg. 2.23 MBytes 9.37 Mbits / seg.
[3] 4.0- 6.0 segundos 2.28 MBytes 9.57 Mbits / seg
[3] 6.0- 8.0 segundos 1.88 MBytes 7.90 Mbits / seg
[3] 8.0-10.0 segundos 1.00 MBytes 4.19 Mbits / seg
[3] 10.0-12.0 segundos 1.30 MBytes 5.47 Mbits / seg
[3] 12.0-14.0 segundos 688 KBytes 2.82 Mbits / seg
[3] 14.0-16.0 seg 840 KBytes 3.44 Mbits / seg
[3] 16.0-18.0 seg 1.03 MBytes 4.33 Mbits / seg
[3] 18.0-20.0 seg 1.01 MBytes 4.23 Mbits / seg
[3] 20.0-22.0 seg 1.03 MBytes 4.33 Mbits / seg
[3] 22.0-24.0 seg 1.18 MBytes 4.95 Mbits / seg
[3] 24.0-26.0 segundos 904 KBytes 3.70 Mbits / seg
[3] 26.0-28.0 segundos 840 KBytes 3.44 Mbits / seg
[3] 28.0-30.0 seg 936 KBytes 3.83 Mbits / seg
[3] 30.0-32.0 seg 1.09 MBytes 4.59 Mbits / seg
[3] 32.0-34.0 seg 960 KBytes 3.93 Mbits / seg
[3] 34.0-36.0 segundos 752 KBytes 3.08 Mbits / seg
[3] 36.0-38.0 seg 1.09 MBytes 4.59 Mbits / seg
[3] 38.0-40.0 seg 1.09 MBytes 4.59 Mbits / seg
[3] 40.0-42.0 segundos 840 KBytes 3.44 Mbits / seg
[3] 42.0-44.0 segundos 1.27 MBytes 5.34 Mbits / seg
[3] 44.0-46.0 seg 1.16 MBytes 4.85 Mbits / seg
[3] 46.0-48.0 seg 840 KBytes 3.44 Mbits / seg
[3] 48.0-50.0 seg 960 KBytes 3.93 Mbits / seg
[3] 50.0-52.0 segundos 1.28 MBytes 5.37 Mbits / seg
[3] 52.0-54.0 seg 1.09 MBytes 4.59 Mbits / seg
[3] 54.0-56.0 segundos 992 KBytes 4.06 Mbits / seg
[3] 56.0-58.0 segundos 1.00 MBytes 4.19 Mbits / seg
[3] 58.0-60.0 seg 1.09 MBytes 4.59 Mbits / seg
[3] 0.0-60.2 seg 33.9 MBytes 4.73 Mbits / seg
[5] puerto local 10.x 5001 conectado con puerto 192.168.x 10965
[5] 0.0- 2.0 seg 1.85 MBytes 7.75 Mbits / seg
[5] 2.0- 4.0 seg 1.90 MBytes 7.98 Mbits / seg
[5] 4.0- 6.0 segundos 1.89 MBytes 7.93 Mbits / seg
[5] 6.0- 8.0 segundos 1.92 MBytes 8.07 Mbits / seg
[5] 8.0-10.0 segundos 1.91 MBytes 8.02 Mbits / seg
[5] 10.0-12.0 segundos 1.83 MBytes 7.69 Mbits / seg
[5] 12.0-14.0 segundos 1.86 MBytes 7.78 Mbits / seg
[5] 14.0-16.0 seg 1.79 MBytes 7.52 Mbits / seg
[5] 16.0-18.0 seg 1.79 MBytes 7.52 Mbits / seg
[5] 18.0-20.0 segundos 1.89 MBytes 7.91 Mbits / seg
[5] 20.0-22.0 segundos 1.91 MBytes 8.00 Mbits / seg
[5] 22.0-24.0 seg 1.88 MBytes 7.91 Mbits / seg
[5] 24.0-26.0 seg 1.95 MBytes 8.16 Mbits / seg
[5] 26.0-28.0 segundos 1.90 MBytes 7.99 Mbits / seg
[5] 28.0-30.0 seg 1.87 MBytes 7.84 Mbits / seg
[5] 30.0-32.0 segundos 1.85 MBytes 7.77 Mbits / seg
[5] 32.0-34.0 seg 1.55 MBytes 6.49 Mbits / seg
[5] 34.0-36.0 segundos 1.92 MBytes 8.07 Mbits / seg
[5] 36.0-38.0 segundos 1.90 MBytes 7.99 Mbits / seg
[5] 38.0-40.0 segundos 1.84 MBytes 7.73 Mbits / seg
[5] 40.0-42.0 seg 1.66 MBytes 6.95 Mbits / seg
[5] 42.0-44.0 segundos 1.92 MBytes 8.07 Mbits / seg
[5] 44.0-46.0 segundos 1.91 MBytes 7.99 Mbits / seg
[5] 46.0-48.0 seg 1.90 MBytes 7.98 Mbits / seg
[5] 48.0-50.0 seg 1.84 MBytes 7.70 Mbits / seg
[5] 50.0-52.0 segundos 1.93 MBytes 8.09 Mbits / seg
[5] 52.0-54.0 segundos 1.80 MBytes 7.54 Mbits / seg
[5] 54.0-56.0 seg 1.83 MBytes 7.67 Mbits / seg
[5] 56.0-58.0 seg 1.88 MBytes 7.86 Mbits / seg
[5] 58.0-60.0 segundos 1.85 MBytes 7.78 Mbits / seg
[5] 0.0-60.3 segundos 56.0 MBytes 7.79 Mbits / seg
  • Para llegar al fondo, aquí hay pruebas UDP de dos hosts en la misma VLAN que aún usan la Conexión Metro, 200 = remota, 201 = DC

Vemos que la pérdida de paquetes aumenta a medida que aumenta el ancho de banda (cuando nos acercamos a 10Mbps tenemos 0,93%, comienza a ser crítico ... y también explicaría por qué TCP tiene problemas de rendimiento)

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Servidor escuchando en el puerto UDP 5001
Recepción de datagramas de 1470 bytes
Tamaño del búfer UDP: 64.0 KByte (predeterminado)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Cliente que se conecta a 192.168.191.200, puerto UDP 5001
Envío de datagramas de 1470 bytes
Tamaño del búfer UDP: 64.0 KByte (predeterminado)
-------------------------------------------------- ----------
[4] puerto local 192.168.191.201 61759 conectado con el puerto 192.168.191.200 5001
[ID] Intervalo de transferencia de ancho de banda
[4] 0.0- 1.0 seg 128 KBytes 1.05 Mbits / seg
[4] 1.0- 2.0 seg 128 KBytes 1.05 Mbits / seg
[4] 2.0- 3.0 seg. 129 KBytes 1.06 Mbits / seg.
[4] 3.0- 4.0 seg 128 KBytes 1.05 Mbits / seg
[4] 4.0- 5.0 segundos 128 KBytes 1.05 Mbits / seg
[4] 5.0- 6.0 segundos 128 KBytes 1.05 Mbits / seg
[4] 6.0- 7.0 segundos 128 KBytes 1.05 Mbits / segundo
[4] 7.0- 8.0 segundos 128 KBytes 1.05 Mbits / segundo
[4] 8.0- 9.0 segundos 128 KBytes 1.05 Mbits / segundo
[4] 9.0-10.0 segundos 129 KBytes 1.06 Mbits / seg
[4] 10.0-11.0 segundos 128 KBytes 1.05 Mbits / segundo
[4] 11.0-12.0 segundos 128 KBytes 1.05 Mbits / segundo
[4] 12.0-13.0 segundos 128 KBytes 1.05 Mbits / seg
[4] 13.0-14.0 segundos 128 KBytes 1.05 Mbits / seg
[4] 14.0-15.0 segundos 128 KBytes 1.05 Mbits / seg
[4] 15.0-16.0 segundos 128 KBytes 1.05 Mbits / segundo
[4] 16.0-17.0 segundos 128 KBytes 1.05 Mbits / segundo
[4] 17.0-18.0 segundos 128 KBytes 1.05 Mbits / seg
[4] 18.0-19.0 segundos 131 KBytes 1.07 Mbits / segundo
[4] 19.0-20.0 segundos 128 KBytes 1.05 Mbits / seg
[4] 0.0-20.0 seg 2.50 MBytes 1.05 Mbits / seg
[4] Enviados 1785 datagramas
[4] Informe del servidor:
[4] 0.0-20.0 seg 2.50 MBytes 1.05 Mbits / seg 0.257 ms 0/1785 (0%)
[3] puerto local 192.168.191.201 5001 conectado con el puerto 192.168.191.200 50749
[3] 0.0- 1.0 seg 128 KBytes 1.05 Mbits / seg 0.285 ms 0/89 (0%)
[3] 1.0- 2.0 segundos 128 KBytes 1.05 Mbits / segundo 0.313 ms 0/89 (0%)
[3] 2.0- 3.0 segundos 128 KBytes 1.05 Mbits / segundo 0.278 ms 0/89 (0%)
[3] 3.0- 4.0 segundos 128 KBytes 1.05 Mbits / segundo 0.241 ms 0/89 (0%)
[3] 4.0- 5.0 segundos 128 KBytes 1.05 Mbits / segundo 0.266 ms 0/89 (0%)
[3] 5.0- 6.0 seg 128 KBytes 1.05 Mbits / seg 0.293 ms 0/89 (0%)
[3] 6.0- 7.0 seg 128 KBytes 1.05 Mbits / seg 0.314 ms 0/89 (0%)
[3] 7.0- 8.0 segundos 128 KBytes 1.05 Mbits / segundo 0.280 ms 0/89 (0%)
[3] 8.0- 9.0 segundos 128 KBytes 1.05 Mbits / segundo 0.242 ms 0/89 (0%)
[3] 9.0-10.0 segundos 129 KBytes 1.06 Mbits / segundo 0.250 ms 0/90 (0%)
[3] 10.0-11.0 segundos 128 KBytes 1.05 Mbits / segundo 0.275 ms 0/89 (0%)
[3] 11.0-12.0 segundos 128 KBytes 1.05 Mbits / segundo 0.299 ms 0/89 (0%)
[3] 12.0-13.0 segundos 128 KBytes 1.05 Mbits / seg 0.327 ms 0/89 (0%)
[3] 13.0-14.0 segundos 128 KBytes 1.05 Mbits / segundo 0.290 ms 0/89 (0%)
[3] 14.0-15.0 segundos 128 KBytes 1.05 Mbits / segundo 0.251 ms 0/89 (0%)
[3] 15.0-16.0 segundos 128 KBytes 1.05 Mbits / segundo 0.275 ms 0/89 (0%)
[3] 16.0-17.0 segundos 128 KBytes 1.05 Mbits / seg 0.303 ms 0/89 (0%)
[3] 17.0-18.0 segundos 128 KBytes 1.05 Mbits / seg 0.333 ms 0/89 (0%)
[3] 18.0-19.0 segundos 128 KBytes 1.05 Mbits / seg 0.294 ms 0/89 (0%)
[3] 19.0-20.0 segundos 131 KBytes 1.07 Mbits / segundo 0.281 ms 0/91 (0%)
[3] 0.0-20.0 seg 2.50 MBytes 1.05 Mbits / seg 0.305 ms 0/1785 (0%)

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 5m
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Servidor escuchando en el puerto UDP 5001
Recepción de datagramas de 1470 bytes
Tamaño del búfer UDP: 64.0 KByte (predeterminado)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Cliente que se conecta a 192.168.191.200, puerto UDP 5001
Envío de datagramas de 1470 bytes
Tamaño del búfer UDP: 64.0 KByte (predeterminado)
-------------------------------------------------- ----------
[4] puerto local 192.168.191.201 61760 conectado con el puerto 192.168.191.200 5001
[ID] Intervalo de transferencia de ancho de banda
[4] 0.0- 1.0 seg 610 KBytes 5.00 Mbits / seg
[4] 1.0- 2.0 segundos 609 KBytes 4.99 Mbits / seg
[4] 2.0- 3.0 seg 610 KBytes 5.00 Mbits / seg
[4] 3.0- 4.0 segundos 609 KBytes 4.99 Mbits / seg
[4] 4.0- 5.0 segundos 610 KBytes 5.00 Mbits / seg
[4] 5.0- 6.0 segundos 609 KBytes 4.99 Mbits / seg
[4] 6.0- 7.0 segundos 610 KBytes 5.00 Mbits / segundo
[4] 7.0- 8.0 segundos 609 KBytes 4.99 Mbits / seg
[4] 8.0- 9.0 segundos 610 KBytes 5.00 Mbits / segundo
[4] 9.0-10.0 segundos 619 KBytes 5.07 Mbits / segundo
[4] 10.0-11.0 segundos 610 KBytes 5.00 Mbits / segundo
[4] 11.0-12.0 segundos 609 KBytes 4.99 Mbits / seg
[4] 12.0-13.0 segundos 609 KBytes 4.99 Mbits / seg
[4] 13.0-14.0 segundos 610 KBytes 5.00 Mbits / segundo
[4] 14.0-15.0 segundos 609 KBytes 4.99 Mbits / seg
[4] 15.0-16.0 segundos 610 KBytes 5.00 Mbits / segundo
[4] 16.0-17.0 segundos 609 KBytes 4.99 Mbits / seg
[4] 17.0-18.0 seg. 610 KBytes 5.00 Mbits / seg.
[4] 18.0-19.0 seg. 619 KBytes 5.07 Mbits / seg.
[4] 19.0-20.0 segundos 609 KBytes 4.99 Mbits / seg
[4] 0.0-20.0 seg 11.9 MBytes 5.00 Mbits / seg
[4] Enviados 8504 datagramas
[4] Informe del servidor:
[4] 0.0-20.0 seg 11.9 MBytes 4.99 Mbits / seg 0.000 ms 12/8503 (0.14%)
[4] 0.0-20.0 sec 1 datagramas recibidos fuera de orden
[3] puerto local 192.168.191.201 5001 conectado con el puerto 192.168.191.200 50750
[3] 0.0- 1.0 sec 606 KBytes 4.96 Mbits / sec 2.238 ms 1/423 (0.24%)
[3] 1.0- 2.0 sec 610 KBytes 5.00 Mbits / sec 2.739 ms 0/425 (0%)
[3] 2.0- 3.0 sec 609 KBytes 4.99 Mbits / sec 3.089 ms 1/425 (0.24%)
[3] 3.0- 4.0 sec 609 KBytes 4.99 Mbits / sec 3.605 ms 0/424 (0%)
[3] 4.0- 5.0 segundos 607 KBytes 4.97 Mbits / seg 1.954 ms 0/423 (0%)
[3] 5.0- 6.0 segundos 612 KBytes 5.01 Mbits / segundo 2.666 ms 0/426 (0%)
[3] 6.0- 7.0 sec 607 KBytes 4.97 Mbits / sec 2.602 ms 0/423 (0%)
[3] 7.0- 8.0 seg 612 KBytes 5.01 Mbits / seg 2.960 ms 0/426 (0%)
[3] 8.0- 9.0 segundos 609 KBytes 4.99 Mbits / seg 2.512 ms 0/424 (0%)
[3] 9.0-10.0 sec 619 KBytes 5.07 Mbits / sec 2.133 ms 0/431 (0%)
[3] 10.0-11.0 segundos 609 KBytes 4.99 Mbits / seg 3.605 ms 1/425 (0.24%)
[3] 11.0-12.0 segundos 609 KBytes 4.99 Mbits / seg 2.509 ms 0/424 (0%)
[3] 12.0-13.0 segundos 610 KBytes 5.00 Mbits / segundo 3.570 ms 0/425 (0%)
[3] 13.0-14.0 segundos 609 KBytes 4.99 Mbits / seg 3.077 ms 1/425 (0.24%)
[3] 14.0-15.0 segundos 609 KBytes 4.99 Mbits / seg 2.679 ms 0/424 (0%)
[3] 15.0-16.0 segundos 609 KBytes 4.99 Mbits / seg 1.887 ms 0/424 (0%)
[3] 16.0-17.0 sec 610 KBytes 5.00 Mbits / sec 2.651 ms 0/425 (0%)
[3] 17.0-18.0 segundos 609 KBytes 4.99 Mbits / segundo 3.390 ms 0/424 (0%)
[3] 18.0-19.0 segundos 617 KBytes 5.06 Mbits / segundo 2.601 ms 0/430 (0%)
[3] 19.0-20.0 segundos 612 KBytes 5.01 Mbits / seg 3.525 ms 0/426 (0%)
[3] 0.0-20.0 seg 11.9 MBytes 4.99 Mbits / seg 3.156 ms 3/8503 (0.035%)
[3] 0.0-20.0 sec 1 datagramas recibidos fuera de orden

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9m
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Servidor escuchando en el puerto UDP 5001
Recepción de datagramas de 1470 bytes
Tamaño del búfer UDP: 64.0 KByte (predeterminado)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Cliente que se conecta a 192.168.191.200, puerto UDP 5001
Envío de datagramas de 1470 bytes
Tamaño del búfer UDP: 64.0 KByte (predeterminado)
-------------------------------------------------- ----------
[4] puerto local 192.168.191.201 61761 conectado con el puerto 192.168.191.200 5001
[ID] Intervalo de transferencia de ancho de banda
[4] 0.0- 1.0 seg 1.07 MBytes 9.00 Mbits / seg
[4] 1.0- 2.0 seg 1.07 MBytes 8.98 Mbits / seg
[4] 2.0- 3.0 seg 1.07 MBytes 9.00 Mbits / seg
[4] 3.0- 4.0 seg 1.07 MBytes 8.98 Mbits / seg
[4] 4.0- 5.0 seg 1.07 MBytes 9.00 Mbits / seg
[4] 5.0- 6.0 seg 1.07 MBytes 8.98 Mbits / seg
[4] 6.0- 7.0 seg 1.07 MBytes 8.98 Mbits / seg
[4] 7.0- 8.0 seg 1.07 MBytes 9.00 Mbits / seg
[4] 8.0- 9.0 seg 1.07 MBytes 8.98 Mbits / seg
[4] 9.0-10.0 seg 1.09 MBytes 9.14 Mbits / seg
[4] 10.0-11.0 seg 1.07 MBytes 9.00 Mbits / seg
[4] 11.0-12.0 segundos 1.07 MBytes 8.98 Mbits / seg
[4] 12.0-13.0 seg 1.07 MBytes 8.98 Mbits / seg
[4] 13.0-14.0 seg 1.07 MBytes 9.00 Mbits / seg
[4] 14.0-15.0 seg 1.07 MBytes 8.98 Mbits / seg
[4] 15.0-16.0 seg 1.07 MBytes 9.00 Mbits / seg
[4] 16.0-17.0 seg 1.07 MBytes 8.98 Mbits / seg
[4] 17.0-18.0 seg 1.07 MBytes 8.98 Mbits / seg
[4] 18.0-19.0 seg 1.09 MBytes 9.14 Mbits / seg
[4] 19.0-20.0 seg 1.07 MBytes 9.00 Mbits / seg
[4] 0.0-20.0 segundos 21.5 MBytes 9.00 Mbits / seg
[4] Enviaron 15315 datagramas
[4] Informe del servidor:
[4] 0.0-20.0 seg 21.3 MBytes 8.94 Mbits / seg 0.104 ms 96/15314 (0.63%) !!!!!!!!!!
[4] 0.0-20.0 sec 1 datagramas recibidos fuera de orden
[3] puerto local 192.168.191.201 5001 conectado con el puerto 192.168.191.200 50751
[3] 0.0- 1.0 seg 1.06 MBytes 8.89 Mbits / seg 2.405 ms 0/756 (0%)
[3] 1.0- 2.0 seg 1.07 MBytes 9.00 Mbits / seg 2.308 ms 0/765 (0%)
[3] 2.0- 3.0 seg 1.07 MBytes 9.00 Mbits / seg 2.305 ms 0/765 (0%)
[3] 3.0- 4.0 seg 1.07 MBytes 8.97 Mbits / seg 2.290 ms 1/764 (0.13%)
[3] 4.0- 5.0 sec 1.07 MBytes 8.98 Mbits / sec 2.271 ms 1/765 (0.13%)
[3] 5.0- 6.0 seg 1.07 MBytes 8.98 Mbits / seg 2.313 ms 0/764 (0%)
[3] 6.0- 7.0 seg 1.07 MBytes 9.00 Mbits / seg 2.191 ms 0/765 (0%)
[3] 7.0- 8.0 seg 1.07 MBytes 8.95 Mbits / seg 2.314 ms 3/764 (0.39%)
[3] 8.0- 9.0 seg 1.07 MBytes 8.98 Mbits / seg 2.232 ms 1/765 (0.13%)
[3] 9.0-10.0 seg 1.09 MBytes 9.13 Mbits / seg 2.257 ms 0/776 (0%)
[3] 10.0-11.0 seg 1.07 MBytes 8.98 Mbits / seg 2.365 ms 0/764 (0%)
[3] 11.0-12.0 seg 1.07 MBytes 8.98 Mbits / seg 2.301 ms 1/765 (0.13%)
[3] 12.0-13.0 seg 1.07 MBytes 8.98 Mbits / seg 2.277 ms 0/764 (0%)
[3] 13.0-14.0 seg 1.07 MBytes 9.00 Mbits / seg 2.323 ms 0/765 (0%)
[3] 14.0-15.0 seg 1.07 MBytes 9.00 Mbits / seg 2.176 ms 0/765 (0%)
[3] 15.0-16.0 seg 1.07 MBytes 8.96 Mbits / seg 2.273 ms 2/764 (0.26%)
[3] 16.0-17.0 seg 1.07 MBytes 8.98 Mbits / seg 2.313 ms 0/764 (0%)
[3] 17.0-18.0 seg 1.07 MBytes 8.98 Mbits / seg 2.247 ms 1/765 (0.13%)
[3] 18.0-19.0 seg 1.09 MBytes 9.11 Mbits / seg 2.276 ms 1/776 (0.13%)
[3] 19.0-20.0 seg 1.07 MBytes 8.97 Mbits / seg 2.394 ms 1/764 (0.13%)
[3] 0.0-20.0 seg 21.5 MBytes 8.99 Mbits / seg 2.659 ms 11/15314 (0.072%)
[3] 0.0-20.0 sec 1 datagramas recibidos fuera de orden

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9850k
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Servidor escuchando en el puerto UDP 5001
Recepción de datagramas de 1470 bytes
Tamaño del búfer UDP: 64.0 KByte (predeterminado)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Cliente que se conecta a 192.168.191.200, puerto UDP 5001
Envío de datagramas de 1470 bytes
Tamaño del búfer UDP: 64.0 KByte (predeterminado)
-------------------------------------------------- ----------
[4] puerto local 192.168.191.201 61762 conectado con el puerto 192.168.191.200 5001
[ID] Intervalo de transferencia de ancho de banda
[4] 0.0- 1.0 seg 1.17 MBytes 9.84 Mbits / seg
[4] 1.0- 2.0 seg 1.17 MBytes 9.84 Mbits / seg
[4] 2.0- 3.0 seg 1.17 MBytes 9.84 Mbits / seg
[4] 3.0- 4.0 seg 1.17 MBytes 9.84 Mbits / seg
[4] 4.0- 5.0 seg 1.17 MBytes 9.84 Mbits / seg
[4] 5.0- 6.0 seg 1.17 MBytes 9.83 Mbits / seg
[4] 6.0- 7.0 seg 1.17 MBytes 9.84 Mbits / seg
[4] 7.0- 8.0 seg 1.17 MBytes 9.84 Mbits / seg
[4] 8.0- 9.0 segundos 1.17 MBytes 9.84 Mbits / seg
[4] 9.0-10.0 seg 1.19 MBytes 10.0 Mbits / seg
[4] 10.0-11.0 seg 1.17 MBytes 9.84 Mbits / seg
[4] 11.0-12.0 segundos 1.17 MBytes 9.84 Mbits / seg
[4] 12.0-13.0 seg 1.17 MBytes 9.83 Mbits / seg
[4] 13.0-14.0 segundos 1.17 MBytes 9.85 Mbits / seg
[4] 14.0-15.0 seg 1.17 MBytes 9.83 Mbits / seg
[4] 15.0-16.0 seg 1.17 MBytes 9.85 Mbits / seg
[4] 16.0-17.0 seg 1.17 MBytes 9.83 Mbits / seg
[4] 17.0-18.0 seg 1.17 MBytes 9.84 Mbits / seg
[4] 18.0-19.0 seg 1.19 MBytes 10.0 Mbits / seg
[4] 19.0-20.0 seg 1.17 MBytes 9.84 Mbits / seg
[4] 0.0-20.0 seg 23.5 MBytes 9.85 Mbits / seg
[4] Enviaron 16765 datagramas.
[4] Informe del servidor:
[4] 0.0-20.0 seg 23.3 MBytes 9.74 Mbits / seg 3.421 ms 156/16764 (0.93%) !!!!!!!!!!
[4] 0.0-20.0 sec 1 datagramas recibidos fuera de orden
[3] puerto local 192.168.191.201 5001 conectado con el puerto 192.168.191.200 50752
[3] 0.0- 1.0 seg 1.16 MBytes 9.74 Mbits / seg 2.131 ms 0/828 (0%)
[3] 1.0- 2.0 seg 1.17 MBytes 9.84 Mbits / seg 2.140 ms 0/837 (0%)
[3] 2.0- 3.0 seg 1.17 MBytes 9.83 Mbits / seg 2.099 ms 1/837 (0.12%)
[3] 3.0- 4.0 seg 1.17 MBytes 9.84 Mbits / seg 2.113 ms 0/837 (0%)
[3] 4.0- 5.0 seg 1.17 MBytes 9.84 Mbits / seg 2.105 ms 0/837 (0%)
[3] 5.0- 6.0 seg 1.17 MBytes 9.83 Mbits / seg 2.058 ms 1/837 (0.12%)
[3] 6.0- 7.0 seg 1.17 MBytes 9.82 Mbits / seg 2.165 ms 1/836 (0.12%)
[3] 7.0- 8.0 seg 1.17 MBytes 9.84 Mbits / seg 2.156 ms 0/837 (0%)
[3] 8.0- 9.0 seg 1.17 MBytes 9.82 Mbits / seg 2.135 ms 2/837 (0.24%)
[3] 9.0-10.0 seg 1.19 MBytes 9.97 Mbits / seg 2.152 ms 2/850 (0.24%)
[3] 10.0-11.0 seg 1.17 MBytes 9.83 Mbits / seg 2.153 ms 1/837 (0.12%)
[3] 11.0-12.0 seg 1.17 MBytes 9.84 Mbits / seg 2.127 ms 0/837 (0%)
[3] 12.0-13.0 seg 1.17 MBytes 9.83 Mbits / seg 2.136 ms 1/837 (0.12%)
[3] 13.0-14.0 seg 1.17 MBytes 9.82 Mbits / seg 2.087 ms 2/837 (0.24%)
[3] 14.0-15.0 seg 1.17 MBytes 9.83 Mbits / seg 2.061 ms 1/837 (0.12%)
[3] 15.0-16.0 seg 1.17 MBytes 9.84 Mbits / seg 2.045 ms 0/837 (0%)
[3] 16.0-17.0 seg 1.17 MBytes 9.82 Mbits / seg 2.203 ms 1/836 (0.12%)
[3] 17.0-18.0 seg 1.17 MBytes 9.84 Mbits / seg 2.165 ms 0/837 (0%)
[3] 18.0-19.0 seg 1.17 MBytes 9.83 Mbits / seg 2.154 ms 1/837 (0.12%)
[3] 19.0-20.0 seg 1.19 MBytes 9.98 Mbits / seg 2.209 ms 0/849 (0%)
[3] 0.0-20.0 seg 23.5 MBytes 9.84 Mbits / seg 2.548 ms 13/16764 (0.078%)
[3] 0.0-20.0 sec 1 datagramas recibidos fuera de orden

La verdadera pregunta sigue siendo:

No estamos suscribiendo en exceso el enlace DC ya que está a 100Mbps y no puede enviar más de 100Mbps. Sin embargo, los sitios remotos están a 10 Mbps.

  • ¿Las memorias intermedias en el lado remoto están desbordando y soltando paquetes?
  • ¿El modelador de tráfico del proveedor está haciendo algo al tráfico? (¿El tráfico proveniente de otro nodo estaría influenciado por el modelador de tráfico de los ISP o solo el tráfico que ingresa al nodo (desde afuera)) ...... ¿Ves lo que quiero decir?

¿Por qué TCP no puede manejar todo eso por sí solo?

Actualización n. ° 3 Ahora he usado el siguiente escenario:

Laptop ------- ... LAN ... --- DC switch --- Metro-Eth --- Laptop (directly connected)
NIC@10Mbps                       100Mbps                  NIC@10Mbps

Aquí está la pérdida de paquetes en la dirección DC-> remota: (prueba UDP iperf 9 Mbps)

[  3] local 192.168.191.200 port 5001 connected with 192.168.191.201 port 55236
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec   912 KBytes  7.47 Mbits/sec   2.713 ms    0/  635 (0%)
[  3]  1.0- 2.0 sec  1001 KBytes  8.20 Mbits/sec   2.168 ms    0/  697 (0%)
[  3]  2.0- 3.0 sec  1001 KBytes  8.20 Mbits/sec   2.478 ms    0/  697 (0%)
[  3]  3.0- 4.0 sec   999 KBytes  8.18 Mbits/sec   0.933 ms    0/  696 (0%)
[  3]  4.0- 5.0 sec  1001 KBytes  8.20 Mbits/sec   2.620 ms    0/  697 (0%)
[  3]  5.0- 6.0 sec  1001 KBytes  8.20 Mbits/sec   2.721 ms    0/  697 (0%)
[  3]  6.0- 7.0 sec  1001 KBytes  8.20 Mbits/sec   2.089 ms    0/  697 (0%)
[  3]  7.0- 8.0 sec   999 KBytes  8.18 Mbits/sec   2.641 ms    0/  696 (0%)
[  3]  8.0- 9.0 sec  1002 KBytes  8.21 Mbits/sec   0.896 ms    0/  698 (0%)
[  3]  9.0-10.0 sec  1015 KBytes  8.31 Mbits/sec   2.557 ms    0/  707 (0%)
[  3] 10.0-11.0 sec   999 KBytes  8.18 Mbits/sec   2.822 ms    1/  697 (0.14%)
[  3] 11.0-12.0 sec   999 KBytes  8.18 Mbits/sec   1.551 ms    1/  697 (0.14%)
[  3] 12.0-13.0 sec   998 KBytes  8.17 Mbits/sec   2.504 ms    2/  697 (0.29%)
[  3] 13.0-14.0 sec   995 KBytes  8.15 Mbits/sec   2.038 ms    3/  696 (0.43%)
[  3] 14.0-15.0 sec   991 KBytes  8.11 Mbits/sec   2.539 ms    7/  697 (1%)
[  3] 15.0-16.0 sec   992 KBytes  8.13 Mbits/sec   2.759 ms    6/  697 (0.86%)
[  3] 16.0-17.0 sec   998 KBytes  8.17 Mbits/sec   2.229 ms    2/  697 (0.29%)
[  3] 17.0-18.0 sec   993 KBytes  8.14 Mbits/sec   2.723 ms    4/  696 (0.57%)
[  3] 18.0-19.0 sec   998 KBytes  8.17 Mbits/sec   2.038 ms    2/  697 (0.29%)
[  3] 19.0-20.0 sec  1012 KBytes  8.29 Mbits/sec   2.575 ms    3/  708 (0.42%)
[  3]  0.0-20.0 sec  19.5 MBytes  8.15 Mbits/sec   2.775 ms   31/13917 (0.22%)
[  3]  0.0-20.0 sec  1 datagrams received out-of-order

La otra dirección está bien. Sin embargo , cuando se ejecuta una prueba TCP, la dirección remota-> CC no funciona mucho mejor que la dirección remota DC-> (aproximadamente 5 Mbps) .......

No estoy seguro de haber llegado al fondo de esto.

ethernet tcp troubleshooting packet-analysis metro-ethernet Marki
fuente
Realmente no es una respuesta, pero mi recomendación sería obtener un JDSU y probar este circuito. Si lo están vigilando, asegúrese de obtener la configuración del regulador, "regulador" ... Si tienen un CBS pequeño, entonces están limitando su tráfico TCP a un tamaño de ventana esencialmente más pequeño. Puede probar esto a través de una prueba de back-2-back. He pasado mucho tiempo yendo y viniendo con los proveedores en los circuitos L2 para saber que cuando recibamos una nueva prueba de circuito, no solo en el CIR sino en el CBS ...
matak
Además, solo una nota al margen rápida. El rendimiento de TCP que se ve desde un sistema operativo Windows vs Linux será diferente porque la configuración de TCP será diferente; es decir. tamaño del búfer, algoritmo, etc. Puede ver la configuración de su máquina Linux si sysctlno está seguro acerca de Windows ... tal vez netsh. Si tuviera que adivinar qué está mal con su circuito, diría que el CPE en el sitio de radios está configurado con un CBS más grande que el lado del concentrador ... que generalmente es al revés. Nuevamente, el JDSU les devolverá el balón o les permitirá volver a centrarse en cuál es el problema.
matak
@matak ¿Por qué no hacer una respuesta adicional de sus comentarios? Cuando hablamos del moldeador, ¿dónde imagino este dispositivo? En la CC hay un enchufe RJ45 sin CPE (visible). En los sitios remotos, principalmente tengo un módem VDSL y algún tipo de enrutador compatible con MPLS. Sin embargo, no estoy seguro si usan MPLS. Y además, ¿en qué dirección del tráfico se forma el moldeador? Podemos dar forma a ingress @ radios (desde el sitio), egress @ radios (hacia la nube del ISP), ingress @ hub (desde DC), egress @ hub (hacia la nube del ISP) ... Probablemente me estoy perdiendo el panorama general. ¿Puedes ilustrar por qué el problema con la CBS sería un problema?
Marki

Respuestas:

20

Referencia a nuestro chat de Stack Exchange ...

En pocas palabras, debe controlar los desajustes de velocidad en ambos lados de sus enlaces Ethernet de metro ... Redibujé su diagrama en aras de la claridad ... Nota 1

Diagrama de problemas

  • Las transiciones de CC (que se muestran en verde) de 10GE a 100M muy rápidamente ... esta es una transición de velocidad de 100 veces, y normalmente necesita implementar alguna forma de qos (como la configuración) para mitigar una transición tan grande. Consulte la parte inferior de esta respuesta para obtener evidencia de que el DC necesita formarse (por sitio) ...
  • El lado remoto pasa de 1GE a 10M CIR de muy rápidamente ... esto nuevamente, es una transición de 100 veces la velocidad. Por lo general, se requieren formas u otras soluciones de calidad de servicio.
  • También parece haber un desajuste de velocidad entre el DC UNI (100M) y el UNI remoto (10M); esto en sí mismo pide una solución de administración de ancho de banda por sitio.

Para su información, si su proveedor implementa servicios compatibles con MEF , no están formando, están vigilando . El tráfico TCP tiende a funcionar mejor con la configuración .

La necesidad de tu propia QoS

Pareces cuestionar la necesidad de qos , así que citaré de la técnico "Comprensión del rendimiento de la portadora Ethernet" MEF , página 9 ... a modo de revisión, el cliente en la Figura 2 del documento técnico de MEF tiene una mejor situación que usted. .. compraron un CIR de 50Mbps, pero su UNI se entrega en un 1GE ... su sitio remoto tiene un CIR de 10Mbps en un 1GE UNI.

The transition from legacy services such as T1, T3, Frame Relay and ATM
to Carrier Ethernet has created some unintended consequences. Not all customers have 
conforming equipment facing the network which properly limits/shapes the traffic outbound
to the network, with deleterious results.  For instance, on the 1 GigE interface of
Figure 2, if the customer’s equipment accidentally transmits long bursts of data at 
150 Mbits instead of the SLA’s Committed Information Rate of 50 Mbits, 67% of the data 
may be lost and network breakdown will likely result.

Responder a otras preguntas de TCP en una edición ...

No estamos suscribiendo en exceso el enlace DC ya que está a 100Mbps y no puede enviar más de 100Mbps ...

No estoy de acuerdo, puede enviar microburst s a 10GE porque su DC tiene enlaces 10GE, pero el metro UNI es de 100Mbps. Una pregunta abierta es la cantidad de almacenamiento en búfer que tiene en su conmutador LAN Enterasys (conmutador A) cuando realiza la transición de 10GE a 100M.

¿Por qué TCP no puede manejar todo eso por sí solo?

TCP maneja las cosas disminuyendo la velocidad cuando ve una pérdida de paquetes ... realmente se ralentiza (y puede abortar la conexión) por una pérdida grave de paquetes. Entonces, TCP está haciendo lo que debería ... como ingeniero de redes, su objetivo es construir una red con condiciones que hagan feliz a TCP.

Otras preguntas TCP del chat

Dijo Marki : No entiendo lo que se está dejando caer, dónde y por quién y por qué y por qué TCP no solo maneja el hecho de que hay 100Mb (reales) en un extremo y solo 10Mbps en el otro.

Con respecto a la necesidad de TCP de almacenamiento en búfer, y las consecuencias de la ausencia de búferes :

Hecho número 1: TCP necesita almacenamiento en búfer para las transiciones de velocidad porque está diseñado como un sistema de control de retroalimentación .

Usando una analogía de conducción: como buenos conductores, siempre dejamos unos segundos de espacio entre nosotros y el automóvil que tenemos delante; de alguna manera, ese espacio entre automóviles es más o menos análogo a un búfer de red. Si la persona frente a nosotros pisa los frenos cuando un animal corre delante de ellos, el espacio entre nuestros autos (con suerte) nos impide golpearlos. Dejamos espacio porque nuestros ojos tardan en ver las luces de freno, nuestro pie para reaccionar y los frenos para disipar suficiente calor; nuestros ojos nos dan un sistema de control visual de retroalimentación.

Del mismo modo, cuando una sesión FTP se elimina a 10GE, las ráfagas de tráfico pueden tener hasta 4 MB de longitud (en su caso) debido al tamaño de ventana escalado de TCP antes de que el socket deba detenerse y esperar un TCP ACK. Mientras tanto, si el flujo de tráfico 10GE golpea repentinamente un "Fast Ethernet", el TCP debe disminuir gradualmente. Los amortiguadores profundos en el equipo de red permiten que TCP descarte muchos menos paquetes cuando realiza transiciones de velocidad; sin embargo, si no tiene búferes, podría perder quizás el 99% de esa ventana TCP de 4 MB cuando se limita de 10GE a 100M. Piense en esa severa pérdida del 99% como un bloqueo del socket TCP; TCP reacciona previsiblemente a la pérdida de paquetes relativamente gradual. TCP reacciona de forma mucho menos previsible a la pérdida de paquetes grave y continua Nota 3 .

A la pregunta de por qué no debe usar un CIR Ethernet Metro asimétrico con 100M en la CC y 10M en el control remoto, hágase una pregunta retórica "quién está almacenando esa ráfaga de tráfico de 100Mbps cuando llega a la Ethernet barata de 10Mbps NID que su metro -ethernet proveedor le dio? "... (pista: nadie está almacenando en el búfer).

Si nadie está amortiguando las grandes transiciones de velocidad (ver Nota 2), esos puntos son lugares potenciales para dejar caer el tráfico de forma intermitente.

Lo que está dejando caer quién :

El tráfico de egreso cae del DC

Cuando el tráfico TCP abandona el centro de datos, hay tres lugares en los que podría descartarse:

  • En D1: porque los conmutadores LAN rara vez tienen almacenamiento en búfer lo suficientemente profundo para una transición de velocidad de 100: 1
  • En D2: si el NID alguna vez negoció el enlace UNI a una velocidad mayor que el CIR ; ese no es el caso en este momento, así que no espero caídas allí.
  • En D3: por todas las razones que acabo de describir sobre los CIR asimétricos de Metro Ethernet .

Cuando el tráfico TCP va al centro de datos ...

El tráfico de entrada cae al DC

  • En D4: porque tiene un 1GE UNI y un 10M CIR ; Este es el caso patológico de D2 que mencioné anteriormente.

Cómo mitigar los desajustes de velocidad:

Un ejemplo de solución EVPL : EVPL con solución de EVC punto a punto

  • En una topología conmutada como esta, un EVPL con EVC punto a punto desde el DC a cada control remoto es probablemente su mejor opción (consulte el diagrama anterior). Esto aplicaría un CIR individual a cada EVC. Nota: toda la otra guía de QoS en esta respuesta se aplica ... es decir, evitar transiciones de alta velocidad. Nota 2 sin probar si su equipo lo manejará lo suficientemente bien.
  • Alternativamente, podría considerar comprar servicios de metro que tengan tarifas simétricas entre el DC y el control remoto; aunque admitiría que podría no ser la guía más práctica.
  • Para su información, la solución clásica a este problema para los servicios enrutados es comprar enrutadores que admitan la configuración a las velocidades requeridas y luego dar forma a su tráfico de metro al CIR apropiado (por sitio remoto). Para su información, el lado remoto podría salirse con la suya con un enrutador razonablemente pequeño, ya que es solo una entrada 1GE y un CIR de 10Mbps ... Hace meses, cuando hablamos sobre el diseño de este servicio, le recomendé el enrutamiento si estaba cómodo con las tecnologías. ...

  • Si no tiene dinero extra para gastar y no puede rediseñar su servicio de metro-ethernet, podría resolver los desajustes de velocidad más gradualmente. Nunca he hecho esto, pero en principio podrías intentar hacer las transiciones de velocidad de 10 a 1, en lugar de 100 a 1 (que es lo que tienes actualmente tanto en DC como en remoto):

    • En lugar de comprar un enrutador para dar forma al control remoto a 10M, podría intentar forzar a la UNI remota a negociar automáticamente a 100M en lugar de 1GE; GigabitEthernet requiere todos los pines en un cable Cat5e , por lo que podría forzarlo efectivamente a 100M con un enchufe mod RJ45 que simplemente conecta los pines 1, 2, 3 y 6.
    • En lugar de comprar un enrutador para dar forma a DC a 100M, use su Enterasys para vigilar el enlace 10GE a 1GE cuando envíe tráfico hacia el enlace 100M

Analizando sus iperfresultados ...

Hay dos puntos clave para recordar iperf(toda la información basada en la iperfversión 2):

Como tal, la siguiente salida muestra que la máquina de CC (en iperf -cmodo) se conecta al iperfservidor en el sitio remoto (192.168.x) y envía datos desde la CC (100M UNI) al sitio remoto (10M UNI) ...

./iperf -c 192.168.x -i2 -t 60 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.x, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.x port 38195 connected with 192.168.x port 5001
[  3]  0.0- 2.0 sec  1.44 MBytes  6.03 Mbits/sec
[  3]  2.0- 4.0 sec  2.23 MBytes  9.37 Mbits/sec
[  3]  4.0- 6.0 sec  2.28 MBytes  9.57 Mbits/sec
[  3]  6.0- 8.0 sec  1.88 MBytes  7.90 Mbits/sec
[  3]  8.0-10.0 sec  1.00 MBytes  4.19 Mbits/sec
[  3] 10.0-12.0 sec  1.30 MBytes  5.47 Mbits/sec
[  3] 12.0-14.0 sec    688 KBytes  2.82 Mbits/sec

La salida anterior muestra claramente problemas en la dirección DC a remota; deberíamos esperar ver 9Mbps o más cuando las cosas funcionan bien (es decir, espera al menos el 90% de la capacidad, 10Mbps en el sitio remoto). Ahora, veamos el tráfico en la dirección opuesta (cuando iperfenvía datos desde el sitio remoto al DC) ...

[  5] local 10.x port 5001 connected with 192.168.x port 10965
[  5]  0.0- 2.0 sec  1.85 MBytes  7.75 Mbits/sec
[  5]  2.0- 4.0 sec  1.90 MBytes  7.98 Mbits/sec
[  5]  4.0- 6.0 sec  1.89 MBytes  7.93 Mbits/sec
[  5]  6.0- 8.0 sec  1.92 MBytes  8.07 Mbits/sec
[  5]  8.0-10.0 sec  1.91 MBytes  8.02 Mbits/sec
[  5] 10.0-12.0 sec  1.83 MBytes  7.69 Mbits/sec
[  5] 12.0-14.0 sec  1.86 MBytes  7.78 Mbits/sec

Puede enviar alrededor del 80% de la capacidad de su CIR remoto, pero aún así es menos de lo que esperaba.

Ilustración de la falta de coincidencia de velocidad de CC (10 Gbps -> 100 Mbps)

marki dijo : No lo olvides, el problema solo se muestra cuando el flujo es de 100Mb-> 10Mb, no al revés.

El problema se muestra en ambas direcciones, pero los iperfsíntomas parecen empeorar en DC -> dirección remota. Vea mi análisis de la iperfsalida anterior.

Para hacer esto concreto, echemos un vistazo a su pcap FTP cuando empuje un archivo desde su servidor FTP DC (130.1.6.4) al sitio remoto (192.168.191.2). La transferencia desde el lado de Ethernet de 100M metro se limita en varios puntos durante la transferencia. Puede ver esto si mira el dc-to-remote_remote-side.pcapngpcap y filtra enexpert.message contains "segment not captured"

ingrese la descripción de la imagen aquí

Notas finales :

Nota 1 Elijo valores CBS de 25 KB por 1Mbps MetroEthernet CIR; esta es una proporción común utilizada por los proveedores ... YMMV
Nota 2 Mi regla personal: "grande" es una transición de velocidad que es significativamente mayor que una transición de velocidad 10: 1
Nota 3No puedo dar números concretos de lo que es y no es demasiada pérdida de paquetes para TCP. Si la pérdida es lo suficientemente grave como para que sus aplicaciones sufran, entonces es demasiado. Mi regla personal: cuando trato con una red corporativa cableada completamente bajo mi propio control, cualquier pérdida de paquetes (no intencional) es demasiado. Dicho esto, hay algunos modelos de interruptores que reducen las esquinas en el almacenamiento en búfer; estos conmutadores pueden ocasionalmente descartar paquetes ... es una decisión de juicio si tiene que vivir con el problema o comprar mejores conmutadores. FYI: No siempre es obvio, pero TCP aumenta periódicamente la velocidad de transmisión de un socket para garantizar que obtenga el mayor rendimiento posible; muchas implementaciones de TCP saben que van demasiado rápido cuando ven caídas de paquetes.

Mike Pennington
fuente
Tenga en cuenta que la velocidad PHY de DC (puerto Ethernet Metro) ya está en 100Mb. Pero tampoco puedo enviar a 100M porque el otro lado tiene un máximo de 10Mb ... En este momento todavía no me queda claro dónde debe tener lugar exactamente la configuración. Ah, ¿y quisiste decir "los síntomas de iperf parecen empeorar en DC -> dirección remota "?
Marki
Actualicé la respuesta, sí "remoto -> DC" fue un error tipográfico en la respuesta original.
Mike Pennington
Estoy de acuerdo con Mike aquí, dependiendo de quién sea su proveedor, si les pregunta si le dirán la tarifa de línea, haga que coincidan con sus interfaces físicas que cuelgan de su metro-E. En cuanto a DONDE a QoS, lo haría en sus puntos de entrada más grandes, por lo que sus dispositivos de 10 Gb, antes de que suban a los dispositivos aguas arriba más pequeños. Sin embargo, paso más tiempo cortafuegos y enrutamiento que cambiar, ¡pero espero que Mike pueda corroborar mis afirmaciones!
AL
3
@MikePennington: el bloqueo de egreso debido a desajustes de velocidad es algo con lo que me encuentro mucho con los enlaces de microondas P2P. Gran respuesta, mucha buena información en tu publicación. ¡Gracias!
matak
1
También verifique la falta de coincidencia dúplex, esto puede causar problemas de velocidad unidireccional.
cpt_fink
2

Si bien discutir este problema fue muy interesante, el ISP, mientras tanto, comenzó a intercambiar los módems DSL en los diferentes sitios por otra marca. Algunos problemas de fragmentación de paquetes dicen. Y bueno, 9.5 Mbps en ambas direcciones sin ningún problema o configuración especial.

Marki
fuente