Сторонний DWDM SFP+ остаётся down на Arista 7050T с EOS 4.10.6 - есть ли что-то, кроме патча образа?

Прежде чем кто-то отправит вас к образу, два момента.

На какой ветке EOS вы реально привязаны на этом 7050T? Если нужно оставаться на 4.10.6, то хак под конкретную сборку хотя бы самосогласован. Если можно сдвинуться, учтите, что обработка трансиверов была реорганизована в более поздних релизах, и ни один рецепт, написанный для 4.10.6, не переносится.

И что реально может прошить ваш поставщик в модули? Стоит спросить, есть ли у их программатора вообще профиль Arista, или только специфичная под платформу кодировка Cisco, которую большинство из них держит - например, деталям ASR9K нужен свой собственный профиль, и поставщики оптики его поддерживают. Перекодировать партию заметно дешевле, чем жить на модифицированном образе. Отдельно: вы уже спрашивали у своего аккаунт-менеджера ключ unsupported-transceiver, или это исключено по коммерческим причинам?

Патч образа реально работает на этой конкретной сборке, и работы там немного - но делайте это на лабораторном или запасном устройстве, никогда на том, что несёт трафик.

В общих чертах: распакуйте EOS-4.10.6.swi и сохраните элементы - boot0, initrd-i386, linux-i386, rootfs-i386.sqsh и version. Распакуйте корневую файловую систему от root, отредактируйте агент, соберите заново:

unsquashfs rootfs-i386.sqsh
mksquashfs squashfs-root/ rootfs-i386.sqsh
zip -Z store EOS-4.10.6a.swi boot0 initrd-i386 linux-i386 rootfs-i386.sqsh version

Сама правка - в squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py: закомментируйте четыре строки около строки 172, которые проверяют состояние presence, а затем выполняют аутентификацию трансивера. -Z store в zip не опционален, swi должен оставаться несжатым, иначе устройство его не загрузит.

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

Отвечая на вопросы выше: устройство запасное, без контракта поддержки, а у поставщика в программаторе вообще нет профиля Arista - они кодируют под платформы Cisco, и на этом список заканчивается, так что перекодировать эту партию не предлагают. Путь через аккаунт-менеджера не исключён, просто на этой неделе он мне не поможет.

Пересобрал 4.10.6, как описано, загрузил пропатченный образ, и оба порта DWDM поднялись с первой попытки. Штатный образ всё ещё на флэше. Линк держится стабильно с тех пор, и на дальнем конце ничего необычного не видно.

Рад, что сработало, но будьте честны с собой насчёт срока годности этого патча, потому что ветка выше делает его звучащим более универсальным, чем он есть.

Он написан для 4.10.6 и ни для чего больше. Люди спрашивали, как повторить это на 4.14.5F, 4.14.7M и 4.23.8M, и никто так и не опубликовал рабочего ответа, потому что менеджер трансиверов был реорганизован в более поздних релизах, и тех четырёх строк там просто нет. К тому же каждое обновление заменяет образ, так что патч исчезает, и порты падают при следующем плановом обслуживании.

Варианты, которые переживают обновление, - это специфичный для заказчика ключ service unsupported-transceiver, который выдаёт аккаунт-менеджер, и на более старых платформах файл-маркер enable3px. Используйте пропатченный образ, чтобы продлить жизнь старому устройству, а не как стандарт для сети.

Та же борьба на стороне Cisco, с деталью, которую стоит взять на заметку. Сторонние DWDM SFP+ 80 км (Pro10Optix, маркировка SFP-10G-DWDM-192) работали в коммутаторах Catalyst 6500 без нареканий. Переставленные во встроенные порты SFP+ ASR 9001 на IOS XR 5.3.3 они выдали:

%PLATFORM-SFP-3-DEV_SFP_SUPPORTED_ERROR: SFP Module is not supported
%PLATFORM-SFP-3-DEV_SFP_PID_NOT_SUPPORTED: Not supported Product ID

Красный светодиод порта, интерфейс down, состояние сообщается как потеря линка или слабый сигнал без loopback, длина волны читается как 0 нм, лазер вообще не включается. transceiver permit pid all на интерфейсе сам по себе ничего не менял, и глобальная service unsupported-transceiver поверх тоже не спасла эту партию. Платформа ожидает партномер в форме DWDM-SFP10G-xx.yy из своей собственной матрицы оптики, а обобщённый PID не отображается ни на одну поддерживаемую оптику, так что обходу просто нечего ослаблять.

У кого-то другого на том же релизе модули Skylane SPDTU080100D139 80 км работали на 9001 - но только с обеими командами настроенными, иначе интерфейс не восстанавливался после скачка линка. Отказавшую партию в итоге заменили на правильно закодированные модули.

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

Пока модули у них на стенде, попросите подтвердить, что EEPROM строго соответствует SFF-8472. Небрежные данные A2h читаются как бессмыслица - упомянутая выше длина волны 0 нм именно такого рода, - и как только считывание станет чистым, а платформа всё равно откажет деталь, у вас будет что-то конкретное для поддержки вендора вместо общего спора о сторонней оптике.