JNCIP - BGP - POLÍTICAS DE ENRUTAMIENTO - EXTERNAL NETWORK

Las políticas de enrutamiento vistas desde la parte de la empresa las podemos diferenciar en dos claras categorías. Estas a su vez se subdividen en lo que podríamos decir que se ha convertido en un estándar a la hora de planificar el comportamiento de nuestra red:

• INBOUND (entrada)
• Basado en la Topología
• Primaria / Secundario
• Balanceo de carga por direccionamiento

• OUTBOUND (salida)
• Basado en la Topología
• Primaria / Secundario
• Balanceo de carga por direccionamiento

Hay muchas maneras de configurar nuestro enrutamiento dependiendo de factores como el rendimiento, la disponibilidad, el coste, etc.  Lo que tenemos que tener claro es que desde el punto de vista de un empresa, nosotros no tenemos el control total del tráfico de entrada (inbound), solo podemos influir en él. Cada AS tiene control de sus políticas de salida del tráfico. Para que el resultado de nuestras políticas de entrada se ajusten a lo que queremos, debemos pensar y coordinar tanto con los ISP como con las empresas con las que queramos tener una comunicación más directa.

Podríamos resumir en dos los tipos de topologías respecto al tráfico externo siempre desde el punto de vista de una empresa (lo de los ISP es otra historia):

Una práctica común en los ISP es configurar el "local-preference" para dar prioridad por un enlace u orto hacia un cliente en la salida del tráfico. Suelen aceptar también "communities" desde los clientes para aceptar el tráfico y dirigirlo a un enlace u otro dependiendo de estas communities que elige el cliente cómo configurar y el comportamiento correspondiente del tráfico. Lo más común en los ISP es establecer filtros de IMPORT en las sesiones BGP con los clientes para sumarizar, evitar inundación de prefijos, modificar el AS PATH, etc. Tenemos que entender que estas políticas en los ISP también pueden influir en nuestro tráfico.

En las políticas de enrutamiento basadas en la topología todas las rutas son aceptadas sin modificación de los atributos. La elección del camino usa factores como el AS PATH, el MED y la métrica del IGP que tenga la red. Este modelo suele ajustarse a las necesidades de nuestra red si no tenemos preferencias sobre los caminos a elegir.

En una topología como la esta, en primer lugar el router determina el mejor camino mirando la longitud del AS PATH (como hace RIP con los salto pero aquí con los AS). Si la longitud es igual, mirará el Origen, luego el MED, etc. Recordemos la selección del mejor camino en BGP:

1. Elige la ruta con el "local-preference" más alto
2. Elige el AS-PATH más corto. Normalmente es este campo el que acaba siendo el decisorio.
3. Elige el ORIGIN más bajo. I (IGP) < E (EGP) < ? (Incomplete)
4. Elige el MED más bajo. Si no hay MED, da por sentado un valor de 0.
5. Elige ruta recibida de un EBGP antes que la de un IBGP. Si todas son EBGP, se va al punto 9
6. Si son aprendidas por IBGP, usa el camino con el coste IGP hacia el IBGP más bajo. Por cada vecino IBGP, el next-hop se instala siguiendo las siguientes reglas.
1. BGP examina el next-hop de las tablas inet.0 e inet.3 y elige el de menor preferencia
2. Si hay empate, se usa el de la tabla inet.3
3. Si continua el empate, se elige el next-hop que tenga más caminos instalados.
7. Elige el RID más bajo (normalmente la loopback). Cuando hay dos rutas externas de diferentes AS y el RID es el mismo, elegirá la que esté en ese momento activa. El comando "external-router-id" puede modificar el comportamiento si le configuramos más bajo independientemente de si está activa o no la ruta de ese RID.
8. Longitud más corta del cluster-list. Es parecio al AS-PATH. Aquí "cluster" es sinónimo de Router Reflector
9. ID de par más bajo

