☰

Estratégia de sub-redes e VLANs para vários edifícios

tag-icon • tag-icon networking vlan subnet
Estratégia de sub-redes e VLANs para vários edifícios

Curioso para receber um pequeno feedback sobre como outros fazem isso.

Um site que estou vendo tem vários edifícios conectados por fibra e cada um está em sua própria sub-rede.

192.168.0.0 - Building 1 - VLAN10
192.168.1.0 - Building 2 - VLAN20
192.168.2.0 - Building 3 - VLAN30

etc.

(para constar, entendo as implicações indesejadas de estar em uma sub-rede 192.168)

Cada prédio administra seu próprio pequeno datacenter com servidores DHCP e controladores de domínio.

Meu grande problema é que acho muito confuso ter servidores em

192.168.0.1 - building 1
192.168.0.5 - building 1
192.168.1.11 - building 2
192.168.2.5 - building 3
etc.

Obviamente, eu poderia dizer que colocaria todos os equipamentos de rede na sub-rede 192.168.0.0 e todos os servidores em 192.168.1.0, DHCP em 192.168.3.0, mas isso criaria vlans cruzadas.

Por exemplo, eu provavelmente ainda desejaria um servidor DHCP na VLAN20 com todos os computadores daquele prédio e, da mesma forma, um servidor DHCP na VLAN10 com os computadores daquele prédio.

Por tradição, as VLANs são mantidas 1 para 1 com sua sub-rede.

Como os outros gerenciam isso? Você sabe que 192.168.0.1-.50 está reservado para equipamentos de servidor?

Eu vim de uma rede 10.1.0.0/21, então tínhamos endereços suficientes para manter tudo separado e não fizemos nenhuma vlan.

Responder1

Esta é uma pergunta muito difícil de responder com base em cenários porque há muitos factores a considerar com pouca informação fornecida. No entanto, em um sentido geral, aqui está minha visão.

Em primeiro lugar, concordo com os comentários contra a questão de que nenhum grupo de endereços privados é mais ou menos desejável do que outro com base na susceptibilidade de ser semelhante a utilizadores domésticos. Pela minha experiência, não importa o quanto você tente evitar conflitos com usuários VPN, se isso não ocorrer para o usuário 'A', eventualmente haverá algum usuário 'B' para o qual isso ocorre.

Uma coisa crítica que você não mencionou na pergunta é o volume de dispositivos e o crescimento esperado ao longo da vida útil da infraestrutura. Manterei os pontos gerais, devido ao escopo aberto e à ambiguidade.

Se você estiver determinado a dividir sua rede em sub-redes por edifício, primeiro identifique o número de edifícios necessários e, em seguida, considere a probabilidade de que isso seja suficiente por um prazo mais longo (5 a 10 anos). Tente chegar a uma quantidade de redes que não seja excessiva, mas realista. Eu normalmente seria liberal e permitiria despesas marginais. Use isto para definir o intervalo mais estreito prático para sub-redes de nível superior.

Por exemplo, se você tem 3 edifícios, mas previu que isso poderia crescer para 5 em 10 anos, escolha um múltiplo de base dois que seja sensato para isso e divida o primeiro octeto utilizável com este prefixo. Por exemplo. de 172.16.xx com até 8 redes:

000 | x xxxx . xxxx xxxx - Common Equiptment. 192.168.0.0 /19
001 | x xxxx . xxxx xxxx - Building 1. 172.16.32.0 /19
010 | x xxxx . xxxx xxxx - Building 2. 172.16.64.0 /19
011 | x xxxx . xxxx xxxx - Building 3. 172.16.96.0 /19
100 | x xxxx . xxxx xxxx - Building 4. 172.16.128.0 /19

Isso maximizará o escopo do seu endereço e permitirá sub-redes adicionais. Também simplifica a definição de rotas se todas as sub-redes dentro de qualquer escopo .19 passarem pelo mesmo nó para a maior parte da rede restante. Observe que esse equilíbrio deve funcionar de duas maneiras. Digamos, por exemplo, que você tenha um pequeno número de edifícios além de seus edifícios principais, como escritórios remotos, que não precisam de muitos endereços, mas simplesmente precisam estar conectados - você pode alocá-los em uma única sub-rede 'pai' de edifício, e divida-o para atendê-los. Em última análise, seu objetivo é manter o maior espaço de endereço onde ele será mais necessário.

