Коммутаторы : Коммутаторы Cisco Nexus серии 7000

Стандартное оборудование устранения неполадок и проблемы архитектуры в коммутаторах Cisco Nexus серии 7000

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

Содержание

Введение

Этот документ предоставляет краткое объяснение и решения для стандартного оборудования и проблемы архитектуры для коммутаторов Cisco Nexus серии 7000, которые выполняют системное программное обеспечение Cisco NX-OS.

Примечание: Точный формат системного журнала и сообщений об ошибках, которые описывает этот документ, может варьироваться немного. Изменения зависят от версии программного обеспечения, используемого на модуле управления Supervisor Engine.

Внесенный Иваном Ширшином и Нэвином Венкэтешэйой, специалистами службы технической поддержки Cisco.

Сбой

Проблема: SpineControlBus

Контрольное испытание позвоночника отказывает для супервизора Nexus 7000:

Nexus7000# show module internal exceptionlog module 5
...
System Errorcode : 0x418b0022 Spine control test failed
Error Type       : Warning
PhyPortLayer     : 0x0
Port(s) Affected : none
Error Description : Module 10 Spine Control Bus test Failed
...
        11) SpineControlBus E
                Error code ------------------> DIAG TEST ERR DISABLE
               Total run count -------------> 1597800
               Last test execution time ----> Mon May 27 21:57:17 2013
               First test failure time -----> Sun Nov 20 00:30:55 2011
               Last test failure time ------> Mon May 27 21:57:17 2013
               Last test pass time ---------> Mon May 27 21:56:47 2013
               Total failure count ---------> 33
               Consecutive failure count ---> 1
               Last failure reason ---------> Spine control test failed

Решение

Эта проблема отнесена к идентификатору ошибки Cisco CSCuc72466. См. часто задаваемые вопросы Nexus 7000: Когда SpineControlBus тестируют сбои, что должно взять рекомендованное действие?.

Проблема: Дефектные блоки, найденные на NVRAM

Ошибки NVRAM появляются в диагностических событиях:

Nexus7000#show diagnostic events
1) Event:E_DEBUG, length:97, at 9664 usecs after Wed Dec 5 01:03:42 2012
   [103] Event_ERROR: TestName->NVRAM TestingType->health monitoring module->5
Result->fail Reason->
#show diagnostic result module 5 test NVRAM detail
 4) NVRAM-------------------------> E
                Error code ------------------> DIAG TEST ERR DISABLE
               Total run count -------------> 52596
               Last test execution time ----> Wed Dec 5 01:03:41 2012
               First test failure time -----> Tue Dec 4 23:28:45 2012
               Last test failure time ------> Wed Dec 5 01:03:42 2012
               Last test pass time ---------> Tue Dec 4 23:23:41 2012
               Total failure count ---------> 20
               Consecutive failure count ---> 20
               Last failure reason ---------> Bad blocks found on nvram

Это - или проблема аппаратных средств, сбой Supervisor Engine или переходная проблема.

Решение

  1. Повторно выполните тест NVRAM, чтобы видеть, является ли это ошибочным сигналом тревоги. Введите эти команды, чтобы отключить и реактивировать диагностический тест (пример, если дали для проблемного модуля 5):
    • никакой модуль 5 диагностического монитора не тестирует NVRAM
    • модуль 5 диагностического монитора тестирует NVRAM

    Введите show diagnostic result module 5 тестовых подробных команд NVRAM для наблюдения результатов тестовой команды.

  2. Если тест NVRAM отказывает снова, переустановите модуль 5. Наблюдайте результат show diagnostic result module 5 и команды show module.
  3. Если модуль отказывает снова, повысьте запрос Разрешения на возврат материалов (RMA) о Супервизоре в проблемном слоте.

Проблема: Сбой стандарта Compact Flash модуля 9

