RIPv2 se configureaza in mod similar cu predecesorul sau. De aceea, in acest articol voi insista pe diferenta dintre un protocol “classful”(RIPv1) si unul “classless”(RIPv2). Principala limitare a RIPv1 este ca in mesajele de update acesta nu include si masca de retea. Din acest motiv pot aparea probleme cu retelele ce folosesc Variable-Length Subnet Mask(VLSM). Spre deosebire de versiunea 1, versiunea 2 include si aceste masti de retea ceea ce face ca RIPv2 sa fie compatibil cu retelele mai moderne.

RIPv2 nu reprezinta un protocol de rutare complet nou. Este mai degraba o imbunatatire a predecesorului sau. Astfel enumeram urmatoarele:

• adresa urmatorului hop este inclusa in update-urile de rutare
• foloseste adrese de multicast la trimiterea update-urile
• posibilitatea de autentificare

Dupa cum am specificat in articolul despre RIPv1, la activarea protocolului RIP acesta este “by default” versiunea 1. Pentru a folosi versiunea 2 se introcude comanda “version 2″ in modul de configurare al protocolului.

Caracteristici

RIPv1 prezinta urmatoarele caracteristici:

• este un protocol distance vector
• foloseste numarul de hopuri ca singura sa metrica folosita in alegerea rutei
• mesajele cu informatii de rutare sunt de tipul broadcast si sunt trimise la fiecare 30 de secunde
• RIP implementeaza mecanismele de Split Horizon şi Holddown timer pentru a evita aparitia buclelor de rutare
• foloseşte protocolul UDP pe portul 520 pentru trimiterea actualizărilor
• este un protocol classful
• distanta administrativa 120

Modul de functionare

RIPv1 foloseste doua tipuri de mesaje in comunicarea cu alte routere ce folosesc acest protocol: Request si Response.

Fiecare interfata configurata cu protocolul RIP trimite un mesaje de tip request la pornire. Prin acest mesaj se cer tabelele de rutare complete de la toti vecinii RIP. Un mesaj de tip response este primit de la fiecare astfel de vecin. Cand router-ul ce initializeaza cererea primeste raspunsul incepe evaluarea fiecarei intrari din tabela de rutare. Daca o intrare este noua, atunci router-ul o introduce in tabela sa de rutare. Daca intrarea exista deja, ea este inlocuita doar daca hop-count-ul celei noi este mai mic. Dupa evaluare informatiilor primite, router-ul trimite un update pe toate interfetele ce ruleaza RIP.  Acest update contine noua tabela de rutare si asftel se anunta vecinii de eventualele rute noi.

RIPv1 este un protocol de rutare classful. Update-ul referit mai sus nu contine si informatii referitoare la masca de retea. Prin urmare, un router fie foloseste masca de retea configurata pe interfata locala sau aplica masca de retea bazata pe clasa de adrese. Datorita acestei caractersitici (limitare),  retelele ce folosesc RIPv1 nu pot implementa VLSM.

Configurari de baza

Inainte de toate se intra in modul de configurare al router-ului. Se activeaza protocolul RIP prin comanda router rip.

R1(config)# router rip

Comanda  network este folosita pentru a introduce retelele direct conectate, specificarea interfetelor pe care se vor trimite/asculta actualizari.

R1(config-router)# network 192.168.13.0

R1(config-router)# network 192.168.14.0

Alte comenzi folosite in configurarea RIPv1:

• Dezactivarea Split-horizon

R1(config-router)# no ip split-horizon

• Setarea timpilor (update, invalid, holddown, flush)

R1(config-router)# timers basic 30 180 180 240

• Setarea intervalului de update

R1(config-router)# update-timer 40

• Dezactivarea update-urilor pe o interfaţă

R1(config-router)# passive-interface f0/0

• Interpretarea pachetelor primite (versiune)

R1(config-router)# ip rip receive version 1 2

Modul de utilizare (din punctul de vedere al utilizatorului) este unul destul de simplu: “instalez aplicatia, fac rost de o imagine IOS Cisco=Torrents si citesc documentatia”. Aceasta din urma este destul de comprehensiva oferind informatiile necesare pentru configurarea cu succes a setarilor aplicatiei cat si a unui fisier .net.

Problemele apar atunci cand incercati o instalare pe Windows Vista. Dupa ce ati parcurs documentatia sunteti nerabdatori sa va utilizati noile cunostinte si sa rulati o topologie. Toate bune si frumoase pana cand rulati comanda console [numele echipamentului] pentru a deschide o sesiune de consola cu echipamentul dorit. Surpriza pe care Vista o are pentru dumneavoastra este ca aceasta comanda nu genereaza nimic.

Comanda utilizeaza in spate un client de telnet, problema fiind ca Windows Vista nu are implicit pornita functionalitatea aceasta. Pentru rezolvare exista doua solutii:

1. Instalati un client de telnet (putty) si configurati aplicatia dupa cum sunteti indrumati in documentatie
2. Activati clientul de telnet al Windows-ului

Solutia 2 este mai usor de implementat deoarece nu necesita configurari ale fisierului de .conf al Dynamips-ului.

Ce trebuie sa faceti:

Navigati: Control Panel -> Programs and Features -> Turn Windows features on or off (left sidebar).

Dupa click vi se va cere permisiunea de a modifica aceste setari dupa care va aparea o fereastra din care pot fi activate functionalitati pe care Windows Vista le poate oferi.

Bifati Telnet Client.

Urmatorul pas este partea tricky. Este posibil ca dupa toate aceste configurari comanda console [nume echipament] inca sa nu mearga. Exista doua solutii:

1. Editati fisierul .net si in loc de [localhost:7200] sa scrieti [127.0.0.1:7200]
2. Editati fisierul hosts din Windows si creati o intrare noua localhost cu adresa 127.0.0.1

Fisierul hosts se poate gasi in C:\Windows\System32\drivers\etc. Pentru a putea edita fisierul trebuie sa oferiti drepturi de scriere pe acesta user-ului cu care sunteti logati. Pentru a face acest lucru editati access list-ul fisierului din properties, tab-ul security. Deschideti fisierul cu wordpad si introduceti pe o linie noua dar inainte de linia “::1 localhost” text-ul “127.0.0.1 localhost”.

Explicatia gasita de mine (disclaimer) pentru acest comportament ciudat al dynamips-ului este urmatoarea : pentru a putea accesa echipamentele emulate se foloseste un client de telnet. Echipamentele ruleaza pe masina locala (adresa IP 127.0.0.1) diferenta intre ele fiind facuta de numarul port-ului. In fisierul .net linia “[localhost:7200]” spune dynamips-ului care este primul port pe care se poate seta un server de telnet sa asculte. Problema apare atunci cand sistemul incearca sa rezolve numele localhost. Pentru a-l rezolva sistemul consulta fisierul hosts si gaseste o intrare ::1, de altfel valida dar doar pentru IPv6, lucru care impiedica conectarea clientului de telnet la echipament deoarece clientul nu are capabilitati IPv6. Aceasta este interpretarea mea a fenomenului. Se prea poate sa ma insel. Daca este asa va rog sa ma corectati.