¿Por qué los diferentes resultados para ping? ¿O por qué se involucra la Cápsula del Tiempo?

Estoy configurando un monitor de red bash script en cuyo núcleo estoy usando ping.

Cuando un host está inactivo, obtengo el estándar host is unreachable, por lo general.

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

Mi red:

  • Estoy en un MBP corriendo 10.11 (ElCapitan).
  • La red en este caso es toda cableada.
  • Todas las direcciones IP se asignan desde Fritz!Box.
  • Los conmutadores no están administrados.
  • La cápsula del tiempo tiene Wi-Fi desactivado (utilizo Wi-Fi de Fritz!Box).
  • He acortado el pingconteo 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 (llamaremos wwwelcy Ubuntu) están en un estado de apagado* con WoLactivo (excepto que la Mac mini aún no se está iniciando; se determinará por qué más adelante).

Editar: resulta que la Mac mini solo estaba en estado de suspensión, lo que es peor ya que no se estaba despertando en absoluto ... tema de una pregunta diferente aunque posiblemente relacionada

Del MBP recibo dos respuestas inalcanzables diferentes. Ejecutar 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 están respondiendo con lo esperado Request timeout for icmp_seqy en muchos paquetes a veces también se ven ping: sendto: Host is down.

A veces aparece un desvío similar cuando el sistema está activo, pero ahora tengo problemas para replicarlo. Para solucionarlo en ese momento, simplemente desactivé el puerto Ethernet y lo volví a activar:

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

Estaba ejecutando esto desde SSHy sin él exitbloquearía mi sesión remota de Terminal :)

Aquí hay una copia de pinglos resultados 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 del tiempo de ciclo de energía

puedes ver cuando la máquina del tiempo 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 máquina del tiempo y le di tiempo para que arrancara. Mis pings se wwelcmantuvieron sucintos. Lo desperté del modo de suspensión (logré que se despertara usando Magic Packet), inicié sesión SSHy lo envié de nuevo a dormir (sí, soy desagradable: despertar, volver a dormir, despertar, volver a dormir): )

Pensé que todo iba a estar bien, pero finalmente vi esto (el ping se agota una vez que 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 revisé la configuración de Time Machine y no puedo ver dónde, cómo o por qué está interviniendo en el ping. Wi-Fi en ambas unidades están apagados.

Aquí hay un ping que va a otro 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 pasa por la máquina del tiempo cuando no se puede acceder a la Mac mini.

  • Time Machine no está configurado como Time Machine (solo actúa como un servidor de archivos).
  • Wi-Fi en ambas unidades está apagado.
  • Time Machine tiene todas las funciones inalámbricas deshabilitadas.
  • Time Machine no sirve DHCP, sino el enrutador.
  • La Máquina del Tiempo no interviene en ningún otro ping, solo en este.

¿Algunas ideas?

Verifique / publique la tabla de enrutamiento de MBP.
Time Capsule puede actuar como un proxy de suspensión para Mac.

Respuestas (1)

Realmente no hay nada de qué preocuparse: lo que está viendo son redireccionamientos 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 la 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.

Imagine que ya no está en el caché del conmutador. Esto significa que el conmutador no tiene otra opción 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.

Time Capsule recibe el paquete y actúa como un enrutador. Intentará enrutar el paquete a su destino. Encuentra que el paquete en realidad está destinado a algo en la conexión ethernet por la que entró en la Time Capsule, es decir, no debe enrutarse con los puertos de conexión Wi-Fi o Internet.

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

Time Capsule envía la redirección ICMP para ser "agradable". Le permite al remitente saber que recibió un paquete que podría haberlo enviado directamente al siguiente salto de la ruta sin involucrar a Time Capsule. Entonces le está haciendo saber que podría haber ahorrado un salto.

Es decir, se cumplen las siguientes condiciones:

  • El paquete entró en el mismo puerto desde el que se va a enrutar.

  • La red (subred) de la IP de origen es la misma red que el próximo salto (es decir, el remitente podría haberlo enviado directamente a ese próximo salto)

  • El paquete no está enrutado en origen (es decir, el remitente no indicó que se tomara una ruta específica)

Así que esa es la explicación de lo que estás viendo. Time Capsule recibe el paquete porque SWITCH o MBP no sabe a 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 todavía está inactivo, por lo que, por supuesto, no obtendrá ninguna respuesta del destino.

Gracias por tu respuesta muy detallada. No es algo que me preocupara, más bien quería llegar al fondo del asunto. Más porque estaba escribiendo un guión para interpretar la respuesta y luego apareció esto (y no lo esperaba). Saludos
¿Por qué los diferentes resultados para ping? ¿O por qué se involucra la Cápsula del Tiempo?
RespuestasAquíPolítica de privacidad1y, 0v