Protocolul PIM. Protocoale PIM și IGMP
Protocolul PIM-SM este una dintre cele două versiuni ale protocolului PIM (Protocol Independent Multicast) descrise în specificația RFC 2362:
- versiuni de mod dens PIM-DM (Protocol Independent Multicast - Dense Mode);
- versiuni ale modului descărcat PIM-SM (Protocol Independent Multicast - Sparse Mode).
Aceste versiuni diferă semnificativ în modul în care construiesc și utilizează arborele întindere, dar au și un lucru în comun. Este inclusă în numele fiecăruia dintre aceste protocoale și înseamnă independență a acestui protocol din protocoale de rutare specifice. Dacă DVMPR utilizează mecanisme RIP în funcționarea sa, iar protocolul MOSPF este o extensie protocol OSPF, atunci protocolul PIM poate funcționa împreună cu orice protocol de rutare. Protocolul PIM folosește tabele de rutare gata făcute pentru a redirecționa pachete multicast și mesaje de serviciu și nu contează ce protocol folosesc routerele pentru a construi aceste tabele.
Protocolul PIM-DM este similar cu protocolul DVMPR. Acesta, fiind, de asemenea, un protocol de mod dens, construiește arbori pentru livrarea pachetelor multicast cu partea de sus la sursă, folosind verificări pentru progresul pe calea inversă și tehnici de difuzare și trunchiere. Principala diferență este că se aplică PIM-DM masă gata făcută rutare, mai degrabă decât construirea ei în sine, așa cum face DVMPR.
Caracteristica principală a protocolului PIM-SM este că este proiectat să funcționeze în modul descărcat, adică trimite pachete multicast numai atunci când este solicitat în mod explicit de către destinatar. Pentru a furniza date fiecărui grup specific de destinatari, protocolul PIM-SM construiește un arbore partajat, comun tuturor surselor acestui grup (Fig. 1).
Orez. 1. Arborele de protocol PIM-SM partajat
Partea de sus a arborelui partajat nu poate fi localizată în sursă, deoarece pot exista mai multe surse. Ca vârf al arborelui partajat, se folosește un router special dedicat acestui scop, care îndeplinește funcțiile de punct de întâlnire (RP). Toate routerele dintr-un domeniu PIM-SM trebuie să aibă informații consistente despre locația punctului de întâlnire. Grupuri diferite pot avea aceleași puncte de întâlnire sau diferite.
Cel mai comun și poate cel mai într-un mod simplu Configurarea punctelor de întâlnire locale (în cadrul unui domeniu PIM-SM) înseamnă a le atribui static între mai multe routere ale unui anumit domeniu. Acest lucru are ca rezultat o configurație foarte specifică și facilitează găsirea erorilor în viitor decât în cazul altor abordări.
Pentru destinatarii fiecărui grup specific și sursele care difuzează către acest grup, routerul punctului de întâlnire este intermediarul care îi conectează între ei.
Procesul de livrare a traficului de grup de la o sursă către destinatarii aparținând unui anumit grup folosind protocolul PIM-SM poate fi reprezentat în trei etape:
1. Construirea unui arbore partajat cu un vârf la punctul de întâlnire, care descrie căile de livrare a pachetelor de grup între punctul de întâlnire și membrii acestui grup. Acest arbore se mai numește și Arborele Punctului de întâlnire (RPT).
2. Construirea unui arbore cu calea cea mai scurtă (SPT), care va livra pachete între sursa acestui grup și punctul de întâlnire.
3. Construirea unui set de arbori SPT, care, de dragul creșterii eficienței, va fi folosit pentru a livra pachete direct între sursă și fiecare dintre destinatarii grupului.
NOTĂ
Ordinea etapelor nu este fixă. De exemplu, sursele multicast pot începe să transmită înainte să existe ascultători interesați de acel trafic sau cel mai scurt arbore de cale între o sursă și ascultătorii săi poate fi deja construit atunci când se face o nouă solicitare de alăturare la grup.
Să ne uităm la funcționarea protocolului PIM-SM folosind un exemplu simplu. În fig. Figura 2 prezintă o rețea cu un singur domeniu în care protocolul PIM-SM stabilește o conexiune între un destinatar A și o sursă 5. Presupunem că funcționarea rețelei corespunde modelului ASM (multicast din orice sursă), protocolul IGMP este implementat pe toate nodurile de rețea și toate routerele acceptă protocolul PIM-SM. De asemenea, vom presupune că punctul de întâlnire este configurat static: atât sursele, cât și destinatarii cunosc adresa individuală a punctului de întâlnire, al cărui rol în această rețea este jucat de routerul D. Pentru a notifica nodurilor din rețea despre adresa punctului de întâlnire, există un protocol standard de notificare automată numit protocol de pornire.
Orez. 2. Etapa 1 - construirea unui arbore comun
Etapa 1- construirea unui arbore RPT comun de la destinatar până la punctul de întâlnire. Odată ce arborele partajat a fost construit, traficul multicast este transmis de la punctul de întâlnire către destinatarii interesați. Cu toate acestea, procesul de construire a unui arbore comun se mută direcție inversă- de la destinatari la punctul de întâlnire pe baza unei abordări pas cu pas (hop-by-hop).
Deci, lăsați gazda A să decidă să se alăture grupului G, din acest motiv ea trimite un mesaj de raport de membru IGMP care conține adresa grupului G către rețeaua locală la care este conectată. Acest mesaj va fi primit de routerul C, prin care această rețea locală este conectată la alte rețele.
Routerul C, după ce a primit acest mesaj IGMP de la gazda A, trimite un mesaj de protocol PIM-SM pentru a se alătura la adresa individuală a routerului D, care acționează ca punct de întâlnire. Acest mesaj este transmis în mod obișnuit, pe baza tabelelor de rutare construite de orice protocoale de rutare. Toate routerele intermediare de-a lungul căii de la gazda de destinație la punctul de întâlnire înregistrează starea progresului pentru acel grup. Fiecare router adaugă interfața care a primit mesajul PIM-SM join la lista sa de interfețe prin care traficul grupului menționat în mesaj poate fi livrat destinatarilor interesați. Ca urmare, se formează un arbore comun pentru acest grup, iar rădăcina lui este punctul de întâlnire.
În exemplul nostru la în această etapă Nu surse active, astfel încât datele multicast nu au ajuns încă la punctul de întâlnire (vezi Fig. 2).
Etapa 2- construirea unui arbore SPT de la sursă până la punctul de întâlnire. Când sursa S devine activă și începe să trimită pachete multicast către rețeaua sa locală, routerul F, la care această rețea este conectată direct, observă că sursa 5 a devenit o sursă multicast. Routerul F trimite un mesaj de înregistrare PIM (registru) la adresa individuală a punctului de întâlnire (routerul D). În acest caz, mesajul de înregistrare este încapsulat într-un pachet multicast de la sursa 5 (Fig. 3).
Când routerul D (punctul de întâlnire) primește mesajul de înregistrare, acesta răspunde cu două acțiuni. În primul rând, transmite datele multicast încapsulate de-a lungul unui arbore partajat (RPT) de la punctul de întâlnire la destinație și, în al doilea rând, trimite un mesaj de conectare PIM înapoi către sursă pentru a crea un arbore cu calea cea mai scurtă (SPT). Acest mesaj este trimis de la un router la altul, cu informațiile de alăturare a grupului înregistrate pe interfețele corespunzătoare.
Odată ce a fost construit cel mai scurt arbore de cale de la sursă la punctul de întâlnire, routerul D începe să primească două copii ale fiecărui pachet multicast. O copie vine de la Sursa 5 pe calea cea mai scurtă nou creată, cealaltă de la Router-ul F, care, continuând să răspundă la activitatea detectată a Sursei 5, trimite din nou un mesaj de înregistrare care conține oa doua copie a pachetului multicast încapsulat. Când routerul de întâlnire recunoaște această situație, trimite un mesaj către Router F pentru a opri înregistrarea. La primirea acestui mesaj pentru o anumită pereche sursă-grup, Router-ul F încetează să genereze mesaje de înregistrare și să încapsuleze pachete de grup sursă în cadrul acestora. În schimb, începe să le trimită în forma lor originală cu o adresă multicast, deoarece în acest moment sursa s-a alăturat deja arborelui grupului, iar acest atașament este înregistrat pe routerele necesare.
Orez. 3. Etapa 2 - înregistrarea sursei cu construirea arborelui de calea cea mai scurtă
Astfel, fluxul de date multicast de la sursa S începe să fie transmis de-a lungul arborelui SPT la punctul de întâlnire și apoi mai departe de la punctul de întâlnire de-a lungul arborelui partajat către toți destinatarii interesați (inclusiv routerul C la care gazda A este conectată).
Etapa 3- construirea unui arbore cu calea cea mai scurtă de la sursă la destinatar. Când Routerul C primește primul pachet multicast, învață din antetul pachetului adresa IP sursă, care în acest caz este Sursa 5. Pe baza acestei adrese, Router C încearcă să construiască un arbore cu calea cea mai scurtă direct de la sursă la el însuși. În exemplul nostru, cea mai scurtă cale este prin Router-ul B. Routerul C trimite un mesaj de unire către Router-ul B, care apoi, la rândul său, trimite un mesaj de unire către Router-ul F. Fiecare dintre ei angajează interfața către care va trimite pachetele grup.
Acum că a fost construit cel mai scurt arbore de cale pentru pereche (sursa 5, destinația A), ruterele F, B și C încep să transmită pachete multicast de-a lungul acestuia. Când pachetele încep să sosească la Router-ul C, acesta descoperă două copii ale fiecărui pachet - una care ajunge pe noua cale cea mai scurtă prin Router-ul B, cealaltă de-a lungul arborelui partajat de la Router-ul D. Pentru a opri duplicarea, Router-ul C trimite o tăiere PIM rendezvous. mesaj (la router-ul D), care oprește sursa din arborele RPT partajat (Fig. 4).
Orez. 4. Etapa 3 - construirea unui arbore cu calea cea mai scurtă de la sursă la destinatar
Din acest moment, routerul C primește doar o copie a fiecărui pachet de la sursa 5 prin arborele său separat de calea cea mai scurtă și o redirecționează către rețeaua locală în care se află destinatarul.
Pentru a simplifica, am descris cazul în care există un singur punct de întâlnire în rețea și este creat un singur arbore partajat. Cu toate acestea, tehnologia permite mai multe puncte de întâlnire într-o rețea. Decizia cu privire la câte puncte de întâlnire ar trebui să existe în rețea și unde ar trebui să fie amplasate face obiectul planificării rețelei și nu este determinată de protocolul PIM.
Versiunea 3 acceptă tot ceea ce acceptă IGMPv2, dar există o serie de modificări. În primul rând, Raportul nu mai este trimis la adresa de grup, ci la adresa serviciului multicast 224.0.0.22 . Iar adresa grupului solicitat este indicată doar în interiorul pachetului. Acest lucru se face pentru a simplifica munca IGMP Snooping, despre care vom vorbi.
În al doilea rând, și mai important, IGMPv3 a început să accepte SSM în formă pură. Acesta este așa-numitul. În acest caz, clientul poate nu doar să solicite un grup, ci și să specifice o listă de surse din care ar dori să primească trafic sau, dimpotrivă, nu ar dori. În IGMPv2, clientul pur și simplu solicită și primește trafic de grup fără a-și face griji cu privire la sursă.
Deci, IGMP este conceput pentru comunicarea între clienți și router. Prin urmare, revenind la Exemplul II, unde nu există router, putem afirma cu autoritate că IGMP nu este nimic mai mult decât o formalitate. Nu există nici un router, iar clientul nu are de la cine să solicite un flux multicast. Și videoclipul va funcționa din simplul motiv că fluxul curge deja de la comutator - trebuie doar să-l ridicați.
Amintiți-vă că IGMP nu funcționează pentru IPv6. Există un protocol numit MLD.
Să o repetăm din nou
*Dump filtrat de IGMP*.
1.
Primul lucru pe care l-a făcut routerul a fost să-și trimită interogarea generală IGMP după ce a activat IGMP pe interfața sa pentru a vedea dacă există destinatari și pentru a-și declara dorința de a fi Interogatori. La acea vreme nu era nimeni în acest grup.
2.
Apoi a apărut un client care a dorit să primească trafic de la grupul 224.2.2.4 și a trimis Raportul său IGMP. După aceea, traficul s-a îndreptat spre el, dar a fost filtrat din groapă.
3.
Apoi, din anumite motive, routerul a decis să verifice dacă mai există clienți și a trimis din nou o interogare generală IGMP, la care clientul a fost forțat să răspundă ( 4
).
5.
Periodic (o dată pe minut), routerul verifică dacă mai există destinatari care utilizează IGMP General Query, iar gazda confirmă acest lucru folosind Raport IGMP.
6.
Apoi s-a răzgândit și a abandonat grupul, trimițând IGMP Leave.
7.
Routerul a primit Leave și, dorind să se asigure că nu există alți destinatari, trimite o interogare specifică grupului IGMP... de două ori. Și după expirarea temporizatorului, nu mai transmite trafic aici.
8.
Cu toate acestea, continuă să transmită interogarea IGMP către rețea. De exemplu, în cazul în care nu ați oprit playerul, dar a fost pur și simplu o problemă cu conexiunea undeva. Apoi conexiunea este restabilită, dar clientul nu trimite singur Raport. Dar răspunde la Query. În acest fel, fluxul poate fi restabilit fără intervenția omului.
Încă o dată
IGMP- un protocol cu care routerul află despre prezența destinatarilor de trafic multicast și despre deconectarea acestora.- trimis de client la conectare și ca răspuns la IGMP Query. Indică faptul că clientul dorește să primească trafic dintr-un anumit grup.
- trimis de router periodic pentru a verifica ce grupuri sunt necesare în prezent. Adresa destinatarului este 224.0.0.1.
Interogare septică de grup IGMP- trimis de router ca răspuns la mesajul Leave pentru a afla dacă mai sunt alți destinatari în acest grup. Adresa grupului multicast este indicată ca adresa destinatarului.
- trimis de client cand doreste sa paraseasca grupul.
Interogatoriu- dacă există mai multe routere într-un segment de difuzare care pot difuza, dintre ele este selectat unul principal - Querier. Va trimite periodic Interogare și va transmite trafic.
Descrierea detaliată a tuturor termenilor IGMP.
PIM
Așadar, ne-am dat seama cum își comunică clienții intențiile celui mai apropiat router. Acum ar fi o idee bună să redirecționați traficul de la sursă la destinație printr-o rețea mai mare.Dacă te gândești bine, stăm în fața unui mulțumit problema complexa- sursa transmite doar grupului, nu știe nimic despre unde sunt destinatarii și câți sunt.
Destinatarii și ruterele cele mai apropiate de ei știu doar că au nevoie de trafic de la un anumit grup, dar nu au idee unde este sursa sau care este adresa acesteia.
Cum să livrezi trafic într-o astfel de situație?
Există mai multe protocoale pentru rutarea traficului multicast: DVMRP, MOSPF, CBT - toate rezolvă această problemă în moduri diferite. Dar a devenit standardul de facto PIM - Protocol Independent Multicast.
Alte abordări sunt atât de neviabile încât uneori chiar și dezvoltatorii lor practic recunosc. De exemplu, iată un extras din RFC privind protocolul CBT:
CBT versiunea 2 nu este și nu a fost destinată să fie compatibilă cu versiunea 1; nu ne așteptăm ca acest lucru să cauzeze probleme extinse de compatibilitate, deoarece nu credem că CBT este deloc implementat pe scară largă în această etapă.
PIM are două versiuni, care pot fi numite chiar două protocoale diferite, în principiu, sunt foarte diferite:
- PIM Dens Mode (DM)
- Mod rar PIM (SM)
PIM Dens Mode
încercând să rezolve problema livrării multiaxt direct. În mod evident, presupune că destinatarii sunt peste tot, în toate colțurile rețelei. Prin urmare, inițial inundă întreaga rețea cu trafic multicast, adică o trimite către toate porturile cu excepția celui din care a provenit. Dacă mai târziu se dovedește că nu este necesar undeva, atunci această ramură este „decupată” folosind un mesaj special PIM Prune - traficul nu mai este trimis acolo.Dar după ceva timp, routerul încearcă din nou să trimită un multicast către aceeași ramură - dintr-o dată au apărut destinatarii. Dacă nu apar, ramura este tăiată din nou pentru o anumită perioadă. Dacă un client apare pe router între aceste două evenimente, este trimis un mesaj Graft - routerul solicită ramura tăiată înapoi pentru a nu aștepta până când ajunge ceva la ea.
După cum puteți vedea, nu se pune problema de a determina calea către destinatari - traficul va ajunge la ei pur și simplu pentru că este peste tot.
După „tunderea” ramurilor inutile, rămâne un arbore de-a lungul căruia este transmis traficul multicast. Acest copac se numește SPT - Cea mai scurtă cale arbore.
Nu are bucle și folosește cea mai scurtă cale de la destinație la sursă. În esență, este foarte asemănător cu Spanning Tree din STP, unde rădăcina este sursa.
SPT este un tip specific de arbore - un arbore cu calea cea mai scurtă. În general, orice arbore multicast se numește .
PIM DM este destinat a fi utilizat în rețele cu densitate mare clienți multicast, ceea ce explică numele acestuia (Dense). Dar realitatea este că această situație este mai degrabă o excepție și de multe ori PIM DM nu este practic.
Ceea ce ne pasă cu adevărat acum este mecanismul de evitare a buclei.
Să ne imaginăm o rețea ca aceasta:
O sursă, o destinație și o simplă rețea IP între ele. Toate routerele rulează PIM DM.
Ce s-ar întâmpla dacă nu ar exista un mecanism special de evitare a buclei?
Sursa trimite trafic multicast. R1 îl primește și, în conformitate cu principiile PIM DM, îl trimite către toate interfețele, cu excepția celei de unde a venit - adică către R2 și R3.
R2 face același lucru, adică trimite trafic spre R3. R3 nu poate determina că acesta este același trafic pe care l-a primit deja de la R1, așa că îl redirecționează către toate interfețele sale. R1 va primi o copie a traficului de la R3 și așa mai departe. Aici este - o buclă.
Ce oferă PIM în această situație? RPF - Reverse Path Forwarding. Acest principiu principal transmiterea traficului multicast către PIM (de orice tip: atât DM, cât și SM) - traficul de la sursă trebuie să ajungă pe calea cea mai scurtă.
Adică, pentru fiecare pachet multicast primit, se face o verificare pe baza tabelului de rutare pentru a vedea dacă a venit de acolo.
1) Routerul se uită la adresa sursă a pachetului multicast.
2) Verifică tabelul de rutare prin care interfață este disponibilă adresa sursă.
3) Verifică interfața prin care a sosit pachetul multicast.
4) Dacă interfețele se potrivesc, totul este în regulă, pachetul multicast este omis, dar dacă datele provin de la o altă interfață, acestea vor fi aruncate.
În exemplul nostru, R3 știe că cea mai scurtă cale către sursă este prin R1 (rută statică sau dinamică). Prin urmare, pachetele multicast care provin de la R1 sunt verificate și acceptate de R3, iar cele care provin de la R2 sunt aruncate.
Acest control se numește RPF-Verificareși mulțumită ei și mai mult rețele complexe nu vor apărea bucle în MDT.
Acest mecanism este important pentru noi deoarece este relevant și în PIM-SM și funcționează acolo exact în același mod.
După cum puteți vedea, PIM se bazează pe o tabelă de rutare unicast, dar, în primul rând, nu direcționează traficul în sine și, în al doilea rând, nu contează cine a umplut tabelul și cum.
Nu ne vom opri aici și vom examina în detaliu funcționarea PIM DM - acesta este un protocol învechit, cu o mulțime de deficiențe (bine, ca RIP).
Cu toate acestea, PIM DM poate fi aplicabil în unele cazuri. De exemplu, în destul rețele mici, unde fluxul multicast este mic.
Mod rar PIM
Ia o abordare complet diferită PIM SM. În ciuda numelui (mod sparse), poate fi folosit cu succes în orice rețea cu o eficiență cel puțin la fel de bună ca PIM DM.Aici au abandonat ideea de a inunda necondiționat rețeaua cu multicast. Nodurile interesate solicită în mod independent conectarea la arbore folosind mesaje Alăturați-vă PIM.
Dacă routerul nu a trimis Join, atunci traficul nu va fi trimis către acesta.
Pentru a înțelege cum funcționează PIM, să începem cu o rețea simplă cu un router PIM cu care suntem deja familiarizați: 
Din setările de pe R1, trebuie să activați rutarea multicast, PIM SM pe două interfețe (la sursă și către client) și IGMP către client. Printre alții setări de bază, desigur (IP, IGP).
De acum înainte, puteți descoperi GNS-ul și asambla laboratorul. Am descris suficient de detaliat cum să asamblați un suport pentru multicast în acest articol.
R1(config)#ip multicast-routing R1(config)#int fa0/0 R1(config-if)#ip pim sparse-mode R1(config-if)#int fa1/0 R1(config-if)#ip pim modul rar
Cisco, ca de obicei, se distinge prin abordarea sa specială: atunci când PIM este activat pe o interfață, IGMP este activat automat. IGMP funcționează și pe toate interfețele în care PIM este activat.
În același timp, alți producători activează două protocoale diferite folosind două comenzi diferite: separat IGMP, separat PIM.
Îi vom ierta pe Cisco pentru această ciudățenie? Împreună cu toți ceilalți?În plus, poate fi necesar să configurați adresa RP ( ip pim rp-adresa 172.16.0.1, De exemplu). Mai multe despre asta mai târziu, deocamdată luați-o de la sine înțeles și împăcați-vă cu ea.
Să verificăm starea curentă a tabelului de rutare multicast pentru grupul 224.2.2.4:
După ce începeți să difuzați pe sursă, trebuie să verificați din nou tabelul.
Să ne uităm la această concluzie concisă.
Tip de înregistrare (*, 225.0.1.1)
numit /citește starcomadji/ și ne vorbește despre destinatari. Mai mult, nu vorbim neapărat de un computer client în general, ar putea fi, de exemplu, un alt router PIM; Ceea ce contează este la ce interfețe trebuie trimis traficul.
Dacă lista de interfețe din aval (OIL) este goală - Nul, ceea ce înseamnă că nu există destinatari - și nu i-am lansat încă.
Record (172.16.0.5, 225.0.1.1) numit /citește Eskomadji/ și indică faptul că sursa este cunoscută. În cazul nostru, sursa cu adresa 172.16.0.5 difuzează trafic pentru grupul 224.2.2.4. Traficul multicast vine la interfața FE0/1 - asta este ascendent (în amonte) interfață.
Deci, fără clienți. Traficul de la sursă ajunge la router și aici se termină viața lui. Să adăugăm acum un destinatar - configurați recepția multicast pe computer.
PC-ul trimite un Raport IGMP, routerul înțelege că au apărut clienții și actualizează tabelul de rutare multicast.
Acum arata cam asa:
A apărut și o interfață în aval: FE0/0, ceea ce este destul de așteptat. Mai mult, a apărut atât în (*, G) cât și (S, G). Lista interfețelor din aval este apelată OIL - Listă de interfețe de ieșire.
Să adăugăm un alt client la interfața FE1/0:
(S, G): Când traficul multicast cu adresa de destinație 224.2.2.4 de la sursa 172.16.0.5 ajunge pe interfața FE0/1, copii ale acestuia trebuie trimise către FE0/0 și FE1/0.
Dar acesta a fost un exemplu foarte simplu - un router știe imediat atât adresa sursei, cât și unde se află destinatarii. De fapt, aici nu există nici măcar copaci - cu excepția celor degenerați. Dar ne-a ajutat să înțelegem cum interacționează PIM și IGMP.
Pentru a înțelege ce este PIM, să trecem la o rețea mult mai complexă
Să presupunem că toate adresele IP au fost deja configurate conform schemei. IGP rulează în rețea pentru rutare unicast obișnuită.
Client1, de exemplu, poate ping serverul sursă.
Dar în timp ce PIM și IGMP nu rulează, clienții nu solicită canale.
Deci, timpul 0.
Activem rutarea multicast pe toate cele cinci routere:
RX(config)#ip multicast-routing
PIM este activat direct pe toate interfețele tuturor routerelor (inclusiv pe interfața către serverul sursă și clienți):
RX(config)#int FEX/X RX(config-if)#ip pim sparse-mode
IGMP, în teorie, ar trebui să fie activat pe interfețele client, dar, după cum am menționat mai sus, pe echipamentele Cisco este activat automat împreună cu PIM.
Primul lucru pe care îl face PIM este să stabilească un cartier. Mesajele sunt folosite pentru aceasta. Când PIM este activat pe o interfață, un PIM Hello este trimis de la aceasta la adresa 224.0.0.13 cu un TTL de 1. Aceasta înseamnă că numai routerele din același domeniu de difuzare pot fi vecine.
De îndată ce vecinii au primit salutări unul de la altul:
Acum sunt gata să accepte cereri pentru grupuri multicaste.
Dacă acum lansăm clienții în incintă pe de o parte și activăm un flux multicast de la server pe cealaltă, atunci R1 va primi un flux de trafic, iar R4 va primi un raport IGMP atunci când clientul încearcă să se conecteze. Ca urmare, R1 nu va ști nimic despre destinatari, iar R4 nu va ști nimic despre sursă.
Ar fi bine dacă informațiile despre sursă și clienții grupului ar fi colectate undeva într-un singur loc. Dar care?
Acest punct de întâlnire este numit Punct de întâlnire - RP. Acesta este conceptul central al PIM SM. Fără ea, nimic nu ar funcționa. Aici se întâlnesc sursa și destinatarii.
Toate routerele PIM trebuie să știe cine este RP-ul din domeniu, adică să cunoască adresa lui IP.
Pentru a construi un arbore MDT, un anumit punct central este selectat ca RP în rețea, care,
- este responsabil pentru studierea sursei,
- este un punct de atracție pentru mesajele Join de la toate părțile interesate.
Lăsați R2 să acționeze ca RP pentru moment.
Pentru a crește fiabilitatea, adresa interfeței Loopback este de obicei selectată. De aceea pentru toti Pe routere comanda este executată:
RX(config)#ip pim rp-address 2.2.2.2
Desigur, această adresă trebuie să fie accesibilă prin tabelul de rutare din toate punctele.
Ei bine, din moment ce adresa 2.2.2.2 este RP, pe interfață Loopback 0 Este recomandabil să activați și PIM pe R2.
R2(config)#interfață Loopback 0 RX(config-if)#ip pim sparse-mode
Imediat după aceasta, R4 află despre sursa de trafic pentru grupul 224.2.2.4:
Și chiar transmite trafic:
362000 bps sosesc la interfața FE0/1 și sunt transmise prin interfața FE0/0.
Tot ce am făcut:
S-a activat capacitatea de a direcționa traficul multicast ( rutare multicast ip)
PIM activat pe interfețe ( ip pim sparse-mode)
Adresa RP specificată ( ip pim rp-adress X.X.X.X
)
Asta e, este deja configurație de lucruși poți începe să analizezi, pentru că în culise este mult mai ascuns decât se vede pe scenă.
Configurare completă cu PIM.
Debriefing
Deci, cum funcționează totul până la urmă? Cum află RP unde este sursa, unde sunt clienții și asigură comunicarea între ei?Întrucât totul este început de dragul clienților noștri dragi, începând cu ei, vom lua în considerare întregul proces în detaliu.
1) Clientul 1 trimite un Raport IGMP pentru grupul 224.2.2.4
2) R4 primește această solicitare, înțelege că există un client în spatele interfeței FE0/0, adaugă această interfață la OIL și generează o înregistrare (*, G).
Interfața în amonte FE0/1 este vizibilă aici, dar asta nu înseamnă că R4 primește trafic pentru grupul 224.2.2.4. Asta înseamnă doar că singurul loc pe care îl poate primi de acum este FE0/1, pentru că acolo este RP. De altfel, aici este trecut și vecinul care a trecut RPF-Verificare- R2: 10.0.2.24. Așteptat.
R4 se numește LHR (Last Hop Router) - ultimul router pe calea traficului multicast, dacă numărați de la sursă. Cu alte cuvinte, acesta este routerul cel mai apropiat de destinatar. Pentru Client1- acesta este R4, pentru Clientul2- acesta este R5.
3) Deoarece R4 nu are încă un flux multicast (nu a solicitat unul înainte), generează un mesaj PIM Join și îl trimite către RP (2.2.2.2).
PIM Join este trimis prin multicast la adresa 224.0.0.13. „Spre RP” înseamnă prin interfața care este listată în tabelul de rutare ca ieșire pentru adresa care este specificată în interiorul pachetului. În cazul nostru, aceasta este 2.2.2.2 - adresa RP. O astfel de unire este, de asemenea, notat ca Alăturați-vă(*,G)și spune: „Nu contează cine este sursa, am nevoie de trafic din grupul 224.2.2.4.”
Adică, fiecare router de pe cale trebuie să proceseze un astfel de Join și, dacă este necesar, să trimită un nou Join către RP. (Este important să înțelegeți că, dacă routerul are deja acest grup, nu va trimite deasupra Join - pur și simplu va adăuga interfața de la care Join a venit la OIL și va începe să trimită trafic).
În cazul nostru, Join a ajuns la FE0/1:
4) R2, după ce a primit Join, formează o înregistrare (*, G) și adaugă interfața FE0/0 la OIL. Dar Join nu are unde să trimită - el însuși este deja un RP și încă nu se știe nimic despre sursă.
Astfel RP știe unde sunt clienții.
Dacă Clientul 2 dorește, de asemenea, să primească trafic multicast pentru același grup, R5 va trimite PIM Join la FE0/1, deoarece RP este în spatele lui, R3, după ce l-a primit, formează un nou PIM Join și îl trimite la FE1/1 - unde se află RP .
Adică, Join călătorește astfel nod cu nod până ajunge la RP sau la alt router unde există deja clienți ai acestui grup.
Deci, R2 - RP-ul nostru - acum știe că în spatele FE0/0 și FE1/0 are destinatari pentru grupul 224.2.2.4.
Mai mult, nu contează câți dintre ei sunt - unul în spatele fiecărei interfețe sau o sută - fluxul de trafic va fi în continuare unul pe interfață.
Dacă descriem grafic ceea ce am obținut, va arăta astfel:
Seamănă vag cu un copac, nu-i așa? De aceea se numește așa... RPT - Arborele punctului de întâlnire. Acesta este un arbore cu rădăcina la RP și ramurile care se extind către clienți.
Un termen mai general, așa cum am menționat mai sus, este MDT - Arborele de distribuție multicast- un arbore de-a lungul căruia se propagă un flux multicast. Veți vedea diferența dintre MDT și RPT mai târziu.
5)
Acum pornim serverul. După cum am discutat mai sus, nu se îngrijorează de PIM, RP, IGMP - doar difuzează. Și R1 primește acest flux. Sarcina sa este să livreze multicast către RP.
PIM are tip special mesaje - Inregistreaza-te. Este necesar pentru a înregistra sursa multicast pe RP.
Deci, R1 primește un flux multicast al grupului 224.2.2.4:
R1 este FHR (ruter primul hop)- primul router pe calea traficului multicast sau cel mai apropiat de sursă.
Acordați atenție stivei de protocol. Pe deasupra antetului unicast IP și PIM se află IP-ul multicast original, UDP și date.
Acum, spre deosebire de toate celelalte mesaje PIM cunoscute până acum, adresa destinatarului conține 2.2.2.2, și nu o adresă multicast.
Un astfel de pachet este livrat către RP în conformitate cu regulile standard de rutare unicast și poartă pachetul multicast original, adică... acesta este tunel!
Serverul 172.16.0.5 rulează o aplicație care poate trimite pachete doar la adresa de difuzare 255.255.255.255, cu un port de destinație UDP de 10999.
Acest trafic trebuie livrat clienților 1 și 2:
Către Clientul 1 sub formă de trafic multicast cu adresa de grup 239.9.9.9.
Și către segmentul de client 2, sub formă de pachete de difuzare la adresa 255.255.255.255.
Notă de topologie: În această sarcină, numai routerele R1, R2, R3 sunt sub controlul administratorilor noștri de rețea. Adică configurația poate fi schimbată doar pe ele.
Serverul 172.16.0.5 transmite trafic multicast către grupurile 239.1.1.1 și 239.2.2.2.
Configurați rețeaua în așa fel încât traficul grupului 239.1.1.1 să nu fie transmis către segmentul dintre R3 și R5 și către toate segmentele sub R5.
Dar, în același timp, traficul grupului 239.2.2.2 ar trebui să fie transmis fără probleme.
La fel ca sursă DR, numai pentru destinatarii de trafic multicast - LHR (Last Hop Router) .
Exemplu de topologie:
Receiver DR este responsabil pentru trimiterea către RP PIM Join. În topologia de mai sus, dacă ambele routere trimit Join, atunci ambele vor primi trafic multicast, dar acest lucru nu este necesar. Doar DR trimite Join. Al doilea pur și simplu monitorizează disponibilitatea DR.
Deoarece DR trimite Join, va difuza și trafic către LAN. Dar aici apare o întrebare logică - ce se întâmplă dacă unul devine PIM DR, iar celălalt devine IGMP Querier? Dar situația este destul de posibilă, pentru că pentru Querier cu cât IP este mai mic, cu atât mai bine, dar pentru DR, invers.
În acest caz, DR selectează routerul care este deja un Querier și această problemă nu apare.
Regulile pentru alegerea Receiver DR sunt exact aceleași cu Source DR.
Problema a două routere care transmit simultan poate apărea și în mijlocul rețelei, unde nu există clienți finali sau surse - doar routere.
Această problemă a fost foarte acută în PIM DM, unde a fost o situație complet obișnuită din cauza mecanismului Flood and Prune.
Dar nici in PIM SM nu este exclus.
Luați în considerare următoarea rețea:
Aici, trei routere sunt situate pe același segment de rețea și, în consecință, sunt vecini PIM. R1 acționează ca RP.
R4 trimite PIM Join către RP. Deoarece acest pachet este multicast, ajunge atât la R2, cât și la R3 și ambii, după ce l-au procesat, adaugă o interfață în aval la OIL.
Mecanismul de selecție DR ar trebui să funcționeze aici, dar atât R2, cât și R3 au alți clienți în acest grup și ambele routere vor trebui să trimită PIM Join într-un fel sau altul.
Când traficul multicast vine de la o sursă pe R2 și R3, acesta este transmis segmentului de ambele routere și duplicat acolo. PIM nu încearcă să prevină o astfel de situație - aici acționează pe baza faptului crimei - de îndată ce routerul primește trafic multicast chiar de la acest grup în interfața sa din aval pentru un anumit grup (din lista OIL), înțelege: ceva nu este în regulă - există deja un alt expeditor în acest segment.
Apoi routerul trimite un mesaj special.
Acest mesaj vă ajută să alegeți Forwarder PIM- routerul care are dreptul de a difuza în acest segment.
Nu trebuie confundat cu PIM DR. În primul rând, PIM DR este responsabil pentru trimitere Mesajele PIM Join și Eliminați, și PIM Forwarder - pentru trimitere trafic. A doua diferență este că PIM DR este întotdeauna selectat în orice rețea atunci când se stabilește o vecinătate, iar PIM Forwrder este selectat doar atunci când este necesar - atunci când traficul multicast este primit de la o interfață din lista OIL.
Selectarea RP
Mai sus, pentru simplitate, setăm RP manual cu comanda ip pim rp-adresa X.X.X.X .Și așa arăta echipa:
Dar să ne imaginăm o situație care este complet imposibilă în rețelele moderne - R2 a eșuat. Asta este tot - linia de sosire. Clientul 2 va funcționa în continuare, deoarece a avut loc Comutarea SPT, dar totul nou și tot ce a trecut prin RP se va rupe, chiar dacă există o cale alternativă.
Ei bine, povara pentru administratorul de domeniu. Imaginați-vă: întrerupeți manual cel puțin o comandă pe 50 de routere (și pot exista diferite RP-uri pentru diferite grupuri).
Selectarea dinamică a RP vă permite să evitați munca manuală și să asigurați fiabilitatea - dacă un RP devine indisponibil, altul va intra imediat în luptă.
ÎN acest moment Există un protocol general acceptat care vă permite să faceți acest lucru - . Pe vremuri, Cisco promova Auto-RP oarecum stângaci, dar acum nu este folosit aproape niciodată, deși Cisco nu recunoaște acest lucru și avem un rudiment enervant sub forma grupului 224.0.1.40.
Chiar trebuie să acordăm credit protocolului Auto-RP. El a fost mântuirea în vremurile de demult. Dar odată cu apariția Bootstrap deschis și flexibil, acesta și-a pierdut în mod natural poziția.
Deci, să presupunem că în rețeaua noastră dorim ca R3 să preia funcțiile lui RP dacă R2 eșuează.
R2 și R3 sunt identificați ca candidați pentru rolul de RP - așa se numesc C-RP. Pe aceste routere configuram:
RX(config)interfață Loopback 0 RX(config-if)ip pim sparse-mode RX(config-if)exit RX(config)#ip pim rp-candidate loopback 0
Dar încă nu se întâmplă nimic - candidații nu știu încă să anunțe pe toată lumea despre ei înșiși.
Pentru a informa toate routerele multicast dintr-un domeniu despre RP-urile existente, este introdus un mecanism BSR - Router BootStrap. Pot fi mai mulți concurenți, la fel ca C-RP. Ele sunt denumite în consecință C-BSR. Ele sunt configurate într-un mod similar.
Să avem un BSR și pentru test (exclusiv) va fi R1.
R1(config)interfață Loopback 0 R1(config-if)ip pim sparse-mode R1(config-if)exit R1(config)#ip pim bsr-candidate loopback 0
În primul rând, dintre toate C-BSR-urile, este selectat un BSR principal, care va rula totul. Pentru a face acest lucru, fiecare C-BSR trimite un multicast Mesaj BootStrap (BSM) la adresa 224.0.0.13 - acesta este și un pachet de protocol PIM. Acesta trebuie să fie acceptat și procesat de toate routerele multicast și apoi trimis către toate porturile unde PIM este activat. BSM nu se transmite spre ceva (RP sau sursă), spre deosebire de PIM Join, ci în toate direcțiile. Acest tip de difuzare ajută BSM să ajungă în toate colțurile rețelei, inclusiv toate C-BSR-urile și toate C-RP-urile. Pentru a împiedica BSM să rătăcească la nesfârșit prin rețea, se folosește același mecanism RPF - dacă BSM provine dintr-o interfață diferită de rețeaua expeditorului acestui mesaj, un astfel de mesaj este eliminat.
Cu ajutorul acestor BSM, toate routerele multicast determină cel mai demn candidat pe baza priorităților. De îndată ce C-BSR primește un BSM de la un alt router cu o prioritate mai mare, nu își mai trimite mesajele. Drept urmare, toată lumea are aceleași informații.
În această etapă, când este selectat un BSR, datorită faptului că BSM-urile sale s-au dispersat deja în întreaga rețea, C-RP-urile cunosc adresa acestuia și îi trimit mesaje folosind unicast. Candidte-RP-Reclama, în care poartă o listă de grupuri pe care le deservesc - aceasta se numește maparea grup-la-RP. BSR reunește toate aceste mesaje și creează RP-Set- tabel informativ: ce RP deservesc fiecare grup.
Apoi, BSR, în același mod în formă de evantai, trimite același mesaj BootStrap, care de data aceasta conține RP-Set. Aceste mesaje ajung cu succes la toate routerele multicast, fiecare dintre acestea pe cont propriu alege ce RP ar trebui utilizat pentru fiecare grup specific.
BSR face periodic astfel de mailinguri, astfel încât, pe de o parte, toată lumea să știe că informațiile despre RP sunt încă relevante, iar pe de altă parte, C-BSR-ii sunt conștienți că principalul BSR însuși este încă în viață.
RP, de altfel, își trimit periodic și anunțurile de Candidat-RP-Reclame către BSR.
De fapt, tot ce trebuie să faceți pentru a configura selecția automată RP este să specificați C-RP și să specificați C-BSR - nu prea multă muncă, PIM se ocupă de restul pentru tine.
Ca întotdeauna, pentru a îmbunătăți fiabilitatea, este recomandat să specificați interfețele Loopback ca candidați.
Încheind capitolul PIM SM, să notăm încă o dată cele mai importante puncte
- Conectivitatea normală unicast ar trebui să fie furnizată folosind IGP sau rute statice. Aceasta este baza algoritmului RPF.
- Arborele se construiește numai după apariția clientului. Clientul este cel care inițiază construcția arborelui. Fără client - fără arbore.
- RPF ajută la evitarea buclelor.
- Toate routerele trebuie să știe cine este RP - doar cu ajutorul lui se poate construi arborele.
- RP poate fi specificat static sau poate fi selectat automat folosind protocolul BootStrap.
- În prima fază, se construiește un RPT - un arbore de la clienți la RP - și un arbore sursă - un arbore de la sursă la RP. În a doua fază, are loc o comutare de la RPT construit la SPT - cea mai scurtă cale de la destinatar la sursă.
Să enumerăm, de asemenea, toate tipurile de arbori și mesaje pe care le cunoaștem acum.
MDT - Arborele de distribuție multicast. Un termen general care descrie orice arbore de transmisie multicast.
SPT - Cea mai scurtă cale arbore. Arborele cu calea cea mai scurtă de la client sau RP la sursă. PIM DM are doar SPT. În PIM SM, SPT poate fi de la sursă la RP sau de la sursă la destinație după ce a avut loc comutarea SPT. Indicat printr-o înregistrare - sursa grupului este cunoscută.
Arborele sursei- la fel ca SPT.
RPT - Arborele punctului de întâlnire. Arborele de la RP la destinatari. Folosit numai în PIM SM. Identificat prin intrare .
Arborele comun- la fel ca RPT. Numit așa deoarece toți clienții sunt conectați la un arbore comun înrădăcinat în RP.
Tipuri de mesaje PIM Sparse Mode:
Buna ziua- să stabilească un cartier și să mențină aceste relații. De asemenea, necesar pentru selectarea DR.
- o solicitare de conectare la arborele grupului G Nu contează cine este sursa. Trimis către RP. Cu ajutorul lor se construiește arborele RPT.
- Asociere specifică sursei. Aceasta este o solicitare de conectare la un arbore din grupa G cu o anumită sursă - S. Este trimisă către sursa - S. Cu ajutorul lor, se construiește arborele SPT.
Prune (*, G)- o solicitare de deconectare de la arborele grupului G, indiferent de ce surse există pentru aceasta. Trimis către RP. Așa este tăiată ramura RPT.
Prune (S, G)- o cerere de deconectare de la un arbore din grupa G, a cărui rădăcină este sursa S. Trimis către sursă. Așa este tăiată ramura SPT.
Inregistreaza-te- un mesaj special în cadrul căruia un multicast este transmis către RP până când un SPT este construit de la sursă la RP. Transmis prin unicast de la FHR la RP.
Înregistrare-Oprire- trimis prin unicast de la RP la FHR, ordonând oprirea trimiterii traficului multicast încapsulat în Register.
- Pachete de mecanism BSR, care vă permit să selectați un router care să acționeze ca BSR și, de asemenea, să transmiteți informații despre RP-urile și grupurile existente.
Afirma- un mesaj pentru selectarea PIM Forwarder, astfel încât două routere să nu transmită trafic către un singur segment.
Candidat-RP-Reclamă- un mesaj în care RP trimite informații către BSR despre ce grupuri deservește.
RP-accesibil- un mesaj de la RP, cu care îi anunță pe toată lumea despre disponibilitatea ei.
*Există și alte tipuri de mesaje în PIM, dar acestea sunt deja detalii*
Acum să încercăm să facem abstracție de la detaliile protocolului? Și atunci complexitatea sa devine evidentă.
1) Definiția RP,
2) Înregistrare sursă pe RP,
3) Comutați la arborele SPT.
Multe stări de protocol, multe intrări în tabelul de rutare multicast. Este posibil să facem ceva în privința asta?
Astăzi, există două abordări diametral opuse pentru simplificarea PIM: SSM și BIDIR PIM.
SSM
Tot ce am descris până acum este ASM - Orice sursă Multicast. Clienților nu le pasă cine este sursa de trafic pentru grup - principalul lucru este că îl primesc. După cum vă amintiți, mesajul Raport IGMPv2 solicită pur și simplu o conexiune la grup.SSM - Multicast specific sursei- o abordare alternativă. În acest caz, clienții specifică grupul și sursa atunci când se conectează.
Ce dă asta? Nici mai mult, nici mai puțin: capacitatea de a scăpa complet de RP. LHR știe imediat adresa sursei - nu este nevoie să trimiteți un Join la RP, routerul poate trimite imediat un Join (S, G) în direcția sursei și construi un SPT.
În felul acesta scăpăm de
- Căutare RP (protocoale Bootstrap și Auto-RP),
- Înregistrarea unei surse pe un multicast (ceea ce înseamnă timp suplimentar, utilizarea dublă a lățimii de bandă și a tunelului)
- Trecerea la SPT.
O altă problemă care se rezolvă cu ajutorul SSM este prezența mai multor surse. ASM recomandă ca adresa grupului de multicast să fie unică și să fie difuzată o singură sursă către aceasta, deoarece în arborele RPT se vor îmbina mai multe fluxuri, iar clientul, primind două fluxuri de la surse diferite, probabil că nu le va putea desluși.
Pentru traficul SSM de la diverse surse este distribuit independent, fiecare după propriul arbore SPT, iar acest lucru nu mai devine o problemă, ci un avantaj - mai multe servere pot difuza simultan. Dacă dintr-o dată clientul începe să înregistreze pierderi din sursa principală, poate trece la cea de rezervă fără măcar să o solicite din nou - a primit deja două fluxuri.
În plus, un posibil vector de atac într-o rețea cu rutare multicast activată este ca un atacator să își conecteze sursa și să genereze un volum mare de trafic multicast care va supraîncărca rețeaua. În SSM acest lucru este practic imposibil.
Pentru SSM este alocată o gamă specială de adrese IP: 232.0.0.0/8.
Pe routerele care acceptă SSM, modul PIM SSM este activat.
Router(config)# ip pim ssm
IGMPv3 și MLDv2 acceptă SSM în forma sa pură.
Când le folosește, clientul poate
- Solicitați conectarea doar la un grup, fără a specifica sursele. Adică funcționează ca un ASM tipic.
- Solicitați conectarea la un grup cu o anumită sursă. Puteți specifica mai multe surse - se va construi un arbore pentru fiecare dintre ele.
- Solicitați o conexiune la grup și specificați o listă de surse din care clientul nu a vrut ar primi trafic
IGMPv1/v2, MLDv1 nu acceptă SSM, dar există așa ceva ca Maparea SSM. Pe routerul cel mai apropiat de client (LHR), fiecărui grup i se atribuie o adresă sursă (sau mai multe). Prin urmare, dacă există clienți în rețea care nu acceptă IGMPv3/MLDv2, se va construi și SPT pentru ei, mai degrabă decât RPT, din cauza faptului că adresa sursă este încă cunoscută.
Maparea SSM poate fi implementată fie prin configurație statică pe LHR, fie prin accesarea serverului DNS.
Problema cu SSM este că clienții trebuie să cunoască în prealabil adresele sursei - nu sunt informați de nicio semnalizare.
Prin urmare, SSM este bun în situațiile în care există un anumit set de surse în rețea, adresele acestora sunt cunoscute și nu se vor schimba. Iar terminalele sau aplicațiile client sunt strict legate de ele.
Cu alte cuvinte, IPTV este un mediu foarte potrivit pentru implementarea SSM. Aceasta descrie bine conceptul Unu-la-Mulți- o sursă, mulți destinatari.
Ce se întâmplă dacă sursele din rețea pot apărea spontan ici și colo, difuzate către aceleași grupuri, încetează rapid transmiterea și dispar?
De exemplu, această situație este posibilă în jocurile online sau într-un centru de date în care datele sunt replicate între diferite servere. Acesta este conceptul Mulți-la-Mulți- multe surse, multi clienti.
Cum arată un PIM SM tipic la asta? Este clar că un PIM SSM inert nu este deloc potrivit aici?
Gândiți-vă doar la haosul care va urma: înregistrări nesfârșite ale surselor, reconstrucția copacilor, o cantitate mareînregistrările (S, G) în direct timp de câteva minute datorită cronometrelor de protocol.
PIM bidirecțional vine în ajutor ( PIM bidirecțional, BIDIR PIM). Spre deosebire de SSM, dimpotrivă, abandonează complet SPT și înregistrează (S, G) - rămâne doar arborele partajat cu rădăcina în RP.
Și dacă într-un PIM obișnuit, arborele este unidirecțional - traficul este transmis întotdeauna de la sursă în jos prin SPT și de la RP în jos prin RPT - există o diviziune clară, unde este sursa, unde sunt clienții, apoi în bidirecțional traficul de la sursă la RP este transmis, de asemenea, în sus prin arborele partajat - în același mod în care traficul curge către clienți.
Acest lucru vă permite să refuzați înregistrarea sursei pe RP - traficul este transmis necondiționat, fără nicio semnalizare sau modificări de stare. Deoarece nu există arbori SPT deloc, nu există nicio comutare SPT.
De exemplu:
Sursa 1 a început să transmită traficul grupului 224.2.2.4 către rețea simultan cu Sursa 2. Fluxurile de la ei pur și simplu s-au revărsat spre RP. Unii dintre clienții care se află în apropiere au început să primească imediat trafic, deoarece routerele au o înregistrare (*, G) (sunt clienți). Cealaltă parte primește trafic Shared Tree de la RP. Mai mult, primesc trafic din ambele surse simultan.
Adică dacă luăm drept exemplu speculativul joc de rețea, Sursa 1 este primul jucător dintr-un joc cu împușcături care a tras o lovitură și Sursa 2- acesta este un alt jucător care a făcut un pas în lateral. Informații despre aceste două evenimente răspândite în întreaga rețea. ȘI fiecare alt jucător ( Destinatar) ar trebui să învețe despre ambele evenimente.
Dacă vă amintiți, v-am explicat de ce este necesar procesul de înregistrare a unei surse pe RP - pentru ca traficul să nu ocupe canalul atunci când nu există clienți, adică RP pur și simplu îl refuză. De ce nu ne gândim acum la această problemă? Motivul este simplu: BIDIR PIM este pentru situațiile în care există multe surse, dar acestea nu difuzează în mod constant, ci periodic, în bucăți de date relativ mici. Adică, canalul de la sursă la RP nu va fi irosit în zadar.
Rețineți că în imaginea de mai sus există o linie dreaptă între R5 și R7, mult mai scurtă decât calea prin RP, dar nu a fost folosită deoarece Join-urile merg spre RP conform tabelului de rutare în care acest drum nu este optim.
Pare destul de simplu - trebuie să trimiteți pachete multicast în direcția RP și atât, dar există o nuanță care strică totul - RPF. În arborele RPT, necesită ca traficul să provină din RP și nimic altceva. Dar la noi poate veni de oriunde. Desigur, nu putem abandona pur și simplu RPF - acesta este singurul mecanism care ne permite să evităm formarea buclelor.
Prin urmare, conceptul este introdus în BIDIR PIM. În fiecare segment de rețea, pe fiecare linie, pentru acest rol este selectat routerul a cărui rută către RP este mai bună.
Acest lucru se face și pe acele linii în care clienții sunt conectați direct. În BIDIR PIM, DF este automat DR.
Lista OIL este formată numai din acele interfețe pe care routerul a fost selectat ca DF.
Regulile sunt destul de clare:
- Dacă o solicitare PIM Join/Leave vine la interfața care este DF în acest segment, aceasta este transmisă către RP conform regulilor standard.
De exemplu, R3. Dacă solicitările vin către interfețele DF, care sunt marcate cu un cerc roșu, acesta le transmite către RP (prin R1 sau R2, în funcție de tabelul de rutare). - Dacă o solicitare PIM Join/Leave a ajuns la o interfață non-DF, aceasta va fi ignorată.
Să presupunem că un client situat între R1 și R3 a decis să se conecteze și a trimis un Raport IGMP. R1 îl primește prin interfața unde este selectat de DF (marcat cu un cerc roșu) și ne întoarcem la scenariul anterior. Și R3 primește o solicitare pentru o interfață care nu este DF. R3 vede că nu este cel mai bun aici și ignoră cererea. - Dacă traficul multicast a ajuns la interfața DF, acesta va fi trimis către interfețele din lista OIL și către RP.
De exemplu, Sursa 1 a început să transmită trafic. R4 îl primește la interfața sa DF și îl transmite către o altă interfață DF - către client și către RP - acest lucru este important deoarece traficul trebuie să ajungă la RP și să se răspândească la toți destinatarii. Sosește și R3 - o copie la interfețele din lista OIL - adică la R5, unde va fi aruncată din cauza verificării RPF, iar cealaltă - spre RP. - Dacă traficul multicast a ajuns la o interfață non-DF, ar trebui trimis către interfețele din lista OIL, dar nu voi trimis către RP.
De exemplu, Sursa 2 a început să difuzeze, traficul a ajuns în RP și a început să se răspândească pe RPT. R3 primește trafic de la R1 și nu îl va redirecționa către R2 - doar până la R4 și la R5.
În acest fel, DF asigură că numai o copie a pachetului multicast va fi trimisă în cele din urmă către RP și sunt evitate buclele. În acest caz, arborele comun în care se află sursa va primi în mod natural acest trafic înainte de a ajunge la RP. RP, conform regulilor obișnuite, va trimite trafic în toate porturile OIL, cu excepția celui din care a venit traficul.
Apropo, nu mai este nevoie de mesaje Assert, deoarece DF este selectat în fiecare segment. Spre deosebire de DR, acesta este responsabil nu doar de trimiterea Join către RP, ci și de transmiterea traficului către segment, adică situația în care două routere transmit trafic către aceeași subrețea este exclusă în BIDIR PIM.
Poate ultimul lucru care trebuie spus despre PIM bidirecțional este modul în care funcționează RP. Dacă în PIM SM RP a îndeplinit o funcție foarte specifică - înregistrarea sursei, atunci în BIDIR PIM RP este un punct foarte condiționat la care tinde traficul pe de o parte și Join de la clienți pe de altă parte. Nimeni nu ar trebui să efectueze decapsularea, solicita construirea arborelui SPT. Doar că pe un router traficul de la surse începe să fie transmis brusc către Shared Tree. De ce spun „pe unele”? Faptul este că în BIDIR PIM RP este un punct abstract, nu un anumit router, adresa RP poate fi în general o adresă IP inexistentă - principalul lucru este că este rutabilă (un astfel de RP se numește Phantom RP);
Toți termenii legați de PIM pot fi găsiți în glosar.
Multicast activat nivelul link-ului
Așadar, o săptămână lungă de lucru cu lipsă de somn, ore suplimentare, teste a rămas în urmă - ați implementat cu succes multicast și v-ați mulțumit clienții, directorul și departamentul de vânzări.Vinerea nu este o zi rea pentru a vedea creația și a-ți permite o odihnă plăcută.
Dar somnul tău de după-amiază a fost brusc perturbat de un apel de asistență tehnică, apoi unul și încă unul - nimic nu funcționează, totul este stricat. Tu verifici - sunt pierderi, lacune. Totul converge pe un segment de mai multe comutatoare.
Am dezvăluit SSH, am verificat CPU, am verificat utilizarea interfețelor și s-a oprit - încărcarea a fost de aproape 100% pe toate interfețele unui VLAN verificând și ați observat că pe interfața upstream aveți o mulțime de trafic de intrare către nucleu și trafic de ieșire către toți clienții din aval. Acest lucru este, de asemenea, tipic pentru o buclă, dar cumva suspect: au implementat multicast, nu au făcut nicio muncă de comutare. iar saltul este doar într-o singură direcție.
Am verificat lista de grupuri multicast de pe router - și a existat un abonament la toate canale posibile si toate pe un port - firesc, cel care duce la acest segment.
O investigație meticuloasă a arătat că computerul clientului a fost infectat și trimitea IGMP Query către toate adresele multicast la rând.
Pierderile de pachete au început deoarece comutatoarele au trebuit să treacă printr-o cantitate imensă de trafic. Acest lucru a cauzat depășirea memoriei tampon de interfață.
Întrebarea principală este de ce traficul unui client a început să fie copiat în toate porturile?
Motivul pentru aceasta constă în natura adreselor MAC multicast. Faptul este că spațiul adreselor IP multicast este mapat într-un mod special în spațiul adreselor MAC multicast. Și problema este că nu vor fi niciodată folosite ca adresă MAC sursă și, prin urmare, nu vor fi învățate de comutator și introduse în tabelul de adrese MAC. Ce face comutatorul cu cadrele a căror adresă de destinație nu a fost învățată? Le trimite în toate porturile. Ceea ce s-a întâmplat exact.
Aceasta este acțiunea implicită.
Adrese MAC multicast
Deci, ce adrese MAC destinatare sunt introduse în antetul Ethernet al unor astfel de pachete? Difuzare? Nu. Există o gamă specială de adrese MAC la care sunt mapate adresele IP multicast.Aceste adrese speciale încep astfel: 0x01005e și următorul al 25-lea bit ar trebui să fie 0 (încercați să răspundeți de ce este așa). Cei 23 de biți rămași (să vă reamintesc, sunt 48 de biți în adresa MAC) sunt transferați de la adresa IP.
Aici zac unele nu foarte grave, dar problema. Gama adreselor multicast este determinată de masca 224.0.0.0/4, ceea ce înseamnă că primii 4 biți sunt rezervați: 1110, iar restul de 28 de biți pot fi modificați. Adică avem 2^28 de adrese IP multicast și doar 2^23 de adrese MAC - lipsesc 5 biți pentru a mapa 1 la 1. Prin urmare, ultimii 23 de biți ai adresei IP sunt pur și simplu luați și transferați unul la unu la adresa MAC, restul de 5 sunt aruncați.
Acest lucru înseamnă în esență că o adresă MAC multicast se va mapa la 2^5=32 de adrese IP. De exemplu, grupurile 224.0.0.1, 224.128.0.1, 225.0.0.1 și așa mai departe până la 239.128.0.1 se vor mapa toate la aceeași adresă MAC 0100:5e00:0001.
Dacă luăm exemplul unei gropi streaming video, atunci poți vedea:
Adresă IP - 224.2.2.4, adresa MAC: 01:00:5E:02:02:04.
Există și alte adrese MAC multicast care nu au nimic de-a face cu multicast IPv4 (clic). Toate, de altfel, se caracterizează prin faptul că ultimul pic primul octet este 1.
Desigur, nu pe niciuna card de retea, o astfel de adresă MAC nu poate fi configurată, deci nu va fi niciodată în câmpul Sursă MAC al cadrului Ethernet și nu va intra niciodată în tabelul de adrese MAC. Aceasta înseamnă că astfel de cadre ar trebui trimise ca orice Unicast necunoscut către toate porturile VLAN.
Tot ceea ce am considerat înainte este suficient pentru transmiterea completă a oricărui trafic multicast de la streaming video la cotațiile bursiere. Dar vom suporta, în lumea noastră aproape perfectă, un asemenea scandal precum transmiterea prin difuzare a ceea ce s-ar putea transmite la câțiva aleși?
Deloc. Mai ales pentru perfecționiști a fost inventat un mecanism Snooping IGMP.
Snooping IGMP
Ideea este foarte simplă - comutatorul „ascultă” pachetele IGMP care trec prin el.Pentru fiecare grup separat, menține un tabel de porturi din amonte și din aval.
Dacă un raport IGMP pentru un grup vine de la un port, înseamnă că există un client acolo, comutatorul îl adaugă la lista de legături în jos pentru acest grup.
Dacă o interogare IGMP pentru un grup provine dintr-un port, înseamnă că există un router acolo, comutatorul îl adaugă la lista celor din amonte.
În acest fel, se formează un tabel pentru transmiterea traficului multicast la nivel de legătură.
Ca urmare, atunci când un flux multicast vine de sus, acesta este copiat numai pe interfețele din aval. Dacă există doar doi clienți pe un switch cu 16 porturi, traficul va fi livrat numai către aceștia.
Geniul acestei idei se termină atunci când ne gândim la natura ei. Mecanismul presupune că comutatorul trebuie să asculte traficul la nivelul 3.
Cu toate acestea, IGMP-Snooping nu poate fi comparat cu NAT în ceea ce privește gradul în care sunt ignorate principiile interacțiunii cu rețeaua. În plus, pe lângă economisirea resurselor, oferă o mulțime de oportunități mai puțin evidente. Și, în general, în lumea modernă, un comutator care poate privi în interiorul IP nu este un fenomen excepțional.
Serverul 172.16.0.5 transmite trafic multicast către grupurile 239.1.1.1, 239.2.2.2 și 239.0.0.x.
Configurați rețeaua astfel încât:
- clientul 1 nu s-a putut alătura grupului 239.2.2.2. Dar în același timp s-ar putea alătura grupului 239.0.0.x.
- clientul 2 nu s-a putut alătura grupului 239.1.1.1. Dar în același timp s-ar putea alătura grupului 239.0.0.x.
În sfârșit, o problemă non-trivială pe multicast (autorii nu suntem noi, răspunsurile vor conține un link către original).
Cea mai simplă schemă:
Pe de o parte este serverul sursă, pe de altă parte este un computer care este gata să primească trafic.
Puteți seta singur adresa fluxului multicast.
Și, în consecință, două întrebări:
1.
Ce trebuie făcut pentru ca computerul să poată primi fluxul fără a recurge la rutarea multicast?
2.
Să presupunem că nici măcar nu știți ce este multicast și nu îl puteți configura, cum să transferați un flux de pe server pe computer?
Problema poate fi găsită cu ușurință într-un motor de căutare, dar încercați să o rezolvați singur.
Mulțumim lui JDima pentru ajutor în pregătirea acestui articol...
In spate suport tehnic mulțumită Natașei Samoilenko.
KDPV a fost desenat de Nina Dolgopolova, o artistă minunată și prietenă a proiectului.
Există încă o mulțime de lucruri interesante în grupul de articole SDSM înainte de a se termina, așa că nu este nevoie să îngropați ciclul din cauza absenței îndelungate a lansării - cu fiecare articol nou, complexitatea crește semnificativ. Aproape toate MPLS, IPv6, QoS și designul de rețea sunt înainte.
După cum probabil ați observat deja, linkmeup are acum proiect nou- Glosarul Lookmeup (da, imaginația noastră nu este departe). Sperăm că acest glosar va deveni cea mai cuprinzătoare referință de termeni din domeniul comunicațiilor, așa că salutăm orice ajutor în completarea lui. Scrie-ne la [email protected]
Etichete:
Adaugă eticheteScriitor senior de tehnologie
Cineva v-a trimis un e-mail un fișier PIM și nu știți cum să îl deschideți? Poate ați găsit un fișier PIM pe computerul dvs. și vă întrebați ce este? Windows vă poate spune că nu îl puteți deschide sau, în cel mai rău caz, puteți întâlni un mesaj de eroare corespunzător legat de fișierul PIM.
Înainte de a putea deschide un fișier PIM, trebuie să aflați ce fel de fișier este extensia de fișier PIM.
Bacsis: Erorile de asociere incorectă a fișierelor PIM pot fi un simptom al altor probleme de fond în Windows sistem de operare. Aceste intrări nevalide pot produce, de asemenea, simptome asociate, cum ar fi porniri lente ale Windows, înghețarea computerului și alte probleme de performanță a computerului. Prin urmare, este foarte recomandat să scanați registrul Windows pentru asocieri de fișiere nevalide și alte probleme legate de un registru fragmentat.
Răspuns:
Fișierele PIM au Fișiere comprimate, care este asociat în principal cu fișierul Manager de informații personale.
Fișierele PIM sunt, de asemenea, asociate cu PixMaker Project File, Ultimate Draw Pascal Text Mode Image, PIMPLE Compressed File (Ilia Muraviev) și FileViewPro.
Tipuri suplimentare de fișiere pot folosi, de asemenea, extensia de fișier PIM. Dacă cunoașteți orice alte formate de fișiere care utilizează extensia de fișier PIM, vă rugăm să ne contactați pentru a ne putea actualiza informațiile în consecință.
Cum să vă deschideți fișierul PIM:
Cel mai rapid și simplu mod de a vă deschide fișierul PIM este să faceți dublu clic pe el. În acest caz, sistemul Windows însuși va alege programul necesar pentru a vă deschide fișierul PIM.
În cazul în care fișierul dvs. PIM nu se deschide, este foarte probabil să nu aveți aplicația necesară instalată pe computer pentru a vizualiza sau edita fișiere cu extensii PIM.
Dacă computerul deschide un fișier PIM dar program greșit, va trebui să modificați setările de asociere a fișierelor din dvs Registrul Windows. Cu alte cuvinte, Windows asociază extensiile de fișiere PIM cu programul greșit.
Instalați produse opționale - FileViewPro (Solvusoft) | | | |
Instrumentul de analiză a fișierelor PIM™
Nu sunteți sigur ce tip de fișier PIM este? Doriți să obțineți informații precise despre un fișier, despre creatorul acestuia și despre cum poate fi deschis?
Acum puteți obține instantaneu toate informațiile necesare despre fișierul PIM!
Revoluționarul PIM File Analysis Tool™ scanează, analizează și raportează informații detaliate despre fișierele PIM. Algoritmul nostru în curs de brevetare analizează rapid fișierul și oferă informații detaliate în câteva secunde într-un format clar, ușor de citit.†
În doar câteva secunde, veți ști exact ce tip de fișier PIM aveți, aplicația asociată fișierului, numele utilizatorului care a creat fișierul, starea de securitate a fișierului și alte informații utile.
Pentru a începe analiza gratuită a fișierului dvs., pur și simplu glisați și fixați fișierul dvs. PIM în interiorul liniei punctate de mai jos sau faceți clic pe „Răsfoiește-mi computerul” și selectați fișierul. Raportul de analiză a fișierului PIM va fi afișat mai jos, chiar în fereastra browserului.
Trageți și plasați fișierul dvs. PIM aici pentru a începe analiza
Vizualizați computerul meu »
Vă rugăm să verificați și fișierul meu pentru viruși
Fișierul dvs. este analizat... așteptați.
Relativ recent, am avut norocul să introduc și chiar să configurez rutarea multicast pentru IPTV. Inițial, nu eram complet familiarizat cu acest subiect, iar acest lucru m-a forțat să ling partea de sus a unui rezervor de vodcă și să caut o cantitate imensă de documente pentru a ajunge la curent.
Și aici este problema. De obicei, totul este prezentat în documentație odată, iar pentru o persoană care întâlnește acest subiect pentru prima dată, nu este clar de unde să înceapă. În timp ce citeam pdf-urile, m-am surprins gândindu-mă că ar fi bine să dau undeva peste un articol care ar putea lua o scurtătură de la teorie la practică pentru a înțelege de unde să încep și de unde să concentrezi atenția.
Nu am reusit sa gasesc un astfel de articol. Acest lucru m-a determinat să scriu acest articol pentru cei care, la fel ca mine, se confruntă cu întrebarea ce fel de fiară este IPTV și cum să o rezolv.
Introducere
Acesta este primul meu articol (dar nu ultimul! Sunt mult mai multe animale), voi încerca să prezint totul cât mai accesibil.În primul rând, să schițăm câteva concepte pentru a elimina alte neînțelegeri. Există trei tipuri de trafic:
- unicast- unicast, o sursă de flux, o destinație
- difuzat- difuzare, o singură sursă, destinatarii sunt toți clienții din rețea
- multicast- multicast, un expeditor, destinatari un grup de clienți
Ce tip de trafic ar trebui să folosesc pentru IPTV?
Evident, pentru canalele de difuzare, cea mai mare preferință este dată de multicast.
Orice canal TV pe care dorim să-l transmitem în rețea este caracterizat de o adresă de grup, care este selectată din gama rezervată acestor scopuri: 224.0.0.0 – 239.255.255.255
.
Pentru ca IPTV să funcționeze, aveți nevoie de un router care acceptă multicast (denumit în continuare MR). Acesta va urmări apartenența unui anumit client într-un anumit grup, de ex. Monitorizați în mod constant ce client este trimis pe ce canal TV.
Pentru ca un client să se înregistreze într-unul dintre aceste grupuri și să se uite la un canal TV, se folosește un protocol IGMP(Internet Group Management Protocol).
Câteva despre cum funcționează IGMP.
Există un server care este inclus în routerul MR. Acest server difuzează mai multe desene animate TV, de exemplu:Clientul pornește canalul de știri, astfel, fără să bănuiască, trimite o solicitare către MR pentru a se conecta la grupul 224.12.0.1. Din punctul de vedere al protocolului IGMP, aceasta este o solicitare „ ÎNSCRIEȚI LA 224.12.0.1”.
Dacă utilizatorul trece la alt canal, atunci el trimite mai întâi o notificare către MR că dezactivează canalul de știri sau părăsește acest grup. Pentru IGMP este „ PLACIE 224.12.0.1" Și apoi repetă o solicitare similară JOIN pentru canalul dorit.
MR întreabă uneori pe toată lumea: „Cine este conectat la ce grup?” pentru a deconecta acei clienți cu care s-a pierdut conexiunea și nu au avut timp să trimită o notificare PĂRĂSI. Pentru aceasta MR folosește cererea ÎNTREBARE.
Răspunsul abonatului la această solicitare este RAPORT DE MEMBRU, care conține o listă a tuturor grupurilor din care face parte clientul.
Configurarea rutei multicast.
Să presupunem că clienții aceluiași grup urmăresc același desen animat, dar se află în segmente de rețea diferite (rețeaua A și rețeaua B). Pentru ca ei să-și obțină desenele animate, a fost inventată rutarea multicast.
Exemplu de configurare a routerelor MR1 și MR2.
| Rețeaua A | 10.1.0.0/24 |
| Rețeaua B | 10.2.0.0/24 |
| Rețeaua C | 10.3.0.0/24 |
| MR1 | MR2 |
| MR1#sh alergă rutare multicast IP |
MR2#sh alergă rutare multicast IP |
Echipa" rutare multicast ip" pornește rutarea corespunzătoare, dar dacă este oprită, atunci routerul nu transmite pachete multicast, adică nu vor ajunge la vizualizatorul perplex al desenelor animate.
Să aruncăm o privire mai atentă la comanda " ip pim sparse-mode".
Despre modurile protocolului PIM și protocolul în sine.
PIM(Protocol Independent Multicast) - protocol de rutare multicast. Își populează tabelul de rutare multicast pe baza tabelului de rutare obișnuit. Aceste tabele pot fi vizualizate folosind comenzile „ ruta de expediere" Și " ruta de expediere„, respectiv. Scopul protocolului PIM este de a construi un arbore de rute pentru trimiterea de mesaje multicast.Protocolul PIM are două moduri principale: descărcat ( mod rar) și dens ( modul dens). Tabelul de rutare multicast arată puțin diferit pentru ei. Uneori, aceste moduri sunt considerate ca protocoale separate - PIM-SM și PIM-DM.
În configurația noastră pe interfețe am specificat modul " ip pim sparse-mode".
(config-if)# ip pim?
Modul dens Activați funcționarea în modul dens PIM
sparse-dense-mode Activați funcționarea PIM în mod sparse-dense
sparse-mode Activați funcționarea PIM în modul dispers
………
Care este diferența?
PIM-DM folosește un mecanism de inundare și tăiere. Cu alte cuvinte. Routerul MR trimite tuturor fluxurile multicast care sunt înregistrate pe el. Dacă clientul nu are nevoie de niciunul dintre aceste canale, atunci îl refuză. Dacă toți clienții agățați de router au abandonat canalul, atunci routerul trimite un „nu mulțumesc, nu este nevoie” routerului din amonte.PIM-SM nu trimite inițial canale TV înregistrate pe acesta. Trimiterea va începe numai atunci când un client primește o cerere pentru aceasta.
Acestea. în PIM-DM MR trimite tuturor, apoi elimină ceea ce nu este necesar, iar în PIM-SM MR începe să transmită doar la cerere.
Dacă membrii grupului sunt împrăștiați pe mai multe segmente de rețea, așa cum este tipic în cazul IPTV, PIM-DM va folosi cea mai mare parte a lățimii de bandă. Și acest lucru poate duce la scăderea productivității. În acest caz, este mai bine să utilizați PIM-SM.
Există și alte diferențe între PIM-DM și PIM-SM.
PIM-DM construiește un arbore separat pentru fiecare sursă a unui anumit grup multicast, de ex. O rută multicast va fi caracterizată printr-o adresă sursă și o adresă de grup. Tabelul de rutare multicast va avea intrări de forma (S,G), unde S este sursa, G este grup.
PIM-SM are câteva caracteristici speciale. Acest mod necesită un punct de întâlnire ( RP - punct de întâlnire) pe care vor fi înregistrate surse de fluxuri multicast și se va crea o rută de la sursa S (în sine) către grupul G: (S,G).
Astfel, traficul merge de la sursă la RP de-a lungul traseului (S,G), iar apoi către clienți de-a lungul unui arbore comun surselor unui anumit grup, care se caracterizează prin traseul (*,G) - „* ” simbolizează „orice sursă”. Acestea. sursele înregistrate la RP, iar apoi clienții primesc deja un flux de la RP și nu contează pentru ei cine a fost sursa originală. Rădăcina acestui arbore comun va fi RP.
Punctul de întâlnire este unul dintre routerele multicast, dar toate celelalte routere trebuie să știe „cine este punctul RP” și să poată ajunge la el.
Exemplu definiție statică RP (MR1). Să anunțăm tuturor ruterelor multicast că punctul de întâlnire este 10.0.0.1 (MR1):
Toate celelalte routere trebuie să cunoască ruta către RP:
ruta IP 10.0.0.0 255.255.255.0 10.10.10.1
Există și alte modalități de a determina RP, acestea sunt auto-RP și router bootstarp, dar acesta este un subiect pentru un articol separat ( daca este cineva interesat - va rog)?
Să vedem ce se întâmplă după configurarea routerelor.
Încă luăm în considerare o schemă cu routere MR1 (RP) și MR2. De îndată ce activăm legătura între routerele MR1 și MR2, ar trebui să vedem mesaje în jurnalelePentru MR1:
%PIM-5-NBRCHG: vecin 10.10.10.2 UP pe interfața Ethernet3
Pentru MR2:
%PIM-5-NBRCHG: vecin 10.10.10.1 UP pe interfața Ethernet0
Acest lucru indică faptul că ruterele au stabilit o relație de adiacență PIM între ele. De asemenea, puteți verifica acest lucru folosind comanda:
MR1# sh ip pim vecin
Masa vecinilor PIM
Mod: B - Capabil Bidir, DR - Router desemnat, N - Prioritate DR implicită, S - Capabil pentru reîmprospătarea stării
| Adresa vecinului | Interfață | Timp de funcționare/Expiră | Ver | DR Prio/Mode |
| 10.10.10.2 | Ethernet3 | 00:03:05/00:01:37 | v2 | 1/DR S |
Nu uitați de TTL.
Mi-a fost convenabil să îl folosesc ca server de testare player VLC. Totuși, așa cum am descoperit mai târziu, chiar dacă am setat un TTL suficient prin GUI, tot (sper doar în versiunea pe care am folosit-o) a trimis cu încăpățânare pachete multicast cu TTL=1. A trebuit să îl rulez pe cel încăpățânat cu opțiunea „vlc.exe –ttl 3” pentru că vom avea două routere pe drum, fiecare dintre ele reduce TTL-ul pachetului cu unul.Cum poți detecta în continuare o problemă cu TTL? Una dintre metode. Lăsați serverul să transmită canalul 224.12.0.3 cu TTL=2, apoi pachetele trec în mod normal pe routerul MR1, dar în spatele routerului MR2 clienții nu vor mai putea să-și vizioneze desenele animate.
Acest lucru este detectat folosind comanda „sh ip traffic” de pe MR2. Ne uităm la câmpul „număr de hop bad” - acesta este numărul de pachete care „au murit”, măsurat de acestea, la TTL=0.
MR2# traficul de nave
Statistici IP:
RCVD: 36788 total, 433 destinație locală
0 erori de format, 0 erori de sumă de control, 2363 număr de hop prost
……………………………………
Dacă acest contor crește rapid, atunci problema este TTL.
Afișați ruta IP
După ce am activat difuzarea a trei canale pe server, vedem următoarele în tabelul de rutare multicast:MR1# ruta de expediere
(*, 224.12.0.1), 00:03:51/oprit, RP 10.0.0.1, steaguri: SP
(10.0.0.2, 224.12.0.1), 00:03:52/00:02:50, steaguri: PT
Lista interfețelor de ieșire: nulă
(*, 224.12.0.2), 00:00:45/oprit, RP 10.0.0.1, steaguri: SP
Interfață de intrare: Null, RPF nbr 0.0.0.0
Lista interfețelor de ieșire: nulă
(10.0.0.2, 224.12.0.2), 00:00:45/00:02:50, steaguri: PT
Interfață de intrare: Ethernet0, RPF nbr 0.0.0.0
Lista interfețelor de ieșire: nulă
(*, 224.12.0.3), 00:00:09/oprit, RP 10.0.0.1, steaguri: SP
Interfață de intrare: Null, RPF nbr 0.0.0.0
Lista interfețelor de ieșire: nulă
(10.0.0.2, 224.12.0.3), 00:00:09/00:02:59, steaguri: PT
Interfață de intrare: Ethernet0, RPF nbr 0.0.0.0
Lista interfețelor de ieșire: nulă
Vedem ca au aparut rute de forma (S,G), de exemplu (10.0.0.2, 224.12.0.3), i.e. sursa 10.0.0.2 s-a înregistrat, difuzând pentru grupul 224.12.0.3. Și, de asemenea, rutele de la RP la client: (*,G), de exemplu (*, 224.12.0.3) - pe care le vor folosi, așa-numitul arbore comun tuturor.
De îndată ce o solicitare de recepție a canalului 1 ajunge pe interfața MR1 (RP), în tabelul de rutare multicast apar următoarele modificări:
MR1# ruta de expediere
…………………
(*, 224.12.0.1), 00:33:16/00:02:54, RP 10.0.0.1, steaguri: S
Interfață de intrare: Null, RPF nbr 0.0.0.0
Lista interfețelor de ieșire:
(10.0.0.2, 224.12.0.1), 00:33:17/00:03:25, steaguri: T
Interfață de intrare: Ethernet0, RPF nbr 0.0.0.0
Lista interfețelor de ieșire:
Ethernet3, Forward/Sparse, 00:02:37/00:02:53
A devenit clar că cererile pentru acest grup veneau de la portul Ethernet3.
verificare RPF
Este posibilă o situație când routerul primește un flux multicast pe două interfețe. Pe care dintre aceste două interfețe o va considera routerul ca sursă?Pentru a face acest lucru, efectuează o verificare RPF (Reverse Path Forwarding) - verifică ruta către sursă folosind tabelul obișnuit de rutare unicast și selectează interfața prin care trece ruta către această sursă. Această verificare este necesară pentru a evita formarea buclelor.
Protocoale PIMși IGMP
Există multe protocoale pentru a livra multicast de la sursă la destinatar - IGMP, PIM, MSDP, MBGP, MOSPF, DVMRP. În prezent, cele mai frecvent utilizate protocoale enumerate mai sus sunt: PIM și IGMP .
Figura 6.8
PIM (Multicast independent de protocol) construiește o cale circulația traficului multicast de la sursă la destinatari prin routere. PIM oferă un grafic de rețea care conectează toate gazdele dintr-un anumit grup, cu o singură cale între două gazde. Un astfel de grafic se numește spanning tree. Protocolul PIM monitorizează în mod constant arborele de întindere și din când în când taie acele ramuri ale arborelui care, din cauza schimbărilor în starea rețelei, nu mai conduc la membrii unui anumit grup.
Protocolul IGMP(Protocolul de management al grupului de Internet ) este un protocol de control al grupului de Internet dezvoltat în 1989. IGMP - Acest protocol de rețea interacțiunea dintre clienții de trafic multicast și routerul cel mai apropiat de ei. Folosind acest protocol, routerul află despre prezența destinatarilor de trafic multicast și despre deconectarea acestora. Rolul IGMP este foarte simplu: dacă nu există clienți, atunci nu este nevoie să transmiteți trafic multicast către segment. Dacă apare un client, acesta anunță routerul folosind IGMP că dorește să primească trafic.
Sursă programe IPTV nu are nevoie de protocolul IGMP. Orice computer conectat la Internet poate deveni o sursă multicast fără a necesita niciun fel suplimentar software, în plus, care este inclus ca parte a implementării normale a stivei TCP/IP.
Pentru a deveni un destinatar de date multicast, un nod trebuie să-și „exprime” interesul față de routerul la care este conectată direct rețeaua sa. Pentru a face acest lucru, gazda trebuie să stabilească comunicarea cu routerul utilizând protocolul IGMP.
La difuzarea programelor TV în modul multicast, serverul video trimite un singur flux video (pentru fiecare program TV), indiferent de numărul de abonați.
La secțiunea de conectare dintre serverul video și gateway-ul de acces (comutator Ethernet, DSLAM), toate programele TV sunt difuzate (Figura 6.6). Pe secțiunea de conexiune dintre centrală și STB este difuzat doar programul pe care abonatul a ales să-l urmărească. Acest lucru se întâmplă prin protocolul IGMP.
Figura 6.6
IGMP definește trei tipuri de mesaje:
1) Cerere de membru. Cu acest mesaj, routerul încearcă să afle ce grupuri sunt gazdele din retea locala atașat la oricare dintre interfețele sale. Solicitarea de membru vine sub două forme: într-una, routerul o face cerere generală despre toate grupurile" Interogare generală IGMP"(cerere generală), în altul este interesat doar de informații despre un anumit grup, a cărui adresă este indicată în cerere „Interogare septică de grup IGMP”.
2) Raport de membru (Raport IGMP) . Cu acest mesaj, gazdele răspund routerului care a trimis o solicitare de membru în rețea. Mesajul conține informații despre adresa IP a grupului din care aparțin. Routerul, fiind membru al tuturor grupurilor, primește mesaje direcționate către orice adresă de grup. Pentru un router care primește mesaje de răspuns, este important doar faptul că există membri ai unui anumit grup și nu dacă anumite gazde aparțin unor grupuri specifice. O gazdă poate trimite un raport de membru nu numai ca răspuns la o solicitare de router, ci și din proprie inițiativă atunci când încearcă să se alăture unui anumit grup. După un astfel de mesaj, gazda se poate aștepta ca traficul pentru acest grup să fie livrat efectiv către rețeaua căreia îi aparține gazda.
3) Paraseste grupul (IGMP Pleacă). Gazda poate folosi acest mesaj pentru a semnala ruterului „sau” că dorește să părăsească un grup în care a fost anterior membru. La primirea acestui mesaj, routerul trimite o cerere de apartenență specifică doar membrilor acelui grup specific. « Interogare septică de grup IGMP » , iar dacă nu primește un răspuns la acesta (adică a fost ultima gazdă din grup), atunci nu mai transmite trafic multicast pentru acest grup.
Mesajele de solicitare de membru sunt trimise de router în mod regulat, la o anumită frecvență. Tabelele cache de grup sunt menținute pe fiecare interfață cu routerele IGMP instalate. Tabelul cache conține o listă a tuturor grupurilor care au cel puțin un membru. Fiecare rând de tabel are un timeout. Routerul trimite în mod regulat solicitări „IGMP General Query”. » (implicit este la fiecare 60 de secunde) pentru a verifica dacă fiecare grup are în continuare membri. Dacă nu este primit un răspuns pentru un grup în intervalul de timp specificat, rândul corespunzător este eliminat din tabelul cache, iar routerul presupune că nu mai există membri ai grupului respectiv în rețea.
O rețea locală poate avea mai multe gazde interesate să primească trafic de la același grup, dar routerul are nevoie doar de o confirmare de la o gazdă pentru a continua să trimită trafic către rețea pentru acel grup. Pe baza informațiilor obținute prin IGMP, routerele pot determina ce rețele conectate la ele ar trebui să redirecționeze traficul multicast.
Pentru ca o gazdă să primească trafic multicast, nu este suficient să instalați protocolul IGMP pe ea, prin care gazda poate trimite un mesaj routerului său despre dorința sa de a se alătura grupului. În plus, trebuie să configurați interfața de rețea a gazdei astfel încât să înceapă să capteze cadre din rețeaua locală care transportă pachete multicast pentru grupul la care s-a alăturat gazda.
Pentru a fi mai clar cum funcționează IPTV, să ne uităm la mic exemplu (Figura 6.9). Pentru ca IPTV să funcționeze, aveți nevoie de un router care acceptă multicast (în continuare DOMNUL. ). Acesta va urmări apartenența unui anumit client într-un anumit grup, de ex. monitorizați în mod constant ce canal TV este trimis către care client. Există un server în rețea ( Sursă multicast ), conectat la routerul MR. Acest server transmite canale TV, de exemplu:
Să presupunem că clientul pornește canalul de Știri, prin urmare, fără să bănuiască, trimite o solicitare către MR pentru a se conecta la grupul 224.12.0.1. Din punctul de vedere al protocolului IGMP, acest mesaj « Raport IGMP 224.12.0.1 ” . Dupa primire Router multicast a acestui mesaj, DOMNUL. îl înregistrează și comutatorul Ethernet ( S.W. ) începe copierea pachetelor de difuzare destinate acestui grup în portul la care este conectat clientul. Clientul începe să primească trafic.
Figura 6.9 – Principiul de funcționare IGMP
Dacă clientul trece la alt canal, mai întâi trimite o notificare DOMNUL. , că dezactivează canalul de știri, adică. părăsește acest grup. Pentru IGMP acest mesaj este „ PLACIE 224.12.0.1 ” (PĂREȘI grupa 224.12.0.1). Și apoi trimite din nou mesajul « Raport IGMP » pentru canalul dorit.
Router DOMNUL. primirea mesajului „ PĂRĂSI ” pentru orice grup, trebuie să se asigure că nu există alți destinatari ai acestui canal, trimite mesajul ” Interogare specifică grupului IGMP" de două ori. Și dacă niciun STB nu răspunde, atunci DOMNUL. nu mai transmite trafic pentru acest grup.
În plus, M.R. periodic (la fiecare 60 de secunde) chestionează pe toată lumea: „la care grup este cine s-a conectat?” pentru a afla componența grupurilor la momentul actual, pentru a deconecta acei clienți cu care s-a pierdut conexiunea. în care DOMNUL. folosește interogarea " Interogare generală IGMP» (General cerere ) . Dacă pentru 3 la rând" Interogare" nu existau interfete DOMNUL. Răspuns " Raport IGMP" pentru un grup DOMNUL. elimină acest canal din tabelul său de rutare multicast - oprește trimiterea de trafic către acest canal până când cel puțin un client se conectează la acest grup.
După alăturarea grupului necesar, echipamentul client începe să primească flux de date prin protocolul UDP pe portul 1234.
Prin urmare, schimbând canalele de pe telecomanda leneș”, atât de familiar și simplu pentru utilizatorii de televiziune tradițională, este dificil pentru rețeaua IPTV. Ori de câte ori un utilizator IPTV schimbă canalul, rețeaua pornește lucrează în plină desfășurare:
1) În primul rând, utilizatorul ar trebui să fie deconectat de la grupul Multicast.
2) În al doilea rând, conectați-l la un nou grup Multicast.
3) În al treilea rând, dacă nu există niciun canal de difuzare în acest moment, deoarece nimeni nu îl urmărește, atunci trebuie să inițiați difuzarea și să creați un nou grup Multicast.
Așa că hai să repetăm:
Raport IGMP- trimis de client la conectare dacă clientul dorește să primească trafic de la un anumit grup sau ca răspuns la cererea de membru IGMP Query a unui router.
Interogare generală IGMP- trimis de router periodic pentru a verifica ce grupuri sunt necesare în prezent.
Interogare septică de grup IGMP- trimis de router ca răspuns la mesajul Leave pentru a afla dacă mai sunt alți destinatari în acest grup. Adresa grupului multicast este indicată ca adresa destinatarului.
IGMP Pleacă- trimis de client cand doreste sa paraseasca grupul.
7 rețele optice pasive (PON) – revoluția în bandă largă
Fibră optică pe ultimul
mile: trebuie să înțelegi asta
Tehnologia PON este utilizată pentru implementarea structurilor FTTH de la fibră până la domiciliu. Capacitățile tehnologiei GPON sunt surprinzătoare în primul rând pentru că accesul la resursele de Internet este posibil la viteze de până la 1 Gb/s, ceea ce este de două sute de ori mai mare decât pe liniile de cupru.
Rețeaua este construită folosind divizoare de putere optice pasive (splitters) care nu necesită alimentare sau întreținere. O caracteristică a tehnologiei este un canal 100% optic de la PBX la apartamentul sau biroul clientului, care vă permite să îmbunătățiți calitatea transmisiei semnalului (voce, date, video) și să creșteți viteza de transfer de date de zece ori.
Infrastructura GPON este extrem de nepretențioasă și sigură: nu necesită alimentare și poate fi instalată în orice încăpere, chiar și în cele nepotrivite.
Principalele avantaje ale PON:
1 Simplitatea și perspectivele de implementare a infrastructurii de distribuție;
2 Lipsa nodurilor active intermediare;
3 Implementarea rapidă a rețelei;
4 Usor de asociat cu orice echipament extern;
5 Flexibilitate ridicată în dezvoltarea și extinderea rețelei;
6 Utilizarea independentă a oricăror protocoale de operare și tehnologii de comunicare;
7 Fiabilitate crescută;
8 Ușurința de conectare a noilor abonați și ușurința de întreținere (conectarea, deconectarea sau defecțiunea unuia sau mai multor noduri de abonat nu afectează în niciun fel funcționarea celorlalți);
9 Cost scăzut crearea unei rețele etc.
