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

Configurer un switch Cisco sous MacOS

CISCO LOGOCela fait désormais un an que je suis utilisateur assidu de MacOS. J’ai toujours réussi à faire ce que je faisais sur PC sur MacOS à quelques exceptions près. Ces deux exceptions sont les jeux 3D spécifiques Windows (Flight Simulator entre autre) et l’administration d’un équipement réseau via port série.

Les MacBook Pro ne sont pas dotés d’un port série. J’ai donc du commander un adaptateur USB-Série sur Ebay pour une somme tout à fait correcte dont je ne me souviens plus. On en trouve actuellement pour moins d’une dizaine d’euros. Vous allez cependant devoir vous armer de patience car ils sont le plus souvent expédiés de Chine. Voici à quoi ressemble ce fameux adaptateur.

usbserie

Il fonctionne parfaitement sous Ubuntu. Je n’ai eu aucune difficulté particulière. Une simple recherche Google et l’installation d’un driver a suffit pour le faire fonctionner. Je souhaitais cependant le faire fonctionner sur mon MacBook car il est quand même bien plus pratique de déplacer un portable qu’une tour.

La première action à effectuer est de récupérer le pilote adapté à l’adaptateur que vous avez acheté. Le problème est qu’il n’y a strictement rien marqué dessus. Ayant précédemment fait l’installation sous Ubuntu, j’avais réussi à déterminer qu’il s’agissait d’un PL2303. Ces adaptateurs semblent très répandus. Il y a donc beaucoup de chances que si le votre ressemble au mien, ce soit la même chose. Vous trouverez le pilote du PL2303 sur le site d’Apple. Vous allez devoir redémarrer votre poste pour finaliser l’installation du pilote.

Ensuite, il va falloir se connecter au périphérique que vous avez raccordé à l’autre bout de votre câble série. Sur Windows, vous auriez eu HyperTerminal qui remplit très bien ses fonctions. Sur MacOS, il est visiblement possible de faire fonctionner Minicom. Je n’ai pas du tout réussi… Fink et apt-get n’ont pas réussi à le trouver dans leurs dépôts. Je me suis donc lancé dans l’utilisation de screen. Dans mon cas, mon adaptateur était reconnu sous le nom /dev/cu.PL2303-00002006.

Il va falloir aller configurer les paramètres du port série du système. Dans le fichier /etc/gettytab, vous devriez trouver des lignes commencant par « serial. « . Effacez (ou commentez) toutes celles ne contenant pas 9600. Sauvegardez le fichier et exécuter la commande suivante :

stty -f /dev/cu.serial

Si la première ligne de la réponse est « speed 9600 baud; », votre port série est bien configuré. Vous pouvez ensuite accéder au périphérique en exécutant la commande suivante :

screen /dev/cu.PL2303-00002006

Vous devriez pouvoir accéder à votre périphérique. Une fois que vous aurez fini la configuration, vous pouvez quitter le screen en tapant « Cmd A » puis « Cmd . ».

Je pense que ce tutoriel devrait être utile à quelques personnes car cette configuration n’est pas forcément aisée à faire. Je me suis aidé d’un sujet sur le site d’Apple et d’un tutoriel du site MacOSHints.

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

stepfinal2Je vais commencer une nouvelle série d’article plus orientée vers le réseau. Je n’ai eu que relativement peu d’occasions de parler de réseau sur ce blog mais je vais me rattraper quelque peu. Cette série devrait comporter 3 articles voire peut être un peu plus, en fonction de mon humeur. Elle est le résultat d’une journée d’expérimentation effectuée avec un collègue dans le cadre de mon stage. Dans ce billet d’introduction, je vais présenter l’objectif de l’expérimentation, le matériel utilisé et la topologie.

La problématique

Lorsque nous nous sommes lancés dans ces expériences, nous avions un objectif bien précis correspondant à la réalité d’une architecture actuellement en production. La problématique était d’isoler au niveau IP plusieurs clients pouvant potentiellement avoir des plages d’IP similaires. Plus concrètement, l’objectif était d’isoler chaque client dans sa « bulle de routage » afin de pouvoir avoir une plus grande liberté dans l’évolution de l’architecture et dans l’intégration de nouveaux clients.

