Dia 7: BGP — Peering, Autonomous Systems e Encaminhamento

No Dia 5 abordámos encaminhamento estático, RIP e OSPF — protocolos de interior, que funcionam dentro de uma organização. No Dia 6 aprofundámos OSPF com áreas, LSA e eleição de DR/BDR. Hoje damos o salto para o exterior: como é que redes diferentes, geridas por entidades distintas, trocam informação de encaminhamento à escala planetária?

A resposta é o Border Gateway Protocol (BGP), definido na RFC 4271. Ao contrário do OSPF, que descobre vizinhos automaticamente e calcula caminhos mais curtos, o BGP foi concebido para um mundo onde a política importa mais do que a distância. Um operador pode preferir uma rota mais longa porque é mais barata, ou rejeitar tráfego de um parceiro por razões comerciais.

1. Introdução ao BGP

O BGP é um protocolo de encaminhamento path-vector. Em vez de calcular o caminho mais curto com métricas (como OSPF com custo ou RIP com saltos), o BGP troca rotas na forma de prefixos IP acompanhados de uma lista de Autonomous Systems (AS-Path) que a rota atravessou. Esta lista funciona simultaneamente como atributo de política e como mecanismo de prevenção de ciclos: se um router vê o seu próprio AS no AS-Path de uma rota recebida, descarta-a imediatamente.

O BGP opera sobre TCP na porta 179. Ao contrário do OSPF, que usa multicast para descobrir vizinhos, o BGP exige configuração manual de cada vizinho (neighbor) com o endereço IP e o AS remoto. Esta escolha de design reflecte a natureza inter-organizacional do protocolo: cada peering é um acordo comercial explícito, não uma descoberta automática.

Existem dois modos fundamentais de operação:

• eBGP (External BGP) — entre routers de AS diferentes, tipicamente com ligações directas.
• iBGP (Internal BGP) — entre routers do mesmo AS, usado para distribuir rotas aprendidas externamente.

A versão actual, BGP-4, foi definida em 2006 e introduziu suporte para CIDR (Classless Inter-Domain Routing), permitindo agregacao de prefixos — fundamental para manter a tabela de encaminhamento global num tamanho viável (cerca de 950.000 prefixos IPv4 em 2025).

2. Autonomous Systems e Peering

Um Autonomous System (AS) é um conjunto de redes IP sob uma única administração técnica que apresenta uma política de encaminhamento coerente para a Internet. Cada AS recebe um número único (ASN — Autonomous System Number) atribuído por um RIR (Regional Internet Registry) como RIPE NCC para a Europa.

Existem duas categorias de ASN:

As relações comerciais entre ASs determinam o fluxo de tráfego na Internet. Existem três modelos principais:

• Transit — um AS paga a outro para transportar tráfego para qualquer destino na Internet. O provedor de transit anuncia uma rota predefinida (0.0.0.0/0) ou a tabela completa.
• Peering — dois ASs trocam tráfego mutuamente, tipicamente sem custos (peering sem custos), anunciando apenas os seus próprios prefixos e os dos clientes. Pode ser público (num Internet Exchange Point) ou privado (PNI — Private Network Interconnect).
• Customer — um AS paga ao outro para receber tráfego destinado aos seus prefixos. O cliente anuncia os seus prefixos ao provedor, que os propaga aos seus pares e provedores de transit.

Esta hierarquia de relações cria o modelo clássico Tier 1 / Tier 2 / Tier 3. Os Tier 1 (ex: Lumen, Telia, NTT) não compram transit a ninguém — só fazem peering. Os Tier 2 compram transit a Tier 1 mas também fazem peering. Os Tier 3 (ISP locais) compram transit a Tier 2 e vendem aos clientes finais.

Os Internet Exchange Points (IXP) são infraestruturas físicas onde múltiplos ASs se ligam a um switch de alta capacidade para estabelecer peering público. Em Portugal, a GigaPIX (operada pela FCCN) é o ponto de troca nacional, permitindo que ISPs, universidades e empresas troquem tráfego nacional sem passar pelo estrangeiro.

3. eBGP vs iBGP

