Huawei CE6800 100GE-uplink naar een Profitap XX-3200G komt met SR4-optiek nooit op
Ik vervang het bestaande aggregatiekoppel van een klant door CloudEngine-apparatuur, en de ene link die weigert op te komen is de 100GE-feed naar hun packet broker. Al het andere op de switch ging er probleemloos in.
- Huawei CloudEngine 6800, 100GE-poort
- 100GBASE-SR4 QSFP28-modules, Huawei-onderdelen, één aan elk uiteinde
- Profitap XX-3200G packet broker aan de andere kant
Beide kanten zien hun module. In het switchlog staat niets behalve transceiver-insert- en -removemeldingen van toen ik dingen aan het herplaatsen was, geen enkel alarm, en de interface blijft gewoon down:
<CE6800> display interface 100GE1/0/1
...
FEC : RS-FECAl geprobeerd:
- beide modules vervangen door reserve-exemplaren en de MPO-uiteinden gereinigd, geen verandering;
- de link naar een andere 100GE-poort op de switch verplaatst;
- de brokerkant gecontroleerd, die detecteert zijn module en meldt niets verkeerd.
De optiek wordt dus aan beide kanten herkend, niets klaagt, en er is geen link. Wat moet er nog meer overeenkomen tussen een CloudEngine-100GE-poort en een third-party-doos voordat de link traint?
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
Dit is een FEC-mismatch. CloudEngine zet RS-FEC standaard aan op 100GE-poorten met SR4-optiek, de broker heeft geen FEC-instelling en draait dus zonder, en twee kanten die het oneens zijn over FEC maken het trainen nooit af. Er is niets kapot, dus er wordt niets gelogd, en daarom staan in het log alleen je insert- en removemeldingen.
Zet het uit op de switch, in de interface-view:
undo fec modedoet hetzelfde. De tweede regel is degene die telt. CE werkt met tweetrapsconfiguratie, en een niet-gecommittefec mode noneziet er bij het terugkijken van de config volkomen correct uit terwijl de poort precies even down blijft als daarvoor. Ik heb meegemaakt dat een klantcase daardoor een dag langer liep, met iedereen ervan overtuigd dat FEC al uitstond.Na de commit zou
display interfaceFEC: NONE moeten tonen en zou de poort moeten trainen.Als de andere kant ooit wel een FEC-instelling krijgt, is de betere oplossing om daar RS-FEC aan te zetten en de switch op zijn standaard te laten staan, want op 100G wil je die correctie juist wel. Tussen twee verschillende vendors zou ik FEC expliciet aan beide kanten instellen in plaats van erop te vertrouwen dat het onderhandeld wordt.
Wat zegt de broker aan zijn kant over FEC, als hij daar überhaupt iets over zegt? Je hebt de interessante helft zelf al gepost: de switchpoort draait RS-FEC. Huawei is expliciet dat beide kanten van een 100GE-link dezelfde FEC-modus moeten gebruiken, anders komen de interfaces nooit op, en die storing ziet er precies zo uit als bij jou: beide modules gezond, geen alarm, geen log, poort down.
De meeste packet brokers en taps waar ik mee gewerkt heb, bieden helemaal geen FEC-knop, wat betekent dat ze zonder draaien en dat de switch de kant is die moet toegeven. Bevestig dat eerst, verander dan één ding.
Het is de moeite waard om toe te voegen dat de CloudEngine-standaard geen vaste waarde is, het hangt af van de module. QSFP28-100G-LR4 en QSFP28-100G-LR1 draaien met FEC uit volgens IEEE 802.3, terwijl alle andere QSFP28-types standaard FEC aan hebben. Het advies om het gewoon uit te zetten is dus fout op een LR4-link, waar de switch al uitstaat en de mismatch aan de andere kant zit.
Nog twee regels uit hetzelfde hoofdstuk waar ik zelf in getrapt ben:
Kijk dus met
display transceiver interface 100GE1/0/1 verbosewat je daadwerkelijk in handen hebt voordat je beslist welke kant op je FEC duwt, en denk hoe dan ook aan de commit.