10
HP Procurve Log Meldung : RMON PARITY ERROR RECOVERY
Hallo zusammen,
ich suche seit ein paar Tagen was die u.g Log Meldung bedeutet:
Hintergrund: Wir hatten letzte Woche im Netzwerk einige "Performance" Probleme, die wir nicht so richtig identifizieren könnten. Beim Troubleshooting bin ich auf die folgende Log Meldung gestoßen:
W 03/08/14 11:48:54 00995 system: Module B 9747527 parity recoveries in previous
W 03/09/14 11:48:55 00995 system: Module B 9752621 parity recoveries in previous
W 03/10/14 11:48:55 00995 system: Module B 9756298 parity recoveries in previous
W 03/11/14 11:48:55 00995 system: Module B 9765975 parity recoveries in previous
W 03/12/14 11:48:55 00995 system: Module B 9754116 parity recoveries in previous
W 03/13/14 11:48:55 00995 system: Module B 9748349 parity recoveries in previous
W 03/14/14 11:48:55 00995 system: Module B 9755338 parity recoveries in previous
W 03/15/14 11:48:56 00995 system: Module B 9749489 parity recoveries in previous
W 03/16/14 11:48:56 00995 system: Module B 9748026 parity recoveries in previous
W 03/17/14 11:48:56 00995 system: Module B 9750663 parity recoveries in previous 24 hours
W 03/18/14 11:48:56 00995 system: Module B 9748221 parity recoveries in previous 24 hours
W 03/19/14 11:48:56 00995 system: Module B 9747020 parity recoveries in previous 24 hours
W 03/20/14 11:48:56 00995 system: Module B 9747933 parity recoveries in previous 24 hours
W 03/21/14 11:48:57 00995 system: Module B 9751132 parity recoveries in previous 24 hours
W 03/22/14 11:48:57 00995 system: Module B 9753547 parity recoveries in previous 24 hours
W 03/23/14 11:48:57 00995 system: Module B 9754983 parity recoveries in previous 24 hours
SW01#
Ich habe folgendes auf der HP Seite (HP Switch Software June 2013 Event Log Message Reference Guide)
bezüglich des „parity recovery error“ gefunden:
994
system: <module| port> <id> <number> parity error recoveries
in previous <interval>
warning Logs the number of successful recoveries that occurred during
the interval: 5 minutes, 1 hour, 24 hours. This reduces the number
of system log events when many recoveries happen close in time.
RMON_PARITY_ERROR_RECOVERY
Leider kann ich das nicht so richtig interpretieren.
Habt ihr eine Idee, was das bedeutet kann?
Vielen Dank!
aguila
ich suche seit ein paar Tagen was die u.g Log Meldung bedeutet:
Hintergrund: Wir hatten letzte Woche im Netzwerk einige "Performance" Probleme, die wir nicht so richtig identifizieren könnten. Beim Troubleshooting bin ich auf die folgende Log Meldung gestoßen:
W 03/08/14 11:48:54 00995 system: Module B 9747527 parity recoveries in previous
W 03/09/14 11:48:55 00995 system: Module B 9752621 parity recoveries in previous
W 03/10/14 11:48:55 00995 system: Module B 9756298 parity recoveries in previous
W 03/11/14 11:48:55 00995 system: Module B 9765975 parity recoveries in previous
W 03/12/14 11:48:55 00995 system: Module B 9754116 parity recoveries in previous
W 03/13/14 11:48:55 00995 system: Module B 9748349 parity recoveries in previous
W 03/14/14 11:48:55 00995 system: Module B 9755338 parity recoveries in previous
W 03/15/14 11:48:56 00995 system: Module B 9749489 parity recoveries in previous
W 03/16/14 11:48:56 00995 system: Module B 9748026 parity recoveries in previous
W 03/17/14 11:48:56 00995 system: Module B 9750663 parity recoveries in previous 24 hours
W 03/18/14 11:48:56 00995 system: Module B 9748221 parity recoveries in previous 24 hours
W 03/19/14 11:48:56 00995 system: Module B 9747020 parity recoveries in previous 24 hours
W 03/20/14 11:48:56 00995 system: Module B 9747933 parity recoveries in previous 24 hours
W 03/21/14 11:48:57 00995 system: Module B 9751132 parity recoveries in previous 24 hours
W 03/22/14 11:48:57 00995 system: Module B 9753547 parity recoveries in previous 24 hours
W 03/23/14 11:48:57 00995 system: Module B 9754983 parity recoveries in previous 24 hours
SW01#
Ich habe folgendes auf der HP Seite (HP Switch Software June 2013 Event Log Message Reference Guide)
bezüglich des „parity recovery error“ gefunden:
994
system: <module| port> <id> <number> parity error recoveries
in previous <interval>
warning Logs the number of successful recoveries that occurred during
the interval: 5 minutes, 1 hour, 24 hours. This reduces the number
of system log events when many recoveries happen close in time.
RMON_PARITY_ERROR_RECOVERY
Leider kann ich das nicht so richtig interpretieren.
Habt ihr eine Idee, was das bedeutet kann?
Vielen Dank!
aguila
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 233464
Url: https://administrator.de/contentid/233464
Printed on: April 25, 2024 at 04:04 o'clock
10 Comments
Latest comment
Hi aguila,
Rmon hat mit Überwachung/Layer 2 bis 4 Monitoring zu tun.
ein Parity Error typischerweise etwas mit Hardware.
Ist es ein L3 Switch?
Vielleicht Überlast oder Speicherprobleme.
Prinzipiell priorisieren Switches Aufgaben. Wenn sie mit dem Switchen voll beschäftigt sind, dann fallen die Überwachungsfunktionen hinten runter. Z.B: SNMP oder eben rmon.
Gruß
Netman
Rmon hat mit Überwachung/Layer 2 bis 4 Monitoring zu tun.
ein Parity Error typischerweise etwas mit Hardware.
Ist es ein L3 Switch?
Vielleicht Überlast oder Speicherprobleme.
Prinzipiell priorisieren Switches Aufgaben. Wenn sie mit dem Switchen voll beschäftigt sind, dann fallen die Überwachungsfunktionen hinten runter. Z.B: SNMP oder eben rmon.
Gruß
Netman
1
Hi Netman,
nein, der Switch ist kein L3 ABER im Modul B stecken zwei 1000 sx Ports: Ein mal zum L3 switch und ein mal zu einer Kette von 6 weitere L2 Switche.
Meine Vermutung war auch so was wie "Überlast oder Speicherprobleme", wie Du es geschrieben hast.
Möchte aber sicher sein, ob das wirklich das Problem im Netzwerk ist.
Danke!
nein, der Switch ist kein L3 ABER im Modul B stecken zwei 1000 sx Ports: Ein mal zum L3 switch und ein mal zu einer Kette von 6 weitere L2 Switche.
Meine Vermutung war auch so was wie "Überlast oder Speicherprobleme", wie Du es geschrieben hast.
Möchte aber sicher sein, ob das wirklich das Problem im Netzwerk ist.
Danke!
zu einer Kette von 6 weitere L2 Switche.
Oha... grausames Design für ein Ethernet und eigentlich ein NoGo !
Hi,
ja, das Design ist problematisch. Aber zu dem Fehler kann ich dir den Tipp geben, den HP Support zu kontaktieren. Die diagnostizieren das mit dir per Remote unt tauschen dann dsa Gerät ggf. aus. Du hast bei den ProCurve i.d. R. Lifetime Warranty
Heute angerufen und morgen hast du ein Ersatzgerät (Neu / Repariert).
Gruß
ja, das Design ist problematisch. Aber zu dem Fehler kann ich dir den Tipp geben, den HP Support zu kontaktieren. Die diagnostizieren das mit dir per Remote unt tauschen dann dsa Gerät ggf. aus. Du hast bei den ProCurve i.d. R. Lifetime Warranty
Heute angerufen und morgen hast du ein Ersatzgerät (Neu / Repariert).
Gruß
Hallo aqui,
ja!Das Design wurde so wie oben im Bild gemacht.
Wie üblich: der Kollege ist bei der Firma nicht mehr da!
Also dann muss ich 100% davon ausgehen, dass das Performance Problem doch durch die Überlast im Modul B am SW01 das Netzwerk instabil macht?
Danke!
Das Design ist nur dann sinnvoll, wenn die Last gering und die Wege weit sind. Eine der beiden Verbindungen ist ja immer tot und dann sind alle Switches auf einer einzigen Kette.
Wenn du natürlich jeden der Switche so und direkt an deine Layer3 Switche anbinden würdest, dann ist es wirklich gut und Stand der Technik.
Gruß
Netman
Wenn du natürlich jeden der Switche so und direkt an deine Layer3 Switche anbinden würdest, dann ist es wirklich gut und Stand der Technik.
Gruß
Netman
1
Hi MrNetmann,
danke! ich denke, dass dieses Design wurde genau wegen der Entfernung zwischen L3 und L2 Switche gemacht. Die Entfernung von Serverraum, wo die L3 Switche sind und die weitere Systeme im Lager liegen verteilt in Verschiedenen Gebäuden und Etagen zwischen 800 und 1200 m auseinander.
VG
aguila
danke! ich denke, dass dieses Design wurde genau wegen der Entfernung zwischen L3 und L2 Switche gemacht. Die Entfernung von Serverraum, wo die L3 Switche sind und die weitere Systeme im Lager liegen verteilt in Verschiedenen Gebäuden und Etagen zwischen 800 und 1200 m auseinander.
VG
aguila
Nun, da Singlemode Kabel ja nicht nur zwei Fasern haben, wirst du ja noch etliche Anschlüsse frei haben. 12 Fasern sind die übliche Untergrenze..
Und nutzte doch die selbe Konfiguration, die auch zwischen den L3-Switchen funktioniert um über LWL einen doppelt so breiten Uplink zu bekommen. Zwischen den Switches kann dann auch eine doppelte Verbindung mitttels LAG/LACP genutzt werden.
Das kann die Ursache für die Fehlermeldung sein.
Aber man sollte mittels SNMP leicht heraus finden können welche Ports überlastet sind. Das ist ein Übliche Vorgehensweise und man hat mit der Historie auch ein Gefühl für den Ist-Zustand und Tendenzen und muss nicht bei Problemen im Panik-Modus alles durchsuchen.
Gruß
Netman
Und nutzte doch die selbe Konfiguration, die auch zwischen den L3-Switchen funktioniert um über LWL einen doppelt so breiten Uplink zu bekommen. Zwischen den Switches kann dann auch eine doppelte Verbindung mitttels LAG/LACP genutzt werden.
Das kann die Ursache für die Fehlermeldung sein.
Aber man sollte mittels SNMP leicht heraus finden können welche Ports überlastet sind. Das ist ein Übliche Vorgehensweise und man hat mit der Historie auch ein Gefühl für den Ist-Zustand und Tendenzen und muss nicht bei Problemen im Panik-Modus alles durchsuchen.
Gruß
Netman
1
Hallo zusammen,
vielen Dank für euere Anregungen und Mühe!
beste Grüße
aguila
vielen Dank für euere Anregungen und Mühe!
beste Grüße
aguila
Nur mal so off Topic...
Solche Kettendesigns sind tödlich für Ethernet. Wer auch immer sowas verbrochen hat hat recht wenig Fachwissen von Ethernet Netzwerken.
Wenn Ringe dann muss man bei Ringen auch spezielle Ring Protokolle verwenden die die Konvergenz niedrig halten in redundanten netzen.
Das was du da machst ist eine Katastrofe und es ist klar das das füher oder später in erhebliche Probleme münden wird.
Klassische LAN Designs sehen so aus:
Man sollte nie mehr als maximal 3 Switches in eine Kette nehmen wenn man es nicht vermeiden kann. Besser gar keine Ketten wenn es nicht ein aktives Stacking ist !!
Solche Kettendesigns sind tödlich für Ethernet. Wer auch immer sowas verbrochen hat hat recht wenig Fachwissen von Ethernet Netzwerken.
Wenn Ringe dann muss man bei Ringen auch spezielle Ring Protokolle verwenden die die Konvergenz niedrig halten in redundanten netzen.
Das was du da machst ist eine Katastrofe und es ist klar das das füher oder später in erhebliche Probleme münden wird.
Klassische LAN Designs sehen so aus:
1
