Définition

Les réseaux de distribution de contenu sont des réseaux qui ne ressemblent pas aux réseaux traditionnels. Traditionnellement, un réseau est présent dans un endroit ou dans plusieurs. Pour les réseaux d’entreprise, ils sont présents sur le siège social, les diverses succursales et éventuellement un centre de données. Dans le cas des réseaux d’opérateur, ils couvrent un pays ou bien plusieurs avec plusieurs points d’interconnexions dans le monde.

Les réseaux de distribution de contenu sont éclatés à travers le monde. Leur objectif est d’être présent dans le plus d’endroits possibles afin de fournir du contenu au plus proche de l’utilisateur. Nous avons donc à faire à des réseaux multi-localisés.

Positionnement stratégique

L’intérêt même des réseaux de distribution de contenu est leur présence dans les endroits « stratégiques » de l’Internet. Leur objectif est de réduire les coûts de distribution de contenu en se rapprochant de l’utilisateur final. Il leur est donc très intéressant de se rapprocher des noeuds d’interconnexion de l’Internet mais également des fournisseurs d’accès à Internet.

Leur présence dans les locaux des fournisseurs d’accès permet une très forte réduction des coûts de bande passante. Du point de vue du fournisseur d’accès à Internet, il ne crée pas de trafic supplémentaire avec le reste du monde. C’est précisément ce type de trafic réseau vers le reste du monde qui est couteux. Le FAI ont donc tout intérêt à intégrer des CDN dans son réseau. Au lieu d’envoyer n-fois un contenu sur un lien interocéanique, il suffira de l’envoyer une fois et il sera ensuite redistribué à partir du réseau du FAI.

La proximité géographique n’est pas forcément synonyme de proximité au niveau de l’Internet. Les nœuds de l’Internet ne répondent aux mêmes logiques de proximité que les réseaux routiers. Les grands nœuds d’interconnexion européens sont Londres et Amsterdam. Il sera donc parfois plus rapide voire nécessaire de router un flux via ces villes pour accéder un pays voisin ce qui est contraire à la simple proximité géographique.

Données statiques

Les réseaux de distribution de contenu distribuent essentiellement des données statiques. Par données statiques, j’entends des données qui ne varient pas dans le temps. La vidéo peut donc être considéré comme un contenu statique dans le cas de vidéos Youtube par exemple. Les CDN ne disposent normalement pas de ressources de calcul de scripts type PHP, ASP ou autre.

L’exception à cette affirmation est le contenu vidéo diffusé en direct. Les CDN peuvent être utilisés pour diffuser ce type de contenu. Mais il reste invariant du point de vue des utilisateurs. Chaque utilisateur reçoit le même contenu avec un décalage minimal.

Au final, nous avons réussi à faire un tour rapide de la définition des réseaux de distribution de contenu. Il serait possible de s’étendre longuement sur ce sujet mais ce n’est pas le but ici. Nous verrons par la suite les techniques d’accès au contenu et de répartition de charge.

Avant de rentrer dans le vif du sujet, la présentation que nous avons effectué est disponible sur Slideshare. L’affichage des animations est quelque peu fastidieux par le biais de la visionneuse Slideshare mais ca reste assez lisible. Il s’agit d’une présentation Keynote contenant assez peu de détails car la plupart du sujet a été traité à l’oral. Pour le détail, il faudra lire les articles de cette série de billets.

Tout d’abord, nous pouvons traduire le terme « Content Delivery Network » par « Réseau de distribution de contenu ». L’adaptation de ce terme en Français me semble tout à fait satisfaisante. J’utiliserais ce terme pour la suite des billets et les autres billets à venir. Je ferais une exception pour le titre mais ça c’est pour l’indexation Google.

Les réseaux de distribution de contenu ont été conçus pour répondre à des problématiques très concrètes rencontrées sur Internet. Lors de cette introduction, nous nous attacherons à identifier ces problématiques et à les détailler. Nous distinguerons deux types de problématiques : les nouvelles problématiques et les problématiques historiques.

Nouvelles problématiques

L’utilisation de l’Internet a beaucoup évolué depuis ces dix dernières années et ces évolutions ont amené de nombreuses nouvelles problématiques.

