Quantas VLANs são poucas e muitas?

No momento, estamos executando uma rede de mais de 800 PCs e mais de 20 servidores, a infra-estrutura da rede segue as linhas do Core Switch 10Gb-> Switch de Área 2GB-> Switch Local de 1GB-> Desktop. Todo o equipamento 3Com em execução (1).

Temos 3 comutadores de área para quatro áreas (A, B, C, D são mesclados com o núcleo), cada comutador de área terá entre 10 e 20 comutadores locais conectados a eles. Há também um comutador principal de backup, com menos energia, mas conectado como o comutador principal.

Também temos um sistema de telefone IP. Os computadores / servidores e dispositivos estão em um intervalo 10.x ip, os telefones em um intervalo 192.168.x. Os computadores geralmente não precisam conversar entre si, exceto nos laboratórios de informática, mas precisam conversar com a maioria dos nossos servidores (AD, DNS, Exchange, armazenamento de arquivos etc.)

Quando configuramos, foi decidido que teríamos 3 VLANs, uma para Switches e Computadores, uma para Telefones e outra para replicação de servidor (isso era contra o conselho dos engenheiros da 3Com). A rede está estável e funcionando desde esse ponto (2), mas agora começamos a atualizar para o ambiente de SAN e Virtualização. Agora, dividir essa nova infraestrutura em VLANs separadas faz sentido, e repensar a maneira como nossas VLANS são configuradas parece sensato.

Agora está sendo proposto que as VLANs sejam configuradas sala por sala, ou seja, um laboratório de informática com mais de 5 PCs deve ser sua própria VLAN, mas se seguirmos esse modelo, procuraremos pelo menos 25 "novas" VLANS , além dos servidores VLANS for SAN / Virtual. O que me parece acrescentar uma quantidade excessiva de administração, embora, por acaso, esteja provado que estou errado.

Qual seria a melhor prática parece sugerir? Existe um certo número de PCs que é aconselhável não passar por cima / abaixo em uma VLAN.

(1) Os switches 3Com (3870 e 8800) roteiam entre VLANs de maneira diferente da maneira como outros fazem, não requer um roteador separado, pois são de camada3.

(2) Às vezes, obtemos altas taxas de descarte ou alterações de STP e, na ocasião, o diretor da 3Com Network informa que os switches estão com pouca carga e lentos para responder aos pings, ou um switch com falha que consegue derrubar a rede (todos os VLANs de telefone e computador! , uma vez, não faço ideia do porquê)

Parece que alguém em sua organização deseja criar VLANs sem entender os motivos pelos quais você faria isso e os prós / contras associados a eles. Parece que você precisa fazer algumas medições e apresentar algumas razões reais para fazer isso antes de avançar, pelo menos com a loucura insana de "VLAN para uma sala".

Você não deve começar a quebrar uma LAN Ethernet em VLANs, a menos que tenha boas razões para fazê-lo. Os dois melhores motivos são:

• Atenuando problemas de desempenho. As LANs Ethernet não podem ser escalonadas indefinidamente. Transmissões excessivas ou inundação de quadros para destinos desconhecidos limitarão sua escala. Qualquer uma dessas condições pode ser causada ao tornar um único domínio de broadcast em uma LAN Ethernet muito grande. O tráfego de transmissão é fácil de entender, mas a inundação de quadros para destinos desconhecidos é um pouco mais obscura ( tanto que nenhum dos outros pôsteres aqui menciona isso!) Se você obtiver tantos dispositivos que as tabelas MAC do seu switch estiverem transbordando, os switches serão forçados a inundar os quadros não transmitidos por todas as portas, se o destino do quadro não corresponder a nenhuma entrada na tabela MAC. Se você tiver um domínio de broadcast único grande o suficiente em uma LAN Ethernet com um perfil de tráfego que hospede a comunicação com pouca frequência (ou seja, com a frequência insuficiente de que suas entradas tenham idade fora das tabelas MAC nos seus comutadores), você também poderá obter uma inundação excessiva de quadros .

• O desejo de limitar / controlar o tráfego que se move entre os hosts na camada 3 ou acima. Você pode fazer alguma invasão examinando o tráfego na camada 2 (ala Linux ebtables), mas isso é difícil de gerenciar (porque as regras estão vinculadas aos endereços MAC e a alteração das NICs exige mudanças de regras) pode causar comportamentos que parecem realmente estranhos (fazer o proxy transparente do HTTP na camada 2, por exemplo, é esquisito e divertido, mas é totalmente natural e pode ser muito intuitivo para solucionar problemas) e geralmente é difícil de ser feito nas camadas inferiores (porque as ferramentas da camada 2 são como paus e rochas ao lidar com as preocupações da camada 3+). Se você deseja controlar o tráfego IP (ou TCP, UDP, etc) entre hosts, em vez de atacar o problema na camada 2, sub-rede e cole firewalls / roteadores com ACLs entre as sub-redes.

Os problemas de exaustão da largura de banda (a menos que sejam causados ​​por pacotes de transmissão ou inundação de quadros) não são resolvidos com VLANs normalmente. Elas acontecem devido à falta de conectividade física (poucas NICs em um servidor, poucas portas em um grupo de agregação, a necessidade de subir para uma velocidade de porta mais rápida) e não podem ser resolvidas sub-redes ou implantando VLANs desde aumentar a quantidade de largura de banda disponível.

