Кратко

  • RFC 4950 закрывает диагностический пробел: обычная ошибка ICMP может показать извлечённую IP-дейтаграмму, но не стек MPLS, повлиявший на пересылку.
  • Расширение работает с ICMPv4 и ICMPv6 и использует структуру расширений и заголовки объектов из RFC 4884.
  • Объект стека меток может сопровождать сообщения Time Exceeded и Destination Unreachable; исходный IP-заголовок и начальные октеты полезной нагрузки сохраняются.

Каждая запись стека занимает ровно четыре октета: 20-битная метка, три бита экспериментального назначения в терминологии текста 2007 года, один бит Bottom of Stack и 8-битный TTL. Передаётся полный стек в том виде, в каком он прибыл на маршрутизатор, сообщивший об ошибке. Это не восстановление полного пути и не доказательство корневой причины.

Улучшенный traceroute может показать посещённые узлы и состояние MPLS-инкапсуляции исходной дейтаграммы на каждом ответившем узле. Однако RFC 4950 не определяет общую связь MPLS с ICMP и не задаёт специальное для инкапсуляции изменение TTL. Процедуры TTL, способные сорвать обычный traceroute, могут сорвать и улучшенный. Поэтому объект нельзя смешивать с моделью распространения TTL, входными данными балансировки, обнаружением живости BFD или полномочиями BGP по объявлениям и сессиям.

Анализ Elias Ward — не требование RFC: операторы и специалисты по устранению неисправностей получают контекст меток, которого нет в обычной ICMP-ошибке. Возможность принадлежит сообщающему LSR, а решение о раскрытии принимает оператор по локальной политике. Цена — дополнительная видимость операционных деталей. Частичная поддержка, фильтрация, совместимость и поведение TTL могут сделать свидетельство неполным; молчание нельзя превращать в отрицательное доказательство. В контрфактическом варианте классические ICMP и traceroute по-прежнему показывают ошибку и видимые узлы, но расследование сильнее зависит от внутренней телеметрии и журналов устройств.

Отсутствие объекта стека не доказывает, что пакет не был инкапсулирован в MPLS: наблюдение могут подавить поддержка, политика, фильтрация и TTL. Переданный стек сам по себе не доказывает полный путь, первопричину или одинаковую информацию на каждом переходе. Значения меток не дают разрешения менять пересылку и не доказывают владение, намерение или соблюдение политики. Историческое утверждение RFC о широком развёртывании не подтверждает сегодняшнее повсеместное покрытие, единое поведение производителей или текущие настройки раскрытия.

Решения оператора и проверочные сценарии

  1. Проверьте версию ICMP, многочастную структуру RFC 4884 и заголовок объекта; короткое сообщение нельзя трактовать шире его содержимого.
  2. Убедитесь, что сохранены исходный IP-заголовок и начальные октеты полезной нагрузки; разберите каждую четырёхоктетную запись на 20-битную метку, три экспериментальных бита, S-бит и 8-битный TTL.
  3. Сопоставьте несколько контролируемых ответов Time Exceeded и Destination Unreachable, фиксируя узел, фильтрацию, политику раскрытия и поведение TTL.
  4. Используйте обнаруженный стек для сужения внутреннего расследования, но не как команду на изменение маршрута, создание LSP или выдачу доступа. При отсутствии объекта запросите телеметрию и журналы устройства, а не объявляйте MPLS отсутствующим.

Источники