Les technologies du Cloud Computing

Antoine 5 commentaires

Les vacances sont finies et les affaires reprennent avec plus d’open source et de cloud computing. Lors d’un précédent article, nous avons essayé de trouver une définition à peu près convenable du cloud computing de manière générale. Ceci s’est avéré relativement complexe et hasardeux. J’ai finalement choisi de conserver la définition proposée par Wikipedia en Anglais.

A défaut de réussir à définir conceptuellement le cloud computing, nous allons essayer de le définir technologiquement. Cet exercice devrait être largement plus simple que le précédent car les ressources abondent sur ce plan. Comme vous vous en doutez déjà, il existe de nombreux types d’infrastructures physiques et applicatives placées sous la dénomination de cloud computing. Nous essayerons de faire une sélection des technologies réccurentes.

La virtualisation

Lorsqu’est évoqué la notion de cloud computing, la notion de virtualisation n’est pas bien loin. La montée en popularité du cloud computing coïncide largement avec la monte en popularité des plate-formes de virtualisation. Bien qu’il existe de nombreux types de virtualisation, la virtualisation de systèmes d’exploitation est la plus fréquente, de loin. Nous pouvons affirmer de manière relativement sûre que la base essentielle du cloud computing est la virtualisation de systèmes d’exploitation.

La virtualisation de système d’exploitation n’est cependant pas un phénomène récent. Les premières applications de VMWare datent de 1998. L’amélioration des processeurs x86 n’est certainement pas étranger à ce phénomène avec la multiplication et la densification des coeurs de calcul. La montée du cloud computing est sans aucun doute liée avec la montée en puissance des applications d’automatisation des plate-formes de virtualisation. Cette automatisation permet une flexibilité exceptionnelle et une réactivité dans l’évolution du cloud.

La place de l’open source

Alors que l’on pourrait croire que l’acteur le plus populaire dans ce domaine est VMWare, la réalité ne confirme pas cette intuition. L’open source joue un rôle essentiel dans le domaine du cloud computing à travers l’hyperviseur Xen. Le cloud publique d’Amazon est basé sur le projet Xen tout comme l’offre de serveur virtuel privé de Gandi. Cette adoption massive peut probablement s’expliquer par la nature open source de l’hyperviseur ayant permis le développement des outils d’automatisation mais aussi par la faible perte de performance. Bien que le projet KVM ait été intégré dans le noyau Linux et choisi par différentes distributions, ceci signifie en aucun cas la fin du projet Xen.

Dans le cas du déploiement de grands clouds publiques, l’utilisation des plate-formes de virtualisation propriétaires telles que VMWare ou Hyper-V ne semblent pas viables financièrement. Les licences VMWare sont exceptionnellement coûteuses, de même pour les licences Windows 2008 Server. Un grand cloud public basé sur ces technologies rendrait l’offre particulièrement peu compétitive. De plus, l’hébergeur dépendrait totalement de l’éditeur pour les fonctionnalités qu’il peut implémenter et n’aura que peu de marge pour innover. L’utilisation des outils propriétaires peut être viable financièrement dans le cadre de clouds privés de taille modeste bien que la gratuité de XenServer de Citrix ne facilite pas l’adoption.

La mise en réseau du stockage

Tandis que les deux premières technologies sont visibles par les utilisateurs des clouds, le troisième l’est nettement moins. Traditionnellement, les unités de stockage de masse sont connectées directement sur les serveurs. Concrètement, cela se traduit par la connexion des disques dur directement sur le bus ATA ou SCSI de chaque serveur. Cette forme de stockage a comme avantage d’être particulièrement simple mais a comme désavantage d’être très peu flexible.

La mise en réseau des éléments de stockage à travers le SAN (Storage Area Network) a permis de s’affranchir de nombreuses contraintes. Cette flexibilité exceptionnelle a permis aux clouds de pouvoir s’automatiser rapidement avec notament l’utilisation des techniques de snapshots ou de déduplication. De plus, le réseau de stockage a permis d’augmenter massivement les performances des IO permettant de pouvoir centraliser les données. Cette centralisation a rendu possible les techniques de migration automatique à chaud et de répartition de charge dynamique entre différents hyerviseurs.

