Consultare la guida alla configurazione iniziale rapida del multicast IP

Introduzione

Questo documento descrive le nozioni di base su come configurare il multicast per vari scenari di rete.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza di questo argomento:

• Multicast IP (Internet Protocol).

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Premesse

Il multicasting IP è una tecnologia che riduce il traffico e consente di distribuire un singolo flusso di informazioni a migliaia di destinatari e abitazioni aziendali. Le applicazioni che sfruttano il multicast includono videoconferenze, comunicazioni aziendali, formazione a distanza e distribuzione di software, quotazioni di borsa e notizie.

Modalità Dense

Cisco consiglia di utilizzare la modalità sparse PIM (Protocol Independent Multicast), in particolare Auto-RP, dove possibile e soprattutto per nuove distribuzioni. Tuttavia, se si desidera la modalità densa, configurare il comando globale ip multicast-routing e il comando di interfaccia ip pim sparse-dense-mode su ciascuna interfaccia che deve elaborare il traffico multicast. In tutte le configurazioni descritte in questo documento, il requisito comune è configurare il multicasting a livello globale e configurare il protocollo PIM sulle interfacce. A partire dal software Cisco IOS® versione 11.1, è possibile configurare i comandi di interfaccia ip pim dense-mode e ip pim sparse-mode contemporaneamente al comando ip pim sparse-dense-mode. In questa modalità, l'interfaccia viene considerata in modalità dense se se il gruppo è in modalità dense. Se il gruppo è in modalità sparse (ad esempio, se è noto un RP), l'interfaccia viene trattata come modalità sparse.

Nota: la voce "Source" (Origine) negli esempi riportati in questo documento rappresenta l'origine del traffico multicast, mentre la voce "Receiver" (Ricevitore) rappresenta il destinatario del traffico multicast.

Interfaccia trattata come modalità Dense se Group è in modalità Dense

ip multicast-routing 

interface ethernet0 
ip address <address> <mask>
ip pim sparse-dense-mode  

interface serial0 
ip address <address> <mask>
ip pim sparse-dense-mode

ip multicast-routing 

interface serial0 
ip address <address> <mask>
ip pim sparse-dense-mode 

interface ethernet0 
ip address <address> <mask>
ip pim sparse-dense-mode 

Modalità sparse con un RP

Nell'esempio, il router A è l'RP, in genere il router più vicino all'origine. La configurazione RP statica richiede che per tutti i router del dominio PIM siano configurati i comandi samei p pim rp-address. È possibile configurare più RP, ma può esistere un solo RP per gruppo specifico.

Possono esistere più RP, ma solo un RP per gruppo specifico

ip multicast-routing 
ip pim rp-address 10.1.1.1
 

interface ethernet0 
ip address <address> <mask>
ip pim sparse-dense-mode 

interface serial0 
ip address 10.1.1.1 255.255.255.0 
ip pim sparse-dense-mode 

ip multicast-routing 
ip pim rp-address 10.1.1.1 


interface serial0 
ip address <address> <mask>
ip pim sparse-dense-mode 

interface ethernet0 
ip address <address> <mask>
ip pim sparse-dense-mode 

Modalità sparse con più RP

Nell'esempio, la sorgente A invia a 24.1.1.1, 224.1.1.2 e 224.1.1.3. La sorgente B invia a 224.2.2.2, 224.2.2.3 e 224.2.2.4. È possibile avere un router, RP 1 o RP 2, come RP per tutti i gruppi. Tuttavia, se si desidera che RP diversi gestiscano gruppi diversi, è necessario configurare tutti i router in modo che includano i gruppi che gli RP possono servire. Per questo tipo di configurazione RP statica è necessario che tutti i router del dominio PIM dispongano dello stesso comando acl indirizzo ip pim configurato. È inoltre possibile utilizzare Auto-RP per ottenere la stessa impostazione, che è più facile da configurare.

La sorgente A invia i dati a 224.1.1.1, 224.1.1.2 e 224.1.1.3, la sorgente B invia i dati a 224.2.2.2, 224.2.2.3 e 224.2.2.4.

ip multicast-routing 
 
ip pim RP-address 10.1.1.1 2
ip pim RP-address 10.2.2.2 3 
 
access-list 2 permit 224.1.1.1 
access-list 2 permit 224.1.1.2 
access-list 2 permit 224.1.1.3
access-list 3 permit 224.2.2.2 
access-list 3 permit 224.2.2.3 
access-list 3 permit 224.2.2.4

