2.2.

3 Protocolul informaţiei de rutare (RIP)

Protocolul RIP (Routing Information Protocol) este un exemplu de protocol de

rutare în interiorul unui SA de dimensiuni mici. RIP este inspirat din protocolul de
rutare Xerox XNS. RIP este un protocol de tip vector distanţă.
 2.2.3.1 Tipuri de pachete RIP

Protocolul RIP specifică două tipuri de pachete. Aceste pachete pot fi transmise de
către orice nod în care rulează protocolul RIP:
o pachete cerere: un pachet de cerere solicită nodurilor RIP vecine să transmită tabela lor
de vectori distanţă. În cerere se specifică dacă nodul vecin trebuie să transmită numai un
subset de vectori sau să transmită întregul conţinut al tabelei;
o pachete răspuns: un pachet de răspuns este transmis de către un nod pentru a anunţa
informaţia menţinută în tabela locală de vectori distanţă. Tabela este transmisă în
următoarele situaţii:
 În mod automat, la fiecare 30 de secunde;
 Ca răspuns la un pachet de cerere generat de un alt nod RIP;
 Dacă este disponibilă funcţia de actualizare declanşată (triggered update), tabela
este transmisă atunci când apare o modificare a tabelei de vectori distanţă.

Atunci când se recepţionează un pachet de răspuns la un nod, informaţia conţinută

în acesta este comparată cu cea din tabela locală de vectori distanţă. Dacă pachetul de
răspuns anunţă o rută către o destinaţie cu un cost mai mic, atunci tabela este
actualizată cu noua cale.
 2.2.3.2 Formatul pachetelor RIP

Pachetele RIP sunt transmise în cadrul datagramelor UDP (protocolul RIP lucrează peste
nivelul transport!). RIP transmite şi recepţionează datagrame folosind portul UDP cu numărul
520.

Datagramele RIP conţin maxim 512 octeţi. Informaţiile de actualizare mai mari decât
această dimensiune maximă sunt transmise în mai multe datagrame succesive.

Formatul pachetului RIP:

 2.2.3.2 Formatul pachetelor RIP (contin.)

Pachetul RIP conţine câmpurile cu următoarele semnificaţii:
o Comandă – acest câmp specifică rolul acestui pachet. Valoarea acestui câmp
determină rolul pachetului RIP, după cum urmează:
 Comandă = 1 – cerere către nodul vecin de a trimite tabela de rutare, parţial sau
total.
 Comandă = 2 – răspuns la cererea unui nod vecin sau un mesaj de actualizare
generat la iniţiativa ruterului sursă; acest pachet conţine tabela de rutare, parţial sau
total.

o Versiune – Întotdeauna cu valoarea 1, în cazul versiunii RIP-1.

o AFI (Address Family Identifier) – Identificatorul modului de adresare şi implicit, al

protocolului rutat. RIP a fost proiectat pentru a ruta pachete pentru orice tip de
protocol de nivel 3. În reţelele Internet (protocolul IP) se utilizează valoarea 2 pentru
acest câmp.
 2.2.3.2 Formatul pachetelor RIP (contin.)

o Pentru fiecare informaţie de rutare definind ruta către o anumită ţintă se specifică
perechea:

 Adresă IP – adresa IP a reţelei sau a unui staţii de lucru (host) de destinaţie.

 Metrica – Metrica (de obicei, in numar de hop-uri) până la destinaţia specificată în

câmpul anterior. Valorile uzuale sunt între 1 şi 15 (inclusiv), dar există şi valoarea 16
care specifică o destinaţie inaccesibilă.

o Rezervat – aceste câmpuri sunt scrise cu valoarea 0.

o Informaţia de anunţare a unei rute începe cu câmpul AFI şi se încheie cu câmpul de

metrică (20 octeţi pentru fiecare rută). Un pachet de 512 octeţi permite transmiterea a unui
număr maxim de 25 de informaţii de rutare în cadrul unui singur pachet RIP.
 2.2.3.3 Modurile de operare RIP

Nodurile RIP au două moduri de operare:
o Modul activ: Nodurile care lucrează în modul activ transmit tabelele lor de
vectori distanţă şi recepţionează actualizări de rutare de la nodurile RIP vecine.
De obicei, ruterii sunt configuraţi să funcţioneze implicit în modul activ.

o Modul pasiv (silenţios): Echipamentelele care lucrează în acest mod, doar

recepţionează actualizări de rutare de la nodurile RIP vecine. Aceste echipamente
nu transmit tabela de vectori distanţă. De obicei, staţiile de capăt sunt configurate
să lucreze în modul pasiv.
 2.2.3.4 Conţinutul tabelei de vectori distanţă

