3 votos

Madivad avatar

¿Por qué los resultados de ping son diferentes? ¿O por qué se está involucrando la Time Capsule?

Preguntado el 1 de Enero, 2016
Cuando se hizo la pregunta
333 visitas
Cuantas visitas ha tenido la pregunta
1 Respuestas
Cuantas respuestas ha tenido la pregunta
Resuelta
Estado actual de la pregunta

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

Cuando un host está caído, generalmente obtengo el estándar host is unreachable.

Pero en una caja parece estar obteniendo un ping redirigido que no entiendo.

Mi Red:

  • Estoy en un MBP corriendo 10.11 (El Capitan).
  • La red en este caso está completamente cableada.
  • Las direcciones IP están asignadas desde el Fritz!Box.
  • Los switches son sin gestionar.
  • Time Capsule tiene el Wi-Fi apagado (utilizo el Wi-Fi del Fritz!Box).
  • He acortado la cuenta de ping abajo puramente por brevedad.

Mapa de red:

IP del MBP: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 corriendo 10.11 pero apagado)
 |     \___ 192.168.178.80
 \
  \  Ubuntu
   \__ 192.168.178.28

Ambas máquinas (llamaremos wwwelc y Ubuntu) están en estado de apagado* con WoL activo (excepto que el Mac mini no se está encendiendo todavía—para determinar por qué en otro momento).

Edit: Resulta que el Mac mini solo estaba en un estado de reposo, lo cual es peor ya que no se despertaba en absoluto... tema de otra pregunta diferente aunque posiblemente relacionada

Desde el MBP estoy obteniendo dos respuestas diferentes de inalcanzable. Ejecutado 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 datos bytes
Tiempo de espera para icmp_seq 0
Tiempo de espera para icmp_seq 1

--- 192.168.178.28 estadísticas ping ---
3 paquetes transmitidos, 0 paquetes recibidos, 100.0% pérdida de paquetes

MBP > wwelc

MBP:~ madivad$ ping -c 3 -W 1 192.168.178.80
PING 192.168.178.80 (192.168.178.80): 56 datos bytes
36 bytes desde dav3tc.fritz.box (192.168.178.29): Redirigir Host(Nueva dirección: 192.168.178.80)
Vr HL TOS  Longitud   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

Tiempo de espera para icmp_seq 0
36 bytes desde dav3tc.fritz.box (192.168.178.29): Redirigir Host(Nueva dirección: 192.168.178.80)
Vr HL TOS  Longitud   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

Tiempo de espera para icmp_seq 1
36 bytes desde dav3tc.fritz.box (192.168.178.29): Redirigir Host(Nueva dirección: 192.168.178.80)
Vr HL TOS  Longitud   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 estadísticas ping ---
3 paquetes transmitidos, 0 paquetes recibidos, 100.0% pérdida de paquetes

Ambos responden con el esperado Tiempo de espera para icmp_seq y en muchos paquetes a veces también ves ping: sendto: Host is down.

A veces obtengo una desviación similar apareciendo cuando el sistema está activo, pero tengo problemas para replicarlo ahora. Para solucionarlo en ese momento simplemente bajé y subí el puerto Ethernet de nuevo:

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í tienes una copia de los resultados de ping mientras apago el wwwelc:

64 bytes desde 192.168.178.80: icmp_seq=1273 ttl=64 time=0.674 ms
64 bytes desde 192.168.178.80: icmp_seq=1274 ttl=64 time=0.528 ms
64 bytes desde 192.168.178.80: icmp_seq=1275 ttl=64 time=0.636 ms
64 bytes desde 192.168.178.80: icmp_seq=1276 ttl=64 time=0.715 ms
Tiempo de espera para icmp_seq 1277
Tiempo de espera para icmp_seq 1278
Tiempo de espera para icmp_seq 1279
36 bytes desde dav3tc.fritz.box (192.168.178.29): Redirigir Host(Nueva dirección: 192.168.178.80)
Vr HL TOS  Longitud   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

Tiempo de espera para icmp_seq 1280
36 bytes desde dav3tc.fritz.box (192.168.178.29): Redirigir Host(Nueva dirección: 192.168.178.80)
Vr HL TOS  Longitud   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, el Time Machine está involucrándose de nuevo.

Ciclo de energía del Time Machine

Puedes ver cuando se desconecta el Time Machine:

Tiempo de espera para icmp_seq 1462
36 bytes desde dav3tc.fritz.box (192.168.178.29): Redirigir Host(Nueva dirección: 192.168.178.80)
Vr HL TOS  Longitud   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

Tiempo de espera para icmp_seq 1463
Tiempo de espera para icmp_seq 1464
Tiempo de espera para icmp_seq 1465
Tiempo de espera para icmp_seq 1466

Luego volví a enchufar el Time Machine y le di tiempo para arrancar. Mis pings a wwelc se mantuvieron concisos. Lo desperté del reposo (logré hacerlo despertar usando Magic Packet), inicié sesión por SSH y lo mandé de vuelta al reposo (sí, soy malo—despertar, volver al reposo, despertar, volver al reposo) :)