ip multicast-routing
  
ip pim RP-address 10.1.1.1 2 
ip pim RP-address 10.2.2.2  3
 
access-list 2 permit 224.1.1.1 
access-list 2 permit 224.1.1.2 
access-list 2 permit 224.1.1.3 
access-list 3 permit 224.2.2.2 
access-list 3 permit 224.2.2.3 
access-list 3 permit 224.2.2.4 

ip multicast-routing 
ip pim RP-address 10.1.1.1  2 
ip pim RP-address 10.2.2.2  3
 

access-list 2 permit 224.1.1.1 
access-list 2 permit 224.1.1.2 
access-list 2 permit 224.1.1.3 
access-list 3 permit 224.2.2.2 
access-list 3 permit 224.2.2.3 
access-list 3 permit 224.2.2.4 

Auto-RP con un RP

L'Auto-RP richiede la configurazione degli RP per annunciarne la disponibilità come RP e agenti di mapping. Le RP utilizzano 224.0.1.39 per inviare i loro annunci. L'agente di mapping RP resta in ascolto dei pacchetti annunciati dagli RP, quindi invia i mapping RP-a-gruppo in un messaggio di individuazione inviato a 24.0.1.40. Questi messaggi di individuazione vengono utilizzati dai router residui per la mappa da RP a gruppo. È possibile utilizzare un RP che funga anche da agente di mapping oppure configurare più RP e più agenti di mapping a scopo di ridondanza.

Si noti che, quando si sceglie un'interfaccia dalla quale originare gli annunci RP, Cisco consiglia di utilizzare un'interfaccia quale un loopback anziché un'interfaccia fisica. Inoltre, è possibile utilizzare interfacce VLAN commutate (SVI). Se si usa un'interfaccia VLAN per annunciare l'indirizzo RP, l'opzione interface-type nel comando ip pim [vrf vrf-name] send-rp-notice {interface-type-number | ip-address} il comando ttl-value dell'ambito deve contenere l'interfaccia VLAN e il numero VLAN. Ad esempio, il comando ha il formato ip pim send-rp-noticeVlan500 scope 100 . Se si sceglie un'interfaccia fisica, è necessario che l'interfaccia sia sempre attiva. Ciò non accade sempre e il router smette di pubblicizzarsi come RP una volta che l'interfaccia fisica si interrompe. Con un'interfaccia di loopback, è sempre attivo e non si abbassa mai, il che assicura che l'RP continui a farsi pubblicità attraverso qualsiasi interfaccia disponibile come un RP. Ciò avviene anche se si verifica un errore in una o più interfacce fisiche. L'interfaccia di loopback deve essere abilitata per PIM e pubblicizzata da un IGP (Interior Gateway Protocol) oppure deve essere raggiungibile con il routing statico.

L'interfaccia di loopback deve essere abilitata per PIM e annunciata da un protocollo gateway interno o raggiungibile con routing statico

ip multicast-routing 
 
ip pim send-rp-annouce loopback0 scope 16

ip pim send-rp-discover

 scope 16 

interface loopback0
ip address <address> <mask>
ip pim sparse-dense-mode 
 
interface ethernet0 
ip address <address> <mask>
ip pim sparse-dense-mode 

interface serial0 
ip address <address> <mask>
ip pim sparse-dense-mode 

ip multicast-routing 


interface ethernet0 
ip address <address> <mask>
ip pim sparse-dense-mode 

interface serial0 
ip address <address> <mask>
ip pim sparse-dense-mode 

Auto-RP con più RP

Gli elenchi degli accessi di questo esempio consentono di utilizzare gli RP solo per i gruppi desiderati. Se non è configurato alcun elenco degli accessi, gli RP sono disponibili come RP per tutti i gruppi. Se due RP dichiarano di essere RP per lo stesso gruppo, gli agenti di mapping risolvono questi conflitti con la regola "l'indirizzo IP più alto prevale".

Quando due RP sono annunciati per quel gruppo, è possibile configurare ciascun router con un indirizzo di loopback in modo da influenzare quale router sia l'RP per un particolare gruppo. Posizionare l'indirizzo IP più alto sull'RP preferito, quindi usare l'interfaccia di loopback come origine dei pacchetti di annuncio; ad esempio, ip pim send-RP-indeceloopback0 . Quando si utilizzano più agenti di mapping, ciascuno annuncia lo stesso gruppo ai mapping RP al gruppo di rilevamento 224.0.1.40.

