Capítulo 10: Protocol-Independent Routing

RUTAS ESTÁTICAS

Ya sabemos que las rutas estáticas se pueden usar para diferentes soluciones, incluidas las rutas por defecto para los Sistemas Autónomos (AS). Siempre se tendrán que configurar manualmente las redes a las que se quiere llegar.

CONFIGURACIÓN DE RUTAS ESTÁTICAS

Todas las configuraciones de rutas estáticas se hacen bajo el nivel de configuración "edit routing-options". Una ruta estática básica tiene una dirección (prefijo) de destino y el siguiente salto VÁLIDO para llegar a ella. En los enlaces P2P se puede especificar la interfaz por donde sale en vez de la dirección ip, pero si es un enlace ethernet deberemos especificar la dirección ip.

Otra posibilidad para configurar un "siguiente salto válido" (valid next hop) es enviarlo a un "bit bucket" (podríamos traducirlo como el pozo sin fondo donde se pierden los bits...). En Junos la manera para representar el descarte de los paquetes es con "reject" o "discard" (rechazar o descartar). Ambas opciones "tiran el paquete". La diferencia entre estas dos acciones está en que con reject como "next-hop", el sistema manda un mensaje ICMP al origen notificando que no se ha alcanzado la red que se pretendía. Con discard no se manda ningún mensaje.

Las rutas estáticas  permanecen en el equipo hasta que las eliminamos manualmente o se vuelven inactivas, como por ejemplo cuando el next hop no es alcanzable.

Al contrario de otros vendedores, Junos no hace un "lookup" o búsqueda de los propios next hops para ver si son alcanzables. Sin embargo, podemos configurarlo para que sí que haga el "lookup", incluyendo en la ruta estática la palabra resolve.

Otra opción que nos da para configurar las estáticas es la posibilidad de tener varios next hop para llegar a un destino pero preferimos que se use siempre uno antes si está disponible. Para ello tendremos que configurar el qualified-next-hop:

Las rutas estáticas asumen una preferencia de 5. En el ejemplo de arriba el tráfico preferirá ir por la 172.30.25.1, pues el "qualified-next-hop" tiene configurada una "preference" más alta (7). Recordad que la elegirá siempre y cuando esté activa y, solo cuando esta no esté activa usará la 172.30.25.5. A esto Cisco le llama la "ruta estática flotante".

Otra opción es el "next-table", donde le decimos al equipo que mire o haga "lookup" en otras tablas de rutas del equipo. No todos los Junos admiten esta posibilidad.

EJEMPLO CONFIGURACIÓN DE RUTAS ESTÁTICAS

Aquello que configuremos debajo de "defaults" se aplicará a todas las rutas de IPv4 que no tengan esa configuración más específica. En el ejemplo se configura la "preference" pero tenemos más opciones:

• As-Path: se usa para redistribuir una ruta hacia BGP con unos atributos específicos
• Community: se usa para añadir valores de "community" en la ruta BGP
• Metric: si varias rutas tienen la misma "preference" hacia destino, elegirá la ruta con mejor métrica. Con este atributo podemos influir.
• Preference: por defecto para las rutas estáticas es 5. Se usa para modificar la preference y dar prioridad a otras rutas.



Como podemos ver en la configuración, a las rutas estáticas se les configura una preference de 180 para aquellas que no tengan nada específico configurado como la 172.30.25.1. Sin embargo, vemos un "siguiente salto válido" (qualified-next-hop) que tiene configurado una preference de 7, por lo que al tener una preference menor, elegirá la 172.30.25.5 como siguiente salto para la ruta estática 0.0.0.0/0.

La ruta estática 172.29.13.0 no será exportada; las demás estáticas sí.



RUTAS AGREGADAS

Juniper llama rutas agregadas a lo que Cisco llama sumarización. Consiste en combinar un grupo de direcciones en una sola dirección. Así, reducimos el número de rutas que propagamos y, por lo tanto, también reducimos el tamaño de la tabla de rutas. Una segunda ventaja es que como solo propagamos el agregado, evitamos que se propague la posible inestabilidad del enrutamiento interno.

La 172.29.0.0/22 aglutina las otras 3 rutas de tipo 172.29.X.X/24 (subnetting)

NOTA:  Si no domináis el subnetting, ya es hora de que os pongáis en serio con ello.

Para configurar un agregado:





Es importante recordar que un agregado está activo siempre y cuando haya alguna ruta de las que combina que esté a su vez también activa en la tabla de rutas.

Por defecto, el agregado tiene asignado una preference de 130 y el siguiente salto válido como "reject". Esto es modificable, por supuesto.

Si un equipo que propaga una agregado recibe un paquete con destino a una de las redes más específicas que combina el agregado, pero esta red no existe, el equipo descartará el paquete y notificará por ICMP al origen.





 En este ejemplo de configuración, la ruta hacia la 172.25.0.0/16 usará la community 1:999 y la ruta que no tiene nada específico configurado, la 172.29.0.0/22 usará la 1:888.

