Third-party SFP+ optics blijven down op een tweedehands DCS-7150S-24: is het enable3px flash-bestand nog een optie?
Ik heb een paar tweedehands Arista switches voor het lab opgehaald en liep meteen tegen de optics gate aan. Arista-gecodeerde modules linken op, passieve DAC-kabels linken op, en alles wat third-party is laat de poort down.
De labkant:
- DCS-7150S-24, tweedehands gekocht, geen supportcontract en geen accountteam achter me
- diverse third-party SFP+ modules
- passieve DAC-kabels voor de korte runs binnen het rack
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes upWat ik tot nu toe heb uitgevogeld:
- de DAC die opkomt terwijl optics dat niet doen vertelt me dat dit een coding check is, geen bekabeling en geen dode cage
- er is een configuratiecommando van de vorm
service unsupported-transceiver CUSTOMERNAME LICENSEKEY, dat uiteraard een key wil die ik nergens vandaan kan halen - oudere write-ups noemen een markerbestand op flash in plaats van een key, maar ik kan niet zeggen voor welke generatie dat geldt
Welk van de twee mechanismes is het voor een box van deze leeftijd, en is het flash-bestand nog een optie op een 7150S, of is de key de enige route die overblijft?
Comments 6
Bij die generatie is het het bestand, en het is net zo bot als het klinkt. Vanuit de EOS CLI:
Een leeg bestand, niets erin - alleen al de aanwezigheid ervan schakelt third-party optics in na de reload. De lijst met platformen waar dit werkt is lang: DCS-7120T-4S, de DCS-7050 familie en de hele DCS-7150S lijn onder andere, en elk model heeft een nieuwste EOS release die het bestand nog honoreert, ruwweg van 4.13.16M op de oudste boxen tot de 4.23 train op de 7150S. Nieuwere switches negeren het bestand volledig.
Een 7150S-24 zit dus aan de goede kant van die grens, mits je niet verder bent gegaan dan wat het model ondersteunt. Probeer dit voordat je ook maar in de buurt van de key-route komt.
Welke EOS train draait er op die 7150S-24, en heb je die geüpgraded nadat je hem kocht? Dat maakt uit, want de cut-off geldt per platform en niet per familie. Het flag-bestand staat gedocumenteerd als werkend op de 7048T, de 7120T-4S, de 7140T-8S, de 7124 en 7148 SFP+ varianten, de 7050 en 7150S series en de 7548S-LC line cards, maar de laatste EOS release die het nog honoreert verschilt per model.
Als je EOS op een tweedehands box al hebt geüpgraded, is er een reële kans dat je jezelf uit de truc hebt geüpgraded, en dan is de goedkope fix teruggaan naar een oudere train in plaats van op een key te jagen.
EOS nooit aangeraakt sinds de box aankwam, dus hij staat nog op welke train de verkoper er ook op had laten staan - wat achteraf geluk bleek. De touch, write memory, reload gedaan - en de third-party SFP+ modules die eerst dood waren komen nu op als gewone poorten. Geen key, geen accountteam, verder niets nodig. De DACs bleven de hele tijd gewoon werken, zoals verwacht.
Voor iedereen die hier terechtkomt met een nieuwere box: het bestand wordt daar echt genegeerd, en de enige weg is een per-klant cryptografische key die in de running configuration staat als
De key komt van het account- of salesteam, niet van support - TAC is niet bevoegd om unlock keys uit te geven en stuurt je terug naar account management, wat een doodlopende weg is als de switch van de tweedehands markt komt.
De moeite waard om te herhalen voor labopstellingen: passieve DAC-kabels worden standaard geaccepteerd ongeacht de unlock-status. Als de runs kort genoeg zijn, kun je de hele kwestie omzeilen door met DAC te bekabelen en de optics te bewaren voor de links die ze echt nodig hebben.
Kleine correctie op "staat in de running configuration": in de oudere code waar ik mee werkte was er ook een ongedocumenteerde variant van hetzelfde commando, dus als je een verwijzing tegenkomt die niet met de syntax hierboven overeenkomt, komt dat daarvandaan en niet van iemand die zich vertypt heeft.
In mijn ervaring werkte de key ook zonder reboot - de meeste third-party optics begonnen meteen te werken nadat het commando was ingevoerd, al bleven een paar modules hoe dan ook weigeren. Dat was een tijd terug op hardware die ik niet meer heb, dus check het op je eigen box voordat je er een onderhoudsvenster omheen plant.
Omdat deze vergelijking elke keer terugkomt als het onderwerp opduikt: op Cisco IOS-XE en IOS XR is het equivalent twee stappen in plaats van één. Het globale commando alleen is niet genoeg, je hebt ook het per-interface commando nodig op elke fysieke poort die de module moet accepteren:
De per-interface regel is degene die de product-ID check overslaat, dus de poort probeert dan tenminste de optic te laten branden - geen garantie dat de module daarna werkt, alleen dat het platform hem niet meer weigert. Ik heb het gedaan op IOS XR 5.3.3 en op IOS-XE boxen.
Het voorbehoud is bij beide vendors hetzelfde, en het is de reden dat mensen hier steeds over blijven discussiëren: als een storing herleid wordt naar een door de klant geïnstalleerde third-party transceiver, kan support onder garantie of contract worden geweigerd. Prima voor een lab, een beslissing die je in productie bewust moet nemen.