LAND & JOINT SYSTEM MULTICAST IPv6 INTRA & INTER DOMAINE

Transcription

1 LAND & JOINT SYSTEM MULTICAST IPv6 INTRA & INTER DOMAINE Cong Thien NGUYEN Jérôme TENEUR 1

2 Sommaire 1. MULTICAST & IPV ADRESSAGE IPV LES DIFFERENTES CATEGORIES D'ADRESSES IPV ABREVIATION D'ADRESSES IPV LES DIFFERENTS TYPES D ADRESSES IPV Adresse de loopback: :: Adresse de lien local: fe80:: / Adresse de site local: fec0:: / Adresse IPv4 compatible: ::a.b.c.d Adressage agrégé (routable sur internet) Adressage multicast Adresses multicast spécifiques ADRESSE IPV6 DERIVEE D UNE ADRESSE MAC ROUTAGE MULTICAST LE ROUTAGE INTRA-AS MLD PIM-SM (sparse-mode) LE ROUTAGE INTER-AS PIM Embedded RP PIM-SSM EMULATION SOUS CLOWNIX QU EST CE QUE CLOWNIX? CREATION D UNE PLATE-FORME VIRTUELLE SOUS CLOWNIX UTILISATION DE CLOWNIX CONFIGURATION SUR ROUTEUR CISCO ROUTAGE INTRA-AS Compatibilité, déclaration, et routage unicast Activation du routage multicast IPv Portée de diffusion d un flux multicast ROUTAGE INTER-AS Déclaration des AS et des réseaux voisins Activation du routage multicast Ipv CONFIGURATION SUR ROUTEURS LINUX LES POSSIBILITES QUAGGA XORP (EXTENSIBLE OPEN ROUTER PLATFORM) Installation et configuration initiale Routage intra-as Routage inter-as Routage multicast IPv ASPECT SECURITE

3 6.4. FONCTIONS PROTOCOLAIRES NATIVES TESTS DE FONCTIONNEMENT SUR RESEAU EMULE APPLICATIONS UTILISEES POUR LES TESTS Application ASM Applications SSM IOS CISCO Utilisation d un script Perl Tests en intra-domaine Test en inter-domaine QUAGGA XORP COHABITATION CISCO - QUAGGA - XORP GLOSSAIRE REFERENCES DOCUMENTS NORMATIFS REFERENCE BIBLIOGRAPHIQUE REFERENCE INTERNET ANNEXES PROGRAMME ASM APPLICATION SERVEUR PROGRAMME ASM APPLICATION CLIENT FICHIER DE CONFIG CISCO 2 RENDEZ-VOUS POINT FICHIER DE CONFIG CISCO SCRIPT PERL DE CONFIGURATION DES ROUTEURS PIM-SM EXEMPLE FICHIERS DE CONFIGURATION QUAGGA FICHIER DE CONFIGURATION XORP COMPARAISON DES COMMANDES CISCO ET XORP Table des illustrations Figure 1 - Diffusion unicast... 5 Figure 2 - Diffusion multicast... 5 Figure 3 - Format d'adresse IPv6 de base... 6 Figure 4 - Format d'adresse IPv6 de lien local... 7 Figure 5 - Format d'adresse IPv6 de site local... 8 Figure 6 - Format d'adresse IPv6 compatible Ipv Figure 7 - Format d'adresse IPv6 routable... 9 Figure 8 - Format général d'une adresse IPv6 multicast Figure 9 - Format d'une adresse IPv6 multicast dérivée d une adresse unicast

4 Figure 10 - Format d'une adresse IPv6 multicast PIM-SM Figure 11 - Format d'une adresse IPv6 multicast Embedded-RP Figure 12 - Adresse IPv6 dérivée d'une adresse MAC Figure 13 - User Mode Linux Figure 14 - Organisation de la plate-forme Clownix Figure 15 - Fichier de configuration 'config_simu_net' Figure 16 - Zebra Figure 17 - Topologie de test intra-domaine Figure 18 - Topologie de test inter-domaine

5 1. MULTICAST & IPV6 Cette étude à pour but de mettre en avant les différentes techniques pouvant être employées afin de permettre la diffusion de flux multicast en IPv6. On entend par multicast le fait de communiquer simultanément avec un groupe d'ordinateurs identifiés par une adresse spécifique (adresse de groupe). Cela implique l utilisation de deux protocoles, l un permettant l inscription au groupe de diffusion, le second permettant d'envoyer un même paquet à plusieurs utilisateurs. En unicast, si l on veut pas exemple transmettre un même flux de données (exemple type : un flux vidéo) vers plusieurs destinataire, on est obligé d établir autant de connexion qu il y a de client. Figure 1 - Diffusion unicast A contrario de l'unicast, en multicast le paquet n'est émis qu'une seule fois, et sera routé vers toutes les machines du groupe de diffusion. Figure 2 - Diffusion multicast L ensemble des services qui fonctionneront sur ce modèle de diffusion, se verront également appliquer le protocole de connexion IPv6. Ce dernier étant une évolution de l actuelle IPv4 basé sur un adressage en 128bits (32bits en IPv4). 5

6 2. ADRESSAGE IPV6 IPv6 définit trois types d'adresses : - l'adresse Unicast pour définir un hôte particulier. Un paquet émis avec cette adresse de destination n'est remis qu'à la machine ayant cette adresse IPv6. - l'adresse de Multicast qui concerne un ensemble d'hôtes appartenant à un même groupe de diffusion. Un paquet émis avec cette adresse de destination est remis à l'ensemble des machines concernées par cette adresse. - l'adresse Anycast est ni plus ni moins de l'adressage multicast, à la différence qu'un paquet émis avec cette adresse de destination ne sera remis qu'à un seul membre du groupe. Une adresse IPv6 est longue de 128 bits et se compose de huit champs de 16 bits, chacun étant délimité par deux-points (:). Chaque champ doit contenir un nombre hexadécimal, à la différence de la notation en format décimal avec points des adresses IPv4. Figure 3 - Format d'adresse IPv6 de base Les trois champs situés complètement à gauche (48 bits) contiennent le préfixe de site. Le préfixe décrit la topologie publique allouée par une autorité compétente. Le champ suivant correspond à l'id de sous-réseau de 16 bits alloué au site. L'ID de sous-réseau décrit la topologie privée, mais par souci de simplification pour le restant du document, nous regrouperons ce champ avec le préfixe du site sous le nom de préfixe de sous-réseau. Les quatre champs les plus à droite (64 bits) contiennent l'id d'interface, également appelée jeton. L'ID d'interface est soit configurée automatiquement à partir de l'adresse MAC de l'interface, soit configurée manuellement. 6