Nous savions déjà qu’il était possible de résoudre le problème d’isolation par le biais des VRF de Cisco. Pour rappel, une VRF est une « bulle de routage » spécifique à un groupe de ports. Typiquement, une VRF correspond à un client spécifique. La véritable difficulté venait du fait que nous souhaitions également qu’il soit possible de communiquer de manière sélective entre les différentes VRF.

Le matériel utilisé

Afin de pouvoir tester la mise en place de cette idée, nous avons ressorti des équipements Cisco qui se trouvaient fortuitement sur notre chemin. Ce jour là, notre chemin a rencontré deux Cisco 7204 VXR ainsi que deux Cisco 2970G. Chaque 7204 VXR était doté d’une carte de supervision avec 2 ports 100Mbit/s ainsi que d’un module 1 interface 100Mbit/s supplémentaire. Nous avons donc mélangé tout ce matériel pour faire deux routeurs différents : le « Routeur 1  » sans module supplémentaire et le « Routeur 2  » avec les deux modules supplémentaires.

Voici une petite photo du montage que nous avons effectué.

matosLe « Routeur 1  » était le routeur du haut et le « Routeur 2  » était le routeur du bas. Au niveau des switchs, nous n’avons utilisé que celui du bas. Les ports 1 et 2 servaient pour le réseau « Interco ». Les ports 13 à 16 étaient le VLAN de Prod. Les ports 17 à 20 étaient le VLAN Client 1. Les ports 21 à 24 étaient les VLAN Client 2. Le câble permettait de relier le PC de test.

Topologie logique

Le schéma suivant représente la topologie logique que nous avons mis en place.

SchemaGlobalSmall

Le « Routeur 1  » est le routeur qui pourrait faire office de routeur de sortie vers Internet. La route par défaut de notre réseau pointera sur lui. Le « Routeur 2  » est le routeur « coeur » qui arbitrera toutes les VRF et les échanges de routes. Les trois switch du bas du schéma sont les différents LAN de nos clients. L’objectif sera de faire communiquer les LAN client avec le routeur 1 et le LAN de Prod.

Au final, cet article avait pour objectif de vous présenter la topologie et la problématique. Le prochain article s’attachera  la configuration des équipements et la mise en place des VRF.

Articles de la série

Configuration réseau d’OpenSolaris

solarisJe vous ai déjà fait une présentation succincte de Solaris et introduit la prise en main d’un tel système d’exploitation. Au fur et à mesure que je découvre, de mon coté, OpenSolaris, je rencontre différents problèmes. Un problème assez handicapant que j’ai rencontré est la configuration réseau.

Lorsque j’ai monté ma machine virtuelle OpenSolaris, j’ai fait la configuration réseau à la main rapidement via l’utilitaire ifconfig. Je ne représenterais pas cet utilitaire dans ce billet. Son fonctionnement sous Solaris est fortement similaire à son fonctionnement sous Linux. L’utilitaire route fonctionne de manière similaire pour l’ajout de routes. Il est cependant différent dans la mesure où il ne permet pas l’affichage de la table de routage via la commande route -n. Afin d’afficher la table de routage, il est nécessaire d’exécuter la commande netstat -rn.

La problématique de ce type de configuration est que la configuration n’est pas conservée après un redémarrage du système d’exploitation. Nous allons donc nous intéresser plus spécifiquement à la configuration pérenne des interfaces réseau en IP statique. La configuration se fera via le module physical:default.

Tout d’abord, vous allez devoir déclarer le nom d’hôte de votre machine. Vous remplacerez xnf0 par le nom de votre interface réseau.

echo « hostname »> /etc/hostname.xnf0

Ensuite, on sauvegarde le fichier hosts d’origine et on y insère les noms d’hôte de votre machine.

echo « 127.0.0.1 localhost »> /etc/inet/hosts

echo « 10.0.0.3 antoinebenkemoun.fr »>> /etc/inet/hosts

Nous allons ensuite spécifier le masque de sous-réseau lié à cette interface.

echo « 10.0.0.0 255.0.0.0 »>> /etc/inet/netmasks

Il nous reste plus qu’à préciser la route par défaut.

echo « 10.0.0.1 »> /etc/defaultrouter

La configuration de l’interface est désormais terminée. Il ne nous reste plus qu’à vérifier que les bon services sont activés. Nous devons activer le service physical:default et désactiver physical:nwam. Ce deuxième service est un doublon du premier, il ne faut donc en activer qu’un seul.

