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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 233464
Url: https://administrator.de/contentid/233464
Ausgedruckt am: 26.11.2024 um 00:11 Uhr
10 Kommentare
Neuester Kommentar
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
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ß
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
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
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:
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 !!