Pruebas de pérdida de conectividad si cambiamos la IP del gateway

Fecha: 1 de junio del 2023

Escenario

Este escenario enfoca en que cuando configuramos un dispositivo, configuramos IP, máscara y gateway (el DNS

aquí no lo necesitamos), pero lo que realmente utilizamos del gateway (o puerta de enlace predeterminada) no es

la IP sino la dirección MAC, el host “convierte” la dirección IP en la dirección MAC a través una consulta de ARP

y así poder enviar una trama en layer 2 al router.

Entonces, la pregunta es ¿una vez que generamos tráfico de extremo a extremo y cambiamos la IP del gateway,

la comunicación se interrumpe? Manos a la obra…

Otra pregunta antes de comenzar: ¿Por qué cambiaríamos la IP del gateway? Las respuestas pueden ser varias,

desde error humano, una migración de routers en horario de producción, o que pisen una running con una versión

que tenga otra IP, etc… Lo dejo a la imaginación de cada uno, lo importante es el concepto de la prueba.

1.- Verificación inicial:

Las direcciones MAC de origen y destino siempre serán dentro de cada segmento local (LAN) separadas por un router

o un switch de layer 3, o sea que en este escenario utilizaremos 4 direcciones MAC, aunque en este router ambas MAC

son iguales, total están en LANs separadas, lo que no tiene ningún impacto.

Las direcciones IP de origen y destino son las de ambas PCs, las direcciones IP de los gateways (routers o switches de

layer 3) no intervienen, salvo para responder peticiones ARP para obtener su dirección MAC.

Una vez aprendida la dirección MAC del gateway la comunicación es de MAC a MAC en layer 2

en cada segmento en ambas “patas” del router, y de IP a IP en layer 3 (de host a host).

El retorno es similar:

En el ejemplo anterior, para simplificar, sólo se muestran los campos más relevantes de cada

capa utilizados para establecer la comunicación, a continuación veremos la trama/paquete en

detalle y no encontraremos ninguna referencia a la IP del default gateway

Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface id 0

Ethernet II, Src: 00:1b:38:7e:f1:71, Dst: 70:81:05:b5:77:82 (layer 2 del modelo OSI)

Destination: 70:81:05:b5:77:82 (la dirección MAC del gateway)

Source: 00:1b:38:7e:f1:71 (la dirección MAC de PC1)

Type: IPv4 (0x0800)

Internet Protocol Version 4, Src: 192.168.1.100, Dst: 192.168.2.100 (layer 3 del modelo OSI)

0100 .... = Version: 4

.... 0101 = Header Length: 20 bytes (5)

Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)

Total Length: 60

Identification: 0x0534 (1332)

000. .... = Flags: 0x0

...0 0000 0000 0000 = Fragment Offset: 0

Time to Live: 128

Protocol: ICMP (1)

Header Checksum: 0xb074 [validation disabled]

[Header checksum status: Unverified]

Source Address: 192.168.1.100

Destination Address: 192.168.2.100 (la dirección de PC2)

Internet Control Message Protocol (payload ICMP)

1.1.- En el router:

1.1.1.- Verificamos las IP:

Gateway#sh ip int brief

Interface IP-Address OK? Method Status Protocol

FastEthernet1 unassigned YES unset up up

FastEthernet2 unassigned YES unset up up

Vlan1 192.168.1.1 YES manual up up

Vlan2 192.168.2.1 YES manual up up

Gateway#

1.1.2.- Verificamos la tabla ARP:

Gateway#sh arp

Protocol Address Age (min) Hardware Addr Type Interface

Internet 192.168.1.1 - 7081.05b5.7782 ARPA Vlan1

Internet 192.168.1.100 0 001b.387e.f171 ARPA Vlan1

Internet 192.168.2.1 - 7081.05b5.7782 ARPA Vlan2

Internet 192.168.2.100 0 001b.38fe.8ac7 ARPA Vlan2

Gateway#

1.2.- En la PC:

1.2.1.- Verificamos la IP:

C:\>ipconfig /all

