Маршрутизаторы : Маршрутизаторы агрегации Cisco ASR серии 9000

ASR руководство устранения неполадок сбоев пути данных матрицы избыточного направления серии 9000

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Содержание

Связанные обсуждения сообщества поддержки Cisco

Введение

Этот документ описывает сообщения об ошибках пути данных матрицы избыточного направления, замеченные во время Маршрутизатора агрегации (ASR) Cisco операция серии 9000. Сообщение появляется в этом формате:

RP/0/RSP0/CPU0:Sep 3 13:49:36.595 UTC: pfm_node_rp[358]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 1) (0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5)
(0/7/CPU0, 6) (0/7/CPU0, 7)

Этот документ предназначен для любого, кто хочет понять сообщение об ошибках и меры, которые должны быть приняты, если замечена проблема.

Внесенный Махешем Ширшьядом, полномочия Дэвида и Жан-Кристоф поехали, специалисты службы технической поддержки Cisco.

Предварительные условия

Требования

Cisco рекомендует иметь высокоуровневое знание этих тем:

  • ASR 9000 линейных карт
  • Платы матрицы
  • Процессоры маршрута
  • Архитектура шасси

Однако этот документ не требует, чтобы читатели были знакомы с аппаратными подробными данными. Необходимые общие сведения предоставлены, прежде чем сообщение об ошибках объяснено. Этот документ описывает ошибку и на Трайденте - и на Сетевых картах по типу тайфуна. Посмотрите ASR Типы Линейной карты серии 9000 для пояснения тех сроков.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

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

Как Использовать этот документ

Рассмотрите эти предложения о том, как использовать этот документ для подбора существенных подробных данных и как справочного руководства в процессе устранения неполадок:

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

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

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

Общие сведения

Пакет может пересечь или два перехода или три перехода через коммутационную матрицу, основанную на типе линейной карты. В то время как Сетевые карты в форме трезубца коммутируют весь трафик с матрицей на карте процессора маршрутов только, линейные карты генерации тайфуна добавляют дополнительный элемент коммутационной матрицы. Эти элементы show fabric схем для обоих из этих типов линейной карты, а также оптоволоконное подключение к карте процессора маршрутов:

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

Диагностическое приложение, которое работает на ЦП карты процессора маршрутизации, вводит диагностические пакеты, предназначенные к каждому Сетевому процессору (NP) периодически. Диагностический пакет циклично выполнен назад в NP и повторно введен к ЦП карты процессора маршрутизации, который получил пакет. Этот периодический медицинский осмотр каждого NP с уникальным пакетом на непер диагностическим приложением на карте процессора маршрутов предоставляет предупреждение для любых функциональных ошибок на пути данных во время работы маршрутизатора. Важно обратить внимание, что диагностическое приложение и на активном процессоре маршрутизации и на процессоре маршрутизации в режиме ожидания вводит один пакет на непер периодически и поддерживает на количество успешности или неуспешности непера. Когда порог отброшенных диагностических пакетов достигнут, приложение повышает отказ.

Концептуальное представление диагностического пути

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

Путь пакета между картой активного процессора маршрутизации и линейной картой

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

Эта схема изображает путь диагностического пакета, полученный от активного процессора маршрутизации.

Примечание: Первая ссылка, которая подключает Fabric Interface ASIC (FIA) на линейной карте к Перемычке (XBAR) на карте процессора маршрутов, выбрана все время для пакетов, предназначенных к NP. Ответные пакеты от NP подвергнуты алгоритму распределения нагрузки ссылки (если линейная карта Основана на тайфуне). Это означает, что ответный пакет от NP к активному процессору маршрутизации может выбрать любую из оптоволоконных ссылок, которые подключают линейные карты с картой процессора маршрутов на основе оптоволоконной загрузки ссылки.

Путь пакета между картой процессора маршрутизации в режиме ожидания и линейной картой

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

Предыдущая схема изображает путь диагностического пакета, полученный от процессора маршрутизации в режиме ожидания. Заметьте, что, в отличие от случая активного процессора маршрутизации, осуществлены все ссылки, которые подключают линейную карту с XBAR на процессоре маршрута. Ответные пакеты от NP берут ту же оптоволоконную ссылку, которая использовалась пакетом в процессоре маршрута к направлению линейной карты. Этот тест гарантирует, что все ссылки, которые подключают процессор маршрутизации в режиме ожидания с линейной картой, проверяются постоянно.

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

Эта схема изображает полученные диагностические пакеты процессора маршрута, предназначенные к NP, который циклично выполнен назад к процессору маршрута. Важно обратить внимание на ссылки пути данных и ASIC-схемы, которые характерны для всех NP, а также ссылок и компонентов, которые являются определенными для подмножества NP. Например, в то время как FIA0 характерен для всех NP, ASIC Моста 0 (B0) характерен для NP0 и NP1. На конце процессора маршрута все ссылки, ASIC-схемы пути данных и Программируемая на месте логическая матрица (FPGA) характерны для всех линейных карт, и следовательно для всех NP в шасси.

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

Эта схема изображает полученные диагностические пакеты карты процессора маршрутов, предназначенные к NP, который циклично выполнен назад к процессору маршрута. Важно обратить внимание на ссылки пути данных и ASIC-схемы, которые характерны для всех NP, а также ссылок и компонентов, которые являются определенными для подмножества NP. Например, FIA0 характерен для NP0 и NP1. На конце карты процессора маршрутов все ссылки, ASIC-схемы пути данных и FGPA характерны для всех линейных карт, и следовательно для всех NP в шасси.

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

Сигнал тревоги диагностики матрицы избыточного направления и создание отчетов сбоя

Сбой для получения ответов от NP в ASR маршрутизатор на основе 9000 приводит к сигналу тревоги. Решение выдать аварийный сигнал онлайновым диагностическим приложением, которое выполняется на процессоре маршрута, происходит, когда существует три последовательных отказа. Диагностическое приложение поддерживает три пакетных окна сбоя для каждого NP. Активный процессор маршрутизации и процессор маршрутизации в режиме ожидания диагностируют независимо и параллельно. Активный процессор маршрутизации, процессор маршрутизации в режиме ожидания или обе карты процессора маршрутов могли бы сообщить об ошибке. Местоположение отказа и потери пакета определяет, какой процессор маршрута сообщает о сигнале тревоги.

Частота по умолчанию диагностического пакета к каждому NP является одним пакетом в 60 секунд или один в минуту.

Вот формат аварийного сообщения:

RP/0/RSP0/CPU0:Sep 3 13:49:36.595 UTC: pfm_node_rp[358]: 
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 1) (0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5)
(0/7/CPU0, 6) (0/7/CPU0, 7)

Сообщение должно быть считано как сбой для достижения NP 1, 2, 3, 4, 5, 6, и 7 на линейной карте 0/7/cpu0 от процессора маршрута 0/rsp0/cpu0.

Из списка онлайновых диагностических тестов вы видите атрибуты кольцевой проверки матрицы избыточного направления с этой командой:

RP/0/RSP0/CPU0:iox(admin)#show diagnostic content location 0/RSP0/CPU0


