BGP es un protocolo de enrutamiento entre Sistemas Autónomos y se le suele catalogar como un protocolo de enruamiento vector-distancia (path-vector) porque usa un camino de AS, usado como un vector, para evitar bucles. La información de enrutamiento consiste en una serie de AS que indican el camino a seguir. Aunque es usado para el enrutamiento entre AS, también es utilizado en grandes redes tipo MPLS-VPN y también para separar dominios OSPF. BGP es muy escalable y ofrece un gran control de políticas para IGP.
BGP intercambia información entre AS. Un AS es un conjunto de routers que están bajo la misma administración. La información de enrutamiento de BGP incluye la ruta completa hasta destino. BGP usa esta info para mantener una base de datos sobre la "información de accesibilidad de la capa de red" (NLRI), que intercambia con otros sistemas BGP.
BGP es un protocolo de enrutamiento sin clase. Intercambia la info entre dos pares (peers) y estos deben estar directamente conectados para el enrutamiento entre AS. Establecen una conexión TCP.
¿Dónde debemos usar BGP?
Los clientes con una única conexión hacia el ISP suelen configurar una ruta estática por defecto. No se suele configurar un protocolo de enrutamiento. El ISP suele configurar también una estática para llegar al cliente. Normalmente, este tipo de usuarios tienen asignada una dirección ip que pertenece al propio ISP y que está dentro de un conjunto de direcciones (agregado). Estas direcciones son conocidas como "no portables". De esta manera el ISP puede anunciar este rango (agregado) para múltiples clientes y además reducir la tabla de rutas.
BGP es usado cuando el cliente tiene varios enlaces hacia el ISP (pueden ser ISP diferentes). Se configuran políticas para controlar por donde entra y sale el tráfico.
IBGP y EBGP
BGP tiene dos modos de intercambiar la información de enrutamiento:
- EBGP (external): intercambio entre AS (inter-as routing)
- IBGP (internal): intercambio en el mismo AS (intra-as routing)
Una conexión EBGP se establece entre dos equipos que pertenecen a diferente AS. Cada AS tiene al menos un "border gateway" (puerta de enlace frontera). Por defecto, una conexión EBGP se establece entre equipos conectados directamente porque el valor TTL (Time To Live) de los paquetes EBGP es 1. Se suele configurar el peer contra la dirección ip de la interface física del vecino para, entre otras ventajas, no tener que guardar ningún tipo de ruta del otro AS para formar vecindades. Si tuvieramos al vecino EBGP más allá de un salto (suele ser la loopback del equipo al que nos enfrentamos), tendríamos que configurar una sesión "multihop EBGP".
Normalmente una conexión IBGP se establece a través de "loopbacks" de routers que no están directamente conectados, aunque depende de la arquitectura de la red, claro (no es una condición infranqueable). Se usan las loopback para darle estabilidad, ya que las loopback siempre están "up" a menos que el router se apague. Las sesiones TCP de BGP se establecen usando la tabla de enrutamiento normal. Dentro del AS, existe una regla para el IGP que transporta las rutas: Una ruta aprendida por IBGP no puede ser repropagada a otro IBGP.
Sesiones de pares en BGP
En BGP no existe el descubrimiento automático de vecino, hay que configurarlos manualmente siempre.
BGP usa el puerto 179 de TCP para establecer las sesiones. Tenemos varios estados de la vecindad:
- Idle: estado inicial cuando todas las sesiones son rechazadas. Necesita de un "start event" (un evento de inicio) para que el nodo local inicie BGP y preparar el transporte de la sesión hacia otro nodo BGP.
- Connect: BGP está esperando a que la conexión del protocolo de transporte se complete. Si se completa, el nodo local envía un mensaje "OPEN" y se pasa al estado de "OpenState". Si falla, el nodo local reinicia el temporizador "ConnectRetryTime" y espera a que el nodo remoto le pida iniciar la conexión. Cuando falla, se queda en el estado de "ACTIVE".
- Active: en este estado está intentando conectar con un par o nodo para iniciar la conexión BGP. Si se completa, el nodo local envía un mensaje "OPEN" y se pasa al estado de "OpenState". Si falla, debemos comprobar los nodos, tanto local como remoto.
- OpenSent: BGP está esperando un mensaje "OPEN" desde el par remoto. Cuando se recibe, se comprueba que no haya errores y si es así, BGP manda un mensaje tipo "keepalive". Si hay errores, vuelve al estado "IDLE".
- OpenConfirm: BGP está esperando un mensaje "keepalive" o una "notification". Si no se recibe un "keepalive" antes de que el temporizador (hold timer) expire, el nodo local manda un mensaje tipo "notification" diciendo que ha expirado el tiempo y se pone en estado "IDLE". Si el nodo local recibe una "notification" también cambia el estado a "IDLE". Si el nodo local recibe un "keepalive", el estado cambia a "ESTABLISHED".
- Established: en este estado BGP intercambia mensajes tipo "UPDATE", "NOTIFICATION" y "KEEPALIVE" con su par o nodo remoto. Cuando el nodo local recibe un "update" o un "keepalive" y el temporizador negociado tiene un valor que no sea 0, se reinicia el temporizador. Si llega a 0, el nodo local envía un "keepalive" y resetea el contador del temporizador.
Tipos de mensajes BGP
BGP procesa los mensajes una vez los ha recibido completamente. El tamaño máximo de estos mensajes es de 4096 octetos. Y el tamaño mínimo será el de un paquete con solo la cabecera BGP (19 octetos). Tenemos los siguientes tipos de mensaje:
- Open: es enviado una vez que el proceso TCP "three-way-handshake" es completado. Este mensaje inicia la sesión BGP y contiene detalles del vecino BGP e información sobre las opciones negociadas y soportadas.
- Update: se usa para enviar la información de enrutamiento de los nodos.
- Keepalive: no usa keepalive en la capa de transporte, eso ya lo hace TCP. Se envían para asegurarse que el temporizador (hold timer) no expira. No incluye datos.
- Notification: se usa para notificar cuando algo va mal. Se envía cuando una opción no es soportada en un mensaje "open" o cuando un nodo no envía un "update" o "keepalive". Cuando se detecta un error, la sesión BGP se cierra.
- Refresh: normalmente un nodo no reenvía las rutas que ya ha reenviado y han llegado. El "refresh" se usa para hacer un "soft clearing"de la sesión BGP permitiendo que se reenvíen las rutas. Es muy útil para redes tipo MPLS-VPN cuando queremos añadir rutas de los clientes que ya tenemos sin tener que cerrar la sesión BGP.
 |