A distinção entre eBGP e iBGP é fundamental para compreender como o BGP escala dentro de um AS com múltiplos routers de borda.

A regra crítica do iBGP é: um router iBGP não re-anuncia rotas aprendidas via iBGP para outro vizinho iBGP. Isto evita ciclos, mas exige que todos os routers de borda tenham sessões iBGP entre si (full-mesh). Para ASs grandes, o full-mesh torna-se impraticável (N×(N-1)/2 sessões). A solução é o Route Reflector (RFC 4456): um router designado reflecte rotas iBGP aos seus clientes, reduzindo o número de sessões para N-1.

Outra alternativa é a Confederação BGP (RFC 5065): o AS principal é dividido em sub-ASs (member-AS) com ASNs privados. Dentro da confederação, eBGP é usado entre os sub-ASs, mas externamente o AS confederado apresenta um único ASN.

4. Configuração BGP no Linux (FRR)

O FRRouting (FRR) é o sucessor do Quagga e Zebra, oferecendo uma implementação completa de BGP (e OSPF, RIP, IS-IS) para Linux. É a ferramenta ideal para laboratórios, ambientes de produção em centros de dados, e aprendizagem prática do protocolo sem equipamento proprietário.

# Instalar FRR para BGP
apt install frr frr-rtrlib
# Configurar BGP no Linux com FRR
vtysh
configure terminal
router bgp 65001
bgp router-id 192.168.1.1
neighbor 10.0.0.2 remote-as 65002
address-family ipv4 unicast
network 192.168.1.0/24
exit-address-family
exit
# Verificar vizinhos BGP
show ip bgp summary
# Verificar tabela BGP
show ip bgp
# Filtrar prefixos
neighbor 10.0.0.2 prefix-list FILTER-IN in
ip prefix-list FILTER-IN permit 192.168.0.0/16 le 24

Após instalar o FRR, é necessário activar o daemon BGP no ficheiro de configuração do daemon, tipicamente em /etc/frr/daemons, definindo bgpd=yes. Reiniciar o serviço com systemctl restart frr.

O comando show ip bgp summary é a primeira ferramenta de diagnóstico. A coluna State/PfxRcd mostra o estado da sessão e o número de prefixos recebidos de cada vizinho. Se aparecer Idle, a sessão TCP não foi estabelecida — verificar conectividade L3, firewall na porta 179 e ASN remoto.

O bgp router-id identifica único do router no domínio BGP. Se não for configurado manualmente, o FRR usa o maior IP de loopback. Em ambientes de produção, deve ser sempre definido explicitamente com um endereço de loopback estável.

5. Políticas de Encaminhamento e Filtragem

A essência do BGP não está em encontrar o caminho mais curto — está em aplicar políticas. Um operador decide quais rotas aceita, quais prefere, quais re-anuncia e com que atributos. Isto é feito através de filtros, route-maps e manipulação de atributos BGP.

Os principais atributos BGP que influenciam a selecção de rotas, por ordem de prioridade:

A filtragem de rotas é feita com prefix-lists (para prefixos IP), filter-lists (baseadas em AS-Path com expressões regulares), e route-maps (combina múltiplas condições e permite modificar atributos). O exemplo do FRR acima usa uma prefix-list para aceitar apenas prefixos de 192.168.0.0/16 com máscara até /24.

As BGP Communities (RFC 1997) são etiquetas de 32 bits (formato AS:nn) que viajam com as rotas e permitem sinalizar preferências a provedores de transit. Comunidades bem conhecidas incluem:

• no-export (65535:1) — a rota não deve ser anunciada a vizinhos eBGP.
• no-advertise (65535:2) — a rota não deve ser anunciada a nenhum vizinho.
• blackhole (65535:666) — pedir ao provedor para descartar tráfego para o prefixo (mitigação de DDoS).

O RPKI (Resource Public Key Infrastructure, RFC 6480) é a infraestrutura de validação criptográfica que permite verificar se um AS está autorizado a anunciar um prefixo. O FRR suporta RPKI através do pacote frr-rtrlib, que se liga aos validadores como Routinator ou OctoRPKI. Rotas Invalid são rejeitadas; rotas NotFound ou Valid são aceites.

