Кратко

  • RFC 3609 рассматривал IP-переход верхнего уровня и нижележащие переходы внутри туннеля как разные объекты доказательства; завершённая внешняя трасса могла быть точной, но неполной.
  • Сила внутреннего отчёта зависела от отдельных запросов и ответов, полномочий, поддержки протокола, обратного пути, плоскости наблюдения и эквивалентности пробного пакета.

Линия между двумя известными точками

В операционной системе есть сильный визуальный соблазн: если вход и выход туннеля известны, соединить их сплошной линией и считать участок объяснённым. Такая линия описывает абстракцию, но не свидетельствует о каждом действии пересылки. Внутри могут находиться GRE, MPLS, IPsec, GMPLS, IP-in-IP или L2TP, а несколько разнородных туннелей могут быть вложены друг в друга.

RFC 3609 вышел в сентябре 2003 года как Informational RFC. Он сформулировал требования к универсальному приложению трассировки и поддерживающему протоколу. Документ не был готовым общераспространённым протоколом и не доказывал внедрение. Он зафиксировал архитектурную потребность: обычный traceroute видит IP-переходы, но может скрыть нижние уровни, на которых фактически работает forwarding plane.

В тексте разделены top-level IP hop и lower-level hop, содержащийся в туннеле. Первый относится к внешнему IP-представлению. Второй пытается раскрыть механизм под ним. Видимость границ не доказывает внутренний маршрут. Описание из плоскости управления не доказывает, что конкретный рабочий пакет прошёл каждый перечисленный элемент.

Право раскрыть не следует из права спросить

Туннель можно было показать одним IP-переходом или развернуть. Пользователь выбирал желаемый вид, но подробность зависела от разрешения. Security token представлял привилегии трассировщика, а сетевые элементы решали, что вернуть. Политика должна была учитывать идентификацию, авторизацию и ограничение ресурсов.

Поэтому видимость — не постоянное свойство сети, а ответ в рамках полномочий. Внешний наблюдатель может увидеть один переход, внутренний оператор — тип, имя, идентификатор, конечные адреса, компоненты и round-trip delay. Оба результата могут быть корректны. Вместе с ними необходимо хранить наблюдателя, класс доступа, запрошенную и полученную глубину, время.

Без этого контекста привилегированный отчёт превращается в якобы общедоступную топологию, а ограниченный отчёт — в ложное доказательство отсутствия внутренней структуры. И сами поля ограничены: имя не доказывает владельца, идентификатор не гарантирует актуальную конфигурацию, двусторонняя задержка не разделяет направления, список компонентов не обещает тот же путь следующему потоку.

Отдельный ответ переживает поломку

Приложение должно было поддерживать частичную трассу через сломанный путь или туннель. Поэтому каждый probe должен вызывать один response, а каждый ответ представлять один верхний или нижний hop. Если одна запись собирает весь путь последовательно, исследуемая неисправность может уничтожить именно тот документ, который должен был её локализовать.

Отдельные квитанции сохраняют последнюю наблюдаемую границу. Но отсутствие ответа неоднозначно. Причиной могут быть ошибка пересылки, фильтр, ограничение частоты, отсутствие поддержки, отказ в раскрытии или невозможный обратный маршрут. RFC 3609 требовал сообщать о неподдерживающем устройстве и пытаться продолжить поиск ниже. «Сломано», «не поддерживается», «не разрешено» и «неизвестно» нельзя рисовать одним цветом.

Условия возврата входят в эксперимент. Хост трассировки должен иметь маршрут к входу исследуемого пути и к входу каждого туннеля, детали которого он запрашивает. Внутренним устройствам нужен путь обратно к входу туннеля, не обязательно прямо к исходному хосту. Рабочий трафик способен идти вперёд, когда диагностический ответ не может вернуться. Это разрыв наблюдаемости, пока иное не доказано.

Особый пакет создаёт особое наблюдение

RFC отверг схему с одним probe и опцией IP Router Alert. Многие сети обрабатывают пакеты с IP options иначе, чем обычные. Диагностика могла бы измерить путь, возникший из-за её собственной особенности, а затем выдать его за путь нужного трафика.

Тот же риск несут размер, семейство адресов, flow key, DSCP, инкапсуляция и время. В доказательстве нужно сохранить точный профиль пакета и обосновать его эквивалентность рабочему потоку. Одинаковый адрес назначения не обеспечивает одинаковый эксперимент. Детальная карта другой категории пакетов остаётся точным ответом на другой вопрос.

Документ предпочитал UDP и stateless-режим ради масштабирования и устойчивости к denial of service. Stateless означает, что узлы не обязаны сохранять состояние между сообщениями. Это не удостоверяет содержание ответа, владельца топологии или доставку приложению.

Два свидетеля на разных плоскостях

Приложение должно было трассировать control plane, forwarding plane или обе. В контрольной плоскости о переходе сообщает входное устройство. В плоскости пересылки отвечает выходное устройство, если туннель использует уменьшение TTL или сходный механизм. Меняется не только способ; меняется источник свидетельства.

Контрольная плоскость может содержать согласованное намерение, когда установленное состояние пересылки устарело. Ответ пересылки показывает встречу одного probe, но не объясняет политику выбора. Совпадение повышает уверенность, не объединяя источники. Проектный путь, запрограммированное состояние, наблюдаемая пересылка и результат сервиса должны оставаться отдельными.

TTL propagation также отличается от наличия decrement. RFC 3609 хотел поддерживать трассировку пересылки независимо от копирования внутреннего TTL во внешний заголовок, если механизм уменьшения существует. Появление или исчезновение внутреннего узла само по себе не доказывает ошибочную настройку.

Более поздние RFC добавили конкретные инструменты. GRE и MPLS объясняют слои инкапсуляции и labels. RFC 3443 описывает модели TTL в MPLS. RFC 4379 и заменивший его RFC 8029 определяют LSP ping и traceroute с собственными проверками. RFC 4884 расширяет ICMP, а RFC 4950 вводит объект стека MPLS-меток. Эти механизмы дают дополнительные квитанции, но не превращают локальный ответ в полное свидетельство пути и исхода.

Набор квитанций вместо властной карты

Минимальная запись начинается с образца трафика: источник, назначение, поля потока, размер, options, маркировка и время. Затем идут внешняя трасса, точка наблюдения и метод. Для туннеля добавляются вход, выход, требуемая глубина, основание раскрытия и отвечающая плоскость. Для каждого внутреннего перехода сохраняются запрос, ответ, условие возврата и причина отрицательного результата. Доставка, выполнение сервиса и пользовательский исход требуют самостоятельных подтверждений.

Такая схема создаёт минимальный общий язык и не требует от сети раскрывать всю локальную реальность. Оператор сохраняет контроль над чувствительными деталями, но честно помечает границу раскрытия. Работающий код создаёт состояние; схема лишь проецирует ограниченные наблюдения на конкретный момент.

Источники