Indledning
Denne artikel fortsætter serien om IP Multicast. Vi tager et kig på, hvordan grundlæggende IP multicast fungerer. Derefter ser vi på, hvordan PIM Dense Mode (PIM-DM) fungerer, hvordan den konfigureres, og hvordan den fejlfindes. Dette skulle varme os op, inden vi tager fat på den lidt mere komplekse og mere skalerbare PIM Sparse Mode i en senere artikel.
Den oprindelige multicast-artikel indeholder links til de vigtigste IETF-arbejdsgrupper i slutningen af artiklen. Den findes på The Protocols of IP Multicast.
Understanding IP Multicast Forwarding
Sigtet med en multicast-routing-protokol er at give routere mulighed for at samarbejde om effektivt at levere kopier af multicast-pakker til interesserede modtagere. I den forbindelse giver multicast-routingprotokollen sandsynligvis også naboer en mekanisme til at opdage og spore naboroutere, der også bruger multicast-routingprotokollen.
Som vi så i den sidste artikel, bruger de computere, der er interesseret i at modtage en multicast-pakkestrøm, IGMP til at underrette de(n) tilstødende router(e). Routerne bruger derefter multicast-protokollen til at sørge for, at der sendes en kopi af multicast-pakkestrømmen til dem, så de kan videresende den til det LAN, der indeholder modtageren. Vi har ikke nævnt, hvad der sker i kildenden af pakkestrømmen. I IP-multicast er der ingen protokol, der gør det muligt for kilden at kommunikere, registrere eller underrette routerne. Kilden begynder bare at sende IP multicast-pakker, og så er det op til naborouterne at gøre det rigtige. (Hvad det “rigtige” er, afhænger af multicast-routing-protokollen).
Det følgende billede viser en kilde, der sender en multicast-pakke med rødt, og downstream-routere, der duplikerer pakken og oversvømmer den til andre routere og i sidste ende til alle LAN-segmenter. Som vi vil se om lidt, er dette den indledende (og periodiske) opførsel af Ciscos Protocol Independent Multicast (PIM) multicast-routingprotokol, når den fungerer i Dense Mode.
Bemærk på ovenstående billede, at de blå pile videresender kopier af multicast-pakker på en organiseret måde. Der kan være to kopier af hver pakke, der kommer ind i nogle af routerne eller LAN-segmenterne. Men routerne videresender ikke pakkerne “baglæns”. Det er en god ting: tænk på, hvad der kunne ske, hvis router E videresendte en kopi af den pakke, den modtog fra C, til router B. Ville B derefter videresende pakken til A, som måske videresendte den til C osv. i en videresendelsessløjfe? Dette ville være en slags Layer 3-ækvivalent til det, der sker i Layer 2, når Spanning Tree er deaktiveret i en loop-topologi: en god måde at spilde en masse båndbredde og routerkapacitet på.
For at forhindre multicast-videresendelsessløjfer udfører IP-multicast altid en RPF-kontrol, som vi omtaler om lidt.
Ud over RPF-kontrollen kan multicast-routingprotokoller som PIM også arbejde for at forhindre ineffektivitet. For eksempel behøver router E på billedet ikke at modtage to kopier af hver multicast-pakke (en fra B og en fra C).
Multicast-routing-protokollen bestemmer, hvilke grænseflader der skal sendes kopier ud (eller ikke sendes kopier ud). Som ovenstående billede antyder, sker multicast-videresendelse langs logiske træer, forgrenede stier gennem netværket. Alle oplysninger om multicast-videresendelse er gemt i multicast-statustabellen, som nogle kalder multicast-routingtabellen. Disse oplysninger kan ses med den meget nyttige kommando, show ip mroute. Lad os tage et kort kig på et eksempel på output fra kommandoen show ip mroute (med PIM Dense Mode kørende).
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
For at forstå dette skal du bemærke, at adresser, der starter med 224-239, er IP-multicast-adresser eller -grupper. (Gruppen henviser til gruppen af modtagere for den pågældende multicast-destinationsadresse).
Posten, der starter med (*, 233.1.1.1.1), er en post i et delt multicast-træ, som nogle gange kaldes en (*, G)-post. (G er her blot 223.1.1.1.1). PIM-DM bruger ikke disse til videresendelse af pakker, men angiver grænseflader med en rolle i multicast (kendt IGMP-modtager eller PIM-nabo) som udgående grænseflader under sådanne poster.
Posten, der starter med (172.16.16.16.1, 233.1.1.1.1), betegnes som en (S, G)-post. S er kilde, G er gruppe. Hvis du foretrækker det, kan du tænke på dette som kilde og destination i IP-headeret (da det er der, de faktisk vises i pakkerne). Denne post er et kildespecifikt multicast-træ for en bestemt multicast-gruppe. Der vil normalt være en sådan post for hver kilde og gruppe. Bemærk, at næste hop for unicast-routing vises som RPF-naboen, og at den indgående grænseflade er RPF-grænsefladen, dvs. den grænseflade, der anvendes af unicast-routing mod kilden 172.16.16.1. Listen over udgående grænseflader viser, at enhver pakke fra 172.16.16.1.1 med destination 233.1.1.1.1, der modtages på FastEthernet1, vil blive kopieret ud af Ethernet0.
Du kan tegne multicast-videresendelsestræet for en bestemt (S, G) til fejlfinding. For at gøre dette skal du køre kommandoen show ip mroute på hver router. Tag en kopi af dit netværkskort, og tegn en udgående pil for hver grænseflade i listen over udgående grænseflader (“OIL” eller “OILIST”). Du ender med et diagram, der minder lidt om ovenstående billede.
State flags, som du kan se i PIM-DM show ip mroute output:
- D = Dense Mode (tæt tilstand). Vises kun på (*, G)-poster. Gruppen fungerer i tæt tilstand.
- C = Direkte tilsluttet vært (IGMP!)
- L = Lokal (Routeren er konfigureret til at være medlem af multicastgruppen).
- P = Beskåret (Alle OILIST-grænseflader er indstillet til Beskåret). Routeren sender normalt Prune til sin RPF-nabo, når dette sker.
- T = Videresendelse via Shortest Path Tree (SPT), angiver, at mindst én pakke er modtaget/videresendt.
- J = Deltag i SPT. Altid på i (*,G)-post i PIM-DM, betyder ikke meget.
Hvad er RPF-tjek og hvorfor?
IP multicast forwarding udfører altid et RPF-tjek. RPF står for Reverse Path Forwarding. Målet med RPF-kontrollen er at forsøge at forhindre en multicast-pakkevideresendelsessløjfe på en enkel måde. For hver multicast-stream kontrollerer multicast-routeren kildeadressen, hvilken enhed der har sendt multicast’en. Derefter slår den afsenderen op i unicast-routingtabellen og bestemmer, hvilken grænseflade den vil bruge til at sende unicast-pakker til multicast-kilden. Denne grænseflade er RPF-grænsefladen, dvs. den grænseflade, som routeren “forventer” at modtage multicasts på. Tænk på det som den “officielt godkendte” grænseflade til at modtage multicasts fra den pågældende kilde. Routeren gemmer RPF-grænsefladen som en del af multicast-statusoplysningerne for den pågældende kilde og den pågældende multicast-destination (gruppe).
Når en multicast-pakke modtages af routeren, registrerer routeren, hvilken grænseflade pakken kom ind på. Hvis pakken er den første pakke fra en ny kilde, bestemmes RPF-grænsefladen og gemmes i mroute-tabellen, som netop beskrevet. Ellers slår routeren kilden og multicastgruppen op i mroute-tabellen. Hvis pakken blev modtaget på RPF-grænsefladen, kopieres pakken og videresendes på hver enkelt udgående grænseflade, der er opført i mroute-tabellen. Hvis pakken blev modtaget på en ikke-RPF-grænseflade, kasseres den. Hvis routeren var en person, ville dette svare til: “Hvorfor sender den person mig dette? De må være forvirrede, jeg ignorerer det, de lige har sendt mig.”
Routeren sender heller ikke en kopi af en pakke tilbage ud af den grænseflade, den kom ind på (RPF-grænsefladen). Med andre ord, selv om naborouteren på RPF-grænsefladen på en eller anden måde skulle anmode om at få tilsendt kopier af en multicast-stream, vil routeren ikke tilføje RPF-grænsefladen til listen over udgående grænseflader, der modtager kopier af multicast-streamet. Dette beskytter mod enhver form for protokolfejl, der får to naboer ind i en tæt multicast-videresendelsessløjfe.
Router E ignorerer sandsynligvis også en af de to pakkestrømme, baseret på om B eller C er forbundet til RPF-grænsefladen. Selv med ruter med samme omkostninger vælges normalt kun én grænseflade som RPF-grænseflade. Så hvis du har to forbindelser, der forbinder to routere, vil kun den ene typisk blive brugt til multicast fra et hvilket som helst kildesubnet.
Se dog kommandoen ip multicast multipath (ny i Cisco IOS Version 12.0(8) T, 12.0(5) S)). Med denne kommando, der anvendes korrekt, kan der være belastningsudligning for forskellige kilder til en bestemt multicast-gruppe. Da dette er pr. kilde og ikke pr. strøm, bliver det i virkeligheden mere som belastningsopdeling. Det ender måske ikke med at blive meget afbalanceret.
Lastudligning af trafik for én pakkestrøm (én kilde og gruppe) over to links mellem to routere kan også gøres ved hjælp af GRE-tunneler mellem loopback-interfaces, selv om jeg måske ville bekymre mig om præstationsimplikationerne ved at gøre dette med en strøm med høj båndbredde.
Dette fortæller os i øvrigt også, hvordan vi kan dirigere IP multicast over links efter eget valg. Vi styrer, hvor multicast-trafikken går hen ved at styre RPF-tjekket. Hvis en router ikke lærer ruter tilbage til en multicastkilde på en eller anden grænseflade, vil denne grænseflade ikke være RPF-grænseflade. Så med distance vector-protokoller og “route starvation” (ikke annoncere en rute til en nabo) kan vi styre eller dirigere multicast.
Vi vil senere se, at alle PIM-grafts eller -joins sendes ud af RPF-grænsefladen, tilbage mod kilden (eller RP, i PIM Sparse Mode). Ved at styre, hvor denne aktivitet finder sted, styrer vi, hvilke links multicast sendes videre på. Statiske mroute-poster (statiske ruter tilbage til kilden med henblik på RPF-kontrol af multicast) er en anden måde at dirigere multicast-trafikken på. Hvis / når vi taler om Multicast MBGP (Multiprotocol BGP for Multicast), vil vi se, at MBGP også giver os en måde at lede eller kontrollere de links, der anvendes af multicasttrafikken. Bemærk også, at hvis RPF-grænsefladen ikke har IP multicast aktiveret, så forventer routeren i realiteten pakker, hvor den ikke vil modtage dem. RPF-grænsefladen bør altid være en grænseflade, hvor IP multicast er aktiveret.
PIM Dense Mode – Oversigt
Protocol Independent Multicast har to tilstande, Dense Mode og Sparse Mode. Denne artikel har kun plads til at dække den førstnævnte. Vi kommer til PIM-SM i den næste artikel.
PIM Dense Mode (PIM-DM) bruger en ret enkel tilgang til at håndtere IP-multicast-routing. Den grundlæggende antagelse bag PIM-DM er, at multicast-pakkestrømmen har modtagere på de fleste steder. Et eksempel på dette kunne være en virksomhedspræsentation af en virksomheds administrerende direktør eller præsident. I modsætning hertil antager PIM Sparse Mode (PIM-SM), at der er relativt færre modtagere. Et eksempel kunne være den indledende orienteringsvideo for nye medarbejdere.
Denne forskel viser sig i de to protokollers indledende adfærd og mekanismer. PIM-SM sender kun multicasts, når der anmodes om det. Mens PIM-DM starter med at oversvømme multicast-trafikken og derefter stoppe den på hvert link, hvor den ikke er nødvendig, ved hjælp af en Prune-meddelelse. Jeg tænker på Prune-meddelelsen som en router, der fortæller en anden router “vi har ikke brug for den multicast herovre lige nu”.
I ældre Cisco IOS-udgaver ville PIM-DM genoverflodde al multicast-trafik hvert 3. minut. Dette er fint til multicast med lav volumen, men ikke multicast-pakkestrømme med større båndbredde. Nyere Cisco IOS-versioner understøtter en ny funktion kaldet PIM Dense Mode State Refresh, siden 12.1(5)T. Denne funktion bruger en PIM-tilstandsopdateringsmeddelelse til at opdatere Prune-tilstanden på udgående grænseflader. En anden fordel er, at topologiændringer genkendes hurtigere. Som standard sendes PIM state refresh-meddelelserne hvert 60. sekund.
Tænk på routerne E og F i ovenstående billede. Når to PIM-DM-routere opretter forbindelse til et LAN, vil de se multicast-pakkerne fra hinanden. Den ene skal videresende pakkerne til LAN’et, og den anden skal ikke videresende dem. De sender begge Assert-meddelelser. Den bedste routingmetrik vinder, med den højeste IP-adresse som afgørende faktor. Hvis de anvender forskellige routingprotokoller, afgøres det ved hjælp af en vægtet routingmetriksystem, lidt ligesom administrativ afstand, hvilken router der skal være Forwarder (videresende multicast-pakkerne til LAN). Forwarderen kan blive gjort tavs af en Prune fra en nedstrømsrouter uden modtagere, hvis der heller ikke er nogen modtagere på LAN-segmentet. Nedstrøms-routere kan være nødt til at justere deres RPF-naboer, så de afspejler vinderen af Assert-processen.
For at gentage det i alle detaljer: Når multicast-trafik modtages på en ikke-RPF-grænseflade, sendes en Prune-meddelelse, forudsat at grænsefladen er punkt-til-punkt. Disse Prune-meddelelser er hastighedsbegrænsede for at sikre, at mængden af dem (potentielt én pr. modtaget multicast) ikke forårsager yderligere problemer.
Hvis den ikke-RPF-grænseflade er et LAN, sendes en Assert-meddelelse. Non-Forwarder-routere sender derefter en Prune-meddelelse på deres RPF-grænseflade, hvis de ikke har brug for multicast-strømmen. Der sendes kun én sådan Prune på tidspunktet for overgangen til ikke at have nogen grænseflader i Outgoing Interface List (OILIST). LAN Prune-modtageren venter med at handle på den i 3 sekunder, så hvis en anden LAN-router stadig har brug for multicast-strømmen, kan den sende en PIM Join-meddelelse for at modvirke (annullere) Prune-meddelelsen. (“Yo, den router har ikke brug for den, men det har jeg stadig!”)
Sæt, at en router har Pruned, og at en modtager noget senere anmoder om multicast-strømmen med en IGMP-meddelelse. Routeren sender derefter en Graft-meddelelse. I realiteten “hey, jeg har brug for den multicast-stream herovre nu”.
Det følgende billede illustrerer dette, ganske vist i noget komprimeret form.
Oplysning af billedet:
(1), måske vælger router E B som RPF-nabo, baseret på unicast-routing tilbage til kilden. Derefter modtager E en multicast-pakke på punkt-til-punkt-grænsefladen fra C. Den sender en rate-limited Prune til C.
(2), routerne E og F på LAN’et udveksler Assert-pakker, når E eller F ser multicast, der er videresendt af den anden af de to. Antag at E vinder, baseret på unicast-routing-metrikken eller -adressen. Så ved F, at han ikke må videresende multicasts på LAN’et. Bemærk, at G og H ikke er involveret, da Ethernet er deres RPF-interface.
(3), antag, at router G ikke har nogen modtagere nedstrøms. Den kan så sende en LAN Prune til Forwarder for LAN’et, router E.
(4), hvis router H har lokale eller downstream-modtagere, imødegår den dette med en LAN Join.
(5), antag, at router D ikke havde nogen downstream- eller lokale modtagere og sendte en Prune til B. Antag, at en af pc’erne til højre for routeren senere sender den en IGMP-meddelelse for den samme multicast-gruppe. Router D kan så sende en PIM Graft til B og bede B om at genoptage udsendelsen af den angivne multicast-gruppe.
PIM-protokol og pakketyper
PIM er en komplet routing-protokol med forskellige typer meddelelser. Jeg har ikke tænkt mig at drønle løs om de forskellige meddelelser. Men jeg synes, at det er værd at tage et kort kig på den, da den fortæller os lidt om protokollen.
PIM bruger Hello beskeder til at finde naboer og danne adjacencies. Hello-meddelelsen sendes til den lokale All-PIM-Routers-multicastadresse, 224.0.0.0.13, hvert 30. sekund (PIMv1 bruger AllRouters, 224.0.0.0.2). Hvert LAN har en PIM-designeret router (DR), der anvendes i PIM Sparse Mode. Det er også IGMPv1 Querier: den højeste IP-adresse på LAN’et. Kommandoen show ip pim neighbor viser naboer og adjacency- og timeroplysninger.
Klargøring tilføjet 12/11/2004: IGMP querier og Designated Router er de to roller, der er tale om. Se her.
I IGMP version 1, “DR er ansvarlig for følgende opgaver:
- Sending PIM register- og PIM join- og prune-meddelelser mod RP for at informere den om værtsgruppemedlemskab.
- Sending IGMP host-query-meddelelser.”
I IGMP version 2 er de afkoblet. IGMP-querier vælges af den laveste IP på LAN’et. PIM vælger DR efter højeste IP på LAN’et for at videresende multicasts til LAN’et. (Dette aflaster arbejdet).
PIM har også en Join/Prune-meddelelse, der bruges som beskrevet ovenfor. Der er også Graft- og Graft ACK-meddelelser, som fortæller os, at Graft udføres pålideligt (i modsætning til den virkelige verden?).
Og der er PIM Assert-meddelelsen.
PIM-SM har yderligere 3 meddelelsestyper: Register, Register-Stop og RP-Reachability (ikke i PIMv2).
Konfigurering af PIM Dense Mode
Konfigurering af PIM-DM er ligefrem let sammenlignet med alt det ovenstående.
Globalt skal du aktivere multicast-routing med kommandoen:
ip multicast-routing
Dernæst skal du på hver grænseflade, du ønsker at deltage i multicasting, aktivere IP multicast og PIM med grænsefladekommandoen:
interface …
ip pim dense-mode
Det er faktisk bedre praksis at konfigurere sparse-dense-tilstand:
interface …
ip pim sparse-dense-mode
Grunden er, at dette giver dig mulighed for simpelthen at migrere nogle eller alle multicast-grupper til Sparse Mode, ved at lade routeren vide om et Rendezvous Point. Og du kan endda gøre dette uden at rekonfigurere en masse routere eller routergrænseflader.
Du kan konfigurere stub-netværk til simpel IP-multicast. Idéen er at lade være med at køre PIM til stubdele af netværket, f.eks. små fjernstationer, for enkelhedens skyld. Dette er en særlig god idé med routere, der ikke er under din kontrol: Du ønsker ikke, at de deler multicast-routing med dine routere. Det eliminerer også PIM-DM-flooding til sådanne routere (med ældre Cisco IOS-udgaver).
For at konfigurere stub multicast skal du konfigurere
ip igmp helper-address a.b.c.d
på alle LAN-grænseflader til stub-routere med potentielle multicast-modtagere. Adressen a.b.c.d er adressen på den centrale PIM-talende router. På den centrale router konfigurerer du et filter til at fravælge alle PIM-meddelelser, som stub-naboen måtte sende, med:
ip pim neighbor-filter access-list
Se også kommandoguiden på URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm .
Der er flere show-kommandoer, der kan hjælpe med fejlfinding af IP-multicast. Dem jeg bedst kan lide:
- show ip mroute
- show ip pim interface
- show ip pim neighbor
- show ip rpf
Da pladsen er trang, henviser jeg til kommandoguiden for at få eksempler.
En note til fejlfinding: Hvis du har multicast med høj båndbredde i dit netværk, skal du sørge for at bruge Prune State Refresh i de nyere Cisco IOS-udgaver, hvis du bruger sparse-dense-tilstand. Jeg er bekymret for, at routere “glemmer”, at de har en RP, og at de vender tilbage til den tætte tilstand med periodisk oversvømmelse. Dette kan være en sjælden utilsigtet hændelse, men det kan virkelig ødelægge din morgen! Du kan også overveje RP robusthedsteknikker også, et emne for vores senere PIM-SM eller Rendezvous Point artikel.
In Conclusion
Den anbefalede bog for en masse multicast emner: Developing IP Multicast Networks: The Definitive Guide to Designing and Deploying CISCO IP Multicast Networks, Beau Williamson.
Et andet ekstremt godt Cisco multicast link kan findes her.
Næste artikel: Skalering med PIM Sparse Mode.