BGP para PME: Multihoming, Filtragem de Rotas e RPKI — Dia 23

O BGP (Border Gateway Protocol) é o protocolo que faz a Internet funcionar — troca rotas entre sistemas autónomos (AS) e decide por onde passa cada pacote. Embora seja frequentemente associado a grandes operadores, cada vez mais pequenas e médias empresas (PME) precisam de BGP para redundância real, multihoming e controlo do seu espaço de endereçamento. Neste artigo, exploramos como configurar BGP prático para PME com FRRouting, multihoming com dois ISPs, filtragem de rotas e validação RPKI.

ℹ O multihoming via BGP dá redundância real — se um ISP cai, o tráfego transita automaticamente pelo outro sem intervenção manual.

Neste artigo

1. Introdução ao BGP para PME

O BGP é um protocolo de routing path-vector que troca informações de alcançabilidade de rede entre sistemas autónomos. Cada AS (Autonomous System) é identificado por um número único (ASN) atribuído por um RIR (Regional Internet Registry) como o RIPE NCC para a Europa. Para uma PME, o BGP torna-se relevante quando se precisa de mais do que uma simples ligação à Internet — quando se quer redundância, controlo de tráfego ou quando se tem o próprio bloco de endereços IP.

No contexto de uma PME, existem dois cenários típicos. O primeiro é o multihoming com o próprio ASN e bloco PI (Provider Independent), que dá máxima portabilidade entre ISPs. O segundo é o multihoming com endereçamento PA (Provider Aggregatable), onde se anunciam prefixos de cada ISP separadamente — menos flexível mas mais simples e barato.

A ferramenta de eleição para correr BGP em servidores Linux é o FRRouting (FRR), sucessor do Quagga e Zebra. O FRR suporta BGP, OSPF, IS-IS e outros protocolos, com uma sintaxe familiar estilo Cisco IOS. Pode ser instalado em qualquer distribuição Linux e corre como daemon, permitindo que um servidor comum funcione como router BGP de produção.

Conceitos-chave do BGP

Conceito Descrição
AS (Autonomous System) Conjunto de redes sob uma única política administrativa, identificado por um ASN
AS_PATH Lista de ASNs por onde a rota passou — usado para evitar loops e preferir caminhos curtos
Prefixo Bloco de endereços IP anunciado (ex: 192.168.1.0/24)
eBGP BGP entre ASs diferentes (external BGP) — o mais comum em multihoming
iBGP BGP dentro do mesmo AS (internal BGP) — usado em redes internas com múltiplos routers
LOCAL_PREF Atributo local que define preferência de saída — valor mais alto = preferido
MED Multi-Exit Discriminator — sugere ao vizinho qual o caminho de entrada preferido

2. Multihoming com Dois ISPs

O multihoming é a principal razão para uma PME usar BGP. Com dois ISPs e o próprio ASN, consegue-se redundância activa-passiva (um primário, outra reserva) ou activa-activa (tráfego distribuído por ambos). A configuração básica em FRR define dois vizinhos eBGP, um para cada ISP, e anuncia o prefixo da empresa.

Para tornar um ISP primário e a outra reserva, a técnica mais simples é o AS_PATH prepending — anunciar o prefixo para o ISP secundário com o próprio ASN repetido várias vezes no AS_PATH. Isto faz com que o resto da Internet veja o caminho pelo secundário como mais longo (menos preferido), pelo que só o usa se o primário ficar indisponível.

# Configurar multihoming com FRR
router bgp 65001
 bgp router-id 192.168.1.1
 # ISP1 - primario
 neighbor 203.0.113.1 remote-as 64500
 neighbor 203.0.113.1 description ISP1-Primario
 # ISP2 - secundario
 neighbor 198.51.100.1 remote-as 64501
 neighbor 198.51.100.1 description ISP2-Secundario
 # Anunciar prefixo
 address-family ipv4 unicast
  network 192.168.1.0/24
  # ISP1 - preferir este caminho
  neighbor 203.0.113.1 route-map ISP1-OUT out
  neighbor 203.0.113.1 route-map ISP1-IN in
  # ISP2 - backup (AS_PATH mais longo)
  neighbor 198.51.100.1 route-map ISP2-OUT out
  neighbor 198.51.100.1 route-map ISP2-IN in
 exit-address-family
