Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Устранение неполадок MPLS

Проверка MPLS интерфейсов

Цель

Если MPLS не настроен правильно на маршрутизаторах сети, интерфейсы не смогут выполнять MPLS коммутатор.

Прим.:

Чтобы маршрут с маркировкой разрешался через интерфейс, необходимо настроить на уровне иерархии, чтобы маршрут был family mpls[edit interfaces] успешно разрешен. Если интерфейс не настроен, маршруты с маркировкой family mpls не будут разрешены.

Действий

Для проверки MPLS интерфейсов введите следующую Junos OS интерфейс командной строки (интерфейс командной строки) operational mode:

Пример выходных данных 1

command-name

Следующий пример выходных данных для всех маршрутизаторов в сети показан в топологии MPLS сети.

Пример выходных данных 2

command-name

Пример выходных данных 3

command-name

Смысл

Пример выходных данных 1 показывает, MPLS все интерфейсы на всех маршрутизаторах сети включены () и могут MPLS Up коммутатор. Если не удается настроить правильный интерфейс на уровне иерархии [] или включить утверждение на уровне [] иерархии, интерфейс не может MPLS коммутатор и не будет отображаться в выходных данных edit protocols mplsfamily mpls edit interfaces type-fpc/pic/port unit number show mpls interface команды.

Административные группы не настроены ни на любом интерфейсе, изображенного в примере сети MPLS топологии сети. Однако, если бы это было так, выходные данные показывают, какие биты affinity класса включены на маршрутизаторе.

Пример выходных данных 2 показывает, что интерфейс отсутствует и поэтому so-0/0/2.0 может быть неправильно настроен. Например, интерфейс может не быть включен на уровне иерархии [] или утверждение может быть не включено на уровне edit protocols mplsfamily mpls edit interfaces type-fpc/pic/port unit number [] иерархии. Если интерфейс настроен правильно, возможно, RSVP еще не был сигнализирован через этот интерфейс. Дополнительные сведения о настройке интерфейса см. в "Проверка семейок протоколов".

Пример выходных данных 3 показывает, MPLS протокол не настроен на уровне edit protocols mpls [] иерархии.

Проверка семейок протоколов

Цель

Если логический интерфейс не имеет включенной MPLS, он не MPLS коммутатор. Этот шаг позволяет быстро определить, какие интерфейсы настроены с MPLS и другими семействами протоколов.

Действий

Чтобы проверить семейства протоколов, настроенные на маршрутизаторах сети, введите следующую команду Junos OS интерфейс командной строки operational mode:

Пример выходных данных 1

command-name

Пример выходных данных 2

command-name

Смысл

Пример выходных данных 1 показывает интерфейс, административное состояние соединения (), статус уровня передачи данных на уровне (), семейства протоколов, настроенные на интерфейсе () и локальные и удаленные адреса на AdminLinkProto интерфейсе.

Все интерфейсы всех маршрутов сети, показанные в топологии MPLS, административно включены и работают на уровне передачи данных с MPLS и IS-IS и имеют inet адрес. Все они настроены с помощью семейства протоколов IPv4 () и имеют IS-IS () и MPLS () семейства протоколов, настроенные на уровне inetisomplsedit interfaces type-fpc/pic/port unit number [] иерархии.

Пример выходных данных 2 показывает, что в интерфейсе on не содержится утверждение so-0/0/2.0R6 на уровне mplsedit interfaces type-fpc/pic/port unit number иерархии []

Проверка конфигурации MPLS

Цель

После проверки транзитного и входящего маршрутизаторов используйте команду для проверки BGP следующего перехода и использования команды для проверки активного пути, можно проверить наличие проблем с конфигурацией MPLS на уровнях иерархии и на уровне tracerouteping[edit protocols mpls][edit interfaces] иерархии.

Прим.:

Чтобы маршрут с маркировкой разрешался через интерфейс, необходимо настроить на уровне иерархии, чтобы маршрут был family mpls[edit interfaces] успешно разрешен. Если интерфейс не настроен, маршруты с маркировкой family mpls не будут разрешены.

Действий

Чтобы проверить конфигурацию MPLS, введите следующие команды для входящего, транзитного и выходного маршрутизаторов:

Пример выходных данных 1

command-name

Пример выходных данных 2

command-name

Смысл

Пример выходных данных 1 от входящего, транзитного и выходного маршрутизаторов показывает, что конфигурация интерфейсов на маршрутизатор исходящего трафика R6 неверна. Интерфейс включен как неактивный на уровне [] иерархии, когда он должен быть активным, так как это интерфейс, через so-0/0/3.0 edit protocols mpls который проходит LSP.

Пример выходных данных 2 показывает, что интерфейсы правильно настроены для MPLS на R6 маршрутизатор исходящего трафика. Интерфейсы также правильно настроены на входящем и транзитном маршрутизаторах (не показан).

Проверка MPLS уровня

Цель

После того, как вы настроили путь с коммутаатом по метке (LSP), выдав команду и определив, что имеется ошибка, можно обнаружить, что ошибка не находится на физическом уровне, в соединении данных, в интернет-протоколе (IP), в уровнях протокола внутреннего шлюза (IGP) или протокола резервирования ресурсов show mpls lsp (RSVP). Продолжайте изучение проблемы на MPLS уровне сети.

Рис. 1 иллюстрирует MPLS многоуровневой MPLS модели.

Рис. 1: Проверка MPLS уровняПроверка MPLS уровня

На MPLS уровня можно проверить, функционирует ли LSP должным образом. Если сеть не работает на этом уровне, LSP не будет работать так, как законфигурирован.

Рис. 2 иллюстрирует MPLS, используемых в данной теме.

Рис. 2: MPLS сеть, разбитая на MPLS уровнеMPLS сеть, разбитая на MPLS уровне

Сеть, показанная в полносетевой конфигурации, где каждый непосредственно подключенный интерфейс может принимать и посылать пакеты Рис. 2 на любой другой аналогичный интерфейс. LSP в этой сети настроен на запуск от входящего маршрутизатора через транзитный маршрутизатор R1R3 для R6 маршрутизатор исходящего трафика. Кроме того, обратный LSP настраивается для работы с сквозной перенаправлением R6R3 на создание R1 двухнаправленного трафика.

Однако в этом примере обратный LSP отстает без пути от R6 к R1 .

Показано перекрестное Рис. 2 обозначение места, где разбит LSP. Возможные причины, по которой LSP не работает, могут включать неправильно настроенный MPLS или интерфейсы, неправильно настроенные для MPLS.

В сети, изображенной на этом, ошибка конфигурации на маршрутизатор исходящего трафика предотвращает прохождение Рис. 2R6 LSP по сети, как ожидалось.

Чтобы проверить уровень MPLS, выполните следующие действия:

Проверка LSP

Цель

