BGP Communities no Huawei: da Prefix-List a um Sistema para Trânsitos, PTTs do IX.br e Blackhole

28 de setembro de 2026 69 min de leitura

BGP communities são etiquetas numéricas que você prende a uma rota para dizer ao seu roteador, e aos roteadores dos vizinhos, o que fazer com ela: aplicar prepend em um trânsito, não anunciar em outro, anunciar só dentro do PTT ou descartar o tráfego durante um ataque. Aqui o sistema é montado do zero em Huawei NE8000 (VRP8), para um provedor com três trânsitos, três PTTs do IX.br e blackhole.

Resumo em 1 minuto

Uma community standard (RFC 1997) é um valor de 32 bits no formato ASN:valor que viaja com a rota e dispara decisões de política.
A prefix-list continua filtrando o que entra e o que sai; a community decide o que acontece com um prefixo que já passou no filtro: prepend, no-export, bloqueio ou blackhole.
O sistema usa o namespace privado 64700 no formato 64700:5CCAA, em que CC é o link e AA é a ação, então cadastrar um trânsito novo é uma linha na tabela de links.
No Huawei a peça é o trio ip community-filter, route-policy com if-match community-filter e peer advertise-community; sem este último, o VRP não envia communities ao vizinho.
Para blackhole, um /32 próprio marcado com 64700:666 sai traduzido para a community de descarte de cada vizinho, como a 65535:666 do IX.br (RFC 7999), com no-export nos trânsitos (no IX.br, confira no looking glass).

O ponto de partida é o modelo que quase todo provedor pequeno e médio tem: uma route-policy de exportação por link, com um nó para cada prefix-list e um prepend fixo dentro do nó. Funciona com dois trânsitos. Com seis links e uma dúzia de blocos, cada pedido simples (tirar o prepend de um /24 só no trânsito B, por exemplo) vira edição em várias políticas, e a chance de esquecer uma delas cresce a cada link novo.

Na minha borda o dicionário de communities existe e ainda não está ligado. Os filtros por trânsito, os de prepend, no-export e blackhole estão criados, mas nenhuma route-policy consulta esses filtros. Este guia é o roteiro que eu faria para ligar os fios: desenhar o namespace, marcar a origem, filtrar a entrada, traduzir as communities na saída e só depois aposentar os nós de prefix-list.

Todos os números do cenário são fictícios: ASN de documentação 65550 (RFC 5398), blocos das faixas de documentação e IPs de sessão da faixa de benchmark. Você troca pelos seus valores; a lógica e os comandos continuam os mesmos.

Por Ivan Alves. Revisado em 28 de setembro de 2026. Sintaxe conferida para NE8000/NE40 (VRP8); as saídas de display são exemplos de laboratório.

Os Passos 1 a 4 explicam o desenho na ordem em que a configuração faz sentido. A ordem de implantação das BGP communities em produção é outra, detalhada na seção do plano de transição:

Marque a origem das rotas sem mudar nenhuma política de exportação.
Crie os nós de community nas políticas de exportação antes dos nós antigos de prefix-list.
Compare os anúncios de cada peer antes e depois, um link por vez.
Remova os nós antigos de prefix-list quando os anúncios baterem.
Libere as communities de ação para os clientes BGP e publique o guia.

O que são BGP communities (standard, extended e large)

BGP communities são atributos opcionais e transitivos do BGP (RFC 1997) que agrupam rotas sob um rótulo numérico. O rótulo não muda o caminho sozinho: ele só tem efeito quando uma route-policy, sua ou do vizinho, procura por ele e aplica uma ação, como local-preference, prepend ou descarte.

Pense na community como a etiqueta de uma mala no aeroporto. A mala (o prefixo) segue o mesmo trajeto, mas cada esteira lê a etiqueta e decide se ela vai para o voo A, para o voo B ou fica retida. Existem três famílias de etiqueta, com tamanhos diferentes:

Tipo	Tamanho e formato	Uso típico	Suporte no Huawei VRP8
Standard (RFC 1997)	32 bits, ASN16:valor16, ex.: 64700:50102	Política entre provedores, prepend, no-export, blackhole, IX.br	ip community-filter (basic e advanced) e apply community
Extended (RFC 4360)	64 bits, tipo + valor, ex.: RT 65550:100	Route target e SoO de VPN, ações de FlowSpec	Configurada pela VPN (vpn-target) e por filtros de extcommunity
Large (RFC 8092)	96 bits, ASN32:função:parâmetro, ex.: 65550:102:1	Mesmas funções da standard para quem tem ASN de 32 bits	ip large-community-filter e peer advertise-large-community (documentação Huawei)

Se você montou a MPLS L3VPN no Huawei, já usou extended communities sem chamar pelo nome: o vpn-target é um route target, e o route target é uma extended community que o MP-BGP carrega para decidir em qual VRF a rota entra. O foco aqui é a standard, a que trânsitos e route servers do IX.br leem; a large ganha seção própria mais adiante.

Communities bem conhecidas (well-known)

Alguns valores têm significado reservado e todo roteador BGP conforme a RFC trata do mesmo jeito, sem que você precise escrever política para isso. São as que mais aparecem numa borda de provedor:

Nome	Valor	Efeito	Palavra-chave no VRP
NO_EXPORT	65535:65281	Não é anunciada a peers eBGP; a rota fica no AS que a recebeu	no-export
NO_ADVERTISE	65535:65282	A rota não é anunciada a nenhum peer, nem iBGP	no-advertise
NO_EXPORT_SUBCONFED	65535:65283	Não sai da sub-AS numa confederação	no-export-subconfed
BLACKHOLE (RFC 7999)	65535:666	Pede ao vizinho que descarte o tráfego para o prefixo	valor numérico 65535:666
GRACEFUL_SHUTDOWN (RFC 8326)	65535:0	Avisa que a sessão vai cair; o vizinho baixa o local-pref antes	valor numérico 65535:0

O no-export é a que mais vai aparecer nos exemplos. Quando você anuncia um /32 de blackhole para um trânsito, ele precisa morrer ali: se o trânsito repassasse o /32 adiante, o descarte se espalharia pela internet e o endereço atacado ficaria fora do ar em lugares que você não controla.

Por que um ASN de 32 bits não cabe na community standard

A standard tem 16 bits para o ASN e 16 bits para o valor. Um ASN de 32 bits ocupa sozinho os 32 bits inteiros e não sobra espaço para a ação. O AS do cenário mostra o problema: 65550 passa de 65535, então 65550:100 não é uma community standard válida e o VRP recusa o comando.

Há três saídas, e o mercado usa as três:

Usar um namespace privado de 16 bits, como o 64700 deste guia, que só tem significado dentro do seu AS e na documentação que você publica para clientes.
Usar extended communities do tipo 4-octet AS specific, que poucos trânsitos aceitam para política de clientes.
Usar large communities (RFC 8092), no formato 65550:função:parâmetro, desde que o seu VRP e o vizinho suportem.

Muitos provedores brasileiros têm ASN de 32 bits, e montar as BGP communities num namespace privado resolve o dia a dia com suporte universal. O IX.br segue a mesma ideia ao usar o ASN do route server (26162) e valores reservados na sua própria política de tratamento de communities.

Prefix-list ou BGP communities: o que cada uma resolve

A prefix-list responde este prefixo pode entrar ou sair?; as BGP communities respondem o que eu faço com este prefixo agora que ele pode sair?. A migração não troca uma pela outra: a prefix-list fica como trava de segurança e a community passa a carregar a decisão de política.

Critério	Prefix-list	BGP communities
Segurança do que entra e sai	É a trava certa: bogons, prefixos próprios vindos de fora, só blocos exportáveis na saída	Não substitui: uma community errada não pode liberar um prefixo que não é seu
Decisão de política	Fixa no nó: o prefixo recebe o prepend daquele nó e pronto	Viaja com a rota: prepend, no-export, bloqueio e blackhole por link ou por grupo
Escala com N links	Cada link repete as listas e os nós; 6 links são 6 lugares para editar	Um molde de política por tipo de link, gerado a partir de uma tabela
Mudança sem mexer na política	Não dá: mudar o prepend é editar lista ou nó do link	Dá: troca a community marcada no prefixo e a política continua igual
Delegar ao cliente BGP	Exige ticket e edição sua na borda	O cliente marca a community publicada e a sua borda executa

O modelo com prefix-list por link costuma ter esta cara. O exemplo usa os nomes do cenário, com o bloco 203.0.113.0/24 recebendo dois prepends do AS 65550 no TRANSITO-A:

				
					ip ip-prefix TRANSITO-A-PREPEND-2X index 10 permit 203.0.113.0 24
ip ip-prefix TRANSITO-A-NORMAL index 10 permit 198.51.100.0 24
route-policy EXPORT-TRANSITO-A permit node 10
 if-match ip-prefix TRANSITO-A-PREPEND-2X
 apply as-path 65550 65550 additive
 quit
route-policy EXPORT-TRANSITO-A permit node 20
 if-match ip-prefix TRANSITO-A-NORMAL
 quit
route-policy EXPORT-TRANSITO-A deny node 100
 quit
commit

Agora imagine os pedidos reais de uma semana. O 203.0.113.0/24 precisa de um prepend só, e não dois, no TRANSITO-A; o 198.51.100.0/24 do cliente não pode ser anunciado no TRANSITO-C; e o TRANSITO-B entra em manutenção. Cada pedido mexe em listas e nós de um link diferente, com um commit por política e o risco de deixar um prefixo sem nó correspondente, que cai no deny node 100 e some da internet por aquele link.

Pedido	Modelo prefix-list	Modelo com communities
Prepend 1x em vez de 2x no TRANSITO-A	Mover o prefixo entre duas listas do link	Trocar 64700:50102 por 64700:50101 na origem
Não anunciar o bloco do cliente no TRANSITO-C	Criar nó deny e lista nova no export do link	Marcar 64700:50367 no prefixo
Prepend em todos os trânsitos de uma vez	Editar três políticas, uma por link	Marcar 64700:60002, a community do grupo de trânsitos
Blackhole de um /32 atacado	Rota estática e anúncio manual por link	Uma static com tag 666; o /32 recebe 64700:666 e cada export traduz

Repare no padrão da coluna da direita: nenhuma linha mexe em route-policy. A política de exportação é escrita uma vez, com um nó para cada ação possível, e o que muda no dia a dia é a etiqueta presa ao prefixo. É por isso que as BGP communities escalam: o trabalho cresce com o número de ações, que é pequeno e estável, e não com o produto de links por blocos.

A prefix-list não desaparece. Nas exportações deste guia todos os nós permit têm a EXPORTAVEIS (ou a BH-NOSSOS, nos nós de blackhole), além da community certa. Se alguém marcar por engano uma community de prepend numa rota aprendida de um trânsito, a lista barra o anúncio e você não vira trânsito entre dois upstreams.

A regra que resume a migração: prefix-list para filtrar, community para decidir. Qualquer nó de exportação que dependa só de community, sem conferir o prefixo, é um vazamento esperando o primeiro erro de digitação.

Cenário: três trânsitos e três PTTs do IX.br

O cenário é um provedor com AS 65550, uma borda Huawei NE8000, três trânsitos IP e sessões com os route servers de três localidades do IX.br. Todos os valores são fictícios e saem do mesmo arquivo de configuração que gera os comandos do post, então o que aparece nas tabelas bate com o que aparece nos blocos de CLI.

Cada link recebe um identificador de dois dígitos (o CC), que vai aparecer dentro das communities mais adiante. Trânsitos usam 01 a 03 e PTTs usam 11 a 13, o que deixa espaço para crescer sem renumerar nada:

CC	Link	Tipo	ASN do vizinho	IP de sessão	Local-pref	Faixa de communities	Community de blackhole
01	TRANSITO-A	Trânsito	AS 64510	198.18.1.1	100	64700:50100 a 64700:50167	64510:666
02	TRANSITO-B	Trânsito	AS 64511	198.18.2.1	100	64700:50200 a 64700:50267	64511:9999
03	TRANSITO-C	Trânsito	AS 64509	198.18.3.1	90	64700:50300 a 64700:50367	64509:666
11	IX-SP (localidade 011)	PTT (route server)	AS 26162	198.18.11.253	150	64700:51100 a 64700:51167	65535:666
12	IX-FORTALEZA (localidade 085)	PTT (route server)	AS 26162	198.18.12.253	150	64700:51200 a 64700:51267	65535:666
13	IX-MG (localidade 031)	PTT (route server)	AS 26162	198.18.13.253	150	64700:51300 a 64700:51367	65535:666

