Мониторинг состояния путей LSP

Наличие встроенных в транспортную технологию средств мониторинга состояния соеди­нений и локализации ошибок (то есть средств ОАМ) является необходимым условием для того, чтобы она претендовала на статус технологии операторского класса. В противном случае ее трудно будет использовать операторам сетей, которым нужно обеспечивать своих многочисленных клиентов транспортным сервисом с высоким коэффициентом готовности (в пределах 0,999-0,99999), как это принято в телекоммуникационных сетях. Первоначально технология MPLS не имела таких встроенных средств, полагаясь на такие средства стека TCP/IP, как утилиты ping и traceroute (использующие, как вы знаете из главы 17, ICMP-сообщения Echo Request и Echo Response). Однако классические утилиты ping и traceroute стека TCP/IP не дают корректной информации о состоянии путей LSP так как они могут переноситься как вдоль, так и в обход этих путей с помощью обычной тех­ники продвижения пакетов протокола IP. Поэтому позднее был разработан специальный протокол LSP Ping, который позволяет как тестировать работоспособность LSP (режим ping), так и локализовывать отказы (режим traceroute).

Кроме того, для мониторинга состояния LSP можно применять более экономичный, чем LSP Ping, протокол двунаправленного обнаружения ошибок продвижения (см. далее).

Тестирование путей LSP

В протоколе LSP Ping для тестирования состояния LSP применяется техника, близкая к механизму работы утилиты ping протокола IP. Она заключается в том, что протокол LSP Ping отправляет вдоль тестируемого пути LSP сообщение Echo Request. Если такое сообщение доходит до устройства LER, которое является конечным узлом тестируемого пути LSP, оно отвечает сообщением Echo Replay. Получение исходным узлом такого со­общения означает, что путь LSP работоспособен.

Описанная схема работы аналогична схеме работы утилиты ping протокола IP, однако она имеет свои особенности, которые мы поясним на примере сети, изображенной на рис. 20.12.

Рис. 20.12. Тестирование LSP с помощью протокола LSP Ping

 

В этом примере устройство LSR1 тестирует состояние пути LSP1, который заканчивается на устройстве LSR8 (для этого пути оно является устройством LER).

Для тестирования пути LSP1 устройство LSR1 отправляет MPLS-пакет с меткой 105 — эта метка соответствует пути LSP1 на линии между устройствами LSR1 и LSR4. Сообщение Echo Request вкладывается в UDP-сообщение, которое, в свою очередь, вкладывается в IP-пакет. На рис. 20.12 показаны только значимые для изучения протокола LSP Ping поля: метка MPLS-кадра, IP-адрес источника (SA), IP-адрес назначения (DA), а также поле FEC, которое идентифицирует тестируемый путь LSP. В нашем примере это IP-адрес сети

0.0, к которой ведет путь LSP1.

Адрес назначения в IP-пакете, который переносит сообщение Echo Request, равен 127.0.0.1, то есть является адресом обратной петли стека протоколов IP каждого узла. О причине ис­пользования такого необычного адреса назначения (а не, скажем, IP-адреса интерфейса ко­нечного узла тестируемого пути LSP) мы расскажем позже, а пока заметим, что адрес 127.0.0.1 должен работать правильно, так как в процессе передачи запроса по сети для его продвиже­ния используются MPLS-метки, а не IP-адрес назначения. При приходе на конечный узел IP-пакет освобождается от заголовка MPLS (это также может произойти на предыдущем хопе, если применяется техника РНР) и обрабатывается на основе IP-адреса. Так как адрес

0.1 указывает на собственный узел, то пакет передается собственному стеку TCP/IP, где он распознается как UDP-пакет протокола LSP Ping и обрабатывается соответственно.

Поле FEC посылается в запросе Echo Request для того, чтобы конечный узел пути мог сравнить указанное в пакете значение FEC со значением из его собственной базы данных для пути, по которому пришел кадр запроса. Такой механизм позволяет отслеживать ситуации, когда запрос вследствие каких-то ошибок приходит не по тому пути, который тестируется.

В том случае, когда запрос благополучно доходит до конечного узла пути, и тот убеждает­ся, что полученный запрос пришел по нужному пути (то есть полученное значение FEC совпадает со значением FEC из базы данных конечного узла), он отправляет ответ Echo Replay узлу, выполнившему запрос. В нашем случае узел LSR8 отправляет ответ Echo Replay узлу LSR1. Сообщение Echo Replay посылается уже не по пути LSP, а как обычное UDP-сообщение, вложенное в IP-пакет. Если вспомнить, что пути LSP являются одно­направленными, станет понятно, что это единственное гарантированное решение, так как обратного пути от LSR8 к LSR1 может и не существовать.

Теперь посмотрим, что происходит в том случае, когда по какой-то причине путь LSP поврежден. На рис. 20.13 представлен именно такой случай, когда путь поврежден на по­следнем своем участке (между устройствами LSR7 и LSR8).

Рис. 20.13. Тестирование неисправного пути LSP с помощью протокола LSP Ping

 

В этой ситуации LSR7 не может отправить MPLS-кадр по назначению, как того требует метка 177, а отбрасывает заголовок MPLS и старается обработать кадр как IP-пакет. Как и в случае исправного пути, адрес 127.0.0.1 требует передачи пакета локальному стеку TCP/IP. Именно этого эффекта и добивались разработчики протокола LSP Ping, выбирая в качестве адреса назначения этот специальный адрес. Узел LSR7 обрабатывает сообщение Echo Request и отправляет сообщение Echo Replay узлу LSR1 с информацией об обнару­женной ошибке.

Трассировка путей 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 начальному узлу тестируемого пути.