Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Conventies

Wijzigingen in CGMP en topologie

Stabiele staat

Tijdens en na de Topologie veranderen

Twee IGMP algemene vragen na de melding van de topologie-verandering

Verbeteringen in CGMP

Communicatie tussen de Switch en de router

Routergedrag

Catalyst Switch-gedrag

Gerelateerde informatie

Inleiding

Dit document beschrijft hoe Cisco Group Management Protocol (CGMP) werkt op de Cisco Catalyst switches en de Cisco IOS® routers met betrekking tot het opnieuw opbouwen van de multicast items voor CGMP nadat een overspannend aantal topologieën is opgetreden.

Voorwaarden

Vereisten

Cisco raadt u aan kennis te hebben van deze onderwerpen:

- basisbediening van switches, routers en multicast

- basisbediening van de omspannende boom, CGMP en Internet Group Management Protocol (IGMP)

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

- Catalyst 3550 versie 12.1(9)EA1c

- Catalyst 2900/3500XL versie 12.0(5)WC3b

- Catalyst 4000 Supervisor Engine III versie 12.1(11b)EW

- Catalyst 4000 Supervisor Engine I/II versie 7.2(2)

- Catalyst 6500 Supervisor Engine Cisco IOS-softwarerelease 12.1(11b)EX

- Catalyst 6500 Catalyst OS (CatOS) versie 7.2(2)

- Catalyst 5500 CatOS versie 4.5(13a)

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 de potentiële impact van elke opdracht begrijpen.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Wijzigingen in CGMP en topologie

In deze sectie wordt stap voor stap beschreven wat voorkomt en welke problemen zich kunnen voordoen wanneer een overspits van de verandering van de boomtopologie op een VLAN wordt ontdekt waar CGMP wordt gebruikt om multicast verkeer van overstromingen op alle havens te beperken. Zoals dit voorbeeld laat zien, bestaat het netwerk dat in dit document wordt besproken uit één router, één switch en vier PC's:

- poort 1—ontvanger PC 1

- poort 2—ontvanger PC 2

- poort 3—ontvanger PC 3

- poort 4—geen ontvanger PC 4

- poort 5-andere switch (geen ontvangers of routers op deze switch)

- poort 48-Cisco IOS router met IGMP en CGMP

Voor de doeleinden van dit document wordt aangenomen dat de ontvangerpc’s IGMP gebruiken en dat de switch CGMP uitvoert. De Cisco IOS router voert IGMP en CGMP uit, die een multicast stream van een videoserver op een andere interface ontvangen. Deze interface stuurt naar IP multicast groep 239.100.100.100.

Stabiele staat

Zodra alle apparaten zijn opgestart en de PC's van de ontvanger hun IGMP-berichten voor groep 239.100.100.100 hebben verstuurd, worden ze allemaal door CGMP toegevoegd aan de corresponderende Layer 2-groep die wordt vertegenwoordigd door MAC-adres 01-00-5e-64-64.

Deze lijst toont welke poorten, vet gemarkeerd, op de switch de multicast stream ontvangen die door de Cisco IOS-router komt.

- poort 1—ontvanger PC 1

- poort 2—ontvanger PC 2

- poort 3—ontvanger PC 3

- poort 4—geen ontvanger PC 4

- poort 5-andere switch (geen ontvangers of routers op deze switch)

- poort 48-Cisco IOS-router die IGMP en CGMP draait

Opmerking: de Cisco IOS-router wordt ook toegevoegd aan de multicast groep, maar omdat het de bron is, ontvangt het niet zijn eigen pakketten.

Bij elk query-interval verstuurt de Cisco IOS-router een IGMP algemene query (dat wordt verzonden naar multicast groep 224.0.0.1 en daarom overstroomd naar alle andere componenten). Als dit gebeurt, beginnen alle ontvangers een IGMP-rapport te bouwen voor de groep van 239.100.100.100. De ontvangers sturen dit rapport terug naar IP-multicastgroep 239.100.100.100, met een Layer 2 MAC-adres van 01-00-5E-64-64-64. Aangezien dit naar het groepsadres wordt verzonden, ontvangen alle ontvangers de rapporten die door andere ontvangers worden verzonden, evenals het rapport dat door de eerste ontvanger wordt teruggestuurd . Dit zet de andere PC's van de ontvanger in werking om hun rapport voor deze groep te annuleren. Dit betekent dat slechts één CGMP zich bij bericht wordt verzonden voor deze groep met het bron MAC adres van de PC die als eerste reageerde. Dit duurt lang en alle PC's van de ontvanger ontvangen de video-uitzending.

