Skip to main content


Clearing BGP Connections​

Quando estamos trabalhando com BGP, principalmente com políticas como route-maps, filtros de prefixo, listas de comunidade e etc. essas mudanças não são aplicadas imediatamente às sessões BGP já estabelecidas. O roteador continua usando a política antiga até que a sessão seja reinicializada ou a tabela de rotas seja recalculada. É aí que entra o clearing da sessão BGP, uma forma de forçar a aplicação das novas configurações.


Tipos de clearing BGP:

  • Hard Clear (limpeza total)

    É o método mais agressivo. Derruba a sessão BGP completamente e depois sobe de novo. O roteador encerra a conexão TCP, limpa todas as rotas recebidas e enviadas, e refaz tudo do zero. Isso pode causar interrupção de tráfego, então só use quando realmente necessário.

    clear ip bgp <neighbor-ip>

    Ou:

    # todos os vizinhos:
    clear ip bgp *

  • Soft Clear Inbound (recalcula o que recebo)

    Aqui vamos solicitar que o vizinho reenvie as rotas novamente, sem derrubar a sessão, assim podemos aplicar a nova política de entrada (como um novo route-map). Isso não impacta o tráfego, então é ideal quando se altera filtros de entrada.

    clear bgp ipv4 unicast <neighbor-ip> soft in

  • Soft Clear Outbound (reenvio o que envio)

    Esse força o meu roteador a reaplicar as políticas de saída e reenviar as rotas para o vizinho. Serve quando se muda algo que afeta o que estamos anunciando (como set community, set as-path prepend, etc). Nem todos os roteadores vizinhos aceitam isso de forma limpa, mas em geral funciona bem.

    clear bgp ipv4 unicast <neighbor-ip> soft out

  • Using soft-reconfiguration inbound

    Se o vizinho não suporta soft clear por padrão, eu posso usar essa configuração no meu lado:

    neighbor <IP> soft-reconfiguration inbound

    Isso faz o meu roteador guardar uma cópia das rotas recebidas para poder reaplicar filtros mesmo sem pedir para o vizinho reenviar. Consome mais memória, mas funciona.


Quando eu uso cada um?

  • Mudei algo na entrada (por exemplo, apliquei um novo route-map in): uso soft in.
  • Mudei algo na saída (como comunidades BGP, prepend, etc): uso soft out.
  • A sessão está bugada, rotas estranhas, ou quero reiniciar tudo: uso hard clear.


Filtragem e Manipulação de Rotas​

A Filtragem e manipulação de rotas no BGP são práticas essenciais para controlar o que entra e o que sai da sua tabela de roteamento. Elas servem tanto para proteger sua rede quanto para influenciar o tráfego. Quem opera BGP com responsabilidade nunca anuncia ou aceita rotas cegamente, tudo deve passar por políticas bem definidas.


Quando falamos em filtrar rotas, estamos falando de:

  • Bloquear prefixos indesejados (por tamanho, origem, ASN, etc.)
  • Aceitar apenas rotas válidas ou autorizadas
  • Evitar propagação acidental de prefixos internos

Por exemplo, você pode rejeitar qualquer rota com máscara maior que /24 (prática comum entre provedores), ou bloquear prefixos que pertencem a terceiros que você não deveria anunciar.


Já a manipulação de rotas envolve modificar atributos para influenciar decisões de roteamento, como:

  • Local Preference (define preferência de saída dentro do seu AS)
  • MED (Multi Exit Discriminator) (sugestão de entrada para vizinhos)
  • AS_PATH prepending (tornar o caminho menos atraente para o exterior)
  • Communities (marcar rotas para aplicar políticas em larga escala)

Essas alterações não mudam o destino da rota, mas alteram a preferência de tráfego. Por exemplo, se você tem dois links com operadoras diferentes, pode usar local-preference para preferir um caminho específico para saída, ou usar AS-PATH prepending para "afastar" tráfego de entrada por um dos links.


Tudo isso é aplicado com route-maps, prefix-lists e filtros baseados em communities. Na prática, isso garante que:

  1. Você não anuncie nada que não deva (evita "leaks" de rotas internas)
  2. Você não aceite rotas inválidas ou suspeitas
  3. Você controle como o tráfego entra e sai da sua rede

Essas técnicas são padrão em qualquer política de roteamento profissional, e são reforçadas por boas práticas como o uso de IRR (Internet Routing Registry) e RPKI para validação de origem dos prefixos.


Podemos aplicar filtros de roteamento tanto para os prefixos que recebemos quanto para os que divulgamos. Isso é fundamental para manter controle sobre o que entra na nossa tabela de roteamento e o que sai da nossa rede, evitando, por exemplo, o anúncio acidental de rotas internas ou a aceitação de prefixos inválidos.


