IX e PIX: como a Internet troca tráfego e como conectar seu AS

Este guia técnico explica o Internet Exchange a partir do problema que ele resolve: como redes independentes trocam tráfego diretamente, onde essa infraestrutura fica hospedada e como conectar um Sistema Autônomo (AS) a ela. O foco é o modelo brasileiro do IX.br, operado pelo NIC.br, sem perder a visão universal de como os IXPs funcionam.

Ao final, o leitor sabe avaliar se vale a pena participar, escolher a localidade e o PIX, dimensionar a porta, preparar roteamento e segurança, solicitar adesão e colocar a conexão em produção.

Sobre este material: conteúdo consolidado a partir de fontes oficiais (IX.br, docs.ix.br, Registro.br, PeeringDB e RFCs), consultadas em setembro de 2026. Localidades, PIX, valores, requisitos e políticas mudam — confirme sempre a versão vigente antes de contratar ou configurar. Este é um material educacional e não substitui a documentação contratual nem o projeto executivo.

Por que o IX existe

A Internet não é uma nuvem única: é uma federação de milhares de redes independentes — provedores, clouds, CDNs, empresas, universidades, bancos e governos. Cada rede decide como alcançar as demais. Sem um ponto de troca, duas redes na mesma cidade podem enviar tráfego por um provedor de trânsito e percorrer um caminho maior do que o necessário.

O motivo real

• Localizar o tráfego: manter a comunicação regional próxima de usuários e conteúdo.
• Reduzir dependência: não concentrar todo o tráfego em um único upstream.
• Melhorar desempenho: reduzir saltos, latência, jitter e pontos de congestionamento.
• Melhorar economia: deslocar tráfego elegível do trânsito pago para relações de peering.
• Aumentar resiliência: criar caminhos adicionais entre redes e ecossistemas locais.
• Estimular o ecossistema: aproximar ISPs, conteúdo, nuvens, governo, finanças e educação.

Não é "Internet grátis": o IX carrega somente rotas disponibilizadas pelos participantes. Para alcançar o restante da Internet, normalmente ainda é necessário trânsito IP, peering privado ou outras interconexões.

Como o IX funciona

O núcleo de um IX é uma rede Ethernet de camada 2 — o fabric — distribuída entre pontos físicos. Cada participante conecta uma porta e recebe endereços da LAN de peering. Sobre essa LAN, estabelece sessões BGP com Route Servers e/ou peers bilaterais.

Fluxo simplificado

• Seu roteador anuncia ao Route Server os prefixos autorizados.
• O Route Server valida e exporta essas rotas conforme políticas e communities.
• Seu roteador aprende rotas dos demais membros e escolhe os melhores caminhos.
• Para um destino aprendido no IX, o pacote sai pela porta do IX e chega diretamente ao MAC do peer.
• Rotas não disponíveis no IX continuam usando trânsito IP ou outro caminho.

IX, PIX, CIX, transporte e trânsito

Regra de ouro: peering decide com quem trocar tráfego; transporte decide como chegar fisicamente ao IX; trânsito decide como alcançar o restante da Internet.

Onde o IX.br está hospedado

O IX.br é organizado por localidades metropolitanas. Cada localidade pode possuir vários PIX, conectados ao mesmo ambiente de troca. Os PIX podem estar hospedados em data centers comerciais, operadoras, universidades, redes acadêmicas, órgãos públicos e outras instituições qualificadas.

Estar no mesmo data center de um PIX reduz a complexidade da última milha, mas não é obrigatório — é possível contratar transporte L2 ou um CIX. A documentação oficial consultada em 2026 identifica localidades em quase todos os estados, de Aracaju, Belém e Belo Horizonte a São Paulo, Teresina e Vitória, passando por Brasília, Campinas, Curitiba, Fortaleza, Manaus, Porto Alegre, Recife, Rio de Janeiro e Salvador, entre muitas outras.

