Quando / por que começar a criação de sub-rede em uma rede?

Question

Em que condições começa a considerar a sub-rede de uma rede?

Estou procurando algumas regras gerais ou gatilhos baseados em métricas mensuráveis que tornam a sub-rede algo que deve ser considerado.

    

Answer 1

Pergunta interessante.

Historicamente, antes do advento de redes totalmente comutadas, a principal consideração para dividir uma rede em sub-redes tinha a ver com a limitação do número de nós em um único domínio de colisão. Ou seja, se você tivesse muitos nós, seu desempenho de rede atingiria um pico e, eventualmente, entraria em colapso sob carga pesada devido a colisões excessivas. O número exato de nós que poderiam ser implantados dependia de muitos fatores, mas em geral você não podia carregar regularmente o domínio de colisão muito além de 50% da largura de banda total disponível e ainda manter a rede estável o tempo todo. 50 nós na rede eram muitos nós naqueles dias. Com usuários de uso pesado, você pode ter 20 ou 30 nós antes de precisar criar sub-redes.

Naturalmente, com sub-redes full duplex totalmente comutadas, as colisões não são mais uma preocupação e assumindo usuários típicos do tipo desktop, normalmente é possível implantar centenas de nós em uma única sub-rede sem nenhum problema. Ter muito tráfego de broadcast, como outras respostas aludiram, pode ser uma preocupação dependendo de quais protocolos / aplicativos você está executando na rede. No entanto, entenda que a sub-rede de uma rede não necessariamente ajuda você com suas preocupações de tráfego de transmissão. Muitos dos protocolos usam a transmissão por um motivo - isto é, quando todos os nós na rede realmente precisam ver esse tráfego para implementar os recursos de nível de aplicativo desejados. Simplesmente criar uma sub-rede na rede, na verdade, não lhe compra nada se o pacote transmitido também precisar ser encaminhado para a outra sub-rede e transmitido novamente. Na verdade, isso realmente adiciona tráfego extra (e latência) a ambas as sub-redes, se você pensar assim.

Em geral, hoje em dia, as principais razões para as redes de sub-redes têm muito mais a ver com considerações de limites organizacionais, administrativos e de segurança do que qualquer outra coisa.

A pergunta original pede métricas mensuráveis que acionam considerações de sub-redes. Não tenho certeza se há algum em termos de números específicos. Isso dependerá drasticamente dos "aplicativos" envolvidos e não acho que realmente haja pontos de gatilho que geralmente se apliquem.

Em relação às regras de polegares no planejamento de sub-redes:

• Considere sub-redes para cada departamento / divisão organizacional, especialmente porque eles são não-triviais (mais de 50 nós !?) em tamanho.
• Considere sub-redes para grupos de nós / usuários que usam um conjunto de aplicativos comum que é diferente de outros usuários ou tipos de nó (desenvolvedores, dispositivos VoIP, chão de fábrica)
• Considere sub-redes para grupos de usuários com diferentes requisitos de segurança (protegendo o departamento de contabilidade, protegendo o Wi-Fi)
• Considere as sub-redes de uma perspectiva de epidemia de vírus, violação de segurança e contenção de danos. Quantos nós são expostos / violados - o que é um nível de exposição aceitável para sua organização? Essa consideração assume regras restritivas de roteamento (firewall) entre sub-redes.

Com tudo isso dito, a adição de sub-redes adiciona algum nível de sobrecarga administrativa e pode causar problemas em relação à falta de endereços de nós em uma sub-rede e ter muitos restantes em outro pool etc. As configurações de roteamento e firewall e a colocação de servidores na rede e tal se envolver mais, esse tipo de coisa. Certamente, cada sub-rede deve ter uma razão para existir que supere a sobrecarga de manutenção da topologia lógica mais sofisticada.

    

Answer 2

Se for um site único, não se incomode a menos que você tenha mais do que várias dúzias de sistemas, e mesmo assim é provavelmente desnecessário.

Hoje em dia, com todos usando comutadores de pelo menos 100 Mbps e mais de 1 Gbps, a única razão relacionada ao desempenho para segmentar sua rede é se você está sofrendo um excesso de tráfego de broadcast (ou seja, > 2% )

O principal outro motivo é a segurança, ou seja, DMZ para servidores voltados ao público, outra sub-rede para finanças ou uma VLAN / sub-rede separada para sistemas VoIP.

    

Answer 3

Limitar o escopo para quaisquer requisitos de conformidade que você possa ter (por exemplo, PCI) é um ótimo catalisador para segmentar algumas partes de sua rede. Segmentar seus sistemas de aceitação / processamento de pagamentos e finanças pode economizar dinheiro. Mas, em geral, a criação de sub-redes em uma rede pequena não lhe renderá muito em termos de desempenho.

    

Answer 4

Outro motivo seria relacionado ao Quality of Service. Nós executamos vlans de voz e dados separadamente para que possamos aplicar facilmente o QoS ao tráfego voip.