Si ahondamos en la topología anterior, al mirarla desde un punto de vista de la "salida de tráfico", podemos decir que basándose en el AS PATH, el router vMX-1 de la empresa central atravesará la red interna para llegar a la Oficina B y, vMX-2 para llegar a la Oficina A, haciendo que el enlace entre ellos tenga que ser posiblemente aumentado. Es decir, puede que no sea una solución óptima dejar que la selección del camino sea solo a través del AS PATH.

Cuando basamos nuestras políticas de enrutamiento en una configuración Primario/Secundario, normalmente se usa el primario para todo el tráfico y el secundario solo si el primario deja de estar activo. A esta modalidad se le llama Strict. También se suele configurar en algunos entornos el uso del enlace secundario para un tipo concreto de tráfico, y a esta le llaman Loose. La ventaja de esta configuración es la redundancia, aunque debemos tener en cuenta que para obtener un rendimiento completo de la solución, el enlace secundario debería tener la misma capacidad que el primario.

Cuando tenemos contratados 2 enlaces para tener redundancia, lo normal es hacer que los ISP nos envíen un ruta por defecto a través de cada enlace y luego nosotros otorgamos la preferencia de salida según nos convenga, normalmente priorizando con "local-preference".

Vamos a ver todo esto con un ejemplo que siempre se entiende mejor:

Configuraciones básicas:


vMX-3

set interfaces ge-0/0/0 unit 0 family inet address 6.0.0.2/30
set interfaces ge-0/0/3 unit 0 family inet address 192.168.30.1/24
set routing-options autonomous-system 65001
set protocols bgp group EBGP export EXPORT-LAN
set protocols bgp group EBGP neighbor 6.0.0.1 peer-as 300
set policy-options policy-statement EXPORT-LAN term 1 from protocol direct
set policy-options policy-statement EXPORT-LAN term 1 from route-filter 192.168.30.0/24 exact
set policy-options policy-statement EXPORT-LAN term 1 then accept
 

ISP-C

set interfaces ge-0/0/0 unit 0 family inet address 6.0.0.1/30
set interfaces ge-0/0/1 unit 0 family inet address 5.0.0.1/30
set interfaces ge-0/0/2 unit 0 family inet address 3.0.0.2/30
set routing-options static route 0.0.0.0/0 discard 
set routing-options autonomous-system 300
set protocols bgp group EBGP-65002 export DEFAULT-65002 
set protocols bgp group EBGP-65002 neighbor 5.0.0.2 peer-as 65002
set protocols bgp group EBGP-65001 export DEFAULT-65001
set protocols bgp group EBGP-65001 neighbor 6.0.0.2 peer-as 65001
set protocols bgp group EBGP-100 export EXPORT-WANS
set protocols bgp group EBGP-100 neighbor 3.0.0.1 peer-as 100
set policy-options policy-statement DEFAULT-65001 term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement DEFAULT-65001 term 1 then accept
set policy-options policy-statement DEFAULT-65001 then reject
set policy-options policy-statement DEFAULT-65002 term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement DEFAULT-65002 term 1 then accept
set policy-options policy-statement DEFAULT-65002 then reject
set policy-options policy-statement EXPORT-WANS term 1 from protocol direct
set policy-options policy-statement EXPORT-WANS term 1 then accept


vMX-4

set interfaces ge-0/0/0 unit 0 family inet address 4.0.0.2/30
set interfaces ge-0/0/1 unit 0 family inet address 5.0.0.2/30
set interfaces ge-0/0/3 unit 0 family inet address 192.168.40.1/24
set routing-options autonomous-system 65002
set protocols bgp export EXPORT-LAN
set protocols bgp group EBGP-200 neighbor 4.0.0.1 peer-as 200
set protocols bgp group EBGP-300 neighbor 5.0.0.1 peer-as 300
set policy-options policy-statement EXPORT-LAN term 1 from protocol direct
set policy-options policy-statement EXPORT-LAN term 1 from route-filter 192.168.40.0/24 exact
set policy-options policy-statement EXPORT-LAN term 1 then accept