| Todos los mensajes tienen un tamaño de 19 bytes |
Los mensajes BGP UPDATE describen un único camino y una lista de rutas alcanzables a través de ese camino. BGP asume que esa información no ha cambiado a menos que el prefijo sea marcado como no alcanzable o se reciba un nuevo update con otra información sobre esa ruta. BGP usa los updates para asegurarse de que los vecinos tengan la información más actualizada. También se usa para detectar "bucles" (loops) obviamente.
Cuando se caeun vecino BGP con otro, se borran las rutas aprendidas de este vecino y se envía un UPDATE a los demás vecinos.
EJEMPLO DE BGP
 |
| La red asignada es parte de un "agregado" del ISP A - 172.20.0.0/16 |
 |
| Vemos la nube de ISP A en detalle |
El ISP A mantiene internamente la información de la "alcanzabilidad" para cada prefijo dentro de su agregado (172.20.0.0/16). Además, cada router de ISP A sabe acerca de las /24 que tiene asignado el Customer A. Esta información se propaga a través del IGP o del IBGP.
El ISP A solo propaga externamente los agregados.
Uno de los atributos que propaga BGP cuando anuncia las rutas es el AS PATH, que es una lista de los sistemas autónomos (AS) por los que tiene que pasar para llegar al agregado. Cada As va añadiendo su propio AS para completar el camino.
 |
| Desde el punto de vista de Customer B sucede lo mismo |
Customer A no tiene montada una sesión BGP con el ISP A, es lo que se llama un "single-homed. No la necesita, puesto que para llegar al Customer B no necesita conocer toda la ruta, con la estática por defecto (0/0) es suficiente. Una vez que llega al ISP A, entonces este si lo enruta todo a través del camino que conoce por BGP.
Ahora imaginemos que el Customer B añade una conexión más apuntando al ISP B. Es lo que se llamaría un "multi-homed".
 |
