Resumo executivo

  • RouteViews é um projeto de medição operado pela University of Oregon e pelo Network Startup Resource Center que recebe rotas BGP de redes voluntárias, registra instantâneos da Routing Information Base e mensagens de atualização e distribui os dados resultantes por arquivos MRT, streams ao vivo, uma API e um Looking Glass web.
  • O projeto surgiu de um experimento externo de 1995 envolvendo um primeiro feed MAE-WEST fornecido por Randy Bush e pela RAINET. David Meyer foi um arquiteto inicial de destaque na University of Oregon, enquanto a arquivamento diário sistemático começou pelo NLANR/MOAT em novembro de 1997.
  • Os coletores RouteViews observam o plano de controle de roteamento, mas não carregam tráfego de usuário comum, não originam um portfólio normal de prefixos de serviço e não têm autoridade para retirar, corrigir ou impor uma rota de outra rede. Seu valor é de natureza probatória: tornam visíveis anúncios, retiradas e caminhos selecionados a partir de pontos de vista de contribuição.
  • A revisão de janeiro de 2026 sobre 2025 reportou 883 sessões de rota completa de 277 sistemas autônomos únicos, oito novos coletores, 67 TB de armazenamento de RIB e atualização, expansão da API e do Looking Glass, modernização da infraestrutura Kafka e implantação do Bimper BMP. Esses números descrevem unidades distintas e não devem ser tratados como uma única contagem de coletores.
  • RouteViews é indispensável em parte porque seu arquivo não pode ser recriado depois do fato consumado. Também é incompleta por desenho: os peers BGP exportam rotas selecionadas por política, geralmente melhores caminhos, e o conjunto de pontos de vista voluntários inclui vieses geográficos, topológicos e de tipo de rede, redundâncias, artefatos de sessão e ruído operacional.
  • A questão de longo prazo do projeto é se uma camada observável, de acesso livre, com hospedagem institucional e parcialmente doada, consegue escalar armazenamento, software, equipe, replicação e governança enquanto a tabela de roteamento, o uso comercial e a demanda por acesso quase em tempo real continuam a crescer.

A internet não consegue se observar de um único lugar

A internet é frequentemente descrita como uma rede global, mas é operada como milhares de redes com controle independente. Cada sistema autônomo administra seus próprios roteadores, topologia interna, acordos de interconexão, políticas de exportação e objetivos operacionais. O Border Gateway Protocol permite que esses sistemas troquem informação de alcançabilidade, mas não cria uma sala de controle universal. Um operador consegue ver as rotas recebidas por seus próprios roteadores e as rotas selecionadas conforme sua política.

Ele não consegue ver automaticamente como cada rede distante está propagando os prefixes que origina, quais rotas alternativas foram ocultadas pela seleção do melhor caminho ou o que outro operador escolheu não exportar.

A ausência de visão completa não é uma falha temporária esperando por um painel suficientemente poderoso. Ela decorre da arquitetura. O BGP distribui informação parcial entre fronteiras administrativas. As redes revelam o que suas políticas permitem, e o estado do plano de controle resultante é diferente em locais diferentes. Uma rota pode ser visível em uma região, suprimida em outra, preferida por um provedor e substituída por um anúncio mais específico em outro ponto. Mesmo quando dois roteadores recebem o mesmo prefixo, podem selecionar caminhos diferentes porque seus relacionamentos comerciais e preferências locais diferem.

RouteViews existe dentro desse vazio estrutural. Não tenta se tornar a autoridade que decide qual rota está correta para o mundo. Propõe uma pergunta operacional mais estreita: que informação de roteamento uma rede contribuidora exportou para um coletor específico em um horário específico? Ao reunir muitas dessas respostas, preservá-las e torná-las reutilizáveis, RouteViews cria uma camada pública de observação para um sistema que não tem único proprietário e não possui memória nativa abrangente.

A distinção entre observação e controle é a base do projeto. Um coletor RouteViews participa de sessões BGP, mas não se comporta como um provedor transitário comum. Ele recebe rotas de peers e as registra. O perfil da PeeringDB para AS6447 informa zero prefixos IPv4 e IPv6 originados, um padrão de baixo tráfego e majoritariamente inbound, compatível com esse papel passivo. A RouteViews normalmente não envia rotas comuns de volta às redes que contribuem com dados.

Portanto, não pode redirecionar a internet ao publicar um caminho preferencial, reparar um vazamento editando a política de outro sistema autônomo ou retirar uma rota sequestrada em nome do titular legítimo.

Essa limitação é o que torna o projeto analiticamente honesto. A evidência pode mostrar que surgiu um novo originador inesperado, que um caminho mudou, que um anúncio mais específico se espalhou ou que uma rota desapareceu de vários pontos de vista. A evidência, por si, não prova o caminho físico percorrido pelos pacotes, o contrato comercial entre duas redes ou a intenção por trás da mudança. RouteViews torna o comportamento de roteamento mais observável. Operadores, pesquisadores e sistemas de segurança ainda precisam interpretar esse comportamento e combiná-lo com logs locais, dados RPKI, medição de plano de dados e comunicação direta.

É um tipo de infraestrutura em que o resultado é conhecimento, não transporte. Os coletores estão conectados ao sistema de roteamento em tempo real, o arquivo registra suas mudanças e os serviços de acesso distribuem esses registros. O projeto importa porque decisões operacionais críticas dependem de evidência sobre sistemas que nenhum participante consegue inspecionar sozinho. Sua contribuição não é comando soberano sobre o roteamento. É um método duradouro para ver partes selecionadas da realidade de roteamento a partir de fora da rede que busca se compreender.

Da visão MAE-WEST a uma utilidade pública

RouteViews começou em 1995, quando looking glasses web públicos ainda não eram parte rotineira das operações de rede. O problema original era prático. Uma rede podia originar um prefixo e verificar se seus próprios roteadores estavam configurados corretamente, mas permanecia incerta sobre como os provedores viam o anúncio em outros lugares. A resolução de problemas de dentro da rede de origem não respondia à questão externa. O operador precisava de uma visão fora de sua própria fronteira administrativa.

Material histórico do projeto registra um feed externo inicial no MAE-WEST, um dos ambientes de interconexão importantes da época. Randy Bush, por meio da RAINET, forneceu a visão. O relato posterior de David Meyer descreve a recepção de uma sessão eBGP multihop na University of Oregon e a adição de peers, pesquisadores e sistemas à medida que o uso se expandia. A evidência sustenta descrever Meyer como um arquiteto e operador inicial principal. Não sustenta reduzir a origem a uma narrativa de único fundador.

O feed de Bush, o Advanced Network Technology Center da University of Oregon e os operadores que voluntariamente forneceram visões adicionais faziam parte da construção do sistema.

O hostname de serviço original, route-views.oregon-ix.net, refletia seu propósito inicial restrito. Usuários podiam conectar a um roteador e inspecionar informações BGP aprendidas externamente sem receber privilégios de configuração nem tornar-se clientes de trânsito. O valor estava em separar papéis: a rede contribuidora fornecia uma visão, a University of Oregon hospedava o acesso e o operador consultante ganhava perspectiva. Nenhuma instituição central precisava certificar a rota para que a visão fosse útil.

O uso gerou um ciclo de reforço. Operadores encontraram valor na perspectiva externa. Isso incentivou mais redes a contribuir com feeds. Feeds adicionais tornaram a ferramenta mais útil porque expunham diferenças entre provedores e localizações. Pesquisadores então reconheceram que observações repetidas poderiam responder perguntas além da resolução imediata de problemas. Uma tabela ao vivo mostrava como uma rede via o mundo em um momento; uma sequência de tabelas revelava crescimento, mudança de política, instabilidade e resposta a falhas no tempo.