La première grande révolution est l’introduction de la vidéo dans le navigateur web. Ceci peut paraitre tout à fait « normal » aujourd’hui mais l’intégration de contenus vidéos était quelque chose de rare il y a une dizaine d’années. Le lecteur Real Player avait permis de faire les premiers pas vers cette intégration mais son utilisation était exceptionnellement pénible. Ceux qui l’ont utilisé se souviendront probablement du casse tête entre les version gratuites et payantes ainsi que les publicités associées. Cette révolution a permis au plus grand monde d’accéder à des quantités de contenu astronomiques.

La seconde révolution est le haut débit par le biais des technologies de transmission ADSL et câble. Chaque utilisateur connecté derrière la box de son fournisseur d’accès à Internet obtient ainsi la possibilité de récupérer des données à une vitesse particulièrement élevée. Aujourd’hui, la quasi totalité des accès ADSL/Câble classiques disposent de plusieurs Mégabits de débit.

La troisième révolution a été les réseaux sociaux. Dans l’absolu, les réseaux sociaux ne sont que des sites comme des autres. Leur particularité réside dans le fait que la quantité de contenu qui y est ajouté chaque heure est colossale. De plus, ces contenus sont consultés de manière régulière par de nombreuses personnes à longueur de journée.

Pour résumer, le contenu distribué sur Internet a largement grossi à cause de la vidéo mais les utilisateurs ont également la possibilité de le récupérer à des vitesses élevés. Au final, il était nécessaire de trouver un solution efficace et le moins cher possible car tous ses contenus sont accessibles gratuitement.

Problématiques historiques

Nous venons de voir un certains nombre de facteurs récents qui ont modifié l’utilisation de l’Internet. Nous allons maintenant nous intéresser aux problématiques qui ne sont elles pas récentes.

La première problématique est le coût de la mise en place des liaisons transocéaniques et transcontinentales. L’investissement initial est élevé et la maintenance sur ces câbles est exceptionnellement compliquée. Les procédés de fabrication des fibres ont été améliorés et leur utilisation a été optimisé mais il reste nécessaire de faire traverser l’océan par un navire câblier ou bien de creuser les trous pour enfouir les fibres. Cette problématique induit le fait que plus le trafic réseau parcourt de la distance, plus les couts sont élevés.

La seconde problématique est la vitesse de la lumière. Transcrit en des termes plus informatiques, la seconde problématique est la latence. Cette dernière est bornée inéluctablement par la vitesse de propagation d’un signal dans une fibre optique qui dépend de la vitesse de la lumière. Les utilisateurs veulent non seulement du contenu mais le veulent rapidement. La latence peut devenir un problème dans le cas de liaisons transocéaniques. Des chiffres donnés par Akamai évoquent une latence de 1,6 ms pour du contenu situé à 160 Km et une latence de 96 ms pour du contenu situé sur un autre continent.

Au final, ces deux jeux de problématiques s’additionnent et viennent compliquer la vision traditionnelle de la distribution de contenu sur Internet. Les réseaux de distribution de contenu ont été créé dans l’objectif de résoudre au mieux à toutes ces problématiques.

La méthode la plus simple consiste à utiliser les outils easy-rsa en ligne de commande. Ces outils simplifient réellement la tâche par rapport à l’utilisation directe d’OpenSSL. Le problème avec l’utilisation de ces outils est la nécessité d’interagir avec le terminal. Cet outil va vous demander bon nombre de renseignements tels que le pays, la ville, l’adresse email, etc. Cette interaction rend compliquée la création par lots de certificats.

Une méthode plus compliquée, mais plus efficace, consiste à adapter les scripts easy-rsa afin de rendre leur utilisation plus linéaire et non interactive afin qu’un script puisse les exécuter. De plus, j’ai souhaité donner la possibilité de spécifier la durée de validité du certificat au cas par cas, ce qui n’est pas possible par défaut.

Le premier script, build-key-batch, permet de créer une clé en spécifiant une durée de validité. Il n’y a qu’une toute petite modification qui permet de récupérer la durée de validité passée en argument.

