Configuração de iBGP: guia prático para provedores
Configuração de iBGP: é montar as sessões que levam as rotas externas e os blocos de clientes entre os roteadores do próprio provedor, como bordas, núcleo e concentradores. As sessões usam os loopbacks, as bordas aplicam next-hop-self e o protocolo interno carrega só os loopbacks e enlaces que sustentam essas sessões.
Resumo
- O iBGP distribui dentro da rede as rotas que o eBGP trouxe de fora pela borda.
- Rota aprendida de um vizinho iBGP não é repassada a outro, por isso todos falam com todos ou com um refletor.
- Sessões entre loopbacks sobrevivem à queda de um enlace quando existe caminho reserva.
- Sem next-hop-self na borda, a rota chega ao núcleo com um próximo salto que ninguém alcança.
O que o iBGP faz dentro do provedor
O iBGP é a parte do BGP que roda entre roteadores do mesmo ASN. Ele distribui as rotas aprendidas nas bordas para que cada roteador saiba por qual saída mandar cada destino e onde está cada bloco de cliente.
O eBGP traz as rotas de fora: trânsito, IX.br e caches entregam os prefixos na borda. Sem o iBGP, só o roteador que recebeu a rota saberia usá-la, e o resto da rede dependeria de rota padrão.
No BGP, uma regra explica quase todo problema interno: rota aprendida de um vizinho iBGP não é repassada a outro vizinho iBGP. Por isso todos precisam falar com todos, ou com um route reflector. A configuração de BGP para provedores inclui esse desenho desde o primeiro roteador.
| Roteadores | Sessões em malha completa |
|---|---|
| 3 | 3 |
| 5 | 10 |
| 10 | 45 |
| 20 | 190 |
A conta da tabela é n vezes n menos um, dividido por dois. Com poucos roteadores a malha completa é simples; com muitos, cada equipamento novo exige mexer em todos os outros.
Como funciona a configuração de iBGP?
A configuração de iBGP exige duas camadas trabalhando juntas: o protocolo interno, que faz os loopbacks se enxergarem, e as sessões BGP, que usam esses loopbacks para trocar as rotas.
- Camada de baixo: OSPF ou IS-IS anunciam loopbacks e enlaces internos, nada além disso.
- Camada de cima: o iBGP carrega rotas externas, blocos de clientes e rotas de agregação.
- Ligação entre elas: o próximo salto de cada rota BGP precisa ser alcançável pelo protocolo interno.
Quando o protocolo interno falha, as sessões iBGP caem em cascata. Por isso o desenho começa pelo OSPF ou pelo IS-IS, e só depois se configura o BGP interno.
Quatro princípios para configurar iBGP sem surpresa
Quatro princípios evitam a maioria das falhas de iBGP em redes de provedores regionais. Eles valem para qualquer fabricante e para qualquer tamanho de rede.
- Sessões entre loopbacks: a sessão não cai quando um enlace cai, se houver caminho reserva.
- Next-hop-self nas bordas: os outros roteadores não precisam conhecer os enlaces de trânsito.
- IGP só com loopbacks e enlaces: o OSPF ou IS-IS sustenta as sessões; o resto fica no BGP.
- Tabela completa só onde é preciso: concentradores podem receber rota padrão e rotas internas.
O terceiro princípio é o mais desrespeitado. Colocar os blocos de clientes ou as rotas externas no protocolo interno parece resolver rápido, mas deixa a rede lenta para convergir e frágil a qualquer erro.
Qual protocolo interno usar por baixo
Tanto OSPF quanto IS-IS sustentam bem o iBGP de um provedor regional. O que importa é que ele carregue só o necessário e convirja rápido quando um enlace cai.
Os guias de configuração de OSPF e de configuração de IS-IS mostram o desenho de cada um com loopbacks e áreas.
Por que o iBGP não repassa rotas internas
No eBGP, o caminho de ASNs evita laços: um roteador descarta a rota que já traz o próprio número. Dentro do mesmo ASN esse número não muda, então o protocolo precisa de outra proteção.
A proteção escolhida foi simples: o que veio de um vizinho interno não volta para outro vizinho interno. Isso evita laços, mas obriga a malha completa ou o uso de refletores, que recebem permissão para repassar com regras próprias.
Entender essa regra poupa horas de diagnóstico. Quando uma rota existe num roteador e falta no vizinho, a primeira pergunta é se os dois têm sessão direta ou se há um refletor no caminho.
Configuração de iBGP passo a passo
O exemplo mostra uma borda com sessões iBGP para dois outros roteadores, usando peer-group. A sintaxe é de Cisco IOS-XE, e a lógica vale para os demais fabricantes.
- Loopbacks no IGP: confirme que o loopback de cada roteador aparece na tabela de todos os outros.
- Peer-group: crie um grupo com o ASN interno e a origem das sessões no Loopback0.
- Vizinhos: inclua cada loopback interno no grupo, com uma descrição clara.
- Família IPv4: ative os vizinhos, ligue o envio de communities e o next-hop-self.
- Conferência: verifique as sessões estabelecidas e o próximo salto das rotas recebidas.
router bgp 64500
bgp router-id 10.255.0.1
neighbor IBGP peer-group
neighbor IBGP remote-as 64500
neighbor IBGP update-source Loopback0
neighbor IBGP description Sessoes internas
neighbor 10.255.0.2 peer-group IBGP
neighbor 10.255.0.3 peer-group IBGP
address-family ipv4
neighbor IBGP send-community both
neighbor IBGP next-hop-self
neighbor 10.255.0.2 activate
neighbor 10.255.0.3 activateRepita a configuração para IPv6, com sessões entre os loopbacks IPv6. Não misture as famílias numa sessão só sem planejar o próximo salto de cada uma.
Vai ligar o segundo roteador de borda?
Na configuração de BGP, um Especialista desenha o iBGP junto com as sessões externas e deixa tudo documentado para a sua equipe.
O que cada linha resolve
O peer-group evita repetir as mesmas opções para cada vizinho. Um roteador novo entra com duas linhas, sem risco de esquecer uma opção.
- Update-source Loopback0: a sessão sai do loopback, e não da porta física.
- Remote-as igual ao local: é isso que torna a sessão interna.
- Send-community both: as marcas de origem das rotas chegam aos outros roteadores.
- Next-hop-self: a borda se anuncia como próximo salto das rotas externas.
O envio de communities é o que permite aos outros roteadores aplicarem a mesma política da borda. O guia de configuração de communities BGP mostra esse plano de marcas.
Malha completa ou route reflector?
Com até quatro ou cinco roteadores, a malha completa costuma ser suficiente. Acima disso, cada roteador novo exige mexer em todos os outros, e o route reflector passa a valer a pena.
| Desenho | Faz sentido quando | Cuidado |
|---|---|---|
| Malha completa | Poucos roteadores e crescimento lento | Esquecer uma sessão ao incluir roteador novo |
| Route reflector | Vários POPs ou crescimento frequente | Refletor único vira ponto de falha |
| Dois refletores | Rede que não pode parar por um equipamento | Exige cluster-id e desenho cuidadoso |
Veja a implantação de route reflector para o passo a passo. Se a borda tem dois roteadores com gateway compartilhado para os clientes, veja também a configuração de VRRP.
Quem precisa da tabela completa
O roteador de borda precisa da tabela completa para escolher a saída certa para cada destino. Concentradores e roteadores de acesso quase sempre funcionam com rota padrão e rotas internas.
Filtrar o que cada roteador recebe economiza memória e acelera a convergência. A validação de origem pelo RPKI também fica na borda, onde as rotas externas entram.
Erros comuns na configuração de iBGP
Os sintomas costumam ser rotas que aparecem num roteador e não em outro, ou tráfego que some no meio da rede. Os erros abaixo explicam a maior parte desses casos.
Evite
- Sessões entre endereços de enlace, que caem junto com a porta.
- Faltar next-hop-self, deixando o próximo salto inalcançável.
- Redistribuir o BGP no OSPF para resolver rota faltando.
- Malha incompleta, com um roteador sem sessão com outro.
- Tabela completa num concentrador com pouca memória.
A redistribuição do BGP no protocolo interno merece atenção especial. Com a tabela completa, ela pode encher a memória dos roteadores e derrubar o próprio IGP que sustenta as sessões.
Exemplo: bloco de cliente que não chega à outra borda
Um provedor com três roteadores liga um cliente com ASN próprio na borda A. A borda B, que fala com a operadora, não anuncia o bloco, e o cliente fica sem tráfego de entrada por ela.
- Sintoma: o bloco aparece na borda A e no núcleo, mas não na borda B.
- Causa: a borda A só tem sessão com o núcleo, que aprendeu a rota por iBGP e não repassa.
- Correção: a sessão que faltava entre A e B fecha a malha, e o bloco aparece.
Quando a sessão nem chega a subir, o problema é outro. O guia de sessão BGP que não sobe lista as causas por ordem de frequência.
Checklist de validação do iBGP
Confira sessões, rotas e próximos saltos em cada roteador logo depois da mudança. Depois, derrube um enlace de propósito numa janela combinada e veja se as sessões continuam.
Confira em cada roteador depois de configurar o iBGP
- Todas as sessões iBGP estão estabelecidas entre loopbacks.
- As rotas de cada borda aparecem nos outros roteadores com próximo salto alcançável.
- Os blocos de clientes aparecem em todas as bordas.
- A queda de um enlace não derruba as sessões iBGP.
- O protocolo interno carrega só loopbacks e enlaces, sem rotas de clientes.
- A configuração ficou salva e documentada com o desenho das sessões.
Se um item falhar, comece pelo protocolo interno, porque ele sustenta todas as sessões. Quase sempre a falha de iBGP é consequência de um loopback que não chega.
- Resumo das sessões: o show bgp ipv4 unicast summary mostra o estado e o número de prefixos de cada vizinho.
- Rota de um bloco: o show bgp ipv4 unicast seguido do prefixo mostra de quem veio e qual é o próximo salto.
- Alcance do próximo salto: o show ip route com o loopback da borda confirma que o IGP chega até ela.
A Táquion Tech configura o iBGP junto com as sessões externas e deixa o desenho escrito, para que um roteador novo entre na rede sem depender de quem montou a primeira versão.
Perguntas frequentes sobre configuração de iBGP
Qual a diferença entre iBGP e eBGP?
O eBGP fala com outras redes, de ASN diferente. O iBGP fala entre roteadores do mesmo ASN e distribui dentro da rede o que o eBGP trouxe.
Por que usar loopback nas sessões iBGP?
Porque o loopback não cai com a queda de uma porta. Se houver caminho reserva, o protocolo interno reencaminha e a sessão continua.
O que significa next-hop-self no iBGP?
É a borda se colocar como próximo salto das rotas externas que repassa aos vizinhos internos. Assim os outros roteadores alcançam essas rotas sem conhecer os enlaces de trânsito.
Todo roteador precisa da tabela completa?
Não. Bordas sim; concentradores e roteadores de acesso podem funcionar com rota padrão e rotas internas.
Posso rodar iBGP sem OSPF ou IS-IS?
Em redes muito pequenas dá para usar rotas estáticas entre loopbacks, mas cada mudança vira trabalho manual. Com mais de dois ou três roteadores, um protocolo interno evita erros e acelera a recuperação de falhas.
Serviços ligados a este guia
- Alta disponibilidade de borda para provedores BGP e roteamento
- Integração de redes após aquisição para provedores Fusões e aquisições
- Alta disponibilidade de DNS para provedores Sistemas para provedores
Fontes
- RFC 4271, A Border Gateway Protocol 4 (BGP-4): regras de repasse entre vizinhos internos.
- RFC 4456, BGP Route Reflection: alternativa à malha completa.
- RFC 7454, BGP Operations and Security: boas práticas de sessões BGP.