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

33 La ligne de commande de Xorp est appelée xorpsh pour xorp shell. Cette interface ressemble à celle du système d'exploitation de Juniper mais est très différente de celle de Cisco et de son fameux IOS (une comparaison des commandes se trouve en annexe). Une interface web efficace est disponible de plus, les protocoles telnet et ssh (secure shell) peuvent aussi être utilisés pour accéder à Xorp. Le routeur Xorp reste moins puissant lorsqu'il est comparé à des produits commerciaux. Il ne possède pas nativement la richesse des fonctionnalités d'un routeur Cisco et la puissance de sa plate-forme. Fort heureusement, cela n'est pas un problème parce que seules quelques fonctionnalités déjà supportés par Xorp sont vraiment utilisées pour faire tourner un routeur. Par ailleurs, des packages sont disponibles pour rajoutés des fonctionnalités comme par exemple, le support de CDP (Cisco Discovery Protocol). Certains testeurs mettent en garde dans l utilisation de BGP en raisons de bugs critiques lors de la redistribution de OSPF vers BGP Installation et configuration initiale L insatallation de xorp peut se faire de deux manières, soit via les dépôts officiels, soit en téléchargeant l archive source sur le site de l éditeur. Nous choisirons donc bien sur la deuxième solution. Afin de garder toute possibilité de retour en arrière, j ai choisi d installer Xorp dans un premier temps, directement sur une machine virtuelle. Ce test ayant été réaliser avec succès, j ai ensuite installer l application dans l image root_fs de Clownix de la même manière que Net_Telnet et Net_Telnet_Cisco (procédure d installation décrite dans la partie test Cisco). NB : L utilisation du xorp shell se fera en étant loggé sous un user nommé xorp appartenant à un groupe également nommé xorp. Cela se fera grâce aux commandes suivantes : #groupadd xorp #useradd xorp g xorp 33

