Como funcionam as VLANs?

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 dinheiro na compra de hardware paralelo. Estarei falando sobre VLANs Ethernet nesta resposta (mesmo que outras tecnologias de rede possam suportar VLANs) e não vou me aprofundar em todas as nuances.

Um exemplo inventado e um problema

Como um cenário de exemplo puramente artificial, imagine que você possui um prédio de escritórios que aluga para inquilinos. Como benefício do arrendamento, cada inquilino receberá 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 locatários usam sub-redes TCP/IP diferentes e tudo parece funcionar bem.

Mais tarde, um novo inquilino aluga metade do andar 3 e traz um desses servidores DHCP novos. O tempo passa e o inquilino do 1º andar decide entrar na onda do DHCP também. Este é o ponto em que as coisas começam a dar errado. Os inquilinos do andar 3 relatam que alguns de seus computadores estão obtendo endereços IP "engraçados" de uma máquina que não é seu servidor DHCP. Logo, os inquilinos do andar 1 relatam a mesma coisa.

DHCP é um protocolo que aproveita a capacidade de transmissão da Ethernet para permitir que computadores clientes obtenham endereços IP dinamicamente. Como todos os locatários estão compartilhando a mesma rede Ethernet física, eles compartilham o mesmo domínio de transmissão. Um pacote de broadcast 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ão de endereços IP e, efetivamente, duelarão para ver quem pode responder primeiro. Este claramente não é o comportamento que você pretende que seus inquilinos experimentem. Este é o comportamento, porém, de uma rede Ethernet "plana" sem quaisquer VLANs.

Pior ainda, um inquilino no andar 2 adquire esse software "Wireshark" e relata que, de tempos em tempos, vê tráfego saindo de seu switch que faz referência a computadores e endereços IP dos quais nunca ouviu falar. Um de seus funcionários até descobriu que 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 realizar "serviços de administração de sistema pro-bono não autorizados" para um dos outros inquilinos. Não é bom.

Soluções potenciais

Você precisa de uma solução! Você poderia 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 piso 3. Se não houver uma conexão entre o interruptor do piso 3 e o interruptor do porão, o novo inquilino não será capaz de obter comunicação entre seus computadores que estarão espalhados por ambos os andares. Puxar os plugues não é a resposta. Pior ainda, o novo inquilino está trazendo mais um desses servidores DHCP!

Você flerta com a ideia de comprar conjuntos fisicamente separados de switches Ethernet para cada inquilino, mas vendo como seu prédio tem 30 andares, qualquer um dos quais pode ser subdividido em até 4 maneiras, o ninho de ratos em potencial de cabos piso a piso entre um grande número de switches Ethernet paralelos pode ser um pesadelo, para não dizer caro. Se ao menos houvesse uma maneira de fazer uma única rede Ethernet física agir como se fosse várias redes Ethernet físicas, cada uma com seu próprio domínio de transmissão.

VLANs para o resgate

As VLANs são uma resposta para esse problema confuso. As VLANs permitem subdividir um switch Ethernet em switches Ethernet virtuais logicamente diferentes. Isso permite que um único switch Ethernet aja como se fossem vários switches Ethernet físicos. No caso do seu piso 3 subdividido, 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 estejam em uma determinada VLAN ( que chamaremos de VLAN 13). Ao criar as VLANs em seu switch, você terá que atribuir a elas algum tipo de nome ou número de VLAN. Os números que estou usando aqui são na maioria arbitrários, então não se preocupe com quais números específicos eu escolho.

Depois de dividir o switch do piso 3 nas VLANs 12 e 13, você descobre que o novo inquilino do piso 3 pode conectar seu servidor DHCP a uma das portas atribuídas à VLAN 13 e um PC conectado a uma porta atribuída à VLAN 12 não t obter um endereço IP do novo servidor DHCP. Excelente! Problema resolvido!

Oh, espere... como podemos levar os dados da VLAN 13 para o porão?

Comunicação VLAN entre Switches

Seu inquilino de meio andar 3 e meio porão gostaria de conectar computadores no porão a seus servidores no andar 3. Você pode passar um cabo diretamente de uma das portas atribuídas à VLAN no switch do andar 3 para o porão e a vida seria bom, certo?

