Principios de funcionamiento del protocolo BGP

Hoy revisaremos el protocolo BGP. No vamos a hablar mucho sobre por qué se usa como el único protocolo. Hay bastante información al respecto, por ejemplo aquí.

Entonces, ¿qué es BGP? BGP es un protocolo de enrutamiento dinámico que es el único protocolo EGP (Protocolo de Puerta de Enlace Externa). Este protocolo se utiliza para construir el enrutamiento en Internet. Veamos cómo se establece la vecindad entre dos enrutadores BGP.

Principios de funcionamiento del protocolo BGP
Consideremos la vecindad entre Router1 y Router3. Los configuraremos utilizando los siguientes comandos:

router bgp 10
  network 192.168.12.0
  network 192.168.13.0
  neighbor 192.168.13.3 remote-as 10

router bgp 10
  network 192.168.13.0
  network 192.168.24.0
  neighbor 192.168.13.1 remote-as 10

La vecindad dentro de un mismo sistema autónomo — AS 10. Después de ingresar los datos en el enrutador, por ejemplo en Router1, este enrutador intenta establecer relaciones de vecindad con el enrutador Router3. El estado inicial, cuando no sucede nada, se llama Idle. Una vez que BGP esté configurado en Router1, comenzará a escuchar el puerto TCP 179 — pasará al estado Conexión, y cuando intente abrir una sesión con Router3, pasará al estado Activo.

Después de que se establezca la sesión entre Router1 y Router3, se produce el intercambio de mensajes Open. Cuando este mensaje sea enviado por Router1, este estado se llamará Open Sent. Y cuando reciba un mensaje Open de Router3, pasará al estado Open Confirm. Veamos más de cerca el mensaje Open:

Principios de funcionamiento del protocolo BGP
Este mensaje transmite información sobre el protocolo BGP que utiliza el enrutador. Al intercambiar mensajes Open, Router1 y Router3 se informan mutuamente sobre sus configuraciones. Se transmiten los siguientes parámetros:

  • Versión: esto incluye la versión de BGP que está utilizando el enrutador. La versión actual de BGP es la versión 4, que se describe en el RFC 4271. Dos enrutadores BGP intentarán negociar una versión compatible; cuando hay un desacuerdo, no habrá sesión BGP.
  • My AS: esto incluye el número AS del enrutador BGP, los enrutadores tendrán que acordar los números AS y también define si ejecutarán iBGP o eBGP.
  • Hold Time: si BGP no recibe ningún mensaje de keepalive o actualización del otro lado durante la duración del tiempo de retención, declarará que el otro lado está 'muerto' y destruirá la sesión BGP. Por defecto, el tiempo de retención está configurado en 180 segundos en los enrutadores Cisco IOS; el mensaje de keepalive se envía cada 60 segundos. Ambos enrutadores deben acordar el tiempo de retención o no habrá sesión BGP.
  • BGP Identifier: este es el ID local del enrutador BGP que se elige de la misma manera que OSPF:
    • Use el router-ID que fue configurado manualmente con el comando bgp router-id.
    • Use la dirección IP más alta en una interfaz de loopback.
    • Use la dirección IP más alta en una interfaz física.
  • Optional Parameters: aquí encontrarás algunas capacidades opcionales del enrutador BGP. Este campo se ha añadido para que se puedan agregar nuevas características al BGP sin necesidad de crear una nueva versión. Las cosas que podrías encontrar aquí son:
    • soporte para MP-BGP (BGP de Múltiples Protocolos).
    • soporte para Route Refresh.
    • soporte para números AS de 4 octetos.

Para establecer la vecindad, es necesario cumplir las siguientes condiciones:

  • Número de versión. La versión actual es 4.
  • El número AS debe coincidir con el que has configurado neighbor 192.168.13.3 remote-as 10.
  • El Router ID debe ser diferente del del vecino.