Exemplo de hospedagem distribuída: em Brasília, a lista oficial de PIX inclui instalações de data center, RNP, Telebras, Serpro, BR.Digital, SAMM e Eletronet. Outras localidades têm conjuntos próprios de PIX, e o fabric interliga esses pontos para que a localidade funcione como um único domínio de troca. A existência de uma localidade não significa que todos os conteúdos estejam presentes nela — antes de contratar, confira participantes, tráfego, políticas de peering e rotas efetivamente disponíveis.

Peering bilateral e multilateral

Quando usar cada um

• Comece pelo ATM para capturar rapidamente o valor do ecossistema.
• Adicione sessões bilaterais quando a política de um peer exigir ou quando houver benefício operacional.
• Avalie PNI quando o volume com uma única rede justificar porta/circuito dedicado, ou quando houver requisitos especiais de capacidade e isolamento.

Política de peering: cada AS deve documentar se sua política é aberta, seletiva ou restritiva; volumes mínimos; locais; capacidade; contatos de NOC; critérios de congestionamento e regras de anúncio. Uma conta no PeeringDB atualizada facilita a descoberta e as validações do ecossistema.

Route Servers e o caminho real do tráfego

O Route Server recebe rotas de muitos participantes e as redistribui conforme política, preservando o next-hop do originador. Assim, o seu roteador envia os pacotes diretamente ao peer. RS1 e RS2 oferecem redundância do plano de controle, mas não substituem a redundância física do acesso.

Recursos modernos do IX.br

• Validação de origem usando dados de registro, IRR e RPKI.
• Filtros de prefixos, bogons, AS-PATH e proteção contra anúncios indevidos.
• Communities para controlar exportação, prepend, localidade, RTT e perda.
• Suporte a graceful shutdown para manutenção controlada.
• Blackhole remoto para prefixos específicos, conforme política vigente.
• Mecanismos para mitigar hidden paths, incluindo add-path quando suportado.

Atenção: a política de communities evolui. Em julho de 2026, o IX.br publicou a versão 4.4 — use sempre a tabela oficial mais recente antes de configurar engenharia de tráfego.

Pré-requisitos técnicos e administrativos

Administrativos

• Ser uma organização apta a participar e possuir um Sistema Autônomo vinculado no portal.
• Criar usuário no Meu IX.br e vinculá-lo ao ASN.
• Aceitar e assinar os instrumentos de adesão aplicáveis.
• Manter contatos técnico, administrativo, financeiro e de NOC atualizados.
• Negociar separadamente com o PIX, transportador ou CIX os serviços físicos e comerciais.

Técnicos

• ASN próprio e recursos de numeração adequadamente registrados.
• Roteador com eBGP, IPv4 e preferencialmente IPv6, capacidade de filtros e communities.
• Interface Ethernet e óptica compatíveis com a porta/PIX contratado.
• Conexão camada 2 transparente até o fabric, sem NAT e sem roteamento intermediário na LAN de peering.
• Prefixos e objetos de roteamento consistentes; ROAs RPKI e dados IRR/PeeringDB atualizados.
• Controle de MAC, ARP/ND, broadcast e protocolos permitidos conforme a política técnica.
• Capacidade, redundância, monitoramento, segurança e equipe operacional 24x7 compatíveis com o serviço.

Formas de conexão

Perguntas ao fornecedor

• A entrega é porta dedicada, VLAN em porta compartilhada ou transporte até outro PIX?
• Qual a capacidade, MTU, SLA, latência, prazo e política de upgrade?
• Há diversidade real de rota, duto, POP, switch e energia?
• Quem fornece óptica, cross-connect, LOA/CFA e suporte em incidentes?
• Há proteção contra loop, tempestade, MAC excessivo e vazamento de protocolos?

Projeto de rede e dimensionamento

A porta não deve ser dimensionada apenas pela média. Observe pico, percentil 95, crescimento, horário de maior movimento, tráfego por peer e margem para falhas.

