O que e ASN

Definição formal: RFC 1930 e RFC 4271

A RFC 1930 (J. Hawkinson e T. Bates, março de 1996, "Guidelines for creation, selection, and registration of an Autonomous System") estabeleceu os critérios para que uma organização justifique a necessidade de um ASN. Três condições são aceitas: a organização tem múltiplas conexões a ISPs diferentes (multi-homing), tem uma política de roteamento própria e distinta dos provedores que usa, ou opera uma escala de rede que demanda gerenciamento BGP independente.

Um Sistema Autônomo é um conjunto de prefixos IP gerenciado por uma única entidade administrativa com política de roteamento coerente para o mundo externo. A palavra "autônomo" não significa que a rede opera isolada: significa que ela toma suas próprias decisões de roteamento, independentemente das políticas dos provedores de trânsito que usa.

O protocolo BGP-4 (Border Gateway Protocol version 4), definido pela RFC 4271 (Y. Rekhter et al., 2006), usa o ASN em dois campos críticos das mensagens UPDATE que os roteadores trocam: o campo AS_PATH, que lista a sequência de ASNs pelos quais o anúncio de rota passou (e serve para detectar loops), e o campo NEXT_HOP, que identifica o próximo salto para alcançar o prefixo anunciado.

ASNs de 16 bits e de 32 bits

Os ASNs originais eram de 16 bits, cobrindo valores de 1 a 65535. O valor 0 e o 65535 são reservados. Com a expansão da internet, esse espaço se aproximou do esgotamento. A RFC 6793 (2012, que atualizou a RFC 4893 de 2007) expandiu o espaço para 32 bits, cobrindo valores até 4.294.967.295.

A notação de ASNs de 32 bits tem dois formatos. A notação "asplain" usa o número inteiro diretamente: AS131072. A notação "asdot" divide em dois grupos de 16 bits separados por ponto: AS2.0 (porque 131072 = 2 * 65536 + 0). O LACNIC aloca por padrão ASNs de 32 bits desde janeiro de 2010. Organizações podem solicitar ASN de 16 bits apenas com justificativa técnica específica.

Como o BGP usa o ASN

O BGP é o protocolo de roteamento inter-domínio da internet. Funciona sobre TCP na porta 179 e usa quatro tipos de mensagem: OPEN (estabelece a sessão e apresenta o ASN), UPDATE (anuncia ou retira prefixos), NOTIFICATION (sinaliza erros) e KEEPALIVE (mantém a sessão ativa). Toda sessão BGP começa com os dois lados trocando seus ASNs no OPEN. Essa identificação é a base de toda a troca de rotas que segue.

Uma sessão BGP entre dois ASNs distintos é chamada de eBGP (external BGP). Dentro do mesmo AS, roteadores que precisam propagar as rotas aprendidas externamente usam iBGP (internal BGP). A diferença técnica principal: o AS_PATH não é modificado no iBGP (a rota já está dentro do mesmo AS), mas é acrescido de um novo ASN no eBGP a cada salto entre sistemas autônomos.

O campo AS_PATH e como ele funciona

O AS_PATH é o campo mais importante dos anúncios BGP do ponto de vista de roteamento. Ele lista todos os ASNs pelos quais o anúncio passou, do mais recente para o mais antigo. Quando um roteador recebe um UPDATE com o próprio ASN já no AS_PATH, ele descarta o anúncio: isso é a detecção de loop do BGP.

Um AS_PATH típico de um usuário Vivo no Brasil acessando um servidor AWS nos EUA pode ser: AS26599 (Vivo) → AS1299 (Telia, trânsito global) → AS16509 (Amazon AWS). O roteador do usuário no AS26599 aprende que para chegar ao prefixo do servidor, deve enviar pacotes para o roteador da Telia (AS1299), que então encaminha para a Amazon (AS16509).

O comprimento do AS_PATH é um dos fatores que o BGP usa para decidir qual é o melhor caminho quando existem múltiplas rotas para o mesmo destino. Um AS_PATH mais curto geralmente indica menos saltos entre redes. Mas não é o único fator: politicas de roteamento locais, MEDs (Multi-Exit Discriminators) e preferências manuais podem sobrescrever a escolha pelo AS_PATH mais curto.

Tipos de relacionamento entre sistemas autônomos

A internet é um tecido de acordos comerciais e técnicos entre sistemas autônomos. Existem três tipos principais de relacionamento:

• Trânsito. O cliente paga ao provedor (trânsito upstream) para que seus prefixos sejam anunciados para a internet inteira. O provedor anuncia todos os prefixos do cliente e fornece rotas completas (full table) para o cliente. É a relação padrão de qualquer ISP com o seu upstream global.
• Peering. Dois ASNs trocam rotas diretamente, sem custo de trânsito, mas apenas para os prefixos de seus próprios clientes. O AS A anuncia ao AS B apenas seus próprios prefixos e os de seus clientes; o B faz o mesmo. Tráfego que precisaria passar por um terceiro AS vai por trânsito, não peering.
• Parceiro / reseller. Variações comerciais do trânsito, como acordos regionais e resellers de conectividade, com políticas de roteamento específicas negociadas bilateralmente.

