Problemen met multicast-verkeer oplossen in hetzelfde VLAN op Catalyst-Switches

Inleiding

In dit document wordt beschreven hoe een multicast-toepassingsfout kan worden opgelost wanneer deze wordt geïmplementeerd in hetzelfde VLAN tussen Catalyst-switches.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

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

• Catalyst 6500 met Supervisor Engine 720 waarop Cisco IOS®-software wordt uitgevoerd

• Catalyst 3750 met een Cisco IOS-software

• Elke Catalyst-switch die een Cisco IOS-softwarerelease uitvoert en ook IGMP-snooping (Internet Group Management Protocol) ondersteunt

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.

Conventies

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

Achtergrondinformatie

Bovendien kunnen sommige servers/toepassingen die multicastpakketten gebruiken voor de werking van het cluster/de werking met hoge beschikbaarheid, niet werken als u de switches niet correct configureert. Dit wordt ook behandeld in dit artikel.

Opmerking: Raadpleeg de sectie IGMP Snooping Feature Catalyst Switch Support Matrix van het document Multicast Catalyst Switches Support Matrix om deze switches te helpen identificeren.

Probleem

Multicast-verkeer gaat niet over Catalyst-switches, zelfs niet in hetzelfde VLAN.Afbeelding 1 geeft dit scenario weer.

Afbeelding 1 – Netwerkconfiguratie met Multicast-bron en -ontvangers

Netwerkdiagram

De multicast-bron is verbonden met Switch 1, een Catalyst 6500-Switch met Supervisor Engine 720 waarop Cisco IOS Software wordt uitgevoerd.

Ontvanger 1 is aangesloten op Switch 1 en ontvanger 2 op Switch 2. Switch 2 is een Catalyst 3750.

Er is een Layer 2-link, zowel toegang als trunk, tussen Switch 1 en Switch 2.

In deze configuratie vindt u dat Receiver 1, die zich op dezelfde switch als de bron bevindt, de multicaststroom zonder problemen krijgt. Ontvanger 2 krijgt echter geen multicast-verkeer. Dit document is bedoeld om dit probleem op te lossen.

Belangrijke multicastconcepten opnieuw bekijken

Voordat u de oplossing en de verschillende opties die u hebt, moet u duidelijk zijn over bepaalde belangrijke concepten van Layer 2 multicast. In dit hoofdstuk worden deze begrippen gedefinieerd.

Opmerking: Deze sectie biedt een zeer eenvoudige en directe uitleg die zich alleen richt op dit specifieke probleem. Zie de sectie Gerelateerde informatie aan het einde van dit document voor een gedetailleerde uitleg van deze voorwaarden.

IGMP

IGMP is een protocol waarmee eindhosts (ontvangers) een multicast-router (IGMP-querier) kunnen informeren over de intentie van de eindhost om bepaald multicast-verkeer te ontvangen.

Dit is dus een protocol dat tussen een router en eindhosts wordt uitgevoerd en het volgende toestaat:

• Routers vragen aan eindhosts of ze een bepaalde multicaststroom nodig hebben (IGMP-query)

• Eindhosts om de router te vertellen of erop te reageren als ze op zoek zijn naar een bepaalde multicast-stream (IGMP-rapporten)

IGMP-snooping

IGMP-snooping is een mechanisme om multicast-verkeer te beperken tot alleen de poorten waarop ontvangers zijn aangesloten.

Het systeem zorgt voor meer efficiëntie omdat het een Layer 2-switch in staat stelt om selectief multicastpakketten uit te zenden op alleen de poorten die ze nodig hebben.

Zonder IGMP-snooping overspoelt de switch de pakketten op elke poort. De switch "luistert" naar het uitwisselen van IGMP-berichten door de router en de eindhosts.

Op deze manier bouwt de switch een IGMP-snuffeltafel met een lijst van alle poorten die een bepaalde multicast-groep hebben aangevraagd.

Mrouter-poort

De mrouterpoort is gewoon de poort vanuit het oogpunt van de switch die verbinding maakt met een multicastrouter. De aanwezigheid van ten minste één moterpoort is absoluut noodzakelijk voor de IGMP-snuffeloperatie om over switches te werken.

Multicast bij L2

Elk IP-versie 4 (IPv4)-verkeer met een IP-bestemming in het bereik van 224.0.0.0 tot 239.255.255.255 is een multicast-stream.

Alle IPv4-multicastpakketten worden toegewezen aan een vooraf gedefinieerd IEEE MAC-adres met het formaat 01.00.5e. xx. xx.

Opmerking: IGMP-snooping werkt alleen als het multicast MAC-adres is toegewezen aan dit IEEE-compatibele MAC-bereik. Sommige gereserveerde multicast-reeksen zijn uitgesloten van de reeksen die door het ontwerp worden gesnuffeld. Als een niet-conform multicast-pakket afkomstig is van een geschakeld netwerk, wordt het pakket overspoeld door dat VLAN, wat betekent dat het wordt behandeld als uitzendverkeer.

