Figura 1- Scenariu de baz

Studiu Rutarea static

1. Configurare rute statice Rutarea statica presupune configurarea unor rute statice catre toate retelele cu care se doreste a avea conectivitate. Administratorul trebuie sa introduca reelele pentru fiecare ruter n parte , operatie ce necesita multa munca si atentie din partea administratorului. Pentru configurarea retelei in modul static se foloseste urmtoarea comand n modul configuare globala : R(config): ip route [ ip destinaie] [masc pentru ip destinaie] [interfaa de ieire /urmtorul nod ] opionale: [metrica], [numele], [rut permanent], [marcr] Pentru conectivitate ntre R1 si R3: R1(config)#ip route 192.168.23.0 255.255.255.0 192.168.12.2 R1(config)#ip route 192.168.34.0 255.255.255.0 192.168.14.4 Dar pentru a funciona pingul trebuie configurata i ruta napoi. R3(config)#ip route 192.168.14.0 255.255.255.0 192.168.34.4 R3(config)#ip route 192.168.12.0 255.255.255.0 192.168.23.2 Se verifica tabela de rutare cu comanda show ip route: R3#sh ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set S 192.168.12.0/24 [1/0] via 192.168.23.2 S 192.168.14.0/24 [1/0] via 192.168.34.4 C 192.168.23.0/24 is directly connected, Serial0/0 C 192.168.34.0/24 is directly connected, Serial0/1 Rutele introduse vor avea litera S (static) n stnga lor, cele direct conectate au litera C (connected). Desi nu am configurat nimic pe R2 si R4 , ruterele intermediare, pingul totui functioneaz R3#ping 192.168.14.4 Sending 5, 100-byte ICMP Echos to 192.168.14.4, timeout is 2 seconds:

!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/61/104 ms Interesant de observat este faptul c dac am fi trimis tot traficul de la R4 spre R1 pe ramura de sus adica prin R2, si am fi dat din nou ping, acesta nu ar mai fi funcionat. Acest lucru se intampla deoarece pachetul ajunge la ruterul R2, adica urmatorul nod, dar R2 nu are in tabela de rutare reteaua 192.16.14.0 aa c va renuna la pachet. Adugand rute statice pe R2 si R4 vom avea conectivitatea n ntreaga reea. Daca s-ar introduce reele noi, ar trebui configurate manual ctre fiecarea reea att ruta dus ct i cea ntors.
2. Configurare rut static cu metric prestabilit.

n cazul in care legatura dintre R1 i R2 s-ar dezactiva desi exista o ruta alternativa pachetele de la R1 spre reteau 192.168.23.0 nu ar mai ajunge. Pentru a rezolva aceasta problema vom configura o rut alternativ prin R4 spre 192.168.23 dar cu metrica mai mare pentru a pstra ruta prin R2 ca ruta principal. R1(config)#ip route 192.168.23.0 255.255.255.0 192.168.12.2 10 R1(config)#ip route 192.168.23.0 255.255.255.0 192.168.14.4 50 Daca inchidem interfata dintre ruterul R1 si ruterul R2 ruta cu metrica 10 va fi stears din tabela de rutare si se va introduce ruta cu metrica 50. Folosind comanda debug ip routing putem urmri ntreg procesul: *Mar *Mar *Mar *Mar *Mar *Mar *Mar *Mar *Mar 1 06:00:49.466: RT: interface Serial0/0 removed from routing table 1 06:00:49.466: RT: del 192.168.12.0 via 0.0.0.0, connected metric [0/0] 1 06:00:49.466: RT: delete network route to 192.168.12.0 1 06:00:49.466: RT: NET-RED 192.168.12.0/24 1 06:00:50.466: RT: del 192.168.23.0 via 192.168.12.2, static metric [10/0] 1 06:00:50.466: RT: delete network route to 192.168.23.0 1 06:00:50.466: RT: NET-RED 192.168.23.0/24 1 06:00:50.466: RT: add 192.168.23.0/24 via 192.168.14.4, static metric [50/0] 1 06:00:50.470: RT: NET-RED 192.168.23.0/24

Desi timpul necesar pentru configurare este foarte mare, ceea ce constituie un dezavantaj foarte mare, rutarea statica are dou avantaje: nu se face trafic necesar procesului de rutare in retea, deci am toata latimea de banda disponibila pentru traficul de date, si nu se foloseste procesorul . Rutarea statica este folosita ntre echipamentele utilizatorului si cele ale furnizorului de servicii.

Protocoale Intra-domeniu Studiu RIP

1. Limitri Rip v1 si rezolvarea lor prin configurarea versiunii extinse RIP v2

Cand un protocol este pornit pentru prima data va trimite mesaje de tip cerere pentru a obtine informatiile necesare procesului de rutare, si va primii inapoi mesaje de tip raspuns cu intreaga tabela de rutare a vecinilor. Rip v1 foloseste adresa de broadcast (difuzare) pentru a trimite informatiile, ceea ce inseamna ca statiile nu vor putea ignora mesajele RIP. De fiecare data cand se primeste un mesaj de difuzare, fiecare statie l va procesa i va determina daca pachetul i este adresat. Cand se foloseste RIP v2 acest comportament este evitat, datorit adresrii multicast. *Mar 1 00:50:30.859: RIP: sending request on Serial0/0 to 255.255.255.255

*Mar 1 00:50:30.907: RIP: received v1 update from 192.168.12.2 on Serial0/0 *Mar 1 00:50:30.907: 192.168.23.0 in 1 hops *Mar 1 00:50:30.911: 192.168.34.0 in 1 hops Rip v1 este un protocol limitat deoarece nu suport adresarea CIDR, ceea ce nseamna ca o adresa cu masca /24 nu poate fi subnetat. Prin comanda debug ip rip se poate observa lipsa mstii de subreea n mesajul de actualizare trimis de ruterul R1 catre ruterul R2. *Mar 1 02:13:51.083: RIP: build update entries *Mar 1 02:13:51.083: network 2.0.0.0 metric 1 *Mar 1 02:13:51.083: network 3.0.0.0 metric 1 Pe ruterul R2 folosind comanda debug ip rip database se poate verifica primirea unui mesaj de actualizare cu masca /8. *Mar 1 02:19:50.855: RIP-DB: network_update with 2.0.0.0/8 succeeds *Mar 1 02:19:50.855: RIP-DB: adding 2.0.0.0/0 (metric 1) via 192.168.34.2 on Serial0/0 to RIP database *Mar 1 02:19:50.859: RIP-DB: network_update with 3.0.0.0/8 succeeds *Mar 1 02:19:50.859: RIP-DB: adding 3.0.0.0/0 (metric 1) via 192.168.34.2 on Serial0/0 to RIP database Versiunea actualizat Ripv2 este un protocol classless ce trimite in pachetele de actualizare masca de subretea. Sumarizarea automata este pornita implicit pentru Ripv2 iar pentru a putea beneficia de rutarea classless, sumarizarea automata trebuie dezactivata. Vizualizand mesajele schimbate intre ruterele ce ruleaza acest protocol se poate observa existenta mastii de retea i trimiterea pachetelor la adresa de multicast 224.0.0.9 *Mar *Mar *Mar *Mar 1 00:42:59.771: RIP: build update entries 1 00:42:59.771: 2.2.2.0/27 via 0.0.0.0, metric 1, tag 0 1 00:42:59.771: 3.3.3.0/29 via 0.0.0.0, metric 1, tag 0 1 00:43:00.283: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (192.168.12.1)

n tabela de rutare, reelele sunt afisate cu masc de reea corect si litera R , specificand protocolul prin care au fost nvate R2# [...] Gateway of last resort is not set 192.168.12.0/30 is subnetted, 1 subnets C 192.168.12.0 is directly connected, Serial0/0 2.0.0.0/27 is subnetted, 1 subnets R 2.2.2.0 [120/1] via 192.168.12.1, 00:00:15, Serial0/0 192.168.14.0/29 is subnetted, 1 subnets R 192.168.14.0 [120/1] via 192.168.12.1, 00:00:15, Serial0/0 3.0.0.0/29 is subnetted, 1 subnets R 3.3.3.0 [120/1] via 192.168.12.1, 00:00:15, Serial0/0 192.168.23.0/29 is subnetted, 1 subnets C 192.168.23.0 is directly connected, Serial0/1 192.168.34.0/29 is subnetted, 1 subnets R 192.168.34.0 [120/1] via 192.168.23.3, 00:00:24, Serial0/1

2. Timpi folositi n Rip

Fiind un protocol vector de distanta se trimite actualizari periodice la fiecare 30 de secunde ctre portul UDP 520. Folosind debug ip rip se poate observa transimiterea acestor actualizare la fiecare 30 de secunde. *Mar 1 01:29:17.791: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 92.168.24.2) *Mar 1 01:29:17.795: RIP: build update entries *Mar 1 01:29:17.795: 2.2.2.0/27 via 0.0.0.0, metric 2, tag 0 *Mar 1 01:29:17.799: 192.168.12.0/30 via 0.0.0.0, metric 1, tag 0 *Mar 1 01:29:17.799: 192.168.23.0/29 via 0.0.0.0, metric 1, tag 0 [...........] *Mar 1 01:29:47.191: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 92.168.24.2) *Mar 1 01:29:47.195: RIP: build update entries *Mar 1 01:29:47.195: 2.2.2.0/27 via 0.0.0.0, metric 2, tag 0 *Mar 1 01:29:47.199: 192.168.12.0/30 via 0.0.0.0, metric 1, tag 0 *Mar 1 01:29:47.199: 192.168.23.0/29 via 0.0.0.0, metric 1, tag 0 3. Calcul metric Mare dezavantaj al protocolului Rip este limitarea la numrul maxim de 16 noduri. Metrica folosita in rip este cumulativa, reprezintand suma tuturor costurilor asociate reelelor traversate pentru a ajunge la destinaie. Exemplu : R1# debug ip rip *Mar 1 01:53:34.759: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (192.168.12.1) *Mar 1 01:53:34.759: RIP: build update entries *Mar 1 01:53:34.763: 2.2.2.0/27 via 0.0.0.0, metric 1, tag 0 Ruterul R1 trimite catre ruterul R2 prin interfata S0/0 o actualizare despre reteaua 2.2.2.0/27. In tabela lui R1 aceast reea are o metrica egal cu 1, ceea ce inseamna ca este o reea direct conectata. R2 va primi actualizarea , R2# debug ip rip *Mar 1 01:29:15.775: RIP: received v2 update from 192.168.12.1 on Serial1/0 *Mar 1 01:29:15.779: 2.2.2.0/27 via 0.0.0.0 in 1 hops [...] va recalcula noua metric, i va trimite actualizarea ctre restul vecinilor *Mar 1 01:30:02.271: RIP: sending v2 update to 224.0.0.9 via Serial1/1 (192.1.23.2) *Mar 1 01:30:02.271: RIP: build update entries *Mar 1 01:30:02.275: 2.2.2.0/27 via 0.0.0.0, metric 2, tag 0 [...]

