Sunteți pe pagina 1din 44

Administrarea reelelor de

calculatoare

- curs -

1. Noiuni de baz despre rutare.


Sistemul Internet este format dintr-un numr de reele interconectate care suport comunicaii
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 aplicaie i transport ce depind de
acestea.
Toate protocoalele Internet folosesc IP ca mecanism de baz pentru transportul datelor. IP
este un protocol de comunicaie de tip datagram sau care nu se bazeaz pe conexiune i
include faciliti pentru adresare, specificaii despre tipul serviciului, fragmentarea i
reasamblarea pachetelor i securitate. ICMP i IGMP sunt considerate ca fiind pri
integrante ale IP, de altfel ele sunt arhitectural, nivele peste IP. ICMP furnizeaz rapoarte
privind erorile de transmisie, controlul fluxului, primul gateway i alte funcii privind
mentenana i controlul comunicaiei. IGMP furnizeaz mecanisme prin care host-urile i
router-ele se altur i prsesc un grup multicast.
Sigurana transferurilor de date este dat n Internet de protocoalele nivelului transport i
anume de Transmission Control Protocol (TCP), care furnizeaz retransmisia ntre surs i
destinaie, 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, cnd DARPA (Defense
Advanced Research Projects Agency) a devenit interasat de realizarea unei reele cu
comutarea pachetelor care ar fi facilitat comunicaia ntre diverse sisteme informatice ale
instituiilor de cercetare. Avnd n minte scopul unei conectiviti heterogene, DARPA a
finanat cercetarea Universitaii Stanford i a companiei BBN (Bolt, Beranek i Newman).
Rezultatul acestui efort de cercetare a fost suita de protocoale Internet, completat la sfritul
anilor 1970.
TCP/IP a fost inclus mai trziu cu Berkeley Software Distribution (BSD) UNIX i a devenit
apoi fundamentul pe care se bazeaz Internetul i World Wide Web (WWW).

Documentaia despre protocoalele Internet (incluznd 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 corespunztoare lor din modelul OSI.
1.1 Protocolul Internet.
Protocolul Internet se afla la baza comunicaiei n Internet. Funciile 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 ctre host-ul aflat la distan;
- realizarea fragmentrii i reasamblrii datagramelor.
nainte de descrierea n detaliu a acestor funcii, s analizm cteva caracteristici ale IP. nti,
IP este un protocol care nu se bazeaz pe conexiune. Acest lucru nseamn c IP nu schimb
informaii de control ("handshake") pentru a stabili o conexiune ntre surs i destinaie
naintea transmiterii de date. n contrast, un protocol orientat pe conexiune schimb
informaii de control cu sistemul aflat la distan pentru a verifica dac este gata s primeasc
date nainte de a transmite vreuna. Cnd 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 conine 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 reea, dar nu va verifica dac
datele au fost corect recepionate. Protocoalele altor nivele ale arhitecturii TCP/IP furnizeaz
aceast verificare atunci cnd este cerut.
1.1.1

Datagrama

Protocoalele TCP/IP au fost dezvoltate pentru a transmite date n reeaua ARPANET, care
este o reea cu comutarea pachetelor. Un pachet este un bloc de date care conine i
informaiile necesare pentru livrare - ntr-o manier asemntoare cu scrisoarea potal, care
are adresa scris pe plic. O reea cu comutarea pachetelor folosete informaia coninut n
pachete privind adresa, pentru a comuta pachetele de pe un nivel fizic pe altul, transmindule apoi mai departe spre destinaia final. Fiecare pachet strbate reeaua 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 bii ai datagramei reprezint informaii de
control i se numesc header. Implicit, header-ul are o lungime de 5 cuvinte, al 6-lea fiind
opional. Din cauz c lungimea header-ului poate fi variabil se include un cmp numit IHL
(Internet Header Length - lungimea header-ului internet) care indic lungimea exact a
acestuia. Header-ul conine toate informaiile necesare livrrii pachetului.
Protocolul Internet livreaz datagrama verificnd adresa destinaie din al 5-lea cuv al headerului. Adresa destinaie este o adres IP v4 standard de 32 de bii care identific reeaua
destinaie i host-ul respectiv.
Dac adresa destinaie este adresa unui host din reeaua local, pachetul este livrat direct
destinaiei. Dac adresa destinaie nu face parte din reeaua local, pachetul este trimis la un
gateway pentru a fi livrat. Gateway-urile sunt dispozitive care comut pachete ntre diferite

reele fizice. Decizia privind ce gateway se va folosi se numete rutare. Router-ele (gatewayurile) 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, reelele constituente sunt interconectate prin echipamente specifice
numite router-e sau IP router-e. Istoric, router-ele au fost iniial realizate cu soft-uri de
comutare a pachetelor ce rulau pe echipamente nespecializate. Deoarece, n timp,
implementarea de hardware a devenit mai ieftin, iar cerinele privind performanele 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 reele. n jargonul
tradiional TCP/IP, exist numai 2 tipuri de dispozitive de reea: gateway-uri i host-uri.
Gateway-urile expediaz pachetele ntre reele i host-urile nu. Oricum, dac un host este
conectat cu mai mult de o reea (i se numete multi-homed host), el poate expedia pachete
ntre reele. Cnd un host multi-home expediaz pachete, el se comport ca orice gateway i
este considerat a fi gateway. Terminologia actual a comunicaiilor de date face distincie
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 reele ce utilizeaz acelai 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 pn la nivelul Internet unde se ia decizia de rutare.

Figura 1.3 Rutarea prin gateway-uri


Sistemele pot numai s livreze pachetele altor dispozitive ataate n aceeai reea fizic.
Pachetele de la A1 destinate hostului C1 sunt expediate prin gateway-urile G1 i G2. Hostul
A1 mai nti livreaz pachetele spre gateway-ul G1, prin reeaua A la care ambele sunt
conectate. Gateway-ul G1 livreaz pachetul la G2 prin reeaua B. Gateway-ul G2 livreaz
apoi pachetul direct hostului C1 deoarece ambele fac parte din aceeai reea C. Hostul A1 nu
cunoate nimic n afar de gateway-ul G1. El trimite pachetele destinate reelelor B sau C
ctre acelai gateway local, i apoi devine sarcina gateway-ului s expedieze corect pachetele
ctre destinaia lor. Tot aa, hostul C1 va trimite pachetele sale ctre G2, n scopul de a
ajunge la un host din reaeaua A, sau din reeaua B.
1.2 ICMP
ICMP este considerat adesea ca fcnd parte din nivelul IP. El furnizeaz mesaje de eroare i
alte informaii necesare pentru controlul comunicaiei. 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, aa 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 rspuns 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 aa mai departe, indefinit).
5

Cnd un mesaj de eroare ICMP este transmis, el conine totdeauna headerul IP i primii 8
octei 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 cmpul de protocol
din headerul IP) i cu un anume proces al userului (rezultat din numerele de port TCP sau
UDP care sunt coninute n primii 8 octei ai headerului datagramei IP).
Cererea ICMP de tip timestamp permite unui sistem s interogheze un alt sistem n ceea ce
privete timpul curent. Valoarea recomandat pentru a fi returnat este un numr 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 rezoluie la nivel de milisecund, n timp ce alte metode
pentru obinerea timpului curent de la un host (cum ar fi comada rdate furnizat de unele
sisteme Unix) furnizeaz o rezoluie de ordinul secundelor. Inconvenientul acestei metode
este faptul c se poate afla numai intervalul de timp ntre ora curent i ora zero, urmnd ca
data curent s fie aflat prin alte mijloace.
1.3 Rutere
Rutarea const n transmiterea informaiei printr-o reea de la o surs ctre o destinaie. De-a
lungul cii parcurse, este ntlnit cel puin un nod intermediar. Rutarea este adesea n contrast
cu funcia de bridge care aparent realizeaz acelai lucru. Diferena 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 informaie diferit pentru rutare i respectiv bridging,
informaie necesar n procesul transmiterii pachetelor de la surs la destinaie, deci aceste 2
funcii i ndeplinesc rolurile n moduri diferite.
Un router dispune de 2 sau mai multe interfee de comunicaie(figura 1.5), conectate la
subreele IP sau la linii de tip punct-la-punct. Cu toate acestea, exist cel puin o interfa
fizic. Expedierea unei datagrame IP necesit n general ca un router s aleag interfaa i
adresa router-ului urmtor (next-hop) sau (n cazul ultimului router de pe traseu), host-ul
destinaie. Aceast alegere, (numit relaying) se face n funcie de o baz de date care se
afl pe router coninnd rute. Aceast baz de date se mai numete i tabel de rutare.
Temenul de router deriv din modul n care se construiete aceast baz de date coninnd
rute (ci); protocoalele de rutare i configurare interacionaez n cadrul unui proces numit
rutare.

Figura 1.5 Interconectarea a 2 reele printr-un router


Baza de date coninnd rute trebuie s fie dinamic pentru a reflecta topologia curent a
sistemului de reele interconectate. n mod normal, un router ndeplinete acest lucru prin
interaciune cu alte routere pe baza unor algoritmi de rutare.
Ruterele furnizeaz numai transportul de datagrame, i caut s reduc la minim informaia
de stare necesar efecturii acestui serviciu, avnd ca scop flexibilitatea i robusteea rutrii.
Un sistem autonom (AS) este reea ce const dintr-o colecie de subreele (avnd ataate hosturi) interconectate printr-un set de routere. E de preferat ca subreelele i routerele s fie sub
controlul unei singure organizaii ce realizeaz operarea i administrarea. ntr-un sistem
autonom, routerele pot folosi unul sau mai multe protocoale de rutare intern, i cteodat
cteva seturi de metrici. Este de ateptat ca un sistem autonom s dispun de un plan de rutare
interioar coerent. Un sistem autonom este identificat cu un numr de sistem autonom.
2. Bridging cu routere
n scopul de a mbunti performanele, urmtoarele performane au fost adugate unor
routere:
- bridging transparent;
- source-route bridging.
Bridge-urile transparente se gsesc predominant n reelele Ethernet, iar source-route bridges
(SRBs) se gsesc aproape exclusiv n reelele Token-Ring. Ambele sunt utilizate pe scar
larg.
2.1 Bridging transparent
Bridge-urile transparente au fost mai nti implementate de Digital Equipment Corporation la
nceputul anilor 1980. Digital a transmis aceste implementri la IEEE care le-a ncorporat n
standardul IEEE 802.1. Bridge-urile transparente sunt foarte comune n reelele

Ethernet/IEEE 802.3. n acest paragraf se face o trecere n revist a modului n care bridgingul transparent manipuleaz traficul i componentele protocolului.
Numele de bridge transparent provine din faptul c prezena i modul de operare al acestuia
sunt transparente pentru host-urile din reea. Cnd este pornit un bridge tranparent, el
nva locaia staiiilor de lucru prin analizarea adresei MAC surs a pachetelor pe care le
primete de la toate reelele ataate. De exemplu, dac un bridge primete 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 construiete (procesul de nvare) o tabel, ca
cea din figura de mai jos:

Figura 2.1. Bridge-uri transparente: construirea unei tabele cu ajutorul creia se determin
cum pot fi accesate host-urile.
Bridge-ul folosete aceast tabel ca baz n procesul de expediere a traficului. Cnd este
primit un frame pe una din interfeele bridge-ului, acesta caut adresa destinaie a frame-ului
n tabela sa intern. Dac tabela conine o asociere ntre adresa destinaie 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
puin 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 reea
(intrasegment), reducnd astfel traficul pe fiecare segment individual. Acest lucru se numete
filtrare i apare atunci cnd adresa MAC a sursei i destinaiei aparin aceleai interfee a
bridge-ului. Filtrarea mbuntete de obicei timpul de rspuns al reelei, aa cum este el
perceput de utilizator. Volumul crui trafic este redus i care timpi de rspuns sunt
mbuntii 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)
8