A local-preference segue a ordem de custo. Rotas de clientes BGP recebem 200, porque tráfego para cliente é receita; PTT recebe 150, porque é tráfego sem custo de trânsito; trânsito principal fica no padrão 100; e o TRANSITO-C, contratado como backup, recebe 90 para só ser usado quando a rota não existir pelos outros.

A última coluna mostra por que o sistema precisa de uma camada de tradução: cada vizinho tem o seu valor de descarte, e a tabela da seção de blackhole (RTBH) detalha todos. Na sua rede existe uma única community de descarte, a 64700:666, e cada política de exportação converte essa marca para a linguagem do vizinho. Com BGP communities próprias, você não decora o dialeto de cada operadora na hora do ataque.

Os blocos e endereços do cenário vêm todos de faixas reservadas para documentação:

Item	Valor no cenário	Faixa de origem
AS do provedor	65550	ASN de documentação (RFC 5398)
Namespace de communities	64700	ASN privado de 16 bits
Bloco próprio	203.0.113.0/24	TEST-NET-3 (RFC 5737)
Bloco do cliente BGP	198.51.100.0/24	TEST-NET-2 (RFC 5737)
Next-hop de descarte do RTBH	192.0.2.1/32 para NULL0	TEST-NET-1, padrão da RFC 5635
IPs de sessão com os vizinhos	198.18.x.x	Faixa de benchmark (RFC 2544)
Route servers do IX.br	AS 26162	ASN real do IX.br, o mesmo em todas as localidades

Os IPs de sessão da tabela são fictícios. Os endereços reais dos route servers de cada localidade vêm do IX.br no processo de ativação da porta, e cada localidade tem seu próprio par de route servers. O ASN 26162 é o mesmo em todas, então não use o ASN para distinguir São Paulo de Fortaleza nas políticas: use o nome do peer e a community de localidade.

A borda fala iBGP com um route reflector interno, que distribui para os concentradores as rotas aprendidas nos seis links. As communities precisam atravessar essa sessão, e o VRP8 só envia communities a um peer quando você configura advertise-community para ele; o Passo 1 trata disso. Se precisar relembrar a sintaxe básica de VRP, a lista de comandos para roteadores e switches Huawei cobre o essencial.

O mesmo NE8000 pode acumular outras funções. Se ele já entrega VPNs, como os circuitos da série sobre MPLS L2VC no Huawei, nada disso interfere: as políticas deste guia se aplicam só aos peers da família IPv4 unicast da internet e não tocam nas instâncias de VPN. Para IPv6 a lógica é a mesma, com listas ip ipv6-prefix equivalentes às prefix-lists IPv4 e as mesmas communities.

Desenhando o sistema de BGP communities do provedor

Um sistema de BGP communities é um dicionário fechado: cada valor tem um único significado, um dono e um lugar onde é aplicado. No cenário deste post tudo vive no namespace 64700, no formato 64700:5CCAA, em que CC identifica o link e AA identifica a ação. Sem esse desenho, as route-policies viram uma coleção de exceções.

É a situação de muita gente que começou a planejar a migração e parou no meio, a minha inclusive. O desenho abaixo parte dessa base e fecha as pontas que costumam ficar soltas.

Por que um namespace privado e não o próprio ASN

Como visto acima, 65550 não cabe na community standard. Escolhi 64700 (faixa privada 64512 a 65534) porque todo equipamento, looking glass e cliente entende communities padrão, e o suporte a large communities (RFC 8092) ainda varia entre roteadores de cliente e alguns trânsitos. O preço é que outra rede pode usar o mesmo número privado. Por isso as nossas BGP communities internas nunca saem para trânsitos e PTTs e nunca são aceitas de fora. A seção de large communities mostra o caminho equivalente com 65550:função:parâmetro.

Anatomia de uma community: 64700:5CCAA

O valor da direita é lido como cinco dígitos. O primeiro, 5, avisa que a community age sobre um link específico. Os dois seguintes são o código do link (01 a 03 para trânsitos, 11 a 13 para PTTs). Os dois últimos são a ação. Assim, 64700:50202 se lê como prepend 2x só no TRANSITO-B e 64700:51167 como não anunciar no IX-SP. No formato 5CCAA o maior valor é 59999, e as faixas de grupo (600xx e 601xx) também ficam abaixo de 65535.

A tabela abaixo é o sistema completo. Ela é gerada do mesmo arquivo que produz a configuração, então documentação e roteador não divergem. A coluna Quem aplica importa tanto quanto o significado: communities de origem são aplicadas só pela borda, e as de ação podem vir do NOC ou do cliente.

Community	Tipo	Significado	Quem aplica
`64700:10091`	Origem	Bloco próprio (203.0.113.0/24)	network com route-policy
`64700:10093`	Origem	Rota de cliente BGP	Import do cliente (CLIENTE-X-IN)
`64700:10094`	Origem	Rota de CDN interna	Import da sessão da CDN
`64700:5CC00`	Informativa	Rota aprendida no link CC	Import do link CC
`64700:5CC01` a `5CC03`	Ação por link	Prepend 1x, 2x ou 3x só no link CC	NOC ou cliente
`64700:5CC08`	Ação por link	Anunciar com NO_EXPORT no link CC	NOC ou cliente
`64700:5CC66`	Ação por link	Blackhole só no link CC	NOC
`64700:5CC67`	Ação por link	Não anunciar no link CC	NOC ou cliente
`64700:60001` a `60003`	Grupo trânsitos	Prepend 1x a 3x em todos os trânsitos	NOC ou cliente
`64700:60008`	Grupo trânsitos	Anunciar com NO_EXPORT em todos os trânsitos (nó 21 do export)	NOC ou cliente
`64700:60067`	Grupo trânsitos	Não anunciar em nenhum trânsito	NOC ou cliente
`64700:60101` a `60103`	Grupo PTTs	Prepend 1x a 3x em todos os PTTs	NOC ou cliente
`64700:60108`	Grupo PTTs	Anunciar com NO_EXPORT em todos os PTTs (nó 21 do export)	NOC ou cliente
`64700:60167`	Grupo PTTs	Não anunciar em nenhum PTT	NOC ou cliente
`64700:666`	Global	Blackhole (RTBH) em todos os links	NOC (estática com tag 666) ou a borda, ao traduzir o `65535:666` do cliente

As faixas de grupo existem para as ações repetitivas. Pedir prepend 2x em todos os trânsitos com uma única community (64700:60002) é mais simples do que marcar três valores, um por link, e o cliente que quer sair de todos os PTTs usa 64700:60167. Quando um link novo entra no grupo, ele passa a obedecer às communities do grupo sem que ninguém mude nada do lado do cliente.

Cadastro de links

Cada link recebe um código CC fixo, e esse código reserva uma faixa de cem valores. O código não muda quando o circuito troca de operadora: se o TRANSITO-A for substituído, o C01 continua sendo o link 01, e as BGP communities que os clientes já usam seguem valendo. Trânsitos ficam na dezena 0 e PTTs na dezena 1, o que deixa espaço para CDNs e bilaterais nas dezenas seguintes.

CC	Link	Faixa de communities
C01	TRANSITO-A	`64700:50100` a `50167`
C02	TRANSITO-B	`64700:50200` a `50267`
C03	TRANSITO-C	`64700:50300` a `50367`
C11	IX-SP	`64700:51100` a `51167`
C12	IX-FORTALEZA	`64700:51200` a `51267`
C13	IX-MG	`64700:51300` a `51367`

O local-pref de cada link também sai do cadastro. O teste do desenho é o link novo; no fim do Passo 4 você vê o TRANSITO-D inteiro saindo de uma linha do cadastro.

Regras de ouro do sistema

As communities internas (64700:*) nunca saem para trânsitos e PTTs, porque toda política de saída para eles apaga o namespace antes de anunciar.
Nenhuma community 64700:* vinda de trânsito, PTT, CDN ou cliente é aceita, porque toda política de entrada apaga o namespace antes de marcar a rota.
Cada valor fica documentado em um só lugar, e esse lugar gera a configuração e a página pública para clientes.
Um valor nunca muda de significado; se a ação mudar, cria-se um valor novo e o antigo é aposentado.

Atenção: sem a remoção do namespace na entrada, um cliente ou um vizinho de PTT pode mandar 64700:10091 ou 64700:666 e ganhar poderes de rota interna na sua borda, como ser exportado para todos os trânsitos ou disparar um blackhole. A linha apply comm-filter NS-INTERNO delete é a trava que impede isso.

Prefix-lists e community-filters

As prefix-lists continuam no desenho, com outro papel: deixam de escolher o que vai para cada link e passam a validar prefixos (bogons, blocos próprios, tamanho máximo, /32 de blackhole). EXPORTAVEIS vira a rede de segurança da saída, e BH-NOSSOS limita o blackhole a endereços nossos e dos clientes. Cada cliente BGP ganha duas listas só dele: CLIENTE-X-BLOCOS e CLIENTE-X-BH.

				
					ip ip-prefix MEUS-BLOCOS index 10 permit 203.0.113.0 24
ip ip-prefix CLIENTE-X-BLOCOS index 10 permit 198.51.100.0 24
ip ip-prefix CLIENTE-X-BH index 10 permit 198.51.100.0 24 greater-equal 32
ip ip-prefix EXPORTAVEIS index 10 permit 203.0.113.0 24
ip ip-prefix EXPORTAVEIS index 20 permit 198.51.100.0 24
ip ip-prefix BH-NOSSOS index 10 permit 203.0.113.0 24 greater-equal 32
ip ip-prefix BH-NOSSOS index 20 permit 198.51.100.0 24 greater-equal 32
ip ip-prefix NOSSOS-QUALQUER index 10 permit 203.0.113.0 24 less-equal 32
ip ip-prefix NOSSOS-QUALQUER index 20 permit 198.51.100.0 24 less-equal 32
ip ip-prefix BOGONS index 10 permit 0.0.0.0 8 less-equal 32
ip ip-prefix BOGONS index 20 permit 10.0.0.0 8 less-equal 32
ip ip-prefix BOGONS index 30 permit 100.64.0.0 10 less-equal 32
ip ip-prefix BOGONS index 40 permit 127.0.0.0 8 less-equal 32
ip ip-prefix BOGONS index 50 permit 169.254.0.0 16 less-equal 32
ip ip-prefix BOGONS index 60 permit 172.16.0.0 12 less-equal 32
ip ip-prefix BOGONS index 70 permit 192.168.0.0 16 less-equal 32
ip ip-prefix BOGONS index 80 permit 224.0.0.0 3 less-equal 32
ip ip-prefix MAIS-ESPECIFICAS index 10 permit 0.0.0.0 0 greater-equal 25
ip ip-prefix BH-32 index 10 permit 0.0.0.0 0 greater-equal 32
commit

A lista BOGONS está resumida porque o cenário usa faixas de documentação; em produção inclua também 192.0.0.0/24, 192.0.2.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24 e, se não quiser rota default, 0.0.0.0/0.

Os community-filters dão nome às BGP communities do dicionário, e as route-policies passam a testar nomes como L01-P2 em vez de números soltos. O bloco é longo porque cria um filtro por ação e por link; no roteador ele entra uma vez e não se mexe mais.

				
					ip community-filter basic ORIGEM-LOCAL index 10 permit 64700:10091