# Route-map para backup (prepending)
ip prefix-list MINHA-REDE permit 192.168.1.0/24
route-map ISP2-OUT permit 10
 match ip address prefix-list MINHA-REDE
 set as-path prepend 65001 65001
# Filtragem de entrada - so aceitar rotas validas
route-map ISP1-IN permit 10
 match ip address prefix-list ROTAS-VALIDAS

Nesta configuração, o route-map ISP2-OUT adiciona o ASN 65001 duas vezes ao AS_PATH, tornando o caminho pelo ISP2 três hops mais longo. O tráfego de entrada prefere naturalmente o ISP1. Para o tráfego de saída, pode-se usar LOCAL_PREF para preferir rotas aprendidas via ISP1.

Verificar sessões e estado

# Verificar sessões BGP
show ip bgp summary
show ip bgp
# Verificar RPKI
show ip bgp rpki

O comando show ip bgp summary mostra o estado de cada vizinho. A coluna State/PfxRcd indica o número de prefixos recebidos — um número significa sessão estabelecida; Idle ou Active indica problema de conectividade.

3. Filtragem de Rotas (Prefix-lists e Route-maps)

A filtragem de rotas é a defesa mais crítica em BGP. Sem filtros, um router aceita tudo o que o vizinho envia — incluindo rotas inválidas, mal formadas ou maliciosas. O incidente histórico mais conhecido foi em 2008, quando o Paquistão tentou bloquear o YouTube nacionalmente e acabou por anunciar o prefixo do YouTube globalmente, derrubando o site para todo o mundo. Em 2018, a Amazon AWS sofreu um sequestro similar de DNS via BGP.

Existem dois mecanismos principais de filtragem no FRR/Cisco IOS. As prefix-lists definem exactamente que prefixos são permitidos ou negados, com suporte para correspondência por tamanho de máscara. Os route-maps aplicam lógica condicional sobre as prefix-lists, permitindo modificar atributos BGP (AS_PATH, LOCAL_PREF, MED, communities) consoante a regra correspondida.

Prefix-lists — controlo granular

# Prefix-list para rotas validas de ISP1
ip prefix-list ROTAS-VALIDAS permit 203.0.113.0/24
ip prefix-list ROTAS-VALIDAS permit 198.51.100.0/24
# Negar tudo o resto
ip prefix-list ROTAS-VALIDAS deny 0.0.0.0/0 le 32
# Filtro anti-default: nao aceitar rota default de ISP2
ip prefix-list SEM-DEFAULT deny 0.0.0.0/0
ip prefix-list SEM-DEFAULT permit 0.0.0.0/0 le 32
# Prefix-list com correspondencia por mascara
# le = less or equal (mascara menor ou igual)
# ge = greater or equal (mascara maior ou igual)
ip prefix-list APENAS-24 permit 192.168.0.0/16 ge 24 le 24

As opções ge (greater or equal) e le (less or equal) permitem especificar intervalos de máscara. Por exemplo, ge 24 le 24 aceita apenas prefixos /24 dentro do bloco 192.168.0.0/16 — útil para filtrar anúncios mais específicos não autorizados.

Route-maps — lógica condicional

# Route-map de entrada: filtrar e atribuir LOCAL_PREF
route-map ISP1-IN permit 10
 match ip address prefix-list ROTAS-VALIDAS
 set local-preference 200
route-map ISP1-IN deny 100
# Route-map de saida: so anunciar o nosso prefixo
route-map ISP1-OUT permit 10
 match ip address prefix-list MINHA-REDE
route-map ISP1-OUT deny 100
# Route-map para prepending no ISP2
route-map ISP2-OUT permit 10
 match ip address prefix-list MINHA-REDE
 set as-path prepend 65001 65001
route-map ISP2-OUT deny 100

A regra deny 100 no final de cada route-map é uma rede de segurança — tudo o que não correspondeu a uma regra permit anterior é descartado. Sem isto, o FRR pode deixar passar rotas inesperadas. O set local-preference 200 atribui prioridade alta a rotas vindas do ISP1, garantindo que o tráfego de saída prefere esse caminho.