RP 0/RSP0/CPU0:

Diagnostics test suite attributes:
M/C/* - Minimal bootup level test / Complete bootup level test / NA
B/O/* - Basic ondemand test / not Ondemand test / NA
P/V/* - Per port test / Per device test / NA
D/N/* - Disruptive test / Non-disruptive test / NA
S/* - Only applicable to standby unit / NA
X/* - Not a health monitoring test / NA
F/* - Fixed monitoring interval test / NA
E/* - Always enabled monitoring test / NA
A/I - Monitoring is active / Monitoring is inactive
Test Interval Thre-
ID Test Name Attributes (day hh:mm:ss.ms shold)
==== ================================== ============ ================= =====
1) PuntFPGAScratchRegister ---------- *B*N****A 000 00:01:00.000 1
2) FIAScratchRegister --------------- *B*N****A 000 00:01:00.000 1
3) ClkCtrlScratchRegister ----------- *B*N****A 000 00:01:00.000 1
4) IntCtrlScratchRegister ----------- *B*N****A 000 00:01:00.000 1
5) CPUCtrlScratchRegister ----------- *B*N****A 000 00:01:00.000 1
6) FabSwitchIdRegister -------------- *B*N****A 000 00:01:00.000 1
7) EccSbeTest ----------------------- *B*N****I 000 00:01:00.000 3
8) SrspStandbyEobcHeartbeat --------- *B*NS***A 000 00:00:05.000 3
9) SrspActiveEobcHeartbeat ---------- *B*NS***A 000 00:00:05.000 3
10) FabricLoopback ------------------- MB*N****A 000 00:01:00.000 3
11) PuntFabricDataPath --------------- *B*N****A 000 00:01:00.000 3
12) FPDimageVerify ------------------- *B*N****I 001 00:00:00.000 1

RP/0/RSP0/CPU0:ios(admin)#

Выходные данные показывают, что тестовая частота PuntFabricDataPath является одним пакетом каждую минуту, и пороговое значение отказа равняется трем, которые подразумевают, что потеря трех последовательных пакетов не допускается и приводит к сигналу тревоги. Тест приписывает показанный, значения по умолчанию. Для изменения настроек по умолчанию введите команды diagnostic monitor interval и diagnostic monitor threshold в режим конфигурации администрирования.

Путь диагностического пакета сетевых карт в форме трезубца

Диагностическая ошибка NP0

Оптоволоконный диагностический путь

Эта схема изображает путь пакета между ЦП процессора маршрута и линейной картой NP0. Ссылка, которая подключает B0 и NP0, является единственной ссылкой, определенной для NP0. Все другие ссылки падают в общем пути.

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

Анализ диагностической ошибки NP0

Сценарий одиночного отказа

Если Обработчик ошибок одной платформы (PFM), сигнал сбоя пути данных матрицы избыточного направления с только NP0 в сообщении об ошибках обнаружен, отказ, находится только на оптоволоконном пути, который подключает процессор маршрута и линейную карту NP0. Это - одиночный отказ. Если отказ обнаружен к нескольким NP, обратитесь ко Множественному разделу Сценария Отказа.

RP/0/RSP0/CPU0:Sep 3 13:49:36.595 UTC: pfm_node_rp[358]: 
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 0)

Примечание: Этот раздел документа применяется к любому слоту линейной платы в шасси, независимо от типа шасси. Следовательно, это может быть применено ко всем слотам линейной платы.

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

  • Ссылка, которая подключает NP0 и B0
  • В очередях B0, направленных к NP0
  • В NP0

Множественный сценарий отказа

Множественные отказы NP

Когда другие отказы наблюдаются относительно NP0 или отказа, о PUNT_FABRIC_DATA_PATH_FAILED также сообщают другие NP на той же линейной карте, тогда повреждение изоляции сделано путем корреляции всех отказов. Например, если и отказ PUNT_FABRIC_DATA_PATH_FAILED и отказ LC_NP_LOOPBACK_FAILED происходят на NP0, то NP прекратил обрабатывать пакеты. См. NP Путь Диагностики обратной связи разделяет для понимания петлевого отказа. Это могло быть ранней индикацией относительно критического опасного отказа в NP0. Однако, если только один из двух отказов происходит, то отказ локализован или к пути данных матрицы избыточного направления или на ЦП линейной карты к пути NP.

Если несколько NP на линейной карте имеют отказ пути данных матрицы избыточного направления, то необходимо идти по древовидному пути оптоволоконных ссылок для изоляции неисправного компонента. Например, если и NP0 и NP1 имеют отказ, то отказ должен быть в B0 или ссылке, которая подключает B0 и FIA0. Менее вероятно, что и NP0 и NP1 встречаются с важной внутренней ошибкой в то же время. Несмотря на то, что это менее вероятно, для NP0 и NP1 возможно встретиться с отказом критической ошибки из-за неправильной обработки определенного вида пакета или недопустимого пакета.

Оба отчёта о картах процессора маршрутов отказ

Если и активный процессор маршрутизации и карты процессора маршрутизации в режиме ожидания сообщают об отказе одному или более NP на линейной карте, то проверьте все общие ссылки и компоненты на пути данных между NP, на которые влияют, и обоими карты процессора маршрутов.

Диагностическая ошибка NP1

Эта схема изображает путь пакета между ЦП карты процессора маршрутизации и линейной картой NP1. Ссылка, которая подключает ASIC Моста 0 (B0) и NP1, является единственной ссылкой, определенной для NP1. Все другие ссылки падают в общем пути.

Сделайте примечание пути пакета от карты процессора маршрутов к NP1. Несмотря на то, что существует четыре ссылки для использования для пакетов, предназначенных к NP0 от процессора маршрута, первая ссылка между процессором маршрута и слотом линейной платы используется для пакета от процессора маршрута к линейной карте. Возвращенный пакет от NP1 можно передать обратно в активный процессор маршрутизации по любому из двух оптоволоконных путей ссылок между слотом линейной платы и активный процессор маршрутизации. Выбор которого из двух ссылок на использование зависит от загрузки ссылки в то время. Ответный пакет от NP1 к процессору маршрутизации в режиме ожидания использует обе ссылки, но одну ссылку за один раз. Выбор ссылки основывается на поле заголовка, которое заполняет диагностическое приложение.

Оптоволоконный диагностический путь

Анализ диагностической ошибки NP1

См. Аналитический раздел Диагностической ошибки NP0, но применяют то же обоснование для NP1 (вместо NP0).

Диагностическая ошибка NP2

Эта схема изображает путь пакета между ЦП карты процессора маршрутизации и линейной картой NP2. Ссылка, которая подключает B1 и NP2, является единственной ссылкой, определенной для NP2. Все другие ссылки падают в общем пути.

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

Оптоволоконный диагностический путь

Анализ диагностической ошибки NP2

См. Аналитический раздел Диагностической ошибки NP0, но применяют то же обоснование для NP2 (вместо NP0).

Диагностическая ошибка NP3

Эта схема изображает путь пакета между ЦП карты процессора маршрутизации и линейной картой NP3. Ссылка, которая подключает Мост (B1) ASIC 1 и NP3, является единственной ссылкой, определенной для NP3. Все другие ссылки падают в общем пути.

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

Оптоволоконный диагностический путь

Анализ диагностической ошибки NP3

См. Аналитический раздел Диагностической ошибки NP0, но применяют то же обоснование для NP3 (вместо NP0).

Путь диагностического пакета сетевой карты по типу тайфуна

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

Тайфун диагностическая ошибка NP1

Следующая схема изображает путь пакета между ЦП карты процессора маршрутизации и линейной картой NP1. Ссылка, которая подключает FIA0 и NP1, является единственной ссылкой, определенной для пути NP1. Все другие ссылки между слотом линейной платы и слотом карты процессора маршрутов падают в общем пути. Ссылки, которые подключают оптоволоконный ASIC XBAR на линейной карте к FIA на линейной карте, являются определенными для подмножества NP. Например, обе ссылки между FIA0 и локальным оптоволоконным ASIC XBAR на линейной карте используются для трафика к NP1.

Сделайте примечание пути пакета от карты процессора маршрутов к NP1. Несмотря на то, что существует восемь ссылок для использования для пакетов, предназначенных к NP1 от карты процессора маршрутов, одиночный сервер между картой процессора маршрутов и слотом линейной платы используется. Возвращенный пакет от NP1 можно передать обратно в карту процессора маршрутов более чем восемь оптоволоконных путей ссылок между слотом линейной платы и процессором маршрута. Когда диагностический пакет предназначен назад к ЦП карты процессора маршрутизации, каждая из этих восьми ссылок осуществлена по одному.

Оптоволоконный диагностический путь

Тайфун диагностическая ошибка NP3

Эта схема изображает путь пакета между ЦП карты процессора маршрутизации и линейной картой NP3. Ссылка, которая подключает FIA1 и NP3, является единственной ссылкой, определенной для пути NP3. Все другие ссылки между слотом линейной платы и слотом карты процессора маршрутов падают в общем пути. Ссылки, которые подключают оптоволоконный ASIC XBAR на линейной карте к FIA на линейной карте, являются определенными для подмножества NP. Например, обе ссылки между FIA1 и локальным оптоволоконным ASIC XBAR на линейной карте используются для трафика к NP3.

Сделайте примечание пути пакета от карты процессора маршрутов к NP3. Несмотря на то, что существует восемь ссылок для использования для пакетов, предназначенных к NP3 от карты процессора маршрутов, одиночный сервер между картой процессора маршрутов и слотом линейной платы используется. Возвращенный пакет от NP1 можно передать обратно в карту процессора маршрутов более чем восемь оптоволоконных путей ссылок между слотом линейной платы и процессором маршрута. Когда диагностический пакет предназначен назад к ЦП карты процессора маршрутизации, каждая из этих восьми ссылок осуществлена по одному.

Оптоволоконный диагностический путь

Проанализируйте отказы

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

Переходный отказ

Если сообщение PFM набора придерживается ясным сообщением PFM, то отказ произошел, и маршрутизатор исправил сам отказ. Переходные отказы могут произойти из-за условий среды и восстанавливаемых отказов в аппаратных компонентах. Иногда может быть трудно привязать переходные отказы к какому-то конкретному событию.

Пример переходного оптоволоконного отказа перечислен здесь для ясности:

RP/0/RSP0/CPU0:Feb 5 05:05:44.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0) 

RP/0/RSP0/CPU0:Feb 5 05:05:46.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Clear|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0) 

Переходные корректирующие действия отказа

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

Серьезный отказ

Если сообщение PFM набора не придерживается ясным сообщением PFM, то отказ произошел, и маршрутизатор не исправил сам отказ кодом обработки отказа, или природа отказа оборудования не является восстанавливаемой. Серьезные отказы могут произойти из-за условий среды и неисправимых отказов в аппаратных компонентах. Предложенный подход для серьезных отказов должен использовать рекомендации, упомянутые в Проанализировать разделе Серьезных отказов.

Пример твердого оптоволоконного отказа перечислен здесь для ясности. Для сообщения данного примера нет соответствующего ясного сообщения PFM.

RP/0/RSP0/CPU0:Feb 5 05:05:44.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0)

Корректирующие действия серьезного отказа

Согласно сценарию серьезного отказа, соберите все команды, упомянутые в Данных, Чтобы Собрать Перед разделом Создания Запроса на обслуживание и открыть запрос на обслуживание. В экстренных случаях после сбора всех выходных данных команды устранения проблем инициируют карту процессора маршрутов или повторную загрузку линейной карты на основе повреждения изоляции. После повторной загрузки, если ошибка не восстановлена, инициируют Разрешение на возврат материалов (RMA).

Проанализируйте переходные отказы

Выполните эти шаги для анализа переходных отказов.

  1. Введите show logging | inc команда "PUNT_FABRIC_DATA_PATH", чтобы обнаружить, произошла ли ошибка однажды или многократно.

  2. Введите показ pfm местоположение вся команда для определения текущего статуса (НАБОР или ЯСНЫЙ). Ошибка является выдающейся или очищенной? Если изменения состояния ошибки между НАБОРОМ и ЯСНЫЙ, то один или несколько отказов в оптоволоконном пути данных неоднократно происходят и исправлены или программным обеспечением или аппаратными средствами.

  3. Условие или Перехваты простого протокола управления сетью (SNMP) или выполняет сценарий, который собирает, показывают pfm местоположению все выходные данные команды, и ищет строку с ошибкой периодически для мониторинга возникновения в будущем отказа (когда последний статус ошибки ЯСЕН, и никакие новые отказы не происходят).

Команды для Использования

Введите эти команды для анализа переходных отказов:

  • show logging | inc "PUNT_FABRIC_DATA_PATH"
  • покажите pfm местоположению все 

Проанализируйте серьезные отказы

При просмотре оптоволоконных ссылок пути данных на линейной карте как дерево (где подробные данные описаны в фоновом режиме Раздел сведений), то необходимо вывести - основанный на точке отказа - или один или несколько NP недоступны. Когда множественные отказы происходят на множественных NP, затем используйте команды, перечисленные в этом разделе для анализа отказов.

Команды для Использования

Введите эти команды для анализа серьезных отказов:

  • show logging | inc "PUNT_FABRIC_DATA_PATH"

    Выходные данные могли бы содержать один или несколько NP (Пример: NP2, NP3).

  • show controller fabric fia местоположение link-status <lc>

    И начиная с NP2 и начиная с NP3 (во время Тайфуна раздел Диагностической ошибки NP3) получают и передают через одиночный FIA, разумно вывести, что отказ находится в cвязанном FIA на пути.

  • экземпляр состояния канала матричного коммутатора show controller fabric <0 и 1> местоположение <LC или RSP>

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

    экземпляр состояния канала матричного коммутатора show controller fabric 0 местоположений <lc>

    экземпляр состояния канала матричного коммутатора show controller fabric 0 местоположений 0/rsp0/cpu0

    экземпляр состояния канала матричного коммутатора show controller fabric 1 местоположение 0/rsp0/cpu0

    экземпляр состояния канала матричного коммутатора show controller fabric 0 местоположений 0/rsp1/cpu0

    экземпляр состояния канала матричного коммутатора show controller fabric 1 местоположение 0/rsp1/cpu0

  • show controller fabric fia местоположение link-status 0/rsp*/cpu0

    show controller fabric fia местоположение link-status 0/rsp0/cpu0

    show controller fabric fia местоположение link-status 0/rsp1/cpu0

  • show controller fabric fia соединяет местоположение синхронизирующего статуса 0/rsp*/cpu0

    show controller fabric fia соединяет местоположение синхронизирующего статуса 0/rsp0/cpu0

    show controller fabric fia соединяет местоположение синхронизирующего статуса 0/rsp1/cpu0

    покажите технический терминал матрицы