ip community-filter basic ORIGEM-CLIENTES index 10 permit 64700:10093
ip community-filter basic ORIGEM-CDN index 10 permit 64700:10094
ip community-filter basic ORIGEM-EXPORTAVEL index 10 permit 64700:10091
ip community-filter basic ORIGEM-EXPORTAVEL index 20 permit 64700:10093
ip community-filter basic BLACKHOLE-GLOBAL index 10 permit 64700:666
ip community-filter basic BH-RFC7999 index 10 permit 65535:666
ip community-filter basic IXBR-BH-CONFIRMADO index 10 permit 26162:666
ip community-filter advanced NS-INTERNO index 10 permit ^64700:
ip community-filter basic TRANSITOS-P1 index 10 permit 64700:60001
ip community-filter basic TRANSITOS-P2 index 10 permit 64700:60002
ip community-filter basic TRANSITOS-P3 index 10 permit 64700:60003
ip community-filter basic TRANSITOS-NOEXPORT index 10 permit 64700:60008
ip community-filter basic TRANSITOS-BLOQUEIO index 10 permit 64700:60067
ip community-filter basic PTTS-P1 index 10 permit 64700:60101
ip community-filter basic PTTS-P2 index 10 permit 64700:60102
ip community-filter basic PTTS-P3 index 10 permit 64700:60103
ip community-filter basic PTTS-NOEXPORT index 10 permit 64700:60108
ip community-filter basic PTTS-BLOQUEIO index 10 permit 64700:60167
ip community-filter basic L01-RECEBIDA index 10 permit 64700:50100
ip community-filter basic L01-P1 index 10 permit 64700:50101
ip community-filter basic L01-P2 index 10 permit 64700:50102
ip community-filter basic L01-P3 index 10 permit 64700:50103
ip community-filter basic L01-NOEXPORT index 10 permit 64700:50108
ip community-filter basic L01-BLACKHOLE index 10 permit 64700:50166
ip community-filter basic L01-BLOQUEIO index 10 permit 64700:50167
ip community-filter basic L02-RECEBIDA index 10 permit 64700:50200
ip community-filter basic L02-P1 index 10 permit 64700:50201
ip community-filter basic L02-P2 index 10 permit 64700:50202
ip community-filter basic L02-P3 index 10 permit 64700:50203
ip community-filter basic L02-NOEXPORT index 10 permit 64700:50208
ip community-filter basic L02-BLACKHOLE index 10 permit 64700:50266
ip community-filter basic L02-BLOQUEIO index 10 permit 64700:50267
ip community-filter basic L03-RECEBIDA index 10 permit 64700:50300
ip community-filter basic L03-P1 index 10 permit 64700:50301
ip community-filter basic L03-P2 index 10 permit 64700:50302
ip community-filter basic L03-P3 index 10 permit 64700:50303
ip community-filter basic L03-NOEXPORT index 10 permit 64700:50308
ip community-filter basic L03-BLACKHOLE index 10 permit 64700:50366
ip community-filter basic L03-BLOQUEIO index 10 permit 64700:50367
ip community-filter basic L11-RECEBIDA index 10 permit 64700:51100
ip community-filter basic L11-P1 index 10 permit 64700:51101
ip community-filter basic L11-P2 index 10 permit 64700:51102
ip community-filter basic L11-P3 index 10 permit 64700:51103
ip community-filter basic L11-NOEXPORT index 10 permit 64700:51108
ip community-filter basic L11-BLACKHOLE index 10 permit 64700:51166
ip community-filter basic L11-BLOQUEIO index 10 permit 64700:51167
ip community-filter basic L12-RECEBIDA index 10 permit 64700:51200
ip community-filter basic L12-P1 index 10 permit 64700:51201
ip community-filter basic L12-P2 index 10 permit 64700:51202
ip community-filter basic L12-P3 index 10 permit 64700:51203
ip community-filter basic L12-NOEXPORT index 10 permit 64700:51208
ip community-filter basic L12-BLACKHOLE index 10 permit 64700:51266
ip community-filter basic L12-BLOQUEIO index 10 permit 64700:51267
ip community-filter basic L13-RECEBIDA index 10 permit 64700:51300
ip community-filter basic L13-P1 index 10 permit 64700:51301
ip community-filter basic L13-P2 index 10 permit 64700:51302
ip community-filter basic L13-P3 index 10 permit 64700:51303
ip community-filter basic L13-NOEXPORT index 10 permit 64700:51308
ip community-filter basic L13-BLACKHOLE index 10 permit 64700:51366
ip community-filter basic L13-BLOQUEIO index 10 permit 64700:51367
commit

Tipo	Como casa	Exemplo	Uso no sistema
basic	Valor exato. Vários índices no mesmo filtro funcionam como OU.	`ORIGEM-EXPORTAVEL`, índices 10 (64700:10091) e 20 (64700:10093)	Testar ações e origens específicas
advanced	Expressão regular aplicada ao texto da community.	`NS-INTERNO` com `^64700:`	Apagar o namespace inteiro de uma vez

A regex ^64700: casa com qualquer community que comece com 64700 seguido de dois pontos, ou seja, todo o namespace, de 64700:0 a 64700:65535. O circunflexo ancora no início e os dois pontos fecham o número: uma regex só com 64700 casaria também com 65000:64700, que pertence a outra rede. Usada com apply comm-filter NS-INTERNO delete, ela remove só as nossas e preserva as communities do trânsito e do IX.br.

Crie prefix-lists e community-filters antes de ligar as políticas aos peers e confira os nomes com display ip ip-prefix: um if-match ip-prefix que aponta para uma lista inexistente pode casar com tudo, conforme a versão; teste em laboratório.

Passo 1: marcar a origem das rotas

O primeiro uso das BGP communities é marcar a origem da rota no momento em que ela entra no BGP: 64700:10091 para os blocos próprios e 64700:10093 para as rotas de clientes. A exportação dos passos seguintes só anuncia rotas que carregam uma dessas marcas, o que impede vazar rota de trânsito para outro trânsito.

				
					route-policy ORIGEM-LOCAL permit node 10
 if-match ip-prefix MEUS-BLOCOS
 apply community 64700:10091 additive
 quit
route-policy ORIGEM-LOCAL deny node 100
 quit
route-policy CLIENTE-X-IN permit node 5
 if-match community-filter BH-RFC7999
 if-match ip-prefix CLIENTE-X-BH
 apply comm-filter NS-INTERNO delete
 apply community 64700:666 additive
 apply local-preference 200
 quit
route-policy CLIENTE-X-IN permit node 10
 if-match ip-prefix CLIENTE-X-BLOCOS
 apply comm-filter NS-INTERNO delete
 apply community 64700:10093 additive
 apply local-preference 200
 quit
route-policy CLIENTE-X-IN deny node 100
 quit
bgp 65550
 ipv4-family unicast
  network 203.0.113.0 255.255.255.0 route-policy ORIGEM-LOCAL
  quit
 quit
commit

O bloco próprio entra pelo comando network com route-policy ORIGEM-LOCAL. O network exige a rota exata na tabela, normalmente ip route-static 203.0.113.0 24 NULL0. A política confere se o prefixo está em MEUS-BLOCOS e aplica 64700:10091 com additive, que acrescenta a community sem apagar as outras. Sem additive, o apply community substitui a lista inteira, e o sintoma costuma ser uma marca de blackhole que some no meio do caminho.

A marca de origem é o que separa este modelo do anterior. Com prefix-list, a política de saída perguntava este prefixo está na lista?; com BGP communities, pergunta de onde esta rota veio?. Uma rota aprendida no TRANSITO-B não tem marca de origem e, por isso, não sai para o TRANSITO-A, mesmo que alguém erre uma prefix-list.

Uma política por cliente

Cada cliente tem a sua cópia (CLIENTE-X-IN) com uma prefix-list só dos blocos dele (CLIENTE-X-BLOCOS); uma lista compartilhada deixa um cliente anunciar o bloco de outro. O nó 10 apaga qualquer community do nosso namespace que o cliente tenha mandado, marca 64700:10093 e sobe o local-pref para 200. O nó 100 nega o que sobrou, então um prefixo alheio fica de fora.

O nó 5 trata o blackhole pedido pelo cliente. Ele manda o valor padrão 65535:666 da RFC 7999, e o nó só casa se a rota também for um /32 dentro do bloco dele (CLIENTE-X-BH). Nesse caso a borda apaga o namespace e traduz o pedido para 64700:666, que as políticas de saída já sabem converter no blackhole de cada vizinho. Um 65535:666 em qualquer outro prefixo não casa no nó 5 e segue para os nós seguintes como rota comum.

A sessão do cliente liga a política no import, envia communities e limita a quantidade de prefixos com route-limit, para que um erro de configuração do lado dele não despeje uma tabela inteira na sua borda:

				
					bgp 65550
 peer 198.18.50.1 as-number 64505
 peer 198.18.50.1 description CLIENTE-X
 ipv4-family unicast
  peer 198.18.50.1 enable
  peer 198.18.50.1 route-policy CLIENTE-X-IN import
  peer 198.18.50.1 advertise-community
  peer 198.18.50.1 route-limit 300 alert-only
  quit
 quit
commit

Dimensione o limite para os blocos mais os /32 de blackhole que o cliente pode mandar num ataque; com alert-only a sessão não cai, só gera alarme (confirme a palavra-chave com ?).

Para o cliente, a borda envia as communities informativas de propósito (são as do guia). O que ele recebe, tabela completa ou só default, é decisão sua; se não quiser expor o namespace, aplique no export do cliente o mesmo apply comm-filter NS-INTERNO delete.

Essa versão é restritiva de propósito. As communities de ação que o cliente poderá usar (prepend, não anunciar em um link) também estão no namespace e são apagadas no nó 10. Quando você publicar o guia para clientes, o nó passa a apagar só as de origem e a deixar passar a faixa de ação; o blackhole continua entrando só como 65535:666, traduzido pelo nó 5. Começar fechado e abrir depois é mais seguro do que o contrário.

A sessão da CDN interna segue a mesma lógica: o import dela também apaga o namespace antes de marcar 64700:10094.

Levando as communities para o iBGP

O VRP não envia BGP communities para nenhum vizinho, interno ou externo, sem o comando peer X advertise-community. Sem ele, o route reflector repassa a rota sem a marca e as políticas de exportação a descartam. Configure em toda sessão iBGP:

				
					bgp 65550
 peer 10.99.255.2 as-number 65550
 peer 10.99.255.2 connect-interface LoopBack0
 ipv4-family unicast
  peer 10.99.255.2 enable
  peer 10.99.255.2 advertise-community
  quit
 quit
commit

Na outra ponta da sessão, o bloco próprio aparece com a marca de origem. Saída esperada em laboratório, olhando do route reflector:

<RR>display bgp routing-table 203.0.113.0 24

 BGP local router ID : 10.99.255.2
 Local AS number : 65550
 Paths:   1 available, 1 best, 1 select, 0 best-external, 0 add-path
 BGP routing table entry information of 203.0.113.0/24:
 From: 10.99.255.1 (10.99.255.1)
 Route Duration: 0d01h12m40s
 Relay IP Nexthop: 10.99.0.1
 Relay IP Out-Interface: GigabitEthernet0/1/1
 Original nexthop: 10.99.255.1
 Qos information : 0x0
 Community: <64700:10091>
 AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal,
 best, select, active, pre 255
 Not advertised to any peer yet

A linha Community: <64700:10091> é a prova de que a marca atravessou o iBGP. AS-path Nil e internal confirmam que a rota nasceu dentro do AS. Se a linha de community não aparecer, falta o advertise-community em algum salto, e os passos de exportação vão descartar a rota em silêncio.

Comando	Função
`network ... route-policy ORIGEM-LOCAL`	Injeta o bloco próprio no BGP já marcado
`apply community 64700:10091 additive`	Acrescenta a marca sem apagar as existentes
`apply comm-filter NS-INTERNO delete`	Apaga do vizinho qualquer valor do nosso namespace
`CLIENTE-X-IN` nó 5	Traduz o `65535:666` do cliente em `64700:666`, só para /32 do bloco dele
`apply local-preference 200`	Faz a rota de cliente vencer PTT e trânsito
`deny node 100`	Descarta o que não casou nos nós anteriores
`peer X route-limit`	Alarma (com alert-only) quando o cliente passa do limite de prefixos
`peer X advertise-community`	Libera o envio de communities para o vizinho