Studiu Eigrp
1. Stabilirea adiacentelor Spre deosebire de Rip , unde este suficienta comanda network retea, protocol Eigrp necesit la configurare introducerea wildcardului si a sistemului autonom din care face parte. R4(config)#router eigrp 1 R4(config-router)#network 192.168.24.0 0.0.0.7 Un proces Eigrp incepe cu descoperirea vecinilor, folosind pachete de tip salut. Apoi va trimite actualizari in mod multicast si va astepta confirmari unicast. Mesajele de tip salut se transmit in mod implicit odata la 5 secunde, dar acest interval poate fi modificat. Comanda debug eigrp packets ne permite sa urmarim schimbul de mesaje salut intre vecini. *Mar *Mar *Mar *Mar 1 10:56:16.661: EIGRP: Sending HELLO on FastEthernet0/0 1 10:56:16.661: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 1 10:56:19.237: EIGRP: Received HELLO on FastEthernet0/0 nbr 192.168.24.4 1 10:56:19.241: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

Acest mesaj ne confirm stabilirea adiacentei. *Mar 1 05:48:50.578: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.24.2 (FastEthernet0/0) is up: new adjacency
2. Tabele utilizate

Eigrp ntretine trei tabele : tabela cu vecini, tabela de topologie i tabela de rutare. Tabela cu vecini contine informatii despre ruterele adiacente si este folosita pentru a verifica primirea confirmarilor de la toti vecinii. Tabela de topologie contine anumite rute din retea. Cele mai bune rute din tabela de topologie sunt introduse in tabela de rutare.
2.1 Tabela cu vecini

R2#sh ip eigrp neighbors IP-EIGRP neighbors for process 1 H Address Interface 2 1 0 192.168.24.4 192.168.23.3 192.168.12.1 Fa0/0 Se1/1 Se1/0

Hold Uptime (sec) 10 00:48:41 14 00:48:44 13 00:48:44

SRTT (ms) 164 8 8

RTO 984 200 200

Q Cnt 0 0 0

Seq Num 34 35 40

Exista doua probleme in legatura cu actualizarile sigure folosite de Eigrp. Pe de o parte, ruterul nu stie cate pachete de tip Confirmare s atepte, deoarece nu cunoaste numarul de rutere din retea. Pe de alta parte, ruterul nu stie daca o actualizare pierduta inseamna ca nu exista nici o informatie noua, sau daca vecinul este deconectat. Aceaste probleme sunt rezolvate folosind notiunea de vecini. Pachetele de tip salut sunt folosite pentru a construi tabela de vecini pe fiecare ruter. Daca un vecin nu trimite pachete salut o anumita perioda de timp (hold time), atunci vecinul este scos din tabela Eigrp si se produce o reconvergenta a rutarii. Tabela cu vecini va fi folosita pentru a verifica care dintre acestia nu au confirmat.
2.2 Tabela de topologie

In tabela de topologie este stocata distanta raportata si distanta viabila pentru fiecare ruta in parte. Se modifica atunci cand o ruta direct conectata sau o interfata se schimba sau cand un vecin anunta modificarea unei rute. R2#sh ip eigrp topology IP-EIGRP Topology Table for AS(1)/ID(192.168.24.2) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 192.168.34.0/29, 1 successors, FD is 2172416 via 192.168.24.4 (2172416/2169856), FastEthernet0/0 via 192.168.23.3 (2681856/2169856), Serial1/1 P 192.168.12.0/30, 1 successors, FD is 2169856 via Connected, Serial1/0 P 192.168.14.0/29, 1 successors, FD is 2172416 via 192.168.24.4 (2172416/2169856), FastEthernet0/0 via 192.168.12.1 (2681856/2169856), Serial1/0 P 192.168.24.0/29, 1 successors, FD is 28160 via Connected, FastEthernet0/0 P 192.168.23.0/29, 1 successors, FD is 2169856 via Connected, Serial1/1 Din tabelul urmator se poate observa ca sistemul autonom de care apartine ruterul este 1 iar identificatorul ruterului este RID 192.168.24.2. Prima coloana reprezinta starea rutei respective care poate fi : P (Passive)- reteaua este accesibila, ruta poate fi instalata in tabela de rutare; A (Active)- reteaua nu este accesibila, ruta nu poate fi instalata in tabela de rutare. Exist pachete de tip interogare trimise catre aceasta ruta; U (Update), Q (Query), R( Reply status) S( Stuck in active)- ruta este in starea blocat pe activ, ceea ce inseamna existena unor probleme de convergenta 2.3 Tabela de rutare Folosind comanda show ip route eigrp pentru inspecta doar rutele EIGRP din tabela de rutare. 192.168.14.0/29 is subnetted, 1 subnets D 192.168.14.0 [90/2172416] via 192.168.24.4, 04:13:13, FastEthernet0/0 3.0.0.0/29 is subnetted, 1 subnets D EX 3.3.3.0 [170/2297856] via 192.168.12.1, 00:08:17, Serial1/0 192.168.34.0/29 is subnetted, 1 subnets D 192.168.34.0 [90/2172416] via 192.168.24.4, 04:13:13, FastEthernet0/0 Eigrp va introduce in tabela de rutare 3 tipuri de rute: interne, externe si sumarizate. Cele interne vor fi reprezentate prin litera D, cele externe prin literele D EX. Dupa adresa retelei destinatie, intre paranteze patrate se afla doua numere. Primul numar reprezinta distanta administrativa care pentru rute Eigrp interne este 90 si pentru rute Eigrp externe este 170. Protocolul Eigrp a fost configurat peste Rip, iar datorit distantei administrative mai mici se va prefera Eigrp ca protocol de rutare. Al doilea numar reprezinta metrica rutei care este egala cu distanta viabila din tabela de topologie. Urmatorul camp va specifica adresa urmatorului nod catre destinatia respectiva. Mai vedem timpul scurs de la ultimul anunt despre aceasta rut, precum si interfata de iesire pentru aceea destinatie.

3. Timpi si mesaje schimbate folositi in Eigrp

Spre deosebire de celelalte protocoale bazate pe vectori de distana, Eigrp nu trimite actualizari in mod periodic, ci doar atunci cnd apar modificari de topologie. Dupa cum se poate observa si din procesul de depnare se trimit actualizri doar referitoare la rutele modificate. Eigrp are un comportament diferit faa de protocoalele bazate pe starea legaturilor, acestea din urma trimind actualizri catre toate ruterele din retea.

4. Optimizarea timpilor de convergenta folosind Dual Protocolul Eigrp permite retinerea in tabela de topologie a unor rute de rezerv, denumite rute viabile, ce vor promova in tabela de rutare automat, atunci cand nici un ruter succesor nu mai este accesibil. Datorita acestui proces, timpii de convergenta in Eigrp sunt foarte mici. R2# sh ip route eigrp 2.0.0.0/27 is subnetted, 1 subnets D 2.2.2.0 [90/2297856] via 192.168.12.1, 00:52:44, Serial1/0 192.168.14.0/29 is subnetted, 1 subnets D 192.168.14.0 [90/2172416] via 192.168.24.4, 02:32:49, FastEthernet0/0 192.168.34.0/29 is subnetted, 1 subnets D 192.168.34.0 [90/2172416] via 192.168.24.4, 02:32:49, FastEthernet0/0 Se observa ca de pe ruterul R2 la reteaua 192.168.34.0 se ajungea prin interfata fa0/0, urmatorul nod 192.168.24.4. Vom inchide aceasta interfata, iar cu debug ip routing si debug eigrp fsm se poate studia modul in care functioneaza Dual *Mar *Mar *Mar *Mar *Mar 1 14:07:10.704: RT: delete route to 192.168.34.0 via 192.168.24.4, FastEthernet0/0 1 14:07:10.704: RT: no routes to 192.168.34.0, flushing 1 14:07:10.704: RT: NET-RED 192.168.34.0/29 1 14:07:10.704: RT: delete network route to 192.168.34.0 1 14:07:10.704: RT: NET-RED 192.168.34.0/24

*Mar *Mar *Mar *Mar *Mar *Mar *Mar *Mar *Mar *Mar

