Recientemente realicé una actualización en un Cisco 2520. Como parte de la actualización, se agregó SVI al conmutador para permitir que una VLAN se enrute localmente, lo que anteriormente se hacía en otro conmutador (a través de una troncal). El SVI tenía los siguientes parámetros;
Dirección de red: 192.168.65.96 Máscara de subred: 255.255.255.248 Dirección SVI: 192.168.65.102
Había dos dispositivos en esta subred y, cuando se realizó el cambio, ambos dispositivos aún podían comunicarse con la red remota a pesar de que la puerta de enlace y la máscara de subred predeterminadas eran 192.168.65.1/255.255.255.0 respectivamente.
Después de esto, mientras monitoreaba, perdí la comunicación con uno de los dispositivos, pero el otro permaneció en línea. Rectifiqué el problema configurando correctamente la máscara de subred y la puerta de enlace predeterminada en ambos dispositivos, pero me preguntaba si alguien podría explicar por qué pude comunicarme con un dispositivo y no con el otro a pesar de que ambos dispositivos tenían máscaras Sunet/puertas de enlace predeterminadas configuradas incorrectamente.
¡Gracias!
Respuesta1
Las máscaras de red (máscaras de subred) no forman parte de la dirección IP y no van a ninguna parte del encabezado IP; un paquete dirigido a "192.168.65.96" todavía está dirigido a "192.168.65.96" sin importar la máscara de red utilizada.
En cambio, las máscaras de red funcionan como una forma derutasy sólo se utilizan al enviar paquetes, pero no al recibirlos; es decir, un host con una máscara de red incorrecta configurada aún podrá recibir paquetes pero es posible que no pueda enviarlos correctamente.
Al enviar paquetes, se verifica la máscara de red para determinarsi la dirección IP de destino está en la misma subredcomo host de envío:
Si tanto el origen como el destino están en la misma subred, eso significa que es posible enviar paquetes directamente al nivel MAC ("capa 2")sin usar una puerta de enlacey el remitente utilizará ARP para resolver directamente la dirección IP en la dirección MAC del receptor.
Entonces, si ambos hosts están dentro de la misma subred (según la máscara de red de cada uno), entonces no importa si la dirección de la puerta de enlace está mal configurada porque no se necesita una puerta de enlace en esa situación.
si sonnoen la misma subred, entonces se requiere una puerta de enlace y el remitente utilizará ARP para encontrar la dirección MAC de la puerta de enlace.
Entonces una máscara de red mal configurada solo afectará las comunicaciones con aquellas direcciones para las cuales dé resultados incorrectos al mensaje "¿Misma subred?" prueba.
Si tu máscara de red esdemasiado amplia(la longitud del prefijo es demasiado corta) y cubre más direcciones de las que debería, entonces ya no podrá enviar paquetes a las direcciones que la máscara de red incluye accidentalmente (pero que en realidad no son "locales" a su subred).
Al intentar enviar paquetes a dichas direcciones, su host intentará resolverlos mediante ARP como si fueran locales, aunque no lo sean, es decir, las solicitudes ARP no les llegarán.
Por ejemplo, si está en la subred 192.168.1.0/24, pero configura accidentalmente su máscara de red como /16 (255.255.0.0), perderá la comunicación con el resto de 192.168.xx (aunque aún podrá comunicarse con 192.168.1.x como antes).
(Aunque las comunicacionespuedeAún será posible si su puerta de enlace implementa 'Proxy ARP' y responde esas solicitudes ARP en nombre del "otro lado"; en realidad, esto a veces lo hacen los ISP como 'aislamiento del cliente' o como un paso intermedio para dividir una subred grande. De hecho, Proxy-ARP se utilizó para dividir grandes redes con clase antes de que se inventara la división en subredes).
De cualquier manera, aún podrá comunicarse con hosts locales que realmente se encuentran en su subred, así como con hosts remotos que la máscara de red incorrecta no cubre, por lo que esto puede pasar desapercibido por un tiempo.
Si la máscara de red esdemasiado estrecho(la longitud del prefijo es demasiado larga) y no cubre las direcciones que debería, entonces obtendrá el resultado opuesto: es posible que no pueda comunicarse con la parte de su subred que la máscara de red excluye accidentalmente, porque su host cree que es necesario pasar por una puerta de enlace para esas direcciones.
Sí hayesuna puerta de enlace, entonces puede simplemente enrutar paquetes de regreso a la misma subred, y las cosas seguirán funcionando, pero de manera muy ineficiente. La puerta de enlace también podría enviarle paquetes ICMP "Redirect", informándole que existe una ruta más directa, y su sistema operativo podría actualizar automáticamente su tabla de enrutamiento para permitir comunicaciones directas nuevamente. Por lo tanto, la mala configuración puede pasar desapercibida durante mucho tiempo.
Pero si la máscara de red es demasiado estrechayla puerta de enlace es incorrecta, entonces no podrá enviar paquetes a esas direcciones en absoluto; su host intentará dirigirlos a través de la puerta de enlace inexistente.
En ambas situaciones, los únicos destinos afectados son aquellos para los cuales las máscaras de red "correctas" e "incorrectas" dan resultados diferentes.