IP-multicast handleiding voor probleemoplossing

Voer aanvullende opdrachten voor debuggen in:

ip22-72a#debug ip mpacket 224.1.1.1 
*Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.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 de show ip mroute count toeneemt, en HostA ontvangt pakketten.

ip22-72a#show ip mroute 224.1.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 (*, 224.1.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, 224.1.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 224.1.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: 224.1.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 224.1.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: 224.1.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 224.1.1.1 *Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.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 output van   show ip mroute  de opdracht op router A om de multicast routerstatus 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 (*, 224.1.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 de 224.0.1.40 in de uitvoer negeren omdat alle routers zich bij deze Auto-RP Discovery-groep aansluiten. Maar er is geen bron vermeld voor 224.1.1.1. Naast "*, 224.1.1.1" kunt u "10.1.1.1, 224.1.1.1" niet 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 op de interfaces is geconfigureerd met de opdrachtshow ip pim interface:

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 opdrachtshow ip mroute active:

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 IGMP-rapporten (joins) voor groep 24.1.1.1. U kunt deze 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 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2 

224.1.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 of dit een TTL-probleem is met de sniffer capture en ook met show ip traffic  commando:

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 (*, 224.1.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, 224.1.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 (*, 224.1.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, 224.1.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 224.1.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 (*, 224.1.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, 224.1.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 er absoluut zeker van te zijn dat router 75a de pakketten doorstuurt, schakel debug alleen in 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 224.1.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=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied

De 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 <value> commando betekent dat alle 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

ip multicast ttl-threshold <value> Ofwel verwijder de opdracht met de no form van deze opdracht, die terugkeert naar de standaard TTL drempelwaarde van 0, ofwel verlaag de TTL drempelwaarde 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 224.1.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 (*, 224.1.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, 224.1.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 224.1.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 (*, 224.1.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, 224.1.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 heeft geconfigureerd, voert u de opdracht in om de multicastroute (route) voor de groep te zien:

ip22-75a#show ip mroute 224.1.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 (*, 224.1.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, 224.1.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 224.1.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 (*, 224.1.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, 224.1.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 (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.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  verklaring in de configuratie verondersteld te verwezenlijken? In IP Multicast Routing Commands, het stelt dat "om een router te vormen om goed te keuren toetreedt of snoeien bestemd voor een gespecificeerde RP en voor een specifieke lijst van groepen, gebruik het ip pim accept-rp globale configuratiebevel. Om die controle te verwijderen, gebruik het nr formulier van dit bevel."

Wanneer u het ip pim accept-rp bevel verwijdert, 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 de show ip pim rp mapping  opdracht in 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 verklaring in de configuratie is dus pim accept-rp fout.

Mogelijke oplossingen

De oplossing is om het IP-adres in de verklaring als volgt te corrigerenip pim accept-rp:

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 24.1.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 24.1.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 224.1.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#

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 spoelbeurten controleren met de opdrachtshow interface.

Switch#show interface gigabitethernet 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 opdracht op een of meer interfaces gebruiktip igmp join-group <group-name>, wordt er wel switching verwerkt. 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 opdracht uitvoeren en de abnormale grootte controleren.

Switch#show buffers input-interface gigabitethernet 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 opdrachtip igmp static-group <group-name> gebruiken in plaats van de ip igmp join-group <group-name> opdracht.

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