O projeto, portanto, evoluiu de serviço para utilidade sem uma fronteira fundadora nítida. Não foi lançado como uma plataforma global de medição completa com roteiro de produto definido, equipe dedicada e arquitetura distribuída. Acumulou essas propriedades porque os usuários mantiveram à mostra os limites da forma anterior. A história importa porque explica o caráter institucional que permanece visível hoje. RouteViews é um serviço de produção, um conjunto de dados acadêmico, uma colaboração entre operadores e uma dependência de infraestrutura pública ao mesmo tempo.

Essa identidade híbrida também explica por que o projeto não deve ser descrito como uma empresa incorporada separadamente. Registros atuais o colocam dentro da University of Oregon e operacionalmente no Network Startup Resource Center. Suas interfaces públicas têm nomes, um ASN, um DOI, repositórios de software e políticas de peering, mas não personalidade jurídica separada, acionistas, demonstração de receita ou diretoria independente verificada. A autoridade do projeto vem de operar coletores, manter dados e sustentar participação contínua — não da propriedade corporativa das rotas que observa.

Assim, a história de origem é mais instrutiva tratada como mecanismo de infraestrutura do que como biografia heroica. Um operador de rede contribuiu com uma visão útil. Uma equipe universitária expôs essa visão com segurança. Mais redes aderiram voluntariamente. Os usuários geraram demanda. O arquivamento transformou estado transitório em evidência reutilizável. Cada passo tornou-se real porque pessoas configuraram roteadores, executaram sistemas e usaram o resultado. Nenhuma declaração tornou RouteViews importante antecipadamente. A importância emergiu de uma dependência operacional repetida.

Como um looking glass ao vivo virou um arquivo histórico

Uma visão ao vivo pode resolver um problema atual de troubleshooting, mas não responde como era o sistema de roteamento ontem, a menos que alguém o tenha registrado. O NLANR/MOAT iniciou em novembro de 1997 o arquivamento diário sistemático da saída da RouteViews. Esse ato mudou a natureza do projeto. O serviço deixou de ser apenas um local onde um operador podia inspecionar o estado atual. Tornou-se uma memória das mudanças contínuas do plano de controle da internet.

Os primeiros arquivos consistiam em despejos diários de saída de comandos. Esses arquivos foram valiosos por preservar informação que desapareceria, mas sua cadência e formato limitavam o que podia ser reconstruído. Uma rota podia ser anunciada, alterada e retirada entre dois snapshots sem aparecer em nenhum deles. Texto raspado da linha de comando de um roteador também era menos adequado para análise programática padronizada do que um registro binário pensado para representar estado de protocolo.

Em março de 2001, RouteViews ampliou a coleta de tabelas para cadência de duas horas. O intervalo permanece associado aos arquivos atuais de RIB do projeto. Um snapshot de RIB responde a uma pergunta de estado: quais rotas esse coletor mantinha no momento da captura? Ele não explica sozinho todas as mudanças ocorridas antes ou depois do snapshot. Para isso, os analistas precisam do fluxo de atualizações — anúncios, retiradas e mudanças de atributos observadas entre estados.

Essa transição para gravação local de MRT foi, portanto, mais importante do que apenas aumentar a frequência dos arquivos. MRT oferece estrutura legível por máquina para mensagens de roteamento, informação de peers, mudanças de estado e conteúdos de RIB. Um coletor pode registrar atualizações à medida que chegam e exportar periodicamente estado de tabela sem depender de milhares de usuários remotos executando comandos show. Os arquivos resultantes podem ser processados por ferramentas como BGPStream, BGPKIT, bgpdump e software de pesquisa personalizado.

Essa arquitetura viabilizou um fluxo analítico comum. Um pesquisador carrega um snapshot de RIB para estabelecer estado inicial, depois aplica atualizações subsequentes para reconstruir como esse estado mudou. O método suporta estudo de mudanças de origem, mudanças de caminho, retiradas, deagregação e propagação de eventos. Também evidencia a importância da integridade dos dados. Um arquivo de atualização ausente, uma sessão interrompida, um erro de parser ou uma interrupção de coletor pode criar uma lacuna entre o estado reconstruído e o que o peer efetivamente exportou.

O arquivo de longa duração é um dos ativos mais fortes de RouteViews porque evidência histórica de plano de controle não é renovável. Um novo coletor pode começar a observar amanhã, mas não consegue recriar um anúncio de rota que não foi registrado em 1998, 2008 ou 2018. O arquivo permite que pesquisadores examinem crescimento de tabela, adoção de IPv6, aparecimento e desaparecimento de sistemas autônomos, mudanças de estrutura de caminho e efeitos de roteamento de incidentes importantes ao longo de décadas.

“Contínuo desde 1997” deve, no entanto, ser interpretado como continuidade do programa, não como garantia de que cada coletor, peer e arquivo esteve presente sem interrupção. Sistemas distribuídos passam por manutenção, reinícios, falhas de rede e intervalos faltantes. O arquivo mais antigo também difere materialmente do método atual em formato, frequência e cobertura geográfica. Um uso responsável dos dados identifica os coletores e períodos relevantes em vez de tratar todo o arquivo como um instrumento uniforme.

Assim, o valor do arquivo vem tanto de profundidade quanto de limitação documentada. É um registro de observações, não uma verdade histórica perfeita. Preserva o que roteadores participantes exportaram aos coletores disponíveis nas condições operacionais do momento. Isso é suficiente para sustentar grande trabalho científico e operacional, desde que o usuário não confunda um registro longo com onisciência.

Centralização fracassou antes de a distribuição se tornar estratégia

O modelo original da RouteViews concentrava muitos feeds e usuários em um roteador central. Em meados de 2000, um Cisco 7200VXR lidava com mais de 50 sessões BGP multihop e cerca de 5.000 logins interativos por dia. O sistema tinha se tornado útil o bastante para ultrapassar a arquitetura que o criou. CPU, memória, estabilidade de sessão e acesso via linha de comando competiam na mesma superfície operacional.

A primeira resposta foi adicionar novo software. RouteViews lançou o route-views2 em outubro de 2001 usando Zebra BGPD no Linux. A migração para sistemas commodity e roteamento de código aberto foi estrategicamente significativa porque um coletor não precisa de hardware completo de encaminhamento de um roteador central que carrega tráfego. Precisa de uma implementação BGP confiável, memória suficiente para manter tabelas de roteamento e mecanismos para registrar estado. O roteamento por software ofereceu menor custo e maior potencial de automação.

O Zebra inicial não resolveu imediatamente o problema. Material histórico registra dificuldade para lidar com cerca de 60 peers. A lição é importante para análise de infraestrutura moderna: substituir hardware proprietário por software aberto não é automaticamente uma atualização de capacidade. O roteamento em produção depende de maturidade de implementação, comportamento de memória, correção de protocolo, observabilidade e recuperação de falhas. RouteViews manteve e melhorou hardware enquanto a trilha de software evoluía.

A resposta mais duradoura foi a separação arquitetural. A gravação MRT reduziu dependência de scraping interativo por CLI. Múltiplos coletores reduziram a dependência de um único sistema. Camadas dedicadas de arquivo e processamento separaram o acesso de usuários da coleta de protocolo. Cada separação atribuiu responsabilidade a um componente desenhado para aquela carga, em vez de permitir que um único roteador atendesse peers, arquivasse dados e satisfizesse simultaneamente milhares de consultas humanas e automatizadas.

O modelo multihop central também tinha fragilidade conceitual. A sessão BGP de um peer com um coletor no Oregon poderia depender da mesma internet pública cuja falha o projeto buscava observar. Se um evento interrompia a alcançabilidade entre peer e coletor, a sessão podia desaparecer, gerando ambiguidade sobre se a rota mudou, o peer falhou ou o caminho até o sistema de medição quebrou. A distância geográfica também limitava visibilidade de interconexão local que talvez nunca se propagasse por um provedor distante.

