¿Cómo funcionan las VLAN?

¿Qué son las VLAN? ¿Qué problemas resuelven?

Estoy ayudando a un amigo a aprender redes básicas, ya que se ha convertido en el único administrador de sistemas de una pequeña empresa. Le he estado señalando varias preguntas / respuestas sobre Serverfault relacionadas con varios temas de redes, y noté una brecha: no parece haber una respuesta que explique desde los primeros principios qué son las VLAN. En el espíritu de Cómo funciona la división en subredes , pensé que sería útil tener una pregunta con una respuesta canónica aquí.

Algunos temas potenciales para cubrir en una respuesta:

• ¿Qué son las VLAN?
• ¿Qué problemas estaban destinados a resolver?
• ¿Cómo funcionaban las cosas antes de las VLAN?
• ¿Cómo se relacionan las VLAN con las subredes?
• ¿Qué son las SVI?
• ¿Qué son los puertos troncales y los puertos de acceso?
• ¿Qué es el VTP?

EDITAR: para ser claros, ya sé cómo funcionan las VLAN, solo creo que Serverfault debería tener una respuesta que cubra estas preguntas. Si el tiempo lo permite, presentaré mi propia respuesta también.

Las LAN virtuales (VLAN) son una abstracción que permite que una sola red física emule la funcionalidad de múltiples redes físicas paralelas. Esto es útil porque puede haber situaciones en las que necesite la funcionalidad de múltiples redes físicas paralelas, pero prefiere no gastar el dinero en comprar hardware paralelo. Hablaré sobre las VLAN Ethernet en esta respuesta (aunque otras tecnologías de red pueden admitir VLAN) y no profundizaré en cada matiz.

Un ejemplo contribuido y un problema

Como un ejemplo puramente imaginario, imagine que es dueño de un edificio de oficinas que alquila a inquilinos. Como beneficio del contrato de arrendamiento, cada inquilino obtendrá tomas de Ethernet en vivo en cada habitación de la oficina. Usted compra un conmutador Ethernet para cada piso, los conecta a las tomas de cada oficina en ese piso y conecta todos los conmutadores juntos.

Inicialmente, alquila espacio a dos inquilinos diferentes: uno en el piso 1 y otro en 2. Cada uno de estos inquilinos configura sus computadoras con direcciones IPv4 estáticas. Ambos inquilinos usan diferentes subredes TCP / IP y todo parece funcionar bien.

Más tarde, un nuevo inquilino alquila la mitad del piso 3 y muestra uno de estos nuevos servidores DHCP. El tiempo pasa y el inquilino del primer piso decide subirse al carro de DHCP también. Este es el punto cuando las cosas comienzan a ir mal. Los inquilinos del piso 3 informan que algunas de sus computadoras obtienen direcciones IP "divertidas" de una máquina que no es su servidor DHCP. Pronto, los inquilinos del piso 1 informan lo mismo.

DHCP es un protocolo que aprovecha la capacidad de transmisión de Ethernet para permitir que las computadoras cliente obtengan direcciones IP dinámicamente. Como todos los inquilinos comparten la misma red Ethernet física, comparten el mismo dominio de difusión. Un paquete de transmisión enviado desde cualquier computadora en la red inundará todos los puertos del conmutador a cualquier otra computadora. Los servidores DHCP en los pisos 1 y 3 recibirán todas las solicitudes de arrendamientos de direcciones IP y, de hecho, tendrán un duelo para ver quién puede responder primero. Claramente, este no es el comportamiento que pretende que experimenten sus inquilinos. Sin embargo, este es el comportamiento de una red Ethernet "plana" sin ninguna VLAN.

Peor aún, un inquilino en el piso 2 adquiere este software "Wireshark" e informa que, de vez en cuando, ven tráfico saliendo de su conmutador que hace referencia a computadoras y direcciones IP de las que nunca han oído hablar. ¡Uno de sus empleados incluso ha descubierto que puede comunicarse con estas otras computadoras cambiando la dirección IP asignada a su PC de 192.168.1.38 a 192.168.0.38! Presumiblemente, está a solo unos pocos pasos de realizar "servicios de administración de sistemas pro bono no autorizados" para uno de los otros inquilinos. No está bien.

