IP : Protocole IP Multicast

Multicast sur un tunnel GRE

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


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 beaucoup de scénarios de réseau vous voulez configurer votre réseau pour utiliser des tunnels GRE pour envoyer le Protocol Independent Multicast (PIM) et le trafic de multidiffusion entre les Routeurs. Typiquement, ceci se produit quand la source multicast et le récepteur sont séparés par un nuage IP qui n'est pas configuré pour l'acheminement de Protocole IP Multicast. Dans de tels scénarios de réseau, configurer un tunnel à travers un nuage IP avec PIM a activé des paquets de multidiffusion de transports vers le récepteur. Ce document décrit la configuration, vérification, et les questions connexes concernant la multifusion au-dessus d'un GRE percent un tunnel.

Conditions préalables

Conditions requises

Assurez-vous que vous répondez à ces exigences avant d'essayer cette configuration :

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Configurez

Cette section vous fournit des informations pour configurer les fonctionnalités décrites dans ce document.

Remarque: Utilisez l'outil Command Lookup Tool (clients enregistrés seulement) pour trouver plus d'informations sur les commandes utilisées dans ce document.

Pendant que le schéma de réseau affiche, la source multicast (10.1.1.1) est connectée à R102 et est configurée pour le groupe de multidiffusion 239.1.1.20. Le récepteur multicast (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 de R104 est un nuage IP, qui n'est pas configuré pour le routage de Multidiffusion.

Un tunnel est configuré entre R102 à R104 originaire avec leurs interfaces de bouclage. La commande clairsemé-dense de mode d'ip pim est configurée sur des interfaces de tunnel et le multicast-routing est activé sur R102 et R104. la configuration de mode Clairsemé-dense sur les interfaces de tunnel permet le clairsemé-mode ou les paquets de dense-mode à expédier au-dessus du tunnel selon la configuration du point de rendez-vous (RP) pour le groupe.

Remarque:  Pour le mode dense — Le mode dense PIM étant configuré au-dessus du tunnel, une commande du tunnel 0 de 10.1.1.0 255.255.255.0 d'ip mroute est configurée sur R104 d'assurer un RPF réussi pour l'adresse source multicast 10.1.1.1. (10.1.1.1, 239.1.1.20) les paquets de multidiffusion entrants au-dessus de Tunnel0 (Tu0) sont le Reverse Path Forwarding vérifié (RPF) utilisant cette déclaration de mroute. Après qu'un contrôle réussi, les paquets de multidiffusion soient expédiés aux interfaces de liste d'interfaces en sortie (HUILE).

Remarque:  Pour le mode clairsemé — Le mode intermédiaire PIM étant configuré au-dessus du tunnel, assurez-vous que ces points sont abordés :

  • Pour une vérification réussie RPF du trafic de multidiffusion circulant au-dessus de l'arbre partagé (*, G) du RP, une commande de nexthop de rp-address d'ip mroute doit être configurée pour l'adresse RP, ce indique l'interface de tunnel.

    Avec la supposition que R102 est le RP (adresse 2.2.2.2 RP) dans ce cas, puis le mroute est la commande du tunnel 0 de 2.2.2.2 255.255.255.255 d'ip mroute, qui s'assure qu'un RPF réussi vérifient le trafic qui circule sur l'arbre partagé.

  • Pour une vérification réussie RPF de Multidiffusion (S, G) le trafic circulant au-dessus de l'arbre au chemin le plus court (SPT), une commande de nexthop de source-address d'ip mroute doit être configuré pour la source multicast, indiquant l'interface de tunnel.

    Dans ce cas, quand le trafic SPT circule au-dessus de l'interface de tunnel une commande du tunnel 0 de 10.1.1.0 255.255.255.0 d'ip mroute est configurée sur R104 d'assurer une vérification réussie RPF pour (10.1.1.1, 239.1.1.20) les paquets de multidiffusion entrants au-dessus de l'interface Tu0.

Diagramme du réseau

Ce document utilise la configuration réseau suivante :

/image/gif/paws/43584/mcast-gre2.gif

Configurations

Ce document utilise les configurations suivantes :

Configurez le routeur 102 selon 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 
!--- the show command response time.

!
ip multicast-routing

!--- Enables IP multicast routing.

!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 
!--- Tunnel Source interface.

!
interface Tunnel0

!--- Tunnel interface configured for PIM and carrying 
!--- multicast packets to R104.

 ip address 192.168.24.1 255.255.255.252
 ip pim sparse-dense-mode
 tunnel source Loopback0
 tunnel destination 4.4.4.4
!
interface Ethernet0/0

!--- Interface connected to Source.

 ip address 10.1.1.2 255.255.255.0
 ip pim sparse-dense-mode
!
!
interface Serial8/0
 ip address 192.168.23.1 255.255.255.252

!--- Note IP PIM sparse-dense mode is 
!--- not configured on Serial interface.

!router ospf 1
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 0
 network 10.1.1.0 0.0.0.255 area 0
 network 192.168.23.0 0.0.0.255 area 0
!
ip classless
ip pim bidir-enable
!
line con 0
line aux 0
line vty 0 4
 login
!
end

Configurez le routeur 104 selon 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 
!--- the show command response time.

!
ip multicast-routing

!--- Enables IP multicast routing.

!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255

!--- Tunnel Source interface.

!
interface Tunnel0
 ip address 192.168.24.2 255.255.255.252

!--- Tunnel interface configured for PIM 
!--- and carrying multicast packets.

 ip pim sparse-dense-mode
 tunnel source Loopback0
 tunnel destination 2.2.2.2
!
interface Ethernet0/0
 ip address 10.2.2.2 255.255.255.0
 ip pim sparse-dense-mode
!
interface Serial9/0
 ip address 192.168.34.1 255.255.255.252

!--- Note IP PIM sparse-dense mode is not 
!--- configured on Serial interface.

!
!
router ospf 1
 log-adjacency-changes
 network 4.4.4.4 0.0.0.0 area 0
 network 10.2.2.0 0.0.0.255 area 0
 network 192.168.34.0 0.0.0.255 area 0
!
ip classless
no ip http server
ip pim bidir-enable
ip mroute 10.1.1.0 255.255.255.0 Tunnel0


!--- This mroute ensures a successful RPF check 
!--- for packets flowing from the source.
!--- 10.1.1.1 over Shared tree in case of Dense 
!--- more and SPT in case of Sparse mode.

!
ip mroute 2.2.2.2 255.255.255.255 tunnel 0


!--- This mroute is required for RPF check when 
!--- Sparse mode multicast traffic is 
!--- flowing from RP (assuming R102 with 2.2.2.2 as RP)
!--- towards receiver via tunnel  
!--- before the SPT switchover.

line con 0
line aux 0
line vty 0 4
 login
!
end

Vérifiez

Référez-vous à cette section pour vous assurer du bon fonctionnement de votre configuration.

L'Outil Interpréteur de sortie (clients enregistrés uniquement) (OIT) prend en charge certaines commandes show. Utilisez l'OIT pour afficher une analyse de la sortie de la commande show .

  • groupe d'igmp de show ip — Vérifie que le récepteur a envoyé son IGMP joignent la demande d'adhésion du 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
  • adresse de groupe de show ip mroute — Vérifie que quand la source 10.1.1.1 commence des paquets de multifusion pour le groupe 239.1.1.20, R102 installe (*,239.1.1.20) et (10.1.1.1, 239.1.1.20) des entrées dans la table mroute R102.

    Remarque: Dans (10.1.1.1, 239.1.1.20) l'entrée, l'HUILE 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
  • adresse de groupe de show ip mroute — Vérifie que R104 a (*,239.1.1.20) et (10.1.1.1, 239.1.1.20) des entrées tandis qu'il expédie des paquets de multidiffusion pour le groupe 239.1.1.20 originaire 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 — la tête de réseau de tunnel sur R102. La vérification RPF est faite a basé sur le mroute configuré sur R104, et les paquets de multidiffusion sont éliminés à l'HUILE au récepteur connecté sur les Ethernets 0/0 interface.

    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
  • IP address de show ip rpf — Exécutez une vérification RPF pour des paquets originaires de 10.1.1.1. L'exemple suivant confirme que le RPF pour 10.1.1.1 est par l'intermédiaire du tunnel 0, sur lequel nous recevons la Multidiffusion (S, G) des paquets.

    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épannez

Utilisez cette section pour dépanner votre configuration.

L'Outil Interpréteur de sortie (clients enregistrés uniquement) (OIT) prend en charge certaines commandes show. Utilisez l'OIT pour afficher une analyse de la sortie de la commande show .

Remarque: Référez-vous aux informations importantes sur les commandes de débogage avant d'utiliser les commandes de débogage.

Si votre Multidiffusion au-dessus de tunnel GRE ne fonctionne pas, un de ces derniers peut être la cause :

  • Tunnel pas UP/UP — La source du tunnel et la destination ne s'assortissent pas sur chaque extrémité du tunnel. Par exemple, si la destination de tunnel sur R102 était changée à l'adresse IP 10.2.2.2 au lieu de 2.2.2.2 tandis que la configuration sur R104 demeurait la même, le tunnel ne monterait pas.

    Émettez la commande de l'interface tunnel 0 d'exposition afin de vérifier l'état du tunnel.

  • Des paquets de multidiffusion sont lâchés en raison de la panne RPF.

    Émettez la commande de compte de show ip mroute. Un résultat témoin de cette commande et de ses compteurs croissants pour la panne RPF est affiché 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 de source de show ip rpf. Assurez-vous que l'interface RPF est identique que celle sur laquelle les paquets de multidiffusion de source sont reçus — percent un tunnel 0 dans cet exemple. Référez-vous au guide de dépannage de Protocole IP Multicast pour plus d'informations sur des pannes RPF.

  • Voisins PIM — Le routeur R102 n'expédie pas au-dessus de l'interface Tunnel0 parce qu'elle ne voit pas un voisin R104 P.M.

    Émettez les commandes suivantes :

    • show ip pim neighbor — Vous pouvez utiliser la commande de show ip pim neighbor sur R102 d'afficher le voisin R104 au-dessus du tunnel.

    • pim international de show ip — Vous pouvez également utiliser la commande du pim international de show ip de prouver qu'il y a un voisin.

    • clairsemé-dense-mode d'ip pim — Vérifiez que la commande de clairsemé-dense-mode d'ip pim de niveau d'interface est configurée sur les deux extrémités du tunnel et que l'ip multicast-routing est activé.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 43584