Assim, a distribuição surgiu como requisito de escala e de medição ao mesmo tempo. O projeto precisava de coletores mais próximos das redes que fornecem dados, especialmente em internet exchanges onde muitos sistemas autônomos poderiam estabelecer sessões BGP locais. Um coletor regional podia observar servidores de rota e peers bilaterais sem exigir que toda contribuição atravessasse um longo caminho multihop até Oregon.

Essa transição é exemplo recorrente de padrão de infraestrutura. Uma ferramenta central torna-se popular por simplificar acesso. O crescimento então expõe concentração de carga de trabalho, falha e interpretação. A solução não é negar o valor do centro, mas dividir coleta, armazenamento e acesso para que o centro coordene um sistema distribuído em vez de fingir que encarna o próprio sistema.

Por que o projeto migrou para as malhas de internet exchange

RouteViews começou a aceitar feeds IPv6 em maio de 2003 e implantou seu primeiro coletor documentado em exchange, o DIX-IE em Tóquio, em julho daquele ano com apoio do WIDE Project. Novos coletores vieram em ISC/PAIX em outubro de 2003, LINX em Londres em março de 2004 e Equinix Ashburn em maio de 2004. Essas implantações criaram o modelo que hoje define boa parte da plataforma: um coletor RouteViews ligado diretamente ao ambiente de uma exchange e recebendo sessões eBGP locais de redes presentes ali.

Um coletor em IXP tem várias vantagens. A adjacência BGP pode ser estabelecida no tecido local compartilhado, em vez de por uma sessão multihop pela internet pública. O coletor pode recrutar múltiplas redes já concentradas em um mesmo local. Pode receber um feed do route server da exchange, que pode representar rotas de muitos participantes. Pode também observar interconexão local ou regional que não aparece por meio de um provedor de trânsito global.

Vantagem é informacional, não mágica. Um coletor em exchange ainda enxerga apenas o que seus peers exportam. Uma rede pode enviar uma tabela completa, prefixos de cliente selecionados, rotas locais ou uma visão mais limitada. Um feed de route server representa a política e a adesão daquele servidor, não todos os relacionamentos bilaterais da exchange. A presença física em uma IXP não torna a RouteViews operadora da exchange nem dona das redes conectadas.

O modelo distribuído também depende de hosts. RouteViews normalmente solicita a uma exchange ou rede que forneça uma máquina virtual ou servidor, uma porta de exchange, conectividade de trânsito ou gestão, energia, refrigeração e assistência local. A equipe centraliza configuração, automação, integração e suporte operacional. Essa arranjo torna a implantação global economicamente viável sem a necessidade de a RouteViews construir instalações próprias em cada região.

O modelo de contribuição em espécie cria uma dependência específica. Um coletor pode desaparecer se o host muda prioridades, remove a porta, encerra o trânsito ou desativa a máquina virtual. Hardware, ambiente de hipervisor e rede local podem variar. A automação central precisa, portanto, produzir comportamento consistente em infraestrutura que não é totalmente própria nem fisicamente controlada pela University of Oregon.

A expansão recente mostra por que a presença em exchange continua estrategicamente importante. Em 2025, RouteViews adicionou coletores na Costa Rica, Filipinas, Hong Kong, Indonésia, Romênia, Nigéria, Suécia e Dinamarca. As localizações incluíram CRIX, sites GetaFIX em Manila, Cebu e Davao, HKIX, IIX em Jacarta, InterLAN em Bucareste, IXPN em Lagos e sites Netnod em Estocolmo e Copenhague. Em fevereiro de 2026, o NSRC informou um novo coletor no DE-CIX Frankfurt.

Essas adições não são apenas pontos em um mapa global. Elas respondem a uma mudança na topologia da internet. Grandes plataformas de conteúdo, CDNs e redes regionais passam a trocar tráfego cada vez mais localmente. Um coletor que vê só rotas de trânsito hierárquico pode perder relacionamentos e políticas que permanecem próximos da borda. A política de peering seletivo de 2025 da RouteViews prioriza explicitamente regiões e redes que adicionam visibilidade distintiva, em vez de tratar toda sessão adicional como igualmente valiosa.

O projeto continua a operar coletores multihop porque nem todo peer útil compartilha uma IXP com AS6447. Os dois modelos cumprem propósitos diferentes. Sessões locais em IXP melhoram visibilidade regional e de troca. Sessões multihop ampliam participação para grandes backbone, redes de pesquisa ou operadores especializados em outros lugares. Uma estratégia completa precisa de ambos, reconhecendo a dependência de trajetória e os limites interpretativos de cada um.

O que realmente registra um coletor RouteViews

Um peer RouteViews estabelece uma sessão BGP e exporta rotas conforme sua própria política e as exigências de peering do projeto. O coletor recebe essas rotas em uma base de informação de roteamento BGP. Registra estado e mudanças da tabela, mas não tem função normal de encaminhamento para as rotas. Pacotes de usuários comuns não são enviados pelo coletor apenas porque o coletor aprendeu um caminho.

A palavra “rota” pode esconder diferentes tipos de informação. Para um prefixo, um registro BGP pode incluir o sistema autônomo de origem, o AS path, next-hop, communities e outros atributos. Uma atualização registra um anúncio, uma retirada ou mudança. O coletor associa a mensagem a um peer e a um horário. Os analistas podem então comparar o que diferentes peers exportaram e como a visibilidade mudou.

O registro não revela toda a infraestrutura subjacente. Um AS path não é um mapa físico de fibra. Não mostra todos os roteadores dentro de cada sistema autônomo nem identifica toda a instalação atravessada. Não divulga capacidade de enlace, volume de tráfego ou condições contratuais comerciais. O caminho representa informação de plano de controle usada para decidir alcançabilidade, e atributos BGP podem ser transformados por política.

A distinção entre rotas completas e todos os caminhos é especialmente importante. RouteViews prioriza peers que enviem uma visão de rota completa, isto é, rotas cobrindo a maioria dos prefixos globalmente alcançáveis. A exportação padrão do BGP normalmente envia o melhor caminho selecionado para cada prefixo, não todos os caminhos alternativos conhecidos internamente. RouteViews não aceita Add-Path em sua política atual. Um feed de rota completa, portanto, melhora cobertura de prefixos e topologia sem expor o conjunto interno completo de decisões de um peer.

Uma sessão de route server adiciona outra camada. Em uma exchange, o route server recebe rotas de muitos participantes e as redistribui conforme sua política. Uma única sessão RouteViews com esse servidor pode revelar rotas locais de muitas redes. Ainda assim, o peer é o route server, enquanto os caminhos representados se originam em outro lugar. Os analistas não devem interpretar a presença de um ASN nos dados como prova de relacionamento comercial direto com RouteViews ou mesmo de acordo bilateral de peering na exchange.

Por isso, as ferramentas internas modernas de RouteViews distinguem observações bilaterais e por route server. Pela política seletiva, o projeto pode recusar uma sessão bilateral que não adiciona informação significativa além de um feed de route server existente. O objetivo não é a maior contagem possível de adjacências. É um conjunto útil de perspectivas com diversidade, estabilidade e valor regional suficiente para justificar custo operacional.

A passividade do coletor também define o limite de segurança. RouteViews pode mostrar que uma rota com origem inesperada estava visível para um peer. Pode expor um anúncio mais específico ou a propagação de uma rota inválida quando combinado com dados RPKI. Não pode decidir que a rota deve ser removida de outra rede. A aplicação de controles permanece com operadores locais que acionam filtros, validação de origem de rota, limites de prefixo e procedimentos de incidente.

O conjunto de dados resultante é poderoso porque está próximo da operação real e, ao mesmo tempo, cuidadosamente limitado. Registra mensagens de protocolo de redes de produção. Não é um registro de verdade contratual, nem um rastreamento de pacotes de tráfego de usuários, nem um oráculo central de roteamento. Toda análise válida começa respeitando esse limite.