Au final, les technologies du cloud computing sont plus simples à cibler que le concept global. J’aurais l’occasion d’évoquer et de traiter les réseaux de stockage en détail ultérieurement. Ces trois technologies sont des technologies « centrales » autour desquelles peuvent en orbiter de nombreuses autres.

Installation d’OpenVPN sur OpenSolaris

Antoine

Cela fait un bon bout de temps que je n’ai pas eu l’occasion de vous parler d’OpenSolaris. Le dernier article remonte même à mi-Novembre ! Je n’ai pas abandonné ni laissé tomber OpenSolaris, loin de là. La machine virtuelle hébergeant ce blog a été migrée sur OpenSolaris comme j’avais eu l’occasion de l’expliquer dans un article précédent. Je vais donc profiter de ces quelques jours de vacances rallongées (hélas) pour vous parler de l’installation d’OpenVPN sur OpenSolaris.

Pour rappel, OpenVPN est une application qui permet de créer des tunnels VPN chiffrés afin d’y faire passser du trafic IP. Cette application est relativement simple à utiliser une fois qu’on a réussi à comprendre rapidement son fonctionnement. Je vous en avais déjà parlé à travers l’article sur Viscosity, client VPN pour MacOS. Si vous êtes intéressés par un tutoriel d’installation sous Linux, je vous renverrais vers l’excellent tutoriel écrit par Smurf.

Pré-requis

Afin de pouvoir installer OpenVPN sur OpenSolaris, il va vous falloir une installation fonctionnelle d’OpenSolaris. Logique, non ? Nous allons ensuite travailler avec les packages fournis par Blastwave. Il s’agit d’un dépot de paquets spécifiques de manière similaire au dépots Sun. L’avantage de Blastwave est que les paquets sont plus nombreux et plus récents. Le nom des paquets Blastwave commencent par CSW au lieu de SUNW pour les paquets Sun. Afin de pouvoir installer facilement des paquets Blastwave, il est nécessaire de récupérer et installer l’utilitaire d’installation pkgutil (sorte d’équivalent à apt-get).

# wget ftp://ftp.belnet.be/packages/blastwave.org/pkgutil_1.6.1_i386.pkg

# pkgadd -d pkgutil_1.6.1_i386.pkg

Une fois cette utilitaire installé, nous allons pouvoir installer le reste beaucoup plus simplement.

Installation

Tout d’abord, nous allons devoir récupérer et installer les modules tun et tap nécessaires pour le fonctionnement d’OpenVPN. Une fois que ces modules seront installés, nous allons pouvoir nous occuper d’OpenVPN. De manière similaire à apt-get, la récupération des binaires et leur installation est automatique.

# /opt/csw/bin/pkgutil -i tun tap
# /opt/csw/bin/pkgutil -i openvpn

L’installation de tous ces paquets se fait toute seule. Il sera juste peut être nécessaire de confirmer l’installation en tapant un simple « y ».

Génération des certificats

Une fois l’installation initiale des paquets terminée, nous allons nous attaquer à la génération des certificats. Nous allons tout d’abord créer le certificat racine de notre serveur OpenVPN. Le certificat racine est le certificat d’origine qui servira à signer tous les certifications délégués aux utilisateurs de notre concentrateur VPN.

# cd /etc/csw/openvpn/easy-rsa
# source vars
NOTE: when you run ./clean-all, I will be doing a rm -rf on /etc/csw/openvpn/easy-rsa/keys
# ./clean-all
# ./build-ca
Generating a 1024 bit RSA private key
.++++++
………..++++++
writing new private key to ‘ca.key’

Un certain nombre de questions vous seront ensuite posées. Les réponses à ces questions permettront de pouvoir identifier plus clairement votre certificat racine. Rassurez-vous, il n’y a donc pas de mauvaise réponse. Une fois que vous aurez fini, vous remarquerez que deux nouveaux fichiers ont été créés : ca.crt et ca.key. Le fichier ca.key est à garder précieusement car c’est ce dernier qui permet de signer et de créer de nouveaux certificats donnant accès à votre concentrateur VPN. Nous allons ensuite créer le jeu de clés du serveur OpenVPN.

