Сторонняя оптика SFP+ остаётся down на подержанном DCS-7150S-24: остаётся ли вариантом файл enable3px во флеше?
Приобрёл пару подержанных коммутаторов Arista для лаборатории и сразу упёрся в шлюз оптики. Закодированные Arista модули линкуются, пассивные DAC-кабели линкуются, а всё стороннее оставляет порт в down.
Лабораторная сторона:
- DCS-7150S-24, куплен б/у, без контракта поддержки и без закреплённой аккаунт-команды
- разные сторонние модули SFP+
- пассивные DAC-кабели для коротких линков внутри стойки
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes upЧто я уже выяснил:
- то, что DAC поднимается, а оптика нет, говорит мне, что это проверка кодирования, а не кабель и не мёртвый кейдж
- есть конфигурационная команда вида
service unsupported-transceiver CUSTOMERNAME LICENSEKEY, которая очевидно требует ключ, который мне неоткуда взять - в старых заметках упоминается файл-маркер во флеше вместо ключа, но я не могу понять, к какому поколению это относится
Какой из двух механизмов актуален для коробки такого возраста, и остаётся ли файл во флеше вариантом на 7150S, или ключ - единственный оставшийся путь?
Comments 6
На этом поколении это файл, и он настолько же грубый, насколько звучит. Из CLI EOS:
Пустой файл, ничего внутри - само его наличие включает стороннюю оптику после перезагрузки. Список платформ, где это работает, длинный: DCS-7120T-4S, семейство DCS-7050 и вся линейка DCS-7150S среди прочих, и у каждой модели есть самый новый релиз EOS, который ещё учитывает этот файл, начиная примерно с 4.13.16M на самых старых коробках и до ветки 4.23 на 7150S. Более новые коммутаторы полностью игнорируют файл.
Так что 7150S-24 находится на хорошей стороне этой границы, при условии что вы не ушли дальше того, что поддерживает модель. Попробуйте это, прежде чем лезть к варианту с ключом.
На какой ветке EOS этот 7150S-24, и обновляли ли вы её после покупки? Это важно, потому что граница отсечения задаётся по платформе, а не по семейству. Файл-флаг документирован как рабочий на 7048T, 7120T-4S, 7140T-8S, вариантах SFP+ 7124 и 7148, сериях 7050 и 7150S и линейных картах 7548S-LC, но последний релиз EOS, который его ещё учитывает, для каждой из них свой.
Если вы уже обновляли EOS на подержанной коробке, есть неплохой шанс, что вы обновлением ушли за пределы этого трюка, и тогда дешёвое решение - откатиться на ветку ниже, а не искать ключ.
Ни разу не трогал EOS с момента, как коробка приехала, так что она всё ещё на той ветке, на которой её оставил продавец - что оказалось удачей. Сделал touch, write memory, reload - и сторонние модули SFP+, которые раньше были мертвы, теперь поднимаются как обычные порты. Без ключа, без аккаунт-команды, больше ничего не понадобилось. DAC при этом продолжали работать, как и ожидалось.
Для тех, кто попадёт сюда с более новой коробкой: там файл реально игнорируется, и единственный путь - криптографический ключ для конкретного заказчика, который живёт в running-конфигурации как
Ключ выдаёт аккаунт-команда или команда решений, а не поддержка - TAC не уполномочен выдавать ключи разблокировки и отправит вас обратно к аккаунт-менеджменту, что тупик, если коммутатор пришёл с вторичного рынка.
Стоит повторить для лабораторных сборок: пассивные DAC-кабели принимаются по умолчанию независимо от состояния разблокировки. Если линки достаточно короткие, можно вообще обойти весь вопрос, коммутируя через DAC и оставив оптику для тех линков, которым она реально нужна.
Небольшая поправка к "живёт в running-конфигурации": на более старом коде, с которым я работал, был также недокументированный вариант той же команды, так что если наткнётесь на упоминание, не совпадающее по синтаксису с приведённым выше, дело в этом, а не в чьей-то опечатке.
По моему опыту ключ также срабатывал без перезагрузки - большинство сторонней оптики начинало работать сразу после ввода команды, хотя пара модулей всё равно отказывалась, что бы ни делали. Это было давно, на железе, которого у меня уже нет, так что проверьте на своей коробке, прежде чем планировать окно обслуживания под это.
Поскольку это сравнение всплывает каждый раз, когда заходит речь о теме: на Cisco IOS-XE и IOS XR эквивалент - это два шага, а не один. Одной глобальной команды недостаточно, нужна ещё команда для каждого интерфейса на любом физическом порту, который должен принять модуль:
Строка для интерфейса - та, что пропускает проверку product ID, так что порт хотя бы попытается зажечь оптику - без гарантии, что модуль после этого заработает, только гарантия, что платформа перестанет его отклонять. Делал это на IOS XR 5.3.3 и на коробках IOS-XE.
Оговорка одинакова у обоих вендоров, и именно поэтому люди продолжают спорить об этом: если неисправность будет прослежена до установленного заказчиком стороннего трансивера, в поддержке по гарантии или контракту может быть отказано. Нормально для лаборатории, решение, которое стоит принимать осознанно в продакшене.