Coletores, sessões, sistemas autônomos e pontos de vista não são equivalentes

A escala atual da RouteViews costuma ser expressa por vários números que respondem a perguntas diferentes. A revisão operacional de janeiro de 2026 reportou 883 sessões recebendo rotas completas de 277 sistemas autônomos únicos. Uma apresentação de fevereiro de 2026 descreveu uma rede com mais de 40 coletores, embora alguns slides trazessem data de atualização de maio de 2025. O PeeringDB listou 26 conexões públicas de exchange para AS6447 em 29 de julho de 2026. Esses dados podem coexistir porque descrevem camadas distintas da plataforma.

Um coletor é um roteador ou instância de software de roteamento que recebe sessões BGP. Uma sessão é uma adjacência entre um endereço de peer e um coletor. Um sistema autônomo pode fornecer múltiplas sessões em múltiplas localizações, em IPv4 e IPv6, ou por meio de route server e relações bilaterais. Um ponto de vista é a perspectiva observacional gerada por uma sessão ou por um roteador contribuidor. Uma conexão de exchange é a presença de AS6447 em um tecido específico. Nenhuma dessas unidades tem mapeamento um-para-um com as outras.

Essa distinção importa para independência analítica. Duas sessões do mesmo ASN em exchanges diferentes podem revelar políticas e caminhos realmente distintos. Também podem ser altamente redundantes. Uma sessão de route server pode expor centenas de origens de participantes, mas ainda representar um contexto de política de exchange único. Um coletor com muitos peers pode produzir uma visão local ampla, enquanto um coletor com um peer incomum pode contribuir com informação mais única para uma pesquisa específica.

Os 20% de crescimento em sessões de rota completa em 2025, portanto, não devem ser lidos como melhora de 20% na visibilidade global. Mais de 50 peers existentes alteraram sua política de exportação para enviar rotas completas, e 28 novos peers de rota completa foram adicionados. Isso aumenta a quantidade de dados de tabela utilizáveis, mas o ganho incremental depende de onde esses peers estão, o que exportam e quais caminhos já eram visíveis em outras fontes.

Pesquisas sobre o problema dos “pontos mais valiosos” tornam essa dependência explícita. Um ponto de vista que melhora detecção de sequestro pode não ser o mesmo que mais contribui para inferência de relações AS. Remover ou amostrar peers aleatoriamente pode reduzir precisão de forma desigual. A política seletiva do projeto, portanto, é uma transição de contar feeds para avaliar o que cada feed adiciona.

Não foi encontrada no registro público uma relação de coletores ativa e alinhada por data. O número de mais de 40, as oito adições e as 26 conexões de exchange do PeeringDB não devem ser combinados em um total fabricado. Não é detalhe menor de relato. Um inventário público com status operacional, localização, tipo de sessão e continuidade de arquivo permitiria aos usuários entender quais perspectivas estavam disponíveis para uma análise.

As métricas de escala continuam significativas quando usadas corretamente. Elas mostram que RouteViews não é mais um roteador universitário isolado. É um sistema distribuído com centenas de sessões de rota completa, centenas de ASNs contribuintes, dezenas de coletores e presenças em exchanges por região. A disciplina analítica é preservar a unidade associada a cada número.

Snapshots de RIB, fluxos de atualização e reconstrução do estado de roteamento

O arquivo da RouteViews é construído em duas formas complementares de evidência. Snapshots de RIB registram as rotas que um coletor mantinha em um momento específico. Arquivos de atualização registram anúncios e retiradas observados entre snapshots. A documentação atual descreve cadência de RIB em duas horas e arquivos de atualização agrupados em intervalos de 15 minutos.

Os intervalos são convenções de empacotamento, não garantias de que todos os eventos ocorram nesses limites. As atualizações BGP chegam continuamente. O coletor as agrupa para distribuição. A exportação de um RIB também pode levar tempo para ser produzida, especialmente à medida que as tabelas crescem. Analistas precisam entender carimbos de tempo, comportamento de coletor e completude dos arquivos em vez de tratar cada nome de arquivo como uma amostra instantânea perfeita.

Reconstruir estado geralmente começa com um RIB e depois aplica atualizações posteriores em ordem. Isso permite perguntar se a origem de um prefixo mudou, como um anúncio se propagou ou por quanto tempo uma retirada permaneceu visível. O método também revela como eventos de coletor podem ser confundidos com eventos de internet.

O reset de sessão BGP é o exemplo clássico. Quando uma sessão é restabelecida, o peer pode transferir sua tabela novamente. O pico de atualizações resultante pode parecer mudança ampla de roteamento mesmo que a topologia global não tenha mudado da mesma forma. A pesquisa sobre identificação de transferências de tabela de roteamento desenvolveu métodos para diferenciar esses padrões quando os logs explícitos de sessão são incompletos.

Um peer que para de enviar dados silenciosamente apresenta problema distinto. O coletor pode continuar operando enquanto um ponto de vista fica obsoleto ou ausente. Um arquivo pode existir e ainda conter menos informação que o esperado. Em contrapartida, um peer pode gerar volume extremo de atualizações via flapping, mudanças de atributos, deagregação, defeitos de software ou retransmissão repetida de tabela.

Esses comportamentos criam a escolha não resolvida entre fidelidade e filtragem. Preservar toda mensagem observada mantém evidência de instabilidade e má configuração. Também aumenta armazenamento, carga de processamento e risco de análises ingênuas contarem ruído repetitivo como mudança significativa global. Filtrar ruído pode melhorar usabilidade, enquanto também remove a evidência que outro pesquisador pode querer estudar.

A revisão de 2025 de RouteViews descreveu monitoramento de impacto por peer e capacidade de desativar sessões que ameaçam a estabilidade da plataforma. Esse é um controle operacional necessário, mas introduz uma questão de governança e documentação: quando um feed deixa de ser evidência valiosa e passa a ser risco de infraestrutura inaceitável? Não existe regra pública universal que elimine o julgamento, porque a resposta depende de volume, causa, valor analítico e saúde do serviço.

O valor do projeto, portanto, depende de mais do que coletar mensagens. Depende de registrar metadados suficientes, monitorar saúde de sessões, preservar arquivos, documentar mudanças e ajudar usuários a distinguir eventos de roteamento de artefatos de medição. O arquivo é um instrumento. Como qualquer instrumento, precisa de calibração e interpretação.

O backend atual: FRRouting, BMP, Bimper e Kafka

A identidade histórica da RouteViews está associada a arquivos MRT e acesso direto a roteador, mas sua plataforma atual inclui uma arquitetura de software e streaming mais ampla. Apresentações de 2026 descreveram o Ubuntu Server 24.04 como sistema operacional padrão dos coletores e FRRouting 10.5 em coletores de software, com um Cisco ASR1004 mantido enquanto o projeto continuava a migrar de appliances físicos para máquinas virtuais.

A migração para coletores de software muda o modelo operacional. Uma máquina virtual padrão pode ser hospedada por uma exchange ou rede com hardware menos especializado, e configuração pode ser automatizada entre sites. A especificação de host publicada pela RouteViews exige pelo menos 16 GB de memória, preferencialmente 32 GB, quatro CPUs virtuais, 100 GB de armazenamento, uma interface de gerenciamento ou trânsito e uma interface voltada para exchange. Esses requisitos descrevem o nó de coleta, não o espelho central de arquivo ou de stream.

Coletores produzem arquivos MRT para arquivo histórico e também podem exportar estado BGP via BGP Monitoring Protocol. O BMP foi projetado para expor informação de roteamento de um roteador para sistemas de monitoramento sem tornar esses sistemas participantes da seleção de rotas. Na arquitetura da RouteViews, o Bimper recebe registros BMP dos coletores, encaminha mensagens brutas compatíveis ao Kafka e exporta métricas operacionais por meio do Prometheus. A ferramenta bimperctl permite à equipe inspecionar conexões e status de serviço.