Soluciones potenciales

¡Necesitas una solución! ¡Podrías simplemente tirar de los enchufes entre los pisos y eso cortaría toda comunicación no deseada! ¡Sí! Ese es el boleto ...

Eso podría funcionar, excepto que tiene un nuevo inquilino que alquilará la mitad del sótano y la mitad desocupada del piso 3. Si no hay una conexión entre el interruptor del piso 3 y el interruptor del sótano, el nuevo inquilino no será capaz de obtener comunicación entre sus computadoras que se extenderá por sus dos pisos. Tirar de los enchufes no es la respuesta. Peor aún, ¡el nuevo inquilino está trayendo otro de estos servidores DHCP!

Coquetea con la idea de comprar conjuntos de conmutadores Ethernet físicamente separados para cada inquilino, pero viendo cómo su edificio tiene 30 pisos, cualquiera de los cuales se puede subdividir hasta 4 formas, las ratas potenciales anidan de cables de piso a piso entre Un gran número de conmutadores Ethernet paralelos podría ser una pesadilla, por no mencionar costoso. Si solo hubiera una manera de hacer que una única red Ethernet física actuara como si fuera una red Ethernet física múltiple, cada una con su propio dominio de difusión.

VLAN al rescate

Las VLAN son una respuesta a este problema desordenado. Las VLAN le permiten subdividir un conmutador Ethernet en conmutadores Ethernet virtuales lógicamente dispares. Esto permite que un solo conmutador Ethernet actúe como si fueran múltiples conmutadores Ethernet físicos. En el caso de su piso 3 subdividido, por ejemplo, puede configurar su conmutador de 48 puertos de modo que los 24 puertos inferiores estén en una VLAN determinada (que llamaremos VLAN 12) y los 24 puertos superiores estén en una VLAN dada ( que llamaremos VLAN 13). Cuando cree las VLAN en su conmutador, tendrá que asignarles algún tipo de nombre o número de VLAN. Los números que estoy usando aquí son en su mayoría arbitrarios, así que no te preocupes por los números específicos que elijo.

Una vez que haya dividido el conmutador del piso 3 en las VLAN 12 y 13, encontrará que el nuevo inquilino del piso 3 puede conectar su servidor DHCP a uno de los puertos asignados a la VLAN 13 y una PC conectada a un puerto asignado a la VLAN 12 no t obtenga una dirección IP del nuevo servidor DHCP. ¡Excelente! ¡Problema resuelto!

Oh, espera ... ¿cómo llevamos los datos de la VLAN 13 al sótano?

Comunicación VLAN entre conmutadores

A su inquilino de la mitad del piso 3 y la mitad del sótano le gustaría conectar las computadoras en el sótano a sus servidores en la planta 3. Puede pasar un cable directamente desde uno de los puertos asignados a su VLAN en el piso 3, cambiar al sótano y la vida útil. estaría bien, ¿verdad?

En los primeros días de las VLAN (estándar anterior a 802.1Q) podría hacer exactamente eso. Todo el interruptor del sótano sería, efectivamente, parte de la VLAN 13 (la VLAN que ha optado por asignar al nuevo inquilino en el piso 3 y el sótano) porque ese interruptor del sótano sería "alimentado" por un puerto en el piso 3 que está asignado a la VLAN 13.

Esta solución funcionaría hasta que usted alquile la otra mitad del sótano a su inquilino del primer piso, que también desea comunicarse entre sus computadoras del primer piso y del sótano. Puede dividir el conmutador del sótano utilizando VLAN (en, por ejemplo, VLAN 2 y 13) y pasar un cable desde el piso 1 a un puerto asignado a la VLAN 2 en el sótano, pero su mejor juicio le dice que esto podría convertirse rápidamente en un nido de ratas de cables (y solo va a empeorar). Dividir los conmutadores que usan VLAN es bueno, pero tener que pasar varios cables desde otros conmutadores a puertos que son miembros de diferentes VLAN parece desordenado. Sin lugar a dudas, si tuviera que dividir el interruptor del sótano de 4 maneras entre los inquilinos que también tenían espacio en los pisos más altos, usaría 4 puertos en el interruptor del sótano solo para terminar los cables "alimentadores" de las VLAN de arriba.