Примечание: Если все NP на всех линейных картах сообщают об отказе, то отказ наиболее вероятен на карте процессора маршрутов (процессор карты активного процессора маршрутизации или карта процессора маршрутизации в режиме ожидания). См. ссылку, которая подключает ЦП карты процессора маршрутизации с FPGA и FIA карты процессора маршрутов в фоновом режиме Раздел сведений.

Прошлые сбои

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

Если подобные ошибки наблюдаются, следующие разделы определяют некоторые прошлые сбои, с которыми встречаются для служения в качестве руководства.

Переменная ошибка из-за превышения подписки NP

Если ошибка происходит из-за превышения подписки NP, эти сообщения отображаются.

RP/0/RP1/CPU0:Jun 26 13:08:28.669 : pfm_node_rp[349]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[200823]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/10/CPU0, 0)

RP/0/RP1/CPU0:Jun 26 13:09:28.692 : pfm_node_rp[349]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Clear|online_diag_rsp[200823]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/10/CPU0,0)

Переходные отказы может быть более трудно подтвердить. Один метод, чтобы определить, превышается ли NP в настоящее время или был превышен в прошлом, должен проверить для определенного вида отбрасывания в NP и для отбрасывания остатка в FIA. Когда NP превышен и не может не отставать от входящего трафика, отбрасывания Входного переднего непосредственного доступа к памяти (IFDMA) в NP происходят. Отбрасывание остатка FIA происходит, когда выходной NP утверждает управление потоками (просит входная линейная плата передавать меньше трафика). Согласно сценарию управления потоками, входной FIA имеет отбрасывание остатка.

