La ou je travaille actuellement on a traite exactement la meme problematique. Plusieurs entites (services/departements,) plusieurs batiments, des stacks par batiment et un coeur qui relient tous ces batiments. Avec la subtilite qu'une entite peut etre eclatee sur un ou plusieurs batiments.
On s'est pose les memes questions en terme de decoupage reseau : par batiment ? par entite ? - Decoupage par batiment : comme ca a deja ete aborde, on peut faire du L3 par batiment, pas la peine de se prende la tete avec des LANs etendus, on a l'avantage de toute la flexibilite des protocoles de routages etc. Par contre, il faut accepter (et faire accepter) que les protocoles en broadcast ne vont pas fonctionner (entre batiment j'entend). Exemple, dans l'entite machin, ils ont un petit NAS ou un serveur de licence ou une Time Capsule, etc etc. Ce truc va tres bien marche pour les membres de l'entite qui sont dans le meme batiment mais pas pour les autres, ca peut creer de la confusion (et de l'incomprehension des utilisateurs) Il faut aussi prendre en compte que ds ce scenario si tu envisage de faire qq filtrage par IP (genre authoriser le service bidule a acceder au site machin, ou interdire le service truc a acceder au serveur toto) la il faut avoir un sous reseau par entite par baitment. Si tu as 3 entites et 4 batiments ca passe, mais si tu as 250 entites et 50 batiments la gymnastique devient complexe. Autre piste, tu met tous les postes du batiment A ds le meme VLAN (et tu passes sur un filtrage par utilisateur, groupes, ce qui est un autre debat) - Decoupage par entite/service : ca necessite un LAN etendu sur tous le "campus", tous les vlans sont sur toutes les stacks. Les protocoles de broadcasts fonctionnent, mais tu a tous les incovenhients du LAN (etendu). Ca fonctionne chez nous avec des plus de 300 vlans et plus de 50 batiments. Le plus important ici, est que tu dois gerer un protocle d'attribution de VLAN dynamique pour que les postes atterissent dans le bon VLAN quand ils accedent au reseau (802.1x ou du MAC based vlan etc) ceci necessiste de connaitre les adresses MAC de tous les postes, gerer une base radius avec etc etc (PacketFence & consors). Pareil, si tu gere que des postes fixes, tu peux faire les confs sur les switchs en statiques et a la mimine, mais des que tu as une grande volatilite (des postes et des entites) ca devient ingerable. Qq remarques : - L'experience montre que tot ou tard tu vas tomber sur un use case ou ton decoupage par batiment ne fera pas l'affaire et que tois le "porcifier" pour avoir un LAN etendu entre batiment. C'est rare mais ca peut arriver. Je peux donner par exemple les reseaux d'alarmes temperature par exemple ou les gens qui ont imagine le soft ne se sont pas pose la question et partent du principe que toutes les sondes doivent etre ds le meme reseau (un exemple parmi d'autres) - 802.1x necessite une tres grande maitrise des postes. Sur le papier c'est "supporte" par les OS du marche mais quand on rentre ds les details, c'est l'enfer. Pareil, tot ou tard, tu vas tomber sur ZE equipement qui ne sais pas faire et tu vas devoir enforcer le port en statique sur le switch (ou tu vas te rendre compte que les 250 imprimantes recemment achete ne font pas de 802.1x :) ) L'alternative est de se contenter de l'adresse MAC et des fonctionnlite des swicths de type "MAC Authentication Bypass sur Cisco, ou Netlogin sur Extreme etc) - Le fait de devoir creer les VLANs sur tous les switchs peut etre alleger par les fonctionnalites que peuvent proposer les swicths. Par exemple, il y'a des switchs qui proposent d'auto creer le VLAN (et lui coller les uplinks) quand un poste est authorise sur le reseau (le Radius envoie cette infos) mais ca creer une adherence par rapport au constructeur ce qui n'est pas toujours souhaitable si tu as un mix de constructeur sur ton reseau. Pour le moment, nous somme dans le scenario 2 (decoupage par entite) on a un LAN etendu et de l'attribution dynamique de VLAN base sur adresse MAC (et de l'auto creation de VLAN parce que le constructeur sais faire) On ne fais pas de 802.1x parce qu'on ne maitrise pas la totalite du parc. On utilise des outils maison pour gere cette base d'adresse MAC ce qui n'est pas tres confortable. Les outils du marche de type IPAM ne gerent malheureusement pas ce use case (aucun ne supporte du L2, les VLANs, Radius etc) Bon courage ! Youssef Ghorbal 2016-06-12 12:44 GMT+02:00 Bruno LEAL DE SOUSA <[email protected]>: > Merci beaucoup pour ces réponses. > > Oui effectivement on est plus dans un mode office-mobile où les gens > bougent assez souvent et les services déménagent souvent de bureaux.. > En gros si je veux pas avoir trop de soucis et faire un découpage par > service, il faudrait que je mette en place du 802.1x et que je propage mes > vlans bureautiques sur toutes les piles.. Ce qui m'embête un peu.. > C'est pas top quand même de devoir propager tous ces vlan's sur toutes les > piles... > > D'où la question que je me posais.. Est-ce qu'un découpage par bâtiment ne > serait pas plus pertinent ? > > Merci. > A+ > > -- > Bruno LEAL DE SOUSA > IT System and Network Administrator > Co-founder and editor of Bidouille-IT :http://bidouilleit.com > > « Failure is the foundation of success, and the means by which it is > achieved. » - Lao Tzu > Le 12 juin 2016 12:23, "Phil Regnauld" <[email protected]> a écrit : > >> David Ponzone (david.ponzone) writes: >> > Oui, la question dans le cas présent, c’est combien de services y a-t-il >> et à quel point sont-ils éparpillés sur le campus ? >> > Donc en clair, si généralement un service est dans un bâtiment, sauf >> quelques exceptions, et qu’il y a15-20 services, je pense que ça reste >> maitrisé, et il y a peu de chance que ça change radicalement. >> > Si par contre, c’est plutôt 50 services tous présents dans les 30 >> bâtiments, avec une politique mobile-office (pas mal de gens qui se >> baladent un peu partout sur le campus, ou qui changent de bâtiments sans >> changer de service), alors là, c’est peut-être un peu plu délicat. >> >> Oui, on est bien d'accord. La solution du mobile office c'est >> justement >> (à mon avis) de traiter tout le monde pareil et ne pas espérer >> avoir >> une politique trop dynamique - ça casse souvent, et vouloir mettre >> des ACLs interservice dans ce contexte: AIE!) >> >> Voir PacketFence, par exemple, pour ce genre de chose, mais c'est >> pas exactement léger :) >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
