¿La mejor forma de segmentar tráfico, VLAN o subred?

13

Tenemos una red de tamaño medio de alrededor de 200 nodos y actualmente estamos en el proceso de reemplazar los viejos conmutadores en cadena con conmutadores apilables o de estilo chasis.

En este momento, nuestra red se divide a través de subredes: producción, administración, propiedad intelectual (IP), etc., cada una en una subred separada. ¿Sería más beneficioso crear VLAN en lugar de subredes?

Nuestro objetivo general es evitar cuellos de botella, separar el tráfico por motivos de seguridad y gestionar el tráfico con mayor facilidad.

el pájaro
fuente
1
probablemente sus diferentes vlans se utilizarán para tener subredes separadas en ellos.
pQd
1
Puede encontrar útil la respuesta de Evan a esta pregunta que hice hace un tiempo: serverfault.com/questions/25907/…
Kyle Brandt el

Respuestas:

16

Las VLAN y subredes resuelven diferentes problemas. Las VLAN funcionan en la capa 2 , alterando así los dominios de difusión (por ejemplo). Mientras que las subredes son la capa 3 en el contexto actual

Una sugerencia sería implementar ambos

Tenga, por ejemplo, VLAN 10-15 para sus diferentes tipos de dispositivos (Dev, Test, Production, Users, etc.)

VLAN 10, puede tener la subred 192.168.54.x / 24 VLAN 11, puede tener la subred 192.168.55.x / 24

Y así

Sin embargo, esto requeriría que tenga un enrutador dentro de su red

Depende de usted en qué ruta se encuentre (conoce su red mejor que nunca). Si cree que el tamaño de su dominio de transmisión será algún tipo de problema, utilice las VLAN. Si cree que el tamaño de sus dominios de administración de red (por ejemplo, su red de administración), posiblemente use una red más cercana a un / 16 sobre un / 24

Sus 200 nodos encajarán en un / 24, pero eso obviamente no le da muchas posibilidades de crecimiento

Por lo que parece, ya está utilizando diferentes subredes para diferentes tipos de dispositivos. Entonces, ¿por qué no seguir con eso? Si lo desea, puede vincular cada subred a una VLAN. Sin embargo, la segmentación de capa 2 hará que el comportamiento de su red cambie de cómo se comporta actualmente

Tendría que investigar el impacto potencial de ese

Ben Quick
fuente
2
+1 - Dijo casi todo lo que quería. Si fuera a desechar el diseño actual de subredes que tiene, mi única sugerencia adicional sería explorar la configuración de un espacio de direcciones utilizando un / 22 o / 23. Posiblemente "elimine" bits si encuentra que necesita más subredes. Después de todo, ya no estamos limitados a / 16 o / 24. Luego, coloque cada subred en su propia VLAN para reducir el tráfico de transmisión.
romandas
13

(He estado en la carretera todo el día y me perdí el salto en este ... Aún así, tarde en el juego veré qué puedo hacer).

Por lo general, crea VLAN en Ethernet y asigna subredes IP 1 a 1 en ellas. Hay maneras de no hacer esto, pero si se queda en un mundo estrictamente "simple" crearía una VLAN, piense en una subred IP para usar en la VLAN, asigne a algún enrutador una dirección IP en esa VLAN, conecte ese enrutador a la VLAN (ya sea con una interfaz física o una subinterfaz virtual en el enrutador), conecte algunos hosts a la VLAN y asígneles direcciones IP en la subred que definió, y enrute su tráfico dentro y fuera de la VLAN.