Например:

RP/0/RSP0/CPU0:RP/0/RSP0/CPU0:ASR9006-C#show controllers np counters all
Wed Feb 19 13:10:11.848 EST

Node: 0/1/CPU0:
----------------------------------------------------------------
Show global stats counters for NP0, revision v3

Read 93 non-zero NP counters:
Offset Counter FrameValue Rate (pps)
-----------------------------------------------------------------------
22 PARSE_ENET_RECEIVE_CNT 46913080435 118335
23 PARSE_FABRIC_RECEIVE_CNT 40175773071 5
24 PARSE_LOOPBACK_RECEIVE_CNT 5198971143966 0
<SNIP>

Show special stats counters for NP0, revision v3

Offset Counter CounterValue
----------------------------------------------------------------------------
524032 IFDMA discard stats counters 0 8008746088 0 <<<<<

Например:

RP/0/RSP0/CPU0:ASR9006-C#show controllers fabric fia drops ingress location 0/1/cPU0
Wed Feb 19 13:37:27.159 EST
********** FIA-0 **********
Category: in_drop-0
DDR Rx FIFO-0 0
DDR Rx FIFO-1 0
Tail Drop-0 0 <<<<<<<
Tail Drop-1 0 <<<<<<<
Tail Drop-2 0 <<<<<<<
Tail Drop-3 0 <<<<<<<
Tail Drop DE-0 0
Tail Drop DE-1 0
Tail Drop DE-2 0
Tail Drop DE-3 0
Hard Drop-0 0
Hard Drop-1 0
Hard Drop-2 0
Hard Drop-3 0
Hard Drop DE-0 0
Hard Drop DE-1 0
Hard Drop DE-2 0
Hard Drop DE-3 0
WRED Drop-0 0
WRED Drop-1 0
WRED Drop-2 0
WRED Drop-3 0
WRED Drop DE-0 0
WRED Drop DE-1 0
WRED Drop DE-2 0
WRED Drop DE-3 0
Mc No Rep 0

Серьезный отказ из-за NP Быстрый Сброс

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

LC/0/2/CPU0:Aug 26 12:09:15.784 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702

LC/0/2/CPU0:Aug 26 12:09:18.798 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702

LC/0/2/CPU0:Aug 26 12:09:21.812 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702

LC/0/2/CPU0:Aug 26 12:09:24.815 CEST:
prm_server_ty[303]: NP-DIAG health monitoring failure on NP0

LC/0/2/CPU0:Aug 26 12:09:24.815 CEST: pfm_node_lc[291]:
%PLATFORM-NP-0-NP_DIAG : Set|prm_server_ty[172112]|
Network Processor Unit(0x1008000)| NP diagnostics warning on NP0.

LC/0/2/CPU0:Aug 26 12:09:40.492 CEST: prm_server_ty[303]:
Starting fast reset for NP 0 LC/0/2/CPU0:Aug 26 12:09:40.524 CEST:
prm_server_ty[303]: Fast Reset NP0 - successful auto-recovery of NP

Для Сетевых карт в форме трезубца этот журнал замечен с быстрым сбросом NP:

LC/0/1/CPU0:Mar 29 15:27:43.787 test:
pfm_node_lc[279]: Fast Reset initiated on NP3

Сбои между процессорами маршрута RSP440 и линейными картами тайфуна

Cisco устранила проблему, где переобучены редко оптоволоконные ссылки между Процессором переключателей маршрута (RSP) 440 и Сетевыми картами по типу тайфуна через объединительную плату. Оптоволоконные ссылки переобучены, потому что уровень сигнала не оптимален. Эта проблема присутствует в основной Cisco Выпуски ПО IOS®-XR 4.2.1, 4.2.2, 4.2.3, 4.3.0, 4.3.1, и 4.3.2. Обновление обслуживания программного обеспечения (SMU) для каждых из этих версий зарегистрировано на Cisco Connection Online и отслежено с идентификатором ошибки Cisco CSCuj10837 и идентификатор ошибки Cisco CSCul39674.

Когда эта проблема происходит на маршрутизаторе, любой из этих сценариев может произойти:

  1. Ссылка выключается и подходит. (Переходный процесс)
  2. Ссылка идет постоянно вниз.

Идентификатор ошибки Cisco Матрица CSCuj10837 Переобучается Между RSP и LC (Направление TX)

Для подтверждения соберите выходные данные ltrace от LC и обоих RSP (местоположение ltrace перемычки show controller fabric <>) и проверка, если эти выходные данные замечены в ltrace RSP:

SMU уже доступен

Например:

RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain

    Oct 1 08:22:58.999 crossbar 0/RSP1/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (1,1,0),(2,1,0),1.

RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain

    Oct 1 08:22:58.967 crossbar 0/0/CPU0 t1  init xbar_trigger_link_retrain:
destslot:0 fmlgrp:3 rc:0
     Oct 1 08:22:58.967 crossbar 0/0/CPU0 t1  detail xbar_pfm_alarm_callback:
xbar_trigger_link_retrain(): (2,0,7) initiated
    Oct 1 08:22:58.969 crossbar 0/0/CPU0 t1  detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (2,1,0),(2,2,0),0.

Направление TX условия обращается к направлению с точки зрения интерфейса перекрестной матрицы RSP к оптоволоконному перекрестному интерфейсу на Сетевой карте по типу тайфуна.

Идентификатор ошибки Cisco CSCuj10837 характеризуется обнаружением линейной карты Тайфуна проблемы на ссылке RX от RSP и инициировании ссылки, переобучается. Или сторона (LC или RSP) могут инициировать переобучать событие. В случае идентификатора ошибки Cisco CSCuj10837 LC инициирует переобучение и может быть обнаружен Init xbar_trigger_link_retrain: сообщение в трассировках на LC.

RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain

    Oct 1 08:22:58.967 crossbar 0/0/CPU0 t1  init xbar_trigger_link_retrain: destslot:
0 fmlgrp:3 rc:0

Когда LC инициирует переобучение, RSP сообщает о rcvd link_retrain в выходных данных трассировки.

RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain

    Oct 1 08:22:58.999 crossbar 0/RSP1/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (1,1,0),(2,1,0),1.

Идентификатор ошибки Cisco Матрица CSCul39674 Переобучается Между RSP и LC (Направление RX)

Для подтверждения соберите выходные данные ltrace от линейной карты и обоих RSP (местоположение ltrace перемычки show controller fabric <>) и проверка, если эти выходные данные замечены в ltrace RSP:

Например:

RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain

Jan 8 17:28:39.215 crossbar 0/0/CPU0 t1    detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (0,1,0),(5,1,1),0.

RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain

Jan 8 17:28:39.207 crossbar 0/RSP1/CPU0 t1      init xbar_trigger_link_retrain:
destslot:4 fmlgrp:3 rc:0
Jan 8 17:28:39.207 crossbar 0/RSP1/CPU0 t1    detail xbar_pfm_alarm_callback:
xbar_trigger_link_retrain(): (5,1,11) initiated
Jan 8 17:28:39.256 crossbar 0/RSP1/CPU0 t1    detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (5,1,1),(0,1,0),0. 

Направление RX условия обращается к направлению с точки зрения интерфейса перекрестной матрицы RSP от оптоволоконного перекрестного интерфейса на Сетевой карте по типу тайфуна.

Идентификатор ошибки Cisco CSCul39674 характеризуется обнаружением RSP проблемы на ссылке RX от линейной карты Тайфуна и инициировании ссылки, переобучается. Или сторона (LC или RSP) могут инициировать переобучать событие. В случае идентификатора ошибки Cisco CSCul39674 RSP инициирует переобучение и может быть обнаружен Init xbar_trigger_link_retrain: сообщение в трассировках на RSP.

RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain

 Jan 8 17:28:39.207 crossbar 0/RSP1/CPU0 t1 init xbar_trigger_link_retrain: destslot:4
fmlgrp: 3 rc:0

Когда RSP инициирует переобучение, LC сообщает о rcvd link_retrain событие в выходных данных трассировки.

RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain

 Jan 8 17:28:39.215 crossbar 0/0/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (0,1,0),(5,1,1),0.

Матрица переобучает различия в выпуске 4. 3.2 и более поздние версии

Значительная работа была сделана для уменьшения времени, которое требуется для переквалификации оптоволоконной ссылки в Выпуске 4 IOS-XR. 3.2 и более поздние версии. Матрица переобучается, теперь происходит в подвторые разы и незаметен к трафикам. В Выпуске 4.3.2 только они замечено сообщение системного журнала, когда оптоволоконная ссылка переобучается, произошел.

%PLATFORM-FABMGR-5-FABRIC_TRANSIENT_FAULT :  Fabric backplane crossbar link
underwent link retraining to recover from a transient error: Physical slot 1

Сбой из-за к переполнению FIFO специализированной интегральной схемы с коммутационной матрицей

Cisco устранила проблему, где Специализированная интегральная схема с коммутационной матрицей (FIA) могла бы быть перезагружена из-за неисправимого условия переполнения Первым прибыл, первым обслужен (FIFO). Это обращено с идентификатором ошибки Cisco CSCul66510. Эта проблема только влияет на Сетевые карты в форме трезубца и только встречена в редких случаях с тяжелой перегрузкой пути для внешнего доступа. Если с этой проблемой встречаются, это сообщение системного журнала отображено, прежде чем линейная плата перезагружена для восстановления с условия. 

RP/0/RSP0/CPU0:asr9k-2#show log
LC/0/3/CPU0:Nov 13 03:46:38.860 utc: pfm_node_lc[284]:
%FABRIC-FIA-0-ASIC_FATAL_FAULT Set|fialc[159814]
|Fabric Interface(0x1014000)|Fabric interface asic ASIC1 encountered fatal
fault 0x1b - OC_DF_INT_PROT_ERR_0
LC/0/3/CPU0:Nov 13 03:46:38.863 utc: pfm_node_lc[284]:
%PLATFORM-PFM-0-CARD_RESET_REQ : pfm_dev_sm_perform_recovery_action,
Card reset requested by: Process ID:159814 (fialc), Fault Sev: 0, Target node:
0/3/CPU0, CompId: 0x10, Device Handle: 0x1014000, CondID: 2545, Fault Reason:
Fabric interface asic ASIC1 encountered fatal fault 0x1b - OC_DF_INT_PROT_ERR_0

Сбой из-за к тяжелому наращиванию виртуальной очереди вывода (VOQ) от оптоволоконной перегрузки

Cisco устранила проблему, где расширенная сильная перегрузка могла бы привести к оптоволоконному истощению ресурсов и потере трафика. Потеря трафика может даже произойти на не связанных друг с другом потоках. Эта проблема решена с идентификатором ошибки Cisco CSCug90300 и решена в Выпуске 4 IOS-XR. 3.2 и более поздние версии. Исправление также отправлено в Выпуске 4.2.3 CSMU#3, SMU CSCui33805. С этой редкой проблемой можно было бы встретиться или на Трайденте - или на Сетевых картах по типу тайфуна.

Подходящие команды

Необходимо собрать эти команды:

  • show tech-support fabric
  • show controller fabric fia местоположение flowcontrol моста <LC> <=== Получает эти выходные данные для всех LC
  • show controllers fabric fia местоположение q-глубины <LC>

Вот некоторые примеры выходных данных:

RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia q-depth location 0/6/CPU0
Sun Dec 29 23:10:56.307 UTC 
********** FIA-0 **********
Category: q_stats_a-0
Voq      ddr           pri           pktcnt   
11       0             2             7
********** FIA-0 **********
Category: q_stats_b-0
Voq      ddr           pri           pktcnt
********** FIA-1 **********
Category: q_stats_a-1
Voq      ddr           pri           pktcnt
11       0             0             2491
11       0             2             5701
********** FIA-1 **********
Category: q_stats_b-1
Voq      ddr           pri           pktcnt
RP/0/RSP0/CPU0:asr9k-1#
RP/0/RSP0/CPU0:asr9k-1#show controllers pm location 0/1/CPU0 | in "switch|if"