7 Pour des réseaux locaux de type Ethernet, on utilise l'adresse MAC de la carte réseau. On inverse la valeur du septième bit, on découpe en deux blocs de 24 bits, et on intercale fffe entre les 2 blocs. Par exemple, si l'adresse MAC est 00:0D:60:38:6D:16, on obtient l'identifiant 20d:60ff:fe38:6d16 Cette étape de création d adresses est plus explicitement présentée dans la partie «Adresse IPv6 dérivée d une adresse MAC» En général, les adresses IPv6 n'occupent pas la totalité des 128 bits dont elles disposent. Certains champs sont renseignés partiellement ou en totalité par des zéros. L'adressage IPv6 permet d'utiliser la notation à deux points (::) pour représenter les champs de zéros de 16 bits. On peux par exemple raccourcir l'adresse IPv6 de la Figure 3 en remplaçant les deux champs de zéros contigus de l'id d'interface par deux deux-points. L'adresse devient alors : 2001:0db8:3c4d:0015::1a2f:1a2b. Attention cependant, ce raccourci ne peut être utiliser qu une seule fois sur la totalité de l adresse. Les autres champs de zéro peuvent être représentés par un seul 0. De plus, il est également possible d omettre le(s) zéro(s) au début d un champ. Par exemple 0db8 peut être remplacé par db8 Donc, l'adresse 2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b peut être raccourcie en 2001:db8:3c4d:15::1a2f:1a2b Adresse de loopback: ::1 L'adresse de boucle ::1 a le même rôle qu'une adresse IPv Lorsqu'une machine utilise cette adresse, elle s'envoie des paquets IPv6 à elle même Adresse de lien local: fe80:: /10 Cette adresse de lien local est obtenue par configuration automatique et n est valide uniquement que sur un même espace de lien sans routeur intermédiaire. Un routeur ne route pas ce type d'adresse. L'interconnexion par hub ou switch de niveau Mac représente cet espace de lien. Le préfixe d'une adresse de lien local est fe80:: / bits 54 bits 64 bits ID interface F E 8 Figure 4 - Format d'adresse IPv6 de lien local 7

8 Adresse de site local: fec0:: /10 Cette adresse de site local est restreinte au site. Par exemple un site non relié sur Internet. L'idée consiste à reprendre le concept des adresses IPv4 confinées au site et ne pouvant être routées sur internet (par exemple les adresses /8, /12 et /16). Un routeur de sortie de site ne doit pas router ce type d'adresse. Le préfixe d'une adresse de site local est fec0:: / bits 38 bits 16 bits 64 bits ID Subnet ID interface F E C Figure 5 - Format d'adresse IPv6 de site local Adresse IPv4 compatible: ::a.b.c.d Une machine IPv6 communiquant avec une autre machine IPv6 via un tunnel automatique IPv6/IPv4 utilise des adresses IPv4 compatibles. En fait, le paquet IPv6 ayant pour adresse destination une adresse IPv6 compatible (exemple :: ) est encapsulé dans un paquet IPv4 ayant pour adresse destination l'adresse IPv Le paquet IPv4 peut éventuellement être routé avant d'atteindre son destinataire. Le destinataire recevant le paquet IPv4 retire le paquet IPv6 qui y est encapsulé. Ces adresses sont de la forme ::a.b.c.d. Par exemple :: bits 32 bits Adr IPv Figure 6 - Format d'adresse IPv6 compatible Ipv4 8

9 Adressage agrégé (routable sur internet) L'adressage IPv6 est structurée en plusieurs niveaux selon un modèle dit "agrégé". Cette composition devrait permettre une meilleure agrégation des routes et une diminution de la tailles des tables de routage. 3b 13bits 8bits 24 bits 16 bits 64 bits TLA Reserve NLA SLA ID interface Figure 7 - Format d'adresse IPv6 routable La taille d'une adresse IPv6 est de 16 octets (128 bits). Cette taille, suffisamment importante, permet d'établir un plan d'adressage hiérarchisé en trois niveaux. 1 - la topologie publique utilisant 48 bits 2 - la topologie de site sur 16 bits 3 - la topologie d'interface sur 64 bits. Les deux premiers niveaux identifient le réseau tandis que le troisième identifie l'hôte sur le réseau. Ainsi on retrouve: - le préfixe 2000::/3 (c'est-à-dire sur 3 bits) identifie le plan d'adressage agrégé - le 13 bits suivants identifient l'unité d'agrégation haute (TLA Top Level Aggregator), - les 8 bits suivants sont réservés pour l'évolution de l'adressage. Ces bits pourront être ré-attribués aux TLA ou NLA dans l'avenir car pour l'instant, ces besoins sont difficilement quantifiables. - les 24 bits suivants identifient l'unité d'agrégation basse (NLA Next Level Aggregator). - les 16 bits suivants (SLA Site Level Aggregator) sont sous la responsabilité du gestionnaire de site. - les derniers 64 bits identifient l'interface, c'est-à-dire l'hôte sur le réseau identifié par les 64 premiers bits. 9

10 Adressage multicast L'adresse IPv6 multicast permet de distribuer des informations ou des services identiques à un groupe de machines, appelé groupe multicast. Une interface peut faire partie d'un nombre indéfini de groupes multicast. Les paquets envoyés à l'adresse multicast sont distribués à tous les membres du groupe. 8 bits 4 bits 4 bits 112 bits FLGS SCOP Group-ID F F Figure 8 - Format général d'une adresse IPv6 multicast Identifie l'adresse en tant qu'adresse multicast. - FLGS Jeu des quatre indicateurs 0,R,P,T Le bit T indique la pérennité de l adresse 0 = adresse permanente attribué par l IANA 1 = adresse temporaire Le bit P permet de décrire une adresse lié au protocole de routage PIM-SSM Le bit R décrit une adresse lié au protocole PIM embedded-rp (Si R est à 1, P doit être également à 1) Le bit de poids fort n est pas encore attribué et reste donc à 0 - SCOP permet d'en limiter la portée de diffusion. En IPv4, la portée d'un paquet est limitée par le champ TTL (Time To Live), de même en Ipv6, des préfixes peuvent être définis à portée réduite. Les valeurs suivantes sont définies : 1 - node-local 2 - link-local 3 - subnet-local 4 - admin-local 5 - site-local 8 - organisation-local E - global Les portées 0 et F sont réservées. - ID de groupe - Identificateur du groupe multicast (permanent ou dynamique). 10

