Youssef Ghorbal (youssef.ghorbal) writes:
> 
> On s'est pose les memes questions en terme de decoupage reseau : par
> batiment ? par entite ?

        Si on veut regarder vers l'avenir, c'est par bâtiment, je dirais.

        Le concept du domaine de diffusion comme frontière du groupe
        de travail est mort...

> 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)

        Malheureusement, oui - mais ça devient un cauchemard au niveau
        gestion si il faut tenir compte de ça. En théorie, l'appartenance
        dynamique à un VLAN basée sur une authentification 802.1x / EAP/TLS
        va permettre ce genre de découpage, mais bonjour les problèmes
        d'interopérabilité et le débuggage...

> 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.

        Ça ne fonctionne en pratique nulle part (de ce que j'ai pu voir).

> 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)

        Le filtrage au niveau IP est peu fiable, ça fait longtemps qu'on ne
        peut plus se permettre d'associer une IP à un utilisateur. Il faut
        faire confiance à une forte authentification au niveaux des services
        et applications.

> - 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.

        Et (question honnête) - est-ce que vous pensez pouvoir continuer
        avec ce modèle si le réseau grandit 2-3 fois ?

> 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.

        Au revoir le mobile office...

> 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.

        C'est souvent inévitable, mais tenter d'en faire une exception plutôt
        que la règle.


> - 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.

        Cf. interop. ci-dessus.

        Et, ça peut effondrer le coeur (ou vous rendre plus vulnérable à
        $bigvendeur qui va tenter de vous convaincre d'acheter un truc à
        10x le prix et surdimensionné pour pouvoir continuer à évoluer
        avec cette architecture).

> 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)

        Intéressant.


---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à