Antoine Benkemoun

15 avr, 2010

Architecture réseau d’une LAN Party : La latence

Posté par Antoine dans la catégorie Libre|Réseau

Ce billet sera le dernier billet évoquant la préparation de l’Utt Arena. En tant que dernier sujet, j’ai choisi de parler de la mesure de la latence sur une LAN. Avant de commencer, faisons un petit point d’avancement comme à chaque fois.

L’Utt Arena c’est demain. Ca fait toujours un choc de se rendre compte de ca je trouve. Nous avons fait une dernière séance de préparation hier soir afin de régler les derniers aspects de réseau. Nous avons vérifié le fonctionnement des accès Telnet aux équipements afin de pouvoir les administrer le jour J, nous avons validé les configurations des routeurs 2800 et des 3750. Nous avons également testé le fonctionnement de notre sonde de mesure de la latence dont je parlerais plus en détail aujourd’hui. Nous sommes prêts. Nous avons réussi à faire et à tester tout ce que nous souhaitions effectuer avant l’événement. Pour le reste, on donnera le meilleur de nous-même.

Je vais faire le maximum pour essayer de faire au moins un retour d’expérience pendant l’évènement pour ceux que ca pourrait intéresser. Je ne garantis pas que ce sera extraordinaire car la fatigue et la déconcentration devront être de la partie. De toute manière, je ferais un retour d’expérience une fois l’évènement passé et après avoir débriefé avec mon équipe.

La latence est l’intervalle de temps entre l’émission d’un requête et la réception de la réponse. La notion de latence peut s’appliquer à toutes les applications impliquant un ou plusieurs intermédiaires. Il s’agit d’une notion clé lors d’une LAN Party. Les joueurs passent un temps non négligeable les yeux rivés sur l’indicateur de latence.

Les facteurs influant sur la latence sont la congestion réseau, surtout dans le cas d’applications UDP, les temps de calcul des équipements intermédiaires et la qualité du support physique. La congestion réseau est un vrai problème en LAN car des fichiers ont tendance à circuler entre les différents ordinateurs. Nous avons solutionné largement ce problème en appliquant des ACL de filtrage lorsque les tournois ont lieu. La qualité du support phyisque est un problème réduit dans le cas des réseaux câblés mais peut néanmoins intervenir lorsque les câbles sont maltraités.

Le temps de calcul des équipements intermédiaires est une réelle problématique sur laquelle il est relativement difficile d’agir. Dans le cas de commutateur, le temps d’exécution de l’algorithme de commutation est minime mais peut augmenter avec la montée du CPU du commutateur. Dans le cas d’un routeur, les algorithmes sont plus longs. Pour éviter cela, nous avons implémenté un mécanisme de QoS (LLQ).

Habituellement, nous sommes dans le flou concernant les temps de latence. La seule indication que nous avons habituellement est l’affichage du « ping » sur Counter-Strike ce qui fournit une mesure peu représentative de l’état du réseau. Nous avons donc décidé d’implémenter l’outil SmokePing. Cet outil a été conçu afin de mesurer la latence entre un serveur et différents points du réseau. L’installation de cette application est particulièrement simpliste, de même pour la configuration.

La plus-value de Smokeping est l’étude statistique qu’il effectue sur les valeurs de la latence. Les solutions traditionnelles de supervision se contentent d’afficher une unique valeur de latence. Smokeping vous affiche la distribution statistique de vos valeurs afin d’avoir une idée plus claire de la latence mais aussi de la gigue sur votre réseau. Vous trouverez ci-dessous un exemple de graph que j’ai pu trouver sur Internet. Les barres bleues correspondent aux valeurs de perte de paquets. Les valeurs vertes correspondent à la médiane de latence et les valeurs noires la distribution statistique.

Nous allons mesurer la latence entre un serveur placé dans le LAN des Serveurs et une interface IP du 3750 dans le LAN des joueurs. Ce mode de mesure ne prend pas en compte la latence induite par la congestion des uplinks des tables. Hélas, nous n’avions pas la possibilité de faire autrement sans placer des machines sur les tables. Afin d’observer la congestion réseau sur les liens, nous aurons une weathermap Cacti. Nous mesurerons donc le temps de traversée des routeurs et des ASA, ce qui est déjà un bon début.

Au final, la latence est un aspect réellement primordial d’une LAN. Nous avons décidé de mettre en place un système de mesure efficace afin d’avoir de véritables valeurs et de pouvoir différencier les vrais problèmes de l’effet placebo ou d’une imagination débordante. Smokeping est vraiment un outil excellent d’une simplicité exceptionnelle.

