¿Debo dividir mi red de datos en 2 VLAN separadas?


9

Actualmente estoy usando 10.54.0.0 / 19 para todos mis clientes e impresoras de escritorio. Tenemos aproximadamente 550 clientes / impresoras.

Además del ancho de banda, que apenas se está utilizando, ¿hay alguna otra razón para dividir mi red de datos o ir a una subred más pequeña que la / 19 que estoy usando actualmente?


44
... por qué / 19? / 16 o / 24 habría sido bastante más fácil de administrar, sin ningún costo adicional.
Massimo

/ 24 no habría acomodado a 550 clientes e impresoras.
Alex Berry

@Alex Berry: /24no se puede acceder a 550 dispositivos, eso es cierto; pero tener un par de /24redes podría (uno para impresoras, uno para la contabilidad, una para recursos humanos, etc.)
Warren

@warren, esto es cierto, sin embargo, pensé que estaría implícito en su pregunta con el uso de diferentes vlans.
Alex Berry

Además, ¿por qué un en /19lugar de un /21?
warren

Respuestas:


11

Tener clientes de escritorio en un / 19 le brinda un dominio de transmisión increíblemente grande. Eso significa que las solicitudes DHCP, consultas arp, mDNS, netbios, descubrimiento de impresoras IPP, etc., paquetes de un solo host se están replicando 550x. En general, un / 24 es la subred más grande en la que desea colocar hosts reales. Dado que se encuentra en el espacio RFC1918 , puede usar un diferente /24(o lo que sea) para cada división lógica que pueda encontrar.

La verdadera pregunta que debe hacerse es si debería usar subredes más pequeñas. La respuesta a la cual es "probablemente". Si elige implementar eso con VLAN o no, es realmente ortogonal.


55
¿Por qué es a / 24 la subred más grande en la que desearía ubicar hosts reales? ¿Existe una métrica que pueda evaluarse objetivamente para corroborar esa conclusión, por ejemplo, si (Paquetes de difusión / Todos los demás paquetes)> .25, entonces debe subred?
Chris Magnuson el

1
Ciertamente, puede llegar a métricas, como qué porcentaje de su ancho de banda está dispuesto a permitir que la carga de transmisión media utilice. Cuanto más grande es la subred, más hosts pueden verse afectados por un solo host mal comportamiento Imagine que una compañía de Fortune 500 se pone de rodillas porque todos sus hosts están en un / 8 y uno de ellos hace una inundación de transmisión ... Además, usted tiene considerar que no todas las redes son un montón de PC conectadas a un conmutador gigE barato. Es bastante común que las empresas tengan varias oficinas conectadas por enlaces MOE o WAN. 1mbit / s puede no ser mucho en un lan pero ...
Joshua Hoblitt

Para mí, / 24 tiene más sentido para la conexión inalámbrica. Puede hacerse mucho más grande en redes conmutadas sin muchos problemas. Sin embargo, definitivamente tiene sentido que los extremos separados de los enlaces MOE / WAN estén en subredes diferentes.
Joel Coel

Estoy de acuerdo en que 550 hosts no son completamente irracionales en una sola subred, pero un valor de / 19 (8K IP) en la mayoría de los escenarios sí lo sería. Señaló específicamente que tenía escritorios en su subred única.
Joshua Hoblitt

4

Debido a que su red está infrautilizada y tiene solo unos pocos hosts, la única razón para dividir el / 19 en prefijos más pequeños sería la seguridad. Esto significa que usará VLAN y un enrutador para permitir / filtrar la comunicación entre VLAN.

Evalúe cuánto tiempo llevará cambiar las IP y las aplicaciones que están usando esas IP y vea si vale la pena cambiar a otros prefijos. Con menos recursos, puede encontrar y eliminar generadores de transmisión innecesarios, si están afectando el tráfico de su red.

Si agrega más hosts, puede alcanzar algunas limitaciones, como el número máximo de MAC en la tabla de direcciones MAC de los conmutadores o el número de entradas ARP en la tabla ARP en el enrutador. Si alcanza este límite, notará grandes retrasos o comportamientos extraños (hosts que no pueden comunicarse entre sí, transmisiones excesivas).

Si divide su red en prefijos más pequeños, pero no usa VLAN, no reducirá el tráfico de transmisión y no hará que su red sea más segura. Incluso si divide su red en VLAN, pero transporta las VLAN en todos los conmutadores (por ejemplo, no está utilizando la poda de VLAN) el tráfico de difusión afectará a todos los conmutadores.

Algunos equipos, como los conmutadores Cisco , también pueden limitar la transmisión (por velocidad o por tipo).

Planificación de la red: antes de realizar cualquier cambio, cree casos de uso con problemas que pueda encontrar en su red y planifique en función de esos supuestos.


+1 para obtener información sobre lo que sucede cuando la tabla MAC o la tabla ARP se llena
dunxd

3

550 hosts no está totalmente descartado para una sola subred. Básicamente necesita evaluar sus propios requisitos. Si los paquetes de difusión están afectando (o se prevé que impactarán) el rendimiento de su red de una manera que impida la función de su negocio, entonces debe separar sus hosts en diferentes subredes en diferentes VLAN. Si no está afectando el negocio, entonces no hay necesidad de hacerlo.

Parece que el ancho de banda no es una preocupación, por lo que puede que no haya una razón comercial justificable para invertir en su infraestructura de esta manera. Otras razones generalmente girarían en torno a las separaciones de seguridad, pero solo usted podría decirnos si su empresa tiene necesidades de seguridad que no se satisfacen con la infraestructura actual.


¿Alguna recomendación sobre qué número de hosts quedaría fuera de discusión y posiblemente alguna métrica que pueda evaluarse que indique cuándo debe subred específicamente para aislar dominios de difusión?
Chris Magnuson

@obligatory - Esa es una pregunta difícil de responder. Cada ambiente es un poco diferente. Puedo decir que 550 hosts no es mucho de qué preocuparse en la mayoría de los entornos. Sin embargo, si hay transmisiones en exceso debido a alguna aplicación LOB, eso puede cambiar totalmente la situación. Básicamente, todo depende.
Jason Berg
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.