Algoritmul care stă în spatele acestui tip de protocol de rutare (distance vector) trimite tabela de rutare completă routerelor vecine care o combină cu cea pe care o au deja şi formează propria lor tabelă de rutare.

Este posibil să avem o reţea care are mai multe link-uri înspre aceeaşi reţea remote, iar în acest caz distanţa administrativă este verificată prima dată. Dacă şi AD-ul este acelaşi, protocolul va trebui să se folosească de alte metode pentru determinarea rutei optime înspre reţea remote respectivă.

RIP-ul foloseşte doar numărul hop-urilor pentru aflarea “drumului” optim către o reţea. Dacă acelaşi RIP găseşte mai multe rute înspre reţeaua remote cu acelaşi număr de hop-uri atunci el va trece la acţionarea load balancing-ului pe cele două link-uri. Acest protocol de rutare este în stare să efectueze load balancing pe 6 link-uri simultan (cu acelaşi număr de hop-uri înspre destinaţia remote).

Însă, avem o problemă atunci când două link-uri cu acelaşi număr de hop-uri au bandwidth-uri diferite înspre o reţea remote. Să luăm un exemplu. Reţeau remote să fie 172.16.10.0, iar cele două link-uri să aibă ca şi bandwidth 1,54 Mbps şi 56K. Normal că am prefera ca să urmăm ruta cu T1. Să punem şi ” o poză” aici:

Aşadar, cum noi folosim RIP, el vede cele două link-uri ca şi având costuri egale. Acestui “issue” i se mai zice şi pinhole congestion. Este important pentru noi să ştim cum “gândeşte” un protocol distance-vector. În figura de mai sus avem patru routere. Toate la început pornesc doar cu rutele direct conectate în tabela de rutare. După ce pornim un protocol de tip distance-vector pe fiecare router, tabelele de routing sunt updated cu informaţiile primite de la routerele vecine. Fiecare router trimite întreaga tabelă de rutare pe fiecare din link-urile active pe care le posedă. Astfel înainte de distance vector avem:

Iar după ce pornim un protocol de routing distance-vector avem ceva de genul:

În tabelele de rutare de mai sus avem adresa de reţea destinaţie, interfaţa pe care trimitem pachetele (exit) şi numărul hop-urilor înspre reţeaua remote. Ultima poză conţine tabelele de routig întregi, deoarece includ informaţii despre fiecare reţea din internetwork. Le mai considerăm şi converged. Nu ştiu exact cum să traduc acest concept în română, aşa că nici nu o să mă chinuiesc. Apare atunci când se modifică tabela de rutare. De aceea când apar schimbări, timpul de convergence este foarte important. În cazul RIP-ului este un timp mare, aşa că este posibil ca atunci când routerele sunt ocupate cu “schimbările” să ai o mică problemă.

Loop-uri în routing

Protocoalele de rutare distance-vector  au grijă să ţină cont de orice schimbare apărută în internetwork şi să trimită update-uri periodice pe toate link-urile active. Aceste update-uri sunt de fapt tabelele de rutare întregi. Ce rezultă de aici? CPU usage mare, bandwidth folosit şi dacă mai ţinem cont şi de timpul de “convergenţă” mare nu e prea ok în cazul unor outage-uri. Şi aici apar şi loop-urile, atunci când router-ele nu sunt updated simultan.

Dar despre loop-uri şi metode de rezolvare a acestei probleme, vom discuta în materialul următor.