10 Commentaires to "Architecture réseau d’une LAN Party : La latence"

1 | Zaxe

avril 15th, 2010 at 22 h 21 min

Avatar

Si après l’UTT, tu peux nous mettre à disposition quekques Smoke Ping ca serait cool.

Pour information, j’ai cité tes artivles sur Actu-Lan.com.

2 | Antoine

avril 15th, 2010 at 22 h 21 min

Avatar

Ouaip j’essayerais d’y penser ! J’ai vu, merci pour le lien =)

3 | Kasi

avril 16th, 2010 at 9 h 25 min

Avatar

Ahhhh quel plaisir de tomber sur le blog d’un étudiant à l’UTT, voila une raison de plus pour le lire :).

Pour ma part je suis en stage de fin d’étude, l’UTT c’est bientôt fini pour moi !

4 | LuKe

avril 16th, 2010 at 9 h 41 min

Avatar

Salut,

J’ai lu tout tes articles sur la mise en place du réseau de l’UTT (ancien joueur de cs donc je connais ta lan :D), et j’ai trouvé ça vraiment intéressant et clairement expliqué.
Je t’avoue que je ne pensais pas que la qualité de service que vous déployez pour les joueurs pouvait être aussi poussée, et jtrouve que c’est une très bonne chose.

ps : du coup tu fais quoi comme études?

5 | Nicolargo

avril 16th, 2010 at 9 h 48 min

Avatar

Je suis justement en train de tester Smoke Ping (et je ferais surement un billet sur le sujet) mais je ne vois pas comment faire pour « monitorer » la gigue réseau comme tu le dis dans ton article. Y a t’il une probe spéciale ?

6 | Antoine

avril 16th, 2010 at 10 h 21 min

Avatar

@Luke, je fais SIT-IR à l’UTT

@Nicolargo, la gigue est affichée sans plugin supplémentaire. Elle est représentée par les traces noires d’opacité variable. Moins il y a des traces noires résiduelles, moins il y a de gigue donc. Plus elles sont concentrées autour de la médiane, moins il y a de gigue.

7 | Zaxe

avril 16th, 2010 at 20 h 50 min

Avatar

Pour le commentaire de LuKe.
Les organisateurs passent énormément de temps pour préparer et configurer le réseau/serveurs d’une LAN. Mais dans le cas de l’UTT, c’est quand même l’artillerie lourde de haute précision.
L’OSPF est utilisé dans plus dans les data center ou de très grosse structure réseau et non pour une LAN.

8 | Rémy

avril 19th, 2010 at 11 h 07 min

Avatar

Bonjour,
Aprés de maintes recherche, de tests, nous utilisons Ops View, basé sur nagios. Cela nous donne beaucoup plus d’indications, car se limiter à quelques paquets ICMP est bien insuffisant pour un monitoring efficace. Nous en avons fait l’expérience en démontrant qu’un routeur était saturé alors qu’il n’y avait aucune perte sur le traffic ICMP. Malgré les mécanismes Qos avec des priorités basses pour le traffic ICMP, le routeur traité les requetes ICMP, mais rejetés beaucoup de traffic TCP et UDP.

9 | Antoine

avril 19th, 2010 at 11 h 18 min

Avatar

Bonjour,

OpsView a l’air vraiment bien ! Si j’avais su, on aurait testé ca également. Merci beaucoup pour l’information.

10 | Pierre

juin 18th, 2010 at 3 h 14 min

Avatar

pour mesurer la latence entre les switches de table et le serveur concerné, je pense qu’utiliser un « ip sla monitor » simple de type icmp echo sur les switches t’aurai donné les valeurs que tu cherchais.

Ajoutez votre commentaire


  • PUNSOLA: Bonjour Il n'est jamais trop tard pour bien faire. Software était utilisé depuis longtemps, quand il a été remplacé par logiciel, qui a bien pri
  • virtualisation: Bonjour, J'ai également virtualisé mes services sous HyperV, avec un serveur virtuel par VM donc par service : et ça représente un avantage consid
  • eric: Article intéressant, cependant lorsqu'on a besoin du NWAM pour avoir une interface reseaux en DHCP et l'autre en Static on ne peux pas utiliser cette

A propos de ce blog

Ce blog a pour objectif de partager des informations avec tous les internautes. Comme indiqué dans le titre, je traiterais de différrents sujets gravitant autour de la sécurité informatique, de la virtualisation, de la l'administration système et du réseau.