Tijdens en na de Topologie veranderen

Op dit punt, veroorzaakt de andere switch een topologie verandering in het netwerk. In overeenstemming met de CGMP-specificatie bij het ontvangen van de topologie-verandering, verwijdert de switch alle multicast items die deze via het CGMP heeft geleerd. Het multicast verkeer vanaf de router wordt naar alle poorten op de switch overstroomd.

Deze lijst toont welke havens, die in vet worden gemarkeerd, op de switch de multicast stroom ontvangen die door de Cisco IOS router komt:

- poort 1—ontvanger PC 1

- poort 2—ontvanger PC 2

- poort 3—ontvanger PC 3

- poort 4—geen ontvanger PC 4

- poort 5-andere switch (geen ontvangers of routers op deze switch)

- poort 48-Cisco IOS-router die IGMP en CGMP draait

Aangezien het verkeer naar alle poorten wordt overstroomd, merken de ontvangende PC's geen verschil en blijven de video-uitzending ontvangen. Aangezien het verkeer echter naar alle poorten overstroomt, is PC 4, die geen ontvanger is, en de andere switch nu ook de multicast stream ontvangen, hoewel ze er niet om hebben gevraagd. Dit gaat verder tot de Cisco IOS router zijn periodieke IGMP algemene vraag opnieuw verstuurt. De standaardwaarde voor dit is 60 seconden op Cisco IOS routers (geconfigureerd met een IP IGMP-query-interval).

Twee IGMP algemene vragen na de melding van de topologie-verandering

Wanneer de Cisco IOS-router zijn eerste IGMP algemene query uitstuurt, beginnen alle ontvangende PC's hun IGMP-rapport te bouwen voor de 239.100.100.100 groep. Eén daarvan (in dit document is het PC 3) is de eerste die zijn IGMP-rapport terugstuurt. Omdat er nog geen multicast ingang is die op de switch gebouwd is, wordt deze door alle PC's ontvangen, en de andere PC's van de ontvanger annuleren hun IGMP rapport. De Cisco IOS-router ontvangt het rapport en stuurt het volgende CGMP uit bij bericht met het bronadres van de ontvanger PC 3.

De switch bouwt een multicast ingang opnieuw voor groep 01-00-5e-64-64-64 en voegt poort 3 toe aan het, aangezien dit het bronadres in het CGMP aansluit bij pakket. Aangezien poort 5 de multicast routerpoort is, wordt dit ook toegevoegd aan de multicast groep. Daarom ontvangt alleen ontvanger PC 3 de videostream, terwijl de videostream op PC 1 en PC 2 stilstaat.

Deze lijst toont welke poorten, vet gemarkeerd, op de switch de multicast stream ontvangen die door de Cisco IOS-router komt:

- poort 1—ontvanger PC 1

- poort 2—ontvanger PC 2

- poort 3—ontvanger PC 3

- poort 4—geen ontvanger PC 4

- poort 5-andere switch (geen ontvangers of routers op deze switch)

- poort 48-Cisco IOS router met IGMP en CGMP

Aan het eind van een IGMP zich het interval beweegt, verstuurt de Cisco IOS router een andere IGMP algemene query. Na ontvangst van de query maken alle PC's van de ontvanger een rapport op voor de groep van 239.100.100.100. Deze keer worden de rapporten van de andere PC's echter alleen ontvangen door ontvanger PC 3 en de Cisco IOS router. (De routerpoort wordt automatisch toegevoegd aan elke multicast groep.)

Aangezien de ontvangers van PC 1 en PC 2 geen verslag van een andere ontvanger zien, sturen zij beiden hun verslagen. De Cisco IOS router stuurt een CGMP om zich aan te sluiten bij bericht met het bron-MAC-adres van de respectieve pc’s en daarom worden ze toegevoegd en beginnen ze de multicast-stream opnieuw te ontvangen via de Cisco IOS-router.