Nos primórdios das VLANs (padrão anterior ao 802.1Q), você poderia fazer exatamente isso. Todo o switch do porão seria, efetivamente, parte da VLAN 13 (a VLAN que você optou por atribuir ao novo inquilino no andar 3 e ao porão) porque esse switch do porão seria "alimentado" por uma porta no andar 3 atribuída para VLAN 13.

Essa solução funcionaria até você alugar a outra metade do porão para o inquilino do 1º andar que também deseja ter comunicação entre o 1º andar e os computadores do porão. Você pode dividir o switch do porão usando VLANs (em, digamos, VLANS 2 e 13) e passar um cabo do andar 1 para uma porta atribuída à VLAN 2 no porão, mas seu melhor julgamento diz que isso pode rapidamente se tornar um ninho de ratos de cabos (e só vai piorar). Dividir switches usando VLANs é bom, mas ter que passar 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 switch do porão de 4 maneiras entre os inquilinos que também tinham espaço nos andares mais altos, você usaria 4 portas no switch do porão apenas para terminar os cabos "alimentadores" das VLANs do andar de cima.

Agora deve ficar claro que algum tipo de método generalizado de movimentação de tráfego de várias VLANs entre switches em um único cabo é necessário. Apenas adicionar mais cabos entre switches para dar suporte a conexões entre diferentes VLANs não é uma estratégia escalável. Eventualmente, com VLANs suficientes, você estará consumindo todas as portas em seus switches com essas conexões inter-VLAN/inter-switch. O que é necessário é uma maneira de transportar os pacotes de várias VLANs ao longo de uma única conexão - uma conexão "tronco" entre os switches.

Até este ponto, todas as portas de switch sobre as quais 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 quaisquer VLANs estão presentes. Os quadros que os dispositivos clientes enviam são entregues ao switch, que se encarrega de garantir que o quadro seja enviado apenas às portas atribuídas como membros da VLAN atribuída à porta em que o quadro entrou no switch. Se um quadro entrar no switch em uma porta atribuída como membro da VLAN 12, o switch só enviará esse quadro para as portas que são membros da VLAN 12. O switch "sabe" o número da VLAN atribuído a uma porta da qual recebe um frame e de alguma forma sabe apenas entregar este frame para fora das portas da mesma VLAN.

Se houvesse alguma maneira de um switch compartilhar o número de VLAN associado a um determinado quadro para outros switches, o outro switch poderia lidar adequadamente com a entrega desse quadro apenas para as portas de destino apropriadas. Isso é o que o protocolo de marcação 802.1Q VLAN faz. (Vale a pena notar que, antes do 802.1Q, alguns fornecedores criavam seus próprios padrões para marcação de VLAN e entroncamento entre comutadores. Na maior parte, esses métodos pré-padrão foram todos suplantados pelo 802.1Q.)

Quando você tem dois switches com reconhecimento de VLAN conectados um ao outro e deseja que esses switches entreguem quadros entre si para a VLAN adequada, você conecta esses switches usando portas "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 para aquela porta terá uma "tag VLAN" incluída 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. Esta etiqueta indica o número de VLAN associado à porta da qual o quadro se originou.

O switch receptor pode examinar a etiqueta para determinar de qual VLAN o quadro se originou e, com base nessa informação, encaminhar o quadro apenas para as portas atribuídas à VLAN de origem. Como os dispositivos conectados às portas de "acesso" não estão cientes de que as VLANs estão sendo usadas, as informações de "tag" devem ser retiradas do quadro antes de serem enviadas para uma porta configurada no modo de acesso. Essa remoção das informações de tag faz com que todo o processo de entroncamento de VLAN seja ocultado dos dispositivos clientes, pois o quadro que eles recebem não conterá nenhuma informação de tag de VLAN.

Antes de configurar 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 algum tráfego de amostra de outro computador, conectado a uma porta de acesso, e ver 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 tag VLAN nos quadros no Wireshark. Acho que vale a pena realmente ver o que acontece em um sniffer. Ler sobre o padrão de marcação 802.1Q também é uma coisa decente a se fazer neste momento (especialmente porque não estou falando de coisas como "VLANs nativas" ou marcação dupla).