Configuración IP de Windows

---resumido---

Adaptador de Ethernet Conexión de área local:

Sufijo DNS específico para la conexión. . :

Descripción . . . . . . . . . . . . . . . . . . . . : Conexión de red Intel (VE)

Dirección física. . . . . . . . . . . . . . . . . .: 00-1B-38-7E-F1-71

DHCP habilitado . . . . . . . . . . . . . . . . : no

Configuración automática habilitada : no

Dirección IPv4. . . . . . . . . . . . . . . . . . : 192.168.1.100

Máscara de subred . . . . . . . . . . . . . : 255.255.255.0

Puerta de enlace predeterminada . . : 192.168.1.1

NetBIOS sobre TCP/IP. . . . . . . . . . . : deshabilitado

---resumido---

1.2.2.- Verificamos la tabla ARP:

C:\>arp -a

Interfaz: 192.168.1.100 --- 0xb

Dirección de Internet Dirección física Tipo

192.168.1.1 70-81-05-b5-77-82 dinámico

224.0.0.22 01-00-5e-00-00-16 estático

224.0.0.251 01-00-5e-00-00-fb estático

C:\>

1.2.3.- Verificamos conectividad al gateway:

C:\>ping 192.168.1.1

Haciendo ping a 192.168.1.1 con 32 bytes de datos:

Respuesta desde 192.168.1.1: bytes=32 tiempo<1m TTL=255

1.2.4.- Verificamos conectividad al host remoto:

C:\>ping 192.168.2.100

Haciendo ping a 192.168.2.100 con 32 bytes de datos:

Respuesta desde 192.168.2.100: bytes=32 tiempo<1m TTL=63

2.- Prueba 1:

2.1.- Generamos tráfico al host remoto:

C:\>ping 192.168.2.100 -t

Haciendo ping a 192.168.2.100 con 32 bytes de datos:

Respuesta desde 192.168.2.100: bytes=32 tiempo<1m TTL=63

--- continúa ---

2.2.- Cambiamos la IP del Gateway:

Gateway#conf t

Gateway(config)#int vlan 1

Gateway(config-if)#ip add 192.168.1.2 255.255.255.0

Gateway(config-if)#

2.3.- Verificamos:

Respuesta desde 192.168.2.100: bytes=32 tiempo<1m TTL=63

Respuesta desde 192.168.1.100: Host de destino inaccesible. (se corta la conectividad…)

Respuesta desde 192.168.1.100: Host de destino inaccesible.

2.4.- Buscamos la causa:

Podemos observar que al cambiar la IP de la interface, se purga la tabla ARP y el router genera una petición ARP para aprender

la MAC de PC1, también la podría aprender en la próxima trama/paquete recibida, pero en todas las pruebas resultó igual.

También podemos ver que el router envía un ARP gratuito ya con la IP cambiada, esto tampoco cambia el escenario.

C:\>arp -a

Interfaz: 192.168.1.100 --- 0xb

Dirección de Internet Dirección física Tipo

192.168.1.2 70-81-05-b5-77-82 dinámico (ya no existe la entrada a 192.168.1.1)

224.0.0.22 01-00-5e-00-00-16 estático

224.0.0.251 01-00-5e-00-00-fb estático

C:\>

En la trama #12 podemos ver que PC1 solicita la MAC de su Gateway, aunque sin respuesta, la comunicación continúa.

En algún momento la entrada de la tabla ARP de la PC expira y esta genera una nueva solicitud, pero nadie va a responder debido

a que la IP 192.168.1.1 ya no existe en la red y en algún memento expira, causando la pérdida de conectividad.

3.- Prueba 2:

En esta prueba desactivamos el ARP gratuito en el router para no generarle “confusiones” a la PC1.

3.1.- Realizamos rollback:

Gateway#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Gateway(config)#int vlan 1

Gateway(config-if)#ip add 192.168.1.1 255.255.255.0

Gateway(config-if)#exit

Gateway(config)#

3.2.- Desactivamos el ARP gratuito:

Gateway(config)#no ip gratuitous-arps

