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

Lorsqu’une architecture est conçue initialement, les concepteurs disposent d’un certain nombre d’éléments motivant un choix technologique par dessus un autre. Dans le cas du cloud computing, ces éléments ne sont pas fixés depuis une durée particulièrement longue et ne sont clairement pas fixés à des échéances au delà du moyen terme. La relative nouveauté du cloud computing devrait démotiver bon nombre de concepteurs d’architecture.

Dans le cas où le choix serait fait de se baser sur une architecture intégrée au sein d’un cloud quelconque, il est nécessaire de se poser très sérieusement la question de l’interopérabilité. Lorsqu’une entité va placer son architecture,  elle confiera d’une part ses données mais aussi le travail humain lié à la conception d’une plateforme. Ce travail humain a un coût relativement important en fonction de l’architecture en question. De sérieux problèmes sont à envisager dans l’éventualité d’une faillite de la société hébergeant le cloud ou même une catastrophe quelconque mettant à mal le cloud. La non-transparence des clouds actuels rend exceptionnellement compliqué l’évaluation de ces risques.

La problématique de l’interopérabilité se pose ainsi. Dans le cas où une entité utilisatrice utilisatrice d’infrastructure cloud souhaite changer d’hébergeur pour une raison X ou Y, en a-t’elle la possibilité ? Il y a bien sur plusieurs niveaux de réponse à cette question. Nous pouvons envisager une situation dans laquelle il lui est juste possible de récupérer les données applicatives ce qui impliquerait de devoir reconstruire la quasi totalité de l’infrastructure applicative. Nous pouvons également envisager une situation où il est possible de récupérer une version « packagée » des machines virtuelles ou, à l’opposé, une situation où rien n’est prévu pour être compatible avec d’autres plateformes.

De plus, ce n’est pas parcqu’il est possible de récupérer une machine virtuelle qu’il sera possible de l’exécuter sur une autre plateforme sans devoir se plonger dans les méandres du système d’exploitation pour peu que celà soit même possible.

Au final, l’interopérabilité est un enjeu majeur de toute plateforme informatique et suscite de nombreux débats habituellement. Les problématiques d’interopérabilité dans le cloud computing ne semblent pas encore avoir passioné grand monde ce qui est dommage car elle est bien réelle et existante. Le logiciel libre a clairement un rôle à jouer dans le cadre de cette standardisation avec les acteurs majeurs de l’industrie associée.

Qu’on apprécie OVH ou non, le nombre de serveurs qu’ils hébergent est réellement impressionant. Selon leurs dires, ils hébergeraient pas moins de 70.000 serveurs aujourd’hui et visent 100.000 d’ici à la fin de l’année. Selon Wikipedia, il s’agirait même du 5ème hébergeur mondial en terme de quantité de serveurs.

Leur succès est lié à leurs prix qui défient toute concurrence sur le marché des serveurs dédiés. Je ne connaissais absolument pas l’histoire d’OVH et ce qui faisait leur succès. La présentation suivante est une présentation faite par deux responsables d’OVH qui retrace l’histoire de leur société. Elle est particulièrement intéressante car elle détaille toutes les « astuces » qu’ils ont utilisé afin de pouvoir grandir au fur et à mesure. Vous y apprendrez par exemple que la quasi totalité des serveurs OVH sont refroidis par un système à eau.

FRnOG 15 – Comment héberger 70000 serveurs ? (part 1)

FRnOG 15 – Comment héberger 70000 serveurs ? (part 2)

Cette présentation est un bel exposé d’audacité et d’ingéniosité comme il en faudrait, surement, plus souvent. Il y a en tout une bonne heure de vidéo. Ceci est extrait d’une conférence FRnOG qui regroupe tous les grands opérateurs Français.

J’ai pu emprunter ce livre deux semaines à la Bibliothèque des Sciences et de l’Industrie située à l’intérieur de la Cité des Sciences. Je me suis tourné vers cette bibliothèque car il s’agissait de la plus proche de mon lieu de travail avant la reprise des cours. J’y ai cependant trouvé un large choix de livre récents traitant de nombreux sujets informatiques. J’avais plutôt été habitué aux livres poussiéreux des bibliothèques classiques. Je vous recommande donc ce lieu si vous passez dans le coin !

« Menaces sur le réseau » est un ouvrage traitant de la sécurité informatique au sens très large. Il a été écrit par un chercheur en sécurité informatique polonais qui explique les différents concepts avec une pédagogie exceptionnelle. Ce livre reprend rapidement les bases théoriques nécessaires à la compréhension des éléments techniques et vous explique différentes techniques d’attaques. Il est donc à lire si vous avez certaines bases en systèmes d’exploitation et en réseaux IP.

