6 votos

Rechazos de la misteriosa "fragmentación necesaria" de gateway VM

He sido la solución de un grave WAN tema de la velocidad. Me fijo, pero para el beneficio de los demás:

A través de WireShark, el registro y la simplificación de la configuración del yo se redujo a algún extraño comportamiento de una puerta de enlace a hacer DNAT a los servidores de la red interna. La puerta de enlace (CentOS) y los servidores se ejecutan en el mismo VMware ESXi 5 host (y esto resulta ser significativo).

Esta es la secuencia de eventos que ha ocurrido - de manera bastante - cuando me intento descargar un archivo desde un servidor HTTP detrás de la DNAT, el uso de un cliente de prueba conectado directamente a la red WAN lado de la puerta de enlace (sin utilizar la conexión de Internet que normalmente se usa aquí):

  1. La costumbre de establecimiento de conexión TCP (SYN, SYN, ACK, ACK) procede con normalidad; la puerta de entrada vuelve a asignar la IP del servidor correctamente en ambos sentidos.

  2. El cliente envía un único segmento TCP con el GET de HTTP y esto también es DNATted correctamente en el servidor de destino.

  3. El servidor envía una 1460 bytes del segmento TCP con la respuesta 200 y parte del archivo, a través de la puerta de enlace. El tamaño de la trama en el cable es de 1514 bytes - 1500 en la carga útil. Este segmento debe cruzar la puerta de entrada, pero no.

  4. El servidor envía una segunda 1460 bytes del segmento TCP, continuando el archivo, a través de la puerta de enlace. De nuevo, el enlace de la carga útil es de 1500 bytes. Este segmento no cruza la puerta y nunca se representaron.

  5. La puerta de enlace envía un ICMP de Tipo 3 Código 4 (destino inalcanzable fragmentación necesaria) paquete de vuelta al servidor, citando el paquete enviado en 3 de Evento. El paquete ICMP indica el siguiente MTU de 1500. Este parece ser un contrasentido, ya que la red es de 1500 bytes limpio y el enlace de cargas útiles en 3 y 4 ya estaban dentro de la indicada 1500 bytes de límite. El servidor es comprensible ignora esta respuesta. (Originalmente, ICMP había caído por un exceso de celo firewall, pero esto se ha solucionado.)

  6. Después de un retraso considerable (y en algunas configuraciones, Ack duplicados desde el servidor), el servidor decide volver a enviar el segmento de 3 de Evento, esta vez solo. Aparte de la identificación de IP de campo y de la suma, la trama es idéntica a la de 3 de Evento. Son de la misma longitud y la nueva todavía tiene el no Fragmentar indicador establecido. Sin embargo, esta vez, la puerta de entrada pasa el segmento en el cliente en una sola pieza - en lugar de enviar un ICMP rechazar.

  7. El cliente Ack este, y la transferencia continúa, aunque muy lentamente, ya que los segmentos siguientes que ir a través de aproximadamente el mismo patrón de ser rechazado, el tiempo de espera, se resienten y, a continuación, pasar a través de.

El cliente y el servidor de trabajar juntos, normalmente, si el cliente se mueve a la LAN, así como para acceder al servidor directamente.

Este extraño comportamiento varía de forma impredecible basado en aparentemente irrelevantes detalles del servidor de destino.

Por ejemplo, en el Servidor 2003 R2, el de 7 mb de un archivo de prueba se haría cargo de 7h a transmitir si el Firewall de Windows fue habilitado (incluso si es permitido HTTP y todo ICMP), mientras que la cuestión no aparece en absoluto, y, paradójicamente, el rechazo nunca sería enviada por la puerta de enlace, en primer lugar, si el Firewall de Windows se ha desactivado. Por otro lado, en el Servidor 2008 R2, deshabilitar el Firewall de Windows no tuvo ningún efecto en absoluto, pero la transferencia, mientras que todavía está siendo afectada, podría ocurrir mucho más rápido que en el Servidor 2003 R2 con el firewall activado. (Creo que esto es debido a 2008 R2 es el uso más inteligente de tiempo de espera de la heurística y TCP rápido de la retransmisión.)

