ich habe an unseren Zweigstellen Cisco Meraki Switche im Einsatz, die wir über SNMP monitoren. Das hat eine ganze Zeit lang auch super geklappt.
Vor nicht ganz zwei Wochen haben wir unsere SSIDs für unser Meraki WLAN angepasst und danach fing es an, dass die Switche Probleme mit SNMP haben. Fehler: [snmp] Cannot fetch system description OID .1.3.6.1.2.1.1.1.0. Please check your SNMP configuration. Possible reason might be: Wrong credentials, wrong SNMP version, Firewall rules, etc.CRIT , Got no information from hostCRIT , execution time 50.1 sec
Der Fehler tritt immer wieder sporadisch auf und ist nicht dauerhaft da.
Ich habe die Intervalle und die Zeit für den Check schon angepasst, sodass sie jetzt alle 3 Minuten abgefragt werden und 25 Sekunden Zeit pro Versuch mit einem erneuten Versuch haben. Vorher war es jede Minute und 2 Sekunden Zeit pro Versuch.
Jetzt kommt noch dazu, das CheckMK meldet, dass die Switche z.T. 80% Packetloss haben, was aber nicht sein kann. Pinge ich einen der Switche über die Konsole meiner CheckMK Appliance an, habe ich gar keinen Packetloss. Wie kann das sein?
Hat jemand von euch sowas ähnliches schonmal gehabt? Wie kann das sein, dass der Service PING Packetloss anzeigt, der gar nicht da ist?
Frage vorab. Konntest du dein Problem bereits lösen?
Dieses Thema muss im Detail betrachtet werden und ist wahrscheinlich ein bisschen zu vielschichtig für das Forum.
Der Paketloss lässt sich aber recht einfach unabhängig überprüfen, mit tools wie z.B. mtr.
Es gibt einige Troubleshooting Fragen, die man klären müsste, um das Problem genauer zu spezifizieren wie z.B.:
Nutzt du beim Ping Monitoring den Smart Ping der Enterprise Edition oder den klassischen Ping Check?
Wie viele Ping Pakete werden verschickt?
Was ist das Abfrage-Intervall?
Besteht das Problem auch bei einem mtr zum Host?
Sind alle Hosts betroffen oder nur einige wenige?
Ist das Problem mit Änderungen an der Infrastruktur erst aufgetreten, wenn ja, welche Änderungen haben bewusst stattgefunden?
Bestehen andere Probleme mit Bezug auf das Netzwerk?
Natürlich kann ich jetzt noch viele weitere Fragen stellen, um das Problem einzugrenzen, aber wie bereits erwähnt müsste man sich das Ganze im Detail ansehen. Ich hatte bereits aber öfters, dass solche Themen im Monitoring aufgefallen sind und dann beim genaueren Hingucken gravierende Probleme in der Netzwerkinfrastruktur gefunden wurden. Das braucht aber natürlich Zeit, aber meistens lügt das Checkmk nicht, obwohl es den Eindruck macht.
Ich hoffe das ich dir damit etwas weiter helfen kann und sonst kann ich immer empfehlen sich Externe Hilfe dazuzuholen.
Das würde ich nicht so einstellen - besser ist hier eine Einstellung 4-5 Sekunden und dann 4 od. 5 Versuche.
Mit deiner derzeitigen Einstellung wird nur ewig lange gewartet was im Endeffekt nix bringt.
Sicher, dass zur gleichen Zeit nicht auch Sachen an den Firewalls angepasst/geändert wurden. Dein Problem sieht mir sehr nach einem Firewall Problem aus.
Der klassische Ping im CheckMK funktioniert etwas anders wie der Ping auf der Shell. Wenn du den Ping Check im CMK aktivierst, dann werden hierbei immer alle ICMP Pakete mit einem mal versendet und geschaut was zurück kommt innerhalb des Timeout. Ping auf der Shell wird immer ein ICMP Paket gesendet pro Sekunde. Was ich nun schon beobachten konnte sind Firewalls welche von dem 5er ICMP Pakethaufen einfach mal 2-3 wegwerfen und nur den Rest durchlasen.
Innerhalb von CheckMK gibt es auch noch den Ping check welcher sich so verhält wie der auf der Shell.
“Check hosts with PING (ICMP Echo Request)” → check_icmp - alle Pakete auf einmal
“Integrate Nagios plugins” → $USER1$/check_ping $HOSTADDRESS$ -w 200,40% -c 600,80% → check_ping klassisch ein Paket nach dem anderen
Mann sieht auch gut den Unterschied zwischen beiden Checks auf der CLI, dort ist check_icmp eigentlich instanz fertig und check_ping braucht halt seine 4-5 Sekunden ca.
Falls check_ping sauber Ergebnisse liefert solltest mal deine Firewalls “befragen”
Das Problem besteht leider noch nach wie vor. Nutzt du beim Ping Monitoring den Smart Ping der Enterprise Edition oder den klassischen Ping Check?
Ich benutze beides und nur der klassische Ping Check macht Probleme.
Der Service ist aktuell so eingestellt:
Round trip average: warn 200.00 ms, crit 500.00 ms
Packet loss: warn 80.0%, crit 100.0%
Number of packets: 1
Total timeout of check: 4
Intervall: 3 Minuten
Besteht das Problem auch bei einem mtr zum Host?
Wenn ich klassisch über die Konsole vom CheckMK dahin Pinge besteht das Problem nicht.
Sind alle Hosts betroffen oder nur einige wenige?
Es sind ausschließlich die Switche an Außenstellen mit WLAN betroffen und nur die Switche. Die Accesspoints und Firewalls haben an den Standorten keine Probleme.
Ist das Problem mit Änderungen an der Infrastruktur erst aufgetreten, wenn ja, welche Änderungen haben bewusst stattgefunden?
Ja das Problem besteht erst, seit wir ein VLAN für das WLAN eingerichtet haben. Das VLAN wurde aber nur in der SSID eingestellt. Auf den Switchen musste nichts gemacht werden, da die Trunkports das VLAN ohnehin erlaubt haben.
Bestehen andere Probleme mit Bezug auf das Netzwerk?
Bisher sind keine anderen Probleme bekannt und über das Monitoring sichtbar.
Das ist schon mal ein ganz guter Hinweis. Den Check habe ich jetzt dazu genommen und vergleiche über die Zeit mal die Werte.
Mich würde es ehrlich gesagt wundern, wenn es die Firewall wäre, da ich das Problem ja sonst auch mit anderen Maschinen dahinter erwartet hätte. Es sind aber immer nur die Switche betroffen. Da aber auch nicht alle, sondern nur die an den Zweigstellen an denen wir das VLAN neu eingeführt haben.
Das habe ich jetzt auch mal umgestellt, gebessert hat sich dadurch leider auch noch nichts.
Vielen Dank schonmal für die Tipps soweit! Auch wenn es hier noch nicht geholfen hat, lernt man ja trotzdem dazu
So ich habe den Check, den Andreas empfohlen hatte, einmal eingestellt und habe parallel über die Konsole vom CheckMK Server auch einfach mal gepingt. Das ganze lief über 7000 Sekunden.
Mein Ping in der Konsole hatte 0% Paketverlust und ich habe kein einziges Paket verloren.
Laut dem Check in CheckMK sollen es 15% Paketverlust sein, das kann doch nicht angehen.