1 14:07:10.712: DUAL: Destination 192.168.34.0/29 1 14:07:10.712: DUAL: Find FS for dest 192.168.34.0/29. FD is 2172416, RD is 2172416 1 14:07:10.712: DUAL: 192.168.24.4 metric 4294967295/4294967295 1 14:07:10.712: DUAL: 192.168.23.3 metric 2681856/2169856 found Dmin is 2681856 1 14:07:10.712: DUAL: Removing dest 192.168.34.0/29, nexthop 192.168.24.4 1 14:07:10.712: RT: add 192.168.34.0/29 via 192.168.23.3, eigrp metric [90/2681856] 1 14:07:10.712: RT: NET-RED 192.168.34.0/29 1 14:07:10.716: DUAL: RT installed 192.168.34.0/29 via 192.168.23.3 1 14:07:10.716: DUAL: Send update about 192.168.34.0/29. Reason: metric chg 1 14:07:10.716: DUAL: Send update about 192.168.34.0/29. Reason: new if

Se poate observa faptul ca pentru gsirea unei noi rute spre reteau 192.168.34.0, nu a fost nevoie de trecerea rutei in stare activa. Asadar nu s-au mai trimis pachete de tip interogare catre vecini, si nu a mai fost nevoie de procesarea raspunsurilor, convergenta realizndu-se foarte rapid in doar 12ms. Acest lucru a fost posibil datorita faptului ca n tabela de topolgie avem doua rute spre aceast reea. P 192.168.34.0/29, 1 successors, FD is 2172416 via 192.168.24.4 (2172416/2169856), FastEthernet0/0 via 192.168.23.3 (2681856/2169856), Serial1/1 Prima ruta cea de cost mai mic (2172416) este ruta directa (succesorul),ea fiind introdus si n tabela de rutare, a doua fiind ruta de rezerva prin ruterul R3. Pentru a fi retinut in tabela de topologie aceasta rut trebuie sa respecte regula de alegere a succesorului viabil (Fs), costul total al celei mai bune rute fiind mai mare decat distanta raportata de primul vecin pe ruta de rezerv (2172416>2169856) Calculnd distanta raportata de R1, adica costul caii de la R1 la reteaua 192.168.34.0 observam ca R1 nu indeplinea conditia de viabiliate, motiv pentru care nu a fost introdus in tabela de topologie. Latime de band= 107/min(latime band)= 107/1544=6476 ntrzierea=2x20000/10 = 4000 Metrica= 256x( 6476+4000)= 2681856 > 2172416 (Distanta raportat de ctre ruterul R1 este mai mare decat costul total al succesorului ) Vom repeta procesul dar vom inchide si interfata serial 1/1, astfel incat in tabela de topologie nu va mai exista nici un succesor, ruta intrnd in starea active. *Mar *Mar *Mar 0/29 *Mar *Mar *Mar *Mar *Mar *Mar *Mar *Mar *Mar *Mar *Mar table 1 16:16:18.071: RT: delete route to 192.168.34.0 via 192.168.23.3, Serial1/1 1 16:16:18.071: RT: no routes to 192.168.34.0, flushing 1 16:16:18.071: RT: NET-RED 192.168.34. 1 16:16:18.071: RT: delete network route to 192.168.34.0 1 16:16:18.071: RT: NET-RED 192.168.34.0/24 1 16:16:18.079: DUAL: Destination 192.168.34.0/29 1 16:16:18.079: DUAL: Find FS for dest 192.168.34.0/29. FD is 2172416, RD is 2681856 1 16:16:18.079: DUAL: 192.168.23.3 metric 4294967295/4294967295 1 16:16:18.079: DUAL: 192.168.12.1 metric 3193856/2681856 not found Dmin is 3193856 1 16:16:18.079: DUAL: Peer total/stub 1/0 template/full-stub 1/0 1 16:16:18.079: DUAL: Dest 192.168.34.0/29 entering active state. 1 16:16:18.079: DUAL: Set reply-status table. Count is 1. 1 16:16:18.079: DUAL: Not doing split horizon 1 16:16:18.095: IP-EIGRP(Default-IP-Routing-Table:1): 192.168.34.0/29 - not in IP routing

*Mar 1 16:16:18.095: IP-EIGRP(Default-IP-Routing-Table:1): Int 192.168.34.0/29 metric 4294967295 - 167856 4294967295 *Mar 1 16:16:18.171: IP-EIGRP(Default-IP-Routing-Table:1): Processing incoming REPLY packet *Mar 1 16:16:18.171: IP-EIGRP(Default-IP-Routing-Table:1): Int 192.168.34.0/29 M 3193856 1657856 156000 SM 2681856 - 1657856 1024000 *Mar 1 16:16:18.175: DUAL: rcvreply: 192.168.34.0/29 via 192.168.12.1 metric 3193856/2681856 *Mar 1 16:16:18.179: DUAL: reply count is 1 *Mar 1 16:16:18.179: DUAL: Clearing handle 0, count now 0 *Mar 1 16:16:18.179: DUAL: Freeing reply status table *Mar 1 16:16:18.179: DUAL: Find FS for dest 192.168.34.0/29. FD is 4294967295, RD is 4294967295 found *Mar 1 16:16:18.179: DUAL: Removing dest 192.168.34.0/29, nexthop 192.168.23.3 *Mar 1 16:16:18.183: RT: add 192.168.34.0/29 via 192.168.12.1, eigrp metric [90/3193856] *Mar 1 16:16:18.183: RT: NET-RED 192.168.34.0/29 *Mar 1 16:16:18.183: DUAL: RT installed 192.168.34.0/29 via 192.168.12.1 *Mar 1 16:16:18.183: DUAL: Send update about 192.168.34.0/29. Reason: metric chg *Mar 1 16:16:18.183: DUAL: Send update about 192.168.34.0/29. Reason: new if *Mar 1 16:16:18.199: IP-EIGRP(Default-IP-Routing-Table:1): Int 192.168.34.0/29 metric 3193856 165786 1536000 Deasemenea se poate observa introducerea noii rute in tabela de rutare. Acum convergenta sa obinut n 112 ms in comparatie cu 12 ms cand nu era nevoie de trecerea in starea active. 5. Calcul Metric Eigrp foloseste pentru determinarea metrici, urmatoarele componente: latimea de banda, intarzierea, siguranta si incarcarea. Componenetele privind laimea de banda si ntrzierea sunt considerate in mod implicit in calcul metricii. Ltimea de banda se refera la cea mai mic ltime de banda de pe calea ctre destinaie. ntrzierea se refera la suma ntrzierilor de pe fiecare legatura in calea catre destinaie. Pentru inceput vom studia de ce ruterul R2 prefera calea spre 192.168.34.0 prin 192.168.24.4 si nu cea prin 192.168.23.3. Folosind comanda show interface [nume interfata] se vizualizeaz valoare parametrilor necesari n calculul metrici. R2#sh int fa0/0 Calcul metrica FastEthernet0/0 is up, line protocol is up latimea de banda=107/min(band) = 107/ 1544=6476 Internet address is 192.168.24.2/29 ntarzierea=(100+20000)/10=2010 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, metrica=256x(2010+6476)=2172416 reliability 255/255, txload 1/255, rxload 1/255 R2#sh int s1/1 Calcul metrica Serial1/1 is up, line protocol is up latimea de banda=107/min(band) = 107/ 1544=6476 Internet address is 192.168.23.2/29 ntarzierea=2x20000/10=4000 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, metrica=256x(4000+6476)=2681856 reliability 255/255, txload 1/255, rxload 1/255 Pentru a calcula metrica de mai sus am folosit formula

Dar Eigrp ne permite sa tinem cont de mai multi factori atunci cand se calculeaza metrica unei rute.Voi modifica configurarea protocolului astfel nct sa calculeze metrica si in functie de incarcare folosind comanada R2(config-router)#metric weights 0 1 1 1 0 0 , unde k1 reprezinta latimea de banda, k2- ncarcarea, k3- ntrzierea, k4- sigurana i k5-MTU Noua metric va fi calculata cu formula : 256 * [ K1*latimea de banda+(K2* latimea de banda)/(256incarcarea) + K3*ntarzierea] Pentru a forma adiacente acesti parametri trebuiesc setati la fel pe toate ruterele, altfel vom primi eroare de nepotrivire a parametrilor K. *Mar 2 00:48:02.153: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.14.1 (Serial1/0) is down: K-value mismatch *Mar 2 00:48:02.157: DUAL: linkdown: start - 192.168.14.1 via Serial1/0 Noua metrica, lund in calcul si ncrcarea va fi egala cu 2178917. D 192.168.34.0/29 is subnetted, 1 subnets 192.168.34.0 [90/2178917] via 192.168.24.4, 00:05:39, FastEthernet0/0

Putem influenta alegerea unei rute modificand valoare acestor parametri. Pentru exemplificare vom modifica ntarzierea si ncarcarea legturilor astfel incat urmtorul nod va fi 192.168.12.1 adica ip-ul de pe interfata s0/0 a ruterului R1 (ruter ce initial nu indeplinea conditia de viabilitate). ntarzierea pe interfetele s1/1 si fa0/0 a fost setata la valoarea 9999999, iar pe interfata s1/0 egal cu 10. Noua metrica va fi 2690917, iar ruta 192.168.34.0 va fi trecut in tabela de rutare via 192.168.12.1. D 192.168.34.0/29 is subnetted, 1 subnets 192.168.34.0 [90/2690917] via 192.168.12.1, 00:04:39, Serial1/0 6. Impartirea traficului pe rute cu costuri diferite Eigrp spre deosebire de Ospf poate realiza mprirea traficului pe rute cu costuri diferite. Comanda variance foreaz ruterul sa trimit traficul si pe rutele cu o metrica mai mica de n ori decat cea mai mica metrica (FD) spre aceea destinatie. Parametri au fost modificati astfel incat de pe R4 pentru a ajunge la reteau 1.1.1.0, conectata direct la ruterul R2 , sa va prefera ruta 192.168.24.2, dar in tabela de topologie exist si celelalte doua rute de rezerva.