Sun Dec 29 23:37:05.621 UTC
Ifname(2): TenGigE0_1_0_2, ifh: 0x2000200 : <==Corresponding interface ten 0/1/0/2
iftype 0x1e
switch_fabric_port 0xb <==== VQI 11
parent_ifh 0x0
parent_bundle_ifh 0x80009e0
RP/0/RSP0/CPU0:asr9k-1#

При обычных условиях это очень вряд ли будет видеть, что VOQ с пакетами стоял в очереди. Эта команда является быстрым снимком в реальном времени очередей FIA. Этой команде свойственно не показать любые пакеты, с очередями вообще. 

Влияние трафика из-за Устранимых ошибок Моста/FPGA на Сетевых картах в форме трезубца

Устранимые ошибки являются непостоянными ошибками, которые заставляют механизм состояний быть вне синхронизования. Они замечены как Cyclic Redundancy Checks (CRC), Контрольная сумма фрейма (FCS) или ошибочные пакеты на оптоволоконной стороне NP или на входной стороне FIA.

Вот некоторые примеры того, как может быть замечена эта проблема:

RP/0/RSP0/CPU0:asr9k-1#show controllers fabric  fia drops ingress location 0/3/CPU0
Fri Dec 6 19:50:42.135 UTC
********** FIA-0 **********
Category: in_drop-0
DDR Rx FIFO-0 0
DDR Rx FIFO-1 32609856 <=== Errors

RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia errors ingress location 0/3/CPU0
Fri Dec 6 19:50:48.934 UTC

********** FIA-0 **********
Category: in_error-0
DDR Rx CRC-0 0
DDR Rx CRC-1 32616455 <=== Errors
RP/0/RSP1/CPU0:asr9k-1#show controllers fabric fia bridge stats location 0/0/CPU0
Ingress Drop Stats (MC & UC combined)
**************************************
PriorityPacket Error Threshold
Direction Drops Drops
--------------------------------------------------
LP NP-3 to Fabric 0 0
HP NP-3 to Fabric 1750 0
RP/0/RSP1/CPU0:asr9k-1#
RP/0/RSP1/CPU0:asr9k-1#show controllers fabric fia bridge stats location 0/6/CPU0

Sat Jan 4 06:33:41.392 CST
  ********** FIA-0 **********
Category: bridge_in-0
                                 UcH Fr Np-0                16867506
                                 UcH Fr Np-1                  115685
                                 UcH Fr Np-2                  104891
                                 UcH Fr Np-3                  105103
                                 UcL Fr Np-0              1482833391
                                 UcL Fr Np-1             31852547525
                                 UcL Fr Np-2              3038838776
                                 UcL Fr Np-3             30863851758
                                 McH Fr Np-0                  194999
                                 McH Fr Np-1                  793098
                                 McH Fr Np-2                  345046
                                 McH Fr Np-3                  453957
                                 McL Fr Np-0                27567869
                                 McL Fr Np-1                12613863
                                 McL Fr Np-2                  663139
                                 McL Fr Np-3                21276923
                                Hp ErrFrNp-0                       0
                                Hp ErrFrNp-1                       0
                                Hp ErrFrNp-2                       0
                                Hp ErrFrNp-3                       0
                                Lp ErrFrNp-0                       0
                                Lp ErrFrNp-1                       0
                                Lp ErrFrNp-2                       0
                                Lp ErrFrNp-3                       0
                                Hp ThrFrNp-0                       0
                                Hp ThrFrNp-1                       0
                                Hp ThrFrNp-2                       0
                                Hp ThrFrNp-3                       0
                                Lp ThrFrNp-0                       0
                                Lp ThrFrNp-1                       0
                                Lp ThrFrNp-2                       0
                                Lp ThrFrNp-3                       0
  ********** FIA-0 **********
Category: bridge_eg-0
                                 UcH to Np-0                  779765
                                 UcH to Np-1                 3744578
                                 UcH to Np-2                  946908
                                 UcH to Np-3                 9764723
                                 UcL to Np-0              1522490680
                                 UcL to Np-1             32717279812
                                 UcL to Np-2              3117563988
                                 UcL to Np-3             29201555584
                               UcH ErrToNp-0                       0
                               UcH ErrToNp-1                       0
                               UcH ErrToNp-2                     129 <==============
                               UcH ErrToNp-3                       0
                               UcL ErrToNp-0                       0
                               UcL ErrToNp-1                       0
                               UcL ErrToNp-2                   90359 <==========

Команды для Сбора для Устранимых ошибок Моста/FPGA на Сетевых картах в форме трезубца

Необходимо собрать эти команды:

  • show tech-support fabric
  • покажите техподдержку np
  • show controller fabric fia местоположение stats моста <> (несколько раз добираются),

Восстановление после Устранимых ошибок Моста/FPGA

Метод восстановления должен повторно загрузить линейную карту, на которую влияют.

RP/0/RSP0/CPU0:asr9k-1#hw-module location 0/6/cpu0 reload

Онлайновый отчёт о диагностическом тесте

Когда тест прошел, <node> местоположения show diagnostic result [тест <тестовый идентификатор> подробность] команда предоставляет сводку всех онлайновых диагностических тестов и сбоев, а также прошлый раз штамп. Тестовый ID для сбоя пути данных матрицы избыточного направления равняется десяти. Список всех тестов наряду с частотой пакетов тестирования может быть замечен с командой <node> местоположения show diagnostic content.

Выходные данные результата тестирования пути данных матрицы избыточного направления будут подобны этому примеру выходных данных:

RP/0/RSP0/CPU0:ios(admin)#show diagnostic result location 0/rsp0/cpu0  test 10 detail
Current bootup diagnostic level for RP 0/RSP0/CPU0: minimal
Test results: (. = Pass, F = Fail, U = Untested)

___________________________________________________________________________
10 ) FabricLoopback ------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 357
Last test execution time ----> Sat Jan 10 18:55:46 2009
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> Sat Jan 10 18:55:46 2009
Total failure count ---------> 0
Consecutive failure count ---> 0

Усовершенствования автоматического восстановления

Как описано в идентификаторе ошибки Cisco CSCuc04493, существует теперь способ завершить работу маршрутизатора автоматически все порты, которые привязаны к  ошибкам PUNT_FABRIC_DATA_PATH.

Первый метод отслежен через идентификатор ошибки Cisco CSCuc04493. Для Версии 4.2.3 это включено в идентификатор ошибки Cisco CSCui33805. В этой версии это собирается автоматически завершить работу всех портов, которые привязаны к NP, на которые влияют.

Вот пример, который показывает, как системные журналы появились бы:

RP/0/RSP0/CPU0:Jun 10 16:11:26 BKK: pfm_node_rp[359]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|System
Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed:
(0/1/CPU0, 0)
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINK-3-UPDOWN : Interface
TenGigE0/1/0/0, changed state to Down
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line
protocol on Interface TenGigE0/1/0/0, changed state to Down
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINK-3-UPDOWN : Interface
TenGigE0/1/0/1, changed state to Down
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line
protocol on Interface TenGigE0/1/0/1, changed state to Down