Pensé que todo iba a estar bien, pero finalmente vi esto (los pings se agotan una vez que se duerme):

64 bytes desde 192.168.178.80: icmp_seq=1670 ttl=64 time=0.617 ms
64 bytes desde 192.168.178.80: icmp_seq=1671 ttl=64 time=0.588 ms
64 bytes desde 192.168.178.80: icmp_seq=1672 ttl=64 time=0.493 ms
64 bytes desde 192.168.178.80: icmp_seq=1673 ttl=64 time=0.690 ms
Tiempo de espera para icmp_seq 1674
Tiempo de espera para icmp_seq 1675
Tiempo de espera para icmp_seq 1676
Tiempo de espera para icmp_seq 1677
Tiempo de espera para icmp_seq 1678
36 bytes desde dav3tc.fritz.box (192.168.178.29): Redirigir Host(Nueva dirección: 192.168.178.80)
Vr HL TOS  Longitud   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

Tiempo de espera para icmp_seq 1679
36 bytes desde dav3tc.fritz.box (192.168.178.29): Redirigir Host(Nueva dirección: 192.168.178.80)
Vr HL TOS  Longitud   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

Tiempo de espera para icmp_seq 1680
36 bytes desde dav3tc.fritz.box (192.168.178.29): Redirigir Host(Nueva dirección: 192.168.178.80)
Vr HL TOS  Longitud   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 los ajustes del Time Machine y no puedo ver dónde, cómo o por qué está interviniendo en el ping. El Wi-Fi en ambas unidades está apagado.

Aquí tienes un ping yendo a otro Mac mini:

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

TLDR;

Por alguna razón, al hacer ping a un Mac mini (wwelc) desde mi MBP pasa por el Time Machine cuando el Mac mini es inalcanzable.

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

¿Alguna idea?

Preguntado el 1 de Enero, 2016 por Madivad

0 votos

Avatar de klanomath

Verifique/publica la tabla de enrutamiento de MBP.

Comentado el 2 de Enero, 2016 por klanomath

0 votos

Avatar de DHayes

Cápsula del tiempo puede actuar como un proxy de sueño para Mac.

Comentado el 2 de Enero, 2016 por DHayes

Respuesta

¿Demasiados anuncios?

7voto

Jose Chavez avatar
Jose Chavez Puntos 645

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

La razón detrás de lo que estás viendo es la siguiente:

Normalmente, tu MBP tiene la dirección MAC de wwwelc en su caché ARP. De manera similar, SWITCH1 y SWITCH2 saben en qué puertos están conectadas las computadoras con la dirección MAC de wwwelc. Esto significa que pueden enviar paquetes IP directamente a la dirección MAC de wwwelc.

Cuando apagas el Mac Mini y pasa un tiempo, la dirección MAC eventualmente será eliminada de las cachés en tus switches y/o la caché ARP en el MBP.

Imagina que ya no está en la caché del switch. Esto significa que el switch no tiene otra opción que difundir paquetes para esa dirección MAC a todos sus puertos. Esto significa que SWITCH1 enviará el paquete tanto al Time Capsule como a SWITCH2.

El Time Capsule recibe el paquete y actúa como un enrutador. Intentará enrutar el paquete hacia su destino. Descubre que el paquete está realmente destinado a algo en la conexión ethernet por la que ingresó al Time Capsule, es decir, no debe ser enrutado a través de los puertos WiFi o de conexión a Internet.

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

El Time Capsule envía la redirección ICMP para ser "amable". Está dejando saber al remitente que recibió un paquete que, en realidad, el remitente podría haberlo enviado directamente al siguiente salto de la ruta sin involucrar al Time Capsule. Así que le está informando que podría haberse ahorrado un salto.

Es decir, se cumplen las siguientes condiciones:

  • El paquete entró por el mismo puerto por donde se va a enrutar

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

  • El paquete no está enrutado desde la fuente (es decir, el remitente no instruyó que se tomara una ruta específica)

Así que esa es la explicación de lo que estás viendo. El Time Capsule recibe el paquete porque el SWITCH o el MBP no saben a dónde enviar el paquete, por lo que lo difunden. El Time Capsule intenta ser amable, diciendo que el paquete podría haber sido entregado de una manera más fácil. Y finalmente, el destino wwwelc todavía está inactivo, por lo que naturalmente no obtendrás ninguna respuesta del destino.

Respondido el 2 de Enero, 2016 por Jose Chavez (645 Puntos )

0 votos

Avatar de Madivad

Gracias por tu respuesta muy detallada. No es algo de lo que estaba preocupado, sino que simplemente quería llegar al fondo de ello. Más bien porque estaba escribiendo un script para interpretar la respuesta y luego esto apareció (y no lo estaba esperando). Saludos

Comentado el 2 de Enero, 2016 por Madivad

Preguntas relacionadas

Preguntas Destacadas

Etiquetas mas usadas

En nuestra red

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

Yandex
X