Vrem sa trimitem pachetele cu o ratie de 8/4/2 adica 8 pachete pe interfata fa0/0, 4 pe s1/0 si 2 pachet pe s1/1. Pentru aceasta trebuie sa determinam distanta viabil si sa calculam latimea de banda pentru fiecare legatur.

Pentru cazul 8/4 putem echivala cu 1 la 2. Daca distanta viabila (FD) este 1349376, atunci metrica pentru seriala1/0 trebuie sa fie de doua ori mai mare : ( 2*1349376=2698752 ). Folosind formula de mai sus vom obtine: 107/ [(2698752/256) (45000/10)]= 1655 Kb, ceea ce reprezint latimea de banda pentru seriala s1/0 Pentru seriala s1/1 metrica trebuie sa fie de 4 ori mai mare (4*1349376=5397504) vom obtine: 107/ [(5397504/256) (45000/10)]= 602 Kb Pentru a obtine o rat 8/4/2 va trebui sa folosim o varianta de 8 ( variance 8)

Studiu OSPF

1. Stabilirea adiacentelor Pentru a configura Ospf trebuie stiu faptul ca fiecare retea face parte dintr-o aria. Aria 0 este aria magistrala, si toate celelalte arii trebuiesc conectate la ea. Configurarea se face folosind comanda: R4(config)#router ospf 1 R4(config-router)#network 192.168.24.0 0.0.0.7 area 0 La fel ca Eigrp, OSPF formeaza adiacente cu ruterele vecine, trimitand pachete de tip salut la fiecare 10 secunde. Mai jos se poate urmarii schimbul de mesaje intre doi vecini care ajung sa stabileasca o adiacenta. Intreg procesul este explicat in partea de teorie acum vizualizand practic ce se intampla. Stabilirea a convergentei a durat 168 de ms, un timp foarte bun. *Mar 1 08:02:12.510: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to up *Mar 1 08:02:12.518: OSPF: Interface Serial1/0 going Up *Mar 1 08:02:12.522: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/0 from 192.168.14.4 *Mar 1 08:02:12.534: OSPF: Rcv hello from 192.168.14.1 area 0 from Serial1/0 192.168.14.1 *Mar 1 08:02:12.538: OSPF: 2 Way Communication to 192.168.14.1 on Serial1/0, state 2WAY *Mar 1 08:02:12.542: OSPF: Send DBD to 192.168.14.1 on Serial1/0 seq 0x897 opt 0x52 flag 0x7 len 32 *Mar 1 08:02:12.542: OSPF: Send immediate hello to nbr 192.168.14.1, src address 192.168.14.1, on Serial1/0 *Mar 1 08:02:12.546: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/0 from 192.168.14.4 *Mar 1 08:02:12.550: OSPF: End of hello processing *Mar 1 08:02:12.654: OSPF: Rcv DBD from 192.168.14.1 on Serial1/0 seq 0x206E opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART *Mar 1 08:02:12.654: OSPF: First DBD and we are not SLAVE *Mar 1 08:02:12.654: OSPF: Rcv DBD from 192.168.14.1 on Serial1/0 seq 0x897 opt 0x52 flag 0x2 len 132 mtu 1500 state EXSTART *Mar 1 08:02:12.654: OSPF: NBR Negotiation Done. We are the MASTER *Mar 1 08:02:12.654: OSPF: Send DBD to 192.168.14.1 on Serial1/0 seq 0x898 opt 0x52 flag 0x3 len 132 *Mar 1 08:02:12.666: OSPF: Rcv DBD from 192.168.14.1 on Serial1/0 seq 0x898 opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE *Mar 1 08:02:12.666: OSPF: Send DBD to 192.168.14.1 on Serial1/0 seq 0x899 opt 0x52 flag 0x1 len 32 *Mar 1 08:02:12.678: OSPF: Rcv DBD from 192.168.14.1 on Serial1/0 seq 0x899 opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE *Mar 1 08:02:12.678: OSPF: Exchange Done with 192.168.14.1 on Serial1/0 *Mar 1 08:02:12.678: OSPF: Synchronized with 192.168.14.1 on Serial1/0, state FULL *Mar 1 08:02:12.678: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.14.1 on Serial1/0 from LOADING to FULL, Loading Done

2. Tabele utilizate

Ospf asemenea protocolului Eigrp ntreine trei tabele : tabela de adiacenta, tabela de topologie i tabela de rutare. 2.1 Tabela de adiacena Ca urmare a stabilirii relatiilor bidirectionale cu ruterele vecine ce ruleaza Ospf, un ruter va completa tabela de adiacenta. Daca unul din vecini nu trimite pachete de tipsalut pentru o perioada mai lunga decat intervalul permis ( interval Dead ), tabela de adiacenta este actualizata prin stergerea acestuia si se invalideaza toate caile care treceau prin acel vecin. R2#sh ip ospf neighbor Neighbor ID Pri State 192.168.14.1 0 FULL/ 192.168.34.3 0 FULL/ 192.168.34.4 1 FULL/DR Dead Time 00:00:38 00:00:34 00:00:30 Address 192.168.12.1 192.168.23.3 192.168.24.4 Interface Serial1/0 Serial1/1 FastEthernet0/0

A treia intrare in tabela reprezinta adiacenta formata pe interfata FastEthernet0/0. Starea FULL inseamna ca tabelele de topologie au fost schimbate intre ruterele vecine, iar DR inseamna ca ruterul vecin este ruter desemnat (designated router) pentru reteaua respectiv, de aceea si prioritatea este 1. Primele doua linii reprezinta adiacenta cu vecinii de pe legaturile seriale. Lipsa parametrilor DR/BDR/DROTHER se datoreaza faptului ca legatura este serial, deoarece doar pe legaturi multiacces se alege DR i BDR. O stare 2way , este o stare normala , stabila, stare a vecinilor care nu au schimbat topologia direct, asta inseamna ca fiecare ruter face schimb de topologie doar cu ruterul desemnat (designated router). 2.2 Tabela de topologie Tabela de topologie ( Link-state database - LSDB) contine o imagine detaliat a intregii retele, constand in toate mesajele de actualizare a starii legaturilor, mai exact starile tuturor legaturilor ruterelor din retea. LSDB este sincronizata periodic cu tabelele celorlalte rutere din retea, sau din aria respectiva- in cazul Ospf structurat pe mai multe arii, ceea ce inseamna ca ruterele au o tabela de topologie identic.
2.2.1 Tabela de topologie pentru Ospf cu o singura arie

In cazul Ospf cu o singura arie, pentru a selecta ruta optim catre o destinatie, ruterul aplic algoritmul Dijkstra SPF, situndu-se la radacina arborelui si cautand ruta cu metrica cea mai scazuta. Ruta optim este adaugata in tabela de rutare Tabela de topologie se poate afisa folosind comanda show ip ospf database. Se vor afia toate LSAurile grupate dupa tip pentru fiecare arie in parte. R2#sh ip ospf data OSPF Router with ID (192.168.24.2) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# 192.168.14.1 192.168.14.1 1324 0x8000000E 192.168.24.2 192.168.24.2 986 0x80000010 192.168.34.3 192.168.34.3 1114 0x8000000D 192.168.34.4 192.168.34.4 978 0x80000011 Net Link States (Area 0) Link ID ADV Router Age Seq#

Checksum Link count 0x00E33F 4 0x007079 5 0x003089 4 0x002C88 5 Checksum

192.168.24.4

192.168.34.4

977

0x8000000C

0x00D439

Coloanele tabelului au semnificatia urmatoare: Link ID este identificatorul LSA-ului, ADV Router este ruterul care a generat acest LSA, Age este vrsta Lsa-ului in secunde, Seq# este numrul de secven al Lsa-ului. Iniial este 0x80000001 si creste la fiecare actualizare, Checksum este suma de control a pachetului LSA, Link count este numarul de legaturi direct conectate si este folosit doar pentru LSA de tip Router. Deci pentru topologia cu o singura arie sunt transmise doar dou tipuri de LSA-uri, de tip 1 i 2. Se observa ca LSA-urile de tip 2 sunt transmise de ctre DR-urile fiecrei reele multiacces( reeaua 192.168.24.0 cu ruterul R4 ca DR )
2.2.2. Tabela de topologie pentru OSPF structurat pe mai multe arii

Figura 2 - Scenariu de baz structurat pe mai multe arii Intr-o topologie cu mai multe arii, retelele din arii diferite sunt anuntate prin LSA-uri de tip 3 (summary). LSA-urile de tip 3 creeaza rute de tip inter-area (IA) vizibile si in tabela de rutare. De exemplu pentru ruterul R2 din aria 3, reteaua 192.168.12.0, 192.168.23.0 din aria 0, reteaua 192.168.14.0 si 192.168.34.0 din ariile 1, respectiv 2 sunt primite ca summary LSA, dupa cum se observa si din tabela de topologie. Rutele redistribuite sunt primite prin LSA-uri de tip 5 (128.23.0.0). R2#sh ip ospf database OSPF Router with ID (192.168.24.2) (Process ID 1) Router Link States (Area 0) Link ID ADV Router 192.168.14.1 192.168.14.1 192.168.24.2 192.168.24.2 192.168.34.3 192.168.34.3 Age 20 912 1175 Seq# Checksum Link count 0x8000000C 0x00EA4E 2 0x8000000C 0x001CE7 4 0x8000000C 0x008674 2

Summary Net Link States (Area 0) Link ID ADV Router Age 2.2.2.2 192.168.24.2 1171 192.168.14.0 192.168.14.1 20 Seq# Checksum 0x80000002 0x00743B 0x8000000A 0x000FFB

192.168.24.0 192.168.24.2 649 192.168.34.0 192.168.34.3 1175 Router Link States (Area 3) Link ID ADV Router Age 192.168.24.2 192.168.24.2 649 192.168.34.4 192.168.34.4 872 Net Link States (Area 3) Link ID ADV Router Age 192.168.24.4 192.168.34.4 872

