Catalyst 3850 переводит порт в err-disable, когда ThinkSystem SR650 использует оптику Lenovo 46C3447 SR
Новый хост ESXi ставится в стойку, подключённую к кампусному 3850. Управление по меди поднялось без проблем, а вот 10G-аплинки - нет: как только сервер загружается, порт коммутатора уходит в err-disable, и хост не видит ничего на этом vmnic.
- Lenovo ThinkSystem SR650, 7X06CTO1WW, с адаптером Emulex VFA5.2 2x10GbE SFP+
- модули Lenovo 10GBASE-SR, 46C3447, в адаптере
- Cisco WS-C3850-24XS-S с Cisco SFP-10G-SR на стороне коммутатора
- патч-корд OM3 LC-LC между ними
Te1/0/7: goes err-disabled within seconds of the server powering on
ESXi: the uplink shows DISCONNECTED
Same patch cord, Cisco SFP-10G-SR at both ends switch to switch: link up and stableУже пробовал:
- переставил сервер на другой порт того же коммутатора - то же самое
- поменял 46C3447 на близнеца с другого порта адаптера
- свежий патч-корд, оба конца почищены и переустановлены
С оптикой на стороне коммутатора и с самим волокном явно всё в порядке, так что что-то возражает именно против модуля Lenovo. Кто здесь возражает - сервер или коммутатор, и есть ли способ заставить 3850 с этим смириться?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
Этот лог всё решает.
gbic-invalid- это коммутатор отказывается от того, что он читает как неавторизованный модуль, и эта проверка живёт на стороне Cisco, а не на SR650 и не в ESXi. Он возражает против SR-оптики с кодировкой Lenovo в этой линии и убивает порт ещё до того, как линк вообще оценивается - именно поэтому смена портов и патч-кордов у вас ничего не изменила.Две строки в глобальной конфигурации:
Первая говорит коммутатору продолжать работу с модулем, который он не распознаёт, вторая не даёт err-disable отстреливать порт, когда эта проверка CRC не проходит. Ни одна из них не действует задним числом, так что после этого перезапустите порт и переустановите оптику, пока он выключен:
Сохраните конфигурацию, как только порт поднимется. Если она остаётся только в running config, после следующей перезагрузки порт снова окажется в err-disable, и вам придётся разбираться с этим заново в гораздо более неудобный момент.
Две оговорки. Вы теперь вне поддерживаемой Cisco конфигурации: они считают стороннюю оптику непротестированной, и TAC может отказаться от case по совместимости, если в нём участвует такой модуль - это важно, если линк подпадает под контракт. И
service unsupported-transceiver- не универсальное лекарство. То же сообщение о плохом crc переживает эту команду, если препятствие в самом порту, например 1G-only слот SFP с воткнутым в него 10G-модулем, так что если порт остаётся выключенным после перезапуска, проверьте, на какой скорости реально работает каждый конец, прежде чем снова винить оптику.Прежде чем гадать: что именно пишет коммутатор в лог, когда порт падает? Err-disable всегда называет причину, и причина полностью меняет ответ. Жалоба на безопасность или CRC модуля - это совсем другая проблема, чем флап или срабатывание протокола, и лекарство от одного не поможет с другим.
Вытащите
show loggingза момент включения сервера и выложите строки по этому порту. Также подтвердите, что физически стоит в Te1/0/7 - вы говорите Cisco SFP-10G-SR, значит 46C3447 - единственная нецисковская деталь на этом пути?Лог с момента падения, две строки по этому порту:
То есть срабатывает проверка безопасности, а не флап. И да, сторона коммутатора - это настоящий Cisco SFP-10G-SR из коробки Cisco, 46C3447 в сервере - единственная деталь с кодировкой Lenovo на всём пути. Это меня и сбило с толку, потому что сообщение называет порт на коммутаторе, а не что-либо со стороны сервера.