En infraestructuras corporativas de misión crítica, la degradación intermitente de servicios suele ser más compleja de resolver que una caída total. Cuando dos activos de red reclaman simultáneamente la misma dirección IPv4 en un mismo dominio de difusión (VLAN), el protocolo de resolución de direcciones (ARP, RFC 826) genera una condición de carrera no determinista. Este caso de estudio documenta la intervención de un Ingeniero de Soporte Nivel 3 frente a un incidente de alta severidad (Sev-1) que afectó al nodo principal de bases de datos de una institución financiera, provocando microcortes transaccionales, caídas de sesiones TCP y corrupción de estados en el balanceador de carga.
Síntomas y Descripción del Escenario
El incidente comenzó a las 08:42 UTC en el clúster de procesamiento transaccional alojado en la VLAN 120 (subred 10.120.40.0/24). El servidor afectado, identificado como DB-CORE-PROD01 con la dirección estática 10.120.40.50, comenzó a reportar pérdidas intermitentes de conectividad hacia el clúster de aplicaciones y la pasarela de enlace predeterminada (Default Gateway) configurada en un par de switches Cisco Catalyst 9500 en esquema HSRP (Hot Standby Router Protocol).
Los principales síntomas observados por el equipo de operaciones incluyeron:
- Rendimiento de red errático: Pérdida de paquetes oscilante entre el 30% y el 60% en ráfagas de 30 a 90 segundos hacia y desde la IP 10.120.40.50.
- Ruptura de sesiones de transporte: Múltiples alertas de terminación abrupta de sesiones TCP mediante paquetes RST (Reset), interrumpiendo sincronizaciones sincrónicas de base de datos.
- Alertas de sistema operativo: Los registros del sistema en el servidor Linux de producción registraron mensajes críticos del kernel indicando colisión de direcciones: "kernel: IPv4: host 10.120.40.50 received ARP duplicate from...".
- Inconsistencia en el Default Gateway: La tabla ARP del switch multicapa alternaba constantemente la dirección física (MAC address) asociada a la IP 10.120.40.50 entre dos interfaces físicas diferentes.
Metodología de Diagnóstico Capa por Capa
Para aislar la causa raíz sin introducir disrupciones adicionales en la infraestructura, se aplicó una metodología de resolución descendente basada en el modelo OSI, descartando metódicamente vectores de falla potenciales:
Capa 1 (Física): Se inspeccionó la integridad del cableado estructurado y la telemetría óptica de los transceptores SFP+ en las interfaces de distribución. Los contadores de errores en interfaces (CRC, Input Errors, Runts, Giants) se mantuvieron en cero. Los niveles de potencia óptica (Tx/Rx DDM) operaban dentro de los umbrales nominales (-2.1 dBm a -3.4 dBm). La capa física fue descartada como origen del problema.
Capa 2 (Enlace de Datos): Se analizó la topología de árbol de expansión (Rapid Spanning Tree Protocol, RSTP). No se detectaron transiciones de estado de topología (Topology Change Notifications, TCNs) en la VLAN 120, descartando la presencia de un bucle de Capa 2. Sin embargo, al inspeccionar el comportamiento de la tabla de direcciones MAC (CAM table) en el switch de agregación, se evidenció un evento severo de MAC Flapping. Dos direcciones de Capa 2 distintas estaban asociándose alternativamente a puertos de acceso diferentes, pero reclamando la misma identidad de Capa 3 mediante anuncios Gratuitous ARP (GARP).
Capa 3 (Red): En este estrato se confirmó la naturaleza del conflicto. El protocolo ARP opera sin estado ni autenticación intrínseca. Se identificó la coexistencia de dos dispositivos respondiendo a las solicitudes de tipo ARP Request (Who has 10.120.40.50?): el servidor legítimo de base de datos con MAC 00:50:56:b3:4a:11 y un segundo host no inventariado con MAC b4:96:91:2c:88:ef. La latencia y las rutas de Capa 2 determinaban cuál de los dos dispositivos respondía primero, envenenando alternadamente la memoria caché ARP del gateway y de los servidores adyacentes.
Capa 4 (Transporte): El análisis de capturas de paquetes (PCAP) reveló retransmisiones masivas de segmentos TCP SYN y números de secuencia fuera de orden. Las conexiones se abortaban debido a que los paquetes de datos dirigidos a la IP 10.120.40.50 llegaban a un host espurio cuyo stack TCP/IP respondía de inmediato con flags RST-ACK, al no reconocer los números de puerto ni el identificador de sesión existente.
Comandos de Inspección y Análisis de Resultados
A continuación se detallan los comandos de diagnóstico ejecutados en los conmutadores de núcleo y en el servidor afectado, junto con el análisis técnico de las salidas obtenidas.
En el switch de distribución SW-CORE-01, se procedió a verificar la tabla ARP activa para la IP comprometida:
SW-CORE-01# show ip arp vlan 120 | include 10.120.40.50
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.120.40.50 0 b496.912c.88ef ARPA Vlan120
SW-CORE-01# show ip arp vlan 120 | include 10.120.40.50
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.120.40.50 0 0050.56b3.4a11 ARPA Vlan120El temporizador de antigüedad (Age) en cero minutos y la alternancia de direcciones MAC en ejecuciones consecutivas confirmaron el envenenamiento bidireccional de la tabla ARP. Posteriormente, se rastreó la localización física de ambas direcciones MAC en la tabla de conmutación de Capa 2:
SW-CORE-01# show mac address-table address 0050.56b3.4a11
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
120 0050.56b3.4a11 DYNAMIC Port-channel10
SW-CORE-01# show mac address-table address b496.912c.88ef
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
120 b496.912c.88ef DYNAMIC GigabitEthernet1/0/38El resultado reveló que la dirección legítima (OUI de VMware: 00:50:56) ingresaba a través del Port-channel10 conectado a los chasis de virtualización de producción. Por el contrario, la dirección en conflicto (OUI correspondiente a hardware físico HP: b4:96:91) provenía de la interfaz de acceso directo GigabitEthernet1/0/38.
En el servidor Linux legítimo, se ejecutó la herramienta arping para enviar solicitudes de Capa 2 forzadas y validar la duplicidad desde la perspectiva del host:
[root@DB-CORE-PROD01 ~]# arping -I ens192 -c 3 10.120.40.50
ARPING 10.120.40.50 from 10.120.40.50 ens192
Unicast reply from 10.120.40.50 [B4:96:91:2C:88:EF] 0.842ms
Unicast reply from 10.120.40.50 [B4:96:91:2C:88:EF] 0.789ms
Sent 3 probes (1 broadcast, 2 unicast)
Received 2 response(s)La recepción de respuestas unicast con una dirección MAC foránea confirmó la violación de unicidad estipulada en el RFC 5227 (IPv4 Address Conflict Detection).
Causa Raíz Identificada y Solución Definitiva
Causa Raíz: Durante una ventana de mantenimiento previa no autorizada por el comité de cambios (CAB), un ingeniero de infraestructura física conectó un servidor de pruebas fuera de servicio en el puerto de acceso GigabitEthernet1/0/38. Dicho servidor mantenía una configuración estática obsoleta de red asignada previamente en un entorno de laboratorio temporal que compartía el mismo esquema de direccionamiento. Al encenderse el equipo, su sistema operativo envió tramas Gratuitous ARP al segmento, reclamando la IP 10.120.40.50 e interceptando el tráfico productivo.
Plan de Remediación y Solución Ejecutada:
1. Aislamiento Inmediato del Puerto Ofensor: Como medida de contención de emergencia, se procedió al bloqueo administrativo de la interfaz responsable del tráfico corruptor:
SW-CORE-01(config)# interface GigabitEthernet1/0/38
SW-CORE-01(config-if)# description QUARANTINE_ROGUE_DEVICE_INCIDENT_88421
SW-CORE-01(config-if)# shutdown2. Purga y Normalización de Tablas ARP y CAM: Para forzar la re-convergencia inmediata del tráfico hacia el servidor legítimo sin esperar el vencimiento natural de los timers (Aging time por defecto: 300 segundos para MAC y 14400 segundos para ARP), se eliminaron las entradas inválidas:
SW-CORE-01# clear ip arp 10.120.40.50
SW-CORE-01# clear mac address-table dynamic address b496.912c.88ef3. Refresco Forzado desde el Servidor Legítimo: Se forzó al servidor productivo a emitir un anuncio GARP limpio para actualizar de forma determinista la tabla de conmutación de los switches adyacentes:
[root@DB-CORE-PROD01 ~]# arping -U -c 3 -I ens192 10.120.40.504. Implementación de Mecanismos de Seguridad Definitivos (Hardening): Para prevenir de forma proactiva la recurrencia de este vector de falla, se implementaron controles criptográficos y de inspección en todos los puertos de acceso de la infraestructura:
- Dynamic ARP Inspection (DAI): Se activó la inspección dinámica de ARP en la VLAN 120. DAI intercepta todas las solicitudes y respuestas ARP en puertos no confiables (Untrusted) y valida su correspondencia contra la base de datos de DHCP Snooping o una lista estática de acceso ARP (ARP ACL) previamente autorizada.
- DHCP Snooping e IP Source Guard: Se configuraron políticas para denegar cualquier tráfico IP originado en puertos de acceso cuya combinación de IP/MAC no esté explícitamente validada en el enlace de enlace de datos.
A continuación se presenta la plantilla de configuración aplicada a los switches de Capa 2 para blindar el segmento de servidores:
SW-CORE-01(config)# ip dhcp snooping
SW-CORE-01(config)# ip dhcp snooping vlan 120
SW-CORE-01(config)# ip arp inspection vlan 120
SW-CORE-01(config)# ip arp inspection validate src-mac dst-mac ip
! Definición de enlaces ascendentes confiables
SW-CORE-01(config)# interface Port-channel10
SW-CORE-01(config-if)# ip dhcp snooping trust
SW-CORE-01(config-if)# ip arp inspection trustTras la aplicación de los controles, las pruebas de transmisión ICMP sostenidas mostraron un 0% de pérdida de paquetes a lo largo de 10,000 muestras consecutivas, con una desviación estándar de latencia inferior a 0.2 ms. Las métricas de transacciones en la base de datos retornaron a sus valores operativos normales, dándose por normalizado el incidente y formalizándose el informe de post-mortem para auditoría técnica.
