No hay respuesta a algunos paquetes SYN cuando las marcas de tiempo están habilitadas

Tengo un servidor TCP que escucha en una máquina ("el servidor") que ejecuta Ubuntu 12.04.3 (kernel 3.8.0-31-generic). Recibe conexiones de 2 máquinas cliente diferentes. La máquina A ejecuta Ubuntu 12.04.4 (3.11.0-17-generic) y la máquina B ejecuta Ubuntu 11.10 (3.0.0-32-server).

Si las marcas de tiempo TCP están habilitadas en el servidor (sysctl net.ipv4.tcp_timestamps = 1), a veces los paquetes SYN de la máquina A se "ignoran". Usando tcpdump en el servidor (en modo no promiscuo) puedo ver que los SYN llegan bien y con las sumas de verificación correctas, simplemente no hay respuesta, no hay SYN / ACK y no RST. La máquina A retransmite el SYN varias veces antes de darse por vencido. El software del cliente que se ejecuta en la máquina A (wget en este caso) vuelve a intentarlo inmediatamente con una nueva conexión y tiene éxito, obteniendo un SYN / ACK instantáneo.

La máquina B no tiene problemas con el mismo servidor y su tráfico parece normal: también está utilizando las mismas opciones de TCP que la máquina A (por lo que veo en los archivos de captura). Deshabilitar las marcas de tiempo TCP en el servidor hace que todo funcione como debería.

Sin embargo, las marcas de tiempo en los paquetes SYN ignorados parecen ser válidas para mí, así que no estoy seguro de por qué están causando problemas o si son la causa subyacente en absoluto.

He puesto un pcap anonimizado aquí https://www.dropbox.com/s/onimdkbyx9lim70/server-machineA.pcap . Se tomó en el servidor (10.76.0.74) mostrando la máquina A (10.4.0.76) realizando con éxito un HTTP GET (paquetes 1 a 10) y luego 1 segundo más tarde tratando de recuperar la misma URL (paquetes 11 a 17) pero en su lugar tiene sus SYN ignorados. Los paquetes del 18 al 27 son otro éxito.

Sospecho que este es un problema similar al descrito en " ¿Por qué un servidor no enviaría un paquete SYN / ACK en respuesta a un paquete SYN? " Y aunque deshabilitar las marcas de tiempo es una solución alternativa, me gustaría entender lo que está sucediendo. ¿Es esto solo un error?

No hay firewall local en ejecución. El servidor maneja bastantes conexiones TCP (aproximadamente 32K en cualquier momento) pero tiene mucha memoria / CPU libre. En el momento de la prueba que se muestra en el pcap, no había otras conexiones TCP entre la máquina A y el servidor. No hay señales de que la cola de aceptación de la aplicación del servidor se esté llenando repentinamente (además, eso debería afectar a ambos clientes, supongo). Como los paquetes se ven bien en un pcap tomado en el servidor, no parece que un dispositivo de red interviniente esté rompiendo cosas.

Originalmente publiqué esto en los foros de ubuntu, pero en retrospectiva, esta puede ser una ubicación más apropiada. Esperando el préstamo de una pista.

En mi caso, el siguiente comando solucionó el problema con la falta de respuestas SYN / ACK del servidor Linux:

sysctl -w net.ipv4.tcp_tw_recycle=0

Creo que es más correcto que deshabilitar las marcas de tiempo TCP, ya que las marcas de tiempo TCP son útiles después de todo (PAWS, escalado de ventanas, etc.).

La documentación tcp_tw_recycleindica explícitamente que no se recomienda habilitarlo, ya que muchos enrutadores NAT conservan las marcas de tiempo y, por lo tanto, se activa PAWS , ya que las marcas de tiempo de la misma IP no son consistentes.

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.