De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
In dit document worden gangbare problemen met en oplossingen voor IP-multicast beschreven.
Er zijn geen specifieke vereisten van toepassing op dit document.
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.
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.
Deze paragraaf biedt een oplossing voor het veelvoorkomende probleem van een IP-multicast RPF-fout. Dit netwerkdiagram wordt als voorbeeld gebruikt.
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).
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:
Statische routes
DVMRP-routes
MBGP-routes
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.
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
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
Router 75a |
---|
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 |
Router 752b |
---|
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
Deze paragraaf biedt oplossingen voor het veelvoorkomende probleem van de foutmelding "INVALIDATE_RP_JOINT" voor IP-multicast.
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.
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
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.
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#
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.
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.
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.
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.
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.
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?
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.
Of verplaats de bron op hetzelfde subnet als Routers 75a en 75b, zoals in dit voorbeeld.
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
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?
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 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.
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.
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
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.
Dit probleem kan ook optreden als de instelling Receive Side Scaling (RSS), op de eindhosts of servers, is uitgeschakeld.
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.
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
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
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
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.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
2.0 |
26-May-2023 |
Hercertificering |
1.0 |
02-Dec-2013 |
Eerste vrijgave |