# ./build-key-server server
Generating a 1024 bit RSA private key
………………………………………………++++++
………………..++++++
writing new private key to ‘server.key’

Une fois le certificat du serveur créé, vous retrouverez les fichiers server.key et server.crt. Nous allons ensuite pouvoir créer les certificats de nos utilisateurs. Des informations vous seront également demandées sur l’utilisateur pour la création de certificat. Ces informations permettent d’identifier vos utilisateurs, vous avez donc tout intérêt à les remplir précisément.

# ./build-key antoine
# ./build-key jeanmarc

Afin d’achever la génération des certificats, nous allons devoir créer le paramètre de Diffie-Hellman. La génération peut prendre du temps surtout sur un processeur peu occupé.

/etc/csw/openvpn/easy-rsa# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time

Configuration d’OpenVPN

Tout d’abord, nous allons devoir rendre accessible au service les différents certificats dont il va avoir besoin.

# cd /etc/csw/openvpn
# /etc/csw/openvpn# cp openvpn.conf.CSW openvpn.conf
# /etc/csw/openvpn# ln -s easy-rsa/keys/dh1024.pem
# /etc/csw/openvpn# ln -s easy-rsa/keys/server.crt
# /etc/csw/openvpn# ln -s easy-rsa/keys/server.key
# /etc/csw/openvpn# ln -s easy-rsa/keys/ca.crt

Il est nécessaire ensuite de renseigner les différentes informations dans le fichier de configuration d’OpenVPN. Je ne parlerais pas de ce fichier en détail ici car d’autres sites le font déjà et bien mieux que moi. Les lignes importantes sont les suivantes. L’utilisation de TCP pour un VPN est sous-optimal mais permet de contourner une bonne partie des firewalls associé avec le port 443 (HTTPS).

port 443
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 172.19.0.0 255.255.255.0

Ensuite, vous allez pouvoir tester votre paramétrage en exécutant le service OpenVPN.

# ifconfig tun0 unplumb
# /opt/csw/sbin/openvpn /etc/csw/openvpn/openvpn.conf

L’affichage des logs sera fera directement sur votre écran ce qui vous permettra de diagnostiquer d’éventuelles erreurs de configurations ou de connexion. Et ensuite, pour lancer définitivement le démon :

# ifconfig tun0 unplumb && /etc/init.d/openvpn start

Au final, ce petit tutoriel vous permettra de créer un tunnel OpenVPN afin de pouvoir communiquer avec votre serveur de manière sécurisée. Je ferais un autre billet expliquant les manipulations supplémentaires pour passer toute sa connexion Internet dans ce même VPN. Ce tutoriel est largement inspiré d’un autre tutoriel en anglais.

Définition du « Cloud Computing »

Antoine 15 commentaires

Je profite de cette journée de vacances pour prendre le temps de blogger sur un sujet d’actualité mais surtout particulièrement à la mode. Certains préfèreront le terme « trendy » mais je trouve que ca fait peut être un peu beaucoup pour une technique informatique. J’aurais l’occasion de revenir sur le sujet du cloud computing plus d’une fois. Je ne ferais cependant pas une série d’articles liés mais différents aspects à visée plus ou moins objective.

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.

Les domaines Xen : les domaines non privilégiés

Antoine 4 commentaires

Aller hop on se motive ! Pour mon avant-dernier jour de stage chez Orange Business Services, je vais faire la suite du précédent article sur les domaines Xen. J’avais eu l’occasion de détailler les spécificités du domaine privilégié, plus communément connu sous le nom de dom0.

Si vous n’êtes pas familier avec le vocabulaire spécifique à Xen, je vous renvois vers l’article traitant de la terminologie Xen. Si vous ne connaissez pas bien le projet Xen, je vous renvois vers la présentation de ce projet.

Domaine non privilégié : domU

