ERS-8600-Faserport ist up mit 1G Vollduplex, aber der Switch lernt darauf keine MAC
Ein physischer Server an unserem ERS 8600 spricht mit niemandem, und der Switch ist völlig überzeugt, dass alles in Ordnung ist. Der Port ist in diesem Zustand, seit der Server von Kupfer auf Faser umgezogen wurde.
- Avaya ERS 8600, Server an einem 1G-SFP-Port in Slot 3, Port 12
- Server-NIC mit eigenem SFP, Faser-Patch über das Gebäudepanel
- Port auf 1 Gbps Vollduplex belassen, nichts Exotisches in der Config
Was der Switch für diesen Port meldet:
Port 3/12: up, 1000 Mbps, full duplex
FCS errors: 0
Port errors: 0
MAC addresses learned on 3/12: noneDer Port trainiert also, bleibt tagelang up, zählt überhaupt keine Fehler, und trotzdem bekommt die Forwarding-Datenbank keine einzige Adresse von ihm. Der Server ist vom Rest des VLANs aus nicht erreichbar.
Was ich versucht habe:
- den Port mehrfach durchgeschaltet, nichts ändert sich
- Flow Control in beide Richtungen umgeschaltet, auch nichts
- die FDB für das Server-VLAN durchgesehen: Adressen von jedem anderen Port, keine einzige von 3/12
- der Server beharrt darauf, sein eigener Link sei mit Gigabit up
Wo würdet ihr als Nächstes suchen, auf der Switch-Seite oder bei der Optik im Server?
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
Dieses Muster - Link up, Vollduplex, saubere Zähler, leere Forwarding-Datenbank - heißt fast immer, dass das ferne Ende zwar Licht auf die Faser bringt, aber keine gültigen Frames. Das Modul im Server ist der erste Verdächtige, nicht die Switch-Konfiguration.
Erst die Switch-Seite ausräumen, damit später niemand dagegen argumentieren kann. In der ERS-8600-Diagnose-Shell
dumpPortStateundpsDump(<port index>)für diesen Port ausführen. Auf den Index achten: Das ist nicht das Slot/Port aus der normalen CLI, sondern Slot * 64 + (Portnummer - 1). Kommen dabei ein gesunder lokaler Port und saubere Zähler zurück, hat der Switch seinen Job gemacht, und der Fehler lebt auf der anderen Seite der Faser.Bevor irgendwas gekauft wird: die Strecke aus der Gleichung nehmen. Diesen Port über ein Ersatzmodul desselben Typs direkt auf sich selbst zurückpatchen, dann messen, was rausgeht und was zurückkommt, und schauen, ob beide Werte dort stabil bleiben, wo das Datenblatt des Moduls es verlangt. Danach das SFP in der Server-NIC tauschen. Im dokumentierten Fall mit diesen Symptomen war das der ganze Fix: Der Switch-Port hielt tagelang den Link, nie kam irgendetwas Brauchbares von der Faser, und Adressen erschienen in dem Moment, in dem das Modul des Servers ersetzt wurde.
Ein Vorbehalt, falls ein nachweislich gutes Modul nichts ändert: Manche Plattformen haben einen Softwarefehler, der genau gleich aussieht. Beim ERS 5900 ist einer dokumentiert: Die 1-Gbps-Uplink-Module gegen 10-Gbps-SFP+ tauschen, und die Links kommen als aktiv hoch, ohne dass irgendetwas darüber geht. Ein späteres Softwarerelease führt ihn als behoben, und ein Port- oder Switch-Reset bringt einen zwischenzeitlich weiter. Hilft der Tausch also nicht, zuerst die Release Notes für den eigenen Code lesen.
Null Fehler zusammen mit null gelernten Adressen ist eine sehr spezifische Kombination, also erst festnageln, welche Richtung wirklich tot ist. Zeigen die Port-Zähler überhaupt empfangene Frames, oder kommt buchstäblich nichts an? Ist die Empfangsseite flach, während die Sendeseite immer weiter steigt, redet der Switch in ein Loch, und eure leere FDB ist ein Symptom und nicht das Problem.
Es lohnt sich auch, alles zu dumpen, was der Switch selbst vom Modul abgreifen konnte. Bei der VSP-7000-Reihe ist das
show interfaces gbic-info, eingegrenzt mitport <port number>, wenn nur einer gewünscht ist, und es sagt, welches Gerät die Box installiert glaubt und ob sie es für unterstützt hält; falls euer ERS-Release ein Äquivalent hat, dessen Ausgabe für 3/12 posten. Und sagen, welches Modul in der Server-NIC steckt, Hersteller und Typ, nicht nur „ein SFP".Bin wie vorgeschlagen in die Diagnose-Shell gegangen. Für Slot 3 Port 12 ergibt sich der Index zu 3 * 64 + 11 = 203, also
psDump(203)plusdumpPortState- lokaler Port gesund, Zähler sauber, auf dem Switch überhaupt nichts falsch, genau wie vorhergesagt.Also habe ich das SFP aus der Server-NIC gezogen und ein Ersatzteil desselben Typs eingesetzt. Die MAC-Adresse stand in der Forwarding-Datenbank, bevor ich wieder an meinem Schreibtisch war, und der Server ist seitdem durchgehend erreichbar. Ein totes Modul auf der Serverseite, das immer noch genug Licht produzierte, um den Port hochzubringen und oben zu halten. Danke, ich hätte sonst noch einen Tag mit erneutem Lesen der Switch-Config verbracht.