No debe comenzar a dividir en subredes una LAN Ethernet a menos que tenga buenas razones para hacerlo. Las mejores dos razones son:

  • Mitigación de problemas de rendimiento. Las LAN Ethernet no pueden escalar indefinidamente. Las transmisiones excesivas o la inundación de tramas a destinos desconocidos limitarán su escala. Cualquiera de estas condiciones puede ser causada por hacer que un solo dominio de difusión en una LAN Ethernet sea demasiado grande. El tráfico de transmisión es fácil de entender, pero la inundación de tramas a destinos desconocidos es un poco más oscura. Si obtiene tantos dispositivos que las tablas MAC de su conmutador se desbordan, los conmutadores se verán obligados a inundar las tramas que no son de difusión en todos los puertos si el destino de la trama no coincide con ninguna entrada en la tabla MAC. Si tiene un dominio de difusión único lo suficientemente grande en una LAN Ethernet con un perfil de tráfico que los hosts hablan con poca frecuencia (es decir,

  • Un deseo de limitar / controlar el tráfico que se mueve entre los hosts en la capa 3 o superior. Puede hacer un poco de piratería informática examinando el tráfico en la capa 2 (ebtables de ala Linux), pero esto es difícil de administrar (porque las reglas están vinculadas a las direcciones MAC y el cambio de NIC requiere cambios de reglas) puede causar lo que parecen ser comportamientos realmente extraños (hacer El proxy transparente de HTTP en la capa 2, por ejemplo, es extraño y divertido, pero no es natural y puede ser muy poco intuitivo para solucionar problemas, y generalmente es difícil de hacer en las capas inferiores (porque las herramientas de la capa 2 son como palos) y rocas para lidiar con las preocupaciones de la capa 3+). Si desea controlar el tráfico IP (o TCP, o UDP, etc.) entre hosts, en lugar de atacar el problema en la capa 2, debe subred y pegar firewalls / enrutadores con ACL entre las subredes.

Los problemas de agotamiento del ancho de banda (a menos que sean causados ​​por paquetes de difusión o inundación de tramas) no se resuelven con las VLAN y las subredes típicamente. Suceden debido a la falta de conectividad física (muy pocas NIC en un servidor, muy pocos puertos en un grupo de agregación, la necesidad de avanzar a una velocidad de puerto más rápida) y no pueden resolverse dividiendo subredes o implementando VLAN desde que ganó No aumente la cantidad de ancho de banda disponible.

Si ni siquiera tiene algo simple como MRTG ejecutando gráficas de estadísticas de tráfico por puerto en sus conmutadores, ese es realmente su primer negocio antes de comenzar a introducir cuellos de botella con subredes bien intencionadas pero desinformadas. El recuento de bytes sin procesar es un buen comienzo, pero debe seguirlo con la detección selectiva para obtener más detalles sobre los perfiles de tráfico.

Una vez que sepa cómo se mueve el tráfico en su LAN, puede comenzar a pensar en subredes por razones de rendimiento.

En cuanto a la "seguridad", necesitará saber mucho sobre el software de su aplicación y cómo habla antes de poder continuar.

Hice un diseño para una LAN / WAN de tamaño razonable para un cliente médico hace unos años y me pidieron que pusiera listas de acceso en la entidad de capa 3 (un módulo supervisor Cisco Catalyst 6509) para controlar el tráfico que se mueve entre las subredes mediante un " ingeniero "que tenía poca comprensión de qué tipo de trabajo preliminar realmente requeriría pero estaba muy interesado en la" seguridad ". Cuando regresé con una propuesta para estudiar cada aplicación para determinar los puertos TCP / UDP necesarios y los hosts de destino, recibí una respuesta impactante del "ingeniero" que decía que no debería ser tan difícil. Lo último que escuché es que están ejecutando la entidad de capa 3 sin listas de acceso porque no pudieron hacer que todo su software funcionara de manera confiable.

La moraleja: si realmente va a tratar de abotonar el acceso de paquetes y de nivel de transmisión entre las VLAN, prepárese para hacer mucho trabajo de campo con el software de aplicación y el aprendizaje / ingeniería inversa de cómo se habla por cable. La limitación del acceso de los hosts a los servidores a menudo se puede lograr con la funcionalidad de filtrado en los servidores. Limitar el acceso al cable puede proporcionar una falsa sensación de seguridad y calmar a los administradores en una complacencia en la que piensan "Bueno, no necesito configurar la aplicación de forma segura porque los hosts que pueden hablar con la aplicación están limitados por" red'." Le recomiendo que audite la seguridad de la configuración de su servidor antes de comenzar a limitar la comunicación de host a host en el cable.

Evan Anderson
fuente
2
Me alegra ver una voz de razón después de las respuestas que aconsejan ir / 16.
pQd
44
Puede crear subredes en subredes arbitrariamente grandes o pequeñas. Lo que importa es la cantidad de hosts en el dominio de subred / broadcast, no la cantidad de hosts posibles (siempre que tenga suficiente espacio de direcciones). ¿Cuál es la expresión? No es el tamaño de su subred lo que importa, sino cómo lo usa. > sonrisa <
Evan Anderson
@Evan Anderson: lo sé. pero debe admitir que 64k es demasiado, probablemente nunca se utilizará y puede generar problemas cuando se necesita introducir el enrutamiento [por ejemplo, para conectar DC / oficinas / etc remotas].
pQd
1

El 99% del tiempo, una subred debe ser equivalente a una VLAN (es decir, cada subred de acceso debe asignarse a una sola VLAN).

Si tiene hosts de más de una subred IP en la misma VLAN, anula el propósito de las VLAN, ya que las dos (o más) subredes estarán en el mismo dominio de difusión.

Alternativamente, si coloca una subred IP en varias VLAN, los hosts en la subred IP no podrán comunicarse con los hosts en la otra VLAN a menos que su enrutador tenga habilitado el proxy ARP .

Murali Suriar
fuente
-1: las VLAN dividen los dominios de difusión. Los dominios de colisión están divididos por puentes o puentes multipuerto más comúnmente conocidos como conmutadores. Las subredes IP y los dominios de difusión / colisión no tienen nada que ver entre sí en el caso general. En el caso específico de IP sobre Ethernet, es común que una subred IP se asigne a un solo dominio de difusión (porque ARP, el protocolo utilizado para resolver las direcciones IP a las direcciones de hardware de Ethernet se basa en la difusión), pero es posible utilizar trucos inteligentes con proxy ARP para que una subred abarque varios dominios de difusión.
Evan Anderson
@Evan: buen punto, eso me enseñará a escribir respuestas en las primeras horas de la mañana. :) Sin embargo, mantengo los puntos restantes; tener varias subredes en la misma VLAN hará que su tráfico de difusión L2 abarque varias subredes; tener múltiples VLAN para la misma subred funcionará, pero el proxy ARP realmente no es algo que deba usar si puede evitarlo.
Murali Suriar el
-1 eliminado: todo lo demás que dijiste es ciertamente exacto. También estoy de acuerdo, re: proxy ARP-- No lo usaría en el "mundo real" a menos que tuviera una razón convincente.
Evan Anderson
"Las subredes IP y los dominios de difusión / colisión no tienen nada que ver entre sí en el caso general". No, ciertamente lo hacen en el caso general. Cada subred tiene un número de red y una dirección de difusión asociada. Además de ARP, tiene otros paquetes de transmisión. Sería un error hacer esta declaración sin saber si tienen tráfico de multidifusión en su red. Los clientes DHCP utilizan la difusión IP para conocer los servidores DHCP.
Kilo
1
@Evan Anderson ¿Qué extrañé aquí? Retira su -1. Los dominios de colisión se derraman mediante puertos de conmutadores. Decir 2 o subredes en un dominio de colisión no tiene sentido. Creo que quiere decir 2 o más subredes en un dominio de difusión .
JamesBarnett
-5

Estoy de acuerdo con David Pashley :

  1. Yo uso un solo / 16 para todo.
    • pero está segmentado en varias VLAN, unidas por un puente de software en una máquina Linux.
    • En este puente, tengo varias reglas de iptables para filtrar el acceso entre grupos.
    • No importa cómo segmente, use rangos de IP para agrupar, facilita la reestructuración y los casos especiales.
Javier
fuente
2
¡Suena como una pesadilla con la que lidiar!
Evan Anderson
2
-1 No dijiste qué tan grande de una red mantienes, a menos que estés hablando de un proyecto de investigación, no puedo por mi vida pensar en una razón para usar ese tipo de configuración. Por definición, las subredes son "rangos de IP" utilizados para la agrupación. Parece que está reinventando la capa 3 mediante el uso de un cuadro de Linux para hacer su enrutamiento en la capa 2. Es probable que cree problemas que están ocultos por la complejidad innecesaria. Esto crea algo que será difícil de entender para los demás y mucho menos para solucionar problemas.
Rik Schneider