Si alguno de los parámetros no satisface estas condiciones, el enrutador enviará Notification un mensaje que indicará el error. Después de enviar y recibir los mensajes Open, la relación de vecindad pasa a estado ESTABLISHED. Después de esto, los enrutadores pueden intercambiar información sobre rutas, y lo hacen a través de mensaje de Update. Este es un mensaje de Update que Router1 envía a Router3:

Principios de funcionamiento del protocolo BGP

Aquí se indican las redes sobre las que informa Router1 y los atributos de Path, que son análogos a las métricas. Hablaremos más en detalle sobre los atributos de Path. También se envían mensajes Keepalive a través de la sesión TCP. Se envían, por defecto, cada 60 segundos. Este es el Timer de Keepalive. Si durante el Hold Timer no se recibe un mensaje Keepalive, esto significará la pérdida de conexión con el vecino. Por defecto, es igual a 180 segundos.

Tabla útil:

Principios de funcionamiento del protocolo BGP

Parece que hemos aclarado cómo los enrutadores transmiten información entre sí, ahora intentemos entender la lógica de funcionamiento del protocolo BGP.

Para anunciar una ruta en la tabla BGP, al igual que en los protocolos IGP, se utiliza el comando network, pero la lógica de funcionamiento es diferente. Si en IGP, después de especificar la ruta en el comando network, IGP mira qué interfaces pertenecen a esa subred y las incluye en su tabla, el comando network en BGP consulta la tabla de enrutamiento y busca una coincidencia exacta con la ruta en el comando network. Al encontrar tales coincidencias, estas rutas ingresarán a la tabla BGP.

Busca una ruta en la tabla de enrutamiento IP actual del enrutador que coincida exactamente con los parámetros del comando network; si la ruta IP existe, coloca el NLRI equivalente en la tabla BGP local.

Ahora levantaremos BGP en todos los restantes y veremos cómo se realiza la selección de ruta dentro de un mismo AS. Después de que el enrutador BGP reciba rutas del vecino, comienza la selección de la ruta óptima. Aquí se debe entender qué tipo de vecinos pueden ser: internos y externos. ¿El enrutador, según la configuración, entiende si el vecino configurado es interno o externo? Si en el comando:

neighbor 192.168.13.3 remote-as 10 

Como parámetro remote-as se indica el AS que está configurado en el propio enrutador en el comando router bgp 10. Las rutas que provienen de un AS interno se consideran internas, y las rutas externas, por supuesto, externas. Y se aplica una lógica diferente de obtención y envío para cada una. Consideremos la siguiente topología:

Principios de funcionamiento del protocolo BGP

En cada enrutador está configurada una interfaz loopback con ip: x.x.x.x 255.255.255.0 — donde x es el número del enrutador. En Router9 tenemos una interfaz loopback con la dirección — 9.9.9.9 255.255.255.0. Esta la vamos a anunciar por BGP y veremos cómo se distribuye. Esta ruta será transmitida a Router8 y Router12. Desde Router8, esta ruta llegará a Router6, pero en Router5 no estará en la tabla de enrutamiento. Asimismo, en Router12, esta ruta ingresará en la tabla, pero en Router11 tampoco estará. Intentaremos comprender esto. Veamos qué datos y parámetros transmite Router9 a sus vecinos al informar sobre esta ruta. El paquete a continuación será enviado desde Router9 a Router8.

Principios de funcionamiento del protocolo BGP
La información sobre la ruta consta de atributos de camino (Path attributes).

Los atributos de camino se dividen en 4 categorías:

  1. Well-known mandatory — todos los enrutadores que operan con el protocolo BGP deben reconocer estos atributos. Deben estar presentes en todas las actualizaciones (update).
  2. Well-known discretionary — todos los enrutadores que operan con el protocolo BGP deben reconocer estos atributos. Pueden estar presentes en las actualizaciones (update), pero su presencia no es obligatoria.
  3. Optional transitive — pueden no ser reconocidos por todas las implementaciones de BGP. Si un enrutador no reconoce un atributo, lo etiqueta como parcial (partial) y lo envía a sus vecinos, conservando el atributo no reconocido.
  4. Optional non-transitive — pueden no ser reconocidos por todas las implementaciones de BGP. Si un enrutador no reconoce un atributo, este se ignora y se descarta al transmitirse a los vecinos.