Os roteadores da Cisco, de forma geral, oferece quatro mecanismos principais de filtragem de rotas:

  1. distribute-list: permite filtrar rotas com base em ACLs padrão ou numeradas (para IPv4), aplicada na entrada ou saída.
  2. prefix-list: filtro baseado em prefixos IP e suas máscaras, com mais precisão que ACLs.
  3. as-path access-list: permite filtrar rotas com base no conteúdo do AS_PATH, usando expressões regulares.
  4. route-map: o método mais completo e flexível, podendo combinar condições (prefixos, comunidades, as-path, etc.) e aplicar ações (como alterar atributos BGP).

No entanto, não podemos aplicar ao mesmo tempo uma prefix-list e uma distribute-list no mesmo vizinho BGP. O IOS permite apenas um tipo de filtro por direção e por sessão. Se tentar aplicar os dois, um vai sobrescrever o outro.


A prática comum é usar prefix-list para controlar quais prefixos são aceitos ou enviados e route-map para manipular atributos como local-preference, MED ou AS-PATH. Já as-path access-list costuma ser usada dentro de route-maps para filtrar rotas vindas de ASs específicos.



ACL​

No BGP, podemos aplicar filtros de rota com base em ACLs, prefix-lists, ou AS_PATHs, para controlar tanto o que aceitamos (in) quanto o que anunciamos (out). Isso é essencial para garantir que só aceitamos rotas válidas e só propagamos aquilo que realmente nos pertence.


O IOS permite usar ACL padrão e estendida:

  • ACL padrão (números 1 a 99): filtra com base apenas no endereço de origem.
  • ACL estendida (números 100 a 199): permite combinar IP de origem e destino, protocolos, portas etc. No contexto de BGP, ACLs padrão podem ser usadas para filtrar prefixos, embora atualmente se prefira usar prefix-list por ser mais precisa.

No contexto de BGP, ACLs padrão ainda podem ser utilizadas, mas hoje é mais comum e recomendado usar prefix-list, pois são mais precisas e suportam filtragem por tamanho de prefixo (como /24, /25, etc.), coisa que ACLs padrão não conseguem fazer diretamente.


Por exemplo:

access-list 10 permit 192.168.0.0 0.0.255.255
access-list 10 deny any

O wildcard 0.0.255.255 permite qualquer IP entre 192.168.0.0 e 192.168.255.255, ou seja, um /24.


O número 10 é simplesmente o identificador da ACL. No IOS clássico (antes do modo nomeado), esse número define qual lista você está criando ou referenciando. Ele pode estar entre 1 e 99 no caso das ACLs padrão. Você pode escolher qualquer número dentro dessa faixa. Exemplo: access-list 1, access-list 2, ..., access-list 99.


Por padrão, todas as ACLs terminam com um deny any implícito. Isso significa que, se algo não for explicitamente permitido, será negado automaticamente. Mas na prática, é boa prática escrever o deny any de forma explícita, por dois motivos:

  1. Fica mais claro para quem está lendo que existe uma intenção de bloquear tudo que não for permitido.
  2. Facilita o uso de comandos como show access-lists, pois os contadores de match mostram claramente quantas vezes rotas foram negadas.

ACLs padrão podem ser aplicadas no BGP com distribute-list, por exemplo:

router bgp 65000
 address-family ipv4
  neighbor 198.51.100.1 distribute-list 10 in

Aqui, você está dizendo: "aceite apenas os prefixos definidos na ACL 10 que o vizinho tentar me enviar".



Prefix Matching​

Para controlar o tamanho das rotas aceitas, usamos prefix-lists, que suportam operadores como le (less than or equal) e ge (greater than or equal). Abaixo podemos ver uma prefix list clássica:

ip prefix-list ROTA padrao seq 5 permit 0.0.0.0/0 le 32

Isso permite qualquer prefixo válido, do /0 até o /32. Perigoso se usado sem critério, já que permite qualquer coisa. Para bloquear endereços IP privados, podemos fazer:

ip prefix-list BLOQUEIA_PRIVADOS seq 10 deny 10.0.0.0/8 le 32
ip prefix-list BLOQUEIA_PRIVADOS seq 20 deny 172.16.0.0/12 le 32
ip prefix-list BLOQUEIA_PRIVADOS seq 30 deny 192.168.0.0/16 le 32
ip prefix-list BLOQUEIA_PRIVADOS seq 100 permit 0.0.0.0/0 le 32

Ou, para permitir apenas rotas entre /20 e /24:

ip prefix-list BLOQUEIA_MAIOR_QUE_24 seq 5 deny 0.0.0.0/0 ge 25
ip prefix-list BLOQUEIA_MAIOR_QUE_24 seq 10 deny 0.0.0.0/0 le 19
ip prefix-list BLOQUEIA_MAIOR_QUE_24 seq 100 permit 0.0.0.0/0 ge 20 le 24


REGEX e AS_PATH ACL​

No BGP, você também pode filtrar com base em AS_PATH, usando expressões regulares. Um exemplo clássico:

ip as-path access-list 1 permit ^$

Esse filtro permite somente rotas originadas por você mesmo, ou seja, cujo AS_PATH está vazio (^$), o que evita que você reexporte rotas aprendidas de terceiros, algo importante para não se tornar trânsito para outras operadoras.


Exemplo de aplicação no BGP:

router bgp 65000
 address-family ipv4
  neighbor X.X.X.X filter-list 1 out

Aqui, estamos dizendo: "para esse peer, só anuncio prefixos originados pelo meu próprio AS."


Vamos criar um AS-PATH ACL para negar qualquer rota que tenha o AS 65010 em qualquer parte do AS_PATH, negar rotas que terminem com o AS 65020 e permitir apenas rotas originadas no nosso próprio AS (AS_PATH vazio), ou seja, rotas que nós mesmos estamos publicando.

ip as-path access-list 10 deny _65010_
ip as-path access-list 10 deny _65020$
ip as-path access-list 10 permit ^$

router bgp 65000
 address-family ipv4
  neighbor X.X.X.X filter-list 10 out

Se nenhuma das regras der match, a ação padrão é negar (como nas ACLs tradicionais). Então, se você esquecer de colocar uma linha permit, todas as rotas serão bloqueadas.



Aplicando no BGP (in ou out)​

No BGP, os filtros podem ser aplicados tanto na entrada (in) quanto na saída (out) da sessão com o vizinho (peer). Isso define em qual direção o filtro atua:

  • in significa que o filtro será aplicado às rotas que o vizinho está tentando nos enviar. Ou seja, você está controlando o que entra na sua tabela BGP.
  • out significa que o filtro será aplicado às rotas que você está enviando para o vizinho. Ou seja, você está controlando o que a sua rede divulga para ele.

Exemplo:

router bgp 65000
 address-family ipv4
  neighbor 192.0.2.1 prefix-list BLOQUEIA_PRIVADOS in
  neighbor 192.0.2.1 prefix-list PERMITE_20_ATE_24 out

Neste caso:

  • Com in, você rejeita prefixos privados que o vizinho possa estar tentando te mandar.
  • Com out, você limita os anúncios da sua rede para que o vizinho só receba prefixos entre /20 e /24.

Essas direções (in e out) são sempre relativas ao seu roteador. Isso te dá total controle sobre o que entra na sua rede e o que sai dela, o que é essencial para segurança, política de roteamento e evitar anúncios indevidos.



Route Maps​

As Route Maps são como scripts condicionais que podemos usar em roteadores para tomar decisões mais avançadas sobre o que fazer com rotas. Eles funcionam como uma série de instruções: "se isso for verdade, então faça aquilo". Eu uso Route Maps principalmente quando preciso aplicar políticas específicas na hora de redistribuir rotas, fazer filtros mais refinados ou manipular atributos BGP, por exemplo.


Cada Route Map é composto por sequências numeradas chamadas de cláusulas. Em cada cláusula, eu defino uma condição com o comando match e uma ação com o comando set. O match determina se a cláusula se aplica à rota que está sendo analisada (pode ser um prefixo específico, um next-hop, ou até uma lista de AS) e o set é o que será feito se a condição for atendida, como mudar a métrica, o local-preference ou até mesmo o próximo salto. As cláusulas são lidas na ordem, e assim que uma delas der match, a ação é executada e o processamento pode parar ou continuar, dependendo da configuração.


O interessante é que eu posso usar Route Maps em várias situações diferentes, como: controlar o que entra ou sai em um roteador, para aplicar políticas em redistribuições de rotas entre protocolos diferentes, ou para manipular atributos em sessões BGP.


Eles me dão uma flexibilidade que simples ACLs ou filtros de prefixo não têm. E como eu posso empilhar várias cláusulas com números diferentes, consigo criar uma lógica bem precisa para tratar rotas de jeitos diferentes, tudo dentro da mesma estrutura.



Regas​

Ao criar um Route Map, tem umas regras que é bom lembrar porque o comportamento padrão pode influenciar bastante no resultado. Se não for colocado uma ação de permissão ou negação (permit ou deny), ele assume permit por padrão, então qualquer rota que bater nessa cláusula vai ser aceita, a não ser que eu diga o contrário.