Deze lijst toont welke poorten, vet gemarkeerd, op de switch de multicast stream ontvangen die door de Cisco IOS-router komt:

- poort 1—ontvanger PC 1

- poort 2—ontvanger PC 2

- poort 3—ontvanger PC 3

- poort 4—geen ontvanger PC 4

- poort 5-andere switch (geen ontvangers of routers op deze switch)

- poort 48-Cisco IOS router met IGMP en CGMP

De configuratie is terug naar de oorspronkelijke stabiele toestand en alles werkt weer naar behoren. Dit is een verdeling van wat er is gebeurd:

1. Er vindt een topologie-verandering plaats.

Tip: Wanneer portfast niet in een host poort is ingeschakeld, elke keer dat een host wordt herstart of verbonden/losgekoppeld van/naar/van de poort, leidt een verandering in de koppelingen status tot een melding van topologie in het VLAN. Als het debuggen van CGMP is ingeschakeld op het moment van de topologie verandering, wordt dit debug bericht weergegeven:

CGMP SHIM: got short age timer

2. Overstroming begint in alle havens.

3. De eerste IGMP algemene query wordt uitgezonden.

4. Overstroming stopt.

5. Niet alle ontvangers ontvangen de multicast stream.

6. De tweede IGMP algemene query wordt uitgezonden.

7. Alle ontvangers worden toegevoegd en ontvangen de multicast stream opnieuw.

Verbeteringen in CGMP

Aangezien het hebben van een één minuut (het standaard IGMP querying interval) verlies van een multicast stream voor een PC niet altijd acceptabel is, zijn er enkele verbeteringen aangebracht voor zowel de routers als de switches die CGMP uitvoeren.

Communicatie tussen de Switch en de router

Aangezien routers Layer 3-apparaten zijn en daarom over het algemeen niet weten over het overspannen van bomen en topologieveranderingen die zich voordoen, is er een behoefte aan de switches in het netwerk om de router van deze topologie te waarschuwen. Om dit aan te pakken, is een IGMP global leaving-bericht gedefinieerd.

Dit IGMP global leaving-bericht is een IGMP-signaal dat een switch kan verzenden, met het verzoek de groep 0.0.0.0 te verlaten.

Om ervoor te zorgen dat de router niet met IGMP globale verlaten berichten wordt overbelast, is slechts de switch van de wortel in een omspannend boomgebied verantwoordelijk om dit IGMP mondiaal verlaat bericht te verzenden wanneer de topologie voorbij is.

Routergedrag

Wanneer de router dit IGMP mondiaal verlaat bericht op een interface ontvangt die Cisco IOS Software in werking stelt, erkent het dat een het overspuiten van de verandering van de boomtopologie op die interface is voorgekomen en neemt deze acties om het verlies van multicast verkeer voor de multicast ontvangers te proberen te beperken:

1. De partij van CGMP stuurt aantekeningen na ontvangst van het IGMP wereldwijd verlofbericht. De router stuurt een CGMP om zich bij bericht aan te sluiten met zijn eigen MAC-adres als gebruikersbronadres voor elke multicast groep die het in zijn IGMP cache voor die interface heeft. Door deze CGMP-berichten zelf toe te voegen, maken de CGMP-switches automatisch een ingang voor elke groep met alleen de routerpoort erin.

Deze lijst toont het netwerk dat in dit document wordt gebruikt nadat de partij CGMP zich bij het document aansluit. Alleen de Cisco IOS-router is toegevoegd aan de multicast groep, zoals vet weergegeven.

Opmerking: Terwijl in vorige voorbeelden in dit document, werden de poorten die verkeer van de multicast router ontvangen vet weergegeven, toont dit voorbeeld alle poorten die op de switch aan de multicast groep zijn toegevoegd.

- poort 1—ontvanger PC 1

- poort 2—ontvanger PC 2

- poort 3—ontvanger PC 3

- poort 4—geen ontvanger PC 4

- poort 5-andere switch (geen ontvangers of routers op deze switch)

