Introducere
Acest articol continuă seria despre IP Multicast. Vom arunca o privire asupra modului în care funcționează multicastul IP de bază. Ne vom uita apoi la modul în care funcționează PIM Dense Mode (PIM-DM), cum se configurează și cum se depanează. Acest lucru ar trebui să ne încălzească înainte de a aborda modul PIM Sparse Mode, puțin mai complex și mai scalabil, într-un articol ulterior.
Articolul inițial despre multicast conține la sfârșitul său link-uri către grupurile de lucru IETF cheie. Acesta poate fi găsit la The Protocols of IP Multicast.
Understanding IP Multicast Forwarding
Scopul unui protocol de rutare multicast este de a permite routerelor să lucreze împreună pentru a livra eficient copii ale pachetelor multicast către receptorii interesați. În acest proces, probabil că protocolul de rutare multicast oferă, de asemenea, un mecanism pentru ca vecinii să descopere și să urmărească routerele vecine care utilizează, de asemenea, protocolul de rutare multicast.
Așa cum am văzut în ultimul articol, acele calculatoare interesate să primească un flux de pachete multicast utilizează IGMP pentru a notifica routerul (routerele) adiacent(e). Routerele folosesc apoi protocolul de multicast pentru a aranja ca o copie a fluxului de pachete multicast să le fie trimisă, astfel încât să o poată redirecționa pe LAN-ul care conține receptorul. Nu am făcut nicio mențiune cu privire la ceea ce se întâmplă la capătul sursă al fluxului de pachete. În IP multicast, nu există un protocol prin care sursa să comunice, să se înregistreze sau să notifice routerele. Sursa pur și simplu începe să trimită pachete IP multicast și depinde de routerul (routerele) vecin(e) să facă ceea ce trebuie. (Ceea ce se întâmplă să fie „lucrul corect” depinde de protocolul de rutare multicast).
Imaginea următoare arată o sursă care trimite un pachet multicast în roșu, iar routerele din aval dublează pachetul și îl inundă către alte routere și, în cele din urmă, către toate segmentele LAN. După cum vom vedea în scurt timp, acesta este comportamentul inițial (și periodic) al protocolului de rutare multicast PIM (Protocol Independent Multicast) de la Cisco, atunci când acționează în modul Dense Mode.
Observați în imaginea de mai sus că săgețile albastre redirecționează copiile pachetelor multicast într-un mod organizat. Este posibil să existe două copii ale fiecărui pachet care intră în unele dintre routere sau segmente LAN. Dar routerele nu redirecționează pachetele „înapoi”. Acesta este un lucru bun: gândiți-vă la ce s-ar putea întâmpla dacă routerul E ar transmite o copie a pachetului pe care l-a primit de la C către routerul B. Ar transmite apoi B pachetul către A, care l-ar putea transmite către C, și așa mai departe, într-o buclă de redirecționare? Acesta ar fi un fel de echivalent de nivel 3 a ceea ce se întâmplă la nivelul 2 atunci când Spanning Tree este dezactivat într-o topologie în buclă: o modalitate bună de a irosi multă lățime de bandă și capacitate a routerului.
Pentru a preveni buclele de redirecționare multicast, IP multicast efectuează întotdeauna o verificare RPF, despre care vom vorbi în scurt timp.
În plus față de verificarea RPF, protocoalele de rutare multicast, cum ar fi PIM, pot funcționa, de asemenea, pentru a preveni ineficiența. De exemplu, routerul E din imagine nu trebuie să primească două copii ale fiecărui pachet multicast (una de la B, una de la C).
Protocolul de rutare multicast determină ce interfețe să trimită copii (sau să nu trimită copii). După cum sugerează imaginea de mai sus, redirecționarea multicast are loc de-a lungul unor arbori logici, căi de ramificare prin rețea. Toate informațiile de redirecționare multicast sunt stocate în tabela de stare multicast, pe care unii o numesc tabela de rutare multicast. Aceste informații pot fi vizualizate cu ajutorul comenzii foarte utile, show ip mroute. Să aruncăm o scurtă privire la o mostră de ieșire din comanda show ip mroute (cu PIM Dense Mode în funcțiune).
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
Pentru a înțelege acest lucru, rețineți că adresele care încep cu 224-239 sunt adrese sau grupuri IP multicast. (Grupul se referă la grupul de receptori pentru acea adresă de destinație multicast).
Entrarea care începe cu (*, 233.1.1.1.1) este o intrare de arbore de multicast partajat, denumită uneori o intrare (*, G). (G aici este doar 223.1.1.1.1). PIM-DM nu le utilizează pentru expedierea pachetelor, dar listează interfețele cu rol în multicast (receptor IGMP cunoscut sau vecin PIM) ca interfețe de ieșire sub astfel de intrări.
Intrarea care începe cu (172.16.16.1, 233.1.1.1) este menționată ca o intrare (S, G). S este sursa, G este grupul. Dacă preferați, gândiți-vă la acestea ca la sursa și destinația din antetul IP (deoarece acolo apar efectiv în pachete). Această intrare este un arbore de multicast specific sursei pentru un anumit grup de multicast. În general, va exista o astfel de intrare pentru fiecare sursă și grup. Rețineți că următorul salt de rutare unicast apare ca vecin RPF, iar interfața de intrare este interfața RPF, interfața utilizată de rutarea unicast către sursa 172.16.16.1. Lista interfețelor de ieșire arată că orice pachet de la 172.16.16.1 cu destinația 233.1.1.1.1 primit pe FastEthernet1 va fi copiat pe Ethernet0.
Puteți desena arborele de redirecționare multicast pentru un anumit (S, G) în scopul depanării. Pentru a face acest lucru, executați comanda show ip mroute pe fiecare router. Luați o copie a hărții rețelei și desenați o săgeată de ieșire pentru fiecare interfață din lista interfețelor de ieșire („OIL” sau „OILIST”). Veți sfârși cu o diagramă oarecum asemănătoare cu imaginea de mai sus.
Semnele de stare pe care le puteți vedea în ieșirea PIM-DM show ip mroute:
- D = Dense Mode. Apare numai pe intrările (*, G). Grupul funcționează în modul Dense.
- C = Directly Connected Host (IGMP!)
- L = Local (Routerul este configurat pentru a fi membru al grupului multicast).
- P = Pruned (Toate interfețele OILIST setate la Prune). Routerul trimite în general Prune vecinului său RPF atunci când se întâmplă acest lucru.
- T = Forwarding via Shortest Path Tree (SPT), indică cel puțin un pachet primit / transmis.
- J = Join SPT. Întotdeauna activat în intrarea (*,G) din PIM-DM, nu înseamnă mare lucru.
Ce este verificarea RPF și de ce?
Transmiterea multicast IP efectuează întotdeauna o verificare RPF. RPF înseamnă Reverse Path Forwarding (redirecționare pe calea inversă). Scopul verificării RPF este de a încerca să prevină o buclă de redirecționare a pachetelor multicast într-un mod simplu. Pentru fiecare flux de multicast, routerul de multicast verifică adresa sursă, ce dispozitiv a trimis multicastul. Apoi caută expeditorul în tabelul de rutare unicast și determină interfața pe care ar trebui să o folosească pentru a trimite pachete unicast către sursa multicast. Această interfață este interfața RPF, cea pe care routerul „se așteaptă” să primească multicaste. Gândiți-vă la aceasta ca la interfața „aprobată oficial” pentru primirea de multicaste de la sursa respectivă. Routerul stochează interfața RPF ca parte a informațiilor de stare multicast pentru acea sursă particulară și acea destinație (grup) multicast particulară.
Când un pachet multicast este primit de router, routerul urmărește pe ce interfață a venit pachetul. Dacă pachetul este primul pachet de la o sursă nouă, interfața RPF este determinată și stocată în tabelul mroute, așa cum tocmai am discutat. În caz contrar, routerul caută sursa și grupul multicast în tabelul mroute. Dacă pachetul a fost primit pe interfața RPF, pachetul este copiat și transmis pe fiecare interfață de ieșire listată în tabelul mroute. Dacă pachetul a fost primit pe o interfață non-RPF, acesta este eliminat. Dacă routerul ar fi o persoană, acest lucru ar fi echivalentul întrebării „De ce îmi trimite această persoană asta? Trebuie să fie confuză, voi ignora ceea ce tocmai mi-a trimis.”
Routerul nu trimite, de asemenea, o copie a unui pachet înapoi pe interfața pe care a venit (interfața RPF). Cu alte cuvinte, chiar dacă routerul vecin de pe interfața RPF ar solicita cumva să i se trimită copii ale unui flux de multicast, routerul nu va adăuga interfața RPF la lista interfețelor de ieșire care primesc copii ale fluxului de multicast. Acest lucru protejează împotriva oricărui fel de eroare de protocol care ar face ca doi vecini să intre într-o buclă strânsă de redirecționare multicast.
Routerul E ignoră probabil și unul dintre cele două fluxuri de pachete, în funcție de faptul dacă B sau C este conectat la interfața RPF. Chiar și cu rute cu costuri egale, în mod normal, doar o singură interfață este aleasă ca interfață RPF. Așadar, dacă aveți două legături care conectează două routere, doar una dintre ele va fi utilizată în mod normal pentru multicast de la orice subrețea sursă.
Vezi totuși comanda ip multicast multipath (nouă în Cisco IOS versiunea 12.0(8) T, 12.0(5) S). Cu această comandă, utilizată corect, poate exista o echilibrare a încărcăturii pentru diferite surse pentru un anumit grup multicast. Având în vedere că acest lucru se face per sursă și nu per flux, devine de fapt mai mult ca o împărțire a încărcăturii. S-ar putea să nu ajungă să fie foarte echilibrată.
Echilibrarea încărcării traficului pentru un flux de pachete (o sursă și un grup) pe două legături între două routere se poate face, de asemenea, folosind tuneluri GRE între interfețele loopback, deși m-aș putea îngrijora în legătură cu implicațiile asupra performanței de a face acest lucru cu un flux de lățime de bandă mare.
Apropoi, acest lucru ne spune, de asemenea, cum să direcționăm IP multicast pe legături la alegerea noastră. Controlăm încotro se îndreaptă traficul multicast prin controlul verificării RPF. Dacă un router nu învață rutele de întoarcere către o sursă multicast pe o anumită interfață, atunci acea interfață nu va fi interfața RPF. Așadar, cu ajutorul protocoalelor vectoriale de distanță și al „rutei starvation” (nepublicarea unei rute către un vecin), putem dirija sau direcționa multicastul.
Vom vedea mai târziu că orice grefe sau îmbinări PIM sunt trimise pe interfața RPF, înapoi către sursă (sau RP, în modul PIM Sparse). Controlând unde are loc această activitate, controlăm legăturile pe care este redirecționat multicastul. Intrările statice mroute (rute statice către sursă în scopul verificării RPF pentru multicast) reprezintă o altă modalitate de direcționare a traficului de multicast. Dacă / când vom vorbi despre Multicast MBGP (Multiprotocol BGP for Multicast), vom vedea că MBGP ne oferă, de asemenea, o modalitate de a direcționa sau de a controla legăturile utilizate de traficul de multicast. De asemenea, rețineți că, dacă interfața RPF nu are activată funcția IP multicast, atunci, de fapt, routerul așteaptă pachete acolo unde nu le va primi. Interfața RPF ar trebui să fie întotdeauna una în care IP multicastul este activat.
PIM Dense Mode – Overview
Protocol Independent Multicast are două moduri, Dense Mode și Sparse Mode. Acest articol are spațiu doar pentru a-l acoperi pe primul. Vom ajunge la PIM-SM în următorul articol.
PIM Dense Mode (PIM-DM) utilizează o abordare destul de simplă pentru a gestiona rutarea IP multicast. Ipoteza de bază din spatele PIM-DM este că fluxul de pachete multicast are receptori în majoritatea locațiilor. Un exemplu în acest sens ar putea fi o prezentare a unei companii de către CEO sau președintele unei companii. Prin contrast, PIM Sparse Mode (PIM-SM) presupune un număr relativ mai mic de receptori. Un exemplu ar fi videoclipul inițial de orientare pentru noii angajați.
Această diferență se manifestă în comportamentul și mecanismele inițiale ale celor două protocoale. PIM-SM trimite multicaste doar atunci când i se solicită acest lucru. În timp ce PIM-DM începe prin inundarea traficului multicast, iar apoi îl oprește pe fiecare legătură unde nu este necesar, folosind un mesaj Prune. Mă gândesc la mesajul Prune ca la un router care îi spune altuia „nu avem nevoie de acel multicast aici, chiar acum”.
În versiunile mai vechi ale Cisco IOS, PIM-DM ar re-inunda tot traficul multicast la fiecare 3 minute. Acest lucru este în regulă pentru multicast de volum redus, dar nu și pentru fluxurile de pachete multicast cu lățime de bandă mai mare. Versiunile mai recente ale Cisco IOS acceptă o nouă funcție numită PIM Dense Mode State Refresh, începând cu 12.1(5)T. Această caracteristică utilizează mesaje de reîmprospătare a stării PIM pentru a reîmprospăta starea Prune pe interfețele de ieșire. Un alt beneficiu este că schimbările de topologie sunt recunoscute mai rapid. În mod implicit, mesajele de reîmprospătare a stării PIM sunt trimise la fiecare 60 de secunde.
Considerați routerele E și F din imaginea de mai sus. Atunci când două routere PIM-DM se conectează la o rețea LAN, ele vor vedea pachetele multicast unul de la celălalt. Unul dintre ele ar trebui să redirecționeze pachetele către LAN, iar celălalt nu. Ambele trimit mesaje Assert. Cea mai bună metrică de rutare câștigă, cu o adresă IP mai mare drept criteriu de departajare. În cazul în care folosesc protocoale de rutare diferite, o schemă de metrică de rutare ponderată, oarecum asemănătoare cu distanța administrativă, stabilește care router va fi Forwarder (care transmite pachetele multicast către LAN). Forwarder-ul poate fi redus la tăcere de un Prune de la un router din aval care nu are receptori, în cazul în care, de asemenea, nu există receptori pe segmentul LAN. Este posibil ca routerele din aval să fie nevoite să își ajusteze vecinul RPF, pentru a reflecta câștigătorul procesului Assert.
Pentru a repeta acest lucru în detaliu: atunci când traficul multicast este primit pe o interfață non-RPF, se trimite un mesaj Prune, cu condiția ca interfața să fie punct-la-punct. Aceste mesaje Prune sunt limitate în viteză, pentru a se asigura că volumul lor (potențial, unul pentru fiecare multicast primit) nu cauzează probleme suplimentare.
Dacă interfața non-RPF este o rețea LAN, se trimite un mesaj Assert. Routerele non-Forwarder trimit apoi un Prune pe interfața lor RPF dacă nu au nevoie de fluxul de multicast. Se trimite un singur astfel de Prune, în momentul în care se face tranziția către lipsa interfețelor din lista interfețelor de ieșire (OILIST). Receptorul LAN Prune întârzie să acționeze asupra acestuia timp de 3 secunde, astfel încât, dacă un alt router LAN are încă nevoie de fluxul de multicast, acesta poate trimite un mesaj PIM Join pentru a contracara (anula) Prune-ul. („Yo, acel router nu are nevoie de el, dar eu încă am nevoie!”)
Să presupunem că un router a făcut Pruned, iar ceva mai târziu un receptor solicită fluxul multicast cu un mesaj IGMP. Routerul trimite apoi un mesaj Graft. De fapt, „hei, am nevoie de acel flux multicast aici, acum”.
Imaginea următoare ilustrează acest lucru, recunoscându-se că într-o formă oarecum comprimată.
Explicarea imaginii:
(1), probabil că routerul E îl alege pe B ca vecin RPF, pe baza rutei unicast înapoi la sursă. Apoi, E primește un pachet multicast pe interfața punct-la-punct de la C. Acesta trimite un Prune cu viteză limitată către C.
(2), routerele E și F de pe LAN fac schimb de pachete Assert, atunci când E sau F vede multicastul redirecționat de celălalt dintre cei doi. Să presupunem că E câștigă, pe baza metricii sau a adresei de rutare unicast. În acest caz, F știe că nu trebuie să transmită multicaste pe LAN. Rețineți că G și H nu sunt implicate, deoarece Ethernet este interfața lor RPF.
(3), să presupunem că routerul G nu are receptori în aval. Acesta poate trimite atunci un LAN Prune către Forwarder pentru LAN, routerul E.
(4), dacă routerul H are receptor(i) local(i) sau în aval, acesta contracarează acest lucru cu un LAN Join.
(5), să presupunem că routerul D nu are receptori în aval sau locali și a trimis un Prune către B. Să presupunem că, ceva mai târziu, unul dintre PC-urile din dreapta sa îi trimite un mesaj IGMP pentru același grup multicast. Routerul D poate trimite atunci un PIM Graft către B, cerându-i lui B să reia trimiterea grupului multicast specificat.
Protocolul PIM și tipurile de pachete
PIM este un protocol de rutare complet, cu diferite tipuri de mesaje. Nu am de gând să trăncănesc la nesfârșit despre diferitele mesaje. Dar cred că merită să aruncăm o scurtă privire, deoarece ne spune câte ceva despre protocol.
PIM folosește mesajele Hello pentru a descoperi vecinii și a forma adiacențe. Hello este trimis la adresa locală multicast All-PIM-Routers, 224.0.0.13, la fiecare 30 de secunde (PIMv1 folosește AllRouters, 224.0.0.2). Fiecare LAN are un PIM Designated Router (DR), utilizat în modul PIM Sparse. Acesta este, de asemenea, IGMPv1 Querier: cea mai înaltă adresă IP din LAN. Comanda show ip pim neighbor arată vecinii și informațiile despre adiacență și cronometru.
Clarificare adăugată la 12/11/2004: IGMP querier și Designated Router sunt cele două roluri în cauză. A se vedea aici.
În IGMP versiunea 1, „DR este responsabil pentru următoarele sarcini:
- În trimiterea mesajelor PIM register și PIM join și prune către RP pentru a-l informa despre apartenența la grupul de gazde.
- În trimiterea mesajelor IGMP host-query.”
În IGMP versiunea 2, acestea sunt decuplate. Interogatorul IGMP este ales de cel mai mic IP de pe LAN. PIM selectează DR în funcție de cel mai mare IP din LAN, pentru a transmite multicaste către LAN. (Acest lucru descarcă munca).
PIM are, de asemenea, un mesaj Join/Prune, utilizat conform descrierii de mai sus. Există, de asemenea, mesaje Graft și Graft ACK, ceea ce ne spune că Graft se face în mod fiabil (spre deosebire de lumea reală?).
Și mai există și mesajul PIM Assert.
PIM-SM are încă 3 tipuri de mesaje: Register, Register-Stop și RP-Reachability (nu în PIMv2).
Configurarea PIM Dense Mode
Configurarea PIM-DM este de-a dreptul ușoară în comparație cu toate cele de mai sus.
La nivel global, activați rutarea multicast cu comanda:
ip multicast-routing
Apoi, pe fiecare interfață pe care doriți să participați la multicast, activați IP multicast și PIM cu comanda interface:
interfață …
ip pim dense-mode
De fapt, este o practică mai bună să configurați modul sparse-dense:
interfață …
ip pim sparse-dense-mode
Motivul este că acest lucru vă permite să migrați pur și simplu unele sau toate grupurile multicast în modul Sparse, anunțând routerul despre un punct de întâlnire. Și puteți face acest lucru chiar și fără a reconfigura o mulțime de routere sau interfețe de router.
Puteți configura rețele stub pentru multicast IP simplu. Ideea este de a nu rula PIM pentru părți stub ale rețelei, cum ar fi site-urile mici la distanță, pentru simplitate. Aceasta este o idee deosebit de bună în cazul routerelor care nu se află sub controlul dumneavoastră: nu doriți ca acestea să împartă rutarea multicast cu routerele dumneavoastră. De asemenea, elimină inundarea PIM-DM către astfel de routere (cu versiunile mai vechi ale Cisco IOS).
Pentru a configura stub multicast, configurați
ip igmp helper-address a.b.c.d
pe orice interfață LAN a routerului stub cu potențiali receptori de multicast. Adresa a.b.c.d este adresa routerului central vorbitor de PIM. Pe routerul central, configurați un filtru pentru a respinge orice mesaje PIM pe care vecinul stub le-ar putea trimite, cu:
ip pim neighbor-filter access-list
Vezi, de asemenea, Ghidul de comenzi la adresa URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm .
Există mai multe comenzi show pentru a ajuta la depanarea multicastului IP. Cele care îmi plac cel mai mult:
- show ip mroute
- show ip pim interface
- show ip pim neighbor
- show ip rpf
Din moment ce spațiul este limitat, vă voi trimite la Ghidul de comenzi pentru exemple.
O singură notă de depanare: dacă aveți multicast cu lățime de bandă mare în rețeaua dvs., asigurați-vă că utilizați Prune State Refresh în versiunile mai noi ale Cisco IOS dacă utilizați modul sparse-dense. Mă îngrijorează faptul că routerele „uită” că au un RP și revin la modul Dense, cu inundații periodice. Aceasta ar putea fi o întâmplare accidentală rară, dar ar putea să vă strice cu adevărat dimineața! De asemenea, ați putea dori să luați în considerare și tehnicile de robustețe RP, un subiect pentru articolul nostru ulterior despre PIM-SM sau Rendezvous Point.
În concluzie
Cartea recomandată pentru o mulțime de subiecte legate de multicast: Developing IP Multicast Networks: The Definitive Guide to Designing and Deploying CISCO IP Multicast Networks, Beau Williamson.
Un alt link extrem de bun despre multicast de la Cisco poate fi găsit aici.
Articolul următor: Scalarea cu PIM Sparse Mode.
.