¿Alguien puede explicar por qué necesitamos iBGP para las rutas cuando tenemos los protocolos IGP (OSPF, RIP) para la comunicación interna dentro del AS?
He leído muchos artículos y libros, pero no pude encontrar la respuesta.
¿Alguien puede explicar por qué necesitamos iBGP para las rutas cuando tenemos los protocolos IGP (OSPF, RIP) para la comunicación interna dentro del AS?
He leído muchos artículos y libros, pero no pude encontrar la respuesta.
Respuestas:
¿Alguien puede explicarme cuál es la necesidad de la comunicación IBGP para las rutas, cuando tenemos los protocolos IGP (OSPF, RIP) para la comunicación interna?
Exigir límites de confianza / control: BGP tiene más formas de filtrar pares que IGP (para controlar lo que anuncia y recibe).
Las estructuras de datos flexibles (algo relacionadas con la viñeta anterior): comunidades BGP , comunidades extendidas BGP , prefijo local , etc., hacen de BGP una forma atractiva de implementar políticas de enrutamiento personalizadas dentro de su propio sistema autónomo (mediante el uso de iBGP).
Como con todo, hay compensaciones; La escalabilidad, el control y la flexibilidad que obtiene de iBGP significa que es un protocolo convergente más lento que los IGP (en general).
1 escalabilidad :
2 ejemplo de enrutamiento iBGP :
Para comprender por qué podría querer iBGP, considere esta entrada de enrutamiento a 4.2.2.2 ...
R2>sh ip bgp 4.2.2.2
BGP routing table entry for 4.0.0.0/9, version 3146
Paths: (32 available, best #7, table Default-IP-Routing-Table)
... <!-- extra BGP RIB entries deleted -->
7660 2516 3356, (aggregated by 3356 4.69.130.4)
203.181.248.168 from 203.181.248.168 (203.181.248.168)
Origin IGP, localpref 100, valid, internal, atomic-aggregate
Community: 2516:1030
3356, (aggregated by 3356 4.69.130.6)
4.69.184.193 from 4.69.184.193 (4.69.184.193)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2012
... <!-- extra BGP RIB entries deleted -->
Hay 32 caminos a considerar ... En este caso, BGP eligió ir a 4.0.0.0/9 a través de 4.69.184.193 (observe la bestentrada debajo de la RIB). En este caso, BGP eligió esto porque esta ruta tiene la lista de ruta AS más corta. Sin embargo, no todas las rutas serán preferidas a través de AS3356 (conectado a R1). Algunos pueden preferirse a R3 (a través de AS7660). iBGP le brinda la capacidad de saber (en R2) qué camino tomar para tomar el camino BGP más corto.
BGP route to 4.0.0.0/9 via
NH: 4.69.184.193 [Path: 3356]
-------->
eBGP w/ AS3356 }{ iBGP inside AS64000 }{ eBGP w/ AS7660
S1/0 S1/2 S2/1 S2/3 S3/2 S3/0
Peered w/ AS3356 +------+ +------+ +------+ Peered w/ AS7660
4.69.184.193 <------| R1 |---------| R2 |--------| R3 |-----> 203.181.248.168
+------+ +------+ +------+
| S2/0
|
^
^
| Ingress packet to 4.2.2.2
|
R1, R2 y R3 están totalmente mallados con iBGP. Cuando iBGP anuncia una ruta, el siguiente salto permanece sin cambios . Esto significa que necesito transportar la subred para 4.69.184.193 en OSPF ...
R2>sh ip route 4.69.184.193
Routing entry for 4.69.184.192/30
Known via "ospf 100", distance 110, metric 65536, type intra area
Last update from 192.0.2.109 on GigabitEthernet3/1, 1w0d ago
Routing Descriptor Blocks:
* 192.0.2.109, from 192.0.2.3, 1w0d ago, via Serial2/1
Route metric is 65536, traffic share count is 1
R2>
Por lo tanto, cuando un paquete para 4.2.2.2 llega a R2, R2 lo envía Serial2 / 1 porque allí es donde iBGP nos dice que es el siguiente salto.
IGP generalmente es OSPF o ISIS que se basan en el estado del enlace, esto nos da toda la información de la red, todos conocen la red desde el punto de vista de todos, lo que permite opciones de convergencia muy interesantes y opciones de ingeniería de tráfico.
BGP es esencialmente un vector de distancia, conoce una visión muy limitada de la red en general. BGP maneja muy bien el filtrado y la modificación de la información de enrutamiento.
El protocolo de estado de enlace es bastante costoso en comparación con el vector de distancia, sería bastante problemático escalarlo al tamaño INET DFZ.
Entonces, la razón por la que tenemos ambos, es porque dentro de una red específica, tenemos una complejidad suficientemente baja para manejarlo con el protocolo de estado de enlace, lo que nos permite obtener todas las ventajas de un alto grado de conocimiento de la red.
Pero como no se escala al tamaño de Internet, necesitamos alguna otra red para conectar estas muchas islas de estado de enlace.
Podría dentro de su propia red llevar todos los prefijos (incluido el cliente) en su IGP, pero afectará negativamente el rendimiento de IGP, mientras que todas las ventajas de convergencia y TE se pueden obtener simplemente llevando direcciones de bucle invertido de enrutadores centrales. Agregar prefijos de clientes a IGP solo perjudica el rendimiento de su red al hacer que IGP sea innecesariamente complejo.
iBGP no se usa realmente para el enrutamiento interno, es utilizado por todos sus enrutadores eBGP para compartir sus rutas.
Por ejemplo: si está emparejando con otras 3 redes, desea que todos sus enrutadores eBGP conozcan las rutas recibidas por los otros para que puedan propagar esa información a los pares si es necesario / necesario (abriendo así la posibilidad de que su par use el tránsito a través de tú)