11 Adresses multicast spécifiques Les adresses temporaires sont, par définition, inconnues sur le réseau. La solution permettant de router ce type d adresse est de dériver l adresse multicast d une adresse unicast. L adressage peut se faire de plusieurs manières, en fonction de l utilisation de l adresse. On distingue 3 grands types d adresses temporaires 1. Adresse ponctuelle utiliser par exemple dans le cadre d une visioconférence. (FLAGS=0011) 2. Adresse multicast PIM-SSM (FLAGS = 0011) 3. Adresse multicast embedded-rp permettant d inclure l adresse du «Rendezvous Point» dans l adresse de diffusion. (FLAGS = 0111) 1. Adresse ponctuelle 8 bits 4 bits 4 bits 8 bits 8 bits 64 bits 32 bits SCOP Reserve Plen Prefixe reseau ID de groupe F F 3 Figure 9 - Format d'une adresse IPv6 multicast dérivée d une adresse unicast - Réservé - Valeur nulle réservée. - Plen - Nombre de bits au niveau du préfixe du site qui identifient le sous-réseau, pour une adresse multicast assignée en fonction du préfixe réseau. - prefix - ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast. - Groupe-ID - ce champ de 32 bits contient l'identifiant de groupe 2. Adresse multicast PIM-SSM 8 bits 4 bits 4 bits 80 bits 32 bits SCOP 0 Group-ID F F 3 Figure 10 - Format d'une adresse IPv6 multicast PIM-SM Les adresses SSM (Source Specific Multicast) ont un préfixe fixé à FF3X::/96. Ce sont des adresses multicast basées sur le préfixe unicast où les champs Plen et prefix sont positionnés à 0. 11

12 3. Adresse multicast embedded-rp 8 bits 4 bits 4 bits 4bits 4bits 8 bits 64 bits 32 bits SCOP Reser RPad Plen Prefixe reseau ID de groupe F F 7 Figure 11 - Format d'une adresse IPv6 multicast Embedded-RP 1. Reser (reserved) = RPad : 4 derniers bits de l adresse du RP 3. Plen (prefix length) : longueur du préfixe réseau du RP 4. Prefix : valeur du préfixe réseau du RP 5. group ID : identifiant du groupe 4. Récapitulatif des préfixes et de leur usage Préfix FF0X::/16 FF1X::/16 FF3X::/16 FF3X::/96 FF7X::/16 Utilisation Adresses IPv6 multicast permanentes Adresses IPv6 multicast temporaires générales Adresses multicast dérivées d'un préfix unicast (temporaires) Adresses SSM (temporaires) Adresses IPv6 multicast "Embedded-RP" (temporaires) Le schéma ci-dessous décri la manière dont est construit un ID d une adresse IPv6 dérivée d une adresse MAC. Figure 12 - Adresse IPv6 dérivée d'une adresse MAC 12

13 3. ROUTAGE MULTICAST Pour le multicast, on distingue deux modèles de communication : le modèle ASM (Any- Source Multicast) et le modèle SSM (Source-Specific Multicast). Dans le modèle ASM, un récepteur s'abonne à un groupe, et reçoit les données émises par n'importe quelles sources pour ce groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance. Dans le modèle SSM, les sources sont connues à l'avance et les récepteurs s'abonnent à un groupe et un ensemble de sources. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous. Aujourd'hui, aussi bien pour IPv4 que pour IPv6, PIM-SM est le protocole de routage multicast. PIM-SM permet de mettre en place un arbre de distribution, qui prend racine au Point de Rendez-vous (RP). Ainsi lorsqu'un hôte du domaine émet, le RP du domaine reçoit ses données et les propage dans l'arbre de distribution en direction des hôtes ayant rejoint le groupe. Sources et récepteurs n'ont ainsi pas besoin de synchronisation particulière pour se retrouver au sein d'un même groupe logique nommé par une adresse IP multicast. Les sources économisent des ressources : elles n'envoient qu'un flux de données vers l'adresse de groupe et les paquets sont dupliqués par les routeurs de l'arbre de distribution. PIM-SM nécessite que les routeurs du réseau soient configurés avec un seul et même RP. Cette solution fonctionne bien dans un domaine restreint, mais devient plus compliquée en inter-domaine surtout pour des raisons d'indépendance des domaines. Notons qu'il est possible, d'avoir plusieurs RP par domaine, mais tous les routeurs d'un même domaine doivent utiliser le même RP pour un groupe donné. Pour l'inter-domaine multicast IPv4, un protocole appelé MSDP (Multicast Source Discovery Protocol) permet d'échanger l'état des sources actives entre les domaines. Un tel protocole n'a pas été standardisé pour IPv6 car il a été montré qu'une distribution de l'information de toutes les sources actives de tous les groupes de l'internet n'est pas réaliste pour un déploiement à grande échelle. Embedded-RP est l une des solutions qui répond au problème du routage multicast grâce aux capacité d'adressage IPv6. L'idée est d'insérer l'adresse du RP dans l'adresse du groupe de diffusion. Lorsqu'un hôte envoie des données vers un groupe où s'abonne à un groupe, son routeur d'accès en extrait l'adresse du RP et peut ainsi joindre l'arbre partagé immédiatement. Un groupe d AS (Système autonome) devient un seul domaine multicast, contenant plusieurs RP. Embedded est actuellement, la seule solution ASM (Any Source Multicast) utilisé, extensible à l inter-domaine. L autre modèle multicast a donc été défini plus récemment : SSM (Source Specific Multicast). PIM-SSM (Source Specific multicast) est son protocole, il permet de rajouter un paramètre supplémentaire à PIM-SM, ce dernier étant la ou les source(s) associé(s) au groupe. On s affranchi donc du choix d un RP étant donné que nous connaissons la machine source. Cependant des problèmes apparaissent avec l utilisation de SSM : dans un premier temps tous les équipements ne sont pas compatibles. De plus, ce protocole est relativement récent, et peu d applications sont en mesure de l utiliser. Enfin, ce protocole prend tout son intérêt dans une utilisation en inter-domaine car il permettra à chaque utilisateur de lire un flux multicast, sans nécessiter la mise en place d un RP par l AS concerné (RP qui serait utilisé par tous les autres domaines). 13