Tabela de vectori distanţă descrie fiecare reţea de destinaţie. Fiecare intrare din tabelă
conţine următoarele informaţii:
o Adresa reţelei/sistemului destinaţie (vectorul) descrisă de această intrare din tabelă;
o Costul asociat (distanţa) căii preferate pentru a ajunge la această destinaţie. Aceasta
determină capacitatea de a diferenţia căile multiple către o destinaţie. În acest context,
termenii de distanţă şi cost pot fi ambigui. Aceştia nu au nici o legătură directă cu distanţa
fizică exprimată în metri sau cu costul exprimat într-o monedă.
o Adresa IP a următorului ruter (next-hop) care trebuie utilizat pentru a ajunge la reţeaua
de destinaţie.
 2.2.3.5 Algoritmul de calcul al vectorilor distanţă

De fiecare dată când un nod primeşte un mesaj de anunţare a unei tabele de rutare,
acesta procesează informaţiile din mesaj pentru a identifica existenţa unei căi de cost
mai mic către fiecare destinaţie cunoscută. Această funcţie este realizată cu ajutorul
algoritmului vector distanţă RIP.
 2.2.3.5 Algoritmul de calcul al vectorilor distanţă
(contin.)

Algoritmul este prezentat pe scurt în continuare:
o La iniţializare, fiecare ruter conţine o tabelă de vectori distanţă care specifică fiecare
reţea conectată direct şi costul configurat. În mod uzual, fiecărei reţele i se asociază costul
cu valoarea 1. Acest cost reprezintă o cale cu un singur nod intermediar până la destinaţie.
Numărul total de noduri intermediare (hop) dintr-o rută este egal cu costul total al rutei.
Totuşi, costul poate fi modificat pentru a reflecta şi alte măsuri, cum ar fi: utilizarea,
viteza sau fiabilitatea.
o Fiecare ruter transmite periodic (uzual, la fiecare 30 de secunde) către ruterii vecini
tabela proprie de vectori distanţă. Un ruter poate transmite tabela şi atunci când se
produce o modificare a topologiei. Fiecare ruter utilizează aceste informaţii pentru a
actualiza propria tabelă de vectori distanţă:
 Costul total al căii pentru o anumită destinaţie este calculat prin adunarea costului raportat în
tabela transmisă de nodul vecin la costul legăturii cu acel nod. Calea cu costul minim este
salvată în tabela de vectori distanţă.
 În tabela de vectori distanţă toate informaţiile de actualizare înlocuiesc informaţiile
anterioare. Această funcţie permite ca RIP să menţină integritatea rutelor din tabela de rutare.

o Tabela de rutare IP este actualizată pentru a conţine calea de cost minim către fiecare
destinaţie.
 2.2.3.5 Algoritmul de calcul al vectorilor distanţă
(contin.)

Exemplu de actualizare a tabelelor de rutare de tip vector distanţă:
 2.2.3.6 Convergenţa algoritmului RIP şi
numărarea la infinit

După un interval de timp suficient de mare, algoritmul va calcula corect tabela de
vectori distanţă pentru fiecare nod. Totuşi, pe durata acestui timp de convergenţă,
informaţii despre rute eronate se pot propaga prin reţea.

Exemplu de numărare până la infinit:

 2.2.3.6 Convergenţa algoritmului RIP şi
numărarea la infinit (contin.)

Această reţea conţine patru ruteri interconectaţi. Fiecare legătură are costul 1, cu excepţia
legăturii dintre ruterii B şi D, care are costul 10. Valorile costurilor au fost fixate astfel pentru
ca pachetele să nu fie direcţionate pe legătura dintre ruterii B şi D. După ce reţeaua RIP
converge, fiecare ruter deţine informaţii de rutare care descriu toate destinaţiile. Spre exemplu,
pentru a ajunge la reţeaua ţintă, ruterii deţin următoarele informaţii:
o Ruterul D către reţeaua ţintă: reţea conectată direct, cu metrica 1;
o Ruterul B către reţeaua ţintă: următorul “hop” este ruterul C, iar metrica este 3;
o Ruterul C către reţeaua ţintă: următorul “hop” este ruterul D, iar metrica este 2;
o Ruterul A către reţeaua ţintă: următorul “hop” este ruterul C, iar metrica este 3.

Să considerăm în continuare situaţia în care legătura dintre ruterii C şi D nu mai este

funcţională. Astfel, după ce reţeaua reconverge, toate rutele folosesc legătura dintre ruterii B şi
D pentru a ajunge la reţeaua ţintă. Totuşi, în acest caz, timpul de reconvergenţă poate fi destul
de mare.
 2.2.3.6 Convergenţa algoritmului RIP şi
