Contenu
Introduction
Ce document fournit un exemple de configuration pour une multidiffusion au-dessus d'un tunnel d'encapsulation de routage générique (GRE).
Dans de nombreux scénarios de réseau, vous voulez configurer votre réseau pour qu'il utilise des tunnels GRE pour envoyer le trafic de multidiffusion indépendante du protocole (PIM) et de multidiffusion entre les routeurs. En règle générale, cela se produit lorsque la source et le récepteur de multidiffusion sont séparés par un nuage IP qui n'est pas configuré pour le routage de multidiffusion IP. Dans de tels scénarios de réseau, la configuration d'un tunnel à travers un nuage IP avec PIM activé transporte les paquets de multidiffusion vers le récepteur. Ce document décrit la configuration, la vérification et les problèmes connexes liés à la multidiffusion sur un tunnel GRE.
Conditions préalables
Conditions requises
Assurez-vous que vous répondez à ces exigences avant d'essayer cette configuration :
-
Une compréhension de base de la multidiffusion et du protocole PIM est utile. Référez-vous au Guide de configuration de démarrage rapide de multidiffusion pour plus d'informations sur la multidiffusion et le PIM.
Components Used
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Configuration
Cette section vous fournit des informations pour configurer les fonctionnalités décrites dans ce document.
Comme le montre le schéma de réseau, la source de multidiffusion (10.1.1.1) est connectée à R102 et est configurée pour le groupe de multidiffusion 239.1.1.20. Le récepteur de multidiffusion (10.2.2.3) est connecté à R104 et est configuré pour recevoir des paquets de multidiffusion pour le groupe 239.1.1.20. La séparation de R102 et R104 est un nuage IP, qui n'est pas configuré pour le routage de multidiffusion.
Un tunnel est configuré entre R102 et R104 avec leurs interfaces de bouclage. La commande ip pim sparse-dense est configurée sur les interfaces de tunnel et le routage de multidiffusion est activé sur R102 et R104. La configuration en mode dense et partiel sur les interfaces de tunnel permet de transférer des paquets en mode dense ou en mode clairsemé sur le tunnel en fonction de la configuration du point de rendez-vous (RP) du groupe.
Remarque : Pour le mode dense : avec le mode dense PIM configuré sur le tunnel, une commande ip mroute 10.1.1.0 255.255.255.0 tunnel 0 est configurée sur R104 pour garantir une RPF réussie pour l'adresse source de multidiffusion 10.1.1.1. Les paquets de multidiffusion entrants (10.1.1.1, 239.1.1.20) sur Tunnel0 (Tu0) sont vérifiés pour le transfert inverse du chemin (RPF) à l'aide de cette instruction mroute. Après une vérification réussie, les paquets de multidiffusion sont transférés aux interfaces OIL (Outgoing interface list).
Remarque : Pour le mode intermédiaire - Avec le mode intermédiaire PIM configuré sur le tunnel, assurez-vous que ces points sont traités :
-
Pour une vérification RPF réussie du trafic de multidiffusion circulant sur l'arborescence partagée (*, G) à partir du RP, une commande ip mroute rp-address nexthop doit être configurée pour l'adresse RP, qui pointe vers l'interface de tunnel.
En supposant que R102 est le RP (adresse RP 2.2.2.2) dans ce cas, la commande mroute est la commande ip mroute 2.2.2.2 255.255.255.255 tunnel 0, qui garantit une vérification RPF réussie du trafic qui circule sur l'arborescence partagée.
-
Pour une vérification RPF réussie du trafic de multidiffusion (S, G) circulant sur l'arbre du chemin le plus court (SPT), une commande ip mroute source-address nexthop doit être configurée pour la source de multidiffusion, pointant vers l'interface de tunnel.
Dans ce cas, lorsque le trafic SPT circule sur l'interface de tunnel, une commande ip mroute 10.1.1.0 255.255.255.0 tunnel 0 est configurée sur R104 pour garantir une vérification RPF réussie pour le trafic entrant (10.1.1.1, 239.1.1.20) paquets sur l'interface Tu0.
Diagramme du réseau
Ce document utilise la configuration réseau suivante :
Configurations
Ce document utilise les configurations suivantes :
Configurez le routeur 102 conformément à ce fichier de configuration en cours :
| R102 |
|---|
version 12.2 !hostname r102 ! !ip subnet-zero no ip domain-lookup !--- It stops IP domain lookup, which improves |
Configurez le routeur 104 conformément à ce fichier de configuration en cours :
| R104 |
|---|
r104# version 12.2 ! hostname r104 ! ! ip subnet-zero no ip domain-lookup !--- It stops IP domain lookup, which improves |
Vérification
Référez-vous à cette section pour vous assurer du bon fonctionnement de votre configuration.
Certaines commandes d’affichage (« show ») sont offertes par l’outil « Cisco CLI Analyzer » réservé aux clients inscrits. Utilisez Cisco CLI Analyzer pour voir une analyse de la sortie d’une commande show.
-
show ip igmp group - Vérifie que le récepteur a envoyé sa demande d'adhésion IGMP pour le groupe 239.1.1.20 à R104.
r104#show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 239.1.1.20 Ethernet0/0 00:00:04 00:02:55 10.2.2.3
-
show ip mroute group-address - Vérifie que lorsque la source 10.1.1.1 démarre des paquets de multidiffusion pour le groupe 239.1.1.20, R102 installe (*,239.1.1.20) et (10.1.1.1, 239.1.20 ) dans la table de routage R102.
Remarque : dans l'entrée (10.1.1.1, 239.1.1.20), l'OIL est Tunnel0.
r102#show ip mroute 239.1.1.20 IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.1.1.20), 00:00:09/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:00:09/00:00:00 Ethernet0/0, Forward/Sparse-Dense, 00:00:09/00:00:00 (10.1.1.1, 239.1.1.20), 00:00:09/00:02:58, flags: T Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:00:09/00:00:00 -
show ip mroute group-address - Vérifie que R104 a les entrées (*,239.1.1.20) et (10.1.1.1, 239.1.1.20) lors du transfert de paquets de multidiffusion pour le groupe 239.1.1.20 provenant de 10.1. 1.1.
Remarque : Dans (10.1.1.1, 239.1.1.20), l'interface entrante est Tunnel0 et le voisin RPF est 192.168.24.1 - l'extrémité de tête de tunnel sur R102. La vérification RPF est effectuée en fonction de la route configurée sur R104, et les paquets de multidiffusion sont envoyés à l'OIL vers le récepteur connecté à l'interface Ethernet 0/0.
r104#show ip mroute 239.1.1.20 IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.1.1.20), 00:07:10/00:00:00, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:07:10/00:00:00 Ethernet0/0, Forward/Sparse-Dense, 00:07:10/00:00:00 (10.1.1.1, 239.1.1.20), 00:01:13/00:02:24, flags: CLT Incoming interface: Tunnel0, RPF nbr 192.168.24.1, Mroute Outgoing interface list: Ethernet0/0, Forward/Sparse-Dense, 00:01:13/00:00:00 -
show ip rpf ip-address - Effectuez une vérification RPF pour les paquets provenant de 10.1.1.1. L'exemple suivant confirme que RPF pour 10.1.1.1 est via le tunnel 0, sur lequel nous recevons les paquets de multidiffusion (S, G).
r104>show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Tunnel0 RPF neighbor: ? (192.168.24.1) RPF route/mask: 10.1.1.1/24 RPF type: static RPF recursion count: 0 Doing distance-preferred lookups across tables
Dépannage
Utilisez cette section pour dépanner votre configuration.
Certaines commandes d’affichage (« show ») sont offertes par l’outil « Cisco CLI Analyzer » réservé aux clients inscrits. Utilisez Cisco CLI Analyzer pour voir une analyse de la sortie d’une commande show.
Remarque : Consulter les renseignements importants sur les commandes de débogage avant d’utiliser les commandes de débogage.
Si votre multidiffusion sur le tunnel GRE ne fonctionne pas, l'une des causes peut être :
-
Tunnel not UP/UP - La source et la destination du tunnel ne correspondent pas à chaque extrémité du tunnel. Par exemple, si la destination du tunnel sur R102 a été remplacée par l'adresse IP 10.2.2.2 au lieu de 2.2.2.2 alors que la configuration sur R104 est restée la même, le tunnel ne s'afficherait pas.
Émettez la commande show interface tunnel 0 afin de vérifier l'état du tunnel.
-
Les paquets de multidiffusion sont abandonnés en raison d'une défaillance RPF.
Exécutez la commande show ip mroute count. Un exemple de sortie de cette commande et de ses compteurs croissants pour la défaillance RPF est montré dans cette sortie :
r104#show ip mroute count IP Multicast Statistics 3 routes using 1642 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0 Group: 239.1.1.20, Source count: 1, Packets forwarded: 11, Packets received: 45 Source: 10.1.1.1/32, Forwarding: 11/0/100/0, Other: 25/14/0 !--- After some time, the show ip mroute count command
!--- is issued again. You can see the RPF failed counter increasing: r104#show ip mroute count IP Multicast Statistics 3 routes using 1642 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0 Group: 239.1.1.20, Source count: 1, Packets forwarded: 11, Packets received: 50 Source: 10.1.1.1/32, Forwarding: 11/0/100/0, Other: 30/19/0 r104#Vous pouvez également émettre la commande show ip rpf source. Assurez-vous que l'interface RPF est identique à celle sur laquelle les paquets de multidiffusion source sont reçus - Tunnel 0 dans cet exemple. Reportez-vous au Guide de dépannage de multidiffusion IP pour plus d'informations sur les échecs RPF.
-
Voisins PIM - Le routeur R102 ne transfère pas sur l'interface Tunnel0, car il ne voit pas de voisin PM R104.
Émettez les commandes suivantes :
-
show ip pim neighbor - Vous pouvez utiliser la commande show ip pim neighbor sur R102 pour afficher le voisin R104 sur le tunnel.
-
show ip pim int - Vous pouvez également utiliser la commande show ip pim int pour indiquer qu'il existe un voisin.
-
ip pim sparse-dense-mode - Vérifiez que la commande de niveau interface ip pim sparse-dense-mode est configurée aux deux extrémités du tunnel et que le routage de multidiffusion IP est activé.
-