186

Problemas de red

En mi empresa a veces tenemos problemas con la red. No pregunto sobre cómo resolver esos problemas, puesto que ni siquiera sé qué sistema operativo tenemos o si es por algún módem caído, sino por una curiosidad que tengo. Con el módem caído no puedo conectar con ninguna máquina, pero sin embargo las conexiones NFS que tengo establecidas desde mi PC con Linux siguen funcionando. Por cierto, si ejecuto netstat al final me sale, pero tras quedarse un rato como bloqueado ¿Por qué pasa esto?

Albert Casa

Por los síntomas que nos describes, parece que el problema está en que el DNS deja de funcionar, mientras la red local siga en pie. Puede que tu empresa cuente con una intranet que engloba subredes de varias oficinas, en una de las cuales están los servidores DNS. Si se corta la conexión de tu red local con la red en que está el DNS, no podrás establecer nuevas conexiones con ninguna máquina salvo que uses su IP. En el caso del servidor NFS, como la conexión ya estaba establecida y no hay que resolver la IP, sigue funcionando normalmente. Incluso puede que te encuentres con otras aplicaciones que sí logran establecer conexión porque mantienen en cache las resoluciones que han hecho; es el caso de Konqueror apoyado por la arquitectura de KDE 2.

El netstat se queda esperando un rato porque por defecto trata de mostrar las direcciones de las máquinas por su nombre en lugar de por su IP. Si usas la opción -n para que las muestre en formato numérico, no se bloqueará tratando de resolver la dirección.

Cualquier comando que ejecutes que implique resolver la dirección tardará unos segundos en responderte y al final te dirá que no encuentra el nombre. La espera será de unos 20 o 40 segundos según tengas uno o dos servidores DNS configurados. El motivo es que el algoritmo de resolución envía un paquete UDP con la petición y espera una respuesta un máximo de 5 segundos. Si no la recibe, vuelve a reintentarlo otra vez. Son 20 segundos por servidor en lugar de 10 porque hace dos consultas: el nombre tal cual y añadiéndole el dominio por defecto.

En realidad, tanto el tiempo de espera como el número de intentos es configurable en el fichero /etc/resolv.conf, y los valores citados son los que toma cuando no le damos ninguno, o más en concreto, los que estaban definidos en el fichero /usr/include/resolv.h cuando se compiló. Para más información, está la página del manual resolv.conf. Esta información sin embargo no sale en la página en español (la de inglés ha cambiado desde la traducción); para que nos salga deberemos ejecutar (unset LANG ; man resolv.conf).

Puede parecer extraño que el protocolo de resolución espere unos segundos la respuesta, en lugar de darse cuenta en el acto de que no hay conexión, ya que si intentamos un telnet a una IP a la que no hay ruta nos lo dice prácticamente al instante. El motivo es que las consultas DNS se hacen utilizando datagramas UDP en lugar de conexiones TCP, por motivos de eficiencia. Al enviar un datagrama UDP no recibimos confirmación ni error, porque no hay establecida una conexión. Simplemente si el servidor no devuelve la respuesta, es que hubo problemas y hay que repetir. Se le da unos segundos de margen porque a su vez el servidor DNS puede tener que consultar con otros servidores DNS que han de buscar entre millones de entradas.

La llamada en Unix que resuelve una dirección (gethostbyname) a diferencia del resto que involucran sockets no se puede hacer no bloqueante. Por culpa de ello, Netscape se quedaba totalmente bloqueado cada vez que trataba de resolver una dirección, hasta que obtenía respuesta o concluía el timeout. Las versiones actuales atajan el problema lanzando un proceso auxiliar que lidia con el DNS, aunque no siempre parece funcionar.

Anterior Siguiente