Recordad las tablas que tenemos en BGP:
- Adjency-RIB-IN: almacena todas las rutas recibidas de cada peer.
- RIB-LOCAL: contiene las rutas que usa para enviar tráfico
- Adjency-RIB-OUT: contiene todas las rutas propagadas a cada peer.
POLÍTICA DE IMPORT
BGP almacena la información de las rutas recibidas de los otros peers en la RIB-IN. AquÍ todavía no se han aplicado políticas. Toda la información BGP se almacena excepto las rutas en las que falla el chequeo del camino hacia su AS o Cluster-ID (Roter Reflector). Tampoco almacena las rutas de VPN que no coincidan con los criterios de la "community". Una vez en la RIB-IN, BGP las pasa a la RIB-LOCAL.
Las políticas de IMPORT se aplican en el paso que va desde la RIB-IN a la RIB-LOCAL. Estas políticas pueden filtrar o cambiar atributos que afectan a la posterior selección de la mejor ruta.
Es después e aplicar la política de IMPORT cuando BGP decide cuál es la mejor ruta y la instala en la tabla de rutas y en la tabla de envío.
NOTA: aunque no se aplique ninguna política específica, la política por defecto siempre es aplicada. Esta política no se ve, es un mecanismo de Juniper.
Un ejemplo:
Las políticas de IMPORT pueden ser individuales o solamente una para todas. Según la política se rechaza la 0/0 del AS 100 y se aceptan todas las del AS 200. Si nos fijamos bien, la 192.168.10.0/24 del AS 100 es la priorizada o preferida, pero la misma que viene desde AS 200 no es rechazada, es decir, también aparecerá en la tabla de rutas pero en la tabla de envío (forwarding table) se instalará la del AS 100 como hemos decidido en la política de IMPORT:
POLÍTICA DE EXPORT
BGP almacena la información de las rutas que tiene que propagar a sus vecinos BGP en la RIB-OUT.
Las políticas de exPORT se aplican en el paso que va desde la RIB-LOCAL a la RIB-OUT. Estas políticas pueden filtrar o cambiar atributos que afectan a las rutas que propagamos.
Además, en esta política se puede añadir información nueva de enrutamiento al proceso BGP.
Un ejemplo:
ATRIBUTOS
Las características principales de los atributos comunes los podéis encontrar en la parte del BGP del JNCIS-ENT. Aquí voy a poner un ejemplo de uso para cada uno y vamos a hablar de las Regular Expressions aplicadas a los atributos de AS PATH y Community.
Las Regular Expressions en Junos funcionan de forma diferente a la de Cisco. Para Juniper, un "Termino" de Regular Expression es directamente el número completo del AS, tipo 65001, 3465, etc, y no los números individuales del AS.
Cuando usamos un punto (.) esto hace que coincida todo el número del AS y no solo un número.
Lista de Regular Expression para AS PATH que podemos usar en las políticas:
Ejemplos:
- "65005?" - Coincide con un AS PATH con una longitud de 0 o 1, es decir, que en el AS PATH no venga el AS 65005 o que solo aparezca una vez.
- ". (65005|13056)?" - Coincide con un AS PATH con un a longitud de 1 o 2. El primer AS puede ser cualquier valor pero el segundo, si existe un segundo AS, debe ser el 65005 o el 13056.
- "65005 . 3020" - Coincide con un AS PATH con una longitud de 3, donde el primer AS tiene que ser 65005 y el tercero el 3020. El AS que venga en el medio puede ser cualquier valor.
- "( )" - Null As PAth
Lista de Regular Expression para Communities que podemos usar en las políticas:
Ejemplos:
- "^36870:.{2,3}$" - Coincide con la community donde el número de AS es 36870 y la community es un valor de 2 o 3 dígitos
- "^5:.*$" - Coincide con la community donde el AS es el número 5 y la community es cualquier combinación de números
- "65005:2[159]8$" - Coincide con la community donde el AS es el 65005 y la community es un valor que puede ser 218, 258 o 298.
AS PATH
En la topología que tenemos de ejemplo, el equipo vMX-1 usa aleatoriamente uno de los dos caminos que tiene para llegar a vMX-4.
 |