Begrijp het probleem en mogelijke oplossingen

Standaard is IGMP-snooping ingeschakeld voor de Catalyst-switches. Met IGMP-snooping snuffelt (of luistert) de switch naar IGMP-berichten op alle poorten.

De switch bouwt een IGMP-snuffeltafel die in principe een multicast-groep toewijst aan alle switch-poorten die daarom hebben gevraagd.

Stel dat, zonder enige voorafgaande configuratie, ontvanger 1 en ontvanger 2 hun intenties hebben aangegeven om een multicast-stream te ontvangen voor 239.239.239.239 die wordt toegewezen aan het L2 multicast MAC-adres van 01.00.5e.6f.ef.ef.

Zowel Switch 1 als Switch 2 maken een vermelding in hun snuffeltafels voor deze ontvangers in reactie op de IGMP-rapporten die de ontvangers genereren.

Switch 1 gaat Gigabit Ethernet 2/48-poort in de tabel en Switch 2 gaat Fast Ethernet 1/0/47-poort in de tabel in.

Opmerking: op dit punt is de multicast-bron niet gestart met het verkeer en geen van de switches weet van de switch-routerpoort.

Wanneer de bron op Switch 1 multicast-verkeer begint te streamen, heeft Switch 1 het IGMP-rapport van ontvanger 1 "gezien".

Als gevolg hiervan biedt Switch 1 de multicast-out-poort Gigabit Ethernet 2/48.

Omdat Switch 2 het IGMP-rapport van Receiver 2 heeft "geabsorbeerd" als onderdeel van het IGMP-snuffelproces, ziet Switch 1 geen IGMP-rapport (multicast-verzoek) op poort Gigabit Ethernet 2/46.

Als gevolg hiervan stuurt Switch 1 geen multicast-verkeer naar Switch 2.

Daarom krijgt Receiver 2 nooit multicast-verkeer, ook al bevindt Receiver 2 zich in hetzelfde VLAN, maar alleen op een andere switch dan de multicast-bron.

De reden voor dit probleem is dat IGMP-snooping niet echt wordt ondersteund op een Catalyst-platform zonder een router.

Het mechanisme "breekt" af bij afwezigheid van een router-poort. Als u een oplossing voor deze oplossing wilt, moet u de switches op de een of andere manier een moterpoort laten leren of kennen.

Zie het gedeelte Oplossingen van dit document voor een aanvullende uitleg van de procedure. U moet nog steeds ontdekken hoe de aanwezigheid van een routerpoort op de switches het probleem oplost.

Kortom, wanneer de switches leren of statisch weten over een mrouter-poort, treden er twee belangrijke dingen op:

• De switch "relaist" de IGMP-rapporten van de ontvangers naar de routerpoort, wat betekent dat de IGMP-rapporten naar de multicastrouter gaan. De switch geeft niet alle IGMP-rapporten door. In plaats daarvan stuurt de switch slechts enkele rapporten naar de router. Voor deze discussie is het aantal meldingen niet van belang. De multicast-router hoeft alleen te weten of er ten minste één ontvanger is die nog steeds geïnteresseerd is in de multicast-downstream. Om de vaststelling te doen, ontvangt de multicast-router de periodieke IGMP-rapporten als reactie op zijn IGMP-vragen.

• In een multicastscenario met alleen bronnen, waarin nog geen ontvangers zijn "aangesloten", verzendt de switch alleen de multicaststroom uit de moterpoort.

Wanneer de switches hun mrouterpoort kennen, geeft Switch 2 het IGMP-rapport door dat de switch van Receiver 2 naar de mrouterpoort heeft ontvangen.

Deze poort is Fast Ethernet 1/0/33. Switch 1 krijgt dit IGMP-rapport over de switch-poort Gigabit Ethernet 2/46.

Vanuit het oogpunt van Switch 1 heeft de switch slechts een nieuw IGMP-verslag ontvangen.

De switch voegt die poort toe aan zijn IGMP-snuffeltafel en begint ook het multicastverkeer op die poort uit te sturen.

Op dit punt ontvangen beide ontvangers het gevraagde multicast-verkeer en werkt de toepassing zoals verwacht.

Om erachter te komen hoe de switches hun routerpoort identificeren, zodat IGMP-snooping werkt zoals verwacht wordt in een eenvoudige omgeving, raadpleegt u de sectie Oplossingen voor antwoorden.

Oplossingen

Optie 1: PIM inschakelen op de Layer 3 Router/VLAN-interface

Alle Catalyst-platforms hebben de mogelijkheid om dynamisch te leren over de mrouter-poort. De switches luisteren passief naar de Protocol Independent Multicast (PIM)-hellos of de IGMP-queryberichten die een multicastrouter periodiek verzendt.

In dit voorbeeld wordt de VLAN 1-geschakelde virtuele interface (SVI) op de Catalyst 6500 geconfigureerd met ip pim sparse-mode .

