Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Exemple : Configuration de VPN multicast Draft-Rosen 6 à source nulle

Comprendre le multicast n’importe quelle source

Le multicast any-source (ASM) est la forme de multicast dans laquelle vous pouvez avoir plusieurs expéditeurs sur le même groupe, par opposition au multicast spécifique à la source où une seule source particulière est spécifiée. La spécification multicast d’origine, RFC 1112, prend en charge à la fois le modèle ASM plusieurs-à-plusieurs et le modèle SSM un-à-plusieurs. Pour ASM, la paire de groupes source (S,G) est spécifiée sous la forme (*,G), ce qui signifie que le trafic du groupe multicast peut être fourni par plusieurs sources.

Un réseau ASM doit être capable de déterminer l’emplacement de toutes les sources d’un groupe de multidiffusion particulier chaque fois que des auditeurs sont intéressés, quel que soit l’emplacement des sources sur le réseau. Dans l’ASM, la fonction clé de découverte de la source est une fonction requise du réseau lui-même.

Dans un environnement où de nombreuses sources vont et viennent, comme pour un service de visioconférence, l’ASM est approprié. La découverte de sources multicast semble être un processus facile, mais en mode clairsemé, ce n’est pas le cas.

En mode PIM dense mode, il est assez simple d’inonder le trafic vers chaque routeur du réseau afin que chaque routeur apprenne l’adresse source du contenu de ce groupe multicast.

Toutefois, en mode clairsemé PIM, le flooding du trafic n’est pas une option viable, car il pose des problèmes d’évolutivité et d’utilisation des ressources réseau.

Voir aussi

Exemple : Configuration d’un multicast n’importe quelle source pour les VPN Draft-Rosen

Cet exemple montre comment configurer un VPN multicast any-source (MVPN) à l’aide d’une configuration PIM double avec un RP client et un RP fournisseur et mapper les routes multicast du client au fournisseur (connu sous le nom de draft-rosen). Le Junos OS est conforme à la RFC 4364 et à la norme Internet draft draft-rosen-vpn-mcast-07.txt, Multicast in MPLS/BGP VPNs.

Exigences

Avant de commencer :

Aperçu

Les réseaux privés virtuels multicast (MVPN) peuvent être configurés pour prendre en charge les tunnels des fournisseurs de services fonctionnant en mode ASM (Any-Source Multicast) ou SSM (Source-Specific Multicast).

Dans cet exemple, le terme VPN de couche 3 multicast est utilisé pour désigner les MVPN brouillons.

