EX4200 сообщает о неверно прошитой EEPROM SFP+ после обновления Junos, тогда как MX960 по-прежнему показывает DOM
У нас работает несколько DWDM-линий на 80 км через EX4200 со сторонней оптикой на обоих концах, потому что фирменные компоненты DWDM в бюджет никогда бы не вписались. Годами всё было в порядке. После перевода коробок EX на Junos 12.3 оптика по-прежнему стоит в тех же портах, и линии по-прежнему существуют, но коммутатор перестал признавать, что модули вообще являются оптикой.
- EX4200, Junos 12.3 (DOM отлично работал на 11.4 в том же шасси)
- Integra SFPP-C51-80-10GD, DWDM SFP+ на 80 км
- MX960 на дальнем конце той же линии, идентичный партномер, DOM по-прежнему полный
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableЛог messages при установке модуля выводит ровно одну строку: SFP+ of type 0 EEPROM is Mis Programmed.
Что я уже исключил:
- переустановил оптику и переставил её в другой порт того же шасси - без изменений;
- попробовал запасной EX3300 и QFX5100 в лаборатории, оба ведут себя так же, значит дело не в одной сломанной коробке;
- ещё раз проверил дальний конец - MX960 выдаёт полную диагностику для того же партномера из того же заказа.
То есть драйвер EX проверяет что-то в EEPROM, что старая версия просто игнорировала? И если так, можно ли что-то сделать с самой оптикой, или это разговор, который нужно вести с поставщиком?
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 6
Эта строка в логе - не общая жалоба, это драйвер, который прямо говорит, какая проверка не прошла.
Байты 3-10 страницы A0 хранят коды compliance трансивера, описанные в SFF-8472 - биты, которые говорят 10GBASE-SR, LR, ER, коды SONET, коды Fibre Channel и так далее. На этой оптике все восемь байт нулевые, поэтому в сообщении и указан тип 0. Спецификация ожидает, что хотя бы один бит где-то в этом поле будет установлен; полностью нулевое поле compliance - недопустимое описание модуля. Старый код EX туда вообще не смотрел и сразу переходил к разбору страницы диагностики, новый драйвер сначала проверяет это поле и затем отказывается считать модуль известной оптикой 10G. Отсюда и unknown cable, и пропавший DOM. На линейке MX эта проверка на том же пути не выполняется, именно поэтому тот же самый партномер там по-прежнему работает.
Прежде чем с кем-то спорить, докажите это: зайдите в shell и выполните xcvrpeek страницы A0 на этом порту, затем посмотрите смещения с 3 по 10. Все нули закрывают вопрос.
Починить это на месте - вот где обычно всё и упирается. В теории xcvrpoke может записать эти же байты обратно. На практике многие вендоры блокируют страницу A0, и запись возвращает EIO, и со стороны коммутатора с этим ничего не поделать. Остаётся только поставщик: либо он поставляет оптику, прошитую реальными кодами compliance, либо поставляет её с разблокированной A0, чтобы вы могли выставить биты сами. Если он не может ни того, ни другого, это проблема поставщика, замаскированная под проблему Junos.
Прежде чем начинать гадать, стоит уточнить две вещи.
Во-первых, точную версию на каждой коробке. Вы говорите, что EX перевели на 12.3, а что запущено на MX960? Если он всё ещё на более старой ветке, то эти две коробки не совсем сравнимы, и разница пока ничего не говорит.
Во-вторых, партномер на стороне MX - это буквально тот же SFPP-C51-80-10GD из той же партии, или та же модель, но из другого заказа? Партии различаются между собой сильнее, чем хотелось бы.
Приведите
show interfaces diagnostics opticsс обеих сторон, а также всё, что печатает лог messages при извлечении и повторной установке оптики, а не только ту одну строку, что вы уже привели.Один и тот же партномер с обеих сторон, SFPP-C51-80-10GD, тот же заказ, последовательные серийники.
На MX960
show interfaces diagnostics opticsвыдаёт полный набор: температура, ток смещения лазера, TX power, RX power. На EX4200 та же команда печатает заголовок интерфейса, а затем строку unknown cable, и больше ничего. Повторная установка оптики даёт в логеSFP+ of type 0 EEPROM is Mis Programmedи ничего сверх этого, каким бы портом я ни пользовался.Меня беспокоит то, что до обновления эта самая оптика в этом самом шасси и порту сообщала DOM без единой жалобы.
Стоит добавить, что режим "только для чтения" в этом деле есть и по другую сторону забора. У Cisco
show idprom interface <if> detailвыводит байты идентификации вообще без гимнастики с shell, что удобно для проверки партии на запасном коммутаторе, прежде чем модули хоть немного приблизятся к коробке Juniper.Чтение безопасно везде. Запись со стороны хоста - совсем другое дело: xcvrpoke - это внутренний инструмент, он не поддерживается как способ починки модулей, и, как уже отмечалось, примерно в половине случаев его всё равно блокирует привязка к вендору. Используйте его, чтобы доказать, что не так с EEPROM, а затем передайте это доказательство тому, у кого вы купили оптику.
Тот же класс проблемы, совершенно другой симптом - на случай, если кто-то попадёт сюда через поиск.
Мы поставили безымянный SFP 1G BiDi WDM в ge-0/0/1 коммутатора EX4600, и интерфейс просто не существовал. Отсутствовал в
show interfaces terse, а любая команда к нему возвращалаerror: device ge-0/0/1 not found. В логе было написаноOPTIC State changed for port: 0/0/1, а затемFibre channel transceiver plugged in without Fibre channel configuration!!. EEPROM была закодирована так, что Junos классифицировал модуль как трансивер Fibre Channel, а не Gigabit Ethernet, поэтому интерфейс Ethernet для него так и не создавался. Никакая настройка это не исправит; исправит только правильно закодированный модуль.И это касается не только дешёвого сегмента рынка. Была партия SFP+ 10G под маркой Citrix, из-за которой устройства NetScaler MPX и SDX писали в лог при загрузке
*** Unsupported SFP+/SFP type !даже на фирменных модулях самого вендора. У исправных экземпляров на этикетке есть отметка ревизии A2, бракованные ушли по RMA. Плохая кодировка встречается на любом ценовом уровне.Подтверждаю, и спасибо за точные смещения.
xcvrpeek на странице A0 показывает смещения с 3 по 10 нулевыми на каждом из этих модулей SFPP-C51-80-10GD, что я проверил, включая те, что ещё в коробках. xcvrpoke сразу же возвращает EIO, значит A0 заблокирована и спасти на нашей стороне нечего.
Вернулся к поставщику со смещениями байт и приведённой строкой из лога. Они это приняли и перекодируют партию с настоящими кодами compliance; те, что стоят в MX960, останутся как есть, поскольку на этой платформе никто не жалуется. Отмечаю объяснение выше как ответ.