numărarea la infinit (contin.)

Figura următoare ilustrează modul în care sunt
actualizate rutele către reţeaua ţintă pe durata timpului
de reconvergenţă. Pentru simplitate, în această figură se
consideră că toţi ruterii transmit mesaje de actualizare
în acelaşi timp.
 2.2.3.6 Convergenţa algoritmului RIP şi
numărarea la infinit (contin.)

Reconvergenţa începe atunci când ruterul C sesizează că ruta via ruterul D este
indisponibilă. Ruterul C elimină imediat ruta inaccesibilă. Totuşi, un interval considerabil de
timp se va pierde până când ceilalţi ruteri elimină referinţele rutei defecte. Secvenţa de
actualizări ale tabelelor de rutare, este prezentată în continuare:

1. Înainte de producerea defecţiunii, ruterii A şi B deţin o rută către reţeaua ţintă via ruterul C.
2. Se produce defecţiunea pe legătura dintre ruterii D şi C. Ruterul C este capabil să decidă că
ruta optimă către reţeaua ţintă este acum invalidă (expiră un temporizator).
3. Ruterii A şi B continuă să transmită mesaje de actualizare care anunţă ruta optimă via ruterul
C. În realitate, această rută este invalidă deoarece legătura dintre ruterii D şi C este defectă.
4. Ruterul C primeşte mesaje de actualizare de la ruterii A şi B. Ruterul C decide (evident,
eronat) că traficul către reţeaua ţintă ar trebui rutat fie via ruterul A, fie via ruterul B. În
realitate, această rută nu este validă deoarece rutele de la ruterii A şi B sunt informaţii vechi
despre ruta iniţială via ruterul C.
5. Metrica noii rute la ruterul B către reţeaua ţintă via ruterul D a devenit mai mică decât cea
via ruterul A. Astfel, acum se poate schimba tabela de rutare la ruterul B cu valorile reale.
 2.2.3.6 Convergenţa algoritmului RIP şi
numărarea la infinit (contin.)

Convergenţa reţelei continuă deoarece ruterii A şi B sunt implicaţi într-un ciclu de
dezinformare reciprocă. Fiecare ruter pretinde a deţine ruta optimă către reţeaua ţintă via
celălalt ruter. Astfel, calea către reţeaua ţintă conţine o buclă de rutare.

Maniera în care sunt incrementate costurile din tabela de vectori distanţă a condus la
introducerea termenului de numărare la infinit. Astfel, costul continuă să crească, teoretic
tinzând la infinit. Pentru a limita acest proces de incrementare a costului, în cazul în care o
reţea este inaccesibilă trebuie să se întrerupă la un moment dat transmiterea mesajelor de
anunţare a tabelelor de rutare. În cazul protocolului RIP, s-a impus o valoare limită superioară
a costului de 16.

O consecinţă a limitării metricii este că se limitează şi numărul de noduri intermediare prin
care un pachet poate trece pe ruta de la reţeaua sursă la reţeaua destinaţie. Astfel, în reţelele
RIP orice rută care include peste 15 ruteri intermediari este considerată invalidă. Algoritmul de
rutare va elimina aceste rute.

Există alte două metode de îmbunătăţire a algoritmului clasic vector distanţă, din
perspectiva problemei numărării la infinit:

Despicarea orizontului cu întoarcere otrăvită (Split horizon with poison reverse)

Actualizări declanşate (Triggered updates)
 2.2.3.6.1 Despicarea orizontului (Split horizon)

Timpul de convergenţă excesiv de mare cauzat de numărarea la infinit poate fi redus prin
metoda de despicare a orizontului. Această nouă regulă impune ca informaţia de rutare să nu
fie retransmisă de un ruter pe aceeaşi interfaţă pe care a primit această informaţie.

Introducerea funcţiei de despicare a orizontului modifică secvenţa de actualizări de rutare.

Analizând noile tabele de rutare se observă o convergenţă mult mai rapidă în cazul utilizării
regulii de despicare a orizontului:
 2.2.3.6.1 Despicarea orizontului (contin.)

Dezavantajul acestei metode este acela că fiecare nod trebuie să aştepte să expire timpul
pentru ruta către destinaţia inaccesibilă, înainte ca această rută să fie eliminată din tabela de
vectori distanţă. În mediile RIP, acest timp de expirare este de cel puţin trei minute din
momentul ultimei actualizări a informaţiei respective. Pe durata acestui interval, ruterul
continuă să transmită informaţii eronate despre destinaţia inaccesibilă către nodurile vecine.
Acest fapt conduce la persistenţa buclelor de rutare şi a altor probleme de rutare.
 2.2.3.6.2 Despicarea orizontului cu întoarcere
