Warum die unterschiedlichen Ergebnisse für Ping? Oder warum mischt sich die Time Capsule ein?

Ich richte einen Bash-Skript-Netzwerkmonitor ein, dessen Kern ich verwende ping.

Wenn ein Host ausfällt, erhalte ich host is unreachablenormalerweise den Standard .

Aber auf einer Box scheint es einen umgeleiteten Ping zu bekommen, den ich nicht verstehen kann.

Mein Netzwerk:

  • Ich verwende ein MBP mit 10.11 (ElCapitan).
  • Das Netzwerk ist in diesem Fall komplett kabelgebunden.
  • IP-Adressen werden alle von der Fritz!Box vergeben.
  • Switches sind nicht verwaltet.
  • Zeitkapsel hat Wi-Fi deaktiviert (ich verwende Wi-Fi von Fritz!Box).
  • Ich habe die pingZählung unten nur der Kürze halber gekürzt.

Netzwerkkarte:

MBP IP:192.168.178.45
 |
 |
SWITCH#1 ---- Fritz.box (DHCP/Internet) ---- ISP
 |   \         192.168.178.1
 |    \
 |     \ dav3tc (Apple Time Capsule)
 |      \__  192.168.178.29
 |
SWITCH#2
 |  \
 |   \
 |    \ wwwelc (Mac mini running 10.11 but turned off)
 |     \___  192.168.178.80
 \
  \  Ubuntu
   \__ 192.168.178.28

Beide Maschinen (wir nennen wwwelcund Ubuntu) befinden sich im Shutdown-Zustand* und sind WoLaktiv (mit der Ausnahme, dass der Mac mini noch nicht hochfährt – der Grund wird zu einem späteren Zeitpunkt ermittelt).

Bearbeiten: Es stellte sich heraus, dass sich der Mac mini nur in einem Schlafzustand befand, was schlimmer ist, da er überhaupt nicht aufwachte ... Gegenstand einer anderen, wenn auch möglicherweise verwandten Frage

Vom MBP erhalte ich zwei verschiedene unerreichbare Antworten. Führen Sie von demselben Computer (dem MBP) und in derselben Terminalsitzung / demselben Terminalbildschirm aus:

MBP > Ubuntu

MBP:~ madivad$ ping -c 3 -W 1 192.168.178.28
PING 192.168.178.28 (192.168.178.28): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1

--- 192.168.178.28 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

MBP > wwelz

MBP:~ madivad$ ping -c 3 -W 1 192.168.178.80
PING 192.168.178.80 (192.168.178.80): 56 data bytes
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 1c50   0 0000  40  01 788a 192.168.178.45  192.168.178.80

Request timeout for icmp_seq 0
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 8ff4   0 0000  40  01 04e6 192.168.178.45  192.168.178.80

Request timeout for icmp_seq 1
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 bda5   0 0000  40  01 d734 192.168.178.45  192.168.178.80


--- 192.168.178.80 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Beide antworten mit dem Erwarteten Request timeout for icmp_seqund in vielen Paketen sieht man manchmal auch ping: sendto: Host is down.

Manchmal erscheint eine ähnliche Umleitung, wenn das System hochgefahren ist, aber ich habe jetzt Probleme, sie zu replizieren. Um es damals zu beheben, habe ich einfach den Ethernet-Port heruntergefahren und wieder hochgefahren:

sudo ifconfig en0 down && sudo ifconfig en0 up && exit

Ich habe dies ausgeführt SSHund ohne das exitwürde es meine Remote-Terminal-Sitzung sperren :)

Hier ist eine Kopie der pingErgebnisse, wenn ich das herunterfahre wwwelc:

64 bytes from 192.168.178.80: icmp_seq=1273 ttl=64 time=0.674 ms
64 bytes from 192.168.178.80: icmp_seq=1274 ttl=64 time=0.528 ms
64 bytes from 192.168.178.80: icmp_seq=1275 ttl=64 time=0.636 ms
64 bytes from 192.168.178.80: icmp_seq=1276 ttl=64 time=0.715 ms
Request timeout for icmp_seq 1277
Request timeout for icmp_seq 1278
Request timeout for icmp_seq 1279
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 4506   0 0000  40  01 4fd4 192.168.178.45  192.168.178.80

Request timeout for icmp_seq 1280
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 aaae   0 0000  40  01 ea2b 192.168.178.45  192.168.178.80

Wie wir sehen können, mischt sich die Zeitmaschine wieder ein.

Power-Cycle-Time-Machine

Sie können sehen, wenn die Time Machine nicht angeschlossen ist:

Request timeout for icmp_seq 1462
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 cb5d   0 0000  40  01 c97c 192.168.178.45  192.168.178.80

Request timeout for icmp_seq 1463
Request timeout for icmp_seq 1464
Request timeout for icmp_seq 1465
Request timeout for icmp_seq 1466

Dann habe ich die Time Machine wieder angeschlossen und ihr Zeit zum Booten gegeben. Meine Pings wwelcblieben prägnant. Ich habe es aus dem Schlaf geweckt (ich habe es geschafft, es mit aufzuwecken Magic Packet), mich angemeldet SSHund es wieder in den Schlaf geschickt (ja, ich bin böse – wach auf, geh wieder schlafen, wach auf, geh wieder schlafen): )

Ich dachte, es würde alles gut werden, aber schließlich sah ich das (Pings-Timeout, sobald es schläft):