14 MLD MLD est un protocole de gestion de groupe multicast qui réalise la signalisation entre l'hôte et son routeur d'accès DR (Designated Router). Il est utilisé par un routeur de bordure IPv6 pour découvrir la présence de récepteurs multicast sur ses liens directement attachés, ainsi que les adresses multicast concernées. MLD est un sous-protocole d'icmpv6, les messages MLD sont des messages ICMPv6 particuliers. Ils sont envoyés avec : o une adresse source IPv6 lien-local o le champ "nombre de sauts" fixé à 1 o l'option "IPv6 Router Alert" activée PIM-SM (sparse-mode) Le protocole PIM-SM (Protocol Independent Multicast - Sparse Mode) permet la construction d'arbres multicast. Il construit pour chaque groupe un arbre de diffusion unidirectionnelle, chaque arbre prenant racine sur un RP (Rendez-vous Point). Lorsqu'il y a plusieurs sources alimentant le même groupe, les paquets en provenance des différentes sources convergent vers le RP associé au groupe, puis à partir de celui-ci les paquets empruntent l'arbre associé au groupe, ce qui leur permet d'atteindre tous les destinataires membres du groupe. La construction de l'arbre de diffusion peut se décomposer en 3 étapes. Etape 1 : l arbre partagé 1. Une station de travail souhaite recevoir un flux multicast, elle va, dans un premier temps, s inscrire au groupe multicast en se déclarant à son DR grâce au protocole MLD. 2. Le routeur concerné doit à ce moment connaître l adresse du RP pour le groupe donné, et lui envoie un message PIM(*,G)JOIN. Cela indique au RP que le routeur veut s inscrire au groupe G sans tenir compte de la source. Ces messages sont envoyés périodiquement afin de spécifier au RP qu il y a toujours quelqu un membre du group multicast. 3. Dès qu'une station émet un paquet multicast vers le groupe, le DR de son lien-local encapsule ce paquet dans un datagramme unicast (message PIM Register) ayant pour adresse de destination le RP associé au groupe. 4. Lorsque le RP reçoit ce datagramme, il décapsule le paquet multicast, et le propage vers les branches concernées. Le paquet est dupliqué aux noeuds qui forment de nouvelles branches, et donc parvient à l'ensemble des destinataires membres du groupe. Quand tous les destinataires situés sur un lien local quittent le groupe multicast, un message PIM Prune est envoyé par le DR au RP afin de spécifier que plus personne n écoute le flux multicast sur la branche de l arbre concerné. De plus, une durée limite de validité étant associée à chaque adhésion, si aucun message PIM ne parvient, l'adhésion sera résiliée. 14

15 Etape 2 : l acheminement spécifique Deux problèmes apparaissent : l encapsulation des PIM register est très coûteuse en terme de ressource pour les routeurs Le chemin emprunté de la source vers le RP puis du RP vers le(s) destinataire(s) peut provoquer un détour pour les datagrammes et ainsi une surcharge réseau inutile. Le but étant de raccourcir le chemin emprunté par les datagrammes depuis la source vers le(s) récepteur(s), 1. le RP va envoyé un message PIM (S,G) JOIN vers le DR de la source (S étant l adresse Ipv6 de la source, et G le groupe multicast). 2. Tous les routeurs traversés vont alors enregistrer l état (S,G) 3. Le DR de la source va maintenant travailler double, en envoyant les datagrammes multicast et le message PIM Register (datagramme multicast encapsuler dans les trames unicast) 4. Quand le RP voit arriver les messages PIM register et les datagrammes multicast simultanément, il envoie au DR de la source un PIM Registerstop, lui indiquant d arrêter l encapsulation. Etape 3 : l arbre des plus courts chemin 1. le DR d'un récepteur reçoit les paquets émis par la source S vers le groupe G 2. le DR émet un message PIM (S,G) Join vers l'émetteur. Cela crée des états spécifiques (S,G) dans les routeurs rencontrés sur le chemin vers l'émetteur. 3. Le message atteint le DR de la source ou un autre routeur ayant déjà l'état (S,G). 4. Les paquets multicast dorénavant émis par l'émetteur S suivront les états (S,G). 5. À partir de cet instant le DR du destinataire peut recevoir deux copies de chaque paquet multicast : une provenant du RP, l'autre provenant directement de l'émetteur. 6. le DR du destinataire détruit les paquets qui arrivent via RP. Il envoie un message d'élagage PIM (S,G) Prune qui est propagé de routeur en routeur vers le RP. Dans chaque routeur rencontré ce message place un état indiquant que le trafic multicast (S,G) ne doit plus être propagé sur l'arbre partagé. L ensemble des étapes de configuration de PIM-SM sont résumés dans des schémas explicatifs en annexe 6. 15