Les domaines non privilégiés sont communément appelés « domU » (U comme unprivileged). Les domU sont l’équivalent des systèmes d’exploitation invités sur les plateformes de virtualisation classiques. Concrètement, ce sont les machines virtuelles qui s’exécuteront sur votre plateforme Xen. Ces systèmes d’exploitation s’installent une fois que vous avez un hyperviseur et un dom0 fonctionnel. Il existe de nombreux outils vous permettant d’installer des domU de manière plus ou moins simple et rapide.

Comme vous le savez surement, Xen est capable de faire de la paravirtualisation mais aussi de la virtualisation matérielle assistée. A chacun de ces types de virtualisation correspond un type de domaine non privilégié. Les domU de paravirtualisation sont appelés « domU standards » et les domU de virtualisation matérielle assistée sont appelés « domU HVM ». L’acronyme HVM signifie « Hardware-Assisted Virtual Machine ».

domU de paravirtualisation : domU standard

Nous allons tout d’abord nous intéresser aux domU dits « standards ». Les domU de paravirtualisation sont considérés standards car il s’agit des premiers domU qui ont été disponibles pour Xen et les seuls jusqu’à la version 3.0. Ceci s’explique par le fait que la paravirtualisation est la raison d’être du projet Xen et ce qui en a fait un projet inédit.

Du fait qu’il s’agisse de domU de paravirtualisation, il est nécessaire que l’OS de chaque domU standard ait été adapté pour l’hyperviseur Xen. Ceci se fait par le biais d’API spécifiques supportant les hypercalls. De très nombreux systèmes d’exploitation peuvent être placés en tant que domU par dessus Xen. Tous les Linux sont compatibles ainsi que certains BSD et OpenSolaris.

domU de virtualisation matérielle assistée : domU HVM

Lorsqu’un système d’exploitation n’a pas été adapté pour Xen, il est nécessaire de recourir à une technique de virtualisation plus classique. Il s’agit bien évidemment de la virtualisation matérielle assistée. Ce type de domU permet à Xen de supporter la quasi totalité des systèmes d’exploitation existants pour l’architecture x86.

Le module utilisé par Xen pour effectuer les opérations de virtualisation matérielle assistée est le module QEMU. La contre partie des domU HVM est une perte de performances plus importante que dans le cas d’un domU standard. Ceci s’explique par le fait qu’il est nécessaire d’effectuer beaucoup plus d’opérations d’émulation.

Rôle des domU et délégation de périphériques

Les domU n’ont pas de rôle spécifique au niveau de la plateforme de virtualisation. Ils servent juste à exécuter les diverses applications qui sont contenues dans leurs systèmes d’exploitation. Il ne leur est accordé, par défaut, aucun privilège au niveau des ressources physiques. L’hyperviseur leur attribue une partie des ressources dynamiquement et les domU les utilisent ou pas en fonction de leurs besoins.

De plus, il est tout de même possible d’accorder quelques priviléges spécifiques aux domU. Ces privilèges spécifiques se matérialisent par la délégation de périphériques. Par exemple, il est possible de donner accès exclusif à un port USB ou PCI à un domU. Ceci va lui permettre de pouvoir utiliser un composant physique comme il le souhaite. Il y a eu des exemples de cartes graphiques déléguées à un domU permettant de jouer à un jeu 3D dans le domU. Notons tout de même que la délégation de périphérique à un domU restreint totalement sa mobilité entre plusieurs hyperviseurs ce qui peut être handicapant.

Au final, cette article présente les spécificités des domU. J’espère avoir été clair et compréhensible. Si ce n’est pas le cas, vous avez toujours la possibilité de laisser un commentaire pour me le signaler. En ce qui concerne la suite des événements, je suis encore indécis sur les sujets que je vais traiter. Cela devrait varier en fonction de mon prochain emploi. De toute manière, je souhaiterais parler plus des réseaux de stockage et du stockage en général.

Quelques favoris qui pourraient être utiles

Antoine

