Resumo

  • Às 2026-11-10T00:04:49Z, o registro de exchange do InterLAN-IX no PeeringDB (id 270) concluiu uma importação de lista de membros IX-F, com 132 redes contadas. Este texto leu o registro às 00:06:44Z, menos de dois minutos depois.
  • O exchange afirma, em seu próprio site, que oferece dois route servers aos parceiros. A frase não traz endereços, não traz número de sistema autônomo, não traz prefixo de LAN de peering e não traz política de filtro ou de autorização.
  • Para quem decide se conecta, o efeito prático é direto: dá para confirmar que o exchange existe e está ativo pelo carimbo de dois minutos, mas não dá para saber, sem perguntar, quem responde pelas rotas que você vai receber.

Um carimbo novo o bastante para ser checado

A API de exchanges do PeeringDB devolveu ixf_last_import igual a 2026-11-10T00:04:49Z e ixf_net_count igual a 132. A leitura deste texto aconteceu às 00:06:44Z. A diferença é de menos de dois minutos — sinal de que existe um fluxo automático de importação por trás dessa lista legível por máquina, e não um retrato manual esquecido há anos.

O mesmo registro traz id 270, org_id 591, nome InterLAN-IX, nome longo InterLAN Internet Exchange Romania, cidade Bucareste, país RO, região continental Europe, mídia Ethernet. O que esses campos provam é concreto: o exchange existe em registro estruturado, tem uma contagem de participantes legível por máquina e tem um horário de atualização que qualquer pessoa pode conferir.

O que eles não provam é igualmente concreto. Não atestam neutralidade comercial, não atestam comportamento de filtro, não atestam o número de sistema autônomo dos route servers e não atestam que qualquer anúncio específico tenha sido autorizado.

Dois route servers, uma frase, nenhum identificador

No site do próprio exchange está escrito, sem rodeios:

Pentru a facilitar schimbul de trafic, InterLAN-IX pune la dispoziția partenerilor săi două route-servere care permit interconectarea directă cu majoritatea celor conectați.

Em tradução: para facilitar a troca de tráfego, o InterLAN-IX coloca à disposição dos parceiros dois route servers que permitem a interconexão direta com a maioria dos conectados.

A frase entrega o formato do serviço e para aí. Não informa os endereços dos dois route servers, não informa o número de sistema autônomo deles, não informa o prefixo da LAN de peering, não informa a política de filtro e não diz quem pode injetar o quê. Para quem vai se conectar, esses são justamente os parâmetros que definem o que se recebe. Para quem faz diligência, são a única porta de entrada verificável de forma independente.

O resultado é que a verificabilidade pública deste exchange termina na camada institucional. A camada de interface depende de perguntar a alguém.

Um ASN que virou identidade por engano

Quando esta apuração começou, havia um identificador candidato no conjunto de trabalho: o AS39737. Ele apareceu como possível sistema autônomo dos route servers do próprio exchange. Depois de abrir a página do AS39737 no Hurricane Electric BGP Toolkit, a candidatura não se sustentou. O texto original diz:

AS39737 Prime Telecom srl … Country of Origin: Romania … Internet Exchanges: 6 … Prefixes Announced (all): 414 / Prefixes Announced (v4): 392 / Prefixes Announced (v6): 22

Ou seja: nesse diretório de terceiros, o AS pertence à Prime Telecom srl, com país de origem Romênia, presença em 6 exchanges e 414 prefixos anunciados no total — 392 em IPv4 e 22 em IPv6. É o retrato de uma operadora membro, não o de um route server neutro. A página também não afirma que esse AS seja usado pelo InterLAN-IX, nem liga os 414 prefixos a qualquer serviço de route server.

Aqui é preciso separar os números. 132 é a contagem de redes em uma importação IX-F. 414 é a contagem de prefixos anunciados por um sistema autônomo. Objetos diferentes, unidades diferentes, registros diferentes. Colocá-los lado a lado para procurar uma "divergência" é medir a mesma distância com duas réguas que não combinam.

Duas verificabilidades, duas notas separadas

Juntando os três registros, aparece uma fronteira nítida.

A verificabilidade institucional pergunta: este exchange existe em registro público estruturado? Tem contagem de participantes e horário de atualização inspecionáveis? A resposta do InterLAN-IX é sim, e o carimbo é tão recente que um leitor cauteloso desconfia ter lido errado.

A verificabilidade do anúncio pergunta: quais sistemas autônomos originam aquilo que os route servers efetivamente entregam? Quem controla esses sistemas? O que valida a origem? Nos registros lidos para este texto, essa corrente não forma um caminho que o leitor possa refazer. Um carimbo prova que o dado foi publicado; não prova que um único anúncio habilitado por ele tenha sido autorizado.

Este enquadramento é análise minha, não um achado externo: tratar visibilidade institucional e visibilidade de origem como duas categorias separadas de diligência. A consequência prática é que um exchange neutro e bem documentado ainda pode ser ilegível na camada de origem; e, na direção oposta, um documento público que delegue autorização de route server a uma operadora membro não constitui, por si só, irregularidade.

O que não foi lido é limite, não conclusão

Os objetos aut-num e route/route6 de origem inversa do AS39737 no banco de dados do RIPE não foram lidos para este texto. Os endereços dos route servers do exchange, o prefixo da LAN de peering e qualquer estado de ROA de RPKI cobrindo os prefixos discutidos também não foram obtidos. Por isso a camada de origem aparece aqui como não verificada, e não como ausente, vazia ou permissiva. O escopo termina aí: a frase descreve o que esta apuração leu, não o que o registro contém.

Quem quiser fechar a corrente tem caminho. Basta o exchange publicar o ASN dos route servers e a política de filtro, ou colocar os ROAs dos prefixos de route server num lugar pesquisável. Nenhuma das duas coisas exige divulgar condição comercial.

O registro de diretório deste exchange está em InterLAN Internet Exchange SRL Exclusivo para o Círculo Estratégico.