Обычно команда используется для show mpls lsp extensive проверки LSP. Однако для быстрой проверки состояния LSP используйте show mpls lsp команду. Если LSP не используется, используйте extensive этот параметр show mpls lsp extensive) (в качестве последующей. Если в сети имеется несколько LSP, можно рассмотреть возможность указания имени LSP с помощью name параметра show mpls lsp name name (или show mpls lsp name name extensive).

Действий

Для проверки работы LSP введите некоторые или все из следующих команд в входном маршрутизаторе:

Пример выходных данных 1
command-name
Пример выходных данных 2
command-name
Пример выходных данных 3
command-name
Пример выходных данных 4
command-name

Смысл

Пример выходных данных 1 показывает краткое описание состояния LSP для входящего, транзитного и выходного маршрутизаторов. Выходные данные в выходных данных маршрутизатора маршрутизатор исходящего трафика показывают, что оба R1R6 LSP отказано, R1-to-R6R6-toR1 и. С настроенными LSP и R1 другими R6 LSP ожидается откат сеансов LSP как на обоих, R1 так и R6 на. Кроме того, транзитный маршрутизатор R3 не имеет транзитных сеансов.

Пример выходных данных 2 показывает всю информацию о LSP, включая всю информацию об истории состояния и причину сбой LSP. Выходные данные и указывают на отсутствие маршрута к месту назначения из-за сбой алгоритма R1R6 Constrained Shortest Path First (CSPF).

Примеры выходных данных 3 и 4 показывают примеры выходных данных команды show mpls lsp name с extensive параметром. В этом примере выходные данные очень схожи с командой, поскольку только один LSP настраивается в примере сети в MPLS сети, разбитой на show mpls lspMPLS уровне. Однако в крупной сети с настроенным большим числом LSP результаты будут сильно отличаются от двух команд.

Проверка маршрута LSP на транзитном маршрутизаторе

Цель

Если LSP находится в up, маршрут LSP должен появиться в mpls.0 таблице маршрутов. MPLS ведет таблицу маршрутов MPLS пути (routeing table) с списком следующего коммутатора меток в mpls.0 каждом LSP. Эта таблица маршрутов используется на транзитных маршрутизаторах для маршрутки пакетов следующему маршрутизатору по LSP. Если в выходных данных для транзитного маршрутизатора нет маршрутов, проверьте конфигурацию протокола MPLS на входящем и выходном маршрутизаторах.

Действий

Чтобы проверить маршрут LSP на транзитном маршрутизаторе, введите в транзитном маршрутизаторе следующую команду:

Пример выходных данных 1
command-name
Пример выходных данных 2
command-name

Смысл

Пример выходных данных 1 от транзитного маршрутизатора показывает три записи маршрутов в форме R3 MPLS меток. Эти MPLS являются зарезервированными MPLS меток, определенных в RFC 3032, и они всегда присутствуют в таблице маршрутов вне зависимости от состояния mpls.0 LSP. Входящие метки, присвоенные RSVP соседу входящего потока, отсутствуют в выходных данных, что указывает на то, что LSP не может быть. Дополнительные сведения о записях MPLS меток см. в контрольный список для проверки использования LSP.

В отличие от этого, в примере выходных данных 2 показаны MPLS метки и маршруты для корректно настроенного LSP. Присутствуют три MPLS метки, а четыре других записи представляют входящие метки, присвоенные RSVP соседу по потоку. Эти четыре записи представляют два маршрута. Существует две записи на маршрут, так как значения стека в головном MPLS могут быть разными. Для каждого маршрута вторая запись и указывает, что глубина стека не 1, а дополнительные значения меток включены 100864 (S=0)100880 (S=0) в пакет. В отличие от первой записи, со значением S=1, которое указывает на глубину стека 1, каждая метка делает последней меткой в 100864100880 определенном пакете. Двойные записи указывают на то, что это предпоследний маршрутизатор. Дополнительные сведения о стеке MPLS меток см. в RFC 3032, MPLS Label Stack Encoding.

Проверка маршрута LSP на впадаемом маршрутизаторе

Цель

Проверьте, включен ли маршрут LSP в активные записи в таблице маршрутов inet.3 для указанного адреса.

Действий

Чтобы проверить маршрут LSP, введите следующую команду из входного маршрутизатора:

Пример выходных данных 1
command-name
Пример выходных данных 2
command-name

Смысл

Пример выходных данных 1 показывает только записи inet.0 в таблице маршрутов. Таблица inet.3 маршрутов отсутствует в выходных данных, поскольку LSP не работает. Таблица маршрутов используется протоколами внутренних шлюзов (IGP) и Border Gateway Protocol (BGP) для хранения inet.0 сведений о маршруте. В данном случае IGP протокол маршрутизации промежуточных систем (IS-IS). Дополнительные сведения о таблице маршрутов см. в руководстве по Junos MPLS inet.0 приложений.

Если LSP работал, то предполагалось, что записи, включающие LSP в inet.3 таблицу маршрутов, будут включены. Таблица inet.3 маршрутов используется на впадающих маршрутизаторах для BGP пакетов к маршрутизатор исходящего трафика. BGP использует таблицу маршрутов на маршрутизаторе впадаем, чтобы помочь в разрешении адресов inet.3 следующего перехода. BGP настроена в примере сети, показанной в MPLS Network Broken на MPLS уровне.

Пример выходных данных 2 показывает выходные данные, которые вы должны получить, когда LSP находится в up. Выходные данные показывают как inet.0 таблицы, inet.3 так и таблицы маршрутов, что указывает на то, что LPS R1-to-R6 и R6-to-R1 доступны.

Проверка MPLS меток с помощью команды traceroute

Цель

Отобразить маршрутные пакеты до BGP места назначения, где следующим BGP для этого маршрута является адрес отката LSP. По умолчанию BGP использует таблицы маршрутов и таблицы маршрутов для разрешения inet.0inet.3 адреса следующего перехода. Если адрес следующего перехода маршрутизатора BGP не является ID маршрутизатора маршрутизатор исходящего трафика, трафик сопривязыется с IGP маршрутами, а не с LSP. Используйте эту команду в качестве средства отладки, чтобы определить, используется traceroute ли LSP для перенаададки трафика.

Действий

Для проверки MPLS меток введите следующую команду из входного маршрутизатора:

Пример выходных данных 1
command-name
Пример выходных данных 2
command-name

Смысл

Пример выходных данных 1 показывает, BGP трафик не использует LSP, MPLS метки не отображаются в выходных данных. Вместо использования LSP BGP трафик использует IGP (IS-IS, в примере сети в MPLS Network Broken at the MPLS Layer)для достижения выходного адреса LSP следующего BGP перехода. Поведение Junos OS по умолчанию использует LSP для BGP трафика, если следующий BGP перехода равен адресу отката LSP.

Пример выходных данных 2 является примером выходных данных для правильно настроенного LSP. Выходные данные показывают MPLS метки, указывающие, что BGP использует LSP для достижения BGP следующего перехода.

Проверка MPLS меток с помощью команды ping

Цель

При эхо-запросе определенного LSP проверяется, что эхо-запросы отправляются через LSP как MPLS пакетов.

Действий

Для проверки MPLS меток введите следующую команду с входного маршрутизатора для проверки маршрутизатор исходящего трафика:

Например:

Пример выходных данных 1
command-name
Пример выходных данных 2
command-name

Смысл

Пример выходных данных 1 показывает, что LSP не имеет активного пути для переадрит эхо-запросов, что означает, что LSP не работает.

Пример выходных данных 2 является примером выходных данных, которые вы должны получить, когда LSP находится в в up и перенаводке пакетов.

Примите соответствующие меры

Проблема

Описание

В зависимости от ошибок, с которыми вы столкнулись в ходе исследования, необходимо принять соответствующие меры для устранения проблемы. В этом примере интерфейс неправильно настроен на уровне иерархии edit protocols mpls [] маршрутизатор исходящего трафика R6.

Решение

Чтобы исправить ошибку в этом примере, выполните следующие действия:

  1. Активация интерфейса в конфигурации MPLS протокола на R6 маршрутизатор исходящего трафика:

  2. Проверьте и сфиксировать конфигурацию:

Пример выходных данных
Смысл

Пример выходных данных показывает, что неправильно настроенный интерфейс на маршрутизатор исходящего трафика активирован на уровне so-0/0/3.0R6 edit protocols mpls [] иерархии. LSP теперь может быть в том же оке.

Снова проверьте LSP

Цель

После принятия надлежащих мер для исправления ошибки LSP необходимо снова проверить, чтобы подтвердить, что проблема на BGP решена.

Действий

Для повторной проверки LSP введите следующую команду на входных, транзитных и выходных маршрутизаторах:

Пример выходных данных
command-name

Смысл

Пример выходных данных 1 от впадаемго маршрутизатора показывает, что LSP имеет активный маршрут к и R1R1-to-R6 состояние R6 работает.

Пример выходных данных 2 от транзитного маршрутизатора показывает, что есть два транзитных сеанса LSP, один из них в направлении и другой R3R1 из R6 R6R1 в. Оба LSP в том же ок.

Пример выходных данных 3 маршрутизатор исходящего трафика показывает, что LSP активен, и активным R6 маршрутом является основной маршрут. Теперь LSP проходит через сеть по ожидаемому пути, от сквозного к обратному, и обратному R1R3R6 LSP, от R6 сквозного R3R1 к.

Проверка одно к одному резервному копированию

Цель

Можно проверить, установлено ли 1-е резервное копирование, проверив веский маршрутизатор и другие маршрутизаторы в сети.

Действий

Для проверки 1-1-го резервирования введите следующие Junos OS интерфейс командной строки operational mode:

Пример выходных данных

command-name

Ниже приводится пример выходных данных в маршрутизаторе в выходных R1 данных:

Смысл

Пример выходных данных показывает, что объект был включен в сообщения пути для LSP, что позволяет выбрать активный путь для LSP и установить путь R1FastReroute desired R1 detour, чтобы R2 избежать.

В строке 8 Fast-reroute Detour Up показано, что detour является рабочим. Линии 6 и 7 указывают на то, что транзитные маршрутизаторы и их пути R2 отладки R4 установлены.

R2, включает , что означает, что защита узла доступна для 9-го узла и соединения. , включает, что означает, что защита соединения доступна для следующего 10.0.12.14 (flag=9)R410.0.24.2(flag=1) 9-го соединения. В этом случае можно R4 защитить только 9-ой соединение, поскольку маршрутизатор исходящего трафика является R5 маршрутизатор исходящего трафика, который не может быть защищен. Дополнительные сведения о флагах см. в руководстве Junos пользователя.

Выходные данные show mpls lsp extensive этой команды не показывают действительный путь отвода. Чтобы увидеть фактические ссылки, используемые путями detour, необходимо использовать show rsvp session ingress detail команду.

Пример выходных данных

Следующий пример выходных данных от маршрутизатора в выходной сети показан в разных резервных R1 откатах.

Смысл

В примере R1 выходных данных показано сеанс RSVP основного LSP. Путь отладки Detour is Up установлен. Физический путь от detour отображается в Detour Explct route . Путь detour использует R7 и R9 в качестве транзитных маршрутизаторов для достижения R5 маршрутизатор исходящего трафика.

Пример выходных данных

Следующий пример выходных данных с первого транзитного маршрутизатора М2 в сети показан в двух дублях резервного копирования:

Смысл

Пример выходных данных R2 показывает, что detour установлен () и избегает подключения к соединению Detour is Up и R4R4R510.0.45.2 (). Путь detour проходит () и () к (), который отличается от явного маршрута для R710.0.27.2R9 detour from . имеет 10.0.79.2R510.0.59.1R1R1 detour, 10.0.17.14R7R1 проходящий 10.0.27.2 через соединение on, при использовании ссылки. Оба detours объединены по R910.0.79.2 ссылке на R5 ( 10.0.59.1 ).

Пример выходных данных

Следующий пример выходных данных со второго транзитного маршрутизатора R4 в сети показан в одном из следующих резервных отъездов:

Смысл

Пример выходных данных R4 показывает, что detour установлен () и избегает подключения к соединению Detour is Up и R4R510.0.45.2 (). Путь в обеих точках проходит через R9 10.0.49.2R5 (в) в 10.0.59.1 ). Некоторые сведения аналогичны сведениям, найденным в выходных данных R1 для и R2 . Однако явный маршрут для detour отличается, проходит через соединение и R4R9so-0/0/3 (или 10.0.49.2.

Пример выходных данных

Следующий пример выходных данных взяты из ( который используется в пути detour в сети), показанный в примерах 1-1 Резервные R7отсеи:

Смысл

Пример выходных данных показывает ту же информацию, что и для обычного транзитного маршрутизатора, используемого на основном R7 пути LSP: адрес впадаемого (), адрес отката () и имя 192.168.1.1192.168.5.1 LSP r1-to-r5 (). Отображается два пути объездного пути; первый, чтобы избежать R4192.168.4.1 () и второй, чтобы избежать R2 ( 192.168.2.1 ). Поскольку используется как транзитный маршрутизатор by и , может объединять пути detour вместе, как указано одинаковым значением () для обоих путей R7R2R4R7Label out100368 detour. Принимает ли трафик со значением метки или со значением метки, передает пакет со значением R7R4100736R2100752R7R5100368 метки.

Пример выходных данных

Следующий пример выходных данных взят из R9, который является маршрутизатором, используемым в пути detour в сети, показанным в Октеурах резервного копирования один на один:

Смысл

Пример выходных данных показывает, что является предпоследним маршрутизатором для пути R9 detour, явный маршрут включает в себя только адрес выходного соединения (), а значение R910.0.59.1Label out3 () R9 указывает, что выталкивка метки предпоследней. Кроме того, ветвь detour from не включает информацию о пути, так как были объединены пути от и от 10.0.27.1R7 detour. R2R4 Обратите внимание, Label out что значение в ветке detour from такое же, как 10.0.17.13 и значение 100368Label outR7 on.

Пример выходных данных

Следующий пример выходных данных взяты из маршрутизатор исходящего трафика R5 в сети, показанной в отсеике одного к одному резервного копирования:

Смысл

В примере R5 выходных данных показано основное поле LSP и Record route выход через сеть.

Проверка работы основного пути

Цель

При наличии в сети первичные пути всегда должны использоваться, поэтому LSP всегда возвращается на основной путь после сбоя, если не заданная конфигурация. Дополнительные сведения о настройке конфигурации для предотвращения повторного использования сбойного основного пути см. в "Предотвращение использования ранее сбойного пути".

Действий

Чтобы убедиться, что основной путь находится в рабочем состоянии, введите следующие Junos OS интерфейс командной строки (интерфейс командной строки) рабочих режимов:

Пример выходных данных 1

command-name

Пример выходных данных 2

command-name

Смысл

Пример выходных данных 1 показывает, что LSP работает и использует основной путь via-r2 (с) и R210.0.12.14R410.0.24.2 () в качестве транзитных маршрутизаторов. Для настроек и удержания значения приоритетов 6 6 одинаковы. Приоритет 0 является самым высоким (лучшим) приоритетом, а 7 — низшим (худшим) приоритетом. Значение Junos OS для настройки и приоритета удержания - 7:0. Если некоторые LSP не являются более важными, чем другие, сохранение нас по умолчанию является хорошим решением. Настройка приоритета установки, который лучше, чем приоритет удержания не допускается, приводит к сбойу сфиксации во избежание зациклив при приоритете.

Проверка установленного вторичного пути

Цель

Если вторичный путь настроен с помощью утверждения, вторичный путь должен быть активным, но не активным; он станет активным при standby сбойе основного пути. Вторичный путь, настроенный без утверждения, не будет standby установлен, если основной путь не будет сбойным. Чтобы проверить, правильно ли настроен вторичный путь и что он будет активирован в случае с ошибки основного пути, необходимо деактивировать соединение или узел, критически важный для основного пути, и в ответ на show mpls lsp lsp-path-name extensive команду.

Действий

Чтобы убедиться в том, что вторичный путь установлен, введите команду Junos OS интерфейс командной строки operational mode:

Пример выходных данных

Пример выходных данных

command-name

В следующем примере выходных данных показан правильно настроенный вторичный путь до и после его начала. В примере интерфейс fe-0/1/0 on R2 деактивирован, что приводит к отключению основного via-r2 пути. Вский маршрутизатор R1 переключает трафик на вторичный via-r7 путь.

Смысл

Пример выходных данных маршрутизатор исходящего трафика показывает, что правильно настроен вторичный путь в режиме ожидания, так как основной R1 путь все еще находится в состоянии down. При деактивации интерфейса (на) критическом для основного пути, основной путь отключает и включается standby secondary путь, позволяющий переключять трафик на вторичный путь в режиме interface fe-0/1/0R2via-r2 via-r7R1 ожидания.

Проверка физический уровень

Цель

После настройки LSP, выдав команду и определив, что имеется ошибка, можно начать изучение проблемы на физическом show mpls lsp extensive уровне сети.

Рис. 3 иллюстрирует физический уровень многоуровневой MPLS модели.

Рис. 3: Проверка физический уровеньПроверка физический уровень

С помощью этого уровня необходимо убедиться в том, что маршрутизаторы подключены, интерфейсы находятся в исправном месте и настроены правильно на входящем, выходящем и транзитном маршрутизаторах.

Если сеть не функционирует на этом уровне, путь с коммутааной меткой (LSP) не будет работать так, как законфигурирован.

Рис. 4 иллюстрирует MPLS и проблему, описанную в этом разделе.

Рис. 4: MPLS сеть, разбитая на физический уровеньMPLS сеть, разбитая на физический уровень

Сеть, показанная в полносетевой конфигурации, где каждый непосредственно подключенный интерфейс может принимать и посылать пакеты Рис. 4 на любой другой аналогичный интерфейс. LSP в этой сети настроен на запуск от входящего маршрутизатора через транзитный маршрутизатор R1R3 для R6 маршрутизатор исходящего трафика. Кроме того, обратный LSP настраивается для работы с сквозной перенаправлением R6R3 на создание R1 двухнаправленного трафика.

Однако в этом примере трафик не использует настроенный LSP. Вместо этого трафик использует альтернативный маршрут от сквозного к R1 и R2 в R6 обратном направлении, от R6R5 to R1 сквозного.

Когда становится известно о ситуации, когда используется не настроенный LSP, а альтернативный маршрут, убедитесь, что физический уровень функционирует исправно. Может обнаружиться, что маршрутизаторы не подключены или интерфейсы не находятся в сети и настроены правильно на входящем, выходящем или транзитном маршрутизаторе.

Показано перекрестное обозначение места, где LSP сломан из-за ошибки Рис. 4 конфигурации на впадаемом маршрутизаторе. R1

Для проверки физического уровня выполните следующие действия:

Проверка LSP

Цель

Обычно команда используется для show mpls lsp extensive проверки LSP. Однако для быстрой проверки состояния LSP используйте show mpls lsp команду. Если LSP не используется, используйте extensive этот параметр show mpls lsp extensive) (в качестве последующей. Если в сети имеется несколько LSP, можно рассмотреть возможность указания имени LSP с помощью name параметра show mpls lsp name name (или show mpls lsp name name extensive).

Действий

Чтобы определить, что LSP находится в up, введите следующую команду из входного маршрутизатора:

Пример выходных данных
command-name

Смысл

Пример выходных данных маршрутизатора в выходных данных показывает, что LSP использует R1 альтернативный путь, а не настроенный путь. Настроенный путь для LSP проходит через обратный LSP до и для обратного R1R3R6, LSP R6 до R3R1 . Альтернативный путь, используемый LSP, проходит через обратный R1R2R6, LSP, R6 t hrough R5 к R1 .

Проверка подключения маршрутизатора

Цель

Подтвердим, что соответствующие входящие, транзитные и маршрутные маршрутизаторы функционируют, проверяя, были ли пакеты получены и переданы с 0% потерей пакетов.

Действий

Чтобы определить, что маршрутизаторы подключены, введите следующую команду от входных и транзитных маршрутизаторов:

Пример выходных данных
command-name

Смысл

Пример выходных данных показывает, что входящий маршрутизатор получает пакеты от транзитного маршрутизатора и что транзитный маршрутизатор R1R3 маршрутизатор исходящего трафика. Поэтому маршрутизаторы lSP подключены.

Проверка интерфейсов

Цель

Подтвердим, что интерфейсы сконфигурированы правильно с помощью family mpls утверждения.

Действий

Чтобы определить, что соответствующие интерфейсы находятся в входящем, транзитном и выходном маршрутизаторах, введите следующие команды:

Пример выходных данных
command-name

Смысл

Пример выходных данных показывает, что на интерфейсе в маршрутизаторе в момент вплышения не настроена утверждение на уровне [] иерархии, что означает, что интерфейс неправильно настроен для поддержки so-0/0/2.0family mplsedit interfaces type-fpc/pic/port LSP. LSP настроен правильно на уровне edit protocols mpls [] иерархии.

Выходные данные транзитных и выходных маршрутизаторов (не показаны) показывают, что интерфейсы этих маршрутизаторов настроены правильно.

Примите соответствующие меры

Проблема

Описание

В зависимости от ошибок, с которыми вы столкнулись в ходе исследования, необходимо принять соответствующие меры для устранения проблемы. В приведенной ниже примере утверждение, отсутствующий, включено в family mpls конфигурацию веского R1 маршрутизатора.

Решение

Чтобы исправить ошибку в этом примере, введите следующие команды:

Пример выходных данных
Смысл

Пример выходных данных в маршрутизаторе впадания показывает, что утверждение настроено правильно для интерфейса и что LSP теперь работает так, как R1family mpls первоначально so-0/0/2.0 конфигурирован.

Снова проверьте LSP

Цель

После принятия надлежащих мер для исправления ошибки LSP необходимо еще раз проверить, чтобы подтвердить, что проблема на физическом уровне устранена.

Действий

Чтобы убедиться, что LSP находится в up и проходит по сети, введите следующую команду:

Пример выходных данных 1
command-name
Пример выходных данных 2
command-name

Смысл

Пример выходных данных 1 от впадаемго маршрутизатора показывает, что LSP теперь проходит по сети по ожидаемому пути, от сквозного к и обратному R1 R1R3 R6 LSP, от R6R3R1 к.

Пример выходных данных 2 от веского маршрутизатора показывает, что LSP принудительно перебирает предполагаемый путь, MPLS на интерфейсах деактивируется. R1 R1 so-0/0/0.0so-0/0/1.0 Если эти интерфейсы не деактивированы, даже если конфигурация теперь правильна, LSP все равно будет проходить по сети по альтернативному пути.

Проверка ip и IGP уровней

Проблема

Описание

После того, как коммутируемый по метке путь (LSP), выдав команду и определив, что имеется ошибка, можно обнаружить, что ошибка не находится на физическом уровне или на уровнях передачи show mpls lsp extensive данных. Продолжайте изучение проблемы на IP-IGP уровнях сети.

Рис. 7 иллюстрирует IP IGP уровней многоуровневой MPLS модели.

Рис. 7: IP и IGP уровнейIP и IGP уровней

Решение

На уровнях IP и IGP необходимо проверить следующее:

  • Интерфейсы имеют правильную IP-адресу, а IGP или соседства устанавливаются.

  • Open Shortest Path First (OSPF) или протокол маршрутизации промежуточных систем (IS-IS) протоколы настроены и работают корректно.

    • Если протокол OSPF настроен, сначала проверьте УРОВЕНЬ IP, затем OSPF, убедившись, что протокол, интерфейсы и управление трафиком настроены правильно.

    • Если протокол IS-IS настроен, то в первую очередь проверка IS-IS IP не имеет значения, поскольку оба протокола независимы друг от друга. Убедитесь IS-IS что IS-IS и интерфейсы и IS-IS настроены правильно.

      Прим.:

      Протокол IS-IS включен управление трафиком по умолчанию.

Если сеть не работает на уровне IP или IGP, LSP не будет работать так, как законфигурирован.

Рис. 8 иллюстрирует MPLS, используемых в данной теме.

Рис. 8: MPLS сети, разбитой на IP- и IGP уровняхMPLS сети, разбитой на IP- и IGP уровнях

Сеть, показанная в полносетевой конфигурации, где каждый непосредственно подключенный интерфейс может принимать и посылать пакеты Рис. 8 на любой другой аналогичный интерфейс. LSP в этой сети настроен на запуск от входящего маршрутизатора через транзитный маршрутизатор R1R3 для R6 маршрутизатор исходящего трафика. Кроме того, обратный LSP настроен для работы от R6 ( через ) к созданию R3R1 двухнаправленного трафика. Перекрестные скрещении указывают на то, где LSP не работает из-за следующих проблем на Рис. 8 IP-IGP уровне:

  • IP-адрес настроен неправильно на маршрутизаторе в направлении маршрутизатора R1 ().

  • Протокол OSPF настроен с ID (RID) маршрутизатора, но без петли () интерфейса, и управление трафиком отсутствует на транзитном lo0 маршрутизаторе R3 ().

  • Уровни в IS-IS нео несоответствия.

Проверка ip-уровня

Цель

Можно проверить уровень IP до или после того, как проверить уровень протокола внутреннего шлюза (IGP) в зависимости от того, настроены ли OSPF или IS-IS в качестве IGP. Если ваша MPLS сеть настроена с OSPF в качестве IGP, необходимо сначала проверить уровень IP, проверив, что интерфейсы имеют правильную IP-адресу и что OSPF соседи установлены перед OSPF уровней.

Если в IS-IS настроены IGP качестве MPLS сети, можно сначала проверить уровень IP или IS-IS протокол. Порядок проверки IP или IS-IS не влияет на результаты.

Рис. 9: MPLS сети, разбитой на IP-уровнеMPLS сети, разбитой на IP-уровне

Cross in показывает, где LSP сломан из-за неправильной конфигурации Рис. 9 IP-адреса на впадаемом R1 маршрутизаторе.

Проверка LSP

Цель

После настройки LSP необходимо убедиться, что LSP находится в up. LPS могут быть входящими, транзитными или egress. Используйте эту команду для быстрой проверки состояния LSP с помощью параметра (в качестве последующей проверки при show mpls lspextensive отстаании show mpls lsp extensive) LSP. Если в сети имеется несколько LSP, можно рассмотреть возможность указания имени LSP с помощью name параметра show mpls lsp name name show mpls lsp name name extensive) (или.

Действий

Чтобы убедиться в том, что LSP находится в up, введите следующую команду из входного маршрутизатора:

Пример выходных данных 1
command-name

Смысл

Пример выходных данных в маршрутизаторе в выходных данных показывает, что MPLS произошел сбой размещения меток и не удалось получить алгоритм R1 "Constrained Shortest Path First" (CSPF), в результате чего маршрут к пункту назначения on не 10.0.0.6 был. R6

Проверка IP-адресов

Цель

При проверке IP-уровня убедитесь, что интерфейсы имеют правильную IP-адресу и что OSPF или IS-IS соседства установлены. В данном примере IP-адрес настроен неправильно на впадаемом маршрутизаторе R1 ().

Действий

Для проверки IP-адресов введите следующую команду на входных, транзитных и выходных маршрутизаторах:

Пример выходных данных
command-name

Смысл

Пример выходных данных показывает, что IP-адреса для интерфейса so-0/0/2.0R1 "on" и so-0/0/2.0 "interface R3 on" идентичны. IP-адреса интерфейсов в сети должны быть уникальными, чтобы интерфейс был правильно идентифицирован.

Проверка соседей или соседей на уровне IP

Цель

Если IP-адресная адресовка настроена неправильно, OSPF соседей или IS-IS соседей должны быть проверены, чтобы определить, установлен один из них или оба.

Действий

Для проверки соседей (OSPF) или смечений (IS-IS) введите следующие команды из входящего, транзитного и выходного маршрутизаторов:

Пример выходных данных 1
command-name
Пример выходных данных 2
command-name

Смысл

Пример выходных данных 1 от входящего, транзитного и выходного маршрутизаторов показывает, что и не OSPF R1R3 соседям. Учитывая, что два интерфейса (и) настроены с одинаковыми so-0/0/2.0R1R3 IP-адресами, это можно ожидать. Протокол OSPF маршруты IP-пакетов исключительно на основе IP-адреса назначения, содержащихся в ip-пакете. Поэтому одинаковые IP-адреса в автономной системе (AS) приводит к тому, что соседи не устанавливаются.

Пример выходных данных 2 для входящего, транзитного и выходного маршрутизаторов показывает, что и установлено IS-IS, несмотря на идентичные IP-адреса, настроенные на интерфейсах R1R3 on и so-0/0/2.0R1R3 . Протокол IS-IS ведет себя по-другому от OSPF, поскольку он не полагается на IP-установление сдежности. Однако, если LSP не активен, будет еще полезно проверить IP-адресную информацию подсети на случай ошибки на этом уровне. Исправление ошибки адресирования может привести к обратному отополнения LSP.

Примите соответствующие меры

Проблема

Описание

В зависимости от ошибок, с которыми вы столкнулись в ходе исследования, необходимо принять соответствующие меры для устранения проблемы. В данном примере неверно настроен IP-адрес интерфейса на R2 транзитном маршрутизаторе.

Решение

Чтобы исправить ошибку в этом примере, введите следующие команды:

Пример выходных данных
Смысл

Пример выходных данных показывает, что интерфейс в маршрутизаторе в направлении в направлении пользователя теперь настроен с so-0/0/2R1 правильным IP-адресом. Это исправление приводит к уникальным IP-адресам подсети для всех интерфейсов сети MPLS в сети MPLS Network Broken at the IP и IGP Layers,а также к возможности создания LSP.

Снова проверьте LSP

Цель

После принятия надлежащих мер для исправления ошибки LSP необходимо еще раз проверить, чтобы подтвердить, что OSPF устранена проблема в протоколе.

Действий

Для повторной проверки LSP введите следующую команду на входных, транзитных и выходных маршрутизаторах:

Пример выходных данных 1
command-name
Пример выходных данных 2
command-name
Пример выходных данных 3
command-name

Смысл

Пример выходных данных 1 от впадаемго маршрутизатора показывает, что LSP имеет активный маршрут к и R1R1-to-R6 состояние R6 работает. Выходные данные показывают, что в выходной сеанс LSP R6-to-R1 была получена и отправлена метка восстановления.

Пример выходных данных 2 от транзитного маршрутизатора показывает, что имеются два транзитных сеанса LSP, один из них в направлении, а другой от к R3R1R6R6 обоим R1. LSP находятся в up.

Пример выходных данных 3 маршрутизатор исходящего трафика показывает, что LSP активен, и активным R6 маршрутом является основной маршрут. Теперь LSP проходит через сеть по ожидаемому пути, от сквозного к обратному, и обратному R1R3 R6 LSP, от R6 сквозного R3R1 к.

Снова проверьте LSP

Цель

После принятия надлежащих мер для исправления ошибки LSP необходимо снова проверить, чтобы подтвердить, что IS-IS устранена проблема в протоколе.

Действий

Чтобы проверить, что LSP находится в up и проходит по сети, введите следующую команду на входных, выходных и транзитных маршрутизаторах:

Пример выходных данных

command-name

Смысл

Пример выходных данных от веского маршрутизатора и маршрутизатор исходящего трафика показывает, что LSP теперь проходит по сети по ожидаемому пути, от сквозного к и обратному R1 R6 R1R3 R6 LSP, R6R3 от R1 к. Кроме того, пример выходных данных транзитного маршрутизатора показывает, что существует два транзитных сеанса LSP: один из них в направлении и другой R3R1 из R6R6R1 в.

Проверка уровня RSVP

Цель

После того, как вы настроили путь с коммутаатом по метке (LSP), выдав команду и определив, что имеется ошибка, может произойти не на физическом уровне, ни на физическом, ни на физическом, ни на коммутате данных, ни на уровне протоколов (IP) и внутренних IGP show mpls lsp extensive шлюзов. Продолжайте изучение проблемы на уровне RSVP сети.

Рис. 10 иллюстрирует уровень RSVP многоуровневой MPLS модели.

Рис. 10: Проверка уровня RSVPПроверка уровня RSVP

На этом уровне проверяется, что динамическая сигнализация RSVP происходит так, как ожидалось, соседи подключены, и интерфейсы правильно настроены для RSVP. Проверьте входящую, отходящую и транзитную маршрутизаторы.

Если сеть не работает на этом уровне, LSP не будет работать так, как законфигурирован.

Рис. 11 иллюстрирует MPLS, используемых в данной теме.

Рис. 11: MPLS сеть, разбитая на уровне RSVPMPLS сеть, разбитая на уровне RSVP

Сеть, показанная в полносетевой конфигурации, где каждый непосредственно подключенный интерфейс может принимать и посылать пакеты Рис. 11 на любой другой аналогичный интерфейс. LSP в этой сети настроен на запуск от входящего маршрутизатора через транзитный маршрутизатор R1R3 для R6 маршрутизатор исходящего трафика. Кроме того, обратный LSP настраивается для работы с сквозной перенаправлением R6R3 на создание R1 двухнаправленного трафика.

Однако в этом примере LSP отстает без пути в любом направлении — R1 от к или от R6R6R1 к.

Скрещенные Рис. 11 скрещенные скрещенные скрещены показано, где разбит LSP. Некоторые возможные причины, по которой происходит размыкание LSP, могут включать, что динамическая сигнализация RSVP не происходит, соседи не подключены или интерфейсы неправильно настроены для RSVP.

В сети in ошибка конфигурации на транзитном маршрутизаторе предотвращает прохождение Рис. 11R3 LSP по сети.

Чтобы проверить уровень RSVP, выполните следующие действия:

Проверка LSP

Цель

Обычно команда используется для show mpls lsp extensive проверки LSP. Однако для быстрой проверки состояния LSP используйте show mpls lsp команду. Если LSP не используется, используйте extensive этот параметр show mpls lsp extensive) (в качестве последующей. Если в сети имеется несколько LSP, можно рассмотреть возможность указания имени LSP с помощью name параметра show mpls lsp name name (или show mpls lsp name name extensive).

Действий

Чтобы определить, что LSP находится в up, введите следующую команду из входного маршрутизатора:

Пример выходных данных 1
command-name

Смысл

Пример выходных данных показывает, что LSP отстает в обоих направлениях— R1 от к и от R6R6R1 к. Выходные данные показывают, что используется R1 no-cspf LSP, поскольку он пытался исходят вызов, не достигая R1 места назначения. Выходные данные показывают, что алгоритм R6 "Constrained Shortest Path First" (CSPF) не сбой, в результате чего маршрут к пункту назначения не 10.0.0.1 проходит.

Проверка сеансов RSVP

Цель

После успешного создания сеанса RSVP LSP устанавливается на пути, созданные сеансом RSVP. Если сеанс RSVP неуспешен, LSP не будет работать так, как законфигурирован.

Действий

Чтобы проверить активные в данный момент сеансы RSVP, введите следующую команду на входящем, транзитном и выходном маршрутизаторах:

Пример выходных данных 1
command-name
Пример выходных данных 2
command-name

Смысл

Пример выходных данных 1 от всех маршрутизаторов показывает, что сеансы RSVP не были успешно созданы, даже если LSP R6-to-R1 настроен.

В отличие от примера выходных данных 1 иллюстрируют правильные выходные данные, в примере выходных данных 2 показаны выходные данные входящего, транзитного и выходного маршрутизаторов, когда конфигурация RSVP правильна, и LSP проходит сеть в заданная конфигурация. R1и R6 оба показывают сеансы ingress и egress RSVP, с LSP R1-to-R6 и обратным LSP. R6-to-R1 Транзитный маршрутизатор R3 показывает два транзитных сеанса RSVP.

Проверка соседей по RSVP

Цель

Отображение списка соседей RSVP, которые были динамически заучены при обмене пакетами RSVP. Как только сосед узнает, он никогда не удаляется из списка соседей RSVP, если конфигурация RSVP не удалена из маршрутизатора.

Действий

Для проверки соседей по RSVP введите следующую команду на входных, транзитных и выходных маршрутизаторах:

Пример выходных данных 1
command-name
Пример выходных данных 2
command-name

Смысл

Пример выходных данных 1 показывает, R1 что и имеет один сосед R6 RSVP каждый, R3 . Однако значения в поле отличаются. Имеет значение, которое указывает на то, что является активным соседом с, но Up/DnR1 не 1/0 R61/1R1R3R6 является. Если количество вверх больше, чем меньше, сосед активен; если значения равны, сосед отсоеводится. Значения для них R6 равны, что 1/1 указывает на то, что соседний R3 окну не находится.

Транзитный маршрутизатор R3 знает о двух соседних R1 маршрутизаторах, R6 и. Это Up/Dn поле указывает, что R1 является активным соседом и не R6 работает. На данном этапе невозможно определить, является ли проблема активной, или потому что оба соседа R3 R6 не являются активными.

В отличие от примера выходных данных 1 и для иллюстрации корректных выходных данных, Пример выходных данных 2 показывает правильную связь между транзитным маршрутизатором и R3 R6 маршрутизатор исходящего трафика. Поле показывает, что количество вверх больше, чем количество неавт, что означает активность Up/Dn1/0 соседей.

Проверка интерфейсов RSVP

Цель

Отобразить состояние каждого интерфейса, на котором включен RSVP, чтобы определить место ошибки конфигурации.

Действий

Чтобы проверить состояние интерфейсов RSVP, введите следующую команду на входных, транзитных и выходных маршрутизаторах:

Пример выходных данных 1
command-name
Пример выходных данных 2
command-name

Смысл

Пример выходных данных 1 показывает, что даже если у каждого маршрутизатора есть интерфейсы, которые работают и имеют активный RSVP, резервирования на любом из Active resv) маршрутизаторов не существует. В данном примере ожидается как минимум одно резервирование на входящем и выходящем маршрутизаторах, а также два резервирования на транзитном маршрутизаторе.

