Warum sollte Ping mir schnelle RTT-Werte geben, aber es dauert lange, bis jede Antwort zurückkommt?

7

Ich habe hier eine grundlegende Netzwerkfrage zum Thema Ping.

Wenn ich einen bestimmten Host in einem völlig anderen Subnetz anpinge, erhalte ich folgende Antwort:

PING myhost.example.com (1.2.3.4) 56(84) bytes of data.
64 bytes from 1.2.3.4: icmp_req=1 ttl=115 time=1.88 ms
64 bytes from 1.2.3.4: icmp_req=2 ttl=115 time=1.66 ms
64 bytes from 1.2.3.4: icmp_req=3 ttl=115 time=1.96 ms
64 bytes from 1.2.3.4: icmp_req=4 ttl=115 time=1.95 ms

--- myhost.example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 48191ms
rtt min/avg/max/mdev = 1.669/1.868/1.969/0.127 ms

Dies sieht zunächst normal aus, aber dann sehen Sie, dass die Gesamtzeit 48 Sekunden beträgt, um diese 4 Antworten zu erhalten. Wenn der Ping ausgeführt wird, gibt es eine merkliche Lücke von etwa 10 Sekunden, bevor jede Zeile gedruckt wird. Das RTT ist jedoch ziemlich genau das, was ich erwarten würde.

Dies verursacht ein kleines Problem, da ich versuche, diesen Host mit Nagios zu überwachen, und bei der Hostprüfung wird derzeit der Fehler "Netzwerk nicht erreichbar" angezeigt. Das Netzwerk ist erreichbar, das RTT ist vernünftig, aber ich frage mich, ob diese langsame Gesamtzeit etwas damit zu tun haben könnte.

Der Host ist 14 Hops entfernt und die Traceroute sieht folgendermaßen aus (ich habe die Zwischenschritte anonymisiert, sie sind alle unterschiedliche IPs!):

traceroute to myhost (1.2.3.4), 30 hops max, 60 byte packets
 1  10.A.B.C (10.A.B.C)  0.680 ms  0.729 ms  0.833 ms
 2  10.A.B.C (10.A.B.C)  0.636 ms  0.678 ms  0.759 ms
 3  10.A.B.C (10.A.B.C)  0.803 ms  0.867 ms  0.923 ms
 4  10.A.B.C (10.A.B.C)  0.702 ms  0.738 ms  0.782 ms
 5  10.A.B.C (10.A.B.C)  1.027 ms  1.251 ms  1.342 ms
 6  10.A.B.C (10.A.B.C)  2.688 ms  1.436 ms  1.484 ms
 7  10.A.B.C (10.A.B.C)  2.960 ms  3.475 ms  3.527 ms
 8  10.A.B.C (10.A.B.C)  1.284 ms  1.310 ms  1.393 ms
 9  10.A.B.C (10.A.B.C)  1.990 ms  1.865 ms  1.964 ms
10  10.A.B.C (10.A.B.C)  1.750 ms  1.841 ms  1.748 ms
11  10.A.B.C (10.A.B.C)  1.849 ms  1.614 ms  1.628 ms
12  10.A.B.C (10.A.B.C)  1.997 ms  2.150 ms  2.119 ms
13  10.A.B.C (10.A.B.C)  2.442 ms  2.454 ms  2.560 ms
14  1.2.3.4 (1.2.3.4)  1.978 ms * *

Was würde das verursachen?

networking ping

— wachsen
quelle

5

Dies ist eine wilde Vermutung ...

Sie pingen nach DNS-Namen.
Dauert die DNS-Suche von myhost.example.com so lange, bis sie behoben ist?
Was passiert, wenn Sie nach IP-Adresse pingen?

— Tonny
quelle

Guter Ruf, ich hätte das vorher überprüfen sollen. Ping per IP funktioniert wie erwartet. Ich besitze den Forward-DNS-Server, aber nicht den Reverse-DNS-Server. Ich weiß, dass mein DNS-Server in Ordnung ist, also denke ich, dass etwas mit dem umgekehrten DNS nicht stimmt.

— wachsen

1

Sieht ja so aus. Die meisten PING-Implementierungen überprüfen beide und tun dies OHNE Verwendung des DNS-Resolver-Cache. Sie machen das für jeden Ping noch einmal. Dies soll sicherstellen, dass sie einen DNS-basierten Lastenausgleich erkennen können.

— Tonny

1

Versuchen Sie zu bearbeiten /etc/nsswitch.conf. mDNS verursachte mir das gleiche Problem.

Wenn Sie haben:

hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4

versuchen Sie zu ersetzen durch:

hosts:  files dns

— Molnarg
quelle

1

Zusätzlich zum DNS-Suchproblem kann es auch durch das Intervall zwischen Ping-Paketen verursacht werden:

-i interval
          Wait  interval  seconds  between  sending each packet.  The default is to wait for one second between each packet normally, or not to wait in
          flood mode. Only super-user may set interval to values less 0.2 seconds.

Wenn Sie den Server von Google per IP anpingen:

# ping -c 3 74.125.130.101
PING 74.125.130.101 (74.125.130.101) 56(84) bytes of data.
64 bytes from 74.125.130.101: icmp_seq=1 ttl=50 time=2.51 ms
64 bytes from 74.125.130.101: icmp_seq=2 ttl=50 time=2.52 ms
64 bytes from 74.125.130.101: icmp_seq=3 ttl=50 time=2.72 ms

--- 74.125.130.101 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 2.511/2.589/2.729/0.114 ms

Die Gesamtzeit ist immer noch viel größer als die Summe der RTTS.

Wenn Sie jedoch Ping im Flutmodus verwenden:

# ping -c 3 -f 74.125.130.101
PING 74.125.130.101 (74.125.130.101) 56(84) bytes of data.

--- 74.125.130.101 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 2.474/2.744/3.140/0.286 ms, ipg/ewma 4.230/2.657 ms

oder Intervall auf 0 setzen:

# ping -c 3 -i 0 74.125.130.101
PING 74.125.130.101 (74.125.130.101) 56(84) bytes of data.
64 bytes from 74.125.130.101: icmp_seq=1 ttl=50 time=2.83 ms
64 bytes from 74.125.130.101: icmp_seq=2 ttl=50 time=2.87 ms
64 bytes from 74.125.130.101: icmp_seq=3 ttl=50 time=2.96 ms

--- 74.125.130.101 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 9ms
rtt min/avg/max/mdev = 2.834/2.891/2.966/0.083 ms, ipg/ewma 4.510/2.855 ms

Die Gesamtzeit ist fast die Summe der RTTS.

— WKPlus
quelle