A partir daqui, você poderá dividir ainda mais sua rede em cotas específicas de aplicativos. Você pode fazer algo como o seguinte:

Edifício 1 (de cima).

001 | 0 0 | xxx . xxxx xxxx - Building 1's Default Network. 172.16.32.0 /21
001 | 0 1 | xxx . xxxx xxxx - Building 1's Misc Networks. 172.16.40.0 /21
001 | 1 0 | xxx . xxxx xxxx - Building 1's Phone Network. 172.16.48.0 /21

Poderíamos levar isso adiante e ter:

001 | 0 1 | xxx . xxxx xxxx - Building 1's Misc Networks. 172.16.40.0 /21
001 | 0 1 | 001 . xxxx xxxx - Management Network. 172.16.41.0 /24
001 | 0 1 | 010 . xxxx xxxx - Security Camera Network. 172.16.42.0 /24
001 | 0 1 | 011 . xxxx xxxx - Alarm System Network. 172.16.43.0 /24

Acho que o importante a tirar é encontrar uma solução que funcione para o seu cenário. Você provavelmente vai querer:

  • Maximize o espaço para crescimento, onde é mais provável que ocorra. Suponho que seria a rede de seus usuários finais.
  • Mantenha padrões consistentes sempre que possível, para que as ACLs e as regras de firewall possam ser simplificadas. Por exemplo, se você souber no terceiro octeto que o quarto e o quinto bits com o padrão '01' sempre denotarão as 'redes diversas', você poderia ter uma máscara de bits para capturar todos os edifícios em uma única regra.
  • Em vez de focar se um espaço de endereço pode ou não entrar em conflito com a rede doméstica de um usuário, tente focar seu projeto em como eles o usarão. Por exemplo; se for uma VPN ponto a ponto, sem tradução nem sobrecarga, com passagem de tráfego roteado adicional, pode ser importante manter escopos de endereços compatíveis. Para a maioria dos usuários domésticos, a colisão não importará, porque eles se conectarão a partir de seu dispositivo final e seu dispositivo tratará sua conexão como gateway para todo o tráfego. Qualquer desvio disso pode ser contra sua política de uso e fora do escopo de seu suporte.
  • Redes da mesma sub-rede não precisam estar na mesma VLAN... mas provavelmente deveriam estar. O ID da VLAN é exatamente isso; apenas um número. Não precisa ser o mesmo entre os dispositivos conectados se eles não o trocarem, mas não consigo pensar em nenhum cenário em que seria benéfico ter uma estrutura de ID de VLAN inconsistente. Para unir duas VLANs diferentes na mesma rede, você usaria uma ponte (switch). Essencialmente, você terá dividido um switch em vários sub-switches e unido-os de maneira ineficiente, de uma maneira difícil de manter.
  • Minimize o roteamento desnecessário. Embora ter todas essas redes possa ser agradável e lógico, se um grande volume de tráfego passar da rede A para a rede B através de um roteador, não é suficiente apenas assumir que o roteador é capaz de suportá-lo, partindo da premissa de que sua velocidade de porta são adequados. Por exemplo, o roteador Ethernet dual gigabit Cisco 1941, embora tenha portas dual gigabit, tem apenas uma taxa de transferência especulada de 153 Mbps entre redes. (Especificações de rendimento)
  • Não tenha redes suficientes (...no espírito de ser contraditório). Se você não usasse sub-redes para dividir sua rede, uma transmissão alcançaria todos os dispositivos. Se você achar que determinados grupos de dispositivos não precisam se comunicar diretamente com frequência, esta é uma boa indicação de que eles devem ser separados.
  • Adote a escalabilidade horizontal, dentro e entre redes. Em vez de ter um grande servidor atendendo todos os seus usuários; tenha um servidor menor para cada rede para atender apenas seus clientes. Eles poderiam compartilhar uma fonte de dados comum e isso também aliviaria o seu roteador. No entanto, existem muitas maneiras de obter escala horizontal.

Espero que isso ajude ou lhe dê algumas idéias :)

informação relacionada