Huawei-CE6800-100GE-Uplink zum Profitap XX-3200G kommt mit SR4-Optik nie hoch
Wir ersetzen das bestehende Aggregation-Paar eines Kunden durch CloudEngine-Technik, und der einzige Link, der sich weigert hochzukommen, ist die 100GE-Zuführung zu deren Packet-Broker. Alles andere am Switch ging ohne Drama rein.
- Huawei CloudEngine 6800, 100GE-Port
- 100GBASE-SR4-QSFP28-Module, Huawei-Teile, je eines an jedem Ende
- Profitap XX-3200G Packet Broker auf der Gegenseite
Beide Enden sehen ihr Modul. Im Switch-Log stehen nur Transceiver-Insert- und -Remove-Einträge von meinem eigenen Umstecken, keinerlei Alarme, und das Interface bleibt einfach down:
<CE6800> display interface 100GE1/0/1
...
FEC : RS-FECBisher versucht:
- beide Module gegen Ersatzteile getauscht und die MPO-Enden gereinigt, keine Änderung;
- den Link auf einen anderen 100GE-Port am Switch verlegt;
- die Broker-Seite geprüft, sie erkennt ihr Modul und meldet nichts Auffälliges.
Die Optiken werden also auf beiden Seiten erkannt, nichts beschwert sich, und es gibt keinen Link. Was muss zwischen einem CloudEngine-100GE-Port und einer Drittanbieter-Box noch übereinstimmen, damit der Link trainiert?
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 3
Das ist ein FEC-Mismatch. CloudEngine aktiviert RS-FEC standardmäßig auf 100GE-Ports mit SR4-Optik, der Broker hat keine FEC-Einstellung und läuft deshalb ohne, und zwei Enden, die sich bei FEC nicht einig sind, trainieren nie fertig. Da nichts kaputt ist, wird auch nichts geloggt, deshalb stehen im Log nur deine Insert- und Remove-Meldungen.
Am Switch abschalten, in der Interface-Ansicht:
undo fec modemacht dasselbe. Die zweite Zeile ist die, auf die es ankommt. CE ist zweistufig konfiguriert, und ein nicht committetesfec mode nonesieht beim Zurücklesen der Config völlig korrekt aus, während der Port exakt so down bleibt wie vorher. Ich habe schon einen Kundenfall erlebt, der deswegen einen Tag länger lief, weil alle überzeugt waren, FEC sei bereits deaktiviert.Nach dem Commit sollte
display interfaceFEC: NONE zeigen, und der Port sollte trainieren.Falls die Gegenseite irgendwann doch eine FEC-Einstellung bekommt, ist die bessere Lösung, dort RS-FEC zu aktivieren und den Switch auf seinem Standard zu lassen, denn bei 100G will man die Korrektur eigentlich haben. Zwischen zwei unterschiedlichen Herstellern würde ich FEC auf beiden Seiten explizit setzen, statt irgendetwas dem Aushandeln zu überlassen.
Was sagt der Broker auf seiner Seite zu FEC, falls er überhaupt etwas dazu sagt? Die interessante Hälfte hast du selbst schon gepostet: Der Switch-Port läuft mit RS-FEC. Huawei sagt ausdrücklich, dass beide Enden eines 100GE-Links denselben FEC-Modus verwenden müssen, sonst kommen die Interfaces nie hoch, und genau dieser Fehler sieht so aus wie bei dir: beide Module gesund, kein Alarm, kein Log, Port down.
Die meisten Packet-Broker und Taps, mit denen ich gearbeitet habe, bieten gar keinen FEC-Schalter, was heißt, dass sie ohne laufen und der Switch die Seite ist, die nachgeben muss. Das zuerst bestätigen, dann eine Sache ändern.
Ergänzend: Der CloudEngine-Default ist kein einzelner Wert, er hängt vom Modul ab. QSFP28-100G-LR4 und QSFP28-100G-LR1 laufen laut IEEE 802.3 mit FEC aus, während alle anderen QSFP28-Typen standardmäßig FEC an haben. Der Rat, es einfach zu deaktivieren, ist also bei einem LR4-Link falsch, wo der Switch schon aus ist und der Mismatch auf der anderen Seite liegt.
Noch zwei Regeln aus demselben Kapitel, die mich schon erwischt haben:
Also mit
display transceiver interface 100GE1/0/1 verboseerst prüfen, was man da tatsächlich in der Hand hat, bevor man entscheidet, in welche Richtung man FEC schiebt, und in jedem Fall an den Commit denken.