Quand / pourquoi commencer à sous-réseauter un réseau?

Dans quelles conditions commence-t-on à envisager de sous-réseauter un réseau?

Je cherche quelques règles générales ou des déclencheurs basés sur des métriques mesurables qui font de la sous-traitance un élément à prendre en compte.

Question interessante.

Historiquement, avant l’avènement des réseaux entièrement commutés, la principale considération lors de la décomposition d’un réseau en sous-réseaux était de limiter le nombre de nœuds dans un seul domaine de collision. Autrement dit, si vous avez trop de nœuds, les performances de votre réseau atteindront un sommet et finiront par s’effondrer sous une charge importante en raison de collisions excessives. Le nombre exact de nœuds pouvant être déployés dépend de nombreux facteurs, mais en règle générale, vous ne pouvez pas charger régulièrement le domaine de collision bien au-delà de 50% de la bande passante totale disponible, tout en maintenant le réseau stable. 50 nœuds sur le réseau étaient beaucoup de nœuds à cette époque. Avec des utilisateurs très intensifs, il se peut que vous ayez dépassé 20 ou 30 nœuds avant de devoir commencer à créer des sous-réseaux.

Bien sûr, avec les sous-réseaux en duplex intégral entièrement commutés, les collisions ne sont plus un problème et, en supposant que les utilisateurs de type bureau soient typiques, vous pouvez généralement déployer des centaines de nœuds dans un même sous-réseau sans aucun problème. Comme d'autres réponses l'ont évoqué, le trafic de diffusion peut être un problème en fonction des protocoles / applications que vous exécutez sur le réseau. Toutefois, comprenez que la mise en sous-réseau d’un réseau ne vous aide pas nécessairement à résoudre vos problèmes de trafic de diffusion. De nombreux protocoles utilisent la diffusion pour une raison quelconque, c'est-à-dire lorsque tous les nœuds du réseau doivent réellement voir ce trafic pour implémenter la ou les fonctionnalités au niveau de l'application souhaitées. Sous-réseauter simplement le réseau ne vous achète réellement rien si le paquet diffusé doit également être transféré vers l'autre sous-réseau et rediffusé.

De manière générale, aujourd’hui, les principales raisons des réseaux de sous-réseaux sont beaucoup plus liées à des considérations d’organisation, d’administration et de sécurité que toute autre chose.

La question initiale demande des mesures mesurables qui déclenchent des considérations de sous-réseau. Je ne suis pas sûr qu'il y en ait en termes de chiffres spécifiques. Cela dépendra énormément des «applications» impliquées et je ne pense pas qu'il y ait vraiment de déclencheur qui s'appliquerait généralement.

Par rapport aux règles empiriques dans la planification des sous-réseaux:

• Envisagez des sous-réseaux pour chaque département / division de l’organisation, en particulier dans la mesure où leur taille ne sera pas triviale (plus de 50 nœuds!?).
• Envisagez des sous-réseaux pour des groupes de nœuds / utilisateurs à l'aide d'un ensemble d'applications commun, distinct des autres utilisateurs ou types de nœuds (développeurs, périphériques VoIP, atelier de fabrication).
• Envisagez des sous-réseaux pour des groupes d'utilisateurs ayant des exigences de sécurité différentes (sécurisation du service de comptabilité, sécurisation du Wifi)
• Envisagez les sous-réseaux en cas d’épidémie de virus, de violation de la sécurité et de limitation des dommages. Combien de nœuds sont exposés / dépassés - quel est le niveau d'exposition acceptable pour votre organisation? Cette considération suppose des règles de routage restrictives (pare-feu) entre sous-réseaux.

Cela étant dit, l’ajout de sous-réseaux ajoute une charge administrative supplémentaire et peut entraîner des problèmes liés au manque d’adresses de nœud dans un sous-réseau et au fait qu’il en reste trop dans un autre pool, etc. Les configurations de routage et de pare-feu et l’emplacement des serveurs réseau et autres deviennent plus impliqués, ce genre de chose. Certes, chaque sous-réseau doit avoir une raison d'exister qui l'emporte sur les frais généraux liés au maintien de la topologie logique plus sophistiquée.

S'il s'agit d'un seul site, ne vous inquiétez pas à moins que vous n'ayez plus de plusieurs dizaines de systèmes, et même dans ce cas, c'est probablement inutile.

De nos jours, lorsque tout le monde utilise au moins 100 Mbps de commutateurs et le plus souvent 1 Gbps, la seule raison liée aux performances pour segmenter votre réseau est si vous rencontrez un excès de trafic de diffusion (> 2%, ce qui est évident).

L’autre raison principale est la sécurité, c’est-à-dire la zone démilitarisée (DMZ) pour les serveurs publics, un autre sous-réseau pour les finances ou un VLAN / sous-réseau distinct pour les systèmes VoIP.

Limiter la portée de vos exigences de conformité (PCI) est un très bon catalyseur pour segmenter certaines parties de votre réseau. La segmentation de vos systèmes d'acceptation / traitement des paiements et de financement peut vous faire économiser de l'argent. Mais en général, la mise en réseau d’un petit réseau ne vous apportera pas beaucoup de performances.

Une autre raison serait liée à la qualité de service. Nous utilisons des réseaux locaux virtuels voix et données séparément afin de pouvoir appliquer facilement la qualité de service au trafic VoIP.