#!/bin/sh

if test $# -ne 2; then
     echo « usage: build-key-batch <name> <duree> »;
     exit 1
fi

if test $KEY_DIR; then
     cd $KEY_DIR && \
     openssl req -days $2 -nodes -new -keyout $1.key -out $1.csr -batch -config $KEY_CONFIG && \
     openssl ca -days $2 -out $1.crt -in $1.csr -batch -config $KEY_CONFIG && \
     chmod 0600 $1.key
else
     echo you must define KEY_DIR
fi

Par défaut, easy-rsa nécessite d’exécuter le fichier vars dont le rôle est d’exporter un certain nombre de variables d’environnement utilisées par les scripts de génération de clé. Cela ne me convenait pas car je souhaitais exécuter un seul fichier contenant toutes les informations dont je pouvais avoir besoin. J’ai donc créé un script nommé build-batch qui contient toutes les options.

#!/bin/sh
if test $# -ne 2; then
     echo « usage: batch-build <name> <duree> »;
     exit 1
else
     # Definition des variables
     export D=`pwd`
     export KEY_CONFIG=$D/openssl.cnf
     export KEY_DIR=$D/keys
     export KEY_SIZE=1024
     export KEY_COUNTRY=FR
     export KEY_PROVINCE=XX
     export KEY_CITY=Paris
     export KEY_ORG= »Keeyyyy »
     export KEY_EMAIL= »$1″
     export KEY_CNAME=$1
     ./build-key-batch $1 $2
fi

Ce script nécessite une petite modification du fichier openssl.cnf présent dans le dossier easy-rsa qui est la suivante :

commonName = Common Name (eg, your name or your server\’s hostname)
commonName_max = 64
++ commonName_default = $ENV::KEY_CNAME

Le script a exécuter afin de générer un certificat est donc build-batch suivi de deux arguments qui sont le nom du certificat et la durée de validité. Vous pourrez ainsi générer des certificats pour OpenVPN simplement et efficacement sans nécessiter une intervention humaine.

Source : insights

Je ne referais pas de bilan spécifique car ce dernier a déjà été fait dans un billet précédent. Je n’ai pas d’élément à ajouter à ce que j’ai déjà dit précédemment. Malgré quelques problématiques humaines, je suis satisfait du réseau que nous avons mis en place lors de cette édition de l’Utt Arena.

Pour commencer cette conclusion, voici un récapitulatif de tous les billets de cette série :

• Architecture réseau d’une LAN Party : Introduction
• Architecture réseau d’une LAN Party : Conception
• Architecture réseau d’une LAN Party : Filtrage
• Architecture réseau d’une LAN Party : Configuration des ASA
• Architecture réseau d’une LAN Party : DHCP
• Architecture réseau d’une LAN Party : La latence
• Architecture réseau d’une LAN Party : Premier bilan

Ensuite, je vous ai fait un paquet avec toutes les configurations des équipements. Il s’agit des configurations que nous avons sauvegardé à la fin de l’événement, elle n’inclut donc pas la configuration avant la transition vers les ASA. Pour rappel, les 3750 s’appellaient Kilimandjaro et StHelens et les ASA s’appellaient Etna, Kilauea, Fuji et Pinatubo.

Nous avons mis en place une weathermap lors de l’événement dont voici une capture. A ce moment, les joueurs tentaient de récupérer le GUI CS:Source. La bande passante du serveur étant limitée à 100Mbit/s, la montée en couleur a été réduite. Si vous souhaitez visionner la carte en taille réelle, il suffit de cliquer dessus.

Les résultats de Smokeping ont été également très satisfaisants. La capture d’écran ci-dessous montre un graph de la latence entre le serveur Smokeping et une interface IP d’une 3750 dans le LAN des joueurs. Les données avant le « trou » correspondent aux mesures faites avant la transition vers les ASA. On remarque un pic de latence suite à la transition. Cela correspond à la récupération du GUI par les joueurs et n’a donc pas impacté les tournois.

Pour ceux que cela pourrait intéresser, j’ai fait un paquet contenant de nombreux graphs que j’ai pu sauvegarder le dernier jour de la LAN avant de tout déconnecter. Il y a de nombreux graphs incluant notamment les uplinks vers les tables et les interfaces des ASA.

