Configuração de communities BGP: guia prático para provedores

O que são communities BGP e para que servem

Community é um atributo opcional do BGP que funciona como etiqueta presa à rota. Ela não muda o caminho sozinha: quem recebe a rota decide o que fazer com cada valor, conforme uma política combinada.

Pense na community como um post-it colado no anúncio. O BGP carrega o post-it de roteador em roteador, e cada equipamento que tiver uma regra para aquele valor age; quem não tiver regra só repassa ou descarta a etiqueta, conforme a configuração.

Bem usadas, as communities são a principal ferramenta para influenciar por onde o tráfego entra na sua rede. A engenharia de tráfego BGP para provedores depende delas para dividir a carga entre operadoras sem ficar refém do caminho mais curto.

As communities padrão guardam o ASN em 16 bits. Provedores que receberam um número de 32 bits não cabem nesse campo e precisam da large community para marcar rotas com o próprio número.

Como funciona a configuração de communities BGP?

A configuração tem sempre duas pontas: um lugar onde a etiqueta é colocada e outro onde alguém age sobre ela. Se faltar uma das pontas, a community vira enfeite.

• Marcação: na entrada de uma sessão, um route-map acrescenta o valor às rotas aprendidas daquele vizinho.
• Transporte: o roteador repassa a etiqueta para os vizinhos que têm o envio de communities ligado.
• Ação: em outro ponto, um route-map compara o valor e muda preferência, filtro ou prepend.

A configuração de communities BGP exige, portanto, três peças combinadas: a lista que reconhece o valor, o route-map que marca ou age e a sessão que deixa a etiqueta passar.

Como montar um plano de communities para o provedor?

Antes de digitar qualquer comando, escreva quais valores existem, quem marca e quem age sobre cada um. O plano vira documentação para a equipe e para os clientes que têm ASN próprio.

Um plano curto, com poucos valores bem definidos, funciona melhor do que dezenas de números que ninguém lembra. Comece pela origem das rotas, que é a informação mais útil para decidir o que sai para cada vizinho.

Com a origem marcada, a regra de saída fica simples: para trânsito e IX.br, anuncie só as rotas com 64500:100 e os seus próprios blocos. Tudo o que veio de trânsito ou de ponto de troca fica dentro de casa.

Os números 64500 e 64511 do exemplo estão na faixa que a RFC 5398 reserva para documentação [CONFIRMAR]. Troque pelo ASN do provedor ao aplicar.

Que valores deixar reservados

Separe faixas por função, para que um valor novo caia sempre no lugar certo. Um desenho comum usa centenas para origem e outra faixa para pedidos dos clientes.

• Origem: de onde a rota veio, como cliente, IX.br, trânsito ou bloco próprio.
• Localização: em qual POP ou cidade a rota entrou, útil quando há mais de uma borda.
• Pedidos do cliente: prepend, não anunciar para um vizinho ou descarte, aceitos com regra.

Junto com as prefix-lists que filtram cada cliente, o plano fecha o controle da borda. O guia de configuração de prefix-lists mostra como montar esses filtros.

Configuração de communities BGP passo a passo

O exemplo marca as rotas de um cliente na entrada e usa essa marca para decidir o que sai para o trânsito. A sintaxe é de Cisco IOS-XE, mas a lógica vale para qualquer fabricante.

1. Lista de community: crie a community-list que reconhece o valor de origem do cliente.
2. Marcação na entrada: no route-map do cliente, filtre pela prefix-list e acrescente a community com additive.
3. Política de saída: no route-map do trânsito, deixe passar só o que tem a marca de cliente e os blocos próprios.
4. Envio liberado: ligue o envio de communities na sessão com o trânsito, senão o pedido não sai.
5. Conferência: limpe a sessão de forma suave e veja as rotas recebidas e anunciadas.

ip community-list standard DE-CLIENTE permit 64500:100
!
route-map CLIENTE-A-IN permit 10
 match ip address prefix-list CLIENTE-A
 set community 64500:100 additive
!
route-map TRANSITO-OUT permit 10
 match community DE-CLIENTE
 set community 64511:3 additive