Контроллер укажет , что причина для интерфейсного не работания происходит из-за DATA_PATH_DOWN. Например:

RP/0/RSP0/CPU0:ASR9006-E#show controllers gigabitEthernet 0/0/0/13 internal
Wed Dec 18 02:42:52.221 UTC

Port Number       : 13
Port Type         : GE
Transport mode    : LAN
BIA MAC addr      : 6c9c.ed08.3cbd
Oper. MAC addr    : 6c9c.ed08.3cbd
Egress MAC addr   : 6c9c.ed08.3cbd
Port Available    : true
Status polling is : enabled
Status events are : enabled
I/F Handle        : 0x04000400
Cfg Link Enabled  : tx/rx enabled
H/W Tx Enable     : no
UDLF enabled      : no
SFP PWR DN Reason : 0x00000000
SFP Capability    : 0x00000024
MTU               : 1538
H/W Speed         : 1 Gbps
H/W Duplex        : Full
H/W Loopback Type : None
H/W FlowCtrl type : None
H/W AutoNeg Enable: Off
H/W Link Defects  : (0x00080000) DATA_PATH_DOWN <<<<<<<<<<<
Link Up           : no
Link Led Status   : Link down -- Red
Input good underflow          : 0
Input ucast underflow         : 0
Output ucast underflow        : 0
Input unknown opcode underflow: 0
Pluggable Present   : yes
Pluggable Type      : 1000BASE-LX
Pluggable Compl.    : (Service Un) - Compliant
Pluggable Type Supp.: (Service Un) - Supported
Pluggable PID Supp. : (Service Un) - Supported
Pluggable Scan Flg: false

В Версиях 4.3.1 и позже, должно быть включено это поведение. Существует новая команда config admin, которая используется для выполнения этого. Поскольку поведение по умолчанию больше не должно завершать работу портов, это должно быть вручную настроено.