Au final, la gestion du réseau de cet événement fut un réel plaisir et m’a permis d’acquérir de nouvelles compétences notamment au niveau de l’utilisation des Cisco ASA et 3750 mais aussi des outils Cacti et Smokeping. Ici s’achève donc la plus longue série de billets de ce blog jusqu’à présent.

Phase 1

Tout d’abord, nous n’avions pas la possibilité d’avoir les équipements réseau type Cisco ASA et 2800 avant le Samedi midi car ils n’arrivaient pas avant ce moment là. Nous avons donc du faire avec une solution secondaire par le biais des 3750. Cela était parfaitement prévu depuis quelques semaines mais je n’avais pas souhaité en parler afin d’éviter l’effet placebo lors de la transition vers le réseau définitif.

La mise en place des deux 3750 s’est faite sans aucun soucis particulier. Le premier 3750 nommé Kilimandjaro disposait d’une interface IP dans tous les VLAN et effectuer le routage entre ces derniers. Le second 3750 nommé StHelens avait pour seule fonctionnalité la commutation des paquets associées à ses interfaces. Nous avions également prévu ce second 3750 afin d’avoir une solution de secours en cas de panne du premier 3750.

Transition

Lorsque les ASA sont arrivés, nous avons dû effectuer la transition du réseau initial vers le réseau prévu. Les joueurs n’ont pas été mis au courant de ce changement afin d’éviter un effet placebo qui correspondrait à voir des pannes partout sans réelle raison. Les organisateurs ont cependant été mis au courant ce qui a provoqué une avalanche de remontées de problèmes divers et, en grande partie, sans aucun rapport avec transition. La gestion des remontées de ces problèmes a été plutôt mauvaise car tous les organisateurs remontaient vers l’équipe réseau tous les problèmes, incluant ceux n’ayant aucun rapport de près ou de loin avec le réseau.

Nous avons racké les ASA dans la baie prévue à cet effet. J’évoquerais l’architecture physique ultérieurement. Nous avons ensuite injecté les configurations en port série et nous avons validé que nous avions bien un accès Telnet à ses équipements afin d’éviter de mauvaises surprises. Nous avons ensuite connecté tous les ports de Management et d’interconnexion des ASA afin qu’ils prennent connaissance de la topologie IP. Nous avons ensuite basculé les interfaces IP du 3750 vers les ASA une par une. Nous avons tout de même laissé une interface par VLAN sur les 3750 pour la fonctionnalité DHCP. Pour les routeurs, nous avons appliqué une méthodologie similaire.

Lors de la transition, nous avions donc une partie des VLAN routés par le 3750 et une partie des VLAN routés par les ASA/2800. Cette configuration temporaire a impliqué un routage asymétrique. Autant les routeurs sont peu sensibles aux asymétries de routage, les ASA ne le sont pas car ils effectuent un suivi de la session TCP. Nous avons réussir à contenir en bonne partie l’asymétrie du routage en jouant avec les identifiants de routeur OSPF ou du moins on pense que ce fut le cas. De toute manière, la transition a duré une petite heure.

Une fois la topologie reconstituée, nous avons coupé l’OSPF sur le 3750 afin qu’il soit exclu du processus de routage et nous avons laissé les ASA et les 2800 faire leur travail. Une coupure d’une trentaine de secondes est induite par la réélection OSPF et le recalcul des routes.

Phase 2

Une fois toute l’architecture en place, nous avons pu commencé à débugger nos configurations. Nous avons essentiellement eu des soucis de configuration de VLAN sur les switchs que nous avons mis un peu de temps à corriger. Les remontées de problèmes pertinentes ont mis un peu de temps à nous parvenir réellement car elles étaient noyées dans un volume assez important de demandes.