Pesadelos de configuração de VLAN e a solução

À medida que você aluga mais e mais espaço em seu prédio, o número de VLANs cresce. Cada vez que você adiciona uma nova VLAN, você 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 de VLAN de cada switch?

Protocolos como o "VLAN Trunking Protocol" (VTP) proprietário da Cisco ou o "Multiple VLAN Registration Protocol" (MVRP--GVRP) baseado em padrões) cumprem essa 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 para todos os switches da rede. Essa mensagem de protocolo comunica a mudança na configuração de VLAN para o restante dos switches que, por sua vez, modificam suas configurações de VLAN. O VTP e o MVRP não se preocupam com quais portas específicas sã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 switches.

Quando você se familiarizar com as VLANs, provavelmente desejará voltar e ler sobre a "remoção de VLANs", que está associada a protocolos como VTP e MVRP. Por enquanto não é nada para se preocupar tremendamente. (O artigo VTP na Wikipedia tem um diagrama legal que explica a remoção de VLAN e os benefícios com isso.)

Quando você usa VLANs na vida real?

Antes de irmos muito mais longe, é importante pensar na vida real ao invés de exemplos artificiais. Em vez de duplicar o texto de outra resposta, vou encaminhá-lo para minha resposta: quando criar VLANs . Não é necessariamente "nível iniciante", mas vale a pena dar uma olhada agora, pois vou fazer uma breve referência a ele antes de voltar a um exemplo artificial.

Para a multidão "tl;dr" (que certamente parou de ler neste ponto, de qualquer maneira), a essência desse link acima é: Crie VLANs para tornar os domínios de broadcast menores ou quando você quiser segregar o tráfego por algum motivo específico (segurança , política, etc). Não há realmente nenhuma outra boa razão para usar VLANs.

Em nosso exemplo, estamos usando VLANs para limitar domínios de broadcast (para manter protocolos como DHCP funcionando corretamente) e, secundariamente, porque queremos isolamento entre as várias redes de inquilinos.

Um aparte re: Sub-redes IP e VLANs

De um modo geral, geralmente há um relacionamento um-para-um entre VLANs e sub-redes IP por questão de 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 combinará seu 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á anulando o propósito de isolamento.

O IP usa um protocolo baseado em broadcast, Address Resolution Protocol (ARP), para mapear endereços IP em endereços físicos (Ethernet MAC). Como o ARP é baseado em broadcast, atribuir diferentes partes da mesma sub-rede IP a diferentes VLANs seria problemático porque os hosts em uma VLAN não poderiam receber respostas ARP de hosts na outra VLAN, pois as transmissões não são encaminhadas entre VLANs. Você pode resolver esse "problema" usando proxy-ARP, mas, em última análise, a menos que você tenha um bom motivo para precisar dividir uma sub-rede IP em várias VLANs, é melhor não fazê-lo.

Um último lado: VLANs e segurança

Finalmente, vale a pena notar que as VLANs não são um ótimo dispositivo de segurança. Muitos switches Ethernet têm bugs que permitem que quadros originados de uma VLAN sejam enviados para portas atribuídas a outra VLAN. Os fabricantes de switches Ethernet trabalharam duro para corrigir esses bugs, mas é duvidoso que haja uma implementação completamente livre de bugs.

No caso do nosso exemplo artificial, o funcionário do andar 2 que está a momentos de fornecer "serviços" gratuitos de administração de sistemas para outro inquilino pode ser impedido de fazê-lo isolando seu tráfego em uma VLAN. Ele também pode descobrir como explorar bugs no firmware do switch, no entanto, para permitir que seu tráfego "vaze" também para a VLAN de outro locatário.

Os provedores Metro Ethernet estão confiando cada vez mais na funcionalidade de marcação de VLAN e no isolamento que os switches fornecem. Não é justo dizer que não há segurança oferecida pelo uso de VLANs. É justo dizer, porém, que em situações com conexões de Internet não confiáveis ​​ou redes DMZ, provavelmente é melhor usar switches fisicamente separados para transportar esse tráfego "sensível" em vez de VLANs em switches que também transportam seu tráfego confiável "atrás do firewall".

