Combien de VLAN sont trop peu nombreux et trop nombreux?

Nous utilisons actuellement un réseau de plus de 800 PC et 20+ serveurs, l'infrastructure du réseau est similaire à Core Switch 10 Go-> Area Switch 2 Go-> Local Switch 1 Go-> Desktop. Tous les équipements 3Com fonctionnant (1).

Nous avons 3 commutateurs de zone pour quatre zones (A, B, C, D est fusionné avec le noyau), chaque commutateur de zone aura entre 10 et 20 commutateurs locaux connectés à ceux-ci. Il existe également un commutateur principal de secours, moins alimenté mais connecté comme le commutateur principal principal.

Nous avons également un système de téléphonie IP. Les ordinateurs / serveurs et commutateurs sont sur une plage IP 10.x, les téléphones sur une plage 192.168.x. Les ordinateurs n'ont généralement pas à se parler sauf dans les laboratoires informatiques, mais ils doivent pouvoir parler à la plupart de nos serveurs (AD, DNS, Exchange, stockage de fichiers, etc.)

Lors de notre installation, il a été décidé que nous devions avoir 3 VLAN, un pour les commutateurs et les ordinateurs, un pour les téléphones et un pour la réplication du serveur (ce qui était contraire aux conseils des ingénieurs de 3Com). Le réseau est stable et fonctionne depuis ce point (2), mais nous avons maintenant commencé à passer au SAN et à l'environnement de virtualisation. Il est désormais logique de fractionner cette nouvelle infrastructure en VLAN séparés, et il semble judicieux de réorganiser la configuration de nos VLANS.

Il est maintenant proposé que les VLAN soient installés pièce par pièce, c'est-à-dire qu'un laboratoire informatique avec 5+ PC devrait être son propre VLAN, mais si nous suivons ce modèle, nous chercherons au moins 25 "nouveaux" VLANS , plus les VLANS pour les serveurs SAN / virtuels. Ce qui me semble ajouter une quantité excessive d'administration, bien que je sois très heureux de me tromper.

Quelle serait la meilleure pratique semble suggérer? Existe-t-il un certain nombre de PC qu'il est conseillé de ne pas dépasser / en dessous dans un VLAN.

(1) Les commutateurs 3Com (3870 et 8800) acheminent les VLAN différemment de la façon dont certains le font, il ne nécessite pas de routeur séparé car ils sont de niveau 3.

(2) Nous obtenons parfois des taux de rejet élevés, ou des changements STP, et à certains moments, le directeur du réseau 3Com rapporte que les commutateurs sont sous-chargés et lents à répondre aux pings, ou un commutateur échoué réussissant à détruire le réseau (tous les VLANS de téléphone et d'ordinateur! , une fois, je ne sais pas pourquoi)

Il semble que quelqu'un dans votre organisation veuille créer des VLAN sans comprendre les raisons pour lesquelles vous le feriez et les avantages / inconvénients qui y sont associés. Il semble que vous ayez besoin de faire des mesures et de trouver de vraies raisons pour le faire avant d'aller de l'avant, au moins avec la folie stupide "VLAN pour une pièce".

Vous ne devriez pas commencer à casser un LAN Ethernet en VLAN à moins d'avoir de bonnes raisons de le faire. Les deux meilleures raisons sont:

• Atténuation des problèmes de performances. Les réseaux locaux Ethernet ne peuvent pas évoluer indéfiniment. Des diffusions excessives ou des inondations d'images vers des destinations inconnues limiteront leur échelle. L'une ou l'autre de ces conditions peut être provoquée par un trop grand domaine de diffusion dans un LAN Ethernet. Le trafic de diffusion est facile à comprendre, mais l'inondation d'images vers des destinations inconnues est un peu plus obscure (à tel point qu'aucune des autres affiches ici ne le mentionne!). Si vous obtenez autant de périphériques que vos tables MAC de commutateur débordent, les commutateurs seront forcés d'inonder les trames non diffusées de tous les ports si la destination de la trame ne correspond à aucune entrée de la table MAC. Si vous disposez d'un domaine de diffusion unique suffisamment grand dans un réseau local Ethernet avec un profil de trafic qui héberge des conversations peu fréquentes (c'est-à-dire assez rarement pour que leurs entrées aient vieilli hors des tables MAC sur vos commutateurs), vous pouvez également obtenir une inondation excessive des trames .

• Un désir de limiter / contrôler le trafic se déplaçant entre les hôtes au niveau 3 ou supérieur. Vous pouvez faire du piratage en examinant le trafic au niveau 2 (ala Linux ebtables) mais cela est difficile à gérer (car les règles sont liées aux adresses MAC et la modification des cartes réseau nécessite des changements de règles) peut provoquer ce qui semble être des comportements vraiment très étranges (faire Le proxy transparent de HTTP sur la couche 2, par exemple, est bizarre et amusant, mais est tout à fait naturel et peut être très intuitif à dépanner), et est généralement difficile à faire sur les couches inférieures (car les outils de la couche 2 sont comme des bâtons et des roches pour traiter les problèmes de la couche 3+). Si vous souhaitez contrôler le trafic IP (ou TCP, ou UDP, etc.) entre les hôtes, plutôt que d'attaquer le problème au niveau de la couche 2, vous devez mettre en sous-réseau et coller des pare-feu / routeurs avec des ACL entre les sous-réseaux.

Les problèmes d'épuisement de la bande passante (à moins qu'ils ne soient causés par des paquets de diffusion ou une inondation de trames) ne sont généralement pas résolus avec les VLAN. Ils se produisent en raison d'un manque de connectivité physique (trop peu de cartes réseau sur un serveur, trop peu de ports dans un groupe d'agrégation, la nécessité de passer à une vitesse de port plus rapide) et ne peuvent pas être résolus en sous-réseau ou en déployant des VLAN depuis cela a gagné 't augmenter la quantité de bande passante disponible.

Si vous n'avez même pas quelque chose de simple comme MRTG exécutant des statistiques de trafic par port sur vos commutateurs, c'est vraiment votre premier ordre du jour avant de commencer potentiellement à introduire des goulots d'étranglement avec une segmentation VLAN bien intentionnée mais non informée. Le nombre d'octets bruts est un bon début, mais vous devez le suivre avec un reniflement ciblé pour obtenir plus de détails sur les profils de trafic.

Une fois que vous savez comment le trafic se déplace sur votre réseau local, vous pouvez commencer à penser à segmenter le réseau local pour des raisons de performances.

Si vous voulez vraiment essayer de boutonner l'accès au niveau des paquets et des flux entre les VLAN, préparez-vous à faire beaucoup de travail avec les logiciels d'application et à apprendre / inverser la façon dont il parle sur le fil. La limitation de l'accès des hôtes aux serveurs peut souvent être accomplie avec une fonctionnalité de filtrage sur les serveurs. Limiter l'accès sur le câble peut fournir un faux sentiment de sécurité et calmer les administrateurs dans une complaisance où ils pensent "Eh bien, je n'ai pas besoin de configurer l'application. En toute sécurité car les hôtes qui peuvent parler à l'application. Sont limités par" le réseau'." Je vous encourage à vérifier la sécurité de la configuration de votre serveur avant de commencer à limiter la communication d'hôte à hôte sur le câble.

En règle générale, vous créez des VLAN dans Ethernet et mappez les sous-réseaux IP 1 à 1 sur eux. Vous allez avoir besoin de BEAUCOUP de sous-réseaux IP pour ce que vous décrivez, et potentiellement de nombreuses entrées de table de routage. Mieux planifier ces sous-réseaux avec VLSM pour résumer vos entrées de table de routage, hein?

(Oui, oui - il existe des moyens de ne pas utiliser un sous-réseau séparé pour chaque VLAN, mais en restant dans un monde strictement "simple", vous créeriez un VLAN, imaginez un sous-réseau IP à utiliser dans le VLAN, affectez un routeur une adresse IP dans ce VLAN, attachez ce routeur au VLAN, soit avec une interface physique ou une sous-interface virtuelle sur le routeur, connectez certains hôtes au VLAN et attribuez-leur des adresses IP dans le sous-réseau que vous avez défini, et acheminez leur trafic vers et hors du VLAN.)

Les VLAN ne sont vraiment utiles que pour restreindre le trafic de diffusion. Si quelque chose va faire beaucoup de diffusion, alors séparez-le en son propre VLAN, sinon je ne me dérangerais pas. Vous voudrez peut-être avoir une duplication virtualisée d'un système en direct sur le même réseau et souhaitez utiliser la même plage d'adresses, puis encore une fois, cela pourrait valoir un VLAN distinct.

Les VLAN sont un bon niveau de sécurité supplémentaire. Je ne sais pas comment 3Com le gère, mais vous pouvez généralement segmenter différents groupes fonctionnels en différents VLAN (par exemple, comptabilité, WLAN, etc.). Vous pouvez ensuite contrôler qui a accès à un VLAN particulier.

Je ne pense pas qu'il y ait de perte de performances significative s'il y a plusieurs ordinateurs dans le même VLAN. Je ne trouve pas pratique de segmenter le LAN dans une pièce par pièce, mais encore une fois, je ne sais pas comment 3Com le gère. Habituellement, la directive n'est pas la taille, mais plutôt la sécurité ou le fonctionnement.

En fait, je ne vois aucune raison de segmenter même le LAN en différents VLAN s'il n'y a pas de sécurité ou de gains opérationnels.

À moins que vous ayez 25 groupes de test et de développement qui tuent régulièrement le réseau avec des inondations de diffusion, 25 VLAN par chambre sont 24 de trop.

De toute évidence, votre SAN a besoin de son propre VLAN et non du même VLAN que le LAN et l'accès Internet des systèmes virtuels! Tout cela peut être fait via un seul port Ethernet sur le système hôte, donc ne vous inquiétez pas de diviser ces fonctions.

Si vous avez des crap-outs de performances, envisagez de placer votre téléphone et votre SAN sur du matériel réseau séparé, pas seulement sur des VLAN.

Il y aura toujours du trafic de diffusion, qu'il s'agisse de diffusions à résolution de noms, de diffusions ARP, etc. L'important est de surveiller la quantité de trafic diffusé. S'il dépasse 3 à 5% du trafic total, c'est un problème.

Les VLAN sont bons pour réduire la taille des domaines de diffusion (comme l'a déclaré David) ou pour la sécurité, ou pour créer des réseaux de sauvegarde dédiés. Ce ne sont pas vraiment des domaines de "gestion". De plus, vous ajouterez de la complexité de routage et des frais généraux à votre réseau en implémentant des VLAN.

En règle générale, vous ne souhaitez envisager d'utiliser des VLAN que lorsque vous devez mettre en quarantaine des appareils (comme une zone où les utilisateurs peuvent apporter leurs propres ordinateurs portables, ou lorsque vous disposez d'une infrastructure de serveur critique qui doit être protégée) ou si votre domaine de diffusion est trop haut.

Les domaines de diffusion peuvent généralement compter environ 1000 appareils avant que vous ne commenciez à voir des problèmes sur les réseaux à 100 Mbits, bien que je réduise cela à 250 appareils si vous avez affaire à des zones Windows relativement bruyantes.

Pour la plupart, les réseaux modernes n'ont pas besoin de VLAN, sauf si vous effectuez cette mise en quarantaine (avec un pare-feu approprié à l'aide des ACL, bien sûr) ou une limitation de diffusion.

Ils sont également utiles pour empêcher les diffusions DHCP d'atteindre les périphériques réseau indésirables.