As LANs virtuais (VLANs) são uma abstração para permitir que uma única rede física emule a funcionalidade de várias redes físicas paralelas. Isso é útil porque pode haver situações em que você precisa da funcionalidade de várias redes físicas paralelas, mas prefere não gastar o dinheiro comprando hardware paralelo. Vou falar sobre VLANs Ethernet nesta resposta (mesmo que outras tecnologias de rede possam suportar VLANs) e não vou mergulhar profundamente em todas as nuances.
Um exemplo inventado e um problema
Como um exemplo de exemplo puramente artificial, imagine que você possui um prédio de escritórios que aluga para inquilinos. Como benefício do aluguel, cada inquilino obterá conectores Ethernet ativos em cada sala do escritório. Você compra um switch Ethernet para cada andar, conecta-os a tomadas em cada escritório naquele andar e conecta todos os switches.
Inicialmente, você aluga espaço para dois inquilinos diferentes - um no andar 1 e outro no 2. Cada um desses inquilinos configura seus computadores com endereços IPv4 estáticos. Ambos os inquilinos usam sub-redes TCP / IP diferentes e tudo parece funcionar bem.
Posteriormente, um novo inquilino aluga metade do piso 3 e abre um desses servidores DHCP com novos ventiladores. O tempo passa e o inquilino do 1º andar decide também entrar na onda de DHCP. Este é o ponto em que as coisas começam a dar errado. Os inquilinos do terceiro andar relatam que alguns de seus computadores estão recebendo endereços IP "engraçados" de uma máquina que não é seu servidor DHCP. Em breve, os inquilinos do andar 1 relatam a mesma coisa.
O DHCP é um protocolo que tira proveito do recurso de transmissão da Ethernet para permitir que os computadores clientes obtenham endereços IP dinamicamente. Como os inquilinos compartilham a mesma rede Ethernet física, compartilham o mesmo domínio de broadcast. Um pacote de transmissão enviado de qualquer computador na rede inundará todas as portas do switch para todos os outros computadores. Os servidores DHCP nos andares 1 e 3 receberão todas as solicitações de concessões de endereços IP e duelarão efetivamente para ver quem pode responder primeiro. Claramente, esse não é o comportamento que você pretende que seus inquilinos experimentem. Esse é o comportamento, no entanto, de uma rede Ethernet "plana" sem nenhuma VLAN.
Pior ainda, um inquilino no segundo andar adquire esse software "Wireshark" e relata que, de tempos em tempos, vê o tráfego saindo de seu comutador que faz referência a computadores e endereços IP dos quais nunca ouviu falar. Um de seus funcionários descobriu que ele pode se comunicar com esses outros computadores alterando o endereço IP atribuído ao seu PC de 192.168.1.38 para 192.168.0.38! Presumivelmente, ele está a poucos passos de executar "serviços não autorizados de administração de sistemas pro bono" para um dos outros inquilinos. Não é bom.
Soluções Potenciais
Você precisa de uma solução! Você pode simplesmente puxar os plugues entre os pisos e isso cortaria toda a comunicação indesejada! sim! Esse é o bilhete ...
Isso pode funcionar, exceto que você tem um novo inquilino que alugará metade do porão e a metade desocupada do andar 3. Se não houver uma conexão entre o comutador do piso 3 e o comutador do porão, o novo inquilino não será capaz de obter comunicação entre os computadores que se espalharão pelos dois andares. Puxar os plugues não é a resposta. Pior ainda, o novo inquilino está trazendo mais um desses servidores DHCP!
Você flerta com a idéia de comprar conjuntos fisicamente separados de comutadores Ethernet para cada inquilino, mas, vendo como seu prédio tem 30 andares, qualquer um dos quais pode ser subdividido em até quatro maneiras, os ratos em potencial aninham cabos do chão ao chão entre um grande número de switches Ethernet paralelos pode ser um pesadelo, para não mencionar caro. Se ao menos houvesse uma maneira de fazer uma única rede Ethernet física agir como se fossem várias redes Ethernet físicas, cada uma com seu próprio domínio de broadcast.
VLANs para o Rescue
As VLANs são uma resposta para esse problema complicado. As VLANs permitem subdividir um comutador Ethernet em comutadores Ethernet virtuais logicamente diferentes. Isso permite que um único switch Ethernet atue como se fosse vários switches Ethernet físicos. No caso do seu piso subdividido 3, por exemplo, você pode configurar seu switch de 48 portas de forma que as 24 portas inferiores estejam em uma determinada VLAN (que chamaremos de VLAN 12) e as 24 portas superiores em uma determinada VLAN ( que chamaremos de VLAN 13). Ao criar as VLANs no seu switch, você precisará atribuir a eles algum tipo de nome ou número de VLAN. Os números que estou usando aqui são arbitrários, então não se preocupe com os números específicos que eu escolher.
Depois de dividir o switch do piso 3 nas VLANs 12 e 13, você descobre que o novo inquilino do piso 3 pode conectar o servidor DHCP a uma das portas atribuídas à VLAN 13 e um PC conectado a uma porta atribuída à VLAN 12 não ' t obtenha um endereço IP do novo servidor DHCP. Excelente! Problema resolvido!
Ah, espere ... como podemos levar esses dados da VLAN 13 para o porão?
Comunicação VLAN entre comutadores
Seu inquilino de meio andar 3 e meio porão gostaria de conectar computadores no porão aos seus servidores no andar 3. Você pode executar um cabo diretamente de uma das portas atribuídas à sua VLAN no comutador do andar 3 para o porão e a vida útil seria bom, né?
Nos primeiros dias das VLANs (padrão pré-802.1Q), você pode fazer exatamente isso. Todo o comutador do porão seria, efetivamente, parte da VLAN 13 (a VLAN que você optou por atribuir ao novo inquilino no andar 3 e no porão) porque esse comutador do porão seria "alimentado" por uma porta no andar 3 designada para VLAN 13.
Essa solução funcionaria até você alugar a outra metade do porão para o inquilino do andar 1, que também deseja ter comunicação entre os computadores do 1º andar e do porão. Você pode dividir o comutador do porão usando VLANs (em, por exemplo, VLANS 2 e 13) e passar um cabo do andar 1 a uma porta atribuída à VLAN 2 no porão, mas você deve julgar que isso pode rapidamente se tornar um ninho de rato de cabos (e só vai piorar). A divisão de switches usando VLANs é boa, mas ter que executar vários cabos de outros switches para portas que são membros de diferentes VLANs parece confuso. Sem dúvida, se você tivesse que dividir o comutador do porão de quatro maneiras entre os inquilinos que também tinham espaço nos andares mais altos, usaria 4 portas no comutador do subsolo apenas para terminar os cabos "alimentadores" das VLANs no andar de cima.
Agora deve ficar claro que é necessário algum tipo de método generalizado de movimentação de tráfego de várias VLANs entre comutadores em um único cabo. Apenas adicionar mais cabos entre comutadores para oferecer suporte a conexões entre diferentes VLANs não é uma estratégia escalável. Eventualmente, com VLANs suficientes, você estará consumindo todas as portas dos seus switches com essas conexões entre VLANs e entre switches. O que é necessário é uma maneira de transportar os pacotes de várias VLANs em uma única conexão - uma conexão de "tronco" entre comutadores.
Até este ponto, todas as portas de switch de que falamos são chamadas de portas de "acesso". Ou seja, essas portas são dedicadas ao acesso a uma única VLAN. Os dispositivos conectados a essas portas não possuem configuração especial. Esses dispositivos não "sabem" que existem VLANs presentes. Os quadros que os dispositivos clientes enviam são entregues ao comutador, que cuida para garantir que o quadro seja enviado apenas para as portas atribuídas como membros da VLAN atribuída à porta em que o quadro entrou no comutador. Se um quadro entrar no switch em uma porta atribuída como membro da VLAN 12, o switch enviará apenas as portas de quadro que são membros da VLAN 12. O switch "conhece" o número da VLAN atribuído a uma porta da qual recebe um frame e de alguma forma sabe entregar apenas esse frame out portas da mesma VLAN.
Se houvesse uma maneira de um comutador compartilhar o número da VLAN associado a um determinado quadro com outros comutadores, o outro comutador poderia lidar adequadamente com a entrega desse quadro apenas para as portas de destino apropriadas. É isso que o protocolo de marcação de VLAN 802.1Q faz. (Vale a pena notar que, antes do 802.1Q, alguns fornecedores criavam seus próprios padrões para identificação de VLAN e entroncamento entre comutadores. Na maioria dos casos, esses métodos pré-padrão foram todos substituídos pelo 802.1Q.)
Quando você tem dois comutadores compatíveis com VLAN conectados um ao outro e deseja que esses comutadores entreguem quadros entre si à VLAN adequada, você os conecta usando portas de "tronco". Isso envolve alterar a configuração de uma porta em cada switch do modo "acesso" para o modo "tronco" (em uma configuração muito básica).
Quando uma porta é configurada no modo de tronco, cada quadro que o switch envia essa porta terá um "tag VLAN" incluído no quadro. Essa "tag VLAN" não fazia parte do quadro original que o cliente enviou. Em vez disso, essa tag é adicionada pelo switch de envio antes de enviar o quadro pela porta de tronco. Essa tag indica o número da VLAN associado à porta da qual o quadro se originou.
O switch de recebimento pode examinar a etiqueta para determinar de qual VLAN o quadro se originou e, com base nessas informações, encaminhar o quadro apenas para as portas atribuídas à VLAN de origem. Como os dispositivos conectados às portas de "acesso" não sabem que as VLANs estão sendo usadas, as informações de "tag" devem ser retiradas do quadro antes de serem enviadas uma porta configurada no modo de acesso. Essa remoção das informações da etiqueta faz com que todo o processo de entroncamento da VLAN seja oculto dos dispositivos clientes, pois o quadro que eles recebem não contém nenhuma informação da etiqueta da VLAN.
Antes de configurar as VLANs na vida real, recomendo configurar uma porta para o modo de tronco em um switch de teste e monitorar o tráfego que está sendo enviado para essa porta usando um sniffer (como o Wireshark). Você pode criar um exemplo de tráfego de outro computador, conectado a uma porta de acesso, e verificar que os quadros que saem da porta de tronco serão, de fato, maiores do que os quadros enviados pelo computador de teste. Você verá as informações da etiqueta VLAN nos quadros no Wireshark. Acho que vale a pena ver o que acontece em um farejador. Ler sobre o padrão de marcação 802.1Q também é uma coisa decente a ser feita neste momento (especialmente porque não estou falando sobre coisas como "VLANs nativas" ou marcação dupla).
Pesadelos de configuração de VLAN e a solução
À medida que você aluga cada vez mais espaço em seu prédio, o número de VLANs aumenta. Cada vez que você adiciona uma nova VLAN, descobre que precisa fazer logon em cada vez mais switches Ethernet e adicionar essa VLAN à lista. Não seria ótimo se houvesse algum método pelo qual você pudesse adicionar essa VLAN a um único manifesto de configuração e fazer com que ela preenchesse automaticamente a configuração da VLAN de cada switch?
Protocolos como o "Protocolo de entroncamento de VLAN" (VTP) proprietário da Cisco ou o "Protocolo de registro múltiplo de VLAN" (MVRP - GVRP anteriormente escrito de GVRP) cumprem esta função. Em uma rede que usa esses protocolos, uma única entrada de criação ou exclusão de VLAN resulta no envio de mensagens de protocolo a todos os comutadores da rede. Essa mensagem de protocolo comunica a alteração na configuração da VLAN aos demais switches que, por sua vez, modificam suas configurações de VLAN. O VTP e o MVRP não estão preocupados com quais portas específicas estão configuradas como portas de acesso para VLANs específicas, mas são úteis para comunicar a criação ou exclusão de VLANs a todos os comutadores.
Quando você se sentir confortável com as VLANs, provavelmente desejará voltar e ler sobre a "remoção de VLAN", que está associada a protocolos como VTP e MVRP. Por enquanto não é nada com que se preocupar tremendamente. (O artigo sobre VTP na Wikipedia possui um belo diagrama que explica a poda de VLAN e os benefícios com ela.)
Quando você usa VLANs na vida real?
Antes de avançarmos muito, é importante pensar na vida real, em vez de exemplos artificiais. Em vez de duplicar o texto de outra resposta aqui, encaminharei você para minha resposta re: quando criar VLANs . Não é necessariamente "nível iniciante", mas vale a pena dar uma olhada agora, já que vou fazer referência a ele brevemente antes de voltar para um exemplo artificial.
Para a multidão "tl; dr" (que certamente parou de ler neste momento), a essência desse link acima é: Crie VLANs para diminuir os domínios de broadcast ou quando você quiser segregar o tráfego por algum motivo em particular (segurança , política etc.). Não há realmente outras boas razões para usar VLANs.
Em nosso exemplo, estamos usando VLANs para limitar domínios de broadcast (para manter protocolos como o DHCP funcionando corretamente) e, secundariamente, porque queremos isolamento entre as redes dos vários inquilinos.
Além disso: sub-redes IP e VLANs
De um modo geral, geralmente existe um relacionamento individual entre VLANs e sub-redes IP por conveniência, para facilitar o isolamento e por causa de como o protocolo ARP funciona.
Como vimos no início desta resposta, duas sub-redes IP diferentes podem ser usadas na mesma Ethernet física sem problemas. Se você estiver usando VLANs para reduzir domínios de transmissão, não desejará compartilhar a mesma VLAN com duas sub-redes IP diferentes, pois estará combinando o ARP e outro tráfego de transmissão.
Se você estiver usando VLANs para segregar o tráfego por motivos de segurança ou política, provavelmente também não desejará combinar várias sub-redes na mesma VLAN, pois estará derrotando o objetivo do isolamento.
O IP usa um protocolo baseado em broadcast, ARP (Address Resolution Protocol), para mapear endereços IP em endereços físicos (Ethernet MAC). Como o ARP é baseado em difusão, a atribuição de diferentes partes da mesma sub-rede IP a diferentes VLANs seria problemática porque os hosts em uma VLAN não poderiam receber respostas ARP dos hosts na outra VLAN, pois as transmissões não são encaminhadas entre as VLANs. Você pode resolver esse "problema" usando o proxy-ARP, mas, a menos que você tenha um bom motivo para dividir uma sub-rede IP entre várias VLANs, é melhor não fazer isso.
Um último lado: VLANs e segurança
Por fim, vale ressaltar que as VLANs não são um ótimo dispositivo de segurança. Muitos comutadores Ethernet possuem bugs que permitem que os quadros originários de uma VLAN sejam enviados para as portas atribuídas a outra VLAN. Os fabricantes de switches Ethernet trabalharam duro para corrigir esses bugs, mas é duvidoso que alguma vez haja uma implementação completamente livre de bugs.
No caso do nosso exemplo, o funcionário do segundo andar, que está a poucos minutos de fornecer "serviços" gratuitos de administração de sistemas para outro inquilino, pode ser impedido de fazer isso isolando seu tráfego em uma VLAN. Ele também pode descobrir como explorar bugs no firmware do switch, para permitir que seu tráfego "vaze" na VLAN de outro inquilino também.
Os provedores de Ethernet Metro confiam cada vez mais na funcionalidade de marcação de VLAN e no isolamento que os comutadores fornecem. Não é justo dizer que não há segurança oferecida usando VLANs. É justo dizer, no entanto, que em situações com conexões de Internet não confiáveis ou redes DMZ, é provavelmente melhor usar comutadores fisicamente separados para transportar esse tráfego "delicado" em vez de VLANs em comutadores que também transportam seu tráfego "atrás do firewall" confiável.
Trazendo a Camada 3 para a Imagem
Até agora, tudo o que essa resposta falou se refere à camada 2 - quadros Ethernet. O que acontece se começarmos a trazer a camada 3 para isso?
Vamos voltar ao exemplo de construção artificial. Você adotou as VLANs que optaram por configurar as portas de cada inquilino como membros de VLANs separadas. Você configurou as portas de tronco de modo que os comutadores de cada andar possam trocar os quadros marcados com o número de VLAN de origem pelos comutadores no andar acima e abaixo. Um inquilino pode ter computadores espalhados por vários andares, mas, devido às suas habilidades de configuração de VLAN, esses computadores distribuídos fisicamente podem parecer fazer parte da mesma LAN física.
Você está tão cheio de suas realizações de TI que decide começar a oferecer conectividade com a Internet para seus inquilinos. Você compra um cachimbo de Internet gordo e um roteador. Você transmite a ideia a todos os seus inquilinos e dois deles compram imediatamente. Felizmente para você, seu roteador possui três portas Ethernet. Você conecta uma porta ao seu canal de Internet gordo, outra porta a uma porta do switch atribuída para acessar a VLAN do primeiro inquilino e a outra a uma porta atribuída para acessar a VLAN do segundo inquilino. Você configura as portas do seu roteador com endereços IP na rede de cada inquilino e os inquilinos começam a acessar a Internet através do seu serviço! A receita aumenta e você está feliz.
Logo, porém, outro inquilino decide acessar sua oferta na Internet. Você está sem portas no seu roteador. O que fazer?
Felizmente, você comprou um roteador que suporta a configuração de "subinterfaces virtuais" em suas portas Ethernet. Em resumo, essa funcionalidade permite que o roteador receba e interprete os quadros marcados com números de VLAN de origem e tenha interfaces virtuais (ou seja, não físicas) configuradas com endereços IP apropriados para cada VLAN com a qual se comunicará. Com efeito, isso permite "multiplexar" uma única porta Ethernet no roteador, de modo que pareça funcionar como várias portas Ethernet físicas.
Você conecta seu roteador a uma porta de tronco em um de seus comutadores e configura subinterfaces virtuais correspondentes ao esquema de endereçamento IP de cada inquilino. Cada sub-interface virtual é configurada com o número da VLAN atribuído a cada cliente. Quando um quadro deixa a porta de tronco no switch, com destino ao roteador, ele carrega uma etiqueta com o número de VLAN de origem (já que é uma porta de tronco). O roteador interpretará essa tag e tratará o pacote como se tivesse chegado a uma interface física dedicada correspondente a essa VLAN. Da mesma forma, quando o roteador envia um quadro ao comutador em resposta a uma solicitação, ele adiciona um tag VLAN ao quadro, de modo que o comutador saiba para qual VLAN o quadro de resposta deve ser entregue. Com efeito, você configurou o roteador para "aparecer"
Roteadores em Sticks e Switches de Camada 3
Usando subinterfaces virtuais, você conseguiu vender a conectividade da Internet a todos os seus inquilinos sem precisar comprar um roteador com mais de 25 interfaces Ethernet. Você está bastante satisfeito com suas realizações de TI e responde positivamente quando dois de seus inquilinos chegam até você com uma nova solicitação.
Esses inquilinos optaram por "fazer parceria" em um projeto e desejam permitir o acesso de computadores clientes no escritório de um inquilino (uma determinada VLAN) a um computador servidor no escritório do outro inquilino (outra VLAN). Como ambos são clientes do seu serviço de Internet, é uma alteração bastante simples de uma ACL no roteador principal da Internet (na qual há uma sub interface virtual configurada para cada uma das VLANs desse inquilino) para permitir que o tráfego flua entre suas VLANs, conforme bem como à Internet a partir de suas VLANs. Você faz a alteração e envia os inquilinos a caminho.
No dia seguinte, você recebe reclamações de ambos os inquilinos que o acesso entre os computadores clientes em um escritório ao servidor no segundo escritório é muito lento. Os computadores servidor e cliente têm conexões Ethernet de gigabit com seus comutadores, mas os arquivos são transferidos apenas a cerca de 45 Mbps, o que, coincidentemente, é aproximadamente metade da velocidade com a qual o roteador principal se conecta ao comutador. Claramente, o tráfego que flui da VLAN de origem para o roteador e volta do roteador para a VLAN de destino está sendo afunilado pela conexão do roteador ao switch.
O que você fez com o roteador principal, permitindo rotear o tráfego entre VLANs, é comumente conhecido como "roteador em um bastão" (um eufemismo indiscutivelmente estupidamente caprichoso). Essa estratégia pode funcionar bem, mas o tráfego só pode fluir entre as VLANs até a capacidade da conexão do roteador ao switch. Se, de alguma forma, o roteador pudesse ser combinado com as "tripas" do próprio switch Ethernet, ele poderia rotear o tráfego ainda mais rápido (já que o próprio switch Ethernet, de acordo com a folha de especificações do fabricante, é capaz de alternar 2 Gbps de tráfego).
Um "switch de camada 3" é um switch Ethernet que, logicamente falando, contém um roteador enterrado dentro de si. Acho tremendamente útil pensar em um switch de camada 3 como tendo um roteador pequeno e rápido escondido dentro do switch. Além disso, recomendo que você pense na funcionalidade de roteamento como uma função distinta da função de comutação Ethernet que o comutador de camada 3 fornece. Um switch de camada 3 é, para todos os efeitos, dois dispositivos distintos agrupados em um único chassi.
O roteador incorporado em um comutador de camada 3 é conectado à malha de comutação interna do comutador a uma velocidade que, normalmente, permite o roteamento de pacotes entre VLANs na velocidade do fio ou próximo a ele. Analogamente às subinterfaces virtuais que você configurou no seu "roteador em um bastão", este roteador incorporado dentro do switch da camada 3 pode ser configurado com interfaces virtuais que "parecem" serem conexões de "acesso" a cada VLAN. Em vez de serem chamadas de subinterfaces virtuais, essas conexões lógicas das VLANs para o roteador incorporado dentro de um switch de camada 3 são denominadas Switch Virtual Interfaces (SVIs). Com efeito, o roteador incorporado dentro de um switch de camada 3 possui uma quantidade de "portas virtuais" que podem ser "conectadas" a qualquer uma das VLANs do switch.
O roteador incorporado funciona da mesma maneira que um roteador físico, exceto que normalmente não possui todos os mesmos recursos de protocolo de roteamento dinâmico ou lista de controle de acesso (ACL) que um roteador físico (a menos que você tenha comprado uma camada muito boa). interruptor). No entanto, o roteador incorporado tem a vantagem de ser muito rápido e não ter um gargalo associado a uma porta de switch física na qual está conectado.
No caso do nosso exemplo aqui, com os inquilinos "em parceria", você pode optar por obter um switch da camada 3, conectá-lo às portas de tronco para que o tráfego das VLANs dos clientes chegue até ele e, em seguida, configure os SVIs com endereços IP e associações à VLAN, de forma que "aparece" nas duas VLANs dos clientes. Depois de fazer isso, basta ajustar a tabela de roteamento no roteador principal e no roteador incorporado no switch da camada 3, de modo que o tráfego que flui entre as VLANs dos inquilinos seja roteado pelo roteador incorporado dentro do switch da camada 3 versus o "roteador em uma vara".
O uso de um switch de camada 3 não significa que ainda não haverá gargalos associados à largura de banda das portas de tronco que interconectam seus switches. Essa é uma preocupação ortogonal para aqueles endereçados pelas VLANs. As VLANs não têm nada a ver com problemas de largura de banda. Normalmente, os problemas de largura de banda são resolvidos através da obtenção de conexões entre comutadores de alta velocidade ou do uso de protocolos de agregação de link para "unir" várias conexões de baixa velocidade em uma conexão virtual de alta velocidade. A menos que todos os dispositivos que criam quadros a serem roteados pelo roteador incorporado no switch 3 posterior sejam eles mesmos conectados às portas diretamente no switch da camada 3, você ainda precisa se preocupar com a largura de banda dos troncos entre os switches. Um comutador de camada 3 não é uma panacéia, mas geralmente é mais rápido que um "
VLANs dinâmicas
Por fim, há uma função em alguns switches para fornecer associação dinâmica à VLAN. Em vez de atribuir uma determinada porta a ser uma porta de acesso para uma determinada VLAN, a configuração da porta (acesso ou tronco e para a qual VLANs) pode ser alterada dinamicamente quando um dispositivo está conectado. VLANs dinâmicas são um tópico mais avançado, mas saber que a funcionalidade existe pode ser útil.
A funcionalidade varia entre os fornecedores, mas geralmente você pode configurar a associação VLAN dinâmica com base no endereço MAC do dispositivo conectado, status de autenticação 802.1X do dispositivo, protocolos proprietários e baseados em padrões (CDP e LLDP, por exemplo, para permitir que telefones IP "descobrir" o número da VLAN para tráfego de voz), sub-rede IP atribuída ao dispositivo cliente ou tipo de protocolo Ethernet.