Switch1#show run interface vlan 1
!
interface Vlan1
 ip address 10.1.1.1 255.255.255.0
 ip pim sparse-mode
end

- Switch 1 now reflects itself (Actually the internal router port) as an Mrouter port. 

Switch1#show ip igmp snooping mrouter 
vlan            ports
-----+----------------------------------------
   1  Router

- Switch 2 receives the same PIM hellos on its Fa 1/0/33 interface. So it assigns that port as its Mrouter port.

Switch2#show ip igmp snooping mrouter 
Vlan    ports
----    -----
   1    Fa1/0/33(dynamic)

Optie 2: IGMP Querier-functie inschakelen op een Layer 2 Catalyst-Switch

Wanneer een netwerk/VLAN geen router heeft die de multicast-routerrol kan overnemen en de routerdetectie op de switches kan uitvoeren, kunt u de IGMP-querierfunctie inschakelen.

Met deze functie kan de Layer 2-switch een proxy voor een multicastrouter maken en periodieke IGMP-query's in dat netwerk verzenden. Deze actie zorgt ervoor dat de switch zichzelf als een router-poort beschouwt.

De rest van de switches in het netwerk definiëren eenvoudig hun respectievelijke mrouterpoorten als de interface waarop ze deze IGMP-query hebben ontvangen.

Switch2(config)#ip igmp snooping querier

Switch2#show ip igmp snooping querier 
Vlan      IP Address     IGMP Version   Port               
-------------------------------------------------------------
1         10.1.1.2        v2             Switch

Switch 1 ziet nu dat poort Gig 2/46 linkt naar Switch 2 als een mrouterpoort.

Switch1#show ip igmp snooping mrouter 
vlan            ports
-----+----------------------------------------
   1  Gi2/46

Wanneer de bron op Switch 1 multicastverkeer begint te streamen, stuurt Switch 1 het multicastverkeer door naar de Receiver 1 die wordt gevonden via IGMP-snooping (dat wil zeggen, uit poort Gig 2/48) en naar de mrouterpoort (dat wil zeggen, uit poort Gig 2/46).

Optie 3: Statische Mrouter-poort op de Switch configureren

Het multicast-verkeer faalt binnen hetzelfde Layer 2 VLAN vanwege het ontbreken van een routerpoort op de switches, het gedeelte Begrijp het probleem en de oplossingen behandelt dit onderwerp.

Als u een moterpoort op alle switches statisch configureert, kunnen IGMP-rapporten in dat VLAN worden doorgegeven aan alle switches. Hierdoor is multicasting mogelijk.

In het voorbeeld moet u de Catalyst 3750-Switch dus statisch configureren om Fast Ethernet 1/0/33 als routerpoort te hebben.

In dit voorbeeld hebt u alleen een statische routerpoort op Switch 2 nodig:

Switch2(config)#ip igmp snooping vlan 1 mrouter interface fastethernet 1/0/33

Switch2#show ip igmp snooping mrouter
Vlan    ports
----    -----
   1    Fa1/0/33(static)

Optie 4: Statische Multicast MAC-items configureren op alle Switches

U kunt een statische inhoud-adresseerbare geheugeninvoer (CAM) maken voor het multicast MAC-adres op alle switches voor alle ontvangerpoorten en de downstream switch-poorten.

Elke switch voldoet aan de statische CAM-invoerregels en verzendt het pakket alle interfaces die in de CAM-tabel zijn opgegeven.

Dit is de minst schaalbare oplossing voor een omgeving met veel multicast-toepassingen.

Switch1(config)#mac-address-table static 0100.5e6f.efef vlan 1 interface gigabitethernet 2/46 gigabitethernet 2/48

Switch1#show mac-address-table multicast vlan 1

 vlan   mac address     type   learn qos             ports
-----+---------------+--------+-----+---+--------------------------------
   1  0100.5e6f.efef    static  Yes          -   Gi2/46,Gi2/48


Switch2(config)#mac-address-table static 0100.5e6f.efef vlan 1 interface fastethernet 1/0/47

Switch2#show mac-address-table multicast vlan 1
Vlan    Mac Address       Type       Ports
----    -----------       ----       -----
   1    0100.5e6f.efef    USER        Fa1/0/47

Optie 5: IGMP-snooping uitschakelen op alle Switches

Als u IGMP-snooping uitschakelt, behandelen alle switches multicastverkeer als uitzendverkeer. Hierdoor wordt het verkeer overspoeld naar alle poorten in dat VLAN, ongeacht of de poorten geïnteresseerde ontvangers voor die multicaststroom hebben.

Switch1(config)#no ip igmp snooping

Switch2(config)#no ip igmp snooping

Gerelateerde informatie

• Multicast in een campusnetwerk: CGMP en IGMP-snooping
• Multicast Catalyst Switches Support Matrix
• Ondersteuning voor IP-multicast
• TechNotes om problemen met IP Multicast op te lossen
• Gids voor probleemoplossing met IP Multicast
• Cisco Technical Support en downloads