Solicitud de ARP fuera de LAN; ¿La máquina objetivo o la respuesta del enrutador?


7

Si envié una solicitud ARP a la máquina de destino, que se encuentra en Internet y tiene 2 enrutadores, ¿cuál será la dirección IP de destino en mi paquete de solicitud (0001)? ¿Será la dirección IP del enrutador, que es mi puerta de enlace, o será la dirección de la máquina de destino?

Ejemplo: Digamos que quiero hacer una solicitud ARP desde Computer Ahasta Computer C, y el esquema está debajo.

Router1 => Internet => Router2 => Computer C 

¿Cuál sería la dirección IP de destino Router1o Computer C?

Por favor, ayúdame con esto. Estoy un poco confundido

Gracias.


¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.
Ron Maupin

Respuestas:


10

Usando su diagrama original:

Diagrama original de OP

Cuando la computadora A intenta comunicarse con la computadora C, los siguientes pasos resuelven la dirección asignada por el software del enrutador 1 a su dirección de control de acceso a los medios asignada por el hardware: según el contenido de la tabla de enrutamiento en la computadora A, IP determina que la dirección IP de reenvío a Se utiliza para llegar a la computadora C a través del enrutador 1, la dirección IP de su puerta de enlace predeterminada. El host A luego comprueba su propia caché ARP local para una dirección de hardware coincidente para el enrutador 1.

Si la computadora A no encuentra mapeo en el caché, transmite una trama de solicitud ARP a todos los hosts en la red local con la pregunta "¿Cuál es la dirección de hardware para el enrutador 1?" Las direcciones de hardware y software para la fuente, Host A, se incluyen en la solicitud ARP.

Cada host en la red local recibe la solicitud ARP y comprueba si hay una coincidencia con su propia dirección IP. Si un host no encuentra una coincidencia, descarta la solicitud ARP.

El enrutador 1 determina que la dirección IP en la solicitud ARP coincide con su propia dirección IP y agrega una asignación de dirección de hardware / software para el Host A a su caché ARP local.

El enrutador 1 luego envía un mensaje de respuesta ARP que contiene su dirección de hardware directamente al host A.

Cuando el host A recibe el mensaje de respuesta ARP del enrutador, actualiza su caché ARP con una asignación de dirección de hardware / software para el enrutador 1.

Una vez que se ha determinado la dirección de control de acceso a medios para la interfaz de enrutador 1, el host A puede enviar tráfico IP al enrutador 1 dirigiéndolo a la dirección de control de acceso a medios de la interfaz de enrutador 1. Luego, el enrutador reenvía el tráfico al Host C a través del mismo proceso ARP que se describe en esta sección.

Esto se actualizó de un artículo de Microsoft Technet para que coincida con su ejemplo. Otra referencia con un buen ejemplo es la descripción de las redes Juniper .

En pocas palabras, el Host A cuando se comunica con direcciones IP externas / hosts buscará su puerta de enlace predeterminada para la resolución de IP externa y asumirá que el tráfico hacia el Host C será reenviado por esta puerta de enlace.


1
Gracias por su respuesta. Si el caché ARP está vacío, la computadora A haría la solicitud ARP al enrutador 1 para encontrar la puerta de enlace, por lo que la dirección IP de destino sería la dirección IP del enrutador 1 en el primer paquete de solicitud. Estoy en lo cierto?
ebyrock

Sí, si el ARP en la computadora A está vacío, buscaría su puerta de enlace predeterminada y enviaría una solicitud de ARP para el enrutador 1, luego reenviaría el tráfico para el host C al enrutador 1.
Mike Naylor

No hay problema, espero que esto ayude.
Mike Naylor

Soy curioso. ¿Cómo funciona esto con las direcciones IP privadas , establecidas por el enrutador, dado que la dirección MAC del destino es desconocida?
Sometowngeek

4

Todo depende de cómo se configuren las máscaras de subred de A y R1-1, y si la configuración de R1 incluye el proxy-arp.