ISP-A

set interfaces ge-0/0/1 unit 0 family inet address 1.0.0.2/30
set interfaces ge-0/0/2 unit 0 family inet address 3.0.0.1/30
set interfaces ge-0/0/7 unit 0 family inet address 7.0.0.1/30
set routing-options static route 0.0.0.0/0 discard    -    creamos la 0/0
set routing-options autonomous-system 100
set protocols bgp group EBGP-65000 export DEFAULT-65000
set protocols bgp group EBGP-65000 neighbor 1.0.0.1 peer-as 65000
set protocols bgp group EBGP-300 export EXPORT-WANS
set protocols bgp group EBGP-300 neighbor 3.0.0.2 peer-as 300
set protocols bgp group EBGP-200 export EXPORT-WANS
set protocols bgp group EBGP-200 neighbor 7.0.0.2 peer-as 200
set policy-options policy-statement DEFAULT-65000 term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement DEFAULT-65000 term 1 then accept
set policy-options policy-statement DEFAULT-65000 then reject  -  rechaza todas las WAN
set policy-options policy-statement EXPORT-WANS term 1 from protocol direct
set policy-options policy-statement EXPORT-WANS term 1 then accept

ISP-B

set interfaces ge-0/0/0 unit 0 family inet address 4.0.0.1/30

set interfaces ge-0/0/1 unit 0 family inet address 2.0.0.2/30
set interfaces ge-0/0/7 unit 0 family inet address 7.0.0.2/30

set routing-options static route 0.0.0.0/0 discard 

set routing-options autonomous-system 200
set protocols bgp group EBGP-65002 export DEFAULT-65002

set protocols bgp group EBGP-65002 neighbor 4.0.0.2 peer-as 65002

set protocols bgp group EBGP-65000 export DEFAULT-65000

set protocols bgp group EBGP-65000 neighbor 2.0.0.1 peer-as 65000
set protocols bgp group EBGP-100 export EXPORT-WANS
set protocols bgp group EBGP-100 neighbor 7.0.0.1 peer-as 100

set policy-options policy-statement DEFAULT-65000 term 1 from route-filter 0.0.0.0/0 exact

set policy-options policy-statement DEFAULT-65000 term 1 then accept
set policy-options policy-statement DEFAULT-65000 then reject 
set policy-options policy-statement DEFAULT-65002 term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement DEFAULT-65002 term 1 then accept
set policy-options policy-statement DEFAULT-65002 then reject 

set policy-options policy-statement EXPORT-WANS term 1 from protocol direct

set policy-options policy-statement EXPORT-WANS term 1 then accept

Nota: en rojo la manera clásica para exportar una ruta por defecto 0/0 desde un ISP a un cliente para que solo le llegue esta ruta. El router cliente no necesita tener toda la tabla BGP de Internet. Si probáis a quitar el "reject", veréis como le empiezan a llegar las redes "WAN".

vMX-1

set interfaces ge-0/0/0 unit 0 family inet address 10.0.12.1/30
set interfaces ge-0/0/1 unit 0 family inet address 1.0.0.1/30
set interfaces ge-0/0/3 unit 0 family inet address 10.0.15.1/30
set interfaces lo0 unit 0 family inet address 172.31.1.1/32
set routing-options autonomous-system 65000
set protocols bgp group EBGP export EXPORT-LAN
set protocols bgp group EBGP neighbor 1.0.0.2 peer-as 100
set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 172.31.1.1
set protocols bgp group IBGP peer-as 65000
set protocols bgp group IBGP neighbor 172.31.1.2
set protocols bgp group IBGP neighbor 172.31.1.5
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 interface-type p2p
set policy-options policy-statement EXPORT-LAN term 1 from protocol ospf
set policy-options policy-statement EXPORT-LAN term 1 from route-filter 192.168.50.0/24 exact
set policy-options policy-statement EXPORT-LAN term 1 then accept

vMX-2

set interfaces ge-0/0/0 unit 0 family inet address 10.0.12.2/30

