Bevezetés
Ez a cikk az IP Multicastról szóló sorozat folytatása. Megnézzük, hogyan működik az alapvető IP multicast. Ezután megnézzük, hogyan működik a PIM Dense Mode (PIM-DM), hogyan kell konfigurálni, és hogyan kell hibaelhárítani. Ez bemelegít minket, mielőtt egy későbbi cikkben a valamivel összetettebb és jobban skálázható PIM Sparse Mode-ot vesszük sorra.
A kezdeti multicast cikk végén a legfontosabb IETF munkacsoportok linkjeit találjuk. Megtalálható a The Protocols of IP Multicast címen.
Understanding IP Multicast Forwarding
A multicast útválasztási protokoll célja, hogy az útválasztók együttműködve hatékonyan juttassák el a multicast csomagok másolatait az érdekelt vevőkhöz. Ennek során a multicast útválasztási protokoll valószínűleg egy olyan mechanizmust is biztosít, amellyel a szomszédok felfedezhetik és nyomon követhetik a szintén a multicast útválasztási protokollt használó szomszédos útválasztókat.
Amint azt az előző cikkben láttuk, a multicast csomagfolyam fogadásában érdekelt számítógépek az IGMP segítségével értesítik a szomszédos útválasztó(ka)t. Az útválasztók ezután a multicast protokoll segítségével gondoskodnak arról, hogy a multicast csomagfolyam egy példányát elküldjék nekik, hogy továbbíthassák a címzettet tartalmazó LAN-ba. Nem tettünk említést arról, hogy mi történik a csomagfolyam forrásánál. Az IP-multicastban nincs olyan protokoll, amellyel a forrás kommunikálhatna, regisztrálhatna vagy értesíthetné az útválasztókat. A forrás csak elkezdi küldeni az IP multicast csomagokat, és a szomszédos útválasztó(k)n múlik, hogy helyesen jár-e el. (Hogy mi a “helyes dolog”, az a multicast útválasztási protokolltól függ.)
A következő képen a forrás egy multicast csomagot küld piros színnel, a downstream útválasztók pedig lemásolják a csomagot, és elárasztják azt a többi útválasztóhoz és végül az összes LAN-szegmenshez. Mint rövidesen látni fogjuk, ez a Cisco protokollfüggetlen multicast (PIM) multicast útválasztó protokolljának kezdeti (és időszakos) viselkedése, amikor sűrű üzemmódban működik.
A fenti képen észrevehetjük, hogy a kék nyilak a multicast csomagmásolatokat szervezetten továbbítják. Előfordulhat, hogy minden csomagból két példány érkezik egyes útválasztókba vagy LAN-szegmensekbe. A routerek azonban nem “visszafelé” továbbítják a csomagokat. Ez egy jó dolog: gondoljunk bele, mi történne, ha az E router továbbküldené a C-től kapott csomag egy másolatát a B routerhez. B továbbküldené a csomagot A-hoz, aki továbbküldené azt C-hez, és így tovább, egy továbbítási hurokban? Ez egyfajta 3. rétegbeli megfelelője lenne annak, ami a 2. rétegben történik, amikor a Spanning Tree le van tiltva egy huroktopológiában: egy jó módja annak, hogy sok sávszélességet és útválasztókapacitást pazaroljunk.
A multicast továbbítási hurok megelőzésére az IP multicast mindig végrehajt egy RPF-ellenőrzést, amiről rövidesen beszélni fogunk.
Az RPF-ellenőrzés mellett a multicast útválasztási protokollok, például a PIM is működhetnek a nem hatékony működés megelőzésére. Például a képen látható E útválasztónak nem kell minden multicast csomagból két példányt kapnia (egyet B-től, egyet C-től).
A multicast útválasztó protokoll határozza meg, hogy mely interfészekről küldjön ki (vagy ne küldjön ki) példányokat. Ahogy a fenti kép is mutatja, a multicast-továbbítás logikai fák, elágazó útvonalak mentén történik a hálózaton keresztül. Az összes multicast továbbítási információt a multicast állapottábla tárolja, amelyet egyesek multicast útválasztási táblának neveznek. Ez az információ a nagyon hasznos show ip mroute paranccsal tekinthető meg. Nézzük meg röviden a show ip mroute parancs kimeneti mintáját (PIM Dense Mode futtatásával).
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
Az érthetőség kedvéért jegyezzük meg, hogy a 224-239-cel kezdődő címek IP multicast címek vagy csoportok. (A csoport az adott multicast célcímhez tartozó vevők csoportjára utal).
A (*, 233.1.1.1.1)-vel kezdődő bejegyzés egy megosztott multicast fa bejegyzés, néha (*, G) bejegyzésnek is nevezik. (A G itt csak a 223.1.1.1.1-et jelenti). A PIM-DM ezeket nem használja csomagtovábbításra, de az ilyen bejegyzések alatt a multicastban szerepet játszó (ismert IGMP-vevő vagy PIM-szomszéd) interfészek kimenő interfészként szerepelnek.
A (172.16.16.1, 233.1.1.1.1) kezdetű bejegyzést (S, G) bejegyzésnek nevezzük. Az S a forrás, a G a csoport. Ha úgy tetszik, gondoljon erre úgy, mint az IP-fejlécben szereplő forrásra és célállomásra (mivel valójában ott jelennek meg a csomagokban). Ez a bejegyzés egy forrásspecifikus multicast fa egy adott multicast csoporthoz. Általában minden forráshoz és csoporthoz egy ilyen bejegyzés tartozik. Vegyük észre, hogy az unicast útválasztás következő ugrásaként az RPF-szomszéd jelenik meg, és a bejövő interfész az RPF-interfész, az unicast útválasztás által a 172.16.16.1 forrás felé használt interfész. A kimenő interfészek listája azt mutatja, hogy a 172.16.16.1-től a FastEthernet1-en érkező 233.1.1.1.1 célállomású csomagot az Ethernet0-ra másolja ki.
Hibaelhárítás céljából megrajzolhatja a multicast továbbítási fát egy adott (S, G) számára. Ehhez futtassa a show ip mroute parancsot az egyes útválasztókon. Vegyen egy másolatot a hálózati térképéről, és rajzoljon egy kifelé mutató nyilat minden egyes interfészhez a kimenő interfészek listájában (“OIL” vagy “OILIST”). A végeredmény egy, a fenti képhez hasonló diagram lesz.
A PIM-DM show ip mroute kimenetén látható állapotjelzők:
- D = Dense Mode. Csak a (*, G) bejegyzéseknél jelenik meg. A csoport sűrű üzemmódban működik.
- C = Közvetlenül csatlakozó állomás (IGMP!)
- L = Helyi (A router úgy van konfigurálva, hogy tagja legyen a multicast csoportnak).
- P = Pruned (Minden OILIST interfész Prune-ra van állítva). Az útválasztó általában Prune-t küld az RPF szomszédjának, amikor ez történik.
- T = Forwarding via Shortest Path Tree (SPT), jelzi, hogy legalább egy csomagot fogadott/továbbított.
- J = Join SPT. A PIM-DM-ben a (*,G) bejegyzésben mindig be van kapcsolva, nem jelent sokat.
Mi az RPF-ellenőrzés és miért?
Az IP multicast továbbítás mindig végez RPF-ellenőrzést. Az RPF a Reverse Path Forwarding rövidítése. Az RPF-ellenőrzés célja, hogy egyszerű módon próbálja megakadályozni a multicast csomagtovábbítási hurkot. A multicast útválasztó minden egyes multicast folyam esetében ellenőrzi a forráscímet, hogy melyik eszköz küldte a multicastot. Ezután megkeresi a feladót az unicast útválasztási táblázatban, és meghatározza, hogy melyik interfészt használná az unicast csomagok küldésére a multicast forráshoz. Ez az interfész az RPF-interfész, az, amelyen az útválasztó “elvárja” a multicastok fogadását. Gondoljunk erre úgy, mint a “hivatalosan jóváhagyott” interfészre, amely az adott forrásból származó többszörös küldeményeket fogadja. Az útválasztó az RPF-interfészt az adott forrás és az adott multicast-célállomás (csoport) multicast állapotinformációjának részeként tárolja.
Amikor az útválasztó multicast-csomagot kap, az útválasztó nyomon követi, hogy a csomag melyik interfészen érkezett. Ha a csomag az első csomag egy új forrásból, akkor az RPF-interfész kerül meghatározásra és tárolásra az mroute-táblában, az imént tárgyaltak szerint. Ellenkező esetben az útválasztó megkeresi a forrást és a multicast csoportot az mroute táblában. Ha a csomag az RPF-interfészen érkezett, a csomagot lemásolja és továbbítja az mroute-táblában felsorolt minden kimenő interfészen. Ha a csomag nem RPF-interfészen érkezett, akkor a csomag elvetésre kerül. Ha az útválasztó egy személy lenne, akkor ez a következővel lenne egyenértékű: “Miért küldi ezt nekem ez a személy? Biztos összezavarodott, figyelmen kívül hagyom, amit küldött nekem.”
A router nem küldi vissza a csomag másolatát azon az interfészen, amelyen érkezett (az RPF-interfészen). Más szóval, még ha a szomszédos útválasztó az RPF-interfészen valahogyan kérné is, hogy küldjön másolatokat egy multicast folyamból, az útválasztó nem fogja hozzáadni az RPF-interfészt a kimenő interfészek listájához, amelyek megkapják a multicast folyam másolatát. Ez védelmet nyújt az ellen, hogy bármilyen protokollhiba miatt két szomszéd szoros multicast-továbbítási hurokba kerüljön.
Az E útválasztó valószínűleg szintén figyelmen kívül hagyja a két csomagfolyam egyikét, annak alapján, hogy B vagy C csatlakozik-e az RPF-interfészhez. Még egyenlő költségű útvonalak esetén is általában csak egy interfészt választanak RPF-interfésznek. Ha tehát két útválasztót két link köt össze, akkor általában csak az egyiket használják bármelyik forrás alhálózatból érkező többszörös küldésre.
Lásd azonban az ip multicast multipath parancsot (új a Cisco IOS 12.0(8) T, 12.0(5) S verziójában). Ezzel a paranccsal, megfelelően használva, egy adott multicast-csoport különböző forrásai számára teherelosztás valósulhat meg. Mivel ez forrásonként és nem folyamonként történik, ezért inkább a terhelés megosztására hasonlít. A végén nem biztos, hogy nagyon kiegyensúlyozott lesz.
A forgalom terheléselosztása egy csomagfolyam (egy forrás és egy csoport) számára két útválasztó közötti két kapcsolaton keresztül szintén elvégezhető a loopback interfészek közötti GRE-alagutak használatával, bár aggódnék a teljesítményre gyakorolt hatások miatt, ha ezt egy nagy sávszélességű áramlással tennénk.
Apropó, ez azt is elmondja, hogyan irányítsuk az IP-multicastot az általunk választott kapcsolatokon keresztül. Az RPF-ellenőrzés vezérlésével szabályozzuk, hogy hova menjen a multicast forgalom. Ha egy útválasztó nem tanul vissza útvonalakat egy multicast forráshoz valamilyen interfészen, akkor az az interfész nem lesz RPF interfész. Így a távolságvektoros protokollokkal és az “útvonal éhezéssel” (útvonal nem hirdetése a szomszédnak) irányíthatjuk vagy irányíthatjuk a multiküldést.
Később látni fogjuk, hogy minden PIM graft vagy csatlakozás az RPF interfészen keresztül kerül visszaküldésre a forrás (vagy RP, PIM Sparse módban) felé. Azzal, hogy szabályozzuk, hol történik ez a tevékenység, szabályozzuk, hogy a multicast mely linkeken kerül továbbításra. A statikus mroute bejegyzések (statikus útvonalak vissza a forráshoz a multicast RPF ellenőrzés céljából) egy másik módja a multicast forgalom irányításának. Ha / amikor a Multicast MBGP-ről (Multiprotocol BGP for Multicast) beszélünk, látni fogjuk, hogy az MBGP szintén lehetőséget biztosít számunkra a multicast forgalom által használt linkek irányítására vagy ellenőrzésére. Azt is vegye figyelembe, hogy ha az RPF-interfészen nincs engedélyezve az IP multicast, akkor valójában az útválasztó olyan csomagokat vár, ahol nem fogadja azokat. Az RPF-interfésznek mindig olyannak kell lennie, ahol az IP-multiküldés engedélyezve van.
PIM Dense Mode – Overview
A protokollfüggetlen multiküldésnek két módja van, a Dense Mode és a Sparse Mode. Ebben a cikkben csak az előbbire van hely. A PIM-SM-re a következő cikkben térünk ki.
A PIM Dense Mode (PIM-DM) egy meglehetősen egyszerű megközelítést használ az IP multicast útválasztás kezelésére. A PIM-DM alapfeltevése az, hogy a multicast csomagfolyamnak a legtöbb helyen vannak vevői. Erre példa lehet egy céges prezentáció, amelyet a vállalat vezérigazgatója vagy elnöke tart. Ezzel szemben a PIM Sparse Mode (PIM-SM) viszonylag kevesebb vevőt feltételez. Erre példa lehet az új alkalmazottak kezdeti eligazító videója.
Ez a különbség a két protokoll kezdeti viselkedésében és mechanizmusaiban mutatkozik meg. A PIM-SM csak akkor küld multicastokat, ha erre kérik. Míg a PIM-DM a multicast forgalom elárasztásával kezdi, majd Prune üzenettel leállítja azt minden olyan linken, ahol nincs rá szükség. A Prune üzenetet úgy gondolom, hogy az egyik útválasztó közli a másikkal, hogy “most nincs szükségünk erre a multicastra”.
A régebbi Cisco IOS kiadásokban a PIM-DM 3 percenként újra elárasztotta az összes multicast forgalmat. Ez rendben van a kis volumenű multicasthoz, de a nagyobb sávszélességű multicast csomagáramokhoz nem. A Cisco IOS újabb verziói a 12.1(5)T óta támogatják a PIM Dense Mode State Refresh nevű új funkciót. Ez a funkció PIM állapotfrissítő üzeneteket használ a Prune állapot frissítésére a kimenő interfészeken. További előnye, hogy a topológiaváltozások gyorsabban felismerhetők. Alapértelmezés szerint a PIM állapotfrissítő üzenetek 60 másodpercenként kerülnek elküldésre.
Nézzük a fenti képen látható E és F routereket. Amikor két PIM-DM router csatlakozik egy LAN-hoz, látni fogják egymás multicast csomagjait. Az egyiknek továbbítania kell a csomagokat a LAN felé, a másiknak nem. Mindkettő Assert üzenetet küld. A legjobb útválasztási metrika nyer, a magasabb IP-cím dönti el a holtversenyt. Ha különböző útválasztási protokollokat használnak, akkor egy súlyozott útválasztási metrika séma – az adminisztratív távolsághoz hasonlóan – dönti el, hogy melyik útválasztó legyen a továbbító (továbbítja a multicast csomagokat a LAN-ba). A továbbítót elhallgattathatja egy Prune egy olyan downstream útválasztó, amelynek nincs vevője, ha a LAN-szegmensben sincs vevő. A downstream útválasztóknak esetleg módosítaniuk kell az RPF szomszédjukat, hogy tükrözze az Assert folyamat győztesét.
Még egyszer megismételjük ezt teljes részletességgel: amikor multicast forgalom érkezik egy nem-RPF interfészre, Prune üzenetet küldünk, feltéve, hogy az interfész pont-pont közötti. Ezek a Prune üzenetek sebességkorlátozással vannak ellátva, hogy a mennyiségük (potenciálisan egy-egy multicast fogadásonként egy) ne okozzon további problémákat.
Ha a nem-RPF interfész egy LAN, akkor Assert üzenetet küldünk. A nem-továbbító útválasztók ezután Prune üzenetet küldenek az RPF-interfészükön, ha nincs szükségük a multicast folyamra. Csak egy ilyen Prune üzenetet küldenek, a kimenő interfészlistában (OILIST) lévő interfészek hiányára való áttéréskor. A LAN Prune vevője 3 másodpercig késlelteti a reagálást, hogy ha egy másik LAN-router még mindig igényli a multicast folyamot, küldhessen egy PIM Join üzenetet a Prune ellensúlyozására (törlésére). (“Hé, annak az útválasztónak már nincs rá szüksége, de nekem még igen!”)
Tegyük fel, hogy egy útválasztó Prune-olt, és valamivel később egy vevő IGMP üzenettel kéri a multicast streamet. Az útválasztó ezután egy Graft üzenetet küld. Gyakorlatilag: “hé, nekem most kell az a multicast stream ide”.
A következő kép ezt szemlélteti, igaz, kissé tömörített formában.
A kép magyarázata:
(1), talán az E router B-t választja RPF szomszédjának, a forráshoz visszavezető unicast routing alapján. Ezután E egy multicast csomagot kap a pont-pont interfészen C-től. Egy rate-limited Prune-t küld C-nek.
(2), a LAN-on lévő E és F routerek Assert csomagokat cserélnek, amikor E vagy F látja a másik által továbbított multicastot. Tegyük fel, hogy E nyer, az unicast útválasztási metrika vagy cím alapján. Ekkor F tudja, hogy a LAN-on nem továbbítja a multicastokat. Vegyük észre, hogy G és H nem érintett, mivel az Ethernet az ő RPF-interfészük.
(3), tegyük fel, hogy a G útválasztónak nincs vevője downstream. Ekkor küldhet egy LAN Prune-t a LAN továbbítójának, az E router-nek.
(4), ha a H router-nek vannak helyi vagy downstream vevő(i), akkor ezt egy LAN Join-nal viszonozza.
(5), tegyük fel, hogy a D router-nek nincsenek downstream vagy helyi vevői, és küldött egy Prune-t B-nek. Tegyük fel, hogy valamikor később a tőle jobbra lévő PC-k egyike küld neki egy IGMP üzenetet ugyanarra a multicast csoportra. Ekkor a D router küldhet egy PIM Graftot B-nek, kérve B-t, hogy újra küldje neki a megadott multicast csoportot.
PIM protokoll és csomagtípusok
A PIM egy teljes útválasztási protokoll, különböző típusú üzenetekkel. Nem fogok hosszasan dobolni a különböző üzenetekről. De úgy gondolom, hogy érdemes egy rövid pillantást vetni rá, mivel elmond egy keveset a protokollról.
A PIM a Hello üzeneteket használja a szomszédok felfedezésére és a szomszédságok kialakítására. A Hello üzenetet 30 másodpercenként küldi az All-PIM-Routers helyi multicast címére, a 224.0.0.13-ra (a PIMv1 az AllRouters-t használja, 224.0.0.2). Minden LAN-nak van egy PIM kijelölt útválasztója (DR), amelyet a PIM Sparse módban használnak. Ez egyben az IGMPv1 Querier is: a LAN legmagasabb IP-címe. A show ip pim neighbor parancs megmutatja a szomszédokat, valamint a szomszédsági és időzítési információkat.
Magyarázat hozzáadva: 2004.11.12: IGMP Querier és Designated Router a két szóban forgó szerepkör. Lásd itt.
Az IGMP 1. verziójában “A DR a következő feladatokért felelős:
- PIM register és PIM join és prune üzenetek küldése az RP felé, hogy tájékoztassa az RP-t a host csoporttagságról.
- IGMP host-query üzenetek küldése.”
Az IGMP 2. verziójában ezek szét vannak választva. Az IGMP lekérdezőt a LAN legalacsonyabb IP címe választja. A PIM a DR-t a LAN legmagasabb IP-je alapján választja ki, hogy továbbítsa a multicastokat a LAN-ba. (Ez tehermentesíti a munkát).
A PIM-nek van egy Join/Prune üzenete is, amelyet a fent leírtak szerint használnak. Vannak Graft és Graft ACK üzenetek is, ami arról árulkodik, hogy a Graft megbízhatóan történik (ellentétben a való világgal?).
És van a PIM Assert üzenet.
A PIM-SM-nek még 3 üzenettípusa van: Register, Register-Stop és RP-Reachability (nincs a PIMv2-ben).
A PIM Dense Mode konfigurálása
A PIM-DM konfigurálása a fentiekhez képest kifejezetten egyszerű.
Globálisan engedélyezzük a multicast routingot a következő paranccsal:
ip multicast-routing
Ezután minden olyan interfészen, amely részt kíván venni a multicastingban, engedélyezzük az IP multicastot és a PIM-et az interface paranccsal:
interface …
ip pim dense-mode
Ténylegesen jobb gyakorlat a sparse-dense mód konfigurálása:
interface …
ip pim sparse-dense-mode
Az ok az, hogy így egyszerűen áttérhetünk néhány vagy az összes multicast csoportot Sparse módba, azáltal, hogy a router tudomást szerez egy randevúpontról. És ezt még sok útválasztó vagy útválasztóinterfész átkonfigurálása nélkül is megtehetjük.
Egyszerű IP-multicasthoz csonkhálózatokat konfigurálhatunk. Az ötlet az, hogy az egyszerűség kedvéért ne futtassuk a PIM-et a hálózat csonkolt részein, például a kis távoli telephelyeken. Ez különösen jó ötlet olyan útválasztók esetében, amelyek nem az Ön irányítása alatt állnak: nem szeretné, ha megosztanák a multicast útválasztást az Ön útválasztóival. Ez kiküszöböli a PIM-DM elárasztását is az ilyen útválasztók felé (régebbi Cisco IOS-kiadásokkal).
A csonka multicast konfigurálásához konfigurálja
ip igmp helper-address a.b.c.d
minden olyan csonka útválasztó LAN-interfészén, amely potenciális multicast-vevővel rendelkezik. Az a.b.c.d cím a központi PIM-et beszélő útválasztó címe. A központi útválasztón egy szűrőt állítunk be, hogy a csonkaszomszéd által esetlegesen küldött PIM-üzeneteket kikapcsoljuk, a következővel:
ip pim neighbor-filter access-list
Lássuk még a parancsok útmutatóját az URL-címen:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm .
Az IP multicast hibaelhárításában több show parancs is segít. Az általam legjobban kedveltek:
- show ip mroute
- show ip pim interface
- show ip pim neighbor
- show ip rpf
Mivel a hely szűkös, a példákért a Command Reference-ra utalok.
Egy hibaelhárítási megjegyzés: ha valóban nagy sávszélességű multicast van a hálózatban, győződjön meg róla, hogy az újabb Cisco IOS-kiadásokban használja a Prune State Refresh funkciót, ha sparse-dense módot használ. Aggódom amiatt, hogy a routerek “elfelejtik”, hogy van RP-jük, és visszatérnek a sűrű módba, időszakos elárasztással. Ez egy ritka véletlen esemény lehet, de nagyon tönkreteheti a reggelét! Érdemes lehet megfontolni az RP robusztussági technikákat is, ez egy későbbi PIM-SM vagy Rendezvous Point cikkünk témája.
Végkövetkeztetés
Egy csomó multicast témában ajánlott könyv: Developing IP Multicast Networks: The Definitive Guide to Designing and Deploying CISCO IP Multicast Networks, Beau Williamson.
Egy másik rendkívül jó Cisco multicast linket itt találsz.
Következő cikk: Skálázás a PIM Sparse Mode segítségével.