Ejemplos de atributos BGP:

  • Well-known mandatory:
    • Autonomous system path
    • Next-hop
    • Origen

  • Well-known discretionary:
    • Local preference
    • Atomic aggregate
  • Optional transitive:
    • Aggregator
    • Communities
  • Optional non-transitive:
    • Multi-exit discriminator (MED)
    • Originator ID
    • Cluster list

En este caso, por ahora nos interesarán Origin, Next-hop, AS Path. Dado que la ruta se transmite entre Router8 y Router9, es decir, dentro de un mismo AS, se considera interna y prestaremos atención a Origin.

El atributo Origin — indica cómo fue obtenida la ruta en la actualización. Los posibles valores del atributo son:

  • 0 — IGP: NLRI recibido dentro del sistema autónomo original;
  • 1 — EGP: NLRI se aprendió a través del protocolo Exterior Gateway Protocol (EGP). Predecesor de BGP, no se utiliza.
  • 2 — Incomplete: NLRI se aprendió de otra manera.

En nuestro caso, como se puede ver, el paquete es 0. Cuando esta ruta se transfiera a Router12, este código tendrá el valor de 1.

A continuación, Next-hop. El atributo Next-hop.

  • Es la dirección IP del enrutador eBGP a través del cual se establece el camino hacia la red de destino.
  • El atributo cambia al transferir el prefijo a otro AS.

En el caso de iBGP, es decir, dentro de un mismo AS, el Next-hop será el que conoció o informó sobre esta ruta. En nuestro caso, será 192.168.89.9. Pero cuando esta ruta se transfiera de Router8 a Router6, Router8 la cambiará y la reemplazará por su propia dirección. El Next-hop será 192.168.68.8. Esto nos lleva a dos reglas:

  1. Si un enrutador transfiere una ruta a su vecino interno, no cambia el parámetro Next-hop.
  2. Si un enrutador transfiere una ruta a su vecino externo, cambia el Next-hop a la IP de la interfaz desde la que transfiere dicho enrutador.

Esto nos lleva a comprender el primer problema: ¿Por qué no habrá ruta en la tabla de enrutamiento en Router5 y Router11? Analicemos más detenidamente. Así que, Router6 recibió información sobre la ruta 9.9.9.0/24 y la agregó correctamente a la tabla de enrutamiento:

Router6#show ip route bgp
Códigos: L - local, C - conectado, S - estático, R - RIP, M - móvil, B - BGP
       D - EIGRP, EX - EIGRP externo, O - OSPF, IA - OSPF inter-área
       N1 - OSPF NSSA externo tipo 1, N2 - OSPF NSSA externo tipo 2
       E1 - OSPF externo tipo 1, E2 - OSPF externo tipo 2
       i - IS-IS, su - resumen IS-IS, L1 - IS-IS nivel 1, L2 - IS-IS nivel 2
       ia - IS-IS inter-área, * - ruta por defecto candidata, U - ruta estática por usuario
       o - ODR, P - ruta estática descargada periódicamente, H - NHRP, l - LISP
       a - ruta de aplicación
       + - ruta replicada, % - anulación de siguiente salto, p - anulaciones de PfR

La puerta de enlace de último recurso no está configurada

      9.0.0.0/24 está subdividido, 1 subred
B        9.9.9.0 [20/0] a través de 192.168.68.8, 00:38:25<source>
Ahora Router6 ha pasado la ruta a Router5 y la primera regla Next-hop no ha cambiado. Es decir, Router5 debe agregar  <b>9.9.9.0 [20/0] a través de 192.168.68.8</b> , pero no tiene ruta hacia 192.168.68.8, por lo que esta ruta no se añadirá, aunque la información sobre esta ruta se almacenará en la tabla BGP:

