IP-multicast handleiding voor probleemoplossing

Inleiding

In dit document worden gangbare problemen met en oplossingen voor IP-multicast beschreven.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies. 

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

Wanneer u multicast routing problemen oplost, is de primaire zorg het bronadres. Multicast heeft een concept van Reverse Path Forwarding (RPF)-controle. Wanneer een multicast pakket op een interface aankomt, controleert het RPF-proces om ervoor te zorgen dat deze inkomende interface de uitgaande interface is die door unicast-routing wordt gebruikt om de bron van het multicast pakket te bereiken. Dit RPF-controleproces voorkomt lusvorming. Multicast-routing stuurt geen pakket door, tenzij de bron van het pakket een RPF-controle doorgeeft. Zodra een pakket deze PDF-controle doorgeeft, wordt het pakket met multicast-routing doorgestuurd op basis van alleen het doeladres.

Als unicast-routing heeft multicast routing verschillende beschikbare protocollen, zoals Protocol Independent Multicast dense mode (PIM-DM), PIM sparse mode (PIM-SM), Distance Vector Multicast Routing Protocol (DVMRP), Multicast Border Gateway Protocol (MBGP) en Multicast Source Discovery Protocol (MSDP). De casestudy’s in dit document lopen u door het proces om verschillende problemen op te lossen. U kunt zien welke opdrachten worden gebruikt om het probleem snel te identificeren en te leren hoe u het kunt oplossen. De casestudy’s die hier worden vermeld, zijn generiek voor alle protocollen, behalve waar anders vermeld.

Router stuurt geen multicast-pakketten door naar host vanwege RPF-fout

Deze paragraaf biedt een oplossing voor het veelvoorkomende probleem van een IP-multicast RPF-fout. Dit netwerkdiagram wordt als voorbeeld gebruikt.

Network Diagram Voorbeeld van multicast RPF-fout

In dit cijfer, komen multicast pakketten in E0/0 van router 75a van een server waarvan IP adres 10.1.1.1 is en verzenden naar groep 10.224.1.1. Dit staat bekend als een (S,G) of (10.1.1.1, 10.224.1.1).

Het probleem diagnosticeren

Hosts die rechtstreeks zijn verbonden met router 75a ontvangen de multicast feed, maar hosts die rechtstreeks zijn verbonden met router 72a niet. Voer eerst de show ip mroute 224.1.1.1  bevel om activiteit op router 75a te controleren. Deze opdracht onderzoekt de multicastroute (route) voor het groepsadres 10.224.1.1:

75a#show ip mroute 10.224.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 10.224.1.1), 00:01:23/00:02:59, RP 0.0.0.0, flags: D 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00 

(10.1.1.1, 10.224.1.1), 00:01:23/00:03:00, flags: TA 
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00 

Aangezien de router PIM dense mode draait (u weet dat het dicht mode is vanwege de D vlag), negeer de *,G entry en focus op de S,G entry. Deze ingang vertelt u dat de multicast pakketten afkomstig zijn van een server waarvan het adres 10.1.1.1 is, die naar een multicast groep van 10.224.1.1 verzendt. De pakketten komen in de interface Ethernet0/0 en door:sturen uit de interface Ethernet0/1. Dit is een perfect scenario.

Voer het show ip pim neighbor bevel om te zien of router 72a de stroomopwaartse router (75a) als buur PIM toont:

ip22-72a#show ip pim neighbor
PIM Neighbor Table 
Neighbor Address  Interface          Uptime    Expires   Ver  Mode 
10.2.1.1           Ethernet3/1        2d00h     00:01:15  v2 

Van de show ip pim neighbor opdrachtoutput, ziet de PIM-buurt er goed uit.

Voer het show ip mroute  bevel om te zien of router 72a goede route heeft:

ip22-72a#show ip mroute 10.224.1.1
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, Z - Multicast Tunnel
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
 