Inserire l'indirizzo IP superiore nell'RP preferita

ip multicast-routing
 
interface loopback0
ip address <address> <mask>
ip pim sparse-dense-mode  
 
ip pim send-RP-announce loopback0 scope 16 group-list 1
ip pim send-RP-discovery scope 16 

access-list 1 permit 239.0.0.0 0.255.255.255 

ip multicast-routing
 
interface loopback0
ip address <address> <mask>
ip pim sparse-dense-mode 
 
ip pim send-RP-announce loopback0 scope 16 group-list 1
ip pim send-RP-discovery scope 16 


access-list 1 deny 239.0.0.0 0.255.255.255 
access-list 1 permit 224.0.0.0 10.255.255.255 

DVMRP

Il provider di servizi Internet (ISP) potrebbe suggerire di creare un tunnel DVMRP (Distance Vector Multicast Routing Protocol) per l'ISP in modo da ottenere l'accesso alla backbone multicast in Internet (mbone). Di seguito sono riportati i comandi minimi per configurare un tunnel DVMRP:

interface tunnel0  
ip unnumbered <any pim interface>
tunnel source <address of source>
tunnel destination <address of ISPs mrouted box> 
tunnel mode dvmrp  
ip pim sparse-dense-mode

In genere, l'ISP consente di eseguire il tunnel su un computer UNIX che esegue "mrouted" (DVMRP). Se invece l'ISP dispone del tunnel a un altro dispositivo Cisco, utilizzare la modalità predefinita del tunnel GRE.

Se si desidera generare pacchetti multicast per gli altri utenti sulla barra multifunzione da visualizzare invece di ricevere pacchetti multicast, è necessario annunciare le subnet di origine. Se l'indirizzo host di origine multicast è 172.16.108.1, è necessario annunciare l'esistenza di tale subnet al mbone. Per impostazione predefinita, le reti con connessione diretta vengono pubblicizzate con la metrica 1.

Se l'origine non è collegata direttamente al router con il tunnel DVMRP, configurarlo in interface tunnel0:

ip dvmrp metric 1 list 3  
access-list 3 permit  172.16.108.0 0.0.0.255

Nota: per evitare di annunciare l'intera tabella di routing Unicast al mbone, è necessario includere un elenco degli accessi con questo comando.

Se l'impostazione è simile a quella mostrata qui e si desidera propagare le route DVMRP attraverso il dominio, configurare il comando ip dvmrp unicast-routing sulle interfacce serial0 dei router A e B. Questa azione consente l'inoltro delle route DVMRP ai router adiacenti PIM che dispongono quindi di una tabella di routing DVMRP utilizzata per il protocollo RPF (Reverse Path Forwarding). Le route apprese da DVMRP hanno la precedenza su tutti gli altri protocolli, ad eccezione delle route con connessione diretta.

Propaga route DVMRP tramite il dominio

MBGP

Il protocollo MBGP (Multiprotocol Border Gateway Protocol) è un metodo di base per trasportare due set di route, uno impostata per il routing unicast e l'altro impostata per il routing multicast. Il protocollo MBGP fornisce il controllo necessario per decidere dove consentire il flusso dei pacchetti multicast. PIM utilizza le route associate al routing multicast per creare strutture di distribuzione dei dati. MBGP fornisce il percorso RPF, non la creazione dello stato multicast. PIM è ancora necessario per inoltrare i pacchetti multicast.

PIM è ancora necessario per inoltrare i pacchetti multicast

ip multicast-routing 


interface loopback0 
ip pim sparse-dense-mode 
ip address 192.168.2.2 255.255.255.0 


interface serial0 
ip address 192.168.100.1 255.255.255.0 


interface serial1 
ip pim sparse-dense-mode 
ip address 192.168.200.1 255.255.255.0 


router bgp 123 
network 192.168.100.0 nlri unicast 
network 192.168.200.0 nlri multicast 
neighbor 192.168.1.1 remote-as 321 nlri unicast multicast 
neighbor 192.168.1.1 ebgp-multihop 255 
neighbor 192.168.100.2 update-source loopback0 
neighbor 192.168.1.1 route-map setNH out 


route-map setNH permit 10 
match nlri multicast 
set ip next-hop 192.168.200.1 


route-map setNH permit 20 

ip multicast-routing 


interface loopback0 
ip pim sparse-dense-mode 
ip address 192.168.1.1 255.255.255.0 