Один или все они замечены на Супервизоре 2/супервизор 2E:

  • :
    DEVICE_TEST-2-COMPACT_FLASH_FAIL: Module 5 has failed test CompactFlash 
    20 times on device Compact Flash due to error The compact flash power test failed.
  • Неспособный к save config.
  • Отказы диагностического теста:
          Test results: (. = Pass, F = Fail, I = Incomplete,
          U = Untested, A = Abort, E = Error disabled)
          7) CompactFlash E
                  Error code ------------------> DIAG TEST ERR DISABLE
                  Total run count -------------> 23302
                  Last test execution time ----> Sun Apr 13 10:07:30 2014
                  First test failure time -----> Sun Apr 13 00:37:41 2014
                  Last test failure time ------> Sun Apr 13 10:07:40 2014
                 Last test pass time ---------> Sun Apr 13 00:07:41 2014
                Total failure count ---------> 20
                  Consecutive failure count ---> 20
                  Last failure reason ---------> The compact flash power test
                                                  failed
                  Next Execution time ---------> Sun Apr 13 10:37:30 2014

Основная причина

Второе поколение Nexus 7000 Супервизоров поставлено с двумя идентичными вспышками eUSB для резервирования. Вспышки предоставляют репозиторий для загрузочной флэш-памяти, конфигураций и другой информации о принадлежности. Эти две вспышки реконфигурированы как Резервный набор независимых дисков (RAID) 1 массив, который внедряет внутреннее зеркалирование. С резервированием Супервизор может функционировать с потерей одной из вспышек, но не обоих.

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

Решение

Выполните эти шаги, чтобы проверить, ли это или не является проблемой аппаратных средств:

  1. Повторно загрузите проблемный Супервизор, если это возможно.
  2. Если проблема замечена после повторной загрузки вам нужна замена оборудования.
  3. Если проблема устранена повторной загрузкой, основная причина отнесена к идентификатору ошибки Cisco CSCus22805.

Линейная плата

Проблема: N7K-M132XP-12 сбой проверки PortLoopback

Линейная плата сообщает, что сбой из-за диагностики портирует сбой проверки PortLoopback 10 раз последовательно:

DIAG_PORT_LB-2-PORTLOOPBACK_TEST_FAIL Module:16 Test:PortLoopback
failed 10 consecutive times. Faulty module:Module 16 affected ports:5,7 
Error:Loopback test failed. Packets lost on the LC at the Queueing engine ASIC

MODULE-4-MOD_WARNING Module 16 (serial: XXXX) reported warning on
ports 16/5-16/5 (Ethernet) due to Loopback test failed. 
Packets lost on the LC at the Queueing engine ASIC in device 78
(device error 0x41830059)

Основная причина

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

Решение

Проверьте для идентификатора ошибки Cisco CSCtn81109 и идентификатор ошибки Cisco CSCti95293 сначала, поскольку это могло быть проблемой программного обеспечения.

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

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

  • журнал show logging
  • show module
  • покажите модулю результата diagn всю подробность

Также вы можете повторно выполнить только этот определенный тест и не должны повторно загружать плату. Данный пример показывает модуль 16:

show diagnostic result module 16
diagnostic clear result module all
(config)# no diagnostic monitor module 16 test 5
(config)# diagnostic monitor module 16 test 5
diagnostic start module 16 test 5
show diagnostic result module 16 test 5

Линейная плата

Проблема: N7K-M132XP-12 MODULE-4-MOD_WARNING

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

2013 Mar 27 00:40:23 DC3-7000-PRODD2-A23  MODULE-4-MOD_WARNING  
Module 9 (serial: XXX) reported warning on ports 9/1-9/3 (Unknown)
due to BE2 Arbiter experienced an error in device 65 (device error 0xc410f613)

Основная причина

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