Resultado: toda rota que nasce na sua rede ou chega de um cliente já carrega a marca de origem (64700:10091 ou 64700:10093), e essa marca chega a todas as bordas pelo iBGP.

Passo 2: filtrar e marcar o que chega de cada link

A política de entrada de cada link descarta o que não deve entrar (bogons, nossos próprios blocos, prefixos mais longos que /24), apaga as BGP communities do nosso namespace e marca a rota com 64700:5CC00 e o local-pref do link. Todo link usa os mesmos nós; só o PTT ganha um nó extra para o blackhole confirmado pelo IX.br.

Política do TRANSITO-A (C01):

				
					route-policy IMPORT-TRANSITO-A deny node 10
 if-match ip-prefix BOGONS
 quit
route-policy IMPORT-TRANSITO-A deny node 20
 if-match ip-prefix NOSSOS-QUALQUER
 quit
route-policy IMPORT-TRANSITO-A deny node 40
 if-match ip-prefix MAIS-ESPECIFICAS
 quit
route-policy IMPORT-TRANSITO-A permit node 90
 apply comm-filter NS-INTERNO delete
 apply community 64700:50100 additive
 apply local-preference 100
 quit
commit

Política do IX-SP (C11), com o nó 30 a mais:

				
					route-policy IMPORT-IX-SP deny node 10
 if-match ip-prefix BOGONS
 quit
route-policy IMPORT-IX-SP deny node 20
 if-match ip-prefix NOSSOS-QUALQUER
 quit
route-policy IMPORT-IX-SP permit node 30
 if-match community-filter IXBR-BH-CONFIRMADO
 if-match ip-prefix BH-32
 apply comm-filter NS-INTERNO delete
 quit
route-policy IMPORT-IX-SP deny node 40
 if-match ip-prefix MAIS-ESPECIFICAS
 quit
route-policy IMPORT-IX-SP permit node 90
 apply comm-filter NS-INTERNO delete
 apply community 64700:51100 additive
 apply local-preference 150
 quit
commit

Nó	Ação	Condição	Por quê
10	deny	Prefixo em `BOGONS`	Espaço privado, reservado ou multicast nunca entra
20	deny	Prefixo em `NOSSOS-QUALQUER`	Ninguém de fora anuncia nossos blocos nem pedaços deles (sequestro ou loop)
30 (só PTT)	permit	`26162:666` e prefixo /32	Blackhole confirmado pelo route server do IX.br
40	deny	Prefixo em `MAIS-ESPECIFICAS` (/25 a /32)	Protege a FIB de desagregação e lixo
90	permit	Todo o resto	Apaga `64700:*`, marca `64700:5CC00` e aplica o local-pref do link

Se o cliente tiver outro upstream, tire o bloco dele da NOSSOS-QUALQUER: com o local-pref 200 a sessão direta continua vencendo, e se ela cair a sua rede ainda alcança o cliente pelos trânsitos.

No VRP, a route-policy é avaliada nó a nó, do menor número para o maior, e para no primeiro nó que casa. Dentro de um nó, as várias linhas if-match são combinadas com E: o nó 30 só casa quando a rota traz a community do IX.br e também é um /32. Uma rota que não casa em nenhum nó é negada.

A ordem dos nós é o ponto sensível. O nó 30 precisa vir antes do 40, senão o /32 de blackhole cairia no filtro de mais específicas e seria descartado. E o nó 20 vem antes do 30 de propósito: um /32 dentro dos nossos blocos, mesmo com 26162:666, é recusado, porque blackhole de prefixo nosso só nasce aqui dentro. Pela política de communities do IX.br v4.3, a community 26162:666 é colocada pelo route server depois de validar o anúncio de blackhole do participante.

O nó 90 não tem if-match, então casa com tudo o que sobrou e aplica o local-pref do cadastro. O /32 aceito pelo nó 30 já chega com o next-hop de descarte do PTT, trocado pelo route server; basta aceitar a rota, sem apply ip-address next-hop.

Por que a prefix-list continua na entrada

Community é uma etiqueta que o vizinho escolhe colocar, e na entrada ela não vale como prova de nada. Quem decide se um prefixo pode entrar é o próprio prefixo: tamanho, faixa e dono. Por isso a entrada segue baseada em prefix-list, e as BGP communities aparecem só como marca que nós mesmos aplicamos depois do filtro. As únicas communities externas em que as políticas confiam são 26162:666, do route server, e 65535:666, do cliente, e ambas só junto com uma prefix-list de /32.

Na saída a lógica se inverte: a decisão passa a ser da community, e a prefix-list EXPORTAVEIS fica como rede de segurança em todos os nós, para o caso de alguém marcar a rota errada.

Conferindo a marca de entrada

Uma rota aprendida no TRANSITO-A deve chegar com as communities do próprio trânsito, preservadas pelo additive, mais a nossa 64700:50100. No exemplo, 198.18.100.0/24 representa um prefixo qualquer da internet (saída esperada em laboratório):

<BORDA-01>display bgp routing-table 198.18.100.0 24

 BGP local router ID : 10.99.255.1
 Local AS number : 65550
 Paths:   1 available, 1 best, 1 select, 0 best-external, 0 add-path
 BGP routing table entry information of 198.18.100.0/24:
 From: 198.18.1.1 (198.18.1.1)
 Route Duration: 0d03h41m07s
 Direct Out-interface: GigabitEthernet0/1/0
 Original nexthop: 198.18.1.1
 Qos information : 0x0
 Community: <64510:2011>, <64700:50100>
 AS-path 64510 64500, origin igp, MED 0, localpref 100, pref-val 0, valid, external,
 best, select, active, pre 255
 Advertised to such 1 peers:
    10.99.255.2

A leitura é direta. <64510:2011> é uma community informativa do trânsito (no exemplo, a localidade onde ele aprendeu a rota), mantida porque o nó 90 usa additive. <64700:50100> diz que a rota entrou pelo link C01, e o localpref 100 veio do cadastro do link. Se aparecer qualquer outro valor do namespace 64700 nessa linha, o delete do nó 90 não está funcionando.

O desenho depende de o VRP executar o apply comm-filter delete antes do apply community no mesmo nó, como descreve a documentação da Huawei. A fase 1 do plano confirma isso: se a 64700:5CC00 ou a 64700:10093 não aparecer na rota, pare antes de seguir.

Com as BGP communities de entrada no lugar, filtrar a tabela por origem vira um comando só: display bgp routing-table community 64700:51100 lista tudo o que veio do IX-SP. Na política por prefix-list, responder a mesma pergunta exigia cruzar o next-hop com a lista de peers.

Resultado: nada indevido entra pela borda, nenhuma community 64700:* de fora sobrevive, e cada rota aprendida carrega o link de entrada (64700:5CC00) e o local-pref da sua classe.

Passo 3: exportar para os trânsitos por community

Exportar para trânsito com BGP communities significa ter uma route-policy por link em que cada nó lê uma community e executa uma ação: blackhole, bloqueio, no-export, prepend ou anúncio padrão. O prefixo só sai se tiver a origem certa e também estiver na prefix-list EXPORTAVEIS, a dupla trava contra vazamento.

Abaixo está a política do TRANSITO-A (link C01, AS 64510); os outros trânsitos trocam só o id do link e a community de blackhole. É aqui que o dicionário começa a mudar o que sai da borda.

				
					route-policy EXPORT-TRANSITO-A permit node 5
 if-match community-filter BLACKHOLE-GLOBAL
 if-match ip-prefix BH-NOSSOS
 apply comm-filter NS-INTERNO delete
 apply community 64510:666 no-export additive
 quit
route-policy EXPORT-TRANSITO-A permit node 6
 if-match community-filter L01-BLACKHOLE
 if-match ip-prefix BH-NOSSOS
 apply comm-filter NS-INTERNO delete
 apply community 64510:666 no-export additive
 quit
route-policy EXPORT-TRANSITO-A deny node 10
 if-match community-filter L01-BLOQUEIO
 quit
route-policy EXPORT-TRANSITO-A deny node 11
 if-match community-filter TRANSITOS-BLOQUEIO
 quit
route-policy EXPORT-TRANSITO-A permit node 20
 if-match community-filter L01-NOEXPORT
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply community no-export additive
 quit
route-policy EXPORT-TRANSITO-A permit node 21
 if-match community-filter TRANSITOS-NOEXPORT
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply community no-export additive
 quit
route-policy EXPORT-TRANSITO-A permit node 30
 if-match community-filter L01-P3
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 65550 65550 additive
 quit
route-policy EXPORT-TRANSITO-A permit node 31
 if-match community-filter TRANSITOS-P3
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 65550 65550 additive
 quit
route-policy EXPORT-TRANSITO-A permit node 40
 if-match community-filter L01-P2
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 65550 additive
 quit
route-policy EXPORT-TRANSITO-A permit node 41
 if-match community-filter TRANSITOS-P2
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 65550 additive
 quit
route-policy EXPORT-TRANSITO-A permit node 50
 if-match community-filter L01-P1
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 additive
 quit
route-policy EXPORT-TRANSITO-A permit node 51
 if-match community-filter TRANSITOS-P1
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 additive
 quit
route-policy EXPORT-TRANSITO-A permit node 90
 if-match community-filter ORIGEM-EXPORTAVEL
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 quit
route-policy EXPORT-TRANSITO-A deny node 100
 quit
commit

Como na entrada, vence o primeiro nó que casa: cada prefixo recebe uma única ação por link. Com 64700:50108 e 64700:50102 no mesmo prefixo, vale o no-export do nó 20 e o prepend não é aplicado.

Os prepends ficam em dezenas separadas: 30 e 31 para três repetições, 40 e 41 para duas, 50 e 51 para uma. O primeiro nó de cada dezena é o do link, o segundo é o do grupo. Isso faz o prepend maior vencer o menor e o pedido específico do link vencer o do grupo, e deixa espaço livre (32 a 39, 42 a 49) para uma ação nova sem renumerar a política.

Nó	Casa com	Ação	Uso
5	64700:666 + BH-NOSSOS	permit, sai com 64510:666 e no-export	Blackhole em todos os links
6	64700:50166 + BH-NOSSOS	igual ao nó 5	Blackhole só no TRANSITO-A
10	64700:50167	deny	Não anunciar neste link
11	64700:60067	deny	Não anunciar em nenhum trânsito
20	64700:50108 + EXPORTAVEIS	permit com no-export	No-export só no TRANSITO-A
21	64700:60008 + EXPORTAVEIS	permit com no-export	No-export em todos os trânsitos
30 / 31	64700:50103 ou 64700:60003 + EXPORTAVEIS	prepend 3x (65550 65550 65550)	Link C01 (30) ou grupo TRÂNSITOS (31)
40 / 41	64700:50102 ou 64700:60002 + EXPORTAVEIS	prepend 2x (65550 65550)	Link C01 (40) ou grupo TRÂNSITOS (41)
50 / 51	64700:50101 ou 64700:60001 + EXPORTAVEIS	prepend 1x (65550)	Link C01 (50) ou grupo TRÂNSITOS (51)
90	ORIGEM-EXPORTAVEL (64700:10091 ou 64700:10093) + EXPORTAVEIS	permit sem alteração	Anúncio padrão
100	qualquer rota	deny	O que não foi marcado fica em casa

O no-export dos nós 20 e 21 faz o trânsito usar a rota sem repassá-la aos vizinhos dele. O nó 20 atende o pedido de um link só; o nó 21 atende o grupo inteiro com uma community, 64700:60008, útil quando você quer que todo o tráfego de trânsito para um bloco entre por clientes diretos das operadoras.

Todos os nós que deixam a rota sair apagam o namespace interno com apply comm-filter NS-INTERNO delete. O filtro advanced casa ^64700:, então as BGP communities internas não chegam à operadora. Sobra no anúncio só o que o vizinho precisa ler: no-export ou a community de blackhole dele.

Por que limpar as communities antes de exportar

Communities são transitivas: se a sua borda manda, elas seguem com a rota para o trânsito e, muitas vezes, para os vizinhos dele. O trânsito só age sobre valores que ele mesmo definiu e sobre as well-known. As suas 64700:* não fazem nada lá fora, mas expõem o desenho interno e podem colidir com o espaço de ação de outra rede. Por isso a regra é limpar as internas e mandar só o que o vizinho documentou.