<source><b>Router5#show ip bgp
La versión de la tabla BGP es 1, el ID del router local es 5.5.5.5
Códigos de estado: s suprimido, d amortiguado, h historia, * válido, &gt; mejor, i - interno,
              r fallo del RIB, S stale, m multipath, b ruta de respaldo, f filtro RT,
              x mejor externo, a ruta adicional, c RIB comprimido,
Códigos de origen: i - IGP, e - EGP, ? - incompleto
Códigos de validación RPKI: V válido, I inválido, N no encontrado

     Red             Siguiente Salto       Métrica LocPrf Peso Ruta
 * i 9.9.9.0/24     192.168.68.8             0    100      0 45 i</b>

La misma situación ocurrirá entre Router11 y Router12. Para evitar tal situación, es necesario configurar que Router6 o Router12, al transferir rutas a sus vecinos internos, utilicen su propia dirección IP como Next-hop. Esto se hace con el comando:

neighbor 192.168.56.5 next-hop-self

Después de este comando, Router6 enviará un mensaje de actualización, donde para las rutas se indicará la dirección IP de la interfaz Gi0/0 de Router6 — 192.168.56.6, después de lo cual esta ruta se incluirá en la tabla de enrutamiento.

Sigamos adelante y veamos si esta ruta aparecerá en Router7 y Router10. No estará en la tabla de enrutamiento y podríamos pensar que el problema es el mismo que con el parámetro Next-hop, pero si observamos la salida del comando show ip bgp, veremos que la ruta no se recibió incluso con un Next-hop incorrecto, lo que significa que la ruta ni siquiera fue transferida. Esto nos lleva a la existencia de otra regla:

Las rutas recibidas de vecinos internos no se transfieren a otros vecinos internos.

Dado que Router5 recibió la ruta de Router6, no se la enviará a su otro vecino interno. Para que la transmisión ocurra, es necesario configurar la función Route Reflector, o configurar relaciones de vecindad full mesh, es decir, Router5-7 será vecino de cada uno. En este caso, utilizaremos Route Reflector. Se debe usar el siguiente comando en Router5:

neighbor 192.168.57.7 route-reflector-client

El Route Reflector cambia el comportamiento de BGP al transmitir rutas a un vecino interno. Si el vecino interno se especifica como route-reflector-client, a estos clientes se les anunciarán rutas internas.

¿No apareció la ruta en Router7? No olvidemos también el Next-hop. Después de estas manipulaciones, la ruta debería aparecer en Router7, pero eso no ocurre. Esto nos lleva a otra regla:

La regla de next-hop solo funciona para rutas externas. Para rutas internas, el atributo next-hop no se reemplaza.

Y tenemos una situación en la que es necesario crear un entorno mediante enrutamiento estático o protocolos IGP para informar a los enrutadores sobre todas las rutas dentro de AS. Definiremos rutas estáticas en Router6 y Router7 y, después de eso, obtendremos la ruta necesaria en la tabla del enrutador. En AS 678, haremos algo un poco diferente: definiremos rutas estáticas para 192.168.112.0/24 en Router10 y 192.168.110.0/24 en Router12. Luego, estableceremos relaciones de vecindad entre Router10 y Router12. También configuraremos en Router12 el envío de su next-hop para Router10:

neighbor 192.168.110.10 next-hop-self

Como resultado, Router10 recibirá la ruta 9.9.9.0/24, que será obtenida tanto de Router7 como de Router12. Veamos qué decisión tomará Router10:

Router10#show ip bgp
La versión de la tabla BGP es 3, el ID del enrutador local es 6.6.6.6
Códigos de estado: s suprimido, d amortiguado, h historial, * válido, > mejor, i - interno,
              r falla de RIB, S obsoleto, m multipath, b ruta de respaldo, f filtro RT,
              x mejor-externo, a ruta adicional, c RIB-comprimido,
Códigos de origen: i - IGP, e - EGP, ? - incompleto
Códigos de validación RPKI: V válido, I inválido, N no encontrado

     Red                  Next Hop            Métrica LocPrf Peso Ruta
 * >i 9.9.9.0/24       192.168.112.12           0    100       0      45 i

                               192.168.107.7                                0     123 45 i  