| Customer B anuncia su red a dos ISP diferentes |
ISP B elige la mejor ruta (tiene directamente conectado al Customer B) y es la que anuncia. Se puede ver que en el anuncio no se envía la información del ISP C, puesto que no pasa la ruta por él. En caso de que fallara el enlace directo, anunciaría que se puede llegar a través del otro camino, a través del ISP C y, ahí si metería el AS del ISP C.
No se muestra, pero al Customer B le están llegando los anuncios tanto del ISP B como del ISP C. Customer B elige la mejor ruta, es decir, la que va directamente al ISP B y la instala en su tabla de enrutamiento.
Tabla de atributos BGP
Los atributos de BGP están descritos en la RFC 1771. Tenemos 4:
- Well-Known Mandatory: debe estar soportado en todas las implementaciones de BGP y se debe incluir en todos los "updates" (actualizaciones) de BGP.
- Well-Known Discretionary: debe estar soportado en todas las implementaciones de BGP pero no tiene por qué estar incluido en todos los "updates" (actualizaciones) de BGP.
- Optional Transitive: no es requerido en las implementaciones de BGP, pero si éstá, debe pasarse a todos los pares de BGP sin modificación.
- Optional Nontransitive: no es requerido en las implementaciones de BGP. Si se pasa pero no es reconocido por el equipo, no se pasa a los pares de BGP.
ATRIBUTOS BGP EN DETALLE
El primer objetivo de BGP no es encontrar el camino más corto, sino encontrar "el mejor camino". Cada AS determina el mejor camino hacia un prefijo/red basándose en sus propias preferencias de enrutamiento para llegar a ese destino, en las preferencias de enrutamiento de la ruta de origen y en la información que se va añadiendo a lo largo del camino. Esta información está en los "atributos del camino" hacia ese destino. Estos atributos contienen la información que BGP usa para implementar la políticas de enrutamiento de origen, destino y tránsito.
El atributo NEXT-HOP
El "next-hop" es la dirección ip del par BGP. Se usa para verificar la conectividad del par BGP remoto. Puede ser un equipo directamente conectado o uno remoto. La dirección ip especificada en el next-hop debe ser alcanzable por el router local antes de que la ruta sea activa en la tabla de rutas.
Por defecto, el router de origen del tráfico añade su next-hop en el campo de los atributos. Cuando son enlaces EBGP cambia, es decir, el next-hop es la ip del equipo que propaga la ruta. Cuando la ruta se origina en un EBGP y se envía a un IBGP no cambia, pero se pueden aplicar politícas para que lo haga.
El atributo next-hop siempre estará presente para todas las rutas BGP. Si las rutas están activas, el atributo se pasa. Si las rutas tienen un next-hop que no es "alcanzable" se instalarán en la tabla de rutas pero como HIDDEN (ocultas). Para ver estas rutas ocultas escribimos el comando:
show route hidden
El atributo LOCAL-PREFERENCE
Con este atributo podemos dirigir el tráfico de salida a través de un par específico. Antes de enviar tráfico a los pares internos (internal peers), el router asigna un valor de "local-preference" en todas las rutas recibidas. Entonces, todos los pares usan esas rutas en sus tablas RIB locales.
El "local-preference" es un valor numérico. Cuanto más alto sea, mejor métrica. Es el primer valor que se compara cuando se hace la selección de ruta válida. Junos nos permite modificar ese valor a través de la configuración directa de este valor o con políticas de enrutamiento. Si configuramos este valor con ambos modos a la vez, Junos elegirá el valor de la política de enrutamiento.
BGP usa el "local-preference" siempre dentro del propio AS. Este valor no se propaga a través de los enlaces EBGP. Deben entenderlo todos los routers BGP pero es no obligatorio en los updates.
El valor por defecto en Junos es 100 (entre 0 y 4.294.967.295, valor de 32 bits).
 |
| Cómo se trata el "loca-preference" dentro del AS |
En este ejemplo vemos que el administrador del As MyNET ha decidido que el tráfico salga por el ISP A siempre que esté activo y, usar el ISP B como camino secundario. Esta decisión se puede hacer por diferentes motivos, ya sea por coste de los enlaces, por rendimiento de los equipos, etc.
Para ello, ha configurado un local-preference más alto en ISP A para que sea asignado a las rutas que recibe.
El atributo AS-PATH
El AS-PATH describe los diferentes AS que atraviesa durante el camino desde el origen. Cuando un router recibe un "update" de BGP lo primero que hace es comprobar si en el campo AS-PATH está su AS local. Si está su propio AS, quiere decir que la ruta ya ha pasado a través de su AS y, si aceptara la ruta, provocaría un bucle; por lo tanto, lo que hace es descartar la ruta y no la propaga. Este comportamiento puede ser alterado usando el comando "as-override", que es muy usado en entornos de MPLS-VPN.
Por defecto, se van añadiendo los AS durante el camino. Sin embargo, podemos anexar información a este campo usando una política de enrutamiento. Es decir, podemos configurar el campo AS-PATH para que añada nuestro número de AS más de una vez y así modificar el comportamiento de la decisión de enrutamiento. Cuando la decisión de enrutamiento se basa en el AS PATH, la ruta elegida es la que menos AS tenga para llegar al desitno.
Imaginemos con el ejemplo de arriba que el AS 452 quiere añadir dos veces su número de AS.
Configuraríamos el prepend: as-path-prepend "452 452" y entonces quedaría:
AS-PATH: 452 452 452 645 501
Junos soporta Regular Expressions para dar flexibilidad a los criterios de coincidencia. Esto está fuera del estudio del JNCIS.
El atributo AS-PATH es obligatorio. Debe estar presente en todas las rutas BGP.
El atributo ORIGIN
El router BGP que inicialmente inyecta una ruta en el proceso BGP es el encargado de añadir el atributo ORIGIN al campo en la ruta. Describe por lo tanto el router de origen. Tiene varias elecciones:
- IGP (I): BGP asigna a una ruta IGP el valor de 0. Ejemplos de rutas IGP incluye OSPF, IS-IS, estáticas y agregados.
- EGP (E): BGP asigna a una ruta EGP el valor de 1. Las rutas EGP son las que provienen del protocolo EGP que las origina, es decir, el protocolo que precede a BGP.
- Incomplete (?): BGP asigna a las rutas "desconocidas" el valor de 2. Estas rutas son las que no provienen ni de un IGP ni de un EGP.
Se prefiere el origen interno (I) al externo (E) y, este antes del incompleto (?)
El atributo ORIGIN es obligatorio. Debe estar presente en todas las rutas BGP. Por defecto, Junos asigna a todas las rutas inyectadas en BGP establece el valor del ORIGIN como "I" para IGP. Esto se puede alterar con un política de enrutamiento.
El atributo MED
Por defecto, BGP usa el MED (multiple exit discriminator) solo cuando un router BGP tiene 2 o más enlaces para enviar tráfico de salida.
El MED se usa para tratar de influir en el tráfico de una ruta cuando tiene que volver hacia el AS. El AS local configura el MED en diferentes equipos que apunten al mismo AS. El AS remoto escoge la ruta que tenga el MED más pequeño y lo manda por el equipo que lo haya recibido para devolvérselo al AS originario. Cunado se recibe un MEd desde un EBGP, este se pasa los vecinos IBGP pero nunca se envía a otro peer EBGP.
El MED no es un atributo obligatorio. Si no aparece, BGP le asigna un valor de 0.
El atributo COMMUNITY
El atributo COMMUNITY es un identificador que representa un grupo de direcciones de destino que comparten una propiedad en común. Se usan para etiquetar rutas específicas que puedan ser identificadas rápidamente para utilizarlas con varios propósitos. No lo necesitan entender todos los routers BGP pero debe ser enviado por todos.
Este atributo se configura a través de políticas de enrutamiento.
Las communities se configuran bajo "policy-options" y se hace una referencia en la política de enrutamiento. Se pueden asociar mútliples communities a una misma ruta BGP.
[edit
policy-options policy-statement ibgp-export]
user@R1# set then community ?
Possible
completions:
Name
to identify a BGP community
+
Add BGP communities to the route
-
Remove BGP communities from the route
=
Set the BGP communities in the route
add
Add BGP communities to the route
delete
Remove BGP communities from the route
set
Set the BGP communities in the route
|
Lo normal es borrar o cambiar las communities que entran a nuestro AS.
Well-Known Communities
Están definidas en la RFC 1997 y deben entenderla todos los equipos con BGP. Esto facilita la implementación de Communities entre diversos fabricantes:
- No-Export: se propagan las rutas al AS vecino pero este no las puede propagar más allá.
- No-Advertise: se propagan las rutas a los peers vecinos pero estos no las puede propagar más allá.
- No-Export-Subconfed: usado con Confederaciones permite porpagar las ruas a los AS de la subconfederación pero estos no las pueden propagar más allá
El uso avanzado de las communities está fuera del estudio del JNCIS.
SELECCIÓN DE LA RUTA EN BGP
Antes de que BGP instale una ruta en la tabla, el next-hop debe ser alcanzable y que no existan bucles. Si no hay conectividad con el next-hop o si hay un bucle, la ruta no entra en la selección ni es instalada en la tabla.
Antes de instalarse, se evalua la preferencia de la ruta. Recordad que esta preferencia se puede alterar con una política de enrutamiento haciendo que una ruta que proviene de dos pares diferentes tenga también una preferencia diferente. Y si es así, se elige la que tiene la preferencia más baja. Todo este proceso es antes de empezar con la selección de la ruta.
Cuando una ruta es instalada en la tabla, si existe más de un camino para llegar al mismo destino y con la misma preferencia, se inicia el proceso de la selección de la ruta. El orden es el siguiente.
- Elige la ruta con el "local-preference" más alto
- Elige el AS-PATH más corto. Normalmente es este campo el que acaba siendo el decisorio.
- Elige el ORIGIN más bajo. I (IGP) < E (EGP) < ? (Incomplete)
- Elige el MED más bajo. Si no hay MED, da por sentado un valor de 0.
- Elige ruta recibida de un EBGP antes que la de un IBGP. Si todas son EBGP, se va al punto 9
- 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.
- BGP examina el next-hop de las tablas inet.0 e inet.3 y elige el de menor preferencia
- Si hay empate, se usa el de la tabla inet.3
- Si continua el empate, se elige el next-hop que tenga más caminos instalados.
- 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.
- Longitud más corta del cluster-list. Es parecio al AS-PATH. Aquí "cluster" es sinónimo de Router Reflector
- ID de par más bajo
IBGP VS EBGP
El tipo de relación entre vecinos es importante a la hora de la decisión de la selección de rutas como hemos visto antes.
Para distinguir si es un IBGP o un EBGP es simple. Si los vecinos pertenecen al mismo AS, entonces hablamos de vecinos IBGP. Si pertenecen a distinto AS, entonces son EBGP.
VECINDAD DE PARES CON LOOPBACKS
 |