Ce livre permet de comprendre plus concrètement le monde de la sécurité informatique. Un exemple est l’explication du fingerprinting de systèmes d’exploitation dont l’auteur semble particulièrement friant. Vous comprendez quelles sont les traces laissées par les systèmes d’exploitation dans tous les paquets IP qu’ils émettent. Un autre exemple est le fingerprinting d’OS en se basant uniquement sur les ID des paquets IP, ce qui est pour le moins créatif mais surtout impressionnant. Grâce à une analyse statique graphique, l’auteur arrive à démontrer la possibilité de cette technique, intimement liée au fait que les ID ne sont pas générés tout à fait aléatoirement.

Au final, ce livre est à lire absolument pour tous ceux qui souhaitent s’intéresser à la sécurité dans le domaine des systèmes d’exploitation et des réseaux et qui ont quelques bases dans ces domaines. Pour ceux qui souhaitent s’intéresser aux aspects « management » de la sécurité, passez votre chemin.

Les dangers liés au cloud computing sont la conséquence directe de la dématérialisation des infrastructures physiques.

Tout d’abord, la première problématique est la localisation des données. L’abstraction des infrastructures physiques rend la localisation de données spécifiques significativement plus compliquée. Cette incertitude induit une sécurité pas forcément amoindrie mais certainement considérablement complexifiée.

Cette première problématique est évidente dans le cas des clouds publics ou privés-publics. Le client des infrastructures de cloud computing accorde une confiance totale aux prestataires en lui livrant toutes ses données. Bien que la plupart des argumentaires commerciaux mettent en avant une sécurité des données et, le plus souvent, un chiffrement, il est impossible de vérifier cela. Le client devient spectateur de la sécurisation de ces données.

Nous pouvons faire une exception à cette problématique dans le cas de clouds privés-publics. Ce cloisonnement reste tout à fait relatif. Ce cloisonnement peut être, dans le cas d’infrastructures « bas de gamme » seulement un mécanisme réseau tel que les VLAN. Ce mécanisme peut difficilement être considéré en tant que mécanisme de cloisonnement de données efficace.

Dans le cas d’infrastructures « haut de gamme », nous pouvons imaginer une architecture de type « cloud computing » exclusive à chaque client. Cette alternative se place dans le haut de gamme par le coût que cela engendre. Ce type d’offre permettrait, au passage, une plus grande flexibilité dans l’architecture à tous les niveaux.

Au final, la sécurité des données est une réelle problématique du cloud computing. Nous nous intéresserons plus tard aux problématiques d’interopérabilité des plateformes.

Dans cet article, je parlerais uniquement de BIND car il s’agit de la référence en terme de serveurs DNS. Je supposerais également que vous utilisez Linux. Et oui, BIND ça fonctionne également sous Windows. Je l’ai même déjà en production sur du Windows… Cela fait un petit pincement au coeur je vous assure.

dig

Le premier outil totalement indispensable est la commande dig. Elle permet d’interroger sélectivement des serveurs DNS. De plus, elle affiche une bonne quantité d’information quant à la requête effectuée. Cette commande sera donc particulièrement utile pour vérifier le bon fonctionnement de votre serveur DNS.

antoine@ks:~$ dig @ns0.infoclip.fr www.infoclip.fr
; <<>> DiG 9.3.4-P1.2 <<>> @ns0.infoclip.fr www.infoclip.fr
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47195
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; QUESTION SECTION:
;www.infoclip.fr.               IN      A
;; ANSWER SECTION:
www.infoclip.fr.        86400   IN      A       217.25.177.18
;; AUTHORITY SECTION:
infoclip.fr.            86400   IN      NS      ns0.infoclip.fr.
infoclip.fr.            86400   IN      NS      ns1.infoclip.fr.
;; ADDITIONAL SECTION:
ns0.infoclip.fr.        86400   IN      A       217.25.176.28
ns0.infoclip.fr.        86400   IN      AAAA    2001:1650:0:1001::2
ns1.infoclip.fr.        86400   IN      A       194.29.206.67
;; Query time: 5 msec
;; SERVER: 217.25.176.28#53(217.25.176.28)
;; WHEN: Fri Feb 12 10:23:54 2010
;; MSG SIZE  rcvd: 145

host

La commande host est un outil particulièrement utile pour créer des scripts utilisant des informations DNS. Elle permet d’afficher très simplement des informations en rapport avec un nom de domaine telles que les serveurs DNS d’autorité, les MX ou le SOA.

antoine@ks:~$ host -t MX lemonde.fr

lemonde.fr mail is handled by 5 smtp0.lemonde.fr.

lemonde.fr mail is handled by 10 smtp1.lemonde.fr.