Vous savez, je réfléchis davantage à cette question. Il existe une foule de bonnes raisons pour concevoir un nouveau réseau utilisant des réseaux distincts (performances, sécurité, qualité de service, limitation de la portée de DHCP, limitation du trafic de diffusion (qui peut être lié à la fois à la sécurité et aux performances)).

Mais en pensant à une métrique pour la reconfiguration en sous-réseau et aux réseaux que je devais gérer par le passé, tout ce à quoi je peux penser, c’est «wow, il faudrait un réseau vraiment foiré pour me redéfinir complètement. c'est pour le sous-réseau ". Il y a de nombreuses autres raisons - bande passante, utilisation de l'unité centrale des périphériques installés, etc.

La sécurité et la qualité principalement (tant que le segment de réseau en question peut prendre en charge les nœuds en question bien sûr). Un réseau distinct pour le trafic des imprimantes, voix / téléphone, des départements isolés tels que les opérations informatiques et bien sûr les segments de serveur, les segments Internet (un par service Internet est populaire, pas seulement "un dmz fera") et ainsi de suite.

Si vous prévoyez de vous développer (vous construisez un réseau, pas seulement 5 serveurs et nous le ferons), nous allons commencer le routage dès que possible. Beaucoup trop de réseaux sont instables et difficiles à développer car ils se sont développés de manière organique et ont beaucoup trop d'éléments de la couche 2.

Exemples:

• vous avez deux serveurs de noms sur le même segment de réseau. Maintenant, vous ne pouvez pas déplacer l'un d'entre eux dans une autre ville, car vous devrez alors scinder ce fichier / 24 ou renuméroter le DNS. Beaucoup plus facile s'ils étaient sur des réseaux différents. Je ne parle pas nécessairement du fait que ces annonces deviennent des annonces distinctes du BGP dans le monde. Cet exemple serait pour un fournisseur de services Internet à l'échelle nationale. Notez également que certaines choses dans la zone des fournisseurs de services ne sont pas aussi simples que "simplement enregistrer le nouveau DNS auprès du registraire".
• Couche 2 boucles sucer le cul. De même que Spanning Tree (et VTP). En cas d'échec de Spanning Tree (et dans de nombreux cas, il le fera disparaître pour cause d'inondation prenant le processeur du commutateur / routeur). Lorsque OSPF ou IS-IS échoue (ou d’autres protocoles de routage), le réseau ne se bloque pas et vous pouvez réparer un segment à la fois. De défaut d'isolement.

En bref: lorsque vous effectuez une montée en puissance à l'endroit où vous pensez avoir besoin de Spanning Tree, envisagez plutôt le routage.

Personnellement, j'aime bien prendre la segmentation de la couche 3 aussi près que possible des commutateurs d'accès, car

• Je n'aime pas Spanning Tree (vous pouvez lui faire faire des choses très marrantes si vous êtes méchant)
• Surtout sur les réseaux Windoze, les émissions constituent un réel problème.
• Sur les réseaux privés, vous avez beaucoup d’espace IP à perdre :)
• Même les commutateurs les moins chers ont déjà des capacités de routage à la vitesse du fil - pourquoi ne pas les utiliser?
• Facilite la vie en matière de sécurité (par exemple, Auth et ACL à l'egde, etc.)
• De meilleures possibilités de QoS pour la VoIP et les choses en temps réel
• Vous pouvez connaître l'emplacement d'un client à partir de son IP

S'agissant de réseaux étendus / étendus où deux commutateurs / routeurs principaux ne sont pas suffisants, les mécanismes de redondance normaux tels que VRRP présentent de nombreux inconvénients (le trafic passe plusieurs fois en liaison montante, ...).

Il y a probablement beaucoup d'autres raisons de soutenir l' approche use-small-broadcast- domain.

Je pense que la portée de l'organisation compte beaucoup. S'il y a 200 hôtes ou moins sur un réseau et que le trafic n'a pas besoin d'être segmenté pour une raison quelconque, pourquoi ajouter la complexité des VLAN et des sous-réseaux? Mais plus la portée est grande, plus cela peut avoir de sens.

La scission de réseaux qui normalement n’auraient pas besoin d’être peut cependant faciliter certaines choses. Par exemple, nos PDU qui alimentent des serveurs se trouvent dans le même VLAN ou le même sous-réseau que les serveurs. Cela signifie que notre système d'analyse des vulnérabilités utilisé sur notre gamme de serveurs analyse également les PDU. Ce n'est pas grave, mais nous n'avons pas besoin d'analyser les PDU. De plus, il serait bien de pouvoir configurer les PDU par DHCP, car ils sont difficiles à configurer, mais comme ils sont dans le même VLAN que les serveurs, cela n’est pas très faisable.

Bien que nous n’ayons pas besoin d’un autre VLAN pour les PDU, cela peut faciliter certaines choses. Et cela entre dans l'argumentation plus vs moins VLAN qui continuera à jamais.

Moi, je pense juste avoir des VLAN où cela a du sens. Si, par exemple, nous donnons à nos PDU leur propre VLAN, cela ne signifie pas que nous devons toujours attribuer leur propre VLAN à de petits groupes de périphériques. Mais dans ce cas, cela peut sembler logique. Si un groupe de périphériques n'a pas besoin de posséder son propre VLAN et qu'il n'y a aucun avantage à le faire, vous pouvez envisager de laisser les choses en l'état.