Was der Catalyst 2960X im SFP-Dump berechnet: Vendor-Code, Name und MD5, und warum eine kopierte Dump-Datei nicht durchkommt
Ich betreue das Netz eines Providers, der Modulpark ist gemischt, deshalb muss ich regelmäßig Module für konkrete Switches vorbereiten. Ich will endlich die Mechanik der Prüfung verstehen, statt Dumps auf gut Glück zusammenzubasteln.
Womit ich arbeite:
- Cisco Catalyst 2960X-24PS-L, der wählerischste im Park
- QTECH QSW-3750-28TX-AC und D-Link DGS-3420, bei denen dieselben Module ohne Murren hochkommen
- Module SNR-SFP+SR und SFP-10G-BX
Im Dump eines Moduls, das der Catalyst akzeptiert, sehe ich am Anfang das Byte des Vendor-Codes und direkt danach den Namen in ASCII:
0E 43 49 53 43 4F ...Was ich probiert habe: einen Dump von einem Modul gezogen, das am C2960X-24PS-L hochkommt, und in ein anderes Modul nur den Vendor-Namen aus diesem Dump zurückgeschrieben. Bei QTECH und D-Link kommt danach alles hoch, aber der Catalyst akzeptiert dieses Modul nicht, obwohl die geänderten Bytes eins zu eins mit dem Spendermodul übereinstimmen.
Daher die Frage zur Funktionsweise der Prüfung. Was genau berechnet Cisco und über welche Bytes, wo im Modul liegt das Ergebnis, und warum reicht dafür ein aus einem funktionierenden Dump übernommener Vendor-Name nicht? Mir geht es um die Logik, den Rest finde ich selbst raus.
Comments 6
Die Mechanik dahinter ist simpel und längst durchleuchtet. Geprüft wird nicht ein einzelnes Feld, sondern eine Kombination: das Byte des Vendor-Codes plus die Bytes des Vendor-Namens. Aus dieser Sequenz wird ein MD5 gebildet, das Ergebnis liegt im Modul selbst, der Switch berechnet dasselbe und vergleicht.
Reproduzierbar mit Bordmitteln, nichts Spezielles nötig:
Du setzt deinen Code und deinen Vendor-Namen ein und bekommst den Wert, der im Modul liegen muss. Von den Codes, die in Dumps tatsächlich vorkommen: 02 - Finisar, 0E - Methode, 11 taucht regelmäßig auf, aber wem er gehört, wurde nie geklärt. Wenn das Paar Code-Name zusammenpasst und der Hash dazu passt, kommt das Modul am C2960X-24PS-L durch.
Zum vorigen Punkt: zeig, was bei dir im Empfängermodul tatsächlich drinsteht. Welches Byte des Vendor-Codes ist dort geblieben, und welcher Name steht daneben? Nach der Beschreibung hast du den Namen übertragen, aber Code oder Hash vom Originalmodul gelassen, und dann geht die Kombination auseinander, und der Catalyst weist sie völlig zu Recht zurück. Prüfe alle drei Dinge auf einmal, nicht nur das Feld, das im Switch-Output sichtbar ist.
Geprüft, alles stimmt mit eurer Version überein. Im Spender steht 0E und danach CISCO, im Empfänger habe ich tatsächlich den Namen umgeschrieben, aber der Vendor-Code ist original geblieben, und der Hash auch der alte. Beide Kombinationen durch xxd -r -p und md5sum gejagt: beim Spender stimmt der Wert mit dem überein, was im Modul liegt, bei meinem von Hand zusammengebauten nicht.
Das heißt, man muss die Kombination als Ganzes übertragen, nicht Feld für Feld. Jetzt ist wenigstens klar, wohin man schauen und was man abgleichen muss, bevor man das Modul in den Port steckt.
Eine wichtige Folge, die ständig vergessen wird: wenn Vendor-Code und Name nicht zusammenpassen, kommt das Modul am Catalyst auch dann nicht durch, wenn am Switch nicht unterstützte Module erlaubt sind. Genau deshalb funktionieren fremde Dumps nur jedes zweite Mal - sie wurden teilweise angepasst, und die Prüfung schaut auf die Kombination.
Daraus folgt praktisch etwas zum Umfang: im 256-Byte-Dump sind die ersten 128 Byte relevant, danach kommt die Herstellerzone. Das ganze Image mitzuschleppen ist unnötig, aber die erste Hälfte muss konsistent übertragen werden, einschließlich der Felder, die man im Switch-Output nicht mit bloßem Auge sieht.
Übrigens löst der Dump nicht alles. Im Medick SFP-10G-BX sitzt kein Speicher, sondern ein Mikrocontroller C8051F392: er emuliert A0 und A2 und kann durchaus ein Passwort oder eine Vendor-Abfrage verlangen. Da kannst du die Kombination bis aufs Byte abgleichen - von außen wird sie trotzdem nicht angenommen. An lebendigem Werkzeug habe ich SNR SFP Writer und SFPTotal Plus im Einsatz, bei Kollegen laufen noch Marke-Eigenbau-Lösungen auf CH341.
Eine kleine Korrektur, damit später niemand durcheinanderkommt. Dieses MD5 hat nichts mit den MSA-Prüfsummen zu tun: CC_BASE und CC_EXT aus SFF-8472 werden durch einfache Byte-Addition gebildet und lassen sich im Handumdrehen neu berechnen. Die Vendor-Prüfung lebt oberhalb davon und nach eigenen Regeln und weist das Modul genau in dem Moment zurück, in dem mit den MSA-Summen alles in Ordnung ist - daher der Eindruck, der Dump sei korrekt und das Modul werde trotzdem nicht akzeptiert.
Cisco ist hier übrigens bei weitem nicht der schlimmste Fall: die Mechanik ist wenigstens verständlich und reproduzierbar. Am schwersten sind HP und Aruba, wo sich der Speicher interaktiv verhält und Schlüssel verlangt - da kommt man mit Dumps allein nicht mehr weiter.