Inleiding
Dit artikel vervolgt de serie over IP Multicast. We bekijken hoe basis IP multicast werkt. Daarna bekijken we hoe PIM Dense Mode (PIM-DM) werkt, hoe het te configureren, en hoe het te troubleshooten. Dit moet ons opwarmen voordat we de iets complexere en meer schaalbare PIM Sparse Mode in een later artikel behandelen.
Het oorspronkelijke multicast artikel bevat links naar de belangrijkste IETF werkgroepen aan het eind. Het kan worden gevonden op The Protocols of IP Multicast.
Understanding IP Multicast Forwarding
Het doel van een multicast-routeringsprotocol is om routers te laten samenwerken om kopieën van multicast-pakketten efficiënt bij geïnteresseerde ontvangers af te leveren. Daarbij biedt het multicast-routeringsprotocol waarschijnlijk ook een mechanisme voor buren om naburige routers die ook het multicast-routeringsprotocol gebruiken, te ontdekken en te volgen.
Zoals we in het vorige artikel hebben gezien, gebruiken de computers die geïnteresseerd zijn in het ontvangen van een multicast-pakketstroom IGMP om aangrenzende router(s) op de hoogte te stellen. De routers gebruiken vervolgens het multicast protocol om een kopie van de multicast pakketstroom naar hen te sturen, zodat zij deze kunnen doorsturen naar het LAN dat de ontvanger bevat. We hebben geen melding gemaakt van wat er aan de bronzijde van de pakketstroom gebeurt. Bij IP multicast is er geen protocol voor de bron om te communiceren of de routers te registreren of op de hoogte te brengen. De bron begint gewoon met het verzenden van IP multicast pakketten, en het is aan de naburige router(s) om de juiste actie te ondernemen. (Wat het “juiste” is hangt af van het multicast routing protocol).
De volgende afbeelding toont een bron die een multicast pakket in het rood verstuurt, en downstream routers die het pakket dupliceren en flooden naar andere routers en uiteindelijk alle LAN segmenten. Zoals we zo dadelijk zullen zien, is dit het initiële (en periodieke) gedrag van Cisco’s Protocol Independent Multicast (PIM) multicast-routeringsprotocol, wanneer het in Dense Mode werkt.
Merk in de bovenstaande afbeelding op dat de blauwe pijlen multicast-pakketkopieën op een georganiseerde manier doorsturen. Er kunnen twee kopieën van elk pakket binnenkomen in sommige routers of LAN-segmenten. Maar de routers sturen de pakketten niet “achterwaarts” door. Dit is een goede zaak: bedenk wat er zou kunnen gebeuren als router E een kopie van het pakket dat hij van C ontving zou doorsturen naar router B. Zou B het pakket dan doorsturen naar A, die het zou doorsturen naar C, enzovoort, in een doorstuurlus? Dit zou een soort Layer 3 equivalent zijn van wat er op Layer 2 gebeurt als Spanning Tree is uitgeschakeld in een loop topologie: een goede manier om veel bandbreedte en router capaciteit te verspillen.
Om multicast forwarding loops te voorkomen, voert IP multicast altijd een RPF check uit, waar we het zo meteen over zullen hebben.
Naast de RPF check, kunnen multicast routing protocollen zoals PIM ook werken om inefficiëntie te voorkomen. Router E in de afbeelding hoeft bijvoorbeeld niet twee kopieën van elk multicast-pakket te ontvangen (één van B, één van C).
Het multicast-routeringsprotocol bepaalt welke interfaces kopieën naar buiten moeten sturen (of geen kopieën naar buiten moeten sturen). Zoals het bovenstaande plaatje suggereert, vindt multicast forwarding plaats langs logische bomen, vertakkende paden door het netwerk. Alle informatie over multicast forwarding wordt opgeslagen in de multicast state table, die sommigen de multicast routing table noemen. Deze informatie kan bekeken worden met het zeer nuttige commando, show ip mroute. Laten we eens kort kijken naar een voorbeeld van de uitvoer van het show ip mroute commando (met PIM Dense Mode aan).
Router# show ip mroute 233.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit setTimers: Uptime/ExpiresInterface state: Interface, Next-Hop, State/Mode(*, 233.1.1.1), uptime 0:57:31, expires 0:02:59, RP is 0.0.0.0, flags: DC Incoming interface: Null, RPF neighbor 0.0.0.0 Outgoing interface list: Ethernet0, Forward/Dense, 0:57:31/0:02:52 FastEthernet1, Forward/Dense, 0:56:55/0:01:28 FastEthernet2, Forward/Dense, 0:56:45/0:01:22(172.16.16.1/32, 233.1.1.1), uptime 20:20:00, expires 0:02:55, flags: C Incoming interface: FastEthernet1, RPF neighbor 10.20.30.1 Outgoing interface list: Ethernet0, Forward/Dense, 20:20:00/0:02:52
Om dit te begrijpen, merk op dat adressen beginnend met 224-239 IP multicast adressen of groepen zijn. (De groep verwijst naar de groep ontvangers voor dat multicast-bestemmingsadres).
De entry die begint met (*, 233.1.1.1) is een gedeelde multicast-boom entry, soms aangeduid als een (*, G) entry. (G is hier gewoon 223.1.1.1). PIM-DM gebruikt deze niet voor het doorsturen van pakketten, maar vermeldt wel interfaces met een rol in multicast (bekende IGMP ontvanger of PIM buur) als uitgaande interfaces onder zulke entries.
De entry die begint met (172.16.16.1, 233.1.1.1) wordt aangeduid als een (S, G) entry. S is bron, G is groep. Als je dat liever hebt, zie dit dan als bron en bestemming in de IP header (omdat ze daar ook echt in de pakketten staan). Deze entry is een bron-specifieke multicast tree voor een bepaalde multicast groep. Er zal in het algemeen één zo’n entry zijn voor elke bron en groep. Merk op dat de unicast routing volgende hop verschijnt als de RPF buur, en de inkomende interface is de RPF interface, de interface gebruikt door unicast routing naar de bron 172.16.16.1. De uitgaande interface lijst toont dat elk pakket van 172.16.16.1 met bestemming 233.1.1.1 ontvangen op FastEthernet1 zal gekopieerd worden uit Ethernet0.
U kunt de multicast forwarding tree voor een bepaalde (S, G) tekenen voor troubleshooting doeleinden. Voer hiervoor het commando show ip mroute uit op elke router. Neem een kopie van je netwerkkaart en teken een uitgaande pijl voor elke interface in de uitgaande interface lijst (“OIL” of “OILIST”). U zult eindigen met een diagram dat enigszins lijkt op de bovenstaande afbeelding.
Statusvlaggen die u zou kunnen zien in PIM-DM show ip mroute uitvoer:
- D = Dense Mode. Verschijnt alleen bij (*, G) entries. Groep werkt in Dense mode.
- C = Directly Connected Host (IGMP!)
- L = Local (Router is geconfigureerd om lid te zijn van de multicast groep).
- P = Pruned (Alle OILIST interfaces ingesteld op Prune). De router over het algemeen Prune sturen naar zijn RPF buurman wanneer dit gebeurt.
- T = Doorsturen via Shortest Path Tree (SPT), geeft aan ten minste een pakket ontvangen / doorgestuurd.
- J = Word lid van SPT. Altijd aan in (*,G) entry in PIM-DM, betekent niet veel.
Wat is de RPF Check, en waarom?
IP multicast forwarding voert altijd een RPF check uit. RPF staat voor Reverse Path Forwarding. Het doel van de RPF-check is om op een eenvoudige manier een lus in het doorsturen van multicast-pakketten te voorkomen. Voor elke multicast-stroom controleert de multicast-router het bronadres, welk apparaat de multicast heeft verzonden. Vervolgens zoekt hij de afzender op in de unicast routing tabel, en bepaalt de interface die hij zou gebruiken om unicast pakketten naar de multicast bron te zenden. Die interface is de RPF interface, de interface waarop de router “verwacht” multicasts te ontvangen. Zie het als de “officieel goedgekeurde” interface voor het ontvangen van multicasts van die specifieke bron. De router slaat de RPF-interface op als onderdeel van de multicast-statusinformatie voor die bepaalde bron en die bepaalde multicast-bestemming (groep).
Wanneer een multicast-pakket door de router wordt ontvangen, houdt de router bij via welke interface het pakket binnenkwam. Als het pakket het eerste pakket is van een nieuwe bron, wordt de RPF-interface bepaald en opgeslagen in de mroute-tabel, zoals zojuist besproken. Anders zoekt de router de bron en multicast groep op in de mroute tabel. Als het pakket werd ontvangen op de RPF interface, wordt het pakket gekopieerd en doorgestuurd op elke uitgaande interface die in de mroute tabel staat. Als het pakket werd ontvangen op een niet-RPF interface, wordt het weggegooid. Als de router een persoon was, zou dit het equivalent zijn van “Waarom stuurt die persoon me dit? Ze moeten in de war zijn, ik negeer wat ze me zojuist hebben gestuurd.”
De router stuurt ook geen kopie van een pakket terug naar de interface waar het vandaan kwam (de RPF interface). Met andere woorden, zelfs als de naburige router op de RPF-interface op de een of andere manier zou verzoeken om kopieën van een multicast-stroom te ontvangen, zal de router de RPF-interface niet toevoegen aan de lijst van uitgaande interfaces die kopieën van de multicast-stroom ontvangen. Dit beschermt tegen elke vorm van protocol fouten die twee buren in een strakke multicast forwarding loop krijgen.
Router E negeert waarschijnlijk ook een van de twee pakketstromen, gebaseerd op de vraag of B of C is verbonden met de RPF interface. Zelfs met gelijke kosten routes, wordt normaal gesproken slechts een interface gekozen als de RPF interface. Dus als je twee links hebt die twee routers verbinden, zal er typisch maar één gebruikt worden voor multicast van eender welk bronsubnet.
Zie echter het commando ip multicast multipath (nieuw in Cisco IOS versie 12.0(8) T, 12.0(5) S). Met dit commando, op de juiste wijze gebruikt, kan er load balancing zijn voor verschillende bronnen voor een bepaalde multicast groep. Aangezien dit per bron is en niet per stroom, lijkt het meer op het verdelen van de belasting. Het is mogelijk dat het uiteindelijk niet erg gebalanceerd is.
Load balancing verkeer voor één pakketstroom (één bron en groep) over twee links tussen twee routers kan ook worden gedaan met GRE tunnels tussen loopback interfaces, hoewel ik me zorgen zou kunnen maken over de prestatie-implicaties van dit doen met een hoge bandbreedte stroom.
Dit vertelt ons overigens ook hoe we IP multicast over links van onze keuze kunnen leiden. We bepalen waar het multicast verkeer heen gaat door de RPF check te controleren. Als een router geen routes terugleert naar een multicast bron op een bepaalde interface, dan zal die interface niet de RPF interface zijn. Dus met afstandsvector protocollen en “route starvation” (het niet adverteren van een route naar een buur), kunnen we multicast sturen of leiden.
We zullen later zien dat alle PIM enten of joins via de RPF interface worden gestuurd, terug naar de bron (of RP, in PIM Sparse Mode). Door te controleren waar deze activiteit plaatsvindt, controleren we over welke links de multicast wordt doorgestuurd. Statische mroute entries (statische routes terug naar de bron voor multicast RPF controle doeleinden) zijn een andere manier om multicast verkeer te sturen. Als / wanneer we spreken over Multicast MBGP (Multiprotocol BGP voor Multicast), zullen we zien dat MBGP ons ook een manier biedt om de links die gebruikt worden door multicast verkeer te sturen of te controleren. Merk ook op dat als de RPF interface geen IP multicast ingeschakeld heeft, de router in feite pakketten verwacht waar hij ze niet zal ontvangen. De RPF interface moet er altijd een zijn waar IP multicast is ingeschakeld.
PIM Dense Mode – Overview
Protocol Independent Multicast kent twee modi, Dense Mode en Sparse Mode. Dit artikel heeft alleen ruimte om de eerste te behandelen. We zullen PIM-SM in het volgende artikel behandelen.
PIM Dense Mode (PIM-DM) gebruikt een vrij eenvoudige benadering om IP multicast routing te behandelen. De basisaanname achter PIM-DM is dat de multicast pakketstroom ontvangers heeft op de meeste locaties. Een voorbeeld hiervan zou een bedrijfspresentatie door de CEO of President van een bedrijf kunnen zijn. PIM Sparse Mode (PIM-SM) daarentegen gaat uit van relatief minder ontvangers. Een voorbeeld hiervan is de eerste oriëntatievideo voor nieuwe werknemers.
Dit verschil komt tot uiting in het aanvankelijke gedrag en de mechanismen van de twee protocollen. PIM-SM verstuurt alleen multicasts wanneer daarom wordt gevraagd. Terwijl PIM-DM begint met het overspoelen van het multicast verkeer, om het vervolgens te stoppen op elke link waar het niet nodig is, met behulp van een Prune bericht. Ik zie het Prune-bericht als een boodschap van een router aan een andere router: “We hebben die multicast hier nu niet nodig”.
In oudere Cisco IOS versies, zou PIM-DM elke 3 minuten al het multicast-verkeer re-flooden. Dit is prima voor laag volume multicast, maar niet voor hogere bandbreedte multicast packet streams. Recentere Cisco IOS versies ondersteunen een nieuwe mogelijkheid genaamd PIM Dense Mode State Refresh, sinds 12.1(5)T. Deze functie gebruikt een PIM state refresh bericht om de Prune status op uitgaande interfaces te vernieuwen. Een ander voordeel is dat topologie veranderingen sneller herkend worden. Standaard worden de PIM state refresh berichten elke 60 seconden verzonden.
Bedenk routers E en F in de bovenstaande afbeelding. Wanneer twee PIM-DM routers verbinding maken met een LAN, zullen ze de multicast pakketten van elkaar zien. De ene moet pakketten doorsturen naar het LAN, en de andere niet. Ze sturen allebei Assert berichten. De beste routing metric wint, met een hoger IP adres als tie-breaker. Als ze verschillende routing protocols gebruiken, beslist een gewogen routing metric schema, een beetje zoals administratieve afstand, welke router de Forwarder is (die de multicast pakketten doorstuurt naar het LAN). De Forwarder kan het zwijgen worden opgelegd door een Prune van een downstream-router zonder ontvangers, als er ook geen ontvangers op het LAN-segment zijn. Het kan zijn dat downstream routers hun RPF buurman moeten aanpassen, om de winnaar van het Assert proces weer te geven.
Om dat nog eens in detail te herhalen: wanneer multicast verkeer wordt ontvangen op een niet-RPF interface, wordt een Prune bericht verstuurd, mits de interface point-to-point is. Deze Prune-berichten zijn gelimiteerd in snelheid, om ervoor te zorgen dat het volume ervan (mogelijk één per ontvangen multicast) geen verdere problemen veroorzaakt.
Als de niet-RPF interface een LAN is, wordt een Assert-bericht verzonden. Non-Forwarder routers sturen dan een Prune op hun RPF interface als ze de multicast stream niet nodig hebben. Er wordt slechts één zo’n Prune verzonden, op het moment van de overgang naar het hebben van geen interfaces in de Outgoing Interface List (OILIST). De LAN Prune ontvanger stelt zijn actie 3 seconden uit, zodat als een andere LAN router de multicast stream nog steeds nodig heeft, deze een PIM Join bericht kan sturen om de Prune tegen te gaan (te annuleren). (“Yo, die router heeft het niet nodig, maar ik nog wel!”)
Voorstel dat een router heeft Pruned, en enige tijd later vraagt een ontvanger de multicast stream aan met een IGMP bericht. De router stuurt dan een Graft-bericht. In feite: “Hé, ik heb die multicast-stroom nu hier nodig”.
Het volgende plaatje illustreert dit, weliswaar in enigszins gecomprimeerde vorm.
Uitleg van het plaatje:
(1), misschien kiest de router E B als zijn RPF-buur, op basis van unicast-routering terug naar de bron. Dan ontvangt E een multicast pakket op de point-to-point interface van C. Het stuurt een rate-limited Prune naar C.
(2), de routers E en F op het LAN wisselen Assert pakketten uit, wanneer E of F de multicast doorgestuurd ziet worden door de andere van de twee. Stel dat E wint, gebaseerd op unicast routing metric of adres. Dan weet F dat hij geen multicasts moet doorsturen op het LAN. Merk op dat G en H hier niet bij betrokken zijn, omdat het Ethernet hun RPF interface is.
(3), stel dat router G geen ontvangers downstream heeft. Hij kan dan een LAN Prune sturen naar de Forwarder voor het LAN, router E.
(4), als router H lokale of downstream ontvanger(s) heeft, countert hij dit met een LAN Join.
(5), stel dat router D geen downstream of lokale ontvangers had en een Prune stuurde naar B. Stel dat enige tijd later een van de PC’s rechts van hem een IGMP bericht stuurt voor dezelfde multicast groep. Router D kan dan een PIM Graft naar B sturen, met het verzoek aan B om de gespecificeerde multicast groep weer naar hem te zenden.
PIM Protocol and Packet Types
PIM is een volledig routing protocol, met verschillende soorten berichten. Ik ga niet doorzeuren over de verschillende berichten. Maar ik denk wel dat het de moeite waard is om er even naar te kijken, omdat het ons iets vertelt over het protocol.
PIM gebruikt Hello berichten om buren te ontdekken en adjacencies te vormen. De Hello wordt elke 30 seconden naar het All-PIM-Routers lokale multicast adres, 224.0.0.13, gestuurd (PIMv1 gebruikt AllRouters, 224.0.0.2). Elk LAN heeft een PIM Designated Router (DR), gebruikt in PIM Sparse Mode. Het is ook de IGMPv1 Querier: het hoogste IP adres op het LAN. Het show ip pim neighbor commando toont buren en adjacency en timer informatie.
Verduidelijking toegevoegd 12/11/2004: IGMP querier en Designated Router zijn de twee rollen in kwestie. Zie hier.
In IGMP versie 1, “De DR is verantwoordelijk voor de volgende taken:
- Versturen van PIM register en PIM join en prune berichten naar de RP om deze te informeren over host groep lidmaatschap.
- Versturen van IGMP host-query berichten.”
In IGMP versie 2, zijn ze losgekoppeld. De IGMP querier wordt gekozen door het laagste IP op het LAN. PIM selecteert de DR op basis van het hoogste IP op het LAN, om multicasts naar het LAN door te sturen. (Hierdoor wordt het werk uit handen genomen).
PIM heeft ook een Join/Prune bericht, dat gebruikt wordt zoals hierboven beschreven. Er zijn ook Graft en Graft ACK berichten, die ons vertellen dat Graft betrouwbaar wordt gedaan (in tegenstelling tot de echte wereld?).
En er is het PIM Assert bericht.
PIM-SM heeft nog 3 andere berichttypen: Register, Register-Stop, en RP-Reachability (niet in PIMv2).
Configuratie van PIM Dense Mode
Configuratie van PIM-DM is ronduit eenvoudig vergeleken met al het bovenstaande.
Globaal, schakel multicast routing in met het commando:
ip multicast-routing
Dan op elke interface die u wenst deel te nemen aan multicasting, schakel IP multicast en PIM in met het interface commando:
interface …
ip pim dense-mode
Eigenlijk is het beter om sparse-dense modus te configureren:
interface …
ip pim sparse-dense-mode
De reden hiervoor is dat je hiermee eenvoudig enkele of alle multicast groepen naar Sparse Mode kunt migreren, door de router op de hoogte te stellen van een Rendezvous Point. En je kunt dit zelfs doen zonder veel routers of router interfaces te herconfigureren.
Je kunt stub netwerken configureren voor eenvoudige IP multicast. Het idee is om PIM niet uit te voeren naar stub delen van het netwerk, zoals kleine remote sites, voor de eenvoud. Dit is vooral een goed idee met routers die niet onder uw beheer staan: u wilt niet dat ze multicast routing delen met uw routers. Het elimineert ook PIM-DM flooding naar dergelijke routers (met oudere Cisco IOS-releases).
Om stub multicast in te stellen, configureer
ip igmp helper-address a.b.c.d
op elke stub router LAN-interfaces met potentiële multicast-ontvangers. Het adres a.b.c.d is het adres van de centrale PIM-sprekende router. Op de centrale router configureer je een filter om alle PIM-berichten die de stub-buur zou kunnen sturen, uit te sluiten, met:
ip pim neighbor-filter access-list
Zie ook de Command Guide op de URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm .
Er zijn verschillende show-commando’s om problemen met IP multicast te helpen oplossen. Degene die ik het beste vind:
- show ip mroute
- show ip pim interface
- show ip pim neighbor
- show ip rpf
Omdat er weinig ruimte is, verwijs ik u naar de Command Reference voor voorbeelden.
Eén probleemoplossing: als u multicast met hoge bandbreedte in uw netwerk hebt, zorg er dan voor dat u de Prune State Refresh gebruikt in de nieuwere Cisco IOS-versies als u sparse-dense modus gebruikt. Ik maak me zorgen over routers die “vergeten” dat ze een RP hebben en terugkeren naar Dense Mode, met periodieke flooding. Dit zou een zeldzame toevallige gebeurtenis kunnen zijn, maar het zou je ochtend echt kunnen verpesten! Misschien wil je ook RP robuustheid technieken overwegen, een onderwerp voor ons latere PIM-SM of Rendezvous Point artikel.
In Conclusie
Het aanbevolen boek voor een heleboel multicast onderwerpen: Developing IP Multicast Networks: The Definitive Guide to Designing and Deploying CISCO IP Multicast Networks, Beau Williamson.
Een andere zeer goede Cisco multicast link is hier te vinden.
Volgend artikel: schalen met PIM Sparse Mode.