Ошибки на портe 9 с оптическим SFP

[san]

Дефект проявляется на всех сочетаниях оптических модулей/патчкордов/плат SW-01 которые пробовали (порядка 10 плат SW-01). Эти же модули и патчкорды работают без ошибок при установке в GE-12.

Схема - две sw-01 включённые друг на друга через оптику(SFP 10-nb километровые). При включении питания иногда одна или обе sw-01 начинают регистрировать ошибки badcrc/Frag/Collisions по приёму. Ошибок достаточно много, пропорционально трафику.

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

С медными sfp такого не наблюдается

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

Как выглядят ошибки можно посмотреть на стенде:
Блоки 192.168.20.111 и 192.168.20.160 соединены полутораметровым оптическим патчкордом.

[alx]

Ты считаешь, что ошибки ложные?

[alx]

Понаблюдал за поведением счетчика ошибок, отображаемого в веб-интерфейсе. Отображаемое значение монотонно увеличивается с течением времени мелкими шагами.

Программа платы SW-01 сама подсчетом ошибок не занимается. В данном контексте все, что делает программа - это читает значение счетчиков из коммутатора ethernet и передает прочитанные значения для отображения веб-интерфейсу. Если бы в программе имел место баг (например значение счетчика искажалось при чтении из регистра коммутатора), было бы логично ожидать более хаотичное поведение отображаемых значений - значения бы прыгали вперед и назад, время от времени были очень большими и т.п (кстати, подобный баг когда-то действительно был). Ничего подобного сейчас не наблюдается. Я предполагаю, что значения счетчиков отображаются верно, то есть коммутатор действительно фиксирует ошибки.

[alx]

Replying to san:

Как выглядят ошибки можно посмотреть на стенде:
Блоки 192.168.20.111 и 192.168.20.160 соединены полутораметровым оптическим патчкордом.

Из переписки в Telegram по данной проблеме я узнал некоторые дополнительные детали, не указанные в описании тикета. А зря, так как это может быть причиной проблемы. Во-первых, в качестве линейного тракта используется одномодовое волокно. Во-вторых, в линейном тракте установлен оптический аттенюатор.

Полтора метра - очень маленькая длина для одномодового кабеля. При такой длине паразитные моды не успевают затухнуть, и при использовании аттенюатора (который представляет собой просто зазор между входным и выходным волокнами) создают интерференционную картину, что делает величину затухания непредсказуемой и нестабильной. Такой короткий кабель не может использоваться с аттенюатором. С подобной проблемой я когда-то сталкивался, работая в Интеллектронике, и выше приведенное объяснение - со слов специалиста по ВОЛС, который нам помог консультацией. Для подобной схемы соединения длина патчкорда должна составлять не менее 30-50 метров. И аттенюатор, конечно же, должен устанавливаться на входе, а не на выходе (уточняю на всякий случай, так как не знаю, где он установлен сейчас).

[alx]

Replying to san:

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

Во-первых, не уточняется, использовался ли с платой GE-12 аттенюатор, или только патчкорды.

Во-вторых, откуда известно, что плата работала без ошибок, если в ней нет счетчиков ошибок (по крайней мере, ошибки не отображаются в веб-интерфейсе платы)? В веб-интерфейсе отображаются только счетчики "AS" и "UAS", которые, согласно Руководству по эксплуатации, отображают время, в течение которого интерфейс был в рабочем состоянии и был недоступен соответственно. Что значит "в рабочем состоянии" и "недоступен", в руководстве не уточняется. Таким образом, имеющиеся в плате счетчики ничего не говорят о наличии или отсутствии ошибок CRC.

В-третьих, насколько я знаю, оптический интерфейс платы GE-12 вообще не является интерфейсом ethernet. Это какой-то проприетарный интерфейс. Лично мне вообще неизвестно есть ли там вообще контроль CRC. Вполне может быть, что ошибок CRC там не может быть в принципе - в виду отсутствия CRC... Таким образом, отсутствие ошибок не говорит о том, что линейный тракт работает хорошо.

[san]

Ты считаешь, что ошибки ложные?

Нет, ошибки действительно есть. Я пропускаю некоторый трафик через это соединение и часть пакетов пропадает.

во-вторых, в линейном тракте установлен оптический аттенюатор.

Сейчас без аттенюатора включено

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

Внешними средствами проверяли что трафик проходит.

[san]

Я предполагаю, что проблема не в оптическом сигнале, т.к. проблема всегда устраняется блокировкой/разблокировкой порта и больше не воспроизводится никогда пока не выключишь-включишь питание платы.

[alx]

Replying to san:

Ты считаешь, что ошибки ложные?

Нет, ошибки действительно есть.

Тогда непонятно, что ты считаешь багом. Если ошибки есть, и аппаратура их отображает - значит все работает так, как должно. Что, в таком случае, ты ожидаешь, чтобы я сделал? В описании тикета никаких конкретных предложений нет...

во-вторых, в линейном тракте установлен оптический аттенюатор.

Сейчас без аттенюатора включено

О, это существенное уточнение!

[san]

Тогда непонятно, что ты считаешь багом

Предпосылок для возникновения ошибок нет, однако ошибки есть.

То что этот баг устраняется "програмно" (блокировкой/разблокировкой) наводит на мысль о том что и сам баг тоже программный.

Прямо сейчас можно сделать "обходной путь" - дёргать линком порта при включении платы и это решит проблему, насколько я вижу. Но хотелось бы найти и устранить саму причину.

[alx]

Replying to san:

То что этот баг устраняется "програмно" (блокировкой/разблокировкой) наводит на мысль о том что и сам баг тоже программный.

Спасибо за пояснение, теперь мысль понятна. Это, как мне кажется, нетрудно проверить, просто остановив программу командой killall -9 swd (предварительно запустив ее с -w чтобы watchdog не сработал). Если ошибки не прекратятся - значит это не программный баг.

Прошу провести такой эксперимент.

[san]

Не думаю что убийство swd прекратит ошибки)
Я имел в виду что какая-то особенность инициализации порта или модуля SFP возможно приводит к такому состоянию порта или модуля.

[san]

При перезапуске платы SW-01 кнопочкой перезагрузка в веб-интерфейсе - ошибки также появляются.

[alx]

Replying to san:

Я имел в виду что какая-то особенность инициализации порта или модуля SFP возможно приводит к такому состоянию порта или модуля.

Это по-моему противоречит наблюдаемым фактам: выше ты написал, что ошибки пропадают не только после выключения/включения порта, но и если дернуть линк тоже. А ведь в последнем случае никакой повторной инициализации порта нет, он как работал так и работает... Уточни, пожалуйста, что подразумевается под "дернуть линк".

И еще необъяснимо, почему ошибки возникают только с оптическими SFP, и не возникают с другими устройствами...

А точно ли установлено, что пропадание пакетов коррелирует с отображаемыми ошибками? А то я помню, что при подключении VE-01 отображались какие-то ошибки, но никаких потерь при этом не было...

[san]

что подразумевается под "дернуть линк".

Выдернуть оптический патчкорд и сунуть обратно.

А точно ли установлено, что пропадание пакетов коррелирует с отображаемыми ошибками

Да, точно установлено.

[alx]

При выполнении блокировки/разблокировки порта коммутатора программа изменяет режим работы коммутатора путем записи новых значений в его управляющие регистры. Таким образом, эти функции нельзя считать чисто программными, изолированными от "железа". Следовательно, вывод, сделанный в comment:8, о том, что баг программный, нельзя считать обоснованным.

Так как предложенный мной эксперимент не проведен, и никаких других предложений не поступило, тикет закрываю.