Alguém pode explicar por que precisamos do iBGP para as rotas quando temos os protocolos IGP (OSPF, RIP) para comunicação interna no AS?
Eu li muitos artigos e livros, mas não consegui encontrar a resposta.
Alguém pode explicar por que precisamos do iBGP para as rotas quando temos os protocolos IGP (OSPF, RIP) para comunicação interna no AS?
Eu li muitos artigos e livros, mas não consegui encontrar a resposta.
Respostas:
Alguém pode me explicar qual é a necessidade de comunicação IBGP para as rotas, quando temos os protocolos IGP (OSPF, RIP) para comunicação interna?
Impor limites de confiança / controle: o BGP tem mais maneiras de filtrar pares do que IGPs (para controlar o que você anuncia e recebe).
Estruturas de dados flexíveis (um pouco relacionadas ao item anterior): comunidades BGP , comunidades BGP Extended , local-pref , etc ... tornam o BGP uma maneira atraente de implementar políticas de roteamento personalizadas em seu próprio sistema autônomo (usando o iBGP).
Como em tudo, existem compensações; a escalabilidade, controle e flexibilidade que você obtém do iBGP significa que é um protocolo de convergência mais lento que os IGPs (em geral).
1 Escalabilidade :
2 Exemplo de roteamento iBGP :
Para entender por que você pode querer o iBGP, considere esta entrada de roteamento como 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 -->
Existem 32 caminhos a serem considerados ... Nesse caso, o BGP optou por ir para 4.0.0.0/9 via 4.69.184.193 (observe a bestentrada RIB). Nesse caso, o BGP escolheu isso porque essa rota possui a lista mais curta do caminho AS. No entanto, nem todas as rotas serão preferidas via AS3356 (anexado ao R1). Alguns podem ser preferidos em relação ao R3 (via AS7660). O iBGP permite que você saiba (no R2) qual caminho seguir para seguir o caminho mais curto do BGP.
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 e R3 são totalmente iBGP em malha. Quando o iBGP anuncia uma rota, o próximo salto permanece inalterado . Isso significa que eu preciso carregar a sub-rede para 4.69.184.193 no 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>
Assim, quando um pacote para 4.2.2.2 chega ao R2, o R2 envia o Serial2 / 1 porque é aí que o iBGP nos diz que o próximo salto é.
O IGP geralmente é OSPF ou ISIS, que são baseados no estado do link, isso nos dá todas as informações da rede, todo mundo conhece a rede do ponto de vista de todos, o que permite opções de convergência e engenharia de tráfego muito interessantes.
O BGP é essencialmente um vetor de distância; ele conhece uma visão muito limitada da rede como um todo. O BGP lida muito bem com as informações de filtragem e modificação de roteamento.
O protocolo do estado do link é bastante caro comparado ao vetor de distância, seria bastante problemático escalá-lo para o tamanho do INET DFZ.
Portanto, o motivo pelo qual temos os dois é que, dentro de uma rede específica, temos complexidade suficientemente baixa para lidar com o protocolo de estado de link, o que nos permite obter todas as vantagens do alto grau de conhecimento da rede.
Mas como ele não se adapta ao tamanho da Internet, precisamos de outra rede para conectar essas muitas ilhas de link state.
Você pode, dentro da sua própria rede, transportar todos os prefixos (incluindo o cliente) no seu IGP, mas isso afetará negativamente o desempenho do IGP, enquanto todas as vantagens de convergência e TE podem ser obtidas com o transporte de endereços de loopback dos roteadores principais. A adição de prefixos de clientes ao IGP prejudica apenas o desempenho da rede, tornando o IGP desnecessariamente complexo.
Uma das razões pelas quais vi com frequência é a clareza: todas as rotas são transportadas dentro de um protocolo de roteamento (BGP), IS-IS, OSPF ou RIP é usado apenas para adjacência. Como resultado, não há necessidade de redistribuir rotas de um protocolo de roteamento para outro.
O iBGP não é realmente usado para roteamento interno, é usado por todos os seus roteadores eBGP para compartilhar suas rotas.
Ex: se você estiver pesquisando com outras 3 redes, deseja que todos os seus roteadores eBGP conheçam as rotas recebidas pelos outros, para que eles possam propagar essas informações aos pares, se necessário / necessário (abrindo assim a possibilidade de seu par usar trânsito através vocês)