⚠ Anunciar prefixos não autorizados via BGP pode causar blackholes globais — usar RPKI e prefix-lists para filtrar.

4. RPKI — Validação de Rotas

O RPKI (Resource Public Key Infrastructure) é um sistema de criptografia de chave pública que associa blocos de IP e ASNs aos seus legítimos detentores. Funciona como um certificado digital: o RIPE NCC (ou outro RIR) assina um ROA (Route Origin Authorization) que declara que um determinado prefixo pode ser anunciado por um ASN específico. Os routers validam cada rota recebida contra estes ROAs e podem descartar rotas inválidas automaticamente.

O RPKI classifica cada rota em três estados. Valid: o prefixo e o ASN de origem correspondem a um ROA existente. NotFound: não existe ROA para o prefixo (não é necessariamente mau, mas não pode ser validado). Invalid: o prefixo ou o ASN de origem contradizem um ROA existente — deve ser descartado. A especificação actual para a extensão RPKI-ROA no BGP está definida na RFC 8210.

Configurar RPKI no FRR

# Configurar cache RPKI (RIPE NCC)
rpki
 rpki caching-server rpki-validator.ripe.net 8282
 rpki polling-period 60
 exit
# Politica: rejeitar rotas invalidas
router bgp 65001
 address-family ipv4 unicast
  neighbor 203.0.113.1 route-map RPKI-CHECK in
 exit-address-family
route-map RPKI-CHECK permit 10
 match rpki valid
route-map RPKI-CHECK permit 20
 match rpki not-found
route-map RPKI-CHECK deny 100

Nesta configuração, o FRR liga-se a um cache RPKI do RIPE NCC, descarrega os ROAs e valida cada rota recebida do ISP1. A route-map RPKI-CHECK aceita rotas valid e not-found, mas rejeita invalid — exactamente o comportamento recomendado pela comunidade operacional.

Estado RPKI Acção recomendada Risco
Valid Aceitar Baixo — rota certificada
NotFound Aceitar com cautela Médio — sem ROA, não verificável
Invalid Rejeitar Alto — origem não autorizada, possível sequestro

5. AS-SET e Objectos de Routing

O AS-SET é um objecto da base de dados do RIR (RIPE Database) que lista os ASNs que uma organização pode originar. Quando um ISP configura filtros automáticos, consulta o AS-SET do cliente para saber exactamente que prefixos aceitar. Sem um AS-SET correctamente configurado, os ISPs podem bloquear os anúncios da empresa ou ter de configurar filtros manuais — algo que muitos recusam fazer.

A criação de objectos na RIPE Database envolve três passos. Primeiro, criar um mntner (maintainer) que define as credenciais de autenticação. Segundo, criar um objecto aut-num com as informações do ASN. Terceiro, criar o AS-SET que referencia o aut-num. Tudo isto é feito via updates ao RIPE Database usando sintaxe RPSL (Routing Policy Specification Language).

Exemplo de objecto AS-SET

as-set:         AS-EMPRESA-PT
descr:          AS-SET para Empresa PT
members:        AS65001
tech-c:         DUMI-RIPE
admin-c:        DUMI-RIPE
mnt-by:         EMPRESA-MNT
mnt-by:         RIPE-NCC-END-MNT
source:         RIPE
changed:        [email protected] 20260809
last-modified:  2026-08-09T10:00:00Z

O campo members lista os ASNs incluídos — para uma PME com um único ASN, basta uma linha. Empresas maiores podem incluir outros AS-SETs como membros, criando hierarquias. O ISP usa este objecto para gerar automaticamente as prefix-lists que aceitam os anúncios da empresa, reduzindo configuração manual e risco de erro.

O objecto route é igualmente importante — associa cada prefixo ao seu ASN de origem na RIPE Database. Quando se cria um ROA no RPKI, este deve ser consistente com o objecto route existente. Inconsistências entre route objects e ROAs causam problemas de validação que podem levar os ISPs a rejeitar os anúncios da empresa.

6. Boas Práticas BGP para PME