16 Nous avons donc trois solutions permettant le routage multicast en IPv6. Ces solutions suivent les deux modèles de diffusion : ASM (Any Source Multicast) et SSM (Source Specific Multicast). Alors que le modèle ASM interdomaine était implémenté par MSDP en IPv4, la solution qui semble privilégiée aujourd'hui est embedded-rp. Pour le modèle SSM, l'utilisation du protocole MLDv2 (non supporter par tous les constructeurs) est indispensable afin d utiliser PIM-SSM. Le protocole PIM-SM fonctionne bien dans un domaine restreint, mais devient plus compliqué en interdomaine surtout pour des raisons d'indépendance des domaines. En effet, si techniquement son implémentation ne pose pas de problème, il est difficilement imaginable, que chaque AS créé des entrées sur ses routeurs pointant vers des RP situés dans d autres domaines. La solution retenue en IPv4 était le protocole MSDP qui permettait l échange d informations (source Xcast, groupe de diffusion) entre RP de différents AS. Mais ce protocole compliqué n a pas été migré en IPv6. En résumé, deux solutions interdomaines sont retenues Embedded RP pour le modèle ASM (aucune configuration particulière sur les routeurs de chaque AS) PIM-SSM pour le modèle SSM (en cours de développement, nécessite de supporter MLDv2 pour les équipements) Enfin, tout comme dans l unicast, un protocole d échange des routes doit être mis en place pour le multicast. Il s agit de MBGP. BGP (Border Gateway Protocol) est le protocole de routage externe entre les différents AS. BGP devient extensible en introduisant la notion de famille d adresse (ex. IPv4, IPv6, ) et de sous-famille d adresse (ex. multicast, unicast ) d ou son nom MBGP pour Multiprotocol Border Gateway Protocol. Ce protocole permet donc l'échange des routes multicast entre deux routeurs d AS différents PIM Embedded RP PIM Embedded RP est apparu en de l'absence de MSDP, car la construction de l'arbre multicast avec PIM-SM nécessite que tous les routeurs PIM soient configurés avec le même ensemble de RP. Un groupe doit correspondre à un seul RP dans tous les AS concernés. La solution retenue : embarquer l adresse de la source multicast dans l adresse de diffusion du groupe. Cela nécessite : De parvenir à construire une adresse de diffusion de 128 bits qui soit en mesure d embarquer une adresse unicast de 128 bits (décrit dans la partie adressage Ipv6) Que tous les routeurs traversés soit en mesure d extraire l adresse du RP La notion de domaine PIM, que l on associe à un RP, n existe alors plus vraiment car les routeurs traversés n ayant plus besoin de connaître à l avance le RP du groupe multicast, ils sont maintenant indépendants des AS auxquels ils appartiennent. 16

17 PIM-SSM Le modèle SSM, implémenté par PIM-SSM constitue un sous-ensemble du modèle ASM. En effet, il a été créé à l origine pour répondre aux problèmes de l'interdomaine ASM. Au niveau du protocole PIM-SSM, il n'y a aucune disposition à prendre pour permettre à ce protocole de fonctionner entre plusieurs domaines. Les messages PIM(S,G)Join sont acheminés de routeur en routeur entre les DR des récepteurs et les sources spécifiées par les récepteurs. Peu importe donc que les sources soient dans le même domaine que les récepteurs. Le problème du déploiement du protocole PIM-SSM sur plusieurs domaines se situera donc au niveau du routage. Dans un premier temps, MLDv2 (non-implémenter par tous les constructeur) permet à un récepteur de spécifier le groupe auquel il veut s'abonner ainsi qu'un ensemble de sources pour ce groupe. Par conséquent, il n est dans ce cas pas nécessaire de déterminer un RP puisque les sources sont connues à l'avance par les destinataires. Prenons l'exemple d'une station qui s'abonne au groupe en indiquant son intérêt pour les sources et uniquement. Le DR du récepteur peut envoyer directement des messages PIM(S1,G)Join vers S1 et PIM(S2,G)Join vers S2 et joindre ainsi les 2 arbres par la source associés. PIM-SSM ne définit aucun nouveau message, c'est un sous-ensemble de PIM Sparse-Mode. Cependant, des adresses multicast dédiées pour PIM-SSM doivent être utilisées. Ce sont des adresses dérivées du préfixe FF3X::/96. 17

18 4. EMULATION SOUS CLOWNIX Afin de tester les différents protocole nous souhaitons virtualiser l ensemble de la topologie. Cela se fera grâce à Clownix. Clownix est un outil basé sur UML (User Mode Linux) qui permet d émuler un réseau de machines Unix et de routeurs Cisco. UML est un noyau Linux compilé qui peut être exécuté dans l'espace utilisateur comme un simple programme. Il permet donc d'avoir plusieurs systèmes d'exploitation virtuels sur une seule machine physique hôte exécutant Linux. Le gros avantage de ce type de configuration, est que l on peut facilement modifier un noyau linux et le tester, sans mettre en danger le système réel étant donner qu il s exécute sur un processeur virtuel. Les routeurs Cisco sont eux émuler grâce à dynamips. Dynamips est une application Linux permettant de virtualiser un équipement de la marque et de charger un IOS. IOS Cisco Dynamips IOS Cisco Dynamips OS Linux OS Linux OS Linux UML UML UML OS Unix Matériel Figure 13 - User Mode Linux 18

19 L exemple présenté ci-dessous est là seulement pour montrer la manière de monter une topologie simple sous Clownix. Le réseau ainsi construit n est pas en rapport (même si il peut être réutiliser) avec la notion de multicast IPv6. La présentation de cette exemple décompose les différentes étapes de création d une plate-forme. 1. Création du dossier racine Dans le répertoire /home/thales/clownix/uml_clownix_net_05/virtual_platform_configs/ On créer un dossier qui contiendra tous les fichiers en relation avec notre configuration. Dans ce dossier, chaque équipement est caractérisé dans un sousdossier qui lui est propre (son nom est important). De plus on retrouvera un fichier «config_simu_net» qui permettra la configuration de l'ensemble de la topologie par Clownix. On aura dans notre cas l'organisation suivante : Figure 14 - Organisation de la plate-forme Clownix NB : le dossier 'all_virtual_machine' servira à regrouper tous les fichiers communs à chaque machines linux. On y retrouvera par exemple toutes les applications de test que nous utiliserons ultérieurement. 19

20 2. Fichier 'config_simu_net' ############################################################################# # SIMULATED NETWORK START CONFIG # ############################################################################# ############################################################################# # WORKING DIRECTORIES USED ON HOST: # # # UmlWorkZone /tmp/uml_clownix_virtual_net UmlSynchroStarter /tmp/uml_clownix_virtual_net/uml_synchro_starter UmlCowPrefix /tmp/uml_clownix_virtual_net/uml_cow/machine UmlSwitch /tmp/uml_clownix_virtual_net/uml_switch UmlSwitchSig /tmp/uml_clownix_virtual_net/uml_switch/sig UmlDataPrefix /tmp/uml_clownix_virtual_net/uml_switch/data UmlCiscoSwitchSig /tmp/uml_clownix_virtual_net/uml_switch/ciscosig UmlCiscoDataPrefix /tmp/uml_clownix_virtual_net/uml_switch/ciscodata UmlDataVm machine UmlDataIf eth UmlCtrlPort 4567 UmlDotPort 4568 # # ############################################################################# # ADMIN. NETWORK USED TO CONFIGURE VIRTUAL MACHINES # # # HostAdmin # # ############################################################################# # VIRTUAL MACHINES # # VMSPY MACHINE1 (0001) VMSPY MACHINE2 (0007) # ############################################################################# # VIRTUAL CISCOS # # CISCO CISCO1 (0001) (0002) CISCO CISCO2 (0002) (0003) CISCO CISCO3 (0003) (0004) CISCO CISCO4 (0004) (0005) CISCO CISCO5 (0005) (0006) CISCO CISCO6 (0006) (0007) # ############################################################################# # TAP # # TAP (0001,0002,0003,0004,0005,0006,0007) Figure 15 - Fichier de configuration ''config_simu_net' 20