Bimper foi desenvolvido porque OpenBMPd encontrou problemas de estabilidade sob a carga da RouteViews. Esse detalhe é importante porque mostra RouteViews como operadora de infraestrutura de software, não apenas usuária de ferramentas existentes. O projeto tinha um gargalo de produção no caminho de dados em tempo real e construiu um componente para suportar sua própria escala e requisitos de observabilidade.

Kafka fornece uma camada de distribuição entre coleta e consumidores. Sem essa camada, cada sistema downstream poderia consultar coletores diretamente ou manter lógica separada de processamento por sessão. Uma plataforma de stream pode tratar fan-out, backpressure e independência de consumidores de forma mais eficiente, embora crie suas próprias dependências de confiabilidade, ordenação, retenção e operação.

O arquivo e o stream ao vivo atendem necessidades diferentes. A pesquisa histórica valoriza completude, reprodutibilidade e capacidade de reprocesar um período com novos métodos. O monitoramento ao vivo valoriza baixa latência e entrega contínua. Um stream pode reconectar e retomar de forma imperfeita; um arquivo pode chegar depois, mas preservar arquivo estável. RouteViews precisa de ambos porque usuários operacionais e pesquisadores fazem perguntas distintas sobre as mesmas observações de base.

Esse backend também aumenta a importância do monitoramento. Um coletor pode estar saudável enquanto sua conexão BMP falha. Kafka pode aceitar dados enquanto um consumidor atrasa. Arquivos MRT podem ser escritos enquanto um stream ao vivo está atrasado. Métricas Prometheus e ferramentas de controle de serviço tornam esses estados internos visíveis para os operadores que mantêm a plataforma. O produto central da RouteViews é observabilidade, e sua própria infraestrutura também precisa ser observável.

API e Looking Glass separam usuários dos coletores

O acesso telnet direto fazia sentido quando a RouteViews atendia uma população gerenciável de operadores humanos. Com o tempo, scripts automatizados passaram a emitir milhares de comandos contra interfaces de coletores. Um roteador desenhado para manter sessões BGP e registrar rotas virou uma máquina de consulta sem limites. O resultado repetiu o problema original do roteador central na camada de acesso: abertura útil gerou carga que ameaçava o sistema que produzia os dados.

RouteViews respondeu com a construção de um Looking Glass baseado em navegador e de uma API estruturada. O Looking Glass foi lançado em maio de 2025 e suporta consultas de prefixo comum, expressão de caminho, resumo e buscas orientadas a RPKI em nós selecionados. No lançamento, seu backend ainda traduziu requisições web em comandos executados via interface telnet. A direção pretendida era migrar mais consultas para a API à medida que a cobertura se expandia.

A API cobre atualmente dez coletores: AMS-IX em Amsterdã, LINX em Londres, NAPAfrica em Johanesburgo, Equinix SG1 em Cingapura, Equinix SYD1 em Sydney, IX.br em São Paulo e quatro coletores multihop na University of Oregon. Ela expõe metadados de coletor, informação de RIB, informação de peers, AS adjacentes e prefixos aprendidos de sessões especificadas. Os metadados são atualizados a cada dois minutos.

A API é explicitamente desenhada para dados atuais, e não para pesquisa histórica profunda. Essa separação evita um erro comum de produto. Um serviço de consulta em tempo real e um arquivo em lote de múltiplas décadas têm estruturas de indexação, armazenamento e custo diferentes. Tentar fazer uma única interface servir ambos pode degradar cada um. RouteViews direciona análise longitudinal para arquivos MRT, enquanto oferece acesso estruturado para perguntas frequentes de estado atual.

A API também apoia operações internas. RouteViews desenvolveu ferramentas que comparam um peer potencial com prefixos originados, observações bilaterais e por route server existentes, contribuição regional e cobertura de coletores. Algumas ferramentas podem gerar ou modificar configuração de coletor. Isso reduz esforço e erro manuais, mas cria nova dependência de registros PeeringDB precisos e de automação segura.

O Looking Glass e a API conseguem restringir carga de formas que o acesso CLI direto não consegue. Podem limitar tipos de consulta, cachear respostas repetidas, aplicar autenticação ou controle de taxa e retornar resultados estruturados. Também simplificam acesso para usuários que não querem parsear arquivos MRT ou aprender sintaxe de comando de roteador.

A transição estava incompleta no corte de julho de 2026. Cobertura da API representava um subconjunto da plataforma, e o Looking Glass ainda dependia em parte da interface legada. Retirar o telnet cedo demais poderia quebrar scripts e fluxos construídos ao longo de décadas. Mantê-lo indefinidamente poderia preservar os problemas de carga e segurança que a modernização pretende resolver.

O ponto estratégico importante é que RouteViews está migrando de acesso centrado em roteador para acesso centrado em serviço sem abandonar o arquivo. O coletor deve coletar. O arquivo deve preservar. A API deve responder consultas estruturadas de estado atual. O Looking Glass deve dar suporte à análise humana. Kafka deve distribuir dados ao vivo. Separar essas funções é a forma atual de gerenciar escala no projeto.

Construindo uma visão global com peers voluntários

RouteViews não obriga nenhum sistema autônomo a contribuir. Sua cobertura emerge de sessões BGP voluntárias, relações de host e disponibilidade das redes em expor informação de roteamento. Isso gera um bem público por decisões locais: cada peer escolhe o que exportar, cada host escolhe que infraestrutura fornecer e cada usuário escolhe como consumir os dados.

O modelo tem baixo requisito de capital central comparado a possuir cada local de coletor, mas o sucesso depende de relações sociais e operacionais. A equipe da RouteViews precisa recrutar peers, verificar prontidão técnica, coordenar conexões de exchange, solucionar sessões e manter confiança. As relações globais da NSRC com operadores, redes de pesquisa e educação e comunidades de exchange fornecem ambiente institucional compatível com esse trabalho.

A política de peering de 2025 formalizou uma mudança da ingestão ampla para crescimento seletivo. Peers preferenciais devem fornecer tabelas completas estáveis, visibilidade regional ou de borda útil, caminhos distintivos e operação de produção de qualidade. Candidatos devem manter dados atuais no PeeringDB, usar espaço de endereços público e ASN público, filtrar rotas de propósito especial, evitar enviar rota padrão e suportar IPv4 e IPv6 quando possível. RouteViews não aceita Add-Path.

A seletividade reconhece custo. Cada sessão consome memória, processamento, monitoramento e atenção da equipe. Cada atualização entra no armazenamento e possivelmente no stream ao vivo. Um feed que duplica visão já existente de route server pode agregar pouca informação. Um peer ruidoso ou instável pode afetar desproporcionalmente toda a plataforma.

A seletividade também cria discricionariedade. O coordenador de peering avalia se uma rede é estável, regionalmente valiosa ou suficientemente não redundante. A política pública permite exceções, inclusive possível aceitação de redes experimentais, mas não foi encontrado processo formal de recurso ou revisão externa. A flexibilidade é operacionalmente útil; a superfície de governança deve permanecer visível porque a seleção molda o conjunto de dados usado por pesquisadores e sistemas de segurança.

As fontes atuais também trazem ambiguidade de função. Nina Bargisen é identificada como RouteViews Peering Coordinator na revisão operacional de janeiro de 2026 e na publicação da política de peering de 2025. Registros da University of Oregon identificam Owen Conway como RouteViews Network Engineer e Peering Coordinator. A evidência não estabelece se as funções são complementares, refletem uma transição ou derivam de relações de emprego diferentes. Um perfil responsável registra ambos sem fabricar resolução.