0x8000000A 0x00DB59 0x80000009 0x009B46

Seq# Checksum Link count 0x8000000A 0x009667 2 0x80000009 0x00A45C 1

Seq# Checksum 0x80000008 0x00DC35

Summary Net Link States (Area 3) Link ID ADV Router 192.168.12.0 192.168.24.2 192.168.14.0 192.168.24.2 192.168.23.0 192.168.24.2 192.168.34.0 192.168.24.2 Age 914 915 915 915 Seq# Checksum 0x80000008 0x00F40B 0x80000008 0x004978 0x80000008 0x006395 0x80000008 0x006C41

Summary ASB Link States (Area 3) Link ID ADV Router Age 192.168.14.1 192.168.24.2 390 Seq# Checksum 0x80000008 0x00D820

Type-5 AS External Link States Link ID 128.23.0.0 ADV Router Age 192.168.14.1 278 Seq# Checksum Tag 0x80000008 0x00C9BF 0

2.3.Tabela de rutare Ruterele Ospf construiesc si mentin LSDB care contin LSA primite de la alte rutere. Informatia este utilizata pentru a rula algoritmul Dijkstra SPF si a obtine arborele SPF. Cele mai bune rute din acest arbore se vor introduce in tabela de rutare. In cazul in care reteaua este segmentata in arii diferite, fiind implementat OSPF Multi-Area, construirea tabelei de rutare se realizeaza diferential pentru destinatiile din propria arie si cele din ariile externe. In primul rand, ruterul va calcula rute optime catre destinatiile din aria n care se afl, i le va adaug n tabela de rutare. Apoi ruterul va prelucra informatiile privind retelele aflate in alte arii Ospf si va selecta caile de cost minim. In final sunt analizate destinaiile externe reelei Ospf. De asemenea, in cazul in care un ruter dispune de o rut inter-zonal i o rut intra-zonal catre aceeasi destinaie, va fi pstrata ruta intra-zonal. R3#sh ip route [..., O - OSPF, IA - OSPF inter area, N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2, E1 - OSPF external type 1, E2 - OSPF external type 2...] Gateway of last resort is not set 192.168.12.0/30 is subnetted, 1 subnets O 192.168.12.0 [110/128] via 192.168.23.2, 00:00:45, Serial0/0 192.168.14.0/29 is subnetted, 1 subnets O IA 192.168.14.0 [110/192] via 192.168.23.2, 00:00:45, Serial0/0

192.168.24.0/29 is subnetted, 1 subnets O IA 192.168.24.0 [110/65] via 192.168.23.2, 00:00:45, Serial0/0 128.23.0.0/24 is subnetted, 1 subnets O E2 128.23.0.0 [110/20] via 192.168.23.2, 00:00:45, Serial0/0 192.168.23.0/29 is subnetted, 1 subnets C 192.168.23.0 is directly connected, Serial0/0 192.168.34.0/29 is subnetted, 1 subnets C 192.168.34.0 is directly connected, Serial0/1 Rutele care au initiala O sunt rute intra-area, adica din propria aria, aria 0 in cazul nostru, rutele cu O IA sunt rute inter-area, aria 2 si aria 3. Rutele invatate de la ASBR, sunt rute externe, invate prin redistribuire i pot fi de tipul 1 sau 2 (E1, E2). Diferena ntre cele doua const n modul n care costul ( metrica rutei) este calculat. In cazul in care exista un singur ASBR in retea, metrica de tipul 2 este preferata deoarece este o valoare constanta in tot sistemul autonom, nefiind nevoie de un calcul suplimentar.Metrica de tipul 1 este o valoare aditiva, reprezentand costul extern plus cel intern pentru a ajunge la destinatie. 3. Optimizarea convergentei folosind timpi hello si dead Folosind acelasi concept ca si Eigrp, dar terminologie diferit, Ospf foloseste doi timpi pentru a monitoriza adiacentele intre vecini. Intervalul salut defineste cat de des se trimit actualizari pe aceea interfata. Intervalul dead defineste cat ar trebui sa astepte un ruter, fara a primi mesaje salut de la vecini, inainte de a declara vecinul drept inaccesibil. *Mar 1 07:59:51.242: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.24.4 [...] *Mar 1 08:00:01.242: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.24.4 Asa cum se observ intervalul de timp intre acest tip de mesaje este de 10 secunde, iar intervalul dead este de patru ori mai mare. Pentru a obtine o convergena mai buna se pot seta timpi mai mici folosind comanda ip ospf hello-interval valoare i ip ospf dead-interval valoare . Daca la cele doua capete aceti timpi nu sunt egali nu se va mai stabili adiacena ntre cei doi vecini. R2#*Mar 1 09:45:13.513: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.34.4 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired *Mar 1 09:46:13.541: OSPF: Rcv hello from 192.168.34.4 area 0 from FastEthernet0/0 192.168.24.4 *Mar 1 09:46:13.545: OSPF: Mismatched hello parameters from 192.168.24.4 *Mar 1 09:46:13.545: OSPF: Dead R 40 C 36, Hello R 10 C 9 Mask R 255.255.255.248 C 255.255.255.248 Desi Ospf nu trimite actualizari a tabelei de rutare in mod periodic, asa cum o face Rip-ul, va retrimite fiecare LSA la fiecare 30 de minute. 4. Calcul metric Tot acest efort de a avea diferite tipuri de LSA, de a creea arii diferite, si de a avea o privire de ansamblu comuna asupra ntregii topologii, are un singur scop: de a permite fiecarui ruter din acea arie s calculeze ctre fiecare subreea ruta cea mai bun i fr bucle. Ospf spre deosebire de Eigrp nu este capabil de a imparti traficul pe rute ce nu au costuri egale.In ceea ce priveste metrica pentru Ospf, trebuie sa se tin cont de rutele intra-area si inter-area.

4.1 Calcul intra-area R1#sh ip route [ ... ] Gateway of last resort is not set 192.168.12.0/30 is subnetted, 1 subnets C 192.168.12.0 is directly connected, Serial0/0 192.168.14.0/29 is subnetted, 1 subnets C 192.168.14.0 is directly connected, Serial0/1 192.168.24.0/29 is subnetted, 1 subnets O 192.168.24.0 [110/65] via 192.168.14.4, 01:24:00, Serial0/1 [110/65] via 192.168.12.2, 01:24:00, Serial0/0 192.168.23.0/29 is subnetted, 1 subnets O 192.168.23.0 [110/128] via 192.168.12.2, 01:24:00, Serial0/0 192.168.34.0/29 is subnetted, 1 subnets O 192.168.34.0 [110/128] via 192.168.14.4, 01:24:00, Serial0/1 De pe R1 la reteaua 192.168.24.0 se poate ajunge prin 192.168.14.4 sau 192.168.12.2 cu un cost egal cu 65. Acest cost se obtine adunnd costul de 64 de pe interfata seriala si cel de 1 de pe interfata de FastEthernet. Pentru a vizualiza costul unei interfee se foloseste comanda show ip ospf interface R2#sh ip ospf interface Serial1/0 is up, line protocol is up Internet Address 192.168.12.2/30, Area 0 Process ID 1, Router ID 192.168.24.2, Network Type POINT_TO_POINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_POINT, [ ...] Ospf foloseste ca referinta latimea de banda de 100 Mbps . Formula pentru a calcula costul este banda de referinta impartita la latimea de banda a legaturii: Cost serial1/0: 105/1544=64.7 Pentru a influenta procesul de rutare comanda ip ospf cost cost ne permita sa setm costul fiecarei interfete, astfel ncat pachetele vor fi rutate pe interfata dorit. 4.2.Calcul inter-area Pentru Ospf ruterele interne unei arii nu au informatii despre intreaga topologie a altor arii, adica nu cunosc LSA-urile de tip 1 si 2. n schimb, trebuie sa se bazeze pe informatiile primite de la ABR. Asa cum am vazut ABR creaz LSA-uri de tip 3, ce contin adresa de subretea, masca, ruter Id-ul ABRului si un cost. Acest cost reprezint cel mai mic cost a ABR-ului pentru a ajunge la subreteaua respectiv. In exemplul de mai jos am urmrit informatiile pe care R4 le va folosi pentru a calcula cea mai buna rut spre 192.168.23.0. Folosind comanda sh ip ospf database summary se poate studia LSA-urile de tip 3 generate de fiecare ruter. R2#sh ip ospf database summary OSPF Router with ID (192.168.24.2) (Process ID 1) Summary Net Link States (Area 3) LS age: 1983 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 192.168.23.0 (summary Network Number)

Advertising Router: 192.168.24.2 LS Seq Number: 80000009 Checksum: 0x6196 Length: 28 Network Mask: /29 TOS: 0 Metric: 64 R3#sh ip ospf database summary 192.168.23.0 OSPF Router with ID (192.168.34.3) (Process ID 1) Summary Net Link States (Area 2) LS age: 1257 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 192.168.23.0 (summary Network Number) Advertising Router: 192.168.34.3 LS Seq Number: 8000000B Checksum: 0x11D9 Length: 28 Network Mask: /29 TOS: 0 Metric: 64 R1#sh ip ospf database summary OSPF Router with ID (192.168.14.1) (Process ID 1) Summary Net Link States (Area 1) LS age: 490 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 192.168.23.0 (summary Network Number) Advertising Router: 192.168.14.1 LS Seq Number: 8000000C Checksum: 0x2A95 Length: 28 Network Mask: /29 TOS: 0 Metric: 128

Figura 3 Exemplificare calcul metric inter-arii Se poate observa faptul ca R4 primeste doua summary LSA cu cost de 64 si unul cu cost de 128. Adunand costul lui R4 pana la ABR-uri de cost mai mic (R3 si R2 ) se va obtine un cost egal cu 65 prin interfata Fa0/0 prin ruterul R2.

