Fundamentos de BGP

Uno de los temas más intimidantes para los candidatos a las certificaciones de Cisco es lo referido al protocolo BGP (Border Gateway Protocol).

Para ayudar a eliminar incertidumbres y dudas que rodean al BGP, compartiremos una serie de publicaciones de blog con ustedes para ayudar a desmitificar este protocolo de enrutamiento. En esta primera publicación de la serie, conoceremos los conceptos básicos de BGP y aprenderá sobre los distintos tipos de mensajes y estados.

Antes de continuar leyendo, debería decirles que “olviden” todo lo que saben sobre protocolos de enrutamiento como RIP, OSPF y EIGRP hasta ahora … Esos tres protocolos de enrutamiento tienen una cosa en común: todos ellos son IGP (Protocolos de pasarela interior). Solo los usamos dentro de nuestro sistema autónomo, pero no son escalables para usarlos en una red tan grande como Internet.

RIP, OSPF y EIGRP son todos diferentes, pero tienen una cosa en común: quieren encontrar el camino más corto hacia el destino. Cuando miramos Internet, no nos importa tanto encontrar el camino más corto, poder manipular el tráfico es mucho más importante. Solo hay un protocolo de enrutamiento que actualmente utilizamos en Internet, que es BGP.

Vamo’ a darle: Border Gateway Protocol es increíblemente único, especialmente cuando lo comparamos con otros protocolos de enrutamiento. Lo primero que hace que BGP sea tan único, es lo que hace por nosotros. Es nuestro único protocolo de gateway exterior (EGP) en uso importante en la actualidad, lo que significa que (generalmente) va a tomar prefijos que están dentro de un sistema autónomo y los envía a otros sistemas autónomos. La Figura 1 muestra un ejemplo de topología BGP.

Es por esto que BGP es el protocolo que hace funcionar la Internet. Los proveedores de servicios de Internet (ISP) pueden usar BGP para mover la información de prefijo entre otros proveedores de servicios de Internet. Sin embargo, las características únicas de BGP no se detienen ahí. Una de las cosas que es muy singular acerca del protocolo es que forma pares de punto a punto con otros enrutadores configurados con BGP, y son los administradores de red quienes crean estos pares manualmente.

Con Border Gateway Protocol no existe tal cosa como formar un vecindario con una gran cantidad de dispositivos en el mismo segmento de forma automática. Para cada uno de los dispositivos con los que BGP necesita par, lo hace utilizando una única relación peer-to-peer, lo que preferimos llamar peer BGP.

Otra propiedad muy única implica el hecho de que BGP es un protocolo de capa de aplicación. Como componente de la capa de aplicación, BGP hace algo brillante. Aprovecha el Protocolo de Control de Transmisión (TCP) para sus operaciones.

Con Border Gateway Protocol, los diseñadores decidieron no diseñar todos los tipos de controles de confiabilidad en el protocolo. Simplemente confían en las maravillas que son las comunicaciones confiables de TCP. Específicamente, BGP usa el puerto TCP 179.

Sistemas Autónomos:

Un AS es una colección de redes bajo un único dominio administrativo. Internet no es más que un montón de sistemas autónomos que están conectados entre sí. Dentro de un sistema autónomo usamos un IGP como OSPF o EIGRP.

Para el enrutamiento entre los diferentes sistemas autónomos utilizamos un EGP. El único EGP que utilizamos hoy en día es BGP.

¿Cómo obtenemos un número de sistema autónomo? Al igual que el espacio de direcciones IP públicas, deberás registrar una.

Los números del sistema autónomo son de 16 bits, lo que significa que tenemos 65535 números para elegir. Al igual que las direcciones IP privadas y públicas, tenemos una gama de números AS públicos y privados.

El rango 1 – 64511 son números AS únicos a nivel mundial y el rango 64512 – 65535 son números de sistema autónomos privados.

BGP tiene dos sabores:

• BGP externo: utilizado entre sistemas autónomos
• BGP interno: utilizado dentro del sistema autónomo.

Cuando formamos un peering entre sistemas autónomos distintos, esto se denomina Protocolo de pasarela de borde exterior (EBGP). Recuerde, la razón por la que BGP distingue entre un peering IBGP y un peering EBGP, es que las características operativas tendrán que cambiar en función de cómo se hace el peering. Por ejemplo, indicamos que hay una ruta AS, que registra los sistemas autónomos que se transitan. Claramente, en un peering EBGP, cuando se envía un prefijo de un AS a otro AS, el AS que envía debe poner su sistema autónomo en la ruta. Pero con IBGP, el prefijo permanece dentro de un AS, por lo que BGP no inserta el valor de AS en la actualización. Puede consultar la Figura 1 para ver en acción estos diferentes tipos de pares.

Mensajes de BGP

BGP utiliza una variedad de mensajes para establecer la conexión, intercambiar información de enrutamiento, verificar si el vecino remoto de BGP todavía está allí y / o notificar al lado remoto si ocurre algún error.

Para hacer todo esto, BGP usa 4 mensajes:

Open
Una vez que dos enrutadores BGP hayan completado un protocolo de enlace de tres vías TCP, intentarán establecer una sesión BGP, esto se hace usando mensajes abiertos. En el mensaje abierto encontrará información sobre el enrutador BGP, ambos deben ser negociados y aceptados por ambos enrutadores antes de que podamos intercambiar información de enrutamiento.