Кроме того, интерфейс транзитного маршрутизатора в конфигурацию so-0/0/3 не R3 включен. Включение этого интерфейса имеет решающее значение для успеха LSP.

В отличие от примера выходных данных 1 и для иллюстрации корректных выходных данных в примере выходных данных 2 показаны соответствующие интерфейсы с активными резервированием.

Проверка конфигурации протокола RSVP

Цель

Проверив сеансы RSVP, интерфейсы, соседи и определите, что имеется ошибка конфигурации, проверьте конфигурацию протокола RSVP.

Действий

Чтобы проверить конфигурацию RSVP, введите следующую команду на входных, транзитных и выходных маршрутизаторах:

Пример выходных данных
command-name

Смысл

Пример выходных данных показывает, R3 что интерфейс отсутствует в so-0/0/3.0 конфигурации протокола RSVP. Этот интерфейс критически важен для правильной работы LSP.

Примите соответствующие меры

Проблема

Описание

В зависимости от ошибок, с которыми вы столкнулись в ходе исследования, необходимо принять соответствующие меры для устранения проблемы. В данном примере отсутствует интерфейс в конфигурации маршрутизатора М3.

Решение

Чтобы исправить ошибку в этом примере, выполните следующие действия:

  1. Включит отсутствующий интерфейс в конфигурацию транзитного маршрутизатора R3:

  2. Проверьте и сфиксировать конфигурацию:

Пример выходных данных
Смысл

Пример выходных данных показывает, что отсутствующий интерфейс на транзитном маршрутизаторе теперь правильно включен на уровне so-0/0/3.0R3 edit protocols rsvp иерархии [] Это приводит к возможности использования LSP.

Снова проверьте LSP

Цель

После принятия надлежащих мер для исправления ошибки LSP необходимо еще раз проверить, чтобы подтвердить, что MPLS на уровне решена.

Действий

Для повторной проверки LSP введите следующую команду на входных, транзитных и выходных маршрутизаторах:

Пример выходных данных 1
command-name
Пример выходных данных 2
command-name
Пример выходных данных 3
command-name

Смысл

Пример выходных данных 1 от впадаемго маршрутизатора показывает, что LSP имеет активный маршрут к и R1R1-to-R6 состояние R6 работает.

Пример выходных данных 2 от транзитного маршрутизатора показывает, что есть два транзитных сеанса LSP, один из них в направлении и другой R3R1 из R6 R6R1 в. Оба LSP в том же ок.

Пример выходных данных 3 маршрутизатор исходящего трафика показывает, что LSP активен, и активным R6 маршрутом является основной маршрут. Теперь LSP проходит через сеть по ожидаемому пути, от сквозного к обратному, и обратному R1R3R6 LSP, от R6 сквозного R3R1 к.