Cet exemple inclut les paramètres suivants.

  • interface lo0.1 : configure une unité supplémentaire sur l’interface de bouclage du routeur PE. Pour l’interface lo0.1 , attribuez une adresse à partir de l’espace d’adressage VPN. Ajoutez l’interface lo0.1 aux endroits suivants dans la configuration :

    • Instance de routage VRF

    • PIM dans l’instance de routage VRF

    • Stratégies IGP et BGP pour annoncer l’interface dans l’espace d’adressage VPN

    Dans les VPN de couche 3 multicast, les routeurs PE multicast doivent utiliser l’adresse de bouclage principale (ou ID de routeur) pour les sessions avec leurs homologues BGP internes. Si les routeurs PE utilisent un réflecteur de route et que le saut suivant est configuré en tant que self, le multicast de couche 3 sur VPN ne fonctionnera pas, car PIM ne peut pas transmettre les informations d’interface en amont pour les sources multicast derrière les PE distants dans le cœur du réseau. Les VPN de couche 3 multicast nécessitent que l’adresse BGP next-hop de la route VPN corresponde à l’adresse BGP next-hop de l’adresse d’instance VRF loopback.

  • protocols pim interface : configure les interfaces entre chaque routeur fournisseur et les routeurs PE. Sur tous les routeurs CE, incluez cette déclaration sur les interfaces orientées vers le routeur fournisseur agissant en tant que RP.

  • protocols pim mode sparse : active le mode PIM clairsemé sur l’interface lo0 de tous les routeurs PE. Vous pouvez soit configurer cette interface spécifique, soit configurer toutes les interfaces avec l’instruction interface all . Sur les routeurs CE, vous pouvez configurer le mode clairsemé ou le mode dense dense clairsemé.

  • protocols pim rp local : sur tous les routeurs agissant en tant que RP, configurez l’adresse de l’interface lo0 locale. Dans cet exemple, le routeur P fait office de routeur RP.

  • protocols pim rp static : sur tous les routeurs PE et CE, configurez l’adresse du routeur faisant office de RP.

    Il est possible qu’un routeur PE soit configuré en tant que routeur RP (C-RP) VP client. Un routeur PE peut également faire office de DR. Ce type de configuration PE peut simplifier la configuration des DR client et des C-RP VPN pour les VPN multicast. Cet exemple ne traite pas de l’utilisation du PE en tant que C-RP VPN.

    La figure 1 illustre la connectivité multicast sur la périphérie client. Sur la figure, CE2 est le routeur RP. Cependant, le routeur RP peut se trouver n’importe où sur le réseau client.

    Figure 1 : connectivité multicast sur les routeurs Multicast Connectivity on the CE Routers CE

  • protocols pim version 2 : active la version 2 de PIM sur l’interface lo0 de tous les routeurs PE et CE. Vous pouvez soit configurer cette interface spécifique, soit configurer toutes les interfaces avec l’instruction interface all .

  • group-address : dans une instance de routage, configurez la connectivité multicast pour le VPN sur les routeurs PE. Configurez une adresse de groupe VPN sur les interfaces orientées vers le routeur agissant en tant que RP.

    La configuration PIM de l’instance VRF (VPN routing and forwarding) sur les routeurs PE doit correspondre à l’instance PIM principale sur le routeur CE. Par conséquent, le routeur PE contient à la fois une instance PIM principale (pour communiquer avec le noyau fournisseur) et l’instance VRF (pour communiquer avec les routeurs CE).

    Les instances VRF qui font partie du même VPN partagent la même adresse de groupe VPN. Par exemple, tous les routeurs PE contenant une instance de routage compatible multicast VPN-A partagent la même configuration d’adresses de groupe VPN. Dans la figure 2, la configuration d’adresse de groupe VPN partagée est 239.1.1.1.

    Figure 2 : connectivité multicast pour le VPN Multicast Connectivity for the VPN

  • routing-instances instance-name protocols pim rib-group : ajoute le groupe de routage à l'instance VRF du VPN.

  • routing-options rib-groups : configure le groupe de routage multicast.

Topologie

Cet exemple décrit comment configurer le multicast en mode PIM sparse pour une plage d’adresses multicast pour VPN-A, comme illustré à la Figure 3.

Figure 3 : Périphérie client et réseaux Customer Edge and Service Provider Networks des fournisseurs de services

Configuration

Procédure

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.

PE1

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande Junos OS.

