Microcortes, el Yeti, Hombres lobo y otros seres imaginarios

Hola a todos , vamos a tratar un tema que desde que trabajo en soporte en Microsoft siempre me ha llamado la atención ( esto es debido a que como los seres imaginarios que he puesto en el título, al ser desconocidos llaman poderosamente la atención , como cualquier tema esotérico )

El primer ser imaginario que vamos a tratar es el microcorte , como todo ser imaginario tiene una serie de características no muy definidas :

1º Nadie lo ha visto jamás , en 7 años de experiencia en el mundo del soporte ( dentro del grupo de plataformas y en las especialidad de NETWORKING ) nunca he resuelto un caso en el que un microcorte fuera el causante del problema.

2º Tiene un hábitat especial , vive dentro de los cables de red .

3º Son difíciles de cazar ( la causa de esto está en el punto 1 ) , para cazarlos necesitaríamos equipamiento especial , como por ejemplo : El fluke EtherScope II : https://www.flukenetworks.com/fnet/en-us/products/EtherScope+Series+II/

Ahora que conocemos un poco mas nuestro ser imaginario , pasemos a identificar el problema:

Muchas veces este empieza de esta manera , tenemos un problema con nuestro servidor , no podemos llegar a los shares , tenemos microcortes ó El cluster esta balanceando entre los nodos creemos que tenemos microcortes en nuestra red y por esto ocurre este problema.

La pregunta lógica desde un punto de vista de un cazador de mitos o ingeniero de soporte ,seria :

¿Porque creéis que son microcortes? ¿Que herramienta habéis utilizado para ver los mismos?

La respuesta a la segunda es : “ninguna” en el 98 % de las ocasiones , a la primera suele ser más variada:

50 % se desconecta la ( añadir lo que se desee , unidad , share , volumen , nodo )-

25 % hay resets en la red.

25 % hay retrasmisiones en la red.

Aquí normalmente , yo ya empiezo a enfadarme con el termino MICROCORTE , por que el problema no es otro que de terminología , es decir ante lo desconocido , lo llamo MICROCORTE ( al igual que cuando vamos por la nieve , vemos algo grande que se mueve a lo lejos ,,, que es : EL YETI ) .

También ocurre mucho con la lentitud de los equipos , suele darse esta situación .

Me va lento el equipo . -----------> tienes un virus.

Me va lenta la red . ----------------> tienes microcortes.

El microcorte como termino , se ha importado de la red eléctrica :

Un fenómeno particular de los "blackouts" son los micro-cortes de energía o micro-blockouts, estos, como la palabra lo indica son pequeñas desapariciones del suministro eléctrico o caídas a niveles bajísimos, la características principal es que son de cortísima duración, se los ubica en el orden de los mili-segundos (1 a 20). Son tan pequeños que a veces son inocuos e intrascendentes, dependiendo del tipo de carga que alimentan, pueden causar daños irreparables o fallas en el funcionamiento.

imagen de : https://www.alcion.es/DOWNLOAD/ArticulosPDF/en/08articulo.pdf

Así que siendo fieles a la definición microcorte debería ser un problema eléctrico , un problema en el transporte de energía , un problema físico . ( Physical layer en OSI ) .

Para poder detectar un problema real de microcortes deberíamos utilizar un analizador como el comentado en el punto 3 .

Para el resto de problemas de red , vamos a utilizar el NETMON3.2 https://www.microsoft.com/downloads/details.aspx?FamilyID=f4db40af-1e08-4a21-a26b-ec2f4dc4190d&DisplayLang=en

Por ahora no trataremos el problema en wireless , ya que el problema de los microcortes en este ámbito se transforma en interferencias ( en un futuro articulo se trataran como Hombres Lobos ).

si alguien quiere utilizar el Wireshark:  https://www.wireshark.org/ .también puede hacerlo los dos tienen ventajas e inconvenientes , pero eso queda para otra entrada en el blog :-).

Asi que como dice Laura Chappel : “The analyzer should be the first tool used against a problematic network, not the last.”

Hablemos entonces de los otros posibles causantes , RESETs y Retransmisiones:

1º RESETs :

La manera que tiene TCP de manejar las conexiones half-open y otras situaciones problemáticas es incluir una función especial de reset.

Un reset es un segmento TCP que se envía con el Flag RST a 1, hablando de forma general un reset se envía cuando ocurre algo inesperado por TCP.

Algunos de los causas generales de un reset son :

• La recepción de un segmento TCP de cualquier dispositivo con el cual no tenemos una sesión TCP iniciada ( cualquier otro que no sea un SYN para iniciar una sesión , se entiende ;-) ).
• La recepción de un segmento TCP con un numero de secuencia invalido o incorrecto.
• Recepción de un SYN en un puerto donde no hay ningún proceso escuchando ( listener ).

Si vemos reset que no corresponde con estos casos lo mejor es capturar trazas y junto con un NETSTAT – NAO verificar que proceso esta escuchando en ese puerto. ( esto netmon 3.2 lo trae incluido )

VS  

2º Retransmisiones:

TCP inicia un temporizador de retransmisión cuando cada segmento se entrega a IP. Si no se no se ha recibido un ACK para los datos de un segmento determinado antes de que caduque el temporizador, este es retransmitido. Para las nuevas solicitudes de conexión, el temporizador de retransmisión se inicia a 3 segundos, y la petición (SYN) es reenviada hasta el valor especificado en TcpMaxConnectRetransmissions ( 2 por defecto ).. En las conexiones existentes, el número de retransmisiones es controlado por el parámetro del Registro TcpMaxDataRetransmissions (5 por defecto). El tiempo de espera de retransmisión se ajusta sobre la marcha para que coincida con las características de la conexión.

Algunos parámetros para controlar el comportamiento de las Retransmisiones ( pudiendo mejorar o empeorar J ) :

TcpMaxConnectRetransmissions

Clave: Tcpip\Parameters
Tipo del valor: REG_DWORD (número)
Intervalo válido: 0 - 0xFFFFFFFF
Valor predeterminado: 2
Descripción: este parámetro determina el número de veces que TCP retransmite una solicitud de conexión (SYN) antes de cancelar el intento. El tiempo de espera de retransmisión se duplica con cada retransmisión sucesiva en un intento de conexión concreto. El valor de tiempo de espera inicial es de tres segundos.

TcpMaxDataRetransmissions

Clave: Tcpip\Parameters
Tipo del valor: REG_DWORD (número)
Intervalo válido: 0 - 0xFFFFFFFF
Valor predeterminado: 5
Descripción: este parámetro controla el número de veces que TCP retransmite un segmento de datos individual (segmento de no conexión) antes de cancelar la conexión. El tiempo de espera de retransmisión se duplica con cada retransmisión sucesiva en una conexión. Se restablece cuando se reanuda la respuesta. El valor de tiempo de espera de base se determina de forma dinámica mediante el tiempo de ida y vuelta medido en la conexión.

Un saludo desde el cable y cuidado con los seres imaginarios…

Alberto Camina Alvarez

Técnico de Soporte Microsoft Premier

Comments

• Anonymous
  January 01, 2003
  Hola Tenia pendiente enlazar el blog de equipo que mantienen los compañeros del grupo al que tuve

• Anonymous
  January 01, 2003
  The comment has been removed