Update
Una vez que dos enrutadores se han convertido en vecinos de BGP, pueden comenzar a intercambiar información de enrutamiento. Esto se hace con el mensaje de actualización. En el mensaje de actualización encontrará información sobre los prefijos que se anuncian. En el “idioma BGP”, un prefijo se conoce como NLRI (información de alcance de la capa de red).

Keepalive

Cuando no hay rutas para anunciarse o retirarse, no hay mucho que nuestros vecinos BGP tengan que compartir entre sí. Para asegurarnos de que el otro lado esté “todavía allí”, usamos estos mensajes de actividad periódica. Por defecto, BGP envía mensajes de keepalive de 19 bytes cada 60 segundos. Cuando un vecino de BGP remoto pierde tres keepalives (3 x 60 = 180 segundos, el valor del tiempo de espera) vaciará las rutas del vecino de BGP.

Notification

El mensaje de notificación se usa cuando ocurre un error que resultará en la terminación de la adyacencia del vecino BGP. Cuando algo sale mal, el mensaje de notificación se enviará y la sesión finalizará.

La sesión TCP se borrará, todas las entradas de este vecino BGP se eliminarán de la tabla BGP y los mensajes de actualización con retiros de ruta se enviarán a otros vecinos BGP.

Estados vecinos de adyacencia BGP

Idle: este es el primer estado en el que BGP espera un “evento de inicio”. El evento de inicio se produce cuando alguien configura un nuevo vecino BGP o cuando restablecemos un par de BGP establecido. Después del evento de inicio, BGP inicializará algunos recursos, restablecerá un temporizador ConnectRetry e iniciará una conexión TCP con el vecino BGP remoto. También comenzará a escuchar una conexión en caso de que el vecino BGP remoto intente establecer una conexión. Cuando tiene éxito, BGP se mueve al estado Conectar. Cuando falla, permanecerá en estado inactivo.

Connect ​​BGP está esperando a que se complete el protocolo de enlace de tres vías de TCP. Cuando tenga éxito, continuará al estado de OpenSent. En caso de que falle, continuamos al estado Activo. Si el temporizador de ConnectRetry expira, permaneceremos en este estado. El temporizador ConnectRetry se reiniciará y BGP intentará un nuevo protocolo de enlace de tres vías TCP. Si ocurre algo más (por ejemplo, restablecer BGP), entonces regresamos al estado Inactivo.

Active BGP intentará otro protocolo de enlace de tres vías TCP para establecer una conexión con el vecino BGP remoto. Si tiene éxito, pasará al estado OpenSent. Si el temporizador de ConnectRetry expira, entonces volvemos al estado de conexión. BGP también seguirá escuchando las conexiones entrantes en caso de que el vecino de BGP remoto intente establecer una conexión. Otros eventos pueden hacer que el enrutador vuelva al estado Inactivo (por ejemplo, restablecer BGP).

OpenSent: En este estado, BGP estará esperando un mensaje de Abrir desde el vecino de BGP remoto. El mensaje Abrir será revisado en busca de errores, si algo está mal (números de versión incorrectos, número AS incorrecto, etc.), entonces el BGP responderá con un mensaje de Notificación y salta al estado de Inactivo. Este es también el momento en el que BGP decide si usamos EBGP o IBGP (ya que verificamos el número de AS). Si todo está bien, BGP comienza a enviar mensajes de keepalive y restablece su temporizador de keepalive.

En este momento, se negocia el tiempo de espera (se selecciona el valor más bajo) entre los dos enrutadores BGP. En caso de que la sesión TCP falle, BGP volverá al estado Activo. Cuando ocurre cualquier otro error (vencimiento del temporizador de espera), BGP enviará un mensaje de notificación con el código de error y saltará al estado de inactividad. En caso de que alguien reinicie el proceso BGP, también saltamos al estado de inactividad.

OpenConfirm: BGP espera un mensaje de keepalive del vecino de BGP remoto. Cuando recibamos el keepalive, podemos pasar al estado establecido y se completará la adyacencia del vecino. Cuando esto ocurra, reiniciará el temporizador de espera. Si recibimos un mensaje de notificación del vecino BGP remoto, entonces regresamos al estado Inactivo. BGP seguirá enviando mensajes keepalive.

Established la adyacencia del vecino BGP está completa y los enrutadores BGP enviarán paquetes de actualización para intercambiar información de enrutamiento. Cada vez que recibimos un mensaje de keepalive o actualización, el temporizador de espera se restablecerá. En caso de que recibamos un mensaje de notificación, volveremos al estado Inactivo.

Se puede visualizar todo este proceso para convertirse en vecinos de BGP, esto podría ser un poco más fácil que solo leerlo. El nombre oficial de un “diagrama” que muestra los diferentes estados y podemos pasar de un estado a otro se llama FSM (Finite State Machine).

Para BGP, se ve así:

Bueno, eso será todo para esta primera publicación del blog de BGP. Manténgase atento a la siguiente, donde profundizaremos en los atributos de ruta (PA) y cómo BGP toma las decisiones de selección de ruta.

]]>