Resumo

  • Um usuário do fórum do RIPE NCC relatou consultas por IP sem dados, embora os respectivos prefixos retornassem informações no Looking Glass.
  • Em 3 de setembro, as quatro verificações deste artigo retornaram dados. O sintoma não foi reproduzido, mas isso não confirma uma correção definitiva.
  • Consultar um endereço exige localizar primeiro o prefixo roteado que o contém. Uma resposta vazia, isoladamente, não demonstra retirada de rota ou indisponibilidade.

Para o operador que investiga um endereço, acrescentar uma máscara pode parecer um ajuste de apresentação. Para o RIPEstat, pode mudar o trabalho necessário para responder. 14.137.164.1 pede uma busca a partir de um IP; 14.137.164.0/24 já informa um bloco específico.

Em 2 de setembro, um usuário relatou que a primeira entrada produzia um resultado vazio no Looking Glass, enquanto a segunda retornava dados. Nossa verificação do dia seguinte não repetiu esse comportamento. As duas funcionaram, assim como o par de entradas de um exemplo anterior no mesmo debate.

O resultado impede tratar o relato como uma falha atual demonstrada. Mas também não explica o estado anterior do serviço. A questão continua sendo como reconhecer o significado de um vazio sem transformá-lo, por conveniência, em um diagnóstico da rede.

O prefixo não é um detalhe da interface

Segundo a documentação do endpoint, um prefixo informado explicitamente precisa corresponder exatamente a um prefixo roteado. Se a entrada for um IP, o serviço tenta encontrar o prefixo roteado que o engloba. Registros antigos são excluídos pelo limite de consulta retrospectiva, de 86.400 segundos por padrão.

Há, portanto, uma operação antes de buscar as observações propriamente ditas. Essa operação permite pesquisar sem saber de antemão qual bloco está anunciado. Ao mesmo tempo, cria uma dependência: uma dificuldade em resolver o endereço pode afetar a consulta sem qualquer alteração nos anúncios de um roteador. Isso descreve uma possibilidade técnica, não a causa comprovada deste caso.

O cuidado vale também para a suposta solução. Acrescentar /24 indiscriminadamente não garante nada. A rota real pode ter outro tamanho. O prefixo usado como comparação deve ter sua presença no roteamento estabelecida por evidência; uma máscara escolhida apenas porque parece plausível muda a pergunta.

Um relato, duas datas de exemplos

O registro público começou em 24 de agosto, com 159.138.184.0 e 159.138.184.0/24. Em 25 de agosto, ties, conta identificada publicamente como integrante da equipe do RIPE NCC, explicou a busca pelo prefixo mais específico, avaliou que o fenômeno parecia transitório e propôs consultar o tratamento de falhas nessa busca.

Em 2 de setembro, o mesmo usuário, moonteach, disse que a entrada anterior já funcionava, mas apresentou o novo contraste. Os horários das duas consultas reproduzidas no post estão separados por 27 segundos. Não são medições simultâneas, relatos de usuários independentes ou uma amostra capaz de medir a incidência do problema. A conversa não anuncia diagnóstico definitivo nem correção concluída.

As quatro requisições feitas para este artigo ocorreram em sequência entre 04:13:08.929 e 04:13:10.945 UTC, em 3 de setembro. Todas receberam HTTP 200, estado ok e dados. Nas buscas por IP, a resposta informou expressamente a conversão para o /24 correspondente, também registrado como recurso efetivo.

Entrada Registros de coletores Linhas de pares
159.138.184.0 23 343
159.138.184.0/24 23 343
14.137.164.1 23 325
14.137.164.0/24 23 325

Essas contagens descrevem as respostas preservadas. Não representam operadoras distintas nem o conjunto de equipamentos do RIS. Na segunda dupla, o campo latest_time difere em 20 segundos. Totais iguais não provam que as duas consultas receberam o mesmo retrato dos dados. Os links da tabela executam consultas atuais e não preservam as respostas históricas.

Quatro resultados positivos têm utilidade limitada e concreta: mostram que o contraste não apareceu nessas tentativas. Não permitem estimar disponibilidade, recuperar o estado anterior do servidor ou atribuir o resultado a uma mudança específica.

O que o código 200 deixa em aberto

A estrutura da Data API distingue estado, mensagens, versão e informações de cache. Uma resposta entregue com sucesso não equivale a um teste de acesso ao destino. Um conjunto vazio tampouco demonstra, sozinho, a retirada de um anúncio.

O RIS reúne observações BGP por meio de sessões fornecidas voluntariamente por redes. Não encaminha o tráfego do usuário até o destino para verificar o serviço. Perspectiva do par, coletor, horário, resolução da entrada e regras de consulta precisam permanecer separados da conclusão sobre conectividade.

Nada no caso comprova queda para clientes, perda de tráfego ou sequestro de rota. A utilidade do episódio está em cobrar uma pergunta anterior: qual prefixo foi efetivamente consultado? Se isso ainda não está claro, o vazio é uma pista para investigar, não uma constatação sobre o funcionamento da rede.