Outra coisa, se não for colocado um número de sequência, o roteador automaticamente incrementa em 10 a partir do anterior. Isso é útil porque me espaço para inserir novas cláusulas depois, sem ter que renumerar tudo, igual nas ACLs.


Se não for definido um critério de correspondência com o match, ele vai aplicar aquela cláusula para qualquer rota, ou seja, todos os prefixos são considerados correspondentes implicitamente. É como se o match fosse "match all".


O processamento do Route Map funciona meio como um filtro sequencial. Assim que uma cláusula dá match, ele executa tudo o que tiver nos set daquela cláusula, e aí para o processamento ali mesmo. Ele não continua para as próximas cláusulas, então a ordem das sequências faz diferença e precisa ser bem pensada.


A ideia principal é que ele vai avaliando as cláusulas em ordem de número. Se uma cláusula não der match, ele tenta a próxima. Mas se der match, ele executa o que tiver nos set daquela cláusula e para por ali, ignorando as outras.


Primeiro, vamos criar as ACLs:

ip access-list standard REDE10
 permit 10.0.0.0 0.0.0.255

ip access-list standard REDE20
 permit 10.0.1.0 0.0.0.255

ip access-list standard REDE30
 permit 10.0.2.0 0.0.0.255

Agora vamos criar os Route Maps:

route-map ROTA_POLICY permit 10
 match ip address REDE10

route-map ROTA_POLICY permit 20
 match ip address REDE20
 set metric 100

route-map ROTA_POLICY permit 30
 match ip address REDE30
 set metric 150

route-map ROTA_POLICY permit 40
 set metric 200

route-map ROTA_POLICY deny 50

  • Se uma rota vier de 10.0.0.0/24, vai dar match na cláusula 10 (REDE10) e a rota será aceita do jeito que veio ao mundo. Não faremos nada com essa Rota.
  • Se for uma rota de 10.0.1.0/24 (REDE20), bate na cláusula 20 e a métrica é configurada para 100 nessa rota.
  • Se for uma rota de 10.0.2.0/24, vai cair na cláusula 30.
  • Agora, se vier uma rota que não bate em nenhuma ACL, ele vai cair na cláusula 40, que não tem match, ou seja, aceita tudo (match implícito). A métrica vira 200.
  • A cláusula 50 com deny é só para garantir que qualquer rota que não for tratada antes seja negada, mas nesse exemplo ela nem vai ser usada, porque a cláusula 40 já aceita qualquer coisa.


Opções de Matching​

Quando se configura uma Route Map, as opções de matching são as condições que são usadas para decidir se aquela cláusula vai se aplicar ou não à rota que está sendo analisada. Se a rota der match com a condição, então o roteador executa as ações definidas com set naquela cláusula e para o processamento ali.


As opções de match são bem variadas, a escolha é de acordo com que se deseja filtrar. Por exemplo, se estiver lidando com rotas IP, podemos usar match ip address junto com uma ACL ou prefix-list. Se for BGP, existem várias opções específicas, como match as-path, match community ou match route-type.


Aqui vão alguns exemplos das opções mais comuns:

  • match ip address: compara o prefixo com uma ACL ou prefix-list.
  • match interface <interface-id>: verifica se a rota está associada a uma determinada interface.
  • match metric: compara com a métrica da rota.
  • match next-hop: compara o endereço IP do próximo salto da rota.
  • match tag: compara o valor de marcação (tag) da rota.
  • match route-type: compara com o tipo da rota (como internal, external, local, etc).
  • match as-path: muito usado em BGP, compara com uma as-path access-list.
  • match community <community-list>: filtra com base em comunidades BGP.
  • match source-protocol {bgp asn | connected | eigrp asn | ospf pid | static}: muito comum para comparar prefixos com base no protocolo de roteamento de origem e/ou processo de roteamento.
  • match local-preference, match origin, match weight: outros filtros específicos para atributos BGP.

Também podemos combinar mais de um match na mesma cláusula. Se fizer isso, o comportamento padrão é "AND", ou seja, todos os critérios precisam ser verdade para dar match. Mas se eu quiser que seja um "OR", aí podemos usar o modificador match any. Se quiser que todos os critérios sejam obrigatórios, uso match all (que é o padrão).


Essas opções dão um controle bem refinado.


Por padrão, quando se usa mais de um match na mesma cláusula, o roteador assume que é AND, ou seja, todas as condições precisam ser verdadeiras para dar match. Se eu quiser mudar isso e dizer que qualquer uma das condições serve, aí eu coloco explicitamente match any.


Exemplo usando AND (padrão):

route-map FILTRO_AND permit 10
 match ip address prefixo10
 match interface FastEthernet0/1