Se você não tem nada simples como o MRTG executando gráficos de estatísticas de tráfego por porta em seus switches, essa é realmente a sua primeira ordem de negócios antes de começar a introduzir gargalos com segmentação de VLAN bem-intencionada, mas desinformada. A contagem bruta de bytes é um bom começo, mas você deve segui-lo com sniffing direcionado para obter mais detalhes sobre os perfis de tráfego.

Depois de saber como o tráfego circula na sua LAN, você pode começar a pensar em segmentar a LAN por motivos de desempenho.

Se você realmente quiser abotoar o acesso de pacotes e de fluxo entre VLANs, esteja preparado para fazer um monte de trabalho braçal com o software aplicativo e aprender / fazer engenharia reversa como ele fala por fio. A limitação do acesso dos hosts aos servidores geralmente pode ser realizada com a funcionalidade de filtragem nos servidores. A limitação do acesso por fio pode fornecer uma falsa sensação de segurança e impedir que os administradores cheguem a uma complacência em que pensam "Bem, não preciso configurar o aplicativo com segurança, porque os hosts que podem conversar com o aplicativo são limitados por 'the rede'." Recomendamos que você audite a segurança da configuração do servidor antes de começar a limitar a comunicação host a host.

Normalmente, você cria VLANs na Ethernet e mapeia as sub-redes IP 1 a 1 para elas. Você vai precisar de um monte de sub-redes IP para o que você está descrevendo, e, potencialmente, um monte de roteamento entradas da tabela. Planeje melhor essas sub-redes com o VLSM para resumir suas entradas da tabela de roteamento, não é?

(Sim, sim - existem maneiras de não usar uma sub-rede separada para cada VLAN, mas, seguindo um mundo estritamente "simples", você criaria uma VLAN, pense em uma sub-rede IP a ser usada na VLAN, atribua algum roteador um endereço IP nessa VLAN, conecte esse roteador à VLAN, com uma interface física ou uma subinterface virtual no roteador, conecte alguns hosts à VLAN e atribua-lhes endereços IP na sub-rede que você definiu e direcione seu tráfego para e fora da VLAN.)

As VLANs são realmente úteis apenas para restringir o tráfego de broadcast. Se algo produzir muita transmissão, separe-o em sua própria VLAN, caso contrário eu não me incomodaria. Você pode querer ter uma duplicação virtualizada de um sistema ativo na mesma rede e usar o mesmo intervalo de endereços; novamente, isso pode valer uma VLAN separada.

As VLANs são boas como um nível de segurança adicional. Não sei como a 3Com lida com isso, mas geralmente você pode segmentar diferentes grupos funcionais em diferentes VLANs (por exemplo, Contabilidade, WLAN, etc.). Você pode controlar quem tem acesso a uma VLAN específica.

Não acredito que haja perda significativa de desempenho se houver muitos computadores na mesma VLAN. Acho impraticável segmentar a LAN em uma sala por sala, mas, novamente, não sei como a 3Com lida com isso. Geralmente, a diretriz não é de tamanho, mas de segurança ou operação.

Na verdade, não vejo motivo para segmentar a LAN em diferentes VLANs, se não houver ganhos de segurança ou operacionais.

A menos que você tenha 25 grupos de teste e desenvolvimento que matam a rede regularmente com inundações de broadcast, 25 VLANs por sala são 24 demais.

Obviamente, sua SAN precisa de sua própria VLAN e não da mesma VLAN dos sistemas virtuais LAN e acesso à Internet! Tudo isso pode ser feito através de uma única porta Ethernet no sistema host, portanto, não se preocupe em dividir essas funções.

Se você tiver problemas de desempenho, considere colocar seu telefone e SAN em hardware de rede separado, não apenas em VLANs.

Sempre haverá tráfego de transmissão, seja transmissão de resolução de nomes, transmissão de ARP, etc. O importante é monitorar a quantidade de tráfego de transmissão. Se exceder de 3 a 5% do tráfego total, será um problema.

As VLANs são boas para reduzir o tamanho dos domínios de broadcast (como David afirmou) ou para segurança ou para criar redes de backup dedicadas. Eles não são realmente significados como domínios de "gerenciamento". Além disso, você adicionará complexidade e sobrecarga de roteamento à sua rede implementando VLANs.

Geralmente, você só deseja considerar o uso de VLANs quando precisar colocar dispositivos em quarentena (como uma área em que os usuários podem trazer seus próprios laptops ou quando você possui uma infraestrutura crítica de servidor que deve ser protegida) ou se o domínio de transmissão estiver em muito alto.

Os domínios de transmissão geralmente podem ter cerca de 1000 dispositivos antes de começar a ver problemas nas redes de 100Mbit, embora eu reduzisse isso para 250 dispositivos, se você estiver lidando com áreas Windows relativamente barulhentas.

Na maioria das vezes, as redes modernas não precisam de VLANs, a menos que você faça isso em quarentena (com firewall apropriado usando ACLs, é claro) ou limitação de transmissão.

Eles também são úteis para impedir transmissões de DHCP para alcançar dispositivos de rede indesejados.