En la administración de infraestructuras críticas y centros de datos, diagnosticar anomalías en la capa de red requiere comprender los mecanismos internos de los protocolos de transporte, control e interconexión. Cuando un enlace se degrada, una ruta oscila o un servicio rechaza conexiones, no basta con ejecutar comandos básicos de forma mecánica; es indispensable entender cómo interactúan los paquetes a nivel de socket, pila TCP/IP del kernel de Linux y tablas de reenvío en routers Cisco. Este documento constituye una referencia técnica exhaustiva de las herramientas de diagnóstico esenciales, abordando su comportamiento bajo el capó y la interpretación granular de sus métricas.
ping: Verificación de Conectividad y Capa de Control ICMP
La herramienta ping implementa el protocolo ICMP (Internet Control Message Protocol, definido en RFC 792 para IPv4 y RFC 4443 para IPv6). A nivel interno, el binario ensambla un paquete IP con protocolo de nivel superior 1 (ICMP) y carga útil que contiene una cabecera específica con campos como Tipo (Type), Código (Code), Checksum, Identificador de Proceso y Número de Secuencia, seguido habitualmente de una marca de tiempo. Cuando el host origen emite un mensaje ICMP Type 8 (Echo Request), espera que el host destino o la interfaz de red responda directamente desde el espacio de kernel con un mensaje ICMP Type 0 (Echo Reply), preservando el Identificador y el Número de Secuencia para computar con precisión el tiempo de ida y vuelta (RTT o Round-Trip Time).
En entornos empresariales y routers Cisco IOS, ping no solo valida la existencia de un nodo en la topología, sino que somete a prueba la estabilidad de la MTU (Maximum Transmission Unit) y detecta problemas de fragmentación mediante el bit DF (Don't Fragment). Si un paquete excede la MTU del siguiente salto y tiene el bit DF activo, el router intermediario lo descarta forzosamente y devuelve un paquete ICMP Type 3, Code 4 (Destination Unreachable, Fragmentation Needed and DF Set), mecanismo fundamental para el algoritmo de Path MTU Discovery (PMTUD).
# Linux: Validación de MTU sin fragmentación con 4 paquetes cada 0.5s
ping -c 4 -i 0.5 -s 1472 -M do -W 2 192.168.1.1
# Linux: Inundación controlada para pruebas de estrés de paquetes
ping -f -c 1000 -s 64 10.0.0.254
# Cisco IOS: Ping extendido con interfaz origen y bit DF activo
ping ip 10.10.10.1 source Loopback0 size 1500 df-bit repeat 50 timeout 1
- -c 4: Define la cantidad exacta de paquetes Echo Request a transmitir antes de finalizar la ejecución de forma automática.
- -i 0.5: Establece el intervalo de espera entre envíos sucesivos de paquetes a 0.5 segundos (500 ms). Requiere privilegios de root para valores menores a 0.2 segundos.
- -s 1472: Especifica el tamaño en bytes del payload ICMP. Al sumar 8 bytes de cabecera ICMP y 20 bytes de cabecera IPv4, da un frame exacto de 1500 bytes (MTU Ethernet estándar).
- -M do: Configura la estrategia de PMTUD en Linux. El valor do fuerza la activación del bit DF (Don't Fragment), prohibiendo la fragmentación en todo el trayecto.
- -W 2: Tiempo de espera máximo (timeout) en segundos para recibir una respuesta antes de considerar el paquete perdido.
- -f: Modo flood. Emite paquetes a la velocidad que la interfaz es capaz de procesar o conforme retornan los ACKs; imprime puntos para envíos y retrocesos para respuestas.
- Cisco source [interfaz]: Especifica la dirección IP de origen ligada a una interfaz específica, útil para validar ruteo simétrico.
- Cisco df-bit / repeat / timeout: Activa el flag DF en el encabezado IP, determina la cantidad de iteraciones y define el tiempo de espera por cada paquete.
Interpretación de resultados: En Linux, observe el porcentaje de packet loss; cualquier valor superior a 0% en enlaces locales indica colisión, saturación de búfer en switch o fallos de capa física. El campo ttl (Time to Live) decrementado revela cuántos saltos de capa 3 atravesó el paquete (un host Linux suele partir de TTL 64, Windows de 128 y Cisco de 255). La desviación estándar mdev (mean deviation) cuantifica el jitter: valores altos de mdev reflejan congestión o buffers saturados (bufferbloat). En Cisco, una salida con signos de exclamación (!) representa recepción exitosa; un punto (.) implica expiración de temporizador; una U indica inalcanzabilidad por recepción de ICMP Type 3; una Q señala saturación de buffers de entrada (source quench); y una M representa fallo por imposibilidad de fragmentar ante discrepancia de MTU.
traceroute: Mapeo de Trayectorias y Descubrimiento de Saltos
La herramienta traceroute mapea la ruta determinista de paquetes hacia un destino explotando el campo TTL de la cabecera IPv4 (o Hop Limit en IPv6) y las respuestas de error ICMP Type 11 Code 0 (Time-to-Live Exceeded in Transit). Por defecto en Linux, traceroute genera datagramas UDP dirigidos a un rango de puertos altos difícilmente utilizados (puerto base 33434, incrementándose en cada probe). En Cisco IOS, el comando de rastreo también recurre por omisión a sondas UDP hacia puertos altos.
El algoritmo comienza enviando una ráfaga de paquetes con TTL=1. El primer router en el trayecto decrementa el TTL a 0, descarta el datagrama por especificación del protocolo IP y despacha de vuelta al origen un mensaje ICMP Type 11 Code 0 con su propia IP en el encabezado de origen. Traceroute registra esta dirección IP y el RTT transcurrido. A continuación, retransmite paquetes con TTL=2, alcanzando el segundo salto, y continúa incrementando progresivamente el TTL. Cuando el paquete alcanza el destino final con el puerto UDP cerrado, la pila IP del host no devuelve Type 11, sino ICMP Type 3 Code 3 (Destination Unreachable: Port Unreachable), lo que indica la terminación exitosa del rastreo.
# Linux: Trazado sin resolución DNS mediante paquetes TCP SYN dirigidos al puerto 443
traceroute -n -T -p 443 -w 2 -q 3 1.1.1.1
# Linux: Trazado forzando ICMP clásico con un límite máximo de 20 saltos
traceroute -I -m 20 8.8.8.8
# Cisco IOS: Trazado extendido especificando interfaz de origen y parámetros numéricos
traceroute 192.168.10.1 source GigabitEthernet0/0 ttl 1 25 numeric probe 3 timeout 2
- -n: Deshabilita la resolución inversa de DNS (PTR) para cada dirección IP descubierta, reduciendo drásticamente la latencia de la ejecución.
- -T: Cambia el protocolo de la sonda de UDP a TCP SYN. Es ideal para sortear firewalls que descartan ráfagas UDP o ICMP pero permiten tráfico web.
- -p 443: Especifica el puerto de destino para las sondas (en conjunción con
-T o -U). En este caso, puerto seguro HTTPS.
- -w 2: Tiempo de espera máximo en segundos por cada respuesta antes de marcar timeout para una sonda individual.
- -q 3: Cantidad de sondas (paquetes concurrentes) emitidas por cada salto para calcular consistencia de RTT.
- -I: Fuerza la utilización de paquetes ICMP Echo Request en lugar de datagramas UDP.
- -m 20: Fija el valor máximo de TTL (número máximo de saltos) a evaluar antes de detener la traza.
- Cisco numeric / probe / ttl: Suprime la búsqueda DNS, define el número de sondas por salto e instruye el rango de TTL inicial y final.
Interpretación de resultados: Cada línea representa un salto de capa 3. Si se visualizan tres asteriscos consecutivos (* * *), esto no necesariamente implica que el enlace esté caído; denota que el nodo intermediario descarta datagramas de control ICMP, tiene deshabilitada la generación de ICMP Type 11 o existe una regla de firewall que filtra las sondas. La presencia de flags como !H (Host Unreachable), !N (Network Unreachable), !P (Protocol Unreachable) o !X (Communication Administratively Prohibited) delata el bloqueo explícito por listas de control de acceso (ACLs). Variaciones asimétricas de RTT entre saltos intermedios sugieren enrutamiento multipath (ECMP) o que el plano de control (Control Plane Policing - CoPP) del router está limitando la tasa (rate-limiting) de generación de paquetes ICMP sin afectar el tráfico de datos en tránsito.
tcpdump y Embedded Packet Capture (EPC): Análisis Profundo de Datagramas
tcpdump es el analizador de paquetes por línea de comandos estándar en Linux, basado en la biblioteca libpcap. Opera interactuando directamente con el subsistema de red del kernel mediante sockets de bajo nivel de tipo AF_PACKET combinados con el modo promiscuo del controlador de interfaz de red (NIC). Al colocarse en modo promiscuo, el hardware de la NIC deshabilita sus filtros de dirección MAC, transfiriendo todas las tramas que circulan por el dominio de colisión/broadcast al búfer del kernel, antes de que el subsistema netfilter/iptables pueda descartarlas o alterarlas.
En el núcleo de tcpdump opera la máquina virtual de filtrado de paquetes de Berkeley (BPF o Berkeley Packet Filter). BPF compila las expresiones de filtrado definidas por el usuario en microcódigo altamente optimizado que se ejecuta en espacio de kernel, evitando copias innecesarias de memoria desde el espacio de kernel hacia el espacio de usuario para aquellos paquetes que no cumplen el patrón. En Cisco IOS, la arquitectura equivalente se implementa como Embedded Packet Capture (EPC), la cual asigna un búfer circular en la memoria RAM del equipo para registrar el flujo antes del switching de capa 3 (Cisco Express Forwarding).
# Linux: Captura full-payload de tráfico TCP hacia puerto 443 omitiendo resolución de nombres
tcpdump -nnvv -i eth0 -s 0 -c 100 'tcp port 443 and (src net 192.168.1.0/24)' -w /tmp/capture.pcap
# Linux: Depuración en vivo de banderas TCP SYN, FIN y RST
tcpdump -nn -i any 'tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0'
# Cisco IOS: Configuración de búfer y captura de paquetes embebida (EPC)
monitor capture buffer BUF-TEST size 4096 max-size 1518 circular
monitor capture point ip cef POINT-TEST GigabitEthernet0/1 both
monitor capture point associate POINT-TEST BUF-TEST
monitor capture buffer BUF-TEST start
- -nn: Evita la resolución tanto de nombres de dominio para direcciones IP como de nombres de servicios reconocidos para números de puerto (e.g., muestra
443 en vez de https).
- -vv: Habilita el nivel de verbosidad muy alto, decodificando cabeceras IP completas (TTL, ID, longitud total, opciones IP) y flags de protocolos de transporte.
- -i eth0 / -i any: Especifica la interfaz física/lógica de escucha. El valor especial
any captura en todas las interfaces activas simultáneamente en pseudocapa de enlace.
- -s 0: Configura el snaplength (longitud de captura por paquete) a 0, lo que en versiones modernas de libpcap equivale a capturar el paquete completo (65535 bytes) sin truncamiento.
- -c 100: Instruye al proceso a finalizar inmediatamente tras registrar 100 paquetes coincidentes con el filtro.
- -w /tmp/capture.pcap: Escribe los paquetes crudos directamente en un archivo compatible con el estándar pcap, listo para análisis forense offline con herramientas como Wireshark.
- 'tcp port 443 and ...': Sintaxis formal BPF para filtrar condicionalmente por capa de transporte, puertos y subredes lógicas.
Interpretación de resultados: La salida estándar de tcpdump expone la marca temporal en microsegundos, la tupla de conexión IP:puerto origen y destino, las banderas TCP entre corchetes ([S] para SYN, [S.] para SYN-ACK, [.] para ACK, [P.] para PUSH-ACK, [F.] para FIN, [R] para RST), el número de secuencia relativo, el campo de acuse de recibo (ack), el tamaño de ventana de recepción (win) y las opciones TCP negociadas (MSS, SACK, Window Scale). Una proliferación de flags [R] (RST) indica rechazo de conexión por parte del demonio local o interrupción inducida por un cortafuegos con stateful inspection. Una reducción de win hasta alcanzar 0 (Zero Window) denuncia que el búfer de recepción del socket a nivel de aplicación está desbordado, imposibilitando recibir más bytes sin generar contrapresión (backpressure).
ss y netstat: Inspección de Sockets y Capa de Transporte
Históricamente, netstat inspeccionaba las estructuras de red leyendo sistemáticamente el sistema de archivos virtual /proc/net/tcp, /proc/net/udp y /proc/net/raw. Aunque funcional, este mecanismo degrada drásticamente el rendimiento en servidores con decenas de miles de conexiones abiertas, debido al bloqueo inducido al iterar y serializar tablas completas en memoria de kernel a texto plano. Por ello, la utilidad moderna ss (Socket Statistics) reemplaza a netstat consumiendo directamente la interfaz Netlink del kernel de Linux, específicamente el subsistema sock_diag.
Mediante Netlink, ss realiza consultas binarias directas que devuelven estructuras de datos compactas sobre el estado de la máquina de estados TCP (definida formalmente en RFC 793). Esto incluye estados canónicos como LISTEN, ESTABLISHED, SYN_SENT, CLOSE_WAIT, TIME_WAIT y FIN_WAIT. Asimismo, ss extrae directamente del struct de control de congestión de la pila IP parámetros cruciales como RTT interno calculado por el kernel, el tamaño de la ventana de congestión (cwnd), los bytes en tránsito no reconocidos y las colas de transmisión/recepción locales.
# Linux: Listado exhaustivo de sockets escuchando en TCP/UDP con identificación de procesos
ss -tulpen
# Linux: Análisis avanzado de sockets TCP establecidos con temporizadores e información interna
ss -tiona '( dport = :https or sport = :https )'
# Linux: Consulta clásica de netstat con tablas de enrutamiento y estadísticas de interfaz
netstat -tulpn
- -t: Filtra la salida para exponer exclusivamente sockets asociados al protocolo de transporte orientado a conexión TCP.
- -u: Incluye sockets de datagramas UDP (mostrados habitualmente en estado UNCONN ya que UDP carece de conexión formal).
- -l: Muestra únicamente sockets en estado
LISTEN, omitiendo las conexiones que ya están activas o negociándose.
- -p: Revela el nombre del proceso (nombre del binario) y su respectivo identificador de proceso (PID) vinculado al descriptor de archivo del socket (requiere root).
- -e: Muestra información extendida del socket, incorporando el UID del usuario dueño del proceso, el número de inodo en memoria y el identificador de socket.
- -n: Deshabilita la traducción de direcciones numéricas a nombres de host y de puertos a nombres de servicios.
- -i: Proyecta variables internas del algoritmo de control de congestión de la pila TCP del kernel (e.g., MSS, cwnd, ssthresh, rtt, rcvspace).
- -o: Expone la información de temporizadores de socket (temporizadores de keepalive, retransmission o FIN_WAIT).
Interpretación de resultados: En sockets en estado LISTEN, la columna Recv-Q denota el número de conexiones TCP que completaron el three-way handshake pero siguen pendientes de ser procesadas por la función accept() de la aplicación (cola de backlog de la aplicación). Si Recv-Q alcanza el límite configurado en Send-Q, la aplicación está bloqueada o desbordada, y los nuevos clientes experimentarán timeouts de conexión (descarte de paquetes SYN o emisión de SYN-ACKs retransmitidos). En sockets en estado ESTABLISHED, Recv-Q indica los bytes copiados al búfer de red del kernel pendientes de lectura por el proceso, y Send-Q son los bytes transmitidos que aún no han sido reconocidos vía ACK por el receptor remoto. Un valor elevado persistente en CLOSE_WAIT señala un bug en la aplicación local por no ejecutar formalmente el close() del descriptor tras recibir un FIN del cliente.
mtr (My Traceroute): Diagnóstico Integral de Pérdida y Jitter
mtr combina la capacidad de localización de rutas provista por traceroute con la evaluación probabilística continua de calidad de servicio característica de ping. Al inicializarse, mtr determina la topología de la ruta mediante sondas TTL incrementales continuas. Una vez identificados los saltos, envía periódicamente paquetes a cada uno de ellos de forma concurrente, actualizando dinámicamente un resumen estadístico en tiempo real.
Mtr puede operar tanto con paquetes ICMP Echo Request como con sondas UDP o paquetes TCP con la bandera SYN activa. Esto resulta crucial para sortear políticas de calidad de servicio (QoS) y priorización diferenciada (DSCP): en muchas redes de proveedores de servicios de telecomunicaciones (Tier 1 y Tier 2), el tráfico ICMP es direccionado a colas de baja prioridad o sometido a rate-limiting en los procesadores de ruta (Route Processors) de los routers, distorsionando la realidad del tráfico de producción TCP. Mtr mitiga este sesgo permitiendo diagnosticar la ruta utilizando el mismo protocolo y puerto que la aplicación final.
# Linux: Modo reporte estático de 100 ciclos usando paquetes TCP dirigidos al puerto 80 sin DNS
mtr --report --report-cycles 100 -n --tcp --port 80 8.8.8.8
# Linux: Interfaz completa interactiva con despliegue de fluctuaciones y jitter
mtr -o "LSD NBAWV" 1.1.1.1
- --report (-r): Ejecuta el análisis en segundo plano durante los ciclos estipulados y vuelca una tabla estadística estructurada a la salida estándar, finalizando automáticamente.
- --report-cycles 100 (-c 100): Determina la cantidad de paquetes emitidos a cada salto del trayecto para consolidar las métricas estadísticas finales.
- -n: Suprime la resolución inversa de DNS (rDNS), reportando estrictamente direcciones IP numéricas para evitar falsas esperas por latencia de resolución.
- --tcp: Modifica el motor de generación de paquetes para emplear sondas TCP SYN en lugar de ICMP.
- --port 80 (-p 80): Establece el puerto TCP destino sobre el cual se abrirán los intentos de handshake en cada salto de red.
- -o "LSD NBAWV": Personaliza las columnas de salida en la interfaz curses (L: Loss%, S: Sent, D: Dropped, N: Hop number, B: Best, A: Average, W: Worst, V: Standard Deviation).
Interpretación de resultados: El análisis de un reporte mtr exige discernir entre caídas de tráfico legítimas y limitación del plano de control. Si un salto intermedio acusa un 20% de pérdida de paquetes (Loss%) pero los saltos subsecuentes hasta el destino final exhiben 0% de pérdida, la degradación es aparente: el procesador del router intermedio simplemente descartó el exceso de paquetes de control dirigidos hacia él, pero conmutó el tráfico a nivel de silicio (ASICs) sin pérdidas en el plano de datos. Por el contrario, si la pérdida de paquetes o un incremento abrupto de latencia en la columna Avg (promedio) comienza en un salto específico y se propaga en cascada constante o incremental hacia todos los saltos posteriores hasta el destino, se ha localizado el punto exacto de congestión de enlace, saturación de búfer o falla de hardware.
ip route y Cisco RIB/FIB: Inspección de Tablas de Enrutamiento
La herramienta ip route, perteneciente a la suite iproute2 en Linux, administra la FIB (Forwarding Information Base) del kernel, comunicándose mediante la interfaz rtnetlink. El enrutamiento IP no decide basándose en el estado de las aplicaciones, sino aplicando de manera estricta el principio LPM (Longest Prefix Match) sobre los destinos evaluados en el encabezado IP. En los sistemas operativos de red Cisco IOS/IOS-XE, la tabla de enrutamiento formal (RIB o Routing Information Base) se alimenta dinámicamente mediante protocolos (BGP, OSPF, EIGRP) y rutas estáticas, transfiriendo posteriormente las entradas óptimas hacia la FIB compilada de Cisco Express Forwarding (CEF), que resuelve directamente las adyacencias de Capa 2.
Linux admite múltiples tablas de enrutamiento independientes combinadas con reglas de enrutamiento basado en políticas (PBR - Policy-Based Routing manipulado con ip rule). Un paquete entrante o local se compara con las tablas predeterminadas (local, main, default) o tablas definidas por el administrador. Comprender cómo el kernel selecciona el próximo salto (next-hop) y la interfaz de salida es fundamental para diagnosticar escenarios de asimetría de rutas, problemas con RPF (Reverse Path Forwarding) o fallos de encapsulamiento.
# Linux: Consulta general de la tabla principal de enrutamiento (main)
ip route show
# Linux: Consulta determinista simulada para validar la ruta exacta que tomaría un paquete
ip route get 8.8.8.8 from 192.168.1.100 iif eth0
# Linux: Inserción de ruta estática persistente con métrica específica y pasarela
ip route add 10.200.0.0/16 via 172.16.1.1 dev eth1 metric 100
# Cisco IOS: Inspección de la tabla de enrutamiento y validación de coincidencia de prefijo
show ip route
show ip route 10.200.1.5
show ip cef 10.200.1.5
- show: Vuelca en pantalla las directivas de enrutamiento activas contenidas en la tabla consultada (por defecto la tabla main).
- get [dirección_ip]: Ejecuta una resolución de ruta simulada en el kernel. Aplica todas las reglas PBR, calcula el next-hop exacto, la interfaz devuelta, el MTU efectivo y la IP que se seleccionará como origen (source address selection).
- from [ip] iif [interfaz]: Parámetros complementarios para
ip route get que simulan el tráfico entrante desde una interfaz específica para validar si RPF o reglas PBR desvían el flujo.
- add [prefijo] via [gateway]: Declara formalmente una nueva regla de direccionamiento de tráfico hacia una red de destino asignando el router de siguiente salto.
- dev [interfaz]: Especifica forzosamente la interfaz física o lógica sobre la cual deben salir las tramas de capa 2 dirigidas a esa red.
- metric [valor]: Asigna una distancia administrativa o costo a la ruta para desempatar ante múltiples trayectorias con idéntica longitud de máscara de red.
- Cisco show ip route [ip]: Devuelve el registro exacto de la base de datos de enrutamiento, informando la distancia administrativa, la métrica interna y la interfaz de salida del prefijo que contiene a dicha dirección.
- Cisco show ip cef [ip]: Muestra la entrada en la tabla CEF de hardware, verificando si el paquete cuenta con una adyacencia de Capa 2 resuelta para reenvío por silicio.
Interpretación de resultados: Al examinar ip route show, el prefijo con la máscara más larga siempre tiene precedencia absoluta sobre los demás, independientemente de la métrica (ej. 10.0.0.0/24 prevalecerá siempre sobre 10.0.0.0/16 y sobre default via ...). La línea que comienza con default define la puerta de enlace predeterminada (0.0.0.0/0). La salida de ip route get es indispensable en depuración compleja: si muestra rt_gateway seguido de la IP del router, el paquete saldrá ruteado; si expone la directiva dev lo con local, indica que la dirección pertenece a una interfaz del propio servidor. En Cisco, la cabecera del comando show ip route revela las fuentes mediante códigos: C (Conectada), S (Estática), R (RIP), O (OSPF), D (EIGRP), B (BGP). Las cifras entre corchetes, por ejemplo [110/2], expresan respectivamente la Distancia Administrativa (confiabilidad de la fuente, donde 110 corresponde a OSPF) y la métrica de costo hacia el destino.