Nous n’avons pas rencontré de problème particulier lié à notre architecture réseau suite aux reconfigurations initiales. Les joueurs Warcraft III ont rencontré de nombreux problèmes de connexion aux parties alors qu’ils étaient tous dans le même VLAN voire sur le même switch. Nous n’avons pas réussi à déterminer l’origine de ce problème épisodique. La piste d’un applicatif malicieux est privilégiée car de multiples changements de switch et un passage en IP fixe n’ont apporté aucune solution à ce problème. La latence est tout à fait correcte selon nos mesures bien que nous rencontrons quelques problèmes du coté des serveurs CSS qui se montrent quelque peu capricieux. Nous avons mis le LLQ pour le principe mais la différence de latence ne parait pas significative.

Au final, la préparation nous a permis d’effectuer une transition propre et plutôt efficace. La vraie difficulté a été la qualification et la pertinence des problèmes remontés aux administrateurs réseaux. Je referais un point une fois l’évènement passé.

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.

Comme d’habitude, faisons un point d’avancement avant de rentrer dans la discussion technique. Le jour J est ce Vendredi soir donc nous nous retrouvons rapidement au pied du mur. Nous sommes cependant prêts à mettre en place l’architecture que nous avons prévu. La dernière de séance de préparation a été assez confortante car nous avons réussi à mettre en place l’architecture rapidement et effectuer les différents ajouts rapidement. Nous avons du apporter des modifications significatives à l’architecture dont je parlerais dans un prochain billet.

J’en avais déjà parlé lors du billet sur la conception de ce réseau, nous avons prévu de mettre en place un certain nombre de VLAN. Traditionnellement, un seul serveur DHCP était nécessaire afin d’allouer des adresses IP à toute la LAN. Or dans le cas présent, nous sommes loin de cette configuration.

Une première solution, assez primitive, aurait consisté à placer un serveur DHCP dans chaque VLAN. Cette solution est, bien évidemment, pas envisageable de par sa complexité de gestion et de sa consommation en machines. Il aura été possible de comprimer cette solution en utilisant des machines virtuelles mais nous n’avons pas de machine suffisamment puissante afin de faire celà.

La seconde solution, la plus évidente, est d’utiliser les ASA afin d’attribuer les bails DHCP. Cette idée est particulièrement efficace car elle permet de regrouper la configuration en un seul point. Les ASA sont parfaitement capables d’assurer la fonctionnalité DHCP pour plusieurs LAN. Ils peuvent allouer des IP inclues dans une plage sur chaque interface. Ce qui est cependant franchement ridicule, ils ne sont capables d’attribuer qu’une seule passerelle par défaut pour tous les LAN. Concrètement, vous pouvez allouer IP et Passerelle pour un LAN mais que des IP pour tous les autres LAN. Nous ne pouvons donc pas utiliser les ASA afin de servir d’allouer des bails DHCP décemment.

La solution finale est d’utiliser des Cisco 3750 afin d’attribuer des bails DHCP. Les 3750 sont des switchs avec une grosse dose d’intelligence supplémentaire. Ils sont capables, en plus de commuter, de router, de gérer un (ou plusieurs) protocoles de routage et d’allouer des bails DHCP pour plusieurs LAN. Cette solution implique que les 3750 aient une interface IP valide dans chaque LAN.

La configuration DHCP des 3750 est particulièrement simple à effectuer. Il faut d’abord créer l’interface IP associée au VLAN. Dans cet exemple, nous créons une interface IP associée au VLAN n°50 qui aura pour IP 10.5.0.5

interface Vlan50
description Admin
ip address 10.5.0.5 255.255.255.0

Il faut ensuite indiquer au switch la plage d’IP qu’il peut allouer sur cette interface ainsi que la passerelle par défaut.

ip dhcp pool 50
network 10.5.0.0 255.255.255.0
default-router 10.5.0.1

Nous pouvons ensuite exclure une plage d’IP qui servira pour adresser divers équipements réseau : ASA et 3750 dans notre cas.

ip dhcp excluded-address 10.5.0.1 10.5.0.10

Au final, la configuration DHCP des Catalyst 3750 est relativement simple. Afin d’adresser de nombreux VLAN, il suffit de répéter le processus précédent. Ensuite, il suffit de placer les joueurs dans le bon VLAN et ils obtiendront les informations de configuration réseau.