Pour configurer le multicast pour les VPN draft-rosen :

  1. Configurez PIM sur le routeur P.

  2. Configurez PIM sur les routeurs PE1 et PE2. Spécifiez un RP statique : le routeur P (10.255.71.47).

  3. Configurez PIM sur CE1. Spécifiez l’adresse RP du RP VPN—Routeur CE2 (10.255.245.91).

  4. Configurez PIM sur CE2, qui fait office de RP VPN. Spécifiez l'adresse de CE2 (10.255.245.91).

  5. Sur PE1, configurez l’instance de routage (VPN-A) pour le VPN de couche 3.

  6. Sur PE1, configurez la stratégie IGP pour annoncer les interfaces dans l’espace d’adressage VPN.

  7. Sur PE1, définissez la configuration RP pour l’instance VRF. La configuration RP au sein de l’instance VRF fournit une connaissance explicite de l’adresse RP, de sorte que l’état (*,G) peut être transféré.

  8. Sur PE1, configurez les interfaces de bouclage.

  9. Comme vous l’avez fait pour le routeur PE1, configurez le routeur PE2.

  10. Lorsque l’un des routeurs PE exécute le logiciel Cisco Systems IOS, vous devez configurer le routeur PE de Juniper Networks pour qu’il prenne en charge cette exigence d’interopérabilité multicast. Le routeur PE Juniper Networks doit disposer de l’interface lo0.0 dans l’instance de routage principale et de l’interface lo0.1 affectée à l’instance de routage VPN. Vous devez configurer l’interface lo0.1 avec la même adresse IP que l’interface lo0.0 utilise pour l’appairage BGP dans le cœur du fournisseur dans l’instance de routage principale.

    Configurez la même adresse IP sur les interfaces de bouclage lo0.0 et lo0.1 du routeur PE de Juniper Networks au niveau de la [edit interfaces lo0] hiérarchie et attribuez l’adresse utilisée pour l’appairage BGP dans le cur fournisseur de l’instance de routage maître. Dans cet autre exemple, l’unité 0 et l’unité 1 sont configurées pour l’interopérabilité Cisco IOS.

  11. Configurez le groupe de tables de routage multicast. Ce groupe accède à inet.2 lorsqu’il effectue des vérifications RPF. Toutefois, si vous utilisez inet.0 pour les vérifications RPF multicast, cette étape empêchera votre configuration multicast de fonctionner.

  12. Activez le groupe de table de routage multicast dans l'instance VRF du VPN.

  13. Si vous avez terminé de configurer l’appareil, validez la configuration.

Résultats

Confirmez votre configuration en saisissant les show interfacescommandes , show protocols, show routing-instanceset show routing-options à partir du mode de configuration. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration. Cette sortie montre la configuration sur PE1.

Vérification

Pour vérifier la configuration, exécutez les commandes suivantes :

  1. Affichez les informations du tunnel multicast et le nombre de voisins à l’aide de la show pim interfaces instance instance-name commande du routeur PE1 ou PE2. Lorsqu’il est émis à partir du routeur PE1, l’affichage de sortie est :

    Vous pouvez également afficher toutes les interfaces de tunnel PE à l’aide de la show pim join commande du routeur fournisseur faisant office de RP.

  2. Affichez les informations de l’interface de tunnel multicast, les informations de reprise après sinistre et l’état du voisin PIM entre les instances VRF sur les routeurs PE1 et PE2 à l’aide de la show pim neighbors instance instance-name commande de l’un ou l’autre routeur PE. Lorsqu’elle provient du routeur PE1, la sortie est la suivante :

Voir aussi

Interfaces de tunnel multicast d’équilibrage de charge entre les PIC disponibles

Lorsque vous configurez le multicast sur des VPN de couche 3 draft-rosen, des interfaces de tunnel multicast sont automatiquement générées pour encapsuler et décapsuler le trafic de contrôle et de données.

Pour générer des interfaces de tunnel multicast, un équipement de routage doit disposer d’un ou plusieurs des PIC compatibles avec les tunnels suivants :

  • Adaptive Services PIC

  • PIC multiservices ou DPC multiservices

  • Services de tunnels PIC

  • Sur les routeurs MX Series, un PIC créé avec l’instruction tunnel-services au niveau de la [edit chassis fpc slot-number pic number] hiérarchie

Note:

Un périphérique de routage est un routeur ou un commutateur EX Series qui fonctionne comme un routeur.

Si un périphérique de routage possède plusieurs PIC de ce type, il peut être important dans votre implémentation d’équilibrer la charge des interfaces de tunnel entre les PIC compatibles avec les tunnels disponibles.

L’interface tunnel multicast utilisée pour l’encapsulation, mt-[xxxxx], est comprise entre 32 768 et 49 151. L’interface mt-[yyyyy], utilisée pour la désencapsulation, est comprise entre 1 081 344 et 1 107 827. PIM s’exécute uniquement sur l’interface d’encapsulation. L’interface de désencapsulation renseigne les informations d’interface en aval. Pour le MDT par défaut, les interfaces de désencapsulation et d’encapsulation d’une instance sont toujours créées sur le même PIC.