interface serial0 
ip address 192.168.100.2 255.255.255.0 


interface serial1 
ip pim sparse-dense-mode 
ip address 192.168.200.2 255.255.255.0 


router bgp 321 
network 192.168.100.0 nlri unicast 
network 192.168.200.0 nlri multicast 
neighbor 192.168.2.2 remote-as 123 nlri unicast multicast 
neighbor 192.168.2.2 ebgp-multihop 255 
neighbor 192.168.100.1 update-source loopback0 
neighbor 192.168.2.2 route-map setNH out 


route-map setNH permit 10 
match nlri multicast 
set ip next-hop 192.168.200.2 


route-map set NH permit 20 

Se le topologie unicast e multicast sono congruenti (ad esempio, utilizzano lo stesso collegamento), la differenza principale nella configurazione è rappresentata dal comando multicast nlri. Di seguito è riportato un esempio:

network 192.168.100.0 nlri unicast multicast

Le topologie congruenti con MBGP offrono un vantaggio: anche se il traffico attraversa gli stessi percorsi, è possibile applicare policy diverse a BGP unicast e BGP multicast.

MSDP

Il protocollo MSDP (Multicast Source Discovery Protocol) connette più domini PIM-SM. Ogni dominio PIM-SM utilizza i propri RP indipendenti e non deve dipendere da RP in altri domini. MSDP consente ai domini di individuare origini multicast da altri domini. Se si utilizza anche il peer BGP con il peer MSDP, è necessario utilizzare lo stesso indirizzo IP per MSDP e per BGP. Quando MSDP esegue i controlli RPF peer, prevede che l'indirizzo peer MSDP corrisponda a quello fornito da BGP/MBGP quando esegue una ricerca della tabella di route sull'RP nel messaggio SA. Tuttavia, non è necessario eseguire BGP/MBGP con il peer MSDP se tra i peer MSDP è presente un percorso BGP/MBGP. Se non è presente alcun percorso BGP/MBGP e sono presenti più peer MSDP, è necessario utilizzare il comando ip msdp default-peer. L'esempio mostra che RP A è l'RP per il proprio dominio e RP B è l'RP per il proprio dominio.

Protocollo MSDP (Multicast Source Discovery Protocol) per la connessione di più domini PIM-SM

ip multicast-routing 


ip pim send-RP-announce loopback0 scope 16 group-list 1
ip pim send-RP-discovery scope 16 

ip msdp peer 192.168.100.2 
ip msdp sa-request 192.168.100.2 

interface loopback0
ip address <address> <mask>
ip pim sparse-dense-mode 
 
interface serial0 
ip address 192.168.100.1 255.255.255.0 
ip pim sparse-dense-mode 

ip multicast-routing 

ip pim send-RP-announce loopback0 scope 16 group-list 1
ip pim send-RP-discovery scope 16 


ip msdp peer 192.168.100.1 
ip msdp sa-request 192.168.100.1 

interface loopback0
ip address <address> <mask>
ip pim sparse-dense-mode 
 
interface serial0 
ip address 192.168.100.2 255.255.255.0 
ip pim sparse-dense-mode 

Stub Multicast Routing

Stub multicast routing consente di configurare router remoti/stub come agenti proxy IGMP. Anziché partecipare completamente al PIM, questi router di stub inoltrano i messaggi IGMP dagli host al router multicast upstream.

I router di stub inoltrano i messaggi IGMP dagli host al router multicast upstream

int s0 
ip pim sparse-dense-mode 
ip pim neighbor-filter 1 


access-list 1 deny 192.168.140.1

Il comando ip pim neighbors-filter è necessario per impedire al router 1 di riconoscere il router 2 come router adiacente PIM. Se si configura il router 1 in modalità sparse, non è necessario utilizzare il filtro adiacente. Il router 2 non deve essere eseguito in modalità sparse. In modalità densa, le sorgenti multicast di stub possono raggiungere i router della backbone.

ip multicast-routing 
int e0 
ip pim sparse-dense-mode 
ip igmp helper-address 192.168.140.2 


int s0 
ip pim sparse-dense-mode 

IGMP UDLR per collegamenti satellitari

