OSPF - JNCIP - MISCELÁNEA

CAMBIO DE PROTOCOLO

Cuando nos surge la necesidad de cambiar de IGP en nuestra red, tenemos que tener en cuenta varias cosas. Lo primero es el diseño de la red. Un buen diseño nos evita problemas y facilita el mantenimiento. Hay que mantener la estabilidad de la red durante la transición de un protocolo a otro y minimizar el tiempo de caída de la red.

Durante una transición de protocolo, lo más probable es que tengamos que exportar información de enrutamiento entre uno y otro. Cuando dos protocolos conviven en una red, solo uno de los dos puede estar activo para el tráfico de tránsito, y Junos usa, como primer criterio para decidir, "Route Preference", que es el mismo concepto que en Cisco se llama Distancia Administrativa. Nos tenemos que asegurar que todos los equipos que participan en el enrutamiento tienen el mismo criterio de "Route Preference". En realidad, se le otorga preferencia a las rutas de un protocolo sobre las de otro.

Gana la preferencia más baja

Hay que poner mucha atención cuando exportamos rutas de un IGP a otro, ya que podríamos causar bucles o comportamientos extraños e ineficaces de los protocolos.

Juniper nos muestra 3 estrategias para una transición de protocolos:

• Overlay:

1. Configuramos en todos los routers para que el protocolo existente tenga mejor "Router Preference" que el nuevo que se va a implementar
2. Configuramos en todos los routers el nuevo protocolo
3. Verficamos que el nuevo protocolo tiene toda la tabla de rutas completa
4. Borramos el protocolo antiguo

• Route Redistribution:

1. Configuramos en todos los routers para que el protocolo existente tenga mejor "Router Preference" que el nuevo que se va a implementar
2. Configuramos el nuevo protocolo en los ABR (para establecer control de enrutamiento)
3. Configuramos el resto de routers
4. Borramos el antiguo protocolo

• Integrated:

1. Implementamos un nuevo Core con el nuevo protocolo
2. Conectamos los viejos Core con los nuevos (configuramos redistribución)
3. Configuramos el resto de routers
4. Se apagan los antiguos Core.

Vamos a ver un ejemplo de una transición Overlay de RIP a OSPF:

Configuramos el direccionamiento en las interfaces y las propagamos por RIP. Un ejemplo de un equipo:


root@vMX-1# run show configuration policy-options             
policy-statement EXP-RIP {
    term to-rip {
        from protocol [ direct rip ];
        then accept;
    }
}


root@vMX-1# run show configuration protocols        
rip {
    group RIP {
        export EXP-RIP;
        neighbor ge-0/0/0.0;
        neighbor ge-0/0/2.0;
        neighbor ge-0/0/3.0;
    }
}

Hay que exportar las conectadas y las que entrar por el propio RIP

Lo primero que vamos a hacer es darle a RIP una preferencia mejor que la de OSPF. Es decir, RIP tiene una preferencia de 100 y OSPF de 10.  Como las rutas estáticas tienen un 5 de preferencia, vamos a darle a RIP un 8, que es mejor que 10 y las rutas estáticas seguirían prevaleciendo sobre las rutas dinámicas:

• set protocols rip group RIP preference 8

Como vemos, el escenario de RIp es un escenario único. Para la configuración de OSPF vamos a crear varias áreas:

Configuramos OSPF sin temor a que se solape con RIP:

• set protocols ospf area X interface X - las loopback de vMX-1 y 2 en el área 0

Comprobamos en la tabla de rutas que OSPF está funcionando pero que es RIP el protocolo elegido para procesar el tráfico:

Una vez comprobado que todas las rutas nos llegan por el nuevo protocolo, deshabilitamos el antiguo y hacemos un "commit confirmed" de 5 minutos para comprobar. Ojo, no lo eliminamos, lo deshabilitamos para poder tener una "marcha atrás":

• deactivate protocols rip
• commit confirmed 5
• commit-and-quit (una vez comprobado que todo funciona)
• delete protocols rip (luego lo podemos eliminar)

VECINDADES MULTIÁREA


Por defecto, una interface solo pertenece a una única área OSPF. Puede surgir la necesidad de tener 2 o más áreas en una interface. Al hacer esto, permitimos que un mismo enlace pueda ser considerado una "intra-area" en múltiples áreas y ser elegido antes que otros enlaces con un coste superior. Cuando lo configuramos así, cada vecindad multiárea será propagado como un enlace "point-to-point unnumbered".

Para configurar una interface en varias áreas:

• set protocols ospf area 0 interface ge-0/0/0.0
• set protocols ospf area 1 interface ge-0/0/0.0 secondary

Un ejemplo de funcionalidad:

Si no levanta entre 1 y 2, configurad interface-type p2p

Tenemos una topología con una aŕea 0 entre vMX-1 y 2 con las interfaces ge-0/0/0. Y un área 25 con todos los routers en las interfaces ge-0/0/1 y 2.

De vMX-1 a vMX-3 hay un salto directo

Vemos una configuración normal de OSPF y nos encontramos con que se cae el enlace entre vMx-1 y 3 en las interfaces ge-0/0/1. En este escenario, si vMX-1 quiere llegar a vMX-3, ahora el tráfico se encaminaría hacia vMX-4, luego vMX-2 y finalmente vMX-3, es decir, 3 saltos.

Ahora de vMX-1 a vMX-3 hay 3 saltos directo

Si ahora configuramos en vMX-1 y 2 sus interfaces ge-0/0/0 para que pertenezcan al área 25 pero como secundarias, obtendremos que solo hay un salto haciendo más eficiente el routing.

• set protocols ospf area 25 interface ge-0/0/0.0 secondary
• show ospf interface

Se confifgura automáticamente un interface de tipo p2p

Ahora vMX-1 tiene 2 vecindades diferentes con vMX-2,una por cada área y, a vMX-2 le pasa lo mismo con vMX-1.




REDISTRIBUCIÓN


Para que OSPF propague las rutas tenemos que crear una política y aplicarla. Junos no lo hace por defecto.

Como las rutas externas tienen un escenario de "inter-area", las políticas son aplicadas en el nivel global de OSPF. Cuando una ruta externa ingresa en el dominio OSPF es considerada, por defecto, como un LSA de Tipo 5 y dentro de las externas, de Tipo 2. Esto podemos modificarlo en las políticas:


policy-options {
     policy-statement REDISTRIBUIR-ESTATICAS {
            term rutas-estaticas {
                             from protocols static;
                             then {
                                   external type 1;
                                   accept;
                             }
                    }
           }
}
protocols ospf {
       export REDISTRIBUIR-ESTATICAS;
}



Es especialmente sensible cuando tenemos que hacer redistribución a y desde diferentes protocolos en varios puntos de la red. Podemos caer en lo que se denomina "sub-optimal routing" y se pueden dar bucles.

Por lo general, si la fuente de la ruta tiene una preferencia más baja que el protocolo a donde lo redistribuimos, no hay problemas. Sin embargo, si la fuente tiene una preferencia más alta, pueden venir los problemas. Hay varios maneras de resolverlo aunque lo más fácil suele ser modificar los valores de preferencia de las rutas.


 Un ejemplo de Redistribución y de Integración en la parte de LABORATORIOS