Skip to main content


Route Aggregation​

A Sumarização de rotas no BGP é o processo de combinar vários prefixos específicos em um único prefixo mais abrangente. Isso ajuda a reduzir o número de rotas anunciadas entre sistemas autônomos, tornando o roteamento mais eficiente e a tabela BGP menos sobrecarregada. Além disso, serve para esconder detalhes da topologia interna de uma rede e proteger contra flapping de rotas específicas.


No BGP, a sumarização não ocorre automaticamente. É preciso configurar manualmente o prefixo agregado usando comandos como network (quando o prefixo já está presente na tabela de roteamento) ou aggregate-address (que permite formar rotas agregadas a partir de rotas mais específicas conhecidas pelo BGP).


Ao usar aggregate-address, é possível adicionar a opção summary-only para que apenas a rota agregada seja anunciada, sem as rotas mais específicas.


Por exemplo, se um roteador BGP aprende as rotas 10.1.0.0/24, 10.1.1.0/24, 10.1.2.0/24 e 10.1.3.0/24, é possível anunciar apenas 10.1.0.0/22. Isso diminui o número de prefixos circulando na internet e melhora a escalabilidade da rede.


No entanto, é importante que todas as rotas específicas estejam realmente presentes na tabela para que o BGP forme o agregado. Caso contrário, o prefixo sumarizado não será anunciado.


Um cuidado importante é que sumarizações mal planejadas podem causar perda de tráfego (blackhole), especialmente se o prefixo agregado for anunciado sem que as redes mais específicas estejam acessíveis ou roteáveis internamente. Por isso, é comum usar rotas nulas (null0) associadas ao prefixo sumarizado para garantir que pacotes que não casam com nenhuma rota específica sejam descartados de forma segura.


Em ambientes com route reflectors ou múltiplos roteadores, a sumarização pode ser feita com mais controle usando políticas de importação/exportação ou rotas estáticas para suportar o agregado.


A prática de sumarização bem feita ajuda a manter a estabilidade e previsibilidade da rede, além de ser uma das recomendações clássicas para melhorar a escalabilidade global do BGP, conforme descrito no RFC 4271.



Rotas mais específicas​

Rotas mais específicas são aquelas que têm uma máscara de rede mais longa, ou seja, que cobrem uma parte menor do espaço de endereços. Por exemplo, 192.168.1.0/24 é mais específica do que 192.168.0.0/16, e 192.168.1.128/25 é ainda mais específica que 192.168.1.0/24.


No roteamento IP, quando existem múltiplas rotas para o mesmo destino, o roteador sempre escolhe a rota mais específica, isso é chamado de longest prefix match. É assim que os sistemas tomam decisões de encaminhamento mais precisas.


No entanto, na internet pública, operadoras e provedores geralmente impõem restrições sobre o quão específicas as rotas podem ser. A prática comum é não aceitar prefixos mais longos que /24, ou seja, rotas como /25, /26, /27 etc. são rejeitadas pelos filtros de roteamento da maioria dos provedores. Isso é feito para evitar o crescimento excessivo da tabela global BGP e garantir maior estabilidade.


Por outro lado, prefixos menores (no sentido de máscara menor e rede maior), como /22, /21, /20, são normalmente aceitos e até incentivados, mas os provedores muitas vezes aplicam sumarização. Por exemplo, se você anunciar várias rotas contíguas como:

  • 10.1.0.0/24
  • 10.1.1.0/24
  • 10.1.2.0/24
  • 10.1.3.0/24

O provedor pode agregar isso como um único prefixo 10.1.0.0/22 na borda de sua rede, antes de propagar para os peers externos. Essa sumarização ajuda a reduzir o número de entradas na tabela global BGP e também oculta detalhes internos da topologia do cliente.


Portanto, embora você possa usar rotas mais específicas dentro da sua rede ou mesmo no BGP interno (iBGP), ao anunciar para a internet é importante respeitar a política comum de aceitar no máximo /24. Se quiser que sua rota seja propagada globalmente, certifique-se de que ela seja /24 ou menos específica (como /23, /22 etc.). Caso contrário, ela provavelmente será ignorada.



Configurar a Sumarização​

A sumarização no BGP funciona de formas diferentes dependendo do tipo de sessão.

No eBGP, você geralmente configura a sumarização via network com máscara mais ampla, desde que essa rota esteja presente na RIB local. Exemplo Cisco:

router bgp 65000
 network 192.168.0.0 mask 255.255.252.0

A rota 192.168.0.0/22 precisa existir na tabela de roteamento para ser anunciada.


Já no iBGP com Route Reflector, você também pode aplicar sumarização com aggregate-address, útil quando você quer consolidar várias rotas recebidas. Exemplo:

router bgp 65000
 address-family ipv4
  aggregate-address 192.168.0.0 255.255.252.0 summary-only

summary-only impede que as rotas mais específicas sejam anunciadas junto.

Se usar aggregate-address sem summary-only, ele anuncia tanto o agregado quanto os prefixos específicos.



Sumarizar ou anunciar uma rota já sumarizada?​

O fato de sumarizar não é só sobre "juntar prefixos" arbitrariamente, mas sim sobre fazer isso com segurança e controle. Imagine que você tenhas os seguintes prefixos:

  • 10.1.0.0/24
  • 10.1.1.0/24
  • 10.1.2.0/24
  • 10.1.3.0/24

Você pode anunciar diretamente o 10.1.0.0/22 se tiver certeza de que todas as sub-redes menores (/24) estão realmente em uso dentro da sua rede e que o tráfego para qualquer IP dentro desse /22 será encaminhado corretamente. Mas isso não é automaticamente o mesmo que "sumarizar" no BGP.