Avant de commencer, il est nécessaire de balayer toutes les éventuelles rumeurs quant à une éventuelle disparition d’OpenSolaris suite au rachat par Oracle. De nombreux médias dits « spécialisés » ont publié des informations très largement fausses par rapport aux conséquences du rachat ou ont très largement oublié certains faits. Si vous souhaitez un article relativement neutre sur le sujet, je vous conseille le blog c0t0d0s0.org.

Le projet Crossbow est un sous-projet lié à la distribution OpenSolaris qui a été intégré à la version 2009.06. L’objectif de ce projet était d’adapter la pile TCP/IP à la virtualisation et d’y ajouter de nombreuses fonctionnalités. Je m’intéresserais plus particulièrement aux outils de gestion de bande passante.

La gestion de bande passante ou QoS est une fonctionnalité bien ancrée dans les équipements réseaux. L’objectif de cette technique est de réguler les flux réseau afin de permettre un partage équitable ou bien une limite définie. La mise en place de cette fonctionnalité est particulièrement compliquée et obscure sous Linux. La documentation, particulièrement nécessaire étant donnée la complexité des outils, est difficile à trouver.

OpenSolaris propose un première utilitaire permettant de différencier les différents flux réseaux selon des critères de niveau 3 et 4 : flowadm. Vous allez pouvoir créer un « flow » selon différents critères que vous choisirez. Vous allez ensuite pouvoir attribuer différentes caractéristiques à ce flux. Par exemple, vous pouvez lui donner un ou bien une priorité, voire même une limite de bande passante. L’incroyable avantage de cet outil est la simplicité avec laquelle il est possible de l’utiliser. En une commande, vous arrivez à créer un flux, lui donner une priorité et lui appliquer une limite de bande passante. En voici un exemple :

flowadm add-flow -l bge0 -a transport=UDP -p maxbw=100M, priority=low limit-udp-1

La page de man de flowadm est particulièrement claire et propose de nombreux exemples dont celui ci-dessus. Une seule commande pour faire tout ca, je trouve ca plutôt exceptionnel. La limite minimale de bande passante que vous pouvez attribuer est fonction du MTU. Dans le cas d’un MTU Ethernet classique, il s’agit de 1,2Mbps.

Une autre fonctionnalité très intéressante est la possibilité d’effectuer de « l’accounting » sur les différents flows que vous avez créé. Vous pourriez par exemple avoir envie de connaitre la quantité de données échangées pour chaque flux. OpenSolaris vous propose ceci ainsi que la possibilité de voir la quantité de données échanges par intervalle de temps. Pour cela, vous pourrez utiliser l’utilitaire acctadm. Cet utilitaire vous permet d’activer l’accounting au niveau de votre système et la commande flowadm vous permettra d’en visualiser le résultat.

Ce billet effectue un tour d’horizon rapide de ce que peut proposer le projet Crossbow en termes de gestion de bande passante réseau. OpenSolaris a clairement une grande avance sur Linux sur ce point bien que ce dernier en soit capable, mais clairement pas avec autant de simplicité.

Avant de rentrer dans le vif du sujet, arrêtons-nous pour faire un petit point d’avancement. Nous commençons à avoir des configurations de base relativement solides qui nous permettent de déployer la topologie IP du réseau à chaque session de travail. Le montage de cette topologie ne pose désormais plus de problème particulier. Nous avons réussi à résoudre le problème de la communication entre deux interfaces d’un même ASA. La résolution de ce problème nous a permis de simplifier grandement nos configurations en supprimant toutes les identités NAT des interfaces à security-level 100, soit toutes nos interfaces internes. Je suis content de notre avancement et nous devrions aboutir sur une préparation satisfaisante.

Les ASA sont la gamme d’équipements de sécurité Cisco orientés vers l’entreprise. J’emplois le terme d’équipement de sécurité et non de pare-feu car cette terminologie est bien plus proche de la réalité. Les fonctionnalités d’un ASA dépassent très largement celles de filtrage protocolaire IP, TCP et UDP. Je vous laisse consulter la liste de fonctionnalités sur le site de Cisco. Nous avons également une carte SSM-AIP pour chaque ASA permettant de faire de l’IPS ce que nous utiliserons pendant l’événement si nous nous ennuyons (sait-on jamais).