otrăvită (Split horizon with poison reverse)

Metoda de întoarcere otrăvită reprezintă o îmbunătăţire adusă implementării despicării
orizontului. Astfel, cu întoarcerea otrăvită toate reţelele cunoscute sunt anunţate în fiecare
mesaj de actualizare a tabelei de rutare. Modificarea esenţială faţă de varianta anterioară este
că reţelele învăţate din mesajele sosite printr-o anumită interfaţă sunt anunţate ca fiind
inaccesibile în mesajele de rutare transmise prin aceeaşi interfaţă.

Această modificare reduce considerabil timpul de convergenţă în reţelele complexe, cu

redundanţă mare. Cu întoarcerea otrăvită, atunci când un mesaj de actualizare indică o reţea ca
fiind inaccesibilă, rutele sunt eliminate imediat din tabela de rutare. Astfel, se întrerup buclele
de rutare, înainte ca informaţiile despre acestea să se propage în reţea, spre deosebire de
aplicarea regulii clasice de despicare a orizontului, unde rutele sunt eliminate numai după
expirarea unui temporizator.

Întoarcerea otrăvită nu oferă nici un avantaj în reţelele fără redundanţă. Un alt dezavantaj al
acestei metode este posibilitatea de a creşte semnificativ numărul de mesajelor de rutare
schimbate între noduri, deoarece toate rutele (chiar şi cele inaccesibile) sunt incluse în fiecare
mesaj.
2.2.3.6.3 Actualizări declanşate (Triggered updates)

Ca şi în cazul despicării orizontului cu întoarcere otrăvită, algoritmii care utilizează

actualizări declanşate vizează reducerea timpului de convergenţă. În cazul utilizării
actualizărilor declanşate, un ruter transmite imediat tabela de vectori distanţă către nodurile
vecine, de fiecare dată când se schimbă costul unei rute. Acest mecanism asigură anunţarea
modificărilor de topologie cât mai repede şi nu în mod periodic, ca în varianta clasică.
 2.2.3.7 Limitările RIP

S-au observat mai multe limitări în mediile cu RIP:

o Valorile limită ale costurilor rutelor: O soluţie la problema numărării la infinit impune
specificarea unui cost maxim pentru o rută. Aceasta determină o limită superioară a
diametrului reţelei. Reţelele care solicită rute cu mai mult de 15 noduri intermediare
trebuie să utilizeze un alt protocol de rutare.
o Încărcarea reţelei datorită actualizării tabelelor: Difuzarea periodică a tabelelor de
vectori distanţă poate determina utilizarea excesivă a resurselor reţelei. Aceasta poate crea
probleme pe anumite segmente de reţea de capacitate redusă.
o Convergenţă relativ lentă: ca şi alte protocoale de tip vector distanţă, RIP converge
relativ lent. Aceşti algoritmi depind de temporizatoare pentru a iniţia transmiterea
mesajelor de actualizare a tabelelor de rutare.
o Nu suportă subreţele de dimensiune variabilă (VLSM): mesajele de anunţare a rutelor
nu includ masca subreţelelor. Prin urmare, în reţelele RIP este imposibilă utilizarea
VLSM.
 2.2.4 Versiunea 2 a protocolului RIP (RIP-2)

Organizaţia IETF (Internet Engineering Task Force) recunoaşte două versiuni ale
protocolului RIP:

o Versiunea 1 RIP (RIP-1): Acest protocol este descris în RFC (Request for Comments)
1058.
o Versiunea 2 RIP (RIP-2): RIP-2 este tot un protocol de tip vector distanţă proiectat
pentru rutarea în interiorul unui SA. RIP-2 este descris în RFC 2453 şi vizează rezolvarea
problemelor observate în cazul RIP-1.

RIP-2 este similar cu RIP-1, dar prezintă în plus următoarele avantaje:

o Suportă CIDR şi VLSM: RIP-2 suportă super-reţelele (CIDR) şi subreţelele de

dimensiuni variabile (VLSM). Acesta este motivul principal pentru dezvoltarea acestui
nou standard.
o Transmisiunile multicast: RIP-2 transmite mesajele de anunţare a rutelor sub formă de
multicast, în locul difuzării. Aceasta reduce încărcarea staţiilor de lucru, care nu mai
interpretează mesajele RIP-2.
o Autentificare: RIP-2 suportă autentificarea fiecărui nod care transmite mesajele de
anunţare a rutelor. Aceasta previne ca surse neautorizate să modifice tabelele de rutare.
o Compatibilitate cu RIP-1.