it-swarm-es.com

¿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.

37
Adam Davis

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 de tipo de escritorio típicos, normalmente pueda implementar cientos de nodos en una sola subred sin ningún problema. Tener mucho tráfico de difusió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 de 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 tendrá que reenviarse a la otra subred y emitirse nuevamente. De hecho, eso realmente agrega tráfico adicional (y latencia) a ambas subredes si lo piensa bien.

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 organizativas, administrativas y de límites 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.

En relación con las reglas generales en la planificación de subredes:

  • Considere las subredes para cada departamento/división organizativa diferente, especialmente a medida que no sean triviales (¡¡más de 50 nodos !?) en tamaño.
  • 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 un 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. La configuración 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 debería tiene una razón para existir que supera la sobrecarga de mantener la topología lógica más sofisticada.

33
Tall Jeff

Si se trata de un solo sitio, no se moleste a menos que tenga más de una docena 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 cabeza)

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.

7
Alnitak

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.

7
Mark Turner

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 subred ". 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

4
jj33

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 servidor, segmentos orientados a Internet (uno por servicio orientado a Internet es popular hoy en día, no solo "un dmz servirá") y así sucesivamente.

3
Oskar Duveborn

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 amplias 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 haya muchas otras razones para apoyar el enfoque se-small-broadcast-domains -.

3
PEra

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 puede mover uno de ellos a otra ciudad, porque entonces tendrá que dividir ese Niza/24 o volver a numerar 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 en que lo hace), 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. Aislamiento de fallos.

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

3
Thomas

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 algún motivo, ¿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 el mismo 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 el mismo VLAN como servidores en este momento, eso no es muy factible.

Si bien no necesitamos otro VLAN para las PDU, puede hacer que algunas cosas sean más fáciles. 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, le dimos a las PDU su propia VLAN no significa que siempre tengamos que dar a sus grupos pequeños de dispositivos su propia VLAN. Pero en este caso, podría tener sentido. Si un grupo de los dispositivos no necesitan tener su propio VLAN y no hay ventajas para hacerlo, entonces puede considerar dejar las cosas como están.

2
Webs