Ahora debe quedar claro que se necesita algún tipo de método generalizado para mover el tráfico de múltiples VLAN entre conmutadores en un solo cable. Simplemente agregar más cables entre conmutadores para admitir conexiones entre diferentes VLAN no es una estrategia escalable. Eventualmente, con suficientes VLAN, estará consumiendo todos los puertos en sus conmutadores con estas conexiones entre VLAN / entre conmutadores. Lo que se necesita es una forma de transportar los paquetes desde varias VLAN a lo largo de una sola conexión: una conexión "troncal" entre conmutadores.

Hasta este punto, todos los puertos de conmutador de los que hemos hablado se denominan puertos de "acceso". Es decir, estos puertos están dedicados a acceder a una sola VLAN. Los dispositivos conectados a estos puertos no tienen una configuración especial en sí mismos. Estos dispositivos no "saben" que alguna VLAN está presente. Las tramas que envían los dispositivos del cliente se entregan al conmutador, que luego se asegura de que la trama solo se envíe a los puertos asignados como miembros de la VLAN asignada al puerto donde la trama ingresó al conmutador. Si una trama ingresa al conmutador en un puerto asignado como miembro de la VLAN 12, entonces el conmutador solo enviará esa trama a los puertos que son miembros de la VLAN 12. El conmutador "conoce" el número de VLAN asignado a un puerto del cual recibe un frame y de alguna manera sabe que solo entrega estos puertos frame out de la misma VLAN.

Si hubiera alguna forma de que un conmutador compartiera el número de VLAN asociado con una trama dada a otros conmutadores, entonces el otro conmutador podría manejar adecuadamente la entrega de esa trama solo a los puertos de destino apropiados. Esto es lo que hace el protocolo de etiquetado VLAN 802.1Q. (Vale la pena señalar que, antes de 802.1Q, algunos proveedores crearon sus propios estándares para el etiquetado de VLAN y el enlace entre conmutadores. En su mayor parte, estos métodos pre-estándar han sido suplantados por 802.1Q).

Cuando tiene dos conmutadores compatibles con VLAN conectados entre sí y desea que esos conmutadores entreguen tramas entre sí a la VLAN adecuada, conecta esos conmutadores utilizando puertos "troncales". Esto implica cambiar la configuración de un puerto en cada conmutador del modo "acceso" al modo "troncal" (en una configuración muy básica).

Cuando un puerto se configura en modo troncal, cada trama que el conmutador envía ese puerto tendrá una "etiqueta VLAN" incluida en la trama. Esta "etiqueta VLAN" no era parte del marco original que envió el cliente. Por el contrario, el conmutador de envío agrega esta etiqueta antes de enviar el marco por el puerto troncal. Esta etiqueta denota el número de VLAN asociado con el puerto desde el que se originó la trama.

El conmutador receptor puede mirar la etiqueta para determinar desde qué VLAN se originó la trama y, en función de esa información, reenviar la trama solo a los puertos asignados a la VLAN de origen. Debido a que los dispositivos conectados a los puertos de "acceso" no son conscientes de que se están utilizando VLAN, la información de "etiqueta" debe ser eliminada del marco antes de enviar un puerto configurado en modo de acceso. Esta eliminación de la información de la etiqueta hace que todo el proceso de enlace troncal de VLAN se oculte de los dispositivos del cliente, ya que la trama que reciben no llevará ninguna información de etiqueta de VLAN.

Antes de configurar las VLAN en la vida real, recomendaría configurar un puerto para el modo troncal en un conmutador de prueba y monitorear el tráfico que se envía a ese puerto utilizando un sniffer (como Wireshark). Puede crear un poco de tráfico de muestra desde otra computadora, conectado a un puerto de acceso, y ver que las tramas que salen del puerto troncal serán, de hecho, más grandes que las tramas enviadas por su computadora de prueba. Verá la información de la etiqueta VLAN en los marcos en Wireshark. Creo que vale la pena ver lo que sucede en un sniffer. Leer en el estándar de etiquetado 802.1Q también es algo decente en este momento (especialmente porque no estoy hablando de cosas como "VLAN nativas" o doble etiquetado).