34 La configuration de Xorp se fera exclusivement via un unique fichier nommé config.boot se trouvant dans le répertoire xorp/rtrmgr. Dans notre cas, ce fichier n existait pas et a dû être créé. C est ce fichier qui sera éditer lors de l utilisation du xorp shell. Ce fichier de configuration fonctionne grâce à une arborescence qui permet de ne déclarer les différents services souhaités. J ai donc choisi dans cette configuration initiale, de ne déclarer que les interfaces et leurs assigner une adresse IPv6. Etant donné que nous travaillons uniquement en environnement émulé, l interface eth0 de chaque équipement est toujours configuré automatiquement par Clownix. Il existe pour cela une commande permettant de n utiliser que les paramètres système pour une interface donnée (dans notre cas eth0). La déclaration des interfaces se fera donc de la manière suivante : interfaces { interface eth0 { disable: false discard: false default-system-config interface eth1 { disable: false discard: false vif eth1 { disable: false address 2001:1:2::1 { prefix-length: 64 disable: false address fe80::ff:fe04:1 { prefix-length: 64 disable: false Attention cependant, l utilisation de certains protocoles (tel que OSPF6) nécessite d avoir une adresse de type lien-local. Raison pour laquelle deux adresses IPv6 sont assignées à l interface eth1. Cette adresse doit obligatoirement commencer par le préfix fe80::/16 et dans notre cas, elle est suivi par un ID dérivé de l adresse MAC de l interface réseau (CF : partie adressage IPv6). Il ne reste plus qu à activer xorp de la manière suivante : Puis accèdeer au shell (CLI) de xorp : #su xorp./xorpsh #sudo./xorp_rtrmgr 34

35 Routage intra-as La première étape est d activer le routage IPv6 sur le routeur. Pour cela on ajoute les commandes suivantes dans le fichier config.boot : fea { unicast-forwarding4 { disable: false unicast-forwarding6 { disable: false NB : cette étape peut être automatiquement induite par la déclaration d un protocole de routage tel que RIPng ou OSPF6. Nous allons ensuite implémenter une protocole de routage. Dans notre cas, il s agit de OSPF6 (6 pour IPv6) Protocols { ospf6 0 { router-id: ip-router-alert: false area { area-type: "normal" interface eth1 { link-type: "broadcast" vif eth1 { priority: 128 hello-interval: 10 router-deadinterval: 40 interface-cost: 1 retransmitinterval: 5 transit-delay: 1 passive: false disable: false NB : le champ router-id est obligatoirement suivi d une adresse Ipv4 35

36 Routage inter-as Le routage inter-domaine xorp suit la même philosophie que chez Cisco, ne seront donc présenté ci-dessous, que les différences notables en terme de déclaration du protocole. protocols { bgp { bgp-id: local-as: "1" enable-4byte-as-numbers: false peer "2001:3::1" { peer-port: 179 local-port: 179 local-ip: "2001:3::2" as: "2" next-hop: next-hop6: 2001:3::2 holdtime: 90 delay-open-time: 0 client: false confederation-member: false disable: false ipv4-unicast: true ipv4-multicast: false ipv6-unicast: true ipv6-multicast: false import: "" export: "" import: "impbgp" export: "expbgp" Les paramètres qui suivent la déclaration de bgp sont les paramètres «locaux», c est à dire propre à notre routeur. On retrouve l ID du routeur (là aussi obligatoirement une adresse IPv4), notre numéro d AS, nos voisins Les paramètres suivant le champs peer seront envoyés à notre voisin. NB : les champs entre guillemet ne seront pas envoyés, se sont des données traités par notre routeur. 36

37 Le champs next-hop6 est le prochain saut que le routeur voisin devra mettre dans sa table de routage pour les routes que nous lui apprenons. Il s agit donc de notre interface ebgp. Le champ next-hop ne devrais pas avoir lieu en IPv6 mais, Xorp rend sa déclaration obligatoire. Le plus judicieux est d utiliser une adresse de LoopBack ipv4 de notre routeur. Xorp exige également la déclaration de politique de routage pour l utilisation de BGP. L exécution de BGP peut être faite sans politique préalablement configurée, mais même si la connexion BGP se fait bien, aucune route ne sera échangée. Dans l exemple ci-dessus, les champs import et export se voient respectivement attribués les politiques impbgp et expbgp. Ces dernières sont déclarées de la manière suivante : policy { policy-statement expbgp { term 100 { from { protocol: "bgp" policy-statement impbgp { term 100 { from { as-path: "2" then { accept { On va donc dans notre cas, exporter des routes apprise par le protocole BGP et importer (dans BGP) des routes provenant de l AS 2. 37

38 Routage multicast IPv6 Un routeur multicast doit avoir une table de routage multicast (distinct de la table unicast). Pour cela il est indispensable de déclarer et de configurer mfea. Typiquement le routeur permettra les inscriptions à un flux multicast grâce à IGMP ou MLD pour IPv6. Le plus souvent, PIM-SM est le protocole de routage multicast implémenté. Enfin xorp peut nécessiter l utilisation du module fib2mrib permettant notamment de palier à une table de routage unicast inexistante. Nous allons donc déclarer quatre modules afin de permettre le routage multicast. L utilisation de Xorp pour le routage de flux multicast est théoriquement possible. Mais un bug rencontré dans notre environnement de virtuallisation nous a empêché de valider son bon fonctionnement. Toutes les étapes décrites ci-dessous n ont donc pas été techniquement validées Mfea6 Ce module va tout simplement autoriser le routage multicast Ipv6 sur les interfaces déclarées. plumbing { mfea6 { disable: false interface eth1 { vif eth1 { disable: false interface eth2 { vif eth2 { disable: false 38

39 MLD MLD est le protocole permettant à un utilisateur de s inscrire à un flux multicast. Sa déclaration se fait de la manière suivante : protocols { mld { disable: false interface eth1 { vif eth1 { disable: false interface eth2 { vif eth2 { disable: false fib2mrib Le Module Fib2mrib est utilisé pour obtenir la «Forwarding information Base», c est à dire la table de routage multicast qui sera alors basé sur les information obtenue via les protocoles de routage uniscast. Ces informations seront ensuite réutilisées par des protocoles tel que PIM-SM. protocols { fib2mrib { disable: false 39

40 PIMSM6 PIM-SM peut être configurer dans xorp afin de permettre le routage Multicast au sein d un domaine PIM-SM. Aucune différences majeur par rapport à une déclaration similaire dans l IOS de Cisco. A noter cependant, qu il est indispensable de configurer une interface virtuelle register_vif afin de permettre le bon fonctionnement de PIM-SM. De plus cette interface doit être présente dans mfea6. protocols { pimsm6 { disable: false interface eth1 { vif eth1 { disable: false interface eth2 { vif eth2 { disable: false interface register_vif { vif register_vif { disable: false Nous avons ensuite deux possibilités pour le choix du RP. Soit une configuration static sur chaque routeur : protocols { pimsm6 { static-rps { rp 2001:DB8:50:50:50:50:50:50 { group-prefix ff00::/8 { Cette dernière doit être identique sur tous les routeurs participants au domaine PIM. De plus, il est possible de préciser le préfix concerné par point de rendez-vous. Dans notre cas nous avons un préfix à : ff00::/8 ce qui signifie que ce RP concerne tous les flux multicast IPv6 de notre réseau. 40

41 Enfin, il est possible de mettre en place un mécanisme de Bootstrap, ce dernier permettant l élection d un Point de Rendez-Vous. protocols { pimsm6 { bootstrap { disable: false cand-bsr { scope-zone ff00::/8 { cand-bsr-by-vif-name: "eth1" cand-rp { group-prefix ff00::/8 { cand-rp-by-vif-name: "eth1" Comme précisé précédemment, afin de permettre le bon fonctionnement du module d élection automatique de RP, il est indispensable de configurer une interface virtuelle register_vif PIM-SSM et Embedded-RP L utilisation de ces protocoles ne nécessite pas de configuration particulière, seulement de configurer un RP pour le mode SSM. Ces protocoles fonctionneront ensuite de la même manière que sur un IOS Cisco. 41

42 ASPECT SECURITE Lors de la configuration des routeurs on veut se prémunir De routeurs intrus (identification de ses voisins) D informations fausses ou erronées (filtrage d annonces) o Mauvaise route par défaut o Erreurs de paramétrage Authentification MD5 des voisins Tout comme Cisco, zebra propose l implémentation d un hachage MD5 d une clé prépartagé entre deux routeurs afin de permettre leur authentification mutuelle (avant l échange de routes via un prtotocole de routage tel que RIP) Possibilité de gérer plusieurs clés Intervalle de validité d'une clé (émission et réception) / \ L authentification fonctionne parfaitement en IPv4 mais n est seulement qu en cours d implémentation pour IPv6 Filtrage Possibilité de créer des filtres que l on applique sur une interface. o On ne retiendra que les routes dont le préfix est inclus dans le filtre. o Retenir toutes les routes, sauf celle étant incluses dans le filtres 42

43 7. TESTS DE FONCTIONNEMENT SUR RESEAU EMULE Des difficultés sont apparues lors des premières phases de test. En effet, l utilisation de Clownix pour l émulation du réseau implique l implémentation de plusieurs interfaces de communication supplémentaires sur chaque équipement. Le problème majeur étant que notre outil de test IPerf ne permettait pas de choisir l interface de sortie de notre flux multicast. Le trafic n était alors pas dirigé vers nos routeurs mais vers l interface d administration de l équipement. Pour pallier à ce problème nous avons choisi d utiliser une autre application spécialement développer pour la diffusion de flux multicast en IPv6. Cette application n a pas toutes les options de tests que propose IPerf mais a l avantage de permettre la sélection l interface de sortie. Une autre alternative était également envisageable : créer une route statique sur la machine obligeant ainsi le trafic à sortir sur une interface donnée. Mais cette solution aussi efficace soit-elle en IPv4 ne fonctionne pas en IPv6, cela étant certainement dû à une mauvaise implémentation d un protocole IPv6 sur la machine Application ASM Nos tests ASM on donc été réalisé par une application développée en C++, (le code source est disponible en Annexe) elle se décompose en deux programmes : l un est le client (client_multicast) et le second la source (source_multicast). La syntaxe est la suivante : Utilisation de l application source : #./source_multicast [ i interface] [-h hop] [ l loop] addr Il nous faut donc préciser l interface de sortie du flux multicast, le nombres de sauts de routeurs maximum, et enfin, l adresse multicast. Utilisation de l application client : #./client_multicast [ i interface] addr Dans ce cas, on ne précise que l interface de sortie et l adresse multicast que l on veut écouter. Il ne reste alors plus qu à envoyer des informations (caractères) via l application sources. A l affichage de ces dernières sur le client, le fonctionnement de l ensemble de la topologie est validée. 43

44 Applications SSM Deux applications ont été testés afin de valider le bon fonctionnement du modèle SSM. Une première application ssmping permettra l envoie de séquence de ping multicast, une seconde application dtms & dtmc permettra à la source d envoyer la date et l heure en multicast Ssmping Ssmping est une application basé sur un modèle client-serveur. Un client (nommé ssmping) va envoyé une requête ping unicast au serveur (nommé ssmpingd), ce dernier va lui répondre en envoyant une série de paquets multicast et unicast. Le serveur sera exécute grâce à la commande ssmpingd. Le client sera exécuté lui en utilisant la commande ssmping suivi de l adresse unicast du serveur : $ ssmping 2001:2:4::2 ssmping joined (S,G) = (2001:2:4::2,ff3e::4321:1234) pinging S from 2001:1:2::1 unicast from 2001:2:4::2, seq=0 dist=20 time= ms unicast from 2001:2:4::2, seq=1 dist=20 time= ms unicast from 2001:2:4::2, seq=2 dist=20 time= ms multicast from 2001:2:4::2, seq=2 dist=12 time= ms unicast from 2001:2:4::2, seq=3 dist=20 time= ms multicast from 2001:2:4::2, seq=3 dist=12 time= ms unicast from 2001:2:4::2, seq=4 dist=20 time= ms multicast from 2001:2:4::2, seq=4 dist=12 time= ms :2:4::2 ssmping statistics packets transmitted, time 4744 ms unicast: 5 packets received, 0% packet loss rtt min/avg/max/std-dev = /57.963/62.466/2.296 ms multicast: 3 packets received, 40% packet loss 0% loss since first multicast packet received (after 2067 ms) rtt min/avg/max/std-dev = /61.372/65.706/3.077 ms $ Cette application montre bien le bon fonctionnement d une topologie voué au modèle SSM. On regrettera cependant que l on ne puisse pas modifier l adresse du flux multicast à laquelle on s abonne. En effet, cette dernière est entré en «dur» dans le code source à savoir ff3e::4321:1234. Codes source : 44

45 Dtms & dtmc Il s agit ici, toujours d une application client-serveur mais cette fois ci basé sur l envoi de la date et l heure instantané d une machine hôte. La version utilisé lors de nos tests, est une version modifié par la communauté du m6bone. Elle permet en plus d envoyer le nom de la machine hôte, ce qui nous garantira le bon confinement des informations lorsque plusieurs sources seront utilisées en même temps. Un premier hôte va exécuter le deamon serveur grâce à la commande : Machine2#./dtms ff3e:: Daytime Multicast Server. Sending... (multicast group: ff3e::123, port: 13) Le second hôte va exécuter le deamon client : Machine3#./dtmc ff3e:: :2:5:2 13 eth1 Interface: eth1 = 4 Mon Apr 30 15:32: Machine2 Mon Apr 30 15:32: Machine2 On indique l adresse multicast concerné, la source que l on souhaite écouter, le port (par defaut : 13) et l interface de sortie. Codes source : Version d origine : Version m6bone :

46 Utilisation d un script Perl Clownix permet de charger des fichiers de configuration de running config pour tous les routeurs Cisco lors de leur démarrage. Cependant, un bug apparai lorsque certaines commandes IPv6 sont chargées au démarrage. En effet des commandes comme l activation du routage multicast IPv6 «ipv6 multicastrouting» font planter le démarrage de l IOS. Cependant ces commandes fonctionnent parfaitement bien lorsqu elles sont exécutées une fois l IOS totalement chargé, et qui plus est, elles sont indispensables au bon fonctionnement de notre étude. Pour pallier à ce problème, nous avons utilisé des scripts Perl permettant d établir des sessions Telnet avec les routeurs et ainsi venir leur passer des commandes. Pour cela deux bibliothèques sont utilisées : Net_Telnet et Net_Telnet_Cisco. Ces dernières permettant justement de créer des sessions telnet avec des équipements Cisco. L utilisation de ce script se fera via l une des machine Linux que l on va virtualiser, mais avant cela, il est nécessaire d implémenter les deux bibliothèques afin de pouvoir effectuer la compilation. Pour cela il faut: Changer de répertoire Monter l'image de l'os «root_fs» dans le répertoire mnt de bulky_stuff affichage du chemin actuel Décompresser l'archive "" "#$ " "%&'()& " " ""# ")'*+&, " " ")'*+&,",-*. " # "*,'// ")"./ "0(0 46

47 Copie du nouveau dossier dans le répertoire attendu " Changement de l'emplacement de la racine system Vérification du répertoire courant changement de répertoire affichage du contenu " # "*,'//)"./ )'*+&,)'*+&,",-*.%&'()& "0(0 Effectuer l installation : )"./ # """ /# 1# "5 " 1#23 22%-5 " 1 #) " " ', # " 6 7 )# "4.&%/(/0/'89:;*;; *; " ""45 < %-"=* 6=* 2 ">">?>? ">"> ">">?>? ">"> "7 "@" A&B* "@" / #" 2CCCD E&5 47

48 * # ">"> " * # ">"> " * # "4 1 # ">">?>? " '# ">">?>? " Quitter le répertoire courant Démonter L installation est maintenant effectuée, il ne reste plus qu à exécuter le fichier depuis la machine virtuelle : "#?" Un exemple de script de configuration, utiliser lors des tests de routage intradomaine avec embedded RP, est présenté en annexe. 48

49 Tests en intra-domaine Afin de valider le bon fonctionnement de la diffusion, et de la récupération de flux multicast en intra-domaine, nous avons émulé un réseau via Clownix. Ce réseau est composé de 5 routeurs CISCO et de 3 machines Linux, ces dernières servant l une à la diffusion, et les deux autres à la récupération des flux multicast. Le cas présenté ci-dessous, se veut le plus généraliste possible, car nous devons faire attention à ne pas tomber dans l un des nombreux cas particuliers, comme par exemple le RP qui est implémenté sur l un des DR. A noté cependant que ces «cas particuliers» ont eux aussi été testés afin d en approuver le bon fonctionnement. Figure 17 - Topologie de test intra-domaine L ensemble de la configuration a été testé sous plusieurs protocoles de routage (RIP, OSPF) et sous plusieurs types de configuration multicast (PIM-SM, Embedded RP, ). De plus, les cas ou le Rendez-vous Point était attribué de manière statique, et dynamique ont été testés. 49

50 Les tests réalisés sur cette topologie n ont pas mis en évidence de problèmes techniques en lien avec l utilisation des protocoles à proprement parlé. L utilisation de PIM-SSM implique deux choses spécifiques : l utilisation de MLDv2, et l utilisation d une application spécifique pour les tests (permettant de préciser la source que l on souhaite écouter). Les IOS embarqués sur les routeurs CISCO étant en version 12.2, permettent l utilisation de MLDv2. De plus, PIM utilise dans ses phases 2 et 3 des messages PIM(S,G)JOIN, qui spécifie donc la source. Les tests réalisés ici ont balayé plusieurs types de configuration, le RP en différents points du réseau Routage intra-domaine RIP et OSPF Test des différentes techniques de création d arbre multicast dans chaque cas de figure Problèmes rencontrés : Compatibilité IPerf et Clownix Application permettant l utilisation de PIM-SSM Routage Test PIM-SM avec RP statique PIM-SM avec RP dynamique Embedded RP PIM-SSM RIP OK OK OK OK OSPF OK OK OK OK 50

51 Test en inter-domaine La plate-forme mise en place pour validé le fonctionnement du multicast IPv6 est composé de 2 AS se voyant chacune attribués 3 routeurs Cisco et une machine Linux. Les deux AS ont été configurés indépendamment, l un se voyant implémenté RIP et l autre OSPF. Les deux routeurs de bordure C3 et C4 étant liés grâce au protocole BGP. Figure 18 - Topologie de test inter-domaine Le routage inter-domaine ne pose aucune difficulté en unicast IPv6, les routes apprises par RIP et OSPF sur les différents AS sont correctement redistribuées dans BGP. Ainsi le routage d un paquet se fait correctement. En revanche l utilisation du multicast en inter-domaine nécessite l utilisation de MBGP qui est en fait une extension de BGP à différentes sous-familles protocolaires. MBGP, créé dans notre cas deux types de tables de routages : IPv6 unicast et IPv6 multicast. Or jusqu à maintenant PIM s appuyait uniquement sur les tables de routage IPv6 unicast, car notre réseau était dit «conguent», c est-à-dire que les paquets multicast n était pas cloisonnés sur des liens spécifiques, ils utilisaient les même routes que les paquets unicast. Il se pose donc un nouveau problème : comment remplire les tables de routage multicast des routeurs C3 et C4 pour leurs permettre de joindre les réseaux situés après 1 saut de routeur, dans leur AS respectif? Deux solutions ont été envisagés : dans un premiers cas, tenter de redistribuer les routes multicast sur les autres routeurs dans l AS et ainsi propager de nouvelles routes sur tous les routeurs. Mais outres les difficultés d implémentation d une telle solution, cela pose un problème d une autre nature, comment cloisonner les routes 51

52 ainsi apprises, afin de limiter l accès à certains point du réseau. La deuxième solution est de déclarer des sessions ibgp sur tout un maillage de routeur. Cela permettra une transmission de flux multicast seulement sur les liens concernés. De plus, sur un réseau de plus grande importance, la déclaration d une session ibgp sur chaque routeur est beaucoup moins coûteuse en terme de ressource et de bande passante que la redistribution de route inter-protocolaire. Test Routage MBGP sur tous les routeurs Redistribution des routes MBGP dans RIP et OSPF PIM-SM avec RP statique PIM-SM avec RP dynamique Embedded RP PIM-SSM OK OK OK OK Pas de redistribution des routes multicast Pas de redistribution des routes multicast Pas de redistribution des routes multicast Pas de redistribution des routes multicast 52

53 53

54 54

55 55

56 8. GLOSSAIRE ASM Any Source Multicast BGMP Border Gateway Multicast Protocol BGP Border Gateway Protocol BSR BootStrap Router DR Designated Router DVMRP Distance Vector Multicast Routing Protocol ICMP Internet Control Message Protocol IETF Internet Engineering Task Force IGMP Internet Group Management Protocol IGP Interior Gateway Protocol MBGP Multiprotocol Border Gateway Protocol MLD Multicast Listener Discovery MOLSR Multicast Optimized Link State Routing Protocol MOSPF Multicast Open Shortest Path First MPR Multi Point Relay MSDP Multicast Source Discovery Protocol OLSR Optimized Link State Routing Protocol OSPF Open Shortest Path First PIM Protocol Independent Multicast PIM-DM Protocol Independent Multicast Dense Mode PIM-SM Protocol Independent Multicast Sparse Mode RFC Request For Comments RIP Routing Information Protocol RP Rendez-vous Point SAFI Subsequent Address Family Identifier SMF Simplified Multicast Forwarding SSM Source Specific Multicast 56

57 9. REFERENCES Référence Date RFC 1075 Novembre 1988 RFC 1584 Mars 1994 RFC 2710 Octobre 1999 RFC 3306 Août 2002 RFC 3307 Août 2002 RFC 3810 Juin 2004 RFC 3913 Septembre 2004 RFC 3956 Novembre 2004 RFC 4291 Février 2006 RFC 4601 Août 2006 RFC 5110 Janvier 2008 RFC 5340 Juillet 2008 Titre Distance Vector Multicast Routing Protocol Multicast Extensions to OSPF Multicast Listener Discovery (MLD) for IPv6 Unicast-Prefix-based IPv6 Multicast Addresses Allocation Guidelines for IPv6 Multicast Addresses Multicast Listener Discovery Version 2 (MLDv2) for IPv6 Border Gateway Multicast Protocol (BGMP): Protocol Specification Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address IP Version 6 Addressing Architecture Protocol Independent Multicast - Sparse Mode (PIM-SM) : Specification (Revised) Overview of the Internet Multicast Routing Architecture OSPF for IPv6 57

58 10. ANNEXES #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <stdio.h> #include <unistd.h> #include <stdlib.h> struct sockaddr_in6 sin6; #define IPPORT void Perror(const char *c) { perror(c); exit(1); void Usage () { fprintf(stderr, "%s\n", "Usage: source_multicast [-i interface][-h hop][- l loop] addr"); exit(1); int main(int argc, char **argv) { u_int hops = 1, /* as defined in rfc2553 */ loop = 1, /* as defined in rfc2553 */ ifi = 0; int s, cc, ch; char buf[1024]; struct in6_addr addr6; extern char *optarg; extern int optind; addr6 = in6addr_any; if ((s = socket(af_inet6, SOCK_DGRAM, IPPROTO_UDP)) < 0) Perror("socket"); while ((ch = getopt(argc, argv, "h:t:l:i:")) = -1) switch(ch) { case 'h': case 't': hops = atoi(optarg); break; case 'l': loop = atoi(optarg); break; case 'i': if (sscanf(optarg, "%u\0", &ifi) = 1) { ifi = if_nametoindex(optarg); if (ifi == 0) Usage(); 58

59 break; default: Usage(); argc -= optind; argv += optind; if (argc = 1 inet_pton(af_inet6, *argv, &addr6) <= 0) Usage(); if (setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_HOPS,&hops, sizeof(hops)) < 0) Perror("setsockopt IPV6_MULTICAST_HOPS"); if (setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_LOOP,&loop, sizeof(loop)) < 0) Perror("setsockopt IPV6_MULTICAST_LOOP"); if (ifi && (setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_IF,&ifi, sizeof(u_int)) < 0)) Perror("setsockopt IPV6_MULTICAST_IF"); #ifdef SIN6_LEN sin6.sin6_len = sizeof(sin6); #endif sin6.sin6_family = AF_INET6; sin6.sin6_addr = addr6; sin6.sin6_port = htons(54321); for (;;) { cc = read(0, buf, 1024); if (cc < 0) Perror("read file"); if (cc == 0) { fprintf(stderr, ".\n", cc); exit (0); if (sendto(s, buf, cc, 0,(struct sockaddr *)&sin6, sizeof(sin6)) < 0) Perror("sendto"); fprintf(stderr, "-%d->\n", cc); 59

60 #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <stdio.h> #include <signal.h> #include <unistd.h> #include <stdlib.h> #ifndef SO_REUSEPORT #define SO_REUSEPORT SO_REUSEADDR #endif struct sockaddr_in6 sin6; #define IPPORT void Perror(const char *c) { perror(c); exit(0); void Usage () { fprintf(stderr, "%s\n", "Usage: client_multicast [-i interface] addr"); exit(0); void BrokenPipe(int Signal) { signal(sigpipe, BrokenPipe); return; int main(int argc, char **argv) { struct ipv6_mreq mreq; int cc, ccb, ch, s; char buf[10240]; u_int one = 1; u_int ifi = 0; signal(sigpipe, BrokenPipe); while ((ch = getopt(argc, argv, "i:")) = -1) switch(ch) { case 'i': if (sscanf(optarg, "%u\0", &ifi) = 1 && (ifi = if_nametoindex(optarg)) == 0) Usage(); break; default: Usage(); argc -= optind; 60

61 argv += optind; if (argc = 1) Usage(); if ((s = socket(af_inet6, SOCK_DGRAM, IPPROTO_UDP)) < 0) Perror("socket"); setsockopt(s, SOL_SOCKET, SO_REUSEPORT, &one, sizeof(one)); #ifdef SIN6_LEN sin6.sin6_len = sizeof(sin6); #endif sin6.sin6_family = AF_INET6; sin6.sin6_port = htons(ipport); if (bind(s, (struct sockaddr *)&sin6, sizeof(sin6)) < 0) Perror("bind"); if (inet_pton(af_inet6, *argv, &mreq.ipv6mr_multiaddr) = 1) Usage(); mreq.ipv6mr_interface = ifi; if (setsockopt(s,ipproto_ipv6, IPV6_JOIN_GROUP, &mreq, sizeof(mreq)) < 0) Perror("setsockopt IPV6_JOIN_GROUP"); for (;;) { cc = read(s, buf, 10240); if (cc < 0) Perror("read socket"); if (cc == 0) { fprintf(stderr, "..\n"); exit(0); ccb = write(1, buf, cc); if (ccb = cc) Perror("write file"); fprintf(stderr, "<-%d-\n", cc); 61

62 Current configuration : 2265 bytes version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption hostname CISCO2 boot-start-marker boot-end-marker enable password clownix no aaa new-model resource policy ip cef ipv6 unicast-routing ipv6 multicast-routing interface Loopback1 no ip address ipv6 address 2001::2/128 ipv6 enable ipv6 rip rip enable interface FastEthernet0/0 mac-address ip address duplex half no ipv6 mfib forwarding interface Ethernet1/0 mac-address no ip address duplex half ipv6 address 2001:1:2::/64 eui-64 ipv6 enable ipv6 nd prefix 2001:1:2::/64 ipv6 rip rip enable interface Ethernet1/1 mac-address no ip address duplex half ipv6 address 2001:1:3::/64 eui-64 ipv6 enable ipv6 nd prefix 2001:1:3::/64 ipv6 rip rip enable interface Ethernet1/2 mac-address no ip address duplex half 62

63 no ipv6 mfib forwarding interface Ethernet1/3 mac-address no ip address shutdown duplex half no ipv6 mfib forwarding router bgp 1 bgp router-id no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 2001:1:2::FF:FE03:2 remote-as 1 neighbor 2001:1:3::FF:FE05:1 remote-as 1 address-family ipv6 neighbor 2001:1:2::FF:FE03:2 activate neighbor 2001:1:2::FF:FE03:2 next-hop-self neighbor 2001:1:3::FF:FE05:1 activate neighbor 2001:1:3::FF:FE05:1 next-hop-self network 2001::2/128 network 2001:1:2::/64 network 2001:1:3::/64 exit-address-family address-family ipv6 multicast neighbor 2001:1:2::FF:FE03:2 activate neighbor 2001:1:2::FF:FE03:2 next-hop-self neighbor 2001:1:3::FF:FE05:1 activate neighbor 2001:1:3::FF:FE05:1 next-hop-self network 2001::2/128 network 2001:1:2::/64 network 2001:1:3::/64 exit-address-family no ip http server no ip http secure-server logging alarm informational ipv6 router rip rip ipv6 pim rp-address 2001::2 control-plane dial-peer cor custom gatekeeper shutdown line con 0 stopbits 1 line aux 0 stopbits 1 line vty 0 5 exec-timeout 0 0 no login end 63

64 Current configuration : 2174 bytes version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption hostname CISCO3 boot-start-marker boot-end-marker enable password clownix no aaa new-model resource policy ip cef ipv6 unicast-routing ipv6 multicast-routing interface Loopback1 no ip address ipv6 address 2001::3/128 ipv6 enable ipv6 rip rip enable interface FastEthernet0/0 mac-address ip address duplex half no ipv6 mfib forwarding interface Ethernet1/0 mac-address no ip address duplex half ipv6 address 2001:1:3::/64 eui-64 ipv6 enable ipv6 nd prefix 2001:1:3::/64 ipv6 rip rip enable interface Ethernet1/1 mac-address no ip address duplex half ipv6 address 2001:4::/64 eui-64 ipv6 enable ipv6 nd prefix 2001:4::/64 interface Ethernet1/2 mac-address no ip address duplex half 64

65 no ipv6 mfib forwarding interface Ethernet1/3 mac-address no ip address shutdown duplex half no ipv6 mfib forwarding router bgp 1 bgp router-id no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 2001:1:2::FF:FE03:2 remote-as 1 neighbor 2001:1:3::FF:FE04:2 remote-as 1 neighbor 2001:4::FF:FE06:1 remote-as 2 address-family ipv6 neighbor 2001:1:2::FF:FE03:2 activate neighbor 2001:1:3::FF:FE04:2 activate neighbor 2001:4::FF:FE06:1 activate network 2001::3/128 network 2001:1:3::/64 network 2001:4::/64 exit-address-family address-family ipv6 multicast neighbor 2001:1:2::FF:FE03:2 activate neighbor 2001:1:3::FF:FE04:2 activate neighbor 2001:4::FF:FE06:1 activate network 2001::3/128 network 2001:1:3::/64 network 2001:4::/64 exit-address-family no ip http server no ip http secure-server logging alarm informational ipv6 router rip rip ipv6 pim rp-address 2001::2 control-plane dial-peer cor custom gatekeeper shutdown line con 0 stopbits 1 line aux 0 stopbits 1 line vty 0 5 exec-timeout 0 0 no login end 65

66 #/usr/bin/perl -w use strict; use warnings; use Net::Telnet::Cisco; my $session_cisco1 = Net::Telnet::Cisco->new(Host => ' '); if ($session_cisco1->enable('clownix')){ $session_cisco1->cmd('conf t'); $session_cisco1->cmd('ipv6 unicast-routing'); $session_cisco1->cmd('ipv6 multicast-routing'); $session_cisco1->cmd('ipv6 router rip rip'); $session_cisco1->cmd('interface eth1/0'); $session_cisco1->cmd('ipv6 enable'); $session_cisco1->cmd('ipv6 address 2001:661::/64 eui-64'); $session_cisco1->cmd('ipv6 nd prefix 2001:661::/64 onlink autoconfig'); $session_cisco1->cmd('ipv6 rip rip enable'); $session_cisco1->cmd('exit'); $session_cisco1->cmd('interface eth1/1'); $session_cisco1->cmd('ipv6 enable'); $session_cisco1->cmd('ipv6 address 2001:662::/64 eui-64'); $session_cisco1->cmd('ipv6 nd prefix 2001:662::/64 onlink autoconfig'); $session_cisco1->cmd('ipv6 rip rip enable'); $session_cisco1->cmd('exit'); $session_cisco1->cmd('interface eth1/2'); $session_cisco1->cmd('ipv6 enable'); $session_cisco1->cmd('ipv6 address 2001:664::/64 eui-64'); $session_cisco1->cmd('ipv6 nd prefix 2001:664::/64 onlink autoconfig'); $session_cisco1->cmd('ipv6 rip rip enable'); $session_cisco1->cmd('exit'); $session_cisco1->cmd('end'); else { warn "Can't enable: $session_cisco1->errmsg\n"; $session_cisco1->close; my $session_cisco2 = Net::Telnet::Cisco->new(Host => ' '); if ($session_cisco2->enable('clownix')){ $session_cisco2->cmd('conf t'); $session_cisco2->cmd('ipv6 unicast-routing'); $session_cisco2->cmd('ipv6 multicast-routing'); $session_cisco2->cmd('ipv6 router rip rip'); $session_cisco2->cmd('interface Loopback1'); $session_cisco2->cmd('ipv6 enable'); $session_cisco2->cmd('ipv6 address 2001:0:1:3::1/128'); $session_cisco2->cmd('ipv6 rip rip enable'); $session_cisco2->cmd('exit'); $session_cisco2->cmd('interface eth1/0'); $session_cisco2->cmd('ipv6 enable'); $session_cisco2->cmd('ipv6 address 2001:664::/64 eui-64'); $session_cisco2->cmd('ipv6 nd prefix 2001:664::/64 onlink autoconfig'); $session_cisco2->cmd('ipv6 rip rip enable'); $session_cisco2->cmd('exit'); $session_cisco2->cmd('interface eth1/1'); $session_cisco2->cmd('ipv6 enable'); $session_cisco2->cmd('ipv6 address 2001:665::/64 eui-64'); $session_cisco2->cmd('ipv6 nd prefix 2001:665::/64 onlink autoconfig'); $session_cisco2->cmd('ipv6 rip rip enable'); 66

67 $session_cisco2->cmd('exit'); $session_cisco2->cmd('ipv6 pim rp-address 2001:0:1:3::1 emb'); $session_cisco2->cmd('ipv6 access-list emb'); $session_cisco2->cmd('permit ipv6 any ff7e:140:2001:0:1:3::/96'); $session_cisco2->cmd('exit'); $session_cisco2->cmd('end'); else { warn "Can't enable: $session_cisco2->errmsg\n"; $session_cisco2->close; my $session_cisco3 = Net::Telnet::Cisco->new(Host => ' '); if ($session_cisco3->enable('clownix')){ $session_cisco3->cmd('conf t'); $session_cisco3->cmd('ipv6 unicast-routing'); $session_cisco3->cmd('ipv6 multicast-routing'); $session_cisco3->cmd('ipv6 router rip rip'); $session_cisco3->cmd('interface eth1/0'); $session_cisco3->cmd('ipv6 enable'); $session_cisco3->cmd('ipv6 address 2001:665::/64 eui-64'); $session_cisco3->cmd('ipv6 nd prefix 2001:665::/64 onlink autoconfig'); $session_cisco3->cmd('ipv6 rip rip enable'); $session_cisco3->cmd('exit'); $session_cisco3->cmd('interface eth1/1'); $session_cisco3->cmd('ipv6 enable'); $session_cisco3->cmd('ipv6 address 2001:666::/64 eui-64'); $session_cisco3->cmd('ipv6 nd prefix 2001:666::/64 onlink autoconfig'); $session_cisco3->cmd('ipv6 rip rip enable'); $session_cisco3->cmd('exit'); $session_cisco3->cmd('end'); else { warn "Can't enable: $session_cisco3->errmsg\n"; $session_cisco3->close; my $session_cisco4 = Net::Telnet::Cisco->new(Host => ' '); if ($session_cisco4->enable('clownix')){ $session_cisco4->cmd('conf t'); $session_cisco4->cmd('ipv6 unicast-routing'); $session_cisco4->cmd('ipv6 multicast-routing'); $session_cisco4->cmd('ipv6 router rip rip'); $session_cisco4->cmd('interface eth1/0'); $session_cisco4->cmd('ipv6 enable'); $session_cisco4->cmd('ipv6 address 2001:666::/64 eui-64'); $session_cisco4->cmd('ipv6 nd prefix 2001:666::/64 onlink autoconfig'); $session_cisco4->cmd('ipv6 rip rip enable'); $session_cisco4->cmd('exit'); $session_cisco4->cmd('interface eth1/1'); $session_cisco4->cmd('ipv6 enable'); $session_cisco4->cmd('ipv6 address 2001:663::/64 eui-64'); $session_cisco4->cmd('ipv6 nd prefix 2001:663::/64 onlink autoconfig'); $session_cisco4->cmd('ipv6 rip rip enable'); $session_cisco4->cmd('exit'); $session_cisco4->cmd('end'); else { warn "Can't enable: $session_cisco4->errmsg\n"; $session_cisco4->close; 67

68 Dans cet exemple, tous les routeurs sont déjà configurés avec un Rendez-vous Point statique (routeur C). Le premier client se joint au group G, le routeur E créé l état (*,G) et envoie un PIM(*,G)JOIN vers le RP Join Register La source émet des données, son DR (A) encapsule les données et envoie des PIM register vers le RP Les données sont ensuite désencapsulées par le RP et transmises au(x) client(s) 68

69 Le RP envoie un PIM(S,G)JOIN vers le DR de la source, A et B créé l état (S,G) Join Pendant ce temps, le flux multicast est toujours transmis via l encapsulation dans les paquets PIM register Register stop Quand le RP reçoit les données multicast ET encapsulées, il envoie un Register Stop vers le DR de la source afin que ce dernier arrête l encapsulation Les données sont maintenant transmises directement (sans encapsulation) via le RP 69

70 E cherche le chemin le plus court vers la source. Il envoie un PIM(S,G)JOIN vers le DR de la source Join Quand E reçoit les données multicast directement de la source et du RP, il envoie un PIM(S,G)Prune vers le RP. Ce dernier en fait de même vers la source. De cette manière, on se retrouve uniquement avec un flux allant directement de la source au client Prune (S,G) Prune (S,G) 70

71 71

72 72

73 Voici une liste non exhaustive de commandes Cisco comparées aux mêmes commandes Xorp MODE DE COMMANDES OPERATIONEL DE Xorp ping traceroute show arp show ip ospf neighbor show ip ospf database show ip route show ip route include show ip interfaces show ip bgp neighbors show ip bgp ping traceroute show arp show ospf4 neighbor show ospf4 database show route show route match... show interfaces ethernet... physical show interfaces ethernet... statistics show bgp peers show bgp routes MODE DE COMMANDES CONFIGURATION DE Xorp INTERFACES interface set description ip address duplex speed OSPF router ospf 1 router-id network... area area... stub nssa BGP router bgp bgp router-id neighbor... remote-as edit interfaces set description set address... prefix-length set duplex set speed set protocols ospf4 edit protocols ospf4 set router-id set area... interface eth1 address set area...area-type stub nssa set protocols bgp edit protocols bgp set bgp-ig set local-as set peer...next-hop set peer... local-ip set peer... as 73