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 rețelele pentru fiecare ruter în parte , operatie ce necesita multa munca si atentie din partea administratorului. Pentru configurarea retelei in modul static se foloseste urmӑtoarea comandӑ în modul “ configuare globala” : R(config): ip route [ ip destinație] [mascӑ pentru ip destinație] [interfața de ieșire /urmӑtorul nod ] opționale: [metrica], [numele], [rutӑ permanentӑ], [marcӑr] 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 funcționa 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
Transcript
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 rețelele pentru fiecare ruter în parte , operatie ce necesita multa munca si atentie din partea administratorului.Pentru configurarea retelei in modul static se foloseste urmӑtoarea comandӑ în modul “ configuare globala” :R(config): ip route [ ip destinație] [mascӑ pentru ip destinație] [interfața de ieșire /urmӑtorul nod ] opționale: [metrica], [numele], [rutӑ permanentӑ], [marcӑr] 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 funcționa 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.2Se verifica tabela de rutare cu comanda show ip route:R3#sh ip routeCodes: 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 routeGateway of last resort is not setS 192.168.12.0/24 [1/0] via 192.168.23.2S 192.168.14.0/24 [1/0] via 192.168.34.4C 192.168.23.0/24 is directly connected, Serial0/0C 192.168.34.0/24 is directly connected, Serial0/1
Rutele introduse vor avea litera S (static) în stânga lor, cele direct conectate au litera C (connected).Desi nu am configurat nimic pe R2 si R4 , ruterele intermediare, pingul totuși functioneazӑ
R3#ping 192.168.14.4Sending 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 funcționat. 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 așa cӑ va renunța la pachet.Adăugand rute statice pe R2 si R4 vom avea conectivitatea în întreaga rețea. Daca s-ar introduce rețele noi, ar trebui configurate manual cӑtre fiecarea rețea atât ruta dus cât ș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 pӑstra ruta prin R2 ca ruta principalӑ.R1(config)#ip route 192.168.23.0 255.255.255.0 192.168.12.2 10R1(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 urmӑri întreg procesul:
*Mar 1 06:00:49.466: RT: interface Serial0/0 removed from routing table*Mar 1 06:00:49.466: RT: del 192.168.12.0 via 0.0.0.0, connected metric [0/0]*Mar 1 06:00:49.466: RT: delete network route to 192.168.12.0*Mar 1 06:00:49.466: RT: NET-RED 192.168.12.0/24*Mar 1 06:00:50.466: RT: del 192.168.23.0 via 192.168.12.2, static metric [10/0]*Mar 1 06:00:50.466: RT: delete network route to 192.168.23.0*Mar 1 06:00:50.466: RT: NET-RED 192.168.23.0/24*Mar 1 06:00:50.466: RT: add 192.168.23.0/24 via 192.168.14.4, static metric [50/0]*Mar 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. Limitӑri 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ӑ adresӑrii 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 mӑstii de subrețea în mesajul de actualizare trimis de ruterul R1 catre ruterul R2.
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 1 00:42:59.771: RIP: build update entries*Mar 1 00:42:59.771: 2.2.2.0/27 via 0.0.0.0, metric 1, tag 0*Mar 1 00:42:59.771: 3.3.3.0/29 via 0.0.0.0, metric 1, tag 0*Mar 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, rețelele sunt afisate cu mascӑ de rețea corectӑ si litera R , specificand protocolul prin care au fost învățate
R2# [...] Gateway of last resort is not set 192.168.12.0/30 is subnetted, 1 subnetsC 192.168.12.0 is directly connected, Serial0/0 2.0.0.0/27 is subnetted, 1 subnetsR 2.2.2.0 [120/1] via 192.168.12.1, 00:00:15, Serial0/0 192.168.14.0/29 is subnetted, 1 subnetsR 192.168.14.0 [120/1] via 192.168.12.1, 00:00:15, Serial0/0 3.0.0.0/29 is subnetted, 1 subnetsR 3.3.3.0 [120/1] via 192.168.12.1, 00:00:15, Serial0/0 192.168.23.0/29 is subnetted, 1 subnetsC 192.168.23.0 is directly connected, Serial0/1 192.168.34.0/29 is subnetted, 1 subnetsR 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 către 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 numӑrul maxim de 16 noduri. Metrica folosita in rip este cumulativa, reprezintand suma tuturor costurilor asociate rețelelor traversate pentru a ajunge la destinație.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ӑ rețea are o metrica egalӑ cu 1, ceea ce inseamna ca este o rețea 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 cӑtre 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.
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 1 10:56:16.661: EIGRP: Sending HELLO on FastEthernet0/0*Mar 1 10:56:16.661: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0*Mar 1 10:56:19.237: EIGRP: Received HELLO on FastEthernet0/0 nbr 192.168.24.4*Mar 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.
Exista doua probleme in legatura cu actualizarile sigure folosite de Eigrp. Pe de o parte, ruterulnu stie cate pachete de tip “ Confirmare” să aștepte, 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 topologyIP-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 StatusP 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/1P 192.168.12.0/30, 1 successors, FD is 2169856 via Connected, Serial1/0P 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/0P 192.168.24.0/29, 1 successors, FD is 28160 via Connected, FastEthernet0/0P 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 existența 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 subnetsD 192.168.14.0 [90/2172416] via 192.168.24.4, 04:13:13, FastEthernet0/0 3.0.0.0/29 is subnetted, 1 subnetsD 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 subnetsD 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 distanța, Eigrp nu trimite actualizari in mod periodic, ci doar atunci când apar modificari de topologie. Dupa cum se poate observa si din procesul de depănare se trimit actualizӑri doar referitoare la rutele modificate. Eigrp are un comportament diferit fața de protocoalele bazate pe starea legaturilor, acestea din urma trimițând actualizӑri 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 subnetsD 2.2.2.0 [90/2297856] via 192.168.12.1, 00:52:44, Serial1/0 192.168.14.0/29 is subnetted, 1 subnetsD 192.168.14.0 [90/2172416] via 192.168.24.4, 02:32:49, FastEthernet0/0 192.168.34.0/29 is subnetted, 1 subnetsD 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 1 14:07:10.704: RT: delete route to 192.168.34.0 via 192.168.24.4, FastEthernet0/0*Mar 1 14:07:10.704: RT: no routes to 192.168.34.0, flushing*Mar 1 14:07:10.704: RT: NET-RED 192.168.34.0/29
*Mar 1 14:07:10.704: RT: delete network route to 192.168.34.0*Mar 1 14:07:10.704: RT: NET-RED 192.168.34.0/24*Mar 1 14:07:10.712: DUAL: Destination 192.168.34.0/29*Mar 1 14:07:10.712: DUAL: Find FS for dest 192.168.34.0/29. FD is 2172416, RD is 2172416*Mar 1 14:07:10.712: DUAL: 192.168.24.4 metric 4294967295/4294967295*Mar 1 14:07:10.712: DUAL: 192.168.23.3 metric 2681856/2169856 found Dmin is 2681856*Mar 1 14:07:10.712: DUAL: Removing dest 192.168.34.0/29, nexthop 192.168.24.4*Mar 1 14:07:10.712: RT: add 192.168.34.0/29 via 192.168.23.3, eigrp metric [90/2681856]*Mar 1 14:07:10.712: RT: NET-RED 192.168.34.0/29*Mar 1 14:07:10.716: DUAL: RT installed 192.168.34.0/29 via 192.168.23.3*Mar 1 14:07:10.716: DUAL: Send update about 192.168.34.0/29. Reason: metric chg*Mar 1 14:07:10.716: DUAL: Send update about 192.168.34.0/29. Reason: new if
Se poate observa faptul ca pentru gӑsirea 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 realizându-se foarte rapid in doar 12ms. Acest lucru a fost posibil datorita faptului ca în tabela de topolgie avem doua rute spre aceastӑ rețea.
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)Calculând 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Întârzierea=2x20000/10 = 4000Metrica= 256x( 6476+4000)= 2681856 > 2172416 (Distanta raportată de către 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 intrând in starea active.
*Mar 1 16:16:18.071: RT: delete route to 192.168.34.0 via 192.168.23.3, Serial1/1*Mar 1 16:16:18.071: RT: no routes to 192.168.34.0, flushing*Mar 1 16:16:18.071: RT: NET-RED 192.168.34.0/29*Mar 1 16:16:18.071: RT: delete network route to 192.168.34.0*Mar 1 16:16:18.071: RT: NET-RED 192.168.34.0/24*Mar 1 16:16:18.079: DUAL: Destination 192.168.34.0/29*Mar 1 16:16:18.079: DUAL: Find FS for dest 192.168.34.0/29. FD is 2172416, RD is 2681856*Mar 1 16:16:18.079: DUAL: 192.168.23.3 metric 4294967295/4294967295*Mar 1 16:16:18.079: DUAL: 192.168.12.1 metric 3193856/2681856 not found Dmin is 3193856*Mar 1 16:16:18.079: DUAL: Peer total/stub 1/0 template/full-stub 1/0*Mar 1 16:16:18.079: DUAL: Dest 192.168.34.0/29 entering active state.
*Mar 1 16:16:18.079: DUAL: Set reply-status table. Count is 1.*Mar 1 16:16:18.079: DUAL: Not doing split horizon*Mar 1 16:16:18.095: IP-EIGRP(Default-IP-Routing-Table:1): 192.168.34.0/29 - not in IP routing table*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 1536000Deasemenea se poate observa introducerea noii rute in tabela de rutare. Acum convergenta sa obținut î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 lațimea de banda si întârzierea sunt considerate in mod implicit in calcul metricii. Lӑtimea de banda se refera la cea mai micӑ lӑtime de banda de pe calea cӑtre destinație. Întârzierea se refera la suma întârzierilor de pe fiecare legatura in calea catre destinație.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 metricaFastEthernet0/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 metricaSerial1/1 is up, line protocol is up latimea de banda=107/min(bandӑ) = 107/ 1544=6476Internet address is 192.168.23.2/29 întarzierea=2x20000/10=4000 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, metrica=256x(4000+6476)=2681856reliability 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 încât 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- întârzierea, k4- siguranța și k5-MTU
Noua metricӑ va fi calculata cu formula : 256 * [ K1*latimea de banda+(K2* latimea de banda)/(256-incarcarea) + K3*întarzierea] Pentru a forma adiacente acesti parametri trebuiesc setati la fel pe toate ruterele, altfel vom primi eroare de nepotrivire a parametrilor K.
Noua metrica, luând in calcul si încӑrcarea va fi egala cu 2178917.
192.168.34.0/29 is subnetted, 1 subnetsD 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 legӑturilor astfel incat urmӑtorul 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. 192.168.34.0/29 is subnetted, 1 subnetsD 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 împӑrțirea traficului pe rute cu costuri diferite. Comanda variance forțeazӑ 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/0Pentru seriala s1/1 metrica trebuie sa fie de 4 ori mai mare (4*1349376=5397504) vom obtine:107/ [(5397504/256) – (45000/10)]= 602 KbPentru 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 1R4(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 întreține trei tabele : tabela de adiacenta, tabela de topologie și tabela de rutare.
2.1 Tabela de adiacența
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 tip“salut” 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 neighborNeighbor ID Pri State Dead Time Address Interface 192.168.14.1 0 FULL/ - 00:00:38 192.168.12.1 Serial1/0 192.168.34.3 0 FULL/ - 00:00:34 192.168.23.3 Serial1/1192.168.34.4 1 FULL/DR 00:00:30 192.168.24.4 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, situându-se la radacina arborelui si cautand ruta cu metrica cea mai scazuta. Ruta optimӑ este adaugata in tabela de rutareTabela de topologie se poate afisa folosind comanda show ip ospf database. Se vor afișa toate LSA-urile 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# Checksum Link count192.168.14.1 192.168.14.1 1324 0x8000000E 0x00E33F 4192.168.24.2 192.168.24.2 986 0x80000010 0x007079 5192.168.34.3 192.168.34.3 1114 0x8000000D 0x003089 4192.168.34.4 192.168.34.4 978 0x80000011 0x002C88 5 Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum192.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 vӑrsta Lsa-ului in secunde, Seq# este numӑrul de secvențӑ al Lsa-ului. Inițial 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 cӑtre DR-urile fiecӑrei rețele multiacces( rețeaua 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 Age Seq# Checksum Link count192.168.14.1 192.168.14.1 20 0x8000000C 0x00EA4E 2192.168.24.2 192.168.24.2 912 0x8000000C 0x001CE7 4192.168.34.3 192.168.34.3 1175 0x8000000C 0x008674 2
Link ID ADV Router Age Seq# Checksum Link count192.168.24.2 192.168.24.2 649 0x8000000A 0x009667 2192.168.34.4 192.168.34.4 872 0x80000009 0x00A45C 1
Net Link States (Area 3)
Link ID ADV Router Age Seq# Checksum192.168.24.4 192.168.34.4 872 0x80000008 0x00DC35
Summary Net Link States (Area 3)
Link ID ADV Router Age Seq# Checksum192.168.12.0 192.168.24.2 914 0x80000008 0x00F40B192.168.14.0 192.168.24.2 915 0x80000008 0x004978192.168.23.0 192.168.24.2 915 0x80000008 0x006395192.168.34.0 192.168.24.2 915 0x80000008 0x006C41
Summary ASB Link States (Area 3)
Link ID ADV Router Age Seq# Checksum192.168.14.1 192.168.24.2 390 0x80000008 0x00D820
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag128.23.0.0 192.168.14.1 278 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 destinațiile externe rețelei Ospf. De asemenea, in cazul in care un ruter dispune de o rutӑ inter-zonalӑ și o rutӑ intra-zonalӑ catre aceeasi destinație, va fi pӑstrata 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 subnetsO 192.168.12.0 [110/128] via 192.168.23.2, 00:00:45, Serial0/0
192.168.14.0/29 is subnetted, 1 subnetsO 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 subnetsO 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 subnetsO 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 subnetsC 192.168.23.0 is directly connected, Serial0/0 192.168.34.0/29 is subnetted, 1 subnetsC 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, invӑțate prin redistribuire și pot fi de tipul 1 sau 2 (E1, E2). Diferența î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 convergența 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 acești timpi nu sunt egali nu se va mai stabili adiacența î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 cӑtre fiecare subrețea ruta cea mai bunӑ și fӑrӑ 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 subnetsC 192.168.12.0 is directly connected, Serial0/0 192.168.14.0/29 is subnetted, 1 subnetsC 192.168.14.0 is directly connected, Serial0/1 192.168.24.0/29 is subnetted, 1 subnetsO 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 subnetsO 192.168.23.0 [110/128] via 192.168.12.2, 01:24:00, Serial0/0 192.168.34.0/29 is subnetted, 1 subnetsO 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 adunând costul de 64 de pe interfata seriala si cel de 1 de pe interfata de FastEthernet. Pentru a vizualiza costul unei interfețe se foloseste comanda show ip ospf interface
R2#sh ip ospf interfaceSerial1/0 is up, line protocol is upInternet Address 192.168.12.2/30, Area 0Process ID 1, Router ID 192.168.24.2, Network Type POINT_TO_POINT, Cost: 64Transmit 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.7Pentru a influenta procesul de rutare comanda ip ospf cost cost ne permita sa setӑm 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 ABR-ului 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 urmӑrit 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: 64R3#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: 64R1#sh ip ospf database summary OSPF Router with ID (192.168.14.1) (Process ID 1) Summary Net Link States (Area 1)LS age: 490Options: (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.1LS Seq Number: 8000000CChecksum: 0x2A95Length: 28Network 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.Așadar in tabela de rutare va fi instalata rețeaua 192.168.23.0 cu metrica 65, urmӑtorul nod fiind 192.168.24.2.
R4#sh ip routeGateway of last resort is not set 192.168.12.0/30 is subnetted, 1 subnetsO 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 subnetsO 2.2.2.2 [110/2] via 192.168.24.2, 01:48:36, FastEthernet0/0 192.168.14.0/29 is subnetted, 1 subnetsC 192.168.14.0 is directly connected, Serial1/0 192.168.24.0/29 is subnetted, 1 subnetsC 192.168.24.0 is directly connected, FastEthernet0/0 128.23.0.0/24 is subnetted, 1 subnetsO 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 subnetsO 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 subnetsC 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
Interval 480 s Interval maxim-65535
Eigrp 132 ms 3 s 780 ms 7 min 40 s 432 msNu 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 msNu 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
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 rețea formată din patru rutere. Timpi de convergența sunt mici, dar depind în mare parte de dimensiunea rețelei, încarcarea acesteia si latimea de bandă. Se poate observa faptul ca timpul de convergența creste exponential odata cu creșterea 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 convergența si utilizarea procesorului. Daca configurăm 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
Interval 480 s Interval maxim-65535
Eigrp 4 s 32 s 280 ms 8 min 10 s 32 msNu 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 msNu 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
Rip Timpul de trimitere a actualizarilor nu pot configurati, timpul de convergenta este influentant de marimea retelei.- 4 min 30 s
Tabel 2 – Timpul de convergenta pentru retea de dimensiune medie
Grafic 1- comparație timp de convergență Eigrp
Grafic 2- comparație 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, performanța nu s-a diminuat foarte mult, timpii de convergența nefiind foarte mari.In schimb Rip nu este un protocol scalabil, intr-o retea medie timpul de convergența 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 căi 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.
Grafic 3- Comparatie Eigrp/Ospf/Rip
Comparand timpi de convergenta pentru Eigrp si Ospf se observă o diferența care ar putea duce la concluzia ca Eigrp este un protocol mai bun din punct de vedere a timpului de convergenta. Totuși cu cât rețeaua 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 întârzierea și procesul
de investigare prin pachete de tip “ Interogare ” încetinesc convergență rețelei pe măsură ce adâncimea retelei creste. Cisco recomandată limita maxima de 7 hopuri.
Desi timpul de convergența a fost mai bun trebuie tinut cont de faptul ca Ospf cunoaște întreaga topologie pe cand Eigrp are doar informații partiale. Asa cum am observat in studiul protocolului , la căderea 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 când 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 conține mai multe înregistrări. Numărul 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 legăturilor, orice schimbare in retea, va fi propagată către toate ruterele care trebuie sa recalculeze fiecare legătură din întrega tabelă de topologie.
Utilizarea resurselor de către 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 functie de protocol)
Nu se poate face o analiza clara a dimensiunii unui pachet deoarce acesta depinde de numarul de înregistrări 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” conținând î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 MBAstfel 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
Deși 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ӑ aceeași comandӑ ca și in cazul oricӑrui alt protocol de rutare: router. În cazul BGP aceastӑ comandӑ primeste ca si parametru atat cuvantul cheie bgp cât ș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 impӑrtita 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 pâna acum.
Figura 5- Scenariu de bază
Cea mai rapidӑ metoda de a realiza sesiunea iBGP intre doua rutere este alegerea unuia dintre IP-urile de pe o interfata si folosirea acestuia în comanda neighbor :
Folosirea cuvântului 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 apӑrea, daca una dintre interfetele celor doua rutere incepe sa oscileze intre starile up/down. Acest lucru se poate intâmpla 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 adiacența 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 adiacența 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.
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 summaryBGP router identifier 1.1.1.1, local AS number 100[...]Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd2.2.2.2 4 100 237 236 2 0 0 01:31:59 14.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 ” >”. Semnificația “i”-ului din stanga este ca ruta a fost învӑțatӑ 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 invătate 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 subnetsB 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 cӑtre reteaua 5.5.5.0. Aceasta problemӑ apare datoritӑ mecanisme de evitare a buclelor de rutare folosit de cӑtre 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 consecința 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 același 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 același AS, vor exista 50*49/2= 1225 conexiuni iBGP. Solutia pentru scӑdera numarului de conexiuni necesare este configurarea unui route-reflector sau confederații.
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ӑ adiacența 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 sӑi (R4).
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.
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( numӑrul de hopuri, lӑțimea 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 bgpBGP table version is 16, local router ID is 192.168.67.2Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path*> 5.5.5.0/24 192.168.67.1 0 600 100 i*> 7.7.7.0/24 0.0.0.0 0 32768 i*> 10.1.1.0/24 192.168.67.1 0 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 destinație.
R7#sh ip bgp Network Next Hop Metric LocPrf Weight Path* 5.5.5.0/24 192.168.57.5 0 500 100 i*> 192.168.67.1 600 100 i*> 7.7.7.0/24 0.0.0.0 0 32768 i*> 10.1.1.0/24 192.168.57.5 0 0 500 i* 192.168.67.1 0 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
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 Next Hop Metric LocPrf Weight Path
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.
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
Se poate observa ca desi au fost păstrate toate atributele setate pană acum, datorita atributului ”Greutate” pachetele vor fi trimise către urmatorul nod 192.186.67.1