antoine@ks:~$ host -t ns lemonde.fr

lemonde.fr name server nsc.bookmyname.com.

lemonde.fr name server nsa.bookmyname.com.

lemonde.fr name server nsb.bookmyname.com.

antoine@ks:~$ host -t soa lemonde.fr

lemonde.fr has SOA record nsa.bookmyname.com. hostmaster.bookmyname.com. 1265963399 43200 3600 604800 3600

named-checkconf

L’outil named-checkconf est fourni avec BIND par défaut mais semble relativement peu connu. Cet utilitaire permet de vérifier la syntaxe d’un fichier de configuration. En sachant que BIND est assez peu tolérant des erreurs, cet outil vous évitera quelques mauvaises surprises.

named-checkconf /etc/named.conf

named-checkzone

Une fois que la configuration de BIND est correcte, il est intéressant de vérifier les zones. Je pense que cette vérification doit être périodique car les erreurs passent facilement inaperçue dans les zones. Cet utilitaire va vérifier la syntaxe de vos zones.

named-checkzone domaine.tld /var/named/domaine.tld

Au final, je pense que ces quelques outils devraient vous permettre de pouvoir mieux diagnostiquer d’éventuels soucis de résolutions de noms de domaine.

L’objectif de cet article est de présenter les différentes définitions du cloud computing que l’on peut trouver sur le web et de les comparer. Afin d’avoir un premier élément de définition, nous pouvons nous rendre sur Wikipedia qui définit le cloud computing comme suit.

L’informatique dans les nuages (en anglais, cloud computing) est un concept majeur faisant référence à l’utilisation de la mémoire et des capacités de calcul des ordinateurs et des serveurs répartis dans le monde entier et liés par un réseau, tel Internet (principe de la grille informatique).

Tout d’abord, Wikipedia France traduit cloud computing par le terme informatique dans les nuages. Cette traduction est une traduction très littérale qui, selon moi, s’adapte relativement mal en Français. A défaut d’une meilleure traduction, je continuerais à utiliser le terme anglais beaucoup plus répandu.

Ensuite, intéressons-nous à la définition proposée par Wikipedia. Cette définition ressemble beaucoup plus à un slogan marketing qu’à une véritable définition d’un concept informatique. Elle commence par préciser qu’il s’agit d’un concept majeur. Cette affirmation est soutenue par un rapport Gartner cité en bas de page. Sans questionner le point de vue de ces analystes, cette définition s’attache en premier lieu à définir la taille de ce concept avant même d’avoir précisé de quoi il s’agissait.

De plus, l’utilisation de capacités de calcul et de mémoire d’ordinateurs via Internet est loin d’être quelque chose de récent ni de propre au cloud computing. Une application web est une utilisation de capacité de calcul via Internet et ce n’est pas pour autant qu’il s’agit d’une nouveauté ou bien même de cloud computing. La fin de la définition fait allusion au grid computing qui est une technique bien différente du cloud computing du fait qu’elle soit conçue pour effectuer du calcul distribué.

Nous pouvon ensuite nous tourner vers la définition proposée par Wikipedia en Anglais en espérant obtenir un résultat plus probant.

In concept, it is a paradigm shift whereby details are abstracted from the users who no longer need knowledge of, expertise in, or control over the technology infrastructure « in the cloud » that supports them. Cloud computing describes a new supplement, consumption and delivery model for IT services based on Internet, and it typically involves the provision of dynamically scalable and often virtualized resources as a service over the Internet.

Pour les francophones, voici la traduction « best effort » que je propose de cette définition.

Conceptuellement, il s’agit d’un changement fondamental se traduisant par une abstraction de l’infrastructure technologique désormais transposée « dans les nuages ». Ce changement fondamental implique que les utilisateurs n’aient plus besoin d’une connaissance ou d’une maitrise de l’infrastructure technologique. Le cloud computing est un technique basée sur un nouveau modèle de consommation et d’utilisation des TIC basées sur Internet. Typiquement, cela inclut la mise à disposition de ressources extensible à la volée et, souvent, virtualisées par le biais d’Internet.

Cette définition semble convenir bien mieux à l’idée du cloud computing qui est traitée régulièrement sur Internet. Je trouve que cela décrit beaucoup mieux le concept et la pratique du cloud computing. Nous remarquons également que la page Wikipedia en Anglais sur le cloud computing précise bien que ce n’est pas la même chose que le grid computing. Promis, je ne l’avais pas vu avant.

Au final, la définition du cloud computing est relativement compliquée à poser étant donné la jeunesse de la technique. De plus, le succès de cette technique incite tous les vendeurs de solutions informatiques à se mettre à l’heure du cloud computing moyennant une définition approximative de ce concept. Dans un prochain article, nous essayerons de trouver une définition plus pratique du cloud computing.

A titre de rappel, je vous renvois vers le précédent billet pour le schéma topologique qui vous permettra de comprendre plus facilement les configurations effectuées ici.

Configuration basique

Afin de pouvoir se retrouver plus facilement parmi tous nos équipements, nous allons paramétrer le nom d’hôte de nos différents équipements conformément au schéma.

ROUTER(config)# hostname ROUTEUR1

ROUTER(config)# hostname ROUTEUR2

Nous allons ensuite configurer les différentes interfaces IP de notre routeur de tête précédemment nommé ROUTEUR1.

ROUTEUR1(config)#interface Fa0/0

ROUTEUR1(config-if)#no ip address

ROUTEUR1(config-if)#shutdown

ROUTEUR1(config-if)#interface Fa0/1

ROUTEUR1(config-if)# ip address 192.168.100.1 255.255.255.0

ROUTEUR1(config-if)#exit

Nous allons ensuite configurer les routes statiques vers les réseaux raccordés directement sur notre second routeur. Il serait possible d’utiliser un protocole de routage mais par simplicité, nous avons choisi d’implémenter des routes statiques.

ROUTEUR1(config)# ip classless

ROUTEUR1(config)# ip route 192.168.0.101.0 255.255.255.0 192.168.100.2

ROUTEUR1(config)# ip route 192.168.0.102.0 255.255.255.0 192.168.100.2

ROUTEUR1(config)# ip route 192.168.0.103.0 255.255.255.0 192.168.100.2

La configuration de ce premier routeur se résume à ces commandes simples. Ce routeur est essentiellement un routeur témoin qui nous permettra de valider nos tests.

Configuration des VRF

Nous allons ensuite nous attaquer à la configuration des VRF sur notre second routeur. Pour rappel, les VRF sont des instances de tables de routage. Nous allons créer une VRF par zone de notre schéma. Nous en avons donc distingué 5 : client1, client2, prod et interco. Chaque zone aura donc sa propre VRF ce qui nous permettra d’avoir un cloisonnement finement paramétrable.

Tout d’abord, nous allons donc créer les VRF. Nous attribuerons un « Route Distinguisher » ou RD à chaque VRF. Un RD est un identifiant unique permettant d’identifier les routes associées à une VRF. Nous nous baserons sur ce critère lorsque nous ferons de la propagation de routes entre les différentes VRF.

ROUTEUR2(config)# ip vrf client1

ROUTEUR2(config-vrf)# rd 200:1

ROUTEUR2(config)# ip vrf client2

ROUTEUR2(config-vrf)# rd 300:1

ROUTEUR2(config)# ip vrf prod

ROUTEUR2(config-vrf)# rd 100:1

ROUTEUR2(config)# ip vrf interco

ROUTEUR2(config-vrf)# rd 400:1

Une fois toutes les VRF créées, nous allons configurer les différentes interfaces selon le schéma défini préalablement.

ROUTEUR2(config)# interface Fa0/0

ROUTEUR2(config-if)# description OUTBOUND

ROUTEUR2(config-if)# ip vrf forwarding interco

ROUTEUR2(config-if)# ip address 192.168.100.2 255.255.255.0

ROUTEUR2(config)# interface Fa0/1

ROUTEUR2(config-if)# description PROD

ROUTEUR2(config-if)# ip vrf forwarding prod

ROUTEUR2(config-if)# ip address 192.168.101.1 255.255.255.0

ROUTEUR2(config)# interface Fa1/0

ROUTEUR2(config-if)# description CLIENT1

ROUTEUR2(config-if)# ip vrf forwarding client1

ROUTEUR2(config-if)# ip address 192.168.102.1 255.255.255.0

ROUTEUR2(config)# interface Fa2/0

ROUTEUR2(config-if)# description CLIENT2

ROUTEUR2(config-if)# ip vrf forwarding client2

ROUTEUR2(config-if)# ip address 192.168.103.1 255.255.255.0

ROUTEUR2(config)# ip route 0.0.0.0 0.0.0.0 192.168.100.1

Nous avons donc configuré les différentes interfaces, les différentes VRF ainsi que l’association des VRF aux interfaces. Si nous n’avions pas eu suffisamment de ports physiques, il vous est tout à fait possible de créer des sous-interfaces 802.1Q qui fonctionneront de manière identiques aux interfaces physiques.

Dans le prochain billet, je détaillerais la configuration du protocole de routage afin de redistribuer les routes de manière sélective parmi toutes nos VRF.

Articles de la série

• Premier épisode : Introduction de l’architecture
• Troisième épisode : BGP