Como vemos, hay dos rutas y la flecha ( > ) indica que se eligió la ruta a través de 192.168.112.12.
Veamos cómo ocurre el proceso de selección de rutas:

  1. Primero, al recibir una ruta, se verifica la disponibilidad de su Next-hop. Por eso, cuando recibimos la ruta en Router5 sin configurar Next-hop-self, esta ruta no se entregó para procesamiento.
  2. A continuación está el parámetro Weight. Este parámetro no es un atributo de ruta (PA) y no se transmite en los mensajes BGP. Se configura localmente en cada enrutador y se utiliza solo para manipular la selección de rutas en el propio enrutador. Consideremos un ejemplo. Un poco más arriba se muestra que el Router10 eligió la ruta para 9.9.9.0/24 a través del Router12 (192.168.112.12). Para cambiar el parámetro Weight, se puede usar route-map para establecerlo para rutas específicas o asignarle un peso al vecino utilizando el comando:
     neighbor 192.168.107.7 weight 200       

    Ahora todas las rutas de este vecino tendrán ese peso. Veamos cómo cambiará la selección de ruta después de esta manipulación:

    Router10#show bgp
    *Mar  2 11:58:13.956: %SYS-5-CONFIG_I: Configurado desde la consola por consola
    La versión de la tabla BGP es 2, el ID del enrutador local es 6.6.6.6
    Códigos de estado: s suprimido, d atenuado, h historial, * válido, > mejor, i - interno,
                  r falla RIB, S obsoleto, m multipath, b ruta de respaldo, f RT-Filter,
                  x mejor-external, a ruta-adicional, c RIB-comprimido,
    Códigos de origen: i - IGP, e - EGP, ? - incompleto
    Códigos de validación RPKI: V válido, I inválido, N No encontrado
    
         Red            Siguiente Salto        Métricas LocPrf Peso      Ruta
     * >  9.9.9.0/24   192.168.107.7                      200      123 45 i
     * i                     192.168.112.12           0          100      0 45 i

    Como pueden ver, ahora se eligió la ruta a través del Router7, pero esto no tendrá ningún efecto en los demás enrutadores.

  3. En la tercera posición tenemos — Local Preference. Este parámetro es un atributo discrecional bien conocido, lo que significa que su presencia no es obligatoria. Este parámetro solo tiene efecto dentro de un AS y solo afecta la selección de rutas para vecinos internos. Es por eso que solo se transmite en los mensajes de Actualización destinados a vecinos internos. En los mensajes de Actualización para vecinos externos está ausente. Por lo tanto, se le ha clasificado como discrecional bien conocido. Intentemos aplicarlo en Router5. En Router5 deberíamos tener dos rutas para 9.9.9.0/24: una a través de Router6 y otra a través de Router7.

    Veamos:

    Router5#show bgp
    La versión de la tabla BGP es 2, el ID del enrutador local es 5.5.5.5
    Códigos de estado: s suprimido, d atenuado, h historial, * válido, > mejor, i - interno,
                  r falla RIB, S obsoleto, m multipath, b ruta de respaldo, f RT-Filter,
                  x mejor-external, a ruta-adicional, c RIB-comprimido,
    Códigos de origen: i - IGP, e - EGP, ? - incompleto
    Códigos de validación RPKI: V válido, I inválido, N No encontrado
    
         Red                Siguiente Salto       Métricas LocPrf Peso Ruta
     * >i 9.9.9.0/24       192.168.56.6           0    100      0 45 i

    Pero como vemos, hay una ruta a través de Router6. ¿Y dónde está la ruta a través de Router7? ¿Puede que no esté en Router7? Veamos:

    Router#show bgp
    La versión de la tabla BGP es 10, la ID del router local es 7.7.7.7
    Códigos de estado: s suprimido, d atenuado, h historial, * válido, > mejor, i - interno,
                  r fallo RIB, S obsoleto, m multipath, b ruta de respaldo, f RT-Filter,
                  x mejor-externo, a ruta-adicional, c RIB-comprimido,
    Códigos de origen: i - IGP, e - EGP, ? - incompleto
    Códigos de validación RPKI: V válido, I inválido, N no encontrado
    
         Red                Siguiente Salto            Métrica LocPrf  Peso    Ruta
     * >i 9.9.9.0/24       192.168.56.6             0     100           0      45 i
    
                                  192.168.107.10                                  0     678 45 i 

    Es extraño, parece que todo está bien. ¿Por qué no se transmite a Router5? Todo se debe a que BGP tiene una regla:

    El enrutador solo transmite las rutas que utiliza.

    Router7 utiliza la ruta a través de Router5, por lo que la ruta a través de Router10 no se transmitirá. Regresamos a la Preferencia Local. Establezcamos la Preferencia Local en Router7 y veamos cómo reacciona Router5:

    ruta-mapa BGP permitir 10
     coincidir dirección ip 10
     establecer preferencia local 250
    lista de acceso 10 permitir cualquier
    enrutador bgp 123
     vecino 192.168.107.10 ruta-mapa BGP entrada</b>

    Entonces, hemos creado un route-map que atrapa todas las rutas y le dijimos a Router7 que al recibirlo cambie el parámetro de Preferencia Local a 250, que por defecto es 100. Veamos qué ocurrió en Router5:

    Router5#show bgp
    La versión de la tabla BGP es 8, la ID del router local es 5.5.5.5
    Códigos de estado: s suprimido, d atenuado, h historial, * válido, > mejor, i - interno,
                  r fallo RIB, S obsoleto, m multipath, b ruta de respaldo, f RT-Filter,
                  x mejor-externo, a ruta-adicional, c RIB-comprimido,
    Códigos de origen: i - IGP, e - EGP, ? - incompleto
    Códigos de validación RPKI: V válido, I inválido, N no encontrado
    
         Red          Siguiente Salto            Métrica LocPrf Peso        Ruta
     * >i 9.9.9.0/24       192.168.57.7             0          250      0 678 45 i

    Como vemos, ahora Router5 prefiere la ruta a través de Router7. La misma situación se dará en Router6, aunque le resulta más beneficioso elegir la ruta a través de Router8. Agreguemos también que el cambio de este parámetro requiere reiniciar la vecindad para que el cambio tenga efecto. Leer aquí. Hemos entendido la Preferencia Local. Pasamos al siguiente parámetro.

  4. Preferencia de ruta con el parámetro Next-hop 0.0.0.0, es decir, rutas locales o agregadas. A estas rutas se les asigna automáticamente el parámetro Weight igual al máximo — 32678 tras el ingreso del comando network:
    Router#show bgp
    La versión de la tabla BGP es 2, la ID del router local es 9.9.9.9
    Códigos de estado: s suprimido, d atenuado, h historial, * válido, > mejor, i - interno,
                  r fallo RIB, S obsoleto, m multipath, b ruta de respaldo, f RT-Filter,
                  x mejor-externo, a ruta-adicional, c RIB-comprimido,
    Códigos de origen: i - IGP, e - EGP, ? - incompleto
    Códigos de validación RPKI: V válido, I inválido, N no encontrado
    
         Red          Siguiente Salto            Métrica LocPrf Peso    Ruta
     * >  9.9.9.0/24       0.0.0.0                  0            32768    i
  5. El camino más corto a través de AS. Se elige el parámetro AS_Path más corto. Cuanto menos número de AS pase la ruta, mejor será. Observemos la ruta a 9.9.9.0/24 en Router10:
    Router10#show bgp
    La versión de la tabla BGP es 2, el ID del enrutador local es 6.6.6.6
    Códigos de estado: s suprimido, d amortiguado, h historial, * válido, > mejor, i - interno,
                  r fallo en RIB, S obsoleto, m multipath, b camino de respaldo, f RT-Filter,
                  x mejor-external, a camino-adicional, c RIB-comprimido,
    Códigos de origen: i - IGP, e - EGP, ? - incompleto
    Códigos de validación RPKI: V válido, I inválido, N no encontrado
    
         Red                Próximo Salto        Métrica LocPrf Peso Ruta
     *   9.9.9.0/24     192.168.107.7                           0           123 45 i
     *>i                     192.168.112.12           0    100       0       45 i

    Como pueden ver, Router10 eligió la ruta a través de 192.168.112.12 porque para esta ruta el parámetro AS_Path contiene solo 45, mientras que en el otro caso contiene 123 y 45. Es intuitivamente claro.

  6. El siguiente parámetro es Origin. IGP (ruta obtenida mediante BGP) es mejor que EGP (ruta obtenida mediante el predecesor de BGP, que ya no se utiliza), y EGP es mejor que Incomplete? (obtenido de otra manera, como redistribución).
  7. El siguiente parámetro es MED. Tuvimos Weight, que funcionaba solo de manera local en el enrutador. Hubo Local Preference, que funcionaba solo dentro de un sistema autónomo. Como es fácil adivinar, MED es el parámetro que se transmitirá entre sistemas autónomos. Muy bueno. Windows sobre este parámetro.