(*, 10.224.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet3/1, Forward/Dense, 00:10:42/00:00:00
    Ethernet3/2, Forward/Dense, 00:10:42/00:00:00
 
(10.1.1.1, 10.224.1.1), 00:01:10/00:02:48, flags: 
  Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet3/1, Forward/Dense, 00:01:10/00:00:00
    Ethernet3/2, Forward/Dense, 00:00:16/00:00:00
 
ip22-72a#

U kunt zien aan de  show ip mroute 10.224.1.1  bevel dat de inkomende interface Ethernet2/0 is, terwijl Ethernet3/1 wordt verwacht.

Voer het  show ip mroute 10.224.1.1 count  bevel om te zien of om het even welk multicast verkeer voor deze groep aan router 72a aankomt en wat daarna gebeurt:

ip22-72a#show ip mroute 10.224.1.1 count
IP Multicast Statistics
3 routes using 2032 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: 10.224.1.1, Source count: 1, Packets forwarded:      0, Packets received: 471
  Source:      10.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0
ip22-72a#

U kunt aan de Andere tellingen zien dat het verkeer door RPF mislukking wordt gelaten: totaal 471 druppels, toe te schrijven aan RPF mislukking - 471...

Voer het show ip rpf   opdracht om te zien of er een RPF-fout is:

ip22-72a#show ip rpf 10.1.1.1
RPF information for ? (10.1.1.1)
  RPF interface: Ethernet2/0
  RPF neighbor: ? (0.0.0.0)
  RPF route/mask: 10.1.1.1/32
  RPF type: unicast (static)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables
ip22-72a#

Cisco IOS® berekent de RPF-interface op deze manier. De mogelijke bronnen van RPF-informatie zijn Unicast Routing Table, MBGP Routing Table, DVMRP Routing Table, en Statische Mroute Table. Wanneer u de RPF-interface berekent, wordt voornamelijk de administratieve afstand gebruikt om precies te bepalen op welke informatiebron de RPF-berekening is gebaseerd. De specifieke regels zijn:

• Alle voorgaande bronnen van RPF-gegevens worden gezocht naar een overeenkomst op het IP-adres van de bron. Wanneer u gedeelde bomen gebruikt, wordt het RP-adres gebruikt in plaats van het bronadres.

• Als meer dan één overeenkomende route wordt gevonden, wordt de route met de laagste administratieve afstand gebruikt.

• Als de administratieve afstanden gelijk zijn, wordt deze voorkeursvolgorde gebruikt:

  1. Statische routes

  2. DVMRP-routes

  3. MBGP-routes

  4. Unicast-routes

• Als er meerdere vermeldingen voor een route binnen dezelfde routetabel voorkomen, wordt de langste overeenkomende route gebruikt.

Het  show ip mroute 224.1.1.1 opdrachtoutput toont dat de RPF-interface E2/0 is, maar de inkomende interface moet E3/1 zijn.

Voer het  show ip mroute 224.1.1.1 commando om te zien waarom de RPF-interface anders is dan verwacht.

ip22-72a#show ip route 10.1.1.1
  Routing entry for 10.1.1.1/32
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Ethernet2/0
   Route metric is 0, traffic share count is 1

U kunt van deze show ip route 10.1.1.1 opdrachtoutput zien dat er een statische /32 route is, die de verkeerde interface maakt om als RPF interface worden gekozen.

Voer aanvullende debug-opdrachten in:

ip22-72a#debug ip mpacket 10.224.1.1 
*Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 len 60, not RPF interface

De pakketten worden geleverd op E3/1, wat correct is. Ze worden echter laten vallen omdat dat niet de interface is die de unicast Routing Table gebruikt voor de RPF-controle.

Opmerking: Zuiveren van pakketten is gevaarlijk. Packet debugging triggers verwerken switching van de multicast-pakketten, wat CPU-intensief is. Ook, kan het pakket het zuiveren grote output veroorzaken die de router volledig wegens langzame output aan de consolehaven kan hangen. Alvorens u pakketten zuivert, moet de speciale zorg worden genomen om logboekoutput aan de console onbruikbaar te maken, en het registreren toe te laten aan de geheugenbuffer. Om dit te bereiken, configureer geen logboekconsole en logboekregistratie gebufferde debugging. De resultaten van debug kunnen met het bevel van het showregistreren worden gezien.

Mogelijke oplossingen

U kunt de unicast-routeringstabel wijzigen om aan deze eis te voldoen of u kunt een statische route toevoegen om multicast naar RPF te dwingen een bepaalde interface uit te voeren, ongeacht wat de unicast-routeringstabel aangeeft. Voeg een statische route toe:

ip22-72a(config)#ip mroute 10.1.1.1 255.255.255.255 10.2.1.1

Deze statische route bepaalt dat om aan het adres 10.1.1.1 voor RPF, gebruik 10.2.1.1 als volgende hop te krijgen die uit interface E3/1 is.

ip22-72a#show ip rpf 10.1.1.1 
RPF information for ? (10.1.1.1) 
  RPF interface: Ethernet3/1 
  RPF neighbor: ? (10.2.1.1) 
  RPF route/mask: 10.1.1.1/32 
  RPF type: static mroute 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

De output van  show ip mroute  en  debug ip mpacket  ziet er goed uit, het aantal verzonden pakketten in  show ip mroute count verhoogt, en HostA ontvangt pakketten.

ip22-72a#show ip mroute 10.224.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 10.224.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 
    Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00 

(10.1.1.1, 10.224.1.1), 00:00:48/00:02:59, flags: CTA 
  Incoming interface: Ethernet3/1, RPF nbr 10.2.1.1, Mroute 
  Outgoing interface list: 
    Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00 

ip22-72a#show ip mroute 10.224.1.1 count
IP Multicast Statistics
3 routes using 2378 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: 10.224.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019
  Source: 10.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0
 
ip22-72a#show ip mroute 10.224.1.1 count
IP Multicast Statistics
3 routes using 2378 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: 10.224.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026
  Source: 10.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0
ip22-72a#
 

ip22-72a#debug ip mpacket 10.224.1.1 
*Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 (Ethernet3/2) len 60, mforward 
*Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 (Ethernet3/2) len 60, mforward 
*Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 (Ethernet3/2) len 60, mforward

Router stuurt geen multicast-pakketten naar host vanwege TTL-instelling van bron

Deze sectie biedt een oplossing voor het veel voorkomende probleem van IP-multicast pakketten die niet worden doorgestuurd omdat de TTL-waarde (Time To Live) is verlaagd naar nul. Dit is een veelvoorkomend probleem, aangezien er veel multicast toepassingen zijn. Deze multicast toepassingen worden hoofdzakelijk ontworpen voor het LAN gebruik, en stellen zo TTL aan een lage waarde of zelfs 1. Gebruik dit netwerkdiagram als voorbeeld. 

Multicasttoepassingen die primair zijn ontworpen voor het LAN-gebruiksvoorbeeld

Het probleem diagnosticeren

In het vorige cijfer, door:sturen de router A geen pakketten van bron(nen) aan router B die direct verbonden ontvanger is. Bekijk de resultaten van de  show ip mroute  bevel op router A om de multicast routerstaat te zien:

ROUTERA#show ip mroute 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00 

(*, 10.224.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00 

U kunt 10.224.0.40 in de uitvoer negeren aangezien alle routers zich bij deze Auto-RP ontdekkingsgroep aansluiten. Maar er wordt geen bron genoemd voor 10.224.1.1. Naast "*, 10.224.1.1" kunt u ook "10.1.1.1, 10.224.1.1" zien.

Voer de opdracht show ip rpf in om te zien of dit een PDF-probleem is:

ROUTERA#show ip rpf 10.1.1.1 
RPF information for ? (10.1.1.1) 
  RPF interface: Ethernet0/0 
  RPF neighbor: ? (0.0.0.0) - directly connected 
  RPF route/mask: 10.1.1.1/24 
  RPF type: unicast (connected) 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

Van de output, is het geen kwestie RPF. De RPF-controle wijst E0/0 om naar het IP-bronadres te gaan.

Controleer of PIM is geconfigureerd op de interfaces met de  show ip pim interface opdracht:

ROUTERA#show ip pim interface 

Address          Interface          Version/Mode    Nbr   Query     DR 
                                                    Count Intvl 
10.1.1.2          Ethernet0/0        v2/Sparse-Dense  0    30     10.1.1.2 
10.2.1.1          Ethernet0/1        v2/Sparse-Dense  2    30     10.2.1.2 

De output ziet er goed uit, dus dit is niet het probleem. Controleer of de router actief verkeer herkent met de show ip mroute active  opdracht:

ROUTERA#show ip mroute active 
Active IP Multicast Sources - sending >= 4 kbps 

Gebaseerd op de output, herkent de router geen actief verkeer.

ROUTERA#debug ip mpacket 
IP multicast packets debugging is on 

Mogelijk verzendt de ontvanger geen Internet Group Management Protocol (IGMP)-rapporten (joins) voor groep 10.224.1.1. U kunt dit controleren met de  show ip igmp group  opdracht:

ROUTERB#show ip igmp group 
IGMP Connected Group Membership 
Group Address    Interface            Uptime    Expires   Last Reporter 
224.0.1.40       Ethernet1/1          00:34:34  never     10.2.1.2 
10.224.1.1        Ethernet1/2          00:30:02  00:02:45  10.3.1.2 

10.224.1.1 is samengevoegd op E1/2, wat prima is.

PIM dense mode is een overstroming en snoei protocol, dus er zijn geen gewrichten, maar er zijn transplantaties. Aangezien router B geen vloed van router A heeft ontvangen, weet het niet waar te om een transplantatie te verzenden.

U kunt controleren om te zien of het een TTL-probleem is met de snuiffer opname en ook gezien met show ip traffic  opdracht:

ROUTERA#show ip traffic 
IP statistics: 
  Rcvd:  248756 total, 1185 local destination 
         0 format errors, 0 checksum errors, 63744 bad hop count 
         0 unknown protocol, 0 not a gateway 
         0 security failures, 0 bad options, 0 with options 

De output toont 63744 slechte hoptellingen. Elke keer dat u deze opdracht typt, neemt de slechte hoptelling toe. Dit is een sterke aanwijzing dat de afzender pakketten met een TTL=1 verzendt, welke router A decrements aan nul. Dit resulteert in een verhoging van het slechte hoptellingsveld.

Mogelijke oplossingen

Om het probleem op te lossen, moet u de TTL verhogen. Dit gebeurt op het toepassingsniveau op de Afzender. Raadpleeg voor meer informatie uw gebruikshandleiding voor multicast-toepassingen.

Zodra dit wordt gedaan, ziet router A er als dit uit:

ROUTERA#show ip mroute 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00 

(*, 10.224.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00 

(10.1.1.1, 10.224.1.1), 00:19:24/00:02:59, flags: TA 
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00 

Dit is het soort uitvoer dat je wilt zien.

Op router B ziet u:

ROUTERB#show ip mroute 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00 

(*, 10.224.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00 
    Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00 

(10.1.1.1, 10.224.1.1), 00:17:46/00:02:59, flags: CTA 
  Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1 
  Outgoing interface list: 
    Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00

Router stuurt geen multicast-pakketten door vanwege TTL-drempel van router

Deze sectie biedt een oplossing voor het algemene probleem waar de TTL-drempel te laag is ingesteld, zodat IP-multicast verkeer de ontvanger niet bereikt. Dit netwerkdiagram wordt als voorbeeld gebruikt.

TTL-drempel is te laag, zodat IP-multicast verkeer de ontvanger niet bereikt

Het probleem diagnosticeren

In het vorige cijfer, ontvangt de ontvanger geen multicast pakketten van de Bron. Er kunnen verschillende routers zijn tussen de bron en router 75a. Kijk eerst naar router 75a, omdat het direct verbonden is met de ontvanger.

ip22-75a#show ip mroute 10.224.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 10.224.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00 

(10.1.1.1, 10.224.1.1), 00:01:02/00:01:57, flags: CTA 
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00 

De output toont router 75a voorwaartse pakketten uit Ethernet0/1. Om absoluut zeker te zijn zal router 75a de pakketten doorsturen, inschakelen  debug alleen voor deze bron en multicast groep:

ip22-75a#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z. 
ip22-75a(config)#access-list 101 permit udp host 10.1.1.1 host 10.224.1.1 
ip22-75a(config)#end 
ip22-75a#debug ip mpacket 101 
IP multicast packets debugging is on for access list 101 
ip22-75a# 
*Jan 17 09:04:08.714: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied 
*Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied 
*Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied

Het  debug berichten geven aan dat router 75a de multicast-pakketten niet doorstuurt omdat de TTL-drempel is bereikt. Bekijk de routerconfiguratie om te zien of u de reden kunt vinden. Deze output laat de schuldige zien:

interface Ethernet0/1 
 ip address 10.2.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
 ip multicast ttl-threshold 15 

De router heeft een TTL-drempel van 15, maar dit betekent niet dat iets groter dan een TTL van 15 niet wordt verzonden. Eigenlijk is het tegenovergestelde waar. De aanvraag wordt verzonden met een TTL van 15. Tegen de tijd dat het aan router 75a wordt, hebben de multicast pakketten een TTL minder dan 15.

Het  ip multicast ttl-threshold  opdracht betekent dat pakketten met een TTL lager dan de opgegeven drempel, in dit geval 15, niet worden doorgestuurd. Deze opdracht wordt meestal gebruikt om een rand te geven om intern multicast-verkeer te voorkomen dat het intranet wordt verlaten.

Mogelijke oplossingen

Verwijder de  ip multicast ttl-threshold  opdracht met geen vorm van deze opdracht, die terugkeert naar de standaard TTL-drempelwaarde van 0, of de TTL-drempel verlagen zodat het verkeer kan passeren.

Meervoudige gelijkwaardige paden resulteren in ongewenst RPF-gedrag

Deze paragraaf laat zien hoe kostenpaden die gelijk zijn aan een multicastbron ongewenste RPF-gedrag kunnen veroorzaken. Ook wordt beschreven hoe IP-multicast moet worden geconfigureerd om dit gedrag te voorkomen. Dit netwerkdiagram wordt als voorbeeld gebruikt.

Gelijke Kostenpaden aan een multicastbron veroorzaakt ongewenst RPF-gedrag

Het probleem diagnosticeren

In het cijfer, router 75b heeft drie gelijke kostenwegen terug naar de Bron (10.1.1.1), en het kiest een verbinding die u niet zijn eerste keus als RPF-verbinding wilt zijn.

Wanneer geconfronteerd met meerdere gelijkwaardige kostenpaden naar een bron, kiest IP multicast de interface die een Protocol Independent Multicast (PIM)-buur heeft met het hoogste IP-adres als de inkomende interface en verstuurt vervolgens prunes naar PIM-buren op de andere koppelingen.

Mogelijke oplossingen

Om de interface IP multicast te veranderen verkiest als zijn inkomende interface, kunt u één van deze doen:

• Configureer alleen PIM op de interfaces waarvoor u multicast wilt verplaatsen, wat betekent dat u multicast-redundantie verliest.

• Verander de subnetten zodat het hoogste IP adres op de link is die u de primaire multicast link wilt zijn.

• Maak een statische multicastroute (mroute) die de voorkeursmulticast interface aangeeft, wat betekent dat u multicast-redundantie verliest.

Als voorbeeld, wordt een statische route gecreëerd.

Alvorens u een statische route installeert, ziet u in deze output dat de routeringstabel drie gelijke kostenroutes voor het bronadres 10.1.1.1 heeft. De RPF-informatie geeft aan dat de RPF-interface E1/3 is:

ip22-75b#show ip route 10.1.1.1 
Routing entry for 10.1.1.1/24 
  Known via "ospf 1", distance 110, metric 20, type intra area 
  Redistributing via ospf 1 
  Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago 
  Routing Descriptor Blocks: 
  * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 
      Route metric is 20, traffic share count is 1 
    10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 
      Route metric is 20, traffic share count is 1 
    10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 
      Route metric is 20, traffic share count is 1 

ip22-75b#show ip rpf 10.1.1.1 
RPF information for ? (10.1.1.1) 
  RPF interface: Ethernet1/3 
  RPF neighbor: ? (10.4.1.1) 
  RPF route/mask: 10.1.1.1/24 
  RPF type: unicast (ospf 1) 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

ip22-75b#show ip mroute 10.224.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 10.224.1.1), 01:30:34/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 01:30:34/00:00:00 
    Ethernet1/1, Forward/Sparse-Dense, 01:30:35/00:00:00 
    Ethernet1/2, Forward/Sparse-Dense, 01:30:35/00:00:00 
    Ethernet1/3, Forward/Sparse-Dense, 00:24:22/00:00:00 

(10.1.1.1, 10.224.1.1), 01:30:35/00:02:59, flags: CT 
  Incoming interface: Ethernet1/3, RPF nbr 10.4.1.1 
  Outgoing interface list: 
    Ethernet1/1, Prune/Sparse-Dense, 01:30:35/00:02:32 
    Ethernet1/4, Forward/Sparse-Dense, 01:30:35/00:00:00 
    Ethernet1/2, Prune/Sparse-Dense, 00:24:22/00:02:42 

Nadat u de statische route hebt geconfigureerd, ziet u in deze uitvoer dat de RPF-interface is veranderd in E1/1:

ip22-75b#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
ip22-75b(config)#ip mroute 0.0.0.0 0.0.0.0 10.2.1.1 
ip22-75b(config)#end 

ip22-75b#show ip rpf 10.1.1.1 
RPF information for ? (10.1.1.1) 
  RPF interface: Ethernet1/1 
  RPF neighbor: ? (10.2.1.1) 
  RPF route/mask: 10.1.1.1/0 
  RPF type: static mroute 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

ip22-75b#show ip route 10.1.1.1 
Routing entry for 10.1.1.1/24 
  Known via "ospf 1", distance 110, metric 20, type intra area 
  Redistributing via ospf 1 
  Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago 
  Routing Descriptor Blocks: 
  * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 
      Route metric is 20, traffic share count is 1 
    10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 
      Route metric is 20, traffic share count is 1 
    10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 
      Route metric is 20, traffic share count is 1 

ip22-75b#show ip mroute 10.224.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 10.224.1.1), 01:31:29/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 01:31:29/00:00:00 
    Ethernet1/1, Forward/Sparse-Dense, 01:31:30/00:00:00 
    Ethernet1/2, Forward/Sparse-Dense, 01:31:30/00:00:00 
    Ethernet1/3, Forward/Sparse-Dense, 00:25:17/00:00:00 

(10.1.1.1, 10.224.1.1), 01:31:30/00:02:59, flags: CT 
  Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1, Mroute 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 01:31:30/00:00:00 
    Ethernet1/2, Prune/Sparse-Dense, 00:25:17/00:01:47 
    Ethernet1/3, Prune/Sparse-Dense, 00:00:31/00:02:28

Waarom wordt de taakverdeling voor IP-multicast niet over alle beschikbare gelijkwaardige paden verdeeld?

Deze sectie biedt een oplossing voor het veel voorkomende probleem hoe u IP-multicast kunt configureren om taakverdeling over alle beschikbare paden met gelijke kosten te waarborgen. Dit netwerkdiagram wordt als voorbeeld gebruikt.

Opmerking: voordat u gesplitste IP-multicast verkeer over gelijkwaardige paden via een tunnel laadt, configureer CEF-taakverdeling per pakket of anders kunnen de GRE-pakketten niet per pakket worden gebalanceerd. Zie IP-multicast verkeer splitsen via ECMP voor andere methoden om delen in multicast-omgevingen te laden.

IP-multicast configureren voor taakverdeling over alle beschikbare gelijkwaardige paden

In het cijfer, router 75b heeft drie gelijke-kosten wegen terug naar de Bron (10.1.1.1). U wilt het multicast verkeer over alle drie de verbindingen laden-in evenwicht brengen.

Mogelijke oplossingen

Zoals u in de sectie Meervoudige Gelijke Kosten resulteert in Ongewenst RPF-gedrag hebt gezien, kiest Protocol Independent Multicast (PIM) slechts één interface voor de RPF-controle en snoeit de anderen. Dit betekent dat taakverdeling niet plaatsvindt. Om load-balance te maken, moet u PIM verwijderen uit de redundante links en een tunnel maken tussen router 75a en router 75b. U kunt dan laden-balans op het koppelingsniveau, en IP loopt over de tunnel.

Dit zijn de configuraties voor de tunnel.

interface Tunnel0 
 ip address 10.6.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet0/0 
 tunnel destination 10.5.1.1 
! 
interface Ethernet0/0 
 ip address 10.1.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
! 
interface Ethernet0/1 
 ip address 10.2.1.1 255.255.255.0 
! 
interface Ethernet0/2 
 ip address 10.3.1.1 255.255.255.0 
! 
interface Ethernet0/3 
 ip address 10.4.1.1 255.255.255.0

interface Tunnel0 
 ip address 10.6.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet1/4 
 tunnel destination 10.1.1.2 
! 
interface Ethernet1/1 
 ip address 10.2.1.2 255.255.255.0 
! 
interface Ethernet1/2 
 ip address 10.3.1.2 255.255.255.0 
! 
interface Ethernet1/3 
 ip address 10.4.1.2 255.255.255.0 
! 
interface Ethernet1/4 
 ip address 10.5.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
! 
ip mroute 0.0.0.0 0.0.0.0 Tunnel0

Nadat u de tunnel hebt geconfigureerd, voert u de show ip mroute  opdracht om de multicastroute (route) voor de groep te zien:

ip22-75a#show ip mroute 10.224.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 10.224.1.1), 02:40:31/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:20:55/00:00:00 

(10.1.1.1, 10.224.1.1), 02:40:32/00:03:29, flags: TA 
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 

ip22-75b#show ip mroute 10.224.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 10.224.1.1), 02:42:20/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Tunnel0, Forward/Sparse-Dense, 00:22:53/00:00:00 
    Ethernet1/4, Forward/Sparse-Dense, 02:42:20/00:00:00 

(10.1.1.1, 10.224.1.1), 00:22:53/00:02:59, flags: CT 
  Incoming interface: Tunnel0, RPF nbr 10.6.1.1, Mroute 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 00:22:53/00:00:00 

Om te controleren dat de multicast gegevens in gelijke mate over de drie verbindingen worden verdeeld, bekijk de interfacegegevens van router 75a.

De inkomende interface is 9000 bits/sec:

ip22-75a#show interface e0/0 
. 
. 
  5 minute input rate 9000 bits/sec, 20 packets/sec 

De drie uitgaande interfaces elk tonen 3000 bits/sec:

ip22-75a#show interface e0/1 
. 
. 
  5 minute output rate 3000 bits/sec, 7 packets/sec 

  
ip22-75a#show interface e0/2 
. 
. 
  5 minute output rate 3000 bits/sec, 7 packets/sec 


ip22-75a#show interface e0/3 
. 
. 
  5 minute output rate 3000 bits/sec, 7 packets/sec

Wanneer u de IP-multicast "INInvalid_RP_JOINT" foutmeldingen op de router ontvangt

Deze paragraaf biedt oplossingen voor het veelvoorkomende probleem van de foutmelding "INVALIDATE_RP_JOINT" voor IP-multicast.

Het probleem diagnosticeren - Deel 1

Deze foutmeldingen worden op het Rendezvous Point (RP) ontvangen:

00:55:15: %PIM-6-INVALID_RP_JOIN: Received (*, 10.224.1.1) 
Join from 10.1.6.2 for invalid RP 10.1.5.4 
00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 10.224.1.1) 
Join from 10.1.6.2 for invalid RP 10.1.5.4 

Het document van de Foutberichten van het Systeem van Cisco IOS-Software legt uit wat deze fout veroorzaakt: een stroomafwaartse router PIM verzond een toetreden bericht voor de gedeelde boom, die deze router niet wil goedkeuren. Dit gedrag geeft aan dat deze router alleen downstream routers toelaat om deel te nemen aan een specifieke RP.

Men vermoedt dat het filtreert. U moet de configuratie van de router bekijken:

interface Ethernet0/0 
 ip address 10.1.5.4 255.255.255.0 
 ip pim sparse-dense-mode 
! 
ip pim accept-rp 10.2.2.2 8 
ip pim send-rp-announce Ethernet0/0 scope 15 
ip pim send-rp-discovery scope 15 
! 
access-list 8 permit 224.0.0.0 0.255.255.255 

Wat is de accept-rp  een verklaring in de configuratie die zou moeten volbrengen? In IP Multicast Routing Commands staat dat "om een router te configureren voor het accepteren van samenvoegingen of snoeien die bestemd zijn voor een bepaalde RP en voor een specifieke lijst van groepen, gebruik maken van de ip pim accept-rp globale configuratieopdracht. Om die controle te verwijderen, gebruik het nr formulier van dit bevel."

Wanneer u de ip pim accept-rp  het bevel, verdwijnen de berichten. Het bevel dat het probleem veroorzaakt werd gevonden, maar wat als u dat bevel in de configuratie wilt houden? U kunt het verkeerde RP-adres toestaan. Voer het show ip pim rp mapping  opdracht om het juiste RP-adres te zien:

ip22-75a#show ip pim rp mapping 
PIM Group-to-RP Mappings 
This system is an RP (Auto-RP) 
This system is an RP-mapping agent 

Group(s) 224.0.0.0/4 
  RP 10.1.5.4 (?), v2v1 
    Info source: 10.1.5.4 (?), via Auto-RP 
         Uptime: 01:00:48, expires: 00:02:07

Gebaseerd op de output, is 10.1.5.4 de enige RP die via Auto-RP of anders wordt geleerd. Deze router is echter alleen de RP voor de groepen 224.0.0.0/4. De pim accept-rp de verklaring in de configuratie is onjuist.

Mogelijke oplossingen

De oplossing is om het IP-adres in het  ip pim accept-rp   verklaring:

Wijzig deze verklaring:

ip pim accept-rp 10.2.2.2 8

Hiertoe:

ip pim accept-rp 10.1.5.4 8

U kunt de verklaring ook wijzigen om te accepteren wat zich in het automatisch rp cache bevindt en ervoor zorgen dat de toegangslijst (8 in dit voorbeeld) de benodigde multicast groepsbereik toestaat. Hierna volgt een voorbeeld:

ip pim accept-rp auto-rp

access-list 8 permit 224.0.0.0 0.255.255.255

Het probleem diagnosticeren - Deel 2

Deze foutenmelding wordt gezien op router2.

router2#
*Aug 12 15:18:17.891:
      %PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40)
      Join from  0.0.0.0 for invalid RP 10.2.1.1

Controleer of router2 de RP is voor groep 10.224.1.1:

router2#show ip pim rp map
PIM Group-to-RP Mappings
 
Group(s) 224.0.0.0/4
  RP 10.1.1.1 (?), v2v1
    Info source: 10.1.1.1 (?), elected via Auto-RP
         Uptime: 00:21:26, expires: 00:02:24
router2#

De referentieprijs voor 10.224.1.1 is 10.1.1.1.

Controleer of dit een van de interfaces van router2 is:

router2#show ip interface brief 
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                10.1.1.2         YES NVRAM  up                    up      
Ethernet1/0                10.2.1.1         YES NVRAM  up                    up      
Ethernet2/0                unassigned      YES NVRAM  administratively down down    
router2#

Aangezien router2 geen RP is, moet het dit RP-Join pakket niet ontvangen hebben. Controleer waarom de downstream router de Join naar router2 heeft gestuurd, terwijl deze niet:

router3#show ip pim rp map
PIM Group-to-RP Mappings
 
Group(s) 224.0.0.0/4
  RP 10.1.1.1 (?), v2v1
    Info source: 10.1.1.1 (?), elected via Auto-RP
         Uptime: 00:24:30, expires: 00:02:16
Group(s): 224.0.0.0/4, Static-Override
    RP: 10.2.1.1 (?)
router3#

Zoals u ziet, router3 heeft statisch RP-informatie geconfigureerd en wijst naar router2, die onjuist is. Dit verklaart waarom router3 RP-Join naar router2 verzendt.

Mogelijke oplossingen

Of maak router2 de RP voor de groep 10.224.1.1 of verander de configuratie op router3 zodat het verwijst naar het juiste RP-adres.

router3#show run | i rp
ip pim rp-address 10.2.1.1 override
router3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
router3(config)#no ip pim rp-address 10.2.1.1 override
router3(config)#exit
router3#

Nadat de configuratie op router3 is gecorrigeerd, verwijst router3 naar het juiste RP-adres en stopt de foutmelding.

router3#show ip pim rp map
PIM Group-to-RP Mappings
 
Group(s) 224.0.0.0/4
  RP 10.1.1.1 (?), v2v1
    Info source: 10.1.1.1 (?), elected via Auto-RP
         Uptime: 00:30:45, expires: 00:02:02
router3#

CGMP voorkomt niet dat multicastpakketten overstromen

Deze sectie legt uit hoe ongewenste overstroming van multicastpakketten kan optreden wanneer Cisco Group Management Protocol (CGMP) niet op alle routers op een bepaalde subnetprocessor is ingeschakeld, en hoe dit probleem kan worden voorkomen. Dit netwerkdiagram wordt als voorbeeld gebruikt.

Cisco Group Management Protocol (CGMP) is niet ingeschakeld

Het probleem diagnosticeren

In het cijfer, toont de statische CAM-tabel in Catalyst 5000 Switch A geen van de juiste poorten die zijn bevolkt. De CGMP-geconfigureerde router verzendt geen CGMP-pakketten.

CGMP is correct geconfigureerd met de set cgmp enable  switch A en de ip cgmp  opdracht op de E0/2 interface van router 75a. Er worden echter geen multicastgroepen gezien op Switch A wanneer de  show multicast group  de opdracht wordt gegeven:

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 

Total Number of Entries = 0

De output van dit bevel moet elke poort tonen die een CGMP-geconfigureerde router erop heeft (poort 2/3) en elke poort die een geïnteresseerde ontvanger erop heeft (poort 2/6). Aangezien 0 vermeld is, kunt u ervan uitgaan dat alle poorten onnodig overstroomd zijn met multicast-verkeer, of ze dat nu willen of niet.

Opmerkingen

Controleer of er Protocol Independent Multicast (PIM)-buren op router 75a zijn:

ip22-75a#show ip pim neighbor 
PIM Neighbor Table 
Neighbor Address  Interface          Uptime    Expires   Ver  Mode 
10.2.1.1           Ethernet0/2        00:07:41  00:01:34  v2 

De output toont aan dat router 75a router 75b als geldige PIM buur door Switch A kan zien.

Controleer nu of u de juiste multicast route (route) informatie over de routers ontvangt:

ip22-75a#show ip mroute 10.224.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 10.224.1.1), 00:14:55/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/2, Forward/Sparse-Dense, 00:14:55/00:00:00 

(10.1.1.1, 10.224.1.1), 00:14:56/00:02:59, flags: CTA 
  Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/2, Forward/Sparse-Dense, 00:14:56/00:00:00 

De output toont router 75a voorwaarts de multicast pakketten uit E0/2 naar Switch A. Deze output toont router 75b de multicast pakketten krijgt en hen correct door:sturen:

ip22-75b#show ip mroute 10.224.1.1 
IP Multicast Routing Table 
Flags: D - Dense, S - Sparse, 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 - Advertised via MSDP 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 

(*, 10.224.1.1), 00:17:57/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet1/3, Forward/Sparse-Dense, 00:17:57/00:00:00 
    Ethernet1/4, Forward/Sparse-Dense, 00:17:57/00:00:00 

(10.1.1.1, 10.224.1.1), 00:00:35/00:02:59, flags: CTA 
  Incoming interface: Ethernet1/3, RPF nbr 10.2.1.2 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00 

Vanuit het oogpunt van Switch A, ziet u dat het router 75a buiten poort 2/3 ziet.

Console> (enable) show multicast router 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 

Port       Vlan 
---------  ---------------- 
 2/3       6 

Total Number of Entries = 1 

Alles wat tot nu toe gezien is, lijkt prima. Voer enkele gegevens in  debug opdrachten op router 75a om te zien wat u kunt vinden:

ip22-75a#debug ip cgmp 
CGMP debugging is on 
*Feb  8 12:45:22.206: CGMP: Sending self Join on Ethernet0/2 
*Feb  8 12:45:22.206:       GDA 0000.0000.0000, USA 00d0.ff2f.a002 
*Feb  8 12:46:22.234: CGMP: Sending self Join on Ethernet0/2 
*Feb  8 12:46:22.234:       GDA 0000.0000.0000, USA 00d0.ff2f.a002 
*Feb  8 12:47:22.262: CGMP: Sending self Join on Ethernet0/2 
*Feb  8 12:47:22.262:       GDA 0000.0000.0000, USA 00d0.ff2f.a002 

In de output, is 0000.000.0000 het adres van alle groepen en gebruikt wanneer de routers CGMP toetreden/verlaat berichten verzenden zodat kunnen de switches routerpoorten bevolken. GDA staat voor Group Destination Address in Media Access Control (MAC) en USA staat voor Unicast Source Address. Dit is het adres van de host die het IGMP-rapport heeft gegenereerd waarvoor dit CGMP-bericht is gegenereerd. In dit geval is het het MAC-adres voor de router 75a interface E0/2. Het MAC-adres voor E0/2 van router 75a is te zien met de  show interface  bevel zoals hier gezien:

ip22-75a#show interface e0/2 
Ethernet0/2 is up, line protocol is up 
  Hardware is cxBus Ethernet, address is 00d0.ff2f.a002 (bia 00d0.ff2f.a002)

Bovendien kunt u dit periodiek zien wanneer de  debug ip igmp  De opdracht is ingeschakeld:

*Feb  8 12:51:41.854: IGMP: Received v2 Report from 10.2.1.3 (Ethernet0/2) for 10.224.1.1

U ziet echter achteraf geen corresponderend CGMP-pakket van router 75a. Dit betekent dat router 75a IGMP-rapporten ontvangt, maar niet de noodzakelijke CGMP-pakketten genereert om Switch A te helpen te weten welke poorten moeten worden geblokkeerd. Dit is iets dat van router 75a wordt verwacht als het de vraag IGMP is. Deze output van router 75a vertelt ons waarom het verwachte gedrag niet voorkomt:

ip22-75a#show ip igmp interface e0/2 
Ethernet0/2 is up, line protocol is up 
  Internet address is 10.2.1.2/24 
  IGMP is enabled on interface 
  Current IGMP version is 2 
  CGMP is enabled 
  IGMP query interval is 60 seconds 
  IGMP querier timeout is 120 seconds 
  IGMP max query response time is 10 seconds 
  Last member query response interval is 1000 ms 
  Inbound IGMP access group is not set 
  IGMP activity: 3 joins, 1 leaves 
  Multicast routing is enabled on interface 
  Multicast TTL threshold is 0 
  Multicast designated router (DR) is 10.2.1.2 (this system) 
  IGMP querying router is 10.2.1.1 
  No multicast groups joined 

Als u twee routers hebt op dezelfde subnetverbinding en u beide voor CGMP configureert, kan slechts één CGMP-pakketten verzenden. De router die de CGMP-pakketten verstuurt, is de IGMP-router die de router doorzoekt. Dit betekent de router met het laagste unicast IP-adres van de IGMP-enabled routers.

In dit geval is IGMP ingeschakeld voor zowel Routers 75a als Router 75b (router 75b is IGMP querying router geworden), maar alleen router 75a heeft CGMP ingeschakeld. Aangezien router 75a niet de IGMP querying router is, worden er geen CGMP-pakketten verzonden.

Mogelijke oplossingen

Om het probleem op te lossen moet u CGMP configureren op de IGMP-querying router. In dit geval, router 75b. Schakel eerst de machine in debug opdrachten op router 75b:

ip22-75b#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
ip22-75b(config)#int e 1/3 
ip22-75b(config-if)#ip cgmp 
ip22-75b(config-if)#end 
ip22-75b#debug ip cgmp 
ip22-75b#debug ip igmp 
*Feb  8 12:58:42.422: IGMP: Received v2 Report from 10.2.1.3 (Ethernet1/3) for 10.224.1.1 
*Feb  8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 
*Feb  8 12:58:42.422:       from 10.2.1.3 for 10.224.1.1 
*Feb  8 12:58:42.422: CGMP: Sending Join on Ethernet1/3 
*Feb  8 12:58:42.422:       GDA 0100.5e01.0101, USA 0030.b655.a859 

Router 75b ontvangt een IGMP-rapport van 10.2.1.3 voor groep 10.24.1.1. Vervolgens wordt een CGMP-lid naar Switch A gestuurd voor het MAC-equivalent van 10.224.1.1 met het MAC-adres (VS) van de 10.2.1.3 geïnteresseerde host. Switch A weet welke poort op die host staat, dus markeert het als open en blokkeert de andere.

Het moet nu gaan om Switch A:

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 
6     01-00-5e-00-01-28             2/3-4 
6     01-00-5e-01-01-01             2/3-4,2/6 

Total Number of Entries = 2 

Dit is veel beter. De pakketten 10.224.1.1 (01-00-5e-01-01-01) worden alleen verzonden als de poorten 2/3, 2/4 en 2/6 op Switch A zijn ingesteld. De overstromingen in alle andere havens zijn gestopt. Het totale aantal inzendingen is nu correct vermeld als 2. Het MAC-adres 01-00-5e-00-01-28 is afkomstig van het multicastadres 224.0.1.40, dat wordt gebruikt voor CGMP-zelftoetredingen.

CGMP voorkomt niet dat multicastpakketten overstromen, vanwege plaatsing van bron/ontvanger

Deze sectie biedt een oplossing voor het veel voorkomende probleem van een Catalyst Switch die verkeer naar elke poort overspoelt, in plaats van alleen naar de juiste host. Dit netwerkdiagram wordt als voorbeeld gebruikt.

Catalyst Switch die verkeer naar elke poort overspoelt

Het probleem diagnosticeren

In de afbeelding worden de routers 75a en 75b en Catalyst 5000 (Switch A) correct geconfigureerd voor multicast en Cisco Group Management Protocol (CGMP). De host krijgt het multicast verkeer. Maar dat geldt ook voor elke andere host van Switch A. Switch A die het verkeer uit elke poort overspoelt, wat betekent dat CGMP niet werkt.

De output van de  show multicast group de opdracht op Switch A ziet er als volgt uit:

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 
6     01-00-5e-00-01-28             2/3-4 

Total Number of Entries = 1 

U kunt uit de output zien dat de enige groep 224.0.1.40 is, die door de router wordt gebruikt wanneer het CGMP zelf-toetreedt voor de auto-RP groep verzendt. Hoe komt het dat er geen andere groepen zijn?

Mogelijke oplossingen

Om de oplossing te kunnen begrijpen, moet u begrijpen hoe CGMP zich onder bepaalde omstandigheden gedraagt. Een CGMP-enabled router stuurt CGMP-leden naar een switch om de switch te informeren over hosts die geïnteresseerd zijn in een bepaalde multicast groep. De switch kijkt omhoog de MAC-adressen voor deze hosts in zijn CAM-tabel, dan forwards multicast-pakketten uit de poorten met geïnteresseerde hosts en blokkeert alle andere poorten van het doorsturen van multicast-pakketten.

Een router stuurt CGMP zelf-toetreedt een CGMP-enabled interface als deze multicastpakketten ontvangt van een bron die zich op dezelfde interface bevindt waarop CGMP is ingeschakeld (de router).

Als de bron zich bijvoorbeeld op hetzelfde subnet (VLAN), 10.2.1.0/24, bevond als de routers 75a en 75b, zou CGMP perfect werken. De router, wanneer het pakketten uit de bron identificeert, zou een CGMP zelf-toetreden naar de switch verzenden, die dan dynamisch zou leren welke poorten de router is en alle andere poorten zou blokkeren van het doorsturen van multicastpakketten.

Een router stuurt CGMP-verbindingen als een CGMP-interface als deze IGMP-rapporten van een host ontvangt op dezelfde interface als waarop CGMP is ingeschakeld (de router).

Een ander voorbeeld is als je een geïnteresseerde host op dit zelfde VLAN had. In dat geval, wanneer een CGMP-enabled router een Internet Group Management Protocol (IGMP)-rapport ontving van een host die geïnteresseerd is in een bepaalde multicast groep, zou de router een CGMP-lid verzenden. De koppeling geeft het MAC-adres (Media Access Control) aan van de host die wil toetreden en de groep waar het lid van wil worden. Catalyst 5000 zou dan zijn CAM-tabel controleren op het host MAC-adres, de bijbehorende poort op de multicast groepslijst zetten en alle andere ongeïnteresseerde poorten blokkeren.

Het zelfde is niet waar wanneer de bron en de geïnteresseerde host(s) zich op een andere subnetverbinding bevinden dan het CGMP-enabled subnetwerkknooppunt (VLAN). Multicastpakketten die van de bron komen, activeren de router niet om CGMP-zelf-toetredingen naar de switch te verzenden. Daarom komen de pakketjes in de switch terecht en komen ze overal binnen VLAN overstroomd. Dit scenario gaat door tot een host in het VLAN, die van een poort op de switch komt, een IGMP-verbinding verstuurt. Alleen met het ontvangen van een IGMP-rapport stuurt de router een CGMP-pakket, waardoor de switch vervolgens de juiste hostpoort toevoegt als doorsturen en alle andere poorten geblokkeerd zijn (afgezien van de routerpoorten).

Voor CGMP om in deze doorvoer-type topologie te werken, kunt u een host aan hetzelfde VLAN toevoegen als Routers 75a en 75b, zoals in dit netwerkdiagram.

Voeg een host toe aan hetzelfde VLAN als routers 75a en 75b

Of verplaats de bron op hetzelfde subnet als Routers 75a en 75b, zoals in dit voorbeeld.

De bron op hetzelfde subnet verplaatsen als routers 75a en 75b

Verplaats de bron naar hetzelfde subnetje en controleer vervolgens de uitvoer van Switch A:

Console> (enable) show multicast router 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 

Port       Vlan 
---------  ---------------- 
 2/3       6 
 2/4       6 

Total Number of Entries = 2 
'*' - Configured 
Console> (enable) 

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 
6     01-00-5e-00-01-28             2/3-4 
6     01-00-5e-01-01-01             2/3-4 

Total Number of Entries = 2 

CGMP voorkomt niet dat multicast-pakketten naar bepaalde groepsadressen vloeien

Deze paragraaf legt uit waarom sommige multicast IP-adressen ervoor zorgen dat Cisco Group Management Protocol (CGMP) multicast verkeer naar alle poorten op een lokaal netwerk (LAN) doorloopt. Wanneer u het multicast groepsadres 10.225.0.1 gebruikt, werkt CGMP niet. Het overspoelt de multicast stroom uit alle switch poorten en verspilt bandbreedte. Als u het adres echter wijzigt in 10.225.1.1 CGMP werkt prima. Kunt u 10.225.0.1 gebruiken omdat het geen geregistreerd adres voor een routeringsprotocol is?

Mogelijke oplossingen

Eerst, is het belangrijk om te begrijpen hoe Layer 3 multicast-adressen aan Layer 2 multicast-adressen in kaart worden gebracht. Alle IP multicast frames gebruiken IEEE MAC-laagadressen die beginnen met de 24-bits prefix van 0x0100.5e. Wanneer u Layer 3 aan Layer 2-adressen toewijst, worden de 23-bits van Layer 3-multicast adressen in de 23-bits van de lage volgorde van het IEEE MAC-adres toegewezen.

Een ander belangrijk feit om te begrijpen is dat er 28 bits unieke adresruimte zijn voor een IP-multicast adres (32 bits min de eerste 4 bits die het prefix 1110 klasse D bevatten). Aangezien er slechts 23 bits zijn aangesloten op het IEEE MAC-adres, blijven er 5 bits van overlap over. Dit betekent dat meerdere Layer 3 multicast-adressen kunnen worden toegewezen aan dezelfde Layer 2 multicast-adres.

Voorbeeld:

10.244.0.1 = 1110 0000.0000 0000.0000 0000.0000 0001 in binary
low order 23 bits =    000 0000.0000 0000.0000 0001
hex equivalent    =     0    0    0    0    0    1
result of mapping = 0x0100.5e00.0001


10.244.128.0 = 1110 0000.1000 0000.0000 0000.0000 0001 in binary
low order 23 bits =      000 0000.0000 0000.0000 0001
hex equivalent    =       0    0    0     0    0    1
result of mapping = 0x0100.5e00.0001

Opmerking in het voorbeeld zowel 10.244.0.1 als 10.244.128.0 kaart naar dezelfde Layer 2 multicast-adres.

Nu u weet hoe Layer 3 tot Layer 2 multicast-adressen in kaart worden gebracht, gaat u verder naar de specifieke oplossing voor dit probleem.

Switch A overstromingen multicast pakketten naar 24.0.0.x omdat die adressen link-lokaal zijn en u wilt ervoor zorgen link-lokale adressen aan alle apparaten op het Local Area Network (LAN) te krijgen. Catalyst switches overspoelen ook multicast-pakketten naar andere multicast-adressen die MAC-niveau ambigu zijn met 24.0.0.x (bijvoorbeeld 10.24.0.1 en 10.225.0.1 beide kaart naar 0100.5e00.0001). De switch overspoelt de multicast pakketten die voor deze link zijn bestemd, lokale adressen of CGMP is ingeschakeld of niet.

Daarom moet de multicast toepassing het gebruik van klasse D adressen vermijden die aan een Layer 2 multicast adres van 0100.5e00.00xx in kaart brengen, waar xx 00 door FF in hexadecimaal kan zijn. Dit bestaat uit deze klassenD-adressen:

224.0.0.x (x = 0 to 255)
225.0.0.x 
.
239.0.0.x


224.128.0.x (x = 0 to 255)
225.128.0.x
.
239.128.0.x

Dubbele multicast-pakketstromen worden ontvangen

Oorzaak 1

Dubbele multicastpakketten worden ontvangen wanneer twee routers in de dichte modus zijn geconfigureerd. In de dichte modus wordt de stroom periodiek overspoeld door het apparaat. Na overstroming, snoeit het van de interfaces waar de stoom niet wordt gewenst. De twee routers gaan ook door het assertieproces en beslissen wie de expediteur is. Elke keer dat de timers van dit gebeurt, en tot dit proces is voltooid, beide routers voorwaarts de stroom. Dit zorgt ervoor dat de applicatie dubbele multicast stromen ontvangt.

Mogelijke Fix 1

Deze kwestie kan worden opgelost als u één van de routers hebt die voor multicast routing zijn geconfigureerd en om de andere router te configureren om de RP in upstream te zijn. Configureer de stream om deze naar de spaarmodus te converteren voordat de stream naar de router komt. Dit kan verhinderen dat dubbele pakketten de toepassing bereiken. Het is geen deel van de netwerkverantwoordelijkheid om ervoor te zorgen dat geen dubbele pakketten ooit een eindgastheer bereiken. Het is een deel van de verantwoordelijkheid van de toepassing om dubbele pakketten te behandelen en onnodige gegevens te negeren.

Oorzaak 2

Dit probleem kan zich voordoen in Cisco Catalyst 6500 switches, die zijn geconfigureerd voor uitgaande multicast-replicatiemodus en kunnen worden geactiveerd door het verwijderen en opnieuw invoegen van elke lijnkaart [OIR]. Na OIR kan de Fabric Port Of Exit [FPOE] verkeerd worden geprogrammeerd, waardoor pakketten naar het verkeerde Fabric-uitgangskanaal kunnen worden geleid en naar de verkeerde lijnkaarten kunnen worden verzonden. Het resultaat is dat ze worden herleid naar de Fabric en meerdere malen worden herhaald wanneer ze op de juiste lijnkaart weggaan.

C6509#show mls ip multicast capability
Current mode of replication is Egress
Auto replication mode detection is ON

 Slot           Multicast replication capability
    1                        Egress
    2                        Egress
    3                        Egress
    4                        Egress
    5                        Egress
    6                        Egress
    7                        Egress

Mogelijke Fix 2

Als tijdelijke oplossing wijzigt u in toegangsreplicatiemodus. Tijdens een verandering van uitgang- naar toegang-replicatie modus, kunnen er verkeersonderbrekingen optreden omdat de sneltoetsen worden gewist en opnieuw geïnstalleerd.

mls ip multicast replication-mode ingress

Upgrade de Cisco IOS-software naar een release die niet wordt beïnvloed door Cisco bug-id CSC28814 om het probleem permanent op te lossen.

Opmerking: alleen geregistreerde Cisco-gebruikers hebben toegang tot interne Cisco-tools en buginformatie.

Oorzaak 3

Dit probleem kan ook optreden als de instelling Receive Side Scaling (RSS), op de eindhosts of servers, is uitgeschakeld.

Mogelijke Fix 3

De RSS-instelling maakt een snellere overdracht van gegevens via meerdere CPU's mogelijk. Schakel de RSS-instelling in op de end-host of server.

Waarom worden multicastpakketten afgevoerd?

Oorzaak 1

Het is mogelijk dat u de overmatige spoelingen en invoerpakketdalingen op de interface(s) ziet wanneer Multicast-verkeer stroomt. U kunt de flushes controleren met de  show interface  uit.

Switch#show interface gi 1/0


!--- Output suppressed


MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is SX
  input flow-control is off, output flow-control is on 
  Clock mode is auto
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 2/75/0/13370328 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 195000 bits/sec, 85 packets/sec
  30 second output rate 1000 bits/sec, 1 packets/sec
  L2 Switched: ucast: 53056 pkt, 4728434 bytes - mcast: 235759386 pkt, 66914376970 bytes
  L3 in Switched: ucast: 8714263 pkt, 1815426423 bytes - mcast: 1081138213 pkt,
 438000092206 bytes mcast
  L3 out Switched: ucast: 4939256 pkt, 790351689 bytes mcast: 0 pkt, 0 bytes
     1326976857 packets input, 506833655045 bytes, 0 no buffer
     Received 1318209538 broadcasts, 0 runts, 0 giants, 1 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     31643944 packets output, 3124494549 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

Mogelijke Fix 1

U kunt de SPT-waarde instellen als oneindigheid voor de interface waar de overmatige spoelingen worden gezien.

Configureer dit:

Switch(config-if)#ip pim spt-threshold infinity

Oorzaak 2

Wanneer u de  ip igmp join-group   In opdracht van elke interface(s) verwerkt het wel switching. Als multicast-pakketten procesgeschakeld zijn op een of meer interfaces, neemt het meer CPU’s in beslag omdat het processwitching van alle pakketten naar die groep verplicht stelt. U kunt de show buffers input-interface de opdracht en controleer de abnormale grootte.

Switch#show buffers input-interface gi 1/0

  Header DataArea  Pool Rcnt  Size Link  Enc    Flags          Input      Output

437C6EAC  8096AE4 Middl    1   434    7    1      280          Gi1/1        None
437C74B4  8097864 Middl    1   298    7    1      280          Gi1/1        None
437C98E4  809C964 Middl    1   434    7    1      280          Gi1/1        None
437CAAFC  809F1E4 Middl    1   349    7    1      280          Gi1/1        None
437CAE00  809F8A4 Middl    1   519    7    1      280          Gi1/1        None


!--- Output suppressed

Mogelijke Fix 2

U kunt de   ip igmp static-group   bevel in plaats van de  ip igmp join-group   uit.

Opmerking: door eerdere problemen is het mogelijk dat je een hoog CPU-gebruik ziet van zo'n 90 procent. CPU komt tot de normale situatie wanneer u ze oplost met deze mogelijke oplossingen.

Gerelateerde informatie

• Probleemoplossing voor multicastnetwerken met CLI-tools
• Configuratiehandleiding voor multicast snelstart

• ECMP-multicast taakverdeling inschakelen 

• Ondersteuning van IP-multicast technologie
• Ondersteuning van IP-routingprotocollen
• Cisco technische ondersteuning en downloads