¿Cuántas VLAN son muy pocas y demasiadas?


23

Actualmente estamos ejecutando una red de más de 800 PC y más de 20 servidores, la infraestructura de red está en la línea de Core Switch 10Gb-> Area Switch 2GB-> Local Switch 1GB-> Desktop. Todos los equipos 3Com en funcionamiento (1).

Tenemos 3 interruptores de área para cuatro áreas (A, B, C, D se fusionan con el núcleo), cada interruptor de área tendrá entre 10 y 20 interruptores locales conectados a estos. También hay un interruptor central de respaldo, de menor potencia pero conectado como el interruptor principal principal.

También tenemos un sistema telefónico IP. Las computadoras / servidores y swicthes están en un rango de ip 10.x, los teléfonos en un rango de 192.168.x. Las computadoras generalmente no tienen que hablar entre sí, excepto en los laboratorios de computadoras, pero sí deben poder hablar con la mayoría de nuestros servidores (AD, DNS, Exchange, almacenamiento de archivos, etc.)

Cuando configuramos, se decidió que debíamos tener 3 VLAN, una para conmutadores y computadoras, una para teléfonos y otra para la replicación del servidor (esto iba en contra del consejo de los ingenieros de 3Com). La red ha estado estable y funcionando desde este punto (2), pero ahora hemos comenzado a actualizar a SAN y al entorno de virtualización. Ahora, dividir esta nueva infraestructura en VLAN separadas tiene sentido, y revisar cómo se configuran nuestros VLANS parece sensato.

Ahora se propone que las VLAN se configuren habitación por habitación, es decir, un laboratorio de computación con más de 5 PC debe ser su propia VLAN, pero si seguimos este modelo, buscaremos al menos 25 "nuevas" VLAN , más las VLAN para servidores SAN / virtuales. Lo que me parece agregará una cantidad excesiva de administración, aunque estoy bastante feliz de que se demuestre que estoy equivocado.

¿Cuál sería la mejor práctica parece sugerir? ¿Hay una cierta cantidad de PC que se recomienda no pasar / bajar en una VLAN?

(1) Los conmutadores 3Com (3870 y 8800) enrutan entre VLAN de manera diferente a como lo hacen otros, no requiere un enrutador separado ya que son de capa 3.

(2) A veces recibimos altas tasas de descarte, o cambios de STP, y en el momento en que el director de la red de 3Com informa que los conmutadores tienen poca carga y son lentos para responder a los pings, o un conmutador fallido que logra desconectar la red (¡todos los VLAN del teléfono y la computadora! , una vez, no tengo idea de por qué)

Respuestas:


36

Parece que alguien en su organización quiere crear VLAN sin comprender las razones por las que lo haría y los pros / contras asociados con ello. Parece que necesita hacer algunas mediciones y encontrar algunas razones reales para hacerlo antes de seguir adelante, al menos con la locura "VLAN para una habitación".

No debe comenzar a dividir una LAN Ethernet en VLAN a menos que tenga buenas razones para hacerlo. Las dos mejores 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 (¡ tanto que ninguno de los otros carteles aquí ni siquiera lo menciona!) 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, con poca frecuencia que sus entradas hayan caducado de las tablas MAC en sus conmutadores), entonces también puede obtener una inundación excesiva de tramas .

  • 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 cambiar las 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) generalmente no se resuelven con las VLAN. 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 segmentación de VLAN bien intencionada pero desinformada. 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 segmentar la LAN por razones de rendimiento.

Si realmente va a intentar abrochar el paquete y el acceso a nivel de transmisión entre las VLAN, prepárese para hacer mucho trabajo preliminar 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 en el 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.

Por lo general, crea VLAN en Ethernet y asigna subredes IP 1 a 1 en ellas. Necesitará MUCHAS subredes IP para lo que está describiendo, y potencialmente muchas entradas de la tabla de enrutamiento. Planifique mejor esas subredes con VLSM para resumir las entradas de su tabla de enrutamiento, ¿eh?

(Sí, sí, hay formas de no usar una subred separada para cada VLAN, pero si se queda en un mundo estrictamente "normal" crearía una VLAN, piense en una subred IP para usar en la VLAN, asigne 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 y fuera de la VLAN).


2
Esta es una excelente explicación. Solo agregaría que, con la mayoría del hardware moderno, la segmentación no es tan complicada siempre que se dé cuenta de que las VLAN deberán enrutarse. No le beneficiará mucho tener una configuración de VLAN súper eficiente que use un enrutador muy sobreexpresado en un dispositivo para pasar el tráfico entre los segmentos.
Greeblesnort