Algoritmul SRB a fost dezvoltat de IBM i a fost propus comitetului IEEE 802.5 ca un mijloc
de legtur ntre LAN-uri. A urmat apoi o nou propunere de standard a IBM: source-route
transparent (SRT) bridging. SRT bridging elimin SRB-ul pur propunnd ca implementrile
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 rspndit.
SRB se numete astfel deoarece presupune c ruta complet surs-destinaie se afl n toate
frame-urile (pachetele) inter-LAN transmise de surs. SRB stocheaz i transmite frame-urile
aa cum este prevzut n rutele ce au fost stabilite prin procesul numit explorare. Figura
urmtoare ilustreaz un model de reea SRB.
S presupunem c hostul X vrea s transmit un frame ctre host Y. Iniial, hostul X nu tie
dac hostul Y aparine aceluiai LAN sau nu. Pentru a determina acest lucru, hostul X
transmite un frame de test. Dac frame-ul se ntoarce la hostul X fr a conine indicaia c
hostul Y l-a vzut, atunci hostul X va presupune c hostul Y aparine unui segment aflat la
distan.

Figura 2.2: Reea SRB coninnd LAN-uri i bridge-uri


Pentru a determina locaia exact a hostului Y, hostul X trimite un frame de explorare.
Fiecare bridge care primete acest frame de explorare (Bridge 1 i 2 n exemplul nostru)
retransmite frame-ul pe toate porturile sale. Informaia despre rut este adugat frame-urilor
de explorare ct timp acestea parcurg reelele interconectate. Cnd frame-urile de explorare
de la hostul X a ajuns la hostul Y, acesta rspunde la fiecare, folosind informaiile deja
9

acumulate despre rut. Dup ce a recepionat toate frame-urile de rspuns, hostul X alege o
rut bazndu-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. Specificaiile standardului IEEE 802.5 nu stabilesc
criteriul pe care s l foloseasc hostul X n alegerea rutei, dar poate s fac cteva sugestii ca
de exemplu:
-

primul rspuns primit,


rspunsul cu numrul minim de hopuri,
rspunsul cu cea mai mare dimensiune permis pentru un frame,
combinaii ale criteriilor de mai sus.

n majoritatea cazurilor, ruta coninut n primul frame primit este cea care va fi folosit.
Dup selectarea rutei, aceasta este inserat n frame-ul destinat hostului Y, n cmpul cu
informaii de rutare (RIF- routing information field). Acest cmp este inclus numai n acele
frame-uri destinate altor LAN-uri. Prezena informaiilor privind ruta este indicat prin
setarea celui mai semnificant bit n cmpul adresa sursei, care se numete bit indicator de
informaii de rutare (RII routing information indicator).
3. Rutare static
Pentru ca rutarea ntre router-ele dintre mai multe reele s fie eficient, router-ele trebuie s
cunoasc ID-urile (adresele) celorlalte reele sau s aib configurat o rut implicit (default).
ntre mai multe reele interconectate, tabelele de rutare trebuie s fie fcute astfel nct
traficul s urmeze totdeauna o cale optim. Felul n care aceste tabele de rutare sunt
construite face de fapt diferena dintre rutarea static i rutarea dinamic.
Procesul de rutare n care tabela de rutare se construiete manual se numete rutare static.
Administratorul de reea, avnd cunotine despre topologia sistemului reele interconectate,
construiete manual tabela de rutare a fiecrui router i o actualizeaz, scriind toate rutele n
aceasta.
Rutarea static funcioneaza bine pentru puine reele intreconectate, dar nu sunt indicate n
cazul n care exist multe reele intreconectate sau care se modific. Router-ele statice nu sunt
tolerante la erori. Timpul ct o configuraie 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 nefuncionarea unui router sau prin ntreruperea unei conexiuni.
3.1 Carcateristicile router-elor
Un router are urmtoarele funcii:
1. Lucreaz n conformitate cu protocoalelor Internet specifice, IP, ICMP i alte protocoale.

10

