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

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.

Un brin d’humour scientifique

Avant de reprendre la série de billets sur les VRF Cisco, je souhaite partager une trouvaille avec vous. Je tiens à remercier la fonction « Explore » de Google Reader qui m’a permis de trouver cet artiste. Si vous ne connaissez pas encore cette fonction et que vous utilisez Google Reader, je vous conseille de la découvrir au plus vite.

Je vous présente Brian Malow qui se décrit en tant que « Science Comedian ». Il s’agit donc d’un humoriste pas tout à fait conventionnel. Là où l’essentiel des humoristes tentent de se rapprocher du grand public et de relater des expériences communes, il a pour sujet central la science.

Brian Malow

Il est américain donc la totalité de ses sketchs sont en anglais. Je vous conseille fortement la vidéo de ses sketchs lors du Wonderfest. La vidéo ci-dessous en est un extrait. Il y a également de nombreux extraits sur son site personnel. Ca s’adresse pas au grand public mais ca vaut vraiment le détour ! Une bonne tranche de rigolade

Les domaines Xen : le domaine privilégié

Xen_logoCela fait désormais un bon bout de temps que je n’ai pas eu l’occasion de vous parler de Xen. Lors du dernier article sur ce sujet, nous avions surtout parlé de configuration réseau. J’aurais peut être l’occasion d’en reparler par la suite, nous verrons bien.

J’ai déjà eu l’occasion de vous parler des domaines Xen à plusieurs occasions sur ce blog. J’ai défini la notion dans l’article sur la terminologie Xen. Dans ce billet je vais essayer d’élaborer un petit plus sur ce sujet en détaillant un peu plus les interactions entre le domaine privilégié et le matériel.

Domaine privilégié : dom0

Le domaine privilégié ou dom0 est le système d’exploitation « visible » d’une installation Xen. Il s’agit du système d’exploitation que l’on installe avant d’installer l’hyperviseur. Pour rappel, cela ne veut pas dire que l’hyperviseur est au desssus du dom0 car il est bien en dessous. Vous pouvez le vérifier au démarrage, car on voit bien que Xen s’exécute avant la distribution du dom0.

Le domaine privilégié est un domaine exceptionnellement sensible. Il s’agit du domaine qui va avoir accès à toutes les ressources physiques auxquelles l’hyperviseur n’aura pas l’accès exclusif. L’hyperviseur n’a un accès exclusif au processeur et à la mémoire. Tout le reste relèvera donc de la compétence du dom0. Ceci inclut donc tout particulièrement les supports de stockage. Le dom0 a donc accès à toutes les données de votre hyperviseur, il est donc indispensable de le sécuriser.

Le rôle du domaine privilégié

En ce qui concerne le rôle du dom0, il est essentiellement de gérer les supports de stockage, les périphériques éventuels ainsi que les éventuels interfaces d’administration. Il n’est pas souhaitable de lui attribuer plus de rôles que cela. Il est cependant indispensable de lui allouer des ressources physiques convenables. Etant donné que la gestion de support de stockage fait partie de sa compétence, il est nécessaire qu’il se voit attribuer suffisamment de mémoire vive afin de pouvoir constituer un cache performant.

L’hyperviseur attribue par défaut tous les périphériques au domaine privilégié. Certaines configurations spécifiques peuvent nécessiter de rendre accessible un périphérique à une machine virtuelle. Ces configurations sont relativement compliquées à mettre en place dans un contexte de haute disponibilité avec migration à chaud. Ceci s’explique habituellement par le simple fait que le périphérique ne peut être branché sur un seul serveur à la fois. Des solutions d’USB sur IP sont plus simples. Il reste cependant possible d’effectuer une délégation de périphérique vers un domaine non privilégié. Il y a déjà eu des exemples de délégation de cartes graphique permettant de jouer à des jeux 3D dans des domaines non privilégiés.

Interface avec les autres domaines

Les autres domaines vont accéder aux ressources relevant de la compétence du dom0 via des pilotes génériques de périphérique. Ces pilotes génériques permettent de maximiser la compatibilité et d’éviter les différences entre les différentes plateformes Xen. L’intérêt des pilotes génériques est immédiat dans le cas de la migration à chaud où la standardisation des environnements est primordiale.

Le schéma suivant récapitule très bien toutes ces interactions.

Capture d’écran 2009-12-14 à 14.39.27

Au final, je pense avoir fait une présentation plutôt détaillée du domaine privilégié. Si vous avez des questions ou des remarques, n’hésitez pas, les commentaires sont faits pour cela. Dans un prochain article, j’évoquerais plus en détail les domaines non privilégiés.

Cloisonnement d’un réseau à l’aide de VRF : Mise en place

stepfinal2Ce billet fait suite au premier billet traitant du sujet du cloisonnement d’un réseau à l’aide de VRF. Le premier billet avait pour objectif dans présenter la plateforme d’expérimentation que nous avons mis en place. Dans ce billet, nous allons nous intéresser à la configuration basique des équipements Cisco que nous avions à notre disposition. Dans un troisième et dernier billet, je présenterais la configuration du BGP permettant le propagation de routes sélectives entre les différentes VRF.

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

Retour sur le Barcamp du 28 Novembre

barcamp_icon_finalJe vous avais parlé du barcamp qui a eu lieu à Troyes le week-end dernier dans un précédent billet. Je vais donc faire un petit retour sur cet événement.

L’objectif fixé était de faire un barcamp ouvert aux extérieurs tout en passant un bon moment au milieu de l’UTT Lan Session. Je pense que nous avons réussi cet objectif à l’exception que nous n’avons pas réussi à attirer beaucoup d’extérieurs. En même temps, nous n’avons pas beaucoup essayé je le reconnais.

Les sujets présentés sont les suivants : OAuth & OpenID, VBA pour Excel, SOAP pour Buckutt, Réseaux de stockage, LDAP, Trap your process et la CNIL. Nous avons donc eu une liste de sujets plutôt variés. Au niveau du timing, nous avons été plus ou moins fidèle à ce qui a été prévu. Certains présentations ont pris beaucoup de temps que prévu mais cela a compensé pour celles qui avaient été plus courtes.

Vous pouvez retrouver la présentation sur OpenAuth & OpenID en cliquant sur le lien ci-dessus. Vous pouvez trouver ma présentation ci-dessous.

Vous l’aurez compris, nous tirons un bilan tout à fait positif de ce barcamp. Nous prévoyons de réitérer cette expérience par la suite. Pour le prochain barcamp, nous le ferons dans les règles de l’art et essayerons d’attirer un maximum d’extérieurs.