¿Cuándo / por qué comenzar a dividir en subredes una red?

¿En qué condiciones se comienza a considerar la división en subredes de una red?

Estoy buscando algunas reglas generales generales o desencadenantes basados ​​en métricas medibles que hacen que la división en subredes sea algo que debe considerarse.

Interesante pregunta.

Históricamente, antes del advenimiento de las redes totalmente conmutadas, la consideración principal para dividir una red en subredes tenía que ver con limitar el número de nodos en un solo dominio de colisión. Es decir, si tuviera demasiados nodos, el rendimiento de su red alcanzaría un pico y eventualmente colapsaría bajo una carga pesada debido a colisiones excesivas. El número exacto de nodos que se podían implementar dependía de muchos factores, pero en general no se podía cargar regularmente el dominio de colisión más allá del 50% del ancho de banda total disponible y aún así la red era estable todo el tiempo. 50 nodos en la red eran muchos nodos en esos días. Con usuarios de uso intensivo, es posible que haya completado en 20 o 30 nodos antes de tener que comenzar a dividir en subredes.

Por supuesto, con las subredes full-duplex totalmente conmutadas, las colisiones ya no son una preocupación y, suponiendo que los usuarios típicos de tipo escritorio, normalmente pueda implementar cientos de nodos en una sola subred sin ningún problema. Tener mucho tráfico de transmisión, como han mencionado otras respuestas, puede ser una preocupación dependiendo de qué protocolos / aplicaciones esté ejecutando en la red. Sin embargo, comprenda que dividir en subredes una red no necesariamente lo ayuda con sus problemas de tráfico de transmisión. Muchos de los protocolos usan la transmisión por una razón, es decir, cuando todos los nodos en la red realmente necesitan ver dicho tráfico para implementar las características de nivel de aplicación deseadas. Simplemente dividir en subredes la red en realidad no le compra nada si el paquete emitido también va a tener que reenviarse a la otra subred y emitirse nuevamente.

En términos generales, hoy en día, las razones principales para dividir en subredes las redes tienen mucho más que ver con consideraciones de límites organizativos, administrativos y de seguridad que cualquier otra cosa.

La pregunta original solicita métricas medibles que desencadenan consideraciones de subredes. No estoy seguro de que haya alguno en términos de números específicos. Esto va a depender dramáticamente de las 'aplicaciones' involucradas y no creo que haya realmente ningún punto desencadenante que generalmente se aplique.

Relativo a las reglas generales en la planificación de subredes:

• Considere las subredes para cada departamento / división organizacional diferente, especialmente a medida que su tamaño no sea trivial (¡¡más de 50 nodos !?).
• Considere las subredes para grupos de nodos / usuarios que usan un conjunto de aplicaciones común que es distinto de otros usuarios o tipos de nodos (desarrolladores, dispositivos VoIP, piso de fabricación)
• Considere subredes para grupos de usuarios que tienen diferentes requisitos de seguridad (asegurar el departamento de contabilidad, Asegurar Wifi)
• Considere las subredes desde un brote de virus, violación de seguridad y perspectiva de contención de daños. ¿Cuántos nodos quedan expuestos / violados? ¿Cuál es un nivel de exposición aceptable para su organización? Esta consideración supone reglas de enrutamiento restrictivo (firewall) entre subredes.

Dicho todo esto, agregar subredes agrega cierto nivel de sobrecarga administrativa y potencialmente causa problemas relacionados con la falta de direcciones de nodo en una subred y tener demasiadas en otro grupo, etc. Las configuraciones de enrutamiento y firewall y la ubicación de servidores comunes en el red y tal involucrarse más, ese tipo de cosas. Ciertamente, cada subred debe tener una razón para existir que supere la sobrecarga de mantener la topología lógica más sofisticada.

Si se trata de un solo sitio, no se moleste a menos que tenga más de varias docenas de sistemas, e incluso entonces probablemente sea innecesario.

En estos días, con todos los que usan conmutadores de al menos 100 Mbps y más a menudo 1 Gbps, la única razón relacionada con el rendimiento para segmentar su red es si está sufriendo un exceso de tráfico de transmisión (es decir,> 2%, fuera de mi alcance)

La otra razón principal es la seguridad, es decir, DMZ para servidores públicos, otra subred para finanzas o una VLAN / subred separada para sistemas VoIP.

Limitar el alcance de cualquier requisito de cumplimiento que pueda tener (es decir, PCI) es un catalizador bastante bueno para segmentar algunas partes de su red. La segmentación de su aceptación de pagos / procesamiento y sistemas financieros puede ahorrar dinero. Pero, en general, dividir en subredes una red pequeña no le proporcionará mucho rendimiento.

Otra razón sería la calidad de servicio relacionada. Ejecutamos vlans de voz y datos por separado para que podamos aplicar QoS fácilmente al tráfico de voip.