No se utilizarán más atributos, pero si dos rutas tienen los mismos, se aplican las siguientes reglas:

  1. Elegir la ruta a través del vecino IGP más cercano.
  2. Elegir la ruta más antigua para el camino eBGP.
  3. Elegir la ruta a través del vecino con el menor ID de enrutador BGP.
  4. Elegir la ruta a través del vecino con la menor dirección IP.

Ahora consideremos la cuestión de la convergencia BGP.

Veamos qué sucede si, supongamos, Router6 pierde la ruta 9.9.9.0/24 a través de Router9. Apagaremos la interfaz Gi0/1 de Router6, que inmediatamente entenderá que la sesión BGP con Router8 se ha interrumpido y el vecino ha desaparecido, lo que significa que la ruta recibida de él no es válida. Router6 envía inmediatamente mensajes Update, donde indica la red 9.9.9.0/24 en el campo Withdrawn Routes. Tan pronto como Router5 reciba tal mensaje, lo enviará a Router7. Pero dado que Router7 tiene una ruta a través de Router10, responderá de inmediato enviando un Update con la nueva ruta. Si no se puede detectar la caída del vecino a través del estado de la interfaz, habrá que esperar la activación del Hold Timer.

Confederación.

Si recuerdas, hablamos de que a menudo se necesita usar una topología completamente conectada. Con un gran número de enrutadores en un solo AS, esto puede causar grandes problemas, por lo que se deben utilizar confederaciones. Un AS se divide en varios sub-AS, lo que permite que funcionen sin el requisito de una topología completamente conectada.

