RIP-ul este un protocol distance-vector. Routerele pe care este implementat acest tip de protocol trimit tabela proprie de rutare pe toate interfeţele active o dată la 30 de secunde. Este folosită doar metoda numărării hop-urilor în determinarea căii optime spre o reţea remote.

Putem vorbi de două versiuni RIP. Versiunea 1 foloseşte classful routing, adică toate device-urile din reţea trebuie să folosească aceeaşi mască. Versiunea a doua ne asigură classless routing, adică RIP-ul 2 trimite informaţii referitoare la mască.

Routing Information Protocol foloseşte trei tpuri de timpi pentru aşi “desfăşura activitatea” aşa cum trebuie:

- route update timer – reprezintă intervalul de timp după care un router trimite update-ul ce conţine întreaga tabelă de rutare;
- route invalid timer – timpul după care un router declară o anumită rută ca fiind invalidă. De exemplu, dacă nu are nicio veste despre o anumită reţea timp de 180 de secunde, routerul va trimite update-uri către toţi vecini ca să îi înştiinţeze despre ruta invalidă;
- holddown timer – am vorbit despre aceşti timpi într-un material anterior;
- route flush timer – timpul care se scurge de la declararea unei rute ca fiind invalidă şi până la ştergerea ei din tabela de rutare.

Este timpul să dăm şi primul exemplu de configurare de RIP.

router(config)#router rip
router(config-router)#network A.B.C.D
router(config-router)#network L.M.N.P
router(config-router)#^Z
router#

Simplu, nu? Comanda router rip activează protocolul RIP pe router, iar prin instrucţiunea network spunem router-ului căror reţele “să le facă reclamă”.

Cu ce comandă putem vedea tabela de rute? Cu show ip route.

Ştiu că e foarte scurt materialul dar sunt cam rupt de obosit după o perioadă un picuţ mai dificilă. Voi reveni cu discuţia despre IGRP – Interior Gateway Routing Protocol.

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.

Default routing

Rutele default sunt folosite pentru trimiterea pachetelor care au ca destinaţie o reţea ce nu se află în tabela de rutare înspre următorul hop (router).

Pentru configurarea rutelor default folosim aceeaşi sintaxă ca şi în cazul rutelor statice, numai că în loc de informaţiile legate de reţeaua destinaţie şi mască vom folosi wildcard-urile.

Să zicem că output-ul pentru comanda show ip route este următorul:

Gateway of last resort is 192.168.100.1 to network 0.0.0.0
C         192.168.20.0 is directly connected, FastEthernet0/0
C         192.168.100.0 is directly connected, Serial0/0
S*      0.0.0.0/0 [1/0] via 192.168.100.1

Ce avem aici? Păi avem două reţele conectate direct la router şi un S*, adică o rută default. C-urile acelea din faţa celor două reţele indică faptul că ele sunt “legate” direct la echipamentul respectiv.

Ce comandă folosim pentru a adăuga ruta default din output-ul de mai sus? Avem două posibilităţi:

ip route 0.0.0.0 0.0.0.0 192.168.100.1
ip route 0.0.0.0 0.0.0.0 s0/0 (vezi nota de mai jos)

Comenzile acestea două fac exact acelaşi lucru, adică spun router-ului că dacă nu există o intrare pentru reţeaua destinaţie în tabela sa de rutare, atunci trimite pachetul înspre hopul (router/IP) specificat în prima comandă sau înspre interfaţa de ieşire specificată în cea de-a doua comandă (s0/0).

Nota! Totuşi există o diferenţa între cele două comenzi. Atunci când folosim interfaţa de ieşire, în output-ul comenzii show ip route vom avea ruta default afişată ca fiind conectată direct la router dar cu o distanţă administrativă de 0.

Rutarea dinamică (dynamic routing)

Rutarea dinamică se întâmplă atunci când sunt folosite anumite protocoale pentru găsirea reţelelor şi pentru update-urile tabelelor de rutare. O să spuneţi…”Ok. Păi dacă putem să facem toată drăcovenia asta de rutare în mod automat…de ce dracului mai folosim celelalte feluri de rutare?”. Păi atunci când lucrăm cu rutare dinamică, automat adăugăm încărcare pe CPU-ul router-ului şi bandwidth consumat pe link-urile între routere.

Un protocol de rutare defineşte un set de reguli folosite de către router atunci când comunică informaţii legate de rutele ştiute de el şi celorlaţi “vecini” (routere vecine).

Vom vorbi în materialele viitoare întâi despre două dintre aceste protocoale de rutare: RIP (Routing Information Protocol) şi IGRP (Interior Gateway Routing Protocol).

Există două tipuri de routing protocols folosite: IGPs (interior gateway protocols) şi EGPs (exterior gateway protocols).

IGP-urile sunt folosite pentru schimbul informaţiilor de rutare între routerele care fac parte din acelaşi AS (autonomous system). Un AS este o colecţie de reţele care sunt administrate de către acelaşi operator, ceea ce înseamnă că routerele care împart aceeaşi tabelă de rutare fac parte din acelaşi AS.

EGP-urile sunt folosite atunci când se comunică între AS-uri. It’s that simple!

Un exemplu de protocol EGP este BGP-ul (Border Gateway Protocol).

Ok. Păi să ne oprim aici deocamdată. Vom continua data viitoare…

Vă salut!