Aún más extraño, el problema desaparecería si WireShark se han instalado en el servidor de destino. Como tal, para diagnosticar el problema he tenido que instalar WireShark por separado en una VM para ver el lado de la LAN de la red de tráfico (probablemente una mejor idea de todos modos por otras razones.)

El ESXi es la versión 5.0 de U2.

7voto

David Schwartz Puntos 22683

No puede dejar de ICMP fragmentación de los mensajes necesarios. Que son necesarios para pMTU discovery, que se requiere para TCP para que funcione correctamente. Por favor, LART el administrador del cortafuegos.

Por la norma de transparencia, un enrutador de filtrado de paquetes que actúa como un firewall que permite que los paquetes IP salientes con el "Don't Fragment" (DF) conjunto de bits NO DEBE bloquear la entrada de ICMP de Destino Inalcanzable / La necesidad de fragmentación de los errores que se envía en respuesta a los paquetes salientes de llegar a los hosts dentro del firewall, ya que esto rompería el cumple con las normas de uso de Path MTU discovery anfitriones de la generación de el tráfico legítimo. -- Requisitos del Firewall - RFC2979 (énfasis en el original)

Esta es una configuración que ha sido reconocido como fundamentalmente roto durante más de una década. ICMP no es opcional.

3voto

Kevin Puntos 538

Finalmente llegué a la parte inferior de esta. Resultó ser un problema con VMware para la implementación de la segmentación TCP descarga en la NIC virtual en el servidor de destino.

El servidor de la pila TCP/IP enviaría un gran bloque a lo largo de la NIC, con la expectativa de que la NIC se dividirla en segmentos TCP restringido a la MTU del enlace. Sin embargo, VMware decidido dejar esta en un gran segmento de hasta - bueno, no estoy seguro de cuando.

Parece que en realidad se quedó una gran segmento cuando alcanzó la puerta de enlace de VM de la pila TCP/IP, lo cual provocó el rechazo.

Una pista importante fue enterrado en la resultante de paquetes ICMP: la cabecera IP del paquete rechazado indica un tamaño de 2960 bytes - la forma más grande que el paquete parecía estar rechazando. Este es también exactamente el tamaño de un segmento TCP sería en el cable si se habían combinado los datos de ambos de los segmentos enviados hasta el momento.

Una cosa que hizo que el tema es muy difícil de diagnosticar, fue que los datos transmitidos en realidad se divide en 1500 bytes marcos tan lejos como WireShark se ejecuta en otra VM (conectados a la misma vSwitch en una independiente, promiscuo grupo de puertos) se podía ver. Realmente no estoy seguro de por qué la puerta de enlace VM vio un paquete, mientras que el WireShark VM vio a dos. FWIW, la puerta de enlace no tiene la descarga de recepción grande habilitado - yo podría entender si lo hizo. El WireShark VM está ejecutando Windows 7.

Creo que VMware lógica en el retraso de la segmentación es que si los datos es a través de una NIC física, la NIC real de descarga de hardware pueden ser aprovechados. Parece buggy, sin embargo, que fracasaría en el segmento antes de enviar a otra máquina virtual, y de forma incoherente, para esa materia. He visto este comportamiento se menciona en otra parte como VMware error.

La solución fue simplemente para apagar la segmentación TCP descarga en el servidor de destino. El procedimiento varía según el SO pero por lo que vale:

En Windows, en las propiedades de la conexión, el General ficha o pestaña funciones de Red, haga clic en "Configurar..." junto al adaptador, y mirar en la ficha Avanzadas. Para Server 2003 R2 es dado como "IPv4 TCP Descarga de la Segmentación." Para Server 2008 R2 es "la Descarga de Envío Grande (IPv4)."

Esta solución es un poco de un parche y posiblemente podría afectar el rendimiento en algunos ambientes, por lo que voy a aceptar cualquier respuesta mejor.

1voto

Rob Fisher Puntos 111

Tuve los mismos síntomas y el problema resultó para ser este error de kernel: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754294

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: