Los updates son incrementales y cuando hay cambios en la red.
Aunque es un gran protocolo, es el usado para internet, suele ser lento en la convergencia.
BGP no tiene visibilidad de la topología de la red o del coste de los enlaces, esto lo delega su protocolo de transporte, en el IGP. Las decisiones de enrutamiento están asociadas a los atributos de las direcciones ip, no a los enlaces.
Al igual que OSPF, también usa sistemas autónomos (AS). Se puede decir que BGP es como Rip, que va por saltos, pero no de router en router, sino saltos de AS en AS. Cada vez que pasa por un AS, lo añade al campo AS_PATH.
Para elegir la rutas se basa en los "path attributes", donde se define la información de la ruta. Son como etiquetas. Estos atributos son muchos. Los más importantes son:
Weight: influye en las rutas en el router local. Solo en Cisco.
Local preference: influye en las rutas en todos los routers del mismo AS. No se envia a los vecinos EBGP.
AS_Path: muestra el número de AS en el camino.
Origin: muestra si es IGP o EGP.
Next Hop Address: siguiente salto para llegar al destino
MED: influye en las rutas en todos los routers de otros AS.
AS_Path, Origin y Next Hop Address son obligatorios.
Un router nunca puede pertenecer a más de un AS.
El orden de los atributos a la hora de elegir la mejor ruta hacia el destino es:
- Ignora las rutas que no tengan un next hop accesible (unaccesible)
- Prefiere la ruta con el WEIGHT más alto (default 32768)
- Prefiere la ruta con el LOCAL_PREF mas alto (default 100)
- Prefiere las rutas creadas con el comando network a las redistribute y estas, a las aggregate.
- Prefiere la rutas con el AS_PATH más corto
- Origin. Prefiere IGP (I) a EGP (E) y EGP a Incomplete (?). Cuando un ruta tiene un Origin I es porque se ha configurado con el comando "network". Cuando vemos la ?, es porque son rutas redistribuidas.
- Prefiere la rutas con el MED más bajo (default 0)
- Prefiere eBGP antes que iBGP
- Prefiere la ruta con la métrica IGP más baja al siguiente salto
- Determina si multiples rutas necesitan instalar en la routing table para el BGP MultiPath
- Cuando ambas rutas hacia destino son externas, prefiere la que fue recibida primero
- Prefiere la ruta que viene de un router BGP con el ID más bajo
- Si para llegar al ID hay varios caminos, prefiere el que menos saltos tenga
- Prefiere la ruta que viene del router con la dirección ip del vecino más baja.
Hay un fallo que se ve mucho que se produce cuando la ruta instalada en la tabla de rutas no es la mejor para llegar a ese destino aunque sí lo es en la tabla de BGP. Es el Rib-Failure y, si hacemos un show ip route la podemos ver marcada como r> Por defecto estas rutas se propagan, pero podemos hacer que no lo hagan ya que pueden crearnos un bucle en ciertos escenarios:
bgp suppress-inactive
Si cuando recibe un UPDATE, en la ruta el equipo ve su propio AS, la descarta para prevenir bucles. Este comportamiento se puede evitar con el comando "allow-as in".
El primer AS que ve en la ruta tiene que ser el del vecino. Podemos forzar para que sea así con el comando bgp enforce-first-as
Cuando ha elegido la mejor ruta, solo es esta ruta la que se instala en la RIB y esta se la pasa a la FIB. Esta es la ruta que se propaga a los vecinos.
Sabiendo los atributos y las reglas, podemos configurar nuestras políticas de enrutamiento para modificar el tráfico tanto de entrada como de salida. Estas políticas son totalmente independientes. Esta versatilidad es uno de los éxitos de BGP.
La mayoría de la veces es el AS_PATH el que determina la elección. El número de AS está restringido. No se puede configurar uno cualquiera.
RANGO DE AS
|
FUNCIÓN
|
0
|
RESERVADO
|
1 – 64495
|
USO PÚBLICO IANA
|
64496 – 64511
|
RESERVADO PARA DOCUMENTACIÓN
|
64512 – 65534
|
RANGO PRIVADO
|
65535
|
RESERVADO
|
Estos son los rangos originales, se componían de número de 2 bytes. Hace tiempo se aprobó la RFC 4893 para que estos número fueran de hasta 4 bytes, creando un número de 4 octetos. Cisco lo soporta desde las IOS 12.4 (24)T
¿Cómo determina el la ruta a través del AS_PATH?
 |