Pesadillas de configuración de VLAN y la solución

A medida que alquila más y más espacio en su edificio, aumenta el número de VLAN. Cada vez que agrega una nueva VLAN, descubre que debe iniciar sesión en cada vez más conmutadores Ethernet y agregar esa VLAN a la lista. ¿No sería genial si hubiera algún método por el cual pudiera agregar esa VLAN a un único manifiesto de configuración y hacer que rellene automáticamente la configuración de VLAN de cada conmutador?

Los protocolos como el "Protocolo de enlace troncal de VLAN" (VTP) patentado por Cisco o el "Protocolo de registro de VLAN múltiple" (MVRP - GVRP, por sus siglas en inglés) cumplieron esta función. En una red que usa estos protocolos, una sola entrada de creación o eliminación de VLAN hace que se envíen mensajes de protocolo a todos los conmutadores de la red. Ese mensaje de protocolo comunica el cambio en la configuración de VLAN al resto de los conmutadores que, a su vez, modifican sus configuraciones de VLAN. VTP y MVRP no se preocupan por qué puertos específicos están configurados como puertos de acceso para VLAN específicas, sino que son útiles para comunicar la creación o eliminación de VLAN a todos los conmutadores.

Cuando se haya familiarizado con las VLAN, es probable que desee volver y leer sobre "poda de VLAN", que está asociada con protocolos como VTP y MVRP. Por ahora no es nada de lo que preocuparse tremendamente. (El artículo de VTP en Wikipedia tiene un buen diagrama que explica la poda de VLAN y los beneficios que ofrece).

¿Cuándo usas VLAN en la vida real?

Antes de ir mucho más allá, es importante pensar en la vida real en lugar de ejemplos artificiales. En lugar de duplicar el texto de otra respuesta aquí, lo remitiré a mi respuesta re: cuándo crear VLAN . No es necesariamente un "nivel de principiante", pero vale la pena echarle un vistazo ahora, ya que voy a hacer una breve referencia antes de volver a un ejemplo artificial.

Para la multitud "tl; dr" (que seguramente han dejado de leer en este momento, de todos modos), la esencia de ese enlace de arriba es: Crear VLAN para hacer que los dominios de transmisión sean más pequeños o cuando desee segregar el tráfico por alguna razón en particular (seguridad , política, etc.). Realmente no hay otras buenas razones para usar VLAN.

En nuestro ejemplo, estamos usando VLAN para limitar los dominios de difusión (para mantener protocolos como DHCP funcionando correctamente) y, en segundo lugar, porque queremos aislamiento entre las redes de los distintos inquilinos.

Un aparte re: subredes IP y VLAN

En términos generales, existe una relación de uno a uno entre las VLAN y las subredes IP por conveniencia, para facilitar el aislamiento y por cómo funciona el protocolo ARP.

Como vimos al comienzo de esta respuesta, se pueden usar dos subredes IP diferentes en la misma Ethernet física sin problemas. Si está utilizando VLAN para reducir los dominios de transmisión, no querrá compartir la misma VLAN con dos subredes IP diferentes, ya que combinará su ARP y otro tráfico de transmisión.

Si está utilizando VLAN para segregar el tráfico por razones de seguridad o políticas, entonces probablemente tampoco querrá combinar varias subredes en la misma VLAN, ya que anulará el propósito del aislamiento.

IP utiliza un protocolo basado en difusión, Protocolo de resolución de direcciones (ARP), para asignar direcciones IP en direcciones físicas (Ethernet MAC). Dado que ARP se basa en la transmisión, asignar diferentes partes de la misma subred IP a diferentes VLAN sería problemático porque los hosts en una VLAN no podrían recibir respuestas ARP de los hosts en la otra VLAN, ya que las transmisiones no se reenvían entre las VLAN. Puede resolver este "problema" utilizando proxy-ARP pero, en última instancia, a menos que tenga una buena razón para dividir una subred IP en varias VLAN, es mejor no hacerlo.

Un último lado: VLAN y seguridad