svcadm disable svc:/network/physical:nwam

svcadm enable svc:/network/physical:default

Afin de faire prendre en compte les modifications d’interface réseau, il est nécessaire de redémarrer le service physical:default.

svcadm restart svc:/network/physical:default

Le tour est joué ! Je pense que ce billet devrait être utile à certaines personnes démarrant sous Solaris et venant du monde de Linux. Dans tous les cas, il me sera utile pour future référence.

Nouvelle classification des types de virtualisation

tech-presentation-2J’ai déjà eu l’occasion de proposer une classification des différents types de virtualisation lors d’un précédent article sur ce blog. Lors de ce précédent article, je m’étais attaché à classifier les solutions de virtualisation de systèmes d’exploitation. Je propose par le biais de cet article de re-préciser cette classification en y intégrant d’autres types de virtualisation et en reprenant en partie le précédent.

Tout d’abord, il sera essentiel de s’interroger sur ce que nous allons virtualiser car il est possible de virtualiser bon nombre de composants applicatifs. J’utiliserais le terme de composant applicatif pour désigner tout ce qui n’est pas matériel. Ce terme inclura donc les systèmes d’exploitation en globalité ou en partie aussi bien que les applications spécifiques. Ensuite, je proposerais un arbre de classification complété par rapport à la première version de cet article. Je rappellerais au passage les appellations correspondantes aux différents types de virtualisation.

Note : Cet article a été publié le 28 Octobre dans une version simplifiée sur le blog Virtualisation d’Orange Business ServiceS.

On virtualise quoi ?

Tout d’abord, il est essentiel de se poser la question « Que virtualise-t’on ? ». Il est possible de virtualiser beaucoup de choses de nos jours. Un début de liste comporterait des routeurs, des switchs, des applications, des systèmes d’exploitation, de l’espace disque et ainsi de suite.

Nous allons distinguer trois familles de virtualisation : réseaux, systèmes d’exploitation et processus. Ces trois types constitueront le premier étage de notre arbre de classification.

On virtualise comment ?

Nous avons donc effectué une première discrimination basée sur le composant applicatif que nous allons virtualiser afin d’établir le premier étage de notre arbre de classification. Nous allons ensuite établir le second étage de cet arbre.

Nous allons ensuite associer à chaque composant applicatif les différents types de virtualisation correspondants. En ce qui concerne les systèmes d’exploitation, nous ajouterons une distinction importante qui est la modification ou non du système d’exploitation invité. Un système d’exploitation invité est un système d’exploitation qui s’exécute par dessus une couche de virtualisation spécifique.

Voici donc l’arbre de classification que je propose :

schema_classification_small

Le premier type de virtualisation présent dans cet arbre est la virtualisation d’équipements réseaux. Il aurait été possible d’inclure la virtualisation de réseaux. Ceci a été exclu de cette classification car il ne s’agit que d’un mécanisme de commutation spécifique. Ce type de virtualisation permet de créer des environnements réseaux spécifiques et cloisonnés de bout en bout. Les solutions existantes dans ce domaine sont les produits Nexus de Cisco et le futur switch virtuel de Citrix.

Dans la catégorie des systèmes d’exploitation, nous avons choisi de distinguer les systèmes d’exploitation modifiées et non modifiées. Les modifications en question sont les modifications du noyau nécessaire à l’exécution du système d’exploitation par dessus une couche de virtualisation spécifique.

La virtualisation de système d’exploitation modifiés est la paravirtualisation. Ce terme a tendance à être utilisé de nombreuses manières différentes. La paravirtualisation est la virtualisation de systèmes d’exploitation dont le noyau a été modifié pour communiquer avec la couche de virtualisation au lieu de communiquer avec le matériel physique. Pour résumer, la système d’exploitation va avoir conscience d’être virtualisé et sera adapté à cet effet. L’ajout de simple drivers spécifique n’implique pas forcément paravirtualisation. Les solutions existantes dans ce domaine sont les produits XenServer de Citrix, xVM de Sun, XenSource voire Hyper-V de Microsoft. VMWare commence à se lancer dans cette technologie prudemment. Si vous souhaitez en savoir plus sur la paravirtualisation, je vous laisse consulter l’article sur la paravirtualisation.