| R1 elige el camino de arriba aunque pasa por más equipos |
Podemos modificar este comportamiento haciendo "Prepend" . En R12 podemos configurar BGP y decirle que el camino de arriba, el AS_PATH 150-100, va a a tener más AS de por medio. En realidad, engañamos al protocolo y lo que se hace es repetir el propio AS el número de veces que haga falta para que ese camino tenga más paths en medio que el camino de abajo. En R12 configuraríamos.
(config-router)#as_path prepend 65001 65001 65001
A R1 le llegaría un path por el camino de arriba de 100-150-65001-65001-65001
A R1 le llegaría un path por el camino de abajo de 200-220-230-65001
Así conseguiríamos que escogiesen el camino más eficiente.
En BGP recibimos los updates desde el vecino. En una topología donde nosotros somos la empresa, del ISP recibimos updates:
- Un ruta por defecto 0.0.0.0 apuntando al equipo de proveedor
- Podemos recibir también la tabla entera de BGP (todo Internet)
- Podemos recibir updates parciales donde nos llegan las rutas BGP que necesitamos
Para propagar rutas a través del protocolo BGP:
- Con el comando network (auto summary por defecto)
- Redistribuir otros protocolos
- Aggregate-address: sirve para sumarizar
- También se propagan las que recibimos y están activas para el proceso BGP
AS EN TRÁNSITO
Entre los proveedores de Internet se establecen acuerdos de peering para dejar pasar tráfico de tránsito, es decir, un tráfico que pasa por nuestro AS, pero no es ni origen ni destino. A través de nuestro AS (estamos hablando como si fueramos un proveedor) pasamos todas las rutas BGP de Internet y el tráfico en tránsito como por ejemplo el de Google.
Hay una regla básica (synchronization) cuando estamos haciendo de tránsito:
BGP no debe propagar una ruta hasta que todos los routers del AS hayan aprendido esa ruta primero a través del IGP (Interior Gateway Protocol).
Es un comportamiento heredado de hace años cuando no todos los equipos IGP podían soportar las tablas de rutas de BGP. Desde la IOS 12.2(8)T viene deshabilitado por defecto.
Paquetes BGP
Open: inicia la sesión
Keepalive: para mantener la sesión. Los procesa el control plane.
Update: intercambio de información de rutas
Tiene 2 campos:
- Update: las rutas para añadir a la tabla
- Withdraw: las rutas para suprimir de la tabla
Notification: algo malo ha sucedido. Cierra la sesión
Tabla en BGP
Neighbor Topology: los equipos con los que hemos formado la vecindad
BGP Table: la lista de todas las rutas BGP
Routing Table: la lista de las mejores rutas
Vecindad
Dos tipos de vecindad:
iBGP: Interna. Mantiene las relaciones de vecindad dentro del mismo AS
eBGP: Externa. Mantiene las relaciones de vecindad con AS externos
Los vecinos se tienen que configurar manualmente, no hay autodiscovery. Tampoco tienen por qué estar directamente conectados. Solo necesitan un IGP para tener comunicación.
Cuando configuramos con el comando "neighbor", le estamos diciendo al equipo que inicie una sesión con el vecino y escuche por el puerto 179 de esa dirección del vecino que le hemos configurado.
Pasos en la formación de la vecindad:
- IDLE: verificando si tiene ruta al vecino
- CONNECT: negociando el 3 -Way Handshake (Syn, Syn-Ack, Ack)
- ACTIVE: Negociando el transporte. También si no se ha recibido el OPEN CONFIRM del vecino
- OPEN SENT: OPEN Message enviado (Versión, AS, Holdtime, ID, etc)
- OPEN CONFIRM: el vecino responde al mensaje
- ESTABLISHED: vecindad formada e intercambio de UPDATES.
Una vez establecida la vecindad se envían los mensajes UPDATE para que conozcan las rutas (NLRI - Network Layer Reachability Information) y se empiezan a mandar mensajes "keep alive" para mantener la sesión.
En estos NLRI vienen 3 campos:
- Dirección ip
- Máscara
- Next Hop - que no tiene por qué ser el vecino ya que podemos modificarlo con los atributos de BGP
Para configurar la vecindad:
(config)#router bgp X - número de AS
(config-router)#neighbor X.X.X.X remote-as X - número de AS
Cuando enviamos el paquete, el origen de este es la interface de salida de la tabla de rutas. Esto puede ser modificado. Es una práctica común que en un escenario de iBGP, como en un ISP, las vecindades se formen con origen desde las interfaces loopback. ¿Por qué? Estas no se caen nunca. En un escenario de eBGP, como los enlaces que conectan a dos ISP, se usa la dirección de la interface porque si no tendríamos que conocer las loopback del otro ISP y, a parte de que es saber su espacio de direccionamiento privado, sin un IGP por medio o una ruta estática no conocemos esa loopback.
(config-router)#neighbor X.X.X.X update-source loopback X
Tenemos dos configuraciones para el "peering" (formación de la vecindad):
- Active - Intenta iniciar la sesión (por defecto)
- Passive - Solo escucha.
Dos equipos en Passive no formarán la vecindad.
Podemos modificarlos:
(config-router)#neighbor X.X.X.X transport-connection mode passive
BGP nos permite el "peering dinámico", muy usado con DMVPN. Los equipos escuchan en el puerto 179 de una lista de direcciones y si le solicitan la sesión la establece si el vecino está en la lista.
También podemos hacer grupos para las vecindades (group peering). Agrupamos las vecindades que tengan configuraciones comunes. Esto lleva asociado un "Update Group", que hace que el router no tenga que procesar un UPDATE distinto para cada vecino del grupo. Procesará el mensaje UPDATE una vez y hará una copia de ese UPDATE para enviar a cada vecino.
Otra opción serían las plantillas (BGP Peer Templates). Se pueden ir enlazando unas con otras (inherit). Tenemos 2 tipos:
- Session Template: Se definen atributos, update-source, password, etc.
- Policy Session: define las opciones de la AFI (Adrress Family)
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 peer 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 BGP 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.
FILTRO DE RUTAS EN BGP
En BGP podemos filtrar de muchas maneras:
Distribute-List -> neighbor X.X.X.X distribute-list [standar/extended acl]
Filter-List -> neighbor X.X.X.X filter-list [as-path-acl]
Prefix-List -> neighbor X.X.X.X prefix-list [prefix-list name]
Route-Map -> neighbor X.X.X.X route-map X
Communities -> set community AA:NN
Conditional Advertisments
Ejemplos:
Bloquear las rutas 192.168.0.0 del vecino X.X.X.X con prefix-list:
ip prefix-list BLOQUEO_RUTAS permit 192.168.0.0/24
route-map BLOQUEO_RUTAS_MAP deny 10
match ip address prefix-list BLOQUEO_RUTAS
route-map BLOQUEO_RUTAS_MAP permit 20
router bgp
neighbor X.X.X.X route-map BLOQUEO_RUTAS_MAP in
Hacer Prepend de las rutas que propagamos a un vecino:
ip prefix-list PREPEND permitX.X.X.X
route-map PREPEND_MAP
match ip address prefix-list PREPEND
set as-path prepend X X X X -> Números de AS (límite de 10)
router bgp
neighbor X.X.X.X route-map PREPEND_MAP out
Por cierto, BGP admite todas las rutas por defecto. Ya sabemos que estas actualmente sobrepasan las 700.000 a nivel global en Internet. Así que, podemos limitar el número de rutas que nos pasa el vecino. Desde el punto de vista de un ISP, un cliente no nos debería pasar toda la tabla. Para limitar esto:
router bgp
neighbor X.X.X.X maximum-prefix
El resultado crea un log y podemos hacer caer la vecindad.
Entre ISP's se pasan la ruta entera pero un cliente de un ISP no necesita tenerla. El ISP le genera una ruta por defecto hacia él y este ya lo enruta con su tabla BGP.
Sin embargo, un cliente puede querer ver cierta parte de la tabla en sus equipos. A esto se le llama ORF (Outbound Route Filter Capabilities). La RFC es la 5291. No es un servicio estándar de los ISP.
router bgp
neighbor X.X.X.X capability orf prefix-list [send| receive| both]
NOTA: al habilitarlo se cae la vecindad BGP
Tenemos que habilitarlo en los dos lados. Lo que hacemos es desde el equipo downstream, el cliente, creamos un prefix-list para decirle al equipo del ISP que queremos que nos envíe de la tabla que tiene (advertised-routes):
En el cliente:
ip prefix-list ORF permit 0.0.0.0/0 ge 30 -> ver solo las /30 y mayores
router bgp
neighbor X.X.X.X capability orf prefix-list send
neighbor X.X.X.X prefix-list ORF in -> ojo con esto, se aplica en inbound.
En el ISP (no hay prefix-list):
router bgp
neighbor X.X.X.X capability orf prefix-list receive
show ip bgp neighbos X.X.X.X receive prefix-filter
También podemos influir el tráfico con Communities.
Es la manera de BGP para configurar "etiquetas". Esto son como plantillas donde configuramos los atributos que se
aplican antes de la la política de entrada que tengamos configurada.
Estamos diciendo a los vecinos eBGP que vamos a hacer con esa ruta cuando nos
entre si tiene esas communities.
Se usan especialmente para agrupar direcciones en la política de propagación de rutas, en el filtro a la entrada y para influir en la elección de la mejor ruta.
Una Community es un atributo de tránsito opcional, es decir, no tiene por qué intercambiarse entre los vecinos por defecto. Para forzarlo:
router bgp
neighbor X.X.X.X send-community
El formato estándar de las communities es un valor de 4 bytes. El formato antiguo era en con un valor de entre 0 y 4294967296. Este es el formato que te muestra Cisco por defecto.
El nuevo formato es con ":" y se compone de:
AA:NN - donde AA es el número de AS y NN es un número con significancia local, como por ejemplo establecer el LOCAL PREFERENCE.
Para que nos muestre el nuevo formato podemos hacerlo de dos maneras dependiendo de la IOS:
ip bgp new-format
ip bgp-community new format
Existen communities reservadas (well-known communities):
- No-Export (0xFFFFFF01) -> no propaga rutas a los EBGP
- No-Advertise (0xFFFFFF02) -> no propaga a ningún vecino
- Local-AS (0xFFFFFF03) -> no propaga a la Confederación de EBGP's
Si queremos que las rutas que le entregamos al vecino, este no las propague a ningún EBGP que tenga, configuraremos la community No-Export. Si queremos que no se las propague ni si quiera a un IBGP, configuramos No-Advertise.
Para que se ejecute correctamente una community tenemos que configurarla en un route-map:
set community AA:NN {community-number [additive] [well-known] | none }
"Additive" no viene configurado por defecto y, ojo que si no le ponemos "additive" borrará la que ya tiene.
Para borrar solo una community usamos al final "none"
Para asociar el tráfico usamos las "Community-List". Aquí definimos una lista a nviel de (config)# que podemos hacer de varias maneras:
- Standard -> asociada a un número o nombre
- ip community-list 1-99 permit no-export
- ip community-list standard NOMBRE permit no-advertise
- Expanded -> asociada a una regular expression:
- ip community-list 100-500 permit XX:[0-9]+/1
- ip community-list expanded NOMBRE permit XX:[0-9]+/1
Después la asociamos a un route-map:
(config)#route-map COMMUNITY permit 10
(config-route-map)#match community NOMBRE
También tenemos las Extended Communities en la RFC 4360. Están mas orientadas para el servicio MPLS. Entraré más en profundidad en ese apartado
Por último, las Conditional Advertisements donde jugamos a crear condiciones con los atributos.
En general, cuando aplicamos una política en "inbound", podemos modificar cualquier atributo. Es decir, al ISP vecino le pasamos una ruta con Prepend de 3 AS y cuando nos la devuelve esa ruta ha sido modificada. Con las Conditional Advertisements podemos evitar esto, que se denomina Route Supression.
Para configurar esto necesitamos:
- advertise-map
- non-exist-map
La regla es:
- Si hay un prefijo (dirección, ruta) que coincide con el prefix-list del non-exist-map, es decir, si deja de estar en la tabla BGP, entonces propaga (advertise) hacia la otra dirección lo configurado en el advertise -map
Esto es muy usado para monitorizar los fallos de los enlaces de tránsito.
Son expresiones que podemos usar para especificar que podemos ver con el comando show y también a la hora de usar TCL o en las communities list y as-path list.
La verdad es que son muy útiles pero no es un tema fácil de explicar. Por ahora os dejo el enlace al documento de Cisco
show ip bgp regexp X
Documento de Cisco sobre Regular Expressions
CONVERGENCIA
Como sabemos, BGP es un protocolo de lenta convergencia. A la hora de detectar caídas de enlaces y vecinos podemos dividirlo en 4 pasos:
- Cuanto tiempo tarda en detectar el fallo (los tiempos de keepalive y hold time)
- Cuanto tiempo tarda en propagar los cambios (withdraw/update)
- Cuanto tiempo tarda en recalcular al mejor ruta
- Cuanto tiempo tarda en instalar la ruta en la forwarding table (FIB Download).
Lo más lógico a primera vista sería reducir el tiempo del intervalo de los keepalive (60s por defecto) y el hold time (180s por defecto) del paso 1:
router bgp
neighbor X.X.X.X timers X X - > hello y hold time
Si configuramos un "hold time" de menos de 20s, el propio router nos advertirá de que puede causar "peer flapping". Es decir, si el vecino está ocupado procesando mucho y tarda más de ese tiempo, tira la vecindad y perdemos las rutas pero no se ha caído, solo estaba ocupado. Creamos un "falso positivo".
Cuando los vecinos están negociando, aquel que tenga los valores más bajos impondrá al otro sus valores. La mayoría de los ISP no dejan hacer esto.
Una solución más óptima es configurar BFD en ambos lados del enlace:
router bgp
neighbor X.X.X.X fall-over bfd
Interface X
bfd interval 150 min_rx 300 multiplier 3
show bfd neighbors details
BFD les dirá a los protocolos de capa superior (Registered Protocols) antes que los hello, que el enlace se ha caído y que tiene que hacer reconvergencia.
Otra opción es la las "Additional Paths". Son como las rutas de backup de EIGRP, la del Feasible Successor". Hace que se instale en la propia CEF uno o varios caminos alternativos. Al estar en la forwarding table, evitamos justamente los pasos 3 y 4 y, además, hace que no importe el paso 2 porque ya tiene ruta alternativa. Se inserta un único "ID Path Identifier" en un campo dedicado en el NLRI para poder diferenciar las diferentes rutas disponibles.
Hay un ejemplo práctico al final de Router Reflector.
Así que, si configuramos BFD a 25 ms y las Additional Paths a la vez, tendremos una convergencia que en realidad será el tiempo que le configuremos a BFD, ya que las Additional Paths son inmediatas. Las aplicaciones ni se darán cuenta.
Soft Reconfiguration Inbound
Esto sirve para limpiar la tabla de BGP que recibimos. El equipo hace una copia de la RIB. Consume más memoria pero nos ayuda cuando hay problemas. Tenemos que configurarlo:
router bgp
neighbor X.X.X.X soft-reconfiguration inbound
Las rutas que se ven cuando está configurado son las del comando:
show ip bgp neighbors X.X.X.X received-routes
Route-Refresh
Se negocia entre vecinos en el OPEN Message. Le pedimos al vecino que nos mande un UPDATE o se lo mandamos nosotros sin tener que resetear la sesión. No consume memoria. Lo hacemos con:
clear ip bgp X.X.X.X soft in
clear ip bgp X.X.X.X soft out
clear ip bgp X.X.X.X soft - ejecutamos ambos
 |
| show ip bgp neighbors X.X.X.X |
Podemos ver que se ha negociado en la sesión.
Algunos comandos útiles:
sh ip bgp - tabla BGP
sh ip bgp sum - vecinos y algunos datos
sh ip bgp neighbor X.X.X.X advertised - rutas enviadas del vecino
sh ip bgp neighbor X.X.X.X routes - rutas recibidas del vecino
clear ip bgp * soft - no cae la vecindad pero resetea la table
clear ip bgp * soft - cae la vecindad
debug ip bgp events
Documento sobre BGP Wedgies
LABORATORIO BGP
No hay comentarios:
Publicar un comentario