Finalmente, vale la pena señalar que las VLAN no son un gran dispositivo de seguridad. Muchos conmutadores Ethernet tienen errores que permiten que las tramas que se originan en una VLAN se envíen a puertos asignados a otra VLAN. Los fabricantes de conmutadores Ethernet han trabajado duro para corregir estos errores, pero es dudoso que alguna vez haya una implementación completamente libre de errores.

En el caso de nuestro ejemplo artificial, el empleado del piso 2 que está a pocos minutos de proporcionar "servicios" de administración de sistemas gratuitos a otro inquilino podría ser impedido de hacerlo aislando su tráfico en una VLAN. Sin embargo, también podría descubrir cómo explotar errores en el firmware del conmutador para permitir que su tráfico se "filtre" en la VLAN de otro inquilino.

Los proveedores de Metro Ethernet dependen cada vez más de la funcionalidad de etiquetado de VLAN y del aislamiento que proporcionan los conmutadores. No es justo decir que no hay ninguna seguridad que ofrece el uso de VLAN. Sin embargo, es justo decir que en situaciones con conexiones a Internet o redes DMZ no confiables, probablemente sea mejor usar conmutadores físicamente separados para transportar este tráfico "sensible" en lugar de VLAN en los conmutadores que también transportan su tráfico confiable "detrás del firewall".

Trayendo la capa 3 a la imagen

Hasta ahora, todo lo que ha mencionado esta respuesta se relaciona con la capa 2: tramas Ethernet. ¿Qué sucede si comenzamos a incorporar la capa 3 a esto?

Volvamos al ejemplo de construcción artificial. Ha adoptado las VLAN y ha optado por configurar los puertos de cada inquilino como miembros de VLAN separadas. Ha configurado los puertos troncales de modo que el conmutador de cada piso pueda intercambiar tramas etiquetadas con el número de VLAN de origen a los conmutadores en el piso superior e inferior. Un inquilino puede tener computadoras distribuidas en varios pisos, pero, debido a sus habilidades de configuración de VLAN, estas computadoras distribuidas físicamente pueden parecer parte de la misma LAN física.

Está tan lleno de sus logros de TI que decide comenzar a ofrecer conectividad a Internet a sus inquilinos. Usted compra una tubería de Internet gruesa y un enrutador. Usted presenta la idea a todos sus inquilinos y dos de ellos aceptan de inmediato. Afortunadamente para usted, su enrutador tiene tres puertos Ethernet. Conecta un puerto a su canal de Internet pesado, otro puerto a un puerto de conmutador asignado para acceder a la VLAN del primer inquilino y el otro a un puerto asignado para acceder a la VLAN del segundo inquilino. ¡Configura los puertos de su enrutador con direcciones IP en la red de cada inquilino y los inquilinos comienzan a acceder a Internet a través de su servicio! Los ingresos aumentan y eres feliz.

Pronto, sin embargo, otro inquilino decide acceder a su oferta de Internet. Sin embargo, no tiene puertos en su enrutador. ¿Qué hacer?

Afortunadamente, compró un enrutador que admite la configuración de "subinterfaces virtuales" en sus puertos Ethernet. En resumen, esta funcionalidad permite al enrutador recibir e interpretar tramas etiquetadas con números de VLAN de origen y tener interfaces virtuales (es decir, no físicas) configuradas con direcciones IP apropiadas para cada VLAN con la que se comunicará. En efecto, esto le permite "multiplexar" un solo puerto Ethernet en el enrutador de modo que parezca funcionar como múltiples puertos Ethernet físicos.

Conecta su enrutador a un puerto troncal en uno de sus conmutadores y configura las subinterfaces virtuales correspondientes al esquema de direccionamiento IP de cada inquilino. Cada subinterfaz virtual se configura con el número de VLAN asignado a cada Cliente. Cuando una trama abandona el puerto troncal en el conmutador, con destino al enrutador, llevará una etiqueta con el número de VLAN de origen (ya que es un puerto troncal). El enrutador interpretará esta etiqueta y tratará el paquete como si llegara a una interfaz física dedicada correspondiente a esa VLAN. Del mismo modo, cuando el enrutador envía una trama al conmutador en respuesta a una solicitud, agregará una etiqueta de VLAN a la trama de modo que el conmutador sepa a qué VLAN debe entregarse la trama de respuesta. En efecto, ha configurado el enrutador para que "aparezca"