Em uma apresentação de 2026, a equipe mais ampla incluía Hans Kuhn, Nina Bargisen, Owen Conway, Philip Smith, Philip Paeps e Anton Berezin. Registros da University of Oregon listam Steve Huter como NSRC Director e Hans Kuhn como Senior Director for Research Infrastructure. Uma vaga de engenheiro de infraestrutura de RouteViews de abril de 2026 descreveu responsabilidades que abrangiam manutenção de coletores, desenvolvimento de ferramentas, relações setoriais, integridade de dados, segurança de roteamento e suporte a pesquisa.

Esses registros mostram que a plataforma depende de pessoas especializadas tanto quanto de máquinas doadas. A coleta global de BGP exige julgamento de peering, operações de roteamento, automação, sistemas distribuídos, gestão de armazenamento e suporte ao usuário. Uma equipe pequena especializada gera eficiência e continuidade, mas também cria risco concentrado de pessoas-chave e de recrutamento.

Segurança de roteamento usa evidência da RouteViews, mas permanece fora do controle da RouteViews

Vazamentos e sequestros de rota frequentemente ficam visíveis como mudanças inesperadas de roteamento. Um prefixo pode surgir com novo ASN de origem, um anúncio mais específico pode se espalhar, o AS path pode mudar de forma abrupta ou a rota anterior pode ser retirada. RouteViews fornece as observações a partir das quais sistemas de monitoramento e analistas de incidente podem detectar ou reconstruir esses padrões.

O projeto não garante detecção automática. Um evento precisa atingir pelo menos um ponto de vista relevante, o peer precisa exportá-lo e a trajetória de coleta precisa permanecer saudável. Um incidente localizado pode ser invisível se nenhuma rede contribuidora o vê ou o relata. Um evento amplo pode aparecer rapidamente em muitas sessões e ainda exigir contexto para diferenciar ação maliciosa de configuração incorreta ou mudança legítima de política.

RPKI adiciona uma camada externa de validação. Route Origin Authorisations podem ser comparadas com anúncios de origem observados para classificá-los como válidos, inválidos ou não encontrados. O Looking Glass da RouteViews suporta verificações orientadas a RPKI. A RouteViews em si não emite ROAs, não define quais redes devem aplicar Route Origin Validation ou remover rotas inválidas da tabela global.

A distinção entre evidência e enforcement é operacionalmente importante. Uma plataforma de segurança pode alertar com dados da RouteViews. Um operador pode configurar filtros ou ROV. Um registry e o titular do recurso podem gerir ROAs. Uma equipe de resposta pode contatar redes. RouteViews fornece um stream de observação compartilhado que ajuda esses atores a coordenar, mas não absorve sua autoridade ou responsabilidade.

Os mesmos dados também sustentam pesquisa de topologia e relacionamentos. Caminhos AS fornecem evidência com a qual pesquisadores inferem relações provedor-cliente, peering, customer cones e dependências de trânsito. CAIDA usa dados RouteViews em prefix-to-AS mappings, AS Rank e produtos relacionados. Esses resultados derivam por metodologia. Não são registros contratuais diretos nem prova de que cada adjacência represente um arranjo comercial específico.

O mapeamento prefixo-origem é igualmente temporal e observacional. Ele associa endereços ao ASN de origem visível nos dados de roteamento em um tempo. É útil para segurança, performance e pesquisa de política, mas não é um registry legal de propriedade. Um anúncio mais específico, implantação anycast, evento temporário ou arranjo multi-origin pode complicar o mapeamento.

Portanto, a relevância de RouteViews para segurança vem da posição de infraestrutura e da continuidade histórica. O projeto registra sinais de plano de controle de muitas redes e os disponibiliza a sistemas que precisam de perspectiva externa. Seu limite também é estrutural: ele vê apenas as rotas enviadas para si e não converte observação em conformidade universal.

Dependência de pesquisa e relação com CAIDA

Dados da RouteViews tornaram-se base para medição da internet porque são públicos, de longa duração e expressos em formatos amplamente suportados. Pesquisadores os usam para estudar crescimento de tabela de roteamento, topologia AS, mudança de caminho, deagregação de prefixo, resiliência, sequestros, vazamentos e adoção de mecanismos de segurança. Uma apresentação de 2019 citou aproximadamente 500 publicações, mas nenhum total atual deduplicado e verificado foi confirmado. A conclusão segura é uso extensivo de pesquisa, não uma contagem atual precisa de papers.

CAIDA é uma das instituições a jusante mais importantes. Ela deriva mapeamentos prefixo-AS e produtos de nível AS a partir de observações RouteViews e fornece ferramentas como BGPStream que ajudam pesquisadores a processar RouteViews e RIPE RIS. A CAIDA, MIT CSAIL e UO NSRC também colaboraram no Global Measurement Infrastructure for Internet Security de outubro de 2021 a setembro de 2025.

O projeto ILANDS, liderado por CAIDA e previsto até março de 2027, trata de escala e infraestrutura de dados em longo prazo de rede, incluindo desafios de roteamento e armazenamento. Essas colaborações mostram a RouteViews inserida em ecossistema de medição mais amplo, em vez de operar como serviço universitário isolado. Valores e objetivos de bolsas devem, entretanto, ser alocados com cuidado: prêmios liderados por CAIDA ou abrangentes da NSRC não são orçamentos exclusivamente da RouteViews.

A relação com a RIPE RIS é complementar. A RIS opera seus próprios Remote Route Collectors distribuídos e serviços públicos de roteamento pelo RIPE NCC. Também usa beacons de roteamento ativos, recurso distinto da identidade de coletor geralmente passivo da RouteViews. As duas plataformas coordenam para melhorar redundância e visibilidade global, permanecendo sistemas separados com pontos de vista e interfaces diferentes.

Pesquisadores combinam com frequência RouteViews e RIS porque nenhuma plataforma é completa. A sobreposição permite verificação cruzada e melhora resiliência. As diferenças mostram como os resultados de medição dependem da seleção de coletores. Isolario e outras plataformas adicionam mais perspectivas, enquanto monitores comerciais enriquecem dados públicos com pontos de vista proprietários, alertas e suporte.

A existência de alternativas não reduz o valor da RouteViews. Ela ajuda a usar corretamente. Uma análise robusta seleciona fontes conforme a pergunta, documenta pontos de vista e testa se conclusões resistem a mudanças de conjunto de dados. RouteViews não é universalmente superior a toda plataforma de peers. Seus pontos fortes distintivos são profundidade de arquivo, familiaridade operacional, dados públicos MRT, combinação de coletores de exchange e multihop e continuidade institucional na University of Oregon.

O DOI do projeto, 10.7264/1y7v-2d90, oferece mecanismo de citação para tornar o uso acadêmico mais visível e reprodutível. Citar é parte da sustentabilidade porque permite reconhecer a contribuição de infraestrutura. Não revela, por si, quantos produtos, papers ou sistemas operacionais dependem dos dados.

Vieses, redundância e os limites de uma visão voluntária

Os peers da RouteViews não são uma amostra aleatória da internet. São redes dispostas e capazes de estabelecer sessões BGP conforme a política do projeto, geralmente em exchanges onde RouteViews possui coletor ou por meio de arranjos multihop. A localização dos coletores depende em parte de hospedagem em espécie. O conjunto de pontos de vista resultante reflete relações de operadores, maturidade de interconexão e seleção estratégica.

Viés geográfico pode surgir porque regiões com grandes exchanges organizadas são mais fáceis de observar. Viés de tipo de rede pode surgir porque provedores de trânsito, redes de pesquisa e operadores com forte engajamento técnico podem ser mais propensos a contribuir do que acessos fechados ou empresas. Viés topológico pode surgir porque algumas partes do gráfico AS possuem muitos pontos de vista, enquanto outras não têm nenhum.

Esses vieses não invalidam os dados. Eles definem a população que os dados conseguem representar. Um estudo de roteamento global que usa RouteViews deve identificar quais coletores e peers foram selecionados e evitar tratar ausência no arquivo como prova de que uma rota não existia em lugar algum.

