1

Administrarea reţelelor de calculatoareAdministrarea reţelelor de calculatoareAdministrarea reţelelor de calculatoareAdministrarea reţelelor de calculatoare

---- curs curs curs curs ----

2

1. Noţiuni de bază despre rutare. Sistemul Internet este format dintr-un număr de reţele interconectate care suportă comunicaţii între calculatoare folosind un set de protocoale Internet. Aceste protocoale includ Internet Protocol (IP), Internet Control Messages Protocol (ICMP), Internet Grup Management Protocol (IGMP), şi o varietate de protocoale de nivel aplicaţie şi transport ce depind de acestea. Toate protocoalele Internet folosesc IP ca mecanism de bază pentru transportul datelor. IP este un protocol de comunicaţie de tip datagramă sau care nu se bazează pe conexiune şi include facilităţi pentru adresare, specificaţii despre tipul serviciului, fragmentarea şi reasamblarea pachetelor şi securitate. ICMP şi IGMP sunt considerate ca fiind părţi integrante ale IP, de altfel ele sunt arhitectural, nivele peste IP. ICMP furnizează rapoarte privind erorile de transmisie, controlul fluxului, primul gateway şi alte funcţii privind mentenanţa şi controlul comunicaţiei. IGMP furnizează mecanisme prin care host-urile şi router-ele se alătură şi părăsesc un grup multicast. Siguranţa transferurilor de date este dată în Internet de protocoalele nivelului transport şi anume de Transmission Control Protocol (TCP), care furnizează retransmisia între sursă şi destinaţie, resegmentarea şi controlul conexiunii. Serviciile care nu se bazează pe conexiune de nivel transport sunt oferite de User Datagram Protocol (UDP).

Figura 1.1 Suita de protocoale Internet acoperă toate nivelele modelului OSI.

Protocoalele Internet au fost dezvoltate la mijlocul anilor 1970, când DARPA (Defense Advanced Research Projects Agency) a devenit interasată de realizarea unei reţele cu comutarea pachetelor care ar fi facilitat comunicaţia între diverse sisteme informatice ale instituţiilor de cercetare. Având în minte scopul unei conectivităţi heterogene, DARPA a finanţat cercetarea Universitaţii Stanford şi a companiei BBN (Bolt, Beranek şi Newman). Rezultatul acestui efort de cercetare a fost suita de protocoale Internet, completată la sfârşitul anilor 1970. TCP/IP a fost inclus mai târziu cu Berkeley Software Distribution (BSD) UNIX şi a devenit apoi fundamentul pe care se bazează Internetul şi World Wide Web (WWW).

3

Documentaţia despre protocoalele Internet (incluzând protocoalele noi sau revizuite) şi politici este specificată în raportul tehnic numit Request For Comments (RFCs), ce a fost publicat şi apoi revizuit de comunitatea Internet. Protocolul revizuit a fost publicat din nou în RFCs. Pentru a ilustra scopul protocoalelor Internet, Figura 1.1 reprezintă o schemă a protocoalelor din suita protocolului Internet şi nivelele corespunzătoare lor din modelul OSI. 1.1 Protocolul Internet. Protocolul Internet se afla la baza comunicaţiei în Internet. Funcţiile sale includ: - definirea de datagrame, care sunt unitatea de bază a transmisiei în Internet; - definirea schemei de adresare în Internet; - transmiterea datelor între nivelul Network Access şi nivelul Transport; - rutarea datagramelor către host-ul aflat la distanţă; - realizarea fragmentării şi reasamblării datagramelor.