Regra operacional recomendada: defina gatilhos internos de expansão antes da saturação. Como referência de engenharia — não como regra do IX — muitas redes iniciam o processo de upgrade quando o uso sustentado alcança cerca de 60% a 70%, ajustando ao prazo de fornecimento e à tolerância de risco.

Redundância correta

• Dois roteadores ou chassis independentes.
• Duas portas e, quando viável, PIX distintos dentro da mesma localidade.
• Transportes por rotas físicas e fornecedores independentes.
• Energia e ópticas separadas.
• Sessões com RS1 e RS2, além de bilaterais críticos.
• Política que preserve o serviço durante manutenção ou falha parcial.

Passo a passo de adesão

Configuração BGP de referência

Modelo conceitual: endereços, ASNs dos Route Servers, communities e limites devem ser substituídos pelos valores fornecidos pelo IX.br e pela política vigente. Não copie para produção sem validação.

A estrutura lógica segue: interface Ethernet → VLAN de peering (quando aplicável) → IPv4/IPv6 da LAN → eBGP com RS1/RS2 → filtros de importação/exportação → política de preferência → monitoramento.

Princípios de política

• Exportação: anunciar somente prefixos próprios autorizados; anexar communities de engenharia quando necessário; negar todo o resto.
• Importação: rejeitar default, bogons e prefixos da LAN do IX; rejeitar RPKI inválido conforme a política interna; impor limites de tamanho de prefixo e de AS-PATH.
• Limites: definir max-prefix por sessão (com warning ou teardown conforme a política) e alertas antes do limite.
• Repetição: aplicar a mesma configuração para RS1 e RS2, em IPv4 e IPv6.

Segurança e boas práticas

Proteção do roteamento

• Crie e mantenha ROAs RPKI; trate anúncios inválidos de forma consciente.
• Mantenha route/route6 e AS-SETs no IRR quando utilizados.
• Exporte somente prefixos autorizados; nunca redistribua a tabela completa por acidente.
• Defina max-prefix por sessão e alertas antes do limite.
• Use filtros de bogons, martians, comprimentos de prefixo e AS-PATH anômalo.
• Aplique graceful shutdown em manutenções planejadas.
• Use autenticação BGP quando suportada e acordada.

Proteção da LAN de peering

• Permita somente protocolos e origens necessários na interface.
• Não habilite IGP, DHCP, RA indevido, STP ou protocolos de descoberta na porta.
• Aplique CoPP/CPPr e limites de ARP/ND conforme a plataforma.
• Não anuncie a LAN do IX para a Internet.
• Evite proxies ARP/ND e qualquer serviço desnecessário na interface.
• Monitore MAC flapping, broadcast, erros ópticos e mudanças inesperadas.

DDoS e blackhole: o Remote Triggered Black Hole pode descartar tráfego destinado a um host atacado para proteger o restante da rede. É uma medida extrema — validação, communities e prefixos aceitos devem seguir a documentação atual, e a equipe precisa testar o procedimento antes de uma crise.

Operação, monitoramento e troubleshooting

KPIs essenciais

• Estado e uptime das sessões; número de rotas IPv4/IPv6.
• Tráfego por direção, peer, aplicação e percentil.
• Erros, descartes, potência óptica, flap de interface e MAC.
• Latência, jitter, perda e traceroute para destinos representativos.
• RPKI/IRR, anúncios rejeitados e mudanças de política.
• Economia de trânsito e qualidade percebida pelo cliente.

NOC: mantenha runbooks, contatos de escalonamento, janelas, matriz de responsabilidade e evidências de testes. No IX, um problema pode envolver a sua rede, o transporte, o PIX, o fabric ou o peer.

Custos, benefícios e business case

Modelo simples de decisão: benefício mensal estimado = economia de trânsito + valor de desempenho + valor de disponibilidade − custo total recorrente do IX. O payback é o investimento inicial dividido pelo benefício líquido mensal. Além do cálculo, inclua os riscos: prazo de upgrade, falha de transporte, concentração de peers, operação e crescimento.