2. Asigur interfaa ntre 2 sau mai multe reele. Pentru fiecare reea care este conectat la un
router, acesta trebuie s implementeze funciile impuse de acea reea. Aceste funcii includ de
obicei urmtoarele:
- s ncapsuleze i s decapsuleze datagramele IP (de ex. adugarea i eliminarea
header-ului Ethernet i a cmpului frame checksum FCS),
- s expedieze i s primeasc datagrame IP avnd o dimensiune mai mic dect
lungimea maxim suportat de acea reea. Aceast lungime maxim poart numele de
Maximum Transmission Unit (MTU),
- s translateze adresele IP destinaie n adrese de nivel reea potrivite reelei conectate
(de exemplu o adres hardware Ethernet), dac acest lucru este necesar,
- s cunoasc protocolul reelei de control al fluxului i indicatorii de eroare, dac
acetia exist.
3. Primete i transmite datagrame Internet. O important carcateristic a acestui proces este
gestionarea buffer-ului, controlul congestiilor de trafic i prioritizarea.
- s recunosc condiiile de eroare i s genereze erori ICMP i mesaje de informaii
suplimentare dac este cazul,
- s elimine datagramele al cror timp de via a devenit zero.
- s fragmenteze datagramele atunci cnd este cazul pentru a se ncadra n MTU-ul
reelei n care trebuie transmise,
4. Alege destinaia urmtoare pentru fiecare datagram IP, pe baza informaiilor (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 acelai sistem autonom (AS).
6. Asigur metode de gestionare a reelei i faciliti pentru suport al sistemului, incluznd
ncrcarea, raportri de stare, raportri de excepii i control.
3.2 Tabela de rutare
Router-ele sunt cele care asigur rutarea datelor ntre reele, dar, decizii privind rutarea
trebuie luate de ctre toate dispozitivele de reea (host-uri i router-e). Pentru cele mai multe
host-uri, decizia de rutare este simpl:
-

dac host-ul destinaie se afl n reeaua local, pachetul este transmis ctre hostul
destinaie,
dac host-ul destinaie aparine unei reele aflate la distan, pachetul este transmis
router-ului prin care se iese din reeaua local.

Deoarece dirijarea traficului (rutarea) se face la nivel de reea, modulul IP ia deciziile de


rutare innd cont doar de partea din adresa destinaie care reprezint adresa de reea. IP
determin ce parte din adres reprezint adresa de reea prin aplicarea unei mti de reea
adresei (se efectueaz operaia logic AND ntre adres i masc). Dac reeaua destinaie
este chiar reeaua local, masca ce se aplic poate fi masca subreelei locale. Dac pentru
adresa respectiv nu exist nici o masc, clasa de adrese din care face parte adresa va
determina poriunea care reprezint adresa reelei.
Dup detreminarea adresei reelei destinaie, modulul IP caut acea adres de reea n tabela
de rutare local. Pachetele sunt rutate ctre destinaia lor aa cum este prevzut n tabela de
rutare. Tabela de rutare poate fi construit de administratorul de reea sau prin protocoalele de

11

rutare dinamic, dar rezultatul final este acelai; IP ia decizia de rutare n conformitate cu
tabela de rutare.
O tabel de rutare are urmtoarele cmpuri:
Destination (destinaie) reeaua destinaia (sau host-ul destinaie)
Gateway - Gateway-ul care va folosit pentru transmiterea pachetului spre destinaia
specificat.
Flags - Aceti indicatori descriu anumite carcateristici ale rutei alese. Valorile posibile sunt:
U - Indic dac acea rut este up i operaional.
H - Indic faptul c acea rut este ctre un anumit host (majoritatea rutelor sunt ctre
reele).
G - Arat faptul c ruta trece printr-un gateway. Interfeele router-ului asigur rute
ctre reelele direct conectate la acestea. Toate celelelate rute folosesc gateway-uri
aflate la distan. n cazul rutelor ctre reelele direct conectate, flagul G nu este setat;
pentru toate celelalte rute este setat.
D - Arat faptul c ruta respectiv a fost adugat n urma unui mesaj ICMP de
redirecionare. Cnd un sistem afl despre o rut printr-un mesaj ICMP de
redirecionare, adaug aceast rut n tabela sa, astfel nct pachetele ctre acea
destinaie nu trebuie s fie redirecionate. Sistemul folosete flagul D pentru a marca
aceste rute.
Ref - Arat de cte ori va ncerca routerul s stabileasc o conexiune.
Use - Numrul de pachete transmise prin routerul respectiv.
Interface - Numele interfeei de reea ce este folosit de ctre o anumit rut.
Tabela de rutare a unui host:
Destination

Netmask

Gateway

Flags

Ref

Use

Interface

127.0.0.1

255.255.255.25
5
255.255.255.0
255.255.255.0
0.0.0.0

127.0.0.1

UH

298

eth0

192.1.1.1
192.1.1.3
192.1.1.1

U
UG
UG

6
4
2

73723
5325
53627

eth0

192.1.1.0
192.1.2.0
Default

Prima linie din tabel este o rut de tip loopback a hostului local. Acest adres de loopback
este rezervat. Pentru c fiecare sistem folosete 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 ctre un anumit host (127.0.0.1) i nu ruta ctre ntreaga reea
(127.0.0.0)
Alt linie unic n tabela de rutare este intrarea ce conine cuvntul default n cmpul
detinaiei. Aceast linie este pentru ruta default, iar gateway-ul specifiact n aceast linie, este
gateway-ul implicit (default). Ruta default este un numr de reea rezervat: 0.0.0.0. Gatewayul default este folosit ori de cte ori n tabela de rutare nu se gsete nici o rut ctre o
anumit adres de reea destinaie. De exemplu, tabela de rutare de mai sus nu are nici o rut
ctre reeaua 192.1.4.0. Dac router-ul primete o datagram adresat acestei reele, va trimite
datagrama ctre gateway-ul 192.1.1.1
Din tabela de mai sus se poate vedea c acest host este direct conectat la reeaua 192.1.1.0.
Ruta ctre acest reea din tabela de rutare nu specific folosirea unui gateway extern, adic,

12

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 reea.
Toate gateway-urile ce apar ntr-o tabel de rutare sunt n reelele direct conectate la sistemul
local. n exemplul de mai sus, acest lucru nseamn c n afara adreselor destinaie, toate
adresele de gateway ncep cu 192.1.1. Aceasta este singura reea la care calculatorul respectiv
este direct conectat, si n consecin este singura reea ctre 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 subreeaua sa.
n figura 3.1 nivelul IP al fiecrui host i gateway dintr-o reaea imaginar este nlocuit cu o
mic parte din tabela de rutare, n care se vd reelele destinaie i gateway-urile folosite
pentru comunicarea cu aceste destinaii. Cnd hostul surs (192.1.1.1) trimite date ctre
hostul destinaie (192.1.2.1), trebuie mai nti s determine dac adresa acestuia se afl ntre
adresele reelei locale i s aplice masca de subreea.
191.1.2.1 AND 255.255.255.0 = 191.1.2.0
Dup aplicarea mtii de subreea, IP va ti c adresa reelei destinaie este 192.1.2.0.
Conform tabelei de rutare a hostului surs, datele ctre 192.1.2.0 trebuie trimise ctre
gateway-ul 192.1.1.2. Gateway-ul 192.1.1.2 va face livrarea direct prin intrefaa 192.1.2.2.
Examinnd tabelel de rutare se observ c toate sistemele afieaz numai gateway-urile
reelelor 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 reeaua
192.1.1.0, are un alt gateway pentru ruta default.

Figura 3.1: Procesul de rutare

13

O tabel de rutare nu conine rute de tip end-to-end (nu descrie toat calea de la surs la
destinaie). De-a lungul cii ctre reeaua destinaie, rutele conin indicaii referitoare numai
la gateway-ul urmtor, 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 reeaua destinaie. Acesta este este gateway-ul final care va livra datele
ctre hostul destinaie.
4. Rutare dinamic
Rutare dinamic are loc atunci cnd router-ele discut cu router-ele adiacente informndu-se
reciproc asupra reelelor 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 colecii de sisteme
autonome (Automonous System-AS), fiecare fiind administrat de ctre o singur organizaie.
De multe ori, o corporaie 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 fiecrui sistem autonom poate fi
selectat propriul protocol de rutare ce asigur comunicaia 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 intenia de a nlocui protocolul RIP. n prezent, n Internet sunt utilizate ambele protocoale
n funcie de condiiile specifice ale fiecrui AS.
O alt categorie de protocoale de rutare este Exterior Gateway Protocols (EGP) sau
Interdomain Routing Protocol. Aceste protocoale sunt utilizate pentru comunicaia ntre
router-e aparinnd unor AS-uri diferite. Din punct de vedere istoric, protocolul de tip EGP
predominant a fost protocolul cu acelai nume: EGP (lucru ce poate da natere uneori la
confuzii). Un protocol de tip EGP mai nou este Border Gateway Protocol (BGP) ce a fost
dezvoltat cu intenia de a nlocui EGP (lucru care s-a produs n mare msur).
Succesul unei rutri dinamice depinde de 2 funcii de baz ale unui router:
-

actualizarea tabelei de rutare,


distribuirea periodic a cunotinelor ctre alte router-e sub forma informaiilor de
rutare actualizate.

Rutarea dinamic se bazeaz pe un protocol de rutare n vederea partajrii informaiilor ntre


router-e. Un protocol de rutare definete 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 actualizrile,


ce informaie este coninut n aceste actualizri,
cnd s se transmit aceast informaie,
cum s fie localizai destinatarii actualizrilor.

Atunci cnd un algoritm de rutare actualizeaz o tabel de rutare, obiectivul principal este de
a determina cea mai bun informaie ce trebuie inclus n tabela de rutare. Fiecare algoritm de
rutare interpreteaz acest lucru n mod propriu. Algoritmul genereaz un numr, numit
14

metric, pentru fiecare cale prin reea. De obicei, cu ct valoarea metricei este mai mic cu
att calea corespunztoare este mai bun. Algoritmii de rutare folosesc diverse metrici n
vederea determinrii rutei optime. Algoritmii de rutare compleci pot utiliza mai multe
metrici n vederea selectrii rutei optime, combinnd aceste metrici ntr-o metric hibrid.
Exemplu de metrici folosite:
-

lungimea cii (numrul de hop-uri),


fiabilitatea,
ntrzierea,
capacitatea de trafic,
ncrcarea,
costul comunicaiei.

Lungimea cii este metrica cea mai des folosit. Unii algoritmi de rutare permit
administratorilor de reea s asigneze costuri arbitrare fiecrei conexiuni din reea. n acest
caz, lungimea cii este suma costurilor asociate fiecrei conexiuni ce este traversat. Alte
protocoale de rutare definesc metrica hop count (numrul de hop-uri) ce specific numrul
de treceri prin echipamente de intreconectare de reele (cum ar fi router-ele) pe care un pachet
trebuie s le realizeze n drumul su de la surs pn la destinaie.
Fiabilitatea, n contextul algoritmilor de rutare se refer la rata de bii eronai a fiecrei
conexiuni de reea. Unele conexiuni pot avea ntreruperi mai des dect altele. Dup o
ntrerupere a unei conexiuni, timpul de repunere n funciune a acesteia poate fi mai mic dect
n cazul altei conexiuni. n vederea asignrii valorii corespunztoare fiabilitii fiecrei
conexiuni, pot fi luai n calcul orice factori ce influeneaz fiabilitatea. Aceste valori sunt de
tip numeric i sunt asignate de ctre administratorii de reea.
ntrzierea se refer la perioada de timp necesar pentru transferul unui pachet de la surs la
destinaie. ntrzierea depinde de muli factori, incluznd capacitatea de trafic a conexiunilor
intremediare, cozile de ateptare la fiecare router prin care trec pachetele, congestia unor
conexiuni intermediare i distana fizic ce trebuie parcurs. Deoarece ntrzierea cumuleaz
cteva variabile importante, este o metric foarte utilizat i util.
O caracteristic a oricrei conexiuni o reprezint capacitatea de trafic disponibil. Dac
ceilali factori sunt echivaleni, atunci o conexiune Ethernet de 10Mbps este de preferat unei
conexiuni pe linie telefonic nchiriat de 64Kbps. Dei capacitatea de trafic depinde de
debitul maxim al unei conexiuni, rutele prin conexiuni cu capacitate de trafic mai mare nu
sunt neaprat mai bune dect rutele prin conexiuni mai lente. De exemplu, n cazul n care o
conexiune mai rapid este foarte ncrcat, timpul necesar pentru transmiterea unui pachet
prin acest conexiune poate fi mai mare dect n cazul utilizrii unei conexiuni cu o
capacitate de trafic mai mic, dar lipsit de ncrcare.
ncrcarea reprezint gradul de ocupare a unei resurse de reea (cum ar fi router-ul).
ncrcarea poate fi calculat n diverse moduri, cum ar fi gradul de utilizare al CPU sau
numrul de pachete prelucrate pe secund. Monitorizarea continu a acestor parametrii poate
duce ea nsi la creterea ncrcrii.
Costul comunicaiei este o alt metric important, n special din cauza faptului c unele
companii acord mai puin importan performanelor dect costurilor de operare. Cu toate

15

c ntrzierile pot fi mai mari, acetia prefer s utilizeze propriile linii de comunicaii n
locul liniilor publice pentru care se pltete n funcie de durata utilizrii acestora.
Majoritatea algoritmilor de rutare pot fi ncadrai ntr-una din urmtoarele categorii:
-

distance vector (vector distan),


link state (starea conexiunii).

Algoritmii de rutare de tip distance vector determin direcia (vectorul) i distana ctre
oricare conexiune din reea. Algoritmii de tip link state (numii de asemenea shortest path
first nti calea cea mai scurt) recreeaz topologia exact a ntregii reele (sau cel puin a
poriunii din reea n care se afl situat router-ul).
Algoritmii de rutare hibrizi combin aspecte ale celor 2 tipuri de algoritmi menionai
anterior.
Algoritmul de rutare este fundamental pentru rutarea dinamic. De cte ori o topologie a unei
reele se modific din cauza extinderii, reconfigurrii sau defeciunilor, baza de informaii
referitoare la reea trebuie de asemenea modificat. Informaiile trebuie s reflecte o proiecie
clar i consistent a noii topologii. Aceast proiecie este numit convergen. Cnd toate
router-ele dintr-o reea opereaz cu aceeai baz de informaii se spune c reeaua este
convergent. O caracteristic dorit pentru orice reea o reprezint convergena 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 cii
ctre o anumit destinaie folosind cel mai mic numr posibil de hop-uri. Se consider un hop
orice trecere printr-un nod. Astfel, n reeaua din exemplul de mai jos, distana de la router-ul
A la reeaua D este 3.

Figura 4.1 Distana de la un router la destinaie


Problema devine mai interesant n cazul n care reeaua nu se ntinde de-a lungul unei linii.
De exemplu, distana dintre router-ul A i reeaua D n exemplul urmtor de reea (fig. 4.2)
poate fi 3, 4, 5 sau 6.

16

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.
Gsirea acestei ci este asigurat de algoritmii Bellman-Ford sau Dijkstra. Apoi, fiecare nod
din reea va fi ntiinat de calea cea mai scurt de la el nsui la fiecare din celelalte noduri
ale reelei.
Exist mai multe moduri de abordare a problemei de gsire a celei mai scurte ci. O metod
util de clasificare a acestor abordri este pe baza tipului de informaii necesare a fi
schimbate ntre gateway-uri pentru ca acestea s fie capabile s gseasc aceste rute.
Algoritmii bazai pe vectorul distan se bazeaz pe schimbul unei cantiti mici de
informaii. Fiecare entitate (gateway sau host) care particip la acest protocol de rutare se
presupune c pstreaz informaii despre toate destinaiile din interiorul sistemului. n
general, informaia despre toate destinaiile posibile dintr-o reea se rezum la o singur
intrare, care descrie ruta ctre toate destinaiile din acea reea. Acest lucru este posibil
deoarece att timp ct rutarea se face la nivel IP, rutarea n interiorul unei reele este
invizibil. Fiecare linie (intrare) din tabela de rutare include gateway-ul urmtor ctre care
datagramele destinate unei alte reele vor trebui trimise. n plus, mai este trecut i o msur
metric a distanei ctre destinaie. Aceast distan este oarecum un concept generalizat,
care poate caracteriza ntrzierea n trimiterea mesajelor ctre acea entitate, costul trimiterii
mesajului, etc. Algoritmii bazai pe vectorul distan sunt numii astfel din cauza faptului c e
posibil s gseasc o cale optim atunci cnd singura informaie schimbat este lista cu aceste
distane. Mai mult dect att, informaia este schimbat ntre entiti adiacente, adic entiti
care aparin aceleeai reele.
4.1.1 RIP: Protocolul bazat pe informaii 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 reelele de
calculatoare nc de la nceputul ARPANET-ului.
Acest protocol este mai util ca protocol de gateway interior. ntr-o reea vast, aa cum
este Internetul, ar fi dezavantajos s fie folosit un singur protocol de rutare. Mai curnd,
reeaua ar trebui s fie organizat ca o colecie de sisteme autonome. Un sistem autonom
este n general administrat de o singur entitate (organizaie), sau cel puin de ctre cineva cu
17

competene 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 interfaa
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 reele de
dimensiuni moderate i care folosesc tehnologii omogene. El este potrivit ca IGP pentru
campusuri i reele regionale ce folosesc linii seriale a cror vitez nu variaz foarte mult. Nu
este recomandat a fi utilzat n medii mai complexe.
RIP face parte din clasa de algoritmi numit algoritmi bazai pe vector distan. Cea mai
veche descriere a acestei clase de algoritmi de ctre autori cunoscui este aceea fcut de Ford
i Fulkerson. Din aceast cauz mai sunt numii i algoritmi Ford-Fulkerson. Termenul
Bellman-Ford este de asemenea utilizat, deoarece aceti algoritmi folosesc ecuaia Bellman,
ecuaie care este baza programrii dinamice.
RIP a fost dezvoltat pentru a fi folosit n Internet. Intrenetul const dintr-un numr de reele
conectate prin gateway-uri. Reelele componente pot fi cu legturi de tip point-to-point fie
reele 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 gatewayul decide unde anume trimite datagramele. E posibil s poat trimite datagrama direct ctre
destinaie, dac acest destinaie este n reeaua la care este direct conectat host-ul sau
gateway-ul. Interesant este situaia n care destinaia nu poate fi atins n mod direct. n
acest situaie, host-ul sau gateway-ul ncearc s trimit datagrama la un gateway care se
afl ct mai aproape de destinaie. Scopul unui protocol de rutare este deci foarte simplu:
furnizarea informaiei necesare n vederea rutrii.
4.1.1.1 Limitrile protocolului
Acest protocol nu rezolv toate problemele posibile de rutare. Aa cum am menionat mai
sus, intenia primar a fost pentru folosirea acestuia ca IGP n reele de dimensiuni mici i
relativ omogene. Trebuie menionate n plus urmtoarele limitri ale acestuia:

Protocolul este limitat pentru reele a cror cea mai lung rut (cale) are 15 hopuri.
Acest protocol, prin modul n care a fost proiectat, nu este potrivit pentru reele mai
mari. De remarcat c acest afirmaie 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 numrarea la infinit pentru rezolvarea anumitor
situaii speciale. (Acest lucru va fi explicat n capitolul urmtor). Dac sistemul de
reele cuprinde cteva sute de reele i se formeaz o bucl de rutare, rezolvarea
acestei bucle va necesita mult timp (dac frecvena actualizrilor de rute este limitat)
sau lrgime de band mare. O astfel de bucl va consuma mult din lrgimea de band
a reelei nainte ca bucla s fie corectat. Se presupune c n situaiile reale aceasta nu
va fi o problem cu excepia cazurilor n care sunt folosite linii lente. Chiar i aa,
problema va fi una special, atta timp ct sunt luate diferite precauii pentru
prevenirea unor astfel de probleme n majoritatea cazurilor.

18

Acest protocol folosete metrice fixe pentru compararea rutelor alternative. Acest
lucru nu este potrivit pentru cazurile n care rutele trebuie s fie alese innd cont de
parametrii de timp real, cum ar fi ntrzierea, fiabilitatea sau ncrcarea.

4.1.1.2 Specificaiile protocolului


RIP permite host-urilor i gateway-urilor s schimbe informaii pentru a putea gsi rute ntr-o
reea 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 documentaiilor IP, termenul
de host va fi folosit aici pentru a le defini pe oricare dintre ele. RIP este folosit pentru a
comunica informaii cu privire la rute ctre destinaii, care pot fi host-uri individuale,
reele, o destinaie special folosit pentru a comunica o rut implicit (default).
Orice host care folosete RIP este de ateptat s aib interfee ctre una sau mai multe reele.
Acestea sunt referite ca reele direct conectate la el. Protocolul se bazeaz pe accesul la
anumite informaii despre fiecare din aceste reele. Cea mai important este metrica sau
costul. Metrica unei reele este un numr ntreg ntre 1 i 15 inclusiv. El este setat ntr-o
anumit manier care nu este specificat n acest protocol. Cele mai multe din implementrile
existente folosesc o metric de valoare 1. Implementrile mai noi permit administratorului de
sistem s seteze costul pentru fiecare reea. n plus fa de cost, fiecare reea va avea o adres
IP de reea i o masc de subreea asociat. Acestea sunt setate de ctre administrator ntr-o
manier nespecificat de acest protocol.
Se presupune c exist o singur masc de subreea ce se aplic pentru fiecare reea IP, i o
singur masc de subreea pentru reelele direct conectate. Exist sisteme ce folosesc mti de
subreea diferite pentru subreele diferite aparinnd unei anumite reele. De asemenea, exist
situaii n care este de preferat pentru un sistem s cunoasc mtile subreelelor aparinnd
unor reele aflate la distan. Astfel de situaii necesit modificri ale regulilor ce guverneaz
modul de rspndire a informaiilor de subreea. Astfel de modificri cresc posibilitile de
interoperabilitate i trebuie avute n vedere ca modificri ale protocolului.
Se consider c fiecare host care are implementat RIP are o tabel de rutare. Aceast tabel
conine cte o intrare (linie), descris prin RIP, pentru fiecare destinaie care poate fi atins.
Fiecare intrare conine cel puin informaiile urmtoare:

Adresa IP a destinaiei
O metric, ce reprezint costul total al transmiterii datagramei de la host la acea
destinaie. Acest metric este suma costurilor associate cu reelele care vor fi
traversate n drumul pn la destinaie.
Adresa IP a gateway-ului urmtor de-a lungul cii ctre destinaie. Dac destinaia
este n una dintre reelele direct conectate, aceast informaie nu este necesar.
Un flag care indic dac acea informaie privind ruta a fost modificat recent. Se mai
numete "route change flag."
Diferii timpi asociai cu ruta respectiv.

Intrrile referitoare la reelele direct conectate sunt setate de ctre host, folosind diverse
informaii culese, nespecificate n acest protocol. Metrica pentru o reea direct conectat este
setat la costul acelei reele. n implementrile RIP existente, pentru acest cost este folosit
totdeauna valoarea 1. n acest caz, metrica RIP se reduce la o simpl numrare de hop-uri.
19

Metrici mai complexe pot fi folosite atunci cnd se dorete evidenierea preferinei pentru o
anumit reea fa de altele, de exemplu din cauza diferenelor privind lrgimea de band sau
sigurana acelei reele. Exsit de asemenea posibilitatea de a permite administratorului de
sistem s adauge rute adiionale.
Rutele ctre alte destinaii dect cele iniiale sunt adugate i updatate de algoritmii descrii
n capitolele urmtoare. Pentru ca un protocol s asigure informaii de rutare complete,
fiecare gateway din system trebuie s participe la aceasta. Host-urile care nu sunt gateway-uri
nu particip, dar multe implementri ale acestui algoritm permit host-urilor s recepioneze
informaiile 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 folosete RIP are un process de rutare
care trimte i primete datagrame pe portul UDP cu numrul 520. Toate mesajele transmise
prin RIP ctre un alt host, sunt trimise ctre portul 520. Toate mesajele de actualizare de rute
sunt trimise pe portul 520. Mesajele de actualizare de rute nesolicitate au ambele porturi surs
i destinaie, 520. Ceea ce se trimite ca rspuns la o cerere se trimite ctre portul de la care a
venit cererea. Interogrile specifice i mesajele de tip debug trebuie s fie trimise de la alte
porturi dect 520, dar ele vor fi direcionate ctre portul 520 al mainii int.

Figura 4.3. Formatul pachetului (RIP versiunea 1)


Formatul pachetului este evideniat n figura 4.3. Poriunea din datagram de la address
family identifier pn la metric poate aprea de pn la 25 de ori. Adresa IP (IP address) este
adresa Internet obinuit (versiunea 4) pe 32 de bii.
n protocol este prevzut 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
20

care nu funcioneaz ca gateway-uri, dar care doresc s asculte actualizrile privind rutele n
vederea monitorizrii gateway-urilor locale i a actualizrii tabelelor de rutare interne. Un
gateway care a pierdut legtura cu toate celelalte mai puin cu una din reelele sale, poate
alege s devin de tip silent, moment din care el nu mai este efectiv gateway. Oricum, acest
lucru nu se va ntmpla dac exist posibilitatea ca gateway-urile vecine s depind de
mesajele sale pentru a detecta dac reeaua czut va redeveni operaional.
Fiecare datagram conine o comand, un numr de versiune i posbil argumente. Mai jos
este descris versiunea 1 a acestui protocol. Cmpul command este folosit pentru a specifica
scopul datagramei. n tabelul de mai jos sunt prezentate cteva comenzi implementate n
versiunea 1:
1 - request

O cerere ca sistemul repondent s transmit o parte sau ntreaga tabel de


rutare.
Un mesaj ce conine toat sau numai o parte din tabela de rutare a

2 - response

expeditorului. Acest mesaj poate fi trimis ca rspuns la o cerere (request),

3 - traceon
4 - traceoff

sau poate fi un mesaj de actualizare generat de expeditor.


nvechit. Mesajele coninnd aceast comand vor fi ignorate.
nvechit. Mesajele coninnd aceast comand vor fi ignorate.
Aceast valoare este folosit de Sun Microsystems pentru scopuri personale.

5 - reserved

Dac noi comenzi sunt adugate n oricare din versiunile urmtoare, acestea
trebuie s nceap cu 6. Mesajele coninnd aceast comand pot fi ignorate
de implementrile care aleg s nu rspund la ele.

Pentru cerere i rspuns, restul datagramei conine o list de destinaii cu informaii despre
fiecare. Fiecare intrare din aceast list conine o reea sau un host destinaie i metrica pentru
ele. Formatul pachetului este fcut pentru a permite RIP s transporte informaii de rutare
pentru cteva protocoale diferite. Astfel, fiecare intrare are un cmp address family identifier
pentru a indica ce tip de adres este specificat n intrarea respectiv. Acest curs descrie
numai rutarea n cazul reelelor IP. Valoarea address family identifier pentru IP este 2. Totui,
pentru a permite dezvoltarea ulterioar, implementrile sunt obligate s ignore intrrile care
conin tipuri de adrese ce nu sunt suportate. (Dimensiunea acestor intrri trebuie s fie aceeai
ca dimensiunea unei intrri ce specific o adres IP). Procesarea mesajului continu n mod
normal dup ce au fost ignorate toate intrrile ce nu sunt suportate. Adresa IP este adresa
Internet obinuit, memorat pe 4 octei. Cmpul metric trebuie s conin o valoare
cuprins ntre 1 i 15 inclusiv, prin care se specific metrica curent pentru destinaie, sau
valoarea 16, ceea ce va indica faptul c destinaia nu poate fi atins. Fiecare rut trimis de un
gateway suprascrie orice rut anterioar trimis de la acelai gateway ctre aceeai destinaie.
Dimensiunea maxim a datagramei este 512 octei. Acetia includ numai poriunea din
datagram descris mai sus. Nu este contorizat i dimensiunea header-ului IP sau UDP.
Comenzile ce conin informaii de reea permit informaiilor s fie mprite n mai multe
datagrame. Nu sunt necesare msuri speciale pentru continuare, atta timp ct se obin
rezultate corecte n urma procesrii individuale a datagramelor.

Formatul pachetului RIP 2

21

Specificaia pentru RIP 2 (descris n RFC 1723) permite includerea multor informaii n
pachetele RIP i asigur un mecanism de autentificare simplu care nu este suportat de ctre
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


Cmpurile ce alctuiesc pachetul IP RIP 2 din figura de mai sus sunt urmtoarele:

Command Indic dac pachetul este un pachet cerere sau un pachet rspuns. Un
pachet de tip cerere ntreab dac un router a trimis o parte sau toat tabela sa de
rutare. Un pachet de tip rspuns poate fi un mesaj de actualizare de rute obinuit
nesolicitat sau poate fi un rspuns la o cerere. Rspunsurile conin linii ale tabelei de
rutare. Pachetele RIP multiple sunt folosite pentr a aduna informaii din tabele mari de
rutare.
Version Specific versiunea de RIP folosit. ntr-un pachet RIP ce conine oricare
din cmpurile RIP 2 sau folosete autentificare, aceast valoare este setat la 2.
Unused Setat 0.
Address-family identifier (AFI) Specific ce familie de adrese este folosit.
Cmpul AFI din RIPv2 are acelai rol ca i cmpul AFI din RFC 1058 RIP, cu o
singur excepie: dac AFI pentru prima linie din mesaj este 0xFFFF, restul liniei
conine informaii de autentificare. n mod obinuit, singurul tip de autentificare este o
simpl parol.
Route tag Asigur metoda de a face diferena dintre rutele interne (nvate de
RIP) i rutele externe (nvate de la alte protocoale)
IP address Specific adresa IP corespunztoare liniei.
Subnet mask Conine masca de subreea corespunztoare acestei linii. Dac acest
cmp este 0, nici o masc de subreea nu este specificat pentru linia respectiv.
Next hop Indic adresa IP a urmtorului hop ctre care trebuie trimise pachetele
corespunztoare acelei linii.
Metric Specific cte hopuri (router-e) sunt traversate n drumul spre destinaie.
Valoarea pentru acest cmp este cuprins ntre 1 i 15 pentru rutele valide i este 16
pentru o rut necunoscut.

4.1.1.4 Consideraii privind adresarea


Aa cum am stabilit anterior, rutarea bazat pe vectorul distan este folosit pentru a descrie
rute spre host-uri individuale sau spre reele. Protocolul RIP permite oricare din cele 2
variante. Destinaiile ce apar n mesaje de cerere sau de rspuns pot fi reele, 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 reea particular. Multe reele sunt configurate
astfel nct aceste informaii de rutare pentru host-uri individuale nu sunt necesare. Dac
fiecare host dintr-o anumit reea sau subreea este accesibil prin intermediul aceluiai
gateway, atunci nu este nici un motiv pentru a meniona host-urile individuale n tabelele de
rutare. Cu toate acestea, reelele care includ linii de comunicaie punct la punct, necesit
22

cteodat ca gateway-urile s pstreze rute ctre anumite host-uri. Dac acest lucru este cerut
sau nu, depinde de modul de adresare i de rutare folosit n sistemul respectiv. Astfel, unele
implementri pot alege s nu accepte rute ctre host-uri. Dac nu sunt acceptate rute ctre
host-uri, acestea vor fi ignorate atunci cnd sunt primite n mesajele de rspuns.
Formatele pachetului RIP nu fac deosebire ntre diferitele tipuri de adrese. Cmpurile care au
eticheta address pot conine:

Adresa hostului - host address


Adresa subreelei - subnet number
Adresa reelei - network number
0, indicnd ruta implicit (default)

Entitile care folosesc RIP utilizeaz informaiile specifice ce sunt disponibile cnd ruteaz o
datagram. Aceasta nseamn c, atunci cnd are loc rutarea unei datagrame, adresa sa
destinaie trebuie mai nti verificat n lista de adrese de hosturi. Apoi se verific dac se
potrivete cu vreo adres de reea sau subreea. n final, dac nu exist nici o potrivire, se va
folosi ruta default.
Cnd un host evalueaz informaiile primite prin RIP, interpretarea unei adrese depinde dac
se cunoate masca de subreea ce trebuie aplicat. Dac se cunoate masca de subreea atunci
se poate determina semnificaia adresei respective. De exemplu, fie reeaua 128.6.0.0. Masca
de subreea este 255.255.255.0. Astfel, 128.6.0.0 este o adres de reea, 128.6.4.0 este o
adres de subreea i 128.6.4.1 este adresa unui host. Cu toate acestea, dac host-ul nu
cunoate masca de subreea, 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 numr de subreea sau o adres de host. Aa cum adresa de reea nu este
de folos fr masca de subreea, se presupune c n aceast situaie adresele reprezint hosturi. Pentru a evita acest gen de ambiguiti, host-urile nu trebuie s trimit rute de subreele
host-urilor care se tie c nu cunosc mti potrivite de subreele. n mod normal, host-urile
cunosc numai mti de subreea pentru reelele direct conectate. De aceea, mai puin n
situaia n care s-a prevzut acest lucru, nu trebuie trimise rute ctre subreele n afara reelei
din care face parte subreeaua respectiv.
Aceast filtrare este asigurat de gateway-urile aflate la grania reelei de subreele. Acestea
sunt gateway-uri ce conecteaz reeaua cu alte reele. n aceast reea de subreele, fiecare
subreea este tratat ca o reea individual. Rutele ctre fiecare subreea sunt transportate de
ctre RIP. Cu toate acestea, gateway-urile de grani trimit numai o intrare (rut) pentru reea
ca i pentru toate host-urile din alte reele. Acest lucru nseamn c un gateway de grani va
trimite informaii diferite ctre vecini diferii. Pentru vecinii conectai la reeaua de subreele,
va fi generat o list cu toate subreelele la care acesta este direct conectat, folosind adresa de
subreea. Pentru vecinii conectai la alte reele, va fi trimis o singur intrare (rut) pentru
reea ca un tot, artnd i metrica asociat acestei reele. (Aceast metric ar trebui s fie cea
mai mic metric pentru subreelele la care gateway-ul este conectat).
n mod asemntor, gateway-urile de grani nu trebuie s menioneze n mesajele ctre alte
reele, rutele ctre host-uri pentru host-urile ce aparin unei reele direct conectate. Acele rute
trebuie s fie subsumate ntr-o singur intrare (rut) ctre reea ca ntreg. Nu am specificat ce
se ntmpl cu rutele ctre host-uri pentru host-urile aflate la distan (adic host-uri ce nu fac
parte din reelele direct conectate). n general, aceste rute indic anumite host-uri la care se
23

ajunge folosind o rut care nu suport alte host-uri din reeaua din care face parte host-ul
respectiv.
Adresa special 0.0.0.0 este folosit pentru ruta default. O rut default este folosit atunci
cnd nu este convenabil s se fac o list cu toate reelele posibile ntr-o actualizare RIP, i
cnd unul sau mai multe gateway-uri strns conectate (closely-connected) din sistem sunt
pregtite s se ocupe de traficul spre reelele ce nu sunt explicit specificate. Aceste gatewayuri trebuie s creeze intrri RIP pentru adresa 0.0.0.0, ca i cum ar fi o reea la care sunt
conectate. Decizia felului n care sunt create aceste intrri pentru reeaua 0.0.0.0 este lsat
celui care face implementarea. Cel mai adesea, administratorul de sistem va avea o metod
pentru a specifica ce gateway va crea intrri pentru 0.0.0.0. Sunt posibile, ns i alte
mecanisme. De exemplu, cel care face implemantarea, poate lua decizia ca orice gateway
care nelege EGP trebuie s fie declarat ca gateway default. Ar putea fi util s se permit
administratorului de reea s aleag metrica ce va fi folosit n aceste intrri. 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 aceeai manier ca i cnd ar fi
vorba de o reea avnd aceast adres. Oricum, intrarea este folosit pentru a ruta orice
datagram a crei adres destinaie nu se potrivete nici unei reele care apare n tabela de
rutare. Nu este obligatorie aplicarea acestei convenii n implementare dar acest lucru este
recomandat. Implementrile care nu suport 0.0.0.0 trebuie s ignore intrrile cu aceast
adres. n astfel de situaii nu vor include aceste intrri n propriile actualizri RIP.
Administratorii de sistem trebuie s se asigure c rutele 0.0.0.0 nu vor fi transmise mai
departe dect n mod intenionat. n general, fiecare sistem autonom, are propriul gateway
default. Astfel, rutele cu 0.0.0.0 nu trebuie s treac de grania 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 declanate de ceasuri.
La fiecare 30 de secunde, procesul de ieire este configurat s genereze un rspuns complet
ctre fiecare gateway vecin. Cnd sunt multe gateway-uri ntr-o singur reea, apare tendina
ca acestea s se sincronizeze unul cu altul astfel nct i trimit actualizrile n acelai timp.
Acest lucru se ntmpl atunci cnd timer-ul de 30 de secunde este afectat de ncrcarea
sistemului. Nu este de dorit ca mesajele de actualizare s se sincronizeze deoarece pot aprea
coliziuni. Astfel, n implementri trebuie s se aib n vedere urmtoarele precauii:

actualizrile la 30 de secunde sunt declanate de un ceas ce nu trebuie s fie afectat de


ncrcarea sistemului sau de timpul ncesitat de actualizarea precedent;
timer-ul de 30 de secunde este decalat prin adugarea unui timp aleator de fiecare dat
cnd 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
meninut n tabel pentru o scurt perioad de timp, astfel nct vecinii s poat afla c acea
rut a fost eliminat. Dup expirarea garbage-collection time ruta este tears din tabel.
Timeout-ul este iniializat cnd este stabilit o rut i de fiecare dat cnd un mesaj de
actualizare este primit pentru ruta respectiv. Dac trec 180 de secunde de la ultima
iniializare a timeout-ului, ruta este considerat expirat i va ncepe procesul de tergere.

24

tergerea are loc din unul din urmtoarele 2 motive: (1) timeout-ul expir, sau (2) metrica
este setat la 16 din cauza unei actualizri primite de la gateway-ul curent. n fiecare din cele
2 cazuri se ntmpl urmtoarele:
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 arta c acest rut a fost modificat i procesul de ieire
este atenionat s declaneze un rspuns.
Pn cnd garbage-collection timer expir, ruta este inclus n toate actualizrile trimise de
acest host, avnd o metric de valoare 16 (infinit). Cnd 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 reea, rut ce o va nlocui pe cea care va fi tears. n acest moment, garbagecollection timer va fi resetat.
4.1.1.6 Tratarea modificrilor topologiei
n practic, se ntlnesc situaii n care liniile de comunicaie se ntrerup i apoi revin.
Versiunea teoretic a algoritmului implic un numr minim de vecini apropiai. Dac
topologia se modific, se schimb i setul de vecini. Data viitoare cnd va fi fcut calculul,
aceste modificri vor fi oglindite. Implementrile actuale utilizeaz o versiune incremental a
minimizrii. Numai cea mai bun rut pentru oricare destinaie dat va fi reamintit. Dac
gateway-ul implicat n aceast rut i ntrerupe funcionarea sau dac conexiunea de reea va
cdea, calculul e posbil s nu reflecte niciodat modificrile. Algoritmul se bazeaz pe faptul
c gateway-ul i ntiineaz vecinii dac metricile sale se modific. Dac gateway-ul cade,
nu exist nici o cale de a anuna vecinii despre modificare.
n ideea de a rezolva acest tip de probleme, protocoalele bazate pe vectorul distan trebuie s
dispun de facilitatea expirrii unei rute. Detaliile depind de protocolul ales. Ca un exemplu,
n RIP fiecare gateway ce particip la rutare trimite un mesaj de actualizare ctre toi vecinii
si la fiecare 30 de secunde. Presupunem c ruta curent ctre reeaua N folosete gateway-ul
G. Dac nu se primete nimic de la G timp de 180 de secunde, se presupune c acest gateway
a czut sau c s-a ntrerupt conexiunea ctre acea reea. Deci, ruta va fi marcat ca fiind
invalid. Atunci cnd vom afla de la un alt vecin c exist o rut valid ctre reeaua N,
aceast rut valid o va nlocui pe cea invalid. De remarcat c se ateapt 180 de secunde
naintea expirrii rutei chiar dac se ateapt mesaje de la fiecare vecin la fiecare 30 de
secunde. Din pcate, cteodat mesajele se pierd n reea. De aceea, nu este o idee bun s se
invalideze o rut numai pe baza unui singur mesaj lips.
Aa cum se va vedea mai departe, este util s existe modaliti de ntiinare a vecinilor c o
anumit rut ctre o anumit reea este invalid. RIP, mpreun cu alte cteva protocoale din
aceaast clas, fac acest lucru printr-un mesaj obinuit de actualizare, marcnd acea reea ca
unreachable (la care nu se poate ajunge). O valoare specific a metricei va fi aleas pentru
a indica o destinaie de neatins; aceast valoare fiind mai mare dect 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 dect cea mai mare valoare valid pentru o
metric. 16 poate prea totui un numr surprinztor de mic. Motivul pentru care a fost aleas
aceast valoare se va vedea n continuare. n majoritatea implementrilor, aceeai convenie
este folosit intern pentru a marca o rut invalid.

25

4.1.1.7 Numrare la infinit (Counting to infinity)


Algoritmul folosit pn acum a presupus totdeauna existena 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 ctre 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 ntmpla cu metricele reelelor ce devin
inaccesibile. E relativ uor s aplicm metode matematice pentru tratarea rutelor ce devin
inaccesibile. Convenia 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 nct 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 reea devine inaccesibil. Toate gateway-urile din
imediata vecintate vor fi n timeout i metrica pentru acea reea 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 reeaua disprut care are costul 16. Atta timp ct
aceasta este singura conexiune ctre reeaua disprut toate celelalte gateway-uri din sistem
vor tinde ctre noi rute ce trec prin unul din aceste gateway-uri. E uor de obesrvat c n
aceast situaie, toate gateway-urile vor avea metrica de valoare minim 16 ctre reeaua
disprut. Gateway-urile aflate la numai un hop distan de vecinii iniiali, vor avea o metric
de valoare cel puin 17; gateway-urile aflate la 2 hopuri, cel puin 18 etc. Atta timp ct
aceste metrici sunt mai mari dect cea mai mare valoare acceptat pentru o metric, ele vor fi
setate la 16. Este evident c n aceast situaie sistemul va converge la nivelul tuturor
gateway-urilor ctre metrica 16 spre acea reea.
Din nefericire, durata intervalului de convergen nu se poate stabili ntr-un mod foarte
simplu. nainte de a merge mai departe s analizm urmtorul exemplu (figura 4.5). de
remarcat c ceea ce va fi artat n continuare nu se va ntmpla n cazul unei implementri
corecte a RIP-ului. Vom ncerca s demostrm de ce sunt necesare anumite caracteristici

Figura 4.5
Toate conexiunile au costul 1, mai puin legtura direct de la C la D care are costul 10.
Fiecare router (gateway) va avea o tabel coninnd o rut ctre fiecare reea.
S notm numai rutele de la fiecare gateway ctre reeaua D.
D:
B:
C:
A:

conectat direct, metric 1


rut prin D, metric 2
rut prin B, metric 3
rut prin B, metric 3

26

S presupunem acum c legtura dintre B i D cade. Rutele vor trebui acum modificate
pentru a folosi legtura de la C la D. Din pcate, va dura ceva vreme pentru ca acest lucru s
se ntmple. Modificrile de rutare ncep atunci cnd B anun c ruta ctre D nu mai este
utilizabil. Pentru simplificare, n tabelul urmtor se presupune c toate gateway-urile trimit
mesaje de actualizare n acealai timp. n tabel apar metricile pentru reeaua int, aa cum
apar n tabela de rutare a fiecrui gateway.
timp ------>

D
B
C
A

Next Dist. Next Dist. Next Dist. Next Dist


hop
hop
hop
hop
Dir
1
Dir
1
Dir
1
Dir
1
Unr
C
4
C
5
C
6
B
3
A
4
A
5
A
6
B
3
C
4
C
5
C
6

Next Dist. Next Dist.


hop
hop
Dir
1
Dir
1
C
11
C
12
A
11
D
11
C
11
C
12

Dir = conectat direct


Unr = de neatins (unreachable)
Apare urmtoarea problem: B este capabil s scape de ruta czut folosind un mecanism de
timeout. Dar urme ale acestei rute persist n sistem pentru o lung perioad de timp. Iniial,
A i C cred c pot ajunge la D prin B. Deci, ele vor continua s trimit mesaje de actulaizare
coninnd metrici de valoare 3. La urmtoarea iteraie, 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 cnd vor descoperi c rutele lor
prin B au disprut, fiecare va crede c mai este o rut disponibil prin cellalt. Eventual
sistemul va converge dar va trece ceva timp pn se va ntmpla acest lucru. Cel mai ru caz
este cnd o reea devine complet inaccesibil dintr-o anumit parte a sistemului. n acest caz,
metrica poate crete ncet ntr-un mod ca cel de mai sus pn cnd va deveni infinit. Din acest
motiv, problema este denumit numrare la infinit.
Acum se poate nelege de ce infinitul a fost ales s aib o valoare ct mai mic. Dac o
reea devine complet inaccesibil, e de preferat ca numrarea la infinit s se opreasc ct mai
repede. Infinitul trebuie s fie suficient de mare astfel nct nici o rut real s nu fie att de
mare. Dar nu poate fi orict de mare. Deci alegerea infinitului este o negociere ntre mrimea
reelei i viteza de convergen n cazul n care are loc o numrare la infinit. Proiectanii RIPului cred c protocolul nu e practic pentru reele cu o ntindere mai mare de 15.
Sunt cteva lucruri ce pot fi fcute pentru a preveni astfel de probleme. Una dintre ele i care
este folosit de RIP se numete "split horizon with poisoned reverse", and "triggered
updates".

4.1.1.8 Mecanismul Split horizon


Se observ c, parial, 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 cellalt. Acest lucru poate fi prevenit dac se are mai mult grij cu privire la
destinatarul informaiei transmise. n particular, nu este corect s pretinzi c deii o rut
27

pentru reeaua destinaie a vecinului de la care de fapt ai nvat acea rut. Split horizon
este o schem pentru evitarea problemelor cauzate de transmiterea actualizrilor ctre
gateway-ul de la care a fost nvat ruta. Schema split horizon n varianta simplificat
omite rutele nvate 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 ctre C ar trebui s indice c D nu
poate fi atins. Dac ruta prin C este real, atunci C ori are o legtur direct cu D, ori o
legtur prin alt gateway. Ruta lui C nu poate duce napoi la A, deoarece formeaz o bucl.
Spunndu-i lui C c D nu poate fi atins, A previne situaia n care C ar putea deveni confuz i
ar crede c exist rut prin A. Acest lucru este evident pentru o legtur punct la punct. Dar
s considerm c A i C sunt conectate printr-o reea broadcast, cum este Ethernet-ul i exist
i alte gateway-uri n aceast reea. Dac A are rut prin C, ar trebui s indice c D este de
neatins cnd discut cu orice alt gateway din acea reea. Celelalte gateway-uri din reea 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 reea nu are nevoie s
tie c A poate ajunge la D. Este o ans, pentru c nseamn c acelai mesaj de actualizare
care este folosit pentru C poate fi folosit pentru toate gateway-urile din reea. Astfel, mesajele
de actualizare pot fi trimise ca broadcast.
n general, Split horizon with poisoned reverse este mai sigur dect Split horizon. Dac 2
gateway-uri au rute care indic unul ctre cellalt, rutele reverse cu o metric de 16 vor
rupe bucla imediat. Dac rutele reverse nu sunt anunate, rutele eronate vor trebui
eleiminate prin ateptarea unui timeout. Totui, poisoned reverse are un dezavantaj: crete
mrimea metricei rutei. S considerm cazul unui backbone de campus ce conecteaz un
numr de cldiri diferite. n fiecare cldire exsist un gateway ce conecteaz backbone-ul la
reeaua local. S ne imaginm ce actualizri (de tip broadcast) de rute ar transmite acele
gateway-uri pe backbone. ntr-adevr restul reelei trebuie s tie despre fiecare gateway la ce
reele locale este conectat. Folosind Split horizon (varianta simpl), numai acele rute ar
aprea n mesajele de actualizare trimise de gateway prin backbone. Dac este folosit Split
horizon with poisoned reverse gateway-ul va trebui s menioneze toate rutele pe care le
nva de la backbone, cu metric de 16. Dac sistemul este mare (numr mare de reele i
gateway-uri), mesajul de actualizare va fi complex cu majoritatea intrrilor indicnd reele de
neatins.
ntr-un sens static, transmind rute de tip reverse cu metric de valoare 16 nu sunt
furnizate informaii adiionale. Dac exist multe gateway-uri ntr-o reea de tip broadcast,
aceste intrri suplimentare pot folosi o lime de band (capacitate de trafic) semnificativ.
Motivul pentru care sunt acolo este pentru a mbunti comportamentul dinamic (a grbi
convergena). Totui, n unele situaii administratorul de reea prefer s accepte o
convergen mai lent pentru a evita suprancrcarea reelei. Cei ce realizeaz implementarea
ar putea alege ei nii Split horizon n detrimentul Split horizon with poisoned reverse,
sau pot furniza o opiune de configurare care permite administratorului reelei s aleag
varianta pe care o consider optim. Este permis s se implementeze scheme hibride care s
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 declanrii schimbrilor de rutare ce le implic) i apoi omindu-le
din mesajele de actualizare.

