El sitio del cliente no tiene direcciones IP, quiere pasar de / 24 a / 12 máscara de red ... ¿Mala idea?

Uno de mis sitios de clientes me llamó para pedirme que cambiara las máscaras de subred de los servidores Linux que administro allí mientras vuelven a IP / cambian la máscara de red de su red según un esquema 10.0.0.x.

"¿Puede cambiar las máscaras de red del servidor Linux de 255.255.255.0 a 255.240.0.0?"

¿Quieres decir 255.255.240.0?

"No, 255.240.0.0".

¿Estás seguro de que necesitas tantas direcciones IP?

"Sí, nunca queremos quedarnos sin direcciones IP".

Una comprobación rápida de la hoja de trucos de subred muestra:

• una máscara de red 255.255.255.0 , a / 24 proporciona 256 hosts. Está claro que una organización puede agotar esa cantidad de direcciones IP.
• una máscara de red 255.240.0.0 , a / 12 proporciona 1,048,576 hosts. Este es un sitio pequeño de <200 usuarios. Dudo que asignen más de 400 direcciones IP, alguna vez ... Tal vez 500, pero en ese punto, deberían establecerse más subredes / VLAN.

Sugerí algo que proporciona menos hosts, como un / 22 o / 21 (1024 y 2048 hosts, respectivamente), pero no pude dar una razón específica contra el uso de la subred / 12.

¿Hay algo por lo que este cliente deba preocuparse? ¿Hay alguna razón específica por la que no deberían usar una máscara tan increíblemente grande en su entorno?

• Como se indicó en otras respuestas, tener demasiados hosts en el dominio de transmisión realmente puede comenzar a hacer que las transmisiones sean un desastre.

  Necesitarán mucha expansión en la subred antes de que se convierta en un problema potencial.

• La planificación del crecimiento futuro se convierte en un desastre.

  Agregar sitios adicionales con su propio espacio IP se vuelve difícil cuando ya ha establecido una huella innecesariamente enorme en el espacio disponible.

• Los límites de seguridad de la red interna se vuelven imposibles.

  Asignar diferentes subredes a diferentes grupos de usuarios y dividir servidores de baja seguridad / servidores de alta seguridad / interfaces de administración restringidas de servidores / almacenamiento / dispositivos de red se sale de la ventana.

  La computadora portátil de cualquier usuario que detectó un virus en casa puede envenenar ARP a la red y quitar los servidores o ponerlos en el medio. No tiene forma de mantener un dispositivo comprometido alejado de ubicaciones sensibles de la red, como las interfaces de administración fuera de banda de los servidores. Un error tipográfico en una reconfiguración inocente de la configuración de red puede potencialmente causar un conflicto de IP con cualquier otro dispositivo en la red.

Si no planean crecer de alguna manera que requiera más subredes, y no planean agregar alguna complejidad o seguridad a su red, entonces está bien, ya que es efectivamente idéntico a su configuración de red actual, pero si Piden esto, obviamente están planeando expandirse.

Inútil en el mejor de los casos, y seriamente mala idea en el peor.

No, no hay nada de malo en usar una máscara más grande, si el número de hosts dentro permanece igual.

El único problema es que al hacer esto, los administradores de red se vuelven perezosos y no hacen subredes adecuadas, lo que resulta en una gran cantidad de hosts que se encuentran en el mismo dominio de difusión. Por ejemplo, cada solicitud ARP es una transmisión, y todas las máquinas (en el mismo dominio de transmisión) tienen que procesarla (aunque generalmente una responde). Lo mismo ocurre con otros protocolos que utilizan difusión.

Otro problema podría ser el espacio de direcciones, ya que 10/8 tiene espacio para solo 16/12 redes, y si continúan con sus solicitudes / 12, solo pueden caber 15 más.

Algún software de seguridad, que realiza escaneos de puertos / pings, para descubrir hosts en vivo tomará mucho más tiempo que ahora (si lo tienen).

De lo contrario, no importa. Si solo tiene dos hosts, el rendimiento será el mismo con un / 30 o un / 8: el tamaño de la red no causa ningún problema de rendimiento.

Los argumentos en contra que puedo ver son que entonces tienes un dominio de difusión más grande y no tendrían tantas subredes adicionales disponibles desde 10.XXX

Para contrarrestar el argumento de las transmisiones, si solo planean un crecimiento futuro, el impacto en la red actual debería ser insignificante. También puede limitar sus servidores DHCP para distribuir solo una pequeña porción de la subred completa para controlar las cosas hasta que realmente se necesiten más IP.

Yo personalmente seguiría argumentando en contra de hacerlo, ya que es innecesario. Identifique la cantidad de direcciones de host necesarias y proyecte para el crecimiento futuro en lugar de simplemente lanzar una subred enorme.

Un empleador anterior hizo que un departamento grande decidiera rediseñar su red departamental alrededor de a / 16. Aunque este departamento en particular tenía múltiples sitios a través de enlaces de latencia relativamente alta (banda ancha del área municipal). Funcionó para ellos, y esto se produjo hace una década cuando los enlaces Gig solo eran comunes en el centro de datos y en los enlaces de distribución.

Hasta donde yo sabía, nunca tuvieron ningún problema con los problemas de transmisión. Como dije, esto fue hace aproximadamente una década con dispositivos mucho más estúpidos que manejan el tráfico de transmisión; los dispositivos modernos ni siquiera deberían pensarlo dos veces. Esta red en particular tenía aproximadamente el doble de los nodos que tenía.

Es decir, no hay nada de malo en una subred tan grande, siempre que su red pueda manejarla .