Decisão: um IX é atraente quando há tráfego significativo com participantes presentes, caminho físico eficiente e maturidade BGP. Volume bruto, sozinho, não garante retorno.

Cenários e topologias

Cenário A — provedor regional

O ISP mantém dois trânsitos IP e adiciona o IX por um CIX de 10 Gb/s. Começa no ATM, mede os top peers e, ao crescer, migra para porta dedicada e transporte redundante. Dois roteadores eBGP na borda, dois upstreams de trânsito e política que prefere peering quando qualidade e capacidade forem adequadas.

Cenário B — empresa com ASN próprio

Uma instituição com serviços digitais públicos participa para reduzir latência até ISPs e clouds. Mantém trânsito para alcance global, anuncia apenas serviços autorizados e reforça DDoS, RPKI e observabilidade.

Cenário C — CDN ou plataforma SaaS

A rede aproxima conteúdo das eyeball networks em múltiplas localidades. Usa ATM para cobertura, bilaterais para políticas específicas e PNI quando o volume bilateral justifica. O planejamento considera capacidade de cache, backhaul e retorno.

Cenário D — arquitetura de alta disponibilidade

Dois roteadores, duas portas, dois PIX e transportes por rotas independentes. Sessões RS1/RS2 e bilaterais críticos. Testes programados provam que a redundância existe de fato.

Checklist de prontidão

• Objetivo e indicadores de sucesso definidos.
• ASN, prefixos e contatos oficiais atualizados.
• ROAs, IRR/AS-SET e PeeringDB revisados.
• Localidade escolhida após análise de participantes e tráfego.
• PIX, transporte ou CIX contratado e com SLA conhecido.
• Roteador, interfaces, ópticas, MTU e capacidade validados.
• Políticas IPv4 e IPv6 aprovadas.
• Filtros, max-prefix, CoPP e communities revisados.
• Sessões RS1/RS2 e bilaterais planejadas.
• Monitoramento, NOC, runbook e escalonamento prontos.
• Teste de falha, rollback e critérios de aceite documentados.
• Gatilhos de upgrade e revisão trimestral definidos.

Perguntas finais para o decisor

• Quais destinos representam a maior parte do nosso tráfego?
• Essas redes estão presentes na localidade escolhida e aceitam peering?
• Quanto custa levar capacidade redundante até o PIX?
• Qual parcela do trânsito poderá realmente migrar?
• O ganho de qualidade é mensurável para os clientes?
• A equipe consegue operar BGP, segurança e incidentes 24x7?

Glossário essencial

Referências oficiais e leitura complementar

Fontes consultadas em setembro de 2026. Como localidades, PIX, valores, requisitos e políticas mudam, confirme sempre a versão vigente antes de contratar ou configurar.

• IX.br — portal, localidades, participantes, topologias e estatísticas: ix.br
• Documentação IX.br: docs.ix.br
• Adesão por localidade e relação dinâmica de PIX/CIX: docs.ix.br/adesao
• Meu IX.br — solicitações e gestão da participação: meu.ix.br
• Política de Requisitos Técnicos do IX.br — documento oficial
• Política de communities BGP e Route Servers v4.4 (21/07/2026) — documento oficial
• Registro.br — Recursos de Numeração e Sistema Autônomo: registro.br/tecnologia/numeracao
• PeeringDB — dados públicos de presença e política de peering: peeringdb.com
• RFC 4271 — Border Gateway Protocol 4: rfc-editor.org/rfc/rfc4271
• RFC 7947 / 7948 — operação e uso de Route Servers em IXPs

Nota editorial

Este material é educacional e não substitui a documentação contratual, a política técnica vigente, o projeto executivo ou a validação do IX.br, PIX, CIX e fornecedores envolvidos. Conectar redes diretamente é reduzir distância técnica, econômica e operacional.

NGG Tech: Cloud • Data Center • Baremetal • Storage • Conectividade • Suporte