Pour chaque VPN, les routeurs PE établissent une arborescence de distribution multicast au sein du réseau central du fournisseur de services. Une fois l’arborescence créée, chaque routeur PE encapsule tout le trafic multicast (messages de données et de contrôle) à partir du VPN connecté et envoie le trafic encapsulé à l’adresse du groupe VPN. Étant donné que tous les routeurs PE sont membres de la liste des interfaces sortantes dans l’arborescence de distribution multicast pour l’adresse du groupe VPN, ils reçoivent tous le trafic encapsulé. Lorsque les routeurs PE reçoivent le trafic encapsulé, ils désencapsulent les messages et envoient les messages de données et de contrôle aux routeurs CE.

Si un périphérique de routage possède plusieurs PIC compatibles avec un tunnel (par exemple, deux PIC pour les services de tunnel), il équilibre la charge de la création d’interfaces de tunnel entre les PIC disponibles. Toutefois, dans certains cas (par exemple, après un redémarrage), un seul PIC peut être sélectionné pour toutes les interfaces du tunnel. Ainsi, un CIP a une charge lourde, tandis que les autres PIC disponibles sont sous-utilisés. Pour éviter cela, vous pouvez configurer manuellement l’équilibrage de charge. Ainsi, vous pouvez configurer et répartir la charge uniformément sur les PIC disponibles.

La définition d’un état équilibré est déterminée par vous et par les exigences de votre implémentation VPN de couche 3. Vous souhaiterez peut-être que toutes les instances soient réparties uniformément sur les PIC disponibles ou sur une liste configurée de PIC. Vous souhaiterez peut-être que toutes les interfaces d’encapsulation de toutes les instances soient réparties uniformément sur les PIC disponibles ou sur une liste configurée de PIC. Si l’on tient compte de la bande passante de chaque interface d’encapsulation de tunnel, on peut choisir une distribution différente. Vous pouvez concevoir votre configuration d’équilibrage de charge en fonction de chaque instance ou de chaque périphérique de routage.

Note:

Dans un VPN de couche 3, chacun des équipements de routage suivants doit disposer d’au moins un PIC compatible avec le tunnel :

  • Chaque routeur Provider Edge (PE).

  • Tout routeur fournisseur (P) agissant en tant que RP.

  • Tout routeur CE (Customer Edge) qui agit en tant que DR ou RP d'une source. Le routeur désigné d'un récepteur n'a pas besoin d'un PIC compatible avec les tunnels.