Определение статистики LSP

Цель

Отображение подробных сведений о объектах RSVP для диагностики проблемы LSP.

Действий

Для проверки объектов RSVP введите команду Junos OS интерфейс командной строки operational mode:

Пример выходных данных

command-name

Смысл

Пример выходных данных показывает, что имеется один сеанс въеха и один выходной сеанс RSVP. В сеансе в сеансе въеха имеется адрес источника () и сеанс 10.0.0.1 работает с одним активным R1 маршрутом. Имя LSP есть R1-to-R6 и является основным путем для LSP.

Метка восстановления () отправляется маршрутизатором с изящной перезагрузкой соседнему маршрутизатору для восстановления 100064 состояния перенаправки. Вероятно, это старая метка, объявленная маршрутизатором перед тем, как она пошлялась вниз.

Этот сеанс использует фиксированный фильтр FF () тип резервирования Resv style ( ). Поскольку это входящий маршрутизатор, то входящие метки не существует. Исходящие метки (предоставлены следующим следующую метку маршрутизатора) является 100064 .

В поле содержится значение в секундах, оставшееся в сеансе RSVP, и объект предоставляет информацию о контролируемой скорости загрузки () и максимальном размере пакета (), о бесконечном значении () для параметра гарантированной доставки и о том, что пакеты размером меньше 20 bytes обрабатываются как 20 bytes, в то время как пакеты больше Time LeftTspec ratepeak 1500 bytes обработаны как Infbps 1500 bytes.

Номер порта – это IPv4-туннельный ID, а номер порта отправитель/приемник – LSP ID. Туннельный IPv4 ID является уникальным для жизни LSP, в то время как ID LSP отправитель/приемник может изменить, например, с резервированием стилей SE.

В PATH rcvfrom поле содержится источник сообщения о пути. Так как это вский маршрутизатор, локальный клиент и исходя из сообщения о пути.

Поле содержит пункт назначения сообщения о пути () и PATH sentto10.1.13.2 исходяющий интерфейс so-0/0/2.0 (). Поле содержит источник полученного сообщения RESV rcvfrom Resv () и 10.1.13.2 входящий интерфейс so-0/0/2.0 ().

Значения явных маршрутов RSVP и записи маршрутов идентичны: 10.1.13.2 и 10.1.36.2 . В большинстве случаев значения явных маршрутов и маршрутов записи идентичны. Различия показывают, что произошла неполная перенастройка пути, как правило, во время быстрого перенастройки.

Эти поля указывают общее количество сеансов ingress, egress и transit RSVP, причем общее количество сеансов равняется сумме сеансов up Total и down. В данном примере имеется один входящий, один сеанс для выпадательных и нет транзитных сеансов RSVP.

Проверка использования LSP в сети

Цель

При проверке допустимого использования LSP на входящем и транзитном маршрутизаторах сети можно определить, возникла ли проблема с многопротокольная коммутация по меткам (MPLS) в сети. Рис. 12 описывает пример сети, используемой в этом разделе.

Рис. 12: MPLS топологии для проверки использования LSPMPLS топологии для проверки использования LSP

Сеть MPLS иллюстрирует сеть только для маршрутизатора с интерфейсами SONET, состоящими Рис. 12 из следующих компонентов:

  • Полноявая внутренняя Border Gateway Protocol (IBGP) топология с использованием AS 65432

  • MPLS и протокол резервирования ресурсов (RSVP) включен на всех маршрутизаторах

  • Политика send-statics на маршрутизаторах М1 и 6, которая позволяет объявлять новый маршрут в сети

  • LSP между маршрутизаторами М1 и R6

Сеть, показанная Рис. 12 в этом Border Gateway Protocol (BGP) полноявая. Поскольку отражатели и конфедерации маршрутов не используются для распространения BGP, каждый маршрутизатор должен иметь сеанс BGP с каждым другим маршрутизатором, работающим BGP.

Чтобы проверить использование LSP в сети, выполните следующие действия:

Проверка LSP на впадаемом маршрутизаторе

Цель

Доступность LSP можно проверить при его работоспособности, проверив таблицу маршрутов inet.3 на впадаемом маршрутизаторе. Таблица inet.3 маршрутов содержит адрес хоста каждой маршрутизатор исходящего трафика. Эта таблица маршрутов используется на впадающих маршрутизаторах для BGP пакетов к маршрутизатор исходящего трафика. BGP использует таблицу маршрутов на маршрутизаторе впадаем, чтобы помочь в разрешении адресов inet.3 следующего перехода.

Действий

Чтобы проверить LSP на входном маршрутизаторе, введите команду Junos OS интерфейс командной строки (интерфейс командной строки) в режиме эксплуатации:

Пример выходных данных
command-name

Смысл

Пример выходных данных показывает inet.3 таблицу маршрутов. По умолчанию только виртуальные BGP и MPLS частные сети (VPN) могут использовать таблицу маршрутов для разрешения информации inet.3 о следующем переходе. Один пункт назначения указан в таблице 10.0.0.6 маршрутов. Это место назначения (сигнализируется RSVP и является текущим активным путем, как указано 10.0.0.6) звездочкой). * Параметром предпочтения протокола для этого маршрута 7 является , а метрика, связанная с ним, является 20 . Путь с переключениями на метку проходит через интерфейс , который является транзитным интерфейсом следующего R1-to-R6so-0/0/2.0 физического перехода.