Enrutadores en palos y conmutadores de capa 3

Utilizando subinterfaces virtuales, ha podido vender conectividad a Internet a todos sus inquilinos sin tener que comprar un enrutador que tenga más de 25 interfaces Ethernet. Está bastante contento con sus logros de TI, por lo que responde positivamente cuando dos de sus inquilinos llegan a usted con una nueva solicitud.

Estos inquilinos han optado por "asociarse" en un proyecto y desean permitir el acceso desde las computadoras del cliente en la oficina de un inquilino (una VLAN dada) a una computadora servidor en la oficina del otro inquilino (otra VLAN). Dado que ambos son Clientes de su servicio de Internet, es un cambio bastante simple de una ACL en su enrutador de Internet central (en el que hay una subinterfaz virtual configurada para cada una de las VLAN de estos inquilinos) para permitir que el tráfico fluya entre sus VLAN como así como a Internet desde sus VLAN. Usted realiza el cambio y envía a los inquilinos en su camino.

Al día siguiente, recibe las quejas de ambos inquilinos de que el acceso entre las computadoras del cliente en una oficina al servidor en la segunda oficina es muy lento. Las computadoras del servidor y del cliente tienen conexiones Gigabit Ethernet a sus conmutadores, pero los archivos solo se transfieren a alrededor de 45 Mbps, que, por coincidencia, es aproximadamente la mitad de la velocidad con la que su enrutador central se conecta a su conmutador. Claramente, el tráfico que fluye desde la VLAN de origen al enrutador y de regreso desde el enrutador a la VLAN de destino está siendo bloqueado por la conexión del enrutador al conmutador.

Lo que ha hecho con su enrutador central, que le permite enrutar el tráfico entre las VLAN, se conoce comúnmente como "enrutador en un palo" (un eufemismo posiblemente estúpidamente caprichoso). Esta estrategia puede funcionar bien, pero el tráfico solo puede fluir entre las VLAN hasta la capacidad de conexión del enrutador al conmutador. Si, de alguna manera, el enrutador pudiera unirse con las "tripas" del conmutador Ethernet en sí mismo, podría enrutar el tráfico aún más rápido (dado que el conmutador Ethernet en sí, según la hoja de especificaciones del fabricante, es capaz de conmutar más de 2 Gbps de tráfico).

Un "conmutador de capa 3" es un conmutador Ethernet que, lógicamente hablando, contiene un enrutador enterrado dentro de sí mismo. Me resulta tremendamente útil pensar que un conmutador de capa 3 tiene un enrutador pequeño y rápido escondido dentro del conmutador. Además, le aconsejaría que piense en la funcionalidad de enrutamiento como una función claramente separada de la función de conmutación de Ethernet que proporciona el conmutador de capa 3. Un switch de capa 3 es, para todos los efectos, dos dispositivos distintos envueltos en un solo chasis.

El enrutador incorporado en un conmutador de capa 3 está conectado a la estructura de conmutación interna del conmutador a una velocidad que, por lo general, permite el enrutamiento de paquetes entre las VLAN a la velocidad del cable o cerca de ella. De manera análoga a las subinterfaces virtuales que configuró en su "enrutador en un palo", este enrutador integrado dentro del conmutador de capa 3 puede configurarse con interfaces virtuales que "parecen" ser conexiones de "acceso" en cada VLAN. En lugar de llamarse subinterfaces virtuales, estas conexiones lógicas desde las VLAN al enrutador incorporado dentro de un conmutador de capa 3 se denominan Interfaces virtuales de conmutador (SVI). En efecto, el enrutador incorporado dentro de un conmutador de capa 3 tiene una cierta cantidad de "puertos virtuales" que se pueden "enchufar" a cualquiera de las VLAN en el conmutador.