Seguir boas práticas BGP não é opcional — é uma responsabilidade para com o resto da Internet. Um router BGP mal configurado pode causar impactos globais, não apenas locais. As práticas seguintes são consensuais na comunidade operacional e alinhadas com as recomendações do RIPE NCC e da MANRS (Mutually Agreed Norms for Routing Security).

Prática Descrição Benefício
Filtragem de saída Anunciar apenas os próprios prefixos Evita propagar rotas de terceiros
Filtragem de entrada Aceitar apenas rotas esperadas dos ISPs Previne aceitar rotas maliciosas
RPKI Publicar ROAs e rejeitar rotas Invalid Defesa contra sequestro de rotas
AS-SET actualizado Manter AS-SET na RIPE Database actualizado ISPs configuram filtros automaticamente
Anti-spoofing Filtrar tráfego com origem fora do bloco próprio (BCP38) Reduz impacto de ataques DDoS reflector
Maximum Prefix Definir limite de prefixos aceites por vizinho Protege contra fluxo excessivo de rotas
MD5/TCP-AO Autenticar sessões BGP com MD5 ou TCP-AO Previne ataques de reset de sessão

Maximum Prefix Limit

# Limite de prefixos por vizinho
router bgp 65001
 neighbor 203.0.113.1 maximum-prefix 100 80 restart 15
 neighbor 198.51.100.1 maximum-prefix 100 80 restart 15
# 100 = limite maximo
# 80 = warning threshold (80%)
# restart 15 = tentar reconectar apos 15 min

O maximum-prefix é uma rede de segurança crítica. Se um ISP começar a enviar milhares de rotas inesperadas (por erro ou ataque), o router corta a sessão em vez de aceitar tudo. O valor deve reflectir o número real de prefixos esperado do vizinho mais uma margem — para uma PME que só recebe rota predefinida, 100 é mais que suficiente.

7. Erros Comuns e Lista de Verificação

Os erros em BGP têm consequências desproporcionadas — uma configuração incorrecta pode afectar não apenas a empresa mas todo o ecossistema de routing da Internet. Identificar os erros mais frequentes e manter uma lista de verificação antes de activar qualquer alteração é essencial.

Erro Causa Solução
Sessão não estabelece Filtro TCP 179, ASN errado, IP errado Verificar conectividade, confirmar remote-as e IPs
Rota não anunciada Sem network statement ou rota na RIB Confirmar que a rota existe na tabela de routing
Tráfego não faz failover Prepending excessivo ou rotas estáticas Testar failover, ajustar prepending, remover estáticas
Prefixo marcado Invalid ROA com ASN ou prefixo errado Verificar ROA no RIPE Database, corrigir e republicar
Rotas aceitas em excesso Sem maximum-prefix ou filtros de entrada Configurar prefix-lists e maximum-prefix
AS-SET desactualizado Novo ASN não adicionado ao AS-SET Actualizar AS-SET na RIPE Database

Lista de verificação antes de activar BGP

  • ASN próprio atribuído por um RIR (RIPE NCC, ARIN, etc.)
  • Bloco PI registado ou acordo PA com ambos os ISPs
  • Objecto aut-num e AS-SET criados na RIPE Database
  • ROA publicado para cada prefixo a anunciar
  • Prefix-lists de entrada e saída configuradas
  • Route-maps com regra deny final explícita
  • Maximum-prefix definido em todos os vizinhos
  • Autenticação MD5 ou TCP-AO nas sessões eBGP
  • Filtragem anti-spoofing (BCP38) no tráfego de saída
  • Teste de failover: cortar ISP1 e confirmar tráfego via ISP2
  • Monitorização de sessões BGP (SNMP, Nagios, Prometheus)
  • Cópias de segurança da configuração do FRR em repositório versionado

O BGP para PME deixou de ser um luxo — é uma necessidade para quem depende da Internet como infra-estrutura crítica. Com as ferramentas certas (FRRouting), boas práticas (RPKI, MANRS) e uma configuração cuidada, qualquer empresa pode ter redundância de nível operador sem investir em hardware proprietário caro. O importante é tratar o routing com o mesmo rigor que se trata qualquer outro sistema crítico.

Artigos Relacionados