Evaluarea Functionala a Implementarii Protocolului Igmp (internet Group Management Protocol)
Evaluarea funcțională a implementării protocolului IGMP(Internet Group Management Protocol)
Cuprins
Lista Figurilor
Lista Tabelelor
Lista Acronimelor
Introducere
1 Stadiul cunoașterii temei
1.1 Noțiuni introductive despre teoria rețelelor
1.2 Clasificarea rețelelor
1.3 Arhitectura OSI
1.4 Retele bazate pe routere
2 Prezentare de tip multicast
2.1 Tipuri de transmisie ale mesajelor
2.2 Adresarea de tip multicast
3 Protocolul IGMP (Internet Group Management Protocol)
3.1 Necesitatea protocolului
3.2 IGMPv1
3.3 IGMPv2
3.4 IGMPv3
3.5 IGMP Snooping
4 Testarea IGMP (Internet Group Management Protocol)
4.1 Introducere în IxNetwork
4.2 GUI Framework
4.3 Enhanced Port Managament
4.4 Enhanced Protocol Configuration
4.5 Traffic Wizard
4.6 Evaluarea protocolului multicast IGMP
4.7 Configurarea echipamentelor
4.8 Configurarea routerului CISCO ( DUT – Device Under Test )
4.9 Selectarea porturilor Ixia
4.10 Configurarea protocolului IGMP
4.11 Verificarea conectivitatii pe router
4.12 Verificarea conectivitatii
4.13 Generarea traficului
4.14 Generarea raporturilor
4.15 Primul scenariu
4.16 Al 2 lea scenariu
4.17 Al 3 lea scenariu
4.18 Al 4 lea scenariu
4.19 Al 5 lea scenariu
4.20 Al 6 lea scenariu
4.21 Al 7 lea scenariu
5 Plan de afacere pentru implementarea rețelelor de calculatoare și mentenanța echipamentelor de routare
5.1 Analiza mediului de afacere și propunerea afacerii
5.2 Descrierea afacerii
6 Concluzii :
7 Bibliografie
Lista Figurilor
Figura 1.1 Segmentarea pachetelor[1] 12
Figura 1.2 Multiplexarea pachetelor[1] 12
Figura 1.3 Rețea de tip WAN[1] 13
Figura 1.4 Stiva OSI[2] 14
Figura 1.5 Formarea unui pachet IPv4[3] 14
Figura 1.6 Structura unui pachet IPv4[3] 15
Figura 1.7 Formarea unei rețele[1] 17
Figura 1.8 Router Cisco[3] 17
Figura 2.1 Dimensiunea unui pachet multicast[3] 20
Figura 2.2 Model de transmisie multicast[3] 20
Figura 3.1 Structura mesaj IGMPv1[6] 23
Figura 3.2 Alaturarea unui calculator la un grup multicast[3] 24
Figura 3.3 Structura unui mesaj IGMPv2[4] 25
Figura 3.4 Calculul timpului de răspuns[4] 26
Figura 3.5 Procesul de parasire al unui grup multicast[4] 27
Figura 3.6 Algoritm pentru părăsirea unui grup multicast[4] 28
Figura 3.7 Formatul unui mesaj IGMPv3[5] 29
Figura 3.8 IGMP Snooping 1[7] 30
Figura 3.9 IGMP Snooping 2[7] 30
Figura 4.1 Interfața grafică IxNetwork 31
Figura 4.2 Adăugarea porturilor din șasiu 32
Figura 4.3 Exemplu Multicast Wizard 33
Figura 4.4 Exemplu Traffic Wizard 34
Figura 4.5 Structura echipamentelor utilizate 35
Figura 4.6 Configurarea Routerului part 1 36
Figura 4.7 Configurarea Routerului part 2 36
Figura 4.8 Exemplu selectare porturi Ixia 37
Figura 4.9 Verificarea functionalitații porturilor 37
Figura 4.10 Exemplu configurare protocol IGMP 1 38
Figura 4.11 Selectare protocolului IGMP 38
Figura 4.12 Exemplu configurare interfețe IGMP 39
Figura 4.13 Configurarea protocolului IGMP 2 39
Figura 4.14 Alegerea versiunii de IGMP în cadrul IxNetwork 40
Figura 4.15 Crearea grupurilor multicast 40
Figura 4.16 Verificarea interfețelor IGMP 41
Figura 4.17 Verificarea grupurilor multicast IGMP 41
Figura 4.18 Verificarea conectivitații router – IxNetwork 42
Figura 4.19 Generarea traficului 42
Figura 4.20 Exemplu de Traffic Wizard 1 43
Figura 4.21 Exemplu de Traffic Wizard Editor Packet QoS 44
Figura 4.22 Exemplu de Traffic Wizard Flow Group Setup 44
Figura 4.23 Exemplu de Traffic Wizard Frame Setup 45
Figura 4.24 Exemplu de Traffic Wizard Rate Setup 46
Figura 4.25 Exemplu de Traffic Wizard Flow Tracking 46
Figura 4.26 Exemplu de Traffic Wizard Preview 47
Figura 4.27 Exemplu de Traffic Wizard Validater 47
Figura 4.28 Aplicarea traficului L2-3 48
Figura 4.29 Colectarea statisticilor 48
Figura 4.30 Selectarea interfețelor pentru transmisie 49
Figura 4.31 Rezultate IGMPv1 topologie 1 49
Figura 4.32 Rezultate IGMPv1 topologie 1 50
Figura 4.33 Rezultate IGMPv1 topologie 1 50
Figura 4.34 Rezultate IGMPv1 topologie 1 51
Figura 4.35 Rezultate IGMPv1 topologie 1 52
Figura 4.36 Rezultate IGMPv1 topologie 1 52
Figura 4.37 Rezultate IGMPv2 topologie 1 53
Figura 4.38 Rezultate IGMPv2 topologie 1 53
Figura 4.39 Rezultate IGMPv2 topologie 1 54
Figura 4.40 Rezultate IGMPv2 topologie 1 54
Figura 4.41 Rezultate IGMPv2 topologie 1 55
Figura 4.42 Rezultate IGMPv2 topologie 1 55
Figura 4.43 Rezultate IGMPv3 topologie 1 56
Figura 4.44 Rezultate IGMPv3 topologie 1 56
Figura 4.45 Rezultate IGMPv3 topologie 1 57
Figura 4.46 Rezultate IGMPv3 topologie 1 57
Figura 4.47 Rezultate IGMPv3 topologie 1 58
Figura 4.48 Rezultate IGMPv3 topologie 1 58
Figura 4.49 Rezultate IGMPv1 topologie 2 59
Figura 4.50 Rezultate IGMPv1 topologie 2 60
Figura 4.51 Rezultate IGMPv1 topologie 2 60
Figura 4.52 Rezultate IGMPv2 topologie 2 61
Figura 4.53 Rezultate IGMPv2 topologie 2 62
Figura 4.54 Rezultate IGMPv2 topologie 2 62
Figura 4.55 Rezultate IGMPv3 topologie 2 63
Figura 4.56 Rezultate IGMPv3 topologie 2 63
Figura 4.57 Rezultate IGMPv3 topologie 2 64
Lista Tabelelor
Table 1 Analiza macromediului 66
Table 2 Analiza punctelor tari și slabe ale afacerii 67
Table 3 Matricea MEFE 68
Table 4 Matricea MEFI 68
Lista Acronimelor
BGP – Border Gateway Protocol
DNS – Domanin Name Server
DUT – Device Under Test
EIGRP – Enhanced Interior Gateway Routing Protocol
GUI – Graphical User Interface
HTTP – Hypertext Transfer Protocol
IANA – Internet Assigned Numbers Authority
IGMP – Internet Group Management Protocol
IMP – Interface Message Processor
INWG – International Network Working Group
IP – Internet Protocol
IS-IS – Intermediate System to Intermediate System
LAN -Local Area Network
MAC – Media Access Control
MAN – Metropolitan Area Network
MRT – Maximum Response Time
NIC – Network Interface Card
OSI – Open Systems Interconnection
OSPF – Open Shortest Path First
PAN – Personal Area Network
PIM – Protocol Independent Multicast
PPP – Point To Point Protocol
RFC – Rever Path Forwarding
RIP – Routing Information Protocol
RP – Rendezvous Point
RS – Report Supression
RT – Response Time
SBT – Source Based Tree
SDP – Shared Distribution Tree
SMTP – Simple Mail Transfer Protocol
TCP – Transmission Control Protocol
TTL – Time To Leave
UDP – User Datagram Protocol
USB – Universal Serial Bus
VoIP – Voice Over IP
Introducere
Plecând de la cele mai mici viețuitoare ale planetei până la cea mai evoluată specie – omul, a existat permanent o nevoie de comunicare. Dorința de cunoaștere și dezvoltare a limbajului de comunicare a devenit o nevoie tot mai stringentă, în condițiile actuale de dezvoltare a societății omenești. Comunicarea a avut în permanență o importață primordială dezvoltându-se în paralel cu evoluția tehnologică.
Ultimele secole caracterizate de Revoluția indistrială și-au pus amprenta asupra prelucrării și transmiterii informației, prin colectarea, gestionarea și distribuirea acesteia. În prezent se poate spune cu certitudine că tehnologia în sine este agentul care influențează evoluția speciei umane. Rețelele de calculatoare și în special Internet-ul, au un rol esențial în procesul de comunicare al omului modern. Ele devin principalul mijloc de informare și comunicare, înlocuind mijloacele de comunicare clasice (poștă, presă, biblioteci etc. Internetul, fără doar și poate, este considerat cea mai mare realizare a secolului trecut, lansarea lui pentru publicul larg a schimbat în cea mai mare parte modul de viață cotidian.
În anul 1974 apare termenul de Internet el fiind o rețea unitară de computere și de alte echipamente electronice cu adrese computerizate, toate fiind interconectate și dirijate de un ansamblu de protocoale de date standardizate, care s-a extins de la o rețea internă la o rețea externă câțiva ani mai târziu 1989, devenind accesibilă pentru publicul obișnuit de abia în anii 1991-1993.
După anul 1993 Internetul poate fi accesat de pe orice calculator personal, dând posibilitatea transmisterii diverselor informații la distanță atât între înstituții cât și între oameni. Astfel prin accesarea lui, omenirea poate comunica într-un mod foarte ușor, apelând de la informații necesare procesului mediului de lucru până la aplicații în interes personal (cumpărături, poze etc), ba chiar mai mult prin prezență la distanță cu ajutorul camerelor video virtuale.
IGMP (Internet Group Management Protocol) – este un protocol pentru transmia multicast a pachetelor de date fiind folosit de către routere și echipamentele electronice terminale. Ajută la crearea grupurilor de multicast fiind folosit pentru aplicațiile de teleconferință, aplicațiile audio-video dar și jocuri.
Motivul alegerii acestei teme derivă din dorința de cunoaștere a rețelelor de calculatoare, modul de funcționare, configurare și administrare fiind un domeniu pe care trebuie să-l cunoască orice inginer în telecomunicații ce dorește să construiasca o astfel de rețea.
În această lucrare este evidențiat modul de funcționare al protocolului IGMP fiind prezentată atât o versiune de bază cât și alte versiuni mai noi ale acestuia.
În acest sens în capitolele 1 și 2 este realizată o introducere în rețelele de calculatoare și este prezentată noțiunea de adrese și grupuri multicast. În cel de al 3 lea capitol este prezentat protocolul IGMP (Internet Group Management Protocol) împreuna cu modul său de funcționare teoretic dar și concret în cadrul anumitor topologii. În capitolul 4 este realizată prezentarea practică a acestui protocol cu ajutorul atât a programului virtual Cisco Packet Tracer cât și fizic cu ajutorul echipamentelor Ixia din cadrul facultății.
Stadiul cunoașterii temei
Noțiuni introductive despre teoria rețelelor
Pentru ca doi sau mai mulți utilizatori să poată comunica la distanță este necesară o rețea de calculatoare cu echipamentele sale terminale, geografic dispersate, conectate între ele pentru a permite schimbul de informații. Pentru ca utilizatorii să poată comunica trebuie mai intâi stabilit un set riguros de reguli. În teoria rețelelor de calculatoare aceste reguli se numesc protocoale ce implică indentificarea transmițatorului și a receptorului, modul de comunicare, limbajul de comunicare precum viteza și intervalul de timp cu care trimit mesajele și se primeste confirmarea receptionării acestora.
O comunicare la distanță poate avea loc dacă există 3 elemente fundamentale: existența unui emițator, unui receptor și a unui mediu de transmisie. Emițatorul poate fi un echipament electronic sau un om, receptorul este cel care primește mesajul și îl interpretează spre ințelegerea lui, mediul de transmisie este aerului sau firele.
Pentru ca mesajul să poată fi transmis, acesta este convertit în cifre de 0 și de 1 numiți biți. Acești biți sunt codati într-un semnal electric sau într-unul luminos în cazul fibrelor optice.
Deobicei mediul de transmisie este folosit simultan de către mai mulți utilizatori ce doresc să comunice. Acest mediu de transmisie are anumite limitări astfel neputând transmite toate aceste mesaje simultan. În acest scop aceste pachete de date sunt segmentate și multiplexate înainte de a fi trimise.
Segmentarea reprezinta procesul de împarțire a datelor în unitați mai mici de transmisie a acestora la destinatie (fig.1).
Multiplexarea este o metodă prin care mai multe fluxuri de date pot fi transmise prin aceeasi legătură. Un beneficiu foarte important al multiplexarii reprezintă conservarea lațimii de bandă. În cazul apariției unei erori dacă unul din segmente este pierdut este retransmis doar cel in cauză (fig.2).
În momentul în care mesajul ajunge la destinație acesta este reasamblat în ordinerea corectă folosindu-se un așa numit număr de secvență (sequence number).
Clasificarea rețelelor
După mediul de transmisie rețelele pot fi împarțite în:
1. Rețele cu fir – sunt cele conectate prin intermediul cablului de cupru sau prin intermediul fibrelor optice.
2. Rețele wireless – sunt rețele fără fir în ează spre ințelegerea lui, mediul de transmisie este aerului sau firele.
Pentru ca mesajul să poată fi transmis, acesta este convertit în cifre de 0 și de 1 numiți biți. Acești biți sunt codati într-un semnal electric sau într-unul luminos în cazul fibrelor optice.
Deobicei mediul de transmisie este folosit simultan de către mai mulți utilizatori ce doresc să comunice. Acest mediu de transmisie are anumite limitări astfel neputând transmite toate aceste mesaje simultan. În acest scop aceste pachete de date sunt segmentate și multiplexate înainte de a fi trimise.
Segmentarea reprezinta procesul de împarțire a datelor în unitați mai mici de transmisie a acestora la destinatie (fig.1).
Multiplexarea este o metodă prin care mai multe fluxuri de date pot fi transmise prin aceeasi legătură. Un beneficiu foarte important al multiplexarii reprezintă conservarea lațimii de bandă. În cazul apariției unei erori dacă unul din segmente este pierdut este retransmis doar cel in cauză (fig.2).
În momentul în care mesajul ajunge la destinație acesta este reasamblat în ordinerea corectă folosindu-se un așa numit număr de secvență (sequence number).
Clasificarea rețelelor
După mediul de transmisie rețelele pot fi împarțite în:
1. Rețele cu fir – sunt cele conectate prin intermediul cablului de cupru sau prin intermediul fibrelor optice.
2. Rețele wireless – sunt rețele fără fir în care mediul de transmisiune este aerul, spațiul geografic fiind foarte întins.
După întinderea lor geografică :
1. Rețele de tip PAN (Personal Area Network) – este o rețea compusă din echipamente electronice aflate la disțante mici ce sunt interconectate prin intermediul unui Bluetooh sau infrarosu. Exemple de dispozitive care sunt folosite în rețeaua de tip PAN sunt imprimantele, telefoanele fixe, scanere, aparate GPS, etc. Raza de acțiune a rețelelor PAN este aproximativ 6-9 metri. Rețelele PAN pot fi conectate cu magistrale USB și FireWire.
2. Rețele de tip LAN (Local Area Network) – un ansamblu de mijloace de transmisiune folosite pentru transportarea și prelucrarea informației pe distante scurte (fig.4) ele fiind bazate pe tehnologia Ethernet. Au o arie geografică restrânsă fiind întalnite în cadrul companiilor și școlilor. Oferă servicii de partajare a perifericelor din sistem, de comunicare și interacțiune între utilizatori, de posibilitate de conectare cu alte rețele.
3. Rețele de tip MAN (Metropolitan Area Network) – un ansamblu de mijloace de transmisiune folosite pentru transportarea și prelucrarea informației pe distanțe ce acoperă orașe. Aceste rețele folosesc cel mai des tehhologia fără fir (wireless) sau fibra optică pentru a crea conexiuni.
4. Rețele de tip WAN (Wide Area Network) – un ansamblu de mijloace de transmisiune folosite pentru transportarea și prelucrarea informației pe distante vaste. Interconectează rețele de tip MAN sau LAN (Fig.I.5).
Arhitectura OSI
Modelul OSI (Open Systems Interconnection) a fost creat în anul 1984 de către Organizația Internațională de Standardizare este formată dintr-o stivă de 7 nivele logice ce oferă posibilitatea de a realiza conexiuni între echipamente eletronice diferite, indiferent de particularitațile constructive ale sistemelor (fabricant, sistem de operare, țară).
Modelul OSI reprezintă soluția comunicării între două sau mai multe echipamente electronice prin împărtirea in 7 straturi distincte numite și layere fiecare nivel având funcțiile sale bine determinate (fig.I.7).
La parcurgerea fiecărui nivel informația este încapsulată adăugându-se la trecea către nivelul inferior un header specific nivelului. La cel de al 2 lea nivel cel de legătură de date pe lângă header se mai adaugă un așa numit trailer ce este folosit pentru controlul erorilor (fig I.8).
În cadrul modelului OSI informația este transmisă de sus în jos incepând cu primul nivel, nivelul aplicație până la ultimul nivel, nivelul fizic.
Nivelul Aplicatie (nivelul 7) reprezintă interfața dintre aplicațiile folosite de utilizatori și rețeaua peste care sunt transmise pachetele de date. La acest nivel întâlnim o serie de protocoale ce au scopul de a transmite/primi date între programele ce rulează pe mașinile sursă respectiv destinatie: HTTP, DNS, SMTP.
Nivelul Prezentare (nivelul 6) asigură codarea și conversia datelor precum și interpretarea corectă a acestora la destinație. De asemenea acest nivel se ocupă de problemele legate de compresia și criptarea datelor dar nu și de transferul biților in rețea.
Nivelul Sesiune (nivelul 5) inițiază și menține dialogul dintre aplicațiile sursă și destinație, restabilește sesiunea în momentul în care aceasta pică și închide conexiunile.
Nivelul Transport (nivelul 4) are rolul de a transporta informația de la un echipament electronic la altul și de a controla informația ce este transferată cu ajutorul segmentării și multiplexării. Asigură ordinea în care pachetele ajung la destinație dar prezintă și îndatoriri pentru controlul asupra erorilor.
Dacă pachetele de date ar fi trimise așa cum sunt primite de la nivelul sesiune, fară prelucrare, ar apărea congestia acestor date care ar duce la pierderea lor, astfel fiind necesară retrimiterea întregului segment de informație.
Protocoalele cele mai cunoscute de la acest nivel sunt TCP (Transmission Control Protocol) și UDP (User Datagram Protocol).
TCP (Transmission Control Protocol) – dezideratul principal al acestui protocol este transmisia corectă și în ordine a mesajelor. Principala diferență dintre TCP și UDP o reprezintă siguranța transmisiei datelor. Acest protocol prezintă 3 faze esențiale. În primă fază se verifică prezența destinatarului, după care se verifică existența serviciului respectiv la destinatar. După ce s-a verificat existența serviciului respectiv la destinatar se informează destinatarul despre intenția sursei de a stabili o conexiune pe acel port. Toți acești trei pasi poartă numele de Three Way Handshake. După stabilirea conexiunii și transferul datelor are loc terminarea conexiunii.
Există posibilitatea ca pachetele trimise într-un flux de date TCP să urmeze căi diferite către destinație, astfel ele ajungând în altă ordine decât cea de la sursă. Pentru ca ele să fie reasamblate în ordinea corectă se foloseste un așa numit număr de secvența (sequence number). Astfel destinația menține un buffer în care segmentele sunt reasamblate și apoi sunt trimise catre nivelul Aplicatie.
UDP(User Datagram Protocol) – este un protocol simplu neorientat pe conexiune ce nu dispune de mecanisme de retransmisie a datelor pierdute și sequence number, astfel intârzierile la acest protocol sunt negrijabile. Protocolul UDP este folosit pentru aplicațiile de video și voce, VoIP.
Nivelul Retea (nivelul 3) – aici are loc împachetarea și transportarea datelor provenite de la nivelul Transport. Partea de început a pachetului se numește hearder și conține adresele sursă și destinație ale pachetului. Protocolul de bază ce lucrează la nivelul 3 este Internet Protocol (IP) versiunea 4 fiind un protocol fără conexiune ce permite transmiterea unor blocuri de informație (datagrame) între emitor și receptor. Nu dispune de mecanisme ce asigură securitatea serviciului sau controlul fluxului de informație și este întotdeauna apelat de protocoalele superioare lui pentru transferul de date, fiind format din 32 de biți.(Fig.I.9)
În headerul IP există un câmp format din 8 biți numit TTL ( time to leave), adică timpul pe care un pachet îl poate consumă în rețea. Este un mecanism ce acordă pachetului o anumită valoare, valoare ce scade de fiecare dată cu unu în momentul în care trece printr – un anumit router astfel evitându -se apariția unor bucle de routare în rețea. Atunci când pachetul ajunge la un TTL egal cu valoarea 0 acesta este aruncat.
Datoriă epuizării resurselor de IPv4 ce a fost implementat la scară largă până în anul 2011 s-a realizat implementarea unui nou tip de IP (Internet Protocol) pe 128 de biți (IPv6) ce se doreste a înlocuii vechea versiune. IPv6 a fost proiectat pentru a oferi fiecărei rețele în parte mai multe adrese astfel ajungându-se de la hosturi.
Pachetele de date sunt dirijate cu ajutorul unor echipamente numite routere. Fiecare router conține o tabelă de routare, adică rute către alte rețele, ce pot fi învățate static (aceste rute statice sunt configurate de către administrator) sau pot fi învățate în mod dinamic cu ajutorul unor protocoale de routare (RIP, OSPF, EIGRP,BGP, IS-IS etc.). Aceste protocoale dinamice de routare, pot schimba între ele informații despre rețelele cunoscute. În cazul în care în rețea au loc modificări, pe masură ce routerele află de acestea informația va fi distribuită către ceilalti vecini.
Nivelul Legatură de date (nivelul 2) – se ocupă cu încapsularea pachetelor de nivel 3 în cadre de nivel 2. Adresarea se face fizic, controlul modului în care datele sunt transmise sau primite la acest nivel se face folosind Media Access Control (MAC). Media Access Control este un protocol ce este format din 12 cifre ce conține 48 de biți (exemplu: 00:11:43:A4:1C:99, 00:C0:00:BE:EE:FF).
Un cadru de nivel 2 este format din pachetul de nivelul 3 la care se adaugă un header ce conține informații despre adresa fizică sursă și destinație, și un trailer ce se găsește la sfârșit conținând un mecanism de corecție al erorilor (FCS – frame check sequence).
Printre echipamentele care lucrează la acest nivel se găsesc switch – uri, bridge – uri și plăcile de rețea (NIC) iar protocoalele care activează aici sunt Ethernet, PPP(point to point protocol) și Frame Relay. Tot la acest nivel se stabileste dacă comunicația în retea este de tip half – duplex sau full – duplex (ambele stații pot transmite și primi date în acelaș timp).
Nivelul Fizic (nivelul 1) – este conectat în mod direct cu celelalate nivele ale altor terminale ocupându-se cu transmiterea biților pe mediul de transmisie, transformându-i în semnale electrice, luminoase și electromagnetice.
Echipamentele care pot fi găsite la acest nivel sunt hub urile și cablurile. Cablurile pot fi de mai multe feluri UTP, STP, cabluri coaxiale, fibra optica.
Fibra optică: – nu este afectată de interferențele electromagnetice având un cost și o dificultate ridicată de implementare. Durata de timp până la deteriorarea unei astfel de fibre optice este de pană la 10 ani.
Retele bazate pe routere
Un router este considerat un calculator ce prezintă funcții specializate, el constituind centrul unei rețele din punct de vedere logic. Un router interconectează două sau mai multe rețele asta însemnand că fiecare interfată a routerului aparține unei rețele diferite. Interfața pe care un router trebuie să trimită un pachet reprezintă rețeaua din care adresa destinație a pachetului face parte, sau poate reprezenta calea către un alt router care cunoaște adresa destinație a pachetului, putând să se ajungă chiar într-un alt LAN (Local Area Network) sau WAN(Wide Area Network).
Principalele responsabilitați pe care un router le are este de a dirija pachetele pentru a ajunge la destinație determinând calea optimă, dar și responsabilitați secundare legate de manipulare, filtrare și modificare a pachetelor.
Primul dispozitiv ce a avut o astfel de funcționalitate (comutarea de pachete) a fost IMP (Interface Message Processor). IMP-urile sunt dispozitivele cu rol de comutare a pachetelor de date, în prima rețea aparută.Numite inițial porți (gateway), grupul de cercetători de rețele, numit INWG (International Network Working Group) a modificat denumirea în router. In figura I.10 este prezentata o astfel de retea.
1.5 Caracteristicile Routerelor
Routerele (fig.I.16) se bazează pe propria tabelă de routare pentru a determina cea mai bună cale și pentru a trimite pachetele de date către destinație. Când un router primește un pachet de date analizează adresa IP destinație uitându-se în tabela de routare pentru a vedea dacă o cunoaste. Dacă adresa destinație a fost gasită, router-ul încapsulează pachetul IP într-un frame acesta fiind trimis pe interfața respectivă către destinație. Dacă routerul nu gasește adresa destinație în propria tabelă acesta trimite pachetul de date către un alt router care la rândul lui analizează adresa destinație și verifică dacă o conține.
Routerele sunt considerate echipamente electronice de nivel 3 deoarece deciziile pe care le iau pentru a trimite pachetele mai departe sunt făcute pe baza IP-ului (Internet Protocol) dar pot participa de asemenea și în procese de nivelul 1 și 2.
Routarea statică are avantajul că prezintă o configurare simplă, ce nu necesită o putere mare de calcul din partea routerului, determinarea rutelor fiind făcute de către administrator. În cazul apariției unor defecțiuni la nivelul rețelei, dacă o rută pică aceasta rămâne inaccesibilă până în momentul în care administratorul intervine. Diferența între routarea statică și cea dinamică este aceea că în cazul rutelor statice, routerele nu schimbă între ele informații de routare ceea ce determină un mediu mult mai aerisit.
Atunci când avem de configurat o rețea de dimensiuni mici ce are doar o singură cale către destinatar, routarea statică este cea mai bună soluție deoarece prezintă un consum redus al lărgimii de bandă.
Routarea dinamica – are rolul de a descoperi cea mai bună cale către destinație, aceasta fiind apoi adăugată în tabela de routare a routerelor. Un avantaj față de routarea statică este aceea că în cazul routării dinamice, routerele interschimbă mesaje învățând de fiecare dată căi noi către destinație, astfel încat dacă o cale cedează administratorul nu mai este nevoit să acționeze imediat pentru a o repara, routerele alegând o altă cale pentru ca mesajul să fie transmis cu success.
Pentru ca routarea dinamică să poată avea loc sunt necesare folosirea anumitor protocoale dinamice de routare specializate ce au fost implementate în rețelele de calculatoare încă de la începutul anilor 80. Aceste protocoale de routare se pot clasifica în funcție de algoritmul de stabilire a informației în protocoale de tip “link state” și protocoale de tip “distance vector”.
Protocoalele de tip link-state memorează tabela de vecini ce ține evidența adiacențelor la nivelul rețelei, o tabelă a topologiei ce va memora toate rutele primite și o tabelă de routare ce menține cele mai bune căi către destinație. În acest fel protocoalele de tip link state transmit informații în intreaga rețea având o imagine de ansamblu a acesteia fiind puțin predispuse la bucle de routare cu o convergență rapidă. Un astfel de protocol de routare ce intră în categoria link-state se numește OSPF (Open Shortest Path First). Cu detalii asupra acestui protocol de routare voi reveni mai târziu.
În cadrul protocoalelor de routare de tip distance-vector routerele interschimbă între ele copi ale tabelelor de routare prin intermediul cărora ei verifică rutele deja existe, iar în cazul informațiilor noi sau a informațiilor cu o distanța administrativă mai bună decât cea existentă acestea vor fi înlocuite în tabela de routare. Prezintă o convergența greoaie având actualizări periodice în funcție de protocol.
Prezentare de tip multicast
Tipuri de transmisie ale mesajelor
Atunci când se doreste transmiterea unui mesaj la un singur echipament electronic se foloseste transmsia de tip unicast. Dacă se doreste transmiterea unui mesaj de la un singur echipament electronic către toate celelalte echipamente electronice din interiorul unei retele se va folosi transmisia de tip broadcast. În cazul în care se doreste transmiterea unui mesaj de la un echipament electronic la un număr determinat de echipamente electronice peste o rețea de nivelul 3 se va folosi transmisia de tip multicast. Acest tip de transmisie devine din ce în ce mai popular odată cu evoluția internetului fiind utilizat în transmisiile de tip audio-video, în teleconferinte sau jocurile de tip multiplayer.
Transmisia de tip unicast este folosită în comunicațiile de tip point-to-point unde ambele hosturi pot juca rolul de clienți dar și de servere în acelas timp. Astfel în transmisia pachetelor de acest tip, adresa folosită pentru trimiterea pachetului este chiar adresa destinație spre deosebire de transmisiile de tip broadcast și multicast care folosesc adrese specializate pentru a se realiza acest lucru.
Transmisia de tip broadcast are loc în momentul în care un mesaj trimis de un calculator ajunge la toate terminalele electronice din cadrul acelei rețele sau în cadrul altei rețele, acest lucru fiind posibil prin utilizarea unor adrese IP speciale. Atunci când un calculator primeste acest mesaj de tip broadcast el îl interpretează ca și cum ar fi unul de tip unicast.
Transmisiile de tip broadcast se pot face în interioriul unei rețele dar pot fi direcționate și către rețele exterioare fiind folosite de către routere pentru a schimba informații cu toate celelalte routere vecine pentru o mai bună mapare a rețelei în funcție de protocolul de routare, sau atunci când un terminal electronic trebuie să transmită informația către toate celelalte terminale electronice din cadrul rețelei respective.
Pentru ca un mesaj de tip broadcast sa fie trimis în exteriorul rețelei este necesară cunoasterea adresei rețelei respective (ex:172.16.4.0/24 unde /24 este masca de rețea a rețelei). Astfel un mesaj de tip broadcast pentru rețeaua cu adresa de 172.16.4.0 va fi 172.16.4.255 unde .255 reprezintă faptul că mesajul va trimis către toate hosturile. Pentru ca un mesaj de tip broadcast să fie trimis în interiorul unei rețele mesajul va trimis pur si simplu cu adresa 255.255.255.255.
Adresarea de tip multicast
Adresarea de tip multicast a luat naștere la sfârșitul anilor 80 în urma unui proiect în care Steve Deering a încercat transmiterea unui mesaj de la un calculator la un grup de mai multe calculatoare folosind o infracstructură a rețelei de nivel 2 si 3.
Pentru ca o transmisie de tip multicast să fie posibilă este nevoie de o infracstructură a rețelei de nivel 2 și 3(o rețea care să conțină routere si switchuri) dar și un suport din partea nivelului aplicație al stivei OSI (atât pentru destinatar cât și pentru cel ce trimite mesajul). În acest sens atât pentru echipamentul electronic sursă cât și pentru cel destinație trebuie să ruleze o aplicație de tip multicast care să trimită pachete cu adresa grupului de multicast dar și să stie să interpreteze aceste mesaje atunci când acestea ajung la destinație. O deosebire față de transmisia de tip unicast este aceea ca în multicast adresele sunt folosite pentru a indentifica grupuri de echipamente electronice. O altă diferență față de transmisia de tip unicast, în multicast aplicațiile pot utiliza ca protocol de transport doar UDP, deoarece momentan nu a fost încă creată o versiune pentru multicast a protocolului TCP. Acest lucru denotă faptul că la nivelul transport nu dispunem de un serviciu fiabil de distribuție.
Adresele multicast IPv4 prezintă o structură formată din 32 de biți ce aparțin clasei D de IP-uri multicast, fiind usor de recunoscut deoarece primi 4 biți vor fi 1110 (fig.II.3).
Pentru efectuarea unei transmisii de tip multicast este nevoie de o serie de protocoale si mecanisme specifice nivelului 3 al stivei OSI (Fig.II.4). Primul element esential pentru a se putea efectua o transmisie multicast este existenta adreselor destinație de tip multicast, destinate identificarii fiecărui grup de echipamente în parte. Un alt element esențial este posibilitatea pentru un echipament electronic de a se putea alătura sau de a putea părăsi acest grup în momentul în care acesta doreste să facă acest lucru, dar și existența unor protocoale specializate de routare multicast pentru a crea o rețea de tip arbore destinate distribuției de la sursă către destinație.
Figura 2.2 Model de transmisie multicast[3]
Scopul transmisiei de tip multicast este de a reduce traficul și a de conserva lațimea de bandă prin transmiterea unui singur șir de pachete în acelas timp către mai multe echipamente electronice terminale. Pachete de tip multicast sunt multiplicate și distribuite în interiorul rețelei de către protocolul PIM (Protocol Independent Multicast) în punctul în care fiecare pachet în parte trebuie să își urmeze propriul său drum către desținație.
Pentru ca un mesaj de tip multicast să poată ajunge la un echipament electronic acesta trebuie să facă parte neapărat din grupul de multicast, ideea transmiterii multicast bazându-se pe ideea de grup, astfel că echipamentul electronic ce dorește să primească mesajul multicast trebuie să i se alăture grupului folosind protocolul IGMP (Internet Group Management Protocol). Despre acest protocol se va vorbi mai pe larg în capitolul urmator.
IANA (Internet Assigned Numbers Authority) este instituția ce controlează transmiterea de adrese IP în lume astfel că pentru transimia de tip multicast aceasta a oferit o clasă de IP-uri numită clasa D ce va conține toate adresele destinație multicast în domeniul de valori 244.0.0.0 – 239.255.255.255. În acest sens fiecare grup de echipamente electronice trebuie să fie identificat de o adresă din cadrul clasei D, adrese ce pot fi folosite doar pentru transmiterea către destinație. În cadrul acestui segment de valori, exista un grup de valori cuprins între 244.0.0.0 – 244.0.0.255 ce se numesc adrese locale rezervate fiind folosite de către protocoalele de retea în scopul de a transmite informații pentru o mai bună cunoastere a rețelei. În interiorul unei rețele locale aceste pachete de tip multicast sunt trimise dispunând de un TTL (timpul după care unui pachet i se va da drop pentru a nu se creea bucle de routare) egal cu 1. În acest scop voi enumara câteva adrese IP folosite de către protocoale pentru o mai bună cunoastere și convergență a rețelei:
244.0.0.5 – utilizat de protocolul de routare OSPF pentru transmiterea de mesaje Hello pe un segment de retea.
244.0.0.6 – utilizat de protocolul de routare OSPF pentru transmiterea informației de routare.
244.0.0.9 – utilizat de protocolul de routare RIPv2 pentru transmiterea informației de routare RIPv2.
244.0.0.10 – utilizat de protocolul de routare EIGRP pentru transmiterea informației de routare.
Pentru ca o comunicație de tip multicast să poată fi facută cu succes între diferite organizații ce dispun de locații geografice diferite, IANA a pus la dispoziție un set de adrese globale cuprinse în domeniul de valori 244.0.1.0 – 238.255.255.255, unele dintre acestea fiind folosite strict de către aplicațiile multicast.
PIM (Protocol Independent Multicast) este un protocol de nivel 3 multicast, ce se ocupă cu multiplicarea pachetelor în punctul în care transmiterea acestora către destinație urmează să aibe loc. Astfel în ajutorul acestui protocol, ca o extensie, a fost creat un nou protocol numit SSM (Source Specific Multicast). Acesta dispune de un set de valori în domeniul 232.0.0.0 – 232.255.255.255 și are rolul de a opri traficul care nu se mai doreste a fi primit în cazul în care adresa sursă devine compromisă.
Pentru organizațiile de dimensiuni mari ce dispun de un număr mare de routere aflate sub o administrare comună și o politică comună (toate aceste reguli împreună cu routerele formează un Sistem Autonom) a fost conceput un set de adrese multicast numite adrese de tip GLOP. GLOP a fost conceput în scopul de a oferi fiecărei organizații folosirea a 255 de adrese multicast proprii, unice la nivel global. Adresele de tip GLOP sunt foarte usor de recunoscut deoarece primi 8 biti din adresa IP vor avea valoarea 233 fiind urmați întotdeauna de următorii 16 biți ce reprezintă practic indentitatea fiecărui sistem autonom în parte. Ultimii 8 biti ai acestor adrese de tip GLOP sunt folosiți pentru obținerea a 255 adrese multicast ce vor fi rutabile la nivel global.
Adresele de tip privat sunt folosite după cum spune și numele, într-un domeniu privat de administrare, încadrându-se în domeniul de valori 239.0.0.0 – 239.255.255.255. Pachetele IP ce folosesc acest segment de valori au nevoie de o administrare privată, direcționarea acestora fiind interzisă într-o rețea publică.
Pentru ca adresele multicast enumerate mai sus să poata fi routate, routerele de tip multicast folosesc o topologie de tip arbore de distribuție, arbori ce pot fi de 2 feluri: arbori de tip sursă (source tree) și arbori partajați (shared tree).
Cea mai simplă topologie de folosit este topologia de tip sursă SBT (Source Based Tree) în care echipamentul sursă reprezintă rădacina arborelui (baza arborelui) de la care pornesc ramificațiile prin rețea către toate destinațiile, astfel creeându-se crengile acestui arbore. Acest mod de distribuție este cunoscut ca fiind topologia ce utilizează căile cele mai scurte către destinație. Pentru ca echipamentele sursă să fie identificate, în mod unic în cazul în care 2 sau mai multe echipamente sursa transmit către acelaș grup de multicast se va folosi notatia: S (source) pentru sursa și G (group) pentru destinație, astfel că dacă 2 echipamente transmit către acelas grup acestea vor fi notate cu S1 respectiv S2.
Tipul de distribuție sursă, are avantajul că întotdeauna va alege calea optimă, cea mai scurtă între sursă și destinație lucru ce determină întârzieri foarte mici în cadrul rețelei. Acest lucru însă determină routerele să interschimbe mereu mesaje între ele, pentru o mai bună cunoaștere a rețelei
(astfel alegându-se calea cea mai optimă către destinație). Prezinta însă un dezavantaj în cadrul unei rețele de dimensiuni mari, deoarece tabelele de routare vor avea dimensiuni considerabile și vor ocupa toată memoria acestora.
Arborii de tip partajat SDP (Shared Distribution Tree) spre deosebire de arborii de tip sursă (prezintă la radacină o sursă), folosesc o singură sursă comună pentru mai multe grupuri de multicast a carei locație este bine aleasă, acesta locație purtând numele de RP (Rendezvous Point). Mesajul trimis de la sursă către RP este de tip unidirectional astfel că pana în punctul RP – ului transmisia va folosi o distribuție de tip sursă, iar de la RP către destinație adresarea de tip partajat va avea loc.
Adresarea de tip partajat spre deosebire de cea sursa, nu alege calea cea mai scurtă către destinație astfel interschimbarea mesajelor între routere nu este necasară, fapt ce determina o tabelă de routare de dimensiuni mici. Însă dezavantajul acestui tip de distribuție multicast este ca transmiterea unui mesaj între sursă și destinație poate deveni suboptimal.
După cum s-a arătat mai sus, în cazul transmisiei de tip unicast este necesară cunoasterea decât a adresei destinație pentru a transmite pachetul, în acest sens se creează o singură copie a pachetului. În cadrul transmisiei de tip multicast traficul trebuie să fie direcționat către mai multe echipamente destinație acestea fiind determinate de grupuri de multicast. În acest sens, routerele de tip multicast trebuie să determine sensul către sursă și receptori și în cazul în care există mai multe echipamente destinație mesajul va fi multiplicat de cate ori este nevoie și va trimis pe interfețele respective.
RFC (Rever Path Forwarding) este un mecanism cu ajutorul căruia routerele nu pot transmite informația pe căile de distribuție ale arborelui în mod eronat. Acest lucru se face prin intermediul tabelei de routare unicast folosite pentru a determina sensul către sursă și către destinație. Atunci când un router primeste un pachet de tip multicast pe interfața corespunzătoare sensului către sursă acesta îi caută adresa sursă a pachetului în tabela de routare unicast pentru a verifica dacă pachetul de date a fost primit pe interfața ce este determinată de cel mai scurt drum către sursă, numai în acest caz el distribuind pachetul mai departe, în cazul în care pachetul este primit pe o altă interfață i se dă drop. Acest mecanism se numeste RPF check și este folosit pentru a se evita apariția buclelor de routare din cadrul unui arbore de distributie.
Mecanismul prin care un echipament electronic poate informa un router că doreste să facă parte din structura unui grup de multicast, sau că doreste sa îl părăsească, poarta numele de IGMP (Internet Group Management Protocol). IGMP este un protocol ce ajută la crearea de grupuri multicast ce pot fi formate din routere sau echipamente electronice terminale. De asemenea poate fi folosit în aplicații de transmisi audio-video, teleconferițe, jocuri, prin intermediul căruia utilizarea lațimii de bandă poate fi conservată cu succes.
Protocolul IGMP (Internet Group Management Protocol)
Necesitatea protocolului
Odata cu evoluția internetului din 1974 și până în prezent, routarea de tip multicast a evoluat considerabil de la începuturile sale până la aplicațiile comerciale din ziua de azi. În prezent multe companii folosesc Internet Group Management Protocol pentru transmia pachetelor multicast peste diferite medii de transmisie, fiind folosit în special pentru transmisiile de tip audio-video, teleconferințe, jocuri, aplicații ce necesită transmiterea informației de la un calculator la un grup ales de mai multe calculatoare.
Protocolul IGMP permite echipamentelor electronice terminale să comunice dorința de a primii și de a transmite informația de la un grup de mai multe echipamente electronice alese. Acest lucru se realizează trimțând informația către routerul de multicast care apoi are sarcina de a construi pe baza acestor mesaje, arborele de distribuție al retelei. În prezent există 3 versiunii ale protocolului IGMP ce sunt îmbunătățite din ce în ce mai mult odata cu evoluția acestora, cea mai folosită și bine realizată versiune fiind versiunea 2.
IGMPv1
Prima versiune a protocolului IGMP reprezintă versiunea de bază fiind testată și implementată la începuturile sale pe o varietate largă de sisteme de operare cum ar fi Unix, sau Windows 95. Fiind o versiune învechita, IGMPv1 nu mai este folosit în ziua de azi, însa el reprezinta baza evolutiei urmatoarei versiunii de IGMP, IGMPv2, versiune ce este folosită la scară largă în rețelele multicast ce rulează peste protocolul IP (adica nivelul 2 al stivei OSI).
Prima versiune a acestui protocol este una relativ simplă, usor de înteles având 2 tipuri esențiale de mesaje ce sunt transmise între routerele de tip multicast și echipamentele electronice terminale : mesaje pentru verificarea echipamentelor electronice din cadrul unui grup de multicast (host membership query) și mesaje de raport pentru un grup de multicast (host membership report). În acest sens pentru o mai bună ințelege a funcționării acestui tip de protocol, voi prezenta structura unui mesaj IGMPv1 împreuna cu toate câmpurile sale :
Figura 3.1 Structura mesaj IGMPv1[6]
IGMP Checksum – este un câmp ce este destinat pentru a verifica integritatea unui mesaj, fiind setat initial cu valoarea 0.
Unused – acest câmp primeste valoarea 0 atunci când un pachet de tip IGMP este trimis, și ignorat când este primit.
Pentru ca aceste mesaje să poată fi transmise cu succes este necesară existența unor echipamente electronice ce se pot alătura unui grup, sau îl pot părăsi :
Procesul de înregistrare la un grup de multicast – are loc când un echipament electronic doreste să se alature unui grup de multicast acesta trimițând un mesaj de tip report, mesaj ce adesea are rolul unui mesaj de tip join. Acest mesaj este transmis cu un TTL = 1, adică acestui mesaj îi este permis să treacă decât printr-un singur router după care i se va da drop. Prin folosirea acestui TTL (time to leave) se evită apariția asa numitelor bucle de routare (un mesaj este trimis la infinit în cadrul unei rețele), lucru ce este foarte folositor in păstrarea lațimii de bandă la un nivel redus.
Figura 3.2 Alaturarea unui calculator la un grup multicast[3]
Host membership query – un router multicast ce foloseste IGMPv1 trimite în mod periodic mesaje către toate echipamentele electronice cu adresa 224.0.0.1 pentru a-și împrospăta cunostințele despre membrii grupului de multicast ce folosesc aceeas mască, intervalul de timp în care aceste mesaje pot fi trimise fiind între 60 – 90 secunde. Dintr-un grup de multicast, un echipament electronic trebuie să trimită un mesaj de tip raport pentru a inștiința routerul de existența acestora. După recepționarea acestui mesaj grupul din tabela de evidență al protocolului IGMP reîmprospătează timpul după care un mesaj expira, astfel grupul de echipamente electronice rămân în tabela de multicast. În cazul în care nici unul din echipamentele electronice nu răspunde, grupul de multicast este înlăturat din tabela de multicast a IGMP ului.
Procesul de părăsire – .un dezavantaj al acestei prime versiuni de IGMP este că un echipament electronic ce face parte dintr-un grup de multicast poate părăsi acest grup oricând doreste fără a anunța acest lucru. Astfel routerul în urma trimiterii a 3 mesaje de tip query dăcă nici unul din echipamentele electronice terminale nu răspund cu un mesaj de tip report, acesta stia de intenția echipamentelor terminale de a nu mai primii streamul de pachete multicast. În acest sens unui router îi erau necesare 90 de secunde pentru a concluziona acest lucru, fapt ce făcea funcționarea acestui protocol una foarte greoaie.
IGMPv2
Cea de a 2 a versiune a protocolului IGMP prezintă o îmbunătățire substanțială față de prima versiune, fiind folosită într-o proporție destul de mare în implimentările industriale sau ale companiilor, îmbunătățire ce constă în faptul că, un echipament electronic înstiințează routerul de intenția sa de a părasi grupul de multicast.
Spre deosebire de prima versiune în care routerul care trimitea mesajele de tip query era ales de protocoalele de routare multicast, în IGMPv2 routerul care trimite mesaje de tip query este ales în funcție de adresa sa IP. Routerul cu cea mai mică adresă IP ca valoare este aleasă pentru a trimite mesajele de query, acest lucru făcându-se de către toate routerele din segmentul respectiv de rețea. În cazul în care routerul primeste un mesaj de tip query cu o adresa IP mai mică decat adresa routerului, acesta nu mai poate trimite pachete de tip query.
Versiunea a 2 a IGMP ului ca și prima versiune folosește aceleas tipuri de mesaje : mesaje pentru verificarea echipamentelor electronice din cadrul unui grup de multicast (host membership query) și mesaje de raport pentru un grup de multicast (host membership report) dar cu îmbunătățiri destul de mici. Toate mesajele pe care acest protocol le foloseste dispun de un TTL egal cu 1, folosit cu scopul de a evita apariția buclelor de routare.
Deoarece este o versiune importantă a acestui protocol pentru o usoară înțelegere a mecanismului de trasmitere a mesajelor, voi prezenta structura unui mesaj de tip IGMPv2 :
Figura 3.3 Structura unui mesaj IGMPv2[4]
Type – este un câmp ce are rolul de a codifica diferitele tipuri de mesaje IGMP. Astfel :
Memebership Query – acest tip de mesaj este folosit de către router cu scopul de a verifica existența unor echipamente electronice destinație, fiind de 2 feluri : General Membership Query și Group Specific Query.
Membership Report – este folosit de către echipamentele electronice destinatare având scopul de a anunța routerul că exista cel puțin un destinatar activ pe acel segment de rețea.
Leave Group – este folosit de către un echipament electronic ce nu mai doreste să primească trafic de la un router.
IGMP Checksum – este un câmp destinat verificării integritații unui mesaj, fiind setat cu valoarea 0.
MRT (Maximum Response Time) – are scopul de a optimiza procesul pentru înregistrarea la un grup de multicast fiind cuprins într-un segment de valori între 0.1 și 25.5. secunde. Scopul său este de a limita timpul de transmisie al mesajlor de tip report dupa ce mesajele de tip query au fost primite. Acest camp își exprimă valorile în ordinul zecilor, adică o valoarea de 40 va însemna 4 secunde. Astfel mesajul query de tip General Membership Query va avea o valoare de 100 adică 10 secunde.
Group Adress – reprezintă poate cel mai important câmp al mesajelor de tip IGMP fiind setat în funcție de tipul mesajului query transmis la diferite valori. Un exemplu de luat în considerare este un mesaj de tip General Membership Query ce va fi setat cu valoarea 0.0.0.0 și își propune să descopere un echipament electronic din orice grup de multicast.
Asa cum am spus și pentru prima versiune a acestui protocol și în IGMPv2 pentru a adera la un grup de tip multicast sau pentru a îl părăsi este necesară desfasurarea unui întreg proces destul de amplu. În acest sens :
Mesajele de tip query – pentru procesul de înregistrare la un grup de multicast la fel ca la prima versiune și în IGMP v2 sunt folosite aceleaș mesaje generale de tip query și report pentru ca un echipament electronic să poata fi înregistrat la un grup de multicast. În acest sens o aplicație de tip multicast trebuie să fie pornită pe echipamentele electronice terminale, după care administratorul de rețea trebuie să configureze o adresă IP de multicast care va rula atât pentru echipamentele terminale cât și pentru serverul aplicației. Odată făcut acest lucru, routerul de multicast va trimite la un interval de 60 de secunde mesaje de tip query pe tot segmentul de retea la care este conectat cu adresa destinație a grupului de multicast pentru a verifica existenta echipamentelor terminale dispunând ca și în prima versiune de TTL = 1 (amintim că adresa 224.0.0.1 este folosită pentru transmisia unui mesaj către toate echipamentele din cadrul grupului de multicast).
Mesajele de tip report – acest tip de mesaj este folosit de către echipamentele destinație pentru a transmite routerului intenția acestora de a primi trafic de tip multicast, mesaje ce se împart în două categorii :
Mesaje solicitate de tipul report – este trimis în urma recepționării unui mesaj de tip query cu intenția de a trasmite routerului dorința de a face parte dintr-un anumit grup de multicast. Acest lucru este posibil prin inserarea în câmpul Group Adress al mesajelor de tip IGMP adresa destinatie a grupului de multicast dorit.
O problemă intâlnită în cadrul acestui tip de mesaje solicitate report este aceea ca în cazul în care routerul folosește un mesaj general de tip query (mesaje destinate transmiterii tuturor membrilor unui grup de multicast, sau către orice grup cu care exista o conexiune) toate echipamentele terminale au intenția să răspundă odată la 60 de secunde cu mesaje de tip report. Să presupunem ca în cadrul unei rețele există 100 de echipamente electronice terminale, dacă toate aceste echipamente ar răspunde cu câte un mesaj de tip report, rețeaua s-ar încărca în mod dramatic astfel routerul nu va mai putea sa față solicitărilor. În acest sens indiferent de numărul de echipamente terminale fie ca sunt 100 fie că este doar unul singur, routerul nu are nevoie decât de un singur mesaj pentru a putea trimite un stream de informatie. Astfel pentru ca acestă problemă să fie rezolvată în interiorul mesajelor generale de tip query a fost introdus câmpul MRT care are scopul de a optimiza procesul de înregistrare la un grup de multicast.
În momentul în care un echipament destinație receptionează un mesaj de tip query, acesta extrage o valoare aleatoare exprimată în secunde din campul MRT dupa care o încapsulează într-un alt câmp numit RT (Response Time). În acest sens se evită trimiterea mesajelor de report prin pornirea unui timer care în momentul în care va expira va transmite mesajul de tip report, asigurând astfel o transmisie cât de cât uniformă a acestora. Stația care are cel mai mic RT, va trimite un mesaj de tip report către router și către toate echipamentele terminale vecine având câmpul Group Adress setat cu valorea adresei de multicast și cu adresa destinație de aceeas valoarea cu cea a grupui. În momentul în care toate celelalte echipamente terminale vecine vor primii reportul, acestea vor renunța la ideea de a trimite un alt mesaj report, în acest sens considerând că un singur mesaj este suficient. Acest comportament se numeste RS (Report Supression).
Figura 3.4 Calculul timpului de răspuns[4]
Mesaje nesolicitate de tip report – există aplicații ce pot fi configurate de către administrator să primească trafic de tip multicast. Pot exista aplicații ce asteaptă mesajele de tip query de la router însă pot exista și aplicații care vor trimite aceste mesaje nesolicatate doarece doresc să adere într – un timp cât mai scurt la grupul de multicast
Procesul de părăsire al unui grup de multicast – așa cum am spus la începutul prezentării protocolului IGMPv2 acesta prezinta o mare îmbunătățire față de prima versiune a aceluiaș protocol datorită faptului că un echipament electronic anunță routerul de intenția sa de a părăsi grupul.
Astfel în funcționarea IGMPv2 a fost inclusă transmiterea unor mesaje de tip Leave Group prin care o stație își poate arăta intenția de a părăsi un grup de multicast. În urma implementării acestor mesaje routerul poate determina dacă într-un grup de multicast mai este cineva care doreste să primească streamul de date în doar 3 secunde spre deosebire de prima versiune a protocolului în care erau necesare 90 de secunde pentru a determina acest lucru.
Pentru o funcționare atât de rapidă a mai fost introdus un tip de mesaje Group Specific Query cu ajutorul căruia un router poate interoga un anumit segment de rețea pentru a vedea câți destinatari mai există în grupul respectiv. În cele ce urmează voi prezenta o topologie a unei rețele pentru o înțelegere cât mai usoară a funcționării acestui proces de părăsire al grupului :
Figura 3.5 Procesul de parasire al unui grup multicast[4]
Astfel echipamentele electronice A1 respectiv A2 fac parte din grupul multicast 227.1.1.1. Echipamentul electronic A1 doreste să părăsească acest grup de multicast și trimite un mesaj de tipul Leave Group cu adresa 224.0.0.2, adresă destinată trimiterii mesajului către toate routerele din cadrul acelei rețele în timp ce echipamentul A2 doreste în continuare să primească trafic multicast. Routerul R1 ce este responsabil pentru acest grup de multicast va trimite un mesaj de tipul Group Specific Query setat cu valorea grupului de multicast 227.1.1.1 pentru a putea determina dacă mai există cineva ce doreste în continuare să primească stream de pachete multicast. În acest sens A2 va trimite un mesaj de tip Membership Report pentru a-și anunța intenția. Astfel routerul va aplica un algoritm prin intermediul căruia acesta va concluziona dacă înca există cineva în grup care încă doreste să primească trafic multicast. Acest algoritm este determinat de 2 constante :
Last Member Query Interval – reprezintă o valoare de timp ce va fi egală cu valoarea câmpului MRT descrisă anterior (valoarea câmpului MRT va avea valoarea de o secunda)
Last Member Query Count – reprezintă un număr întreg pozitiv folosit de către algoritm a cărui valoare este egala cu 2.
Routerul în momentul în care va primi un mesaj de tipul Leave va trimite la randul său în mod automat un mesaj de tip Group Specific Query. Dacă nu va primi un mesaj de tip Report definit de intervalul Last Member Query va trimite în continuare mesaje Group Specific Query și va astepta întervalul Last Member Query pentru fiecare query ce este definit de variabila Last Member Query Count. Algoritmul definit este de determinat de un pseudocod:
Figura 3.6 Algoritm pentru părăsirea unui grup multicast[4]
IGMPv3
IGMPv3 reprezintă ultima versiune a acestui protocol fiind caracterizată de “filtrarea sursa“ ce este realizată prin intermediul routerelor, însă acest protocol la ora actuala este în curs de dezvolatare, doar ultimele versiuni de Windows, Macintosh și Unix suportă acest standard. Filtrarea sursa se referă la faptul că un echipament electronic terminal își poate alege sursa de la care dorește să primeasca trafic multicast. Acest lucru ajută foarte mult la consevarea lațimii de bandă deoarece routerul știe în mod explicit către ce echipamente terminale trebuie trimis traficul, filtrarea putând fi facută în 2 moduri :
Prin trimiterea unei liste (lista de IP-uri inclusă) către router prin care anunță de la ce adrese IP dorește sa primească trafic multicast.
Prin trimiterea unei liste (lista de IP-uri exclusă) către router prin care anunță de la ce adrese IP nu dorește să primească trafic multicast. Prin intermediul acestei liste receptorul practic anunță ca el dorește să primească trafic multicast de la toate celelalte hosturi în afară de cele ce se afla în lista exclusa. În cazul în care receptorul doreste să primeasca trafic de la toate hosturile din rețea acesta trimite către router o listă exclusă în care nu se află nici un fel de informație, practic o listă goală.
În urma acestor filtrări ca și ăn versiunile precedente routerul trimite mesaje de tip query pentru a determina dacă mai există cineva în cadrul grupului de multicast care doreste să primească trafic. Pot fi incluse în cadrul acestui mesaj adresa IP al receptorului (S) către care este destinat traficul sau adresa grupului de multicast (G). Receptorul răspunde cu mesaje de tip report ce poate conține unul din urmatoarele tipuri de înregistrări :
Înregistrari despre starea actuală ce poate indica de la ce echipament sursa traficul poate fi primit sau nu. Înregistrarea poate conține adresa sursă ce poate face parte din lista inclusă (IS_IN) sau din lista exclusa (IN_EX).
Înregistrări ce indică schimbarea modului de filtrare – sursa doreste să transfere anumite adrese IP din lista inclusă în lista exclusă.
Înregistrări ce indică adăugarea unor noi adrese IP de la care se doreste primirea traficului multicast.
Compatibilitatea cu prima și a 2 a versiune – orice grup de multicast sau router poate folosi oricare din cele 3 versiuni ale IGMP-ului. Aceste versiuni pot fi usor recunoscute prin intermediul mesajelor de tip report sau query ce sunt trimise în cadrul unei rețele de către router sau de către echipamentele terminale. O problemă ce apare în cadrul acestui protocol este aceea că spre exemplu un router ce este configurat cu versiunea a 2 a a IGMP-ului poate recunoaste usor mesajele de tip report sau query ale celei de a 3 a versiuni însă nu le poate procesa. De asemenea un router configurat cu cea de a 3 a versiune a IGMP ului poate trimite mesaje de tip query către un router configurat cu a 2 a versiune însa echipamentele terminale din cadrul versiunii a 2 a nu le poate procesa emitând mesaje de eroare.
Acestă problemă de operabilitate între versiuni poate fi rezolvată setând pe fiecare interfață a routerelor versiunea ce se doreste a rula, lucru ce va fi demonstrat practic in ultimul capitol.
Mesajele de tipul IGMP versiunea 3 sunt încapsulate în datagrame ale versiunii 4 a IP – ului dispunând de un TTL egal cu valoarea 1.
Figura 3.7Formatul unui mesaj IGMPv3[5]
Maximum response code – acest câmp specifică timpul maxim ce îi este permis unui echipament electronic terminal pentru a trimite un mesaj de tip report.
Group adress – atunci când un mesaj de tip General Query este trimis acesta este inițializat cu valoarea 0 fiind setat cu adresa destinație a grupului de multicast atunci când este trimis.
QQIC – este un câmp ce specifică intervalul de timp în care mesajele query pot fi trimise.
Campul N – specifica câte adrese sursa sunt prezente într-un mesaj de tip query.
IGMP Snooping
IGMP Snooping a fost conceput pentru a transmite traficului multicast peste echipamente de Nivel 2 (switch – uri). Rolul snooping ului este de a examina informațiile ce vin din partea routerelor, mesaje de join/părăsire a grupurilor de multicast către echipamentele electronice terminale ale grupurilor de multicast. Astfel switchurile ce sunt conectate în mod direct cu echipamentele terminale vor adăuga în componența mesajului trimis de către routere portul către destinația finală a mesajului. În acest sens dacă consideram o rețea ce dispune de un număr mare de echipamente terminale traficul ar fi trimis de către switchuri pe toate porturile disponibile încărcând foarte mult lațimea de bandă, performanța rețelei scăzând în mod consistent.
Vom considera o topologie ce conține în centrul rețelei un router pentru a trimite traficul între toate echipamentele terminale ale retelei :
Figura 3.8 IGMP Snooping 1[7]
Să presupunem că echipamentul electronic A dorește să transmită traffic multicast către echipamentele B și C. Astfel routerul va trimite traficul către switchurile ce leagă echipamentele B și C însă acesta în cazul în care nu are configurat IGMP Snooping va transmite traficul pe toate porturile disponibile încarcand în mod consistent rețeaua. După cum am spus mai sus cu cât rețeaua este mai mare cu atât mai mult transmiterea pachetelor va genera o încărcare foarte mare a acesteia. Însa în cazul în care IGMP Snooping este configurat pe switchurile respective acestea vor trimite traficul doar pe porturile ce necesita acest lucru.
Figura 3.9 IGMP Snooping 2[7]
Testarea IGMP (Internet Group Management Protocol)
Introducere în IxNetwork
IxNetwork este un program dezvoltat de către compania Ixia cu rolul de a testa modul de funcționare al routerelor și switchurilor supuse unor viteze de transmisie mari. Poate fi utilizat folosind modulele de testare Port-CPU dezvoltate de Ixia, module ce pot susține un PowerPC pe care rulează sistemul de operare Windows împreună cu o varietate de protocoale.
IxNetwork dispune de o interfață grafica ( GUI ) destul de usor de utilizat pentru configurarea și testarea diferitelor echipamente electronice. Fiind utilizat împreună cu șasiurile dezvoltate de către Ixia și port-CPU, IxNetwork poate fi utilizat pentru crearea unui mediu de test, mediu configurat și dezvoltat de către cerințele noastre.
Ofera posibilitatea de a utiliza un număr foarte mare de hosturi și routere dar și posibilitatea de a realiza milioane de fluxuri de trafic pentru a evidentia performanțele rețelei.
În continuare voi încerca să fac o prezentare a programului în funcție de cele mai importante secțiuni ale acestuia.
GUI Framework
IxNetwork dispune de o fereastră principală care este compusă din sub-ferestre destinate configurării porturilor supuse testului, configurării protocolului ce se doreste a fi testat dar și configurarea și generarea traficului pentru cel de al 2 lea și al 3 lea nivel al stivei OSI. De asemenea avem opțiunea de a vizualiza în acelaș timp statisticile traficului în urma generării acestuia dar și informații despre modul în care protocolul supus testului s-a comportat. Un exemplu de GUI va fi prezentat în imaginea urmatoare:
Figura 4.1 Interfața grafică IxNetwork
Enhanced Port Managament
Port Management este o casetă de dialog ce permite adăugarea de porturi fizice pentru a fi configurate anterior. Configurarea protocolului destinat testării se va face explicit pe aceste porturi, configurări ce pot fi salvate și rulate ori de câte ori se doreste acest lucru.
Enhanced Protocol Configuration
IxNetwork este o aplicație ce are scopul de a emula diferite topologii de rutare și de a simula o mare varietate de protocoale de routare. În acest sens Protocol Wizards ne permite să creăm și să setăm foarte rapid o topologie destul de complexă, prin urmarirea unui proces ce se realizează pas cu pas. Fereastra destinată configurării protocoalelor permite editarea și vizualizarea configurărilor pentru multiplele porturi supuse testării dar și copierea setărilor și adăugarea acestora către alte porturi în cazul în care se dorește ca rețeaua să fie extinsă.
Figura 4.3 Exemplu Multicast Wizard
Traffic Wizard
Această fereastră este destinată creării a milioane de fluxuri de trafic, trafic ce poate fi configurat pentru o traversare a rețelei în ambele sensuri ( full duplex ) și poate dispune de o încapsulare a pachetelor de acelaș tip. Poate fi determinat tipul de trafic ce se doreste a fi trimis IPv4 sau IPv6, de la un host la altul ( trafic de tip unicast ) sau de la un host către mai multe hosturi (trafic de tip multicast).
Figura 4.4 Exemplu Traffic Wizard
Evaluarea protocolului multicast IGMP
IxNetwork este o aplicație de tip client ce poate funcționa utilizând unul sau mai multe șasiuri dezvoltate de către compania IXIA ce dispun la rândul lor de aplicația IxServer. Pentru a putea realiza efectuarea testelor asupra protocolului IGMP au fost necesare urmatoarele elemente fizice:
Utilizarea unui șasiu Ixia ce dispune de module Ethernet.
Utilizarea a 2 porturi disponibile aflate pe șasiu.
Un router de tip CISCO.
Un laptop pe care sa poată rula IxNetwork.
Cabluri de conectare.
După dobândirea acestor elemente fizice, a fost necesară configurarea atât a aplicației IxNetwork cât și a routerului ce a fost supus testului :
Conectarea și selectarea porturilor
Configurarea protocolului IGMP
Verificarea conectivatății
Configurarea protocolului de routare EIGRP
Configurarea și generarea traficului
Configurarea echipamentelor
Înainte de a începe configurarea setărilor în aplicația IxNetwork a fost necesară realizarea legăturilor fizice între laptop, șasiu și router. Realizarea conexiuni între laptop și șasiul Ixia a fost făcută printr-un port de management iar între router și șasiul prin intermediul a 2 cabluri de tip straight.
Figura 4.5 Structura echipamentelor utilizate
Configurarea routerului CISCO ( DUT – Device Under Test )
În scopul realizării testelor a fost utilizat un router de tipul Cisco prin intermediul căruia au fost realizate configurări pentru pornirea traficului de tip multicast, schimbarea versiunii de IGMP (routerele de tip Cisco vin din fabrică configurate cu IGMP version 1 astfel fiind necesară doar schimbarea versiunii pentru testarea tuturor celor 3 versiuni). În urma activării traficului de tip multicast s-a configurat un protocol de routare EIGRP pentru interschimbarea cu succes a pachetelor. Conexiunea dintre laptop și router a fost facută printr-un cablu de tip RJ45-USB, configurarea routerului fiind făcută prin intermediul aplicației PuTTy.
#ip multicast-routing – prin intermediul acestei comenzi a fost activată funcționarea traficului de tip multicast pe routerul respectiv, fără această comandă fiind imposibilă realizarea acestor teste.
Figura 4.6 Configurarea Routerului part 1
#conf terminal
#interface fastEthernet 0/0
#ip address 192.168.10.1 255.255.255.0
#no sh
#interface fastEthernet 0/1
#ip address 172.16.20.2 255.255.255.0
#no sh
Prin intermediul acestor comenzi am adaugat adresa IP 192.168.10.1 pe interfața fa0/0. Ip-ul v-a fi folosit ulterior ca gateway pentru una din interfețele emulate la Ixia cu scopul de a stabili comunicația între hosturile ce apartin celor 2 interfete. Comanda no sh a fost utilizată pentru a menține starea interfeței fa0/0 activă, după cum ne sugerează ultimele 4 randuri ale imaginii de mai sus. Acelaș lucru se poate spune și pentru interfașa fa0/1 ce utilizează adresa IP 172.16.20.2.
Figura 4.7 Configurarea Routerului part 2
Aceste comenzi au fost necesare configurării unui protocol de routare EIGRP necesar transmiterii cu succes a pachetelor de date.
După configurarea protocolului de routare EIGRP este necesară configurarea unei adrese pentru Rendez-vous Point fiind necesara restului de routere emulate de sasiul Ixia.
#ip pim rp-address 192.168.10.1
Selectarea porturilor Ixia
Figura 4.8 Exemplu selectare porturi Ixia
În scopul selectării porturilor, din fereastra numită Port Manager a fost necesară selectarea și adăugarea porturilor active ( culoarea verde evidențiază acest lucru ) prin apăsarea unui click pe butonul “Add Ports“. În urma acestei acțiuni porturile active vor apărea în fereastra “Port Selection“ ca în figura de mai sus.
Figura 4.9 Verificarea functionalitații porturilor
Ultima imagine evidențiază faptul că porturile au fost adăugate cu succes și ca acestea sunt funcționale.
Configurarea protocolului IGMP
Pentru adăugarea protocolului este necesară apăsarea unui click pe “Add Protocols“ în urma căreia va apărea imaginea urmatoare ‘Protocols WIzards’.
Figura 4.10 Exemplu configurare protocol IGMP 1
În urma apariției acestei ferestre putem observa diversitatea de protocoale ce pot fi utilizate. Pentru a putea folosi protocolul IGMP se merge la secțiunea numită “Multicast“ unde vom bifa casuțele pentru IGMP.
Figura 4.11 Selectare protocolului IGMP
Următorul pas pentru o realizare corectă a configurărilor este selectarea opțiunii “Protocol Interfaces“. Ne interesează configurarea doar a interfețelor direct conectate “Connected Interfaces“ fereastră în care se pot observa mai multe câmpuri ce trebuiesc configurate :
“Port Description“ – conține interfețele ce se doresc a fi configurate.
“Port Link“ – dezvăluie starea în care se află interfețele în momentul respectiv activă/inactivă (verde/rosu).
“Interface Description’ – util identificării mai usoare a interfețelor.
“Enable“ – putem specifica ce host dorim să folosim.
“IPv4 Address“ – reprezintă adresa IP a fiecărui host în parte.
“Gateway“ – adresa prin intermediul căreia pachetele sunt trimise în exteriorul interfeței respective.
Figura 4.12 Exemplu configurare interfețe IGMP
Dupa ce interfețele au fost configurate corect, urmează configurarea protocolului IGMP. Dupa cum se poate vedea în desenul de mai jos observăm că nu se declară utilizarea hosturilor ci a grupurilor de multicast ce îi sunt atasate routerului.
Figura 4.13 Configurarea protocolului IGMP 2
Un prim pas important în configurarea IGMP-ului este asignarea unei interfețe de protocol prin bifarea casutei de ‘Enable’ și specificarea grupurilor de multicast pentru fiecare interfață în parte. Tot aici poate fi specificată versiunea de IGMP ce se dorește a fi rulată. Pentru lucrarea de față vor fi efectuate testele pentru fiecare din cele 3 versiuni ale protocolului. Specificarea versiunii se va face în câmpul “Version“ însă acest lucru nu este suficient deoarece versiunea ce ruleaza în IxNetwork trebuie să fie identică cu cea care rulează pe router.
Figura 4.14 Alegerea versiunii de IGMP în cadrul IxNetwork
După configurarea ferestrei “Hosts“ urmează configurarea ferestei “Group Ranges“ în care pentru fiecare router simulat au fost asignate adrese IP destinate grupurilor de multicast. Tot aici se specifică numărul de echipamente electronice de care un grup multicast poate dispune.
Figura 4.15 Crearea grupurilor multicast
Verificarea conectivitatii pe router
#show ip igmp interfaces – comanda ajută la determinarea detaliilor IGMP de pe fiecare interfață multicast
Figura 4.16 Verificarea interfețelor IGMP
#show ip igmp groups – comanda arată apartenența grupurilor de multicast IGMP pe interfețele routerului. În printul de mai jos ne este arătat uptime-ul dar și routerul prin intermediul căruia grupul a fost raportat.
Figura 4.17 Verificarea grupurilor multicast IGMP
Verificarea conectivitatii
Un lucru esențial ce trebuie realizat pentru a fi siguri de buna funcționare a conectivitații dintre routerul și porturile Ixia este utilizarea comenzii ‘Ping’ în aplicația IxNetwork. Acest lucru se face apăsând butonul de click dreapta pe portul de unde dorim să dăm această comandă. Astfel este adăugată comanda către ce adresă se doreste efectuarea verificării conectivitații și se apasa butonul “Send“. Rezultatul comenzii este:
Figura 4.18Verificarea conectivitații router – IxNetwork
Generarea traficului
Fără generarea traficului configurările făcute în program cât și pe router sunt fără folos deoarece pentru a putea realiza statistici avem nevoie de pachete de date interschimbate între echipamentele topologiei. Astfel în sânga ecranului se va apăsa click pe butonul “Traffic“ în urma căreia ne va apărea următoarea imagine:
Figura 4.19 Generarea traficului
Apăsând click pe “Add L2-3 Traffic Items“ va apărea o fereastră ca mai jos :
Figura 4.20 Exemplu de Traffic Wizard 1
Astfel putem selecta modul în care dorim ca transmisia pachetelor să se facă: de la un host către un alt host (“One-One“), de la un grup de multicast către un alt grup de multicast (“Many – Many“). În acest fel se poate selecta foarte usor sursa/destinația prin bifarea căsuțelor din cadrul interfețelor Ethernet, configurație ce determină fiecare topologie în parte. După ce sursa/destinația a fost adaugată se apasă butonul “Next“ ce va deschide fereastra “Pachet/QoS“:
Figura 4.21 Exemplu de Traffic Wizard Editor Packet QoS
Aici nu vom bifa nimic și apăsăm butonul pentru “Next“. Noua fereastră ce va apărea se numește “Flow Group Setup“ prin intermediul căreia este creată baza de grupuri de trafic. Vom bifa căsuța “None“ ce utilizează o distribuție ce este dată de setările de bază ale programului.
Figura 4.22 Exemplu de Traffic Wizard Flow Group Setup
Apăsăm “Next“ și ne va apărea fereastra “Frame Setup“. Această fereastră permite configurarea cadrurilor (framurilor). Dimensiunea unui cadru poate varia, dimensiunea de baza fiind 64 biți. Tot de aici poate fi configurată și încărcarea cadrurilor.
Figura 4.23 Exemplu de Traffic Wizard Frame Setup
Pasul urmatorul îl reprezintă configurarea ratei de transfer ce se face din fereastra “Rate Setup“. Aici se poate selecta procentul (rata de transfer) la care se doreste ca traficul să fie trimis. Valoarea de baza este de 10% însă pe parcusul testelor aceasta a fost modificată pentru a determina cât mai multe scenarii.
Figura 4.24 Exemplu de Traffic Wizard Rate Setup
“Next“ și următoarea fereastră ce va apărea este “Flow Tracking“ din care este selectat traficul ce se dorește a fi simulat.
Figura 4.25 Exemplu de Traffic Wizard Flow Tracking
‘Next’ si fereastra ‘Preview’ se va deschide. Aici putem vedea grupurile de debil si pachetele de date ce corespund traficului generat.
Figura 4.26 Exemplu de Traffic Wizard Preview
Următorul pas este necesar pentru ști dacă traficul configurat poate fi generat în topologia respectivă.
Figura 4.27 Exemplu de Traffic Wizard Validater
După ce toti acesti pași au fost realizați și am primit bifa verde la toate opțiunile în fereastra “Validate“ nu ne mai ramane decat să generăm acest trafic apăsând click în tab-ul “Home“ pe “Apply L2-3 Traffic“.
Figura 4.28 Aplicarea traficului L2-3
Generarea raporturilor
Din tabul “Results/Reports“ după cum se arată în poza de mai jos putem alege mai multe optiuni în functie de cum dorim să primim statisticile utilizării topologiei.
Figura 4.29 Colectarea statisticilor
Astfel scopul acestei lucrări este de a testa protocolul IGMP urmărind mai multe statistici ce indică performanța protocolului în cadrul topologiei respective: acuratețea transmisiei, latența. În acest scop au fost efectuate multiple teste în care a fost schimbată succesiv rata de transfer a pachetelor și dimensiunea acestora. Pentru fiecare test au fost repetate etapele descrise anterior
Primul scenariu
În cadrul primului scenariu vom trimite pachetele multicast de pe intefața fa0/0 a șasiului Ixia utilizând toate hosturile din cadrul acesteia către interfața fa0/1 utilizâand de asemenea toate hosturile acestei interfețe. A fost utilizată versiunea protocolului IGMPv1 având o rată de transfer de 10% și dimensiunea unui pachet multicast de 64 de biți:
Frame size = 64
Rate = 10%
Figura 4.30 Selectarea interfețelor pentru transmisie
În urma testului efectuat, s-au obținut următoarele rezultate:
Figura 4.31 Rezultate IGMPv1 topologie 1
Figura 4.32 Rezultate IGMPv1 topologie 1
Figura 4.33 Rezultate IGMPv1 topologie 1
Al 2 lea scenariu
În cel de al 2 lea scenariu s-a folosit aceeas topologie ca și în primul scenariu. Și aici se foloseste prima versiune a IGMP-ului dar ce se va schimba este rata de transmisie a acestora la 30%, dimensiunea pachetelor rămânând aceeas . Rezultatele au fost :
Frame size = 64 biți
Rate = 30%
Rezultatele au fost:
Figura 4.34 Rezultate IGMPv1 topologie 1
Figura 4.35 Rezultate IGMPv1 topologie 1
Figura 4.36 Rezultate IGMPv1 topologie 1
Acestea reprezintă statisticile ce au extrase în urma utilizării primei versiuni a IGMP-ului folosind o rată de transfer a pachetelor de 10% respectiv 30% cu o dimensiune a pachetelor de 64 biți.
Al 3 lea scenariu
Al 3 lea scenariu a fost utilizată aceleiasi topologie însă de această dată a fost folosită cea de a 2 a versiune a IGMP-ului. Pentru funcționarea corectă a topologiei a fost necesară schimbarea versiunii atât în cadrul programului IxNetwork cât și pe routerul aflat sub test.
Frame size = 64
Rate = 10%
Figura 4.37 Rezultate IGMPv2 topologie 1
Figura 4.38 Rezultate IGMPv2 topologie 1
Figura 4.39 Rezultate IGMPv2 topologie 1
Al 4 lea scenariu
În ultimul scenariu folosit pentru testarea celei de a 2 versiuni a IGMP-ului aceeaș topologie a fost folosită însa a fost schimbată rata de transmisie a pachetelor multicast. În mod evident rezultatele au fost diferite față de precedenteleȘ
:
Frame size = 64
Rate = 30%
Figura 4.40 Rezultate IGMPv2 topologie 1
Figura 4.41 Rezultate IGMPv2 topologie 1
Figura 4.42 Rezultate IGMPv2 topologie 1
Al 5 lea scenariu
Cel de al 5-lea scenariu a fost folosit pentru testarea ultimei versiuni a IGMP-ului. Ca și în precedentele teste mesajele au fost trimise de pe interfața fa0/0 pe interfața fa0/1. Se doreste a fi observată comportarea fiecărei versiuni în parte pe aceeaș topologie pentru a se deosebi clar diferențele între acestea. Au fost făcute 2 seturi de teste pentru fiecare versiune în parte: odată pachetele au fost trimise având dimensiunea de 64 biți și încărcarea topologiei de 10% iar în celălalt caz încărcarea topologiei a fost ridicată la 30%. În cazul de față se urmărește testarea protocolului IGMPv3 având :
Frame size = 64
Rate = 10%
Figura 4.43 Rezultate IGMPv3 topologie 1
Figura 4.44 Rezultate IGMPv3 topologie 1
Figura 4.45 Rezultate IGMPv3 topologie 1
Al 6 lea scenariu
Un alt scenariu pentru testarea celei de a 3 a versiuni a IGMP-ului este :
Frame size = 64
Rate = 30%
Figura 4.46 Rezultate IGMPv3 topologie 1
Figura 4.47 Rezultate IGMPv3 topologie 1
Figura 4.48 Rezultate IGMPv3 topologie 1
Al 7 lea scenariu
Ultima topoligie a acestei licențe este utilizarea a jumătate din grupurile multicast formate pe fiecare interfață a șasiului Ixia. Ideea formării acestei topologii este de a crea un mediu cat mai aerisit pentru routerul aflat sub test pentru a putea obține informații cât mai clare. Din cauza încărcării foarte mari a rețelei, routerul nu a putut procesa toate pachetele într un timp real, de aceea în scenariile anterioare au fost înregistrate anumite pierderi. În cele ce urmează voi testa toate cele 3 versiuni ale IGMP ului utilizând o rată de transfer de 30% și o dimensiune a pachetului de 64 de biți. Durata testului ca și în scenariile anterioare a fost de 10 minute.
Vom începe prin testarea primei versiuni a IGMP-ului trimitând ca în scenariile anterioare pachete de tip multicast de pe interfața fa0/0 pe interfața fa0/1 însa folosind doar jumatate din groupurile multicast disponibile.Astfel rezultatele au fost următoarele:
Al doilea test al acestei topologii presupune utilizarea celei de a 2 a versiuni a IGMP-ului.Rezultatele pentru această versiune ar trebuii să aduca statistici mai bine decat în cadrul primei versiuni deoarece este o versiune mai noua care este mai bine optimizată decat IGMPv1.În acest sens rezultatele pentru IGMPv2 au fost:
Ultimul test în cadrul acestei licențe reprezintă testarea ultimei versiuni a IGMP-ului. Astfel timpul parcurs de către pachetele multicast ce reprezintă latența în acesta statistici ar trebuii să fie mult mai mic decat în versiunile anterioare iar numărul de pachete transmise să fie mult mai mare. În acest sens rezultatele obtinute sunt:
Plan de afacere pentru implementarea rețelelor de calculatoare și mentenanța echipamentelor de routare
Analiza mediului de afacere și propunerea afacerii
Afacerea va reprezenta o micro-întreprindere în Municipiul București ce se va ocupa cu realizarea și mentenanța rețelelor de calculatoare din cadrul școlilor, universităților cât și configurarea echipamentelor de routare din casele oamenilor.
Table 1 Analiza macromediului
Descrierea afacerii
Se urmărește implementarea rețelelor de calculatoare în cadrul școlilor, universităților și întreprinderilor pentru a servii în scopuri educaționale cât și în securizarea informațiilor. Pentru a realiza acest lucru se urmărește deschiderea unei micro întreprinderi cu răspundere limitată S.C Mentenance of networking S.R.L, finanțată de un singur asociat ce va utiliza inițial un capital propriu. Întreprinderea va avea sediul amplasat pe Nicolae Filipescu nr.74 Sector 5.
Descrierea serviciilor oferite
Activitatea întreprinderii va consta în:
Implementarea rețelelor de calculatoare în cadrul școlilor și universităților.
Mentenanța routerelor la domiciliu.
Etape de lucru:
Configurarea echipamentelor electronice.
Realizarea conexiunilor între echipamentele electronice.
Echipamentele folosite vor fi nou achiziționate. Se urmărește utilizarea unor echipamente noi deoarece acest lucru garantează o durată de funcționare îndelungată a acestora.
2 Laptopuri
Sertizator
Pistol de lipit
Clește pentru fire
Cater
Analiză SWOT
Table 2 Analiza punctelor tari și slabe ale afacerii
Table 3 Matricea MEFE
Table 4 Matricea MEFI
Marketingul afacerii
Domeniul ales pentru dezvoltarea întreprinderii este în plină ascensiune, necesitatea utilizării unei tehnologii noi pentru oferirea unei educații bune fiind întotdeauna necesară. Într – o primă etapă se va urmări deschiderea unui singur sediu în Municipiul București , urmărindu-se extinderea activității și în alte orașe în cazul unui profit ridicat.Pentru început frecvența activităților va fi destul de mică doarece numărul de angajați va fi foarte mic. Odată cu creșterea comenzilor numărul de angajați va crește și el, astfel întreprinderea putând să se afirme pe piață. Se urmărește utilizarea unei strategii de penetrare a pieței cu prețuri de implementare scăzute pentru atragerea clienților.
Întreprinderea va avea un site de prezentare, dar se va încerca promovarea acesteia și prin intermediul mass-media și radio.
Managementul afacerii
Managerul acestei firme are cunostințe în domeniu având rolul de a coordona angajații din întreaga firmă, cât și responsabilitatea de a procura ustensilele necesare pentru a asigura configurarea și crearea întregii rețele.Personalul necesar pentru întreprindere:
2 programatori în domeniul rețelelor de calculatoare
Finanțele afacerii
Costuri aparaturi :
Laptop: 2 * 2500 lei = 5000 lei
Sertizator : 60 lei
Pistol de lipit: 200 lei
Clește pentru fire: 250 lei
Cater: 20 lei
Cablu USB-RJ45 : 20 lei
Total costuri : 5550 lei
Cheltuieli cu salariile:
Programatori : 2 * 2000 lei = 4000 lei
Utilități: 1000 lei
Total cheltuieli: 10550 lei
Venituri într-o luna :
Implementarea rețelelor de calculatoare în cadrul școlilor, universităților și întreprinderilor: 7 ori * 3000 = 21000 lei
Implementarea configurărilor la domiciliu : 20 ori * 40 lei = 800 lei
Venituri totale: 21800 lei
Profitul brut pe lună: VT – CT = 21800 – 10550 = 11250 lei
Concluzie: Pentru a acoperii investiția inițiala și pentru obținerea profitului sunt necesare trei luni de activitate.
Si scrii si tu ca " Din tabel reiese ca ma incadrez in cadranul 1, ceea ce inseamna ca afacerea este una profitabila"
Concluzii :
Proiectul de față a presupus evaluarea performațelor unei rețele ce a implementat protocolul IGMP prin utilizarea sofwaru-lui IxNetwork, aparținând Ixia. În zilele noastre tehnologia evoluează într-un ritm foarte ridicat motivul principal pentru care am ales aceasta temă de licență fiind dorința de a încerca sa țin pasul cu aceasta. Atât pe router cât și pe șasiul de testare Ixia, am efectuat configurarea protocolului IGMP realizând toate procesele necesare pentru crearea unor teste complexe.
Testarea protocoalelor a apărut din nevoia fabricanților de a-și testa echipamentele de rețea în anumite ipostaze de încărcare a rețelei pentru a fi siguri că acestea suportă funcționarea în anumite topologii complexe..
Am avut ca scop analiza funcționalității protocolului IGMP în cadrul programului IxNetwork dezvoltat de Ixia și modul în care acesta reacționează atunci când acesta este implementat intr-o topologie foarte complexă.
Pentru a ilustra acest lucru am creat o topogie prin intermediul căreia am testat toate cele 3 versiunii ale IGMP ului însă la o rată diferită de 10% si 30%:
În urma testării IGMP-ului utilizând toate grupurile multicast formate pe fiecare interfață am observat că au apărut pierderi de pachete deoarece traficul transmis de la o interfață la alta era foarte mare pentru a putea fi procesat în totalitate de către routerul folosit în topologie. Totodată pe lânga pierderile de pachete, latența, adică timpul consumat de un pachet pentru a ajunge de la o interfață la alta a crescut de la prima versiune a IGMP-ului la ultima.
Astfel pentru topologia ce a utilizat o rată de transfer de 10% și o dimensiune a pachetelor multicast de 64 de biți în cadrul fiecărei versiuni au fost înregistrate pierderi de 18%-20% datorate incapabilității routerului de a procesa o cantitate atât de mare de pachete. Pentru o încărcare a topologiei de 30% s-au pierdut mai mult de jumătate din pachetele transmise doarece viteza de transfer a fost mai mare și din nou routerul utilizat nu a putut să realizeze transmisia de la o interfață la alta.
Am decis să utilizez pentru ultimele teste, o topologie formată din jumătate din grupurile de multicast de pe fiecare interfață. Pierderile de pachete au fost foarte mici, aproape de 0, astfel valorile obținute sunt cât se poate de clare pentru fiecare versiune în parte.
În acest sens concluzia pe care o pot trage în urma acestor statistici este că protocolul nu a avut nici o problemă în a crea grupurile de multicast pentru o administrare a acestora ulterioară, latența respectiv pierderile de pachete fiind induse de către routerul ce a fost supus testelor.
Bibliografie
[1] Preda Octavian, Slideuri CCNA1, Academia Cisco UPB
[2] http://www.unibuc.ro/prof/niculae_c_m/telecom/modelul_iso_osi.htm
[3] www.google.ro/image
[4] http://books.google.ro/books?id=s1iT4f3KCp0C&pg=PA193#v=onepage&q&f=false
[5]http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html#wp1015526
[6] http://www.networksorcery.com/enp/protocol/igmp.htm
[7] http://www.dell.com/downloads/global/products/pwcnt/en/app_note_18.pdf
Bibliografie
[1] Preda Octavian, Slideuri CCNA1, Academia Cisco UPB
[2] http://www.unibuc.ro/prof/niculae_c_m/telecom/modelul_iso_osi.htm
[3] www.google.ro/image
[4] http://books.google.ro/books?id=s1iT4f3KCp0C&pg=PA193#v=onepage&q&f=false
[5]http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html#wp1015526
[6] http://www.networksorcery.com/enp/protocol/igmp.htm
[7] http://www.dell.com/downloads/global/products/pwcnt/en/app_note_18.pdf
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Evaluarea Functionala a Implementarii Protocolului Igmp (internet Group Management Protocol) (ID: 139832)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.