BGP — Border Gateway Protocol
Do fundamento ao nível especialista — o protocolo que mantém a internet de pé, com contexto direto de como isso funciona no Brasil (IX.br, registro.br, GTER/GTS) e no mundo.
Nesta página
1. Nível Básico — Fundamentos Básico
Se você nunca configurou BGP na vida, comece aqui. Sem pré-requisito além de entender o que é um endereço IP e uma rota.
1.1 A internet é uma rede de redes
Não existe "a internet" como uma rede única administrada por alguém. Existem milhares de redes independentes — operadoras, provedores regionais, universidades, empresas de conteúdo (Google, Netflix, Cloudflare) — cada uma administrando seu próprio espaço de endereçamento e decidindo sua própria política de roteamento. Cada uma dessas redes é um Sistema Autônomo (AS). O que faz a internet parecer uma rede única é justamente o BGP: o protocolo que permite todos esses ASes anunciarem uns aos outros "eu alcanço esta faixa de endereços IP, por este caminho".
1.2 IGP vs. EGP — por que BGP é diferente de OSPF
Protocolos de roteamento se dividem em duas famílias:
- IGP (Interior Gateway Protocol) — roteia dentro de um único AS. Ex: OSPF, IS-IS, EIGRP. Otimiza por métrica técnica: menor custo, menor número de saltos, maior banda.
- EGP (Exterior Gateway Protocol) — roteia entre AS diferentes. BGP é hoje o único EGP realmente usado no mundo (o EGP original, de mesmo nome, é histórico e obsoleto). Não otimiza por métrica técnica — otimiza por política: contrato comercial, acordo de peering, preferência de tráfego.
Analogia: OSPF é como o GPS dentro de uma cidade, otimizando pela rota mais rápida. BGP é como as regras internacionais de tráfego aéreo entre países — não é sobre "o caminho mais curto", é sobre quem tem acordo com quem, e quais rotas cada país autoriza sobrevoar.
1.3 Tipos de Sistema Autônomo
| Tipo | Característica | Exemplo |
|---|---|---|
| Stub AS | Conectado a só 1 upstream, não repassa tráfego de terceiros | ISP pequeno com 1 link |
| Multihomed AS | Conectado a 2+ upstreams, mas não repassa trânsito de um pro outro | ISP médio com redundância |
| Transit AS | Repassa tráfego entre outros AS — vende trânsito | Operadora de backbone (Tier 1/2) |
1.4 eBGP vs. iBGP
eBGP (external) conecta roteadores de AS diferentes — é o que liga seu provedor a um upstream ou a um peer no IX.br. iBGP (internal) conecta roteadores do mesmo AS, distribuindo internamente o que foi aprendido via eBGP. Diferença de comportamento padrão: uma rota aprendida via iBGP não é repassada para outro peer iBGP (regra do split-horizon de iBGP) — é por isso que redes com mais de 2 roteadores de borda precisam de full-mesh de sessões iBGP ou de Route Reflectors (ver seção Avançado).
1.5 Quando você realmente precisa de BGP
Segundo a política oficial de alocação de ASN no Brasil (registro.br/LACNIC), a justificativa técnica é estar conectado a dois ou mais provedores de trânsito distintos e independentes (exigindo roteamento dinâmico) — ou ter uma política de roteamento própria. Com 1 upstream só, geralmente uma rota estática padrão resolve. BGP entra quando a redundância de trânsito entra em cena.
2. Nível Intermediário — O protocolo em detalhe Intermediário
Pré-requisito: seção 1. Aqui entra o que você precisa saber pra configurar e ler uma sessão BGP com confiança.
2.1 Máquina de estados da sessão (RFC 4271)
Toda sessão BGP passa por uma máquina de estados finita antes de ficar operacional. Reconhecer esses estados é o primeiro passo de qualquer troubleshooting:
| Estado | O que significa |
|---|---|
| Idle | Estado inicial — sem tentativa de conexão TCP ainda, ou peer rejeitando |
| Connect | Aguardando handshake TCP (porta 179) completar |
| Active | TCP falhou, tentando de novo — fica preso aqui quando não há conectividade IP básica |
| OpenSent | TCP ok, mensagem OPEN enviada, aguardando OPEN do peer |
| OpenConfirm | OPEN trocado dos dois lados, aguardando KEEPALIVE de confirmação |
| Established | Sessão operacional — troca de rotas (UPDATE) acontece só aqui |
Regra prática: sessão presa em Active quase sempre é problema de conectividade IP/firewall na porta TCP 179. Sessão presa em OpenSent costuma ser ASN errado configurado de um dos lados.
2.2 As 4 mensagens do protocolo
- OPEN — primeira mensagem, negocia ASN, Hold Time, Router ID e capacidades (ex: suporte IPv6, 4-byte ASN)
- UPDATE — anuncia (NLRI + atributos) ou retira (Withdrawn Routes) prefixos
- KEEPALIVE — mantém a sessão viva; enviada periodicamente (padrão 1/3 do Hold Time)
- NOTIFICATION — sinaliza erro e encerra a sessão imediatamente (ex: Hold Time expirado, erro de autenticação)
2.3 Timers
Hold Time padrão: 180 segundos (se nenhuma mensagem chegar nesse intervalo, a sessão cai). Keepalive Interval padrão: 60 segundos, ou 1/3 do Hold Time negociado. Os dois lados negociam o menor Hold Time proposto entre eles. Redes que precisam de convergência mais rápida reduzem esses valores (ex: 3s/9s) — mas timers agressivos demais em enlace com jitter alto causam flapping desnecessário (ver Troubleshooting).
2.4 Atributos de rota — tabela completa
| Atributo | Categoria RFC 4271 | Função |
|---|---|---|
| ORIGIN | Well-known mandatory | Como o prefixo entrou no BGP: IGP (0), EGP (1) ou INCOMPLETE (2, ex: redistribuído de rota estática) |
| AS_PATH | Well-known mandatory | Lista de AS atravessados. Também previne loop (rota com o próprio AS no path é descartada) |
| NEXT_HOP | Well-known mandatory | IP do próximo salto — em eBGP muda pro IP do roteador anunciante; em iBGP, por padrão, não muda (ver "next-hop-self") |
| LOCAL_PREF | Well-known discretionary | Preferência interna — só se propaga dentro do próprio AS via iBGP, nunca sai pra eBGP |
| MED | Optional non-transitive | Sugestão pro AS vizinho de qual entrada preferir — só comparado entre rotas do mesmo AS vizinho |
| COMMUNITIES | Optional transitive | Marcação flexível de política (RFC 1997) — ver seção Avançado |
| ATOMIC_AGGREGATE | Well-known discretionary | Sinaliza que o prefixo é resultado de uma agregação que perdeu informação de path mais específico |
| AGGREGATOR | Optional transitive | Identifica qual AS/roteador fez a agregação de rotas (route summarization) |
2.5 Algoritmo de seleção — passo a passo com exemplo numérico
Ordem oficial (RFC 4271) — alguns fabricantes adicionam Weight como critério 0, proprietário, local ao roteador, nunca anunciado:
- Maior LOCAL_PREF
- Menor AS_PATH (contagem de AS)
- Menor ORIGIN (IGP < EGP < INCOMPLETE)
- Menor MED (só entre rotas do mesmo AS vizinho)
- eBGP preferida sobre iBGP
- Menor métrica IGP até o next-hop
- Desempate: rota mais antiga → menor Router-ID → menor endereço do peer
Exemplo prático — roteador recebe 2 caminhos pra 198.51.100.0/24:
| Rota A | LOCAL_PREF 100, AS_PATH: 65010 65020 (2 AS) |
| Rota B | LOCAL_PREF 150, AS_PATH: 65030 65040 65050 (3 AS) |
Vence Rota B — mesmo tendo AS_PATH mais longo (critério 2), o critério 1 (LOCAL_PREF) já decide antes de chegar no critério 2. LOCAL_PREF sempre tem prioridade sobre comprimento de AS_PATH.
3. Nível Avançado — Escala e extensões Avançado
Pré-requisito: seções 1 e 2. Conteúdo pra quem já opera BGP em produção e precisa escalar ou resolver cenários complexos.
3.1 Escalando iBGP — Route Reflectors e Confederations
A regra de que iBGP não repassa rota pra outro iBGP obriga, em teoria, full-mesh (todo roteador de borda conectado a todos os outros) — o que escala mal (N×(N-1)/2 sessões). Duas soluções documentadas:
- Route Reflector (RR) — um ou poucos roteadores centrais têm permissão especial de repassar rotas iBGP recebidas pra outros peers iBGP ("clientes" do RR). Elimina a necessidade de full-mesh. Solução mais comum na prática.
- Confederation — divide um AS grande em vários "sub-AS" privados, cada um com full-mesh interno, conectados entre si por uma forma especial de eBGP que preserva a aparência de AS único pra fora. Menos usado que RR, mais complexo de administrar.
3.2 Communities avançadas
Além das communities customizadas (formato ASN:valor), existem 3 well-known communities padronizadas (RFC 1997), reconhecidas por qualquer implementação:
| Community | Valor | Efeito |
|---|---|---|
| NO_EXPORT | 65535:65281 | Não anunciar pra fora do AS (nem eBGP nem confederation) |
| NO_ADVERTISE | 65535:65282 | Não anunciar pra nenhum peer, nem iBGP |
| NO_EXPORT_SUBCONFED | 65535:65283 | Não anunciar pra fora do sub-AS numa confederation |
Duas extensões mais recentes resolvem limitações das communities clássicas (32 bits, formato ASN:valor de 16+16 bits, problemático com ASN de 4 bytes):
- Extended Communities (RFC 4360) — 64 bits, usado principalmente em MPLS L3VPN (Route Target, Route Origin)
- Large Communities (RFC 8092) — 3 campos de 32 bits (Global Administrator:Local Data 1:Local Data 2), desenhado justamente pra funcionar bem com ASN de 4 bytes, cada vez mais comum em política de operadora
3.3 ASN de 4 bytes (RFC 6793)
O espaço original de ASN (16 bits, até 65535) se esgotou globalmente. A extensão pra 4 bytes (até ~4,3 bilhões de ASNs) usa o AS 23456 (AS_TRANS) como placeholder de compatibilidade quando um roteador só entende ASN de 16 bits precisa lidar com um vizinho de 4 bytes. LACNIC — e por consequência registro.br — já aloca ASN de 32 bits por padrão pra novos pedidos.
3.4 Multipath e ECMP
Por padrão o BGP instala só uma rota na tabela de encaminhamento por prefixo (a "melhor", pelo algoritmo da seção 2.5). Com multipath habilitado, caminhos empatados nos primeiros critérios (tipicamente até o MED) podem ser instalados simultaneamente, com balanceamento de carga (ECMP — Equal-Cost Multi-Path) entre eles. Útil quando há 2+ upstreams do mesmo porte, mas exige atenção: nem toda aplicação tolera bem pacotes de um mesmo fluxo chegando por caminhos com latência diferente.
3.5 Convergência rápida — BFD e Graceful Restart
Detectar falha de link só pelo Hold Time do BGP (mínimo prático de alguns segundos) é lento pra rede de produção crítica. BFD (Bidirectional Forwarding Detection) detecta falha de link na casa dos milissegundos e sinaliza o BGP pra derrubar a sessão imediatamente, sem esperar o Hold Time expirar. Graceful Restart (RFC 4724) faz o oposto no sentido de disponibilidade: permite que o plano de encaminhamento continue funcionando durante um restart do processo BGP (ex: atualização de software), sem descartar as rotas já instaladas.
3.6 BGP FlowSpec — mitigação de DDoS via BGP
RFC 8955 estende o BGP pra distribuir regras de filtragem de tráfego (não só rotas) — permite que um cliente sob ataque DDoS sinalize ao upstream, via BGP, "descarte tráfego com esta assinatura" (IP origem/destino, porta, protocolo) automaticamente, em segundos, sem intervenção manual do NOC do upstream. Cada vez mais oferecido como serviço por operadoras de trânsito maiores.
4. Segurança — RPKI, BGPsec e MANRS Avançado
BGP foi desenhado nos anos 1990 sem segurança nativa — qualquer AS pode, por erro ou má-fé, anunciar um prefixo que não é seu. As iniciativas abaixo existem justamente pra mitigar isso.
4.1 RPKI e ROV
RPKI (Resource Public Key Infrastructure) é uma infraestrutura de chave pública que permite ao dono legítimo de um bloco IP assinar criptograficamente um ROA (Route Origin Authorization) — um registro dizendo "o AS X está autorizado a originar o prefixo Y". Roteadores fazem ROV (Route Origin Validation) contra essa base, classificando cada rota recebida como Valid, Invalid ou NotFound (sem ROA cadastrado). A prática recomendada — e cada vez mais exigida por grandes operadoras — é rejeitar automaticamente rotas marcadas Invalid. NIC.br/LACNIC operam a infraestrutura RPKI pra recursos alocados na região.
4.2 BGPsec — o próximo passo (ainda pouco implantado)
RPKI/ROV valida só a origem do anúncio (quem originou o prefixo), não o caminho inteiro — um AS mal-intencionado no meio do caminho ainda pode manipular o AS_PATH. BGPsec (RFC 8205) assina criptograficamente cada salto do AS_PATH, tornando impossível falsificar o caminho sem detecção. Adoção real ainda é baixa globalmente — exige suporte de hardware/software em praticamente todos os ASes do caminho pra funcionar, o que é uma barreira de adoção coletiva significativa.
4.3 MANRS — boas práticas coletivas
MANRS (Mutually Agreed Norms for Routing Security), iniciativa da Internet Society, define um conjunto mínimo de ações que qualquer operador de rede deveria implementar: filtragem de rotas (não aceitar/anunciar prefixo inválido), anti-spoofing (impedir tráfego com IP de origem falsificado saindo da própria rede), coordenação (manter contato técnico atualizado e responsivo) e validação global (publicar dados de rota corretos, incluindo ROA). É voluntário, mas cada vez mais citado como referência de "operação responsável" — inclusive por grandes players exigindo conformidade MANRS de parceiros de peering.
5. Casos reais de sequestro de rota (route hijack) Avançado
Incidentes históricos amplamente documentados internacionalmente — usados aqui como estudo de caso do que RPKI/ROV e filtragem adequada previnem.
Pakistan Telecom recebeu ordem do governo local para bloquear o YouTube internamente, anunciando internamente uma rota mais específica pro bloco de IP do YouTube pra descartar o tráfego. O anúncio vazou para fora da rede local via BGP (deveria ter sido bloqueado por filtro no upstream, mas não foi), fazendo o mundo inteiro rotear tráfego do YouTube para o Paquistão por engano — o YouTube ficou inacessível globalmente por cerca de 2 horas até o incidente ser identificado e revertido.
Atacantes anunciaram, via um provedor de trânsito, rotas mais específicas pra blocos de IP usados pelo serviço de DNS Amazon Route 53, redirecionando parte do tráfego destinado ao site MyEtherWallet (carteira de criptomoeda) para um servidor controlado pelos atacantes, que capturava credenciais. É o exemplo mais citado de sequestro de BGP usado ativamente pra roubo financeiro direto, não só interrupção de serviço.
Os dois casos têm a mesma causa raiz: ausência de filtragem adequada de anúncios ilegítimos, seja por prefix-list mal configurada, seja por falta de ROV/RPKI. É por isso que a seção 4 não é teoria abstrata — é prevenção de incidente documentado.
6. BGP no contexto brasileiro Intermediário
6.1 IX.br — o maior IXP do mundo em tráfego
O IX.br (PTT.br), projeto do CGI.br operado pelo NIC.br, reúne dezenas de PTTs pelo país. É consistentemente citado como o maior conjunto de IXPs do mundo, tanto em volume de tráfego agregado quanto em número de Sistemas Autônomos participantes. Pra maioria dos provedores brasileiros pequenos/médios, participar via route server do IX.br é o primeiro contato real com BGP em produção — dispensa montar sessão eBGP individual com cada peer. O IX.br publica política oficial de tratamento de communities (docs.ix.br), usada tanto pra rastrear origem de prefixo quanto pra política de tráfego mais granular.
6.2 Obtendo um ASN — registro.br e LACNIC
registro.br é o NIR (National Internet Registry) brasileiro, sob hierarquia do LACNIC (equivalente latino-americano do RIPE NCC europeu ou ARIN norte-americano). Documentação tipicamente exigida:
- CNPJ e comprovação de atividade de provedor
- Contrato(s) de link dedicado/trânsito IP com ASN do(s) fornecedor(es)
- Designação dos blocos IP no WHOIS/RDAP referentes ao trânsito contratado
- Gráficos de utilização dos enlaces contratados
- Justificativa de política de roteamento própria e/ou multihoming
6.3 GTER/GTS — a comunidade técnica por trás do conhecimento
O GTER (desde 1994) e o GTS (desde 2003), promovidos pelo NIC.br, reúnem periodicamente engenheiros de rede de operadoras e provedores de todo o Brasil pra compartilhar material técnico não-proprietário — dezenas de apresentações históricas sobre BGP, communities, RPKI, CGNAT e política de roteamento, todas públicas no FTP da registro.br.
7. Configuração de referência — multi-fabricante Intermediário
Mesmo cenário (sessão eBGP com upstream, AS local 65000, peer AS 65001 em 200.0.0.1, anunciando 203.0.113.0/24) implementado nos 4 ambientes mais citados em contexto de provedor brasileiro — genérico Cisco/Juniper por serem os mais usados em material didático internacional, RouterOS por ser o mais comum em ISP pequeno/médio no Brasil, e FRRouting por ser software livre e usado, inclusive, como referência de exemplo pelo próprio IX.br.
Cisco IOS-XE
router bgp 65000
bgp router-id 203.0.113.1
neighbor 200.0.0.1 remote-as 65001
neighbor 200.0.0.1 description Upstream-Principal
neighbor 200.0.0.1 prefix-list UPSTREAM-IN in
neighbor 200.0.0.1 prefix-list ANUNCIO-OUT out
!
address-family ipv4
network 203.0.113.0 mask 255.255.255.0
neighbor 200.0.0.1 activate
exit-address-family
!
ip prefix-list UPSTREAM-IN seq 5 permit 0.0.0.0/0
ip prefix-list ANUNCIO-OUT seq 5 permit 203.0.113.0/24Juniper JunOS
set routing-options autonomous-system 65000
set routing-options router-id 203.0.113.1
set protocols bgp group UPSTREAM type external
set protocols bgp group UPSTREAM peer-as 65001
set protocols bgp group UPSTREAM neighbor 200.0.0.1 description "Upstream Principal"
set protocols bgp group UPSTREAM import UPSTREAM-IN
set protocols bgp group UPSTREAM export ANUNCIO-OUT
set policy-options prefix-list ANUNCIO prefix-list 203.0.113.0/24
set policy-options policy-statement ANUNCIO-OUT term 1 from prefix-list ANUNCIO
set policy-options policy-statement ANUNCIO-OUT term 1 then accept
set routing-options static route 203.0.113.0/24 discardMikrotik RouterOS
/routing bgp template
add name=default as=65000 router-id=203.0.113.1
/routing bgp connection
add name=upstream-principal remote.address=200.0.0.1 remote.as=65001 \
template=default output.filter-chain=anuncio-out input.filter-chain=upstream-in
/routing filter rule
add chain=anuncio-out rule="if (dst in 203.0.113.0/24) { accept }"
add chain=anuncio-out rule="reject"
add chain=upstream-in rule="if (dst in 0.0.0.0/0) { accept }"
/ip route
add dst-address=203.0.113.0/24 type=blackholeFRRouting (Linux)
router bgp 65000
bgp router-id 203.0.113.1
neighbor 200.0.0.1 remote-as 65001
neighbor 200.0.0.1 description Upstream-Principal
!
address-family ipv4 unicast
network 203.0.113.0/24
neighbor 200.0.0.1 prefix-list UPSTREAM-IN in
neighbor 200.0.0.1 prefix-list ANUNCIO-OUT out
exit-address-family
!
ip prefix-list UPSTREAM-IN seq 5 permit 0.0.0.0/0
ip prefix-list ANUNCIO-OUT seq 5 permit 203.0.113.0/24
!
ip route 203.0.113.0/24 Null0FRRouting nasceu como fork do Quagga/Zebra, que seguiu convenção próxima de Cisco IOS clássico — por isso a sintaxe fica quase idêntica ao exemplo Cisco acima.
8. Comandos de verificação e teste Intermediário
Depois de configurar, é assim que você testa e comprova que a sessão está saudável e a política está correta — antes de considerar o trabalho terminado.
| O que checar | Cisco / FRR | JunOS | RouterOS |
|---|---|---|---|
| Estado da sessão | show ip bgp summary | show bgp summary | /routing bgp session print |
| Rotas recebidas de um peer | show ip bgp neighbors X.X.X.X received-routes | show route receive-protocol bgp X.X.X.X | /routing bgp advertisements print |
| Rotas anunciadas a um peer | show ip bgp neighbors X.X.X.X advertised-routes | show route advertising-protocol bgp X.X.X.X | /routing bgp advertisements print |
| Detalhe de um prefixo específico | show ip bgp 203.0.113.0/24 | show route 203.0.113.0/24 detail | /routing bgp route print detail where dst-address="203.0.113.0/24" |
| Reprocessar política sem derrubar sessão | clear ip bgp X.X.X.X soft | clear bgp neighbor X.X.X.X soft | (automático — RouterOS reaplica filtro sem soft-reset manual) |
| Log de eventos da sessão | show logging | include BGP | show log messages | match bgp | /log print where topics~"bgp" |
Checklist mínimo de "sessão pronta pra produção":
- Sessão em Established há tempo suficiente (não recém-subiu)
- Número de prefixos recebidos condiz com o esperado (full table ≈ centenas de milhares; rota parcial, o combinado com o peer)
- Prefixo próprio aparece corretamente do outro lado (peça ao peer ou use looking glass público)
- Filtro de entrada/saída testado — anuncie um prefixo de teste fora da política e confirme que é rejeitado
- MD5/autenticação de sessão configurada, se acordado com o peer
9. Indicadores de operação (KPIs) Avançado
O que monitorar continuamente (via SNMP/NMS — Zabbix, LibreNMS) pra saber se o BGP está saudável antes que o cliente reclame.
| Indicador | O que revela | Sinal de alerta |
|---|---|---|
| Session Uptime | Tempo desde o último Established | Resetando com frequência = instabilidade de link ou timer agressivo |
| Prefixos recebidos (contagem) | Tamanho da tabela recebida do peer | Queda abrupta = peer com problema; crescimento fora do padrão = possível route leak recebido |
| Churn rate (updates/min) | Frequência de mudança de rota | Pico sustentado pode indicar instabilidade em algum ponto da internet (ou do seu enlace) |
| RIB size vs. FIB size | Rotas conhecidas vs. instaladas de fato | Discrepância grande pode indicar limite de hardware/TCAM sendo atingido |
| Convergence Time | Tempo entre falha e rota alternativa ativa | Alto tempo = revisar timers/BFD, ou dependência de Hold Time puro |
| % de rotas com ROV Invalid | Higiene de RPKI da própria política e dos peers | Se não está descartando Invalid automaticamente, está aceitando risco de hijack desnecessário |
10. Exercícios práticos Intermediário
Resolva antes de olhar o gabarito — é assim que fixa de verdade.
Exercício 1. Seu roteador recebe o prefixo 198.51.100.0/24 por dois caminhos: Rota A (eBGP, AS_PATH com 3 AS, sem LOCAL_PREF customizado) e Rota B (iBGP, AS_PATH com 2 AS, sem LOCAL_PREF customizado). Qual vence, e por quê?
Ver gabarito
Com LOCAL_PREF igual nos dois (nenhum customizado, ambos usam o padrão), o critério 1 empata. O critério 2 é menor AS_PATH — Rota B tem AS_PATH menor (2 < 3), então Rota B vence nesse critério, antes mesmo de chegar ao critério 5 (eBGP sobre iBGP), que só seria avaliado em caso de novo empate. Repare: o critério "eBGP preferida sobre iBGP" vem depois de AS_PATH na ordem oficial — por isso não decide aqui.
Exercício 2. Você quer que o tráfego de entrada prefira o Link 1 sobre o Link 2, ambos eBGP com o mesmo upstream. Qual atributo você manipula, e em qual direção (maior ou menor valor pra ser preferido)?
Ver gabarito
MED (Multi-Exit Discriminator) — menor valor é preferido. Configure um MED menor no anúncio saindo pelo Link 1 do que pelo Link 2. Atenção: MED só é comparado quando as duas rotas vêm do mesmo AS vizinho — se fossem upstreams diferentes, MED não teria efeito nenhum, e a ferramenta certa seria AS_PATH prepending (tornar o Link 2 "artificialmente pior" aos olhos do upstream).
Exercício 3. Uma sessão BGP fica presa em estado Active e nunca avança pra OpenSent. Liste 2 causas prováveis, em ordem de probabilidade.
Ver gabarito
1) Falta de conectividade IP básica até o peer (ping falha) — causa mais comum de longe. 2) Firewall/ACL bloqueando TCP porta 179 entre os dois — conectividade IP existe (ping funciona) mas o handshake TCP nunca completa. Estado Active significa "TCP não conseguiu conectar", então o problema está sempre em camada de rede/transporte, nunca em configuração de política do BGP em si (LOCAL_PREF, communities etc. só importam depois de Established).
Exercício 4 (cenário RPKI). Seu roteador recebe um prefixo com ROV = Invalid, mas sua política ainda não rejeita rotas Invalid automaticamente — só loga um alerta. Que tipo de incidente histórico (seção 5) esse cenário deixa sua rede exposta a repetir?
Ver gabarito
Exposição a route hijack do tipo Pakistan Telecom/YouTube (2008) ou MyEtherWallet (2018) — nos dois casos, um anúncio ilegítimo de origem foi aceito e propagado porque não havia validação/filtro rejeitando automaticamente. Só logar sem rejeitar não previne o incidente, só documenta depois que já aconteceu.
11. Troubleshooting comum Intermediário
Verifique nesta ordem: conectividade IP básica → ASN remoto configurado bate com o real do peer → ACL/firewall bloqueando TCP 179 → TTL (sessão multihop precisa de ebgp-multihop).
O prefixo precisa existir de forma exata na tabela de roteamento local — erro comum é declarar network com máscara diferente da rota real instalada (ex: declarar /24 quando a rota instalada é /25).
Verificar se uma prefix-list/route-map de entrada está descartando por engano. Erro clássico: atualizar a prefix-list e esquecer o soft-reset (clear ip bgp soft) pra forçar reprocessamento sem derrubar a sessão.
Causas mais comuns: instabilidade no link físico abaixo do BGP, MTU inconsistente entre os dois lados, ou timers muito agressivos pra um enlace com latência/jitter alto.
Tráfego de ida e volta seguindo caminhos diferentes é normal em BGP (cada AS decide sua própria política de saída) — não é bug. Só investigue se estiver causando problema real (ex: firewall stateful vendo só metade da conversa).
12. Glossário
Ferramentas relacionadas
Perguntas da Comunidade sobre BGP
Sessão não sobe, rota não anuncia, dúvida sobre communities do IX.br ou RPKI? Pergunte pra quem já passou por isso.
Fazer pergunta sobre BGP13. Referências
Padrões internacionais (IETF)
- RFC 4271 — A Border Gateway Protocol 4 (BGP-4)
- RFC 1997 / RFC 4360 — BGP Communities Attribute / Extended Communities
- RFC 8092 — BGP Large Communities Attribute
- RFC 6793 — BGP Support for 4-Octet AS Number Space
- RFC 7454 — BGP Operations and Security (route leak)
- RFC 7911 — Advertisement of Multiple Paths in BGP (Add-Path)
- RFC 4724 — Graceful Restart Mechanism for BGP
- RFC 8205 — BGPsec Protocol Specification
- RFC 8955 — Dissemination of Flow Specification Rules (FlowSpec)
Segurança e boas práticas (internacional)
- MANRS (Internet Society) — Mutually Agreed Norms for Routing Security
- Documentação de incidentes históricos de route hijack — Pakistan Telecom/YouTube (2008), MyEtherWallet/Amazon Route 53 (2018)
Contexto nacional (Brasil)
- IX.br / NIC.br — Política de Tratamento de Communities e documentação oficial de peering (docs.ix.br)
- registro.br — Regras e Políticas de Numeração
- LACNIC — Get IP Addresses/ASNs
- NIC.br / CGI.br — Fascículo "Endereços IP e ASNs: Alocação para Provedores Internet"
- GTER/GTS (NIC.br) — Apresentações técnicas públicas sobre BGP, communities, RPKI e CGNAT (arquivo FTP registro.br)
- IX Fórum Regional — "Boas Práticas em Políticas de Roteamento"
Conteúdo técnico independente, traduzido e contextualizado para o cenário brasileiro. Confirme sempre política vigente diretamente em registro.br/LACNIC/IX.br antes de decisão operacional.