21 Il s'agit des paramètres permettant notamment la déclaration des équipements virtuels que nous souhaitons implémenter. Dans notre cas nous laisserons tous les paramètres de fonctionnement en 'defaut', nous allons plutôt nous attarder sur la déclaration des machines et des routeurs Cisco. La déclaration de chaque machine virtuelle linux se fait dans la partie «VIRTUAL MACHINES» en mettant bout-à-bout les paramètres suivants : VMSPY --> paramètre décrivant une machine Linux MACHINE1 --> déclaration de son nom qui est en réalité le nom du dossier précédemment créé (0001) --> déclaration du lien logique relié à sa première interface La déclaration des routeurs Cisco se fera de la même manière, on utilise le paramètre CISCO pour spécifier qu'il s'agit d'un routeur de la marque, puis on indique le nom de l'équipement correspondant au nom du dossier. Enfin on attribue un lien logique à chaque interface. Par exemple pour le routeur «CISCO2», son interface eth1/0 est connectée au lien logique 0004 et son interface eth1/1 au lien De cette manière, Clownix voit que l'interface eth1/2 du routeur «CISCO» et l'interface eth1/0 du routeur «CISCO2» sont sur le même lien logique (0004). Il est ainsi en mesure de comprendre que nous souhaitons virtuellement câbler ces deux interfaces. Enfin, la partie «TAP» correspond à un lien d'administration que nous créons vers tous les équipements. Il permettra par exemple d'ouvrir directement une session ssh ou telnet pour chaque machine via notre station physique. 3. Running Config Cisco Nous devons pré-paramétrer nos routeurs Cisco en préparant à l'avance un fichier de «running configuration» customisé, qui sera placé dans le répertoire de l'équipement, et qui sera lu au démarrage de l'ios du routeur. Cela permettra notamment la déclaration des adresses IP des interfaces, et ainsi la prise en main de l'équipement via telnet. NB : Certains paramètres tel que «ipv6 unicast-routing» ou encore «ipv6 multicastrouting» ne peuvent être placé dans le fichier de running config car un bug fait qu'ils font planter l'ios au démarrage. 4. Startup des machines Linux Les dossiers de nos machines virtuelles peuvent être associés à la racine de l'os une fois chargé. Nous devons créer un script shell qui attribuera une adresse IP à l'interface réseau de notre machine. Dans ce sens, nous créons un sous-dossier root dans lequel on placera le script shell. De plus, comme nous serons amenés à utiliser un programme en C, il est tout à fait possible de le placer dans un répertoire /bin/ qui sera également automatiquement charger au démarrage de l'os. 21

22 5. all_virtual_machine Ce dossier permet de placer des paramètres/fichiers communs à toutes les machines virtuelles qui nous allons monter. Si par exemple un même programme sera utilisé sur plusieurs de nos machines, il est plus judicieux de ne le copier qu'une seule fois, dans un répertoire /bin/ de ce dossier. 1. Démarrer Clownix Il faut pour cela lancé le script start_uml_clownix avec en paramètre le nom du dossier de notre plate-forme virtuelle:./home/thales/clownix/uml_clownix_net_05/start_uml_clownix 2C3M_V6 Les équipements seront activés les uns après les autres, jusqu'à apparition de l'interface graphique du logiciel : 2. Quitter l application Il est dans un premier temps nécessaire d arrêter le deamon «linux» grâce à la commande : #Pkill linux Ensuite nous pouvons fermer chaque machine virtuelle, Pour les routeurs Cisco : < alt gr > + < ctrl > + < ) > < q > < ctrl > + < c > Pour les machines linux < ctrl > + < c 22

23 5. CONFIGURATION SUR ROUTEUR CISCO Compatibilité, déclaration, et routage unicast Cisco a mis IPv6 dans ses équipements en version expérimentale depuis plusieurs années. Le code est disponible pour tous et maintenu depuis la release Pour mettre en œuvre IPv6 sur un routeur Cisco, la première étape consiste à installer une version d'ios qui supporte cette fonctionnalité. Un show running-config nous permet de connaître la version d'ios embarqué: #sh run Building configuration... Current configuration : 5692 bytes version 12.2 A partir de maintenant on peut activer le routage unicast et multicast IPv6 sur le matériel: >conf t #ipv6 unicast-routing #ipv6 multicast-routing Nous devons ensuite configurer indépendamment chaque interface à la manière de cet extrait de fichier de configuration: interface Ethernet1/1 mac-address ip address duplex half ipv6 enable ipv6 address 2001:1:2::/64 eui-64 ipv6 nd prefix 2001:1:2::/ onlink autoconfig L'interface eth1/1 de notre routeur possédait déjà un adresse IPv4. La directive "ipv6 enable" active sur l'interface le traitement de paquets IPv6. La commande suivante affecte à cette interface une adresse IPv6 dont la partie identifiant d'interface est générée automatiquement à partir de l'adresse MAC. La dernière directive provoque l'annonce du préfixe "2001:1:2::/64" sur le segment Ethernet et permet la configuration automatique en IPv6 des interfaces de postes de travail qui bootent sur ce segment Ethernet. 23

24 Il est nécessaire de spécifier au routeur de laisser passer les datagrammes IPv6 unicast et multicast. Cela se fait grâce aux commandes suivantes : >conf t #ipv6 unicast-routing #ipv6 multicast-routing Il peut être intéressant dans notre cas de figure d'activer le protocole de routage RIP (ce dernier ayant été adapté à IPv6). Pour rappel, ce protocole permettra à chaque routeur de connaître les réseaux qui ne lui sont pas directement recorder. Cela est rendu possible grâce à un algorithme d échange de tables de routage contenant la liste des réseaux voisins. Pour cela, la première étape est d'activer le protocole sur le routeur: >conf t #ipv6 router rip choucroute Le protocole RIP sera identifié sous le non de session "choucroute". On peut ensuite activer RIP sur les interfaces concernées: >conf t #interface Ethernet1/X #ipv6 rip choucroute enable #exit 24