RP/0/RSP1/CPU0:ASR9010-A(admin-config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status

CSCui15435 идентификатора ошибки Cisco  устраняет устранимые ошибки, которые замечены на Сетевых картах в форме трезубца, как описано здесь. Это использует другой метод обнаружения, чем обычный метод диагностики, который описан в идентификаторе ошибки Cisco CSCuc04493.

Этот дефект также представил новую команду CLI конфигурации admin:

(admin-config)#fabric fia soft-error-monitor <1|2> location <specific>

1 = shutdown the ports
2 = reload the linecard

Default behavior: no action is taken.

Когда с этой ошибкой встречаются, этот системный журнал может наблюдаться:

RP/0/RSP0/CPU0:Apr 30 22:17:11.351 : config[65777]: %MGBL-SYS-5-CONFIG_I : Configured
from console by root
LC/0/2/CPU0:Apr 30 22:18:52.252 : pfm_node_lc[283]:
%PLATFORM-BRIDGE-1-SOFT_ERROR_ALERT_1 : Set|fialc[159814]|NPU
Crossbar Fabric Interface Bridge(0x1024000)|Soft Error Detected on Bridge instance 1
RP/0/RSP0/CPU0:Apr 30 22:21:28.747 : pfm_node_rp[348]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed:
(0/2/CPU0, 2) (0/2/CPU0, 3)
LC/0/2/CPU0:Apr 30 22:21:29.707 : ifmgr[194]: %PKT_INFRA-LINK-3-UPDOWN :
Interface TenGigE0/2/0/2, changed state to Down
LC/0/2/CPU0:Apr 30 22:21:29.707 : ifmgr[194]: %PKT_INFRA-LINEPROTO-5-UPDOWN :
Line protocol on Interface TenGigE0/2/0/2, changed state to Down
RP/0/RSP1/CPU0:Apr 30 22:21:35.086 : pfm_node_rp[348]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED :
Set|online_diag_rsp[237646]|System Punt/Fabric/data Path Test(0x2000004)|failure
threshold is 3, (slot, NP) failed: (0/2/CPU0, 2) (0/2/CPU0, 3)

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

Часто задаваемые вопросы (FAQ)

Вопрос. Первичный процессор маршрута или карта процессора маршрутизации в режиме ожидания передают пакеты Keepalive или онлайновые диагностические пакеты к каждому NP в системе?

Ответ: Да. Обе карты процессора маршрутов передают онлайновые диагностические пакеты к каждому NP.

Вопрос. Когда карта процессора маршрутов одна (RSP1) активна, действительно ли путь является тем же?

О. Диагностический путь является тем же для RSP0 или RSP1. Путь зависит от состояния RSP. См. раздел Пути Диагностического пакета Матрицы Избыточного направления этого документа для получения дополнительной информации.

Вопрос. Как часто RSP передают диагностические пакеты, и сколько диагностических пакетов должно быть пропущено, прежде чем сигнал тревоги инициирован?

О. Каждый RSP независимо передает диагностический пакет к каждому NP один раз в минуту. Если три диагностических пакета не подтверждены, любой RSP может инициировать сигнал тревоги.

Вопрос. Как вы определяете, ли NP или был превышен?

О. Один способ проверить, превышается ли NP в настоящее время или был превышен в прошлом, состоит в том, чтобы проверить для определенного вида отбрасывания в NP и для отбрасывания остатка в FIA. Когда NP превышен и не может не отставать от входящего трафика, отбрасывания Входного переднего непосредственного доступа к памяти (IFDMA) в NP происходят. Отбрасывание остатка FIA происходит, когда выходной NP утверждает управление потоками (просит входная линейная плата передавать меньше трафика). Согласно сценарию управления потоками, входной FIA имеет отбрасывание остатка.

Вопрос. Как вы определяете, переносит ли NP отказ, который требует, чтобы он был перезагружен?

О. Как правило, отказ NP очищен быстрым сбросом. Причина для быстрого сброса отображена в журналах.

Вопрос. Какие показы, если NP имеет невосстанавливаемый отказ оборудования?

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

Вопрос. Будет пакет диагностики, который получен от одной карты процессора маршрутов, возвращенной тому же самому?

О. Так как диагностические пакеты получены от обеих карт процессора маршрутов и отслежены на на основание карты процессора маршрутов, диагностический пакет, полученный от карты процессора маршрутов, циклично выполнен назад к той же карте процессора маршрутов NP.

Вопрос. Идентификатор ошибки Cisco CSCuj10837 SMU предоставляет исправление для оптоволоконной ссылки, переобучают событие. Действительно ли это - причина и решение для многих сбоев пути данных матрицы избыточного направления?

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

Вопрос. Сколько времени занимает для переквалификации оптоволоконных ссылок, как только так принято решение сделать?

О. Решение переобучиться принято, как только обнаружен отказ соединения. Перед Выпуском 4.3.2 переобучение могло занять несколько секунд. После Выпуска 4.3.2 переобучать время было значительно улучшено и берет меньше, чем секунда.

Вопрос. В какой точке решение состоит в том, чтобы переобучить оптоволоконную сделанную ссылку?

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

Вопрос. Это только между FIA на карте активного процессора маршрутизации и матрицей, что вы используете первую ссылку, и затем после этого это - наименее загруженная ссылка, когда там действительно ли сложные соединения доступны?

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

Вопрос. Во время переобучения, все пакеты, которые переданы по той оптоволоконной потерянной ссылке?

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

Вопрос. Как часто вы ожидаете видеть, что оптоволоконная ссылка XBAR переобучает событие, после обновления к выпуску или SMU с исправлением для идентификатора ошибки Cisco CSCuj10837?

О. Даже с исправлением для идентификатора ошибки Cisco CSCuj10837 все еще возможно видеть, что оптоволоконная ссылка переобучается из-за идентификатора ошибки Cisco CSCul39674. Но как только у клиента есть исправление для идентификатора ошибки Cisco CSCul39674, оптоволоконная ссылка, переобучающаяся на оптоволоконных ссылках объединительной платы между RSP440 и Сетевыми картами по типу тайфуна, никогда не должна происходить. Если это делает, то повышает запрос на обслуживание с Центром технической поддержки Cisco (TAC) для устренения проблемы.

Вопрос. Идентификаторы ошибок Cisco CSCuj10837 и CSCul39674 влияют на RP на ASR 9922 с Сетевыми картами по типу тайфуна?

Ответ: Да 

Вопрос. Идентификаторы ошибок Cisco CSCuj10837 и CSCul39674 влияют на ASR 9001 и ASR-9001-S маршрутизаторы?

О. Нет 

Вопрос. Если вы встречаетесь со сбоем слота, который не существует с этим сообщением, "PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Тест избыточного направления/матрицы/пути данных Set|online_diag_rsp [237686] |System (0x2000004) |failure порог равняется 3, (слот, NP) подведенный: (8, 0)", в шасси с 10 слотами, какой слот имеет проблему?

О. В более старых версиях необходимо объяснить медосмотр и логические отображения как показано здесь. В данном примере слот 8 соответствует 0/6/CPU0.

For 9010 (10 slot chassis)
L           P
#0 --- #0
#1 --- #1
#2 --- #2
#3 --- #3
RSP0 --- #4
RSP1 --- #5
#4 --- #6
#5 --- #7
#6 --- #8
#7 --- #9

For 9006 (6 slot chassis)
L              P
RSP0 --- #0
RSP1 --- #1
#0 --- #2
#1 --- #3
#2 --- #4
#3 --- #5

Данные для сбора перед созданием запроса на обслуживание

Вот минимальные команды, которые необходимо собрать, прежде чем любые меры приняты:

  • Show logging
  • Покажите pfm местоположению все
  • admin показывает, что местоположение результата diagn 0/rsp0/cpu0 тестирует 8 подробностей
  • admin показывает, что местоположение результата diagn 0/rsp1/cpu0 тестирует 8 подробностей
  • admin показывает, что местоположение результата diagn 0/rsp0/cpu0 тестирует 9 подробностей
  • admin показывает, что местоположение результата diagn 0/rsp1/cpu0 тестирует 9 подробностей
  • admin показывает, что местоположение результата diagn 0/rsp0/cpu0 тестирует 10 подробностей
  • admin показывает, что местоположение результата diagn 0/rsp1/cpu0 тестирует 10 подробностей
  • admin показывает, что местоположение результата diagn 0/rsp0/cpu0 тестирует 11 подробностей
  • admin показывает, что местоположение результата diagn 0/rsp1/cpu0 тестирует 11 подробностей
  • show controller fabric fia местоположение link-status <lc>
  • show controller fabric fia местоположение link-status <оба rsp>
  • show controller fabric fia соединяет местоположение синхронизирующего статуса <оба rsp>
  • экземпляр состояния канала матричного коммутатора show controller fabric 0 местоположений <lc>
  • экземпляр состояния канала матричного коммутатора show controller fabric 0 местоположений <оба rsp>
  • экземпляр состояния канала матричного коммутатора show controller fabric 1 местоположение <оба rsp>
  • местоположение перемычки ltrace show controller fabric <оба rsp>
  • местоположение перемычки ltrace show controller fabric <влияло на lc>
  • покажите техническое местоположение матрицы <отказ, показав lc> файл <путь к файлу>
  • покажите техническое местоположение матрицы <оба rsp> файл <путь к файлу>

Полезные команды диагностики

Вот список команд, которые полезны для диагностических назначений:

  • show diagnostic ondemand settings
  • местоположение show diagnostic content <местоположение>
  • местоположение show diagnostic result <местоположение> [тест {id|id_list|all}] [подробность]
  • show diagnostic status
  • местоположение diagnostic start admin <местоположение> тест {id|id_list|test-комплект}
  • местоположение diagnostic stop admin <местоположение>
  • diagnostic ondemand iterations admin <итеративное количество>
  • diagnostic ondemand action-on-failure admin {продолжает сбой-count|stop}
  • admin-config# [никакое] местоположение диагностического монитора <местоположение> тест {идентификатор | тестовое название} [отключают]
  • admin-config# [никакое] местоположение diagnostic monitor interval <местоположение> тест {идентификатор | тестовое название} день hour:minute:second.millisec
  • admin-config# [никакое] местоположение diagnostic monitor threshold <местоположение> тест {идентификатор | тестовое название} счетчик ошибок

Заключение

С выделенного интервала времени Выпуска 4.3.4 программного обеспечения Cisco IOS XR решено большинство проблем, отнесенных к сбоям пути данных матрицы избыточного направления. Для маршрутизаторов, на которые влияют идентификаторы ошибок Cisco CSCuj10837 и CSCul39674, загрузите замену, SMU для CSCul39674 во избежание оптоволоконной ссылки переобучают события.

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

Приложение

Путь диагностики обратной связи NP

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

LC/0/7/CPU0:Aug 18 19:17:26.924 : pfm_node[182]: 
%PLATFORM-PFM_DIAGS-2-LC_NP_LOOPBACK_FAILED : Set|online_diag_lc[94283]|
Line card NP loopback Test(0x2000006)|link failure mask is 0x8

Это сообщение журнала означает, что этот тест был не в состоянии получать петлевой пакет от NP3. Маска отказа соединения является 0x8 (укусил 3, установлен), который указывает на сбой между ЦП линейной карты для слота 7 и NP3 на слоте 7.

Для получения большего количества подробных данных соберите выходные данные этих команд:

  • местоположение show diagnostic result admin 0 / тест <x>/cpu0 9 подробностей
  • NP show controllers противостоит NP <0-3> местоположение 0 / <x>/cpu0 

Оптоволоконные команды отладки

Команды, перечисленные в этом разделе, применяются ко всем Сетевым картам в форме трезубца, а также Основанному на тайфуне 100GE линейная карта. ASIC FPGA Моста не присутствует на Сетевых картах по типу тайфуна (за исключением 100GE Сетевые карты по типу тайфуна). Так, show controller fabric fia команды моста не применяется к Сетевым картам по типу тайфуна, за исключением 100GE версии.

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



Document ID: 116727