Introduktion
Denna artikel fortsätter serien om IP Multicast. Vi tar en titt på hur grundläggande IP multicast fungerar. Därefter tittar vi på hur PIM Dense Mode (PIM-DM) fungerar, hur man konfigurerar det och hur man felsöker det. Detta bör värma upp oss innan vi tar oss an det något mer komplexa och mer skalbara PIM Sparse Mode i en senare artikel.
Den inledande artikeln om multicast innehåller länkar till de viktigaste IETF-arbetsgrupperna i slutet. Den finns på adressen The Protocols of IP Multicast.
Understanding IP Multicast Forwarding
Syftet med ett routningsprotokoll för multicast är att låta routrar samarbeta för att effektivt leverera kopior av multicastpaket till intresserade mottagare. I processen för att göra detta tillhandahåller routningsprotokollet för multicast förmodligen också en mekanism för grannar att upptäcka och spåra närliggande routrar som också använder routningsprotokollet för multicast.
Som vi såg i förra artikeln använder de datorer som är intresserade av att ta emot en multicastpaketström IGMP för att meddela närliggande router(s). Routrarna använder sedan multicastprotokollet för att ordna så att en kopia av multicastpaketströmmen skickas till dem så att de kan vidarebefordra den till det LAN som innehåller mottagaren. Vi nämnde inte vad som händer i paketflödets källsida. I IP multicast finns det inget protokoll för källan att kommunicera, registrera eller meddela routrarna. Källan börjar bara skicka IP multicast-paket, och det är upp till den eller de närliggande routrarna att göra rätt. (Vad ”rätt sak” råkar vara beror på multicast-routningsprotokollet).
Följande bild visar en källa som skickar ett multicast-paket i rött och nedströmsroutrar som duplicerar paketet och översvämmar det till andra routrar och slutligen till alla LAN-segment. Som vi kommer att se inom kort är detta det initiala (och periodiska) beteendet hos Ciscos protokollsoberoende multicast-routningsprotokoll PIM (Protocol Independent Multicast), när det fungerar i tät läget.
Bemärk i bilden ovan att de blå pilarna vidarebefordrar kopiorna av multicastpaketen på ett organiserat sätt. Det kan finnas två kopior av varje paket som kommer in till vissa routrar eller LAN-segment. Men routrarna vidarebefordrar inte paketen ”bakåt”. Detta är bra: tänk på vad som skulle kunna hända om router E skulle vidarebefordra en kopia av det paket som den mottagit från C till router B. Skulle B då vidarebefordra paketet till A, som skulle kunna vidarebefordra det till C, och så vidare, i en vidarebefordringsslinga? Detta skulle vara en slags Layer 3-ekvivalent till vad som händer på Layer 2 när Spanning Tree är inaktiverat i en loop-topologi: ett bra sätt att slösa bort mycket bandbredd och routerkapacitet.
För att förhindra multicast-vidarebefordringsslingor utför IP-multicast alltid en RPF-kontroll, som vi kommer att prata om inom kort.
Förutom RPF-kontrollen kan multicast-routningsprotokoll, t.ex. PIM, också arbeta för att förhindra ineffektivitet. Till exempel behöver router E i bilden inte ta emot två kopior av varje multicastpaket (en från B och en från C).
Multicastroutningsprotokollet bestämmer vilka gränssnitt som ska skicka ut kopior (eller inte skicka ut kopior). Som bilden ovan antyder sker multicast vidarebefordran längs logiska träd, förgrenade vägar genom nätverket. All information om multicast vidarebefordran lagras i multicast state table, som vissa kallar multicast routing table. Denna information kan visas med det mycket användbara kommandot show ip mroute. Låt oss ta en kort titt på ett exempel på utdata från kommandot show ip mroute (med PIM Dense Mode igång).
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
För att förstå det här ska du notera att adresser som börjar med 224-239 är IP-multicast-adresser eller grupper. (Gruppen hänvisar till gruppen av mottagare för den multicastmåladressen).
Posten som börjar med (*, 233.1.1.1.1) är en post i ett delat multicastträd, ibland kallad en (*, G)-post. (G är här bara 223.1.1.1.1). PIM-DM använder inte dessa för vidarebefordran av paket, men listar gränssnitt med en roll i multicast (känd IGMP-mottagare eller PIM-granne) som utgående gränssnitt under sådana poster.
Posten som börjar med (172.16.16.1, 233.1.1.1.1) kallas en (S, G)-post. S är källa, G är grupp. Om du föredrar det kan du tänka på detta som källa och destination i IP-huvudet (eftersom det är där de faktiskt visas i paketen). Denna post är ett källspecifikt multicastträd för en viss multicastgrupp. Det kommer i allmänhet att finnas en sådan post för varje källa och grupp. Observera att nästa hopp för unicast-routning visas som RPF-granne och att det inkommande gränssnittet är RPF-gränssnittet, det gränssnitt som används av unicast-routning mot källan 172.16.16.1. Listan över utgående gränssnitt visar att alla paket från 172.16.16.1 med destination 233.1.1.1.1 som tas emot på FastEthernet1 kommer att kopieras ut på Ethernet0.
Du kan rita multicast-vidarebefordringsträdet för en viss (S, G) i felsökningssyfte. För att göra detta kör du kommandot show ip mroute på varje router. Ta en kopia av din nätverkskarta och rita en utgående pil för varje gränssnitt i listan över utgående gränssnitt (”OIL” eller ”OILIST”). Du får ett diagram som liknar bilden ovan.
State flags som du kan se i PIM-DM show ip mroute output:
- D = Dense Mode. Visas endast på (*, G)-poster. Gruppen arbetar i tätt läge.
- C = Directly Connected Host (IGMP!)
- L = Local (Router är konfigurerad för att vara medlem i multicastgruppen).
- P = Pruned (Alla OILIST-gränssnitt är inställda på Prune). Routern skickar i allmänhet Prune till sin RPF-granne när detta inträffar.
- T = Vidarebefordring via Shortest Path Tree (SPT), indikerar att minst ett paket har mottagits/vidarebefordrats.
- J = Gå med i SPT. Finns alltid med i posten (*,G) i PIM-DM, betyder inte mycket.
Vad är RPF-kontrollen och varför?
IP-multicast vidarebefordran utför alltid en RPF-kontroll. RPF står för Reverse Path Forwarding (omvänd väg vidarebefordran). Målet med RPF-kontrollen är att på ett enkelt sätt försöka förhindra en loop för vidarebefordran av multicastpaket. För varje multicastflöde kontrollerar multicastroutern källadressen, vilken enhet som skickade multicastflödet. Den söker sedan upp avsändaren i unicast-routingtabellen och bestämmer vilket gränssnitt den skulle använda för att skicka unicast-paket till multicast-källan. Det gränssnittet är RPF-gränssnittet, det gränssnitt som routern ”förväntar” sig att ta emot multicast. Se det som det ”officiellt godkända” gränssnittet för att ta emot multicasts från den aktuella källan. Routern lagrar RPF-gränssnittet som en del av informationen om multicasttillstånd för den specifika källan och den specifika multicastdestinationen (gruppen).
När ett multicastpaket tas emot av routern spårar routern vilket gränssnitt som paketet kom från. Om paketet är det första paketet från en ny källa bestäms RPF-gränssnittet och lagras i mroute-tabellen, som just diskuterats. I annat fall söker routern upp källan och multicastgruppen i mroute-tabellen. Om paketet togs emot på RPF-gränssnittet kopieras paketet och vidarebefordras på varje utgående gränssnitt som anges i mroute-tabellen. Om paketet togs emot på ett icke-RPF-gränssnitt kastas det. Om routern var en person skulle detta motsvara ”Varför skickar den personen det här till mig? De måste vara förvirrade, jag ignorerar det de just skickade till mig.”
Routern skickar inte heller tillbaka en kopia av ett paket till det gränssnitt det kom in i (RPF-gränssnittet). Med andra ord, även om grannroutern på RPF-gränssnittet på något sätt skulle begära att få kopior av ett multicastflöde skickade, kommer routern inte att lägga till RPF-gränssnittet i listan över utgående gränssnitt som tar emot kopior av multicastflödet. Detta skyddar mot att någon form av protokollfel får två grannar att hamna i en snäv multicast vidarebefordringsslinga.
Router E ignorerar troligen också en av de två paketströmmarna, baserat på om B eller C är ansluten till RPF-gränssnittet. Även med rutter med lika kostnader väljs normalt bara ett gränssnitt som RPF-gränssnitt. Så om du har två länkar som ansluter två routrar används vanligtvis bara en av dem för multicast från ett källsubnät.
Se dock kommandot ip multicast multipath (nytt i Cisco IOS version 12.0(8) T, 12.0(5) S)). Med det här kommandot kan det, om det används på rätt sätt, finnas lastbalansering för olika källor för en viss multicastgrupp. Eftersom detta är per källa och inte per ström blir det egentligen mer som lastdelning. Det kanske inte slutar med att det blir särskilt balanserat.
Lastbalansering av trafik för ett paketflöde (en källa och grupp) över två länkar mellan två routrar kan också göras med hjälp av GRE-tunnlar mellan loopback-gränssnitt, även om jag skulle kunna oroa mig för prestandakonsekvenserna av att göra det här med ett flöde med hög bandbredd.
Förresten, det här talar också om hur man kan styra IP-multicast över länkar som man själv väljer. Vi styr vart multicasttrafiken går genom att styra RPF-kontrollen. Om en router inte lär sig rutter tillbaka till en multicastkälla på något gränssnitt, kommer det gränssnittet inte att vara RPF-gränssnittet. Så med distansvektorprotokoll och ”route starvation” (att inte annonsera en rutt till en granne) kan vi styra eller rikta multicast.
Vi kommer att se senare att alla PIM-grafts eller joins skickas ut genom RPF-gränssnittet, tillbaka till källan (eller RP, i PIM Sparse Mode). Genom att styra var den här aktiviteten äger rum styr vi vilka länkar som multicast skickas vidare på. Statiska mrouteposter (statiska vägar tillbaka till källan för RPF-kontroll av multicast) är ett annat sätt att styra multicasttrafiken. Om/när vi talar om Multicast MBGP (Multiprotocol BGP for Multicast) kommer vi att se att MBGP också ger oss ett sätt att styra eller kontrollera de länkar som används av multicasttrafiken. Observera också att om RPF-gränssnittet inte har IP multicast aktiverat så förväntar sig routern i praktiken paket där den inte kommer att ta emot dem. RPF-gränssnittet bör alltid vara ett gränssnitt där IP multicast är aktiverat.
PIM Dense Mode – Overview
Protocol Independent Multicast har två lägen, Dense Mode och Sparse Mode. Den här artikeln har bara utrymme att täcka det förstnämnda. Vi tar upp PIM-SM i nästa artikel.
PIM Dense Mode (PIM-DM) använder ett ganska enkelt tillvägagångssätt för att hantera IP multicast routing. Det grundläggande antagandet bakom PIM-DM är att multicastpaketströmmen har mottagare på de flesta platser. Ett exempel på detta kan vara en företagspresentation av företagets VD eller koncernchef. PIM Sparse Mode (PIM-SM) förutsätter däremot relativt få mottagare. Ett exempel skulle kunna vara den inledande introduktionsvideon för nyanställda.
Denna skillnad visar sig i de två protokollens inledande beteende och mekanismer. PIM-SM skickar endast multicasts när det begärs. Medan PIM-DM börjar med att översvämma multicasttrafiken och sedan stoppa den på varje länk där den inte behövs, med hjälp av ett Prune-meddelande. Jag tänker på Prune-meddelandet som att en router talar om för en annan att ”vi behöver inte multicast här just nu”.
I äldre Cisco IOS-versioner skulle PIM-DM återigen översvämma all multicast-trafik var tredje minut. Detta är bra för multicast med låg volym, men inte för multicastpaketströmmar med högre bandbredd. Senare Cisco IOS-versioner har stöd för en ny funktion som kallas PIM Dense Mode State Refresh, sedan 12.1(5)T. Den här funktionen använder ett PIM-statusuppdateringsmeddelande för att uppdatera Prune-statusen på utgående gränssnitt. En annan fördel är att topologiförändringar upptäcks snabbare. Som standard skickas PIM state refresh-meddelanden var 60:e sekund.
Tänk på routrarna E och F i bilden ovan. När två PIM-DM-routrar ansluter till ett LAN ser de multicastpaketen från varandra. Den ena ska vidarebefordra paketen till LAN och den andra inte. Båda skickar Assert-meddelanden. Bäst routningsmetriker vinner, med högre IP-adress som avgörande faktor. Om de använder olika routningsprotokoll används ett viktat rutningsmetriskt system, ungefär som administrativt avstånd, för att avgöra vilken router som skall vara vidarebefordrare (vidarebefordra multicastpaketen till LAN). Forwarder kan tystas av en Prune från en nedströmsrouter utan mottagare, om det inte heller finns några mottagare på LAN-segmentet. Nedströmsroutrar kan behöva justera sin RPF-granne för att återspegla vinnaren av Assert-processen.
För att upprepa detta i detalj: när multicasttrafik tas emot på ett icke-RPF-gränssnitt skickas ett Prune-meddelande, förutsatt att gränssnittet är punkt-till-punkt. Dessa Prune-meddelanden är hastighetsbegränsade för att se till att mängden av dem (potentiellt ett per mottaget multicast) inte orsakar ytterligare problem.
Om det icke-RPF-gränssnittet är ett LAN skickas ett Assert-meddelande. Routrar som inte är skotarroutrar skickar då ett Prune-meddelande på sitt RPF-gränssnitt om de inte behöver multicastflödet. Endast en sådan Prune skickas, vid tidpunkten för övergången till att inte ha några gränssnitt i listan över utgående gränssnitt (OILIST). LAN Prune-mottagaren väntar med att agera på det i 3 sekunder, så att om en annan LAN-router fortfarande behöver multicastflödet kan den skicka ett PIM Join-meddelande för att motverka (avbryta) Prune-meddelandet. (”Yo, den routern behöver det inte, men jag behöver det fortfarande!”)
Antag att en router har Pruned och att en mottagare en tid senare begär multicastflödet med ett IGMP-meddelande. Routern skickar då ett Graft-meddelande. I själva verket: ”Hej, jag behöver den där multicastströmmen här borta nu”.
Följande bild illustrerar detta, visserligen i något komprimerad form.
Förklaring av bilden:
(1), kanske routern E väljer B som sin RPF-granne, baserat på unicast-routering tillbaka till källan. Sedan tar E emot ett multicastpaket på punkt-till-punkt-gränssnittet från C. Den skickar en hastighetsbegränsad Prune till C.
(2), routrarna E och F på LAN:et utbyter Assert-paket, när E eller F ser multicast som vidarebefordrats av den andra av de två. Antag att E vinner, baserat på metrik eller adress för unicast-routing. Då vet F att han inte ska vidarebefordra multicasts på LAN. Observera att G och H inte är inblandade, eftersom Ethernet är deras RPF-gränssnitt.
(3), anta att router G inte har några mottagare nedströms. Den kan då skicka en LAN Prune till Forwarder för LAN, router E.
(4), om router H har lokala eller nedströms mottagare, så kontrar den detta med en LAN Join.
(5), anta att router D inte hade några nedströms- eller lokala mottagare och skickade en Prune till B. Anta att en av PC:erna till höger om routern någon gång senare skickar ett IGMP-meddelande till router D för samma multicastgrupp. Router D kan då skicka ett PIM Graft till B och be B att återuppta sändningen av den specificerade multicastgruppen.
PIM-protokoll och pakettyper
PIM är ett fullständigt routingprotokoll, med olika typer av meddelanden. Jag tänker inte drämma upp mig om de olika meddelandena. Men jag tycker att det är värt att ta en kort titt, eftersom det berättar lite om protokollet.
PIM använder Hello meddelanden för att upptäcka grannar och bilda adjacenser. Hello-meddelandet skickas till All-PIM-Routers lokala multicastadress, 224.0.0.0.13, var 30:e sekund (PIMv1 använder AllRouters, 224.0.0.0.2). Varje LAN har en PIM Designated Router (DR) som används i PIM Sparse Mode. Det är också IGMPv1 Querier: den högsta IP-adressen på LAN. Kommandot show ip pim neighbor visar grannar och information om adjacency och timer.
Förtydligande tillagt 12/11/2004: IGMP querier och Designated Router är de två rollerna i fråga. Se här.
I IGMP version 1, ”DR ansvarar för följande uppgifter:
- Sändning av PIM-register- och PIM-anslutnings- och prune-meddelanden till RP för att informera den om medlemskap i värdgrupp.
- Sändning av IGMP-värdsförfrågningsmeddelanden.”
I IGMP version 2 är de frikopplade. IGMP-frågorna väljs av den lägsta IP-adressen på LAN. PIM väljer DR efter högsta IP på LAN för att vidarebefordra multicasts till LAN. (Detta avlastar arbetet).
PIM har också ett Join/Prune-meddelande som används enligt beskrivningen ovan. Det finns också Graft- och Graft ACK-meddelanden, vilket talar om att Graft utförs på ett tillförlitligt sätt (till skillnad från den verkliga världen?).
Och det finns PIM Assert-meddelandet.
PIM-SM har ytterligare tre meddelandetyper: Register, Register-Stop och RP-Reachability (finns inte i PIMv2).
Konfigurering av PIM Dense Mode
Konfigurering av PIM-DM är rent ut sagt enkelt jämfört med alla ovanstående.
Globalt aktiverar du multicastrouting med kommandot:
ip multicast-routing
Därefter aktiverar du IP multicast och PIM med gränssnittskommandot på varje gränssnitt som du vill delta i multicasting:
gränssnitt …
ip pim dense-mode
Det är faktiskt bättre att konfigurera sparse-dense-mode:
interface …
ip pim sparse-dense-mode
Anledningen till detta är att du helt enkelt kan migrera några eller alla multicastgrupper till Sparse Mode, genom att låta routern veta om en Rendezvous Point. Och du kan till och med göra detta utan att konfigurera om en massa routrar eller routergränssnitt.
Du kan konfigurera stub-nätverk för enkel IP multicast. Tanken är att man för enkelhetens skull inte ska köra PIM till stub-delar av nätverket, t.ex. små fjärrplatser. Detta är en särskilt bra idé med routrar som inte är under din kontroll: du vill inte att de ska dela multicast-routering med dina routrar. Det eliminerar också PIM-DM-flooding till sådana routrar (med äldre Cisco IOS-versioner).
För att konfigurera stub multicast, configure
ip igmp helper-address a.b.c.d
på alla LAN-gränssnitt för stub-routrar med potentiella multicast-mottagare. Adressen a.b.c.d är adressen till den centrala PIM-talande routern. På den centrala routern konfigurerar du ett filter för att stänga av alla PIM-meddelanden som stubgrannen kan skicka, med:
ip pim neighbor-filter access-list
Se även Kommandoguiden på URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm .
Det finns flera show-kommandon som hjälper till att felsöka IP multicast. De jag gillar bäst:
- show ip mroute
- show ip pim interface
- show ip pim neighbor
- show ip rpf
Då utrymmet är begränsat hänvisar jag till kommandoguiden för exempel.
En anmärkning om felsökning: Om du har multicast med hög bandbredd i ditt nätverk, se till att du använder Prune State Refresh i de nyare Cisco IOS-versionerna om du använder sparse-dense-läge. Jag oroar mig för att routrar ”glömmer” att de har en RP och återgår till tät mode, med periodiska översvämningar. Detta kan vara en sällsynt olyckshändelse, men det kan verkligen förstöra din morgon! Du kanske också vill överväga RP robusthetstekniker också, ett ämne för vår senare PIM-SM eller Rendezvous Point artikel.
In Conclusion
Den rekommenderade boken för många multicast ämnen: Developing IP Multicast Networks: The Definitive Guide to Designing and Deploying CISCO IP Multicast Networks, Beau Williamson.
En annan extremt bra Cisco multicast-länk finns här.
Nästa artikel: Skalning med PIM Sparse Mode.