Gateway(config)#

3.3.- Generamos tráfico al host remoto:

C:\>ping 192.168.2.100 -t

Haciendo ping a 192.168.2.100 con 32 bytes de datos:

Respuesta desde 192.168.2.100: bytes=32 tiempo<1m TTL=63

--- continúa ---

3.4.- Cambiamos la IP del Gateway:

Gateway(config)#int vlan 1

Gateway(config-if)#ip add 192.168.1.2 255.255.255.0

Gateway(config-if)#

3.5.- Verificamos:

Respuesta desde 192.168.2.100: bytes=32 tiempo<1m TTL=63

Respuesta desde 192.168.1.100: Host de destino inaccesible. (se corta la conectividad…)

Respuesta desde 192.168.1.100: Host de destino inaccesible.

3.6.- Buscamos la causa:

También podemos ver que el router envía un ARP gratuito ya con la IP cambiada, aunque lo hayamos desactivado, nuevamente lo

mencionamos, esto tampoco cambia el escenario.

Se repite el mismo proceso de expiración de la entrada en la tabla de ARP de PC1 y esta queda sin saber la MAC de su gateway.

C:\>arp -a

Interfaz: 192.168.1.100 --- 0xb

Dirección de Internet Dirección física Tipo

192.168.1.2 70-81-05-b5-77-82 dinámico (ya no existe la entrada a 192.168.1.1)

224.0.0.22 01-00-5e-00-00-16 estático

224.0.0.251 01-00-5e-00-00-fb estático

C:\>

4.- Prueba 3:

En esta prueba desactivamos con una segunda manera el ARP gratuito en el router para no generarle “confusiones” a la PC1.

4.1.- Realizamos rollback:

Gateway#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Gateway(config)#int vlan 1

Gateway(config-if)#ip add 192.168.1.1 255.255.255.0

Gateway(config-if)#exit

Gateway(config)#

4.2.- Desactivamos el ARP gratuito (variante 2):

Gateway(config)#no ip arp gratuitous

Gateway(config)#

4.3.- Generamos tráfico al host remoto:

C:\>ping 192.168.2.100 -t

Haciendo ping a 192.168.2.100 con 32 bytes de datos:

Respuesta desde 192.168.2.100: bytes=32 tiempo<1m TTL=63

--- continúa ---

4.4.- Cambiamos la IP del Gateway:

Gateway(config)#int vlan 1

Gateway(config-if)#ip add 192.168.1.2 255.255.255.0

Gateway(config-if)#

4.5.- Verificamos:

Respuesta desde 192.168.2.100: bytes=32 tiempo<1m TTL=63

Respuesta desde 192.168.1.100: Host de destino inaccesible. (se corta la conectividad…)

Respuesta desde 192.168.1.100: Host de destino inaccesible.

4.6.- Buscamos la causa:

También podemos ver que el router envía un ARP gratuito ya con la IP cambiada, aunque lo hayamos desactivado, nuevamente lo

mencionamos, esto tampoco cambia el escenario.

Se repite el mismo proceso de expiración de la entrada en la tabla de ARP de PC1 y esta queda sin saber la MAC de su gateway.

C:\>arp -a

Interfaz: 192.168.1.100 --- 0xb

Dirección de Internet Dirección física Tipo

192.168.1.2 70-81-05-b5-77-82 dinámico (ya no existe la entrada a 192.168.1.1)

224.0.0.22 01-00-5e-00-00-16 estático

224.0.0.251 01-00-5e-00-00-fb estático

C:\>

5.- Prueba 4:

En esta prueba generamos una entrada estática en la tabla ARP de la PC1 para que no expire.

5.1.- Realizamos rollback:

Gateway#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Gateway(config)#int vlan 1

Gateway(config-if)#ip add 192.168.1.1 255.255.255.0

Gateway(config-if)#exit

Gateway(config)#

5.2.- Configuramos el ARP estático en la PC:

5.2.1.- Intento 1…

C:\>arp -s 192.168.1.1 70-81-05-b5-77-82