Principios de funcionamiento del protocolo BGP

Aquí está el enlace a este laboratorio, y aquí configuración para GNS3.

Por ejemplo, con esta topología tendríamos que conectar todos los enrutadores en el AS 2345 entre sí, pero usando Confederation, solo podemos establecer relaciones de vecindad entre los enrutadores conectados directamente entre sí. Hablemos de esto en detalle. Si solo tuviéramos el AS 2345, entonces laForge recibiendo un recorrido de Picard les contaría a sus enrutadores Data y Worf, pero ellos no le contarían sobre él al enrutador Crusher . Además, las rutas que el mismo enrutador laForge, no habrían sido transmitidas Crusher ni Worf- no se habría Data.

tendría que configurarse un Route-Reflector o relaciones de vecindad completamente conectadas. Dividiendo un AS 2345 en 4 sub-AS (2, 3, 4, 5) para cada enrutador, al final obtenemos otra lógica de funcionamiento. Todo está muy bien descrito aquí.

Fuentes:

  1. CCIE Routing and Switching v5.0 Official Cert Guide, Volume 2, Fifth Edition, Narbik Kocharians, Terry Vinson.
  2. Sitio web xgu.ru
  3. Sitio web GNS3Vault.

Fuente: habr.com

Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS 🔥 Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS | ProHoster