Por defecto, los agregados tienen configurado "reject", que descarta los paquetes notificando a origen. Sin embargo, en la ruta 172.25.0.0/22 configuramos "discard" y no notificará.


Opciones para configurar en el agregado:

As-Path: se usa para redistribuir una ruta hacia BGP con unos atributos específicos

Community: se usa para añadir valores de "community" en la ruta BGP

Metric: si varias rutas tienen la misma "preference" hacia destino, elegirá la ruta con mejor métrica. Con este atributo podemos influir.

Policy: capacidad para configurar políticas para aceptar o descartar rutas  

Preference: por defecto para las rutas agregadas es 130.

 
Para comprobar los agregados:

Vemos las rutas que contribuyen y el protocolo que las ha metido en la tabla de rutas

 El paquete A será enviado a su destino, pero el paquete B no, ya que aunque la subred 172.29.3./24 entra dentro del agregado 172.29.0.0/22, como R1 no tiene esa red activa, el paquete será descartado con el "reject" que tiene por defecto, notificando a origen este hecho.

 RUTAS GENERADAS

Las rutas generadas actúan igual que los agregados: para ser propagada tiene que tener al menos una ruta activa. Estas rutas son mostradas como si fueran un agregado:



La mayor diferencia entre rutas generadas y agregadas es que las generadas usan como siguiente salto válido el que tenga la ruta primaria de las que contribuyen a la generada. La ruta primaria de las que contribuyen es la que tenga la "preference" más baja y, si hay varias con las misma preference, la elegida es aquella que tenga el direccionamiento más bajo, es decir, se prefiere la 172.30.25.1 a la 172.30.26.1. Una ruta es elegida como "contribuyente" siempre que tenga un salto válido que no sea local del propio equipo. Si no, la clasificará como "hidden" (oculta).





 También son conocidas como "rutas de último recurso". Son usadas para activar una ruta por defecto cuando unas condiciones específicas son cumplidas a través de una "policy" (política).

Vamos a ver un ejemplo de cómo configurar una ruta generada y propagarla si se cumple una condición:

Definimos la pólítica:



Vemos dos políticas configuradas. La primera política, "match-contributing-prefix", establece las condiciones de BGP y la red exacta 10.0.0.0/16. En este ejemplo, todos los prefijos (redes, rutas) que tengan un "next-hop" que no pertenezcan al equipo local, son rutas que contribuyen a la ruta generada puesto que estamos usando una ruta por defecto (0.0.0.0/0).

La segunda política, "export-default", establece las condiciones de protocolo agregado y la ruta por defecto que declaramos anteriormente. 

Aplicamos la política:

Aplicamos la política "match-contributing-prefix" directamente a la ruta por defecto 0.0.0.0/0 y la política "export-default" la aplicamos en la configuración de OSPF como política de exportación.

Comprobación de las políticas:

Desde R1



Desde R2

DIRECCIONES MARCIALES (MARTIAN ADDRESSES)

Estas direcciones son equipos o redes para las que el enrutamiento es ignorado. Estas direcciones nunca son instaladas en la tabla de rutas y tratan de evitar que equipos mal configurados puedan influir en la red al tener destinos inválidos.

En IPv4 tenemos por defecto las siguientes:

•  0.0.0.0/8
• 127.0.0.0/8
• 128.0.0.0/16
• 191.255.0.0/16
• 192.0.0.0/24
• 223.255.255.0/24
• 240.0.0.0/4

Para IPv6, la dirección de loopback, las redes reservadas y no asignadas por la RFC 2373 y la "link-local unicast" son direcciones marciales por defecto.

Podemos añadir debajo de routing-options más redes marciales a la configuración:

#set routing-options martians 36.0.0.0 orlonger

Además debemos configurar una política de control para especificar que redes exactamente queremos filtrar. Las opciones son:

• exact
• longer
• orlonger
• prefix-lenght-range
• through and
• upto

Para comprobar las redes marciales:

show route martians

Cómo podéis observar las redes se instalan en cada una de las tablas de Junos. Para poder ver individualmente las redes marciales en cada una de las tablas:

show route martians table inet.0

Para quitar un bloque de redes de la configuración:

#set routing-options martians 240/4 orlonger allow

Vemos ahora la 240.0.0.0/4 como allowed (permitida) 

 ROUTING INSTANCES (Instancias de Enrutamiento)



Tabla de rutas diferentes para Cliente A y B

Una routing instance es como otro router dentro del router. Es decir, Junos agrupa de una manera lógica (por software) interfaces, tablas de rutas y protocolos en cada routing instance manteniendo estos parámetros e información fuera de las otras routing instances que pueda tener el equipo.