set interfaces ge-0/0/1 unit 0 family inet address 2.0.0.1/30

set interfaces ge-0/0/4 unit 0 family inet address 10.0.25.1/30

set interfaces lo0 unit 0 family inet address 172.31.1.2/32

set routing-options autonomous-system 65000

set protocols bgp group EBGP export EXPORT-LAN

set protocols bgp group EBGP neighbor 2.0.0.2 peer-as 200

set protocols bgp group IBGP type internal

set protocols bgp group IBGP local-address 172.31.1.2

set protocols bgp group IBGP peer-as 65000

set protocols bgp group IBGP neighbor 172.31.1.1

set protocols bgp group IBGP neighbor 172.31.1.5

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p

set protocols ospf area 0.0.0.0 interface lo0.0 passive

set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p

set policy-options policy-statement EXPORT-LAN term 1 from protocol ospf

set policy-options policy-statement EXPORT-LAN term 1 from route-filter 192.168.50.0/24 exact

set policy-options policy-statement EXPORT-LAN term 1 then accept

vMX-5

set interfaces ge-0/0/0 unit 0 family inet address 192.168.50.1/24

set interfaces ge-0/0/3 unit 0 family inet address 10.0.15.2/30

set interfaces ge-0/0/4 unit 0 family inet address 10.0.25.2/30

set interfaces lo0 unit 0 family inet address 172.31.1.5/32

set routing-options autonomous-system 65000

set protocols bgp group IBGP type internal

set protocols bgp group IBGP local-address 172.31.1.5

set protocols bgp group IBGP export EXPORT-LAN

set protocols bgp group IBGP peer-as 65000

set protocols bgp group IBGP neighbor 172.31.1.1

set protocols bgp group IBGP neighbor 172.31.1.2

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 interface-type p2p

set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p

set protocols ospf area 0.0.0.0 interface lo0.0 passive

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 passive

set policy-options policy-statement EXPORT-LAN term 1 from protocol direct

set policy-options policy-statement EXPORT-LAN term 1 from route-filter 192.168.50.0/24 exact

set policy-options policy-statement EXPORT-LAN term 1 then accept

vMX-2, 3 y 4 reciben también un 0/0y ninguna red WAN

------------------------------------------------------------------------------------------------------

El equipo vMX-5 tiene 2 opciones para salir fuera. vMX-1 y vMX-2 están recibiendo una default cada uno para emular la topología de un ISP, que lo único que hace es pasar una default a los clientes. (no siempre es así, pero es lo más usual)

Vamos a crear una configuración tipo STRICT, es decir, utilizamos uno de los dos enlaces para el tráfico de producción y el otro lo reservamos para la redundancia y, solo procesará tráfico si el primario se cae. Para este escenario, vamos a elegir como Primario al vMX-1 y como secundario a vMX-2.

Ahora mismo vMX-5 no sabe cómo salir fuera de su red. Le llega la ruta 0/0, pero no se instala.

Para configurarlos, primero instalamos la ruta 0/0 en nuestra tabla con una política de IMPORT en los equipos que la reciben, donde le damos la preference y, luego creamos otra de EXPORT para nuestros vecinos IBGP con el next-hop.

vMX-1

set policy-options policy-statement IMPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 1 from route-filter 0.0.0.0/0 exact

set policy-options policy-statement IMPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 1 then local-preference 200

set policy-options policy-statement IMPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 1 then accept

set protocols bgp group EBGP import IMPORT-RUTA-POR-DEFECTO-CON-PREFERENCE


set policy-options policy-statement EXPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 1 from route-filter 0.0.0.0/0 exact

set policy-options policy-statement EXPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 1 then next-hop self

set protocols bgp group IBGP export EXPORT-RUTA-POR-DEFECTO-CON-PREFERENCE



vMX-2

set policy-options policy-statement IMPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 1 from route-filter 0.0.0.0/0 exact

set policy-options policy-statement IMPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 1 then local-preference 150