2

Las VLAN solo son realmente útiles para restringir el tráfico de difusión. Si algo va a transmitir mucho, luego sepárelo en su propia VLAN, de lo contrario no me molestaría. Es posible que desee tener una duplicación virtualizada de un sistema en vivo en la misma red y desee usar el mismo rango de direcciones, de nuevo, eso podría valer una VLAN separada.


Estamos ejecutando XP sin WINS en este momento; hacer un nbtstat -r parece sugerir que estamos recibiendo una gran cantidad de tráfico de transmisión.
Tinas

1
Mídalo con algo como Wireshark y vea qué sucede. WINS no es una cosa horrible. Si descubre que está recibiendo muchas solicitudes de búsqueda de nombres de NetBIOS, intente ingresar los nombres correctos en DNS para evitar las solicitudes o simplemente ejecute WINS.
Evan Anderson

2

Las VLAN son buenas como nivel de seguridad adicional. No sé cómo lo maneja 3Com, pero generalmente puede segmentar diferentes grupos funcionales en diferentes VLAN (por ejemplo, Contabilidad, WLAN, etc.). Luego puede controlar quién tiene acceso a una VLAN en particular.

No creo que haya una pérdida significativa de rendimiento si hay muchas computadoras en la misma VLAN. No me resulta práctico segmentar LAN en una habitación por habitación, pero de nuevo, no sé cómo 3Com lo maneja. Por lo general, la directriz no es el tamaño, sino la seguridad u operación.

En efecto, no veo ninguna razón para incluso segmentar LAN en diferentes VLAN si no hay ganancias de seguridad u operativas.


1

A menos que tenga 25 grupos de prueba y desarrollo que regularmente eliminan la red con inundaciones de transmisión, 25 VLAN por habitación son 24 demasiado.

¡Obviamente su SAN necesita su propia VLAN y no la misma VLAN que los sistemas virtuales LAN y acceso a Internet! Todo esto se puede hacer a través de un único puerto ethernet en el sistema host, por lo que no se preocupe por dividir esas funciones.

Si tiene problemas de rendimiento, considere colocar su teléfono y SAN en hardware de red separado, no solo en VLAN.


0

Siempre habrá tráfico de transmisión, ya sean transmisiones de resolución de nombre, transmisiones ARP, etc. Lo importante es controlar la cantidad de tráfico de transmisión. Si supera el 3 - 5% del tráfico total, entonces es un problema.

Las VLAN son buenas para reducir el tamaño de los dominios de transmisión (como dijo David) o por seguridad, o para crear redes de respaldo dedicadas. Realmente no se consideran dominios de "administración". Además, agregará complejidad de enrutamiento y sobrecarga a su red mediante la implementación de VLAN.


Estuve contigo hasta que mencionaste el enrutamiento por encima. El enrutamiento tiene costos, pero generalmente el hardware que hace L2 / L3 reenviará los paquetes de un vlan a otro (y de un puerto a otro) a las mismas velocidades que si reenvía a través de L2.
Chris

Es cierto que no entendí la parte en la publicación original sobre los conmutadores 3COM que pueden enrutar el tráfico entre las VLAN sin necesidad de enrutadores (por lo que voy a suponer que son conmutadores L3). Gracias.
joeqwerty

Pueden funcionar a velocidad de cable, pero aún son enrutadores para configurar y administrar, incluso si son solo entidades de capa 3 dentro de los conmutadores. Si "cambian" los paquetes en la capa 3, son enrutadores.
Evan Anderson

0

En general, solo desea considerar el uso de VLAN cuando necesita poner en cuarentena los dispositivos (como un área donde los usuarios pueden traer sus propias computadoras portátiles, o cuando tiene una infraestructura de servidor crítica que debe protegerse) o si su dominio de transmisión es demasiado alto.

Los dominios de transmisión generalmente pueden tener aproximadamente 1000 dispositivos de gran tamaño antes de que comience a ver problemas en las redes de 100Mbit, aunque lo reduciría a 250 dispositivos si se trata de áreas de Windows relativamente ruidosas.

En su mayor parte, las redes modernas no necesitan VLAN a menos que esté haciendo esta cuarentena (con el firewall apropiado usando ACL, por supuesto) o limitación de transmisión.


1
Son útiles para mantener la pepita de Contador en la creación de una cámara web con el IP del servidor de correo ...
Chris

0

También son útiles para evitar transmisiones DHCP para llegar a dispositivos de red no deseados.


1
La mitigación de los problemas de rendimiento ya se ha mencionado, gracias.
Chris S
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.