Saltar a contenido

🗺️ Lab 07: Ruteo Estático — Múltiples Saltos

En el lab anterior configuraste rutas entre dos routers y todo funcionó. Ahora viene el escenario que confunde a casi todos: tres routers en cadena.

La trampa no está en la sintaxis — ya la sabés. Está en entender qué router necesita qué ruta.


🏗️ Topología

name: "lab-07-ruteo-multisalto"
nodes:
  - name: PC-A
    type: HOST
    x: 50
    y: 200
  - name: R1
    type: ROUTER
    x: 250
    y: 200
  - name: R2
    type: ROUTER
    x: 450
    y: 200
  - name: R3
    type: ROUTER
    x: 650
    y: 200
  - name: PC-B
    type: HOST
    x: 850
    y: 200
links:
  - source: PC-A
    target: R1
  - source: R1
    target: R2
  - source: R2
    target: R3
  - source: R3
    target: PC-B

Cuatro redes:

PC-A ──── R1 ──── R2 ──── R3 ──── PC-B
  192.168.1.0/24  10.1.0.0/30  10.2.0.0/30  192.168.2.0/24
Red Rango Quiénes
Red A 192.168.1.0/24 PC-A + R1 eth1
Enlace 1 10.1.0.0/30 R1 eth2 + R2 eth1
Enlace 2 10.2.0.0/30 R2 eth2 + R3 eth1
Red B 192.168.2.0/24 R3 eth2 + PC-B

🛠️ Paso 1: Configurar IPs

En PC-A:

ip addr add 192.168.1.10/24 dev eth1
ip link set eth1 up
ip route add default via 192.168.1.1

En R1:

ip addr add 192.168.1.1/24 dev eth1
ip addr add 10.1.0.1/30 dev eth2
ip link set eth1 up
ip link set eth2 up

En R2:

ip addr add 10.1.0.2/30 dev eth1
ip addr add 10.2.0.1/30 dev eth2
ip link set eth1 up
ip link set eth2 up

En R3:

    ip addr add 10.2.0.2/30 dev eth1
ip addr add 192.168.2.1/24 dev eth2
ip link set eth1 up
ip link set eth2 up

En PC-B:

ip addr add 192.168.2.10/24 dev eth1
ip link set eth1 up
ip route add default via 192.168.2.1


❌ Paso 2: El error clásico — configurar solo los extremos

La mayoría arranca así: "tengo que conectar Red A con Red B, entonces configuro R1 y R3".

# En R1 — "para llegar a Red B, el próximo salto es R2"
ip route add 192.168.2.0/24 via 10.1.0.2

# En R3 — "para llegar a Red A, el próximo salto es R2"
ip route add 192.168.1.0/24 via 10.2.0.1

Parece completo. Probá el ping:

# Desde PC-A
ping -c 3 192.168.2.10

Falla. Pero esta vez el error es distinto: no es un Unreachable inmediato — los paquetes desaparecen como si nadie los recibiera.


🔬 Paso 3: Rastrear dónde muere el paquete

Hacé clic derecho en el cable que une R2 con R3, seleccioná Sniff R2, y repetí el ping.

Los paquetes llegan a R2. Significa que R1 los está enviando correctamente. El problema está en R2.

Mirá la tabla de ruteo de R2:

# En R2
ip route show
10.1.0.0/30 dev eth1 proto kernel   ← Enlace 1 (directamente conectado)
10.2.0.0/30 dev eth2 proto kernel   ← Enlace 2 (directamente conectado)

R2 solo conoce sus dos enlaces. No sabe nada de Red A (192.168.1.0/24) ni de Red B (192.168.2.0/24).

Cuando llega un paquete de PC-A con destino 192.168.2.10: 1. R2 recibe el paquete 2. Busca en su tabla una ruta hacia 192.168.2.0/24 3. No encuentra nada 4. Descarta el paquete silenciosamente

El punto clave: R2 no es un extremo del camino — es un intermediario. Pero igual necesita saber adónde reenviar los paquetes que pasan por él. No alcanza con que R1 y R3 sepan la ruta. Cada router del recorrido necesita su propia tabla completa.


🔑 Paso 4: Corregir R2

R2 necesita rutas hacia las dos redes que no tiene conectadas directamente:

# En R2 — para llegar a Red A, el próximo salto es R1
ip route add 192.168.1.0/24 via 10.1.0.1

# En R2 — para llegar a Red B, el próximo salto es R3
ip route add 192.168.2.0/24 via 10.2.0.2

Ahora el ping:

# Desde PC-A
ping -c 4 192.168.2.10

Funciona.


📋 Paso 5: El mapa completo de rutas

Para que quede claro, este es el estado final de cada tabla:

R1 necesita saber llegar a lo que no tiene conectado: Red B y Enlace 2.

192.168.1.0/24 dev eth1    ← propia (automática)
10.1.0.0/30    dev eth2    ← propia (automática)
192.168.2.0/24 via 10.1.0.2  ← estática hacia Red B
10.2.0.0/30    via 10.1.0.2  ← estática hacia Enlace 2 (necesaria para llegar a R3)

R2 necesita saber llegar a lo que no tiene conectado: Red A y Red B.

10.1.0.0/30 dev eth1       ← propia (automática)
10.2.0.0/30 dev eth2       ← propia (automática)
192.168.1.0/24 via 10.1.0.1  ← estática hacia Red A
192.168.2.0/24 via 10.2.0.2  ← estática hacia Red B

R3 necesita saber llegar a lo que no tiene conectado: Red A y Enlace 1.

10.2.0.0/30    dev eth1    ← propia (automática)
192.168.2.0/24 dev eth2    ← propia (automática)
192.168.1.0/24 via 10.2.0.1  ← estática hacia Red A
10.1.0.0/30    via 10.2.0.1  ← estática hacia Enlace 1

La regla general: para cada red que existe en el escenario, cada router necesita tener una ruta hacia ella — ya sea directamente conectada (automática) o estática. Si algún router no tiene ruta hacia el destino O hacia el origen de vuelta, el paquete muere ahí.


🔭 Paso 6: Verificar el recorrido con traceroute

traceroute te muestra exactamente por qué routers pasa un paquete:

# Desde PC-A
traceroute 192.168.2.10

Deberías ver algo así:

1  192.168.1.1   (R1)
2  10.1.0.2      (R2)
3  10.2.0.2      (R3)
4  192.168.2.10  (PC-B)

Si R2 no tiene las rutas, el traceroute se va a cortar en el salto 2 con * * * — exactamente donde muere el paquete.


🧩 Desafío

Eliminá la ruta de R1 hacia 10.2.0.0/30 y verificá si el ping a PC-B sigue funcionando. Pensá antes de probarlo: ¿R1 la necesita?

Respuesta No la necesita. R1 solo manda paquetes a R2 (`10.1.0.2`), que está en `10.1.0.0/30` — directamente conectado. No necesita saber explícitamente cómo llegar a `10.2.0.0/30` porque nunca manda paquetes directamente ahí. La ruta `192.168.2.0/24 via 10.1.0.2` alcanza: R1 sabe que para Red B le pasa el paquete a R2, y R2 ya se encarga del resto.

💡 Concepto Clave: el ruteo estático escala mal — en una red grande, configurar todas las rutas manualmente en cada router es inmanejable. Para eso existe el ruteo dinámico (OSPF, BGP), donde los routers aprenden las rutas entre ellos automáticamente. Lo verás en el Nivel 2.