Обычно предпоследний маршрутизатор LSP либо отскакиет метку пакета, либо изменяет метку на значение 0. Если предпоследний маршрутизатор выскакиет верхнюю метку и внизу находится пакет IPv4, маршрутизатор исходящего трафика маршрутизировал пакет IPv4, консультируясь с таблицей IP-маршрутов для определения, как перенаправление inet.0 пакета. Если под верхней меткой находится другой тип метки (например, созданный протоколом распределения меток (LDP) или VPN, но не IPv4, то маршрутизатор исходящего трафика не исследует таблицу inet.0 маршрутов. Вместо этого он анализирует таблицу mpls.0 маршрутов для принятия решений о переадке.

Если предпоследний маршрутизатор изменяет метку пакета на значение 0, маршрутизатор исходящего трафика отключается метка 0, что указывает на последующий пакет IPv4. Пакет рассматривается таблицей маршрутов для принятия inet.0 решений о переададаторе.

Когда транзитный или маршрутизатор исходящего трафика получает пакет MPLS, информация в MPLS таблица переадресации используется для определения следующего транзитного маршрутизатора в LSP или этот маршрутизатор является маршрутизатор исходящего трафика.

Когда BGP устраняет префикс следующего перехода, он проверяет и таблицы маршрутов, и ищет следующий переход с наименьшим inet.0 предпочтением; например, предпочтение RSVP 7 предпочтительнее, чем OSPF inet.3 предпочтение 10. Сигнальный LSP RSVP используется для достижения BGP перехода. Это значение по умолчанию, если BGP следующему переходу равен адресу отката LSP. После BGP следующего перехода через LSP, трафик BGP LSP для BGP транзитного трафика.

Проверка LSP на транзитном маршрутизаторе

Цель

Доступность LSP в работоспособном случае можно проверить, проверив таблицу маршрутов mpls.0 на транзитном маршрутизаторе. MPLS ведет таблицу маршрутов, в которой содержится список следующих коммутаторов с меткой mpls.0 в каждом LSP. Эта таблица маршрутов используется на транзитных маршрутизаторах для маршрутки пакетов следующему маршрутизатору по LSP.

Действий

Чтобы проверить LSP на транзитном маршрутизаторе, введите следующую команду Junos OS интерфейс командной строки operational mode:

Пример выходных данных
command-name

Смысл

В примере выходных данных транзитного маршрутизатора показаны записи маршрутов в форме MPLS меток, указывающих на то, что существует только один активный маршрут, несмотря на то, что существует R3 пять активных записей.

В первых трех MPLS метки зарезервированы MPLS метки, определенные в RFC 3032. Пакеты, полученные с этими значениями меток, отправляются на модуль маршрутизации обработку. Метка 0 является явной null-меткой IPv4. Метка 1 является MPLS меткой alert IP-маршрутизатора, а Label 2 – явной null-меткой IPv6.

Две записи с меткой являются для одного LSP, существует две записи, так как значения стека в головном MPLS могут 100064R1-to-R6. быть разными. Вторая запись, указывает, что глубина стека не является 1, и в пакет включены дополнительные значения 100064 (S=0) меток. В отличие от этого, первая запись содержит вывод S=1, что указывает на глубину стека 1 и делает ее последней 100064 меткой в пакете. Двойная запись указывает, что это предпоследний маршрутизатор. Дополнительные сведения о стеке MPLS меток см. в RFC 3032, MPLS Label Stack Encoding.

Входящий ярлык является MPLS входящего пакета MPLS и присвоен RSVP соседу входящего потока. Juniper Networks маршрутизаторы динамически присваивают метки для LPS, спроектированных трафиком RSVP, в диапазоне от 100 000 до 1 048 575.

Маршрутизатор присваивает метки, начиная с метки 100 000, с приращениями 16. Последовательность назначений меток: 100 000, 100 016, 100 032, 100 048 и так далее. В конце присвоенных меток номера меток начинаются с значения 100001, приращение к единицам 16. Juniper Networks зарезервировать метки для различных целей. Табл. 1 перечисляет различные распределения диапазона меток для входящих меток.

Табл. 1: MPLS меток диапазонов

Входящий метка

Статус

0 Через 15

Зарезервировано IETF

16 Через 1023

Зарезервировано для статического назначения LSP

1024 Через 9999

Зарезервировано для внутреннего использования (например, метки CCC)

10,000 Через 99,999

Зарезервировано для статического назначения LSP

100,000 Через 1,048,575

Зарезервировано для динамического назначения меток

Проверка работы балансировки нагрузки

Цель

После настройки балансировки нагрузки убедитесь, что трафик одинаково сбалансирован по всем путям. В этом разделе выходные данные команды отражают конфигурацию балансировки нагрузки в примере сети, показанную в топологии сети с балансировой нагрузкой. Команды используются для сброса значений LSP и счетчиков интерфейса в ноль, так что значения отражают работу конфигурации clear балансировки нагрузки.

Действий

Для проверки балансировки нагрузки между интерфейсами и LPS используйте следующую команду на в агрессивном маршрутизаторе:

Чтобы проверить балансировку нагрузки между интерфейсами и LPS, используйте на транзитном маршрутизаторе следующие команды:

Пример выходных данных

command-name

Следующий пример выходных данных для конфигурации на маршрутизаторе в R1 выходе:

Смысл

Пример выходных данных команды на маршрутизаторе в направлении впадания показывает, что балансировка нагрузки правильно сконфигурирована с show configurationR1 помощью утверждения lbpp политики. Кроме того, lbpp политика экспортируется в таблица переадресации на [edit routing-options] уровне иерархии.

Пример выходных данных

Следующий пример выходных данных от транзитного маршрутизатора М2:

Смысл

Пример выходных данных команды, выданной на транзитном маршрутизаторе, показывает два пути с равной стоимостью (и через сеть к адресу обратной связи show routeR2 к so-0/0/1so-0/0/2) R0192.168.0.1 (). Даже если правая скоба (>) обычно указывает активный маршрут, в данном случае это не так, как показано в следующих четырех выходных данных.

Пример выходных данных

Следующий пример выходных данных от транзитного маршрутизатора М2:

Смысл

Пример выходных данных для команды, выданной на транзитном маршрутизаторе, показывает, что выходной трафик равномерно распределяется между monitor interface trafficR2 двумя so-0/0/1 интерфейсами so-0/0/2 и.

Пример выходных данных

Следующий пример выходных данных от транзитного маршрутизатора М2:

Смысл

Пример выходных данных для команды, выданной на транзитном маршрутизаторе, показывает, что выходной трафик равномерно распределяется между четырьмя LSP, настроенными на show mpls lsp statisticsR2 входящем R6 маршрутизаторе.

Пример выходных данных

Следующий пример выходных данных от транзитного маршрутизатора М2:

Смысл

Пример выходных данных для команды, выданной на транзитном маршрутизаторе, показывает в поле, что показывает, что show route forwarding-table destinationR2ulstType балансировка нагрузки работает. Два одноналетных (записи в поле являются двумя следующими переходами ucst)Type для LSP.

Пример выходных данных

Следующий пример выходных данных от транзитного маршрутизатора М2:

Смысл

Пример выходных данных для команды, выданной на транзитном маршрутизаторе R2, показывает таблицу маршрутов MPLS, которая содержит метки, полученные и используемые этим маршрутизатором для передачи пакетов маршрутизатору следующего show route forwarding-table | find mpls перехода. Таблица маршрутов используется главным образом на транзитных маршрутизаторах для маршрутки пакетов следующему маршрутизатору по LSP. Первые три метки в столбце (Метка 0, Метка 1 и Метка 2) автоматически вписались MPLS, когда Destination протокол включен. Эти метки зарезервированы MPLS меток, определенных в RFC 3032. Метка 0 является явной null-меткой IPv4. Метка 1 является эквивалентом MPLS метки IP Router Alert, а Label 2 – явной null-меткой IPv6.

Оставшиеся пять меток в столбце являются нерезе заданными метами, которые использует маршрутизатор для перенаправки трафика, а в последнем столбце – интерфейсы, используемые для отправки DestinationNetif маркировного трафика. Во втором столбце показана операция, выполняемая для Type совпадающих пакетов для нерезереженных меток. В этом примере все не зарезервированные пакеты заменяются на метки исходяющих пакетов. Например, перед выталкивкой за интерфейс пакеты с меткой меняются 100112100032so-0/0/1.0 меткой.

Проверка работы балансировки нагрузки неоднородной полосы пропускания

Цель

Когда маршрутизатор выполняет распределение нагрузки с неравной стоимостью между путями LSP, команда отображает поле балансировки, связанное с каждым используемым show route detail следующим переходом.

Действий

Чтобы убедиться в том, что RSVP LSP значительно сбалансирован по нагрузке, используйте следующие Junos OS интерфейс командной строки режима эксплуатации:

Пример выходных данных

command-name

Смысл

Пример выходных данных в маршрутизаторе впадания показывает, что трафик распределяется в соответствии с конфигурацией полосы пропускания LSP, как указано R1 в Balance: xx% поле. Например, lsp1 настроена полоса пропускания 10 Мбит/с, что отражено в Balance: 10% поле.

Использование команды traceroute для проверки MPLS меток

Цель

Эту команду можно traceroute использовать для проверки того, что пакеты посылаются через LSP.

Действий

Для проверки MPLS меток введите следующую Junos OS интерфейс командной строки operational mode, где находится IP-адрес или имя host-name удаленного хоста:

Пример выходных данных 1

command-name

Пример выходных данных 2

command-name

Смысл

Пример выходных данных 1 показывает, MPLS метки используются для передачи пакетов через сеть. В выходных данных содержится значение метки (), значение времени до времени () и значение MPLS Label=100048TTL=1 бита стека S=1 ().

Поле MPLS Label используется для идентификации пакета определенному LSP. Это 20-битное поле с максимальным значением (2^^20-1) или приблизительно 1 000 000.

Значение TTL содержит ограничение на количество переходов, которые MPLS пакет может проходить через сеть (1). Он снижается при каждом переходе, и если значение TTL упадет ниже одного, пакет отбрасывается.

Нижняя часть значения бита стека () указывает, что это последняя метка в стеке и что MPLS имеет с ним S=1 одну метку. Реализация MPLS в серии Junos OS поддерживает глубину стеков 3 на маршрутизаторах серии M и до 5 на платформах серии T. Дополнительные сведения о стеке MPLS меток см. в RFC 3032, MPLS Label Stack Encoding.

MPLS метки отображаются в примере выходных данных 1, поскольку команда выдана BGP BGP месту назначения, где следующим переходом для этого маршрута является адрес выхода traceroute LSP. Поведение Junos OS по умолчанию использует LSP для BGP трафика, если следующий BGP перехода равен адресу отката LSP.

Пример выходных данных 2 показывает, MPLS метки не отображаются в выходных данных traceroute команды. Если следующий BGP переход не равен адресу lSP для перехода на другой маршрут или IGP является маршрутом BGP трафик не использует LSP. Вместо использования LSP, BGP трафик использует IGP (IS-IS, в данном случае) для достижения адреса выхода R6 ().

Устранение неполадок GMPLS и туннеля GRE

Проблема

Описание

Логический канал управления для GMPLS должен быть каналом "точка-точка" и иметь некоторую форму IP-достинимости. На широковещательных интерфейсах или при множественных переходах между равноправными узлами контрольного канала используйте туннель GRE для канала управления. Дополнительные сведения о туннелях GMPLS и GRE см. в руководстве Junos MPLS приложений и руководстве пользователя Junos.

Для настройки туннеля GRE для канала управления GMPLS не требуется туннельНОГО PIC. Вместо этого используйте программный интерфейс, а не gre аппаратный gr-fpc/pic/port интерфейс.

ОСТОРОЖНО:

Из-за ограничений для интерфейса, основанного на программном обеспечении, канал управления GMPLS является единственным поддерживаемым использованием gre интерфейса, основанного на gre программном обеспечении. Любое другое использование неподтверчено и может привести к сбою приложения.

В следующем примере показана базовая gre конфигурация интерфейса. В этом случае источником туннеля является адрес обратной связи локального маршрутизатора, а адрес назначения – это адрес обратной связи удаленного маршрутизатора. Трафик, следующий переход в пункте назначения туннеля, будет использовать туннель. Туннель не используется автоматически всем трафиком, проходящим через интерфейс. Туннель использует только трафик с назначением туннеля в качестве следующего перехода.

Пример выходных данных

Пример выходных данных

Следующий пример выходных данных для команды show interfaces показывает тип и зад, максимальную скорость передачи пакетов через логический интерфейс, назначение и логический адрес.

Следующие требования при настройке GMPLS LSP с использованием туннеля GRE:

  • Канал данных должен начинаться и заканчивается на одном типе интерфейса.

  • Канал управления может быть туннелем GRE, который запускается и заканчивается на том же или другом типе интерфейса.

  • Туннель GRE необходимо настраивать косвенно с утверждением peer-interface peer-name на [edit protocol ospf] иерархическому уровне.

  • Интерфейс GRE должен быть отключен на уровнях [edit protocols ospf][edit protocols rsvp] иерархии и на уровне иерархии.

  • Каналы данных и управления должны быть правильно определены в конфигурации LMP.

  • Отключение первого (CSPF) самого короткого пути с помощью утверждения no-cspf является необязательным.

Этот случай сфокусирован на неправильной настройке конечных точек туннеля GRE. Однако для диагностики других проблем туннелей GRE можно использовать аналогичные процессы и команды. Рис. 13 иллюстрирует топологию сети с MPLS туннелю через интерфейс GRE.

Рис. 13: Топология сети GMPLSТопология сети GMPLS

Топология MPLS в топологии Juniper Networks, настроенных с туннелем GRE, который состоит Рис. 13 из следующих компонентов:

  • Строгий путь GMPLS LSP от маршрутизатора в направлении в направлении маршрутизатор исходящего трафика.

  • На впадаемом маршрутизаторе CSPF отключен с помощью утверждения no-cspf на уровне edit protocol mpls label-switched-path lsp-name иерархии []

  • Каналы управления трафиком и каналы управления внутри утверждения peer на уровне иерархии edit protocols link-management [] на всех маршрутизаторах.

  • OSPF и OSPF управление трафиком настроены на всех маршрутизаторах.

  • Ссылка на команды peer-interface in both OSPF RSVP на всех маршрутизаторах.

  • Проблема типа коммутатора между R2 и R3 .

Симптом

LSP в сети, показанной ниже, отстает, как показано в выходных данных команд и команд, которые Рис. 13show mpls lsp отображают очень show rsvp session сходную информацию. Команда отображает все LPS, настроенные на маршрутизаторе, а также все транзитные и show mpls lsp выходящие LPS. Эта show rsvp session команда выводит сводную информацию о сеансах RSVP. Для проверки состояния LSP можно использовать обе команды. В этом случае LSP gmpls-r1-to-r3 отстает Dn ().

Пример выходных данных

Вызвать

Причиной проблемы с GMPLS LSP является конфигурация различных типов интерфейсов на обоих концах канала данных GMPLS.

Команды для устранения неполадок

Список Junos OS включает команды, полезные при устранении неполадок. На данной теме приводится краткое описание каждой команды, а также пример выходных данных и обсуждение выходных данных в связи с проблемой.

Для устранения проблемы GMPLS можно использовать следующие команды:

Пример выходных данных

Используйте команду show mpls lsp extensive на транзитном маршрутизаторе М1, чтобы отобразить подробную информацию обо всех LSP, транзитном, о конце и настройке на маршрутизаторе.

Смысл

Пример выходных данных команды show mpls lsp extensive показывает сообщение об ошибке MPLS label allocation failure) (в разделе журнала выходных данных. Это событие LSP указывает на то, MPLS или утверждение family mpls не были настроены должным образом. Если событию LSP предшествует IP-адрес, то адресом обычно является маршрутизатор, у MPLS ошибка конфигурации. В этом случае может быть по всей видимости, что у маршрутизатора с адресом lo0192.168.4.1R3 () MPLS конфигурации.

Пример выходных данных

Для отображения подробных сведений о сеансах RSVP используйте команду show rsvp session detail.

Смысл

Пример выходных данных команды show rsvp session detail показывает, что LSP gmpls-r1-to-r3 отстает LSPstate: Dn (). Запись маршрута неполная, что указывает на проблему с явным 100.100.100.100 93.93.93.93 маршрутом. Адрес - 100.100.100.100 канал передачи данных, а адрес - канал данных R2 so-0/0/093.93.93.93 R3 on.

Пример выходных данных

Для отображения сведений о соединении равноправных MPLS команды show link-management peer.

Смысл

Пример выходных данных всех маршрутизаторов в примере сети для команды показывает, что все каналы Рис. 13show link-management peer управления находятся в активном и активном месте. Подробный анализ выходных данных показывает следующие сведения:

  • Имя одноранговых узла или то же самое на соседних маршрутизаторах для tester2 tester3 простоты устранения неполадок.

  • Внутренний идентификатор для узла, 48428tester2 для и 48429tester3 для. Внутренний идентификатор - это диапазон значений от 0 до 64 000.

  • Состояние одноранговых узла, которое может быть в состоянии up или down. В этом случае все рангы находятся в сети.

  • Адрес, на который установлен контрольный канал, например 10.35.1.5.

  • Состояние контрольного канала, которое может быть up, down или active.

  • Каналы, спроектированные трафиком, управляемые их одноранговой узлами, указывая, что контрольным gre.0 каналом tester3 управляется.

Пример выходных данных

Используйте команду show link-management te-link, чтобы отобразить ресурсы, используемые для многопротокольная коммутация по меткам (MPLS) путей переадправления трафика.

Смысл

Пример выходных данных для команды, выданной на трех маршрутизаторах в сети, показывает ресурсы, выделенные для линий связи, спроектированной show link-management te-link Рис. 13te-tester2 трафиком, и te-tester3 . Ресурсы - это интерфейсы SONET и On, а его интерфейсы SONET используются для LSP, как указано so-0/0/0 so-0/0/1. в R1 R2, tgmpls-r1-to-r3YesUsed поле.Однако интерфейс SONET не используется () и не используется so-0/0/1 R3 для Dn LSP Used No (). Для обнаружения причины сияия интерфейса SONET, требуется R3 дальнейшее исследование.

Пример выходных данных

Для отображения содержимого указанного файла журнала используйте команду show log filename. В данном случае файл журнала rsvp.log настроен на уровне иерархии [edit protocols rsvp traceoptions]. Когда файл журнала настроен, необходимо подать команду monitor start filename, чтобы начать регистрацию сообщений в файл.

Прим.:

Параметр, find Error вписаный после канала) ищет экземпляр термина Error в ( | выходных данных.

Пример выходных данных

Смысл

Пример выходных данных команды маршрутизатор исходящего трафика является фрагментом, взятым R3 show log rsvp.log из файла журнала. Фрагмент показывает запрос ресурсов протокола управления связью (LMP) для LSP Запрос имеет проблемы с типом кодиирования (SDH/SONET), что указывает на возможную ошибку при подключении интерфейса gmpls-r1-to-r3. SONET R2R3 и. Дальнейшее исследование конфигурации LMP on R2 и R3 является обязательной.

Пример выходных данных

Для отображения определенной иерархии конфигурации используйте команду show configuration statement-path. в данном примере — управление связью.

Смысл

Пример выходных данных от транзитного маршрутизатора и входящего маршрутизатора для команды показывает, что тип интерфейса на двух R2 R3 show configuration protocols link-management маршрутизаторах отличается. На транзитный маршрутизатор выделен ресурс te-tester3 SONET-интерфейс, а на маршрутизатор исходящего трафика – R2te-tester3 интерфейс R3 ATM. Тип интерфейса на каждом конце передачи данных или каналов управления должен быть одного типа. В этом случае на обоих концах должны быть SONET или ATM.

Решение

Решение

Решение проблемы различных интерфейсов или типов инкапсуляции на обоих концах GMPLS LSP состоит в том, чтобы убедиться, что тип интерфейса на обоих концах один и тот же. В этом случае интерфейс ATM был удален из конфигурации управления связью on, и вместо этого был настроен интерфейс R3 SONET.

Следующие команды иллюстрируют правильную конфигурацию и команды для проверки того, что GMPLS LSP находится в up и использует канал данных:

Пример выходных данных

Смысл

Пример выходных данных для и команд в маршрутизаторе в выходных данных show protocols link-managementshow mpls lsp show link-management te-link R3 показывает, что проблема решена. LMP настроен правильно, и LSP находится в исправной исправной gmpls-r1-to-r3 конфигурации и использует канал so-0/0/1 данных.

Заключение

В заключение следует отметить, что оба конца канала данных GMPLS должны иметь один и тот же тип инкапсуляции или интерфейса. Данный случай иллюстрирует правильную конфигурацию канала данных. Принципы для канала управления одинаковы.

Конфигурации маршрутизатора

Выходные данные показывают конфигурации в выходного маршрутизатора в сети. Параметр, no-more вписаный после канала, предотвращает paginated output from paginated, если выходные данные больше, чем длина ( | экрана терминала.

Пример выходных данных

Следующий пример выходных данных для вного маршрутизатора М1:

Пример выходных данных

Следующий пример выходных данных для транзитного маршрутизатора М2:

Пример выходных данных

Следующий пример выходных данных для маршрутизатор исходящего трафика R3:

Определение состояния LSP

Отображение подробной информации об объектах протокола резервирования ресурсов (RSVP) и истории коммутации меток (LSP), чтобы определить проблему lSP.

Рис. 14 иллюстрирует топологию сети, используемую в этом разделе.

Рис. 14: MPLS сетевой топологииMPLS сетевой топологии

Чтобы определить состояние LSP, выполните следующие действия:

Проверка состояния LSP

Цель

Отобразить состояние пути с коммутаализаемой меткой (LSP).

Действий

Чтобы определить состояние LSP на входном маршрутизаторе, введите следующую команду Junos OS интерфейс командной строки (интерфейс командной строки) operational mode:

Пример выходных данных
command-name

Смысл

Пример выходных данных с входящего маршрутизатора () и показывает информацию о входящем, выходном R1 и транзитном LSP. Входящая информация является для сеансов, которые исходят от этого маршрутизатора, информация об выходе – для сеансов, которые завершаются на этом маршрутизаторе, а транзитная информация – для сеансов, транзитных через этот маршрутизатор.

Существует один вский маршрут от R110.0.0.1 () к R610.0.0.6 (). Этот маршрут в настоящее время работает и является активным маршрутом, установленным в таблице маршрутов Rt (). LSP является основным путем () в противоположность вторичному пути и указывается R1-to-R6P звездочкой * (). Маршрут к R6 не содержит именуемой траектории ActivePath ().

Существует один egress LSP от R6 к R1 . Up, State без маршрутов, установленных в таблице маршрутов. Стиль резервирования RSVP Style () состоит из двух частей. Первый - это количество активных резервирования 1 (). Второй — это тип резервирования(фиксированный FF фильтр). Тип резервирования может быть FFSE (общим явным) или WF (поддиаренный фильтр). Существует три входящих метки () и для этого LSP метки не LabelinLabelout поймем.

Транзитных LPS не существует.

Дополнительные сведения о проверке состояния LSP см. в контрольном списке для работы с моделью MPLS многоуровневой связи.

Отображение состояния дисплея LSP

Цель

Отображение подробной информации о LSP, включая всю информацию о последних состояниях и причины сбойов LSP.

Действий

Чтобы отобразить подробную информацию о LPS на входном маршрутизаторе, введите команду Junos OS интерфейс командной строки operational mode:

Пример выходных данных
command-name

Смысл

Пример выходных данных на входящем маршрутизаторе () и отображает подробные сведения о входящем, выходном и транзитном LSP, включая всю информацию о последних состояниях и причинах сбой R1 LSP. Входящая информация является для сеансов, которые исходят от этого маршрутизатора, информация об выходе – для сеансов, которые завершаются на этом маршрутизаторе, а транзитная информация – для сеансов, транзитных через этот маршрутизатор.

Существует один вский маршрут от R110.0.0.1 () к R610.0.0.6 (). Этот маршрут в настоящее время работает (), с State одним маршрутом, который активно использует LSP, R1-to-R6 . Активный путь LSP является основным. Даже если LSP не содержит ключевое слово или ключевое слово, маршрутизатор продолжает рассматривать LSP как основной LSP, что означает, что в случае сбойного LSP маршрутизатор по умолчанию попытается сигнализировать неактивные LSP через primarysecondary 30-секундные интервалы.

Балансировка нагрузки по умолчанию означает, что при выборе физического пути для LSP маршрутизатор выбирает случайный путь среди путей с равной стоимостью, которые имеют равное число Random переходов. Другие параметры, которые можно настроить: и. помещает LSP над наименее загруженным соединением равноценных путей с равным количеством переходов. Помещает LSP над наиболее загруженным соединением равноценных путей с одинаковым количеством Least-fillMost-fillLeast-fillMost-fill переходов. Коэффициент использования основан на проценте доступной пропускной способности.

Поле Encoding type отображает параметры MPLS generalized (GMPLS) Packet) (или IPv4). Is Switching typePacket и Generalized полезная нагрузка Identifier GPID () is IPv4.

Основной путь является активным, что указывается звездочкой (*). Состояние LSP: Up .

Явный объект маршрута (Explicit Route Object) включает в себя стоимость первого (CSPF) ограниченного кратчайших путей (CSPF) для физического пути, который следует ERO20 за LSP. Наличие метрики CSPF указывает, что это CSPF LSP. Отсутствие метрики CSPF указывает на отсутствие CSPF LSP.

В поле 10.1.13.2 S указывается фактическое поле МВТ. Сигнальные сообщения RSVP переходили строго (в качестве следующего перехода) и завершались 10.1.13.210.1.36.2 строго. Все адреса МВП являются жесткими переходами, если LSP является CSPF LSP. Свободные переходы могут отображаться только в no-CSPF LSP.

Полученный объект маршрута RRO записи (Record Route Object) имеет следующие флаги защиты:

  • 0x01— Локализованная защита доступна. 9-ой поток связи этого узла защищен механизмом локального ремонта. Этот флаг можно установить, только если флаг локальной защиты был установлен SESSION_ATTRIBUTE объектом соответствующего сообщения о пути.

  • 0x02— Локализованная защита. Для поддержания этого туннеля используется механизм локального ремонта (обычно из-за срывов канала, маршрутиченного ранее).

  • 0x04— защита полосы пропускания. 9-ой маршрутизатор имеет резервный путь, обеспечивающий гарантированную полосу пропускания той же гарантированной полосы пропускания, что и защищенный LSP для защищенного раздела.

  • 0x08— Защита узлов. 9-ой маршрутизатор имеет резервный путь, обеспечивающий защиту от сбоя соединения и узла в соответствующем разделе пути. Если ходящий маршрутизатор может настроить только резервный путь для защиты соединения, устанавливается бит "Local protection available", но бит "Node protection" очищается.

  • 0x10В ожидании предварительного вынесения решения. Узел, выполнюющий этот флажок, устанавливает этот флаг, если для LSP, спроектированного трафиком, еще не завершено предварительное время. Это указывает на то, что граничный маршрутизатор (LER) этого LSP на влияемую метку.

Дополнительные сведения о флагах защиты см. в Junos команды Routing Protocols and Policies.

Это поле 10.1.13.2.10.1.36.2 является фактическим полученным маршрутом записи RRO (). Обратите внимание, что адреса в этом RRO поле совпадают с адресами ERO в этом поле. Это нормальная ситуация для LPS CSPF. Если адреса RRO и МВТ не совпадают с CSPF LSP, LSP должен перена маршрутизовать или отсортовать.

В строках с номерами от 91 до 42 содержатся 49 последних записей в журнале истории. Каждая строка штампуется во время. Последние записи имеют наибольший номер журнала и находятся в верхней части журнала, что указывает на то, что строка 91 является самой последней записью журнала. Когда вы прочтаете журнал, начните с самой старой записи 42 () до последней 91 ().

Журнал истории был запущен 10 июля и отображает следующую последовательность действий: LSP был выбран в качестве активного, был признан неактивным, MPLS несколько раз не было выделено меток, несколько раз было удалено, из-за resvTear, был удален как активный и удален. В конце концов, маршрутизатор вычислил CSPF ЦЕР, прогноил вызов, LSP вошел в список RRO (линия 90) и был указан в качестве активного.

Дополнительные сведения о сообщениях об ошибках см. в справочнике по Junos MPLS сетевых операций.

Общее количество отображаемого количества впадаемой LPS 1 составляет «вверх» 1 (up) и 0 «down» (вниз). Число в поле плюс число в поле UpDown должно равняться сумме.

Существует один сеанс на выпадение LSP от R6 к R1 . Up, State без маршрутов, установленных в таблице маршрутов. Стиль резервирования RSVP Style () состоит из двух частей. Первый - это количество активных резервирования 1 (). Второй — это тип резервирования(фиксированный FF фильтр). Тип резервирования может быть FFSE (общим явным) или WF (поддиаренный фильтр). Существует три входящих метки () и для этого LSP метки не LabelinLabelout поймем.

Транзитных LPS не существует.

Дополнительные сведения о проверке состояния LSP см. в контрольном списке для работы с моделью MPLS многоуровневой связи.

Проверка того, что сообщения пути RSVP отправлены и получены

Цель

Наличие или отсутствие различных сообщений RSVP может помочь определить наличие проблем с многопротокольная коммутация по меткам (MPLS) в сети. Например, если в выходных данных возникают сообщения о пути без сообщений Resv, это может указывать на то, что пути с коммутавлвлюемой меткой (LSPs) не создаются.

Действий

Чтобы проверить, отправлены и получены ли сообщения пути RSVP, введите следующую команду Junos OS интерфейс командной строки (интерфейс командной строки) в режиме эксплуатации:

Пример выходных данных

command-name

Смысл

Пример выходных данных показывает отправленные и полученные сообщения RSVP. Общее количество отправленных сообщений пути RSVP — 11 4532 и получено 80 185. В течение последних 5 секунд сообщения не были отправлены и не получены.

Всего было отправлено 5 PathErr сообщений и получено 10. Когда возникают ошибки пути (обычно из-за проблем с параметрами в сообщении пути), маршрутизатор отправляет одноадрешное сообщение PathErr отправителю, выдав сообщение о пути. В этом случае следует отправить как минимум 10 сообщений о пути с ошибкой, как указано в R1 полученных сообщениях PathErr 10. R1 9stream-маршрутизатор отправил пять сообщений о пути с ошибкой, как указано в пяти отправленных R1 сообщениях PathErr. R1 Сообщения PathErr передаются в противоположном направлении к сообщениям пути.

Всего было отправлено 12 сообщений и PathTear получено 6 сообщений, ни одного сообщения за последние 5 секунд. В отличие от сообщений PathErr, сообщения PathTear посылались в том же направлении, в каком и сообщения о пути. Поскольку сообщения пути отправляются и получаются, сообщения PathTear также отправляются и получаются. Однако если отправляются только сообщения пути, в выходных данных появятся только отправленные сообщения PathTear.

Всего было отправлено 80 515 сообщений с фиксированным фильтром () и Resv получено 111 476 сообщений, ни одного сообщения за последние FF 5 секунд. Тип резервирования означает, что в каждом сеансе каждый приемник устанавливает свое собственное резервирование с каждым отправителям от и все выбранные FF отправители перечислены. Сообщения для поддиарвного фильтра () или общих явных () стилей WFSE резервирования не отправляются и не получаются. Дополнительные сведения о стилях резервирования RSVP см. в руководстве по Junos MPLS приложений.

Другие типы сообщений RSVP не отправляются и не получаются. Сведения о типах сообщений ResvErr, ResvTear и Resvconf см. в Junos MPLS приложений.

Сообщения Ack и summary refresh (SRefresh) не отображаются в выходных данных. Сообщения Ack и summary refresh определены в RFC 2961 и являются частью расширений RSVP. Сообщения Ack используются для уменьшения объема трафика управления RSVP в сети.

Всего было отправлено 915 851 приветствуя сообщения и получено 915 881 сообщений, не передано и не получено за последние 5 секунд. Интервал приветствуя RSVP составляет 9 секунд. Если за последние 5 секунд было отправлено или получено более одного сообщения hello, это означает, что RSVP поддерживается более чем одним интерфейсом.

EndtoEnd Сообщения RSVP – это устаревшие сообщения RSVP, которые не используются для управление трафиком. Эти счетчики приращения только когда RSVP передает устаревшие сообщения RSVP, выданные клиентом виртуальной частной сети (VPN) для транзита через магистрали в другой узел (s) в VPN. Они называются "конечными" сообщениями, поскольку они предназначены для противоположной стороны сети и имеют смысл только на двух концах сети поставщика.

В Errors разделе выходных данных показана статистика по пакетам RSVP с ошибками. Всего на модуль маршрутизации PathErr to client было отправлено 15 модуль маршрутизации. Общее число объединяет отправленные и PathErr полученные пакеты.