¿Por qué los diferentes resultados para ping? ¿O por qué se está involucrando la cápsula del tiempo?

Navega tus respuestas
2

Estoy configurando un monitor de red de scripts bash en el núcleo del cual estoy usando ping .

Cuando un host está inactivo, normalmente obtengo host is unreachable .

Pero en una casilla parece estar recibiendo un ping redirigido que no puedo entender.

Mi red:

  • Estoy en un MBP ejecutando 10.11 (ElCapitan).
  • La red en este caso está todo cableada.
  • Las direcciones IP se asignan todas desde Fritz! Box.
  • Los interruptores no están administrados.
  • La cápsula del tiempo tiene la conexión Wi-Fi desactivada (uso Wi-Fi de Fritz! Box).
  • Acorté el recuento de ping a continuación simplemente por brevedad.

Mapa de red: 

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

Ambas máquinas (a las que llamaremos wwwelc y Ubuntu ) están en estado de apagado * con WoL activo (a excepción de que la Mac mini no se está iniciando todavía; se determinará el motivo más adelante) .

Editar: Resulta que el Mac mini solo estaba en estado de reposo, lo que es peor porque no se despertó en absoluto ... tema de una pregunta diferente aunque posiblemente relacionada

Desde el MBP estoy recibiendo dos respuestas diferentes inalcanzables. Ejecute desde la misma computadora (el MBP) y en la misma sesión / pantalla de Terminal:

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

Ambos responden con el Request timeout for icmp_seq esperado y en muchos paquetes a veces también ves ping: sendto: Host is down .

A veces me aparece un desvío similar cuando el sistema está funcionando, pero ahora tengo problemas para replicarlo. Para solucionarlo en el momento en que acabo de bajar el puerto Ethernet y volver a subirlo: 

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

Estaba ejecutando esto desde SSH y sin el exit bloquearía mi sesión de Terminal remota :)

Aquí hay una copia de los resultados de ping cuando apago el 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

Como podemos ver, la máquina del tiempo se está involucrando nuevamente.

Máquina de tiempo del ciclo de alimentación

puedes ver cuando la Time Machine está desconectada: 

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

Luego volví a enchufar la Time Machine y le di tiempo para que arranque. Mis pings a wwelc quedaron sucintos. Lo desperté del sueño (logré que despertara con Magic Packet ), inicié sesión con SSH y lo devolví al sueño (sí, soy desagradable; me levanto, vuelvo a dormir, me despierto, Vuelve a dormir) :)

Pensé que todo iba a estar bien, pero al final vi esto (se agota el tiempo de espera una vez que se duerme): 

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

Una vez más he revisado la configuración de Time Machine y no puedo ver dónde, cómo o por qué está interviniendo en el ping. La conexión Wi-Fi en ambas unidades está desactivada.

Aquí hay un ping que va a otra 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;

Por alguna razón, hacer ping a una Mac mini ( wwwelc ) desde mi MBP se realiza a través de la máquina del tiempo cuando no se puede acceder a la Mac mini.

  • La máquina del tiempo no está configurada como una máquina del tiempo (solo actúa como un servidor de archivos).
  • El Wi-Fi en ambas unidades está apagado.
  • Time Machine tiene todas las funciones inalámbricas desactivadas.
  • DHCP no sirve DHCP, sino que lo hace desde el enrutador.
  • La máquina del tiempo no interviene en ningún otro ping, solo este.

¿Alguna idea?

    
pregunta Madivad 02.01.2016 - 00:33

1 respuesta

7

Realmente no hay nada de qué preocuparse: lo que está viendo son redirecciones ICMP, y no son un problema como tal.

El razonamiento detrás de lo que estás viendo es este:

Su MBP generalmente tiene la dirección MAC de wwwelc en su caché ARP. De manera similar, SWITCH1 y SWITCH2 saben en cuál de sus puertos está conectada la computadora con la dirección MAC de wwwelc. Esto significa que puede enviar paquetes IP directamente a la dirección MAC de wwwelc.

Cuando apague el Mac Mini y pase algún tiempo, la dirección MAC finalmente se borrará de los cachés en sus conmutadores y / o el caché ARP en el MBP.

Imagina que ya no está en el caché del conmutador. Esto significa que el conmutador no tiene más remedio que transmitir paquetes para esa dirección MAC a todos sus puertos. Esto significa que SWITCH1 enviará el paquete tanto a Time Capsule como a SWITCH2.

La Time Capsule recibe el paquete y actúa como un enrutador. Intentará enrutar el paquete a su destino. Encuentra que el paquete está realmente destinado a algo en la conexión Ethernet en la que entró en la Time Capsule, es decir, no se debe enrutar con los puertos de conexión WiFi o Internet.

Para esa situación, tenemos algo que se llama redirecciones ICMP. Es común a muchos enrutadores de varios productores, por lo que no es específico de Time Capsule.

La Time Capsule envía la redirección de ICMP para que sea "agradable". Le está informando al remitente que recibió un paquete donde el remitente podría haberlo enviado directamente al siguiente salto de la ruta sin involucrar a la Time Capsule. Así que es dejarle saber que podría haber salvado un salto.

I.e. Se cumplen las siguientes condiciones:

  • El paquete llegó en el mismo puerto por el que se enrutará

  • La red (subred) de la IP de origen es la misma que la del siguiente salto (es decir, el remitente podría haberlo enviado directamente al siguiente salto)

  • El paquete no está enrutado en origen (es decir, el remitente no dio instrucciones para tomar una ruta específica)

Esa es la explicación de lo que estás viendo. La Time Capsule recibe el paquete porque SWITCH o MBP no sabe dónde enviar el paquete, por lo que lo transmite. La Time Capsule está tratando de ser amable, diciendo que el paquete podría haberse entregado de una manera más fácil. Y, por último, el destino wwwelc aún está inactivo, por lo que no recibirá ninguna respuesta del destino, por supuesto.

    
respondido por el jksoegaard 02.01.2016 - 01:39

Lea otras preguntas en las etiquetas

¿Cómo puedo encontrar lo que está usando el resto de mi unidad? acceso SSH usando la clave .pub