| La conectividad y la sesión se mantiene yendo por el otro camino |
Vamos a aprovechar esta topología para poner un ejemplo de configuración en R1:
routing-options {
router-id 192.168.0.1;
autonomous-system 65503;
}
protocols {
bgp {
group iBGP {
type internal;
local-address 192.168.0.1; - si no lo configuramos, usa la ip de la interface de salida
neighbor 192.168.0.2;
neighbor 192.168.0.3;
}
group eBGP {
type external;
peer-as 65502;
neighbor 172.24.1.1;
}
}
}
Si quisiermaos configrar la sesión eBGP con las loopbacks, tendríamos que añadir el comando multihop.
Cuando declaramos el AS (autonomous-system) todas las sesiones BGP tendrán ese origen a menos que usemos el comando local-as dentro del grupo bgp.
PROPOGACIÓN DE RUTAS ENTRE IBGP
Para la consitencia en las tablas de enrutamiento BGP, se requiere que todos los vecinos IBGP formen vecindad con todos los demás que pertenezcan al mismo AS.
La regla en BGP es que un IBGP no envía rutas a otro IBGP que haya recibido de un IBGP, ya que esto podría crear bucles.
En el ejemplo de arriba vemos que no está configurado el mallado completo. Cuando R1 recibe la ruta del AS 65502, este se la pasa a R2, pero R2 no se la pasa a R3 cumpliendo con la regla descrita anteriormente. Para solucionar esto, lo que hacemos es que R1 y R3 sean vecinos, es decir, creamos un mallado completo. Sin embargo, esta solución requiere de mucha propagación de rutas y de consumo de recursos, por lo que la solución para aliviar esto sería la de crear Router Reflector y Confederaciones. Esta solución está fuera del estudio del JNCIS.
PROPOGACIÓN DEL NEXT-HOP EN IBGP
Por defecto, el next-hop no cambia cuando pasa de un As a otro. Como los routers pueden usar las rutas BGP solo si ya tienen un next-hop alcanzable, debemos configurar BGP para que propague externamente las interfaces a través del IGP o configurar los routers para que cambien ese next-hop con una política de enrutamiento.
Cuando un par EBGP envía rutas a otro EBGP, el next-hop que le mandan es el de la interface con la que comparten la conexión. En el ejemplo de arriba, R1 recibe el next-hop de R2 con la dirección ip 172.24.1.1. R1 se lo manda a R2 SIN cambiar el next-hop. Por lo tanto, R2 debe saber cómo llegar a la 172.24.1.1 a través del IGP, de una ruta estática o que R1 cambie el next-hop para que R2 sepa llegar a través de él.
Esta última opción podemos configurarla estableciendo en R1 el atributo "next-hop-self". De esta manera R1 enviará la ruta a R2 y el next-hop será la dirección ip con la que ya tenga formada la sesión iBGP con R2. Es decir, mientras la sesión esté establecida, R2 sabrá llegar a la 172.24.1.1.
REGLAS DE PROPOGACIÓN DE RUTAS EN BGP
Por defecto, BGP solo propaga rutas que estén activas.
Las reglas por defecto son:
- IBGP propaga rutas recibidas de un EBGP a otros IBGPs.
- EBGP propaga rutas recibidas de IBGPs o EBGPs a otros EBGPs
- IBGP no propaga rutas recibidas de IBGPs a otros IBGPs
Estas reglas se establecen para evitar bucles de enrutamiento.
No hay comentarios:
Publicar un comentario