Трассировка путей lsp

При неисправном состоянии какого-то отрезка пути LSP сообщение об ошибке не всегда может быть отправлено промежуточным устройством LSP. Возможна и такая ситуация, когда ответ на запрос Echo Request просто не приходит — сеть «молчит», например, потому что отказал промежуточный узел. Для того чтобы локализовать отказавший элемент сети (узел или соединение), протокол LSP Ping может работать в режиме трассировки пути LSP. Этот режим аналогичен режиму работы утилиты traceroute стека TCP/IP и в нем используется тот же механизм, заключающийся в посылке серии сообщений Echo Request с монотонно возрастающим от 1 значением поля TTL. Разница состоит в том, что это поле указывается не в IP-пакете, как при использовании IP-утилиты traceroute, а в заголовке MPLS (который также имеет поле TTL).

Дальнейшее поведение протокола LSP Ping в режиме трассировки очевидно — MPLS-кадр с нулевым значением TTL передается «наверх» протоколу LSP Ping того промежуточного узла, который после вычитания единицы из значения этого поля получил нулевой резуль­тат. Протокол реагирует на такую ситуацию отправкой сообщения Echo Replay начальному узлу тестируемого пути.

Протокол двунаправленного обнаружения ошибок продвижения

Протокол двунаправленного обнаружения ошибок продвижения (Biderectional Forwarding Detection, BFD) разработан как «облегченная» альтернатива протоколу LSP Ping для постоянного мониторинга состояния пути LSP. Такой постоянный мониторинг требуется, например, в тех случаях, когда основной путь защищен резервным путем и необходим какой-то механизм, который, с одной стороны, может быстро выявить отказ пути, а с другой — не перегружает сеть тестовыми сообщениями и трудоемкими проверками. Протокол LSP Ping удовлетворяет первому условию, то есть может использоваться для постоянного тестирования состояния пути путем периодической отправки сообщений Echo Requst. Однако обработка этих сообщений конечным узлом пути довольно трудоемка, так как требует сравнения значения FEC в каждом пришедшем запросе со значением из базы данных. Протокол BFD гораздо проще, чем LSP Ping. Однако он не способен локализовать отказавший элемент сети, а только показывает, работоспособен некоторый путь LSP или нет. Название протокола говорит о том, что он проверяет состояние соединения между двумя узлами в обоих направлениях. Так как пути MPLS однонаправленные, то для работы про­токола BFD необходима пара путей LSP, соединяющих два узла в обоих направлениях. Каждый из двух конечных узлов, на которых для мониторинга определенного пути LSP развернут протокол BFD, периодически посылает по этому пути сообщения Hello. Полу­чение сообщений Hello от соседа означает работоспособность пути в одном определенном направлении. Неполучение сообщения Hello в течение определенного времени означает отказ пути в этом направлении, что и фиксирует протокол BFD. Информацию об отказе пути могут немедленно использовать другие протоколы стека MPLS, например рассматриваемые далее протоколы защиты пути.

Протокол BFD посылает сообщения Hello в UDP-сообщениях, которые, в свою очередь, упаковываются в IP-пакеты и снабжаются заголовками MPLS. Протокол BFD может ис­пользоваться не только для мониторинга путей MPLS, он разработан как универсальный протокол тестирования двунаправленных соединений. Обычно для инициализации сеанса BFD служит протокол LSP Ping, который переносит по пути идентификаторы сеанса BFD.