Aqui ele só vai dar match se a rota bater com a prefix-list prefixo10 E a interface de saída for a FastEthernet0/1. Se só uma das duas for verdadeira, não vai dar match, e o roteador pula para próxima cláusula.


Exemplo usando OR com match any:

route-map FILTRO_OR permit 10
 match any
 match ip address prefixo10
 match ip address prefixo20

Nesse caso, se a rota bater em qualquer um dos dois prefixos, já dá match. Ele vai aceitar rotas que estão em prefixo10 ou em prefixo20.


Exemplo explícito com match all:

route-map FILTRO_ALL permit 10
 match all
 match ip address prefixo10
 match interface FastEthernet0/1

Esse aqui faz exatamente o mesmo que o exemplo do AND anterior, mas agora eu deixei claro que quero match all. É útil quando quero evitar ambiguidade e deixar explícito que todas as condições têm que bater.


Se nós colocarmos múltiplas condições na mesma linha, teremos uma confição OR. Abaixo podemos ver um exemplo:

ip prefix-list REDE10 seq 5 permit 10.0.0.0/24
ip prefix-list REDE20 seq 5 permit 10.0.1.0/24

route-map EXEMPLO_OR permit 10
 match ip address prefix-list REDE10 REDE20
 set metric 150

Nesse caso, a cláusula vai dar match se a rota estiver em REDE10 ou REDE20. O match ip address prefix-list com várias listas funciona como match any implícito, não preciso nem escrever match any nesse cenário, porque o comportamento já é "OR" entre as listas informadas na mesma linha.


Se quiser deixar ainda mais claro, podemos fazer assim:

route-map EXEMPLO_OR permit 10
 match any
 match ip address prefix-list REDE10 REDE20
 set metric 150

Mas nesse exemplo acima, como as listas já estão na mesma linha, o match any seria redundante, é útil apens quando há vários comandos match separados, não quando todas as condições estão na mesma linha.



Opções de SET​

As opções de set em um route-map são as ações que queremos aplicar quando uma cláusula dá match. Ou seja, depois que a rota bate nas condições que foram definidas com match, o roteador executa o que está nos comandos set daquela cláusula, pode ser alterar a métrica, o next-hop, marcar uma rota, mudar atributos BGP, entre outros.


A escolha das opções de set dependendo do contexto, como: redistribuição, manipulação de rotas estáticas, OSPF, BGP, etc. Aqui vão os tipos mais comuns:


Para manipular rotas em geral:

  • set metric <valor> Define a métrica da rota. Muito útil na redistribuição entre protocolos.

  • set interface <nome da interface> Define a interface de saída da rota.

  • set ip next-hop <IP> Altera o endereço IP do próximo salto da rota.

  • set ip default next-hop <IP> Seta o next-hop só se a rota não tiver outro válido.

  • set tag <valor> Marca a rota com um número (tag). Isso é útil para identificar rotas e fazer filtros depois com match tag.


Para ambientes com BGP (que é onde o set brilha):

  • set local-preference <valor> Define a preferência local. Usado internamente no AS, quanto maior, mais preferida.

  • set weight <valor> Peso da rota no BGP (Cisco). Também interno ao roteador, maior = mais preferida.

  • set origin <igp|egp|incomplete> Altera a origem da rota no BGP, o que influencia no path selection.

  • set as-path prepend <ASN> Adiciona um ou mais ASNs no início do AS-PATH. É muito útil para tornar a rota menos atrativa para o vizinho BGP.

  • set community <comunidade> Atribui uma ou mais comunidades BGP à rota.

  • set comm-list <lista> delete Remove comunidades BGP específicas da rota.

  • set extcommunity Seta comunidades estendidas (em BGP com VPNs, por exemplo).

  • set aggregator Define informações de agregador BGP (AS e IP).

  • set atomic-aggregate Indica que uma agregação foi feita.

  • set originator-id <router-id> Define o Originator ID em ambientes BGP com route reflectors.

  • set cluster-id <ID> Define o Cluster ID no BGP route reflector.


Outras opções que às vezes aparecem:

  • set level <level-1|level-2|level-1-2> Para IS-IS, define o nível da rota.

  • set ipv6 next-hop <IP> Define o próximo salto para rotas IPv6.

  • set vrf <nome> Associa a rota a uma VRF específica.



Continue​

O continue em um route-map é um recurso que permite não interromper o processamento da rota após um match. Por padrão, quando uma cláusula dá match, o roteador executa os comandos set daquela cláusula e para ali mesmo. Mas se eu usar o continue, eu consigo dizer: "mesmo que essa cláusula tenha dado match, continue processando a cláusula de sequência X".


