OSPF - Rutas por defecto

Autor: Julio Moisa - CCIE R&S #52536
Email: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.

                                                                                  OSPF   DROUTE 

 

Una ruta por defecto es aquella ruta que se utiliza para conocer cualquier prefijo que no está siendo conocido a través de la tabla de enrutamiento ya sea de manera estática o dinámica por algún protocolo de enrutamiento, si no existiera una entrada específica para un prefijo de destino o una ruta por defecto, el paquete enviado hacia ese destino se descartaría. No nos vayamos muy lejos, el caso de Internet, Internet maneja miles y miles de prefijos, y no sería buena práctica intentar instalar esos prefijos en nuestras tablas de enrutamiento; para evitar eso utilizamos rutas por defecto, para proveer un camino a prefijos desconocidos. 

Las rutas por defecto son instaladas en los routers de borde para alcanzar Internet (aunque pueden ser utilizadas internamente para tareas específicas). Cada protocolo de enrutamiento dinámico tiene diferentes maneras de advertir o publicar las rutas por defecto, entre las cuales están redistribución de rutas estáticas, rutas sumarizadas, etc. En el caso de OSPF podemos también utilizar el siguiente comando: default-information originate para advertir una ruta por defecto, y podemos agregar el argumento 'always', dicho argumento advierte una ruta por defecto aunque el router no posea una entrada para la ruta por defecto en su tabla de enrutamiento. 

Trabajemos en el escenario que se muestra en este artículo, en el cual tenemos nuestra red interna conectada a 2 proveedores de Internet para redundancia de Internet. 

Nota: R1, R2, R3 y R4 utilizan el proceso 100 para OSPF.

OSPF   DROUTE1

 

R3 y R4 han sido configurados previamente, podemos revisar la tabla de enrutamiento y adyacencia de cada uno:

 

OSPF   DROUTE R3

OSPF   DROUTE R4

 

Podemos observar que tanto R3 como R4 tienen una ruta por defecto en sus tablas de enrutamiento, todo luce bien :-)  , por defecto prefijos externos siendo redistribuidos dentro de un ASBR o la publicación de una ruta por defecto por un router OSPF, serán advertidos a sus vecinos como rutas externas tipo 2 (E2).

Ahora preguntémonos porque R3 y R4 solo poseen una ruta por defecto; Claramente no existe igualdad de caminos hacia cada proveedor, y siendo más técnicos podemos observar lo siguiente y tomemos como ejemplo a R4:

 

OSPF   DROUTE R4 2

 

Podemos observar que en la base de datos existen 2 entradas para la ruta por defecto 0.0.0.0 (como externas - LSA tipo 5), pero en la tabla de enrutamiento solo hay una entrada entonces ¿qué sucede?, solo por deporte apaguemos la interface en R2 que conecta con el proveedor 2, y observemos el comportamiento en R4.

 

OSPF   DROUTE R4 3

 

Se logra observar que la ruta por defecto es conocida únicamente a través de R3 para luego llegar a R1. En ambas pantallas podemos observar que la métrica de las rutas por defecto advertidas por R1 y R2 es 1. Pero entonces ¿porque no aparecían ambas rutas en la tabla de enrutamiento? es ahí donde entra la línea: forward metric, esta línea se utiliza para romper empates de rutas del tipo E2 con la misma métrica redistribuidas. Forward Metric es básicamente las métricas utilizadas para llegar al ASBR. 

En nuestro caso ambas rutas por defecto eran publicadas con métricas de 1, pero desde R4 hacia R1 tenemos un costo de 20 y hacia R2 tenemos un costo de 10, por ende no existe igualdad de caminos y R2 es preferido como el camino primario. Lo mismo sucede con R3. 

Como un buen diseño es ideal tener un tráfico simétrico, configuremos R2 para el camino primario hace Internet sea a través de R1, aprenderemos a manipular el tráfico de 2 maneras:

 

1) Incrementando la métrica de la ruta por defecto en R2, la métrica actual es de 1, incrementémosla a 2 y veamos que sucede en R4.

 

OSPF   DROUTE R2 1

OSPF   DROUTE R4 4

 

Se observan ambos prefijos en la base de datos de OSPF pero prefiere el prefijo con métrica 1. 

Regresamos todo como estaba antes y utilizamos el método 2 en R1.

2) Utilizar métrica externa tipo 1 (E1) en lugar de E2.

 

OSPF   DROUTE R4 5

 

Ok, una vez todo ha regresado la normalidad modificamos a R1 para publicar la ruta por defecto como E1, para dicho proceso utilizaremos un route-map con métrica E1 y el cual aplicaremos a la línea de comando default-information originate:

 

OSPF   DROUTE R1 1

 

Verifiquemos el resultado en R4:

 

OSPF   DROUTE R4 6

 

OSPF   DROUTE R4 7

 

Podemos observar que la ruta por defecto es preferida a través de R3  para luego llegar a R1, dicha entrada en la tabla de enrutamiento aparece como E1 y ya no se observa la línea forward metric, a continuación la explicación:

La diferencia entre E1 y E2 es la siguiente:

  • Los prefijos marcados como E2 únicamente son advertidas con la métrica de redistribución.
  • Los prefijos marcados como E1 son advertidas con la métrica de redistribución más el costo hacia el ASBR. Por ende nunca se mostrara la línea 'forward metric' en este tipo de prefijos debido a que ya se encuentran incluidos en la métrica advertida a los vecinos. 

OSPF siempre preferirá un prefijo marcado como E1 que un prefijo marcado como E2. 

 

Entre los objetivos de este tipo de implementaciones podemos destacar: alta disponibilidad, escalabilidad, efectividad y una administración más sencilla.

 

 

 

Registrate para comentar.

Visitas del artículo
95746