BGP ISP Engenharia-de-Tráfego Redes Segurança DDoS

BGP communities: a ferramenta de engenharia de tráfego que a maioria dos ISPs na Latam não usa bem

Ariel Weher
BGP communities: a ferramenta de engenharia de tráfego que a maioria dos ISPs na Latam não usa bem

O BGP tem uma funcionalidade que muitos operadores conhecem na teoria mas poucos aproveitam em sua totalidade: as BGP communities. São atributos opcionais anexados aos prefixos anunciados que permitem tomar decisões de roteamento sofisticadas sem modificar a topologia física da rede nem alterar métricas como MED ou local-preference manualmente em cada roteador.

Na prática, o que vemos em redes latino-americanas é um de três cenários: communities não implementadas, communities implementadas pela metade sem documentação coerente, ou communities que se propagam para peers e upstreams quando não deveriam. Os três cenários têm consequências operacionais reais.

Este artigo cobre o que são, para que servem, como projetar um esquema coerente, e como configurá-las no Huawei VRP.

O que são as BGP communities e por que existem três tipos

Uma BGP community é um atributo de 32 bits que é transportado como parte de um anúncio BGP. Não tem efeito por si só: seu valor só importa quando os roteadores que recebem o prefixo têm políticas configuradas para agir em função desse valor.

Existem três variantes:

Standard communities (RFC 1997): O formato clássico, representado como ASN:valor onde cada campo ocupa 16 bits. Por exemplo, 65001:100. A limitação é que o campo ASN está restrito a 16 bits, o que cria ambiguidade em redes com ASNs de 32 bits (4-byte AS). Continuam sendo o padrão mais interoperável e o que praticamente todos os roteadores entendem.

Extended communities (RFC 4360): 64 bits de comprimento, com um campo de tipo que define como interpretar os bits restantes. São usadas principalmente em contextos específicos como MPLS VPN (Route Targets e Route Distinguishers) e em algumas implementações de QoS. Para engenharia de tráfego geral entre ISPs, são menos comuns que as standard.

Large communities (RFC 8092): O formato moderno para redes com ASNs de 32 bits. Representadas como três campos de 32 bits: ASN-global:função:parâmetro. Por exemplo, 65001:1:200 poderia significar “rota aprendida do upstream 200”. São o formato recomendado para esquemas novos e têm bom suporte no software atual (Huawei VRP, Juniper Junos, FRR, BIRD).

A escolha entre standard e large communities depende principalmente do parque de equipamentos. Redes que usam equipamentos relativamente modernos podem adotar large communities desde o início. Redes com equipamentos legados ou com peers que não suportem large communities costumam manter as standard por compatibilidade.

O problema que resolvem: influência de tráfego sem modificar a topologia

Imagine que sua rede tem dois upstreams: um transit provider A com boa conectividade para o Brasil e um transit provider B com melhor cobertura para a Europa. Sem communities, influenciar qual tráfego sai por cada upstream requer modificar o local-preference manualmente nos route-maps de cada roteador de borda, para cada prefixo ou grupo de prefixos.

Com communities, o processo pode ser centralizado: cada prefixo recebido de qualquer fonte é marcado com uma community que indica sua origem. As políticas de local-preference (e portanto de seleção de rota de saída) são aplicadas em função dessa marca. Quando você quer mudar a política (por exemplo, porque o transit provider B melhorou sua cobertura para o Brasil), modifica a policy em um lugar ao invés de reconfigurar roteador por roteador.

Na direção inversa, as communities também servem para influenciar como os upstreams e peers enviam tráfego para você. Muitos provedores de trânsito aceitam communities bem conhecidas que os instruem a modificar o BGP local-preference ou o AS-PATH prepending com que propagam seus prefixos para o resto da internet. Isso dá controle sobre o tráfego de entrada (inbound) sem mudar nada na sua infraestrutura física.

Casos de uso práticos para ISPs

Engenharia de tráfego: preferir rotas pelo upstream A vs B