28

4.1.1.9. Actualizri determinate de anumite evenimente


Mecanismul Split horizon with poisoned reverse va preveni orice bucle de rutare ce implic
numai 2 gateway-uri. Totui exist situaii 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 cnd metrica
atinge infinit i reeua implicat este deci declarat de neatins.
Actualizrile determinate de anumite evenimente sunt o ncercare de a mri viteza
convergenei. Pentru a obine aceste actualizri, adugm o regul prin care ori de cte ori un
gateway schimb metrica pentru o rut, se cere s se transmit imediat mesajul de actualizare
corespunztor, chiar dac nu este nc timpul pentru un mesaj obinuit de actualizare.
(Detaliile de timp vor fi definite pentru fiecare protocol. Unele protocoale bazate pe vector
distan, incluznd RIP, specific o mic ntrziere pentru a evita ca actualizrile s genereze
trafic excesiv n reea). De observat cum acest lucru se combin cu regulile de calculare a
noilor metrici. S presupunem c o rut a unui gateway X ctre destinaia N trece prin
gateway-ul G. Dac sosete un mesaj de actualizare de la G, gateway-ul X trebuie s valideze
informaia nou, necontnd dac noua metric este mai mare sau mai mic dect cea veche.
Dac rezultatul este o schimbare de metric, atunci gateway-ul X va trimite actualizrile ctre
toate host-urile i gateway-urile conectate la el. La rndul lor acestea pot fiecare trimite
actualizri ctre vecinii lor. Rezultatul este o cascad de actualizri. E uor s artm care
gateway-uri i host-uri sunt implicate n cascada de actualizri. S presupunem c gateway-ul
G are ruta ctre N expirat. G va trimite actualizrile ctre toi vecinii si. Totui, singurii
vecini care vor lua n considerare aceste noi informaii sunt aceia ale cror rute ctre N trec
prin G. Celelalte gateway-uri i hosturi vor vedea aceste noi informaii ca fiind rute noi care
sunt mai rele ca cele pe care deja le folosesc, i le vor ignora. Vecinii ale cror rute trec prin
G vor actualiza metricele i vor trimite actualizrile ctre toi vecinii lor. Din nou, numai acei
vecini ale cror rute trec prin el vor ine cont de aceste actualizri. Astfel, actualizrile se vor
propaga napoi de-a lungul tuturor cilor ce duc spre gateway-ul G, actualiznd metricele la
infinit. Aceast propagare se va opri cnd se va ajunge la o poriune a unei reele a crei rut
ctre destinaia N o ia pe alte ci.
Dac sistemul ar putea fi fcut astfel nct s nghee pn cnd este transmis toat
cascada de actualizri, e posibil s se demonstreze c numrtoarea 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 pcate, lucrurile nu stau chiar aa n realitate. Cnd sunt transmise actualizrile
determinate de anumite evenimente, actualizrile uzuale pot avea loc n acelai timp.
Gateway-urile care nu au primit nc actualizri determinate de anumite evenimente vor
trimite n continuare informaii bazate pe rute care de fapt nu mai exist. Este posibil ca dup
trecerea actualizrilor 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 greit.
4.1.2 IGRP Interior Gateway Routing Protocol
IGRP este un protocol (elaborat de Cisco) ce permite unui numr de gateway-uri s i
coordoneze procesele de rutare. Scopurile sunt:

29

rutare stabil chiar i n reele largi sau foarte complexe. Nici o bucl de rutare nu va
aprea nici chiar n mod tranzitoriu ;
rspuns rapid privind schimbrile de topologie ale reelei;
suprancrcare redus. Aceasta deoarece, IGRP folosete limea de band minim
necesar pentru task-urile sale;
mprirea traficului de-a lungul ctorva rute paralele atunci cnd sunt aproximativ
echivalente;
luarea n considerare a ratei de eroare i a nivelului traficului pentru ci diferite;
abilitatea de a trata mai multe tipuri de servicii pe baza unui singur set de informaii.

Implementarea curent a IGRP-ului are n vedere rutarea pentru TCP/IP. Cu toate acestea,
structura de baz a fost creat pentru a funciona cu o varietate de protocoale.
Cu timpul, rutarea a devenit o problem mai dificil dect era de ateptat. Iniial, protocoale
ca RIP erau suficiente pentru a se descurca cu majoritatea reelelor. Cu toate acestea,
creterea Internet-ului, i descentralizarea controlului structurii sale, au avut ca rezultat
crearea unui sistem de reele care este aproape dincolo de posibilitile noastre de
administrare. Situaii asemntoare au loc de asemenea n mari reele ale unor corporaii.
IGRP este o unealt fcut cu intenia de a ajuta n rezolvarea acestei probleme.
Nu exist vreo unelat care s rezolve toate problemele de rutare. n mod convenional,
problema rutrii este mprit n cteva pri. Protocoale ca IGRP sunt numite Internal
Gateway Protocols - IGPs. Acestea sunt fcute cu intenia de a fi utilizate n cadrul unui
singur set de reele, toate acestea aflndu-se sub o singur administrare. Aceste seturi de
reele sunt conectate ntre ele printr-un external gateway protocol (EGPs). Un IGP este
creat pentru a ine evidena privind detalile despre topologia reelei. Prioritar n proiectarea
unui IGP este gsirea de rute optime i rspunsurile rapide la schimbri. n cazul unui EGP se
ateapt protejarea unui sistem de reele mpotriva mesajelor eronate transmise intenionat
sau nu de alte sisteme. Prioritar n implementarea unui EGP este stabilitatea i administrarea.
Adesea este suficient pentru un EGP gsirea de rute rezonabile, mai degrab dect gsirea
unei rute optime. De fapt, exist caracteristici ale implementrii Cisco ce permit IGRP-ului s
fie folosit ca EGP n anumite circumstane. Cu toate acestea, IGRP a fost proiectat pentru a fi
utilizat ca IGP.
IGRP are cteva similariti 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
rnd prin aceea c a fost creat pentru reele mai mari i mai complexe. RIP este cel mai
utilizat din generaia 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 informaii de rutare numai cu gateway-urile adiacente.
Aceste informaii de rutare conin un rezumat al informaiilor despre restul reelei. 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
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 rutrii