A redundância é o custo correspondente da coleção ampla. Muitos peers exportam caminhos idênticos ou muito similares ao melhor caminho. A redundância melhora resiliência e pode revelar desacordo, mas aumenta armazenamento e computação. O valor marginal de um novo feed depende da tarefa. Um caminho redundante para cobertura global de prefixos ainda pode ser valioso para incidente regional.

Feed de route server complica interpretação porque uma sessão pode expor muitos participantes da exchange. Sessões bilaterais podem duplicar essas rotas. O route server pode alterar a representação de caminho conforme seu desenho. Analistas precisam de metadados que distingam a relação de origem e evitem tratar todo ASN representado como peer direto.

A exportação de melhor caminho cria outro ponto cego. Um peer pode conhecer múltiplos caminhos, mas enviar à RouteViews apenas a rota selecionada. Alternativas ocultas podem só ficar visíveis quando política ou alcançabilidade mudam. O arquivo, assim, revela caminhos usados ou exportados, não o conjunto completo de opções disponível dentro de cada rede.

A topologia física também fica oculta. Dois AS paths que parecem disjuntos podem compartilhar fibra, instalações, energia ou uma organização de upstream. Dados de roteamento são essenciais para entender diversidade de plano de controle, mas não provam independência física sem evidência adicional.

A conclusão metodologicamente correta é que RouteViews é um instrumento de medição com propriedades de amostragem conhecidas, não uma tentativa fracassada de onisciência. Mais coletores podem melhorar cobertura, mas nenhum conjunto voluntário e finito remove todo viés. A obrigação científica é descrever o instrumento e limitar a inferência.

Peers ruidosos, crescimento de armazenamento e economia de preservar tudo

RouteViews informou que o armazenamento alocado para RIBs e updates cresceu de 11,1 TB para 67 TB durante 2025. O mesmo relatório descreveu os maiores peers de rota completa com aproximadamente 1,1 milhão de prefixos IPv4 e 253 mil prefixos IPv6. Uma apresentação separada mencionou em torno de 50 TB comprimidos, provavelmente refletindo data mais antiga ou definição de armazenamento diferente.

O crescimento é em parte esperado. Tabelas de roteamento expandem, mais peers enviam rotas completas e mais coletores criam visões paralelas. O tamanho de RIB pode ser modelado de forma razoável a partir de contagem de prefixos e frequência de coleta. O volume de atualização é mais difícil, porque depende do comportamento.

Um peer instável pode gerar número muito alto de mensagens. Flapping de rota, mudanças repetidas de atributos, reinícios de sessão, defeitos de software e deagregação podem produzir picos de atualização que dominam o armazenamento. Parte desse ruído é operacionalmente significativa. Um pesquisador estudando instabilidade pode valorizar exatamente as mensagens que outro usuário quer filtrar.

O problema de armazenamento, portanto, não se resolve apagando duplicatas indiscriminadamente. O propósito do arquivo é preservar evidência. Qualquer política de filtragem altera o instrumento. Ao mesmo tempo, preservar toda mensagem repetida pode tornar o acesso mais lento, elevar custo de nuvem e replicação e incentivar análises enganosas baseadas em contagens brutas.

O backend moderno dá a RouteViews mais ferramentas para gerenciar essa tensão. Bimper e Prometheus podem identificar peers de alto impacto. Kafka pode isolar consumidores. A política de configuração pode desativar uma sessão que ameace a estabilidade. Trabalho de distribuição em Google Cloud e BigQuery pode oferecer capacidade adicional de distribuição e análise.

O repositório RouteViews-Google descreve sincronização, checksums, transferência gRPC, armazenamento em Google Cloud e conversão para tabelas analíticas. Atividade de desenvolvimento continuou em julho de 2026. O repositório público não estabelece cobertura de produção completa, paridade de arquivo, política de retenção, alocação de custos ou garantias de serviço. É evidência de implementação ativa, não prova de que um espelho em nuvem tenha substituído o arquivo da University of Oregon.

Preservação de longo prazo exige mais que adicionar discos. Arquivos precisam de checksums, replicação, recuperação de desastre, metadados e formatos acessíveis. Um arquivo de várias décadas também acumula estruturas históricas heterogêneas que devem permanecer interpretáveis. Distribuição em nuvem pode reduzir carga de um sistema de entrega e baixar barreira para análise em larga escala, mas também pode introduzir dependência de provedor e custo recorrente.

O centro da questão econômica é quais observações vale preservar e quem paga para que continuem disponíveis. A resposta histórica da RouteViews favorece abertura e amplitude. O desafio de sustentabilidade é tornar essa resposta operacionalmente viável sem mudar silenciosamente o significado do arquivo.

O modelo institucional: hospedagem universitária, operação da NSRC e apoio comunitário

RouteViews é hospedada pela University of Oregon e gerida via Network Startup Resource Center. Registros atuais da universidade colocam a NSRC dentro da UO Libraries. Steve Huter aparece como NSRC Director, Hans Kuhn como Senior Director for Research Infrastructure e Owen Conway como RouteViews Network Engineer e Peering Coordinator. A revisão operacional do projeto e apresentações identificam membros adicionais da equipe e o papel de Nina Bargisen em peering.

Esse ambiente institucional dá à RouteViews suporte jurídico, de emprego, de bolsa e administrativo sem criar uma entidade corporativa independente. O arranjo também significa que a situação financeira da RouteViews não pode ser reconstruída a partir de receita e contas próprias, pois não há orçamento auditado, folha de pagamento, reservas ou balanço separados publicados.

O modelo de financiamento combina apoio universitário e de bolsas, contribuições diretas, hospedagem em espécie, colaboração técnica e peers voluntários. O suporte histórico incluiu NSF Award 0323769 para o projeto Oregon Route-Views, um subaward DARPA NETPATH, a University of Oregon, Cisco, Juniper e Sprint. A lista de apoiadores de 2025 incluiu Amazon, Catchpoint, Google, ICANN, Internet Society, Internet Society Foundation, MaxMind, NSF, Verisign, fundações e doadores individuais.

Os valores e restrições dessas contribuições não são públicos em forma exclusiva da RouteViews. A NSRC informa que o Google forneceu apoio de financiamento e hardware substancial, e a University of Oregon anunciou bolsa NSF de US$ 3.732.343 para a NSRC. Essas cifras apoiam o ambiente institucional amplo e não devem ser apresentadas como receita própria do RouteViews.

Hospedagem em espécie é economicamente significativa mesmo quando não aparece em orçamento de caixa. Um host de coletor pode fornecer máquina virtual, porta, trânsito, energia, refrigeração e tempo de equipe. Os peers voluntários fornecem os dados nos quais o serviço depende. A base real de recursos do projeto, portanto, está distribuída entre instituições e redes.

O modelo maximiza acesso público. RouteViews afirma que seus dados são de livre acesso, e o site exibe licença CC BY 4.0. Termos específicos de conjuntos de dados e artefatos históricos devem ser verificados, em vez de assumir que um único rodapé rege todos os caminhos de acesso. Controles de capacidade da API e expectativas de atribuição podem coexistir com acesso gratuito.

Produtos comerciais aparentemente usam dados RouteViews. Apresentações do projeto citam exemplos em monitoramento e inteligência de rede. A reutilização comercial demonstra impacto e pode melhorar operações de roteamento, mas cria problema de free rider. Uma empresa pode construir serviços geradores de receita sobre um arquivo público sem taxa mandatória proporcional ao seu uso.

RouteViews respondeu pedindo que usuários comerciais de sucesso reconheçam e apoiem o projeto. Não foi identificado modelo compulsório de preços comerciais ou contrato de suporte. Isso preserva abertura, enquanto mantém sustentabilidade dependente de contribuições voluntárias, bolsas e compromisso institucional.

