28 de abril de 2012

Publicar una ruta por defecto con EIGRP

En un post anterior revisé el concepto de ruta por defecto y su configuración utilizando una ruta estática. La configuración estática genera un desafío: cómo instalar una ruta por defecto en todos los dispositivos de enrutamiento de una red de medianas proporciones.
Una de las posibilidades es utilizar el protocolo de enrutamiento dinámico implementado en la red para esa tarea.
En primer lugar, analizaré cómo hacer esto en redes que implementan EIGRP como protocolo de enrutamiento.
Consideraciones a tener en cuenta
Un router puede utilizar una ruta de salida por defecto de la red en 2 modalidades diferentes:
  • Una ruta por defecto configurada estáticamente.
  • Una red de destino instalada en la tabla de enrutamiento que es utilizada como "gateway of last resort" para enviar a través de ella todo el tráfico que tiene como destino una ruta que está "fuera" de la red.
EIGRP permite operar del segundo modo mencionado. Es decir, seleccionar una ruta que está presente en la tabla de enrutamiento del router y que oficiará como puerta de enlace hacia la red externa, y publicarla hacia los demás dispositivos de la red interior como gateway of last resort.
Cómo funciona en EIGRP
En el router de borde se define una red por defecto que será la puerta de salida (ip default-network).
  • La red seleccionada debe estar incluida en la tabla de enrutamiento del router de borde como una red de destino posible.
  • La ruta a esta red debe ser publicada por EIGRP.
  • EIGRP etiqueta esta ruta y la publica hacia los demás routers del dominio EIGRP.
  • Los routers interiores del dominio de enrutamiento aprenderán la ruta a la red definida como puerta de salida, y la marcarán como "gateway of last resort".
Un ejemplo:
Para el ejercicio supondremos que el router Borde está enlazado con el router ISP a través de la red 200.1.1.0/24, y que la Red Stub utiliza la red 172.16.0.0 con una máscara de subred de 24 bits.
Configuración del Router Borde:
router eigrp 100
 network 200.1.1.0
 network 172.16.0.0
 ip default-network 200.1.1.0
Configuración del Router Stub
router eigrp 100
 network 172.16.0.0
Tabla de enrutamiento del Router Borde:
...
C*  200.1.1.0/24 is directly connected, Serial 0/0/0
    172.16.0.0/24 is variably subnetted, 4 subnets, 1 mask
C        172.16.1.0/24 is directly connected, Serial 0/0/1
C        172.16.2.0/24 is directly connected, Serial 0/1/0
...
Tabla de enrutamiento del Router Stub
...
Gateway of last resort is 172.16.1.2 to network 0.0.0.0
...
D*  200.1.1.0/24 [90/1051263] via 172.16.1.2, 00:01:01, Serial 0/0/1

      172.16.0.0/24 is variably subnetted, 4 subnets, 1 mask
C        172.16.1.0/24 is directly connected, Serial 0/0/1
...

Para simplificar, en este ejemplo he incluido solamente las rutas que hacen al feature que estamos describiendo.



Otros posts a considerar:


5 comentarios:

  1. Muy bueno, gracias por el aporte. Siempre se los revisa.

    ResponderEliminar
  2. Eso no funciona ya que los paquete seran enrutados siempre a Borde y este no conoce las rutas de ISP. Recuerden tanto como Borde e ISP pertenecen a la red 200.1.1.0/24

    ResponderEliminar
    Respuestas
    1. OSman.
      Si pruebas el comando, verás que paralelamente crea en el router de borde una ruta por defecto hacia el ISP.
      Si haces un laboratorio y lo pruebas, verás que funciona.

      Eliminar
  3. Probé los comandos antes de publicar. No tengo los equipos físicos por lo que hice la prueba en packt tracer. La unica manera con la que pude comunicarme con las redes conectas a ISP fue creando una ruta estatica en Borde para que reenviara todos los paquetes a ISP.

    Borde(conf)#ip route 0.0.0.0 0.0.0.0 s0/0/0
    Lo que sucede es que la ruta que propaga EIGRP como candidata a Ruta por defecto (200.1.1.0/24) incluye a los dos routers tanto a Borde como a ISP. Entonces al momento de intentar comunicarse hacia un host de las redes de ISP desde el router de Red Stub evian el paquete hacia 200.1.1.0/24 y quien procesa el paquete es Borde NO ISP. Con la ruta por defecto que hice pudo solucionar eso. No se si será la solución mejor

    ResponderEliminar
    Respuestas
    1. OSman
      Lo que te ocurrió es que Packet Tracer es un simulador, no es IOS. Estas cosas hay que probarlas directamente en IOS.
      Por supuesto que el salto previo a la salida de los paquetes hacia Internet debe ser el router Borde, y si ese no tiene ruta hacia el ISP no tiene forma de reenviar ese tráfico.

      Eliminar

Gracias por tu comentario.
En este blog los comentarios están moderados, por lo que su publicación está pendiente hasta la revisión del mismo.