O caso mais comum. Se seu AS é o 65001 e você tem dois upstreams (AS 1234 e AS 5678), pode definir um esquema de communities para indicar a preferência de saída:

  • 65001:200 em um prefixo de cliente: sair preferencialmente pelo upstream 1234
  • 65001:201 em um prefixo de cliente: sair preferencialmente pelo upstream 5678
  • 65001:100 em um prefixo de cliente: rotas internas de alta prioridade (local-preference 200)

O route-map de entrada em cada upstream avalia essas communities e atribui o local-preference correspondente. O resultado é que você pode ajustar o roteamento de saída para diferentes blocos de clientes simplesmente modificando qual community é anexada ao prefixo, sem tocar na topologia.

Também pode funcionar ao contrário: usar as communities oferecidas pelos seus upstreams para controlar como eles propagam seus prefixos. Por exemplo, muitos grandes transit providers aceitam X:0 para indicar que não devem propagar um prefixo globalmente, ou X:Y para limitar a propagação a uma região específica. Documentar quais communities cada um dos seus upstreams aceita é parte do trabalho de engenharia de tráfego que faz a diferença entre uma rede reativa e uma rede gerenciada.

Blackholing remoto (RTBH) para mitigar DDoS

O Remote Triggered Blackhole (RTBH) é um dos usos mais valiosos das communities para operadores sob pressão de um ataque DDoS. O mecanismo é conceitualmente simples: você anuncia um prefixo específico (o IP ou bloco atacado) com uma community que instrui seus upstreams e peers a descartar o tráfego destinado a esse prefixo em sua infraestrutura, antes que chegue à sua.

A community padrão para RTBH está definida no RFC 7999 — BLACKHOLE Community: 65535:666. Este RFC, publicado em outubro de 2016, padronizou uma prática que já existia informalmente entre operadores, estabelecendo 65535:666 como a community well-known universal para sinalizar blackhole. Antes do RFC 7999, cada transit provider e cada IXP definia sua própria community para RTBH (por exemplo, transit-asn:666), o que gerava fragmentação e complexidade operacional. Com a padronização, um único anúncio com 65535:666 é reconhecido pela maioria dos grandes transit providers, IXPs e redes de conteúdo.

Ao anunciar um /32 (ou /128 em IPv6) com essa community anexada, você está pedindo aos seus vizinhos BGP que instalem uma rota para esse destino apontando para Null0 ou Discard. O tráfego é descartado na borda do upstream, não na sua rede. O RFC 7999 também recomenda que a rota blackhole seja anunciada com o atributo NO_EXPORT (65535:65281) para evitar que se propague além do necessário.

A sequência operacional é:

  1. Detectar o destino sob ataque (idealmente com NetFlow/sFlow ou sistemas de detecção de anomalias)
  2. Gerar o anúncio BGP do prefixo atacado com 65535:666 anexado
  3. Propagá-lo para upstreams que suportem RTBH
  4. Monitorar a queda do volume de ataque

O custo é que o IP ou bloco atacado fica inalcançável (o tráfego legítimo também é descartado). Mas em um ataque volumétrico sério, isso é melhor do que perder toda a conectividade da rede. Muitos ISPs implementam isso de forma manual e tardia. Os que têm o mecanismo automatizado conseguem reagir em segundos.

A configuração do RTBH também pode ser feita internamente (iBGP blackhole) para descartar o tráfego na borda da sua própria rede, antes que chegue ao serviço atacado. Ambas as variantes são complementares.

Marcação de rotas por origem: customer, peer, upstream, internal

Esta é a base de uma política de roteamento bem projetada. Cada prefixo que entra na sua rede deveria carregar uma marca que identifique sua origem:

Origem Community exemplo
Cliente (customer) 65001:1000
Peer (IXP ou bilateral) 65001:2000
Upstream / transit 65001:3000
Rota interna 65001:4000

Com este esquema, as decisões de exportação se tornam políticas simples e auditáveis: “para meus upstreams, só exporto prefixos com community 65001:1000 (clientes) e meus próprios prefixos”. Nenhuma rota de peer ou upstream deveria propagar-se para outro upstream. Isso evita route leaks (que descrevemos em detalhe no nosso artigo sobre erros de configuração BGP).

Políticas de no-export, no-advertise e blackhole

