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.

Distanţele administrative (administrative distances)

Distanţa administrativă (AD) este folosită pentru a marca nivelul de “încredere” al unor informaţii de rutare primite de către un router de la vecinii săi. AD-ul poate lua valori între 0 şi 255, unde 0 înseamnă “cel mai de încredere”, iar 255 se traduce prin “pe aici nu se trece” (niciun trafic nu va fi forwardat pe ruta respectivă).

Dacă de exemplu, un router primeşte două update-uri despre o reţea remote, primul lucru care este verificat de acesta este AD-ul. Dacă una dintre cele două rute are un AD mai mic decât cealaltă, atunci ea este cea care va fi pusă în tabela de rutare. Şi ce ne facem dacă ambele rute au acelaşi AD? Păi se schimbă criteriul de prioritizare…router-ul va compara cele două rute în funcţie de hop-uri sau bandwidth. Şi dacă nici cu acest criteriu rutele nu pot fi diferenţiate, atunci protocolul de rutare va face load-balancing către reţeaua remote.

Să dăm exemple de câteva AD-uri default. Pentru o reţea conectată direct la router avem un AD egal cu 0, pentru o rută statică AD-ul este 1, pentru EIGRP este 90, pentru IGRP este 100, pesntru OSPF este 110, pentru RIP este 120 şi mai avem 255-ul ăla care interzice router-ului de a folosi ruta respectivă.

Trecem acum la clasificarea protocoalelor de rutare. Avem aşa:

- protocoale distance-vector;
- protocoale link state;
- protocoale hybrid.

Protcoalele de tip distance-vector găsesc cel mai bun “drum” înspre o reţea remote judecînd în funcţie de distanţă. Ştim la ce spunem hop, nu? De fiecare dată când un pachet “traverseză” un router, avem un hop. Ruta cu cele mai puţine hop-uri către reţeaua remote, este considerată ca fiind ruta optimă. Vectorul indică direcţia înspre reţeaua la care vrem să ajungem. RIP şi IGRP sunt două protocoale de tip distance-vector. Update-urile se trimit către routerele direct conectate şi conţin tabelele întregi de rutare.

În protocoalele de tip link state sau shortest-path-first, routerele creează trei tabele diferite. Una dintre ele ţine evidenţa “vecinilor” direct conectaţi, a doua determină topologia întregii infrastructuri de reţea, iar a treia ţine tabela cu rute. Routerele link-state ştiu mai multe despre internetwork decât orice protocol de tip distance-vector. OSPF-ul este un astfel de protocol de rutare de tip shortest-path-first. Protocoalele link state trimit update-uri ce conţin starea link-urilor proprii către toate routerele din reţea. Nu vă speriaţi, vom vorbi mult mai multe pe parcurs despre OSPF.

Protocoalele de rutare hybrid folosesc chestii din primele două categorii descrise mai sus. Un protocol hybrid este EIGRP-ul.

În funcţie de nevoile specifice fiecărui business sau fiecărei companii se alege un protocol de rutare avantajos.

Ar trebui să începem să vorbim despre algoritmul folosit de către protocoalele de tip distance-vector. Dar cum este foarte multă informaţie şi multe chestii de clarificat, cred că o lăsăm pe anul viitor, pentru că oricum numai la rute şi protocoale de rutare nu ne stă capul acum în “ajun de Revelion”.