set policy-options policy-statement IMPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 1 then accept

set protocols bgp group EBGP import IMPORT-RUTA-POR-DEFECTO-CON-PREFERENCE


set policy-options policy-statement EXPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 1 from route-filter 0.0.0.0/0 exact

set policy-options policy-statement EXPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 1 then next-hop self

set protocols bgp group IBGP export EXPORT-RUTA-POR-DEFECTO-CON-PREFERENCE

Entre los beneficios de la política de IMPORT es, como ya hemos dicho en la teoría, la posibilidad de manipulación de las rutas antes de que se instalen en la tabla. Vamos a hacer una prueba.

Imaginemos que el ISP-B tiene un fallo y sin querer nos manda toda la tabla de rutas BGP de Internet a nuestro pequeño router, haciendo que se sature y deje de dar servcio. En este caso, si tenemos una política de IMPORT, podríamos rechazar esas rutas. Vamos a emulularlo con nuestra topología.

Vamos a ISP-B y le quitamos la siguiente línea:

• set policy-options policy-statement DEFAULT-65000 then reject 

De inmendiato, el router vMX-2 empieza a recibir las WAN.

Pues bien, si configuramos en la política de IMPORT en vMX-2 esa línea en nuestros equipos, estas redes WAN no se instalarán y sí que se instalará nuestra ruta por defecto. Para ello, la política de IMPORT quedaría así:


set policy-options policy-statement IMPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 1 from route-filter 0.0.0.0/0 exact

set policy-options policy-statement IMPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 1 then local-preference 150

set policy-options policy-statement IMPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 1 then accept

set policy-options policy-statement IMPORT-RUTA-POR-DEFECTO-CON-PREFERENCE then reject


Es una manera de prevenir un fallo del ISP que nos deje sin comunicaciones.


Ahora vamos a crear una configuración tipo LOOSE, es decir, vamos a hacer el el ISP-B le pase la 192.168.40.0/24 a VMX_2 para que el tráfico desde la Empresa Central a la Oficina B vaya a través del vMX-2 y consecuentemente el ISP-B para optimizar el camino.

Se puede hacer de muchas maneras, aquí vamos a usar Communities. Para ello, lo primero que vamos a hacer es publicar desde el equipo vMX-4 la red 192.168.40.0/24 con una community que la identifique. Luego ISP-B la reconocerá y la pasará hacia vMX-2.


vMX-4

set protocols bgp group EBGP-200 export LAN-COMMUNITY

set policy-options policy-statement LAN-COMMUNITY term 1 from route-filter 192.168.40.0/24 exact

set policy-options policy-statement LAN-COMMUNITY term 1 then community add red-lan-oficina-b

set policy-options policy-statement LAN-COMMUNITY term 1 then accept

set policy-options community red-lan-oficina-b members 65002:40

Comprobamos en ISP-B que nos llega la ruta con la etiqueta:

Configuramos ISP-B para que envíe esta ruta a vMX-2.

set policy-options policy-statement DEFAULT-65000 term 2 from community red-lan-oficina-b

set policy-options policy-statement DEFAULT-65000 term 2 then accept

set policy-options community red-lan-oficina-b members 65002:40

Comprobamos que a vMX-2 le llega esta ruta con la community:

Y ahora en vMX-2 configuramos para que la propague esta ruta a los vecinos IBGP y establezca en next-hop a través de vMX-2:


set policy-options policy-statement EXPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 2 from community red-lan-oficina-b

set policy-options policy-statement EXPORT-RUTA-POR-DEFECTO-CON-PREFERENCE term 2 then next-hop self

 

Ahora vMX-5 tiene la ruta 0/0 principal a través de vMX-1 y la ruta 192.168.40.0 a través de vMX-2:

Si hacemos un traceroute desde el PC-3 hacia la 192.168.40.10 (PC-2) vemos que va a través de vMX-2 y, hacia la 192.168.30.10 (PC-1) a través de vMX-1 usando la ruta 0/0: