Introduction
Tämä artikkeli jatkaa IP Multicastia käsittelevää sarjaa. Käymme läpi, miten IP multicastin perustoiminnot toimivat. Sen jälkeen tarkastelemme, miten PIM Dense Mode (PIM-DM) toimii, miten se konfiguroidaan ja miten sen vianmääritys tehdään. Tämän pitäisi lämmittää meitä ennen kuin käsittelemme hieman monimutkaisempaa ja skaalautuvampaa PIM Sparse Modea myöhemmässä artikkelissa.
Ensimmäisen multicast-artikkelin lopussa on linkkejä tärkeimpiin IETF-työryhmiin. Se löytyy osoitteesta The Protocols of IP Multicast.
Understanding IP Multicast Forwarding
Monilähetysten reititysprotokollan tarkoitus on antaa reitittimille mahdollisuus työskennellä yhdessä monilähetyspakettien kopioiden tehokkaaksi toimittamiseksi kiinnostuneille vastaanottajille. Tätä tehdessään monilähetysreititysprotokolla tarjoaa todennäköisesti myös mekanismin, jonka avulla naapurit voivat löytää ja seurata naapurireitittimiä, jotka myös käyttävät monilähetysreititysprotokollaa.
Kuten edellisessä artikkelissa nähtiin, ne tietokoneet, jotka ovat kiinnostuneita vastaanottamaan monilähetyspakettivirran, käyttävät IGMP:tä ilmoittaakseen asiasta naapurireitittimelle tai -reitittimille. Reitittimet käyttävät sitten monilähetysprotokollaa järjestääkseen monilähetyspakettivirran kopion lähettämisen niille, jotta ne voivat välittää sen vastaanottajan sisältävään lähiverkkoon. Emme maininneet, mitä pakettivirran lähdepäässä tapahtuu. IP-monilähetyksessä ei ole protokollaa, jolla lähde voisi kommunikoida, rekisteröityä tai ilmoittaa reitittimille. Lähde vain alkaa lähettää IP-monilähetyspaketteja, ja naapurireitittimen tai -reitittimien tehtävänä on toimia oikein. (Se, mikä ”oikea asia” sattuu olemaan, riippuu monilähetysreititysprotokollasta).
Seuraavassa kuvassa lähde lähettää monilähetyspaketin punaisella, ja alempana olevat reitittimet monistavat paketin ja tulvivat sen muille reitittimille ja lopulta kaikille LAN-segmenteille. Kuten pian nähdään, tämä on Ciscon PIM (Protocol Independent Multicast) -monilähetysreititysprotokollan (PIM) alkuperäistä (ja jaksottaista) käyttäytymistä, kun se toimii tiheässä tilassa.
Huomaa ylläolevassa kuvassa, että siniset nuolet lähettävät monilähetyspakettien kopioita eteenpäin järjestäytyneesti. Joihinkin reitittimiin tai LAN-segmentteihin saattaa tulla kaksi kopiota kustakin paketista. Reitittimet eivät kuitenkaan välitä paketteja ”takaperin”. Tämä on hyvä asia: mieti, mitä voisi tapahtua, jos reititin E välittäisi kopion C:ltä saamastaan paketista reitittimelle B. Välittäisikö B sitten paketin eteenpäin A:lle, joka saattaisi välittää sen eteenpäin C:lle ja niin edelleen, jolloin syntyisi välityssilmukka? Tämä olisi eräänlainen Layer 3:n vastine sille, mitä Layer 2:lla tapahtuu, kun Spanning Tree on poissa käytöstä silmukkatopologiassa: hyvä tapa tuhlata paljon kaistanleveyttä ja reititinkapasiteettia.
Monilähetyksen välityssilmukoiden estämiseksi IP-monilähetys suorittaa aina RPF-tarkistuksen, josta puhumme pian.
RPF-tarkistuksen lisäksi monilähetyksen reititysprotokollat, kuten esimerkiksi PIM, voivat myös pyrkiä ehkäisemään tehottomuutta. Esimerkiksi kuvan reitittimen E ei tarvitse vastaanottaa kahta kopiota jokaisesta monilähetyspaketista (yksi B:ltä, yksi C:ltä).
Monilähetysreititysprotokolla määrittelee, mistä rajapinnoista kopioita lähetetään (tai ei lähetetä). Kuten yllä olevasta kuvasta voi päätellä, monilähetysten välitys tapahtuu loogisia puita, verkon läpi haarautuvia polkuja pitkin. Kaikki monilähetyksen välitystiedot tallennetaan monilähetyksen tilatauluun, jota jotkut kutsuvat monilähetyksen reititystauluksi. Näitä tietoja voi tarkastella erittäin hyödyllisellä komennolla show ip mroute. Katsotaanpa lyhyesti esimerkkitulostetta komennosta show ip mroute (kun PIM Dense Mode on käytössä).
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
Ymmärtääksesi tämän, huomaa, että osoitteet, jotka alkavat kirjaimilla 224-239, ovat IP-multicast-osoitteita tai -ryhmiä. (Ryhmä viittaa kyseisen multicast-kohdeosoitteen vastaanottajien ryhmään).
Merkintä, joka alkaa (*, 233.1.1.1.1), on jaetun multicast-puun merkintä, jota joskus kutsutaan (*, G)-merkinnäksi. (G on tässä vain 223.1.1.1.1). PIM-DM ei käytä näitä pakettien välittämiseen, mutta listaa tällaisten merkintöjen alle lähteviksi rajapinnoiksi rajapinnat, joilla on rooli monilähetyksessä (tunnettu IGMP-vastaanottaja tai PIM-naapuri).
Merkintää, joka alkaa (172.16.16.1, 233.1.1.1.1), kutsutaan (S, G)-merkinnäksi. S on lähde, G on ryhmä. Voit halutessasi ajatella näitä IP-otsakkeen lähteenä ja määränpäänä (koska ne todella esiintyvät paketeissa). Tämä merkintä on lähdekohtainen monilähetyspuu tietylle monilähetysryhmälle. Tällaisia merkintöjä on yleensä yksi kutakin lähdettä ja ryhmää kohti. Huomaa, että yksilähetysreitityksen seuraava hyppy näkyy RPF-naapurina, ja saapuva rajapinta on RPF-rajapinta eli rajapinta, jota yksilähetysreititys käyttää lähdettä 172.16.16.1 kohti. Lähtevien rajapintojen luettelosta näkyy, että kaikki FastEthernet1:llä vastaanotetut paketit 172.16.16.1:stä, joiden määränpää on 233.1.1.1.1, kopioidaan ulos Ethernet0:sta.
Voit piirtää monilähetyslähetysten edelleenlähetyspuun tietylle (S, G):lle vianmääritystä varten. Voit tehdä tämän suorittamalla show ip mroute -komennon kussakin reitittimessä. Ota kopio verkkokartasta ja piirrä lähtevien liitäntöjen luettelossa (”OIL” tai ”OILIST”) kullekin liitännälle lähtevä nuoli. Saat tulokseksi jokseenkin yllä olevan kuvan kaltaisen kaavion.
Tilalippuja, joita saatat nähdä PIM-DM:n show ip mroute -tulosteessa:
- D = Dense Mode. Näkyy vain (*, G) merkinnöissä. Ryhmä toimii tiheässä tilassa.
- C = Suoraan yhdistetty isäntä (IGMP!)
- L = Paikallinen (Reititin on konfiguroitu monilähetysryhmän jäseneksi).
- P = Karsittu (Kaikki OILIST-liitännät asetettu Prune-tilaan). Reititin lähettää yleensä Prunea RPF-naapurilleen, kun tämä tapahtuu.
- T = Forwarding via Shortest Path Tree (SPT), ilmaisee vähintään yhden vastaanotetun / välitetyn paketin.
- J = Join SPT. Aina päällä (*,G)-merkinnässä PIM-DM:ssä, ei tarkoita paljoa.
Mikä on RPF-tarkistus ja miksi?
IP-multicast-tiedonsiirto suorittaa aina RPF-tarkistuksen. RPF on lyhenne sanoista Reverse Path Forwarding. RPF-tarkastuksen tavoitteena on yrittää estää multicast-pakettien välityssilmukka yksinkertaisella tavalla. Monilähetysreititin tarkistaa jokaisesta monilähetysvirrasta lähdeosoitteen, mikä laite lähetti monilähetyksen. Sen jälkeen se etsii lähettäjän unicast-reititystaulusta ja määrittää rajapinnan, jota se käyttäisi unicast-pakettien lähettämiseen multicast-lähteelle. Tämä rajapinta on RPF-rajapinta, rajapinta, jolla reititin ”odottaa” vastaanottavansa monilähetyksiä. Ajattele, että se on ”virallisesti hyväksytty” rajapinta monilähetysten vastaanottamiseen kyseisestä lähteestä. Reititin tallentaa RPF-liitännän osaksi kyseisen lähteen ja kyseisen monilähetyskohteen (ryhmän) monilähetystilatietoja.
Kun reititin vastaanottaa monilähetyspaketin, reititin seuraa, mistä liitännästä paketti tuli. Jos paketti on ensimmäinen paketti uudesta lähteestä, RPF-liittymä määritetään ja tallennetaan mroute-taulukkoon, kuten juuri käsiteltiin. Muussa tapauksessa reititin etsii lähteen ja monilähetysryhmän mroute-taulusta. Jos paketti vastaanotettiin RPF-rajapinnalla, paketti kopioidaan ja lähetetään eteenpäin jokaisella mroute-taulukkoon merkityllä lähtevällä rajapinnalla. Jos paketti vastaanotettiin muulla kuin RPF-liittymällä, se hylätään. Jos reititin olisi ihminen, tämä vastaisi kysymystä ”Miksi tuo ihminen lähettää minulle tämän?”. Hän on varmaan hämmentynyt, jätän huomiotta sen, mitä hän juuri lähetti minulle.”
Reititin ei myöskään lähetä kopiota paketista takaisin rajapintaan, josta se tuli (RPF-rajapinta). Toisin sanoen, vaikka RPF-liitännän naapurireititin jotenkin pyytäisi, että sille lähetetään kopioita monilähetysvirrasta, reititin ei lisää RPF-liitäntää niiden lähtevien liitäntöjen luetteloon, jotka saavat kopioita monilähetysvirrasta. Tämä suojaa siltä, ettei minkäänlainen protokollavirhe saisi kahta naapuria tiukkaan monilähetyksen välityssilmukkaan.
Reititin E jättää myös todennäköisesti huomioimatta jommankumman pakettivirran sen perusteella, onko B vai C kytketty RPF-liittymään. Tasakustannuksisillakin reiteillä yleensä vain yksi rajapinta valitaan RPF-rajapinnaksi. Jos sinulla on siis kaksi linkkiä, jotka yhdistävät kaksi reititintä, vain toista käytetään yleensä monilähetyksiin yhdestä lähdeosaverkosta.
Vrt. kuitenkin komento ip multicast multipath (uusi Cisco IOS -versiossa 12.0(8) T, 12.0(5) S). Tämän komennon avulla, oikein käytettynä, voidaan tehdä kuormanjakoa eri lähteille tiettyä multicast-ryhmää varten. Koska tämä on lähdekohtaista eikä virtakohtaista, se muistuttaa enemmänkin kuorman jakamista. Lopputulos ei välttämättä ole kovin tasapainoinen.
Kuormituksen tasaaminen yhden pakettivirran (yksi lähde ja ryhmä) osalta kahden reitittimen välisillä kahdella linkillä voidaan tehdä myös käyttämällä GRE-tunneleita loopback-liitäntöjen välillä, vaikka voisin olla huolissani suorituskykyyn liittyvistä vaikutuksista, joita tämä aiheuttaa suurella kaistanleveydellä kulkevan virran kohdalla.
Tässä kerrotaan muuten myös, miten IP-multicastia ohjataan valitsemiemme linkkien yli. Ohjaamme sitä, minne multicast-liikenne menee ohjaamalla RPF-tarkistusta. Jos reititin ei opi reittejä takaisin multicast-lähteeseen jollakin rajapinnalla, kyseinen rajapinta ei ole RPF-rajapinta. Niinpä etäisyysvektoriprotokollien ja ”reittinälän” (reitin mainitsematta jättäminen naapurille) avulla voimme ohjata tai ohjata multilähetyksiä.
Katsomme myöhemmin, että kaikki PIM-siirrot tai -liitännät lähetetään RPF-rajapinnasta takaisin kohti lähdettä (tai RP:tä PIM Sparse -tilassa). Ohjaamalla sitä, missä tämä toiminta tapahtuu, ohjaamme sitä, millä linkeillä multicast lähetetään eteenpäin. Staattiset mroute-merkinnät (staattiset reitit takaisin lähteeseen monilähetyksen RPF-tarkistusta varten) ovat toinen tapa ohjata monilähetysliikennettä. Jos / kun puhumme Multicast MBGP:stä (Multiprotocol BGP for Multicast), huomaamme, että MBGP tarjoaa meille myös keinon ohjata tai hallita multicast-liikenteen käyttämiä linkkejä. Huomaa myös, että jos RPF-rajapinnalla ei ole IP-multicastia käytössä, reititin tosiasiassa odottaa paketteja, joita se ei saa. RPF-rajapinnan tulisi aina olla sellainen, jossa IP-multicast on käytössä.
PIM Dense Mode – Overview
Protokollariippumattomassa multicastissa on kaksi tilaa, Dense Mode ja Sparse Mode. Tässä artikkelissa on tilaa käsitellä vain ensimmäistä. PIM-SM:ään palataan seuraavassa artikkelissa.
PIM Dense Mode (PIM-DM) käyttää melko yksinkertaista lähestymistapaa IP-multicast-reitityksen käsittelyyn. PIM-DM:n perusoletuksena on, että multicast-pakettivirralla on vastaanottajia useimmissa paikoissa. Esimerkkinä voisi olla yrityksen toimitusjohtajan tai pääjohtajan pitämä yritysesittely. Sen sijaan PIM Sparse Mode (PIM-SM) olettaa, että vastaanottajia on suhteellisen vähän. Esimerkkinä voisi olla uusien työntekijöiden perehdytysvideo.
Tämä ero näkyy näiden kahden protokollan alkukäyttäytymisessä ja mekanismeissa. PIM-SM lähettää monilähetyksiä vain pyydettäessä. Kun taas PIM-DM aloittaa tulvimalla multicast-liikennettä ja pysäyttää sen sitten jokaisella linkillä, jossa sitä ei tarvita, Prune-viestillä. Ajattelen Prune-sanomaa niin, että yksi reititin kertoo toiselle: ”Emme tarvitse tätä multicastia juuri nyt.”
Vanhemmissa Cisco IOS:n versioissa PIM-DM tulvitti kaiken multicast-liikenteen uudelleen kolmen minuutin välein. Tämä sopii hyvin pienelle multicast-volyymille, mutta ei suuremman kaistanleveyden multicast-pakettivirroille. Uudemmat Cisco IOS -versiot tukevat uutta ominaisuutta nimeltä PIM Dense Mode State Refresh 12.1(5)T:stä lähtien. Tämä ominaisuus käyttää PIM-tilan päivitysviestejä lähtevien liitäntöjen Prune-tilan päivittämiseen. Toinen etu on, että topologian muutokset tunnistetaan nopeammin. Oletusarvoisesti PIM-tilan päivitysviestit lähetetään 60 sekunnin välein.
Tarkastellaan reitittimiä E ja F yllä olevassa kuvassa. Kun kaksi PIM-DM-reititintä muodostaa yhteyden lähiverkkoon, ne näkevät toistensa multicast-paketit. Toisen pitäisi välittää paketteja lähiverkkoon ja toisen ei. Molemmat lähettävät Assert-viestejä. Paras reititysmetriikka voittaa, ja korkeampi IP-osoite ratkaisee tasapelin. Jos reitittimet käyttävät eri reititysprotokollia, painotettu reititysmetriikka, joka muistuttaa hallinnollista etäisyyttä, ratkaisee, kumpi reitittimistä on edelleenlähettäjä (välittää monilähetyspaketit lähiverkkoon). Eteenpäinlähettäjä voidaan hiljentää Prune-toiminnolla reitittimestä, jolla ei ole vastaanottajia, jos lähiverkkosegmentillä ei myöskään ole vastaanottajia. Alempana olevat reitittimet saattavat joutua mukauttamaan RPF-naapuriaan, jotta ne vastaisivat Assert-prosessin voittajaa.
Kerratakseni tämän täysin yksityiskohtaisesti: kun monilähetysliikennettä vastaanotetaan muulla kuin RPF-rajapinnalla, lähetetään Prune-viesti, edellyttäen, että rajapinta on pisteestä pisteeseen. Nämä Prune-viestit ovat nopeusrajoitettuja, jotta niiden määrä (mahdollisesti yksi per vastaanotettu multicast-lähetys) ei aiheuta lisäongelmia.
Jos ei-RPF-liittymä on LAN, lähetetään Assert-viesti. Non-Forwarder-reitittimet lähettävät sitten Prune-viestin RPF-rajapinnalleen, jos ne eivät tarvitse monilähetysvirtaa. Vain yksi tällainen Prune lähetetään, kun siirrytään siihen, ettei lähtevien rajapintojen luettelossa (OILIST) ole rajapintoja. LAN Prune -vastaanottaja viivyttää sen käsittelyä 3 sekuntia, jotta jos toinen LAN-reititin tarvitsee edelleen monilähetysvirtaa, se voi lähettää PIM Join -viestin vastapainoksi (peruuttaakseen) Prune-viestin. (”Hei, tuo reititin ei tarvitse sitä, mutta minä tarvitsen!”)
Oletetaan, että reititin on karsinut, ja jonkin ajan kuluttua vastaanotin pyytää monilähetysvirtaa IGMP-viestillä. Tämän jälkeen reititin lähettää Graft-viestin. Käytännössä ”hei, tarvitsen tuon multicast-virran nyt tänne”.
Oheinen kuva havainnollistaa tätä, tosin hieman tiivistettynä.
Kuvan selitys:
(1), ehkä reititin E valitsee RPF-naapurikseen B:n perustuen unicast-reititykseen takaisin lähteelle. Sitten E vastaanottaa monilähetyspaketin point-to-point-liitännässä C:ltä. Se lähettää nopeusrajoitetun Prune-paketin C:lle.
(2), lähiverkon reitittimet E ja F vaihtavat keskenään Assert-paketteja, kun E tai F näkee, että monilähetyspaketti on välitetty eteenpäin jommankumman toimesta. Oletetaan, että E voittaa unicast-reititysmetriikan tai -osoitteen perusteella. Tällöin F tietää, ettei se saa välittää monilähetyksiä lähiverkossa. Huomaa, että G ja H eivät ole mukana, koska Ethernet on niiden RPF-rajapinta.
(3), Oletetaan, että reitittimellä G ei ole vastaanottimia alavirtaan. Tällöin se voi lähettää LAN Prune -viestin LAN:n välittäjälle, reitittimelle E.
(4), jos reitittimellä H on paikallisia tai alavirtaan tulevia vastaanottimia, se vastaa tähän LAN Join -viestillä.
(5), oletetaan, että reitittimellä D ei ole alavirtaan tulevia tai paikallisia vastaanottimia ja se lähetti Prune -viestin reitittimelle B. Oletetaan, että joskus myöhemmin yksi sen oikealla puolella olevista PC:stä lähettää sille IGMP-viestin samasta monilähetysryhmästä. Reititin D voi tällöin lähettää B:lle PIM Graft -viestin, jossa se pyytää B:tä lähettämään sille uudelleen määritellyn monilähetysryhmän.
PIM-protokolla ja pakettityypit
PIM on täysimittainen reititysprotokolla, jossa on monenlaisia viestejä. En aio rummuttaa eri viesteistä. Mutta mielestäni se kannattaa katsoa lyhyesti, koska se kertoo hieman protokollasta.
PIM käyttää Hello-viestejä naapureiden löytämiseen ja vierekkäisyyksien muodostamiseen. Hello lähetetään All-PIM-Routersin paikalliseen multicast-osoitteeseen, 224.0.0.13, 30 sekunnin välein (PIMv1 käyttää AllRoutersia, 224.0.0.2). Jokaisella lähiverkolla on PIM Designated Router (DR), jota käytetään PIM Sparse -tilassa. Se on myös IGMPv1 Querier: lähiverkon korkein IP-osoite. Komento show ip pim neighbor näyttää naapurit sekä naapuruus- ja ajastintiedot.
Tarkennus lisätty 11.12.2004: IGMP Querier ja Designated Router ovat kyseiset kaksi roolia. Katso tästä.
IgMP-versiossa 1 ”DR vastaa seuraavista tehtävistä:
- PIM-rekisteröinti- ja PIM-liittymis- ja prune-viestien lähettäminen RP:lle, jotta se saa tiedon isäntäryhmän jäsenyydestä.
- IgMP-isäntäkyselyviestien lähettäminen.”
IgMP-versiossa 2 ne on erotettu toisistaan. IGMP-kyselijä valitaan lähiverkon alimman IP:n mukaan. PIM valitsee DR:n LAN:n korkeimman IP:n mukaan välittämään monilähetyksiä LAN:iin. (Tämä kuormittaa työtä).
PIM:ssä on myös Join/Prune-viesti, jota käytetään edellä kuvatulla tavalla. On myös Graft- ja Graft ACK-viestit, jotka kertovat, että Graft tehdään luotettavasti (toisin kuin reaalimaailmassa?).
Ja on vielä PIM Assert-viesti.
PIM-SM:ssä on vielä 3 viestityyppiä: Register, Register-Stop ja RP-Reachability (ei PIMv2:ssa).
PIM Dense Moden konfigurointi
PIM-DM:n konfigurointi on suorastaan helppoa verrattuna kaikkiin edellä mainittuihin.
Globaalisesti ota monilähetysreititys käyttöön komennolla:
ip multicast-routing
Sitten jokaisessa rajapinnassa, jonka haluat osallistua monilähetykseen, ota IP-monilähetys ja PIM käyttöön interface-komennolla:
interface …
ip pim dense-mode
Tosiasiassa on parempi käytäntö määrittää sparse-dense-tila:
interface …
ip pim sparse-dense-mode
Syy tähän on se, että näin voit yksinkertaisesti siirtää joitakin tai kaikki multicast-ryhmät Sparse-tilaan ilmoittamalla reitittimelle Rendezvous Pointista. Ja voit jopa tehdä tämän konfiguroimatta uudelleen paljon reitittimiä tai reititinrajapintoja.
Voit määrittää stub-verkkoja yksinkertaista IP-multicastia varten. Ideana on yksinkertaisuuden vuoksi olla ajamatta PIM:ää stub-verkon osiin, kuten pieniin etäsijainteihin. Tämä on erityisen hyvä ajatus sellaisten reitittimien kanssa, jotka eivät ole hallinnassasi: et halua niiden jakavan monilähetysreititystä reitittimesi kanssa. Se myös estää PIM-DM-tulvan tulvimisen tällaisiin reitittimiin (vanhemmilla Cisco IOS -versioilla).
Kannattaa määrittääksesi stub-multicastin, määritä
ip igmp helper-address a.b.c.d
kaikkiin stub-reitittimen LAN-liitäntöihin, joissa on potentiaalisia multicast-vastaanottajia. Osoite a.b.c.d on PIM:ää puhuvan keskusreitittimen osoite. Keskusreitittimessä määritetään suodatin, joka virittää pois kaikki PIM-viestit, joita kantanaapuri saattaa lähettää, seuraavasti:
ip pim neighbor-filter access-list
Katso myös komento-opas URL-osoitteesta:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm .
On olemassa useita show-komentoja, joiden avulla voidaan auttaa IP-monilähetyspalveluiden vianmäärityksessä. Niistä pidän eniten:
- show ip mroute
- show ip pim interface
- show ip pim neighbor
- show ip rpf
Koska tila on tiukka, viittaan esimerkkejä varten komento-oppaaseen.
Yksi vianmäärityshuomautus: jos verkossasi on suuren kaistanleveyden monilähetyksiä, varmista, että käytät Prune State Refresh -toimintoa uudemmissa Cisco IOS -julkaisuissa, jos käytät sparse-dense-tilaa. Olen huolissani siitä, että reitittimet ”unohtavat”, että niillä on RP, ja palaavat takaisin tiheään tilaan, jossa on ajoittaista tulvimista. Tämä saattaa olla harvinainen vahinko, mutta se voi todella pilata aamusi! Voit myös harkita RP:n kestävyystekniikoita, mikä on aihe myöhempään PIM-SM- tai Rendezvous Point -artikkeliin.
Johtopäätös
Suositeltava kirja moniin multicast-aiheisiin: Developing IP Multicast Networks: The Definitive Guide to Designing and Deploying CISCO IP Multicast Networks, Beau Williamson.
Toinen erittäin hyvä Cisco multicast-linkki löytyy täältä.
Seuraava artikkeli: Scaling with PIM Sparse Mode.