Sabes, he estado pensando en esta pregunta más. Existen muchas buenas razones para diseñar una nueva red utilizando redes distintas (rendimiento, seguridad, QoS, limitación de los ámbitos DHCP, limitación del tráfico de difusión (que puede estar relacionado tanto con la seguridad como con el rendimiento)).

Pero cuando pienso en una métrica para rediseñar solo a la subred, y pienso en redes que he tenido que manejar en el pasado, todo lo que puedo pensar es "wow, eso tendría que tener una red realmente desordenada para hacerme completamente rediseñado para subredes ". Hay muchas otras razones: ancho de banda, utilización de la CPU de los dispositivos instalados, etc. Pero el hecho de dividirse en subredes en una red de datos pura generalmente no compraría una tonelada de rendimiento

Seguridad y calidad principalmente (siempre que el segmento de red en cuestión pueda soportar los nodos en cuestión, por supuesto). Una red separada para el tráfico de impresoras, voz / teléfono, departamentos aislados como IT Ops y, por supuesto, segmentos de servidores, segmentos orientados a Internet (uno por servicio orientado a Internet es popular hoy en día, no solo "un dmz servirá") y así sucesivamente.

Si espera escalar (está construyendo una red, no solo 5 servidores y eso será todo), comience el enrutamiento lo antes posible. Demasiadas redes son inestables y difíciles de cultivar porque crecieron orgánicamente y tienen demasiadas cosas de la capa 2.

Ejemplos:

• tiene dos servidores de nombres en el mismo segmento de red. Ahora no puedes mover uno de ellos a otra ciudad, porque entonces tendrás que dividir ese bonito / 24 o renumerar el DNS. Mucho más fácil si estuvieran en diferentes redes. No estoy hablando necesariamente de que estos se conviertan en anuncios separados de BGP para el mundo. Este ejemplo sería para un ISP a nivel nacional. También tenga en cuenta que algunas cosas en el área del proveedor de servicios no son tan fáciles como "simplemente registre el nuevo DNS en el registrador".
• La capa 2 bucles chupa el culo. Al igual que el árbol de expansión (y VTP). Cuando falla el árbol de expansión (y hay muchos casos cuando lo hace), lo eliminará todo debido a la inundación que toma la CPU del interruptor / enrutador. Cuando falla OSPF o IS-IS (u otros protocolos de enrutamiento) no bloqueará toda la red, y puede reparar un segmento a la vez. De fallos de aislamiento.

En resumen: cuando escales hasta donde creas que necesitas un árbol de expansión, considera la ruta en su lugar.

Personalmente, me gusta llevar la segmentación de la capa 3 lo más cerca posible de los interruptores de acceso, porque

• No me gusta Spanning Tree (puedes hacer que haga cosas muy divertidas si eres malvado)
• Especialmente en las redes Windoze, las transmisiones son un problema real.
• En redes privadas, tiene mucho espacio de IP para desperdiciar :)
• Incluso los conmutadores más baratos tienen capacidades de enrutamiento a velocidad de cable en este momento, ¿por qué no usarlos?
• Hace la vida más fácil cuando se trata de seguridad (por ejemplo, Auth y ACL en el egde, etc.)
• Mejores posibilidades de QoS para VoIP y material en tiempo real
• Puede distinguir la ubicación de un cliente desde su IP

Si se trata de redes extendidas más grandes / más anchas donde dos conmutadores / enrutadores centrales no son suficientes, los mecanismos de redundancia normales como VRRP tienen muchos inconvenientes (el tráfico pasa enlaces ascendentes varias veces, ...) OSPF no tiene.

Probablemente hay muchas otras razones para admitir el uso-small-broadcast-domains -approach.

Creo que el alcance de la organización es muy importante. Si hay 200 hosts en total o menos en una red y el tráfico no necesita segmentarse por alguna razón, ¿por qué agregar la complejidad de las VLAN y subredes? Pero cuanto mayor sea el alcance, más sentido tendrá.

Sin embargo, dividir las redes que normalmente no deberían serlo puede facilitar algunas cosas. Por ejemplo, nuestras PDU que suministran energía a los servidores están en la misma VLAN o subred que los servidores. Esto significa que nuestro sistema de escaneo de vulnerabilidades utilizado en nuestro rango de servidores también escanea PDU. No es un gran problema, pero no necesitamos PDU para escanear. También sería bueno para DHCP las PDU ya que son difíciles de configurar, pero dado que están en la misma VLAN que los servidores en este momento, eso no es muy factible.

Si bien no necesitamos otra VLAN para las PDU, puede facilitar algunas cosas. Y esto entra en el argumento de VLAN más vs menos que continuará para siempre.

Yo, solo creo que tengo VLAN donde tiene sentido. Si, por ejemplo, les dimos a las PDU su propia VLAN, no significa que siempre tengamos que darles a los pequeños grupos de dispositivos su propia VLAN. Pero más bien en este caso podría tener sentido. Si un grupo de dispositivos no necesita tener su propia VLAN y no hay ventajas para hacerlo, puede considerar dejar las cosas como están.