A diferença entre peering e trânsito tem implicação direta na latência e no custo. Dois ISPs brasileiros que fazem peering no IX.br em São Paulo trocam tráfego diretamente, sem passar por roteadores de backbone nos EUA ou Europa. Isso reduz latência e elimina o custo de trânsito para esse tráfego específico.

IXPs e peering: troca direta de tráfego

IXP (Internet Exchange Point) é uma infraestrutura física onde múltiplos ASNs se conectam para fazer peering de forma eficiente. Em vez de conectar bilateralmente a cada parceiro via circuito dedicado, todos se conectam à mesma fabric de switches do IXP e trocam rotas via BGP de route server.

O IX.br, operado pelo NIC.br, é o maior IXP do Brasil e um dos maiores do mundo em volume de tráfego. Presente em mais de 35 cidades brasileiras, o IX.br em São Paulo (PTT-SP) opera com picos de tráfego na casa de vários terabits por segundo. No início de 2026, centenas de ASNs participam do IX.br, incluindo grandes provedores, CDNs e empresas de conteúdo.

Para uma empresa ou provedor brasileiro, participar do IX.br significa que o tráfego trocado com outros participantes não precisa sair do Brasil. Um vídeo do Globoplay assistido por um assinante Vivo não precisa cruzar links internacionais se ambos participam do IX.br: o tráfego vai diretamente do AS da Globo para o AS da Vivo pelo ponto de troca em São Paulo ou no Rio de Janeiro.

Como obter um ASN

No Brasil, a solicitação de ASN é feita diretamente ao LACNIC em lacnic.net. O processo exige que a organização tenha ou justifique a necessidade de múltiplas conexões BGP com ASNs distintos, ou política de roteamento própria que não seja delegada integralmente a um único provedor.

O requerente precisa documentar a política de roteamento: com quais ASNs vai interconectar, quais prefixos serão anunciados, qual é a justificativa de multi-homing. O LACNIC pode revogar um ASN que permaneça inativo por mais de seis meses sem uso BGP efetivo.

Desde janeiro de 2010, o LACNIC aloca por padrão ASNs de 32 bits. ASNs de 16 bits só são concedidos mediante justificativa técnica específica, geralmente ligada a equipamentos legados que não suportam 32 bits.

Para startups e empresas de tecnologia brasileiras que montam infraestrutura própria (CDN, cloud privada, hosting), obter um ASN e um bloco /22 público do LACNIC é o passo que viabiliza multi-homing real e reduz dependência de um único provedor de trânsito. A taxa de manutenção anual junto ao LACNIC é acessível para PMEs.

Segurança de BGP: RPKI e sequestros de rota

O BGP foi projetado numa época em que todos os participantes da internet eram considerados confiáveis. Não há autenticação criptográfica nativa nos anúncios de rota: qualquer AS pode anunciar qualquer prefixo, e os outros AS só percebem o problema quando o tráfego para de fluir corretamente ou quando o erro já causou dano.

Sequestros de rota BGP acontecem quando um AS anuncia prefixos que não pertencem a ele, intencionalmente ou por erro de configuração. Em abril de 2010, um AS chinês anunciou erroneamente dezenas de milhares de prefixos da internet, redirecionando tráfego de EUA, Europa e Ásia pelo backbone da China por cerca de 18 minutos. Em 2018, o AS de uma pequena empresa nigeriana anunciou prefixos do Google, desviando tráfego de usuários que tentavam acessar o Gmail e o Google Search.

A solução em implantação global é o RPKI (Resource Public Key Infrastructure). O RPKI permite que o titular de um bloco de endereços IP assine criptograficamente um ROA (Route Origin Authorization), declarando qual ASN tem autorização para anunciar aquele prefixo. Roteadores BGP com validação RPKI ativa rejeitam automaticamente anúncios inválidos.

O LACNIC opera o repositório RPKI para a região América Latina e Caribe. Organizações brasileiras que registram prefixos no LACNIC podem criar ROAs via o portal do LACNIC. A adoção de RPKI entre ISPs brasileiros cresceu consistentemente nos últimos anos, mas ainda não é universal, especialmente entre provedores regionais de menor porte.

No IX.br, a comunidade técnica brasileira promove a adoção de RPKI como requisito de boa prática de peering. ISPs que não validam RPKI ficam expostos a aceitar anúncios inválidos que poderiam desviar o tráfego dos seus clientes. A ferramenta BGP.he.net permite verificar se qualquer prefixo tem ROA válido publicado no RPKI global.

Perguntas frequentes sobre ASN