O RFC 1997 e o RFC 7999 definem well-known communities com semântica padronizada que todos os roteadores BGP devem respeitar:

  • NO_EXPORT (65535:65281): Não propague este prefixo fora da confederação ou AS. Usado para rotas que devem permanecer locais à sua rede.
  • NO_ADVERTISE (65535:65282): Não propague este prefixo para nenhum vizinho BGP. O prefixo é usado localmente para decisões de roteamento mas não é redistribuído.
  • NO_EXPORT_SUBCONFED (65535:65283): Similar ao NO_EXPORT mas aplica-se ao nível de sub-confederação.
  • BLACKHOLE (65535:666): Definida pelo RFC 7999, indica que o tráfego para este prefixo deve ser descartado (blackhole). É a community padrão para RTBH e é reconhecida pela maioria dos grandes transit providers e pontos de troca de tráfego (IXPs).

As três primeiras são especialmente úteis para controlar a propagação de rotas de infraestrutura interna (loopbacks de gerência, faixas de IPs de equipamentos de rede) que não deveriam ser visíveis fora do seu AS. A quarta é a base do mecanismo de RTBH descrito acima. O erro comum é não anexá-las e descobrir que essas rotas estão sendo propagadas para peers ou upstreams quando não deveriam.

Como documentar um esquema de communities coerente (RFC 8195)

O RFC 8195 (“Use of BGP Large Communities”) não define apenas o formato técnico: também estabelece convenções de documentação para que os esquemas de communities sejam legíveis e auditáveis. A estrutura recomendada para large communities é:

<Global Administrator>:<Function>:<Parameter>

Onde:

  • Global Administrator: Seu ASN (32 bits)
  • Function: Um número que identifica o tipo de ação ou informação (definido por você)
  • Parameter: O valor específico dentro dessa função

Um exemplo de esquema documentado para AS 65001:

Community Significado
65001:1:1 Rota aprendida de cliente direto
65001:1:2 Rota aprendida de peer IXP
65001:1:3 Rota aprendida de upstream transit
65001:2:100 Ajustar local-preference para 100
65001:2:200 Ajustar local-preference para 200
65001:3:1 Não exportar para upstreams
65001:3:2 Não exportar para peers
65001:9:666 RTBH: descartar tráfego para este prefixo

O fundamental é que este esquema viva em um documento versionado (Git é o lugar certo), seja conhecido por toda a equipe de NOC e engenharia, e seja atualizado quando a política muda. Uma community que ninguém lembra o significado é pior que nenhuma: gera falsa confiança.

Erros comuns: communities que se propagam quando não deveriam

O erro mais frequente que encontramos ao auditar redes ISP é a propagação não controlada de communities internas. Quando sua rede atribui communities próprias aos prefixos (por exemplo, para indicar origem ou prioridade), essas communities devem ser removidas antes de propagar o prefixo para peers e upstreams. Se não fizer isso, você está expondo sua política de roteamento interna a operadores externos, o que no melhor caso gera confusão e no pior caso expõe informação operacional sensível.

O mecanismo para evitar isso é simples: nos route-maps de exportação para peers e upstreams, aplicar um strip de communities antes de anunciar o prefixo.

O segundo erro comum é não documentar quais communities sua rede aceita dos clientes. Se um cliente envia prefixos com communities anexadas e você não tem uma política explícita do que fazer com elas, o roteador as aceita e propaga. Isso pode resultar em que um cliente influencie acidentalmente (ou deliberadamente) sua política de roteamento.

O terceiro erro é mais sutil: não filtrar communities em sessões de peering em IXPs. Em um ponto de troca de tráfego, você recebe prefixos de dezenas de ASes. Alguns podem trazer communities que têm significado na sua rede (por coincidência de numeração). Sem filtros explícitos, essas communities podem afetar suas decisões de roteamento de formas inesperadas.

Exemplo de configuração no Huawei VRP

O exemplo a seguir mostra a configuração de um esquema básico de communities no Huawei VRP: marcação de rotas de clientes, atribuição de local-preference, e remoção de communities internas ao exportar para um upstream.