Quando você anuncia diretamente o /22 com network 10.1.0.0 mask 255.255.252.0, você está dizendo: "minha rede cobre toda essa faixa, de 10.1.0.0 a 10.1.3.255, e eu sou capaz de entregar pacotes para qualquer IP dentro dela."


Mas o BGP só vai propagar essa rota se esse prefixo /22 estiver na RIB (tabela de roteamento local). O que normalmente não vai ocorrer, já que você vai ter (num exemplo didático), quatro interfaces no seu router, sendo que cada interface vai ter configurado um /24 que seria o Gateway das redes.


Como você não tem esse /22, nada será anunciado no BGP. Uma alternativa seria criar uma rota estática apontando para null0:

ip route 10.1.0.0 255.255.252.0 null0

Isso serve como um "placeholder", garantindo que o prefixo exista na RIB e evitando que pacotes inválidos fiquem circulando sem destino. Nesse caso, você não precisa sumarizar via aggregate-address.


Mas o fato de sumarizar permite controlar com mais flexibilidade como o anúncio do agregado acontece, especialmente se:

  • Você aprende rotas mais específicas dinamicamente (ex: via iBGP ou redistribuição de OSPF/ISIS) e quer gerar um anúncio agregado com base nelas.
  • Você quer manter as rotas específicas para uso interno, mas esconder os detalhes ao anunciar externamente.
  • Você quer anunciar só o agregado, sem os /24 juntos (summary-only).
  • Ou ao contrário, quer anunciar o agregado e também os /24 (sem summary-only), para manter granularidade com redundância.

Nesse cenário, só seria válido o uso de rota estática se:

  • Você vai anunciar um prefixo agregado (como /22), mas a sua tabela de roteamento só contém os prefixos mais específicos (como os /24).
  • Você quer evitar loops de roteamento ou blackholes, se o tráfego chegar para um IP que não exista (porque, por exemplo, você removeu um dos /24 internos), ele será descartado silenciosamente.

O uso de sumarização nesse nosso cenário é o exemplo perfeito, porque você poderia anunciar o /22 sem precisar ficar criando rota estática apenas para anunciar um /22, podemos fazer do jeito certo.



Atomic Aggregation​

O atributo Atomic Aggregation no BGP serve para indicar que uma rota agregada foi criada com possível perda de informação sobre as rotas originais. Ele não altera a decisão de roteamento nem influencia o caminho escolhido, mas age como uma espécie de aviso.


Quando um roteador agrega vários prefixos em um único anúncio, por exemplo, ao criar um /22 a partir de vários /24 com origens distintas, ele pode não conseguir preservar todos os detalhes, como os diferentes AS_PATHs das rotas de origem. Nesse caso, ele marca a nova rota com o atributo Atomic Aggregation para sinalizar que nem todas as informações foram mantidas.


Esse comportamento é comum quando a agregação é feita com o comando aggregate-address sem o uso de mecanismos para preservar os ASs originais de forma precisa. O roteador pode também incluir o atributo AGGREGATOR, que identifica quem realizou a agregação (informando o ASN e o router ID que criaram o prefixo agregado).


Ambos os atributos são considerados opcionais e informativos, e na prática moderna, o Atomic Aggregation raramente tem impacto funcional. A maioria dos sistemas BGP atuais ignora sua presença, tratando-o apenas como uma herança de versões mais antigas do protocolo.


Ainda assim, ele pode aparecer em comandos como show bgp ipv4 unicast IP quando um roteador faz agregação de prefixos de forma simplificada.



AS_SET​

O AS_SET é uma estrutura usada no atributo AS_PATH do BGP para representar vários sistemas autônomos (ASNs) de forma não ordenada, geralmente como resultado de sumarização de rotas.


Normalmente, o AS_PATH no BGP é uma lista ordenada de ASNs que uma rota percorreu até chegar a você. Por exemplo, se uma rota veio do AS65001, passou pelo AS65002 e chegou até o seu roteador, o AS_PATH seria: 65001 65002.


Mas imagine que seu roteador aprenda duas rotas diferentes:

  • 10.1.1.0/24 com AS_PATH: 65010 65020
  • 10.1.2.0/24 com AS_PATH: 65030 65040

Se você fizer uma sumarização dessas rotas para 10.1.0.0/23, o roteador não consegue manter ambas as sequências de AS_PATH. Então, ele cria um novo AS_PATH com os ASNs envolvidos, mas sem garantir a ordem: {65010, 65020, 65030, 65040} (quando você repassar essa rota, normalmente nenhuma AS_PATH será mantido). Esse conjunto entre chaves é o AS_SET.


No BGP, AS_SETs são usados para evitar loops de roteamento, mas sem preservar a ordem dos sistemas autônomos envolvidos. Como consequência, rotas que contêm AS_SETs são menos preferidas na seleção de rotas, porque o BGP prefere caminhos com AS_PATHs mais simples e bem definidos.


Na prática, o uso de AS_SET tem diminuído muito. Muitos operadores e provedores evitam sumarização que gere AS_SET justamente para manter o AS_PATH limpo, previsível e mais eficiente. Ainda assim, o BGP suporta AS_SET como parte da sua especificação original, especialmente para cenários de agregação complexa.


Para gerar um AS_SET explicitamente durante a sumarização no BGP, o comando em Cisco IOS (e similares) é:

aggregate-address 10.1.0.0 255.255.254.0 as-set summary-only

Suponha que o AS 65000 aprenda:

10.1.1.0/24 via AS_PATH 65010 65020  
10.1.2.0/24 via AS_PATH 65030 65040

Com a nossa configuração de as_set, o BGP vai anunciar apenas 10.1.0.0/23, com um AS_PATH assim:

{65010 65020 65030 65040} 65000