En una configuración canónica, A y R1-1 deben compartir una misma máscara de subred y su dirección debe coincidir con la misma subred. Cuando esto sucede, C es conocido por A como "no perteneciente a la misma (sub) red", por lo que se debe encontrar un enrutador en la tabla de enrutamiento A que coincida con la dirección C. En el caso más común, R1-1 se conoce como la puerta de enlace predeterminada, por lo que si el MAC de R1-1 aún no se conoce y se envía ARP para descubrirlo. Los detalles están en esta respuesta .

Pero también es posible un escenario diferente: si la máscara de subred de A es tan corta que incluso la IP de C coincide (y las interfaces R1 están configuradas correctamente con una máscara que divide las redes correctamente), entonces A cree que C está en la misma LAN, y intenta enviarle un ARP.

R1 ve el ARP y sabe que ese marco nunca llegará a C que él sabe (debido a sus máscaras de subred más apropiadas) para estar detrás de él, y por lo tanto responderá como C, pero dando la dirección MAC de R1-1. Esta respuesta (conocida como "proxy ARP") de hecho engaña a A, que ahora cree que C está en su propia red con dirección MAC R1-1. Por lo tanto, hablará con C enviando paquetes con C IP y R1-1 MAC tal como resultará del proceso de enrutamiento normal.


Gracias Emilio Sí, mi pregunta se refería al diagrama en la respuesta de Mike. IP-A (Computadora A) y R1-1 están en la misma subred. Y el caché ARP está vacío. Entonces, IP-A primero haría una solicitud ARP a su puerta de enlace predeterminada porque IP-C (Computadora C) está en una subred diferente. Esta es mi comprensión de la respuesta de Mike y tu. Entonces, ¿qué pasará después? ¿Puedes explicar? Gracias.
ebyrock

El paquete Ip de Aa Cse forma envolviéndolos en un marco de ethernet de aa r1-1. (en minúsculas significa la dirección MAC, aquí). R1 recibe el marco, lo abre y lo encuentra en C y, mirando sus propias tablas de enrutamiento, lo envía a su próximo salto hacia la red C. En el último salto, R2 finalmente enviará Aa C(a nivel de IP) de r2-2a c(a nivel de MAC)
Emilio Garavaglia

-2

En la topografía anterior A --- R1 ---- R2 ---- C

Una vez que R2 recibe el paquete de R1, enviará una solicitud ARP para averiguar la dirección MAC de C y solo después de la respuesta de C podrá reenviar el paquete a C.

¿Es eso correcto?


Una solicitud ARP se encuentra en una trama de difusión de capa 2, que todos sabemos que no cruzará un enrutador ya que las tramas se eliminan en el enrutador.
Ron Maupin

Entiendo que. Lo que quise decir es ... R2 y C están en la misma red. Pero como C nunca ha enviado un paquete antes, R2 no tendrá la información de C. entonces, para reenviar el paquete de A a C, R2 deberá enviar una solicitud ARP para la dirección MAC de C.
user22834

El OP está intentando enviar una solicitud ARP a través de Internet. Nunca saldrá de la red donde la computadora A viajará a la computadora C, por lo que R2 nunca la verá para intentar enviarla a la computadora C. De hecho, no creo que la computadora A intente generar un ARP Solicitar una dirección que no esté en su red. Lo que describa sería para un paquete regular que viaja a través de Internet, no una solicitud ARP.
Ron Maupin

No, lo que dije fue que A envía un ARP para R1. R1 envía un ARP para R2. R2 a su vez envía un ARP para C.
user22834

De su respuesta: " Una vez que R2 recibe el paquete de R1 ... " Mi punto es que en la pregunta, que debería responder, R1 no enviará un paquete a R2 ya que el paquete original fue envuelto en un marco de transmisión . De su comentario: " R1 envía un ARP para R2 " . Nuevamente, ARP no funciona en Internet, y en la pregunta que está respondiendo, ¡R! y R2 ​​están separados por Internet. Parece que está respondiendo una pregunta completamente diferente a la que se hizo. Le sugiero que vuelva a leer la pregunta, responda en consecuencia, y quienquiera que lo haya rechazado, o lo hará en el futuro, puede revertirla.
Ron Maupin
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.