Aadar in tabela de rutare va fi instalata reeaua 192.168.23.0 cu metrica 65, urmtorul nod fiind 192.168.24.2. R4#sh ip route Gateway of last resort is not set 192.168.12.0/30 is subnetted, 1 subnets O IA 192.168.12.0 [110/65] via 192.168.24.2, 01:48:36, FastEthernet0/0 2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/2] via 192.168.24.2, 01:48:36, FastEthernet0/0 192.168.14.0/29 is subnetted, 1 subnets C 192.168.14.0 is directly connected, Serial1/0 192.168.24.0/29 is subnetted, 1 subnets C 192.168.24.0 is directly connected, FastEthernet0/0 128.23.0.0/24 is subnetted, 1 subnets O E2 128.23.0.0 [110/20] via 192.168.14.1, 01:48:36, Serial1/0 192.168.23.0/29 is subnetted, 1 subnets O IA 192.168.23.0 [110/65] via 192.168.24.2, 01:48:36, FastEthernet0/0 192.168.34.0/29 is subnetted, 1 subnets C 192.168.34.0 is directly connected, Serial1/1

Timpul de convergen
Pentru masurarea timpului de convergenta intr-o prima faza am folosit reteau de patru rutere pe care am studiat comportamentul fiecarui protocol. Pentru masurarea timpul de convergenta am luat in calcul faptul ca intervalul de trimitere a mesajelor de tip salut poate fi modificat si influenteaza timpul de convergenta.
Protocol (timp de convergenta) Interval 1 sec VALOARE IMPLICITA *Eigrp-5 sec *Ospf-10sec *Rip-30 sec 3 s 780 ms Interval 480 s Interval maxim-65535

Eigrp

132 ms

7 min 40 s 432 ms

Nu se poate folosi acest interval deoarece expira intervalul de hold-time (ar trebui sa fie de 3 ori mai mare decat timpul hello). Chiar si cu o valoare de doua ori mai mica tot nu formeaza adiacente corecte Nu se poate folosi acest interval deoarece expira intervalul de hold-time (ar trebui sa fie de 3 ori mai mare decat timpul hello). Chiar si cu o valoare de doua ori mai mica tot nu formeaza adiacente corecte

Ospf

6 s 304 ms

39 s 952 ms

8 min 176 ms

Rip

Timpul de trimitere a actualizarilor nu pot configurati, timpul de convergenta este influentant de marimea retelei- 1 min

Tabel 1 Timpul de convergenta pentru retea de dimensiune mica In tabelul 1 se poate observa timpul de convergen pentru o reea format din patru rutere. Timpi de convergena sunt mici, dar depind n mare parte de dimensiunea reelei, ncarcarea acesteia si latimea de band. Se poate observa faptul ca timpul de convergena creste exponential odata cu creterea intervalului de transmisie a pachetelor de tip Salut. Intervalul pentru transmiterea

pachetelor de tip salut nu poate fi fixat la dimensiunea maxima acceptat prin comanda de configurare, deoarce expira intervalul de retinere in tabela de rutare a unei rute. In general se lucreaza cu valoarea implict deoarece trebuie sa se fac un compromis intre timpul de convergena si utilizarea procesorului. Daca configurm intervalul prea mare timpul de convergen va fi foarte mare, dac intervalul este prea mic procesorul va fi mult mai solicitat efectuand calcule prea des. Pentru a exprima o concluzie mai clar asupra timpului de convergenta, am configurat o retea mai mare si cu mai multe retele conectate. Pe baza acestor tabele am realizat o comparatie intre timpul de convergenta intr-o retea mica si una medie.

Figura 4 Scenariu de baz extins

Protocol (timp de convergenta)

Interval 1 sec

VALOARE IMPLICITA *Eigrp-5 sec *Ospf-10sec *Rip-30 sec 32 s 280 ms

Interval 480 s

Interval maxim-65535

Eigrp

4s

8 min 10 s 32 ms

Nu se poate folosi acest interval deoarece expira intervalul de hold-time (ar trebui sa fie de 3 ori mai mare decat timpul hello). Chiar si cu o valoare de doua ori mai mica tot nu formeaza adiacente corecte Nu se poate folosi acest interval deoarece expira intervalul de hold-time (ar trebui sa fie de 3 ori mai mare decat timpul hello). Chiar si cu o valoare de doua ori mai mica tot nu formeaza adiacente corecte

Ospf

12 s

1 min 21 s 327 ms

9 min 40 s 345 ms

Rip

Timpul de trimitere a actualizarilor nu pot configurati, timpul de convergenta este influentant de marimea retelei.- 4 min 30 s T pde conv enta im erg
E rp ig 500 400 300 200 100 0 1s ec v loa im a re plicta 480s ec

Tabel 2 pentru retea de

Timpul de convergenta dimensiune medie

reteam ica reteam edie

Grafic 1- comparaie timp de convergen Eigrp

600 500 400 300 200 100 0 1s ec v loa im a re plicta 480s ec reteam ica reteam edie T pde im conv entaO pf erg s

Grafic 2- comparaie timp de convergen Ospf Analizam aceste grafice vom constata faptul ca rezultatul demonstreaz ca atat Ospf cat si Eigrp sunt protocoale scalabile. Odata cu cresterea in dimensiune a retelei, performana nu s-a diminuat foarte mult, timpii de convergena nefiind foarte mari.In schimb Rip nu este un protocol scalabil, intr-o retea medie timpul de convergena fiind foarte mare , de aceea se impune limita de 16 de noduri traversate. Factorii care pot afecta scalabiliatea unei retele pot fi: cantitatea de informatie schimbata intre rutere, numarul de rutere, adancimea topologiei si numarul de ci alternative prin retea. Adancimea unei topologii se refer la numarul de hopuri pe care informatia trebuie sa le parcurg pentru a ajunge la toate ruterele din retea.
600 500 400 300 200 100 0 1s ec v loa im a re plicta 480 s ec E rp ig O pf s R ip C pa tie om ra E rp/ O pf/ ig s R ip

Grafic 3- Comparatie Eigrp/Ospf/Rip Comparand timpi de convergenta pentru Eigrp si Ospf se observ o diferena care ar putea duce la concluzia ca Eigrp este un protocol mai bun din punct de vedere a timpului de convergenta. Totui cu ct reeaua va fi mai mare cu atat Ospf va avea timpi de convergenta mai buni fata de EIGRP datorit posibilitatii de segmentare a retelei in mai multe arii. Pentru Eigrp ntrzierea i procesul de investigare prin pachete de tip Interogare ncetinesc convergen reelei pe msur ce adncimea retelei creste. Cisco recomandat limita maxima de 7 hopuri.

Desi timpul de convergena a fost mai bun trebuie tinut cont de faptul ca Ospf cunoate ntreaga topologie pe cand Eigrp are doar informaii partiale. Asa cum am observat in studiul protocolului , la cderea a unei rute pe care Eigrp nu o are in tabela topologic va trimite pachete Interogare pentru determinarea unei noi rute, folosind din banda necesara pentru traficul utilizatorului. La o retea de dimensiune mic ntreg procesul a durat 112 ms, pe cnd Ospf a gasit-o in tabela de rutare si doar a rulat algoritmul SPF. Pentru Ospf timpii de convergenta vor fi mai buni dar resursele necesare vor fi mai mari. Cu cat reteaua este mai mare, cu atat tabela topologic i tabela de rutare vor conine mai multe nregistrri. Numrul de rute potentiale spre aceeasi destinatie creste odata cu dimensiunea retelei, in consecinta calculele Spf necesare obtinerii rutei optime devin mai complexe. Astfel creste consumul de resurse de memorie si procesor dar si de latime de banda din cauza actualizarilor mai frcvente. In plus, datorit modului de fuctionare a protocoalelor starea legturilor, orice schimbare in retea, va fi propagat ctre toate ruterele care trebuie sa recalculeze fiecare legtur din ntrega tabel de topologie.

Utilizarea resurselor de ctre protocol

Grafic 4-Solicitarea procesorului de catre Ospf

Grafic 5-Solicitarea procesorului de catre Rip

Din graficele de mai jos se poate observa faptul ca Ospf foloseste mai mult procesorul decat Rip. Atunci cand Ospf isi trimite LSA-urile intre vecini, foloseste pana la 90 % din resursele procesorului, desi avem se observa o retea de 15 rutere.

Dimensiunea pachetelor si latimea de banda ocupata cu transmiterea mesajelor pentru rutare

Protocol Tip pachet Numar octeti antet Lungime camp de date(variabil in

Rip

Cerere (Request) Raspuns (Response) Salut (Hello)

4 4

EIGRP *implicit foloseste 50% din Interogare (Query)

20

20 Actualizare (Update) 20 Raspuns (Reply) 20 Salut (Hello) Descriere baza de date (DBD-Datebase Description) Cerere (LSR-Link State Request) Actualizare (Link State Update) 24 24 24 24

functie de protocol) 20 octeti min 20 octeti maxim 504 (512) *Intre 1 si 25 nregistrri fiecare a cate 20 octeti Include : 1) valoarea 32 parametrilor K12 octeti Depinde de 2) Rute interne- numarul de fiecare 28 de nregistrri octeti Depinde de 3)Rute externenumarul de fiecare 48 de nregistrri octeti Depinde de numarul de nregistrri Min 44-Max 48 Min 32-max depinde cate antete LSA trimite-fiecare antet LSA are 20 de octeti 36 Antetul LSA are 20 de octeti dar pot exita 5 tipuri de LSA 1 ) Router-LSA 2) Network-LSA 3,4) Summary-LSA 5) AS-external-LSA Min 44 ( 24+10 LSA header)Depinde cate pachete LSA confirma

OSPF

Confirmare(Link State Acknowledgment)

24

Nu se poate face o analiza clara a dimensiunii unui pachet deoarce acesta depinde de numarul de nregistrri din tabela, deci implicit de dimensiunea retelei. Pentru Rip un pachet poate avea maxim 504 octeti, datorita limitari a maxim 25 de rute intr-un pachet, dar pentru Eigrp si Ospf nu exista aceasta limitare. Dimensiunea unui pachet Eigrp sau Ospf depinde de valoare MTU pe legatutra de date e care se vor transmite pachetele .(de exemplu interfata Ethernet 1500 octeti). Studiem cazul unui link intre doua rutere pe care se porneste Rip si studiem timp de 300 s. Initial, pe link se vor transmite 2 mesaje de tip cerere urmate de 2 raspunsuri, corespunzatoare acestora, intr-un timp foarte scurt. In continuare, se vor transmite inca 10 mesaje de tip raspuns coninnd ntreaga tabela de rutare, la un interval aproximativ de 30 de secunde . Rezulta astfel un total de 24 de mesaje (22 de tip raspuns si 2 de tip cerere). Un mesaj de actualizare poate contine maxim 25 de intrari ale tabelei de rutare. Datorita faptului ca am considerat cate 100 de intrari pentru ambele tabele de rutare, RIP va trimite cate 4 mesaje de actualizare in locul unuia singur. Prin urmare, vom avea un nou total de 90 de mesaje (88=22x4 mesaje de tip raspuns si 2 de cerere). Pentru a exprima valoarea traficului suplimentar introdus de aceste mesaje pe link, se poate calcula numarul de octeti transmisi stiind dimensiunile ambelor tipuri de mesaje RIP din tabelul de mai sus. Astfel, vom putea calcula R (traficul RIP suplimentar in bytes) : R = 88 x 504 + 2 x 24 = 44352 + 48 = 44,4 KB (in 300 de secunde) Stim capacitatea canalui C = 512Kbiti/s = 64KB/s Daca consideram ca se transmite informatie continuu si la capacitate maxima putem estima traficul total transmis in 300 de secunde ca fiind T = 300 x 64 = 19200 KB = 19,2 MB

Astfel putem exprima procentual cat reprezinta valoarea lui R in functie de traficul total T: p = (R / T) x 100 = 0.2 %

Protocol Inter-domeniu Studiu BGP

Dei BGP este unul dintre cele mai complexe protocoale din lumea retelelor de calculatoare, el este usor de configurat din punct de vedere al sintaxei. Pentru a porni procesul BGP pe un ruter trebuie dat aceeai comand ca i in cazul oricrui alt protocol de rutare: router. n cazul BGP aceast comand primeste ca si parametru atat cuvantul cheie bgp ct i un numar de AS. Cel din urma argument are rolul de a i indica procesului BGP in ce sistem autonom se afl. Realizarea unei configuratii BGP poate fi imprtita in doua categorii: realizarea adiacentelor intre vecini si politici BGP.
1. Stabilirea adiacentelor

Adiacentele BGP pot fi de doua tipuri: iBGP si eBGP. Voi incepe cu iBGP, si voi utiliza configurarea acestui protocol pe baza scenariului folosit pna acum.

Figura 5- Scenariu de baz Cea mai rapid metoda de a realiza sesiunea iBGP intre doua rutere este alegerea unuia dintre IPurile de pe o interfata si folosirea acestuia n comanda neighbor : R2(config-router)#neighbor 192.168.12.1 remote-as 100 R1(config-router)#neighbor 192.168.12.2 remote-as 100 Folosirea cuvntului remote-as urmat de un numar de AS, mpreuna cu numarul de AS dat ca parametru la comanda router specific protocolului daca sesiunea este de tip iBGP sau eBGP. Daca numerele de AS sunt identice in cele 2 comenzi, protocolul BGP va ntelege ca ruterul vecin se afla n aceeasi AS si va porni o sesiune iBGP. O problema poate aprea, daca una dintre interfetele celor doua rutere incepe sa oscileze intre starile up/down. Acest lucru se poate intmpla din diverse motive, de la conditiile de mediu sau o defectiune hardware, pana la deconectarea accidental a unor cabluri. Oricare din aceste actiuni va avea ca rezultat distrugerea adiacentei BGP. La protocoalele IGP acest lucru ar fi usor de remediat deoarece adiacenta s-ar reconstrui repede iar numarul de rute trimise nu ar fi atat de mare. O tabela

de rutare BGP poate ajunge la peste 300000 de rute, iar restabilirea unei adiacente necesita mult timp. Pentru a preveni astfel de situatii, este recomandat sa se foloseasca interfetele de loopback de pe fiecare ruter pentru a stabili adiacentele. Motivul este faptul ca interfetele de loopback exist doar in software si nu sunt supuse problemelor de mediu fizic. Folosind debug ip bgp se poate observa comportamentul protocolului. Dupa introducerea comenzilor de configurare de mai sus debug ip bgp va genera urmatorul mesaj : R1#*Mar 1 00:17:16.871: BGP: 2.2.2.2 multihop open delayed 15609ms (no route) *Mar 1 00:17:32.483: BGP: 2.2.2.2 multihop open delayed 14842ms (no route) Acest comportament are loc deoarece pentru a stabili o sesiune de adiacena BGP trebuie sa existe conectivitate intre ruterul pe care se d comanda neighbor si adresa IP a vecinului. In cazul de fata voi asigura aceast adiacent prin protocolul OSPF. Odata configurat aceast protocol am obtinut urmatorul mesaj de debug: R1#*Mar 1 00:28:09.119: BGP: 2.2.2.2 open active, local address 192.168.12.1 *Mar 1 00:28:09.143: BGP: 2.2.2.2 open failed: Connection refused by remote host Prin mesaj se observ ca adiacena iBGP nu s-a realizat. Aceast problema apare din cauza faptului ca fiecare vecin in mod implicit foloseste adreasa IP de pe interfata de iesire a pachetelor ca si adresa Ip surs in pachetele BGP. Cand pachetele ajung la ruterul vecin acesta le refuza deoarece se asteapta sa vada Ip-ul configurat in comanda neighbor, in cazul meu Ip-ul de pe interfata de loopback a vecinului, n campul de IP surs a pachetului. Aceasta problema se rezolva folosind ca argument , la comanda neighbor, update-source si interfata a carei adresa Ip sa fie folosita ca si adresa sursa in pachete.Acum urmarind mesajele de debuging observam stabilirea adiacentei iBGP ntre cele dou rutere: R1#debug ip bgp *Mar 1 00:32:09.171: BGP: 2.2.2.2 open active, local address 1.1.1.1 *Mar 1 00:32:09.219: BGP: 2.2.2.2 went from Active to OpenSent *Mar 1 00:32:09.219: BGP: 2.2.2.2 sending OPEN, version 4, my as: 100 *Mar 1 00:32:09.223: BGP: 2.2.2.2 send message type 1, length (incl. header) 45 *Mar 1 00:32:09.279: BGP: 2.2.2.2 rcv message type 1, length (excl. header) 26 [...] *Mar 1 00:32:09.295: BGP: 2.2.2.2 went from OpenSent to OpenConfirm *Mar 1 00:32:09.295: BGP: 2.2.2.2 went from OpenConfirm to Established *Mar 1 00:32:09.295: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up Linia *Mar 1 00:32:09.295: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up ne confirm stabilirea adiacentei. Adiacentele BGP se creeaza folosind portul 179 TCP si se mentin folosind mesaje de keepalive o data la 60 de secunde. R1#debug ip bgp keepalives *Mar 1 02:43:09.883: BGP: 2.2.2.2 sending KEEPALIVE (io) *Mar 1 02:44:09.883: BGP: 2.2.2.2 sending KEEPALIVE (io) Spre deosebire de protocoalele IGP unde exist un sistem de descoperire automat a vecinilor pentru BGP vecinii sunt configurati manual pe fiecare ruter. 2. Tablele utilizate

Asemenea protocolului OSPF sau EIGRP , BGP mentine trei tabele de rutare: tabela de adiacente, de topologie si de rutare. 2.1 Tabela de adiacente Pentru a vizualiza tabela de adiacente se foloseste comanda show ip bgp neighbors sau show ip bgp summary R1#sh ip bgp summary BGP router identifier 1.1.1.1, local AS number 100 [...] Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 100 237 236 2 0 0 01:31:59 1 4.4.4.4 4 100 228 228 2 0 0 01:31:58 0 Se poate observ c ruterul R1 a stabilit adiacenta cu ruterele R2 i R4. 2.2 Tabela de topologie Pentru a exista rute in tabela de topologie retelele trebuiesc anuntate cu comanda network sau redistribuite din alte protocoale sau rute statice.Vizualizand tabela de topologie cu comanda show ip bgp de pe ruterele cu care R2 a stabilit adiacente vom observa ca acesta exist o rut in tabel.

Ruta cea mai buna, cea care este introdusa in tabela de rutare, este indicat prin folosirea semnului >. Semnificaia i-ului din stanga este ca ruta a fost nvat prin iBGP cu comanda network. Numarul de AS cel mai din dreapta este cel ce a originat ruta. n tabela de mai sus nu apare nici un AS in lista ceea ce inseamna ca ruta este intern, si invtate de la ruterul R2. 2.3 Tabela de rutare In tabela de rutare a lui R1 sau R3 vom aveam o ruta de forma: 5.0.0.0/24 is subnetted, 1 subnets B 5.5.5.0 [200/0] via 2.2.2.2, 01:12:38 Totusi examinand tabela de topologie a ruterului R4 vom observa ca nu a fost instalata nici o ruta ctre reteaua 5.5.5.0. Aceasta problem apare datorit mecanisme de evitare a buclelor de rutare folosit de ctre iBGP: iBGP-un mesaj de actualizare primit de la un vecin iBGP nu va fi trimis mai departe care un alt vecin iBGP. Ca o consecina a mecanismului de evitare a buclelor folosit de iBGP, este necesar ca intr-un AS in care mai multe rutere ruleaza BGP conexiunile iBGP sa fie full-mesh ( fiecare ruter care vorbeste iBGP trebuie s stabileasc o adiacen cu fiecare alt ruter iBGP din acelai AS). Drept urmare, numarul de conexiuni iBGP va creste exponential odata cu cresterea numarului de rutere BGP din