UDLR (Unidirectional Link Routing) fornisce un metodo per l'inoltro di pacchetti multicast su un collegamento satellitare unidirezionale a reti stub con canale posteriore. Questa procedura è simile al routing multicast di stub. Senza questa funzione, il router di uplink non è in grado di individuare dinamicamente gli indirizzi di gruppi multicast IP da inoltrare tramite il collegamento unidirezionale, in quanto il router di downlink non è in grado di inviare dati al mittente.

UDLR (Unidirectional Link Routing) Fornisce un metodo per l'inoltro di pacchetti multicast

ip multicast-routing 


interface Ethernet0 
description Typical IP multicast enabled interface 
ip address 172.16.12.1 255.0.0.0 
ip pim sparse-dense-mode 


interface Ethernet1 
description Back channel which has connectivity to downlink-rtr 
ip address 172.16.11.1 255.0.0.0 
ip pim sparse-dense-mode 


interface Serial0 
description Unidirectional to downlink-rtr 
ip address 10.0.0.1 255.0.0.0 
ip pim sparse-dense-mode 
ip igmp unidirectional-link 
no keepalive 

ip multicast-routing 


interface Ethernet0 
description Typical IP multicast enabled interface 
ip address 172.16.14.2 255.0.0.0 
ip pim sparse-dense-mode 
ip igmp helper-address udl serial0 


interface Ethernet1 
description Back channel which has connectivity to downlink-rtr 
ip address 172.16.13.2 255.0.0.0 
ip pim sparse-dense-mode 


interface Serial0 
description Unidirectional to uplink-rtr 
ip address 10.0.0.2 255.0.0.0 
ip pim sparse-dense-mode 
ip igmp unidirectional-link 
no keepalive 

PIMv2 BSR

Se tutti i router della rete eseguono PIMv2, è possibile configurare un BSR anziché l'Auto-RP. BSR e Auto-RP sono molto simili. Per una configurazione BSR è necessario configurare i candidati BSR (in modo simile all'annuncio RP in Auto-RP) e i BSR (in modo simile agli agenti di mapping Auto-RP). Per configurare un modulo BSR, attenersi alla seguente procedura:

1. Nei BSR candidati configurare:

   ip pim bsr-candidate interface hash-mask-len pref

   Dove interface contiene l'indirizzo IP dei BSR candidati. È consigliabile (ma non obbligatorio) che l'hash-mask-Len sia identico in tutti i BSR candidati. Un BSR candidato con il valore pref più grande viene scelto come BSR per questo dominio.

   Di seguito è riportato un esempio di utilizzo del comando:

   ip pim bsr-candidate ethernet0 30 4

   Il BSR PIMv2 raccoglie le informazioni RP candidate e diffonde le informazioni RP-set associate a ciascun prefisso di gruppo. Per evitare singoli punti di errore, è possibile configurare più router di un dominio come BSR candidati.

   Tra i BSR candidati viene automaticamente selezionato un BSR in base ai valori delle preferenze configurati. Per poter fungere da BSR candidati, i router devono essere connessi e trovarsi nella backbone della rete anziché nell'area di connessione remota della rete.

2. Configurare i router RP candidati. L'esempio mostra un RP candidato, sull'interfaccia ethernet0, per l'intero intervallo di indirizzi dell'ambito di amministrazione:

   access-list 11 permit 239.0.0.0 0.255.255.255
   ip pim rp-candidate ethernet0 group-list 11

CGMP

Per configurare il protocollo CGMP (Group Management Protocol), configurarlo sull'interfaccia del router rivolta allo switch:

ip pim sparse-dense-mode 
ip cgmp

Quindi, configurare questo sullo switch:

set cgmp enable

Snooping IGMP

Lo snooping IGMP (Internet Group Management Protocol) è disponibile nella versione 4.1 di Catalyst 5000. Lo snooping IGMP richiede una scheda Supervisor III. Per configurare lo snooping IGMP sul router, non è necessaria alcuna configurazione diversa da PIM. È ancora necessario un router con snooping IGMP per fornire l'interrogazione IGMP.

L'esempio fornito qui mostra come abilitare lo snooping IGMP sullo switch:

Console> (enable) set igmp enable  
IGMP Snooping is enabled.  
CGMP is disabled. 

Se si tenta di abilitare IGMP ma CGMP è già abilitato, viene visualizzato quanto segue:

Console> (enable) set igmp enable  
Disable CGMP to enable IGMP Snooping feature. 

PGM