Trazendo a camada 3 para a imagem

Até agora, tudo o que esta resposta falou está relacionado à camada 2 - quadros Ethernet. O que acontece se começarmos a trazer a camada 3 para isso?

Vamos voltar ao exemplo da construção artificial. Você adotou as VLANs e optou por configurar as portas de cada locatário como membros de VLANs separadas. Você configurou as portas de tronco de forma que o switch de cada andar possa trocar quadros marcados com o número da VLAN de origem para os switches no andar acima e abaixo. Um locatário 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 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 locatários. Você compra um tubo de Internet gordo e um roteador. Você apresenta a ideia a todos os seus inquilinos e dois deles imediatamente aderem. 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 de switch designada para acesso à VLAN do primeiro locatário e a outra a uma porta designada para acesso à VLAN do segundo locatário. Você configura as portas do seu roteador com endereços IP na rede de cada locatário e os locatários começam a acessar a Internet através do seu serviço! A receita aumenta e você fica feliz.

Logo, porém, outro inquilino decide entrar na sua oferta de Internet. Você está sem portas no seu roteador, no entanto. 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 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á. Na verdade, isso permite que você "multiplexe" 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 switches e configura subinterfaces virtuais correspondentes ao esquema de endereçamento IP de cada locatário. Cada subinterface virtual é configurada com o número de VLAN atribuído a cada Cliente. Quando um quadro sai da porta de tronco no switch, vinculado ao roteador, ele carrega uma etiqueta com o número da VLAN de origem (já que é uma porta de tronco). O roteador interpretará esta etiqueta e tratará o pacote como se tivesse chegado em uma interface física dedicada correspondente àquela VLAN. Da mesma forma, quando o roteador envia um quadro para o switch em resposta a uma solicitação, ele adiciona uma tag VLAN ao quadro, de modo que o switch saiba para qual VLAN o quadro de resposta deve ser entregue. Na verdade, você configurou o roteador para "aparecer"

Roteadores em Sticks e Switches de Camada 3

Usando subinterfaces virtuais, você pode vender conectividade com a Internet para todos os seus locatários 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 locatários chegam até você com uma nova solicitação.

Esses locatários optaram por "parceiros" em um projeto e desejam permitir o acesso de computadores clientes no escritório de um locatário (uma determinada VLAN) a um computador servidor no escritório do outro locatário (outra VLAN). Como ambos são clientes do seu serviço de Internet, é uma mudança bastante simples de uma ACL em seu roteador de Internet principal (no qual há uma subinterface virtual configurada para cada uma das VLANs desses locatários) para permitir que o tráfego flua entre suas VLANs como bem como à Internet de suas VLANs. Você faz a mudança e envia os inquilinos a caminho.

No dia seguinte, você recebe reclamações de ambos os locatários de que o acesso entre os computadores cliente em um escritório e o servidor no segundo escritório é muito lento. Os computadores servidor e cliente têm conexões Gigabit Ethernet para seus switches, mas os arquivos são transferidos apenas a cerca de 45Mbps, o que, coincidentemente, é aproximadamente metade da velocidade com que seu roteador principal se conecta ao switch. Claramente, o tráfego que flui da VLAN de origem para o roteador e de volta do roteador para a VLAN de destino está sendo afunilado pela conexão do roteador ao switch.

