XenServer 6.5 – Intermitencia y perdida de paquetes

Hoy hablare un poco de un problema que tuve con uno de mis servidores con XenServer 6.5.

Soy relativamente nuevo en XenServer 6.5 por lo que poco a poco he ido aprendiendo como hacer distintas cosas, como hacer troubleshooting.

Hasta ahora no había tenido problemas, mas que con un parche que se instalo de manera incorrecta y la verdad por no poner una entrada en este blog, no recuerdo como lo solucioné. (Principios de Alzheimer).

Bien, todo comenzó cuando configure un VPS para rentar a un cliente, el cual requería buen throughput, I/O en disco y suficiente RAM, así que hice un VPS con 2 Cores, 8GB en RAM y 50GB en SSD.

Puse este servidor en una red Interna del XenServer y puse un firewall basado en IPFire (El cual ando probando y me ha gustado) para ser su gateway de seguridad (Estilo UTM).

Probé accesos, forwarding’s y todo en orden, buen I/O en disco, buen CPU y en la parte de red me quede un poco confundido, pero como últimamente había estado fallando mi Internet no le di importancia.

El problema fue cuando se empezó a hacer uso de este VPS y se requería una conexión estable y rápida, por lo que para mi sorpresa no fue así. El servidor mantenía una carga de 0 pero el acceso en ocasiones era LENTISIMO, por lo que recurrí al famosisimo PING y lo deje corriendo.

El comportamiento era extraño, no había relación si entraba en SSH o si había muchas/pocas conexiones entrantes, al final empezaba a perder paquetes sin un patrón definido.

Al principio pensé que podría ser IPFire y algún componente en el filtrado de paquetes, pero nada de eso era el problema.

En este mismo servidor XenServer tengo una pequeña PBX con FreePBX Distro que hace ya algún tiempo empecé a notar cortes en las llamadas y perdidas de paquetes en la VPN a mi oficina (http://torre.vortex.mx).

Al darle ping a mis dos maquinas virtuales VPS y PBX, ambas perdían paquetes la mismo tiempo y aquí la cuestión es que el PBX no esta detrás de un IPFire o en una red Interna, así que el problema era otro.

Decidí investigar más acerca de este tipo de problemas y encontré en varios Blog acerca de un “Tune” en la parte de Red deshabilitando el TCP Offloading, la mayoría hablaba de problemas con Guest Windows, pero encontré que había problemas en los Host con otras tarjetas. En si lo que hace el TCP Offloading es pasar el procesamiento de la pila TCP/IP al controlador de red o NIC.

Muchos hacen referencia a buscar los controladores correctos dependiendo de tu tarjeta y aplicarlos, pues bien, inicie primero depurando con tcpdump en el Host con el comando:

tcpdump -i eth0 -v -nn | grep incorrect

En lo que consiste este comando es el de buscar errores de checksum en la tarjeta de nuestro Host.

Si en el resultado vemos algo así:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
16:38:07.676943 IP (tos 0x0, ttl 64, id 60844, offset 0, flags [DF], proto TCP (6), length 60) xxx.xxx.xxx.xxx.46455 > yyy.yyy.yyy.yyy.80: S, cksum 0x4b8f (incorrect (-> 0x1f20), XXXXXXXXXX:YYYYYYYYYY(0) win 5840 <mss 1460,sackOK,timestamp 731623207 0,nop,wscale 4>
16:38:07.711402 IP (tos 0x0, ttl 64, id 28467, offset 0, flags [DF], proto TCP (6), length 52) xxx.xxx.xxx.xxx.41269 > yyy.yyy.yyy.yyy.80: ., cksum 0x6a18 (incorrect (-> 0xa1f1), 1:1(0) ack 773 win 552 <nop,nop,timestamp XXXXXXXX YYYYYYYY>

En mi caso, no dejaban de salir estos errores, entonces fue cuando decidí deshabilitar el TCP Offloading y probar.

Guarde primero una imagen de como estaba la configuración de mi NIC con ethtool, aspi que ejecute

ethtool -k eth0 > ethtool.eth0.config

En caso de que tuviera que hacer algún rollback, ver como estaba anteriormente.

Enseguida lo que hice fue ejecutar

ethtool -K eth0 rx off tx off sg off tso off ufo off gso off gro off lro off;

Claro que si se tienen más de una NIC se debe aplicar en todas:

for ETHADP in `ip addr | awk '/eth[0-9]/ {print $2}' | sed 's/://g'`
  do
    ethtool -K ${ETHADP} rx off tx off sg off tso off ufo off gso off gro off lro off
done

Al realizar estos pasos, logre que el servidor respondiera de manera rápida y los errores de checksum desaparecieron debido a esto, mi firewall IPFire trabajo muy bien y falta ver como me va con la telefonía.

Este error solo se presento en un servidor y son idénticos en hardware, conectados al mismo Switch, la única diferencia es que en el que paso el problema tiene todos los parches hasta la fecha (12 de Mayo de 2016), mientras que el otro servidor debido a que no he tenido una ventana de mantenimiento autorizada no he podido parchar el XenServer, así que puedo atribuir que alguna de estas actualizaciones cambio los parámetros de TCP Offloading haciendo que tuviera esta intermitencia a nivel de NIC.

Saludos

Referencias:

Leave a Reply

Your email address will not be published. Required fields are marked *