# Definir community-filter para identificar rotas de cliente
ip community-filter basic CLIENTES permit 65001:1000

# Route-policy de entrada desde cliente: marcar com community de origem
route-policy CLIENTE-IN permit node 10
 apply community 65001:1000 additive

# Route-policy de entrada desde upstream: marcar e ajustar local-pref
route-policy UPSTREAM-IN permit node 10
 apply community 65001:3000 additive
 apply local-preference 100

# Route-policy de saída para upstream: só exportar clientes e próprios
# e remover communities internas antes de exportar
route-policy UPSTREAM-OUT permit node 10
 if-match community-filter CLIENTES
 apply community none

route-policy UPSTREAM-OUT permit node 20
 if-match ip-prefix MEUS-PREFIXOS-PROPRIOS
 apply community none

# Sessão BGP com cliente
bgp 65001
 peer 203.0.113.1 as-number 64500
 peer 203.0.113.1 route-policy CLIENTE-IN import
 peer 203.0.113.1 route-policy CLIENTE-OUT export

# Sessão BGP com upstream
 peer 198.51.100.1 as-number 1234
 peer 198.51.100.1 route-policy UPSTREAM-IN import
 peer 198.51.100.1 route-policy UPSTREAM-OUT export

Para configurar RTBH no Huawei VRP, o prefixo atacado é anunciado com a community 65535:666 mediante uma rota estática para Null0 redistribuída pelo BGP:

# Rota estática para Null0 para o IP sob ataque
ip route-static 203.0.113.100 255.255.255.255 NULL0

# Route-policy para redistribuir rotas RTBH com a community correta
route-policy RTBH-OUT permit node 10
 if-match ip-prefix PREFIXOS-RTBH
 apply community 65535:666 additive

# No processo BGP, importar as rotas estáticas com a policy RTBH
bgp 65001
 import-route static route-policy RTBH-OUT

Este esquema básico pode ser estendido para suportar RTBH automático integrado com sistemas de detecção de anomalias.

Relação com RPKI e segurança de roteamento

As BGP communities e o RPKI resolvem problemas distintos mas complementares. RPKI valida que o AS de origem de um anúncio BGP tem autorização criptográfica para anunciar esse prefixo. As communities influenciam como os prefixos são propagados e priorizados uma vez que entram na rede.

Um prefixo pode ser válido do ponto de vista do RPKI (o AS tem autorização) mas ainda assim precisar de communities para que seja roteado corretamente dentro e para fora da sua rede. E um esquema de communities bem projetado complementa o RPKI ao facilitar a marcação de rotas e o controle de propagação que previne route leaks.

Se ainda não tem RPKI implementado na sua rede, o artigo RPKI vs Engenharia Social: Como proteger seu BGP quando o firewall humano falha é uma leitura complementar recomendada. Ambas as ferramentas fazem parte de uma política de roteamento madura.

Nossa experiência em campo

Nas redes ISP que auditamos na América Latina, o padrão mais frequente é o seguinte: as communities foram configuradas em algum ponto histórico, mas o esquema original não foi documentado, a pessoa que o projetou não está mais na organização, e ninguém sabe com certeza o que cada community ativa faz. A equipe de NOC aprende a não mexer nelas por medo de quebrar algo.

Isso não é engenharia de tráfego: é dívida técnica que se acumula silenciosamente.

Um esquema de communities bem projetado deveria poder ser explicado em uma única tabela, estar documentado no mesmo repositório que as configurações dos roteadores, e ser modificável por qualquer engenheiro da equipe sem precisar consultar o “especialista” de plantão.

Se sua rede opera BGP com múltiplos upstreams ou peers e quer revisar como estão configuradas suas communities (o que se propaga, o que se filtra, o que está documentado), podemos fazer essa revisão com você.

Quer projetar ou auditar o esquema de BGP communities da sua rede?

Trabalhamos com ISPs e operadores na América Latina em design de políticas de roteamento, implementação de engenharia de tráfego e auditoria de configurações BGP.

Ver nossos serviços de engenharia de redes →

Contatar a equipe →

Tem perguntas sobre BGP communities ou engenharia de tráfego na sua rede? Escreva para [email protected]

Referências