Мониторинг состояния путей 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-адрес сети 105.0.0.0, к которой ведет путь LSP1.

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