Pode sair para o trânsito ou PTT	Não deve sair
Well-known que você quer que o vizinho aplique: no-export, graceful shutdown (65535:0)	As communities internas do seu namespace (64700:*)
Communities de ação publicadas pela operadora: blackhole, prepend por região, não anunciar a um peer	Communities informativas que você recebeu de outro trânsito ou PTT
Communities de ação do route server do IX.br, só na sessão com o RS	Communities de ação de uma operadora mandadas para outra

No Huawei há um detalhe que ajuda e atrapalha: sem peer ... advertise-community o VRP não envia nenhuma community ao vizinho. É o jeito mais simples de não vazar nada, mas também impede o blackhole da operadora e o no-export de funcionar. Como o sistema precisa mandar esses valores, o advertise-community fica ligado e a limpeza passa a ser feita nos nós da política.

Sobra uma decisão: as communities que um cliente BGP manda, fora do seu namespace, seguem para o trânsito. Isso é útil se você quer que o cliente use as communities de ação da operadora. Se não quer, use a versão estrita: troque o delete por apply community none no nó 90 e, nos nós de blackhole, use apply community sem additive, que substitui tudo pelo valor da operadora mais o no-export.

Basic e advanced não têm relação com extended communities. No Huawei, ip community-filter basic lista valores exatos e advanced usa expressão regular, e os dois tratam communities standard. Extended communities (route target, SoO) são outro atributo, com filtro próprio (ip extcommunity-filter), e não entram neste sistema. Se o seu equipamento não aceitar o filtro advanced, liste o namespace num filtro basic, um índice por valor.

Na dupla trava do nó 90, a community diz a intenção e a prefix-list diz o limite. Se um erro colocar 64700:10091 numa rota da tabela completa, a prefix-list barra. Se alguém esquecer de marcar um bloco novo, ele não sai, e isso aparece no primeiro teste em vez de virar vazamento.

Como no Passo 1, sem advertise-community o 64510:666 e o no-export não chegam à operadora. Os endereços 198.18.x.x são da faixa de benchmark; use os da sua sessão.

				
					bgp 65550
 peer 198.18.1.1 as-number 64510
 peer 198.18.1.1 description TRANSITO-A
 ipv4-family unicast
  peer 198.18.1.1 enable
  peer 198.18.1.1 route-policy IMPORT-TRANSITO-A import
  peer 198.18.1.1 route-policy EXPORT-TRANSITO-A export
  peer 198.18.1.1 advertise-community
  quit
 quit
commit

Exemplo de operação: prepend 2x só no TRANSITO-A

Com a política no ar, a engenharia de tráfego com BGP communities deixa de ser edição de export. Para fazer prepend de duas vezes só no TRANSITO-A, acrescente 64700:50102 ao prefixo na origem. No cenário, a linha de apply do nó 10 da ORIGEM-LOCAL vira apply community 64700:10091 64700:50102 additive. O nó 40 da EXPORT-TRANSITO-A passa a casar e os outros cinco links não mudam.

As duas communities vão na mesma linha porque um segundo apply community no mesmo nó substitui o primeiro, e o prefixo perderia a marca de origem. Confira com display route-policy ORIGEM-LOCAL e depois nas rotas anunciadas ao 198.18.1.1.

O prepend vale por prefixo marcado, e não para o AS inteiro. Se a borda anuncia quatro /24 e só um precisa de prepend, crie um nó na ORIGEM-LOCAL, antes do nó 10, com uma prefix-list daquele bloco e as duas communities. Os outros três continuam saindo sem prepend. No modelo de prefix-list por link, a mesma mudança exigiria mexer na export de cada link afetado.

Rotas que chegam por iBGP ou de um cliente BGP são marcadas na política de entrada daquele ponto. A CLIENTE-X-IN hoje apaga o namespace do cliente; quando você liberar communities de ação para clientes, é ali que um 64700:50102 passaria a ser preservado. Para desfazer o prepend, tire a community e a rota volta ao nó 90.

Resultado: cada trânsito recebe só os blocos marcados e autorizados, com prepend, no-export ou blackhole decididos pelas BGP communities do prefixo e não por uma política escrita à mão para cada link.

Passo 4: exportar para os PTTs do IX.br

A exportação para o IX.br usa o mesmo molde dos trânsitos, com duas diferenças: a community de blackhole é a 65535:666 que o route server entende, e as ações que você quer que o próprio IX.br execute, como não anunciar a um ASN ou fazer prepend para ele, são communities do route server (AS 26162) publicadas na política v4.3.

				
					route-policy EXPORT-IX-SP permit node 5
 if-match community-filter BLACKHOLE-GLOBAL
 if-match ip-prefix BH-NOSSOS
 apply comm-filter NS-INTERNO delete
 apply community 65535:666 no-export additive
 quit
route-policy EXPORT-IX-SP permit node 6
 if-match community-filter L11-BLACKHOLE
 if-match ip-prefix BH-NOSSOS
 apply comm-filter NS-INTERNO delete
 apply community 65535:666 no-export additive
 quit
route-policy EXPORT-IX-SP deny node 10
 if-match community-filter L11-BLOQUEIO
 quit
route-policy EXPORT-IX-SP deny node 11
 if-match community-filter PTTS-BLOQUEIO
 quit
route-policy EXPORT-IX-SP permit node 20
 if-match community-filter L11-NOEXPORT
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply community no-export additive
 quit
route-policy EXPORT-IX-SP permit node 21
 if-match community-filter PTTS-NOEXPORT
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply community no-export additive
 quit
route-policy EXPORT-IX-SP permit node 30
 if-match community-filter L11-P3
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 65550 65550 additive
 quit
route-policy EXPORT-IX-SP permit node 31
 if-match community-filter PTTS-P3
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 65550 65550 additive
 quit
route-policy EXPORT-IX-SP permit node 40
 if-match community-filter L11-P2
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 65550 additive
 quit
route-policy EXPORT-IX-SP permit node 41
 if-match community-filter PTTS-P2
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 65550 additive
 quit
route-policy EXPORT-IX-SP permit node 50
 if-match community-filter L11-P1
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 additive
 quit
route-policy EXPORT-IX-SP permit node 51
 if-match community-filter PTTS-P1
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 additive
 quit
route-policy EXPORT-IX-SP permit node 90
 if-match community-filter ORIGEM-EXPORTAVEL
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 quit
route-policy EXPORT-IX-SP deny node 100
 quit
commit

A leitura nó a nó é a mesma do Passo 3. O nó 11 consulta 64700:60167, o grupo PTTs, em vez do grupo de trânsitos; o nó 21 usa 64700:60108 para no-export em todos os PTTs, e os prepends de grupo usam 64700:60101 a 64700:60103. Um único 64700:60167 tira o prefixo de todos os PTTs sem encostar nos trânsitos, útil quando um bloco só deve ser alcançado pela rota paga.

				
					bgp 65550
 peer 198.18.11.253 as-number 26162
 peer 198.18.11.253 description IX-SP
 ipv4-family unicast
  peer 198.18.11.253 enable
  peer 198.18.11.253 route-policy IMPORT-IX-SP import
  peer 198.18.11.253 route-policy EXPORT-IX-SP export
  peer 198.18.11.253 advertise-community
  quit
 quit
commit

A sessão fecha com o route server, AS 26162, e é por BGP communities que você conversa com ele. Sem advertise-community, qualquer 65000:ASN ou 65535:666 aplicado no export some no caminho.

Communities de ação do route server do IX.br

Os valores abaixo são da Política de tratamento de communities no IX.br, versão 4.3 (22/06/2021). ASN é o participante de destino, e 26162 é o ASN do route server. XXX é o código da localidade, quase sempre o DDD: São Paulo 011, Fortaleza 085, Belo Horizonte 031. O documento cita duas exceções, Campina Grande (183) e Cascavel (145).

Community	Função	Observação
65000:ASN	Não anunciar ao ASN indicado	Ex.: 65000:64496
65001:ASN	Anunciar só ao ASN indicado	Os demais participantes não recebem
64601:ASN / 64602:ASN / 64603:ASN	Prepend de 1, 2 ou 3 vezes para o ASN indicado	O RS faz o prepend só para aquele ASN
65535:0	Graceful shutdown (RFC 8326)	Antes de manutenção na sessão
65535:666	Anúncio de blackhole	Só /32 IPv4 e /128 IPv6, origem validada; large 65535:616:666
26162:666	Blackhole confirmado pelo RS	Aceite o /32 ou /128 que chegar com ela
26162:65XXX	Informativa: PTT de origem do anúncio	Ex.: 26162:65011 para São Paulo
65004:65XXX (tabela) ou 65006:65XXX (texto)	Não anunciar na localidade XXX	O próprio documento diverge: confira

A última linha pede cuidado. A tabela do documento v4.3 lista do not announce to IXP como 65004:65XXX, mas o exemplo no corpo do texto usa 65006:65011 para não anunciar aos participantes de São Paulo. Não é a única divergência: o corpo do texto também usa 65004:0 para not announce to Brazil, enquanto a tabela usa 65002:5 para essa função e reserva 65004 para localidade.

Antes de usar qualquer uma dessas ações, confira a tabela atual da localidade em ix.br/doc e valide o efeito olhando o seu prefixo no looking glass do PTT depois da mudança.

O blackhole no IX.br tem regras próprias. O RS aceita 65535:666 só em /32 e /128 e valida a origem: ASN brasileiro com o bloco conferido no whois do registro.br, ou anúncio stub do ASN conectado para prefixo dele. Aceito o pedido, o RS troca o next-hop por um endereço de descarte no PTT e acrescenta 26162:666. Os participantes precisam aceitar /32 com essa community, como faz o nó 30 das políticas IMPORT-IX-* do Passo 2.

Antes de confiar no blackhole via PTT, confira no looking glass do IX.br se o /32 com 65535:666 e no-export aparece para os outros participantes. Se não aparecer, tire o no-export dos nós 5 e 6 das exports de PTT: o RS devolve a rota com 26162:666 e cada participante a mantém local.

Pedir ao route server para não anunciar a um ASN

Suponha que o AS 64496 (fictício) receba seus prefixos pelo RS de SP e devolva tráfego por um caminho ruim. Há dois jeitos de resolver com BGP communities:

O direto é acrescentar apply community 65000:64496 additive no nó 90 da EXPORT-IX-SP. Ele vale só para os prefixos que saem pelo nó 90; um prefixo com prepend, no-export ou blackhole sai por outro nó e não leva o pedido.
O seletivo é criar uma ação nova no dicionário, por exemplo 64700:51170 (link 11, ação 70), marcá-la na origem dos prefixos afetados e incluir um nó 80 que case só essa community e a EXPORTAVEIS, apague o namespace interno e aplique 65000:64496. Dois if-match community-filter no mesmo nó não são um E confiável no VRP. Como o nó 80 vem depois dos prepends, um prefixo que também tenha community de prepend casa antes nos nós 30 a 51 e sai sem o 65000:64496.

Eu faria pelo segundo jeito, e manteria um prefixo com uma ação por vez. A regra fica no dicionário de BGP communities e o export continua sendo um tradutor: community interna entra, community do IX.br sai. O mesmo vale para 64601:ASN a 64603:ASN quando o problema é preferência e não bloqueio.

Vários PTTs: um export por localidade

Com três PTTs, o cenário tem EXPORT-IX-SP, EXPORT-IX-FORTALEZA e EXPORT-IX-MG geradas pela mesma função, mudando só o id do link (11, 12 e 13). O blackhole seletivo vira 64700:51166, 64700:51266 ou 64700:51366, e o bloqueio por PTT vira 64700:51167, 64700:51267 ou 64700:51367. Na entrada, as três importações aplicam local-preference 150, acima dos trânsitos, para a saída preferir o PTT.

Na minha borda, hoje só com o IX.br SP, o ganho aparece quando entrar a segunda localidade: com BGP communities é uma linha no cadastro de links e uma sessão nova. Com prefix-list, seria copiar a política de SP e revisar nó por nó.