L’activité sur ce blog se fait discrète en ce moment, je vous l’accorde. Pour la fin du mois de Décembre et le début du mois de Janvier, j’avais l’excuse des fêtes de fin d’année. Nous en sommes désormais relativement loin. J’avoues que la motivation se fait plus rare en ce moment mais elle devrait revenir.

A travers ce rapide article, je souhaiterais partager avec vous une sélection de pages web que j’ai eu l’occasion de rencontrer. Ceci vous permettra peut être de découvrir de nouveaux sites ou bien d’en redécouvrir d’anciens. Certains de ces liens sont peut être un peu datés mais ils devraient toujours être utiles.

Configurer Ubuntu en tant que routeur Wifi (lien) : Un petit tutoriel qui vous expliquera comment configurer une Ubuntu en tant que routeur wifi. Ca peut paraitre simple mais ca ne l’est pas forcément.

Installation d’un « pack » de détection d’intrusion (lien) : Tutoriel vous expliquant l’installation de Snort, OSSEC, Prelude sur une Ubuntu. Fonctionne sur Debian également.

Interview du Lt. Col. John Bircher sur la cybersécurité (lien) : Interview d’un officier chargé de la cybersécurité dans l’armée américaine.

Tableau de bord de la sécurité réseau (lien) : Excellent livre traitant de nombreux aspects de la sécurité informatique.

Configuration de Xen dans le cas de domaines HVM (lien) : Article extrait de la documentation SuSe explicitant la configuration et l’utilisation d’un domaine HVM sous Xen. Tout à fait applicable à n’importe quelle installation Xen.

Croix Rouge Française de Paris 9ème (lien) : Site de la délégation locale Croix Rouge où je suis bénévole.

Configuration des quotas sous Debian (lien)

Optimisation de performances Postfix (lien) : Page de la documentation détaillant l’optimisation des performances d’un serveur Postfix.

Installation de grsec sur un noyau Linux (lien)

La gestion des services sous Solaris (lien) : Article de documentation détaillant le fonctionnement du SMF de Solaris 10 de la gestion à la création de services.

Installation de Wireshark sur MacOS X (lien) : Documentation indispensable pour pouvoir installer Wireshark sur MacOS.

Cloisonnement d’un réseau à l’aide de VRF : BGP

Antoine 5 commentaires

Tout d’abord, je souhaite vous souhaiter de bonnes fêtes car c’est la période de l’année habituelle pour le faire. J’espère également que le père Noël aura été généreux en jouets et gadgets électroniques de tous genres. Je vais profiter de cette journée calme au travail afin de vous écrire le dernier épisode de cette série d’article.

Rappel des épisodes précédents

Dans le premier épisode, je vous ai présenté l’architecture réseau qui avait été mise en place ainsi que les équipements. Nous avons également vu l’objectif que nous cherchions à atteindre. Pour rappel, l’objectif était de faire du cloisonnement de réseaux tout en gardant la possibilité de partager des routes entre ces réseaux. C’est pour cela que nous avions choisi d’utiliser les VRF.

Dans le second épisode, nous avons fait la création des VRF ainsi que la configuration IP des interfaces associées.

Protocole de routage : BGP

A la suite de ces deux épisodes précédents, nous avons une configuration IP basique. Afin d’atteindre l’objectif que nous nous étions fixé, il va être nécessaire de partager les routes entre les différentes VRF. Il ne suffira pas de partager toutes les routes à tout le monde car dans ce cas-là les VRF n’aura pas grand intérêt. Nous allons propager les routes de manière sélective.

Le protocole de routage permettant de propager les routes de manière très sélective parmi des VRF est le BGP. Ce protocole de routage ne sert pas uniquement à cela, loin de là. Le BGP est entre autre le protocole de routage utilisé par tous les routeurs de bordure d’Internet afin de propager la totalité des routes de l’Internet. Nous en utiliserons qu’une petite fonctionnalité dans le cas présent.

Afin de pouvoir propager les routes de manière sélective, il va être nécessaire de se baser sur un critère de sélection. Vous vous rappelez surement des « Route Distinguisher » ou RD. Les RD sont une sorte d’étiquettes appliquée aux routes d’une VRF spécifique. Nous allons donc pouvoir choisir les routes que nous propagerons et celles que nous propagerons pas.