El enrutador incorporado funciona de la misma manera que un enrutador físico, excepto que generalmente no tiene el mismo protocolo de enrutamiento dinámico o características de lista de control de acceso (ACL) que un enrutador físico (a menos que haya comprado una capa 3 realmente agradable cambiar). Sin embargo, el enrutador incorporado tiene la ventaja de ser muy rápido y no tener un cuello de botella asociado con un puerto de conmutador físico en el que está enchufado.

En el caso de nuestro ejemplo aquí con los inquilinos "asociados", puede optar por obtener un conmutador de capa 3, conectarlo a los puertos troncales para que llegue el tráfico de las VLAN de ambos Clientes, luego configurar SVI con direcciones IP y membresías de VLAN para que "aparece" en ambas VLAN de clientes. Una vez que haya hecho eso, solo es cuestión de ajustar la tabla de enrutamiento en su enrutador central y el enrutador incorporado en el conmutador de capa 3 de modo que el tráfico que fluye entre las VLAN de los inquilinos sea enrutado por el enrutador incorporado dentro del conmutador de capa 3 en lugar del "enrutador en un palo".

El uso de un conmutador de capa 3 no significa que todavía no habrá cuellos de botella asociados con el ancho de banda de los puertos troncales que interconectan sus conmutadores. Sin embargo, esta es una preocupación ortogonal para aquellos que abordan las VLAN. Las VLAN no tienen nada que ver con problemas de ancho de banda. Por lo general, los problemas de ancho de banda se resuelven obteniendo conexiones entre conmutadores de mayor velocidad o utilizando protocolos de agregación de enlaces para "unir" varias conexiones de menor velocidad en una conexión virtual de mayor velocidad. A menos que todos los dispositivos que crean marcos para ser enrutados por el enrutador incorporado dentro del último conmutador 3 estén conectados a los puertos directamente en el conmutador de capa 3, aún debe preocuparse por el ancho de banda de los enlaces entre los conmutadores. Un interruptor de capa 3 no es una panacea, pero generalmente es más rápido que un "

VLAN dinámicas

Por último, hay una función en algunos conmutadores para proporcionar membresía de VLAN dinámica. En lugar de asignar un puerto determinado para que sea un puerto de acceso para una VLAN determinada, la configuración del puerto (acceso o troncal, y para qué VLAN) puede modificarse dinámicamente cuando se conecta un dispositivo. Las VLAN dinámicas son un tema más avanzado, pero saber que existe la funcionalidad puede ser útil.

La funcionalidad varía entre los proveedores, pero generalmente puede configurar la membresía de VLAN dinámica en función de la dirección MAC del dispositivo conectado, el estado de autenticación 802.1X del dispositivo, los protocolos patentados y basados ​​en estándares (CDP y LLDP, por ejemplo, para permitir que los teléfonos IP "descubra" el número de VLAN para el tráfico de voz), la subred IP asignada al dispositivo cliente o el tipo de protocolo Ethernet.

Las VLAN son "Redes de área local virtual". Lo siguiente es mi entendimiento: mi experiencia es principalmente Ingeniería y Administración de Sistemas con un lado de la programación OO y muchas secuencias de comandos.

Las VLAN están destinadas a crear una red aislada en múltiples dispositivos de hardware. Una LAN tradicional en épocas anteriores solo puede existir cuando tiene un único dispositivo de hardware dedicado a una red en particular. Todos los servidores / dispositivos conectados a ese dispositivo de red (Switch o Hub, dependiendo del marco de tiempo histórico) generalmente pueden comunicarse libremente entre la LAN.

Una VLAN difiere de tal manera que puede interconectar varios dispositivos de red y crear redes aisladas al agrupar servidores en una VLAN, eliminando así la necesidad de tener un dispositivo de red "dedicado" para una sola LAN. El número de VLAN configurables y servidores / dispositivos compatibles variará entre los fabricantes de dispositivos de red.

Una vez más, dependiendo del proveedor, no creo que todos los servidores necesiten estar en la misma subred para formar parte de la misma VLAN. Con las configuraciones de red heredadas, creo que lo hicieron (corrección de inserción del ingeniero de red aquí).

Lo que hace que una VLAN difiera de una VPN es la letra "P" para "Privado". Por lo general, el tráfico de VLAN no está encriptado.

¡Espero que ayude!