En ce qui concerne les systèmes d’exploitation non-modifiés, nous distinguerons deux types de virtualisation : la virtualisation totale et la virtualisation matériel assistée. La virtualisation totale est la virtualisation « primitive » qui consiste à émuler le matériel physique ainsi que son comportement. Il s’agit de l’approche la plus couteuse mais la plus simple à mettre en oeuvre. La virtualisation matériel assisté est une extension du principe de virtualisation totale. Cette extension se matérialise par l’utilisation des extensions processeur spécifiques à la virtualisation (AMD-V et Intel-VT). Ces extensions permettent d’accélérer la virtualisation par différents mécanismes. Les solutions utilisant cette technologie sont VMWare, Virtualbox de Sun, Virtual PC de Microsoft, QEMU et bien d’autres.

Au niveau de la virtualisation de processus, nous retrouvons deux types de virtualisation : la virtualisation au niveau du système d’exploitation et la virtualisation d’application. La virtualisation au niveau du système d’exploitation consiste à faire croire à plusieurs jeux de processus qu’ils s’exécutent dans différents systèmes d’exploitation alors que ce n’est pas le cas. Les solutions utilisant cette technique sont les zones Solaris, les chroot Linux, les jails BSD, OpenVZ et bien d’autres. La virtualisation d’application consiste à livrer des applications non installées sur un poste par un serveur. Les solutions utilisant cette technique sont XenApp de Citrix ou VMWare Thinapp.

Au final, je pense que cette classification est plus complète que la précédente que j’avais eu l’occasion de présenter. Elle inclut notamment la virtualisation d’application et la virtualisation d’équipements réseaux. Cette classification reste une proposition et il est tout à fait possible de proposer une classification sous un autre angle.

La configuration réseau de Xen

J’ai déjà eu l’occasion d’évoquer la spécificité de la configuration réseau dans le cadre d’une plateforme de virtualisation dans un précédent billet. Je vais traiter ici des différentes configuration réseau possible avec Xen. Bien que cet article s’attachera aux modes présents dans Xen, vous pourrez sans aucun doute retrouver dans d’autres solutions de virtualisation. Si vous souhaitez un rappel de la terminologie Xen qui sera utilisé ici, je vous invite à relire l’article sur la terminologie.

Les trois modes de configuration réseau dans Xen sont : bridge, route et NAT. En Français, nous aurons donc pont, routage et NAT. Ces trois modes répondent à différents besoins en terme de configuration réseau. Le premier critère de choix du mode réseau est la topologie logique du réseau existant. Les éléments de topologie vont inclure les VLAN ainsi que les différents réseaux IP.

Le mode pont

RzoXen-Bridge

Le schéma ci-dessus explique le fonctionnement du mode pont. Il s’agit du mode le plus simple agissant au niveau le plus bas. Les domU sont connectés au dom0 via des interfaces réseau virtuels. Le dom0 ne fait qu’une simple commutation en redirigeant les trames soit vers le bon domaine soit vers le reste du réseau.

L’avantage de ce mode est l’extrême simplicité de la configuration qui permet une transparence par rapport au reste de l’architecture. La configuration des domU est également simple et ne nécessite aucune particularité. Il est possible de superposer n’importe quelle configuration IP en utilisant ce mode. Vous remarquerez que ce mode ne prend pas en compte les VLAN nativement. Nous verrons ultérieurement une possibilité de fonctionnement de ce mode avec la prise en compte des VLAN via 802.1Q.

Le mode routage

RzoXen-Route

Le schéma ci-dessus explique le fonctionnement du mode routage. Il s’agit d’un mode assez peu utilisé. La raison de la faible utilisation de ce mode est lié au fort lien entre topologie physique et topologique logique. Je m’explique. Avec cette configuration, il est pratiquement impossible de migrer des machines virtuelles entre des machines physiques sans modification de routage.

Ce mode est cependant très utile dans le cadre d’un serveur OVH doté d’IP supplémentaires. Ceci est du au fait qu’une bonne partie des serveurs OVH ne supportent pas le mode pont pour un raison inconnue.

Le mode NAT

RzoXen-NAT

Le mode NAT est une évolution du mode routage. Vous avez toujours deux plages d’IP différentes de part et d’autre du dom0 mais les IP des domU ne seront pas visibles sur le réseau public.

Par défaut, ce mode permet un accès au réseau public par les domU mais pas d’accès dans le sens inverse. Vous pourrez mettre en place des accès dans le sens inverse en utilisant iptables.