Isso é útil quando eu quero aplicar ações em etapas, ou quando quero acumular múltiplos set com base em vários critérios diferentes, tudo dentro do mesmo route-map.


A sintaxe é continue <número> no final da cláusula que deu match. O número indica qual sequência do route-map deve ser avaliada em seguida. Mesmo que a cláusula atual dê match, o roteador não para, ele pula para cláusula que eu indiquei com o continue e segue o processamento.


route-map TESTE permit 10
 match ip address prefix-list REDE10
 set metric 50
 continue 30

route-map TESTE permit 20
 match ip address prefix-list REDE20
 set metric 100

route-map TESTE permit 30
 match ip address prefix-list REDE30
 set tag 300

Se uma rota bater na prefix-list REDE10, o roteador executa set metric 50, mas por causa do continue 30, ele não para. Vai direto para cláusula 30, e se a rota também bater em REDE30, ele ainda aplica set tag 300.


Importante lembrar:

  • O continue só existe em algumas plataformas Cisco (como IOS 15.3+ e NX-OS). Não é suportado em todas.
  • Ele só funciona entre cláusulas do mesmo route-map, ou seja, ali temos a route map chamada TESTE, mas ele não pode continuar para outra que não seja a TESTE.
  • Se o número de sequência indicado no continue não existir, o processamento termina ali mesmo.


Community​

Atributo Community no BGP é um tipo de marca que pode ser associada a rotas para facilitar o controle e a aplicação de políticas. Ela funciona como uma etiqueta (tag) de 32 bits que pode ser usada para agrupar rotas e definir comportamentos específicos durante o processo de roteamento, como o que anunciar, para quem e com que atributos.


Em vez de criar filtros complexos baseados em prefixos ou AS-PATHs, é possível simplesmente aplicar ou verificar comunidades. Elas são amplamente utilizadas em ambientes de ISPs, grandes empresas ou interconexões onde é necessário aplicar políticas de forma escalável.


O valor de uma community é geralmente exibido no formato AA:NN, onde:

  • AA representa o ASN (ou um número reservado).
  • NN representa o valor definido pelo operador.

Exemplo: 65000:100 pode significar "rota recebida de cliente preferencial".


Existem valores especiais que possuem comportamento padronizado:

  • no-export Impede que a rota seja exportada para vizinhos eBGP.

  • no-advertise Impede que a rota seja anunciada a qualquer vizinho, mesmo iBGP.

  • no-export-subconfed Impede que a rota seja anunciada fora do confederation.

  • internet Indica que a rota pode ser anunciada para qualquer lugar (comportamento padrão).


Essas communities não precisam ser definidas com AA:NN, pois são palavras reservadas.


As communities são usadas para:

  • Marcar rotas ao recebê-las, facilitando o tratamento posterior com route-maps.
  • Aplicar políticas de exportação com base em quem anunciou a rota.
  • Controlar o anúncio seletivo de rotas para parceiros, clientes e provedores.
  • Fazer prepend automático ou alterar atributos como local-preference.

Abaixo podemos ver um exemplo de configuração onde marcamos uma rota com uma community:

route-map MARCAR_CLIENTE permit 10
 match ip address prefix-list CLIENTE
 set community 65000:100 additive

Filtrar rota baseada na community:

route-map FILTRAR_ROTA deny 10
 match community BLOQUEADAS

ip community-list standard BLOQUEADAS permit 65000:200

Remover community:

set comm-list BLOQUEADAS delete


Exemplos com Community​

Abaixo está um exemplo completo e bem detalhado de como utilizar BGP communities para liberar, bloquear e alterar o local-preference entre dois sistemas autônomos (ASNs): 65010 e 65020. Esse cenário é comum em ambientes onde há interconexão entre empresas, ISPs ou datacenters.


  • ASN 65010 é um provedor.
  • ASN 65020 é um cliente que recebe rotas do provedor.
  • O roteador do AS 65010 marca as rotas com communities para aplicar políticas.
  • O roteador do AS 65020 usa essas marcações para filtrar ou priorizar rotas.

Communities definidas:

CommunitySignificado
65010:100Rota permitida para clientes.
65010:200Rota bloqueada (não deve ser anunciada).
65010:300Rota com prioridade alta (Local-Pref).
no-exportRota não será exportada via eBGP.

Na configuração no AS 65010 (Provedor), vamos criar as Prefix-list para identificar rotas:

ip prefix-list REDE-LIBERADA seq 5 permit 10.0.0.0/24
ip prefix-list REDE-BLOQUEADA seq 5 permit 10.1.0.0/24
ip prefix-list REDE-PRIORITARIA seq 5 permit 10.2.0.0/24

Criar o Route-maps para aplicar communities:

