Perché i diversi risultati per il ping? O perché la Time Capsule viene coinvolta?

Naviga le tue risposte
2

Sto configurando un monitor di rete per script bash al centro del quale sto usando ping .

Quando un host non funziona, ottengo lo standard host is unreachable , di solito.

Ma su una casella sembra ricevere un ping reindirizzato che non riesco a capire.

La mia rete:

  • Sono su un MBP runnning 10.11 (ElCapitan).
  • La rete in questo caso è cablata.
  • Gli indirizzi IP sono tutti assegnati da Fritz! Box.
  • Gli switch non sono gestiti.
  • La capsula del tempo ha il Wi-Fi spento (utilizzo il Wi-Fi da Fritz! Box).
  • Ho abbreviato il conteggio di ping sotto puramente per brevità.

Mappa di rete: 

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

Entrambe le macchine (chiameremo wwwelc e Ubuntu ) si trovano in uno stato di chiusura * con WoL attivo (tranne che il Mac mini non è ancora stato avviato, per essere determinato perché in un secondo momento) .

Modifica: si scopre che il Mac mini era solo in stato di sospensione, il che è peggio visto che non si stava affatto svegliando ... argomento di una domanda diversa anche se probabilmente correlata

Da MBP ottengo due risposte irraggiungibili diverse. Esegui dallo stesso computer (MBP) e nella stessa sessione / schermata del terminale:

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 > wwelc 

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

Entrambi stanno rispondendo con il Request timeout for icmp_seq previsto e in molti pacchetti a volte vedi anche ping: sendto: Host is down .

A volte capita che una diversione simile appaia quando il sistema è attivo, ma ho difficoltà a replicarlo ora. Per risolvere il problema al momento ho appena tolto la porta ethernet e l'ho riavviata: 

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

Stavo eseguendo questo da SSH e senza exit avrebbe bloccato la mia sessione terminale remota:)

Ecco una copia dei risultati di ping mentre chiudo il 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

Come possiamo vedere, Time Machine è di nuovo coinvolta.

Power cycle Time Machine

puoi vedere quando Time Machine è scollegato: 

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

Ho quindi reinserito la Time Machine e gli ho permesso di avviarla. I miei ping a wwelc sono rimasti succinti. L'ho risvegliato dal sonno (sono riuscito a farlo scattare usando Magic Packet ), effettuato l'accesso da SSH e l'ho rimandato a dormire (sì, sono cattivo, sveglia, riaddormenta, sveglia, torna a dormire):)

Ho pensato che sarebbe andato tutto bene, ma alla fine l'ho visto (i ping scadono una volta che ha dormito): 

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

Ho ancora una volta eseguito le impostazioni di Time Machine e non riesco a vedere dove, come o perché interviene nel ping. Il Wi-Fi in entrambe le unità è disattivato.

Ecco un passaggio verso un altro 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;

Per qualche motivo il ping di un Mac mini ( wwwelc ) dal mio MBP passa attraverso la macchina del tempo quando Mac mini è irraggiungibile.

  • Time Machine non è configurato come Time Machine (funziona solo come file server).
  • Il Wi-Fi in entrambe le unità è disattivato.
  • Time Machine ha tutte le funzionalità wireless disabilitate.
  • DHCP non è servito da Time Machine, ma dal router.
  • The Time Machine non interviene in nessun altro ping, solo questo.

Qualche idea?

    
posta Madivad 02.01.2016 - 00:33
fonte

1 risposta

7

Non c'è davvero nulla di cui preoccuparsi - ciò che vedi sono i reindirizzamenti ICMP e non rappresentano un problema in quanto tale.

Il ragionamento dietro ciò che stai vedendo è questo:

L'MBP di solito ha l'indirizzo MAC di wwwelc nella sua cache ARP. Allo stesso modo, SWITCH1 e SWITCH2 sanno su quale delle loro porte è connesso il computer con l'indirizzo MAC di wwwelc. Ciò significa che può inviare pacchetti IP direttamente all'indirizzo MAC di wwwelc.

Quando spegni Mac Mini e passa il tempo, l'indirizzo MAC verrà scaricato dalle cache degli switch e / o dalla cache ARP sul MBP.

Immagina che non sia più nella cache sullo switch. Ciò significa che lo switch non ha altra scelta che trasmettere pacchetti per quell'indirizzo MAC a tutte le sue porte. Ciò significa che SWITCH1 invierà il pacchetto sia a Time Capsule sia a SWITCH2.

Time Capsule riceve il pacchetto e funge da router. Proverà a indirizzare il pacchetto verso la sua destinazione. Si scopre che il pacchetto è effettivamente destinato a qualcosa sulla connessione ethernet su cui è arrivato Time Capsule, vale a dire che non deve essere instradato con le porte di connessione WiFi o Internet.

Per quella situazione, abbiamo qualcosa chiamato reindirizzamenti ICMP. È comune a molti router di vari produttori, quindi non è specifico per Time Capsule.

Time Capsule invia il reindirizzamento ICMP per essere "bello". Permette al mittente di sapere che ha ricevuto un pacchetto in cui il mittente potrebbe effettivamente inviarlo direttamente al successivo hop del percorso senza coinvolgere Time Capsule. Quindi sta facendo sapere che potrebbe aver salvato un salto.

vale a dire. sono soddisfatte le seguenti condizioni:

  • Il pacchetto è arrivato sulla stessa porta che verrà instradato fuori

  • La rete (subnet) dell'IP sorgente è la stessa rete dell'hop successivo (ad esempio, il mittente potrebbe averlo inviato direttamente a quell'hop successivo)

  • Il pacchetto non è sorgente indirizzato (cioè il mittente non ha istruito un percorso specifico da adottare)

Quindi questa è la spiegazione per quello che stai vedendo. Time Capsule riceve il pacchetto perché SWITCH o MBP non sanno dove inviare il pacchetto, quindi lo trasmette. Time Capsule sta cercando di essere gentile, dicendo che il pacchetto avrebbe potuto essere consegnato in un modo più semplice. E infine, la destinazione wwwelc è ancora inattivo, quindi non avrai alcuna risposta dalla destinazione, naturalmente.

    
risposta data 02.01.2016 - 01:39
fonte

Leggi altre domande sui tag

Crazy "Sistema" dati sul traffico - Cosa fare? iOS 9 - iPhone 6s Come utilizzo la macchina del tempo per accedere a file di sistema come / etc / hosts?