Pragmatic General Multicast (PGM) è un protocollo di trasporto multicast affidabile per applicazioni che richiedono la consegna di dati multicast ordinati, privi di duplicati, da più origini a più ricevitori. PGM garantisce che il destinatario del gruppo riceva tutti i pacchetti di dati dalle trasmissioni e dalle ritrasmissioni o sia in grado di rilevare la perdita irreversibile dei pacchetti di dati.

Nessun comando globale PGM. Il protocollo PGM viene configurato per ciascuna interfaccia con il comando ip pgm. È necessario abilitare il routing multicast sul router con PIM sull'interfaccia.

MRM

Multicast Routing Monitor (MRM) semplifica il rilevamento automatico degli errori in un'infrastruttura di routing multicast di grandi dimensioni. MRM è progettato per avvisare un amministratore di rete di problemi di routing multicast quasi in tempo reale.

MRM dispone di due componenti: tester MRM e manager MRM. Il tester MRM è un mittente o un destinatario.

MRM è disponibile a partire da Cisco IOS versione 12.0(5)T. Solo i tester e i manager MRM devono eseguire la versione Cisco IOS supportata da MRM.

Multicast Routing Monitor (MRM) Facilita il rilevamento automatico degli errori in una grande infrastruttura di routing multicast

interface Ethernet0 
  ip mrm test-sender 

interface Ethernet0 
  ip mrm test-receiver 

ip mrm manager test1 
 manager e0 group 239.1.1.1 
 senders 1 
 receivers 2 sender-list 1 


 access-list 1 permit 10.1.1.2 
 access-list 2 permit 10.1.4.2 

Di seguito è riportato l'output del comando show ip mrm manager su Test Manager:

Test_Manager# show ip mrm manager 
   Manager:test1/10.1.2.2 is not running  Beacon interval/holdtime/ttl:60/86400/32 Group:239.1.1.1, UDP port test-packet/status-report:16384/65535 Test sender: 10.1.1.2 Test receiver: 10.1.4.2

Avviare il test con il comando indicato di seguito. Il gestore test invia messaggi di controllo al mittente e al destinatario del test come configurato nei parametri del test. Il ricevitore di prova si unisce al gruppo e controlla i pacchetti di prova inviati dal mittente di prova.

Test_Manager# mrm start test1 
 *Feb  4 10:29:51.798: IP MRM test test1 starts ......  
Test_Manager#

Per visualizzare un report sullo stato per il gestore test, immettere questo comando:

Test_Manager# show ip mrm status  

IP MRM status report cache:  
Timestamp        Manager          Test Receiver   Pkt Loss/Dup (%)       Ehsr  
*Feb  4 14:12:46 10.1.2.2         10.1.4.2        1            (4%)      29  
*Feb  4 18:29:54 10.1.2.2         10.1.4.2        1            (4%)      15  
Test_Manager#

L'output mostra che il destinatario ha inviato due rapporti di stato (una riga per ogni) a un determinato timestamp. Ogni report contiene una perdita di pacchetti durante la finestra dell'intervallo (valore predefinito: un secondo). Il valore "Ehsr" mostra il valore stimato del numero di sequenza successivo del mittente del test. Se il ricevitore di prova rileva dei pacchetti duplicati, indica un numero negativo nella colonna "Pkt Loss/Dup".

Per interrompere il test, immettere questo comando:

Test_Manager# mrm stop test1 
*Feb  4 10:30:12.018: IP MRM test test1 stops  
Test_Manager# 

Durante l'esecuzione del test, il mittente MRM invia i pacchetti RTP all'indirizzo di gruppo configurato all'intervallo predefinito di 200 ms. Il ricevitore controlla (prevede) gli stessi pacchetti allo stesso intervallo predefinito. Se il destinatario rileva una perdita di pacchetto nell'intervallo di tempo predefinito di cinque secondi, invia un rapporto al manager MRM. Per visualizzare il rapporto sullo stato inviato dal ricevitore, usare il comando show ip mrm status sul manager.

Risoluzione dei problemi

Alcuni dei problemi più comuni che si verificano quando si implementa il multicast IP in una rete sono quando il router non inoltra il traffico multicast a causa di un errore RPF o di impostazioni TTL. Per una descrizione dettagliata di questi e altri problemi, sintomi e soluzioni comuni, consultare la guida alla risoluzione dei problemi del multicast IP.

Informazioni correlate

• Guida alla risoluzione dei problemi del multicast IP
• Risoluzione dei problemi relativi alle reti multicast con gli strumenti CLI
• Supporto IP multicast
• Supporto tecnico e download Cisco