Você sabe, eu estive pensando mais sobre essa questão. Há vários bons motivos para projetar uma nova rede usando redes distintas (desempenho, segurança, QoS, limitação de escopos DHCP, limitação do tráfego de broadcast (que pode ser relacionado tanto à segurança quanto ao desempenho)).

Mas quando se pensa em uma métrica para redesenhar apenas a sub-rede e pensar em redes que eu tive que lidar no passado, tudo o que posso pensar é "wow, isso teria que criar uma rede realmente confusa para fazer me redesenhar completamente para sub-redes ". Há muitas outras razões - largura de banda, utilização da CPU dos dispositivos instalados, etc. Mas apenas criar uma sub-rede em uma rede de dados pura normalmente não iria comprar uma tonelada de desempenho

    

Answer 5

Segurança e qualidade principalmente (desde que o segmento de rede em questão possa suportar os nós em questão, é claro). Uma rede separada para tráfego de impressora, voz / telefone, departamentos isolados como IT Ops e, claro, segmentos de servidor, segmentos voltados para a Internet (um por serviço voltado para a Internet é popular hoje em dia, e não apenas "um dmz") e assim por diante.

    

Answer 6

Se você espera ampliar (você está construindo uma rede, não apenas 5 servidores e isso é o que nós) começaremos a rotear o mais rápido possível. Muitas redes são instáveis e difíceis de cultivar porque cresceram organicamente e têm muita coisa na camada 2.

Exemplos:

• você tem dois servidores de nomes no mesmo segmento de rede. Agora você não pode mover um deles para outra cidade, porque então você terá que dividir o valor de nice / 24 ou renumerar o DNS. Muito mais fácil se eles estivessem em redes diferentes. Eu não estou falando necessariamente sobre estes se tornarem anúncios separados do BGP para o mundo. Este exemplo seria para um ISP nacional. Observe também que algumas coisas na área de provedores de serviços não são tão fáceis quanto "basta registrar o novo DNS no registrador".
• Loops da camada 2 sugam o cu. Assim como a árvore de abrangência (e VTP). Quando a árvore de abrangência falha (e há muitos casos em que isso ocorre), ela levará tudo para baixo devido à inundação que ocorre na CPU do comutador / roteador. Quando o OSPF ou IS-IS falha (ou outros protocolos de roteamento), ele não trava toda a rede e você pode consertar um segmento de cada vez. Isolamento de falhas.

Então, em suma: quando você escala para onde você acha que precisa de spanning tree, considere rotear.

    

Answer 7

Pessoalmente, gosto de levar a segmentação da camada 3 o mais próximo possível das chaves de acesso, porque

• Eu não gosto de Spanning Tree (você pode fazer coisas muito engraçadas se você for malvado)
• Especialmente nas redes Windoze, as transmissões são um problema real.
• Em redes privadas, você tem muito espaço de IP para desperdiçar:)
• Até mesmo switches mais baratos têm recursos de roteamento de velocidade por fio - por que não usá-los?
• Facilita a vida quando se trata de segurança (por exemplo, Auth e ACLs no egde, etc)
• Melhores possibilidades de QoS para VoIP e material em tempo real
• Você pode informar a localização de um cliente a partir do seu IP

Se se trata de redes maiores / mais largas em que dois switches / switches centrais não são suficientes, os mecanismos normais de redundância como o VRRP têm muitas desvantagens (o tráfego passa várias vezes uplinks, ...) o OSPF não tem.

Provavelmente, há muitos outros motivos para apoiar a abordagem usar pequenos broadcast de domínios .

    

Answer 8

Eu acho que o escopo da organização é muito importante. Se houver 200 hosts no total ou em menos de uma rede e o tráfego não precisar ser segmentado por algum motivo, por que adicionar a complexidade de VLANs e sub-redes? Mas quanto maior o escopo, mais isso pode fazer sentido.

A divisão de redes que normalmente não precisariam ser pode facilitar algumas coisas. Por exemplo, nossas PDUs que fornecem energia para servidores estão na mesma VLAN ou sub-rede que os servidores. Isso significa que nosso sistema de varredura de vulnerabilidades usado em nosso servidor também examina PDUs. Não é um grande negócio, mas não precisamos de PDUs para serem escaneados. Além disso, seria bom para o DHCP as PDUs, pois é difícil configurar, mas como elas estão na mesma VLAN que os servidores agora, isso não é muito viável.

Embora não precisemos de outra VLAN para as PDUs, isso pode facilitar algumas coisas. E isso entra no argumento de VLANs, mais contra menos, que continuará para sempre.

Eu só acho que tenho VLANs onde faz sentido. Se, por exemplo, fornecermos às PDUs sua própria VLAN, isso não significa que sempre temos que fornecer a pequenos grupos de dispositivos sua própria VLAN. Mas, em vez disso, neste caso, pode fazer sentido. Se um grupo de dispositivos não precisar ter sua própria VLAN e não houver vantagens em fazê-lo, convém considerar apenas deixar as coisas como estão.