64 bytes from 192.168.178.80: icmp_seq=1670 ttl=64 time=0.617 ms
64 bytes from 192.168.178.80: icmp_seq=1671 ttl=64 time=0.588 ms
64 bytes from 192.168.178.80: icmp_seq=1672 ttl=64 time=0.493 ms
64 bytes from 192.168.178.80: icmp_seq=1673 ttl=64 time=0.690 ms
Request timeout for icmp_seq 1674
Request timeout for icmp_seq 1675
Request timeout for icmp_seq 1676
Request timeout for icmp_seq 1677
Request timeout for icmp_seq 1678
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 f5fb   0 0000  40  01 9ede 192.168.178.45  192.168.178.80

Request timeout for icmp_seq 1679
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 a2db   0 0000  40  01 f1fe 192.168.178.45  192.168.178.80

Request timeout for icmp_seq 1680
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 41f4   0 0000  40  01 52e6 192.168.178.45  192.168.178.80

Ich bin nochmal die Time Machine Einstellungen durchgegangen und kann nicht erkennen wo, wie oder warum es in den Ping eingreift. WLAN ist in beiden Einheiten ausgeschaltet.

Hier ist ein Ping zu einem anderen Mac mini:

MBP:~ madivad$ ping 192.168.178.26
PING 192.168.178.26 (192.168.178.26): 56 data bytes
64 bytes from 192.168.178.26: icmp_seq=0 ttl=64 time=66.294 ms
64 bytes from 192.168.178.26: icmp_seq=1 ttl=64 time=2.006 ms
64 bytes from 192.168.178.26: icmp_seq=2 ttl=64 time=1.665 ms
64 bytes from 192.168.178.26: icmp_seq=3 ttl=64 time=20.826 ms

TLDR;

Aus irgendeinem Grund geht das Ping eines Mac mini ( wwwelc) von meinem MBP über die Zeitmaschine, wenn der Mac mini nicht erreichbar ist.

  • Die Time Machine ist nicht als Time Machine eingerichtet (sie fungiert nur als Dateiserver).
  • WLAN ist in beiden Einheiten ausgeschaltet.
  • Time Machine hat alle drahtlosen Funktionen deaktiviert.
  • DHCP wird nicht von Time Machine bereitgestellt, sondern vom Router.
  • Bei keinem anderen Ping greift die Time Machine ein, nur bei diesem.

Irgendwelche Ideen?

Überprüfen/posten Sie die Routing-Tabelle von MBP.
Time Capsule kann als Sleep-Proxy für Macs fungieren.

Antworten (1)

Es gibt wirklich keinen Grund zur Sorge - was Sie sehen, sind ICMP-Umleitungen, und sie sind an sich kein Problem.

Der Grund für das, was Sie sehen, ist folgender:

Ihr MBP hat normalerweise die MAC-Adresse von wwwelc in seinem ARP-Cache. Ebenso wissen SWITCH1 und SWITCH2, an welchem ​​ihrer Ports der Rechner mit der MAC-Adresse von wwwelc angeschlossen ist. Das bedeutet, dass er IP-Pakete direkt an die MAC-Adresse von wwwelc senden kann.

Wenn Sie den Mac Mini ausschalten und einige Zeit vergeht, wird die MAC-Adresse schließlich aus den Caches auf Ihren Switches und/oder dem ARP-Cache auf dem MBP geleert.

Stellen Sie sich vor, es befindet sich nicht mehr im Cache des Switches. Das bedeutet, dass der Switch keine andere Wahl hat, als Pakete für diese MAC-Adresse an alle seine Ports zu senden. Dies bedeutet, dass SWITCH1 das Paket sowohl an die Time Capsule als auch an SWITCH2 sendet.

Die Time Capsule empfängt das Paket und fungiert als Router. Es wird versuchen, das Paket an sein Ziel zu leiten. Es stellt fest, dass das Paket tatsächlich für etwas auf der Ethernet-Verbindung bestimmt ist, über die es in die Time Capsule gekommen ist – dh es soll nicht mit den WiFi- oder Internetverbindungsports nach außen geleitet werden.

Für diese Situation haben wir etwas namens ICMP-Umleitungen. Es ist vielen Routern verschiedener Hersteller gemeinsam - es ist also nicht Time Capsule-spezifisch.

Die Time Capsule sendet die ICMP-Umleitung als "nett". Es teilt dem Absender mit, dass er ein Paket erhalten hat, bei dem der Absender es tatsächlich direkt an den nächsten Hop der Route hätte senden können, ohne die Time Capsule einzubeziehen. Es lässt es also wissen, dass es einen Sprung hätte sparen können.

Dh folgende Bedingungen sind erfüllt:

  • Das Paket kam auf dem gleichen Port an, von dem es weitergeleitet werden soll

  • Das Netzwerk (Subnetz) der Quell-IP ist dasselbe Netzwerk wie der nächste Hop (dh der Absender hätte es einfach direkt an diesen nächsten Hop senden können).

  • Das Paket wird nicht an die Quelle weitergeleitet (dh der Absender hat keinen bestimmten zu nehmenden Pfad angegeben).

Das ist also die Erklärung für das, was Sie sehen. Die Time Capsule empfängt das Paket, weil der SWITCH oder MBP nicht weiß, wohin das Paket gesendet werden soll – also sendet es es. Die Time Capsule versucht nett zu sein und sagt, dass das Paket einfacher hätte zugestellt werden können. Und schließlich ist das Ziel wwwelc immer noch ausgefallen, sodass Sie natürlich keine Antworten vom Ziel erhalten werden.

Danke für deine sehr ausführliche Antwort. Es ist nichts, worüber ich mir Sorgen gemacht habe, sondern wollte der Sache nur auf den Grund gehen. Mehr, weil ich ein Skript schrieb, um die Antwort zu interpretieren, und dann tauchte dies auf (und ich hatte es nicht erwartet). Grüße
Warum die unterschiedlichen Ergebnisse für Ping? Oder warum mischt sich die Time Capsule ein?
AntwortenHierDatenschutz-Bestimmungen1y, 0v