A superfície de governança é, portanto, informal no domínio público. Não foram encontrados comitê dedicado à RouteViews, conselho consultivo dedicado, objetivo de serviço nível, processo formal de recurso de remoção de peer, política de retenção publicada ou plano de sucessão. A governança aparece por gestão de University e NSRC, obrigações de bolsas, julgamento da equipe e relações com peers e hosts.

Isso pode funcionar bem quando a instituição é confiável e a equipe é estável. Também gera perguntas à medida que a dependência cresce. Usuários comerciais, pesquisadores e operadores podem depender de RouteViews como infraestrutura sem ter papel formal na definição de retenção, acesso ou prioridades de resiliência. A ausência de corporação separada evita uma burocracia, mas não elimina a necessidade de governança transparente de um serviço compartilhado.

O mecanismo de impacto da RouteViews

O efeito da RouteViews pode ser rastreado como uma cadeia, não como uma pretensão de autoridade. Primeiro, um sistema autônomo exporta voluntariamente rotas BGP para um coletor. Segundo, o coletor registra a visão de plano de controle selecionada como estado de RIB e atualizações. Terceiro, RouteViews preserva e distribui os dados por arquivos, streams e serviços. Quarto, operadores, pesquisadores e fornecedores analisam as observações. Quinto, esses usuários podem mudar monitoramento, resposta a incidente, filtragem, modelos de topologia, política ou investimento.

Cada elo tem um tomador de decisão próprio. O network contribuinte controla a exportação. RouteViews controla coleta e publicação dentro de seus sistemas. O usuário de downstream controla análise. O operador controla se altera política de roteamento. A equipe de segurança controla se dispara alerta. O pesquisador controla metodologia. O impacto do projeto surge da interoperabilidade entre essas decisões.

Essa divisão é força porque não exige aprovação central para que o dado se torne útil. Um network contribui porque escolhe fazer isso. Um pesquisador baixa porque o arquivo é aberto. Um fornecedor integra porque o formato é reutilizável. Um operador age porque a evidência é persuasiva em seu contexto.

É também limite para alegações causais. RouteViews pode fornecer evidência usada em investigação de sequestro sem ser a organização que detectou primeiro o incidente ou o corrigiu. CAIDA pode construir um conjunto derivado da RouteViews sem fazer RouteViews responsável pela metodologia. Um produto comercial pode depender do arquivo sem divulgar quanto de sua saída vem da RouteViews.

A forma mais forte de poder do projeto é epistemológica. Ele molda o que pode ser conhecido sobre roteamento interdomínio e quais perguntas históricas podem ser feitas. Isso é relevante porque decisões de infraestrutura são limitadas pela evidência disponível. Uma rota que nunca foi observada é mais difícil de investigar; um arquivo longo pode revelar padrões invisíveis nos logs de uma única rede.

O poder epistemológico não deve ser confundido com completude factual. O instrumento seleciona a realidade pela participação de peers, política, localização de coletores e decisões de armazenamento. RouteViews merece confiança quando esses limites são documentados, não quando se escondem atrás de alegação de visão global.

O arcabouço editorial de Lu Heng é útil aqui como disciplina, não como fonte factual sobre RouteViews. A separação relevante é entre estado operacional e afirmação institucional. O valor da RouteViews é demonstrado por coletores que recebem rotas, arquivos que preservam registros e usuários que as utilizam. O projeto não precisa afirmar propriedade da verdade de roteamento; sua credibilidade vem de permanecer uma camada observável, auditável e com limites explícitos.

Por que a BTW acompanha a RouteViews

A BTW acompanha a RouteViews porque observabilidade de roteamento é infraestrutura. Os roteadores que carregam tráfego são apenas uma parte da internet operacional. Operadores também precisam de sistemas que mostrem como a alcançabilidade está sendo representada além de suas próprias redes, preservem evidência durante incidentes e permitam comparação de longo prazo.

RouteViews é especialmente importante por combinar ligação operacional a BGP com arquivo histórico remontando a 1997. Essa profundidade torna o projeto útil para perguntas que dashboards comerciais posteriores não conseguem responder. Também é distribuída globalmente o suficiente para expor diferenças regionais, ao mesmo tempo em que é transparente sobre a impossibilidade de cobertura completa.

O projeto ilustra um princípio mais amplo de infraestrutura: visibilidade compartilhada pode ser criada sem centralizar o controle operacional. RouteViews não decide rotas para seus peers. Registra o que eles escolhem revelar. O dataset resultante pode apoiar coordenação entre atores independentes, preservando a autoridade deles para aceitar, recusar e interpretar localmente.

As fragilidades também são instrutivas. A participação voluntária cria viés. O acesso aberto cria pressão de financiamento. A hospedagem doada cria dependência. Interfaces legadas criam dívida técnica. Uma equipe pequena especializada cria risco de continuidade. O crescimento de armazenamento cria problema aberto de preservação de longo prazo. O aumento de dependência comercial pode superar governança e contribuição.

RouteViews não deve, portanto, ser romantizada como mapa completo da internet nem descartada como arquivo acadêmico. É um sistema de medição de produção cujos resultados se tornaram parte de pesquisa, monitoramento e segurança. Sua importância está na posição intermediária: próxima o bastante do roteamento em tempo real para fornecer evidência operacional, limitada o suficiente para que todo usuário entenda o que a evidência não contém.

Principais evidências e questões em aberto

A evidência principal para este perfil é o pacote de pesquisa profunda da própria RouteViews, que por sua vez utiliza a revisão operacional de janeiro de 2026 sobre 2025, a política de peering oficial e a documentação da API, registros da University of Oregon e da NSRC, apresentações históricas da APNIC e da NANOG, PeeringDB, especificações IETF, documentação da RIPE RIS, páginas de projetos e recursos da CAIDA, trabalhos acadêmicos sobre valor de pontos de observação e viés em medição, além de repositórios públicos do projeto.

O registro sustenta a origem em 1995, a contribuição inicial de MAE-WEST por Randy Bush, o papel principal inicial de David Meyer, o início do arquivo em novembro de 1997, a cadência de duas horas iniciada em 2001, o modelo de coletor em IXP de 2003, coleta IPv6, a hospedagem atual na University of Oregon e na NSRC, AS6447, as atuais cadências de arquivo, os números de janeiro de 2026 de sessões e armazenamento, a API, o Looking Glass, Kafka e arquitetura Bimper e a expansão de coletores em 2025.

Alguns fatos importantes permanecem sem resolução. Nenhuma contagem ativa de coletores com data alinhada foi encontrada. Os números de 50 TB e 67 TB usam datas ou definições diferentes. Nina Bargisen e Owen Conway aparecem publicamente associados à coordenação de peering. Os metadados do PeeringDB sobre route server conflitam com a política oficial que aceita rotas de route server. A completude e paridade de produção do arquivo no Google Cloud não estão estabelecidas. RouteViews não publica orçamento próprio isolado, número de equipe, registro de usuários comerciais, histórico formal de uptime nem dashboard de completude de arquivo.

Por isso, o artigo evita várias alegações. RouteViews não é tratado como operador de tráfego, troca internet, exchange, empresa separadamente incorporada, visão completa de roteamento global, serviço automático de enforcement contra sequestro ou dono de toda rota coletada. Rotas completas não são descritas como todos os caminhos. Contagens de sessão não são convertidas em contagem de coletor. Totais de bolsas da NSRC ou colaborações da CAIDA não são atribuídos integralmente à RouteViews.

As fontes que mais diretamente sustentam o perfil incluem:

A questão central em aberto não é se RouteViews tem valor. O arquivo, a rede de coletores e o uso downstream estabelecem isso. A questão é se o projeto consegue preservar sua abertura histórica e sua honestidade metodológica enquanto se torna uma plataforma de dados maior, mais rápida e mais orientada a serviço. Esse resultado dependerá de armazenamento, replicação, cobertura de API, continuidade da equipe, relações de host e um modelo de financiamento que reflita o valor comercial e acadêmico extraído do sistema.