Ping - erst Packet loss, dann ok

This forum was archived to /woltlab and is now in read-only mode.
  • Hallo zusammen,


    erster Post, direkt ne Frage :rolleyes:
    Hab hier ne Nagios 3.4 Installation welche soweit gut läuft.
    Nun wollte ich check_iax implementieren, was nicht klappt. Hab wohl auch herausgefunden wieso.
    Und zwar ist die Synatx check_iax -H Hostname -w WERT -c WERT. Ist im Prinzip auch nicht so wichtig.
    Problem ist nun das immer ein CRITICAL zurückkommt, bzw. ein Error. Das liegt daran, das der Host, eine Maschine verbunden über ein VPN nicht erreichbar ist.
    Stimmt so nicht ganz, das sie eigentlich erreichbar ist, da wir über die VPN-Strecke telefonieren und zwischen unseren VOIP-Servern einen IAX-Trunk steht.
    Nun zum Problem:


    check_iax gibt einen Error zurück, da es wie gesagt den Host auf der anderen Seite nicht erreicht.
    Ping ich diesen Host vom Nagios-Server an, so gehen ca. die ersten 20-30 oder sogar 50 Pakete verloren, erst dann ist der Ping ok.


    Hier ein Beispiel


    Setze ich sofort im Anschluss wieder einen Ping ab, kommt der erste auch sofort an und auch das check_iax-Plugin gibt ein OK zurück.
    Warte ich allerdings ein paar Sekunden, so gehen wieder die ersten 20-30 Pakete verloren und das check_iax-Plugin wirft nen Error.


    Plugin fail

    Code
    1. /usr/local/nagios/libexec/check_iax -H 192.168.9.40 -w 100 -c 500
    2. SERVICE STATUS: ERROR on recv(), errno 11


    Ping abgesetzt, gewartet bis ok, sofort danach nochmal Plugin überprüft


    Plugin ok

    Code
    1. /usr/local/nagios/libexec/check_iax -H 192.168.9.40 -w 100 -c 500
    2. SERVICE STATUS: OK, IAX PONG reply from: 192.168.9.40, in 19 ms


    Ich verstehe es echt nicht.


    - Firewalls auf beiden Servern aus
    - Selinux auf beiden Servern aus
    - im VPN alles erlaubt
    - VPN zwischen beiden Sites steht
    - iptables auf beiden Servern aus
    - ip6tables auf beiden Servern aus


    Hatte jemand sowas schonmal?


    Danke im Voraus.


    Grüße,
    Christof

  • Ich würde 'mal vermuten, daß die VPN-/WAN-Strecke abgebaut wird, wenn kein Traffic drüberläuft, und Du den Effekt beobachtest, daß sie - wenn dann doch welcher kommt - erstmal wieder aufgebaut werden muß ... Es dauert beim VoIPen nicht zufällig hin und wieder die bewußten 20-30 Sekunden, bis aus dem DIALING ein RINGING wird (oder die entsprechenden Leitungstöne)?

  • Hm, hast natürlich grundsätzlich recht, aber zwischen den beiden Niederlassungen geht eigentlich durchgehend was über die Leitung, da von der einen Niederlassung zur Anderen mehrere Benutzer auf einem Terminal-Server arbeiten.
    Daher muss es an was anderem liegen, zudem auch ein Ping auf www.google.de das gleiche Ergebnis liefert....
    Hab echt keine Ahnung und vor allem keine Idee wie ich an die Sache heran gehen soll.

  • Also selber Effekt vom Nagios komplett am VPN vorbei ins Internet? Für mich wäre das der Moment, in dem ich zum Netzwerk-Sniffer greife und mir ansehe, was wann wo übern Draht geht ...


    (Inklusive DNS. Ein Rechner, der IPv6 eingeschaltet hat und Hostnamen erstmal quer durch die Searchlist mit AAAA Requests probiert, kann auch schonmal 'ne Weile brauchen, bevor er auf IPv4 umschwenkt und dort dann normale Reaktionszeiten zeigt.)

  • Ja, auch beim Ping auf www.google.de gehen die ersten Pakete verloren



    hier mal die Routen:


    Code
    1. route
    2. Kernel IP routing table
    3. Destination Gateway Genmask Flags Metric Ref Use Iface
    4. 192.168.xx.0 * 255.255.255.0 U 0 0 0 eth0
    5. default 192.168.xx.1 0.0.0.0 UG 0 0 0 eth0


    an sich ja nichts besonderes


    Welchen brauchbaren Sniffer gibts denn auf Kommandozeilenebene?



    edit: auch abgeschaltetes IPv6 brachte keine Änderung

    The post was edited 1 time, last by c.lewan ().

  • Hallo,


    das sieht mir aber bald nach einer generellen Netzwerkbaustelle aus. Geht der Ping zum Router ohne Packetverlust? Geht der Ping auf IP Ebene ohne Paketverlust?
    Wenn der Router ohne Probleme erreichbar ist auf seiner internen Schnittstelle bräuchte man genauere Infos zum Anschluss.

  • Also ich konnte es soweit nachstellen, dass ich zum Ergebnis gekommen bin das es defintiv an der Firewall liegt. Man sieht im Packet Monitor, dass die ICMP Pakete ankommen und dann verworfen werden. Komischerweise werden sie dann irgendwann nicht mehr verworfen.
    Der Grund fürs Verwerfen ist laut Fehlermeldung eine Firewall-Regel, was aber nicht sein kann, da ALLES im VPN erlaubt ist.
    Habe jetzt auch schon den Support kontaktiert und warte auf Rückruf.
    Konnte es auch mit dem Sniffer netsniff-ng sehen, wie die ICMP-Pakete rausgingen, aber keins zurückgekommen ist, erst nach ca. dem 50 Ping kam dann mal ne Anwort.
    Naja, schaun wir mal was der Support dazu sagt. Werde berichten.


    Danke schonmal an die Hilfeleistenden :)

  • So, lang hats gedauert, aber das Problem ist gelöst.
    Ohne den Sonicwall-Support wäre ich nie drauf gekommen. Und hätte der Support so einen Fall nicht schonmal gehabt, hätte es wohl noch länger gedauert.
    Es lag an einem SSO-Client von Sonicwall. In diesem musste man Ausnahmen definieren, der bestimmten Traffic von bestimmten Hosts durchlässt. Nun funzt der Ping und der Rest wie er soll ;-).