route-map TRANSITO-OUT permit 20
 match ip address prefix-list BLOCOS-PROPRIOS
route-map TRANSITO-OUT deny 100
!
router bgp 64500
 address-family ipv4
  neighbor 203.0.113.2 route-map CLIENTE-A-IN in
  neighbor 192.0.2.1 send-community both
  neighbor 192.0.2.1 route-map TRANSITO-OUT out

No exemplo, 64511:3 representa um pedido de prepend ao trânsito. Cada operadora publica a sua própria tabela de communities, e o mesmo número pode significar coisas diferentes em duas operadoras.

O que cada trecho faz

A sequência 10 do route-map de saída casa as rotas de clientes e acrescenta o pedido de prepend. A sequência 20 deixa passar os blocos do próprio provedor, e a 100 nega todo o resto.

• Additive: acrescenta o valor sem apagar as communities que a rota já tinha.
• Send-community both: envia communities padrão e estendidas para o vizinho.
• Deny 100: garante que rota de trânsito ou de ponto de troca não vaze para outra operadora.

Communities do trânsito e do IX.br

As operadoras de trânsito e o IX.br oferecem communities para você controlar o que elas fazem com as suas rotas. É assim que se pede prepend, não anúncio para um vizinho ou anúncio só em uma região.

Essas communities são a forma de influenciar a entrada sem depender só de prepend no seu próprio roteador. O efeito é mais fino, porque a operadora aplica o ajuste apenas onde você pediu.

• Prepend pela operadora: aumenta o caminho visto em certas regiões, sem mexer no seu roteador.
• Não anunciar para um ASN: útil quando um vizinho distante atrai tráfego demais.
• Controle no route server: escolhe para quais participantes do IX.br a rota é anunciada. [CONFIRMAR valores na documentação do IX.br]
• Blackhole: pede o descarte do tráfego para um /32 sob ataque. A community conhecida é 65535:666.

Quando o tráfego entra torto por causa de um prepend mal calibrado, o resultado aparece como ida por um link e volta por outro. A análise de rotas assimétricas ajuda a separar esse caso de um problema de link.

Quando vale pedir blackhole por community?

O descarte por community vale quando um ataque enche o link de trânsito e o alvo é um endereço que pode ficar fora do ar por um tempo. Você sacrifica um IP para salvar o resto da base.

Antes de pedir descarte ao trânsito, confira se a origem dos prefixos está protegida pelo RPKI com ROA. Veja a criação de ROAs e a validação de origem de rotas.

Para quem precisa disso com frequência, a configuração de blackhole BGP deixa o pedido pronto para ser acionado, com limite de prefixo e registro de cada uso.

Erros comuns em communities BGP

A maior parte dos problemas com communities é configuração esquecida, não falta de conceito. Os erros abaixo aparecem com frequência em redes de provedores regionais.

Um erro silencioso é aplicar a política nova sem limpar a sessão. O roteador só reavalia as rotas quando há um refresh, então a mudança parece não ter efeito até alguém mexer de novo.

Pedido certo para a operadora errada

Copiar a community de uma operadora para outra é um erro clássico. O valor que pede prepend em um trânsito pode significar não anunciar em outro, ou não significar nada.

Guarde a tabela de cada operadora junto com o plano interno. Quando o pedido parecer não funcionar, a primeira suspeita é a tabela desatualizada, não o seu roteador.

Como validar a configuração depois de aplicar

Confira as marcas em cada ponto da rede logo depois da mudança e de novo no horário de pico. O objetivo é ver a etiqueta entrando, passando e produzindo o efeito pedido.

O roteador de borda é o ponto certo para começar a conferência, porque é onde as marcas entram e saem. A Táquion Tech configura e documenta esse plano para que o próximo ajuste não dependa da memória de uma pessoa.

Se o objetivo final é aliviar um link cheio, acompanhe os gráficos depois do ajuste. O guia sobre link de trânsito saturado mostra quais números olhar antes de mexer de novo.

Perguntas frequentes sobre communities BGP

Thiago Manoel

Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]

Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.

A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.

Conheça a equipe da Táquion Tech