What you've done with your core router, allowing it to route traffic between VLANs, is commonly known as "router on a stick" (an arguably stupidly whimsical euphemism). This strategy can work well, but traffic can only flow between the VLANs up to the capacity of the router's connection to the switch. If, somehow, the router could be conjoined with the "guts" of the Ethernet switch itself it could route traffic even faster (since the Ethernet switch itself, per the manufacturer's spec sheet, is capable of switching over 2Gbps of traffic).

A "layer 3 switch" is an Ethernet switch that, logically speaking, contains a router buried inside itself. I find it tremendously helpful to think of a layer 3 switch as having a tiny and fast router hiding inside the switch. Further, I would advise you to think about the routing functionality as a distinctly separate function from the Ethernet switching function that the layer 3 switch provides. A layer 3 switch is, for all intents and purposes, two distinct devices wrapped up in a single chassis.

The embedded router in a layer 3 switch is connected to the switch's internal switching fabric at a speed that, typically, allows for routing of packets between VLANs at or near wire-speed. Analogously to the virtual sub-interfaces you configured on your "router on a stick" this embedded router inside the layer 3 switch can be configured with virtual interfaces that "appear" to be "access" connections into each VLAN. Rather than being called virtual sub-interfaces these logical connections from the VLANs into the embedded router inside a layer 3 switch are called Switch Virtual Interfaces (SVIs). In effect, the embedded router inside a layer 3 switch has some quantity of "virtual ports" that can be "plugged in" to any of the VLANs on the switch.

The embedded router performs the same way as a physical router except that it typically doesn't have all of the same dynamic routing protocol or access-control list (ACL) features as a physical router (unless you've bought a really nice layer 3 switch). The embedded router has the advantage, however, of being very fast and not having a bottleneck associated with a physical switch port that it's plugged into.

In the case of our example here with the "partnering" tenants you might opt to obtain a layer 3 switch, plug it into trunk ports such that traffic from both Customers VLANs reaches it, then configure SVIs with IP addresses and VLAN memberships such that it "appears" in both Customers VLANs. Once you've done that it's just a matter of tweaking the routing table on your core router and the embedded router in the layer 3 switch such that traffic flowing between the tenants' VLANs is routed by the embedded router inside the layer 3 switch versus the "router on a stick".

Using a layer 3 switch doesn't mean that there still won't be bottlenecks associated with the bandwidth of the trunk ports that interconnect your switches. This is an orthogonal concern to those that VLANs address, though. VLANs have nothing to do with bandwidth problems. Typically bandwidth problems are solved by either obtaining higher-speed inter-switch connections or using link-aggregation protocols to "bond" several lower-speed connections together into a virtual higher-speed connection. Unless all the devices creating frames to be routed by the embedded router inside the later 3 switch are, themselves, plugged into ports directly on the layer 3 switch you still need to worry about the bandwidth of the trunks between the switches. A layer 3 switch isn't a panacea, but it's typically faster than a "router on a stick".

Dynamic VLANs

Lastly, there is a function in some switches to provide dynamic VLAN membership. Rather than assigning a given port to be an access port for a given VLAN the port's configuration (access or trunk, and for which VLANs) can be altered dynamically when a device is connected. Dynamic VLANs are a more advanced topic but knowing that the functionality exists can be helpful.

The functionality varies between vendors but typically you can configure dynamic VLAN membership based on the MAC address of the connected device, 802.1X authentication status of the device, proprietary and standards-based protocols (CDP and LLDP, for example, to allow IP phones to "discover" the VLAN number for voice traffic), IP subnet assigned to the client device, or Ethernet protocol type.

VLANs são "redes locais virtuais". O seguinte é o meu entendimento - minha formação é principalmente Engenharia e Administração de Sistemas com um lado de programação OO e muito script.

As VLANs destinam-se a criar uma rede isolada em vários dispositivos de hardware. Uma LAN tradicional em tempos antigos pode existir apenas onde você tem um único dispositivo de hardware dedicado a uma rede específica. Todos os servidores/dispositivos conectados a esse dispositivo de rede (Switch ou Hub, dependendo do período histórico) normalmente têm permissão para se comunicar livremente entre a LAN.

Uma VLAN difere de tal forma que você pode interconectar vários dispositivos de rede e criar redes isoladas agrupando servidores em uma VLAN, eliminando assim a necessidade de ter um dispositivo de rede "dedicado" para uma única LAN. O número de VLANs configuráveis ​​e servidores/dispositivos suportados variam entre os fabricantes de dispositivos de rede.

Novamente, dependendo do fornecedor, não acho que todos os servidores precisem estar na mesma sub-rede para fazer parte da mesma VLAN. Com as configurações de rede legadas, acredito que sim (o engenheiro de rede insere a correção aqui).

O que diferencia uma VLAN de uma VPN é a letra "P" de "Privada". Normalmente, o tráfego de VLAN não é criptografado.

Espero que ajude!