Error en la adición de la entrada ARP: Acceso denegado. (y estoy como administrador…)

C:\>

5.2.2.- Intento 2…(desde PowerShell):

PS C:\Users\user> arp -s 192.168.1.1 70-81-05-b5-77-82

Error en la adición de la entrada ARP: Acceso denegado. (y estoy como administrador…)

PS C:\Users\user>

5.2.3.- Intento 3…

C:\>netsh -c "interface ipv4"

netsh interface ipv4>set neighbors "LAN" "192.168.1.1" "70-81-05-b5-77-82" (bué, anduvo…)

netsh interface ipv4>

5.2.4.- Verificamos:

C:\>arp -a

Interfaz: 192.168.1.100 --- 0xb

Dirección de Internet Dirección física Tipo (no hay entradas dinámicas)

192.168.1.1 70-81-05-b5-77-82 estático

224.0.0.22 01-00-5e-00-00-16 estático

224.0.0.251 01-00-5e-00-00-fb estático

239.255.255.250 01-00-5e-7f-ff-fa estático

C:\>

5.3.- Generamos tráfico al host remoto:

C:\>ping 192.168.2.100 -t

Haciendo ping a 192.168.2.100 con 32 bytes de datos:

Respuesta desde 192.168.2.100: bytes=32 tiempo<1m TTL=63

--- continúa ---

5.4.- Cambiamos la IP del Gateway:

Gateway(config)#int vlan 1

Gateway(config-if)#ip add 192.168.1.2 255.255.255.0

Gateway(config-if)#

5.5.- Verificamos:

5.5.1.- En la PC:

Respuesta desde 192.168.2.100: bytes=32 tiempo<1m TTL=63

Estadísticas de ping para 192.168.2.100:

Paquetes: enviados = 201, recibidos = 201, perdidos = 0 (0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

Mínimo = 0ms, Máximo = 0ms, Media = 0ms

Control-C

5.5.2.- En el router:

Gateway#sh arp

Protocol Address Age (min) Hardware Addr Type Interface

Internet 192.168.1.2 - 7081.05b5.7782 ARPA Vlan1

Internet 192.168.1.100 0 001b.387e.f171 ARPA Vlan1

Internet 192.168.2.1 - 7081.05b5.7782 ARPA Vlan2

Internet 192.168.2.100 5 001b.38fe.8ac7 ARPA Vlan2

Gateway#

5.6.- Buscamos si hubo transacciones ARP:

No hubo transacciones ARP, tampoco hubo ofrecimientos de ARP gratuito…

5.7.- Realizamos rollback de la entrada estática:

C:\>arp -d 192.168.1.1

C:\>

5.8.- Verificamos:

C:\>arp -a

Interfaz: 192.168.1.100 --- 0xb

Dirección de Internet Dirección física Tipo

192.168.1.2 70-81-05-b5-77-82 dinámico (la entrada con la IP cambiada aprendida por el ARP gratuito, ya

224.0.0.22 01-00-5e-00-00-16 estático que la PC1 buscó a la IP 192.168.1.1 vía ARP y no la encontró,

224.0.0.251 01-00-5e-00-00-fb estático pero el router ofreció gratuitamente la petición con su IP nueva)

239.255.255.250 01-00-5e-7f-ff-fa estático

6.- Resumen:

- Confirmamos que la configuración de la IP de Gateway es únicamente para poder resolver el ARP y obtener la MAC.

- Confirmamos que el gateway genera un ARP gratuito al cambiar la IP.

- El host corre un proceso de renovación de su propia tabla ARP, si la entrada de la MAC de su gateway configurado

expira, comienza la pérdida de conectividad.

- Si configuramos la IP y MAC del Gateway manualmente en la tabla ARP, no perderemos conectividad con el mismo.

- Esta es sólo una prueba de concepto y no aplicaría a un caso práctico y útil en una red en producción, la realidad es

que no se puede escapar fácilmente de los ARP (y sus potenciales dolores de cabeza…)

(2023) MAC address is not a Scottish surname

Rosario, Argentina