Architecture réseau d’une LAN Party : Conception
Ce billet fait suite au précédent qui avait eu pour objectif de définir le contexte d’un réseau d’une LAN et de présenter le projet. Aujourd’hui, nous allons définir l’architecture IP et L2 de notre LAN.
Avant de commencer, je souhaite faire un petit point d’avancement. La préparation de l’Utt Arena a commencé quelque peu en retard au niveau du réseau pour diverses raisons. Les choses avancent donc très vite et je vais essayer de vous faire partager notre avancement sur ce blog du mieux possible. J’approfondirais plus ou moins les sujets en fonction du temps que j’ai à ma disposition.
Je pense que l’architecture d’un réseau se doit d’être la plus simple possible et la plus logique possible. Si un réseau est simplement compréhensible par un humain, il sera plus facile à gérer et les sources d’erreur seront réduites. La conception de l’architecture est une phase exceptionnellement critique sur laquelle repose tout le reste.
L’objectif de notre réseau est le contrôle des flux et la l’optimisation de la latence. Ces deux objectifs sont quelque peu contradictoires car le contrôle des flux implique l’ajout d’intermédiaires de filtrage et de routage. Nous avons essayé de concilier au mieux ces deux objectifs.
Nous avons créé un VLAN par switch de table ce qui correspond à 20 joueurs pour les tournois CS et CSS. Ces deux tournois sont, de loin, les plus problématiques en terme d’utilisation réseau. Ceci nous fait donc 8 VLAN pour CS et 4 VLAN pour CSS. Pour les tournois TrackMania et Warcraft III, nous avons choisi de faire un VLAN par tournoi. Les joueurs Warcraft III jouent entre eux sans passer par un serveur, il est donc plus simple de les placer dans un VLAN dédié.
Tous les VLAN contenant les joueurs seront routés par un ASA. Nous avons ensuite réparti les VLAN équitablement parmi les ASA.
Ensuite, nous devons interconnecter les ASA entre eux. Nous avons choisi le protocole de routage OSPF car il s’agit d’un protocole simple et efficace. La logique traditionnelle voudrait que nous insérions un routeur central afin de router les flux des 4 ASA. Etant donné que notre objectif est la latence, nous avons choisi de ne pas mettre ce routeur. Les ASA seront donc tous interconnectés par le même réseau IP. OSPF est parfaitement capable de gérer cette configuration en passant par l’élection d’un DR (Designated Router).
Nous avons ensuite ajouté deux routeurs standards afin de router les flux des serveurs et des administrateurs. Ces routeurs participeront également à l’OSPF avec les ASA.
Et pour finir la tache la plus importante, le nommage des équipements. Inutile mais tellement indispensable et amusant. Nous avons choisi des noms de volcans pour les ASA et des noms de montagne pour les routeurs. Les ASA s’appelleront ainsi Etna, Fuji, Kilauea et Pinatubo et les routeurs Everest et K2.
Cliquez sur l’image pour l’agrandir.
Au final, nous obtenons un schéma relativement effrayant. Ce dernier nous a permis de nous rendre compte de la taille du réseau que nous avons projeté de mettre en place. La difficulté est, honnêtement, un facteur très motivant. Cette réflexion a été faite avec toute l’équipe réseau et avec le retour de personnes extérieures ce qui a permis de dynamiser la réflexion.
Dans les prochains épisodes : la spécificité de la configuration des ASA et un rebondissement inattendu ! Quel suspens !