25 Activation du routage multicast IPv PIM-SM L utilisation de PIM-SM, sur un routeur de la marque Cisco, se fait au travers de la déclaration des Rendez-Vous Point, sur chaque routeur participant au réseau. De cette manière, ils seront tous en mesure de faire transiter les paquets jusqu au point de rendez-vous. Deux manières pour déclarer un RP, soit d une façon statique sur chaque routeur, soit via une élection dynamique. Configuration statique du RP >conf t #ipv6 pim rp-address <@IPv6_Loo_RP> Avec en paramètre l adresse IPv6 du routeur désigné comme Rendez-vous Point. Sur ce point, il est conseillé d utiliser une adresse de LoopBack, ce qui permettrai de palier à un éventuel disfonctionnement d une interface, en reroutant les paquets via une autre interface. Configuration dynamique >conf t #ipv6 pim bsr candidate bsr <@IPv6_Loo_local> #ipv6 pim bsr candidate rp <@IPv6_Loo_local> Dans un domaine PIM, des routeurs sont configurés comme candidats BSR, il est recommandé que les candidats BSR soient identiques aux candidats RP, tout en sachant que il est possible de paramétrer des niveaux de priorité Autres protocoles Rien ne nous contraint à n utiliser que PIM-SM en intra-domaine. Il est tout à fait possible d implémenter Embedded-RP ou encore PIM-SSM. Mais ces deux protocoles étant destinés avant tout à une utilisation inter-domaine, leur utilisation ne sera pas présenter dans cette partie. 25

26 Portée de diffusion d un flux multicast L adressage multicast propose de définir un scope de diffusion. Ce dernier permet de cloisonner un flux multicast au sein d un réseau pré-défini. Pour rappel, le scope se choisi via les bits 13 à 16, en donnant à cet ensemble l une des valeurs suivantes : 1 - node-local 2 - link-local 3 - subnet-local 4 - admin-local 5 - site-local 8 - organisation-local E - global Nativement, la notion de portée du scope est très flou. On peu facilement l imaginer, mais en pratique, sans aucun réglage préalable, la différence de portée ne se distingue qu en 2 groupes Valeurs de scope 1 - node-local 2 - link-local Portée native Ne passe pas un routeur, diffusion restreinte à un lien (passe un switch) 3 - subnet-local 4 - admin-local 5 - site-local 8 - organisation-local E global Pas de contrainte de portée. Passe tous les routeurs, intra et inter-domaine Une commande Cisco permet de configurer, et de limiter la portée de diffusion de nos flux multicast. Chaque interface doit être configurer afin de se voir indiquer une limite de scope : >conf t #interface <interface_name> #ipv6 multicast boundary scope <scope-value> De cette manière, un datagramme multicast ne passera cette interface, que si la valeur du scope de l adresse de diffusion est supérieur à la valeur configurée. 26

27 Nous souhaitons joindre deux AS afin qu ils soient en mesure de transmettre un flux multicast de l un à l autre. Pour cela, nous utiliserons donc MBGP. Comme dit précédemment, ce protocole permet de créer une table de routage multicast via les réseaux déclarés sur la machine, plus les réseaux appri grâce aux voisins ebgp et ibgp. Attention cependant : jusqu à maintenant, PIM s appuyait sur les tables de routage unicast car le réseau était dit «conguent», c est-à-dire qu il n y avait pas de chemins spécifiques pour les paquets multicast, ils empruntaient les mêmes routes que les paquets unicast. Or maintenant la traversée inter-as implique l utilisation de tables de routage multicast. Si nous déclarons dans MBGP, les routes directement connectées au routeur de bordure, il n aura pas connaissance de celles situées plus loin dans le réseau. Pour palier à cela, nous déclarerons des sessions MBGP sur tous les routeurs intra-as Déclaration des AS et des réseaux voisins Routeur de Bordure (session ebgp + mbgp) Nous allons dans un premier temps déclarer un session BGP sur les routeurs de chaque AS participant au routage inter-as : >conf t #router bgp 1 #no bgp default ipv4-unicast #bgp router-id <@IPv6_Loo_local>_ Nous avons donc sur la première ligne, la déclaration de la session bgp suivie du numero d AS (ici 1), la seconde ligne indique qu aucun paquet IPv4 ne sera traité, enfin la troisième ligne est l identifiant de notre routeur. Il est conseillé pour cet identifiant de choisir l adresse de LoopBack du routeur. Nous déclarons ensuite les voisins BGP, il s agit du voisin situé sur l autre AS, mais également de tous les routeurs internes à l AS pourvu d une session ibgp. En effet, notre réseau BGP étant «full mesh», tous les routeurs sont dits «voisins» même si ils ne sont pas sur le même lien physique. #neighbor <@_IPv6_Loo_dist> remote-as <AS> Encore une fois nous utiliserons les adresses de LoopBack des routeurs, pour éviter une éventuelle panne si l interface utiliser venait à tomber. Ensuite nous déclarons le numéro d AS distant. Cette ligne est à répéter autant de fois qu il y a de «voisins» BGP. 27

