Summary

  • RFC 1574 вышла в феврале 1994 года и описала минимальный набор для поиска неисправностей в OSI/CLNP: эхо, трассировку и доступ к таблицам маршрутов хостов и маршрутизаторов.
  • Если в запросе включён флаг сообщения об ошибке, узел CLNP без поддержки нового селектора эхо может ответить ошибкой. Такой ответ обнаруживает отвечающий узел, но не устанавливает работоспособность всего пути.

Дежурный посылает пакет в сторону отказавшего сервиса. В ответ приходит не привычное «эхо», а жалоба: устройство не знает этой функции. На экране можно написать «проверка не прошла» и закрыть окно. Можно, наоборот, узнать первый полезный факт: пакет достиг устройства, способного ответить. Susan Hares и Cathy Wittbrodt посвятили RFC 1574 именно таким различиям. По их описанию, инструменты диагностики сетевого уровня OSI были редкостью, а существующие реализации нередко несовместимы.

Первый инструмент — эхо для CLNP. Сопутствующая RFC 1575 задала шестнадцатеричные селекторы 1E для запроса и 1F для ответа. RFC 1574 требовала выставлять флаг сообщения об ошибке. Узел, понимающий CLNP, но не распознающий новый селектор, должен попытаться вернуть пакет ошибки. Обычный ответ, отказ из-за неизвестной опции и тишина — три разных результата. Утилита должна была показывать код ошибки, время каждого ответа и минимум, максимум и среднее время по нескольким пробам. Для поиска разрыва эти детали важнее крупной красной надписи.

Второй инструмент отслеживал путь. Поле Lifetime в CLNP похоже по назначению на TTL в IP. Значение 1 приводит к исчерпанию срока на первом переходе и возврату ошибки; значение 2 позволяет обнаружить следующий. Повторяя пробу с возрастающими значениями, оператор получает цепочку отвечавших узлов. Коды A0 и A1 различают случаи исчерпания срока, B0 сообщает о неподдерживаемой опции, 80 и 81 — о недостижимом или неизвестном адресате. Разные ошибки требуют разных следующих проверок. Список без кодов теряет половину смысла.

Можно было попросить пакет пройти через выбранный промежуточный узел, задав частичный маршрут от источника. Но ISO 8473 разрешал устройству, которое не знает такой опции, просто переслать пакет дальше. Он мог прибыть в пункт назначения, миновав именно тот узел, который дежурный хотел проверить. RFC 1574 предлагала показывать ошибки исходного маршрута, включая неизвестный адрес и неприемлемый путь. Успешная доставка пакета отвечала на вопрос о прибытии, а не о соблюдении заказанного маршрута.

Третий инструмент говорил от лица самого устройства. Хост или маршрутизатор OSI должен был уметь выдавать свои таблицы маршрутов через отдельный, внеполосный механизм. Записи могли происходить из ES-IS, IS-IS, IDRP, статической настройки и других источников. RFC предлагала команду вроде show osi routes с фильтрами, а также доступ через SNMP или CMIP. При этом тогдашняя CLNS MIB не выдавала всех нужных сведений. Таблица показывает, какие решения о пересылке хранит одна машина; трассировка показывает ответы на конкретные пробы.

Документ описывал требования к инструментам, а не зарегистрированную аварию. Чтобы оценить их работу на реальном оборудовании, понадобились бы датированные результаты эхо, трассировки и выгрузки таблиц. Смысл набора уже ясен: при отказе сеть не произносит единого вердикта. Она отвечает кусками, и даже ошибка может назвать нужный кусок.