30

IGRP se folosete de ctre gateway-uri ce interconecteaz cteva reele. Presupunem c


reelele folosesc o tehnologie bazat pe comutarea pachetelor. Drept urmare, gateway-urile
acioneaz ca nite comutatoare de pachete. Cnd un sistem conectat la o reea dorete s
trimit un pachet unui sistem dintr-o alt reea, l trimite unui gateway. Dac destinaia este
ntr-una din reelele conectate la gateway, gateway-ul va trimite pachetul la destinaie. Dac
destinaia este ntr-o alt reea, gateway-ul va trimite pachetul unui alt gateway care este mai
aproape de destinaie. 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 comunicaie
folosit este IP; problema rutrii este similar i pentru alte protocoale)
Destination
128.6.4.0
128.6.5.0
128.6.21.0
128.121.0.0
10.0.0.0

Gateway
none
none
128.6.4.1
128.6.5.4
128.6.5.4

Interface
Ethernet 0
Ethernet 1
Ethernet 0
Ethernet 1
Ethernet 1

(De fapt tabelele de rutare IGRP conin mai multe informaii 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 reea (de fapt adrese de subreele) 128.6.4.0 i 128.6.5.0. Astfel, pachetele
adresate acestor reele pot fi trimise direct ctre destinaie, pur i simplu prin folosirea
interfeei Ethernet corespunztoare. Sunt 2 gateway-uri apropiate (nvecinate) 128.6.4.1 i
128.6.5.4. Pachetele ctre alte reele dect 128.6.4.0 i 128.6.5.0 vor fi trimise ctre unul sau
altul din cele 2 gateway-uri. Tabela de rutare indic ce gateway trebuie folosit i pentru ce
reea. De exemplu, pachetele adresate unui host din reeaua 10.0.0.0 trebuiesc trimise ctre
gateway-ul 128.6.5.4. Considerm c acest gateway este mai aproape de reeaua 10, adic cea
mai bun rut ctre reeaua 10.0.0.0 trece prin acest gateway. Scopul primar al IGRP este s
permit gateway-urilor s construiasc i s ntrein astfel de tabele.
4.1.2.2 IGRP prezentare general
Aa cum s-a menionat mai sus, IGRP este un protocol care permite gateway-urilor s
construiasc tabela de rutare prin schimbarea de informaii cu alte gateway-uri. Un gateway
ncepe completarea tabelei de rutare cu intrri pentru toate reelele care sunt direct conectate
la el. Obine informaii despre alte reele prin schimburile de actualizri de rute cu gatewayurile adiacente. O rut conine: destinaia, urmtorul gateway ctre care trebuie trimise
pachetele, interfaa de reea ce ar trebui folosit, i informaia privind metrica. Informaia
referitoare la metric este un set de numere care descrie ct 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 cnd are sens s mprim traficul ntre 2 sau mai
multe rute. IGRP va face acest lucru oricnd 2 sau mai multe rute sunt la fel de bune.
Utilizatorul l poate de asemenea configura s mpart traficul atunci cnd rutele sunt aproape
egal de bune. n acest caz mai mult trafic va fi trimis prin calea cu metrica cea mai bun. De
exemplu dac se dorete ca traficul s fie mprit 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 dect cea a liniei de
9600 bps.
Metrica folosit de IGRP poate reprezenta:
31

ntrzierea introdus de conexiunea respectiv;


limea de band (capacitatea de trafic a conexiunii);
gradul de ncrcare a conexiunii;
fiabilitatea conexiunii.

ntrzierea introdus de o conexiune reprezint timpul necesar pentru a ajunge la destinaie


prin acea cale, n condiiile unei reele nencrcate. Desigur exist ntrziere adiional cnd
reeaua este ncrcat. Totui, ncrcarea este contabilizat prin folosirea parametrului gradul
de ncrcare a conexiunii i nu prin ncercarea de a msura ntrzierea propriu-zis. Limea
de band a conexiunii este capacitatea de trafic exprimat n bii/sec. Gradul de ncrcare a
conexiunii indic ct de mult band este folosit curent. Poate fi msurat i se modific
odat cu ncrcarea conexiunii. Fiabilitatea indic rata curent de erori. Poate fi msurat.
Dei nu sunt folosite ca parte a metricei, 2 informaii adiionale sunt transmise cu ea: hop
count i MTU. Hop count reprezint numrul de gateway-uri pe care un pachet va trebui
s le traverseze ca s ajung la destinaie. MTU reprezint mrimea maxim a pachetului ce
poate fi transmis prin ntreaga cale fr fragmentare (este MTU-ul cel mai mic dintre toate
MTU-urile reelelor traversate).
Pe baza informaiei metricelor, pentru o cale se calculeaz o singur metric compus.
Metrica compus combin efectul componentelor diferitelor metrici ntr-un singur numr
reprezentnd calitatea cii. Metrica compus este folosit pentru a decide cea mai bun cale
de urmat.
Periodic, fiecare gateway transmite prin broadcast ntreaga tabel de rutare ctre toate
gateway-urile adiacente (cu unele excepii din cauza mecanismului Split horizon). Cnd un
gateway primete acest mesaj de tip broadcast de la un alt gateway, compar tabela primit cu
cea proprie. Orice destinaii sau ci noi sunt adugate 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. Informaia din broadcast este folosit de asemenea pentru
actualizarea ocuprii canalului de comunicaie i a altor informaii despre rutele existente.
Aceast procedur general este similar cu cea folosit de toate protocoalele bazate pe
vectorul distan (n literatura matematic sunt referii ca algoritmi Belmann-Ford).
n IGRP, algoritmul general Belmann-Ford este modificat n 3 aspecte eseniale. nti, n loc
de o metric simpl, este folosit un vector de metrici pentru a caracteriza cile. Apoi, n locul
alegeri unei singure ci cu metrica cea mai mic, traficul este mprit de-a lungul mai multor
ci ale cror metrici se ncadreaz ntre anumite valori. n al treilea rnd, au fost introduse
cteva elemente pentru a asigura stabilitate n situaiile n care topologia este modificat.
Calea cea mai bun este selectat pe baza unei metrici compuse:
[(K1 / Be) + (K2 * Dc)] r
Unde:
K1, K2 = constante
Be = lrgime de band efectiv
Dc = ntrziere
r = stabilitate.
32

Cale cu cea mai mic metric compus va fi calea cea mai bun. n cazul n care exist mai
multe ci ctre aceeai destinaie, gateway-ul poate ruta pachetele de-a lungul mai multor ci.
Acest lucru este fcut innd 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 ci
ale cror metrici compuse se ncadreaz ntre anumite valori ale celei mai mici metrici
compuse. K1 i K2 indic ponderile ce vor fi atribuite lrgimii de band i ntrzierii. Acestea
depind de tipurile serviciilor. De exemplu, traficul de tip interactiv va acorda n mod normal
o importan mai mare ntrzierii iar traficul de tip transfer de fiiere, lrgimii de band.
Sunt 2 avantaje ale folosirii vectorului de metrici. Primul este c asigur posibilitatea
suportrii mai multor tipuri de servicii pe baza aceluiai set de date. Al doilea avantaj este c
mbuntete acurateea stabilirii rutelor. Cnd este folosit o singur metric, este tratat ca
i cnd ar reprezenta ntrzierea cii. Fiecare conexiune a cii este adugat la metrica total.
Dac exist o legtur cu o lrgime de band mic, ea este caracterizat n mod normal de o
ntrziere mare. Cu toate acestea, limitrile de lrgime de band nu se cumuleaz similar
ntrzierilor. Considernd lrgimea de band ca o component separat, aceasta poate fi
tratat corect. n mod asemntor, ncrcarea poate fi tratat ca un parametru separat care
indic gradul de ocupare a canalului.
IGRP asigur un sistem pentru interconectarea reelelor de calculatoare care poate rezolva n
condiii de stabilitate o topologie general (inclusiv bucle). Sistemul conine informaii
privind metricele ntregilor ci, adic, tie parametrii cilor ctre toate celelalte reele la care
oricare gateway este conectat. Traficul poate fi distribuit pe ci paralele i parametrii cii
multiple pot fi simultan calculai de-a lungul ntregii reele.
4.1.2.3 Descriere detaliat
Cnd un gateway este pornit prima dat, este iniializat tabela sa de rutare. Acest lucru poate
fi fcut de un operator de la consola de comand, sau prin citirea informaiilor din fiierele de
configurare. Este astfel asigurat o descriere a fiecrei reele conectate la gateway, inclusiv
informaii privind ntrzierea conexiunii (adic ct de mult i ia unui singur bit s traverseze
conexiunea) i lrgimea de band a conexiunii.

33

Figura 4.6 Exemplu de reea


De exemplu, n fig 4.6 gateway-ul S, n urma configurrii adreselor IP i a mtilor de reea
corespunztoare pentru interfeele sale, tie c este conectat direct la reelele 2 i 3 prin
interfeele corespunztoare. Deci, iniial, gateway 2 tie numai c el poate retransmite pachete
ctre calculatoarele din reelele 2 i 3. Toate gateway-urile sunt configurate s transmit
periodic gateway-urilor vecine informaiile cu care au fost iniializate, precum i informaiile
obinute de la alte gateway-uri. Astfel, gateway-ul S va primi actualizri de la gateway-urile
R i T i va nva c poate ajunge la calculatoarele din reeaua 1 prin gateway-ul R i
calculatoarele din reeaua 4 prin T. Gateway-ul S i trimite ntreaga tabel de rutare
(actualizat) i prin urmare n ciclul urmtor gateway-ul T va nva c el poate ajunge la
reeaua 1 prin gateway-ul S. E uor de vzut c aceste informaii despre orice reea din sistem
vor ajunge eventual la fiecare gateway din sistem.
Fiecare gateway calculeaz o metric compus pentru a determina calitatea cii ctre
calculatoarele destinaie. De exemplu, n figura 4.7, pentru o destinaie din reeaua 6,
gateway-ul A va clacula valorile metricei pentru 2 ci, prin gateway-ul B i C. De remarcat c
aceste ci sunt definite n mod simplu, prin hostul urmtor. Exist 3 rute posible de la A la
reeaua 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 reprezentnd calea prin C. Metrica sa reprezint cea mai bun cale
de a junge de la C la destinaia final. Dac A trimite un pachet ctre C, depinde de C s
decid dac va folosi pe B sau pe D.

34

Figura 4.7 Exemplu de ci alternative


Metrica compus calculat pentru fiecare cale arat astfel:
[(K1 / Be) + (K2 * Dc)] r

(1)

Unde:
r = fiabilitate
(ct % din transmisie este primit cu succes de hopul urmtor)
Dc = ntrziere compus;
Be = lrgime efectiv de band;
K1, K2 = constante.
n principiu, ntrzierea compus, Dc, poate fi determinat astfel:
Dc = Ds + Dcir + Dt

(2)

Unde:
Ds = ntrziere de comutare;
Dcir = ntrzierea de circuit (ntrzierea dat de propagarea unui bit);
Dt = ntrzierea de transmisie.

35

Cu toate acestea, n practic este utilizat o valoare standard reprezentnd ntrzierea pentru
fiecare tip de reea. De exemplu, exist o valoare standard reprezentnd ntrzierea pentru o
reea 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)
Destinaie
Network 1
Network 2
Network 3
Network 4
Network 5
Network 6

Interfa
I1
I2
I3
I2
I3
I2
I3
I2
I3

gw urmtor
C
B
C
B
C
B

Metric
conectat direct
conectat direct
conectat direct
1270
1180
1270
2130
2040
1180

Figura 4.8 Exemplu de tabel de rutare


Aceste proces de creare a unei tabele de rutare prin schimbul de informaii 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 reele 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 ecuaia (1). Folosirea unui vector de metrici permite gateway-ului s trateze
diverse tipuri de servicii, utiliznd coeficieni diferii n ecuaia (1). De asemenea,
permite o mai bun reprezentare a caracteristicilor reelei dect o metric simpl.
2. n locul alegerii unei singure ci avnd cea mai mic metric, traficul este mprit dea lungul mai multor ci avnd metrice cuprinse ntre anumite valori. Acest lucru
permite folosirea ctorva rute n paralel, asigurnd astfel mai mult eficien n
privina utilizrii lrgimii de band dect n cazul folosirii unei singure rute.
Administratorul de reea specific o constant de variaie V. Toate cile avnd metrica
compus minim M sunt pstrate. n plus, toate cile cu metrice mai mici dect VxM
sunt de asemenea reinute. Traficul este distrubuit de-a lungul mai multor ci invers
proporional cu metricile compuse asociate acestora.
3. Exist cteva probleme legate de conceptul de dezacord. Este dificil de stabilit o
strategie care s asigure folosirea unui constante de variaie cu valoare mai mare dect
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
variaie la 1 n mod permanent.
4. Cteva carcateristici au fost introduse pentru a asigura stabilitatea n cazul
schimbrilor de topologie. Aceste carcateristici au scopul de a preveni buclele de
rutare i numrarea la infinit, fenomene ce au carcaterizat ncercrile anterioare de
folosire a algoritmilor de tip Ford pentru acest tip de aplicaii. Mecanismele cele mai
importante ce asigur stabilitatea sunt "holddowns", "triggered updates", "split
horizon," i "poisoning".
36

mprirea (split-area) traficului (punctul 2) ridic ns i o problem nedorit. Constanta de


