Mecanica rutarii Classful a protocoalelor RIPv1 si IGRP

Acest material descrie cu precizie ceea ce se intampla cu update-urile protocoalelor RIPv1 si IGRP si modificarile ce apar in tabela de rutare in functie de subnet mask-urile configurate intr-o retea interna. Informatiile prezentate mai jos sunt rezultatul mai multor site-uri Cisco cu informatii specifice si al unor operatii de debug extensiv facute de instructor.

Presupunem urmatoarea topologie:

Nu ne intereseaza ip-urile vecinilor de pe interfetele lui R1, insa presupunem ca acestea sunt, respectiv, din acelasi subnet cu fiecare din ip-urile locale. Presupunem ca protocol de rutare RIPv1 sau IGRP.

Cazul1: Intrare update

Vine un update de la Router5 pe interfata S0 a lui Router1 ca in figura:

Cu alte cuvinte, Router5 are direct conectat network-ul/subnetwork-ul 192.168.0.64 si a trimis acest lucru catre Router1. Sa vedem cum gestioneaza Router1 subnet mask-ul pentru acest update.

In primul rand, Router1 verifica din ce clasa majora (A,B sau C) fac parte atat update-ul cat si ip-ul de pe interfata de intrare (S0 in cazul nostru). Verificarea se face prin inspectia primilor 3 biti din primul octet de la stanga la dreapta. Daca ambele adrese fac parte din aceeasi clasa (in cazul nostru ambele sunt de clasa C) atunci ruterul verifica daca cele 2 ip-uri fac parte din acelasi major network . Verificarea se face prin AND-ing dintre ip-ul din update cu subnet-mask-ul specific clasei identificate anterior (/24 in cazul nostru), apoi AND-ing dintre ip-ul de pe interfata cu acelasi subnet mask si, in final, compararea rezultatelor. Astfel:

Daca adresele obtinute sunt identice (ca in cazul nostru), inseamna ca cele 2 ip-uri fac parte din acelasi major net. In acest caz update-ului i se aplica subnet mask-ul de pe interfata de intrare (tot prin AND-ing) si ceea ce rezulta este introdus, daca este cazul, in tabela de rutare.

IP din Update AND Subnet Mask Interfata Intrare:

0. 64 AND

0. 64

In situatia noastra, linia R 192.168.0.64 /28 [120/1] via "ID Ruter vecin", S0    apare in tabela de rutare.

Daca ruterul stabilea ca update-ul si ip-ul de pe interfata de intrare nu erau din acelasi major network (fie rezultatele celor 2 AND-ing uri anterioare erau diferite, fie clasele majore ale cele 2 IP-uri difereau), atunci ruterul aplica (prin AND-ing) subnet mask-ul implicit clasei din care face parte update-ul (/24 in cazul nostru). Rezultatul obtinut era introdus in tabela de rutare.

De exemplu, daca update-ul venea pe interfata E1 (care are IP-ul 100.0.0.1/16), linia din tabela de rutare era:

R 192.168.0.0 /24 [120/1] via "ID Ruter vecin", E1

Analog cu explicatiile anterioare, daca update-ul sosea pe interfata S1, linia din tabela de rutare ar fi fost:

R 192.168.0.64 /28 [120/1] via "ID Ruter vecin", S1

Daca update-ul sosea pe interfata E0, linia din tabela de rutare ar fi fost:

R 192.168.0.64 /30 [120/1] via "ID Ruter vecin", E0

Cazul2: Iesire update

Presupunem urmatoarea linie existenta in tabela de rutare a lui Router1:

R 192.168.0.64 /28 [120/<x>] via "ID Ruter vecin", <interfata_fizica>

Sa zicem ca ruterul trebuie sa trimita update-ul pe urmatoarele interfete: S1, E0, E1.

Daca (sub)network-ul ce urmeaza sa fie introdus in update face parte din acelasi major network cu ip-ul interfetei de iesire si subnet mask-ul (sub)network-ului coincide cu cel al interfetei de iesire atunci (sub)network-ul este trimis nealterat in update. Daca, in schimb, subnet mask-urile nu coincid, atunci network-ul nu este trimis de loc in update-urile de pe acea interfata.

Astfel, update-ul va fi trimis pe S1 ca "192.168.0.64" cu nr. de hopuri asociat +1, iar pe interfata E0 nu va fi trimis niciodata.

Daca (sub)network-ul ce urmeaza sa fie introdus in update nu face parte din acelasi major network cu ip-ul interfetei de iesire, atunci i se aplica subnet mask-ul implicit clasei din care face parte (prin AND-ing), iar rezultatul obtinut este introdus in update-ul de iesire.

In cazul interfetei E1 din exemplul nostru, cum "192.168.0.64"  "100.0.0.1" nu fac parte din acelasi major net, subnet-ului "192.168.0.64" i se va aplica masca /24 (masca implicita clasei C), iar rezultatul obtinut (192.168.0.0) va fi introdus in update.

