Diagnóstico de una red TCP/IP

Una vez que la red ha sido diseñada y configurada, sus usuarios comienzan a trabajar sobre ella y a utilizar sus servicios. Es un hecho que, tarde o temprano, alguno de ellos tendrá alguna dificultad para acceder a algún servicio y recurrirá al administrador de la red a fin de obtener una solución. Sin embargo, antes de poder ofrecer alguna, el administrador deberá diagnosticar el problema, esto es, hallar sus causas.

Mensajes de error usuales

Hay ciertas condiciones de error que son usuales en una red TCP/IP. Si bien los mensajes de error con que las aplicaciones informan al usuario acerca de las mismas son altamente dependientes de la plataforma, la mayoría de las veces son similares a los siguientes:

Unknown host: El nombre de host utilizado por el usuario no pudo resolverse; es decir, no pudo obtenerse su dirección IP. Puede ser indicativo de un error en el acceso al servidor de nombres: quizás es errónea la dirección IP indicada en el archivo /etc/resolv.conf, o el demonio named no se encuenta activo en esa computadora, o el módulo TCP/IP de la misma no se encuentra funcionando correctamente. Sin embargo, también puede deberse a un error en el tipeo del nombre (esto es, podría no existir una computadora con el nombre indicado).

Network unreachable: El sistema local no tiene una ruta que conduzca a la red a la que corresponde la dirección IP de la máquina remota. Puede deberse a un error en la configuración de la tabla de ruteo, a que la ruta se haya vuelto inalcanzable (por ejemplo, porque el gateway o los vínculos de comunicación que conectan con ella están fuera de línea) o a que la dirección IP utilizada es errónea.

No answer from host: El sistema remoto no contesta las peticiones realizadas desde el host local. En este caso, usualmente la dirección IP es correcta y existen rutas a la red a la cual pertenece, pero el host no puede ser contactado debido a que, por ejemplo, se encuentra apagado o desconectado de la red.

Connection refused by peer: Este error indica que, si bien pudo contactarse al host remoto, el mismo denegó la conexión. Puede deberse a medidas de seguridad (es decir, la computadora remota por alguna razón de seguridad no permite el acceso desde la computadora local al servicio que se le requiere) o a que no hay un servicio "escuchando" en el puerto TCP indicado desde la computadora local (por ejemplo, se desea acceder al demonio named en la computadora remota, y el mismo no se encuentra ejecutándose allí).

Herramientas de diagnóstico

Algunas de las herramientas ofrecidas por Unix para diagnosticar problemas de red (y usualmente disponibles también en otras plataformas) son las siguientes:

ping: Es la herramienta básica para verificar la conectividad de la red. Permite determinar si un host es alcanzable y proporciona estadísticas sobre los tiempos de respuesta de la red.

traceroute24: Muestra la ruta que los paquetes seguirán desde un host de origen hasta otro host de destino. Permite, entonces, diagnosticar problemas de ruteo.

nslookup: Permite hacer consultas interactivas a un servidor DNS, tal como se discutió en el capítulo anterior.

netstat: Despliega información sobre la tabla de ruteo, las interfaces y los sockets activos.

ifconfig: Si bien es básicamente una herramienta de configuración, puede utilizarse también como herramienta de diagnóstico, para detectar errores en la dirección IP, mascara de subred o dirección de broadcast (ver capítulo sobre asignación de direcciones IP).

Testeo de alcanzabilidad

El primer paso para diagnosticar un problema en una red TCP/IP es verificar la alcanzabilidad de un host, esto es, si es posible enviar paquetes al mismo a través de la red.

La herramienta primordial para testear alcanzabilidad es ping, cuya sintaxis básica es la siguiente:

ping nombre_de_host_o_dirección_IP

Por ejemplo, para verificar si el host Rigel es alcanzable, habría que ejecutar el siguiente comando:

$ ping rigel
PING rigel.galaxia.org.ar (170.25.1.2): 56 data bytes
64 bytes from 170.25.1.2: icmp_seq=0 ttl=64 time=0.1 ms
64 bytes from 170.25.1.2: icmp_seq=1 ttl=64 time=0.1 ms
64 bytes from 170.25.1.2: icmp_seq=2 ttl=64 time=0.1 ms
64 bytes from 170.25.1.2: icmp_seq=3 ttl=64 time=0.1 ms
64 bytes from 170.25.1.2: icmp_seq=4 ttl=64 time=0.1 ms
64 bytes from 170.25.1.2: icmp_seq=5 ttl=64 time=0.1 ms
64 bytes from 170.25.1.2: icmp_seq=6 ttl=64 time=0.1 ms
64 bytes from 170.25.1.2: icmp_seq=7 ttl=64 time=0.1 ms
64 bytes from 170.25.1.2: icmp_seq=8 ttl=64 time=0.1 ms
64 bytes from 170.25.1.2: icmp_seq=9 ttl=64 time=0.1 ms
^C

--- rigel.galaxia.org.ar ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.1 ms

ping envía paquetes al host remoto utilizando el protocolo ICMP, los cuales, de ser recibidos por dicho host, generan un paquete similar de respuesta para el host local. Cuando el host local los recibe, muestra una línea de información por pantalla, y el ciclo continúa hasta que el usuario lo cancele con Control-C.

Al terminar, ping muestra un reporte estadístico, en el que informa la cantidad de paquetes transmitidos y recibidos, y el porcentaje de pérdida de paquetes. También se informa sobre los tiempos mínimo, promedio y máximo que toma el recorrido de ida y vuelta entre ambos hosts.