Pour configurer l’équilibrage de charge :

  1. Sur un routeur M Series ou T Series ou sur un commutateur EX Series, installez plusieurs CIP compatibles avec les tunnels. (Dans certaines implémentations, un seul PIC est requis. L’équilibrage de charge part du principe qu’un périphérique de routage possède plusieurs PIC compatibles avec un tunnel.)
  2. Sur un routeur MX Series, configurez plusieurs CIP compatibles avec les tunnels.
  3. Configurez les VPN de couche 3 comme décrit dans Exemple : Configuration d’un multicast n’importe quelle source pour les VPN Draft-Rosen.
  4. Pour chaque VPN, spécifiez une liste PIC.

    La position physique du PIC dans le périphérique de routage détermine le nom de l’interface du tunnel multicast. Par exemple, si un PIC Adaptive Services est installé dans les emplacements FPC 0 et 0, le nom de l’interface de tunnel multicast correspondant est mt-0/0/0. Il en va de même pour les PIC de services de tunnel, les PIC multiservices et les DPC multiservices.

    Dans l’instruction tunnel-devices , l’ordre de la liste PIC que vous spécifiez n’a pas d’incidence sur la façon dont les interfaces sont allouées. Une instance utilise tous les PICs répertoriés pour créer des interfaces d’encapsulation et de désencapsulation par défaut, ainsi que des interfaces d’encapsulation MDT de données. L’instance utilise une approche de tourniquet pour distribuer les interfaces de tunnel (MDT par défaut et de données) dans la liste PIC (ou entre les PICs disponibles, en l’absence de liste PIC).

    Pour le premier tunnel, l’algorithme Round-Robin commence par le PIC dont le numéro est le plus bas. Le deuxième tunnel est créé sur le PIC suivant dont le numéro est le plus bas, et ainsi de suite. L’algorithme de sélection fonctionne pour le routage à l’échelle de l’équipement. Le tourniquet ne redémarre pas au CIP le plus bas pour chaque nouvelle instance. Cela s’applique à la fois à l’interface de tunnel MDT par défaut et à l’interface de tunnel MDT de données.

    En cas de défaillance d’un CIP de la liste, de nouvelles interfaces de tunnel sont créées sur les PICs restants de la liste à l’aide de l’algorithme Round-Robin. Si tous les PICs de la liste tombent en panne, toutes les interfaces de tunnel sont supprimées et aucune nouvelle interface de tunnel n’est créée. Si un PIC de la liste sort de l’état inactif et que le PIC restauré est le seul CIP actif, les interfaces sont réaffectées au CIP restauré. Si un PIC de la liste sort de l’état inactif et que d’autres PIC sont déjà actifs, aucune réaffectation d’interface n’est effectuée. Toutefois, lorsqu’une nouvelle interface de tunnel doit être créée, le PIC restauré est disponible pour le processus de sélection. Si vous incluez dans la liste PIC un PIC qui n’est pas installé sur le périphérique de routage, le PIC est traité comme s’il était présent, mais à l’état inactif.

    Pour équilibrer les interfaces entre les instances, vous pouvez affecter un PIC à chaque instance. Par exemple, si vous avez vpn1-10 et que vous avez trois PIC, par exemple, mt-1/1/0, mt-1/2/0mt-2/0/0, vous pouvez configurer vpn1-4 pour qu’il n’utilise mt-1/1/0que , vpn5-7 pour utiliser mt-1/2/0et vpn8-10 pour utiliser mt-2/0/0.

  5. Validez la configuration.

    Lorsque vous validez une nouvelle configuration de liste PIC, toutes les interfaces de tunnel multicast de l’instance de routage sont supprimées et recréées à l’aide de la nouvelle liste PIC.

  6. Si vous redémarrez le périphérique de routage, certains PICs apparaissent plus rapidement que d’autres. La différence peut se chiffrer en minutes. Par conséquent, lors de la création des interfaces de tunnel, la liste des PIC connus peut ne pas être la même que lorsque le périphérique de routage est complètement redémarré. Cela entraîne la création d’interfaces de tunnel sur certains PIC disponibles et configurés, mais pas tous. Pour remédier à cette situation, vous pouvez rééquilibrer manuellement la charge PIC.

    Vérifiez si un rééquilibrage de charge est nécessaire.

    La sortie montre que n’a qu’une seule interface d’encapsulation de tunnel, alors qu’il mt-1/1/0 mt-1/2/0 a trois interfaces d’encapsulation de tunnel. Dans un cas comme celui-ci, vous pouvez décider de rééquilibrer les interfaces. Comme indiqué précédemment, les interfaces d’encapsulation sont comprises entre 32 768 et 49 151. Pour déterminer si un rééquilibrage est nécessaire, examinez uniquement les interfaces d’encapsulation, car l’interface de désencapsulation MDT par défaut réside toujours sur le même PIC que l’interface d’encapsulation MDT par défaut.

  7. (Facultatif) Rééquilibrez la charge PIC.

    Cette commande recrée et rééquilibre toutes les interfaces de tunnel pour une instance spécifique.

    Cette commande recrée et rééquilibre toutes les interfaces de tunnel pour toutes les instances de routage.

  8. Vérifiez que la charge du PIC est équilibrée.

    La sortie montre que mt-1/1/0 a deux interfaces d’encapsulation, et mt-1/2/0 a également deux interfaces d’encapsulation.

Voir aussi

Documentation connexe