IMPORTANT: Update-urile sosite pe o interfata nu sunt pur si simplu trimise direct pe celelalte interfete, ele se analizeaza conform discutiei de mai sus si stocate in tabela de rutare daca este cazul cu subnet mask-ul determinat. Update-urile de iesire sunt construite pe baza continutului tabelei de rutare, nu pe baza unui update venit pe o alta interfata. Acest lucru este valabil pentru orice protocol de rutare.

CONCLUZII :

Conform cu cele explicate mai sus putem conchide ca RipV1 si Igrp nu suporta masti de lungimi variabile din acelasi network major in retea (am observat ca update-urile nu sunt trimise daca masca subnet-ului nu coincide cu masca interfetei de iesire) - adica nu suporta VLSM (variable length subnet masking), nu suporta subnet-uri discontigue (adica separate de un (sub)network dintr-o alta retea majora), dar suporta subnetting simplu (adica trebuie sa avem acelasi subnet mask pentru subnet-urile dintr-un major network in toata reteaua).

Pentru a intari si mai bine aceste concluzii prezentam 3 exemple concrete (dupa aceste exemple urmeaza explicatii aditionale referitoare la functionalitatea celor doua protocoale) :

EXEMPLUL 1 :

R3 are network-ul 192.168.0.64/28 direct conectat si il trimite intr-un update nealterat pe interfata S0 catre R1.    Cum R1.S0 face parte din acelasi network major cu 192.168.0.64 el isi introduce ruta cu masca /28 in tabela de rutare. Ulterior va trimite update-ul catre R2 tot ca "192.168.0.64 " intrucat subnet mask-ul din tabela de rutare coincide cu subnet mask-ul de pe interfata de iesire. R2 va instala ruta, in mod analog, tot cu masca /28.

Concluzia : RipV1 si Igrp suporta subnetting.

EXEMPLUL 2 :

Acesta este un exemplu clasic de retele discontingue. Cele doua subnet-uri .64 si .32 sunt separate de subreteaua 100.0.0.0/16 care nu face parte din acelasi major net cu ele. Sa vedem ce se intampla. Presupunem ca R3 trimite inaintea lui R2 un update despre retelele sale.

R3 are reteaua 192.168.0.64/28 direct conectata in tabela de rutare. Urmeaza sa fie trimis un update pe interfata S0. Ruter-ul "vede" ca subnet-ul si interfata de iesire sunt din major net-uri diferite, de aceea aplica masca implicita clasei C (/24) network-ului si obtine "192.168.0.0" . Acest rezultat obtinut este introdus in update-ul ce urmeaza sa iasa. R1 primeste de la R3 aceasta informatie pe interfata S0. Din nou, cele 2 ip-uri nu fac parte din acelasi major net, astfel ca ruter-ul aplica masca /24 informatiei "192.168.0.0" si rezultatul obtinut este introdus in tabela de rutare. Tabela de rutare a lui Router1 va arata similar cu:

100.0.0.0/16 is subnetted, 1 subnets:

C 100.0.0.0, S0

192.168.0.0 is variably subnetted, 2 subnets:

R 192.168.0.0/24 [120/1] via 100.0.0.1 S0

C 192.168.0.32/28 S1

In update-ul de iesire catre R2, R1 nu va include reteaua 192.168.0.0 intrucat subnet mask-ul ei (/24) nu coincide cu cel al interfetei de iesire (/28).

In update-ul de iesire catre R3 , R1 vede ca subnet-ul 192.168.0.32 si interfata de iesire nu fac parte din acelasi major net. Ca urmare, se aplica masca default /24 subnet-ului si rezultatul obtinut este "192.168.0.0" . Ruter-ul nu poate trimite insa un update pe interfata de pe care a aflat de el initial (el stie ca 192.168.0.0/24 este accesibila via S0 => nu pot trimite update-ul despre aceeasi retea pe aceeasi interfata) - aceasta regula se numeste "split-horizon". si se activeaza pe fiecare interfata a ruterului in parte cu ajutorul comenzii "ip split-horizon". Aceasta comanda este implicita pe toate interfetele unui ruter Cisco. Observam ca Router3 nu afla despre 192.168.0.32 si nici Router2 nu afla despre 192.168.0.64. Daca dezactivam split-horizon pe interfata S0 a lui Router1, acesta va trimite update-ul cu informatia "192.168.0.0" catre Router3, si acesta din urma ii va aplica masca implicita /24 intrucat ip-ul de pe interfata de intrare nu se afla in acelasi major net cu ip-ul din update.

Astfel, Router3 va avea in tabela de rutare:

100.0.0.0 /16 is subnetted, 1 subnets:

C 100.0.0.0/16 S0

192.168.0.0 is variably subnetted, 2 subnets:

R 192.168.0.0/24 [120/1] ] via 100.0.0.2 S0

C 192.168.0.64/28 E0

