Что Catalyst 2960X считает в дампе SFP: код вендора, имя и MD5, и почему копия дампа не проходит
Обслуживаю сеть провайдера, парк модулей смешанный, поэтому регулярно приходится готовить модули под конкретные коммутаторы. Хочу наконец понять механику проверки, а не подбирать дампы наугад.
Чем оперирую:
- Cisco Catalyst 2960X-24PS-L, самый придирчивый в парке
- QTECH QSW-3750-28TX-AC и D-Link DGS-3420, на них те же модули встают спокойно
- модули SNR-SFP+SR и SFP-10G-BX
В дампе модуля, который на Catalyst принимается, в начале вижу байт кода вендора и следом имя в ASCII:
0E 43 49 53 43 4F ...Что пробовал: снял дамп с модуля, который на C2960X-24PS-L поднимается, и переписал в другой модуль только имя вендора из этого дампа. На QTECH и D-Link после этого всё поднимается, а Catalyst такой модуль не принимает, хотя правленые байты совпадают с донором один в один.
Отсюда вопрос по устройству проверки. Что именно Cisco считает и по каким байтам, где в модуле лежит результат и почему переписанного из рабочего дампа имени вендора для этого мало? Мне важна логика, дальше сам разберусь.
Comments 6
Механика там простая и давно разобрана. Проверяется не отдельное поле, а связка: байт кода вендора плюс байты имени вендора. От этой последовательности берётся MD5, и результат лежит в самом модуле, коммутатор считает то же самое и сравнивает.
Воспроизводится штатными утилитами, ничего специального не нужно:
Подставляешь свой код и своё имя вендора и получаешь то значение, которое должно лежать в модуле. Из кодов, которые реально встречаются в дампах: 02 - Finisar, 0E - Methode, 11 попадается регулярно, но чей он, так и не опознали. Если пара код-имя согласована и хэш ей соответствует, модуль на C2960X-24PS-L проходит.
К предыдущему: покажи, что у тебя реально лежит в приёмнике. Какой байт кода вендора там остался и какое имя стоит рядом? Судя по описанию, ты перенёс имя, а код или сам хэш оставил от родного модуля, и тогда связка разъезжается, а Catalyst её отбивает совершенно законно. Проверяй все три вещи сраззу, а не только то поле, которое видно в выводе коммутатора.
Проверил, всё сходится с вашей версией. В доноре 0E и дальше CISCO, а в приёмнике имя я действительно переписал, но код вендора остался родной, и хэш тоже старый. Прогнал обе комбинации через xxd -r -p и md5sum: у донора значение совпадает с тем, что лежит в модуле, у моего собранного вручуню нет.
То есть переносить надо связку целиком, а не по одному полю. Теперь хотя бы понятно, куда смотреть и что сверять перед тем, как ставить модуль в порт.
Важное следствие, о котором постоянно забывают: если код вендора и имя не согласованы, модуль не пройдёт на Catalyst даже тогда, когда на коммутаторе разрешены неподдерживаемые модули. Именно поэтому чужие дампы работают через раз - их правили частично, а проверка смотрит на связку.
Отсюда практический вывод по объёму: в 256-байтном дампе значимы первые 128 байт, дальше идёт зона производителя. Весь образ тащить незачем, а вот первую половину надо переносить согласованно, включая поля, которые глазами в выводе коммутатора не видны.
Кстати, дампом решается не всё. В Medick SFP-10G-BX сидит не память, а микроконтроллер C8051F392: он эмулирует A0 и A2 и вполне может держать пароль или вендорский запрос. Там хоть до байта сверяй связку - снаружи её просто не примут. Из живого инструмента у меня в ходу SNR SFP Writer и SFPTotal Plus, у коллег ещё самоделки на CH341.
Небольшая поправка, чтобы не путать людей, которые придут сюда позже. Этот MD5 не имеет никакого отношения к контрольным суммам MSA: CC_BASE и CC_EXT из SFF-8472 считаются простым сложением байт и пересчитываются на раз. Вендорская проверка жиёт поверх них и по своим правилам, и отбивает модуль ровно в тот момент, когда с MSA-суммами всё в порядке, - отсюда и ощущение, что дамп правильный, а модуль всё равно не принят.
Cisco здесь, к слову, далеко не хуудший случай: механика хотя бы понятна и воспроизводима. Тяжелее всего HP и Aruba, где память ведёт себя интерактивно и требует ключей - вот там дампами уже не отделаешься.