Nous avons 4 équipements Cisco ASA 5510 à notre disposition. La version logicielle associée est la version « Base » contrairement à son équivalent haut de gamme, « Security Plus ». La différence entre ces deux versions est réellement énorme. La version « Security Plus » permet de transformer deux interfaces 10/100 en interfaces Gigabit, de débloquer l’interface 3 et d’utiliser le port de « Management » en tant qu’interface de données.

La configuration des ASA est légèrement différente de celle de routeurs Cisco classiques. Cette différence est liée au fait que les ASA ne sont pas basés sur un IOS mais un « Security Appliance OS ». Il y a de nombreuses similarités mais suffisamment de différences pour devoir se documenter spécifiquement.

Je ne vais pas pouvoir détailler toute la configuration des Cisco ASA dans ce billet car il ferait de très nombreuses pages. Je vais cependant relever les points clés qui nous ont posé problème.

Tout d’abord, les ASA sont faits pour faire du NAT entre toutes les interfaces par défaut. Ceci vient de leur héritage historique vis-à-vis des PIX. Ce comportement induit la nécessité d’effectuer de très nombreuses règles de NAT. Il est, heureusement, possible de désactiver ce comportement grâce à la commande « no nat-control « . Une fois le nat-control désactivé, il sera possible de router en direct entre les interfaces tant qu’on effectue une descente dans les security-level. Il sera nécessaire de faire une petite règle de NAT afin de remonter les security-level. Il est cependant tout à fait possible d’effectuer une règle de NAT qui ne modifie aucunement les adresses IP ni les ports afin que l’ASA se comporte comme un routeur.

Ensuite, les ASA considèrent par défaut que du trafic entre deux interfaces de même security-level effectue une montée de security-level. Ce comportement implique la création de nouvelles règles de NAT. Afin d’éviter ce comportement et de minimiser les lignes de configuration, il est possible d’utiliser la commande « same-security-traffic permit inter-interface « . Ainsi, vous simplifiez votre configuration ce qui est très intéressant.

Je mets à votre disposition la configuration de l’ASA nommé Fuji afin que vous puissiez y jeter un regard plus approfondi que mes explications assez superficielles. Il manque les ACL de filtrage en mode tournoi car nous ne les avons pas encore intégrées ainsi que le paramétrage avancé de l’OSPF.

Avant de commencer à traiter ce sujet, je vais faire un petit point d’avancement sur la préparation du réseau. Nous avons passé 2 soirées à configurer les équipements Cisco et nous avons réussi à créer la topologie IP évoqué au billet précédent en 2 heures. Ce résultat est relativement satisfaisant et a été rendu possible par la préparation des configurations à l’avance. La quantité de VLAN ne nous a pas posé de problème particulier car la configuration des équipements Cisco est claire à ce niveau. Il nous reste juste une petite problématique au niveau de la communication entre deux interfaces du même ASA.

Le filtrage IP est une composante nécessaire de notre configuration réseau car les ASA refusent par défaut le trafic réseau. Dans le cadre d’une LAN, nous pouvons dissocier deux périodes : les périodes de tournoi et les périodes sans tournoi. Nous avons décidé d’adapter la configuration réseau en fonction de chaque période.

Le filtrage IP hors tournoi sera le plus permissif possible. Il n’y a aucun intérêt à restreindre les flux émanant des tables. Nous imposerons éventuellement une limite de bande passante au niveau des flux sortant sur Internet afin d’éviter la saturation trop rapide du lien. Ce niveau de filtrage nous permettra de tester notre configuration réseau sans se soucier des ACL.

Le filtrage IP pendant les tournois sera, au contraire, le plus restrictif possible. L’objectif est de limiter les flux au minimum nécessaire pour les jeux. La présence de flux parasites serait susceptibles d’impacter négativement la latence des flux de jeux causant ainsi le mécontentement des joueurs.

Au final, le filtrage IP s’adaptera en fonction des conditions de la LAN. Ceci se concrétisera par deux jeux d’ACL que nous appliquerons aux interfaces en fonction du filtrage souhaité.