Resultado: cada PTT recebe os mesmos blocos com as mesmas regras dos trânsitos, e as ações do route server do IX.br viram traduções no export, geradas do mesmo cadastro de links.

Cadastrando o 4º trânsito

O teste de um desenho é o link novo. No arquivo de cenário, cadastrar o TRANSITO-D é uma linha na lista de links: id 04, AS 64508, IP da sessão, local-pref e community de blackhole da operadora. Tudo o que está no bloco abaixo sai dessa linha: os filtros L04, a política de entrada, a de saída e o peer.

				
					ip community-filter basic L04-RECEBIDA index 10 permit 64700:50400
ip community-filter basic L04-P1 index 10 permit 64700:50401
ip community-filter basic L04-P2 index 10 permit 64700:50402
ip community-filter basic L04-P3 index 10 permit 64700:50403
ip community-filter basic L04-NOEXPORT index 10 permit 64700:50408
ip community-filter basic L04-BLACKHOLE index 10 permit 64700:50466
ip community-filter basic L04-BLOQUEIO index 10 permit 64700:50467
commit

route-policy IMPORT-TRANSITO-D deny node 10
 if-match ip-prefix BOGONS
 quit
route-policy IMPORT-TRANSITO-D deny node 20
 if-match ip-prefix NOSSOS-QUALQUER
 quit
route-policy IMPORT-TRANSITO-D deny node 40
 if-match ip-prefix MAIS-ESPECIFICAS
 quit
route-policy IMPORT-TRANSITO-D permit node 90
 apply comm-filter NS-INTERNO delete
 apply community 64700:50400 additive
 apply local-preference 100
 quit
commit

route-policy EXPORT-TRANSITO-D permit node 5
 if-match community-filter BLACKHOLE-GLOBAL
 if-match ip-prefix BH-NOSSOS
 apply comm-filter NS-INTERNO delete
 apply community 64508:666 no-export additive
 quit
route-policy EXPORT-TRANSITO-D permit node 6
 if-match community-filter L04-BLACKHOLE
 if-match ip-prefix BH-NOSSOS
 apply comm-filter NS-INTERNO delete
 apply community 64508:666 no-export additive
 quit
route-policy EXPORT-TRANSITO-D deny node 10
 if-match community-filter L04-BLOQUEIO
 quit
route-policy EXPORT-TRANSITO-D deny node 11
 if-match community-filter TRANSITOS-BLOQUEIO
 quit
route-policy EXPORT-TRANSITO-D permit node 20
 if-match community-filter L04-NOEXPORT
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply community no-export additive
 quit
route-policy EXPORT-TRANSITO-D permit node 21
 if-match community-filter TRANSITOS-NOEXPORT
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply community no-export additive
 quit
route-policy EXPORT-TRANSITO-D permit node 30
 if-match community-filter L04-P3
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 65550 65550 additive
 quit
route-policy EXPORT-TRANSITO-D permit node 31
 if-match community-filter TRANSITOS-P3
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 65550 65550 additive
 quit
route-policy EXPORT-TRANSITO-D permit node 40
 if-match community-filter L04-P2
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 65550 additive
 quit
route-policy EXPORT-TRANSITO-D permit node 41
 if-match community-filter TRANSITOS-P2
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 65550 additive
 quit
route-policy EXPORT-TRANSITO-D permit node 50
 if-match community-filter L04-P1
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 additive
 quit
route-policy EXPORT-TRANSITO-D permit node 51
 if-match community-filter TRANSITOS-P1
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 additive
 quit
route-policy EXPORT-TRANSITO-D permit node 90
 if-match community-filter ORIGEM-EXPORTAVEL
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 quit
route-policy EXPORT-TRANSITO-D deny node 100
 quit
commit

bgp 65550
 peer 198.18.4.1 as-number 64508
 peer 198.18.4.1 description TRANSITO-D
 ipv4-family unicast
  peer 198.18.4.1 enable
  peer 198.18.4.1 route-policy IMPORT-TRANSITO-D import
  peer 198.18.4.1 route-policy EXPORT-TRANSITO-D export
  peer 198.18.4.1 advertise-community
  quit
 quit
commit

O bloco prova que o sistema escala. A EXPORT-TRANSITO-D tem os mesmos nós da EXPORT-TRANSITO-A e muda só nos números do link; os grupos TRÂNSITOS (600xx) já valem para ela sem nenhuma linha nova. No modelo por prefix-list, cada link novo pedia uma política escrita à mão, com um nó por prefix-list e o prepend digitado no próprio nó.

Na revisão, isso muda a conversa. Em vez de comparar seis ou dez políticas diferentes, você confere que todas seguem o molde e olha só o cadastro. Os IPs em 198.18.x.x continuam sendo da faixa de benchmark; troque pelos reais.

Blackhole (RTBH) com BGP communities

RTBH (Remotely Triggered Black Hole) é o descarte, na rede do vizinho, do tráfego destinado a um IP sob ataque. Você anuncia o /32 atacado com a community de blackhole de cada operadora e do IX.br, e eles jogam o tráfego fora antes do seu link. Aquele IP fica fora do ar, mas o resto da rede deixa de sofrer com a saturação.

O mecanismo está descrito na RFC 5635, e a RFC 7999 reservou a community bem conhecida BLACKHOLE (65535:666) para padronizar o pedido. Na prática cada trânsito ainda publica o próprio valor. O sistema de BGP communities deste post resolve a diferença com uma única marca interna, 64700:666, que o export de cada link traduz.

Configuração da origem e do gatilho

A configuração tem duas partes. A primeira fica fixa na borda: a rota de descarte para 192.0.2.1 e a route-policy que transforma estáticas com tag 666 em anúncios BGP marcados.

				
					ip route-static 192.0.2.1 255.255.255.255 NULL0
route-policy RTBH-ORIGEM permit node 10
 if-match tag 666
 if-match ip-prefix BH-NOSSOS
 apply community 64700:666 additive
 quit
route-policy RTBH-ORIGEM deny node 100
 quit
bgp 65550
 ipv4-family unicast
  import-route static route-policy RTBH-ORIGEM
  quit
 quit
commit

O nó 10 da RTBH-ORIGEM exige tag 666 e a prefix-list BH-NOSSOS, que só aceita /32 dentro dos blocos autorizados; uma estática com tag 666 para IP de terceiro não vira anúncio. A rota entra no BGP só com a marca interna 64700:666, e o nó 100 impede que outras estáticas vazem pelo import-route.

Se a borda já tem import-route static, com ou sem política, junte os nós na mesma route-policy. O VRP aceita um só import-route static por família de endereços, e o comando novo substitui o antigo: a estática que era redistribuída antes deixaria de ser anunciada sem aviso.

Repare que a origem não aplica no-export, e isso é proposital. Uma rota que já carrega NO_EXPORT não é anunciada a vizinhos eBGP: se o /32 nascesse com essa community, ele circularia pelo iBGP e nunca sairia do AS, e o blackhole não chegaria a nenhuma operadora. Dentro do AS a marca 64700:666 basta para os roteadores reconhecerem o pedido.

O no-export entra no export, nos nós 5 e 6, junto com a community de blackhole do vizinho. Ali ele tem outro papel: o /32 já foi entregue à operadora, e o NO_EXPORT pede que ela não repasse esse anúncio aos vizinhos dela. O descarte fica restrito à rede de quem recebeu o pedido, e um /32 de blackhole não se espalha pela internet, como recomenda a RFC 7999.

A segunda parte é o gatilho, o único comando que o NOC digita durante o ataque:

				
					ip route-static 203.0.113.45 255.255.255.255 NULL0 tag 666
commit

Para desfazer, remova a mesma estática com undo ip route-static 203.0.113.45 255.255.255.255 NULL0 e faça commit. O anúncio é retirado de todos os vizinhos de uma vez, sem tocar em route-policy.

Do ataque ao descarte, passo a passo

O monitoramento de fluxo mostra 203.0.113.45 recebendo volume que satura os trânsitos.
O NOC cria a estática /32 para NULL0 com tag 666 e faz commit.
A RTBH-ORIGEM casa a tag e a BH-NOSSOS, e o /32 entra no BGP com 64700:666, sem no-export.
Os outros roteadores do AS recebem o /32 por iBGP. Neles, uma política de import do iBGP casa 64700:666 (if-match community-filter BLACKHOLE-GLOBAL) e aplica apply ip-address next-hop 192.0.2.1; com a mesma estática de 192.0.2.1 para NULL0, o tráfego morre no primeiro roteador da rede, como prevê a RFC 5635. Confirme em laboratório que o BGP resolve o next-hop 192.0.2.1 pela estática para NULL0.
Na borda, o nó 5 do export de cada link apaga 64700:666 e aplica a community da operadora (64510:666, 64511:9999, 64509:666) ou 65535:666 no IX.br, com no-export nos trânsitos (no IX.br, confira no looking glass).
Cada operadora descarta o tráfego na rede dela; no IX.br, o RS valida e marca 26162:666.
O ataque termina, o NOC remove a estática e o /32 some de todos os vizinhos.

Community de blackhole por vizinho

Link	ASN	Community enviada	Observação
TRANSITO-A	64510	64510:666	Valor fictício do cenário
TRANSITO-B	64511	64511:9999	Fictício; mostra que o valor nem sempre termina em 666
TRANSITO-C	64509	64509:666	Fictício; trânsito backup, LP 90
IX-SP, IX-FORTALEZA, IX-MG	26162 (RS)	65535:666	Só /32 e /128 validados; o RS devolve 26162:666

Os valores dos trânsitos são fictícios. Cada operadora publica a sua community de blackhole, e muitas só honram o pedido depois de habilitar o serviço na sessão. Confirme o valor com o NOC e teste com um IP de laboratório antes do primeiro ataque.

Regras de segurança

Atenção: blackhole só para /32 dos seus próprios blocos e dos blocos validados de clientes. Um erro de prefix-list aqui derruba o tráfego de um bloco inteiro, ou de um terceiro, em todas as operadoras ao mesmo tempo. A BH-NOSSOS, com greater-equal 32 (sem less-equal, o limite superior já é 32), é a trava, e ela aparece na origem e no export.

No-export só no export (veja acima).
Desfazer é remover a estática; ninguém edita route-policy no meio do ataque.
O blackhole seletivo usa 64700:5CC66: com 64700:50166 só o TRANSITO-A descarta. Para o IP continuar alcançável pelos outros links, o gatilho não pode ser a estática para NULL0: use uma estática /32 com o next-hop real e outra tag (por exemplo 667), casada por um segundo nó da RTBH-ORIGEM que aplica 64700:50166.
Os nós 5 e 6 do export repetem a checagem da BH-NOSSOS, então um /24 marcado com 64700:666 por engano não sai como blackhole.

Blackhole pedido por cliente BGP

Cliente com sessão BGP vai querer se defender sozinho, e o cenário já trata isso. O nó 5 da CLIENTE-X-IN casa o community-filter BH-RFC7999 (65535:666) e a prefix-list CLIENTE-X-BH, que aceita só /32 dentro de 198.51.100.0/24. Casando os dois, o nó apaga o namespace interno, aplica 64700:666 e local-preference 200.

O cliente fala a community pública e a borda traduz. Mandar 64700:666 direto não adianta, porque a CLIENTE-X-IN apaga o namespace interno em todos os nós. Um /32 fora do bloco do cliente não casa o nó 5 nem o nó 10 (que aceita só a CLIENTE-X-BLOCOS) e cai no deny do nó 100.

Do lado do export, a BH-NOSSOS ganhou o index 20 com 198.51.100.0/24 greater-equal 32. Assim os nós 5 e 6 deixam sair o /32 do cliente, mas só depois que a CLIENTE-X-IN o validou e marcou. Documente a regra no guia de BGP communities para clientes: ele envia 65535:666, só em /32 do próprio bloco.

Engenharia de tráfego com BGP communities: entrada e saída

Na saída, quem manda é o local-preference aplicado no import: cliente 200, PTT 150, trânsito 100 e trânsito backup 90. Na entrada você só influencia o vizinho, com prepend, NO_EXPORT seletivo, supressão do anúncio em um link ou prefixo mais específico. No dicionário do provedor, cada uma dessas alavancas vira uma etiqueta na rota.