Master Routing Instance

Junos crea una routing instance por defecto de tipo unicast que la llama master. Esta es la inet.0 y sirve para el direccionamiento IPv4. También crea otras como la inet.6 que es para Ipv6 u otras routing instances privadas que utiliza para la comunicación interna del hardware del equipo. Estas últimas podemos ignorarlas a la hora de planificar nuestra instalación de red.

Si está la inet6 es porque se ha habilitado IPv6

Junos nos da la opción de crear routing instances para varios propósitos:

• forwarding: usada para implementar filtros en la capa de acceso
• l2vpn: para las VPN de capa 2
• no-forwarding: usada para separar grandes redes en muchas pequeñas
• virtual-router: para virtualizar
• vpls: usada para LAN point-to-multipoint entre sitios VPN
• l3vpn: para las VPN de capa 3

Dependiendo de la versión de Junos tendremos unas opciones u otras.

Configuración de una routing instance:

Vemos que OSPF participa en la routing instance

Una vez que creamos la routing instance, el sofware crea una tabla unicast a la que le pone el nombre de la routing instance delante de inet.0: nombre.inet.0. Y lo mismo si usamos IPv6:nombre.inet.6

Importante hacer ping con el atributo "routing-instance"

Para el intercambio de rutas entre las diferentes tablas tenemos dos opciones:

• RIB Group: metemos información de enrutamiento en múltiples tablas
• Import/Export en routing instace: fuera del estudio del JNCIS

En la import-rib podemos incluir múltiples tablas pero debe mostrar la tabla primaria (inet.0) en la primera posición en la configuración. Sin embargo, en la export-rib solo podemos incluir una, la primaría y por eso no se suele configurar, porque ya lo hace por defecto.

Para crear un RIB-Group:

#set routing-options rib-groups X

Una vez creado lo podemos aplicar en diferentes partes de la configuración como en rutas estáticas, protocolos de enrutamiento, multicast, etc.

Un ejemplo con OSPF:

[edit routing-options] user@R1# show rib-groups { test { import-rib [ inet.0 test.inet.0 ]; } } [edit protocols ospf] user@R1# show rib-group test; area 0.0.0.0 { interface ge-0/0/1.0; interface lo0.0; }

Rib-Group para las tablas inet.0 y test.inet.0



user@R1> show route table inet.0 protocol ospf inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.20.101.0/24 *[OSPF/150] 00:00:30, metric 0, tag 0 > to 172.20.77.2 via ge-0/0/1.0 172.20.201.0/24 *[OSPF/150] 00:00:30, metric 0, tag 0 > to 172.20.77.2 via ge-0/0/1.0 192.168.2.1/32 *[OSPF/10] 00:00:30, metric 1 > to 172.20.77.2 via ge-0/0/1.0 224.0.0.5/32 *[OSPF/10] 2w1d 02:37:55, metric 1 MultiRecv user@R1> show route table test.inet.0 protocol ospf test.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.20.101.0/24 *[OSPF/150] 00:00:27, metric 0, tag 0 > to 172.20.77.2 via ge-0/0/1.0 172.20.201.0/24 *[OSPF/150] 00:00:27, metric 0, tag 0 > to 172.20.77.2 via ge-0/0/1.0 192.168.2.1/32 *[OSPF/10] 00:00:27, metric 1 > to 172.20.77.2 via ge-0/0/1.0 224.0.0.5/32 *[OSPF/10] 00:00:27, metric 1 MultiRecv

Vemos como la test.inet.0 tiene ahora las rutas OSPF de la tabla inet.0

Intercambio de rutas entre routing instances:

Para el enrutamiento entre routing instances, las podemos conectar físicamente (en este ejemplo por las Ge) o podemos crear interfaces lógicas.

Para conectarlas por una interface lógica, debemos crear una en cada routing instance. Después creamos un vecindad de nodos (peer relationship) para crear una conexión punto a punto. Esta interface la creamos con el siguiente formato: lt-fpc/pic/port

[edit interfaces lt-0/0/0] user@R1# show unit 0 { encapsulation ethernet; peer-unit 1; family inet { } } unit 1 { encapsulation ethernet; peer-unit 0; family inet; }

Observad que los peer-unit son diferentes

No en todos los Junos tenemos la opción de crear interfaces lógicas. En algunos tendremos que tener un hardware específico.

Cuando configuremos interfaces lógicas tenemos que tener en cuenta:

• La interfaces tiene que tener una de las siguietnes encapsulaciones: Ethernet, Ethernet circuit cross-connect (CCC), Ethernet VPLS, Frame Relay, Frame Relay CCC, VLAN, VLAN CCC, or VLAN VPLS.
• Se puede configurar IP, IPv6, ISO o MPLS
• Las interfaces deben pertenecer a la misma interface de tipo túnel del hardware