28 Le routeur fera ensuite, lui-même, la distinction entre les sessions ebgp et ibgp en comparant le numéro d AS entré avec son propre numéro d AS. NB : attention à bien déclarer les adresses de LoopBack utilisées dans les protocoles de routage intra-as. Dernière étape : déclaration des sous-familles d adresses, et activation des voisins pour ces différentes sous-familles : #address-family ipv6 unicast #neighbor <@_IPv6_Loo_dist> activate #network <Prefix_IPv6> #exit #address-family ipv6 multicast #neighbor <@_IPv6_Loo_dist> activate #network <Prefix_IPv6> Ici encore les voisins seront tous activés dans chacune des deux sous-familles, suivi de tous les réseaux directement connectés. NB : attention à bien déclarer les adresses de LoopBack utilisées dans les réseaux connus Routeurs internes (session ibgp + mbgp) Nous allons maintenant déclarer les sessions ibgp sur tous les routeurs internes aux AS. Pour cela nous reprenons les commandes précédemment utilisées : >conf t #router bgp 1 #no bgp default ipv4-unicast #bgp router-id <@IPv6_Loo_local>_ #neighbor <@_IPv6_Loo_dist> remote-as <AS> #address-family ipv6 unicast #neighbor <@_IPv6_Loo_dist> activate #neighbor <@_IPv6_Loo_dist> next-hop-self #network <Prefix_IPv6> #exit #address-family ipv6 multicast #neighbor <@_IPv6_Loo_dist> activate #neighbor <@_IPv6_Loo_dist> next-hop-self #network <Prefix_IPv6> Nous déclarons donc dans un premier temps tous les voisins ayant le même numéro d AS, puis, comme pour le routeur de bordure, nous activons les voisins pour les sous-familles d adresses concernées ainsi que les réseaux directement connectés. Attention cependant, il est, pour ces routeurs, indispensable de déclarer le champ «next-hop-self» pour tous les voisins. En effet, lorsque les routes apprises par ebgp sont transmises aux routeurs voisins via ibgp, le next hop n est pas modifié. De ce fait, ces routeurs se retrouvent avec des next hop qu ils ne connaissent pas. 28

29 Activation du routage multicast Ipv Embedded-RP PIM embedded permet (indirectement) de ne pas avoir à déclarer le RP sur chaque routeur participant au réseau. L'adresse du RP étant incluse dans l'adresse de diffusion multicast. Chaque routeur recevant un datagramme Ipv6, repère le champ lui indiquant qu'il s'agit d'une adresse Embedded dérivée d'une adresse unicast, et qui plus est, de l'adresse du Rendez-vous Point. Ils seront ensuite en mesure de faire suivre le datagramme. Pour cela nous déclarons l'interface de LoopBack 2001::3) d'un des routeurs comme étant le RP : >conf t #ipv6 pim rp-address 2001::3 rpemb Puis il est nécessaire de déclarer une ACL sur le routeur qui autorisera le trafic multicast : #ipv6 access-list rpemb #permit ipv6 any ff7e:140:2001:0:1:3::/ PIM-SSM Au niveau du protocole PIM-SSM, il n'y a aucune disposition à prendre pour permettre à ce protocole de fonctionner entre plusieurs domaines. Car comme expliqué précédemment, on embarque l adresse de la source que l on veut écouter en paramètre. Les clients n ont donc pas besoin de ce référer à un Rendez-vous Point pour recevoir le flux multicast. 29

30 6. CONFIGURATION SUR ROUTEURS LINUX Il existe d autres alternatives aux routeurs Cisco souvent très coûteux. La solutions la plus souvent plébiscitée est basé sur un OS Linux. Au travers de cet OS, il est en effet tout à fait possible d implémenter différentes applications qui offrirons les mêmes services qu un IOS Cisco. Deux écoles se démarquent : Zebra et Xorp. La première application étant la plus utilisée, mais toutes les deux sont théoriquement en mesure de supporter les plus grands protocoles : Unicast RIP v2 en IPv4, ng en IPv6 BPG en IPv4 et IPv6 OSPF v2 et V3 en IPv4 et IPv6 Multicast PIM-SM IPv4 et IPv6 IGMP v1,v2,v3 en IPv4 MLD v1 et v2 en IPv6 RFC QUAGGA XORP CISCO Type du logiciel IOS-Like JunOS-Like Cisco IOS Opensource OUI OUI NON Routage statique - OUI OUI OUI IPv4/IPv6 791/2460 OUI OUI OUI RIPv OUI OUI OUI OSPFv OUI OUI OUI BGPv4 1771/4271 OUI OUI OUI NAT 2766 NON/Linux OUI OUI MLD 2710 OUI OUI OUI IGMP 2236 OUI OUI OUI PIM 2362 OUI OUI OUI VRRP 3768 NON/Linux OUI OUI Access lists OUI OUI OUI Route maps OUI OUI OUI VPN IPSec 4301 NON/Linux OUI OUI VPN SSL 4301 NON/Linux (2) NON/Linux (2) OUI FTP client 959 NON/Linux OUI OUI TFTP client 1350 NON OUI OUI Telnet serveur 854 OUI (1) OUI OUI SSH serveur 4251 NON/Linux OUI OUI/NON HTTP serveur NON OUI OUI DHCP serveur 2131 NON/Linux OUI OUI NTP serveur 1305 NON/Linux NON OUI/NON NTP client 1305 NON/Linux OUI OUI SNMP 3412/1157 OUI (2) OUI OUI 30

31 Quagga est une application libre proposant des fonction de routage avancé. Chaque protocole de routage est supporté par un processus, et dialogue avec un processus maître (zebra) qui, lui, est chargé de gérer la table de routage de la machine en fonction des informations que lui transmettent les processus correspondants aux protocoles activés. Chaque protocole peut être paramétré en éditant un fichier de configuration spécifique ou via un telnet sur un port associé. L'interface de commande et de configuration est calquée sur celle de l'ios de Cisco. De plus ce logiciel est architecturé de façon très modulaire à l image de la figure suivante : Figure 16 - Zebra Afin d utiliser zebra et les autres processus qui en découlent, il est possible de les invoquer au travers d une commande ou de les placer dans le fichier startup de la machine. Pour cela, on rajoute (à titre d exemple) les lignes suivantes : zebra d f /etc/zebra.conf ospd6d d f /etc/ospf6d.conf mrd D f /etc/mrd.conf bgpd d f /etc/bgpd.conf 31

32 La prise en main via telnet de zebra et des autres processus se fera grâce aux commandes suivantes : telnet localhost 2601 telnet localhost 2602 telnet localhost 2603 telnet localhost 2604 telnet localhost 2605 telnet localhost 2606 Zebra RIP RIPngd OSPF BGPD OSPF6d Quagga se voulant calqué sur l IOS de Cisco, la configuration des protocoles de routage unicast et multicast se fera donc de manière très similaire pour ne pas dire identique. A la différence près, qu au lieu de retrouver toutes les configuration dans un seul et même fichier de running_config, on a plusieurs fichiers indiquant les paramètres de chaque protocoles. Pour cette raison, la configuration de Quagga ne sera pas détaillé. Il n y a pas de commandes supplémentaires. Pour des raisons probablement induite par l utilisation d un environnement virtuel, nous ne sommes pas parvenu à implémenter une liaison inter-domaine (ebgp) entre deux routeurs Quagga. 32