Saída: local-preference por classe de link

O tráfego que sai do AS segue a melhor rota, e o critério que você controla por política é o local-preference. Como as políticas de import do Passo 2 já gravam o valor por link, a classe decide sozinha: rota de cliente ganha de rota de PTT, que ganha de rota de trânsito.

Classe	Local-pref	Links do cenário	Efeito prático
Cliente BGP	200	sessões de cliente (CLIENTE-X-IN)	Tráfego para o cliente nunca sai por trânsito se a sessão direta estiver de pé.
PTT	150	IX-SP, IX-FORTALEZA, IX-MG	Conteúdo e redes presentes no IX.br são alcançados sem custo de trânsito.
Trânsito	100	TRANSITO-A, TRANSITO-B	Os dois empatam no local-pref e o desempate cai no AS-path e nos critérios seguintes.
Trânsito backup	90	TRANSITO-C	Só carrega saída quando os outros dois perdem a rota.

Se um destino específico precisa sair por um trânsito diferente, não mexa na classe inteira. Crie um nó no import daquele link com if-match no prefixo ou no AS-path de origem e um local-pref próprio, com número entre 40 e 90 (por exemplo, 80), repetindo o delete do namespace e a marca do link. A exceção fica documentada na própria política.

Entrada: prepend, NO_EXPORT, supressão e mais específico

O tráfego que entra depende da decisão do resto da internet, então as ferramentas são mais fracas. A tabela vai da mais suave para a mais agressiva, que é a ordem em que eu recomendo tentar:

Ferramenta	Community	Efeito	Risco
Prepend por link	`64700:50101` a `64700:50103`	Caminho mais longo por um link; parte do tráfego migra sem retirar nada.	Baixo. Redes que só enxergam você por aquele link continuam chegando por ele.
Prepend por grupo	`64700:60001` a `64700:60003`	Mesmo efeito em todos os trânsitos de uma vez, favorecendo os PTTs.	Baixo. Com todos os trânsitos alongados, a diferença entre eles some.
NO_EXPORT seletivo	`64700:50208`	Deixa a rota só dentro do AS do trânsito (nem os clientes dele recebem), o que reduz o alcance daquele link sem apagá-lo.	Médio. O trânsito vira quase um peering privado para aquele prefixo.
NO_EXPORT por grupo	`64700:60008`	Aplica o mesmo corte em todos os trânsitos.	Alto. Quem não está nos PTTs nem nos trânsitos perde o caminho.
Não anunciar em um link	`64700:50367`	Tira o prefixo daquele vizinho; o tráfego migra inteiro para os outros caminhos.	Médio. Se outro link cair, o prefixo fica com menos rotas de entrada.
Anúncio mais específico	nenhuma (dois /25 no lugar do /24)	Vence qualquer prepend, porque o prefixo mais longo ganha.	Alto. Cresce a tabela global e muita rede descarta abaixo de /24.

O mais específico tem um risco que aparece tarde: se um /25 escapar para o trânsito errado, ele atrai todo o tráfego daquela metade do bloco e nenhum prepend no /24 corrige. Por isso a prefix-list EXPORTAVEIS continua em todos os nós de export.

Casos práticos

Situação	Community	Efeito	Como desfazer
Link saturado: TRANSITO-A em 95% de entrada no pico	`64700:50101` no 203.0.113.0/24, na ORIGEM-LOCAL; se não bastar em meia hora, `64700:50102`	Parte da entrada migra para o TRANSITO-B e para os PTTs.	Tirar a community e fazer o refresh de export do peer (`refresh bgp 198.18.1.1 export`).
Manutenção programada em um link	Graceful shutdown: acrescente `apply community 65535:0 additive` aos nós permit do export daquele link	O vizinho baixa o local-pref das rotas que recebe de você e o tráfego migra antes da queda.	Tirar a community depois que o link voltar e estabilizar.
CDN que chega pelo IX-SP e também pelo TRANSITO-B	`64700:50202` se a CDN estiver entrando pelo trânsito	Na saída, o local-pref 150 já prefere o PTT; na entrada, o trânsito fica mais longo.	Tirar a community; confirmar no looking glass da CDN qual caminho ela escolheu.
Trânsito backup: TRANSITO-C só em falha	`64700:50303` para a entrada; local-pref 90 na saída	Entrada mínima pelo TRANSITO-C enquanto os outros estiverem de pé.	Tirar a community se o TRANSITO-C passar a ser trânsito principal.

A graceful shutdown está na RFC 8326. O vizinho que a honra baixa o local-pref das rotas que recebe de você, o tráfego migra enquanto a sessão ainda está de pé e a queda não gera perda. O route server do IX.br honra (na v4.3, ativo em SP; confira a sua localidade); nos trânsitos, pergunte ao NOC antes de contar com isso.

No caso do backup, o prepend 3x não zera o tráfego de entrada: redes que só enxergam você pelo TRANSITO-C continuam chegando por ele. Se o objetivo é zero, a ferramenta é não anunciar, com o risco da tabela acima.

Plano de transição da prefix-list para BGP communities

A migração segura da borda para BGP communities acontece em cinco fases, uma por janela e um link por vez: marcar a origem sem mudar o export, inserir os nós de community antes dos antigos, comparar os anúncios por peer, remover os nós de prefix-list e só então liberar communities para os clientes. Cada fase tem validação e rollback próprios.

Na minha borda o dicionário existe e ainda não está ligado, e esse é o ponto de partida deste plano. Os community-filters criados na seção de desenho do sistema não mudam nada sozinhos; o comportamento só muda quando uma route-policy de export passa a consultá-los.

Fase	O que fazer	Como validar	Rollback
1. Marcar a origem	Aplicar ORIGEM-LOCAL no comando `network`, CLIENTE-X-IN em cada cliente e as políticas de import com a community de link recebido. Export intacto.	A rota 203.0.113.0/24 mostra 64700:10091, uma rota de cliente mostra 64700:10093 e uma rota de trânsito mostra 64700:5CC00; advertised-routes de cada peer igual ao registro anterior.	Remover o `route-policy` do `network` e voltar o import antigo.
2. Nós novos antes dos antigos	Traduzir cada prepend atual em community na origem e montar uma política nova (EXPORT-TRANSITO-A-V2) com os nós 5 a 90 e os antigos copiados a partir do 110 (o VRP não renumera nó), sem o deny node 100 até a fase 4.	Refresh de export no peer e comparação da saída.	Voltar o nome da política antiga no peer e rodar o refresh de export; a política antiga continua intacta.
3. Comparar anúncios	Rodar advertised-routes antes e depois em cada peer mexido.	Mesma lista de prefixos e mesmo AS-path no looking glass da operadora.	Se divergir, voltar à fase 2 daquele link.
4. Remover nós antigos	Depois de alguns dias estáveis, apagar os nós de prefix-list e incluir o deny node 100.	Contagem de rotas anunciadas igual; nenhuma rota cai no deny.	Recriar os nós antigos a partir do backup da configuração.
5. Liberar para clientes	Publicar o guia e deixar de apagar, na política do cliente, as communities de ação permitidas.	Um cliente piloto testa prepend e blackhole com acompanhamento.	Voltar a apagar todo o namespace na CLIENTE-X-IN.

Na fase 1, mantenha no import novo os local-prefs e filtros de hoje; mude só a marca.

A forma mais segura de fazer a fase 2 é montar a política nova com outro nome (EXPORT-TRANSITO-A-V2), com os nós 5 a 90 e os antigos copiados a partir do 110, sem o deny node 100, e trocar só a referência no peer (peer 198.18.1.1 route-policy EXPORT-TRANSITO-A-V2 export). O rollback é voltar o nome antigo no peer. Nunca cole o bloco do Passo 3 sobre a política em uso: os nós 10 e 20 antigos se misturariam com os novos.

A fase 2 tem uma armadilha. O nó 90 do export aceita qualquer rota com origem exportável, então, se o /24 antes recebia prepend 3x no TRANSITO-C por prefix-list, ele passaria a sair sem prepend assim que o nó 90 entrasse. A solução é adicionar 64700:50303 na ORIGEM-LOCAL antes de ligar os nós novos. O resultado final precisa ser idêntico ao de hoje.

A fase 5 é a única que depende de terceiros. Comece com um cliente piloto que já pediu prepend ou blackhole, acompanhe as primeiras mudanças pelo contador da política e só depois divulgue o guia para todos. Até lá, a CLIENTE-X-IN continua apagando o namespace inteiro, então nenhuma community de cliente muda o seu export.

Soft reset e comparação por peer

O comando refresh bgp 198.18.1.1 export reaplica a route-policy de export e reenvia os updates para aquele peer sem derrubar a sessão. O refresh bgp 198.18.1.1 import faz o mesmo no sentido de entrada, pedindo route-refresh ao vizinho. Nenhum dos dois reinicia a sessão. O export muda o que o vizinho vê; o import muda o que você aceita.

O refresh de import depende da capability route-refresh negociada na sessão, que quase todo trânsito e o route server do IX.br anunciam. Se a sessão não tiver essa capability, o VRP8 precisa guardar uma cópia das rotas recebidas (keep-all-routes) para reaplicar a política sem reset, e isso custa memória numa tabela completa. Confira com display bgp peer 198.18.1.1 verbose antes da janela.

Grave a saída de display bgp routing-table peer 198.18.1.1 advertised-routes antes da mudança, com o log do terminal ligado ou um print, aplique a política, rode o refresh e grave de novo. Compare as duas capturas linha a linha. Qualquer prefixo a mais, a menos ou com AS-path diferente é motivo para parar.

				
					display bgp routing-table peer 198.18.1.1 advertised-routes
refresh bgp 198.18.1.1 export
display bgp routing-table peer 198.18.1.1 advertised-routes

Atenção: mexa em um link por vez, dentro de uma janela de manutenção, com os outros links de pé. Se o export novo do TRANSITO-A anunciar algo errado, o TRANSITO-B e os PTTs seguram o tráfego enquanto você volta a configuração. Mexer em três trânsitos na mesma noite transforma um erro de digitação em queda total.

Large communities para ASN de 32 bits

Large communities (RFC 8092) têm três campos de 32 bits no formato ASN:função:parâmetro, e por isso comportam um ASN de 32 bits no primeiro campo. Com elas, as BGP communities do provedor passam a identificar o dono pelo próprio ASN, sem namespace privado.

A RFC 8195 sugere separar função e parâmetro. A tradução do nosso dicionário fica direta, com o número do link como parâmetro:

Função	Standard (namespace 64700)	Large (AS 65550)
Origem: blocos próprios	64700:10091	65550:1:91
Origem: clientes BGP	64700:10093	65550:1:93
Recebida no link 01	64700:50100	65550:2:1
Prepend 1x/2x/3x no link 01	64700:50101 a 64700:50103	65550:101:1 a 65550:103:1
NO_EXPORT no link 02	64700:50208	65550:108:2
Blackhole só no link 03	64700:50366	65550:166:3
Não anunciar no link 03	64700:50367	65550:167:3
Prepend 2x no grupo trânsitos	64700:60002	65550:102:600
Blackhole em todos os links	64700:666	65550:666:0

Standard ou large?

Critério	Standard (64700)	Large (65550)
Tamanho	32 bits (ASN:valor)	96 bits (ASN:função:parâmetro)
Identifica o dono	Não: namespace privado combinado com o cliente	Sim: o próprio ASN
Suporte em trânsitos	Universal	Depende da operadora e da versão do roteador dela
Route server do IX.br	Aceita	Aceita
Configuração no VRP8	`ip community-filter` e `advertise-community`	`ip large-community-filter` e `advertise-large-community`
Leitura pelo cliente	Exige a tabela do guia	Função e link aparecem no próprio valor

O formato large compensa quando você oferece communities a clientes que também têm ASN de 32 bits e querem etiquetas legíveis, ou quando o namespace de 16 bits começa a apertar. Para seis links e um dicionário estável, a standard resolve, e o route server do IX.br aceita os dois formatos. Eu manteria standard e só adicionaria large em paralelo, sem trocar.