- poort 48-Cisco IOS router met IGMP en CGMP

2. Verstuurt een IGMP algemene query uit. Alle ontvangers ontvangen deze IGMP algemene query en bouwen een rapport voor elke groep waar ze zich bij hebben aangesloten. Aangezien de CGMP-switch al een multicast ingang voor elk van de groepen heeft gebouwd met alleen de router als de ontvanger, worden alle rapporten naar alleen de router verzonden. De router stuurt de volgende CGMP-berichten naar buiten om alle ontvangers aan de corresponderende groepen toe te voegen.

Nadat alle ontvangers hun IGMP-rapport hebben teruggestuurd en de router de corresponderende CGMP-berichten heeft verzonden, zouden alle ontvangers terug moeten zijn toegevoegd aan de multicast-groep.

3. Na 10 seconden (standaard IGMP max-response-time) wordt een andere IGMP algemene query verzonden om te verzekeren dat alle ontvangers worden toegevoegd. Deze stap wordt een paar keer herhaald om ervoor te zorgen dat alle ontvangers zich opnieuw bij de multicast groep aansluiten.

Alle poorten die aan de multicast-groep hadden moeten worden toegevoegd, zijn vet weergegeven in dit voorbeeld:

- poort 1—ontvanger PC 1

- poort 2—ontvanger PC 2

- poort 3—ontvanger PC 3

- poort 4—geen ontvanger PC 4

- poort 5-andere switch (geen ontvangers of routers op deze switch)

- poort 48-Cisco IOS router met IGMP en CGMP

Catalyst Switch-gedrag

Binnen het bereik van Catalyst switches zijn er een aantal verschillen in hun gedrag. Iedere switch die CGMP-compatibel is, doet wat in het CGMP-en het gedeelte Topologie wordt beschreven. Verandert de sectie van dit document. De verbeteringen voor CGMP worden echter niet op alle platforms geïmplementeerd. Deze tabel bevat een lijst van Catalyst-switches en de manier waarop zij op CGMP reageren:

CGMP-Switch

CGMP-router

Verstuurt mondiaal vertrek bij STP-roet (Spanning Tree Protocol)

Catalyst 6500 SFP-software voor Cisco IOS

N

Y

Y

Catalyst 6500 actieve CatOS-indeling

N

N

N

Catalyst 5500, Catalyst 2926/2926G switch

Y

N

Y

Catalyst 4000 Supervisor Engine I/II, Catalyst 2948G/2980G, Catalyst 4912G switch

Y

N

Y

Catalyst 4000/4500 Supervisor Engine III/IV

N

Y

Y

Catalyst 2900XL/3500XL

Y

N

Y

Catalyst 2940

N

N

N

Catalyst 2950

N

N

N

Catalyst 2970

N

N

N

Catalyst 3550

N

Y

Y

Catalyst 3750

N

Y

Y

Opmerking: Op Catalyst 4000/4500 met Supervisor Engine III/IV kan het gedrag met betrekking tot topologische veranderingen en CGMP worden ingesteld. Geef deze opdracht uit om Catalyst 4000 te configureren om al dan niet een IGMP wereldwijd verlaat bericht te verzenden wanneer dit niet de omspant-boomwortel is:

- IP igmp snooping tcn query

Opmerking: Geef dit 'nee'-formulier van de opdracht uit om het uit te schakelen:

- geen ip igmp snooping tcn query opgeeft

Gerelateerde informatie

- Understanding Spanning-Tree Protocol Topology Changes (Inzicht in wijzigingen in topologie van Spanning Tree Protocol)

- Multicast in een Campus Network: CGMP- en IGMP-signalering

- Multicastverkeer beperken met Bron en Ontvangers op hetzelfde VLAN op Catalyst Switches die Catalyst OS uitvoeren

- Configuratiehandleiding voor Catalyst 4000 Cisco IOS-software: IGMP-signalering begrijpen en configureren

- Pagina voor technische ondersteuning van Spanning Tree

- Productondersteuningspagina’s voor LAN

- Ondersteuningspagina voor LAN-switching

- Technische ondersteuning en documentatie – Cisco Systems