route-map APLICA_COMMUNITY permit 10
 match ip address prefix-list REDE-LIBERADA
 set community 65010:100 additive

route-map APLICA_COMMUNITY permit 20
 match ip address prefix-list REDE-BLOQUEADA
 set community 65010:200 additive

route-map APLICA_COMMUNITY permit 30
 match ip address prefix-list REDE-PRIORITARIA
 set community 65010:300 additive

O parâmetro additive no comando set community serve para adicionar uma nova community à rota sem apagar as communities que ela já possui. Sem additive, o comportamento padrão é substituir todas as communities existentes pela nova. Com additive, o roteador mantém as communities anteriores e adiciona a nova ao conjunto.


Agora vamos aplicar no vizinho BGP:

router bgp 65010
 neighbor 192.0.2.2 remote-as 65020
 neighbor 192.0.2.2 route-map APLICA_COMMUNITY out

A configuração no AS 65020 (Cliente), vamos aplicar Community-list para filtrar:

ip community-list standard BLOQUEADAS permit 65010:200
ip community-list standard PRIORITARIAS permit 65010:300

Route-map para bloquear e alterar local-pref:

route-map FILTRA_ENTRADA deny 10
 match community BLOQUEADAS

route-map FILTRA_ENTRADA permit 20
 match community PRIORITARIAS
 set local-preference 200

route-map FILTRA_ENTRADA permit 30
 set local-preference 100

A cláusula 30 é genérica: aplica local-pref padrão (100) se nenhuma outra der match.


Aplicar no vizinho BGP:

router bgp 65020
 neighbor 192.0.2.1 remote-as 65010
 neighbor 192.0.2.1 route-map FILTRA_ENTRADA in


Exemplos com Community Parte 2​

Sobre usar community para rotas que não devam ser anunciadas. Bloquear uma rota com um route-map out e usar uma community podem parecer ações semelhantes, mas o objetivo, o alcance e o controle de cada abordagem são diferentes.


Se o objetivo for apenas não anunciar uma rota para um vizinho BGP, basta configurar a saída (out) com um route-map que filtre ou impeça o envio daquela rota. Não é obrigatório usar community para isso.


Usando prefix-list + route-map:

ip prefix-list BLOQUEAR_ROTA seq 5 deny 10.1.0.0/24
ip prefix-list BLOQUEAR_ROTA seq 10 permit 0.0.0.0/0 le 32

route-map BLOQUEIO_OUT deny 10
 match ip address prefix-list BLOQUEAR_ROTA

route-map BLOQUEIO_OUT permit 20

router bgp 65010
 neighbor 192.0.2.2 remote-as 65020
 neighbor 192.0.2.2 route-map BLOQUEIO_OUT out

Neste exemplo, a rota 10.1.0.0/24 não será anunciada para o vizinho, e todas as demais serão.


Usando community + filtro no route-map (se desejar delegar controle):

route-map MARCAR_BLOQUEIO permit 10
 match ip address prefix-list REDE-BLOQUEADA
 set community 65010:200 additive

router bgp 65010
 neighbor 192.0.2.2 remote-as 65020
 neighbor 192.0.2.2 route-map MARCAR_BLOQUEIO out

Nesse caso, a community é aplicada, e o AS vizinho pode decidir filtrar com base nela.


Usando diretamente no-export:

route-map MARCAR_NOEXPORT permit 10
 match ip address prefix-list REDE-BLOQUEADA
 set community no-export additive

Com no-export, a rota pode circular dentro do AS (entre iBGPs), mas não será anunciada via eBGP, mesmo sem um filtro explícito na saída.


Com Route-map na saída (out), temos bloqueio direto. Esse método impede que a rota seja anunciada a um vizinho específico, aplicando um filtro diretamente. Como funciona:

  • O roteador analisa o prefixo antes de enviar.

  • Se a rota der match com uma ACL ou prefix-list, e o route-map for deny, ela não será anunciada para aquele vizinho.


Esse método é simples e direto. Possui um escopo local, o filtro só vale para aquele vizinho configurado. A decisão de bloquear é feita unilateralmente, pelo roteador que anuncia. Não depende do roteador vizinho interpretar nada.


Usando uma community, a rota é marcada no momento em que é processada ou anunciada. O roteador não bloqueia nada por padrão, quem vai agir sobre a marca é quem recebe a rota (o vizinho).

  • A community é um rótulo, que viaja junto com a rota.

  • O roteador vizinho pode ter regras para negar, preferir ou modificar rotas com base nessa marca.

  • A community não bloqueia sozinha, é preciso configurar o que será feito com ela.