No VRP8 a lógica é a mesma das communities standard: um filtro de large community, um nó na route-policy de export e o envio do atributo habilitado no peer.

				
					ip large-community-filter basic LC-L01-P2 index 10 permit 65550:102:1
route-policy EXPORT-TRANSITO-A permit node 42
 if-match large-community-filter LC-L01-P2
 if-match ip-prefix EXPORTAVEIS
 apply comm-filter NS-INTERNO delete
 apply as-path 65550 65550 additive
 quit
bgp 65550
 ipv4-family unicast
  peer 198.18.1.1 advertise-large-community
  quit
 quit
commit

A sintaxe acima segue a documentação da Huawei para o NetEngine 8000 V800R012 (Configuring the BGP Large-Community Attribute). Confira com ? na CLI da sua versão antes de aplicar. O nó 42 fica entre os nós de prepend 2x (40 e 41) e os de 1x (50 e 51), então a rota marcada com a large community de 2x é avaliada na mesma ordem das communities standard. E o vizinho precisa suportar e aceitar o atributo; sem isso, advertise-large-community não tem efeito do outro lado.

Antes de ligar large communities, apague também o namespace large na entrada de todos os links (filtro advanced ^65550: com o comando de delete de large community da sua versão) e confira com ?; sem isso, qualquer vizinho consegue acionar o nó 42.

Validação e troubleshooting

Quando as BGP communities não se comportam como o esperado, três comandos validam quase tudo: display bgp routing-table 203.0.113.0 24 mostra as communities presas à rota, display bgp routing-table peer 198.18.1.1 advertised-routes mostra o que sai para o peer e display route-policy EXPORT-TRANSITO-A mostra quantas rotas bateram em cada nó. O resto do troubleshooting é comparar esses três com o que você esperava.

				
					display bgp routing-table 203.0.113.0 24

Saída esperada em laboratório, com o bloco marcado na origem e pedindo prepend 2x no link 01:

 BGP local router ID : 10.99.255.1
 Local AS number : 65550
 Paths:   1 available, 1 best, 1 select, 0 best-external, 0 add-path
 BGP routing table entry information of 203.0.113.0/24:
 Network route.
 From: 0.0.0.0 (0.0.0.0)
 Route Duration: 3d07h12m44s
 Direct Out-interface: NULL0
 Original nexthop: 0.0.0.0
 Qos information : 0x0
 Community: <64700:10091>, <64700:50102>
 AS-path Nil, origin igp, MED 0, pref-val 0, valid, local, best, select, pre 255
 Advertised to such 8 peers:
    198.18.1.1
    198.18.2.1
    198.18.3.1
    198.18.11.253
    198.18.12.253
    198.18.13.253
    198.18.50.1
    10.99.255.2

Se a linha Community não aparece, a marcação da origem falhou: confira se a ORIGEM-LOCAL está no comando network e se a prefix-list MEUS-BLOCOS casa o bloco. Para ver todas as rotas que carregam uma etiqueta, use display bgp routing-table community 64700:50102.

				
					display bgp routing-table peer 198.18.1.1 advertised-routes

 BGP Local router ID is 10.99.255.1
 Status codes: * - valid, > - best, d - damped, x - best external,
               a - add path, h - history, i - internal, s - suppressed,
               S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete
 RPKI validation codes: V - valid, I - invalid, N - not-found

 Total Number of Routes: 2
        Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>     198.51.100.0/24    198.18.1.2                           0      64505i
 *>     203.0.113.0/24     198.18.1.2     0                     0      i

Duas rotas, nenhuma a mais: o bloco próprio e o do cliente. Dependendo da versão, a coluna Path/Ogn mostra o AS-path antes do prepend de export, então confirme o prepend no looking glass do trânsito, que mostra o caminho como o mundo recebe. Qualquer /32, bloco de terceiro ou rota aprendida em outro link nessa lista é vazamento.

Sintoma	Causa provável	Como confirmar e corrigir
Communities não chegam ao vizinho	Falta `peer x advertise-community` no peer (ou no iBGP)	O looking glass do vizinho mostra a rota sem communities; adicione o comando e faça o refresh de export.
Prepend não aplica	Ordem dos nós: um nó anterior casou primeiro (por exemplo, o 20 de NO_EXPORT, ou um nó antigo de prefix-list mantido com número menor)	Veja os contadores por nó na `display route-policy` e mova o nó de prepend para antes.
Community interna vazou para fora	Falta `apply comm-filter NS-INTERNO delete` em algum nó de export	Procure o namespace no looking glass do trânsito e corrija o nó.
Blackhole não funciona	Operadora não habilitou RTBH na sessão, o prefixo não é um /32 ou falta o NO_EXPORT (algumas operadoras exigem NO_EXPORT junto)	Confirme com o NOC a community exata e se a sessão aceita o /32; confira a BH-NOSSOS.
Route server descartou a rota	Objeto IRR (route/as-set) ausente ou ROA inválido no RPKI	Veja no looking glass do IX.br as communities 26162:651xx que o RS aplicou à rota; corrija o objeto ou o ROA e aguarde a atualização.
Filtro advanced não casa ou casa demais	Expressão regular errada, como `64700` sem `^` e `:`	Teste com `display ip community-filter` e rotas de exemplo antes de usar o filtro num `delete`.

O sintoma mais comum na migração para BGP communities é o prepend que não aparece. Quase sempre o motivo é um nó que casa antes: o VRP8 para no primeiro nó cujo if-match é verdadeiro, então a numeração é a lógica da política. Os contadores de display route-policy mostram onde cada rota parou.

Como publicar o seu guia de communities para clientes

Publique o guia em três lugares: uma página no site do provedor, o campo de notas no PeeringDB e os remarks no objeto aut-num do seu IRR. O conteúdo é curto: namespace, communities informativas, communities de ação que o cliente pode usar, blackhole e o contato do NOC.

Sem guia público, as BGP communities que você oferece não existem para o cliente. É o documento que ele consulta às duas da manhã, no meio de um ataque, para saber qual etiqueta mandar. Mantenha uma versão com data no topo e avise os clientes quando algo mudar.

Community	Tipo	Significado
64700:10091 / 64700:10093	Informativa	Rota originada pelo provedor / aprendida de cliente
64700:5CC00	Informativa	Rota aprendida no link CC
64700:5CC01 a 5CC03	Ação	Prepend 1x a 3x só no link CC
64700:5CC08	Ação	Anunciar com NO_EXPORT no link CC
64700:5CC67	Ação	Não anunciar no link CC
64700:60001 a 64700:60003	Ação	Prepend em todos os trânsitos
64700:60167	Ação	Não anunciar em nenhum PTT
65535:666	Ação	Blackhole em todos os links (só /32 dentro do bloco do cliente; a borda traduz para 64700:666 e depois para o valor de cada vizinho)

O guia publica só o subconjunto que o cliente pode usar, não o dicionário interno inteiro: nada de blackhole por link nem das communities de origem da CDN. E ele vale a partir da fase 5 do plano de transição; antes disso, a política do cliente apaga as communities de ação.

Um exemplo de texto que resume as BGP communities nos remarks do aut-num, adaptável ao site:

remarks: AS65550 BGP communities (atualizado em 2026-09-28)
remarks: Informativas: 64700:10091 origem propria, 64700:10093 cliente
remarks: 64700:5CC00 aprendida no link CC (01-03 transito, 11-13 PTT)
remarks: Acao: 64700:5CC0N prepend N vezes no link CC (N=1..3)
remarks: 64700:5CC08 no-export no link CC | 64700:5CC67 nao anunciar no CC
remarks: 64700:6000N prepend N vezes em todos os transitos (N=1..3)
remarks: 64700:60167 nao anunciar em nenhum PTT
remarks: 65535:666 blackhole (somente /32 dentro do seu bloco)
remarks: NOC: noc@exemplo.net.br

Troque os códigos de link pela lista real, com o nome de cada trânsito e PTT, e mantenha fora do guia qualquer detalhe que exponha IPs de sessão ou next-hops internos.

Checklist de operação

O checklist de operação tem dez verificações que pegam os erros mais comuns depois que as BGP communities entram em produção: community que não chega ao vizinho, namespace vazando, prefixo a mais no anúncio e blackhole nunca testado. Rode a lista a cada mudança de política e, sem mudança, uma vez por mês.

Todo peer externo e todo peer iBGP que precisa das etiquetas tem advertise-community.
O bloco 203.0.113.0/24 mostra a community de origem em display bgp routing-table 203.0.113.0 24.
Toda política de import apaga o namespace 64700 antes de marcar o link recebido.
Toda política de export termina em deny node 100 e todos os nós permit têm a EXPORTAVEIS (ou a BH-NOSSOS, nos nós de blackhole).
O advertised-routes de cada trânsito e PTT tem só os prefixos esperados.
O looking glass de pelo menos um trânsito não mostra nenhuma community do namespace 64700.
O RTBH foi testado com um /32 de laboratório em cada operadora que oferece o serviço.
Objetos IRR e ROAs cobrem todos os blocos anunciados, inclusive os dos clientes.
O guia público de communities tem a mesma data da última mudança de política.
O backup da configuração foi salvo depois da mudança, junto com a captura do advertised-routes.

Glossário rápido

Termo	Definição	Fonte
BGP community	Atributo opcional e transitivo de 32 bits, escrito como ASN:valor, usado para etiquetar rotas e disparar políticas.	RFC 1997
Large community	Atributo de 96 bits no formato ASN:função:parâmetro, que comporta ASN de 32 bits.	RFC 8092
Extended community	Atributo de 64 bits com campo de tipo, usado em route targets de VPN.	RFC 4360
NO_EXPORT	Community bem conhecida 65535:65281: a rota não é anunciada a peers eBGP do AS que a recebeu.	RFC 1997
BLACKHOLE	Community bem conhecida 65535:666 que pede ao vizinho para descartar o tráfego destinado ao prefixo.	RFC 7999
RTBH	Remotely Triggered Black Hole: descarte de tráfego disparado por um anúncio BGP.	RFC 5635
Graceful shutdown	Community bem conhecida 65535:0 que pede ao vizinho para baixar a preferência da rota antes de uma manutenção.	RFC 8326
Route server	Servidor do PTT que redistribui rotas entre participantes; no IX.br usa o AS 26162 e interpreta communities de controle.	IX.br v4.3

Conclusão

BGP communities trocam uma prefix-list por link por um dicionário que a borda inteira entende: a rota nasce etiquetada, cada export lê a etiqueta e decide prepend, NO_EXPORT, supressão ou blackhole. A base está na RFC 1997, as large communities na RFC 8092, o blackhole nas RFC 7999 e RFC 5635, e as regras do PTT na política de communities do IX.br v4.3.

Se o seu dicionário já existe, como o meu, o que falta é colocá-lo nas políticas com calma: uma fase por janela, um link por vez e o advertised-routes comparado a cada passo. Para os comandos da sua versão, a referência é a documentação da Huawei para o NetEngine 8000, e a lista de comandos Huawei daqui do blog ajuda no dia a dia. Comece pela fase 1 no link de menor tráfego: marcar a origem não muda nenhum anúncio e já deixa a tabela filtrável por community.

#bgp communities #bgp huawei #blackhole bgp #communities bgp #engenharia de trafego bgp #huawei ne8000 #ix.br #ptt #route-policy huawei #rtbh

Sobre o autor

Ivan Alves

Especialista em redes de provedores (ISP)

Ivan Alves trabalha há mais de 15 anos com redes de provedores de internet, do NOC ao backbone e à borda BGP. Coordena infraestrutura e tecnologia em um provedor regional e escreve aqui os tutoriais que gostaria de ter encontrado quando começou: comandos testados, cenário explicado e o porquê de cada linha.

1 Comentário

BGP no Juniper Junos: policy-statement, prefix-list e communities – IA Tecnologia 12/10/2026 às 18:34 Responder
[…] post é o espelho, em Junos, do que eu mostrei em BGP communities no Huawei: prefix-list, filtros de import e export, communities para marcar a origem das rotas, […]