6. BGP para PME — Multihoming

Multihoming é a conectividade redundante a dois ou mais provedores de Internet. Para PMEs que dependem criticamente da conectividade (comércio electrónico, VoIP, serviços cloud), o multihoming via BGP oferece redundancia activa com failover automático.

Existem duas abordagens principais:

Com Provider Independent (PI), a PME obtém um bloco de endereços IP e um ASN próprios, que anuncia a ambos os provedores. Se um provedor falha, o BGP converge (tipicamente em segundos a minutos) e o tráfego passa pelo outro provedor automaticamente. É a solução profissional, mas requer custo de subscrição RIPE e acordos com ambos os ISPs para anunciar o prefixo.

Com Provider Aggregatable (PA), a PME usa endereços de um dos ISPs e faz NAT no router de borda. No failover, o NAT muda de IP de saída, mas os endereços internos não mudam. É mais simples e barato, mas não permite ligações entradas redundantes (servidores acessíveis por ambos os ISPs).

Estratégias de tráfego com multihoming BGP:

• AS-Path prepending — anunciar o próprio AS várias vezes numa rota, tornando o AS-Path mais longo e portanto menos atractivo. Usado para fazer o tráfego preferir um ISP sobre o outro.
• Local Preference — definir preferência local para rotas recebidas de um ISP sobre o outro (aplica-se ao tráfego de saída).
• MED — sugerir ao provedor qual caminho preferir para tráfego de entrada (não é obrigatório ser respeitado).
• Communities — muitos ISPs oferecem comunidades para controlar propagação (ex: anunciar só nacional, só a pares, com prepend).

No Dia 23 abordaremos BGP para PME em detalhe, com cenários práticos de configuração, failover e optimização de custos.

7. Erros Comuns e Lista de Verificação

Erros mais frequentes em configuração BGP:

• Não filtrar prefixos recebidos — aceitar a tabela completa sem prefix-lists permite que um vizinho injecte rotas inválidas, potencialmente desviando tráfego.
• Esquecer o AS-Path loop — se o AS-Path não for verificado, um router pode aceitar uma rota que já atravessou o seu AS, criando um ciclo.
• Next-hop inalcançável em iBGP — o iBGP preserva o next-hop eBGP, que pode não ser alcançável por routers internos. Usar next-hop-self para resolver.
• Full-mesh iBGP incompleto — se nem todos os routers iBGP têm sessões entre si, rotas são aprendidas de forma assimétrica. Usar Route Reflectors ou Confederações.
• TTL insuficiente em eBGP multihop — quando vizinhos eBGP não estão directamente ligados, é necessário ebgp-multihop com TTL adequado.
• Não activar RPKI — sem validação RPKI, o router aceita qualquer prefixo, aumentando o risco de aceitar anúncios maliciosos.
• Router-id duplicado — dois routers com o mesmo router-id causam comportamento imprevisível. Definir sempre manualmente.
• Ignorar BGP Graceful Restart — sem graceful restart, uma reinicialização do processo BGP interrompe todas as sessões e convergência demora mais.

Lista de verificação para produção BGP:

• ✓ bgp router-id definido explicitamente em todos os routers.
• ✓ Prefix-lists de entrada e saída em todos os vizinhos eBGP.
• ✓ RPKI activado com validador operacional (Routinator ou equivalente).
• ✓ next-hop-self em sessões iBGP onde aplicável.
• ✓ Full-mesh iBGP ou Route Reflector configurado.
• ✓ BGP Graceful Restart activado para reduzir tempo de convergência.
• ✓ Monitorização de sessões BGP (SNMP, Prometheus/blackbox exporter, ou Nagios).
• ✓ AS-Path filtering com expressões regulares para rotas de clientes.
• ✓ Comunidades documentadas e acordadas com provedores de transit.
• ✓ Plano de rollback para mudanças de política (guardar configuração anterior).

No próximo dia continuaremos a explorar protocolos de rede essenciais. O Dia 23 dedicar-se-á inteiramente ao BGP para PME, com configurações práticas de multihoming, estratégias de custo e cenários de failover reais.