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
Respuesta desde 192.168.1.1: bytes=32
tiempo<1m TTL=255
Respuesta desde 192.168.1.1: bytes=32
tiempo<1m TTL=255
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
Respuesta desde 192.168.2.100: bytes=32
tiempo<1m TTL=63
Respuesta desde 192.168.2.100: bytes=32
tiempo<1m TTL=63
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
Respuesta desde 192.168.2.100: bytes=32
tiempo<1m TTL=63
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.2.100: bytes=32 tiempo<1m
TTL=63
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.
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
Respuesta desde 192.168.2.100: bytes=32
tiempo<1m TTL=63
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.2.100: bytes=32
tiempo<1m TTL=63
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.
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
Respuesta desde 192.168.2.100: bytes=32
tiempo<1m TTL=63
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.2.100: bytes=32
tiempo<1m TTL=63
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.
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
Respuesta desde 192.168.2.100: bytes=32
tiempo<1m TTL=63
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
Respuesta desde 192.168.2.100: bytes=32
tiempo<1m TTL=63
Respuesta desde 192.168.2.100: bytes=32
tiempo<1m TTL=63
Respuesta desde 192.168.2.100: bytes=32
tiempo<1m TTL=63
Respuesta desde 192.168.2.100: bytes=32
tiempo<1m TTL=63
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
^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