Como puede verse, ping permite además determinar el nivel de carga de la red: si el porcentaje de perdida de paquetes o los tiempos de ida y vuelta es muy alto, podría ser un indicio de sobrecarga de tráfico, interferencias en el medio de comunicación, o inclusive problemas de hardware.

Verificación del estado de las interfaces

Como se recordará el comando ifconfig, al ser invocado sin argumentos, muestra el estado actual de las interfaces de red configuradas:

$ ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
RX packets:331036 errors:0 dropped:0 overruns:0
TX packets:331036 errors:0 dropped:0 overruns:0

eth0 Link encap:Ethernet HWaddr 00:10:4B:38:27:BA
inet addr:170.25.2.254.216 Bcast:170.25.2.244 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4563766 errors:1 dropped:0 overruns:1
TX packets:5864531 errors:0 dropped:0 overruns:0
Interrupt:11 Base address:0x6100

eth1 Link encap:Ethernet HWaddr 00:10:4B:62:45:81
inet addr:170.25.3.254 Bcast:170.25.3.254 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4279043 errors:3 dropped:0 overruns:1
TX packets:2940848 errors:0 dropped:0 overruns:0
Interrupt:10 Base address:0x6200

En el listado anterior, se muestran 3 interfaces (dos placas Ethernet y la interfaz lógica de loopback). En todos los casos, se muestra la dirección de IP asignada, así también como la dirección de broadcast y la máscara de subred.

En el caso de las placas Ethernet, se informa también la dirección física del adaptador (o MAC Address), y características de configuración del adaptador (número de interrupción y dirección base de I/O).

Las líneas que comienzan con RX y TX presentan un informe del funcionamiento de la interfaz en términos de cantidad de paquetes recibidos y transmitidos, respectivamente. También se informa en cada caso la cantidad de paquetes erróneos detectados por la interfaz.

Información similar en un formato mas compacto puede obtenerse con el comando netstat -i:

$ netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flag
lo 3584 0 331036 0 0 0 331036 0 0 0 BLRU
eth0 1500 0 4563766 1 0 0 5864531 0 0 0 BRU
eth1 1500 0 4279043 3 0 0 2940848 0 0 0 BRU

Verificación de las rutas

Por medio de los comandos ifconfig y netstat -i podemos determinar el estado de las interfaces locales, a fin de determinar si son capaces de enviar y recibir paquetes. Usando ping podemos verificar si el host remoto "es visible" desde el host local a través de la red.

Si la comprobación de las interfaces muestra que su estado es el correcto, pero ping no da resultados positivos, el siguiente paso en el diagnóstico de un problema de conectividad con un host remoto es determinar que tan lejos llegan los paquetes.

El comando traceroute permite verificar cual es la ruta que los paquetes siguen para llegar a un host remoto, y de esa manera detectar errores en la configuración de las tablas de ruteo:

$ traceroute canopus
tracing to canopus.galaxia.org.ar (170.25.4.1), 30 hops max, 40 bytes packets
1 orion (170.225.1.254) 0.361 ms 0.302 ms 0.296 ms
2 andromeda (170.25.3.253) 44.366 ms 38.533 ms 13.282 ms
3 canopus (170.25.4.1) 28.743 ms 50.976 ms 39.28 ms

Como puede verse, traceroute se invoca con el nombre de un host remoto, y muestra como resultado todos los gateways intermedios que se atraviesan hasta llegar a destino. La información se recaba por medio del envío de paquetes ICMP; si alguno de ellos se perdiera en el camino, traceroute mostrará una serie de asteriscos.

Por ejemplo, supongamos que el usuario de la computadora Antares reporta la imposibilidad para conectarse a Canopus. El primer paso en el diagnóstico sería revisar la configuración de las interfaces con ifconfig y luego verificar si realmente no hay conectividad, utilizando ping. Si ese fuera el caso, puede deberse tanto a que Canopus esté fuera de línea como a que exista algún problema en algún punto intermedio de la red. Por medio de traceroute puede determinarse cual es el caso.

Supongamos que la salida de traceroute es la siguiente:

$ traceroute canopus
tracing to canopus.galaxia.org.ar (170.25.4.1), 30 hops max, 40 bytes packets
1 orion (170.225.1.254) 0.361 ms 0.302 ms 0.296 ms
2 andromeda (170.25.3.253) 44.366 ms 38.533 ms 13.282 ms
3 * * *
4 * * *
5 * * *

traceroute continuará mostrando asteriscos hasta llegar a los 30 intentos o hasta que el usuario lo cancele con Ctrl-C. La conclusión aquí es que la falta de conectividad se debe a que Canopus está fuera de línea o bien los enlaces desde Andrómeda estan fallando. Podría probarse, por ejemplo, el utilizar ping para intentar llegar a otra computadora sobre la misma subred de Canopus (por ejemplo, ping centauri); si la respuesta es negativa se trataría de un problema de red, mientras que si es positiva, la respuesta es que Canopus está fuera de línea.

Si el resultado de traceroute fuera el siguiente:

$ traceroute canopus
tracing to canopus.galaxia.org.ar (170.25.4.1), 30 hops max, 40 bytes packets
1 orion (170.225.1.254) 0.361 ms 0.302 ms 0.296 ms
2 * * *
3 * * *
4 * * *
5 * * *

entonces o bien hay un problema en el gateway o en las líneas de comunicación hacia él. La cuestión puede zanjarse procediendo de manera similar al caso anterior.

24. Bajo Windows NT, este comando está disponible bajo el nombre de tracert.