Respuestas:
Los sockets TCP / IP establecen una conexión de extremo a extremo a través de la red, entre dos puntos finales direccionados específicamente. BGP usa TCP / IP para comunicarse entre enrutadores (cualquier dispositivo que intercambie información de enrutamiento). La información intercambiada es utilizada por los pares de BGP, para elegir mejor la forma en que eligen a dónde enviar, (también conocido como el siguiente salto) los paquetes que necesitan transmitir.
En los extremos de Internet, las cosas son fáciles; "todo es así", hacia su proveedor de Internet. Más en el medio, un enrutador podría tener múltiples opciones. Por lo tanto, utiliza TCP / IP para mover el tráfico BGP entre sus vecinos de enrutamiento. La información de BGP le dice al enrutador qué rutas preferir cuando hay múltiples formas para que un paquete llegue a su destino.
Los puntos finales (p. Ej., Los navegadores web) y los enrutadores hablan TCP / IP. Pero los enrutadores utilizan TCP / IP (comunicaciones BGP compuestas de paquetes TCP / IP) para hablar sobre qué hacer con los otros paquetes TCP / IP que necesitan enrutar.
Los protocolos de enrutamiento no "logran" la conectividad L3. Completan la tabla de enrutamiento (reenvío) del enrutador con información obtenida de otros enrutadores.
BGP es una "aplicación" que se ejecuta sobre TCP / IP. En otras palabras, un enrutador BGP utiliza TCP / IP para comunicarse con otros enrutadores BGP para intercambiar información de enrutamiento.
Para que BGP funcione, ya debe tener conectividad L3 entre los enrutadores.
El modelo de red OSI y sus capas son útiles para comprender la comunicación de extremo a extremo entre hosts, pero en realidad no tiene la intención de explicar cómo funciona el plano de control de red. Existe un problema de bootstrapping inherente al establecimiento de una conectividad BGP completa, pero la forma en que se lleva a cabo este bootstrapping se entiende bien y no tiene dependencias circulares.
En términos de BGP, la forma en que se forman las adyacencias y se intercambia la información depende del tipo de sesión.
El más simple es eBGP. Por lo general, eBGP se ejecuta en una sesión TCP entre dos enrutadores conectados directamente. En este caso, cada par sabe cómo hablar con el otro porque ambos tienen una interfaz en la misma subred, por lo que no es necesario utilizar un protocolo de enrutamiento externo para formar la adyacencia.
Con iBGP las cosas son un poco complicadas. En la configuración más simple, todos los enrutadores dentro de un sistema autónomo se configurarán como parte de una malla completa, con sesiones de iBGP con todos los demás enrutadores de la red. Dentro del sistema autónomo, un protocolo de puerta de enlace interior como OSPF o ISIS para construir la topología de enrutamiento interno. Cuando el IGP haya hecho su trabajo, todos los enrutadores tendrán una tabla de enrutamiento poblada con rutas a todos los vecinos iBGP que permitirán que la sesión TCP se forme sin dependencia circular.
Donde las cosas se ponen un poco más interesantes es en situaciones en las que no todos los enrutadores del sistema autónomo se ejecutan con una tabla BGP completa. Si la malla iBGP no está completa, puede obtener situaciones en las que un enrutador en el medio de la red tiene una vista diferente de la tabla que sus vecinos directos. Esto provocará un enrutamiento subóptimo y, en algunos casos, bucles de enrutamiento que provocarán rebotes de tráfico entre dispositivos hasta que caduque el TTL.
El enlace tiene configuradas direcciones estáticas y entradas de enrutamiento asociadas, que se utilizan para establecer la sesión BGP. Con BGP, la tabla de enrutamiento se amplía con las entradas apuntando a otras redes.
Como BGP solo se usa entre pares directos, en este punto no se requieren rutas que no sean las que apuntan al otro extremo.
Por ejemplo, si quisiéramos establecer pares, acordaríamos una subred / 30 o / 31, asignaríamos una dirección a cada extremo de la red y crearíamos una ruta de red para esa subred a este enlace, luego configuraríamos la otra como BGP par, en ese momento obtengo entradas de enrutamiento adicionales para todas las redes que anuncia que se enviarán a través de su enrutador (que a su vez es parte de la ruta de red local configurada estáticamente).
--- --- --- ---
| D |------| A |--------| B |--------| C |
--- --- --- ---
Supongamos que A y B son enrutadores (en AS diferentes o iguales) y D y C son hosts. Ahora A y B están conectados entre sí y pueden comunicarse. Pero, ¿cómo conocería D la posición de C para que pueda comunicarse con C. Lo mismo es cierto para C cuando quiere comunicarse con D. Ahora, si ejecutamos el protocolo BGP entre A y B, intercambian la información de conectividad de capa 3 entre sí . En términos simples, A le dirá a B que D está conectado a él. Entonces, B puede transmitir esto a C o si B es la puerta de enlace predeterminada para C, de cualquier manera C puede conocer la posición de D.
Entonces, en este caso, la información de conectividad de capa 3 se pasa entre A y B, dado que A y B ejecutan el protocolo BGP.
Por lo tanto, se necesita una conexión BGP previa entre dos sistemas para intercambiar información de enrutamiento de capa 3. Acabo de mostrar un ejemplo simple para responder a su consulta. En el escenario práctico, se intercambian muchos más datos de enrutamiento entre pares de BGP.
BGP se ejecuta sobre el protocolo TCP. Por lo tanto, se debe abrir un socket TCP entre ellos, solo entonces pueden intercambiar datos de enrutamiento.
sin conectividad previa L3?
La "conectividad L3" no es una cosa de todo o nada.
El administrador que configura el enrutador configurará las interfaces con direcciones IP y máscaras de subred. En base a estas configuraciones, se crearán entradas de tabla de enrutamiento implícito que permitirán al enrutador hablar con sus vecinos.
Los protocolos de enrutamiento pueden ejecutarse sobre esta conectividad L3 local para establecer una conectividad L3 de mayor distancia.