Le schéma suivant récapitule les échanges de routes que nous allons effectuer.

Configuration des VRF

Nous allons donc configurer les VRF avec les import / export que nous avons défini dans le schéma ci-dessus. La configuration des VRF est assez explicite. Je ne pense pas qu’il soit possible de détailler plus que cela.

ROUTEUR2(config)# ip vrf client1

ROUTEUR2(config-vrf)# route-target export 200:1

ROUTEUR2(config-vrf)# route-target import 100:1

ROUTEUR2(config-vrf)# route-target import 400:1

ROUTEUR2(config)# ip vrf client2

ROUTEUR2(config-vrf)# route-target export 300:1

ROUTEUR2(config-vrf)# route-target import 100:1

ROUTEUR2(config-vrf)# route-target import 400:1

ROUTEUR2(config)# ip vrf prod

ROUTEUR2(config-vrf)# route-target export 100:1

ROUTEUR2(config-vrf)# route-target import 200:1

ROUTEUR2(config-vrf)# route-target import 300:1

ROUTEUR2(config-vrf)# route-target import 400:1

ROUTEUR2(config)# ip vrf interco

ROUTEUR2(config-vrf)# route-target export 400:1

ROUTEUR2(config-vrf)# route-target import 100:1

ROUTEUR2(config-vrf)# route-target import 200:1

ROUTEUR2(config-vrf)# route-target import 300:1

Configuration du BGP

Nous allons maintenant configurer le BGP afin de faire la distribution de route que nous souhaitons. Dans le cadre de la configuration de BGP, il sera nécessaire de définir une « address-family » par VRF. Une « address-family » est un groupe de configuration qui va permettre d’appliquer des directives spécifiques à un groupe de routes.

ROUTEUR2(config)# router bgp 1

ROUTEUR2(config-router)# no auto-summary

ROUTEUR2(config-router)# address-family ipv4 vrf prod

ROUTEUR2(config-router-af)# redistribute connected

ROUTEUR2(config-router-af)# synchronization

ROUTEUR2(config-router)# address-family ipv4 vrf interco

ROUTEUR2(config-router-af)# redistribute connected

ROUTEUR2(config-router-af)# redistribute static

ROUTEUR2(config-router-af)# synchronization

ROUTEUR2(config-router)# address-family ipv4 vrf client1

ROUTEUR2(config-router-af)# redistribute connected

ROUTEUR2(config-router-af)# synchronization

ROUTEUR2(config-router)# address-family ipv4 vrf client2

ROUTEUR2(config-router-af)# redistribute connected

ROUTEUR2(config-router-af)# synchronization

Cette configuration va nous permettre donc de propager les routes entre nos VRF. La prise en compte des modifications n’est pas forcément instantanée et peut prendre quelques minutes. Une fois le BGP configuré de cette sorte, il ne nous manque plus qu’une route : la route par défaut. Le BGP n’est pas un protocole réfléchi pour propager des routes par défaut. Il est cependant possible de lui forcer la main pour qu’il le fasse tout de même.

ROUTEUR2(config)# router bgp 1

ROUTEUR2(config)# default-information originate

ROUTEUR2(config-router)# address-family ipv4 vrf interco

ROUTEUR2(config-router)# default-information originate

Vous devriez voir toutes les routes appropriées dans les bonnes VRF. Les VRF clientes doivent donc avoir les routes vers les réseaux de prod et d’interco mais pas l’autre client. Les VRF d’interco et de prod doivent avoir une route vers l’un, l’autre et les VRF clientes.

Cet article clot la série des billets sur le cloisonnement de réseaux par le biais des VRF Cisco. Je vous ai uploadé les configuration que j’ai fait : Routeur1 & Routeur2.  Si vous avez des questions ou que vous pensez qu’il y a des imprécisions, n’hésitez pas à me le signaler par le biais des commentaires. J’espère que ce tutoriel vous aura été utile.