Esse método de política é mais flexível e reutilizável para vários vizinhos. Permite criar regras como: "bloqueie tudo com 65010:200", "dê preferência para 65010:300", etc. O escopo é mais amplo, pode ser interpretada por vários roteadores ou ASNs ao longo do caminho. Permite delegar controle de política para outros AS.


O lado ruim é que a rota será anunciada e o vizinho BGP pode escolher aceitar ou não, mesmo que estejamos dizendo para não aceitar, ele pode.



Maximum Prefix​

O comando maximum-prefix é usado em sessões BGP para limitar a quantidade de rotas que podem ser recebidas de um vizinho. Ele serve como um mecanismo de proteção contra falhas de configuração ou propagação excessiva de rotas, como em casos de vazamentos de rota (route leaks) que podem causar instabilidade na rede.


A finalidade de definir um prefixo máximo é evitar sobrecarga na tabela BGP, proteger contra anúncios excessivos ou incorretos, impedir que um vizinho sobrecarregue o roteador local entre outros.


A sintaxe básica é a seguinte:

neighbor <IP-do-vizinho> maximum-prefix <número> [threshold] [restart-time] [warning-only]

Exemplo, vamos limitar em mil prefixos o que um vizinhos nos envia:

neighbor 192.0.2.1 maximum-prefix 1000

Este comando encerra a sessão BGP se o vizinho tentar anunciar mais de 1000 rotas.


Outro exemplo, vamos usar threshold:

neighbor 192.0.2.1 maximum-prefix 1000 80

1000: limite máximo de rotas aceitas.

80: porcentagem de uso que aciona um alerta (log), neste caso, ao atingir 800 rotas.


Vamos trabalhar com tempo de reconexão:

neighbor 192.0.2.1 maximum-prefix 1000 80 5

Além do alerta com 80% e o limite de 1000 rotas, este comando define que o roteador tentará restabelecer a sessão BGP após 5 minutos, caso ela seja encerrada por excesso de prefixos.


Vamos configurar um log de aviso, sem derrubar a sessão:

neighbor 192.0.2.1 maximum-prefix 1000 80 warning-only

Neste caso, nenhuma ação será tomada se o número for ultrapassado, apenas um log de aviso será gerado.


Sem o warning-only, o comportamento padrão é:

  • A sessão BGP com o vizinho é derrubada imediatamente.
  • Um log de erro é gerado informando que o limite foi excedido.
  • Se o restart-time estiver configurado, a sessão será reativada automaticamente após o tempo definido.


Peer Groups​

Os Peer Groups são um recurso no BGP que permite agrupar vizinhos (peers) que compartilham a mesma configuração. Ao invés de repetir manualmente os mesmos comandos para cada vizinho, é possível definir um grupo com os parâmetros comuns e associar os vizinhos a esse grupo. Isso torna a configuração mais simples, limpa e escalável, especialmente em ambientes com muitos vizinhos BGP, como em ISPs, IXPs ou grandes datacenters.


  1. BGP Peer Group clássico (IPv4, sem template) Utilizado em versões mais antigas do IOS, apenas para sessões semafóricas (IPv4 unicast).

  2. BGP Peer Templates (mais modernos) Suportam múltiplas address-families e permitem herança entre templates.


Abaixo podemos ver um exemplo simples com Peer Group clássico:

router bgp 65010
 neighbor GRUPO-CLIENTES peer-group
 neighbor GRUPO-CLIENTES remote-as 65020
 neighbor GRUPO-CLIENTES update-source Loopback0
 neighbor GRUPO-CLIENTES next-hop-self
 neighbor GRUPO-CLIENTES route-map ENTRADA in
 neighbor GRUPO-CLIENTES route-map SAIDA out

 neighbor 192.0.2.1 peer-group GRUPO-CLIENTES
 neighbor 192.0.2.2 peer-group GRUPO-CLIENTES
 neighbor 192.0.2.3 peer-group GRUPO-CLIENTES

Nesse exemplo, todas as configurações aplicadas ao GRUPO-CLIENTES são herdadas pelos três vizinhos. Qualquer mudança no peer group é propagada automaticamente para os vizinhos associados.


Exemplo com Peer Template (novo modelo)

router bgp 65010

 bgp peer-group TEMPLATE-CLIENTE
 remote-as 65020
 update-source Loopback0
 route-map ENTRADA in
 route-map SAIDA out
 address-family ipv4
  send-community
  next-hop-self
 exit-address-family

 neighbor 192.0.2.1 inherit peer-group TEMPLATE-CLIENTE
 neighbor 192.0.2.2 inherit peer-group TEMPLATE-CLIENTE

Esse formato é mais moderno e usado em IOS-XR, NX-OS e IOS com suporte a peer templates.