Înainte de descrierea în detaliu a acestor funcţii, să analizăm câteva caracteristici ale IP. Întâi, IP este un protocol care nu se bazează pe conexiune. Acest lucru înseamnă că IP nu schimbă informaţii de control ("handshake") pentru a stabili o conexiune între sursă şi destinaţie înaintea transmiterii de date. În contrast, un protocol orientat pe conexiune schimbă informaţii de control cu sistemul aflat la distanţă pentru a verifica dacă este gata să primească date înainte de a transmite vreuna. Când conexiunea (prin ("handshake") este realizată, sistemul spune că a stabilit conexiunea. Protocolul Internet se bazează pe protocoale ale altor nivele pentru stabilirea conexiunii dacă acestea necesită servicii orientate pe conexiune. De asemenea, IP se bazează pe protocoale ale altor nivele pentru detectarea şi corectarea erorilor. IP este uneori numit un protocol incert pentru că nu conţine coduri de detectare şi corectare a erorilor. Asta nu înseamnă că acest protocol nu poate fi considerat sigur. Putem conta pe faptul că IP poate transmite în siguranţă datele într-o reţea, dar nu va verifica dacă datele au fost corect recepţionate. Protocoalele altor nivele ale arhitecturii TCP/IP furnizează această verificare atunci când este cerută. 1.1.1 Datagrama Protocoalele TCP/IP au fost dezvoltate pentru a transmite date în reţeaua ARPANET, care este o reţea cu comutarea pachetelor. Un pachet este un bloc de date care conţine şi informaţiile necesare pentru livrare - într-o manieră asemănătoare cu scrisoarea poştală, care are adresa scrisă pe plic. O reţea cu comutarea pachetelor foloseşte informaţia conţinută în pachete privind adresa, pentru a comuta pachetele de pe un nivel fizic pe altul, transmiţându-le apoi mai departe spre destinaţia finală. Fiecare pachet străbate reţeaua independent de oricare alt pachet. Datagrama este un format de pachet definit de Protocolul Internet. Figura 1.2 reprezintă o datagramă IP. Primele 5 sau 6 cuvinte de 32 biţi ai datagramei reprezintă informaţii de control şi se numesc header. Implicit, header-ul are o lungime de 5 cuvinte, al 6-lea fiind opţional. Din cauză că lungimea header-ului poate fi variabilă se include un câmp numit IHL (Internet Header Length - lungimea header-ului internet) care indică lungimea exactă a acestuia. Header-ul conţine toate informaţiile necesare livrării pachetului. Protocolul Internet livrează datagrama verificând adresa destinaţie din al 5-lea cuv al header-ului. Adresa destinaţie este o adresă IP v4 standard de 32 de biţi care identifică reţeaua destinaţie şi host-ul respectiv. Dacă adresa destinaţie este adresa unui host din reţeaua locală, pachetul este livrat direct destinaţiei. Dacă adresa destinaţie nu face parte din reţeaua locală, pachetul este trimis la un gateway pentru a fi livrat. Gateway-urile sunt dispozitive care comută pachete între diferite

4

reţele fizice. Decizia privind ce gateway se va folosi se numeşte rutare. Router-ele (gateway-urile) iau decizii de rutare pentru fiecare pachet individual ce trebuie transmis.

Figura 1.2 Formatul unei datagrame IP

1.1.2 Rutarea datagramelor

În modelul Internet, reţelele constituente sunt interconectate prin echipamente specifice numite router-e sau IP router-e. Istoric, router-ele au fost iniţial realizate cu soft-uri de comutare a pachetelor ce rulau pe echipamente nespecializate. Deoarece, în timp, implementarea de hardware a devenit mai ieftină, iar cerinţele privind performanţele au crescut, router-ele au fost implementate sub forma unor echipamente specializate. Gateway-urile în Internet sunt de obicei (şi probabil mai corect) referite ca router-e IP deoarece folosesc Protocolul Internet pentru rutarea pachetelor între reţele. În jargonul tradiţional TCP/IP, există numai 2 tipuri de dispozitive de reţea: gateway-uri şi host-uri. Gateway-urile expediază pachetele între reţele şi host-urile nu. Oricum, dacă un host este conectat cu mai mult de o reţea (şi se numeşte multi-homed host), el poate expedia pachete între reţele. Când un host multi-home expediază pachete, el se comportă ca orice gateway şi este considerat a fi gateway. Terminologia actuală a comunicaţiilor de date face distincţie între gateway şi router, dar noi vom folosi termenii de gateway şi router IP unul în locul altuia. În terminologia actuală, un gateway transmite date între diferite protocoale şi un router transmite date între diferite reţele ce utilizează acelaşi protocol. Figura 1.3 prezintă modul în care este folosit un gateway pentru a expedia pachete. Host-urile prelucrează pachetele de-a lungul celor 4 nivele, în timp ce gateway-ul (sau sistemul intremediar) procesează pachetele numai până la nivelul Internet unde se ia decizia de rutare.

5

Figura 1.3 Rutarea prin gateway-uri

Sistemele pot numai să livreze pachetele altor dispozitive ataşate în aceeaşi reţea fizică. Pachetele de la A1 destinate hostului C1 sunt expediate prin gateway-urile G1 şi G2. Hostul A1 mai întâi livrează pachetele spre gateway-ul G1, prin reţeaua A la care ambele sunt conectate. Gateway-ul G1 livrează pachetul la G2 prin reţeaua B. Gateway-ul G2 livrează apoi pachetul direct hostului C1 deoarece ambele fac parte din aceeaşi reţea C. Hostul A1 nu cunoaşte nimic în afară de gateway-ul G1. El trimite pachetele destinate reţelelor B sau C către acelaşi gateway local, şi apoi devine sarcina gateway-ului să expedieze corect pachetele către destinaţia lor. Tot aşa, hostul C1 va trimite pachetele sale către G2, în scopul de a ajunge la un host din reaţeaua A, sau din reţeaua B.

1.2 ICMP ICMP este considerat adesea ca făcând parte din nivelul IP. El furnizează mesaje de eroare şi alte informaţii necesare pentru controlul comunicaţiei. Mesajele ICMP sunt generate de unul din nivelele IP sau de protocoale de la nivele mai înalte (TCP sau UDP). Unele mesaje ICMP furnizează erori ce sunt returnate proceselor utilizatorului. Mesajele ICMP sunt transmise în cadrul datagramelor IP, aşa cum se vede şi în figura 1.4

Figura 1.4 Mesaj ICMP încapsulat în datagrama IP

Este nevoie să facem această diferenţă deoarece, uneori, mesajele de eroare ICMP sunt tratate special. De exemplu, un mesaj de eroare ICMP nu va fi generat niciodată ca răspuns la un alt mesaj de eroare ICMP. (Dacă acest lucru nu ar fi o regulă, ar putea exista scenarii în care o eroare generează altă eroare, care generează alta şi aşa mai departe, indefinit).

6

Când un mesaj de eroare ICMP este transmis, el conţine totdeauna headerul IP şi primii 8 octeţi ai datagramei IP care l-a cauzat. Acest lucru permite modulului ICMP receptor să asocieze mesajul cu un protocol particular (TCP sau UDP specificat în câmpul de protocol din headerul IP) şi cu un anume proces al userului (rezultat din numerele de port TCP sau UDP care sunt conţinute în primii 8 octeţi ai headerului datagramei IP). Cererea ICMP de tip “timestamp” permite unui sistem să interogheze un alt sistem în ceea ce priveşte timpul curent. Valoarea recomandată pentru a fi returnată este un număr de ordinul milisecundelor de la ora zero UTC (Coordinated Universal Time). (În literatura mai veche UCT este denumit Greenwich Mean Time - GMT). O proprietate importantă a mesajului ICMP este aceea că furnizează o rezoluţie la nivel de milisecundă, în timp ce alte metode pentru obţinerea timpului curent de la un host (cum ar fi comada rdate furnizată de unele sisteme Unix) furnizează o rezoluţie de ordinul secundelor. Inconvenientul acestei metode este faptul că se poate afla numai intervalul de timp între ora curentă şi ora zero, urmând ca data curentă să fie aflată prin alte mijloace. 1.3 Rutere Rutarea constă în transmiterea informaţiei printr-o reţea de la o sursă către o destinaţie. De-a lungul căii parcurse, este întâlnit cel puţin un nod intermediar. Rutarea este adesea în contrast cu funcţia de bridge care aparent realizează acelaşi lucru. Diferenţa principală între cele 2 este aceea că “bridging” (switching) are loc în cadrul nivelului 2 (Data link layer) al modelului de referinţă OSI, în timp ce rutarea are loc la nivelul 3 (network layer). Această diferenţă constă în utilizarea de informaţie diferită pentru rutare şi respectiv bridging, informaţie necesară în procesul transmiterii pachetelor de la sursă la destinaţie, deci aceste 2 funcţii îşi îndeplinesc rolurile în moduri diferite. Un router dispune de 2 sau mai multe interfeţe de comunicaţie(figura 1.5), conectate la subreţele IP sau la linii de tip punct-la-punct. Cu toate acestea, există cel puţin o interfaţă fizică. Expedierea unei datagrame IP necesită în general ca un router să aleagă interfaţa şi adresa router-ului următor (next-hop) sau (în cazul ultimului router de pe traseu), host-ul destinaţie. Această alegere, (numită “relaying”) se face în funcţie de o bază de date care se află pe router conţinând rute. Această bază de date se mai numeşte şi tabelă de rutare. Temenul de “router” derivă din modul în care se construieşte această bază de date conţinând rute (căi); protocoalele de rutare şi configurare interacţionaeză în cadrul unui proces numit rutare.

7

Figura 1.5 Interconectarea a 2 reţele printr-un router Baza de date conţinând rute trebuie să fie dinamică pentru a reflecta topologia curentă a sistemului de reţele interconectate. În mod normal, un router îndeplineşte acest lucru prin interacţiune cu alte routere pe baza unor algoritmi de rutare. Ruterele furnizează numai transportul de datagrame, şi caută să reducă la minim informaţia de stare necesară efectuării acestui serviciu, avînd ca scop flexibilitatea şi robusteţea rutării. Un sistem autonom (AS) este reţea ce constă dintr-o colecţie de subreţele (avînd ataşate host-uri) interconectate printr-un set de routere. E de preferat ca subreţelele şi routerele să fie sub controlul unei singure organizaţii ce realizează operarea şi administrarea. Într-un sistem autonom, routerele pot folosi unul sau mai multe protocoale de rutare internă, şi câteodată câteva seturi de metrici. Este de aşteptat ca un sistem autonom să dispună de un plan de rutare interioară coerent. Un sistem autonom este identificat cu un număr de sistem autonom. 2. Bridging cu routere În scopul de a îmbunătăţi performanţele, următoarele performanţe au fost adăugate unor routere: - bridging transparent; - source-route bridging. Bridge-urile transparente se găsesc predominant în reţelele Ethernet, iar source-route bridges (SRBs) se găsesc aproape exclusiv în reţelele Token-Ring. Ambele sunt utilizate pe scară largă. 2.1 Bridging transparent Bridge-urile transparente au fost mai întâi implementate de Digital Equipment Corporation la începutul anilor 1980. Digital a transmis aceste implementări la IEEE care le-a încorporat în standardul IEEE 802.1. Bridge-urile transparente sunt foarte comune în reţelele

8

Ethernet/IEEE 802.3. În acest paragraf se face o trecere în revistă a modului în care bridging-ul transparent manipulează traficul şi componentele protocolului. Numele de “bridge transparent” provine din faptul că prezenţa şi modul de operare al acestuia sunt transparente pentru host-urile din reţea. Când este pornit un “bridge tranparent”, el învaţă locaţia staţiiilor de lucru prin analizarea adresei MAC sursă a pachetelor pe care le primeşte de la toate reţelele ataşate. De exemplu, dacă un bridge primeşte un pachet pe portul 1 de la Host-ul A, el consideră că Host-ul A se află în segmentul conectat pe portul 1. În timpul acestui proces, bridge-ul transparent construieşte (procesul de învăţare) o tabelă, ca cea din figura de mai jos:

Figura 2.1. Bridge-uri transparente: construirea unei tabele cu ajutorul căreia se determină cum pot fi accesate host-urile.

Bridge-ul foloseşte această tabelă ca bază în procesul de expediere a traficului. Când este primit un frame pe una din interfeţele bridge-ului, acesta caută adresa destinaţie a frame-ului în tabela sa internă. Dacă tabela conţine o asociere între adresa destinaţie şi unul din porturile bridge-ului în afară de cel pe care a fost primit frame-ul, frame-ul va fi expediat pe acel port. Dacă nu există nici o asociere în tabelă, frame-ul este transmis pe toate porturile (flood ) mai puţin cel pe care a venit. Broadcast-urile şi multicast-urile sunt de asemenea transmise în acest fel.

Bridge-urile transparente izolează cu succes traficul intern al unui segment de reţea (intrasegment), reducând astfel traficul pe fiecare segment individual. Acest lucru se numeşte filtrare şi apare atunci când adresa MAC a sursei şi destinaţiei aparţin aceleaşi interfeţe a bridge-ului. Filtrarea îmbunătăţeşte de obicei timpul de răspuns al reţelei, aşa cum este el perceput de utilizator. Volumul cărui trafic este redus şi care timpi de răspuns sunt îmbunătăţiţi depinde de volumul traficului pe intersegmente relativ la traficul total, ca şi de volumul traficului de multicast şi broadcast. 2.2 Bridging de tip Source-Route (Source-Route Bridging - SRB)

9

Algoritmul SRB a fost dezvoltat de IBM şi a fost propus comitetului IEEE 802.5 ca un mijloc de legătură între LAN-uri. A urmat apoi o nouă propunere de standard a IBM: source-route transparent (SRT) bridging. SRT bridging elimină SRB-ul pur propunând ca implementările ulterioare să se bazeze pe doi algoritmi: bridge transparent şi bridge SRT.

Cu toate că SRT s-a bucurat de apreciere şi support, SRB este încă larg răspândit.

SRB se numeşte astfel deoarece presupune că ruta completă sursă-destinaţie se află în toate frame-urile (pachetele) inter-LAN transmise de sursă. SRB stochează şi transmite frame-urile aşa cum este prevăzut în rutele ce au fost stabilite prin procesul numit explorare. Figura următoare ilustrează un model de reţea SRB.

Să presupunem că hostul X vrea să transmită un frame către host Y. Iniţial, hostul X nu ştie dacă hostul Y aparţine aceluiaşi LAN sau nu. Pentru a determina acest lucru, hostul X transmite un frame de test. Dacă frame-ul se întoarce la hostul X fără a conţine indicaţia că hostul Y l-a văzut, atunci hostul X va presupune că hostul Y aparţine unui segment aflat la distanţă.

Figura 2.2: Reţea SRB conţinând LAN-uri şi bridge-uri

Pentru a determina locaţia exactă a hostului Y, hostul X trimite un frame de explorare. Fiecare bridge care primeşte acest frame de explorare (Bridge 1 şi 2 în exemplul nostru) retransmite frame-ul pe toate porturile sale. Informaţia despre rută este adăugată frame-urilor de explorare cât timp acestea parcurg reţelele interconectate. Când frame-urile de explorare de la hostul X a ajuns la hostul Y, acesta răspunde la fiecare, folosind informaţiile deja

10

acumulate despre rută. După ce a recepţionat toate frame-urile de răspuns, hostul X alege o rută bazându-se pe un anumit criteriu predefinit.

În exemplul nostru, acest proces va raporta 2 rute:

- LAN 1 – Bridge 1 – LAN 3 – Bridge 3 –LAN 2 - LAN 1 – Bridge 2 – LAN 4 – Bridge 4 – LAN 2

Hostul X va selecta una din aceste 2 rute. Specificaţiile standardului IEEE 802.5 nu stabilesc criteriul pe care să îl folosească hostul X în alegerea rutei, dar poate să facă câteva sugestii ca de exemplu:

- primul răspuns primit, - răspunsul cu numărul minim de hopuri, - răspunsul cu cea mai mare dimensiune permisă pentru un frame, - combinaţii ale criteriilor de mai sus.

În majoritatea cazurilor, ruta conţinută în primul frame primit este cea care va fi folosită.

După selectarea rutei, aceasta este inserată în frame-ul destinat hostului Y, în câmpul cu informaţii de rutare (RIF- routing information field). Acest câmp este inclus numai în acele frame-uri destinate altor LAN-uri. Prezenţa informaţiilor privind ruta este indicată prin setarea celui mai semnificant bit în câmpul adresa sursei, care se numeşte bit indicator de informaţii de rutare (RII – routing information indicator).

3. Rutare statică

Pentru ca rutarea între router-ele dintre mai multe reţele să fie eficientă, router-ele trebuie să cunoască ID-urile (adresele) celorlalte reţele sau să aibă configurată o rută implicită (default). Între mai multe reţele interconectate, tabelele de rutare trebuie să fie făcute astfel încât traficul să urmeze totdeauna o cale optimă. Felul în care aceste tabele de rutare sunt construite face de fapt diferenţa dintre rutarea statică şi rutarea dinamică.

Procesul de rutare în care tabela de rutare se construieşte manual se numeşte rutare statică. Administratorul de reţea, având cunoştinţe despre topologia sistemului reţele interconectate, construieşte manual tabela de rutare a fiecărui router şi o actualizează, scriind toate rutele în aceasta.

Rutarea statică funcţioneaza bine pentru puţine reţele intreconectate, dar nu sunt indicate în cazul în care există multe reţele intreconectate sau care se modifică. Router-ele statice nu sunt tolerante la erori. Timpul cât o configuraţie manuală a unui router static este validă este infinit, dar cu toate acestea, rutarea statică nu este indicată şi nu poate rezolva problemele ce apar prin nefuncţionarea unui router sau prin întreruperea unei conexiuni.

3.1 Carcateristicile router-elor Un router are următoarele funcţii: 1. Lucrează în conformitate cu protocoalelor Internet specifice, IP, ICMP şi alte protocoale.

11

2. Asigură interfaţa între 2 sau mai multe reţele. Pentru fiecare reţea care este conectată la un router, acesta trebuie să implementeze funcţiile impuse de acea reţea. Aceste funcţii includ de obicei următoarele:

- să încapsuleze şi să decapsuleze datagramele IP (de ex. adăugarea şi eliminarea header-ului Ethernet şi a câmpului frame checksum FCS), - să expedieze şi să primească datagrame IP având o dimensiune mai mică decât lungimea maximă suportată de acea reţea. Această lungime maximă poartă numele de Maximum Transmission Unit (MTU), - să translateze adresele IP destinaţie în adrese de nivel reţea potrivite reţelei conectate (de exemplu o adresă hardware Ethernet), dacă acest lucru este necesar, - să cunoască protocolul reţelei de control al fluxului şi indicatorii de eroare, dacă aceştia există.

3. Primeşte şi transmite datagrame Internet. O importantă carcateristică a acestui proces este gestionarea buffer-ului, controlul congestiilor de trafic şi prioritizarea.

- să recunoscă condiţiile de eroare şi să genereze erori ICMP şi mesaje de informaţii suplimentare dacă este cazul, - să elimine datagramele al căror timp de viaţă a devenit zero. - să fragmenteze datagramele atunci când este cazul pentru a se încadra în MTU-ul reţelei în care trebuie transmise,

4. Alege destinaţia următoare pentru fiecare datagramă IP, pe baza informaţiilor (rutelor) din baza sa de date. 5. (de obicei) Suportă un protocol de rutare dinamică de tip interior (Interior Gateway Protocol IGP) pentru a asigura rutarea dinamică şi a comunica cu alte router-e care fac parte din acelaşi sistem autonom (AS). 6. Asigură metode de gestionare a reţelei şi facilităţi pentru suport al sistemului, incluzând încărcarea, raportări de stare, raportări de excepţii şi control. 3.2 Tabela de rutare

Router-ele sunt cele care asigură rutarea datelor între reţele, dar, decizii privind rutarea trebuie luate de către toate dispozitivele de reţea (host-uri şi router-e). Pentru cele mai multe host-uri, decizia de rutare este simplă:

- dacă host-ul destinaţie se află în reţeaua locală, pachetul este transmis către hostul destinaţie,

- dacă host-ul destinaţie aparţine unei reţele aflate la distanţă, pachetul este transmis router-ului prin care se iese din reţeaua locală.

Deoarece dirijarea traficului (rutarea) se face la nivel de reţea, modulul IP ia deciziile de rutare ţinând cont doar de partea din adresa destinaţie care reprezintă adresa de reţea. IP determină ce parte din adresă reprezintă adresa de reţea prin aplicarea unei măşti de reţea adresei (se efectuează operaţia logică AND între adresă şi mască). Dacă reţeaua destinaţie este chiar reţeaua locală, masca ce se aplică poate fi masca subreţelei locale. Dacă pentru adresa respectivă nu există nici o mască, clasa de adrese din care face parte adresa va determina porţiunea care reprezintă adresa reţelei.

După detreminarea adresei reţelei destinaţie, modulul IP caută acea adresă de reţea în tabela de rutare locală. Pachetele sunt rutate către destinaţia lor aşa cum este prevăzut în tabela de rutare. Tabela de rutare poate fi construită de administratorul de reţea sau prin protocoalele de

12

rutare dinamică, dar rezultatul final este acelaşi; IP ia decizia de rutare în conformitate cu tabela de rutare.

O tabelă de rutare are următoarele câmpuri:

Destination (destinaţie) – reţeaua destinaţia (sau host-ul destinaţie) Gateway - Gateway-ul care va folosit pentru transmiterea pachetului spre destinaţia specificată. Flags - Aceşti indicatori descriu anumite carcateristici ale rutei alese. Valorile posibile sunt:

U - Indică dacă acea rută este up şi operaţională. H - Indică faptul că acea rută este către un anumit host (majoritatea rutelor sunt către reţele). G - Arată faptul că ruta trece printr-un gateway. Interfeţele router-ului asigură rute către reţelele direct conectate la acestea. Toate celelelate rute folosesc gateway-uri aflate la distanţă. În cazul rutelor către reţelele direct conectate, flagul G nu este setat; pentru toate celelalte rute este setat. D - Arată faptul că ruta respectivă a fost adăugată în urma unui mesaj ICMP de redirecţionare. Când un sistem află despre o rută printr-un mesaj ICMP de redirecţionare, adaugă această rută în tabela sa, astfel încât pachetele către acea destinaţie nu trebuie să fie redirecţionate. Sistemul foloseşte flagul D pentru a marca aceste rute.

Ref - Arată de câte ori va încerca routerul să stabilească o conexiune. Use - Numărul de pachete transmise prin routerul respectiv. Interface - Numele interfeţei de reţea ce este folosită de către o anumită rută.

Tabela de rutare a unui host:

Destination Netmask Gateway Flags Ref Use Interface 127.0.0.1 255.255.255.255 127.0.0.1 UH 1 298 eth0 192.1.1.0 255.255.255.0 192.1.1.1 U 6 73723 eth0 192.1.2.0 255.255.255.0 192.1.1.3 UG 4 5325 Default 0.0.0.0 192.1.1.1 UG 2 53627

Prima linie din tabelă este o rută de tip loopback a hostului local. Acestă adresă de loopback este rezervată. Pentru că fiecare sistem foloseşte rute de loopback pentru a-şi trimite datagrame, aceste linii apar în toate tabelele de rutare ale hosturilor. Flagul H este setat deoarece este vorba de ruta către un anumit host (127.0.0.1) şi nu ruta către întreaga reţea (127.0.0.0) Altă linie unică în tabela de rutare este intrarea ce conţine cuvântul default în câmpul detinaţiei. Această linie este pentru ruta default, iar gateway-ul specifiact în această linie, este gateway-ul implicit (default). Ruta default este un număr de reţea rezervat: 0.0.0.0. Gateway-ul default este folosit ori de câte ori în tabela de rutare nu se găseşte nici o rută către o anumită adresă de reţea destinaţie. De exemplu, tabela de rutare de mai sus nu are nici o rută către reţeaua 192.1.4.0. Dacă router-ul primeşte o datagramă adresată acestei reţele, va trimite datagrama către gateway-ul 192.1.1.1

Din tabela de mai sus se poate vedea că acest host este direct conectat la reţeaua 192.1.1.0. Ruta către acestă reţea din tabela de rutare nu specifică folosirea unui gateway extern, adică, în tabela de rutare pentru ruta spre 192.1.1.0 nu este setat flagul G. În consecinţă, acest calculator trebuie să fie direct conectat la această reţea.

13

Toate gateway-urile ce apar într-o tabelă de rutare sunt în reţelele direct conectate la sistemul local. În exemplul de mai sus, acest lucru înseamnă că în afara adreselor destinaţie, toate adresele de gateway încep cu 192.1.1. Aceasta este singura reţea la care calculatorul respectiv este direct conectat, si în consecinţă este singura reţea către care poate trimite date în mod direct. Gateway-urile pe care acest calculator le va folosi pentru a comunica cu restul Internetului trebuie să fie în subreţeaua sa.

În figura 3.1 nivelul IP al fiecărui host şi gateway dintr-o reaţea imaginară este înlocuit cu o mică parte din tabela de rutare, în care se văd reţelele destinaţie şi gateway-urile folosite pentru comunicarea cu aceste destinaţii. Când hostul sursă (192.1.1.1) trimite date către hostul destinaţie (192.1.2.1), trebuie mai întâi să determine dacă adresa acestuia se află între adresele reţelei locale şi să aplice masca de subreţea.

191.1.2.1 AND 255.255.255.0 = 191.1.2.0

După aplicarea măştii de subreţea, IP va şti că adresa reţelei destinaţie este 192.1.2.0. Conform tabelei de rutare a hostului sursă, datele către 192.1.2.0 trebuie trimise către gateway-ul 192.1.1.2. Gateway-ul 192.1.1.2 va face livrarea direct prin intrefaţa 192.1.2.2. Examinând tabelel de rutare se observă că toate sistemele afişează numai gateway-urile reţelelor la care sunt direct conectate. De remarcat că 192.1.1.3 este gateway-ul default şi pentru 192.1.1.1 şi pentru 192.1.1.2. Dar pentru că 192.1.2.1 nu e conectat direct cu reţeaua 192.1.1.0, are un alt gateway pentru ruta default.

Figura 3.1: Procesul de rutare

O tabelă de rutare nu conţine rute de tip “end-to-end” (nu descrie toată calea de la sursă la destinaţie). De-a lungul căii către reţeaua destinaţie, rutele conţin indicaţii referitoare numai

14

la gateway-ul următor, numit “next hop”. În vederea transmiterii datelor, un host se bazează pe gateway-ul local, iar un gateway se bazează pe alte gateway-uri. Deoarece o datagramă este transferată de la un gateway la altul, ar trebui eventual să ajungă în final la un gateway conectat direct la reţeaua destinaţie. Acesta este este gateway-ul final care va livra datele către hostul destinaţie.

4. Rutare dinamică

Rutare dinamică are loc atunci când router-ele discută cu router-ele adiacente informându-se reciproc asupra reţelelor la care este conectat fiecare dintre ele. Router-ele trebuie să comunice folosind un protocol de rutare. Într-un sistem cum este Internetul sunt folosite diverse protocoale de rutare. Internetul este organizat sub forma unei colecţii de sisteme autonome (Automonous System-AS), fiecare fiind administrat de către o singură organizaţie. De multe ori, o corporaţie sau un campus universitar definesc un sistem autonom. De exemplu, backbone-ul NSFNET formează un sistem autonom, deoarece toate rutele din acest backbone se află sub un control administrativ unic. În cadrul fiecărui sistem autonom poate fi selectat propriul protocol de rutare ce asigură comunicaţia între router-ele din cadrul respectivului AS. Acesta este numit “interior gateway protocol” (IGP) sau “intradomain routing protocol”. Cel mai popular IGP a fost “Routing Information Protocol” (RIP). Un protocol de tip IGP mai nou este “Open Shortest Path First” (OSPF). Acesta a fost dezvoltat cu intenţia de a înlocui protocolul RIP. În prezent, în Internet sunt utilizate ambele protocoale în funcţie de condiţiile specifice ale fiecărui AS.

O altă categorie de protocoale de rutare este “Exterior Gateway Protocols” (EGP) sau “Interdomain Routing Protocol”. Aceste protocoale sunt utilizate pentru comunicaţia între router-e aparţinând unor AS-uri diferite. Din punct de vedere istoric, protocolul de tip EGP predominant a fost protocolul cu acelaşi nume: EGP (lucru ce poate da naştere uneori la confuzii). Un protocol de tip EGP mai nou este “Border Gateway Protocol” (BGP) ce a fost dezvoltat cu intenţia de a înlocui EGP (lucru care s-a produs în mare măsură).

Succesul unei rutări dinamice depinde de 2 funcţii de bază ale unui router:

- actualizarea tabelei de rutare, - distribuirea periodică a cunoştinţelor către alte router-e sub forma informaţiilor de rutare actualizate.

Rutarea dinamică se bazează pe un protocol de rutare în vederea partajării informaţiilor între router-e. Un protocol de rutare defineşte un set de reguli folosit de un router pentru a comunica cu router-ele vecine. De exemplu, un protocol de rutare descrie:

- cum să se transmită actualizările, - ce informaţie este conţinută în aceste actualizări, - când să se transmită această informaţie, - cum să fie localizaţi destinatarii actualizărilor.

Atunci când un algoritm de rutare actualizează o tabelă de rutare, obiectivul principal este de a determina cea mai bună informaţie ce trebuie inclusă în tabela de rutare. Fiecare algoritm de rutare interpretează acest lucru în mod propriu. Algoritmul generează un număr, numit metrică, pentru fiecare cale prin reţea. De obicei, cu cât valoarea metricei este mai mică cu atât calea corespunzătoare este mai bună. Algoritmii de rutare folosesc diverse metrici în

15

vederea determinării rutei optime. Algoritmii de rutare complecşi pot utiliza mai multe metrici în vederea selectării rutei optime, combinând aceste metrici într-o metrică hibridă. Exemplu de metrici folosite:

- lungimea căii (numărul de hop-uri), - fiabilitatea, - întârzierea, - capacitatea de trafic, - încărcarea, - costul comunicaţiei.

Lungimea căii este metrica cea mai des folosită. Unii algoritmi de rutare permit administratorilor de reţea să asigneze costuri arbitrare fiecărei conexiuni din reţea. În acest caz, lungimea căii este suma costurilor asociate fiecărei conexiuni ce este traversată. Alte protocoale de rutare definesc metrica “hop count” (numărul de hop-uri) ce specifică numărul de treceri prin echipamente de intreconectare de reţele (cum ar fi router-ele) pe care un pachet trebuie să le realizeze în drumul său de la sursă până la destinaţie.

Fiabilitatea, în contextul algoritmilor de rutare se referă la rata de biţi eronaţi a fiecărei conexiuni de reţea. Unele conexiuni pot avea întreruperi mai des decât altele. După o întrerupere a unei conexiuni, timpul de repunere în funcţiune a acesteia poate fi mai mic decât în cazul altei conexiuni. În vederea asignării valorii corespunzătoare fiabilităţii fiecărei conexiuni, pot fi luaţi în calcul orice factori ce influenţează fiabilitatea. Aceste valori sunt de tip numeric şi sunt asignate de către administratorii de reţea.

Întârzierea se referă la perioada de timp necesară pentru transferul unui pachet de la sursă la destinaţie. Întârzierea depinde de mulţi factori, incluzând capacitatea de trafic a conexiunilor intremediare, cozile de aşteptare la fiecare router prin care trec pachetele, congestia unor conexiuni intermediare şi distanţa fizică ce trebuie parcursă. Deoarece întârzierea cumulează câteva variabile importante, este o metrică foarte utilizată şi utilă.

O caracteristică a oricărei conexiuni o reprezintă capacitatea de trafic disponibilă. Dacă ceilalţi factori sunt echivalenţi, atunci o conexiune Ethernet de 10Mbps este de preferat unei conexiuni pe linie telefonică închiriată de 64Kbps. Deşi capacitatea de trafic depinde de debitul maxim al unei conexiuni, rutele prin conexiuni cu capacitate de trafic mai mare nu sunt neapărat mai bune decât rutele prin conexiuni mai lente. De exemplu, în cazul în care o conexiune mai rapidă este foarte încărcată, timpul necesar pentru transmiterea unui pachet prin acestă conexiune poate fi mai mare decât în cazul utilizării unei conexiuni cu o capacitate de trafic mai mică, dar lipsită de încărcare.

Încărcarea reprezintă gradul de ocupare a unei resurse de reţea (cum ar fi router-ul). Încărcarea poate fi calculată în diverse moduri, cum ar fi gradul de utilizare al CPU sau numărul de pachete prelucrate pe secundă. Monitorizarea continuă a acestor parametrii poate duce ea însăşi la creşterea încărcării.

Costul comunicaţiei este o altă metrică importantă, în special din cauza faptului că unele companii acordă mai puţină importanţă performanţelor decât costurilor de operare. Cu toate că întârzierile pot fi mai mari, aceştia preferă să utilizeze propriile linii de comunicaţii în locul liniilor publice pentru care se plăteşte în funcţie de durata utilizării acestora.

16

Majoritatea algoritmilor de rutare pot fi încadraţi într-una din următoarele categorii:

- “distance vector” (vector distanţă), - “link state” (starea conexiunii).

Algoritmii de rutare de tip “distance vector” determină direcţia (vectorul) şi distanţa către oricare conexiune din reţea. Algoritmii de tip “link state” (numiţi de asemenea “shortest path first” – întâi calea cea mai scurtă) recreează topologia exactă a întregii reţele (sau cel puţin a porţiunii din reţea în care se află situat router-ul).

Algoritmii de rutare hibrizi combină aspecte ale celor 2 tipuri de algoritmi menţionaţi anterior.

Algoritmul de rutare este fundamental pentru rutarea dinamică. De câte ori o topologie a unei reţele se modifică din cauza extinderii, reconfigurării sau defecţiunilor, baza de informaţii referitoare la reţea trebuie de asemenea modificată. Informaţiile trebuie să reflecte o proiecţie clară şi consistentă a noii topologii. Această proiecţie este numită convergenţă. Când toate router-ele dintr-o reţea operează cu aceeaşi bază de informaţii se spune că reţeaua este convergentă. O caracteristică dorită pentru orice reţea o reprezintă convergenţa rapidă a acesteia, deoarece acesta reduce perioada de timp în care router-ele ar putea lua decizii incorecte.

4.1 Protocoale de rutare de tip “distance vector”

Algoritmul fundamental bazat pe vectorul distanţă încearcă să rezolve problema alegerii căii către o anumită destinaţie folosind cel mai mic număr posibil de hop-uri. Se consideră un hop orice trecere printr-un nod. Astfel, în reţeaua din exemplul de mai jos, distanţa de la router-ul A la reţeaua D este 3.

Figura 4.1 Distanţa de la un router la destinaţie

Problema devine mai interesantă în cazul în care reţeaua nu se întinde de-a lungul unei linii. De exemplu, distanţa dintre router-ul A şi reţeaua D în exemplul următor de reţea (fig. 4.2) poate fi 3, 4, 5 sau 6.

17

Figura 4.2 Calea cea mai scurtă

În acest exemplu, calea care este de dorit a fi urmată este de la A la B apoi la C şi apoi la D. Găsirea acestei căi este asigurată de algoritmii Bellman-Ford sau Dijkstra. Apoi, fiecare nod din reţea va fi înştiinţat de calea cea mai scurtă de la el însuşi la fiecare din celelalte noduri ale reţelei.

Există mai multe moduri de abordare a problemei de găsire a celei mai scurte căi. O metodă utilă de clasificare a acestor abordări este pe baza tipului de informaţii necesare a fi schimbate între gateway-uri pentru ca acestea să fie capabile să găsească aceste rute. Algoritmii bazaţi pe vectorul distanţă se bazează pe schimbul unei cantităţi mici de informaţii. Fiecare entitate (gateway sau host) care participă la acest protocol de rutare se presupune că păstrează informaţii despre toate destinaţiile din interiorul sistemului. În general, informaţia despre toate destinaţiile posibile dintr-o reţea se rezumă la o singură intrare, care descrie ruta către toate destinaţiile din acea reţea. Acest lucru este posibil deoarece atât timp cât rutarea se face la nivel IP, rutarea în interiorul unei reţele este invizibilă. Fiecare linie (intrare) din tabela de rutare include gateway-ul următor către care datagramele destinate unei alte reţele vor trebui trimise. În plus, mai este trecută şi o măsură “metrică” a distanţei către destinaţie. Această distanţă este oarecum un concept generalizat, care poate caracteriza întârzierea în trimiterea mesajelor către acea entitate, costul trimiterii mesajului, etc. Algoritmii bazaţi pe vectorul distanţă sunt numiţi astfel din cauza faptului că e posibil să găsească o cale optimă atunci când singura informaţie schimbată este lista cu aceste distanţe. Mai mult decât atât, informaţia este schimbată între entităţi adiacente, adică entităţi care aparţin aceleeaşi reţele.

4.1.1 RIP: Protocolul bazat pe informaţii de rutare

RIP este un protocol dintr-o serie de protocoale de rutare bazate pe algoritmul Bellman-Ford (sau vectorul distanţă). Acest algoritm a fost folosit pentru aflarea rutelor în reţelele de calculatoare încă de la începutul ARPANET-ului. Acest protocol este mai util ca “protocol de gateway interior”. Într-o reţea vastă, aşa cum este Internetul, ar fi dezavantajos să fie folosit un singur protocol de rutare. Mai curând, reţeaua ar trebui să fie organizată ca o colecţie de “sisteme autonome”. Un sistem autonom este în general administrat de o singură entitate (organizaţie), sau cel puţin de către cineva cu

18

competenţe rezonabile pentru controlul administrativ şi tehnic. Fiecare sistem autonom va avea propria tehnologie de rutare. Acestă tehnologie poate fi diferită de la un sistem autonom la altul. Protocolul de rutare folosit în cadrul unui sistem autonom este un protocol tip interior sau “IGP” (Interior Gateway Protocol). Un alt tip de protocol este folosit pentru interfaţa dintre sistemele autonome. Cel mai vechi astfel de protocol şi care mai este încă folosit în Intrenet este “EGP” (Exterior Gateway Protocol - protocol de tip exterior). Acest tip de protocoale se mai numesc protocoale de rutare inter-AS. RIP a fost dezvoltat pentru reţele de dimensiuni moderate şi care folosesc tehnologii omogene. El este potrivit ca IGP pentru campusuri şi reţele regionale ce folosesc linii seriale a căror viteză nu variază foarte mult. Nu este recomandat a fi utilzat în medii mai complexe. RIP face parte din clasa de algoritmi numită “algoritmi bazaţi pe vector distanţă”. Cea mai veche descriere a acestei clase de algoritmi de către autori cunoscuţi este aceea făcută de Ford şi Fulkerson. Din această cauză mai sunt numiţi şi algoritmi Ford-Fulkerson. Termenul Bellman-Ford este de asemenea utilizat, deoarece aceşti algoritmi folosesc ecuaţia Bellman, ecuaţie care este baza “programării dinamice”.

RIP a fost dezvoltat pentru a fi folosit în Internet. Intrenetul constă dintr-un număr de reţele conectate prin gateway-uri. Reţelele componente pot fi cu legături de tip point-to-point fie reţele mai complexe cum sunt Ethernet sau ARPANET. Hosturile şi gateway-urile oferă datagrame IP adresate unui anumit host. Rutarea este metoda prin care host-ul sau gateway-ul decide unde anume trimite datagramele. E posibil să poată trimite datagrama direct către destinaţie, dacă acestă destinaţie este în reţeaua la care este direct conectat host-ul sau gateway-ul. Interesantă este situaţia în care destinaţia nu poate fi atinsă în mod direct. În acestă situaţie, host-ul sau gateway-ul încearcă să trimită datagrama la un gateway care se află cât mai aproape de destinaţie. Scopul unui protocol de rutare este deci foarte simplu: furnizarea informaţiei necesare în vederea rutării.

4.1.1.1 Limitările protocolului

Acest protocol nu rezolvă toate problemele posibile de rutare. Aşa cum am menţionat mai sus, intenţia primară a fost pentru folosirea acestuia ca IGP în reţele de dimensiuni mici şi relativ omogene. Trebuie menţionate în plus următoarele limitări ale acestuia:

• Protocolul este limitat pentru reţele a căror cea mai lungă rută (cale) are 15 hopuri. Acest protocol, prin modul în care a fost proiectat, nu este potrivit pentru reţele mai mari. De remarcat că acestă afirmaţie referitoare la limită presupune că pentru fiecare conexiune este folosit un cost de valoare 1. Aceasta este metoda prin care RIP-ul este configurat în mod normal. Dacă administratorul de sistem alege să utilizeze costuri mai mari, limita superioară de 15 devine o problemă.

• Acest protocol se bazează pe “numărarea la infinit” pentru rezolvarea anumitor situaţii speciale. (Acest lucru va fi explicat în capitolul următor). Dacă sistemul de reţele cuprinde câteva sute de reţele şi se formează o buclă de rutare, rezolvarea acestei bucle va necesita mult timp (dacă frecvenţa actualizărilor de rute este limitată) sau lărgime de bandă mare. O astfel de buclă va consuma mult din lărgimea de bandă a reţelei înainte ca bucla să fie corectată. Se presupune că în situaţiile reale aceasta nu va fi o problemă cu excepţia cazurilor în care sunt folosite linii lente. Chiar şi aşa, problema va fi una specială, atâta timp cât sunt luate diferite precauţii pentru prevenirea unor astfel de probleme în majoritatea cazurilor.

19

• Acest protocol foloseşte “metrice” fixe pentru compararea rutelor alternative. Acest lucru nu este potrivit pentru cazurile în care rutele trebuie să fie alese ţinând cont de parametrii de timp real, cum ar fi întârzierea, fiabilitatea sau încărcarea.

4.1.1.2 Specificaţiile protocolului

RIP permite host-urilor şi gateway-urilor să schimbe informaţii pentru a putea găsi rute într-o reţea bazată pe IP. RIP este protocol bazat pe vectorul distanţă (de tip “distance vector”). Poate fi implementat şi de host şi de gateway. Ca în majoritatea documentaţiilor IP, termenul de “host” va fi folosit aici pentru a le defini pe oricare dintre ele. RIP este folosit pentru a comunica informaţii cu privire la rute către “destinaţii”, care pot fi host-uri individuale, reţele, o destinaţie specială folosită pentru a comunica o rută implicită (default). Orice host care foloseşte RIP este de aşteptat să aibă interfeţe către una sau mai multe reţele. Acestea sunt referite ca reţele direct conectate la el. Protocolul se bazează pe accesul la anumite informaţii despre fiecare din aceste reţele. Cea mai importantă este metrica sau costul. Metrica unei reţele este un număr întreg între 1 şi 15 inclusiv. El este setat într-o anumită manieră care nu este specificată în acest protocol. Cele mai multe din implementările existente folosesc o metrică de valoare 1. Implementările mai noi permit administratorului de sistem să seteze costul pentru fiecare reţea. În plus faţă de cost, fiecare reţea va avea o adresă IP de reţea şi o mască de subreţea asociată. Acestea sunt setate de către administrator într-o manieră nespecificată de acest protocol. Se presupune că există o singură mască de subreţea ce se aplică pentru fiecare reţea IP, şi o singură mască de subreţea pentru reţelele direct conectate. Există sisteme ce folosesc măşti de subreţea diferite pentru subreţele diferite aparţinând unei anumite reţele. De asemenea, există situaţii în care este de preferat pentru un sistem să cunoască măştile subreţelelor aparţinând unor reţele aflate la distanţă. Astfel de situaţii necesită modificări ale regulilor ce guvernează modul de răspândire a informaţiilor de subreţea. Astfel de modificări cresc posibilităţile de interoperabilitate şi trebuie avute în vedere ca modificări ale protocolului. Se consideră că fiecare host care are implementat RIP are o tabelă de rutare. Această tabelă conţine câte o intrare (linie), descrisă prin RIP, pentru fiecare destinaţie care poate fi atinsă. Fiecare intrare conţine cel puţin informaţiile următoare:

• Adresa IP a destinaţiei • O metrică, ce reprezintă costul total al transmiterii datagramei de la host la acea destinaţie. Acestă metrică este suma costurilor associate cu reţelele care vor fi traversate în drumul până la destinaţie.

• Adresa IP a gateway-ului următor de-a lungul căii către destinaţie. Dacă destinaţia este în una dintre reţelele direct conectate, această informaţie nu este necesară.

• Un flag care indică dacă acea informaţie privind ruta a fost modificată recent. Se mai numeşte "route change flag."

• Diferiţi timpi asociaţi cu ruta respectivă. Intrările referitoare la reţelele direct conectate sunt setate de către host, folosind diverse informaţii culese, nespecificate în acest protocol. Metrica pentru o reţea direct conectată este setată la costul acelei reţele. În implementările RIP existente, pentru acest cost este folosită totdeauna valoarea 1. În acest caz, metrica RIP se reduce la o simplă numărare de hop-uri.

20

Metrici mai complexe pot fi folosite atunci când se doreşte evidenţierea preferinţei pentru o anumită reţea faţă de altele, de exemplu din cauza diferenţelor privind lărgimea de bandă sau siguranţa acelei reţele. Exsită de asemenea posibilitatea de a permite administratorului de sistem să adauge rute adiţionale. Rutele către alte destinaţii decât cele iniţiale sunt adăugate şi updatate de algoritmii descrişi în capitolele următoare. Pentru ca un protocol să asigure informaţii de rutare complete, fiecare gateway din system trebuie să participe la aceasta. Host-urile care nu sunt gateway-uri nu participă, dar multe implementări ale acestui algoritm permit host-urilor să recepţioneze informaţiile transmise prin RIP pentru a-şi actualiza tabelele de rutare.

4.1.1.3 Formatul mesajului

RIP este un protocol bazat pe UDP. Fiecare host care foloseşte RIP are un process de rutare care trimte şi primeşte datagrame pe portul UDP cu numărul 520. Toate mesajele transmise prin RIP către un alt host, sunt trimise către portul 520. Toate mesajele de actualizare de rute sunt trimise pe portul 520. Mesajele de actualizare de rute nesolicitate au ambele porturi sursă şi destinaţie, 520. Ceea ce se trimite ca răspuns la o cerere se trimite către portul de la care a venit cererea. Interogările specifice şi mesajele de tip debug trebuie să fie trimise de la alte porturi decât 520, dar ele vor fi direcţionate către portul 520 al maşinii ţintă.

Figura 4.3. Formatul pachetului (RIP versiunea 1) Formatul pachetului este evidenţiat în figura 4.3. Porţiunea din datagramă de la address family identifier până la metric poate apărea de până la 25 de ori. Adresa IP (IP address) este adresa Internet obişnuită (versiunea 4) pe 32 de biţi. În protocol este prevăzută şi facilitatea de a permite procese RIP în starea de ascultare "silent RIP". Un process silent este unul care în mod normal nu trimite nici un mesaj. Cu toate acestea, el ascultă mesajele trimise de alte procese. Un silent RIP poate fi folosit de host-uri

21

care nu funcţionează ca gateway-uri, dar care doresc să asculte actualizările privind rutele în vederea monitorizării gateway-urilor locale şi a actualizării tabelelor de rutare interne. Un gateway care a pierdut legătura cu toate celelalte mai puţin cu una din reţelele sale, poate alege să devină de tip silent, moment din care el nu mai este efectiv gateway. Oricum, acest lucru nu se va întâmpla dacă există posibilitatea ca gateway-urile vecine să depindă de mesajele sale pentru a detecta dacă reţeaua “căzută” va redeveni operaţională. Fiecare datagramă conţine o comandă, un număr de versiune şi posbil argumente. Mai jos este descrisă versiunea 1 a acestui protocol. Câmpul command este folosit pentru a specifica scopul datagramei. În tabelul de mai jos sunt prezentate câteva comenzi implementate în versiunea 1:

1 - request O cerere ca sistemul repondent să transmită o parte sau întreaga tabelă de

rutare.

2 - response

Un mesaj ce conţine toată sau numai o parte din tabela de rutare a

expeditorului. Acest mesaj poate fi trimis ca răspuns la o cerere (request),

sau poate fi un mesaj de actualizare generat de expeditor.

3 - traceon Învechit. Mesajele conţinând această comandă vor fi ignorate.

4 - traceoff Învechit. Mesajele conţinând această comandă vor fi ignorate.

5 - reserved

Această valoare este folosită de Sun Microsystems pentru scopuri personale.

Dacă noi comenzi sunt adăugate în oricare din versiunile următoare, acestea

trebuie să înceapă cu 6. Mesajele conţinând această comandă pot fi ignorate

de implementările care aleg să nu răspundă la ele.

Pentru cerere şi răspuns, restul datagramei conţine o listă de destinaţii cu informaţii despre fiecare. Fiecare intrare din această listă conţine o reţea sau un host destinaţie şi metrica pentru ele. Formatul pachetului este făcut pentru a permite RIP să transporte informaţii de rutare pentru câteva protocoale diferite. Astfel, fiecare intrare are un câmp address family identifier pentru a indica ce tip de adresă este specificată în intrarea respectivă. Acest curs descrie numai rutarea în cazul reţelelor IP. Valoarea address family identifier pentru IP este 2. Totuşi, pentru a permite dezvoltarea ulterioară, implementările sunt obligate să ignore intrările care conţin tipuri de adrese ce nu sunt suportate. (Dimensiunea acestor intrări trebuie să fie aceeaşi ca dimensiunea unei intrări ce specifică o adresă IP). Procesarea mesajului continuă în mod normal după ce au fost ignorate toate intrările ce nu sunt suportate. Adresa IP este adresa Internet obişnuită, memorată pe 4 octeţi. Câmpul metrică trebuie să conţină o valoare cuprinsă între 1 şi 15 inclusiv, prin care se specifică metrica curentă pentru destinaţie, sau valoarea 16, ceea ce va indica faptul că destinaţia nu poate fi atinsă. Fiecare rută trimisă de un gateway suprascrie orice rută anterioară trimisă de la acelaşi gateway către aceeaşi destinaţie. Dimensiunea maximă a datagramei este 512 octeţi. Aceştia includ numai porţiunea din datagramă descrisă mai sus. Nu este contorizată şi dimensiunea header-ului IP sau UDP. Comenzile ce conţin informaţii de reţea permit informaţiilor să fie împărţite în mai multe datagrame. Nu sunt necesare măsuri speciale pentru continuare, atâta timp cât se obţin rezultate corecte în urma procesării individuale a datagramelor.

22

Formatul pachetului RIP 2

Specificaţia pentru RIP 2 (descrisă în RFC 1723) permite includerea multor informaţii în pachetele RIP şi asigură un mecanism de autentificare simplu care nu este suportat de către RIP. Figura 4.4 reprezintă formatul pachetului IP RIP 2.

1-octet command field

1-octet version number field

2-octet unused field

2-octet AFI field

2-octet route tag field

4-octet network address field

4-octet subnet mask field

4-octet next hop field

4-octet metric field

Figura 4.4 Formatul pachetului RIP 2

Câmpurile ce alcătuiesc pachetul IP RIP 2 din figura de mai sus sunt următoarele:

• Command — Indică dacă pachetul este un pachet cerere sau un pachet răspuns. Un pachet de tip cerere întreabă dacă un router a trimis o parte sau toată tabela sa de rutare. Un pachet de tip răspuns poate fi un mesaj de actualizare de rute obişnuit nesolicitat sau poate fi un răspuns la o cerere. Răspunsurile conţin linii ale tabelei de rutare. Pachetele RIP multiple sunt folosite pentr a aduna informaţii din tabele mari de rutare.

• Version —Specifică versiunea de RIP folosită. Într-un pachet RIP ce conţine oricare din câmpurile RIP 2 sau foloseşte autentificare, această valoare este setată la 2.

• Unused — Setat 0. • Address-family identifier (AFI) — Specifică ce familie de adrese este folosită. Câmpul AFI din RIPv2 are acelaşi rol ca şi câmpul AFI din RFC 1058 RIP, cu o singură excepţie: dacă AFI pentru prima linie din mesaj este 0xFFFF, restul liniei conţine informaţii de autentificare. În mod obişnuit, singurul tip de autentificare este o simplă parolă.

• Route tag — Asigură metoda de a face diferenţa dintre rutele interne (învăţate de RIP) şi rutele externe (învăţate de la alte protocoale)

• IP address — Specifică adresa IP corespunzătoare liniei. • Subnet mask — Conţine masca de subreţea corespunzătoare acestei linii. Dacă acest câmp este 0, nici o mască de subreţea nu este specificată pentru linia respectivă.

• Next hop —Indică adresa IP a următorului hop către care trebuie trimise pachetele corespunzătoare acelei linii.

• Metric —Specifică câte hopuri (router-e) sunt traversate în drumul spre destinaţie. Valoarea pentru acest câmp este cuprinsă între 1 şi 15 pentru rutele valide şi este 16 pentru o rută necunoscută.

4.1.1.4 Consideraţii privind adresarea

Aşa cum am stabilit anterior, rutarea bazată pe vectorul distanţă este folosită pentru a descrie rute spre host-uri individuale sau spre reţele. Protocolul RIP permite oricare din cele 2 variante. Destinaţiile ce apar în mesaje de cerere sau de răspuns pot fi reţele, host-uri sau un cod special folosit pentru a indica ruta implicită (default). În general, tipul de rută folosit va depinde de strategia de rutare utilizată pentru o reţea particulară. Multe reţele sunt configurate astfel încât aceste informaţii de rutare pentru host-uri individuale nu sunt necesare. Dacă

23

fiecare host dintr-o anumită reţea sau subreţea este accesibil prin intermediul aceluiaşi gateway, atunci nu este nici un motiv pentru a menţiona host-urile individuale în tabelele de rutare. Cu toate acestea, reţelele care includ linii de comunicaţie punct la punct, necesită câteodată ca gateway-urile să păstreze rute către anumite host-uri. Dacă acest lucru este cerut sau nu, depinde de modul de adresare şi de rutare folosit în sistemul respectiv. Astfel, unele implementări pot alege să nu accepte rute către host-uri. Dacă nu sunt acceptate rute către host-uri, acestea vor fi ignorate atunci când sunt primite în mesajele de răspuns. Formatele pachetului RIP nu fac deosebire între diferitele tipuri de adrese. Câmpurile care au eticheta “address” pot conţine:

� Adresa hostului - host address � Adresa subreţelei - subnet number � Adresa reţelei - network number � 0, indicând ruta implicită (default)

Entităţile care folosesc RIP utilizează informaţiile specifice ce sunt disponibile când rutează o datagramă. Aceasta înseamnă că, atunci când are loc rutarea unei datagrame, adresa sa destinaţie trebuie mai întâi verificată în lista de adrese de hosturi. Apoi se verifică dacă se potriveşte cu vreo adresă de reţea sau subreţea. În final, dacă nu există nici o potrivire, se va folosi ruta default. Când un host evaluează informaţiile primite prin RIP, interpretarea unei adrese depinde dacă se cunoaşte masca de subreţea ce trebuie aplicată. Dacă se cunoaşte masca de subreţea atunci se poate determina semnificaţia adresei respective. De exemplu, fie reţeaua 128.6.0.0. Masca de subreţea este 255.255.255.0. Astfel, 128.6.0.0 este o adresă de reţea, 128.6.4.0 este o adresă de subreţea şi 128.6.4.1 este adresa unui host. Cu toate acestea, dacă host-ul nu cunoaşte masca de subreţea, determinarea unei adrese poate fi ambiguă. Deoarece dacă într-o adresă există o parte diferită de 0 pentru host, nu este o metodă clară pentru a determina dacă adresa reprezintă un număr de subreţea sau o adresă de host. Aşa cum adresa de reţea nu este de folos fără masca de subreţea, se presupune că în această situaţie adresele reprezintă host-uri. Pentru a evita acest gen de ambiguităţi, host-urile nu trebuie să trimită rute de subreţele host-urilor care se ştie că nu cunosc măşti potrivite de subreţele. În mod normal, host-urile cunosc numai măşti de subreţea pentru reţelele direct conectate. De aceea, mai puţin în situaţia în care s-a prevăzut acest lucru, nu trebuie trimise rute către subreţele în afara reţelei din care face parte subreţeaua respectivă. Această filtrare este asigurată de gateway-urile aflate la “graniţa” reţelei de subreţele. Acestea sunt gateway-uri ce conectează reţeaua cu alte reţele. În această reţea de subreţele, fiecare subreţea este tratată ca o reţea individuală. Rutele către fiecare subreţea sunt transportate de către RIP. Cu toate acestea, gateway-urile de graniţă trimit numai o intrare (rută) pentru reţea ca şi pentru toate host-urile din alte reţele. Acest lucru înseamnă că un gateway de graniţă va trimite informaţii diferite către vecini diferiţi. Pentru vecinii conectaţi la reţeaua de subreţele, va fi generată o listă cu toate subreţelele la care acesta este direct conectat, folosind adresa de subreţea. Pentru vecinii conectaţi la alte reţele, va fi trimisă o singură intrare (rută) pentru reţea ca un tot, arătând şi metrica asociată acestei reţele. (Această metrică ar trebui să fie cea mai mică metrică pentru subreţelele la care gateway-ul este conectat). În mod asemănător, gateway-urile de graniţă nu trebuie să menţioneze în mesajele către alte reţele, rutele către host-uri pentru host-urile ce aparţin unei reţele direct conectate. Acele rute

24

trebuie să fie subsumate într-o singură intrare (rută) către reţea ca întreg. Nu am specificat ce se întâmplă cu rutele către host-uri pentru host-urile aflate la distanţă (adică host-uri ce nu fac parte din reţelele direct conectate). În general, aceste rute indică anumite host-uri la care se ajunge folosind o rută care nu suportă alte host-uri din reţeaua din care face parte host-ul respectiv. Adresa specială 0.0.0.0 este folosită pentru ruta default. O rută default este folosită atunci când nu este convenabil să se facă o listă cu toate reţelele posibile într-o actualizare RIP, şi când unul sau mai multe gateway-uri strâns conectate (closely-connected) din sistem sunt pregătite să se ocupe de traficul spre reţelele ce nu sunt explicit specificate. Aceste gateway-uri trebuie să creeze intrări RIP pentru adresa 0.0.0.0, ca şi cum ar fi o reţea la care sunt conectate. Decizia felului în care sunt create aceste intrări pentru reţeaua 0.0.0.0 este lăsată celui care face implementarea. Cel mai adesea, administratorul de sistem va avea o metodă pentru a specifica ce gateway va crea intrări pentru 0.0.0.0. Sunt posibile, însă şi alte mecanisme. De exemplu, cel care face implemantarea, poate lua decizia ca orice gateway care înţelege EGP trebuie să fie declarat ca gateway default. Ar putea fi util să se permită administratorului de reţea să aleagă metrica ce va fi folosită în aceste intrări. Dacă există mai mult de un gateway default, această metrică va face posbilă alegerea unuia faţă de altul. Intrarea pentru 0.0.0.0 revine în sarcina RIP-ului în exact aceeaşi manieră ca şi când ar fi vorba de o reţea având această adresă. Oricum, intrarea este folosită pentru a ruta orice datagramă a cărei adresă destinaţie nu se potriveşte nici unei reţele care apare în tabela de rutare. Nu este obligatorie aplicarea acestei convenţii în implementare dar acest lucru este recomandat. Implementările care nu suportă 0.0.0.0 trebuie să ignore intrările cu această adresă. În astfel de situaţii nu vor include aceste intrări în propriile actualizări RIP. Administratorii de sistem trebuie să se asigure că rutele 0.0.0.0 nu vor fi transmise mai departe decât în mod intenţionat. În general, fiecare sistem autonom, are propriul gateway default. Astfel, rutele cu 0.0.0.0 nu trebuie să treacă de graniţa sistemului autonom. Mecanismul care se ocupă cu acest lucru nu este abordat în curs.

4.1.1.5 Ceasuri (Timer-e)

Acest capitol descrie toate evenimentele ce sunt declanşate de ceasuri. La fiecare 30 de secunde, procesul de ieşire este configurat să genereze un răspuns complet către fiecare gateway vecin. Când sunt multe gateway-uri într-o singură reţea, apare tendinţa ca acestea să se sincronizeze unul cu altul astfel încât îşi trimit actualizările în acelaşi timp. Acest lucru se întâmplă atunci când timer-ul de 30 de secunde este afectat de încărcarea sistemului. Nu este de dorit ca mesajele de actualizare să se sincronizeze deoarece pot apărea coliziuni. Astfel, în implementări trebuie să se aibă în vedere următoarele precauţii:

• actualizările la 30 de secunde sunt declanşate de un ceas ce nu trebuie să fie afectat de încărcarea sistemului sau de timpul ncesitat de actualizarea precedentă;

• timer-ul de 30 de secunde este decalat prin adăugarea unui timp aleator de fiecare dată când este setat.

Sunt 2 ceasuri asociate cu fiecare rută, un “timeout” şi un “garbage-collection time” (timp de colectare a gunoiului). După expirarea timeout-ului, ruta nu mai este validă. Oricum, ea este menţinută în tabelă pentru o scurtă perioadă de timp, astfel încât vecinii să poată afla că acea rută a fost eliminată. După expirarea “garbage-collection time” ruta este ştearsă din tabelă.

25

Timeout-ul este iniţializat când este stabilită o rută şi de fiecare dată când un mesaj de actualizare este primit pentru ruta respectivă. Dacă trec 180 de secunde de la ultima iniţializare a timeout-ului, ruta este considerată expirată şi va începe procesul de ştergere. Ştergerea are loc din unul din următoarele 2 motive: (1) timeout-ul expiră, sau (2) metrica este setată la 16 din cauza unei actualizări primite de la gateway-ul curent. În fiecare din cele 2 cazuri se întâmplă următoarele:

• Timpul “garbage-collection” este setat pentru 120 de secunde. • Metrica rutei este setată la valoarea 16 (infinit). Aceasta va face ca ruta să fie ştearsă. • Este setat un fanion pentru a arăta că acestă rută a fost modificată şi procesul de ieşire este atenţionat să declanşeze un răspuns.

Până când „garbage-collection timer” expiră, ruta este inclusă în toate actualizările trimise de acest host, având o metrică de valoare 16 (infinit). Când „garbage-collection timer” expiră, ruta este ştearsă din tabelă. Va trebui ca înainte de expirarea „garbage-collection timer” să fie stabilită o nouă rută spre această reţea, rută ce o va înlocui pe cea care va fi ştearsă. În acest moment, garbage-collection timer va fi resetat.

4.1.1.6 Tratarea modificărilor topologiei

În practică, se întîlnesc situaţii în care liniile de comunicaţie se întrerup şi apoi revin. Versiunea teoretică a algoritmului implică un număr minim de vecini apropiaţi. Dacă topologia se modifică, se schimbă şi setul de vecini. Data viitoare când va fi făcut calculul, aceste modificări vor fi oglindite. Implementările actuale utilizează o versiune incrementală a minimizării. Numai cea mai bună rută pentru oricare destinaţie dată va fi reamintită. Dacă gateway-ul implicat în această rută îşi întrerupe funcţionarea sau dacă conexiunea de reţea va cădea, calculul e posbil să nu reflecte niciodată modificările. Algoritmul se bazează pe faptul că gateway-ul îşi înştiinţează vecinii dacă metricile sale se modifică. Dacă gateway-ul cade, nu există nici o cale de a anunţa vecinii despre modificare.

În ideea de a rezolva acest tip de probleme, protocoalele bazate pe vectorul distanţă trebuie să dispună de facilitatea expirării unei rute. Detaliile depind de protocolul ales. Ca un exemplu, în RIP fiecare gateway ce participă la rutare trimite un mesaj de actualizare către toţi vecinii săi la fiecare 30 de secunde. Presupunem că ruta curentă către reţeaua N foloseşte gateway-ul G. Dacă nu se primeşte nimic de la G timp de 180 de secunde, se presupune că acest gateway a căzut sau că s-a întrerupt conexiunea către acea reţea. Deci, ruta va fi marcată ca fiind invalidă. Atunci când vom afla de la un alt vecin că există o rută validă către reţeaua N, această rută validă o va înlocui pe cea invalidă. De remarcat că se aşteaptă 180 de secunde înaintea expirării rutei chiar dacă se aşteaptă mesaje de la fiecare vecin la fiecare 30 de secunde. Din păcate, câteodată mesajele se pierd în reţea. De aceea, nu este o idee bună să se invalideze o rută numai pe baza unui singur mesaj lipsă.

Aşa cum se va vedea mai departe, este util să existe modalităţi de înştiinţare a vecinilor că o anumită rută către o anumită reţea este invalidă. RIP, împreună cu alte câteva protocoale din aceaastă clasă, fac acest lucru printr-un mesaj obişnuit de actualizare, marcând acea reţea ca “unreachable” (la care nu se poate ajunge). O valoare specifică a metricei va fi aleasă pentru a indica o destinaţie de neatins; această valoare fiind mai mare decât cea mai mare metrică validă. In implementarea actuală a RIP-ului este folosită valoarea 16. Această valoare este referită ca “infinit” deoarece este mai mare decât cea mai mare valoare validă pentru o metrică. 16 poate părea totuşi un număr surprinzător de mic. Motivul pentru care a fost aleasă

26

această valoare se va vedea în continuare. În majoritatea implementărilor, aceeaşi convenţie este folosită intern pentru a marca o rută invalidă.

4.1.1.7 Numărare la infinit (Counting to infinity)

Algoritmul folosit până acum a presupus totdeauna existenţa unui host sau gateway pentru stabilirea unei tabele corecte de rutare. Cu toate acestea, nu este suficient pentru a fi folositor şi în practică. Dovezile de mai sus arată că o tabelă de rutare va converge către valorile corecte într-un interval de timp finit. Nu se garantează că acest timp va fi suficient de mic pentru a fi util şi nici nu se spune ce se va întâmpla cu metricele reţelelor ce devin inaccesibile. E relativ uşor să aplicăm metode matematice pentru tratarea rutelor ce devin inaccesibile. Convenţia de mai sus poate face acest lucru. S-a ales o metrică de valoare mare pentru a reprezenta “infinitul” Această valoare trebuie să fie suficient de mare astfel încât nici o metrică reală să nu poată avea vreodată această valoare. Pentru a exemplifica acest lucru s-a ales valoarea 16. Să presupunem că o reţea devine inaccesibilă. Toate gateway-urile din imediata vecinătate vor fi în timeout şi metrica pentru acea reţea va fi setată la valoarea 16. În scopul de a face o analiză, se va presupune că toate gateway-urile vecine au primit o piesă hard nouă care le conectează direct la reţeaua dispărută care are costul 16. Atâta timp cât aceasta este singura conexiune către reţeaua dispărută toate celelalte gateway-uri din sistem vor tinde către noi rute ce trec prin unul din aceste gateway-uri. E uşor de obesrvat că în această situaţie, toate gateway-urile vor avea metrica de valoare minim 16 către reţeaua dispărută. Gateway-urile aflate la numai un hop distanţă de vecinii iniţiali, vor avea o metrică de valoare cel puţin 17; gateway-urile aflate la 2 hopuri, cel puţin 18 etc. Atâta timp cât aceste metrici sunt mai mari decât cea mai mare valoare acceptată pentru o metrică, ele vor fi setate la 16. Este evident că în această situaţie sistemul va converge la nivelul tuturor gateway-urilor către metrica 16 spre acea reţea. Din nefericire, durata intervalului de convergenţă nu se poate stabili într-un mod foarte simplu. Înainte de a merge mai departe să analizăm următorul exemplu (figura 4.5). de remarcat că ceea ce va fi arătat în continuare nu se va întâmpla în cazul unei implementări corecte a RIP-ului. Vom încerca să demostrăm de ce sunt necesare anumite caracteristici

Figura 4.5 Toate conexiunile au costul 1, mai puţin legătura directă de la C la D care are costul 10. Fiecare router (gateway) va avea o tabelă conţinând o rută către fiecare reţea. Să notăm numai rutele de la fiecare gateway către reţeaua D. D: conectată direct, metrică 1

27

B: rută prin D, metrică 2 C: rută prin B, metrică 3 A: rută prin B, metrică 3 Să presupunem acum că legătura dintre B şi D cade. Rutele vor trebui acum modificate pentru a folosi legătura de la C la D. Din păcate, va dura ceva vreme pentru ca acest lucru să se întâmple. Modificările de rutare încep atunci când B anunţă că ruta către D nu mai este utilizabilă. Pentru simplificare, în tabelul următor se presupune că toate gateway-urile trimit mesaje de actualizare în acealaşi timp. În tabel apar metricile pentru reţeaua ţintă, aşa cum apar în tabela de rutare a fiecărui gateway.

timp ------>

Next hop

Dist. Next hop

Dist. Next hop

Dist. Next hop

Dist …. Next hop

Dist. Next hop

Dist.

D Dir 1 Dir 1 Dir 1 Dir 1 Dir 1 Dir 1 B Unr - C 4 C 5 C 6 C 11 C 12 C B 3 A 4 A 5 A 6 A 11 D 11 A B 3 C 4 C 5 C 6 C 11 C 12

Dir = conectat direct Unr = de neatins (unreachable) Apare următoarea problemă: B este capabil să scape de ruta căzută folosind un mecanism de timeout. Dar urme ale acestei rute persistă în sistem pentru o lungă perioadă de timp. Iniţial, A şi C cred că pot ajunge la D prin B. Deci, ele vor continua să trimită mesaje de actulaizare conţinând metrici de valoare 3. La următoarea iteraţie, B va pretinde că poate ajunge la D fie prin A, fie prin C. Desigur, acest lucru este posibil. Rutele pretinse de A şi C sunt inutilizabile, dar ele nu ştiu încă acest lucru. Şi chiar şi atunci când vor descoperi că rutele lor prin B au dispărut, fiecare va crede că mai este o rută disponibilă prin celălalt. Eventual sistemul va converge dar va trece ceva timp până se va întâmpla acest lucru. Cel mai rău caz este când o reţea devine complet inaccesibilă dintr-o anumită parte a sistemului. În acest caz, metrica poate creşte încet într-un mod ca cel de mai sus până când va deveni infinit. Din acest motiv, problema este denumită “numărare la infinit”. Acum se poate înţelege de ce “infinitul” a fost ales să aibă o valoare cât mai mică. Dacă o reţea devine complet inaccesibilă, e de preferat ca numărarea la infinit să se oprească cât mai repede. Infinitul trebuie să fie suficient de mare astfel încât nici o rută reală să nu fie atât de mare. Dar nu poate fi oricât de mare. Deci alegerea infinitului este o negociere între mărimea reţelei şi viteza de convergenţă în cazul în care are loc o numărare la infinit. Proiectanţii RIP-ului cred că protocolul nu e practic pentru reţele cu o întindere mai mare de 15. Sunt câteva lucruri ce pot fi făcute pentru a preveni astfel de probleme. Una dintre ele şi care este folosită de RIP se numeşte "split horizon with poisoned reverse", and "triggered updates".

28

4.1.1.8 Mecanismul „Split horizon”

Se observă că, parţial, problema de mai sus e cauzată de faptul că gateway-urile A şi C sunt angajate într-un proces de dezinformare reciprocă. Fiecare pretinde să fie capabil să ajungă în D prin celălalt. Acest lucru poate fi prevenit dacă se are mai multă grijă cu privire la destinatarul informaţiei transmise. În particular, nu este corect să pretinzi că deţii o rută pentru reţeaua destinaţie a vecinului de la care de fapt ai învăţat acea rută. „Split horizon” este o schemă pentru evitarea problemelor cauzate de transmiterea actualizărilor către gateway-ul de la care a fost învăţată ruta. Schema „split horizon” în varianta simplificată omite rutele învăţate de la un vecin în mesajele de actualizare trimise la acel vecin. „Split horizon with poisoned reverse” include astfel de rute în mesajele de actualizare dar setează metricele acestora la infinit. Dacă A crede că poate ajunge la D prin C, mesajele sale către C ar trebui să indice că D nu poate fi atins. Dacă ruta prin C este reală, atunci C ori are o legătură directă cu D, ori o legătură prin alt gateway. Ruta lui C nu poate duce înapoi la A, deoarece formează o buclă. Spunându-i lui C că D nu poate fi atins, A previne situaţia în care C ar putea deveni confuz şi ar crede că există rută prin A. Acest lucru este evident pentru o legătură punct la punct. Dar să considerăm că A şi C sunt conectate printr-o reţea broadcast, cum este Ethernet-ul şi există şi alte gateway-uri în această reţea. Dacă A are rută prin C, ar trebui să indice că D este de neatins când discută cu orice alt gateway din acea reţea. Celelalte gateway-uri din reţea pot ajunge ele însele (în mod direct) la C. Nu au nevoie de o rută prin A pentru a ajunge la C. Dacă cea mai bună rută a lui A este prin C, nici un alt gateway din acea reţea nu are nevoie să ştie că A poate ajunge la D. Este o şansă, pentru că înseamnă că acelaşi mesaj de actualizare care este folosit pentru C poate fi folosit pentru toate gateway-urile din reţea. Astfel, mesajele de actualizare pot fi trimise ca broadcast. În general, „Split horizon with poisoned reverse” este mai sigur decât „Split horizon”. Dacă 2 gateway-uri au rute care indică unul către celălalt, rutele „reverse” cu o metrică de 16 vor rupe bucla imediat. Dacă rutele „reverse” nu sunt anunţate, rutele eronate vor trebui eleiminate prin aşteptarea unui timeout. Totuşi, „poisoned reverse” are un dezavantaj: creşte mărimea metricei rutei. Să considerăm cazul unui backbone de campus ce conectează un număr de clădiri diferite. În fiecare clădire exsistă un gateway ce conectează backbone-ul la reţeaua locală. Să ne imaginăm ce actualizări (de tip broadcast) de rute ar transmite acele gateway-uri pe backbone. Într-adevăr restul reţelei trebuie să ştie despre fiecare gateway la ce reţele locale este conectat. Folosind „Split horizon” (varianta simplă), numai acele rute ar apărea în mesajele de actualizare trimise de gateway prin backbone. Dacă este folosit „Split horizon with poisoned reverse” gateway-ul va trebui să menţioneze toate rutele pe care le învaţă de la backbone, cu metrică de 16. Dacă sistemul este mare (număr mare de reţele şi gateway-uri), mesajul de actualizare va fi complex cu majoritatea intrărilor indicând reţele de neatins. Într-un sens static, transmiţând rute de tip „reverse” cu metrică de valoare 16 nu sunt furnizate informaţii adiţionale. Dacă există multe gateway-uri într-o reţea de tip broadcast, aceste intrări suplimentare pot folosi o lăţime de bandă (capacitate de trafic) semnificativă. Motivul pentru care sunt acolo este pentru a îmbunătăţi comportamentul dinamic (a grăbi convergenţa). Totuşi, în unele situaţii administratorul de reţea preferă să accepte o convergenţă mai lentă pentru a evita supraîncărcarea reţelei. Cei ce realizează implementarea ar putea alege ei înşişi „Split horizon” în detrimentul „Split horizon with poisoned reverse”, sau pot furniza o opţiune de configurare care permite administratorului reţelei să aleagă varianta pe care o consideră optimă. Este permis să se implementeze scheme hibride care să

29

promoveze unele rute „reverse” cu o metrică de 16 şi să omită altele. Un exemplu de o astfel de schemă ar fi folosirea unei metrice de 16 pentru rute „reverse” pentru o anumită perioadă de timp (din momentul declanşării schimbărilor de rutare ce le implică) şi apoi omiţându-le din mesajele de actualizare. 4.1.1.9. Actualizări determinate de anumite evenimente Mecanismul „Split horizon with poisoned reverse” va preveni orice bucle de rutare ce implică numai 2 gateway-uri. Totuşi există situaţii în care în formarea buclei sunt implicate 3 gateway-uri. De exemplu, A poate crede că are rută prin B, B prin C şi C prin A. „Split horizon” nu poate elimina o astfel de buclă. Această buclă va fi rezolvată numai când metrica atinge infinit şi reţeua implicată este deci declarată de neatins. Actualizările determinate de anumite evenimente sunt o încercare de a mări viteza convergenţei. Pentru a obţine aceste actualizări, adăugăm o regulă prin care ori de câte ori un gateway schimbă metrica pentru o rută, se cere să se transmită imediat mesajul de actualizare corespunzător, chiar dacă nu este încă timpul pentru un mesaj obişnuit de actualizare. (Detaliile de timp vor fi definite pentru fiecare protocol. Unele protocoale bazate pe vector distanţă, incluzând RIP, specifică o mică întârziere pentru a evita ca actualizările să genereze trafic excesiv în reţea). De observat cum acest lucru se combină cu regulile de calculare a noilor metrici. Să presupunem că o rută a unui gateway X către destinaţia N trece prin gateway-ul G. Dacă soseşte un mesaj de actualizare de la G, gateway-ul X trebuie să valideze informaţia nouă, necontând dacă noua metrică este mai mare sau mai mică decât cea veche. Dacă rezultatul este o schimbare de metrică, atunci gateway-ul X va trimite actualizările către toate host-urile şi gateway-urile conectate la el. La rândul lor acestea pot fiecare trimite actualizări către vecinii lor. Rezultatul este o cascadă de actualizări. E uşor să arătăm care gateway-uri şi host-uri sunt implicate în cascada de actualizări. Să presupunem că gateway-ul G are ruta către N expirată. G va trimite actualizările către toţi vecinii săi. Totuşi, singurii vecini care vor lua în considerare aceste noi informaţii sunt aceia ale căror rute către N trec prin G. Celelalte gateway-uri şi hosturi vor vedea aceste noi informaţii ca fiind rute noi care sunt mai rele ca cele pe care deja le folosesc, şi le vor ignora. Vecinii ale căror rute trec prin G vor actualiza metricele şi vor trimite actualizările către toţi vecinii lor. Din nou, numai acei vecini ale căror rute trec prin el vor ţine cont de aceste actualizări. Astfel, actualizările se vor propaga înapoi de-a lungul tuturor căilor ce duc spre gateway-ul G, actualizând metricele la infinit. Această propagare se va opri când se va ajunge la o porţiune a unei reţele a cărei rută către destinaţia N o ia pe alte căi. Dacă sistemul ar putea fi făcut astfel încât să „îngheţe” până când este transmisă toată cascada de actualizări, e posibil să se demonstreze că numărătoarea la infinit nu va avea loc. Rutele proaste vor fi şterse totdeauna imediat, şi astfel nu se va putea forma nici o buclă de rutare. Din păcate, lucrurile nu stau chiar aşa în realitate. Când sunt transmise actualizările determinate de anumite evenimente, actualizările uzuale pot avea loc în acelaşi timp. Gateway-urile care nu au primit încă actualizări determinate de anumite evenimente vor trimite în continuare informaţii bazate pe rute care de fapt nu mai există. Este posibil ca după trecerea actualizărilor determinate de anumite evenimente printr-un gateway, acesta să primească o actualizare normală de la unul din aceste gateway-uri care nu a fost încă informat asupra evenimentului respectiv. Acest lucru va restabili o rută greşită.

30

4.1.2 IGRP Interior Gateway Routing Protocol

IGRP este un protocol (elaborat de Cisco) ce permite unui număr de gateway-uri să îşi coordoneze procesele de rutare. Scopurile sunt:

• rutare stabilă chiar şi în reţele largi sau foarte complexe. Nici o buclă de rutare nu va apărea nici chiar în mod tranzitoriu ;

• răspuns rapid privind schimbările de topologie ale reţelei; • supraîncărcare redusă. Aceasta deoarece, IGRP foloseşte lăţimea de bandă minimă necesară pentru task-urile sale;

• împărţirea traficului de-a lungul câtorva rute paralele atunci când sunt aproximativ echivalente;

• luarea în considerare a ratei de eroare şi a nivelului traficului pentru căi diferite; • abilitatea de a trata mai multe tipuri de servicii pe baza unui singur set de informaţii.

Implementarea curentă a IGRP-ului are în vedere rutarea pentru TCP/IP. Cu toate acestea, structura de bază a fost creată pentru a funcţiona cu o varietate de protocoale. Cu timpul, rutarea a devenit o problemă mai dificilă decât era de aşteptat. Iniţial, protocoale ca RIP erau suficiente pentru a se descurca cu majoritatea reţelelor. Cu toate acestea, creşterea Internet-ului, şi descentralizarea controlului structurii sale, au avut ca rezultat crearea unui sistem de reţele care este aproape dincolo de posibilităţile noastre de administrare. Situaţii asemănătoare au loc de asemenea în mari reţele ale unor corporaţii. IGRP este o unealtă făcută cu intenţia de a ajuta în rezolvarea acestei probleme. Nu există vreo unelată care să rezolve toate problemele de rutare. În mod convenţional, problema rutării este împărţită în câteva părţi. Protocoale ca IGRP sunt numite „Internal Gateway Protocols” - IGPs. Acestea sunt făcute cu intenţia de a fi utilizate în cadrul unui singur set de reţele, toate acestea aflându-se sub o singură administrare. Aceste seturi de reţele sunt conectate între ele printr-un „external gateway protocol” (EGPs). Un IGP este creat pentru a ţine evidenţa privind detalile despre topologia reţelei. Prioritar în proiectarea unui IGP este găsirea de rute optime şi răspunsurile rapide la schimbări. În cazul unui EGP se aşteaptă protejarea unui sistem de reţele împotriva mesajelor eronate transmise intenţionat sau nu de alte sisteme. Prioritar în implementarea unui EGP este stabilitatea şi administrarea. Adesea este suficient pentru un EGP găsirea de rute rezonabile, mai degrabă decât găsirea unei rute optime. De fapt, există caracteristici ale implementării Cisco ce permit IGRP-ului să fie folosit ca EGP în anumite circumstanţe. Cu toate acestea, IGRP a fost proiectat pentru a fi utilizat ca IGP. IGRP are câteva similarităţi cu protocoale mai vechi cum ar fi Xerox's Routing Information protocol, Berkeley's RIP, şi „Hello” al lui Dave Mills. Diferă de aceste protocoale în primul rând prin aceea că a fost creat pentru reţele mai mari şi mai complexe. RIP este cel mai utilizat din generaţia de protocoale mai vechi.

Ca şi aceste protocoale mai vechi, IGRP este de tip vector distanţă. În cazul unui astfel de protocol, gateway-urile schimbă informaţii de rutare numai cu gateway-urile adiacente. Aceste informaţii de rutare conţin un rezumat al informaţiilor despre restul reţelei. Se poate demonstra matematic, că toate gateway-urile implicate în procesul de rutare iau parte împreună la rezolvarea unei probleme de optimizare pe baza unui algoritm distribuit. Fiecare

31

gateway are nevoie să rezolve numai o parte a problemei şi va primi pentru asta numai o parte din datele totale.

4.1.2.1 Problema rutării

IGRP se foloseşte de către gateway-uri ce interconectează câteva reţele. Presupunem că reţelele folosesc o tehnologie bazată pe comutarea pachetelor. Drept urmare, gateway-urile acţionează ca nişte comutatoare de pachete. Când un sistem conectat la o reţea doreşte să trimită un pachet unui sistem dintr-o altă reţea, îl trimite unui gateway. Dacă destinaţia este într-una din reţelele conectate la gateway, gateway-ul va trimite pachetul la destinaţie. Dacă destinaţia este într-o altă reţea, gateway-ul va trimite pachetul unui alt gateway care este mai aproape de destinaţie. Gateway-urile folosesc tabele de rutare pentru a decide ce să facă cu pachetele. Iată un exemplu de tabelă de rutare. (Se consideră că protocolul de comunicaţie folosit este IP; problema rutării este similară şi pentru alte protocoale)

Destination Gateway Interface 128.6.4.0 none Ethernet 0 128.6.5.0 none Ethernet 1 128.6.21.0 128.6.4.1 Ethernet 0 128.121.0.0 128.6.5.4 Ethernet 1 10.0.0.0 128.6.5.4 Ethernet 1

(De fapt tabelele de rutare IGRP conţin mai multe informaţii pentru fiecare gateway după cum se va vedea)

Acest gateway este conectat la 2 Eternet-uri numite 0 şi 1. Acestora le-au fost alocate adresele IP de reţea (de fapt adrese de subreţele) 128.6.4.0 şi 128.6.5.0. Astfel, pachetele adresate acestor reţele pot fi trimise direct către destinaţie, pur şi simplu prin folosirea interfeţei Ethernet corespunzătoare. Sunt 2 gateway-uri apropiate (învecinate) 128.6.4.1 şi 128.6.5.4. Pachetele către alte reţele decât 128.6.4.0 şi 128.6.5.0 vor fi trimise către unul sau altul din cele 2 gateway-uri. Tabela de rutare indică ce gateway trebuie folosit şi pentru ce reţea. De exemplu, pachetele adresate unui host din reţeaua 10.0.0.0 trebuiesc trimise către gateway-ul 128.6.5.4. Considerăm că acest gateway este mai aproape de reţeaua 10, adică cea mai bună rută către reţeaua 10.0.0.0 trece prin acest gateway. Scopul primar al IGRP este să permită gateway-urilor să construiască şi să întreţină astfel de tabele.

4.1.2.2 IGRP – prezentare generală

Aşa cum s-a menţionat mai sus, IGRP este un protocol care permite gateway-urilor să construiască tabela de rutare prin schimbarea de informaţii cu alte gateway-uri. Un gateway începe completarea tabelei de rutare cu intrări pentru toate reţelele care sunt direct conectate la el. Obţine informaţii despre alte reţele prin schimburile de actualizări de rute cu gateway-urile adiacente. O rută conţine: destinaţia, următorul gateway către care trebuie trimise pachetele, interfaţa de reţea ce ar trebui folosită, şi informaţia privind metrica. Informaţia referitoare la metrică este un set de numere care descrie cât de bună este ruta. Aceasta permite gateway-ului să compare rutele despre care a fost informat de alte gateway-uri şi să decidă pe care să o folosescă. Sunt cazuri când are sens să împărţim traficul între 2 sau mai multe rute. IGRP va face acest lucru oricând 2 sau mai multe rute sunt la fel de bune. Utilizatorul îl poate de asemenea configura să împartă traficul atunci când rutele sunt aproape egal de bune. În acest caz mai mult trafic va fi trimis prin calea cu metrica cea mai bună. De

32

exemplu dacă se doreşte ca traficul să fie împărţit între două linii, una de 9600 bps şi o alta de 19200 bps, liniei de 19200 bps i se va aloca o metrică de 2 ori mai bună decât cea a liniei de 9600 bps.

Metrica folosită de IGRP poate reprezenta:

• întârzierea introdusă de conexiunea respectivă; • lăţimea de bandă (capacitatea de trafic a conexiunii); • gradul de încărcare a conexiunii; • fiabilitatea conexiunii.

Întârzierea introdusă de o conexiune reprezintă timpul necesar pentru a ajunge la destinaţie prin acea cale, în condiţiile unei reţele neîncărcate. Desigur există întârziere adiţională când reţeaua este încărcată. Totuşi, încărcarea este contabilizată prin folosirea parametrului „gradul de încărcare a conexiunii” şi nu prin încercarea de a măsura întârzierea propriu-zisă. Lăţimea de bandă a conexiunii este capacitatea de trafic exprimată în biţi/sec. Gradul de încărcare a conexiunii indică cât de multă bandă este folosită curent. Poate fi măsurată şi se modifică odată cu încărcarea conexiunii. Fiabilitatea indică rata curentă de erori. Poate fi măsurată.

Deşi nu sunt folosite ca parte a metricei, 2 informaţii adiţionale sunt transmise cu ea: „hop count” şi MTU. „Hop count” reprezintă numărul de gateway-uri pe care un pachet va trebui să le traverseze ca să ajungă la destinaţie. MTU reprezintă mărimea maximă a pachetului ce poate fi transmis prin întreaga cale fără fragmentare (este MTU-ul cel mai mic dintre toate MTU-urile reţelelor traversate).

Pe baza informaţiei metricelor, pentru o cale se calculează o singură metrică compusă. Metrica compusă combină efectul componentelor diferitelor metrici într-un singur număr reprezentând “calitatea” căii. Metrica compusă este folosită pentru a decide cea mai bună cale de urmat.

Periodic, fiecare gateway transmite prin broadcast întreaga tabelă de rutare către toate gateway-urile adiacente (cu unele excepţii din cauza mecanismului „Split horizon”). Când un gateway primeşte acest mesaj de tip broadcast de la un alt gateway, compară tabela primită cu cea proprie. Orice destinaţii sau căi noi sunt adăugate tabelei proprii de rutare. Rutele din mesajul broadcast sunt comparate cu rutele existente. Dacă o rută nouă este mai bună, o poate înlocui pe cea existentă. Informaţia din broadcast este folosită de asemenea pentru actualizarea ocupării canalului de comunicaţie şi a altor informaţii despre rutele existente. Această procedură generală este similară cu cea folosită de toate protocoalele bazate pe vectorul distanţă (în literatura matematică sunt referiţi ca algoritmi Belmann-Ford).

În IGRP, algoritmul general Belmann-Ford este modificat în 3 aspecte esenţiale. Întâi, în loc de o metrică simplă, este folosit un vector de metrici pentru a caracteriza căile. Apoi, în locul alegeri unei singure căi cu metrica cea mai mică, traficul este împărţit de-a lungul mai multor căi ale căror metrici se încadrează între anumite valori. În al treilea rând, au fost introduse câteva elemente pentru a asigura stabilitate în situaţiile în care topologia este modificată.

Calea cea mai bună este selectată pe baza unei metrici compuse:

[(K1 / Be) + (K2 * Dc)] r

33

Unde:

K1, K2 = constante Be = lărgime de bandă efectivă Dc = întârziere r = stabilitate.

Cale cu cea mai mică metrică compusă va fi calea cea mai bună. În cazul în care există mai multe căi către aceeaşi destinaţie, gateway-ul poate ruta pachetele de-a lungul mai multor căi. Acest lucru este făcut ţinând cont de metrica compusă pentru fiecare pachet de date. De exemplu, dacă o cale are o metrică compusă 1 şi o altă cale are metrica compusă 3, de 3 ori mai multe pachete vor fi transmise pe calea cu metrica 1. Oricum, vor fi utilizate numai căi ale căror metrici compuse se încadrează între anumite valori ale celei mai mici metrici compuse. K1 şi K2 indică ponderile ce vor fi atribuite lărgimii de bandă şi întârzierii. Acestea depind de tipurile serviciilor. De exemplu, traficul de tip interactiv va acorda în mod normal o importanţă mai mare întârzierii iar traficul de tip transfer de fişiere, lărgimii de bandă.

Sunt 2 avantaje ale folosirii vectorului de metrici. Primul este că asigură posibilitatea suportării mai multor tipuri de servicii pe baza aceluiaşi set de date. Al doilea avantaj este că îmbunătăţeşte acurateţea stabilirii rutelor. Când este folosită o singură metrică, este tratată ca şi când ar reprezenta întârzierea căii. Fiecare conexiune a căii este adăugată la metrica totală. Dacă există o legătură cu o lărgime de bandă mică, ea este caracterizată în mod normal de o întârziere mare. Cu toate acestea, limitările de lărgime de bandă nu se cumulează similar întârzierilor. Considerând lărgimea de bandă ca o componentă separată, aceasta poate fi tratată corect. În mod asemănător, încărcarea poate fi tratată ca un parametru separat care indică gradul de ocupare a canalului.

IGRP asigură un sistem pentru interconectarea reţelelor de calculatoare care poate rezolva în condiţii de stabilitate o topologie generală (inclusiv bucle). Sistemul conţine informaţii privind metricele întregilor căi, adică, ştie parametrii căilor către toate celelalte reţele la care oricare gateway este conectat. Traficul poate fi distribuit pe căi paralele şi parametrii căii multiple pot fi simultan calculaţi de-a lungul întregii reţele.

4.1.2.3 Descriere detaliată

Cînd un gateway este pornit prima dată, este iniţializată tabela sa de rutare. Acest lucru poate fi făcut de un operator de la consola de comandă, sau prin citirea informaţiilor din fişierele de configurare. Este astfel asigurată o descriere a fiecărei reţele conectate la gateway, inclusiv informaţii privind întârzierea conexiunii (adică cît de mult îi ia unui singur bit să traverseze conexiunea) şi lărgimea de bandă a conexiunii.

34

Figura 4.6 Exemplu de reţea De exemplu, în fig 4.6 gateway-ul S, în urma configurării adreselor IP şi a măştilor de reţea corespunzătoare pentru interfeţele sale, ştie că este conectat direct la reţelele 2 şi 3 prin interfeţele corespunzătoare. Deci, iniţial, gateway 2 ştie numai că el poate retransmite pachete către calculatoarele din reţelele 2 şi 3. Toate gateway-urile sunt configurate să transmită periodic gateway-urilor vecine informaţiile cu care au fost iniţializate, precum şi informaţiile obţinute de la alte gateway-uri. Astfel, gateway-ul S va primi actualizări de la gateway-urile R şi T şi va învăţa că poate „ajunge” la calculatoarele din reţeaua 1 prin gateway-ul R şi calculatoarele din reţeaua 4 prin T. Gateway-ul S îşi trimite întreaga tabelă de rutare (actualizată) şi prin urmare în ciclul următor gateway-ul T va învăţa că el poate ajunge la reţeaua 1 prin gateway-ul S. E uşor de văzut că aceste informaţii despre orice reţea din sistem vor ajunge eventual la fiecare gateway din sistem. Fiecare gateway calculează o metrică compusă pentru a determina „calitatea” căii către calculatoarele destinaţie. De exemplu, în figura 4.7, pentru o destinaţie din reţeaua 6, gateway-ul A va clacula valorile metricei pentru 2 căi, prin gateway-ul B şi C. De remarcat că aceste căi sunt definite în mod simplu, prin hostul următor. Există 3 rute posible de la A la reţeaua 6:

• prin B • prin C şi apoi prin B • prin C şi apoi prin D

Cu toate astea, gateway-ul A nu va trebui să aleagă între cele 2 rute prin C. Tabela de rutare a lui A are o singură intrare reprezentând calea prin C. Metrica sa reprezintă cea mai bună cale de a junge de la C la destinaţia finală. Dacă A trimite un pachet către C, depinde de C să decidă dacă va folosi pe B sau pe D.

35

Figura 4.7 Exemplu de căi alternative

Metrica compusă calculată pentru fiecare cale arată astfel:

[(K1 / Be) + (K2 * Dc)] r (1) Unde:

r = fiabilitate (cât % din transmisie este primită cu succes de hopul următor)

Dc = întârziere compusă;

Be = lărgime efectivă de bandă;

K1, K2 = constante.

În principiu, întârzierea compusă, Dc, poate fi determinată astfel:

Dc = Ds + Dcir + Dt (2) Unde:

Ds = întârziere de comutare; Dcir = întârzierea de circuit (întârzierea dată de propagarea unui bit); Dt = întârzierea de transmisie.

36

Cu toate acestea, în practică este utilizată o valoare standard reprezentând întârzierea pentru fiecare tip de reţea. De exemplu, există o valoare standard reprezentând întârzierea pentru o reţea Ethernet şi diverse valori pentru liniile seriale de diverse viteze.

Un exemplu de cum arată tabela de rutare pentru gateway-ul A este prezentat în figura 4.8 (Pentru simplificare, componentele individuale pentru vectorul de metrici nu sunt reprezentate)

Destinaţie Interfaţă gw următor Metrică

Network 1 I1 - conectată direct Network 2 I2 - conectată direct Network 3 I3 - conectată direct Network 4 I2 C 1270 I3 B 1180 Network 5 I2 C 1270 I3 B 2130 Network 6 I2 C 2040 I3 B 1180

Figura 4.8 Exemplu de tabelă de rutare Aceste proces de creare a unei tabele de rutare prin schimbul de informaţii cu vecinii este descris de algoritmul Bellman-Ford. Algoritmul a fost folosit în protocoalele mai vechi ca RIP (RFC 1058). Pentru a fi eficient în reţele mai complexe, IGRP adaugă 3 caracteristici noi algoritmului de bază Bellman-Ford:

1. În locul unei metrici simple, pentru a caracteriza o cale, este folosit un vector de metrici. O singură metrică compusă poate fi calculată pornind de la acest vector şi folosind ecuaţia (1). Folosirea unui vector de metrici permite gateway-ului să trateze diverse tipuri de servicii, utilizând coeficienţi diferiţi în ecuaţia (1). De asemenea, permite o mai bună reprezentare a caracteristicilor reţelei decât o metrică simplă.

2. În locul alegerii unei singure căi având cea mai mică metrică, traficul este împărţit de-a lungul mai multor căi având metrice cuprinse între anumite valori. Acest lucru permite folosirea câtorva rute în paralel, asigurând astfel mai multă eficienţă în privinţa utilizării lărgimii de bandă decât în cazul folosirii unei singure rute. Administratorul de reţea specifică o constantă de variaţie V. Toate căile având metrica compusă minimă M sunt păstrate. În plus, toate căile cu metrice mai mici decât VxM sunt de asemenea reţinute. Traficul este distrubuit de-a lungul mai multor căi invers proporţional cu metricile compuse asociate acestora.

3. Există câteva probleme legate de conceptul de dezacord. Este dificil de stabilit o strategie care să asigure folosirea unui constante de variaţie cu valoare mai mare decât 1, şi de asemenea să nu conducă la bucle de rutare. În Cisco IOS 8.2, mecanismul acesta nu este implementat. Efectul acestui lucru este setarea valorii constantei de variaţie la 1 în mod permanent.

4. Câteva carcateristici au fost introduse pentru a asigura stabilitatea în cazul schimbărilor de topologie. Aceste carcateristici au scopul de a preveni buclele de rutare şi “numărarea la infinit”, fenomene ce au carcaterizat încercările anterioare de folosire a algoritmilor de tip Ford pentru acest tip de aplicaţii. Mecanismele cele mai importante ce asigură stabilitatea sunt "holddowns", "triggered updates", "split horizon," şi "poisoning".

37

Împărţirea (split-area) traficului (punctul 2) ridică însă şi o problemă nedorită. Constanta de variaţie V a fost introdusă pentru a permite gateway-urilor să folosească căi diferite având viteze diferite. De exemplu, poate exista o linie de 9600 bps în paralel cu o linie 19200 bps, pentru a asigura redundanţa. In cazul în care constanta de variaţie V este 1, numai calea cea mai bună va fi folosită. Deci linia de 9600 bps nu va fi folosită dacă linia de 19200 bps are o fiabilitate rezonabilă. (Oricum, dacă sunt câteva căi similare, încărcarea va fi împărţită între ele). Prin creşterea valorii constantei V, putem permite ca traficul să fie împărţit între cea mai bună rută şi alte rute care sunt aproape la fel de bune. Pentru o valoare suficient de mare a constantei V, traficul va fi împărţit între cele 2 linii. Pericolul este ca având o valoare mare pentru V, să fie urmate căi care sunt mai lente dar şi „în direcţii greşite”. Astfel trebuie să existe o regulă adiţională pentru a preveni traficul să fie transmis într-o direcţie greşită. Nici un trafic nu va fi trimis de-a lungul unei căi a cărei metrică compusă calculată la distanţă (calculată la hop-ul următor) este mai mare decât metrica compusă calculată de gateway. În general administratorii de sistem sunt îndrunaţi să nu seteze valoarea constantei la o valoare mai mare decât 1, excepţie făcând situaţiile când e necesară folosirea unor căi paralele. În acest caz, constanta este setată cu grijă, astfel încât să asigure rezultatul „corect”.

IGRP are scopul de a lucra cu mai multe tipuri de servicii şi mai multe protocoale. Tipul serviciului este o specificaţie în pachetul de date care modifică felul în care sunt evaluate căile. De exemplu, protocolul TCP/IP permite pachetului să specifice importanţa relativă a lărgimii de bandă, întârziere mică, sau siguranţă (fiabilitate) ridicată. În general, aplicaţiile interactive vor specifica o întârziere mică, în timp ce aplicaţiile de transfer cantitativ vor specifica lărgimea de bandă ca fiind mai importantă. Aceste cerinţe determină valorile relative pentru K1 şi K2 ce sunt necesare în ecuaţia (1). Combinaţiile de specificaţii din cadrul unui pachet de care trebuie ţinut cont sunt numite “tipuri de servicii”. Pentru ficare tip de servicii, trebuie ales setul de parametri K1 şi K2. Este păstrată o tabelă de rutare pentru fiecare tip de servicii. Acest lucru este făcut deoarece căile sunt selectate şi ordonate în funcţie de metrica compusă definită de ecuaţia (1) şi este diferită pentru fiecare tip de serviciu. Informaţiile din toate aceste tabele de rutare sunt combinate pentru a genera mesajele de actualizare ce se schimbă între gateway-uri.

4.2 Protocoale de rutare de tip „Link state”

4.2.1 Descriere generală

Router-ele ce folosesc protocoale de rutare de tip „link state” schimbă între ele mesaje numite „link state advertisments” (anunţuri privind starea conexiunii)- LSAs care constau în ID-urile reţelelor conectate la router şi costurile interfeţelor. LSAa sunt trimise după activarea gateway-ului şi atunci când sunt detecate schimbări în topologia reţelei. LSA-urile sunt trimise folosind mai degrabă mesaje de tip direct sau multicast decât mesaje de broadcast. Router-ele „link state” construiesc o bază de date de anunţuri LSA şi folosesc această bază de date pentru a calcula rutele optime care sunt adăugate în tabela de rutare. Informaţiile de rutare schimbate între router-ele „link state” sunt sincronizate şi se bazează pe confirmări. În următorul tabel sunt câteva protocoale de rutare de tip „link state”.

Routable Protocol Link State-based Routing Protocol

IP OSPF (Open Shortest Path First)

IPX NLSP (NetWare Link Services Protocol)

38

Avantajele protocoalelor de rutare de tip „link state”:

• Tabele de rutare mai mici. Numai o singură rută optimă pentru fiecare ID de reţea

este stocată în tabela de rutare.

• Supraîncărcare scăzută a reţelei. Router-ele bazate pe starea legăturii nu schimbă

nici o informaţie de rutare când reţeaua este convergentă.

• Capacitatea de scalare. Beneficiind de tablele de rutare mici şi de supraîncărcare

scăzută, protocoalele de rutare de tip „link state” se comportă bine şi cu reţele mari şi

foarte mari.

• Timp de convergenţă scăzut. Protocoalele de rutare de tip „link state” au un timp de

convergenţă scăzut şi reţelele converg fără pericolul apariţiei buclelor de rutare.

Dezavatajele protocoalelor de rutare bazate de tip „link state”:

• Complexitate. Aceste protocoale sunt mult mai complexe şi mai dificil de înţeles şi

de depanat decât protocoalele bazate pe vectorul distanţă.

• Mai dificil de configurat. Implementarea unui protocol de tip „link state” necesită

planificări şi configurări suplimentare.

4.2.2 Open Shortest Path First (OSPF)

OSPF rutează pachetele IP numai pe baza adresei IP destinaţie şi a tipului de serviciu (Type of Service - TOS) specificat în header-ul pachetului IP. Pachetele IP sunt rutate fără a fi încapsulate în vreun alt format al unui protocol suplimetar atât timp cât tranzitează un sistem autonom (AS). OSPF este un protocol de rutare dinamică. Detectează cu uşurinţă schimbările de topologie din sistemul autonom (cum ar fi „căderea” interfeţei unui router) şi calculează noile rute fără bucle după o perioadă de convergenţă. Această perioadă de convergenţă este scurtă şi implică un trafic de rutare minim. În protocolul de rutare de tip „link state”, fiecare router păstrează o bază de date cu descrierea topologiei sistemului autonom. Fiecare router participant are aceeaşi bază de date. Fiecare element din această bază de date este o descriere a unui router din cadrul sistemului autonom (de exemplu interfeţele utilizabile ale router-ului şi vecinii la care acesta poate ajunge). Router-ul distribuie starea sa locală în tot sistemul autonom prin flood-are (inundare). Toate router-ele execută în paralel acelaşi algoritm. De la baza de date topologică, fiecare router îşi construieşte un arbore cu cele mai scurte căi având ca rădăcină pe sine însuşi. Acest arbore cu cele mai scurte căi asigură rutele către fiecare destinaţie din sistemul autonom. Informaţiile privind rutele externe derivate apar ca frunze în arbore. OSPF calculează rute separate pentru fiecare tip de serviciu (TOS). Când sunt câteva rute cu cost egal către o anume destinaţie, traficul este distribuit în mod egal de-a lungul acestora. Costul unei rute este descris de o singură metrică simplă.

39

OSPF permite gruparea mai multor tipuri de reţele. Un astfel de grup se numeşte arie. Topologia unei arii este ascunsă de restul sistemului autonom. Această ascundere de informaţii permite o reducere semnificantă a traficului de rutare. De asemenea, rutarea în interiorul ariei este determinată numai de propria topologie a ariei, asigurând totodată protecţia împotriva unor informaţii de rutare greşite. O arie este o generalizare a unei subreţele IP. OSPF permite configuraţii flexibile de subreţele IP. Fiecare rută distribuită de OSPF are o destinaţie şi o mască. Două subreţele diferite ale aceleiaşi reţele pot avea dimensiuni diferite (adică măşti diferite). Acest lucru este referit în mod obişnuit ca subreţea de lungime variabilă (variable length subnet mask - VLSM). Un pachet este rutat către subreţeaua cea mai bună (adică cu lărgimea cea mai mare). Host-urile sunt considerate subreţele a căror mască este 255.255.255.255 (0xffffffff). Toate schimburile de mesaje ale protocolului OSPF sunt autentificate. Acest lucru înseamnă că numai router-ele de încredere pot participa la rutarea în cadrul sistemului autonom. Poate fi folosită o varietate de scheme de autentificare dar numai o singură schemă de autentificare se configurează pentru fiecare arie. Acest lucru permite unor arii să utilizeze metode de autentificare mai riguroase decât altele. Informaţiile de rutare externe derivate (de exemplu rute învăţate de la Exterior Gateway Protocol - EGP) sunt trecute în mod transparent prin sistemul autonom. Aceste informaţii externe derivate sunt menţinute separat de datele protocolului OSPF. Fiecare rută externă poate fi de asemenea etichetată de router-ul ce transmite mesaje LSA, asigurând transmiterea informaţiilor adiţionale între router-e de la marginea sistemului autonom.

4.2.2.1 Baza de date topologică

Baza de date topologică a sistemului autonom reprezintă un graf orientat. Nodurile grafului reprezintă router-e şi reţele. O conexiune a grafului leagă 2 router-e când acestea sunt interconectate printr-o legătură fizică punct-la-punct. O conexiune ce conectează un router de o reţea indică faptul că acel router are o interfaţă în acea reţea. Nodurile dintr-un graf pot fi clasificate în concordanţă cu funcţia acestora. Numai unele dintre ele transportă trafic de tranzit, adică acel trafic care nu a luat naştere local şi care nici nu are un destinatar local. Nodurile ce transportă traficul de tranzit sunt reprezentate în graf având conexiuni atât de intrare cât şi de ieşire.

Tip nod Nume nod Tranzit

1 Router Da 2 Reţea Da 3 Reţea finală Nu

OSPF suportă următoarele tipuri de reţele fizice:

Reţele Point-to-point

Este o reţea care interconectează o singură pereche de router-e. O linie serială de 56 Kbs este un exemplu de reţea punct-la-punct.

40

Reţele de tip „broadcast”

Reţele ce suportă multe (>2) router-e conectate, împreună cu posibilitatea de a adresa un singur mesaj fizic tuturor router-elor conectate (broadcast). Router-ele vecine sunt descoperite dinamic în aceste reţele prin folosirea protocolului OSPF Hello. Protocolul Hello foloseşte avantajele mesajelor de broadcast. De asemenea, protocolul foloseşte facilităţile de multicast, dacă acestea există. O reţea Ethernet este un exemplu de reţea broadcast.

Non-broadcast networks

Reţelele ce suportă multe (>2) router-e conectate dar fără să aibă posibilitate de broadcast. In aceste reţele router-ele vecine sunt de asemenea descoperite prin folosirea protocolului OSPF Hello. Cu toate acestea, din cauza lipsei posibilităţii de broadcast sunt necesare unele informaţii de configurare pentru ca protocolul Hello să funcţioneze corect. În aceste reţele, pachetele protocolului OSPF care sunt de obicei multicast trebuie să fie trimise fiecărui router vecin, pe rând. Un exemplu de reţea non-broadcast este reţeaua de date publică X.25 (X.25 Public Data Network - PDN).

Vecinătatea fiecărui nod de reţea din graf depinde de existenţa facilităţii de multiacces (fie broadcast fie non-broadcast) şi, dacă aceasta există, de numărul de router-e care au o interfaţă conectată la reţea. În figura 4.9 sunt înfăţişate 3 cazuri. Router-ele sunt notate cu RT, iar reţelele cu N. Interfeţele router-elor sunt notate cu I. Liniile dintre router-e indică reţele punct-la-punct. În parte a figurii este înfăţişată o reţea cu router-ele conectate la ea urmată de graful corespunzător. Două router-e interconectate printr-o reţea punct-la-punct sunt reprezentate în graful orientat ca fiind conectate printr-o pereche de conexiuni, câte una în fiecare direcţie. Nu este obligatoriu ca interfeţelor conectate în reţeaua punct-la-punct să li se asigneze adrese IP. Astfel de reţele punct-la-punct se numesc „fără adresă” (unnumbered). Reprezentarea grafică a reţelelor punct-la-punct este concepută astfel încât aceste reţele „fără adresă” să poată fi suportate în mod natural. Când se asignează adrese IP interfeţelor, acestea sunt modelate ca rute finale. De remarcat că, în această situaţie, fiecare router va avea o conexiune finală către adresa interfeţei celuilalt router. (figura 4.9) Când mai multe router-e sunt ataşate la o reţea multiacces, garful orientat asociat va conţine toate router-ele conectate bidirecţional la reţea (figura 4.9). Dacă la o reţea multiacces este ataşat numai un singur router, în graful corespunzător reţeaua va apărea ca o conexiune finală.

de la

RT1 RT2 RT1 X RT2 X Ia X

s p r e Ib X

41

Reţea fizică punct-la-punct

de la

RT3 RT4 RT5 RT2 N2 RT3 X RT4 X RT5 X RT6 X

s p r e

N2 X X X X

Reţea multiacces

de la

RT7 N3 RT7 X

s p r e N3 X

Reţea multiacces finală

Figura 4.9 Componentele hărţii reţelei

Fiecare reţea (finală sau de tip tranzit) din graf are o adresă IP şi o mască de reţea asociată. Masca indică numărul de noduri din reţea. Host-urile ataşate direct la router-e apar în graf ca reţele finale. Masca de reţea pentru un host este totdeauna 255.255.255.255 (0xffffffff), ceea ce indică prezenţa unui singur nod.

4.2.2.2 Arborele celei mai scurte căi (shortest-path tree)

Când nici o zonă OSPF nu e configurată, fiecare router în sistemul autonom are o bază de date topologică identică, conducând la o reprezentare grafică identică. Pe baza acestui grafic,

42

un router îşi generează tabela de rutare, prin calcularea unui arbore al celor mai scurte căi având ca rădăcină router-ul însuşi. Evident arborele depinde de router-ul care efectuează calculele. După ce este creat arborele, este examinată informaţia de rutare externă. Aceasta poate fi generată de un alt protocol de rutare ca EGP, sau poate fi configurată static. Rutele implicite (default) pot fi de asemenea incluse ca parte a informaţiilor de rutare externă a sistemului autonom. Informaţia externă este retransmisă (prin flood-are) nemodificat prin sistemul autonom. OSPF suportă 2 tipuri de metrică externă. Tipul 1 este echivalent cu metrica „link state”. Tipul 2 este reprezentat de metricele mai mari decât costul oricărei căi interne a sistemului autonom. Utilizarea tipului 2 presupune că rutarea între sisteme autonome reprezintă costul principal al rutării unui pachet şi elimină nevoia de conversie a costurilor externe în metrici interne de tip „link state”. OSPF permite gruparea unei colecţii de reţele host-uri contigue. Un astfel de grup, împreună cu router-ele având interfeţe conectate la oricare din reţelele incluse, poartă numele de zonă (arie). Fiecare zonă rulează o copie separată a algoritmului de rutare de tip „link state”. Acesta înseamnă că fiecare zonă are propria ei bază de date topologică şi graful corespunzător. Topologia unei zone este invizibilă din exteriorul zonei. Router-ele aflate într-o zonă dată nu ştiu nimic despre topologia externă zonei respective. Această izolare permite protocolului să efectueze o reducere semnificativă a traficului de rutare faţă de situaţia în care întregul sistem autonom ar fi tratat ca un singur domeniu „link state”. Odată cu introducerea zonelor, nu mai este valabilă ideea că toate router-ele din sistemul autonom au baze de date topologice identice. Un router are o bază de date separată pentru fiecare zonă la care este conectat. (Router-ele conectate la mai multe zone sunt denumite router-e de graniţă). Două routere aparţinând unei zone au pentru acea zonă baze de date topologice identice. Rutarea în sisteme autonome are loc la 2 nivele. Dacă sursa şi destinaţia unui pachet se află în aceeaşi zonă este folosită rutarea intra-zonală; dacă se află în zone diferite este folosită rutarea inter-zonală. În cadrul rutării intra-zonale, pachetul este rutat numai pe baza informaţiei obţinută în cadrul zonei. Nici o informaţie de rutare obţinută din afara zonei nu poate fi utilizată. Acest lucru protejează rutarea intra-zonală de injectarea informaţiei de rutare eronate.

4.3. Sisteme autonome (Autonomous Systems)

În sisteme de reţele interconectate de dimensiuni foarte mari, e necesar să se împartă reţeaua în entităţi separate cunoscute ca sisteme autonome. Un sistem autonom este o parte a unei reţele având aceeaşi autoritate administrativă. Aceasta poate fi o instituţie sau o corporaţie, dar poate fi de asemenea reprezentată de utilizarea unui protocol de rutare comun (cum ar fi OSPF). Porţiunile alăturate ale unei reţele IP, ce foloseşte OSPF pentru a distribui informaţia de rutare, se află sub autoritatea administrativă a OSPF-ului şi formează, din această cauză, un sistem autonom OSPF. Sistemul autonom poate fi mai departe împărţit în domenii, regiuni sau zone care definesc o ierarhie în cadrul sistemului autonom.

43

Figura 4.10 Sisteme autonome, protocoale interior gateway, şi protocoale exterior gateway.

Protocoalele folosite pentru distribuirea informaţiei de rutare în cadrul unui sistem autonom sunt cunoscute ca Interior Gateway Protocols (IGPs). Protocoalele folosite pentru distribuirea informaţiilor de rutare între sisteme autonome sunt cunoscute ca Exterior Gateway Protocols (EGPs).

Interior Gateway Protocols (IGPs)

Protocoalele IGP sunt protocoale de rutare intra-SA. IGP distribuie rute în interiorul SA.

Exemple de IGP:

• RIP pentru IP. IGP de tip vector distanţă bazat pe RFC.

• OSPF. IGP de tip „link state” bazat pe RFC.

• Interior Gateway Routing Protocol (IGRP). IGP de tip vector distanţă implementat

de Cisco Systems, Inc.

Exterior Gateway Protocols (EGPs)

44

EGP-urile sunt protocoale de rutare inter-SA. Ele definesc modul în care toate reţelele din cadrul sistemelor autonome sunt „anunţate” în afara sistemului autonom. Aceasta poate include o listă de rute într-o infrastructură de rutare pe un singur nivel sau o listă de rute simplificate într-o infrastructură de ruatre ierahică. EGP-urile sunt independente de IGP-urile folosite în cadrul SA. Ele pot facilita schimbul de rute între sistemele autonome care folosesc IGP-uri diferite.

Exemple de EGP pentru reţele IP:

Exterior Gateway Protocol (EGP). Un EGP bazat pe RFC ce a fost dezvoltat pentru utilizare între sisteme autonome din Internet. EGP nu mai e folosit în Internet din cauza faptului că nu dispune de suport pentru medii complexe multi-cale şi Classless Inter-Domain Routing (CIDR).

Border Gateway Protocol (BGP). Un EGP bazat pe RFC care este în mod curent folosit între sistemele autonome din Internet. BGP suplineşte lipsurile EGP-ului. Versiunea curentă de BGP folosită pentru router-ele de backbone din Internet este BGP4.