Lamentablemente, no, eres incorrecto.
Ron hace un buen punto, no proporcionó una máscara de subred, por lo que si asumiéramos la máscara con clase, la dirección 10.xxx tendría una máscara 255.0.0.0, que en realidad pondría a los dos hosts en la misma red. Si ese es el caso, no tendrían problemas para comunicarse.
Sin embargo, dada la naturaleza de su pregunta, me imagino que tiene la intención de que cada uno de estos hosts use una máscara más pequeña; seguiremos adelante y usaremos 255.255.255.0, que coloca a ambos hosts en dos subredes diferentes.
Dicho esto, el corazón de lo que te estás perdiendo está en olvidarte del ARP (Protocolo de resolución de direcciones) . Específicamente, en quién HostA decide ARP para. Dejame explicar...
Antes de que cualquier host ponga un paquete en el cable, lo primero que hace es determinar si la IP de destino está en su propia red o en una red extranjera. Repasemos esto desde la perspectiva del Host A.
El host A conoce su IP (10.1.2.1) y su máscara de subred (/ 24 o 255.255.255.0). Con un poco de subredes , HostA determina que su red abarca todas las direcciones IP en el rango de 10.1.2.0 a 10.1.2.255. (Dejaremos de lado los detalles de NetID y BroadcastIP, ya que por el momento no son relevantes)
El host A también sabe que su IP de destino es 10.1.3.1, que se encuentra fuera del rango de direcciones IP dentro de la propia red del host A. Como tal, el Host A llegaría a la conclusión de que la IP de destino 10.1.3.1 está en una red extranjera, y el Host A solo podría llegar a una red extranjera hablando a través de un enrutador. O más específicamente, a través de la puerta de enlace predeterminada de HostA .
Si HostA no está configurado con una puerta de enlace predeterminada en este momento, entonces el proceso termina aquí con una falla general. HostA no puede hablar con HostB.
Si HostA está configurado con una puerta de enlace predeterminada, enviaría una solicitud ARP (que en sí misma es una trama de difusión), solicitando la dirección MAC de su puerta de enlace predeterminada, NO la dirección MAC de la IP de destino final.
El conmutador, después de recibir la trama de difusión, inundaría el paquete en todas las interfaces, para incluir el que está conectado a HostB. De hecho, HostB recibiría el paquete, pero dado que ARP está buscando la dirección MAC de la puerta de enlace predeterminada (y no la dirección MAC de HostB) , HostB simplemente descartaría e ignoraría la solicitud ARP, sin enviar ningún tipo de respuesta.
HostA, entonces, nunca recibiría una dirección MAC para su puerta de enlace predeterminada y, por lo tanto, no podría encapsular el Paquete de Capa 3 con un encabezado de Capa 2. El paquete fallaría allí.
Puede ver el proceso ARP ilustrado en este video .
Dicho esto, aunque algo no relacionado con tu pregunta, quería hablar con algo que dijiste. Esto puede ser un matiz terminológico, pero solo quiero asegurarme de que se comunique. Un conmutador solo hace dos cosas: reenvía la trama para la que conoce la dirección MAC de destino o las tramas de inundación para las que no conoce la dirección MAC de destino . Un interruptor nunca transmite .
Una transmisión es una trama cuya dirección MAC de destino es ffff.ffff.ffff
. Esta es una dirección MAC especialmente reservada, diseñada específicamente para tramas de difusión. Cuando un conmutador encuentra un marco destinado a ffff.ffff.ffff , su comportamiento es siempre inundar ese marco.
Podrías verlo así, ya que ffff.ffff.ffff es una dirección MAC reservada, el switch no la puede aprender. Por lo tanto, cada vez que un conmutador recibe algo destinado a ffff.ffff.ffff, se ve obligado a inundar todos los puertos en la VLAN en la que se recibió originalmente la trama.