Решение

  1. Проверьте выходные данные этих команд:
    • show version
    • модуль X show system reset-reason
    • show logging onboard внутренняя причина сброса
    • команда "show module" внутренний модуль X истории события
    • show log
  2. Если ваша версия Cisco, которая OX NS ранее, чем Версия 4.2, то обновите к новой версии для обеспечения, исправляет для этих ошибок ПО, интегрированы (минимизируйте возможность ошибок контроля четности):
    • D-кэш CSCso72230 L1 идентификатора ошибки Cisco включил 8541 сбой ЦП с D-ошибками-контроля-четности-кэша L1
    • Идентификатор ошибки Cisco CSCsr90831 - D-кэш L1 включил 8541 сбой ЦП с ошибками контроля четности Толчка D-кэша L1
  3. Если ошибки неоднократно происходят, переустанавливают карту и монитор.
  4. Если ошибки все еще повторяют, заменяют проблемный модуль.

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

Идентификатор ошибки Cisco CSCtb98876

Чико

Проблема: N7K-M224XP-23L serdes Ошибка потери синхронизации

Эти ошибки появляются на модуле:

%MODULE-4-MOD_WARNING: Module # (Serial number: XXXX) reported warning 
Ethernet#/# due to chico serdes sync loss in device DEV_SKYTRAIN
(device error 0xc9003600)

Основная причина

Эти ошибки указывают, что существует проблема потери синхронизации между модулем # и Xbar/ASIC. В большинстве случаев причиной является отказ оборудования модуля.

Если ваша версия Cisco, которая OX NS ранее, чем 6.1 (4) и сообщение, не появляется постоянно, на это может влиять идентификатор ошибки Cisco CSCud91672. Причина дефекта состоит в том, что NX-OS serdes параметры настройки отличаются от диагностических параметров настройки на этих двух каналах между SKT <-> SAC.

Решение

Соберите выходные данные этих команд:

  • show version
  • show module
  • show run
  • команда "show module" внутренний модуль X истории события
  • команда "show module" внутренний модуль X действия
  • модуль X журнала внутренней исключительной ситуации команды "show module"
  • команда "show module" внутренние ошибки истории события
  • show logging last 200
  • show logging nvram

Обновите коммутатор к Версии 6.1 (4) OX NS или позже для изоляции причины дефекта.

Выполните этот тест, чтобы подтвердить, неисправна ли карта вместо xbar или слота шасси:

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

Проблема: N7K-F248XP-25 PrimaryBootROM и сбои проверки SecondaryBootROM

Модуль N7K-F248XP-25 отказывает и в тестах PrimaryBootROM и в SecondaryBootROM:

show module internal exceptionlog module 1 | i Error|xception
********* Exception info for module 1 ********
exception information --- exception instance 1 ----
Error Description : Secondary BootROM test failed
 
exception information --- exception instance 2 ----
Error Description : Primary BootROM test failed

Основная причина

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

Решение

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

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

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

  1. Планируйте период технического обслуживания и войдите , bios модуля X установки вызвал команду как возможный обходной путь. Только введите эту команду во время периода технического обслуживания во избежание влияния потенциального сервиса.
  2. Если шаг 1 не помогает, или не возможно иметь период технического обслуживания для этого действия, заменить модуль. Выходные данные данного примера показывают неудачную попытку:
Nexus7000# install module 1 bios forced
Warning: Installing Bios forcefully...!
Warning: Please do not remove or power off the module at this time
Upgrading primary bios
Started bios programming .... please wait
[#                           0%                            ]
BIOS install failed for module 1, Error=0x40710027(BIOS flash-type verify failed)
BIOS is OK ...
Please try the command again... 

Проблема: Отказ датчика температуры

Эта ошибка замечена на платформе:

%PLATFORM-4-MOD_TEMPFAIL: Module-2 temperature sensor 7 failed

Основная причина

Это - неустойчивая проблема с блоком температуры/напряжения в ASIC при определенных условиях из-за внутренней синхронизации ASIC. Идентификатор ошибки Cisco CSCtw79052 описывает известную причину для этой проблемы.

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

Решение

Соберите выходные данные от этих команд и проверки против идентификатора ошибки Cisco CSCtw79052:

  • show version
  • температура show env
  • модуль show sprom <модуль #> 
  • Attach module Nexus# <модуль #>
  • <module#>#show аппаратные средства внутренние ошибки истории события датчика

Проблема: Xbar Error/C7010-FAB-1 в Нерабочем состоянии Питания

C7010-FAB-1 находится в нерабочем состоянии питания, и эти ошибки появляются:

%PLATFORM-3-EJECTOR_STAT_CHANGED: Ejectors' status in slot 13 has changed, 
Left Ejector is OPEN, Right Ejector is CLOSE

%PLATFORM-3-EJECTOR_STAT_CHANGED: Ejectors' status in slot 13 has changed,
Left Ejector is OPEN, Right Ejector is OPEN

%PLATFORM-2-XBAR_REMOVE: Xbar 3 removed (Serial number XXX)
 
Xbar Ports Module-Type                        Model             Status
--- ----- ----------------------------------- ------------------ ----------
3   0     Fabric Module                      N/A               powered-dn
?
Xbar Power-Status Reason
--- ------------ ---------------------------
3   powered-dn    failure(powered-down) since maximum number of bringups were exceeded

Также ошибки ASIC xbar появляются:

%MODULE-4-MOD_WARNING: Module 15 (serial: XXX) reported warning due to 
X-bar Interface ASIC Error in device 70 (device error 0xc4600248)

%OC_USD-SLOT15-2-RF_CRC: OC2 received packets with CRC error from MOD 15
through XBAR slot 3/inst 2

Основная причина

Эта проблема происходит или из-за неисправного или из-за плохо усаженного xbar модуля или плохого слота шасси.

Решение

  1. Проверьте выходные данные этих команд:
    • show version
    • show module
    • show logging
    • show logging nvram
    • журнал внутренней исключительной ситуации команды "show module"
    • команда "show module" внутренняя история события
    • show core
    • show system reset-reason
    • show environment | в xbar
    • show system внутренняя платформа внутренняя история события xbar X является xbar #
    • show system внутренние xbar-клиентские внутренние ошибки истории события
    • show system внутренний xbar все
    • show system внутренние xbar ошибки истории события
  2. Выполните твердое переустанавливают xbar модуля и проверяют статус.
  3. Если переустановить сбои, протестируйте xbar в другом слоте или протестируйте тот же слот с другим xbar модулем, чтобы гарантировать, что шасси прекрасно.
  4. Замените неисправное оборудование на основе тестов, выполненных в шагах 2 и 3.

Проблема: N7K-C7010-FAN-F отказавший модуль вентилятора

Один или больше этих признаков сбоя вентилятора наблюдаются:

%PLATFORM-5-FAN_STATUS: Fan module 3 (Serial number XXX) 
Fan3(fab_fan1) current-status is FAN_FAIL
 
Nexus 7000#show environment fan
Fan3(fab_fan1) N7K-C7010-FAN-F   1.1    Failure (Failed Fanlets: 2 6 7 8 9 10 14 15 )
Fan4(fab_fan2) N7K-C7010-FAN-F   1.1    Ok 
...
 
#show hardware
----------------------------------
Chassis has 4 Fan slots
----------------------------------
Fan3(fab_fan1) failed
 Model number is N7K-C7010-FAN-F
...

Основная причина

В большинстве случаев это - сбой вентилятор или слот шасси.

Решение

  1. Проверьте выходные данные этих команд:
    • show version
    • show module
    • show inventory
    • show log
    • nvram show log
    • вентилятор show environment
  2. Протестируйте этот N7K-C7010-FAN-F в другом хорошем шасси.
  3. Замените вентилятора или шасси на основе результатов шагов 1 и 2.

Проблема: Аварийный сигнал источника питания %PLATFORM-2-PS_CAPACITY_CHANGE

Сигналы тревоги замечены для изменений емкости, иногда очень часто.

%PLATFORM-2-PS_CAPACITY_CHANGE: Power supply PS2 changed its capacity. 
possibly due to On/Off or power cable removal/

2013 Oct 17 17:06:40 ... last message repeated 14 times

 

Основная причина

Эта проблема происходит или из-за неисправного или из-за разъединенного шнура питания или  сбоя питания.

Решение

Проверьте выходные данные подробной команды питания show env и исследуйте статус источника питания. В выходных данных данного примера связаны обе хорды, но вторая емкость показов только 1200 Вт вместо 3000 Вт и это должно быть для 220-вольтового AC на N7K-AC-6.0KW. Источник питания протестировал OK. Замените источник питания.

PS_2 total capacity:   4200 W  Voltage:50Vchord 1   capacity:   3000 W chord 1   
connected to 110v AC chord 2   capacity:   1200 W chord 2   connected to 220v AC

Проблема: %PLATFORM-5-PS_STATUS: сигнал тревоги PowerSupply X PS_FAIL

Это предупреждение появляется на платформе:

%PLATFORM-5-PS_STATUS: PowerSupply 3 current-status is PS_FAIL

%PLATFORM-2-PS_FAIL: Power supply 3 failed or shut down (Serial number xxxxx)

Основная причина

Это предупреждение происходит или из-за неисправного или из-за разъединенного шнура питания или сбоя питания.

Решение

  1. Проверьте выходные данные этих команд:
    • подробность show environment power
    • show power
  2. Переустановите отказавший источник питания. Используйте дополнительный источник питания, чтобы гарантировать, что питание не идет оффлайн.
  3. Отправьте RMA для источника питания. Используйте дополнительный источник питания, чтобы гарантировать, что питание не идет оффлайн.

Ссылки

Cisco Nexus избыточность питания серии 7000

Проблема: Проблема источника питания на FEX

Эти сигналы тревоги появляются для источника питания FEX:

%SATCTRL-FEX104-2-SOHMS_DIAG_ERROR: FEX-104 Module 1: Runtime diag detected major event:
Voltage failure on power supply: 1
%SATCTRL-FEX104-2-SOHMS_DIAG_ERROR: FEX-104 System minor alarm on power
supply 1: failed

%SATCTRL-FEX104-2-SOHMS_DIAG_ERROR: FEX-104 Recovered: System minor alarm
on power supply 1: failed 

Решение

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

Методы для решения этих вопросов включают:

  1. Переустановите источник питания FEX. Используйте дополнительный источник питания, чтобы гарантировать, что питание не идет оффлайн.
  2. Отправьте RMA для источника питания FEX. Используйте дополнительный источник питания, чтобы гарантировать, что питание не идет оффлайн.
  3. Повторите эти шаги для второго источника питания.

Рассмотрите и ответьте на эти вопросы, чтобы помочь определять обстоятельства сбоя:

  1. На сколько источников питания FEX влияют?
  2. Для второстепенного сигнала вы подкачивали источник питания, и это имело какое-либо значение?
  3. У вас есть другие источники питания FEX, которые имеют проблемы?
  4. У вас есть какие-либо другие коробки того же источника питания?
  5. Вы заменяли шнур питания?
  6. Был ли скачок напряжения или незначительный сбой в среде?

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

  • show sprom fex 100 все
  • журнал show logging | нет
  • покажите технологию fex 100 | нет
  • fex 100 присоединения
  • программное обеспечение show platform satctrl трассировка

Дефект известного программного обеспечения

Идентификатор ошибки Cisco CSCtr77620

Об источниках питания Проблема: N7K-AC-6.0KW Сообщают как Сбой

Об источниках питания Эмерсона N7K-AC-6.0KW сообщают как Сбой / Закрытый, но коммутатор хорошо работает, и не0 эффективных выходных мощностей замечены для проблемного источника питания.

Основная причина

На предоставлении с обоими активными вводами то, когда ввод разъединен, повторно соединилось и разъединило снова в течение 1.5 секунд, предоставление может фиксировать отказ пониженного напряжения, и NX-OS может отметить источник питания, как подведено. В другом изменении, на предоставлении с двумя вводами, удаляют один ввод и ждут 20 - 30 секунд. Предоставление могло бы периодически поставить Внутренний будильник Отказа, и NX-OS сообщает об источнике питания, как подведено.

CSCty78612 идентификатора ошибки Cisco вносит изменения в микропрограммное обеспечение на блоках питания для устранения проблемы.

CSCuc86262 идентификатора ошибки Cisco добавляет улучшение программного обеспечения для восстановления с этих ложных сообщений об ошибках. Если состояние, о котором сообщают, отличается от реального состояния, NX-OS теперь автономно контролирует статус Блока питания (PSU) и модифицирует его к соответствующему статусу.

Решение

Введите подробную команду питания show env и проверьте эффективную выходную мощность для проверки ложных сообщений об ошибках:

Nexus7000# show env power
Power Supply:
Voltage: 50 Volts
Power Actual Total
Supply Model Output Capacity Status
(Watts ) (Watts )
------- ------------------- ----------- ----------- --------------
1 N7K-AC-6.0KW 0 W 0 W Shutdown
2 N7K-AC-6.0KW 3888 W 6000 W Fail/Shut

Ошибочные Отказывают/Закрывают, статус очищен при включении выкл/вкла PSU.

Идентификатор ошибки Cisco CSCty78612 вносит изменения в микропрограммное обеспечение на PSU. Программное обеспечение было улучшено через идентификатор ошибки Cisco CSCuc86262, который восстанавливается со лжи, отказывают/закрывают уведомления с исправлением ложных битов, если источник питания во времени выполнения обычно работает. Версии NX-OS 5.2 (9), 6.1 (3), 6.2 (2) и позже имеют подарок усовершенствования, который избегает RMA.

Проблема: Отбрасывание пакета программного обеспечения

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

Основная причина

Это ожидаемое состояние. Когда система получает пакет IP с длиной дольше, чем настроенный MTU на исходящем интерфейсе пакета, система передает этот пакет к уровню управления, который заботится о фрагментации. В NX-OS 4.1.3 и позже, ограничитель скорости применен к таким плывшим на плоскодонке пакетам. Это ограничивает его максимумом 500 pps по умолчанию.

Решение

Это - дефект известного программного обеспечения в идентификаторе ошибки Cisco CSCsu01048.

Проблема: USER-2-SYSTEM_MSG системная ошибка сбоя самопроверки FIPS

"USER-2-SYSTEM_MSG сбой самопроверки FIPS в DCOS_rand - netstack" ошибочные показы.

Основная причина

Каждый раз, когда случайное число генерируется, выполнения самопроверки Условного генератора случайных чисел (CRNG). Если тест отказывает, сообщение системного журнала зарегистрировано. Это сделано согласно рекомендации Федеральных стандартов обработки информации (FIPS) (FIPS). Однако влияние этого безопасно, поскольку случайное число генерируется снова.

Существует два типа генераторов случайных чисел (RNGs) в NX-OS:

  • RNG FIPS, который внедрен в openssl крипто-библиотеке
  • RNG неFIPS, который является Linux RNG

Согласно FIPS, весь RNGs должен внедрить Условный тест генератора случайных чисел (CRNGT). Тест сравнивает текущее генерируемое случайное число с предыдущим. Если номера являются тем же, то сообщение системного журнала генерируется, и еще одно случайное число генерируется.

Тест запущен, чтобы гарантировать что уникальность случайного числа. Нет никакого функционального влияния, поскольку восстановлен номер.

Решение

Это сообщение безопасно для работы системы. От Версии 5.2x Cisco NX-OS и позже, степени серьезности ошибки сообщения спущены шлюпку от 2, таким образом, это больше не замечается с конфигурацией журнала по умолчанию. Эта регистрация происходит как часть внутренних самопроверок NX-OS для различных функций на коммутаторе.

Это - дефект известного программного обеспечения в идентификаторе ошибки Cisco CSCtn70083.



Document ID: 118959