variaie V a fost introdus pentru a permite gateway-urilor s foloseasc ci diferite avnd
viteze diferite. De exemplu, poate exista o linie de 9600 bps n paralel cu o linie 19200 bps,
pentru a asigura redundana. In cazul n care constanta de variaie 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 cteva ci similare, ncrcarea va fi mprit ntre
ele). Prin creterea valorii constantei V, putem permite ca traficul s fie mprit 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 mprit ntre cele 2 linii. Pericolul este ca avnd o valoare mare
pentru V, s fie urmate ci care sunt mai lente dar i n direcii greite. Astfel trebuie s
existe o regul adiional pentru a preveni traficul s fie transmis ntr-o direcie greit. Nici
un trafic nu va fi trimis de-a lungul unei ci a crei metric compus calculat la distan
(calculat la hop-ul urmtor) este mai mare dect metrica compus calculat de gateway. n
general administratorii de sistem sunt ndrunai s nu seteze valoarea constantei la o valoare
mai mare dect 1, excepie fcnd situaiile cnd e necesar folosirea unor ci paralele. n
acest caz, constanta este setat cu grij, astfel nct s asigure rezultatul corect.
IGRP are scopul de a lucra cu mai multe tipuri de servicii i mai multe protocoale. Tipul
serviciului este o specificaie n pachetul de date care modific felul n care sunt evaluate
cile. De exemplu, protocolul TCP/IP permite pachetului s specifice importana relativ a
lrgimii de band, ntrziere mic, sau siguran (fiabilitate) ridicat. n general, aplicaiile
interactive vor specifica o ntrziere mic, n timp ce aplicaiile de transfer cantitativ vor
specifica lrgimea de band ca fiind mai important. Aceste cerine determin valorile
relative pentru K1 i K2 ce sunt necesare n ecuaia (1). Combinaiile de specificaii 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 pstrat o tabel de rutare pentru
fiecare tip de servicii. Acest lucru este fcut deoarece cile sunt selectate i ordonate n
funcie de metrica compus definit de ecuaia (1) i este diferit pentru fiecare tip de
serviciu. Informaiile 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 (anunuri privind starea conexiunii)- LSAs care constau n ID-urile
reelelor conectate la router i costurile interfeelor. LSAa sunt trimise dup activarea
gateway-ului i atunci cnd sunt detecate schimbri n topologia reelei. LSA-urile sunt
trimise folosind mai degrab mesaje de tip direct sau multicast dect mesaje de broadcast.
Router-ele link state construiesc o baz de date de anunuri LSA i folosesc aceast baz de
date pentru a calcula rutele optime care sunt adugate n tabela de rutare. Informaiile de
rutare schimbate ntre router-ele link state sunt sincronizate i se bazeaz pe confirmri. n
urmtorul tabel sunt cteva 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)

37

Avantajele protocoalelor de rutare de tip link state:

Tabele de rutare mai mici. Numai o singur rut optim pentru fiecare ID de reea
este stocat n tabela de rutare.

Suprancrcare sczut a reelei. Router-ele bazate pe starea legturii nu schimb


nici o informaie de rutare cnd reeaua este convergent.

Capacitatea de scalare. Beneficiind de tablele de rutare mici i de suprancrcare


sczut, protocoalele de rutare de tip link state se comport bine i cu reele mari i
foarte mari.

Timp de convergen sczut. Protocoalele de rutare de tip link state au un timp de


convergen sczut i reelele converg fr pericolul apariiei buclelor de rutare.

Dezavatajele protocoalelor de rutare bazate de tip link state:

Complexitate. Aceste protocoale sunt mult mai complexe i mai dificil de neles i
de depanat dect protocoalele bazate pe vectorul distan.

Mai dificil de configurat. Implementarea unui protocol de tip link state necesit
planificri i configurri suplimentare.

4.2.2 Open Shortest Path First (OSPF)


OSPF ruteaz pachetele IP numai pe baza adresei IP destinaie i a tipului de serviciu (Type
of Service - TOS) specificat n header-ul pachetului IP. Pachetele IP sunt rutate fr a fi
ncapsulate n vreun alt format al unui protocol suplimetar att timp ct tranziteaz un sistem
autonom (AS). OSPF este un protocol de rutare dinamic. Detecteaz cu uurin schimbrile
de topologie din sistemul autonom (cum ar fi cderea interfeei unui router) i calculeaz
noile rute fr 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 pstreaz o baz de date cu descrierea
topologiei sistemului autonom. Fiecare router participant are aceeai baz de date. Fiecare
element din aceast baz de date este o descriere a unui router din cadrul sistemului autonom
(de exemplu interfeele 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 acelai algoritm. De la baza de date topologic, fiecare
router i construiete un arbore cu cele mai scurte ci avnd ca rdcin pe sine nsui. Acest
arbore cu cele mai scurte ci asigur rutele ctre fiecare destinaie din sistemul autonom.
Informaiile privind rutele externe derivate apar ca frunze n arbore.
OSPF calculeaz rute separate pentru fiecare tip de serviciu (TOS). Cnd sunt cteva
rute cu cost egal ctre o anume destinaie, traficul este distribuit n mod egal de-a lungul
acestora. Costul unei rute este descris de o singur metric simpl.

38

OSPF permite gruparea mai multor tipuri de reele. Un astfel de grup se numete arie.
Topologia unei arii este ascuns de restul sistemului autonom. Aceast ascundere de
informaii permite o reducere semnificant a traficului de rutare. De asemenea, rutarea n
interiorul ariei este determinat numai de propria topologie a ariei, asigurnd totodat
protecia mpotriva unor informaii de rutare greite. O arie este o generalizare a unei
subreele IP.
OSPF permite configuraii flexibile de subreele IP. Fiecare rut distribuit de OSPF are o
destinaie i o masc. Dou subreele diferite ale aceleiai reele pot avea dimensiuni diferite
(adic mti diferite). Acest lucru este referit n mod obinuit ca subreea de lungime
variabil (variable length subnet mask - VLSM). Un pachet este rutat ctre subreeaua cea
mai bun (adic cu lrgimea cea mai mare). Host-urile sunt considerate subreele a cror
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 dect altele.
Informaiile de rutare externe derivate (de exemplu rute nvate de la Exterior Gateway
Protocol - EGP) sunt trecute n mod transparent prin sistemul autonom. Aceste informaii
externe derivate sunt meninute separat de datele protocolului OSPF. Fiecare rut extern
poate fi de asemenea etichetat de router-ul ce transmite mesaje LSA, asigurnd transmiterea
informaiilor adiionale 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 reele. O conexiune a grafului leag 2 router-e cnd acestea sunt
interconectate printr-o legtur fizic punct-la-punct. O conexiune ce conecteaz un router de
o reea indic faptul c acel router are o interfa n acea reea.
Nodurile dintr-un graf pot fi clasificate n concordan cu funcia acestora. Numai unele
dintre ele transport trafic de tranzit, adic acel trafic care nu a luat natere local i care nici
nu are un destinatar local. Nodurile ce transport traficul de tranzit sunt reprezentate n graf
avnd conexiuni att de intrare ct i de ieire.
Tip nod
1
2
3

Nume nod
Router
Reea
Reea final

Tranzit
Da
Da
Nu

OSPF suport urmtoarele tipuri de reele fizice:


Reele Point-to-point
Este o reea care interconecteaz o singur pereche de router-e. O linie serial de 56 Kbs
este un exemplu de reea punct-la-punct.

39

Reele de tip broadcast


Reele 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 reele prin folosirea protocolului OSPF Hello. Protocolul
Hello folosete avantajele mesajelor de broadcast. De asemenea, protocolul folosete
facilitile de multicast, dac acestea exist. O reea Ethernet este un exemplu de reea
broadcast.
Non-broadcast networks
Reelele ce suport multe (>2) router-e conectate dar fr s aib posibilitate de broadcast.
In aceste reele router-ele vecine sunt de asemenea descoperite prin folosirea protocolului
OSPF Hello. Cu toate acestea, din cauza lipsei posibilitii de broadcast sunt necesare
unele informaii de configurare pentru ca protocolul Hello s funcioneze corect. n aceste
reele, pachetele protocolului OSPF care sunt de obicei multicast trebuie s fie trimise
fiecrui router vecin, pe rnd. Un exemplu de reea non-broadcast este reeaua de date
public X.25 (X.25 Public Data Network - PDN).
Vecintatea fiecrui nod de reea din graf depinde de existena facilitii de multiacces (fie
broadcast fie non-broadcast) i, dac aceasta exist, de numrul de router-e care au o interfa
conectat la reea. n figura 4.9 sunt nfiate 3 cazuri. Router-ele sunt notate cu RT, iar
reelele cu N. Interfeele router-elor sunt notate cu I. Liniile dintre router-e indic reele
punct-la-punct. n parte a figurii este nfiat o reea cu router-ele conectate la ea urmat de
graful corespunztor.
Dou router-e interconectate printr-o reea punct-la-punct sunt reprezentate n graful orientat
ca fiind conectate printr-o pereche de conexiuni, cte una n fiecare direcie. Nu este
obligatoriu ca interfeelor conectate n reeaua punct-la-punct s li se asigneze adrese IP.
Astfel de reele punct-la-punct se numesc fr adres (unnumbered). Reprezentarea grafic
a reelelor punct-la-punct este conceput astfel nct aceste reele fr adres s poat fi
suportate n mod natural. Cnd se asigneaz adrese IP interfeelor, acestea sunt modelate ca
rute finale. De remarcat c, n aceast situaie, fiecare router va avea o conexiune final ctre
adresa interfeei celuilalt router. (figura 4.9)
Cnd mai multe router-e sunt ataate la o reea multiacces, garful orientat asociat va conine
toate router-ele conectate bidirecional la reea (figura 4.9). Dac la o reea multiacces este
ataat numai un singur router, n graful corespunztor reeaua va aprea ca o conexiune
final.

s
p
r
e

RT1
RT2
Ia
Ib

de la
RT1 RT2
X
X
X
X

40

Reea fizic punct-la-punct

RT3
s
p
r
e

RT3
RT4
RT5
RT6
N2

de la
RT4 RT5

RT2

N2
X
X
X
X

Reea multiacces

s
p
r
e

RT7
N3

de la
RT7 N3
X
X

Reea multiacces final


Figura 4.9 Componentele hrii reelei
Fiecare reea (final sau de tip tranzit) din graf are o adres IP i o masc de reea asociat.
Masca indic numrul de noduri din reea. Host-urile ataate direct la router-e apar n graf ca
reele finale. Masca de reea pentru un host este totdeauna 255.255.255.255 (0xffffffff), ceea
ce indic prezena unui singur nod.
4.2.2.2 Arborele celei mai scurte ci (shortest-path tree)
Cnd nici o zon OSPF nu e configurat, fiecare router n sistemul autonom are o baz de
date topologic identic, conducnd la o reprezentare grafic identic. Pe baza acestui grafic,
41

un router i genereaz tabela de rutare, prin calcularea unui arbore al celor mai scurte ci
avnd ca rdcin router-ul nsui. Evident arborele depinde de router-ul care efectueaz
calculele.
Dup ce este creat arborele, este examinat informaia 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 informaiilor de rutare extern a sistemului
autonom. Informaia 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 dect costul oricrei ci interne a sistemului
autonom. Utilizarea tipului 2 presupune c rutarea ntre sisteme autonome reprezint costul
principal al rutrii unui pachet i elimin nevoia de conversie a costurilor externe n metrici
interne de tip link state.
OSPF permite gruparea unei colecii de reele host-uri contigue. Un astfel de grup, mpreun
cu router-ele avnd interfee conectate la oricare din reelele 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
corespunztor. Topologia unei zone este invizibil din exteriorul zonei. Router-ele aflate ntro 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 situaia 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 aparinnd unei zone au pentru acea zon baze de date
topologice identice.
Rutarea n sisteme autonome are loc la 2 nivele. Dac sursa i destinaia unui pachet se afl n
aceeai zon este folosit rutarea intra-zonal; dac se afl n zone diferite este folosit
rutarea inter-zonal. n cadrul rutrii intra-zonale, pachetul este rutat numai pe baza
informaiei obinut n cadrul zonei. Nici o informaie de rutare obinut din afara zonei nu
poate fi utilizat. Acest lucru protejeaz rutarea intra-zonal de injectarea informaiei de
rutare eronate.
4.3. Sisteme autonome (Autonomous Systems)
n sisteme de reele interconectate de dimensiuni foarte mari, e necesar s se mpart reeaua
n entiti separate cunoscute ca sisteme autonome. Un sistem autonom este o parte a unei
reele avnd aceeai autoritate administrativ. Aceasta poate fi o instituie sau o corporaie,
dar poate fi de asemenea reprezentat de utilizarea unui protocol de rutare comun (cum ar fi
OSPF). Poriunile alturate ale unei reele IP, ce folosete OSPF pentru a distribui informaia
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 mprit n domenii, regiuni
sau zone care definesc o ierarhie n cadrul sistemului autonom.

42

Figura 4.10 Sisteme autonome, protocoale interior gateway, i protocoale exterior gateway.
Protocoalele folosite pentru distribuirea informaiei de rutare n cadrul unui sistem autonom
sunt cunoscute ca Interior Gateway Protocols (IGPs). Protocoalele folosite pentru
distribuirea informaiilor 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)

43

EGP-urile sunt protocoale de rutare inter-SA. Ele definesc modul n care toate reelele din
cadrul sistemelor autonome sunt anunate 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 reele 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 suplinete lipsurile EGP-ului. Versiunea curent
de BGP folosit pentru router-ele de backbone din Internet este BGP4.

44

S-ar putea să vă placă și