| Vemos marcados el AS PATH de cada camino |
Vamos a usar la manipulación del AS PATH para que el tráfico siempre vaya a través de vMX-2 configurando un "Prepend" en la sesión BGP entre vMX-4 y vMX-3:
Creamos la política:
[edit policy-options]
policy-statement AS-PATH-PREPEND {
term prepend-as-30 {
then {
as-path-prepend 40; - Esto hace que meta en el AS PATH otra vez el AS 40
accept;
}
}
}
Aplicamos la política a la sesión con vMX-3:
- set protocols bgp group EBGP neighbor 10.0.34.2 export AS-PATH-PREPEND
Ahora vMX-1 prefiere el camino para llegar a vMX-4 a través de vMX-2 porque el camino a través de vMX-3 tiene un AS PATH más largo. Vemos como se repite 2 veces el AS 40:
AS PATH CON REGULAR EXPRESSIONS
Desde vMX-1 se llega a vMX-5 a través de vMX-3 debido a que hay menos AS en el camino:
Vamos a usar las Regular Expressions para hacer que vMX-1 llegue a la 5.5.5.5/32 a través de vMX-2:
Primero configuramos la Regular Expression:
- set policy-options as-path REGEXP-AS-20 "^20.*89$"
Con esto le decimos al equipo que en el AS PATH, el primer AS tiene que ser el 20. Luego con el punto y el asterisco, le decimos que los siguientes AS pueden ser cualquier cosa y, luego le decimos que el último AS PATH tiene que ser el 89.
Ahora tenemos que crear una política para decirle al equipo que a la ruta que coincida con lo que hemos configurado en la Regular Expression le configure un local-preference más alto para forzar que elija ese camino:
[edit policy-options]
policy-statement RUTA-ALTERNA {
term 1 {
from as-path REGEXP-AS-20;
then {
local-preference 200;
accept;
}
}
}
Ahora tenemos que crear una política para decirle al equipo que a la ruta que coincida con lo que hemos configurado en la Regular Expression le configure un local-preference más alto para forzar que elija ese camino:
[edit policy-options]
policy-statement RUTA-ALTERNA {
term 1 {
from as-path REGEXP-AS-20;
then {
local-preference 200;
accept;
}
}
}
Y por último, aplicamos esa política como IMPORT en el grupo EBGP (donde tenemos configurados los vecinos EBGP):
- set protocols bgp group EBGP import RUTA-ALTERNA
Ahora vemos que eleige el camino más largo, a través de vMX-2. Fijaos como al coincidir la configuración de la Regular Expression, le aplica el local-preference de 200 y por eso es la ruta principal para llegar a la 5.5.5.5/32
Podemos usar el siguiente comando para comprobar que un Regular Expression nos hace lo que nososotro queremos antes de configurarla en producción:
- show route aspath-regex "^20.*89$"
NEXT-HOP
Con una configuración básica de BGP, en este escenario el AS 50 (vMX-3) está exportando al AS 100 vMX-2) la ruta LAN 192.168.0.0/24.
Si miramos la tabla de rutas de vMX-2 vemos que conoce cómo llegar a la LAN:
Sin embargo, si vamos a vMX-1, este no la conoce porque en BGP, el "next-hop" de una ruta aprendida desde un vecino EBGP no se cambia cuando se le manda esta ruta a un vecino IBGP. Y como este vecino no sabe cómo llegar a esa ruta porque no conoce el salta para llegar precisamente a ella, no la instala como ruta activa, sino que la mete en las rutas ocultas (hidden)
Tenemos dos opciones para solucionar esto:
- Crear una política para cambiar el "next-hop"
En vMX-2 creamos la política y la exportamos a nuestro vecino IBGP:
[edit policy-options]
policy-statement CAMBIAR-NEXT-HOP {
term 1 {
from protocol bgp;
then {
next-hop self;
accept;
}
}
}
policy-statement CAMBIAR-NEXT-HOP {
term 1 {
from protocol bgp;
then {
next-hop self;
accept;
}
}
}
set protocols bgp group IBGP export CAMBIAR-NEXT-HOP
- Añadir un protocolo IGP
set protocols ospf area 0 interface ge-0/0/0.0 - en vMX-1 y vMX-2
Y solo en vMX-2 añadimos al dominio OSPF la interface que se enfrenta al vecino EBGP. Importante configurarla como "passive"para que no envie "hellos" de OSPF al vecino EBGP:
set protocols ospf area 0 interface ge-0/0/02.0 passive
Y ahora vemos la ruta en vMX-1:
MED (Multiple Exit Discriminator)
En este escenario hemos montado un AS 100 con BGP y también tiene OSPF como IGP para pasar la LAN 192.168.0.0. Para hacer la práctica vamos a configurarle a vMX-3 una métrica de 100 en OSPF a la interface ge-0/0/3.0 para emular que es un enlace con menos ancho de banda que el que conecta a vMX-2 y vMX-4:
- set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 metric 100
De esta manera, como MED está basado por defecto en la métrica del IGP, cuando hacemos un ping desde el PC-2 al PC-1 elige el camino a través de vMX-2, ya que exporta un MED más alto por el vMX-3:
Junos nos permite modificar este comportamiento a través de un a política:
root@vMX-2#
policy-options {
policy-statement EXPORT-LAN-OSPF {
term 1 {
from {
protocol ospf;
route-filter 192.168.0.0/24 exact;
}
then {
metric 1000; - añade la métrica a la política de export
accept;
}
}
}
}
set protocols bgp group EBGP export EXPORT-LAN-OSPF
Si ahora miramos la tabla de rutas en vMX-1:
Ahora la mejor métrica es a través de vMX-3 con 101 porque vMX-2 está propagando una de 1000. Ahora el traceroute desde el PC-2 debe escoger el camino a través de vMX-3:
LOCAL-PREFERENCE
Usamos la misma topología de MED pero con todos los valores por defecto, es decir, desconfiguramos todas las métricas.
Ahora vMX-2 y 3 están propagando la LAN 172.16.0.0/24 con las métricas por defecto. Si hacemos un ping desde el PC-1 al PC-2 vemos que va a través de vMX-2 (tiene un RID más bajo):
Vamos a crear una política para modificar el local-preference, exportarlo a nuestro vecino IBGP y hacer que el tráfico vaya a través de vMX-2:
root@vMX-3# show | compare
[edit policy-options]
policy-statement LOCAL-PREF {
term 1 {
from {
route-filter 172.16.0.0/24 exact;
}
then {
local-preference 200;
accept;
}
}
}
set protocols bgp group IBGP export LOCAL-PREF
Como sabemos que el local-preference por defecto es 100, se lo subimos a vMX-3 para la LAN 172.16.0.0/24 que nos están pasando y así hacemos que vMX-4 elija el camino a través de vMX-3:
Y ahora el PC-1 elegirá el camino a través de vMX-3 para llegar a la 172.16.0.0/24:
Ahora vamos a conseguir el mismo resultado de manera diferente. Vamos a aplicar la misma política que hemos creado pero esta vez como IMPORT en el grupo EBGP. Esto hará que se aplique el local-preference antes de instalarla en la tabla de rutas (inet.0). Recordad cómo funciona Juniper:
Eliminamos la línea de EXPORT en el grupo IBGP:
- delete protocols bgp group IBGP export LOCAL-PREF (en vMX-3)
- set protocols bgp group EBGP import LOCAL-PREF (en vMX-3)
Comprobamos que aplica la misma política y vMX-4 ve un local-preference de 200 a través de vMX-3 y enviará el tráfico por ahí.
COMMUNITY
Usando la misma topología de antes pero sin ninguna política de local-preference, es decir, con la configuración básica, vamos a hacer que a través de una community "Well-Known" como la de "No-Export" el equipo vMX-4, que actualmente está exportando la ruta LAN que tiene directamente conectada, envie esta community en la ruta y que hace que no se propague fuera del AS cuando llegue a vMX-2 y vMX-3.
Ahora vMX-4 tiene esta configuración:
root@vMX-4# run show configuration
protocols {
bgp {
group IBGP {
type internal;
export EXPORT-LAN;
peer-as 100;
neighbor 10.0.24.2;
neighbor 10.0.34.2;
}
}
}
policy-options {
policy-statement EXPORT-LAN {
term 1 {
from {
protocol direct;
route-filter 192.168.0.0/24 exact;
}
then accept;
}
}
}
Ahora vMX-2 y vMX-3 tienen esta configuración básica:
protocols {
bgp {
group EBGP {
type external;
neighbor 10.0.12.1 { - vMX-3 tiene la 10.0.13.1
peer-as 50;
}
}
group IBGP {
type internal;
neighbor 10.0.24.1 {
peer-as 100;
}
}
}
}
vMX-2 y vMX-3 reciben la 192.168.0.0/24 por OSPF y luego propagan a vMX-1 a través de BGP:
 |
| En vMX-3 se está exportando lo mismo |
vMX-1 ve la 192.168.0.0/24 por ambos equipos:
Añadimos en la política de vMX-4 para que inserte la community que vamos a llamar "no-propagar-lan-192" en dos pasos:
root@vMX-4# show | compare
[edit]
policy-options {
policy-statement EXPORT-LAN {
term 1 {
from {
protocol direct;
route-filter 192.168.0.0/24 exact;
}
then {
community add no-propagar-lan-192;
accept;
}
}
}
community no-propagar-lan-192 members no-export;
}
Y la aplicamos al grupo IBGP como export:
- set protocols bgp group IBGP export EXPORT-LAN
Si vamos a vMX-2 o vMX-3 podremos ver que ahora en la ruta 192.168.0.0/24 viene insertada la community no-export y, por lo tanto, esa ruta no se propaga fuera del AS:
Si vamos a vMX-1, este no recibe ya la ruta:
No hay comentarios:
Publicar un comentario