AS. Pentru 50 de rutere BGP aflate in acelai AS, vor exista 50*49/2= 1225 conexiuni iBGP. Solutia pentru scdera numarului de conexiuni necesare este configurarea unui route-reflector sau confederaii. 3. Topologie full-mesh iBGP In topologia descris mai sus, desi R1 si R3 primesc mesaj de actualizare despre reteaua 5.5.5.0 nu au voie sa transmit acesta actualizare mai departe lui R4 deoarece ar ncalca regula de evitare a buclelor folosit de iBGP. Datorita faptului ca ruterul R4 nu are stabilit adiacena cu ruterul R2 nu va nvata nimic despre reteaua 5.5.5.0.Pentru a nu fii nevoiti sa realizam adiacente intre toate ruterele putem configura pe R1 ca route-reflector si pe R4 ca si client route-reflector, astfel R1 va putea trimite toate rutele primite de la un non-client (R1) la toti clientii si (R4). R1(config)#router bgp 100 R1(config-router)#neighbor 4.4.4.4 route-reflector-client Acum in tabela de topologie a ruterului R4 se vor gasi informatii cu privire la reteaua 5.5.5.0.

In figura de mai sus se poate observa faptul ca reteaua 5.5.5.0 a fost introdusa n retea de catre ruterul R2 ( Originator 2.2.2.2), si a fost invatat pe ruterul R4 de la 1.1.1.1 (Cluster List 1.1.1.1 ) 4. eBGP Trebuie mentinonat ca iBGP nu este un IGP, si nu poate fi folosit in locul unui IGP pentru rutarea in interiorul unui AS. iBGP are doar scopul de a transporta informatiile BGP intre ruterele de granita alea unui sistem autonom. Pentru a studia comportamentul eBGP am folosit configuratia de mai jos.

Figura 6- Scenariu eBGP In cazul eBGP configuratiile sunt asemanatoare cu iBGP, ns numarul AS dat in comanda router este diferit de cel folosit in comanda neighbor. R1(config)#router bgp 100 R1(config-router)#neighbor 192.168.15.5 remote-as 500

Pe R5 am configurat o interfata de loopback cu adresa 10.1.1.1, pe care am anuntat-o in BGP. Daca se verifica tabela de rutare a lui R1, se observa ca ruta a fost invatat prin protocolul BGP. Totusi aceast ruta nu a fost propagata in intreg domeniu iBGP. Cand eBGP transmite rute, schimba automat informatia despre urmatorul nod pentru rutele respective, iBGP nu schimba insa aceasta informatie la transmiterea rutelor. Astfel cand R1 va trimite lui R2 rutele invatate de la R5, adresa urmatorului nod va ramane neschimbat la adresa lui R5. Acest lucru inseamna ca R2 nu va putea instala niciodata aceste rute in tabela de rutare deoarece nu are conectivitate catre adresa urmatorului nod. Pentru a rezolva aceasta problema, putem configura o ruta statica, dar nu ar fi o solutie scalabila, sau putem configura iBGP-ul pentru a avea acelasi comportament de schimbare a adresei urmatorului nou ca si eBGP. R1(config-router)#neighbor 2.2.2.2 next-hop-self 4.1 Calul metrica Daca in cazul IGP-urilor decizia de selectie a unei cai se face pe baza unei metrici( numrul de hopuri, limea de band, costul, etc.) in cazul BGP nu exista o singur metric. Fiecare actualizare contine o serie de atribute, iar pe baza acestora (si a politicilor de rutare existente in As-ul respectiv) BGP decide care este cea mai buna cale spre diferitele destinatii. Tabela de topologie pentru protocolul BGP a ruterului R7 este urmatoarea. R7#sh ip bgp BGP table version is 16, local router ID is 192.168.67.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop *> 5.5.5.0/24 192.168.67.1 *> 7.7.7.0/24 0.0.0.0 *> 10.1.1.0/24 192.168.67.1 Metric LocPrf 0 Weight 0 32768 0 Path 600 100 i i 600 100 500 i

Cea mai buna cale catre o destinatie este marcata cu >, in cazul nostru exista o singura cale si ea va fi adaugata si in tabela de rutare. De asemenea exista si o lista cu cele mai importante atribute: NEXT-HOP,WEIGHT, LOCAL-PREF, AS-PATH, ORIGIN( simbolul de la final Path), MED (Metric). Se poate observa ca toate ruterele au fost injectate in protocol prin comanda network, deoarece au originea notata cu i, in timp ce rutele injectate prin redistribuire au originea notata cu ?. Voi modifica topologia astfel incat sa putem observa modul in care eBGP tine cont de atributele rutelor modificate.

Figura 7- Scenariu eBGP extins Daca vizualizam din nou tabela topologic a lui R7, vom constata ca reteaua destinatie 10.1.1.0 de pe ruterul R5, este acum invatat prin doua locuri, iar in tabela de rutare va fi intodus ca urmatorul hop ruterul R5. Datorit faptului ca atributele greutate-( Weight) si prefix local(Local Pref) sunt egale, traseul de rutare a pachetelor se va alege in functie de numarul de As-uri traversate (As_Path) . Asadar pachetele spre reteaua 10.1.1.0 se vor trimite direct spre As 500, decat sa strabat AS 600 i As 100 pentru a ajunge la destinaie. R7#sh ip bgp Network * 5.5.5.0/24 *> *> 7.7.7.0/24 *> 10.1.1.0/24 * Next Hop 192.168.57.5 192.168.67.1 0.0.0.0 192.168.57.5 192.168.67.1 Metric LocPrf 0 0 Weight 0 32768 0 0 Path 500 100 i 600 100 i i 500 i 600 100 500 i

Folosind diverse atribute vom modifica alegera traseului de trimitere a pachetelor spre reteaua 10.1.1.0. 4.1.1 Modificare atribut AS_Path

Acest atribut este modificata prin adaugarea la inceputul sau( prepending) a Asn-ului propriu, repetata de un numar de ori. Cu cat numarul de repetitii va fi mai mare, cu atat ruta respectiva va fi considerata mai putin buna de catre ruterele din As-uri. Toate modificarile de atribut se realizeaza prin folosirea unor harti de rutare ( route-map ). Route-map ul numit As-path va influenta atributele rutelor ce ies R5(config)#route-map As-path permit 10 R5(config-route-map)#set as-path prepend 500 500 500 R5(config)#router bgp 500 R5(config-router)#neighbor 192.168.57.7 route-map As-path out In rezulatul configuratiei se observa pe R7- ruta prin R5 are un As-path mai lung decat ruta alternativ, si ca urmare R7 va trimite pachetele destinatiei 10.1.1.0 catre R6. R7#sh ip bgp Network * 5.5.5.0/24 Next Hop 192.168.57.5 Metric LocPrf Weight 0 Path 500 500 500 500 100 i

*> *> 7.7.7.0/24 * 10.1.1.0/24 *>

192.168.67.1 0.0.0.0 192.168.57.5 192.168.67.1

0 0

0 600 100 i 32768 i 0 500 500 500 500 i 0 600 100 500 i

4.1.2 Modificare atribut Preferin local Pentru a afecta traficul de iesire se poate modifica atributul Preferint Locala ( Local_Preferance). Acest atribut este nu este trimis catre alte AS-uri. Daca un ruter Bbp premieste mai multe rute catre aceeasi destinatie cu Local-pref diferite, va prefera ruta cu Local-Pref mai mare. Pe ruterul R7 am setat valoarea local_pref pentru vecinul 192.168.57.5 egal cu 300 , iar pentru vecinul 192.168.67.1 valoarea 200. R7#sh ip bgp Network *> 5.5.5.0/24 * *> 7.7.7.0/24 *> 10.1.1.0/24 * Next Hop 192.168.57.5 192.168.67.1 0.0.0.0 192.168.57.5 192.168.67.1 Metric 0 0 LocPrf 300 200 300 200 Weight 0 0 32768 0 0 Path 500 500 500 500 100 i 600 100 i i 500 500 500 500 i 600 100 500 i

Acum se poate observa ca desi se trece prin mai multe sisteme autonome (AS-Path mai lung) se prefera urmatorul nod 192.168.57.5 (> specifica ruta ce a fost intodus in tabela de rutare) datorita atributului Local_pref mai mare. 4.1.2 Modificarea atributului Greutate (Weight)

Parametrul Greuatate este specific Cisco, si se aplic doar pe ruterele pe care este configurat, nefiind comunicat catre alte rutere. El este primul atribut care se ia in considerare atunci cand se alege traseul de rutare a pachetelor. Vom configura din nou ruterul R7 astfel incat sa se prefera urmatorul nod 192.168.67.1 R7#sh ip bgp Network *> 5.5.5.0/24 * *> 7.7.7.0/24 *> 10.1.1.0/24 * Next Hop 192.168.67.1 192.168.57.5 0.0.0.0 192.168.67.1 192.168.57.5 Metric 0 0 LocPrf Weight 40000 0 32768 40000 0 Path 600 100 i 500 500 500 500 100 i i 600 100 500 i 500 500 500 500 i

Se poate observa ca desi au fost pstrate toate atributele setate pan acum, datorita atributului Greutate pachetele vor fi trimise ctre urmatorul nod 192.186.67.1