Daca analizam cele 2 linii marcate cu bold din tabelele de rutare ale lui R1 si R3 observam ca avem de-a face cu o bucla de rutare (routing loop). Pachetele cu destinatii din reteaua marcata vor cicla pana la TTL-ul lor maxim intre cele 2 rutere si apoi vor fi distruse (ignorate). Iata cat de important este split-horizon in aceasta situatie intrucat impiedica aceasta bucla de rutare.

Am presupus la inceputul acestui exemplu ca R3 este cel care trimite primul un update catre R1. Ce s-ar fi intamplat in situatia in care R1 trimitea mai inainte un update despre reteaua sa ? R1 ar fi trimis update-ul ca "192.168.0.0" (explicatiile referitoare la motiv se gasesc mai sus), R3 l-ar fi instalat in tabela de rutare cu masca /24, iar cand R3 ar fi dorit sa trimita un update despre reteaua sa 192.168.0.64 catre R1, avand in vedere faptul ca ip-ul de pe interfata de iesire spre R1 si ip-ul subnet-ului nu se gasesc in acelasi major network , s-ar fi facut AND-ing cu masca /24 , update-ul rezultat ar fi fost "192.168.0.0" si nu ar mai fi fost trimis daca split-horizon era activ (deoarece 192.168.0.0 a fost primit chiar pe acea interfata).

Observam ca stabilitatea tabelelor de rutare depinde de cine este primul care trimite update-ul catre celalalt.

Concluzie: RipV1 si Igrp nu suporta retele discontingue.

EXEMPLUL 3:

In acest exemplu avem o "mixtura" de subnet mask-uri. Sa analizam ce se intampla.

Presupunem ca Router 3 este primul care trimite un update despre reteaua sa 192.168.0.64. El o va trimite nealterat pe S0 catre R1 datorita egalitatii mastilor de retea si datorita faptului ca ip-ul subnet-ului si ip-ul interfetei de iesire fac parte din acelasi major net. R1 va primi update-ul pe S0, va determina ca ip-ul de pe interfata sa si cu ip-ul din update sunt din acelasi major net si va aplica masca /30 informatiei "192.168.0.64", obtinand linia (cu bold):

C 192.168.0.16/30 S0

C 192.168.0.32/30 S1

R 192.168.0.64/30 [120/1] via 192.168.0.17

R1 va crea un update bazandu-se pe liniile din tabela sa de rutare pentru a le trimite catre R2. Cum interfata de iesire (S1) este din acelasi major net cu subnet-urile 192.168.0.64 si 192.168.0.16 si, mai mult, subnet mask-urile coincid, R1 va trimite update-ul nealterat cu cele 2 subnet-uri pe aceasta interfata. R2 primeste subnet-urile, determina ca sunt din acelasi major net cu interfata de intrare, aplica subnet mask-ul de pe interfata celor 2 linii din update si introduce rezultatele obtinute in tabela sa de rutare. Tabela de rutare va arata astfel:

C 192.168.0.32/28 S1

R 192.168.0.64/28 [120/2] via 192.168.0.33

R1 va trimite catre R3 informatia "192.168.0.32" (deja ne putem folosi de explicatiile anterioare ca sa intelegem de ce face acest lucru) iar R3 va stoca in tabela de rutare informatia:

C 192.168.0.16/28

R 192.168.0.32/28 [120/1] via 192.168.0.18

Ca o curiozitate, am obtinut prin aceasta adresare "bizara" o retea pseudofunctionala. Acest exemplu nu ar avea vreo utilitate practica, insa ne este de folos pentru analiza comportamentului protocolului de rutare.

EXPLICATII ADITIONALE:

Stim deja ca retelele direct conectate pe care dorim sa le avertizam le configuram cu ajutorul comenzii network <classful_net_address> din (config-router)# . RIP si IGRP avertizeaza toate retelele "directly connected" (adica cu Administrative Distance = 0) din tabela de rutare care cad sub incidenta retelelor majore configurate cu ajutorul comenzii network. Doua tipuri de rute au AD-ul 0: cele marcate cu "C" (adica fizic direct conectate - cu interfetele ruterului configurate ca facand parte din ele cu ajutorul comenzii ip address) si cele marcate cu "S" via interfata_fizica (configurate cu ajutorul comenzii "ip route subnet_mask interfata_iesire"). Iata deci ca si aceste rute statice cu AD-ul 0 sunt tratate de catre protocoalele de rutare ca fiind "direct conectate". Daca ruta statica are AD-ul > 0 atunci ea trebuie redistribuita (injectata) in protocolul de rutare cu ajutorul comenzii (config-router)#redistribute static .. Iata mai jos explicatia originala din CCNP:

"When using a routing protocol such as RIP or IGRP, static routes that are shown as directly connected will be automatically advertised to other routers if the appropriate network command has been issued. The next hop static route will not be advertised without additional configuration. These static routes can be included in updates if they are injected, or redistributed into the dynamic routing protocol."

Material realizat de Emanuel Balasa.

CCAI: CCNA, Unix

emanuel@credis.ro