Кратко

  • Один пользователь форума RIPE NCC сообщил о пустых результатах Looking Glass для отдельных IP-адресов при наличии данных для соответствующих префиксов.
  • Все четыре запроса, выполненные 3 сентября, вернули данные. Симптом не воспроизвёлся, однако окончательное устранение проблемы этим не доказано.
  • При вводе IP сервис сначала ищет охватывающий его маршрутизируемый префикс. Этот этап нельзя смешивать с наблюдением маршрута и проверкой доставки трафика.

У пустого ответа есть важное свойство: он не объясняет сам себя. Отсутствие данных на экране может показаться отсутствием маршрута, хотя между введённым адресом и результатом есть ещё операции, смысл которых пользователь не проверял.

В случае RIPEstat это стало предметом конкретного сообщения. 2 сентября пользователь написал, что запрос 14.137.164.1 в Looking Glass не возвращает данных, а 14.137.164.0/24 возвращает. В нашей проверке на следующий день оба варианта работали. То же произошло с парой входных значений из более раннего примера.

Поэтому сейчас нельзя утверждать ни наличие воспроизведённого действующего сбоя, ни завершение ремонта. Доступны датированное сообщение и более поздние успешные проверки. Причина различия между ними остаётся неустановленной.

Сначала найти префикс, затем посмотреть маршруты

Документация Looking Glass описывает разные правила для двух типов входных данных. Явно заданный префикс должен точно совпадать с префиксом в данных маршрутизации. При получении IP сервис пытается найти маршрутизируемый префикс, который содержит этот адрес. Слишком старые записи исключаются; предел давности по умолчанию составляет 86 400 секунд.

Такой поиск удобен: не обязательно заранее знать размер объявленного блока. Но удобство добавляет зависимость. Прежде чем извлечь наблюдения, сервис должен определить, к какому объекту они относятся. Проблема на этом этапе могла бы повлиять на ответ без изменения объявлений какого-либо маршрутизатора. Это описание возможного механизма, а не установленная причина рассматриваемого случая.

Совет всегда приписывать /24 был бы неверен. Реально объявленный префикс может иметь другую длину. Произвольная маска меняет вопрос, а не создаёт надёжный контрольный запрос. Для сравнения нужен префикс, присутствие которого в маршрутизации уже подтверждено.

Что известно из переписки

Обсуждение на форуме началось 24 августа с примера 159.138.184.0 и 159.138.184.0/24. На следующий день ties, учётная запись с публичной отметкой сотрудника RIPE NCC, объяснил поиск наиболее специфичного префикса, назвал симптом, по-видимому, временным и предложил уточнить у коллеги обработку неудачного поиска.

2 сентября тот же пользователь, moonteach, сообщил, что прежний адрес уже работает, но привёл другую пару с расхождением. Времена двух запросов в новом сообщении отличаются на 27 секунд. Это не одновременный эксперимент, не несколько независимых свидетельств и не статистика распространённости ошибки. Подтверждённой первопричины или объявления об окончании исправления в переписке нет.

Наши запросы выполнялись последовательно 3 сентября, с 04:13:08.929 до 04:13:10.945 UTC. Все четыре вернули HTTP 200, статус ok и непустые данные. В обоих ответах на отдельные IP присутствовало сообщение о преобразовании в соответствующий /24; этот же префикс был указан в фактическом параметре ресурса.

Входное значение Записи коллекторов Строки пиров
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

Числа относятся к сохранённым ответам. Это не количество независимых операторов и не полный состав инфраструктуры RIS. У второй пары значения latest_time отличаются на 20 секунд. Равное число строк не доказывает тождественности снимков данных. Ссылки в таблице выполняют текущие запросы, а не открывают неизменные архивные ответы.

Проверка полезна именно своей ограниченностью: в этих четырёх попытках различие не возникло. Она не восстанавливает прежнее состояние сервера, не показывает частоту возможных сбоев и не объясняет, какое изменение могло произойти между наблюдениями.

Доставка ответа и доставка пакета

В описании Data API статус, сообщения, версия и сведения о кэше разделены. Успешное получение ответа не доказывает доступность адреса. Пустое поле с данными само по себе также не доказывает отзыв маршрута.

RIS собирает наблюдения BGP через добровольно предоставляемые пиринговые сессии. Это не сквозная проверка пересылки пользовательского трафика. Между работающей сетью и выводом аналитика находятся точка наблюдения, её источники, время данных и правила обработки запроса.

Из рассматриваемых материалов не следует, что произошли клиентский простой, потеря трафика или перехват маршрута. Прежде чем говорить об исчезновении, следует установить, какой именно префикс сервис в действительности искал. Пока этот вопрос открыт, пустой ответ остаётся поводом для исследования, а не его результатом.