Analiza performanțelor de rutare în cazul protcoalelor OSPF și EIGRP [306343]
Universitatea “Politehnica” [anonimizat](i) științific(i) Absolvent
Ș.l. Dr. Ing. Alexandru VULPE Adrian NIȚĂ
Anul
2016
Lista figurilor
Stabilirea comunicației bidirectionale………………………………………………………. 4
Antetul pachetelor OSPF…………………………………………………………………… .6
Relațiile dintre vecini………………………………………………………………………….7
Tabela de rutare a unui ruter…………………………………………………………………..8
[anonimizat]…………………………………………………………………..9
Tipuri de rutere……………………………………………………………………………….10
Zona Stub……………………………………………………………………………………..11
Zona Totally Stubby…………………………………………………………………………12
Zona Not So Stubby…………………………………………………………………………12
Exemplu configurație autentificare OSPF……………………………………………………13
2.1. Timpii de Hello și cei de Hold Times………………………………………………………..15
2.2. Pachetele UPDATE/ ACKNOWLEDGEMENT…………………………………………….16
2.3. Pachetele de tip QUERY/REPLY………………………………………………………….. 16
2.4. Tabela cu vecinii EIGRP…………………………………………………………………….17
2.5. Tabela cu topologia EIGRP………………………………………………………………… 17
2.6. Tabela rutare EIGRP…………………………………………………………………………18
2.7. Verificare valori K……………………………………………………………………………19
2.8. Tabela EIGRP.Succesori.Distanță fezabilă…………………………………………………..20
3.1. Fereastra de lucru GNS3……………………………………………………………………..23
3.2. Prezentare topologie 6 rutere…………………………………………………………………25
3.3. Prezentare topologie 30 rutere………………………………………………………………..27
3.4. Configurarea interfetelor pe un ruter…………………………………………………………31
3.5. Starea interfețelor unui ruter………………………………………………………………….32
3.6. Configurare OSPF………………………………………………………………………… …33
3.7. Protocol OSPF………………………………………………………………………………..34
3.8. Adiacență OSPF………………………………………………………………………………35
3.9. Configurare EIGRP…………………………………………………………………………..36
3.10. Verificare Protocol EIGRP…………………………………………………………………….37
3.11. Cost OSPF……………………………………………………………………………………39
3.12. Eigrp delay……………………………………………………………………………………40
3.13. Ruta catre ruterul A0R4………………………………………………………………………40
3.14. Conectivitate cu ruterul A0R4………………………………………………………………..41
3.15. Ruta catre A0R4………………………………………………………………………………41
3.16. Întrerupere interfata OSPF……………………………………………………………………42
3.17. Întrerupere interfata EIGRP…………………………………………………………………..42
3.18. Întrerupere link………………………………………………………………………………..43
3.19. Ruta către ruterul A0R4………………………………………………………………………43
3.20. Redundanță OSPF/EIGRP……………………………………………………………………44
3.21. [anonimizat]……………………………………………………………………………44
3.22. Ruta OSPF/EIGRP…………………………………………………………………………….45
3.23. Ruta către ruterul A4R4……………………………………………………………………….46
3.24. Întrerupere interfață OSPF……………………………………………………………………..46
3.25. Întrerupere interfață EIGRP……………………………………………………………………47
3.26. Ruta alternativă către A4R4……………………………………………………………………47
3.27. Redundanță OSPF/EIGRP…………………………………………………………………….48
3.28. Generare trafic…………………………………………………………………………………49
3.29. Întrerupere link…………………………………………………………………………………50
3.30. Număr de pachete icmp pierdute………………………………………………………………51
3.31. Captură pachete Wireshark…………………………………………………………………….54
3.32. Ping 192.168.4.4……………………………………………………………………………….55
3.33. Întrerupere link către A4R3……………………………………………………………………56
3.34. Pachete icmp pierdute………………………………………………………………………….57
3.35. Captură pachete Wireshark……………………………………………………………………..59
3.36. Generare trafic………………………………………………………………………………….60
3.37. Întrerupere link…………………………………………………………………………………61
3.38. Număr pachete…………………………………………………………………………………62
3.39. Captură pachete icmp…………………………………………………………………………..65
3.40. Ping ruter A4R4………………………………………………………………………………..66
3.41 Întrerupere link…………………………………………………………………………………67
3.42 Pachete icmp……………………………………………………………………………………68
3.43. Captură Wireshark EIGRP……………………………………………………………………..71
Lista tabelelor
1.1 Starile vecinilor OSPF………………………………………………………………………….. 5
3.1 Adresare IP………………………………………………………………………………………26
3.2 Adresare IP……………………………………………………………………………………….30
3.3 OSPF Cost……………………………………………………………………………………….38
3.4 Eigrp delay……………………………………………………………………………………….39
3.5 Convergenta protocoale rutare……………………………………………………………………72
Lista acronimelor
OSPF Open Shortest Path First
EIGRP Enhanced Interior Gateway Routing Protocol
RIP Routing Information Protocol
IS-IS Intermediate System to Intermediate System
LSA Link-State Advertisement
RD Reported Distance
RTP Reliable Transport Protocol
SPF Shortest Path First
AS Autonomous System
BR Backbone Router
DBD Database Description
DR Designated Router
DUAL Diffusion Update Algorithm
DVR Distance Vector Routing
FC Feasible Condition
FD Feasible Distance
FS Feasible Successor
DES Discrete Event Simulation
RFC Request for Comment
UDP User Datagram Protocol
IPv4 Internet Protocol Version 4
SA Single Area
VLSM Variable-Length Subnet Masking
ABR Area border routers
LSA Link-state advertisment
RID Router-id
ATM Asynchronus transfer mode
IOS Internetwork Operating System
NED Network Description
IGP Interior Gateway Protocol
IP Internet Protocol
CIDR Classless Inter-Domain Routing
NBMA Non-broadcast multiple access network
INTRODUCERE
In rețelele de calculatoare, termenul rutare se referă la selectarea căilor într-o retea, pe care să se trimită anumite date. Rutarea directează drumul pachetelor ce conțin adrese logice dinspre sursă spre destinația finală prin noduri intermediare (numite rutere). Dacă ne imaginăm un ruter ca un dispozitiv similar unui calculator, nu vom fi deloc departe de realitate. Simplificând, un ruter este un dispozitiv ce realizează interconectarea între două sau mai multe rețele. Prin intermediul ruterelor, pachetele de date pot traversa granițele rețelelor, parcurgând oricâte rețele este necesar pentru a ajunge la destinație. Funcția principală a unui ruter este aceea de a ruta pachete sau, altfel spus, de a executa un algoritm ce are drept scop determinarea căii pe care un pachet de rețea trebuie să o urmeze pana la destinație. Procesul de rutare directează de obicei pe baza unor tabele de rutare pe care le gestionează ruterele, care mențin o înregistrare a celor mai bune rute către diferite destinații din rețea. Rețelele mici pot gestiona tabele de rutare configurate manual. Rețelele mari implică topologii mari care se schimbă constant, facând utilizarea manuală a tabelelor de rutare foarte dificilă.
Există două mari tipuri de rutare care stau la baza tuturor celorlalte tipuri de rutare: rutarea statică și rutarea dinamică.Rutarea statică descrie un sistem care rutează într-o rețea de date in funcție de căi fixe. Rutarea dinamică construiește dinamic tabelele de rutare, bazându-se pe informațiile purtate de protocoale, permițand rețelei să acționeze în mod aproape automat pentru a evita erori și blocaje în rețea. Datorită proprietăților sale, rutarea dinamică domină în momentul actual internetul.
Avantajele rutării dinamice fața de cea statică sunt scalabilitatea si adaptibilitatea. O rețea rutată dinamică poate crește mult mai repede și este capabilă să se adapteze schimbărilor din topologia rețelei aduse tocmai de această creștere sau de erorile din una sau mai multe componente ale rețelei. Într-o rețea dinamică, ruterele învață despre topologia rețelei comunicând cu alte rutere. Rutarea dinamică are însă și dezavantaje, cum ar fi creșterea complexității.
Rutarea statică are avantajul că este simplă, nu necesită putere de calcul în ruter pentru determinarea rutelor (această muncă e făcută de administrator) și nu generează trafic în rețea (ruterele nu schimbă între ele informații de rutare), dar prezintă următoarele dezavantaje: în cazul unor schimbări, administrarea este dificilă, nu se adaptează automat în cazul apariției unor defecțiuni; o rută devenită inaccesibilă rămîne inaccesibilă, pînă la intervenția administratorului. Un router care este programat pentru rutare statică expediază pachetele prin porturi predeterminate. După ce routerele statice sunt configurate, ele nu mai trebuie să încerce descoperirea rutelor, nici măcar să comunice informații despre rute. Rolul lor este redus la simpla expediere a pachetelor. Rutarea statică este bună doar pentru rețele foarte mici, care au o singură cale către orice destinație dată. În astfel de cazuri, rutarea statică poate fi cel mai eficient mecanism de rutare, pentru că nu consumă lărgime de bandă, încercând să descopere rute și să comunice cu alte rutere.
Pe măsură ce rețelele cresc și apar căi redundante către destinații, rutarea statică devine o sarcină care necesită prea mult efort si necesită categoric rutare dinamică.
Ruterele utilizează protocoale pentru a face posibilă comunicarea într-o rețea de la un calculator la altul. Un protcol este un set de reguli si convenții cu ajutorul căruia se realizează comunicarea într-o rețea. Protocoalele determină formatul, timpul, secvențele și controlul erorilor în comunicarea de date. Totodata controleaza toate aspectele comunicaîării datelor, printre care și: cum este construita rețeaua fizică; cum sunt conectate calculatoarele la rețea; cum sunt formate datele pentru transmisie; cum sunt transmise datele; cum sunt corectate erorile.
Când vorbim despre protocoale, ne referim la rutare dinamică, care realizează trei funcții elementare: descoperirea de noi rute, comunicarea informațiilor despre noua rută altor rutere și expedierea pachetelor utilizând acele rute. Acestea se împart în trei mari categorii: cu vectori distanță (distance-vector protocols), cu starea legăturilor (link-state protocols), și hibride. Cea de a treia categorie de protocoale, imbina caracteristici ale protocoalelor bazate pe vectori distanță cu unele caracteristici ale protocoalelor bazate pe starea conexiunii.
Pentru protocoalele de tip distance-vector calculul drumului optim se face pe baza de direcție (indicată de obicei prin precizarea interfeței) si distanța pana la destinatie folosind directia respectiva, unde distanța este definită ca metrica și direcția este definită ca numărul de hopuri sau de rutere. Informațiile de rutare se schimbă numai intre ruterele învecinate, la intervale periodice. Rezultă într-un timp de convergentă mare, adică schimbările apărute in topologia rețelei se propagă destul de greu către rutele mai îndepartate de locul apariției modificării în cauză.
Cele mai populare protocoale de rutare bazate pe vectori-distanță sunt RIP și EIGRP. RIP folosește drept metrică numărul de hopuri (rutere) pâna la rețeaua destinație și selectează ruta cu cel mai mic număr de hopuri ca fiind ruta cea mai bună.
EIGRP a fost dezvoltat de către Cisco (eliberat în 1988) cu scopul de a îmbunătăți protocolul RIP pe vremea cînd IETF încă lucra la dezvoltarea OSPF –ului. Acest protocol elimină unele dintre defectele protocolului RIP , și are îmbunătățiri ca folorirea de metrici compuse, rutarea pe căi multiple, și mînuirea rutelor implicite. Acest protocol de rutare este unul dintre cele mai diversificate și robuste protocoale de rutare. Combinația sa unica de caracteristici îmbină cele mai bune atribute ale protocoalelor de vector-distanță cu cele mai bune atribute ale protocoalelor cu starea legăturilor. Rezulatul este un protocol de rutare hibrid care sfidează împărțirea pe categorii a protocoalelor convenționale. Spre deosebire de alte protocoale de rutare bazate pe vectori-distanță, EIGRP nu mandatează o revizuire periodică al tabelelor de rutare între rutere vecine. În schimb, folosește un mecanism de descoperire/recuperare pentru a asigura că vecinii sunt conștienți de accesibilitatea fiecăruia în parte.
Protocoalele de tip link-state (bazate pe starea conexiunii) construiesc o bază de date cu întreaga topologie a rețelei și calculează drumul cel mai scurt pe baza unui algoritm de tip Dijkstra (SPF-shortest path first). Principala problemă a acestor tipuri de protocoale este că fiecare dintre rutere va trebui sa construiască arborele topologic, și apoi să extragă rutele ca drumuri optime în acest arbore. Acest proces necesită resurse de memorie și procesor semnificative. Cu toate acestea timpul de convergența pentru protocoalele link-state este semnificativ mai redus decât pentru protcoalele distance-vector. Un exemplu de astfel de protocol este OSPF (open shortest path first).
Lucrarea este structurată pe trei capitole, primele două prezentând aspectele teoretice pe baza cărora, în ce de-al treilea capitol, am prezentat un studiu de caz, care sa vina in explicarea și completarea teoriei.
CAPITOLUL 1
OSPF
PREZENTAREA PROTOCOLULUI.CARACTERISTICI
OSPF este un protocol bazat pe starea conexiunilor (link-state), standardizat de IETF la începutul anilor 90. Acesta este un protocol open standard. Caracteristicile importante ce recomandă OSPF , țin de diferențele tradiționale dintre protocoalele distance vector și cele link-state. OSPF oferă un timp de convergența de ordinul secundelor ,cel mai adesea cu 2 ordine de mărime mai mic decat cel oferit de exemplu, de RIP.
OSPF va trimite în actualizări și masca de rețea, pe lângă rețeaua destinație. După stabilirea adiacenței cu vecinii și schimbarea informațiilor de rutare, actualizările pentru protocoalele link-state se fac incremental, precizând doar schimbarile apărute, spre deosebire de protocoalele distance vector, ce vor trimite informații complete de rutare vecinilor la fiecare actualizare. Transmiterea periodică a tabelei de rutare, în întreaga rețea, conduce la o convergenta lentă. In plus, într-o retea stabilă consumul de bandă pentru schimbarea informațiilor de rutare este mult mai scăzut pentru OSPF, actualizările fiind trimise doar in cazul unor schimbări de topologie, și nu la intervale fixe de timp precum RIP.
Protocoalele distance-vector sunt vulnerabile în cazul modficărilor din rețea. OSPF este mult mai stabil in fața schimbărilor de topologie, datorită faptului că fiecare ruter are o imagine de ansamblu a rețelei și rutează pachetele independent, conform propriilor decizii.
Ruterele care rulează OSPF obțin o imagine completă asupra rețelei, denumită tabela de topologie dat fiind ca acumulează informații de la toate celelalte rutere. Deoarece ruterul care rulează OSPF dispune de o reprezentare completă a topologiei rețelei, va selecta cea mai buna rută conform unui algoritm Dijkstra Shortest Path First (SPF). Mai precis, ruterele sunt ierarhizate conform costului (metricii) acestora, fiind selectată ruta cu costul cel mai redus. Implicit, costul unei interfețe este calculat ca fiind invers proporțional cu lătimea de bandă a acesteia.
Un alt avantaj este prevenirea buclelor de trafic. Acestea pot apărea atunci când modificarile din topologia rețelei se propagă lent. În cazul OSPF, propagarea rapidă a informațiilor privind modificările din topologia rețelei previne apariția unor astfel de situații, astfel incât rutele calculate de OSPF nu conțin bucle de trafic.
OSPF suportă atât implementari plate, single-area (SA) cât și implementări ierarhice multi-area (MA), permițând împărțirea logică in zone, pentru a limita inundarea intregii rețele cu actualizări atunci când se modifică topologia. Performanțele OSPF privind convergenta și latența sunt datorate caracteristicilor cheie precum independența deciziilor ruterelor și organizarea ierarhică a rețelei.
CAPITOLUL 1.1 FUNCȚIONAREA PROTOCOLULUI
Funcționarea procesului OSPF pe un ruter se desfășoara în 5 etape:
identificarea vecinilor ruterului și stabilirea relațiilor de adiacentă.
in cazul rețelelor multi-access: selectarea unui ruter responsabil de actualizări și a unui ruter de backup
descoperirea rutelor
selectarea rutelor optime către destinație
actualizarea informațiilor de rutare
Înainte de a face schimb de informații, doua rutere vecine trebuie să se identifice si să stabilească o relație de adiacență. Acest proces are loc cu ajutorul pachetelor de tip hello, prin care se stabilesc și se mențin relații bidirecționale. O relație bidirecțională cu un anumit vecin, este stabilită în momentul în care un ruter se recunoaște pe sine î
n lista vecinilor din pachetul hello primit de la acel vecin. Un pachet hello conține următoarele informații: identificatorul ruterului, intervalele hello și dead, lista vecinilor, identificatorul zonei, prioritatea ruterului, adrese ip ale ruterelor DR (ruter desemnator) și BDR (ruter de backup), informația de autentificare și marcajul de zonă stub.
Fiecare ruter are un identificator OSPF, constând dintr-un numar de 32 de biți, exprimat în general in formă zecimală specifică adreselor IP. Alegerea OSPF_ID se va face la inițializarea procesului OSPF. Acest identificator poate fi configurat explicit. Dacă nu există o asfel de setare identificatorul OSPF va fi cea mai mare adresa IP a interfețelor de loopback; dacă nu există nici interfețe de loopback, valoarea OSPF_ID va fi inițializată cu valoarea celei mai mari adrese IP dintre adresele interfețelor active. Acest identificator este folosit atât la stabilirea relațiilor bidirecțioanale, cât și în schimbul de mesaje de actualizare.
Figura 1.1 Stabilirea comunicatiei bidirectionale
Sursa:
Odată cu pornirea procesului OSPF pe un ruter, acesta trece din starea down în starea init trimitănd pachete hello către vecini. Spre deosebire de protocoalele distance-vector care folosesc pachete de broadcast, OSPF initiază procesul de identificare a vecinilor folosind adresa multicast specifică 224.0.0.5. Configurația implicită in retelele Ethernet prespune trimiterea de mesaje hello către ruterele vecine la fiecare 10 secunde. Ruterele vecine ce ruleaza OSPF vor adauga ruterul care a inițiat comunicația în tabela de vecini și îi vor raspunde cu un pachet hello de tip unicast. Dupa cum se observă în figura de mai sus, adresa IP a ruterului care a inițiat procesul de adiacență este inclusă de altfel in pachetul hello de răspuns, pentru a confirma validitatea schimbului de mesaje. În momentul recepționarii răspunsului, ruterul trece în starea 2-way. În această stare, ruterul completează o tabelă de adiacență cu informații privind toți vecinii cu care au stabilit o legătură bidirecțională.
Tabel 1.1 Starile vecinilor OSPF
In rețelele multiacces precum Ethernet, Frame-Relay sau ATM, urmează etapa de selectare a ruterului desemnat pentru actualizări (Designated Router) și a ruterului de Backup (Backup Designated Router). Cele 2 routere au rolul de a media schimbul informațiilor de actualizare. Procesul de alegere se bazează pe 2 valori numerice:
router ID, unic la nivel de ruter
priority, la nivel de interfață
Dacă nu s-a configurat manual un identificator router ID, ruterul alege adresa IP cea mai mare (ca număr de 32 de biți) dintre cele existente pe interfețele ruterului. Dacă există și interfețe loopback, se alege cea mai mare adresă dintre acestea, chiar dacă este mai mică decît a unei interfețe non-loopback. DR si BDR sunt selectate pe baza priorității OSPF atribuite ruterului. Prioritatea unui ruter de a deveni DR se stabilește la nivel de interfața, putand fi configurata intre 0 si 255. Prioritatea implicita este 1, iar valorile mai mari sunt preferate in selecție. Routerul BDR este cel cu valoarea următoare în ordine descrescătoare. Acest ruter de rezervă asigură continuitatea rutării în cazul în care DR se defectează.
CAPITOLUL 1.2 FORMATUL PACHETELOR OSPF
Pachetele OSPF sunt transmise în datagramele IP și nu sunt încapsulate în pachetele TCP sau UDP. Antetul IP conține în câmpul de identificare a protocolului valoarea 89. De asemenea, valoarea câmpului care definește tipul serviciului (type of service) are valoarea 0. Acest mecanism este utilizat pentru a impune o procesare specială a pachetelor.
Toate pachetele OSPF au acelasi antet, care este ilustrat in figura de mai jos. Antetul conține informații generale, cum ar fi: identificatorul ariei, RID (router-id), suma de verificare, și informația de autentificare.
Figura 1.2 Antetul pachetelor OSPF
Sursa:
Există 5 tipuri de pachete OSPF ,folosite pentru stabilirea relațiilor de adiacentă și pentru actualizarea tabelei topologice.
Hello – Acest tip de pachet este utilizat pentru descoperirea și menținerea relațiilor dintre vecini;
DBD – Descrierea bazei de date (Database description) – Acest tip de pachet descrie setul de LSAuri conținute în baza de date a stărilor legăturilor, a ruterului;
LSR – Cerere stare legătură (Link state request) – Acest tip de pachet solicită o variantă mai nouă a unei LSA (link-state advertisment) de la un vecin;
LSU – Actualizare stare legătură (Link state update) – Acest tip de pachet oferă o variantă nouă a unei LSA către un vecin (eventual, care a efectuat o cerere);
LSAck -Confirmare stare legătură (Link state acknowledgement) – Acest tip de pachet confirmă recepționarea unei noi LSA.
Actualizările, sunt trimise, fie ca urmare a sesizării unor modificări în topologia rețelei, fie ca urmare a expirării informațiilor. De asemenea ruterul care observă o modificare a topologiei rețelei informează ruterele vecine. Fiecare ruter compară fiecare LSA primit cu cele deja disponibile în tabela de topologie.
OSPF folosește adresarea multicast și unicast. De exemplu, odată ce un ruter sesizează modificarea topologiei va trimite pachete LSU către adresa de multicast 224.0.0.5. În cazul rutelor multiacces ruterul care a sesizat o modificare, va trimite o actualizare pe adresa de multicast 224.0.0.6
Figura 1.3 Relatiile dintre vecini
Sursa:
CAPITOLUL 1.3 TABELELE OSPF
Informațiile de care dispune procesul OSPF sunt structurate în trei tabele, și anume tabela de adiacență, tabela de topologie și tabela de rutare
Tabela de topologie conține o imagine detaliată a întregii rețele, constând în toate mesajele de actualizare a stării legăturilor. Tabela de topologie este sincronizată periodic cu tabelele celorlate rutere din rețea. Fiecare proces OSPF dispune de o tabelă de topologie, pe baza careia ia deciziile de selectare a căilor optime ce vor fi promovate în tabela de rutare
În cazul OSPF single area pentru a selecta ruta optimă către o destinație ruterul aplică algoritmul Dijkstra SPF, căutand ruta cu metrica cea mai scazută. Ruta optimă este adaugată la tabela de rutare. Fiecare ruter are o tabelă de rutare unică, ce reflectă poziția sa în topologie.
Ca urmare a stabilirii mesajelor bidirecționale cu ruterele vecine ce rulează OSPF, un ruter va completa tabela de adiacența. Dacă unul dintre vecini nu trimite pachete pentru o perioadă mai lungă decât intervalul permis, tabela de adiacență este actualizată prin ștergerea acestuia și se invalidează toate căile care treceau prin acel vecin. Intervalul DEAD este setat implicit cu o valoare de 4 ori mai mare decat intervalul la care se trimit pachetele HELLO.
Figura 1.4 Tabela de rutare a unui ruter
CAPITOLUL 1.4 OSPF MULTI-AREA
Scalabilitatea OSPF se datorează în mare masură posibilității de a segmenta rețeaua în mai multe arii, cu avantaje semnificative pentru timpul de convergența al protocolului și timpul de răspuns al rutării.
Pentru a simplifica reprezentările topologice și calculul rutelor optime, reteaua poate fi structurată în zone (sau arii). O arie reprezintă o mulțime logică de rutere, legături și rețele OSPF, fiind reprezentată printr-un identificator propriu. Identificatorul unei arii este un numar pe 32 de biți, cel mai adesea sub forma unei singure valori in notație zecimală.
Toate rețelele OSPF conțin cel puțin o singură arie. Această arie este aria 0 sau aria coloană vertebrală (backbone). Se pot adăuga și alte arii, în funcție de topologia reală a rețelei sau de alte cerințe de proiectare.
OSPF multi-area se bazează pe un model ierarhic pe 2 nivele. Aria 0 este întodeauna aria centrală, toate celelalte arii atasându-se la aceasta. Aria 0 formează nivelul de sus al ierarhiei, iar celelalte nivelul de jos. Zonele normale sunt cele care includ utilizatorii finali. De regulă o zonă normală, nu este folosită pentru a transporta trafic între zone. Un exemplu de topologie împartita pe zone este prezentată mai jos.
Figura 1.5 Topologie OSPF multi-area
Sursa:
În funcție de amplasarea și rolul unui ruter, în retea exista trei tipuri de rutere:
Ruteri de interior de arie, IA (Intra-area routers) – Acești ruteri sunt amplasați, din punct de vedere logic, în interiorul unei arii OSPF. Fiecare ruter de interior de arie menține o bază de date a topologiei, corespunzătoare numai ariei locale a acestuia.
Ruteri de extremitate de arie, ABR (Area border routers) – Aceste rutere se conectează, cu una sau mai multe arii, dintre care una trebuie să fie aria backbone. Astfel, un ruter ABR este utilizat pentru interconectarea mai multor arii. Fiecare ruter ABR menține o bază de date a topologiei, separat pentru fiecare arie la care se conectează. Ruterele ABR execută instanțe separate de algoritm OSPF pentru fiecare arie.
Ruterele de extremitate de SA, ASBR (AS boundary routers) – Aceste rutere sunt plasate, la periferia unui sistem autonom OSPF. Astfel, un ruter ASBR funcționează ca o poartă de acces (gateway), care anunță căile de acces dintre rețeaua OSPF și alte domenii de rutare. Ruterele ASBR transmit spre interiorul SA, mesajele de anunțare a rutelor LSA externe
Ruterele interne din aria 0, (Backbone routers)- au cel putin o interfata in aria 0, participand astfel la conectarea zonelor normale cu zona 0.
Figura 1.6 Tipuri de rutere
Sursa:
CAPITOLUL 1.5 TIPURI DE LSA (LINK-STATE ADVERTISMENTS) OSPF MA
Comunicarea în cazul OSPF multi-area se realizează prin mai multe tipuri de mesaje LSA, clasificate în funcție de ruterul care le inițiaza și de informația pe care o conțin. Mesajele LSA primite de un ruter formează tabela sa de topologie (LSDB). Ele descriu întreaga topologie a unei rețele sau a unei zone OSPF.
Pentru transmiterea de update-uri, se pot folosi 7 tipuri de pachete:
Tipul 1 – Ruter Link LSA: generat de fiecare ruter pentru fiecare zonă din care face parte. Transmite starea legăturilor ruter-ului respectiv către toate ruter-ele din zonele respective. (mesaj multicast)
Tipul 2 – Network Link LSA: generat de către DR și conține toate ruterele din acea rețea cu care DR are stabilită o relație de adiacență
Tipul 3 – Network Summary LSA: generat de către ABR, descrie legăturile dintre ABR și ruter-ele interne unei anumite zone. Sunt trimise în zona 0, către alte ABR, descriind rute către rețelele din zona locală conectată la ABR
Tipul 4 – Network Summary LSA: generat de ABR, descrie accesul către rutere ASBR
Tipul 5 – AS External Link LSA: generat de către ASBR, descrie rute către destinații externe sistemului autonom(sau rețelei OSPF).
Tipul 6 – Multicast LSA: Neimplementat pe ruter-ele Cisco
Tipul 7 – NSSA External LSA: create de ASBR și transmise în not so stubby areas (NSSA). Aceste LSA-uri vor fi converite la LSA de tipul 5 de către ABR.
CAPITOLUL 1.6 TIPURI DE ARII/ZONE
Exista 4 tipuri de zone normale: zone standard, zone Stub, zone de tip totally stubby și zone de tip not-so-stuby
Zonele standard sunt cele care acceptă toate tipurile de update-uri și sumarizări, fără restricții.
Zonele Stub nu acceptă informații cu privire la rutele din afara sistemului OSPF și prin urmare mesajele LSA4 si LSA5 sunt filtrate. Ruterele din astfel de zone vor folosi ruta default pentru a accesa rețelele din afara sistemului OSPF. Ruterul ABR de la granița zonei STUB va genera un LSA3 pentru a anunța o rută implicită în interiorul zonei.
Figura 1.7 Zona Stub
Sursa:
La un nivel și mai ridicat de izolare zonele de tip Totally Stubby, nu acceptă informații cu privire la rutele externe sistemului autonom sau rute sumarizate din alte zone. Ruta default va fi folosită pentru a accesa toate destinațiile externe sistemului autonom sau externe acestei zone.
Figura 1.8 Zona Totally Stubby
Sursa:
Zonele de tip Not so stubby ( NSSA-not so stubby area) sunt o modificare proprietară Cisco a ariilor Stub sau totally stubby, pentru a permite accesul acestora către rețele din afara sistemului OSPF.
Figura 1.9 Zona Not So Stubby
Sursa:
CAPITOLUL 1.7 SUMARIZAREA RUTELOR ȘI AUTENTIFICAREA OSPF
Principalele beneficii ale sumarizarii rutelor sunt creșterea scalabilitații și reducerea consumului de memorie și procesor.
OSPF pune la dispoziție 2 tipuri de sumarizare: între zone și externă.Sumarizarea rutelor între zone diferite ale aceluiași sistem autonom poate fi configurată pe ABR și se aplică pentru toate rutele din fiecare zonă. Sumarizarea rutelor externe poate fi configurată pe ASBR și se aplică numai rutelor externe incluse în OSPF prin redistribuție.
Pentru a preveni primirea de actualizări neautorizate, este necesară folosirea autentificării vecinilor. Autentificarea se face la primirea fiecarui pachet de actualizare primit prin trimiterea unei parole cunoscute de ambele rutere care comunică. Ruterul verifică fiecare pachet OSPF primit pentru a autentifica sursa actualizării. În mod implicit nu este activată autentificarea în cadrul OSPF. Acesta suportă 2 metode de autentificare ce pot fi configurate: o parolă simplă trimisă în clar și autentificarea prin MD5
Metoda prin MD5 include folosirea unui numar de secvență în fiecare pachet OSPF pentru a proteja ruterele împotriva atacurilor
Figura 1.10 Exemplu configuratie autentificare OSPF
CAPITOLUL 2
EIGRP
PREZENTAREA PROTOCOLULUI. CARACTERISTICI
Enhanced Interior Gateway Routing Protocol (EIGRP) este introdus în 1992 de către Cisco sub forma unui protocol de rutare proprietar. Asa cum spune și numele, EIGRP este o versiune îmbunătățită a IGRP cu care iși și pastreaza compatibilitatea. Amândouă sunt proprietare CISCO și opereaza doar pe ruterele CISCO. Insă din anul 2013, EIGRP se poate folosi și pe alte dispozitive.
EIGRP include câteva îmbunătatiri care nu sunt găsite la alte protocoale de rutare bazate pe vectori distanță ( distance-vector) cum ar fi RIP și IGRP. Aceste caracteristici includ:
Reliable Transport Protocol (RTP) –Protocol de transport sigur
Bounded Updates – Reactualizări legate
Difusing Update Algorithm (DUAL)- Algoritmul DUAL
Establishing Adjacencies-Stabilirea adiacențelor
Neighbor and Topology Tables- Tabelele privind topologia și vecinii
Deși EIGRP se poartă ca un protocol link-state, este în continuare un protocol bazat pe vectori distanță. Termenul de “hibrid” este deseori folosit pentru a defini acest protocol deoarece combină caracteristicile protocoalelor bazate pe vectori-distanță cu algoritmii protocoalelor bazate pe starea conexiunilor. CISCO nu mai folosește acest termen atunci când vorbește de EIGRP.
Cele mai importante caracteristici ale acestui protocol sunt: convergența rapidă, suportul pentru VLSM (Variable-Length Subnet Masking), actualizările parțiale și suportul pentru protocoale rutate multiple.
Prin convergența rapidă, întelegem că ruterul stochează tabelele de rutare ale tuturor vecinilor, iar atunci cand o rută dispare, va folosi o rută alternativă.
Suportul pentru VLSM permite folosirea măștilor de lungime diferită pentru aceeași rețea și suportul pentru subrețele discontinue. EIGRP este un protocol de rutare classless, ceea ce inseamnă că atunci cand anunță o rută către o rețea, trimite și masca de rețea.
Fața de celelalte protocoale distance-vector,EIGRP nu trimite actualizări periodice ci actualizări parțiale declanșate de evenimentele din rețea. Actualizările sunt trimise atunci cand apare o modificare în topologie, și contin doar informații despre rutele modificate. Spre deosebire de protocoalele bazate pe starea legăturilor, care trimit actualizări tuturor ruterelor din retea, EIGRP propaga actualizarea doar catre acelea care au nevoie de acea informatie. Toate acestea duc la un consum mai mic de lațime de bandă.
EIGRP folosește RTP ( reliable transport protocol) pentru trimiterea și receptionarea mesajelor. Deși numele ne spune ca acest protocol utilileaza numai livrări “sigure”, RTP ia in calcul și pe cele “nesigure” la fel ca in cazult TCP/UDP. Mai precis, atunci când se transmite un pachet, emițătorului i se răspunde cu un mesaj de confirmare (acknowledgement) în caz că pachetul a ajuns la destinație. Însă un pachet care nu a ajuns la destinație nu mai cere confirmare.
RTP trimite atât pachete unicast cât și multicast. Pachetele multicast sunt trimise către adresa rezervată 224.0.0.10 pentru IPv4 și FF02::A pentru IPv6.
CAPITOLUL 2.1 FORMATUL PACHETELOR EIGRP
Protocolul EIGRP folosește cinci tipuri de pachete, unele dintre ele fiind folosite în perechi. Mai poarta numele și de mesaje EIGRP. Acestea sunt:
HELLO packets
UPDATE packets
ACKNOWLEDGEMENT packets
QUERY packets
REPLY packets
Pachetele hello sunt folosite pentru a descoperi vecinii și a forma adiacențe cu aceștia. Acestea sunt trimise de către rutere la intervale fixe dar configurabile. Pachetele sunt trimise multicast la adresa 224.0.0.10 și nu sunt confirmate de către destinatie. În majoritatea rețelelor pachetele sunt trimise la fiecare 5 secunde, dar în rețelele multipunct, NBMA (nonbroadcast multiple acces) ca X25, Frame Relay sau interfețele ATM (asynchronus transfer mode) cu legături de acces T1 ( 1.544Mb/s) sau mai mici, pachetele hello sunt trimise unicast la fiecare 60 secunde
EIGRP folosește un hold timer (timp de așteptare) pentru a determina cât timp să aștepte până să primească următorul pachet de Hello. De regulă acest timp reprezintă de trei ori timpul intervalului de Hello ( 15 secunde) în majoritatea retelelor și 180 de secunde în cele de viteza mică NBMA. Dacă timpul de așteptare expiră, EIGRP declară acea ruta indisponibilă (down), iar algoritmul DUAL caută o noua rută de propagare.
Figura 2.1 Timpii de Hello și cei de Hold Times
Sursa:
Pachetele update sunt folosite pentru a propaga informațiile de rutare. Acestea nu trimit update-uri periodice și sunt trimise doar atunci când este necesar doar ruterelor care le cer. Aceste pachete sunt trimise în mod sigur, deoarece necesită confirmare din partea destinației. Pachetele sunt trimise multicast atunci când sunt cerute de mai multe rutere și unicast in cazul unuia singur.
Pachetele de acknowledgement sunt trimise pentru a confirma pachetele trimise în mod sigur.
În figura de mai jos ruterul 2 pierde conexiunea cu interfata Gigabit Ethernet.R2 trimite imediat update catre routerul 1 (R1) și routerul 3 (R3), notificand ruta indisponibila.R1 și R3 vor raspunde cu un mesaj de confirmare pentru a da de stire lui R2 că au recepționat update-ul.
Figura 2.2 Pachetele UPDATE/ ACKNOWLEDGEMENT
Sursa:
Pachetele query sunt folosite atunci când un ruter are nevoie de informații specifice de la vecinii sai. Pachetele de tip reply sunt folosite pentru a raspunde prin unicast la pachetele de tip query..
În figura de mai jos R2 pierde conexiunea LAN și interogheaza prin mesaje de tip query ceilalți vecini pentru a cauta o nouă rută. Toate ruterele trebuie sa raspundă ( mesaj de tip Reply) chiar daca au sau nu o rută catre rețeaua indisponibilă.
Figura 2.3 Pachetele de tip QUERY/REPLY
Sursa:
CAPITOLUL 2.2 TABELELE EIGRP
Protocolul EIGRP este constituit din 3 tabele de rutare: tabela cu vecinii, tabela de topologie, și tabela de rutare. Tabela cu vecini conține informații despre ruterele adiacente. Tabela de topologie conține toate căile din rețea. Cele mai bune căi din tabela de topologie sunt introduse în tabela de rutare
Când un ruter descoperă și formează o adiacența cu un vecin nou, introduce în tabela cu vecini adresa și interfața pe care vecinul poate fi accesat. Tabela cu vecini este asemănătoare tabelei de adiacență a protocoalelor de rutare bazate pe starea conexiunii, deoarece asigură comunicația bidirecțională între vecinii direct conectați. Mai jos putem vedea un exemplu de tabela cu vecinii de pe un ruter folosind comanda: show ip eigrp neighbors
Figura 2.4 Tabela cu vecinii EIGRP
Atunci când ruterul stabilește legătura de adiacență cu un nou vecin, îi va trimite un pachet update cu rutele pe care le cunoaște. Noul vecin de asemenea îi va trimite rutele cunoscute de el. Aceste informații sunt introduse în tabela de topologie, care va conține toate rutele anunțate de către ruterele adiacente. Este importantă de observat că vor fi anunțate doar rutele care apar în tabela de rutare aceasta fiind o caracteristica specifică protocoalelor de rutare bazate pe vectori-distanță. În tabela de topologie este stocată distanța raportată și distanța viabilă pentru fiecare rută în parte. Tabela de topologie se modifică doar atunci cand o ruta direct conectată sau o interfață se schimbă, sau când un vecin anunță o modificare a unei rute. Mai jos putem vedea un exemplu de tabela de topologie folosind comanda: show ip eigrp topology.
Figura 2.5 Tabela cu topologia EIGRP
Ruterul compară toate distanțele viabile pentru o anumită destinație și selectează ruta cu cea mai mică distanță viabilă. Această rută de cost minim va fi plasată în tabela de rutare. Distanța viabilă a acestei rute devine metrica EIGRP pentru destinația respectivă. Mai jos avem un exemplu de tabelă de rutare folosind comanda: show ip route
Figura 2.6 Tabela rutare EIGRP
CAPITOLUL 2.3 CALCULUL METRICII EIGRP
EIGRP folosește următorii parametrii pentru a calcula cea mai bună rută către o anumită destinație. Aceștia sunt:
Bandwidth (lățimea de bandă) – cea mai mică lățime de bandă de la sursa la destinație
Delay (întârzierea) – se referă la totalitatea întârzierilor de la sursa la destinație
Reliability (siguranta) – se referă la nivelul de încredere spre calea către destinație, fiind estimat prin schimbul de mesaje keepalive. Acestea reprezintă mesaje care sunt trimise de la un dispozitiv către altul pentru a verifica dacă legătura dintre ele este operabilă.
Load (incărcarea) – se referă la cel mai scăzut timp de încărcare de la sursă la destinație, bazat pe rata pachetelor și pe lățimea de bandă configurată
Formula pentru calculul metricii este:
Metrica = 256 x [k1 x Bandwidth + ( k2 x Bandwidth ) / ( 256 – Load) + K3 x Delay ] x [ k5/(Relibality + k4)]
Formula este formata din valori K, respectiv de la K1 la K5, cunoscute ca fiind folosite în metrica EIGRP. K1 reprezintă bandwidth iar K3 delay. K2 reprezintă loadu-ul iar k4 și K5 Reliability. De regula, K1 și K3 sunt setate ca având valoarea 1, iar k2, k4 și k5 având valoarea 0. De aici rezultă că numai banda și întârzierea sunt folosite în calculul metricii EIGRP
Metrica = [ k1 x Bandwidth + k3 x Delay ] x 256
Pentru a verifica valorile k pe un ruter se foloseste comanda: show ip protocols, după cum putem vedea mai jos un exemplu:
Figura 2.7 Verificare valori K
În cazul în care există diferite căi cu un cost egal către o destinație dată, EIGRP este capabil să efectueze implicit load balacing (echilibrarea traficului). Procesul de load balacing conduce la folosirea tuturor rutelor către aceeași destinație și creste lățimea de bandă efectivă. O caracteristică importantă este faptul că poate echilibra traficul pe mai multe rute de cost diferit, tinând cont de o valoare a variației acceptabile a metricilor folosite în procesul de load balacing.
CAPITOLUL 2.4 ALGORITMUL DUAL
EIGRP foloseste Diffusing Udate Algorithm (DUAL), care permite ruterului sa identifice rute care nu conțin bucle. Privit ca un protocol distance-vector, EIGRP însotit de acest algoritm vine cu noutăți care nu se regăsesc în tradiționalele protocoale de rutare distance-vector ca RIP sau IGRP, cum ar fi ca nu trimite actualizări periodice, ci numai schimbări care țin de rutare, ca indisponibilitatea unei legături.
Algoritmul DUAL menține o tabelă de topologie separată de tabela de rutare, care include atăt calea către rețeaua destinație cât și calea de rezervă, pe care algoritmul a stabilit că nu conține bucle.
Pentru a descrie acest algoritm sunt folosiți următorii termeni:
Successor (Succesor)
FD – Feasible Distance (Distanță fezabila)
FS – Feasible Succesor (Succesor fezabil)
RD – Reported Distance (Distanță raportată)
FC – Feasible Condition (Conditie de fezabilitate)
Acești termeni și concepte reprezintă cele mai importante lucruri pentu evitarea buclelor de rețea.
Succesorul este acel ruter prin care se ajunge la destinație. Adresa IP a acestuia se observă în tabela de rutare dupa cuvântul <<via>> după cum putea vedea mai jos:
Distanța fezabilă este cea mai mică metrica calculată pentru a atinge rețeaua destinație. FD este listată tot în tabela de rutare, fiind al doilea număr din succesiunea de numere din paranteze.
Unul din motivele pentru care algoritmul DUAL converge foarte rapid in urma unei schimbări în topologia rețelei este acela că folosește căile de rezervă către alte rutere cunoscute ca succesori fezabili, nemaifiind nevoie de a recompila algoritmul. Un succesor fezabil este un ruter vecin care are o cale de rezerva fără buclă către aceeași rețea ca succesorul, dar satisfacand în cele din urmă condiția de fezabilitate. Condiția de fezabilitate e întâlnita atunci când distanța de raportare a unui ruter vecin catre o rețea, este mai mică decât distanța fezabilă a ruterului local catre aceeași rețea, iar distanța de raportare este practic o distanță de fezabilitate către aceeași rețea destinație.
Figura 2.8 Tabela EIGRP.Succesori.Distanță fezabila
CAPITOLUL 2.5 SCALABILITATEA EIGRP ÎN REȚELELE MARI
EIGRP este un protocol scalabil fiindcă, odată cu creșterea în dimensiune a rețelei, performanța nu se diminueaza și procesul se ajustează rapid la schimbări.Protocolul oferă soluții pentru asigurarea scalabilității în rețelele mari, de exemplu prin folosirea rutelor stub pentru a limita domeniul în care se trimit pachete de tip query.
Următorii factori pot afecta scalabilitatea unei rețele: cantitatea de informație schimbată între rutere, numărul de rutere, adâncimea topologiei, și numărul de căi alternative prin rețea. Cu căt crește cantitatea de informație, cu atât ruterele trebuie să trimită mai multă informație atunci când apare un vecin nou sau atunci când apar schimbări în topologie. Consumul de resurse pe un ruter este legat direct
de numărul de rutere aflate în acea rețea.
O rețea ar trebui să ofere căi alternative pentru a nu exista riscul unui punct singular de eșec (single point of failure). În cazul în care o rută devine nevalidă, va trebui gasită o cale alternativă pentru acea destinație. Ruta intră în starea activă și ruterul trimite pachete de tip query către toți vecinii sai, în afară de vecinul prin care trecea ruta declarată nevalidă, întreband dacă există o rută către destinația specificată. Dacă vecinul care a primit un query are o rută alternativă, va trimite un pachet reply, conținând ruta. Dacă vecinul nu are nicio rută către destinație, atunci trimite pachete query la toți vecinii săi întrebând de o cale alternativă. Astfel pachetele de tip query se propagă prin rețea formând un arbore de cereri. Când un ruter are o rută alternativă oprește proapagarea pachetelor pentru ramura respectivă.
CAPITOLUL 2.6 AUTENTIFICAREA EIGRP
Pentru a garanta sursa informațiilor pe care le primește un ruter EIGRP, protocolul permite autentificarea vecinilor înainte de a schimba informații de rutare cu aceștia. Protocolul EIGRP suportă două tipuri de autentificare: parole simple și MD5. Parolele simple sunt trimise în clar și potrivite cu cheia destinatarului. Ele nu ofera siguranță, deoarece oricine poate captura traficul are acces și la această cheie.
Dat fiind că parolele simple nu sunt potrivite pentru securizarea comunicației, se recomandă folosirea parolelor criptate prin MD5. Cheile criptate cu MD5 sunt sigure deoarece din traficul capturat nu se poate obține cheia inițială.
Folosind o cheie criptată în fiecare pachet, EIGRP nu acceptă informații false și neautorizate. Pentru autentificarea prin MD5, un identificator de cheie și o cheie de autentificare trebuie specificate pentru ambele rutere care comunică.
CAPITOLUL 3
STUDIU DE CAZ
SIMULAREA SI COMPAREA PROTOCOALELOR DE RETEA OSPF SI EIGRP
Pentru a compara cele două protocoale de rețea, am folosit ca software un simulator numit GNS3. Am ales ca mod de lucru două tipuri de topologii: o topologie de mărime mică incluzând 6 rutere și una de mărime medie având 30 de rutere, pe ambele fiind configurate ambele protocoale de rutare. Prin urmare, voi explica modul cum au fost configurare ruterele și modul de funcționare al acestora. Apoi la diverse modificări de topologie voi demonstra eficiența și performanțele acestor protocoale.
CAPITOLUL 3.1. PREZENTAREA SIMULATORULUI GNS3
GNS3 este un simulator gratuit (www.gns3.net), folosit pentru a simula funcționarea și configurarea routerelor CISCO. El poate fi rulat pe platforme precum Windows, Mac OS X sau Linux. Ideea de bază a programului este de a încărca IOS-urile corespunzătoare unui număr limitat de serii de routere CISCO în memoria RAM a calculatorului, transformându-l pe acesta într-un router (sau chiar o rețea de routere) veritabil.
Software-ul folosit de routerele CISCO se numeste CISCO IOS (Internetwork Operating System), având, ca și routerele, numeroase versiuni diferențiate prin unele proprietăți. Aceste IOS-uri se încarcă în memoria volatilă a routerelor de fiecare dată când acestea sunt pornite. Ele se află arhivate pe memoria Flash disponibilă routerului.
Fereastra principală a simulatorului este împărțită în trei părți. În partea stângă se afișază seriile de routere disponibile în simulator. La ruterele propriu-zise mai pot fi adăugate manual, pentru acuratețea simulărilor, și alte dispozitive de rețea: switchuri Ethernet și ATM, firewall, calculatoare (stații de lucru) etc.
În fereastra din mijloc se afișază topologia rețelei simulate. Elementele de rețea se aduc în această fereastră cu printr-o operație de "drag and drop" cu ajutorul mouse-ului. Între elementele de rețea se pot configura, tot cu ajutorul mouseului și legături de diverse tipuri (Ethernet, Fast Ethernet, Serial etc). Fereastra din dreapta a interfeței grafice ne oferă, într-un format arbore, o descriere sumară a topologiei rețelei.
În captura de mai jos este reprezentată topologia de 6 rutere în care ruleaza unul din cele două protocoloale de rutare
Figura 3.1 Fereastra de lucru GNS3
Încărcarea și rularea imaginilor IOS consumă din plin resursele PC-ului pe care se află instalat simulatorul. Pentru a rezolva aceste probleme, am instalat masina virtuală ( GNS3 VMware), care este parte integrată din simulatorul GNS3. Mașina virtuală rulează odată cu pornirea GNS3 și folosește Linux ca sistem de operare. Câteva dintre avantajele de a rula GNS3 pe masina virtuală este că funcționează
separat față de PC asigurând o mai bună stabilitate și control asupra CPU și al memoriei.
CAPITOLUL 3.2 CONFIGURAREA UNUI RUTER CISCO – COMENZI BAZĂ
Routerele CISCO pot fi configurate în două feluri, folosind două interfețe diferite cu utilizatorul: prin linia de comandă (CLI – Command Line Interface), sau în modul grafic (GUI – Graphical User Interface). Deși configurarea prin GUI este mai simplă, majoritatea celor care efectuază aplicații practice pe routerele Cisco folosește CLI, deoarece această modalitate oferă o gamă mult mai mare de opțiuni de configurare și permite un mod de lucru mult mai meticulos. În cazul de față vom folosi CLI, singura opțiune valabilă prin intermediul simulatorului GNS3.
După pornirea ruterului, acesta efectuează un set de teste numit POST (Power-On Self Test) prin care verifică din punct de vedere electronic starea fiecărui bloc component. După POST, se încarcă sistemul de operare (IOS-ul) în memoria RAM, apoi începe un ”dialog” cu utilizatorul. În simulator, aceste teste sunt inițiate odată cu lansarea comenzii de Console.
În cazul de față vom alege răspunsul No la întrebarea Would you like to enter the initial configuration dialog? După apasarea tastei Enter avem la dispoziție 4 moduri de lucru:
User EXEC
Privileged EXEC
Configurare globala
Sub-configurare
Primul mod întâlnit este întotdeauna User EXEC. Acest mod oferă un număr restrâns de comenzi pe care poate să le folosească utilizatorul, comenzi ce se referă mai ales la detalii ce nu prezintă un risc în securitatea routerului sau a rețelei din care face parte. Comenzile disponibile (în orice mod) se pot vizualiza apasând tasta “?” la începutul fiecărei linii. Acest mod se remarcă prin apariția prompter-ului Router> la începutul fiecărei linii, unde Router reprezintă numele routerului.
Modul Privileged EXEC reprezintă modul în care se efectuează toată configurarea, indiferent de drepturile ulitizatorului, fiind disponibile toate detaliile deja configurate, precum și toate comenzile sau proprietățile routerelor (interfețe, routare statică sau dinamică, setare de parole sau telnet, etc). Acest mod se activeză cu comanda: Router> enable. Prompter-ul se va schimba în Router#. În acest mod se pot vizualiza o serie de tabele folosite foarte des de utilizatori:
Configurația salvată (dacă există): Router# show startup-config
Configurația curentă: Router# show running-config
Starea interfețelor: Router# show ip interface
Tabela de rutare: Router# show ip route
Alte tabele sau configurații care se pot vedea plasând caracterul "?" dupa comanda show: Router# show ?
Modul Configurare globală poate fi accesat numai din modul User EXEC cu comanda: Router#configure terminal. Dupa introducerea comenzii prompter-ul se va schimba în: Router(config)#
Ieșirea dintr-un anumit mod se poate face în 3 feluri:
Comanda END – duce la modul precedent
Comanda EXIT – duce la modul Privileged EXEC (Router#)
CTRL + Z – același efect ca și cea precedentă.
CAPITOLUL 3.3 PREZENTAREA TOPOLOGIILOR SI ADRESAREA IP
Pentru rețeaua de mărime mică am ales un numar de 6 rutere după cum se poate observa în topologia de mai jos.
Figura 3.2 Prezentare topologie 6 rutere
În continuare atașez adresarea IP pentru topologia de mai sus:
Tabelul 3.1 Adresare IP
Pentru rețeaua de mărime medie am ales un numar de 30 de rutere, după cum putem vedea în captura de mai jos
Figura 3.3 Prezentare topologie 30 rutere
Ca și în cazul anterior, voi prezenta adresarea IP
Tabel 3.2 Adresare IP
Pentru a configura aceste interfețe pe un ruter am procedat astfel: vom lua de exemplu ruterul numit A1R4, pe care il selectăm cu mous-ul apoi click dreapta pentru a selecta consola acestuia, de unde se va incepe configurarea propriu-zisă. Ruterul are 4 interfețe configurate: o interfață ethernet, două interfețe Seriale și una de loopback. Interfața ethernet este cea conectată la PC, iar cele două seriale fac legatura între cele două rutere vecine respectiv A1R3 și A1R5. Interfața de loopback este interfața virtuală, creată în software de către sistemul de operare care nu are nicio componentă hardware asociată dar care poate fi configurată cu adresa IP ca și interfețele fizice. Ele sunt create îndeosebi în procesele de testare ale rețelelor și protocoalelor.
Mai jos se poate observa modul de configurare
Figura 3.4 Configurarea interfetelor pe un ruter
Pentru a putea vedea interfețele de pe un ruter se poate folosi comanda #show ip interface brief care arată numărul interfețelor, precum și starea acestora.
Figura 3.5 Starea interfetelor unui ruter
CAPITOLUL 3.4 CONFIGURAREA PROTOCOLULUI OSPF
Figura 3.6 Configurare OSPF
Anterior am configurat protocolul OSPF pe un ruter. În primul rând se configurează interfețele pe care va fi activat procesul OSPF. Am ales ruterul A1R4 aflat în topologia cu 30 de rutere. Celelalte rutere vor fi configurate similar conform acestuia și adresarii IP corespunzătoare prezentate mai sus. În primul rând se alege un process ID. Process-id este un număr intre 1 si 65535, de unde am ales ca fiind 1. Se utilizează comanda router ospf process-id.
Apoi trebuie ales Router-ID-ul necesar identificării unice a ruterului în domeniul de rutare OSPF. L-am ales ca fiind același cu interfața de loopback, anume 192.168.1.4. După care alegem idenitificatorul de zonă sau area-id, care se referă la aria (zona) OSPF. O rețea OSPF poate fi structurată pe mai multe arii după cum putem vedea în figura 3.3. Topologia este împărțită în 6 arii, cea din mijloc reprezentând aria 0 (backbone). Pentru usurința am notat numele fiecărui ruter sugestiv. De exemplu la ruterul A1R4, A1 reprezintă numărul ariei și R4 numărul ruterului. Această “regula” se aplică și celorlalte rutere din rețea. Când toate ruterele se află în aceeași arie OSPF, comenzile de rețea trebuie să fie configurate cu același area-id pe toate ruterele așa cum putem vedea in figura 3.2. Apoi am configurat timpii de Hello si Dead interval, setând cele mai mici valori pentru o mai bună convergență. Timpul de hello inseamnă cât de des se trimit pachete hello iar timpul dead reprezintă cât timp să aștepte un ruter pachetele hello înainte să declare vecinul ( adiacența) indisponibil.
Pentru a demonstra că protocolul a fost configurat corect folosim cateva comenzi:
-# sh ip ospf neighbours ( indica adiacentele cu vecinii)
-#sh ip protocols( indica protocolul activ)
Figura 3.7 Protocol OSPF
Figura 3.8 Adiacenta OSPF
După cum se poate observa apar cei 2 vecini în procesul OSPF, însemnând ruterele A1R3 și A1R5.
CAPITOLUL 3.5 CONFIGURAREA PROTOCOLULUI EIGRP
Pentru a configura protocolul de rutare EIGRP este necesară parcurgerea următorilor pași:
1. Activarea procesului EIGRP și specificarea unui număr de sistem autonom. Cel mai adesea el nu are o legatură directă cu numărul sistemului autonom din care face parte ruterul, singura constrângere fiind că aceeași valoare să fie configurată pe fiecare dintre ruterele din cadrul rețelei EIGRP. Am ales această valoare 1. Se configureaza cu comanda Router(config)#router eigrp number_AS.
2. Alegerea unui Router-ID. L-am ales ca fiind același cu interfața de loopback : 192.164.1.4
3. Configurarea interfețelor
4. Specificarea rețelelor care fac parte din sistemul autonom. Această comandă indică ce interfețe participă la rutarea prin EIGRP și ce rețele sunt anunțate de către ruter. Acest lucru se realizează cu comanda: Router(config-router)#network rețea [masca_wildcard]. Masca poate fi specificată pentru a identifica anumite subrețele ale unei clase de rețea și poate fi introdusă în formatul invers sau în formatul normal de mască de rețea.
5. Apoi am setat timpii de Hello si hold-time interval, setând cele mai mici valori. Timpul de hello înseamnă cât de des se trimit pachete hello iar timpul dead reprezintă cât timp să aștepte un ruter pachetele de hello înainte să declare vecinul ( adiacența) indisponibil. Setarea acestor timeri la parametrii mici face timpul de convergență să fie mai rapid
În figura de mai jos este reprezentat practic ceea ce am descris anterior
Figura 3.9 Configurare EIGRP
În cazul de față folosim aceleași comenzi ca și la OSPF pentru a demonstra că protocolul EIGRP a fost configurat corect și este activ pe rutere:
-# sh ip ospf neighbours ( indica adiacentele cu vecinii)
-#sh ip protocols( indica protocolul activ)
Figura 3.10 Verificare Protocol EIGRP
CAPITOLUL 3.6 REDUNDANȚA OSPF/EIGRP
Algoritmul Dijkstra sau SPF este responsabil pentru redundanța în OSPF. Mai precis, ruterele sunt ierarhizate conform acestui algoritm, fiind selectată ruta cu costul cel mai redus către destinatie. Calculul presupune, având drept sistem de referință ruterul respectiv, adunarea costurilor de pe interfețele de iesire către acel nod/link.
Pe ruterele Cisco costul se calculează folosind formula BW de referinta / BW interfeței. Banda de referință are valoarea de 100Mbps. De exemplu în cazul unei legaturi Ethernet de 10Mbps, costul OSPF ( 100Mbps/10Mbps) va fi 10.
Mai jos sunt prezentate costurile în cazul diferitelor interfețe și de banda aferenta acestora:
Tabel 3.3 OSPF Cost
EIGRP folosește următorii parametrii pentru a calcula cea mai bună rută către o anumită destinație. Aceștia sunt:
Bandwidth (lățimea de bandă) – cea mai mică lățime de bandă de la sursa la destinație
Delay (întârzierea) – se referă la totalitatea întârzierilor de la sursa la destinație
Reliability (siguranța) – se referă la nivelul de încredere spre calea către destinație, fiind estimat prin schimbul de mesaje keepalive. Acestea reprezintă mesaje care sunt trimise de la un dispozitiv către altul pentru a verifica dacă legătura dintre ele este operabilă.
Load (incărcarea) – se referă la cel mai scăzut timp de încărcare de la sursă la destinație, bazat pe rata pachetelor și pe lățimea de bandă configurată
Formula pentru calculul metricii este:
Metrica = 256 x [k1 x Bandwidth + ( k2 x Bandwidth ) / ( 256 – Load) + K3 x Delay ] x [ k5/(Relibality + k4)]
Formula este formată din valori K, respectiv de la K1 la K5, cunoscute ca fiind folosite în metrica EIGRP. K1 reprezintă bandwidth iar K3 delay. K2 reprezintă loadu-ul iar k4 și K5 Reliability. De regula, K1 și K3 sunt setate ca având valoarea 1, iar k2, k4 și k5 având valoarea 0. De aici rezultă că numai banda și întârzierea sunt folosite în calculul metricii EIGRP
Metrica = [ k1 x Bandwidth + k3 x Delay ] x 256
Pentru a seta o rută preferată, Cisco recomandă a se modifica valoarea parametrului delay (intârzierea). Ruterele ale căror interfețe au valoarea cea mai mică a acestui parametru reprezintă calea principală către destinație.
Tabel 3.4 Eigrp delay
În continuare am să prezint cum am modificat metrica OSPF/EIGRP în cadrul topologiei de 6 rutere, alegând o rută principală și una de rezervă (backup). În cazul OSPF acest lucru se face cu comanda: Router(config-if)# ip ospf cost <nr> // între 1 și 6553, iar la EIGRP: Router(config-if)#delay <nr>. Aceste comenzi vor fi folosite pe acele interfețe ale ruterelor pe care dorim să prioritizăm traficul. Interfețele cu costul cel mai mic este favorit. În topologia noastră am modificat costurile în asa fel încât traficul generat de la PC, la ruterul A0R4 să urmeze urmatorul traseu: A0R1-A0R2-A0R3-A0R4. Mai precis, pe interfețele seriale ale acestor rutere am setat costul ca fiind 100 iar pe celelalte 200 în cazul OSPF, iar la EIGRP am setat delay-ul ( întârzierea) la valoarea de 19000 usec, celelalte rutere având valoarea 20000 usec
Figura 3.11 Cost OSPF
Figura 3.12 Eigrp delay
Figura 3.13 Ruta catre ruterul A0R4
În primul rând, pentru a demonstra că topologia și implicit protocoalele OSPF/EIGRP sunt funcționale, vom verifica dacă se stabilește conexiunea între PC și un ruter oarecare. Voi alege ruterul A0R4. Din ferestra de Command prompt a PC-ului vom folosi comanda PING către adresa de loopback a ruterului și după cum se observă, conexiunea este stabilită.
Figura 3.14 Conectivitate cu ruterul A0R4
În continuare folosim comanda tracert 192.168.1.4 (A0R4), pentru a demonstra că pachetele trimise de pe PC urmează traseul stabilit în urma setării costurilor despre care am discutat anterior.
Figura 3.15 Ruta catre A0R4
Observăm că rutarea a avut succces și ruta a fost cea pe care am stabilit-o. În continuare pentru a demonstra că protocoalele oferă redundanță, oprim o legatură (link) dintre două rutere. Astfel protocolul va reruta pachetele folosind altă rută către destinație. Voi pune în starea shutdown legătura dintre A0R2 și A0R3: Seriala 2/0 de pe A0R2.
Figura 3.16 Intrerupere interfata OSPF
Figura 3.17 Intrerupere interfata EIGRP
Figura 3.18 Intrerupere link
Vom refolosi din nou comanda tracert 192.168.1.4 din CMD pentru a observa ce se intampla:
Figura 3.19 Ruta catre ruterul A0R4
Putem observa că în urma procedurii anterioare calea precedentă a devenit indisponibilă, protocolul optând pentru calea de rezervă către destinatie și anume prin ruterele A0R1-A0R6-A0R5-A0R4. Altfel spus avem redundanță
Figura 3.20 Redundanță OSPF/EIGRP
Similar am procedat și în cadrul topologiei medii de 30 de rutere. Ruta principală pentru care am optat este prin ruterele A1R4-A1R3-A1R2-A1R1-A5R1-A4R1-A4R2-A4R3-A4R4. Prin urmare, în cazul OSPF pe sensul interfețelor către aceste rutere am setat un cost de 60, restul ruterelor din topologie având 64, iar la EIGRP am setat delay ( întârzierea) 19000 usec, restul având valoarea de 20000 usec. Și de această dată am întrerupt o legatură de pe un ruter pentru a verifica redundanța și anume seriala3/1 de pe ruterul A5R1 care face legătura cu A4R1. Pentru moment verificăm funcționalitatea rețelei și implicit a protocolului folosind comanda PING câtre un ruter destinație: A4R4. Vom observa ca avem conectivitate.
Figura 3.21 Conexiune PC-ruter
Figura 3.22 Ruta OSPF/EIGRP
Înainte de a întrerupe legătura de pe ruterul A5R1, folosim comanda tracert 192.168.4.4 ( adresa loopback a ruterului A4R4) pentru a demonstra că pachetele trasnmise de pe PC urmează calea care am prestabilit-o anterior
Figura 3.23 Ruta catre ruterul A4R4
În continuare vom întrerupe interfața Serial3/1 de pe A5R1
Figura 3.24 Intrerupere interfata OSPF
Figura 3.25 Intrerupere interfata EIGRP
În urma acestei operațiuni folosim din nou comanda tracert 192.168.4.4
Figura 3.26 Ruta alternativa catre A4R4
Observăm că acum calea urmată este prin: A1R4-A1R3-A1R2-A1R1-A2R1-A3R1-A4R1-A4R2-A4R3-A4R4
Figura 3.27 Redundanta OSPF/EIGRP
CAPITOLUL 3.7 CONVERGENȚA OSPF ȘI VOLUMUL DE DATE TRANSMIS ATUNCI CÂND APAR MODFICARI ÎN TOPOLOGIE
Timpul de convergență definește cât de repede routerele din topologia de rețea partajează informația de rutare și ajung la o stare de cunoștințe coerenta, despre topologia rețelei. Cu cât este mai rapidă convergența, cu atât este mai preferabil protocolul.
În continuare voi demonstra cât de rapid se adaptează protocolul de rutare OSPF atunci când apare o schimbare în topologia rețelei și cum ruterele fac schimb de informații de rutare.
În cadrul rețelei cu 6 rutere, vom genera trafic de pachete icmp folosind comanda ping de pe PC către ruterul A0R4 folosit ca destinație
Figura 3.28 Generare trafic
Apoi voi întrerupe legătura dintre ruterul A0R3 si A0R4, mai exact interfața seriala2/0 de pe ruterul A0R3
Figura 3.29 Intrerupere link
Accesăm consola ruterului A0R3 și punem interfata Seriala2/0 în starea down
Enter configuration commands, one per line. End with CNTL/Z.
A0R3(config)#int se 2/0
A0R3(config-if)#shutdown
A0R3(config-if)#
May 9 2016 23:01:00.806 EET: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.4 on Serial2/0 from FULL to DOWN, Neighbor Down: Interface down or detached
A0R3(config-if)#
May 9 2016 23:01:02.807 EET: %LINK-5-CHANGED: Interface Serial2/0, changed state to administratively down
May 9 2016 23:01:03.813 EET: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0, changed state to down
A0R3(config-if)#
De reținut momentul la care am pus interfața în starea shutdown:
May 9 2016 23:01:00.806 EET: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.4 on Serial2/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Figura 3.30 Numar de pachete icmp pierdute
Observăm că în urma întreruperii s-au transmis un număr de 237 de pachete dintre care s-au recepționat doar 225. Prin urmare s-au pierdut 12 pachete.
În continuare pentru a determina timpul de convergență de pe rutere am procedat astfel: pe ruterele A0R1 (ruterul sursă la care este conectată interfata LAN) și A0R4 (ruterul destinatie) am folosit comanda Router#debug ip routing. Această comandă ne oferă informații despre actualizări ale protocolului de rutare. Debugging-ul reprezintă defapt un proces de depanare ale unor defecte care țin de mediul de programare sau de echipamentul folosit.
A0R1#debug ip routing
IP routing debugging is on
A0R1#
May 9 2016 23:01:01.344 EET: RT: updating ospf 192.168.1.4/32 (0x0) :
via 10.1.16.6 Se2/1 0
May 9 2016 23:01:01.344 EET: RT: closer admin distance for 192.168.1.4, flushing 1 routes
May 9 2016 23:01:01.344 EET: RT: add 192.168.1.4/32 via 10.1.16.6, ospf metric [110/601]
May 9 2016 23:01:01.344 EET: RT: updating ospf 10.1.45.0/29 (0x0) :
via 10.1.16.6 Se2/1 0
May 9 2016 23:01:01.344 EET: RT: closer admin distance for 10.1.45.0, flushing 1 routes
May 9 2016 23:01:01.344 EET: RT: add 10.1.45.0/29 via 10.1.16.6, ospf metric [110/600]
May 9 2016 23:01:01.344 EET: RT: updating ospf 10.1.34.0/29 (0x0) :
via 10.1.16.6 Se2/1 0
A0R1#
May 9 2016 23:01:01.344 EET: RT: closer admin distance for 10.1.34.0, flushing 1 routes
May 9 2016 23:01:01.344 EET: RT: add 10.1.34.0/29 via 10.1.16.6, ospf metric [110/700]
A0R1#
May 9 2016 23:01:30.776 EET: RT: del 10.1.34.0 via 10.1.16.6, ospf metric [110/700]
May 9 2016 23:01:30.776 EET: RT: delete subnet route to 10.1.34.0/29
A0R1#
Observăm cum ruterele, atunci când detectează o schimbare de topologie, fac schimb de informații și mesaje de rutare anunțând ruterele vecine despre modificare prin intermediul protocolului OSPF
Dintre informațiile și rutele furnizate mai sus, ne interesează actualizările despre adresa IP a ruterului destinație A0R4 respectiv 192.168.1.4. Constatăm că timpul la care s-a facut actualizarea este 23:01:01.344. În comparație cu timpul la care am întrerupt legătura dintre ruterele A0R3 și A0R4, 23:01:00.806, propagarea rutei a fost foarte rapidă, mai precis de 538 msec
May 9 2016 23:01:01.344 EET: RT: updating ospf 192.168.1.4/32 (0x0) :
via 10.1.16.6 Se2/1 0
În continuare vom analiza debug-ul de pe A0R4 și ne vom cauta actualizarea în care este prezentă ruta de la ruterul A0R1: 192.16856.0
A0R4#debug ip routing
IP routing debugging is on
A0R4#
May 9 2016 23:01:01.362 EET: RT: updating ospf 192.168.1.3/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 9 2016 23:01:01.362 EET: RT: closer admin distance for 192.168.1.3, flushing 1 routes
May 9 2016 23:01:01.362 EET: RT: add 192.168.1.3/32 via 10.1.45.5, ospf metric [110/801]
May 9 2016 23:01:01.362 EET: RT: updating ospf 192.168.1.2/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 9 2016 23:01:01.362 EET: RT: closer admin distance for 192.168.1.2, flushing 1 routes
May 9 2016 23:01:01.362 EET: RT: add 192.168.1.2/32 via 10.1.45.5, ospf metric [110/701]
May 9 2016 23:01:01.362 EET: RT: updating ospf 192.168.1.1/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 9 2016 23:01:01.362 EET: RT: closer admin distance for 192.168.1.1, flushing 1 routes
May 9 2016 23:01:01.362 EET: RT: add 192.168.1.1/32 via 10.1.45.5, ospf metric [110/601]
May 9 2016 23:01:01.363 EET: RT: updating ospf 192.168.56.0/24 (0x0) :
via 10.1.45.5 Se2/0 0
May 9 2016 23:01:01.363 EET: RT: closer admin distance for 192.168.56.0, flushing 1 routes
May 9 2016 23:01:01.363 EET: RT: add 192.168.56.0/24 via 10.1.45.5, ospf metric [110/610]
May 9 2016 23:01:01.363 EET: RT: updating ospf 10.1.23.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 9 2016 23:01:01.363 EET: RT: closer admin distance for 10.1.23.0, flushing 1 routes
A0R4#
May 9 2016 23:01:01.363 EET: RT: add 10.1.23.0/29 via 10.1.45.5, ospf metric [110/800]
May 9 2016 23:01:01.363 EET: RT: updating ospf 10.1.16.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 9 2016 23:01:01.363 EET: RT: closer admin distance for 10.1.16.0, flushing 1 routes
May 9 2016 23:01:01.363 EET: RT: add 10.1.16.0/29 via 10.1.45.5, ospf metric [110/600]
May 9 2016 23:01:01.363 EET: RT: updating ospf 10.1.12.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 9 2016 23:01:01.363 EET: RT: closer admin distance for 10.1.12.0, flushing 1 routes
May 9 2016 23:01:01.363 EET: RT: add 10.1.12.0/29 via 10.1.45.5, ospf metric [110/700]
A0R4#
May 9 2016 23:01:03.360 EET: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.3 on Serial2/1 from FULL to DOWN, Neighbor Down: Dead timer expired
A0R4#
May 9 2016 23:01:30.220 EET: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/1, changed state to down
A0R4#
May 9 2016 23:01:30.220 EET: is_up: Serial2/1 0 state: 4 sub state: 1 line: 0
May 9 2016 23:01:30.221 EET: RT: interface Serial2/1 removed from routing table
May 9 2016 23:01:30.221 EET: RT: del 10.1.34.0 via 0.0.0.0, connected metric [0/0]
May 9 2016 23:01:30.221 EET: RT: delete subnet route to 10.1.34.0/29
May 9 2016 23:01:30.221 EET: RT: del 10.1.34.4 via 0.0.0.0, connected metric [0/0]
May 9 2016 23:01:30.221 EET: RT: delete subnet route to 10.1.34.4/32
A0R4#
Să recapitulăm:
Timpul când am întrerupt interfața de pe ruterul A0R3: 23:01:00.806
Timpul la care ruterul A0R1 (sursa) a primit actualizări referitoare la ruterul A0R4 (destinație) : 23:01:01.344
Timpul la care ruterul A0R4 (destinație) a primit actualizări referitoare la ruterul A0R1 (sursa) : 23:01:01.363
Pentru a calcula timpul de convergență scădem din timpul la care ruterul A0R4 (destinația) a primit actualizări, timpul la care am întrerupt interfața de pe ruterul A0R3:
23:01:01.363-23:01:00.806= 557
O altă modalitate de a afla timpul de convergență a fost cu ajutorul analizorului de rețea Wireshark
Figura 3.31 Captura pachete Wireshark
Wireshark este cel ma popular analizor de rețea din lume. Această unealtă foarte puternică furnizează informații despre datele capturate în rețea și în straturile superioare ale protocoalelor. Astfel, în timp ce am folosit comanda PING 192.168.1.4 de pe PC și am întrerupt conexiunea între rutere, am urmarit ce se intamplă cu pachetele transmise în rețea cu ajutorul acestui analizor. După cum stim Ping trimte mesaje ICMP “echo request” (în românește solicitare de răspuns) prin pachete adresate host-ului vizat și așteaptă răspunsul la aceste mesaje venite sub formă de răspunsuri ICMP “echo reply” de la hostul destinație. Remarcăm că atunci când am întrerupt conexiunea, nu s-au mai trimis mesaje “echo reply” din partea ruterului A0R4 ( 192.168.1.1.4) timp de 594 msec. Acesta reprezintă timpul de convergență al ruterelor.
23:01:01:794-23:01:01:200=594
Pentru determinarea timpului de convergență în cazul rețelei medii de 30 de rutere am procedat similar ca în cadrul topologiei de mai sus.
Vom folosi comanda ping de la PC către ruterul A4R4. (192.168.4.4) pentru a genera trafic
Figura 3.32 Ping 192.168.4.4
După care voi întrerupe legătura serială de pe ruterul A1R1 (Se3/1), cea care face conexiunea cu ruterul A5R1
Figura 3.33 Intrerupere link catre A4R3
A1R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
A1R1(config)#int se 3/1
A1R1(config-if)#sh
A1R1(config-if)#
May 11 2016 01:20:57.968 EET: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.5.1 on Serial3/1 from FULL to DOWN, Neighbor Down: Interface down or detached
A1R1(config-if)#
May 11 2016 01:20:59.971 EET: %LINK-5-CHANGED: Interface Serial3/1, changed state to administratively down
May 11 2016 01:21:00.980 EET: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/1, changed state to down
A1R1(config-if)#
Figura 3.34 Pachete icmp pierdute
Constatăm că în urma acestei operațiuni s-au pierdut 13 pachete
În urma debug-ului de pe A1R4 constatăm că actualizările despre ruta 192.168.4.4 s-au propagat într-un timp foarte scurt: 655 msec
A1R4#debug ip routing
IP routing debugging is on
A1R4#
May 11 2016 01:20:58.509 EET: RT: updating ospf 10.0.45.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.509 EET: RT: closer admin distance for 10.0.45.0, flushing 1 routes
May 11 2016 01:20:58.509 EET: RT: add 10.0.45.0/29 via 10.1.34.3, ospf metric [110/432]
May 11 2016 01:20:58.546 EET: RT: updating ospf 10.0.34.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 192.168.4.5, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 192.168.4.5/32 via 10.1.34.3, ospf metric [110/501]
May 11 2016 01:20:58.623 EET: RT: updating ospf 192.168.4.4/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 192.168.4.4, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 192.168.4.4/32 via 10.1.34.3, ospf metric [110/553]
May 11 2016 01:20:58.623 EET: RT: updating ospf 192.168.4.3/32 (0x0) :
via 10.1.34.3 Se2/1 0
Sa analizam debug-ul si in cazul ruterului A4R4:
A4R4#debug ip routing
IP routing debugging is on
A4R4#
May 11 2016 01:20:58.519 EET: RT: updating ospf 10.0.12.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.519 EET: RT: closer admin distance for 10.0.12.0, flushing 1 routes
May 11 2016 01:20:58.519 EET: RT: add 10.0.12.0/29 via 10.4.34.3, ospf metric [110/372]
May 11 2016 01:20:58.555 EET: RT: updating ospf 192.168.1.6/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.634 EET: RT: closer admin distance for 192.168.1.2, flushing 1 routes
May 11 2016 01:20:58.634 EET: RT: add 192.168.1.2/32 via 10.4.34.3, ospf metric [110/433]
May 11 2016 01:20:58.634 EET: RT: updating ospf 192.168.1.1/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.634 EET: RT: closer admin distance for 192.168.1.1, flushing 1 routes
May 11 2016 01:20:58.634 EET: RT: add 192.168.1.1/32 via 10.4.34.3, ospf metric [110/373]
May 11 2016 01:20:58.634 EET: RT: updating ospf 192.168.56.0/24 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.634 EET: RT: closer admin distance for 192.168.56.0, flushing 1 routes
May 11 2016 01:20:58.634 EET: RT: add 192.168.56.0/24 via 10.4.34.3, ospf metric [110/562]
May 11 2016 01:20:58.634 EET: RT: updating ospf 10.1.56.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
Timpul de convergenta in acest caz va fi: 01:20:58.634 – 01:20:57.968 =666
Figura 3.35 Captura pachete Wireshark
Folosind analizorul de retea Wireshark rezulta timp convergenta: 01:21:00:448- 01:20:59.821=627
In final avem urmatoarele rezultate:
CAPITOLUL 3.7 CONVERGENȚA EIGRP ȘI VOLUMUL DE DATE TRANSMIS ATUNCI CÂND APAR MODFICĂRI ÎN TOPOLOGIE
Similar cu ceea ce am lucrat anterior, voi arăta timpul de convergență în cazul protocolului de rutare EIGRP și voi incepe cu rețeaua de 6 rutere.
Figura 3.36 Generare trafic
După ce am folosit comanda ping către ruterul A0R4, întrerupem conexiunea dintre A0R3 (interfata seriala2/0) și A0R4.
Figura 3.37 Intrerupere link
A0R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
A0R3(config)#int se 2/0
A0R3(config-if)#sh
A0R3(config-if)#
May 11 2016 19:43:21.466 EET: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.34.4 (Serial2/0) is down: interface down
A0R3(config-if)#
May 11 2016 19:43:23.578 EET: %LINK-5-CHANGED: Interface Serial2/0, changed state to administratively down
May 11 2016 19:43:24.603 EET: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0, changed state to down
A0R3(config-if)#
Figura 3.38 Numar pachete
Spre deosebire de protocolul OSPF, unde s-au pierdut 12 pachete, în cazul de față avem un număr de 20 pachete
Urmatorul pas este să analizăm debug-urile de pe ruterele A0R1 și A0R4
A0R1#debug ip routing
IP routing debugging is on
A0R1#
May 11 2016 19:43:21.569 EET: RT: delete route to 192.168.1.4 via 10.1.12.2, eigrp metric [90/3245056]
May 11 2016 19:43:21.569 EET: RT: no routes to 192.168.1.4, delayed flush
May 11 2016 19:43:21.569 EET: RT: delete subnet route to 192.168.1.4/32
May 11 2016 19:43:21.569 EET: RT: updating eigrp 192.168.1.4/32 (0x0) :
via 10.1.12.2 Se2/0 0
May 11 2016 19:43:21.569 EET: RT: rib update return code: 5
May 11 2016 19:43:21.569 EET: RT: updating eigrp 192.168.1.4/32 (0x0) :
via 10.1.16.6 Se2/1 0
May 11 2016 19:43:21.569 EET: RT: add 192.168.1.4/32 via 10.1.16.6, eigrp metric [90/3321856]
May 11 2016 19:43:21.618 EET: RT: updating eigrp 192.168.1.5/32 (0x0) :
A0R1# via 10.1.16.6 Se2/1 0
May 11 2016 19:43:21.660 EET: RT: delete route to 10.1.34.0 via 10.1.12.2, eigrp metric [90/3117056]
May 11 2016 19:43:21.660 EET: RT: no routes to 10.1.34.0, delayed flush
May 11 2016 19:43:21.660 EET: RT: delete subnet route to 10.1.34.0/29
May 11 2016 19:43:21.660 EET: RT: updating eigrp 10.1.34.0/29 (0x0) :
via 10.1.12.2 Se2/0 0
May 11 2016 19:43:21.660 EET: RT: rib update return code: 5
May 11 2016 19:43:21.660 EET: RT: updating eigrp 10.1.34.0/29 (0x0) :
via 10.1.16.6 Se2/1 0
May 11 2016 19:43:21.660 EET: RT: add 10.1.34.0/29 via 10.1.16.6, eigrp metric [90/3680256]
A0R1#
May 11 2016 19:43:46.042 EET: RT: delete route to 10.1.34.0 via 10.1.16.6, eigrp metric [90/3680256]
May 11 2016 19:43:46.042 EET: RT: no routes to 10.1.34.0, delayed flush
May 11 2016 19:43:46.042 EET: RT: delete subnet route to 10.1.34.0/29
May 11 2016 19:43:46.042 EET: RT: updating eigrp 10.1.34.0/29 (0x0) :
via 10.1.16.6 Se2/1 0
May 11 2016 19:43:46.042 EET: RT: rib update return code: 5
A0R1#
A0R4#debug ip routing
IP routing debugging is on
A0R4#
May 11 2016 19:43:23.595 EET: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.34.3 (Serial2/1) is down: holding time expired
May 11 2016 19:43:23.596 EET: RT: delete route to 192.168.1.1 via 10.1.34.3, eigrp metric [90/3245056]
May 11 2016 19:43:23.596 EET: RT: no routes to 192.168.1.1, delayed flush
May 11 2016 19:43:23.596 EET: RT: delete subnet route to 192.168.1.1/32
May 11 2016 19:43:23.596 EET: RT: updating eigrp 192.168.1.1/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 19:43:23.596 EET: RT: add 192.168.1.1/32 via 10.1.45.5, eigrp metric [90/3321856]
May 11 2016 19:43:23.596 EET: RT: delete route to 192.168.56.0 via 10.1.34.3, eigrp metric [90/3142656]
May 11 2016 19:43:23.596 EET: RT: no routes to 192.168.56.0, delayed flush
May 11 2016 19:43:23.596 EET: RT:
A0R4#delete network route to 192.168.56.0/24
May 11 2016 19:43:23.596 EET: RT: updating eigrp 192.168.56.0/24 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 19:43:23.596 EET: RT: add 192.168.56.0/24 via 10.1.45.5, eigrp metric [90/3219456]
May 11 2016 19:43:23.760 EET: RT: delete route to 10.1.12.0 via 10.1.34.3, eigrp metric [90/3117056]
May 11 2016 19:43:23.760 EET: RT: no routes to 10.1.12.0, delayed flush
May 11 2016 19:43:23.760 EET: RT: delete subnet route to 10.1.12.0/29
May 11 2016 19:43:23.760 EET: RT: updating eigrp 10.1.12.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 19:43:23.760 EET: RT: add 10.1.12.0/29 via 10.1.45.5, eigrp metric [90/3680256]
May 11 2016 19:43:23.920 EET: RT: delete route to 192.168.1.2 via 10.1.34.3, eigrp metric [90/2758656]
May 11 2016 19:43:23.920 EET: RT: no routes to 192.168.1.2, delayed flush
May 11 2016 19:43:23.920 EET: RT: delete subnet route to 192.168.1.2/32
May 11 2016 19:43:23.920 EET: RT: updating eigrp 192.168.1.2/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 19:43:23.920 EET: RT: add 192.168.1.2/32 via 10.1.45.5, eigrp metric [90/3808256]
May 11 2016 19:43:24.036 EET: RT: delete route to 192.168.1.3 via 10.1.34.3, eigrp metric [90/2272256]
May 11 2016 19:43:24.036 EET: RT: no routes to 192.168.1.3, delayed flush
May 11 2016 19:43:24.036 EET: RT:
A0R4#delete subnet route to 192.168.1.3/32
May 11 2016 19:43:24.037 EET: RT: updating eigrp 192.168.1.3/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 19:43:24.037 EET: RT: add 192.168.1.3/32 via 10.1.45.5, eigrp metric [90/4294656]
May 11 2016 19:43:24.037 EET: RT: delete route to 10.1.23.0 via 10.1.34.3, eigrp metric [90/2630656]
May 11 2016 19:43:24.037 EET: RT: no routes to 10.1.23.0, delayed flush
May 11 2016 19:43:24.037 EET: RT: delete subnet route to 10.1.23.0/29
May 11 2016 19:43:24.037 EET: RT: updating eigrp 10.1.23.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 19:43:24.037 EET: RT: add 10.1.23.0/29 via 10.1.45.5, eigrp metric [90/4166656]
A0R4#
May 11 2016 19:43:45.692 EET: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/1, changed state to down
A0R4#
May 11 2016 19:43:45.693 EET: is_up: Serial2/1 0 state: 4 sub state: 1 line: 0
May 11 2016 19:43:45.693 EET: RT: interface Serial2/1 removed from routing table
May 11 2016 19:43:45.693 EET: RT: del 10.1.34.0 via 0.0.0.0, connected metric [0/0]
May 11 2016 19:43:45.693 EET: RT: delete subnet route to 10.1.34.0/29
May 11 2016 19:43:45.693 EET: RT: del 10.1.34.4 via 0.0.0.0, connected metric [0/0]
May 11 2016 19:43:45.693 EET: RT: delete subnet route to 10.1.34.4/32
Din actualizarile care le-au primit ruterele rezulta timpul de convergenta:
19:43:23.596 – 19:43:21.466 =2.130
In paralel, folosind analizorul Wireshark rezulta timpul de convergenta:
19:43:23.673 – 19:43:21.418= 2.255
Figura 3.39 Captura pachete icmp
De asemenea vom calcula timpul de convergență în cadrul rețelei medii de 30 de rutere.
Figura 3.40 Ping ruter A4R4
După ce am generat trafic în retea cu ajutorul comenzii ping 192.168.4.4, întrerupem legătura dintre ruterul A1R1 (interfata seriala 3/1) și ruterul A5R1
A1R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
A1R1(config)#int se 3/1
A1R1(config-if)#sh
A1R1(config-if)#
May 11 2016 22:42:45.162 EET: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.15.5 (Serial3/1) is down: interface down
A1R1(config-if)#
May 11 2016 22:42:47.157 EET: %LINK-5-CHANGED: Interface Serial3/1, changed state to administratively down
May 11 2016 22:42:48.168 EET: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/1, changed state to down
A1R1(config-if)#
Figura 3.41 Intrerupere link
Figura 3.42 Pachete icmp
Constatăm că în urma acestui proces s-au pierdut 53 de pachete.
Pornim procesele de debug pe ruterele sursă (A1R4) și destinație (A4R4) iar în urma informațiilor despre rute, calculăm timpii de convergență
A1R4#debug ip routing
IP routing debugging is on
A1R4#
May 11 2016 22:42:45.374 EET: RT: updating eigrp 10.0.34.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.374 EET: RT: updating eigrp 10.0.34.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.374 EET: RT: rib update return code: 19
May 11 2016 22:42:45.395 EET: RT: updating eigrp 10.0.34.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.395 EET: RT: eigrp's 10.0.34.0/29 (via 10.1.34.3) metric changed from distance/metric [90/4601856] to [90/4653056]
May 11 2016 22:42:45.395 EET: RT: updating eigrp 10.0.34.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.395 EET: RT: rib update return code: 19
May 11 2016 22:42:45.439 EET: RT: delete route to 10.0.15.0 via 10.1.34.3, eigrp metric [90/3603456]
May 11 2016 22:42:45.439 EET: RT: no routes to 10.0.15.0, delayed flush
May 11 2016 22:42:45.439 EET: RT: delete subnet route to 10.0.15.0/29
May 11 2016 22:42:45.439 EET: RT: updating eigrp 10.0.15.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.718 EET: RT: updating eigrp 192.168.4.5/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.718 EET: RT: del 192.168.4.5/32 via 10.1.45.5, eigrp metric [90/5881856]
May 11 2016 22:42:45.718 EET: RT: add 192.168.4.5/32 via 10.1.34.3, eigrp metric [90/5805056]
May 11 2016 22:42:45.718 EET: RT: updating eigrp 192.168.4.4/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.718 EET: RT: updating eigrp 192.168.4.4/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.718 EET: RT: del 192.168.4.4/32 via 10.1.45.5, eigrp metric [90/6317056]
May 11 2016 22:42:45.718 EET: RT: add 192.168.4.4/32 via 10.1.34.3, eigrp metric [90/6240256]
May 11 2016 22:42:45.718 EET: RT: updating eigrp 10.4.16.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.719 EET: RT: updating eigrp 10.4.16.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
A4R4#debug ip routing
IP routing debugging is on
A4R4#
May 11 2016 22:42:47.499 EET: RT: delete route to 10.1.34.0 via 10.4.34.3, eigrp metric [90/5549056]
May 11 2016 22:42:47.499 EET: RT: no routes to 10.1.34.0, delayed flush
May 11 2016 22:42:47.499 EET: RT: delete subnet route to 10.1.34.0/29
May 11 2016 22:42:47.499 EET: RT: updating eigrp 10.1.34.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.499 EET: RT: rib update return code: 5
May 11 2016 22:42:47.499 EET: RT: updating eigrp 10.1.34.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.499 EET: RT: add 10.1.34.0/29 via 10.4.45.5, eigrp metric [90/5625856]
May 11 2016 22:42:47.499 EET: RT: delete route to 192.168.1.6 via 10.4.34.3, eigrp metric [90/4729856]
May 11 2016 22:42:47.499 EET: RT: no routes to 192.168.1.6, delayed flush
May 11 2016 22:42:47.499 EET: RT: delete subnet route to 192.168.1.6/32
May 11 2016 22:42:47.500 EET: RT: updating eigrp 192.168.1.6/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.892 EET: RT: del 192.168.1.2/32 via 10.4.45.5, eigrp metric [90/5344256]
May 11 2016 22:42:47.892 EET: RT: add 192.168.1.2/32 via 10.4.34.3, eigrp metric [90/5267456]
May 11 2016 22:42:47.892 EET: RT: updating eigrp 192.168.56.0/24 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.892 EET: RT: updating eigrp 192.168.56.0/24 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.892 EET: RT: del 192.168.56.0/24 via 10.4.45.5, eigrp metric [90/6214656]
May 11 2016 22:42:47.892 EET: RT: add 192.168.56.0/24 via 10.4.34.3, eigrp metric [90/6137856]
May 11 2016 22:42:47.892 EET: RT: updating eigrp 10.1.45.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.892 EET: RT: updating eigrp 10.1.45.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.892 EET: RT: del 10.1.45.0/29 via 10.4.45.5, eigrp metric [90/6265856]
May 11 2016 22:42:47.892 EET: RT: add 10.1.45.0/29 via 10.4.34.3, eigrp metric [90/6189056]
May 11 2016 22:42:47.892 EET: RT: updating eigrp 10.1.56.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.892 EET: RT: updating eigrp 10.1.56.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.892 EET: RT: del 10.1.56.0/29 via 10.4.45.5, eigrp metric [90/5753856]
May 11 2016 22:42:47.892 EET: RT:
A4R4#add 10.1.56.0/29 via 10.4.34.3, eigrp metric [90/5677056]
A4R4#
May 11 2016 22:43:24.405 EET: RT: delete route to 10.0.15.0 via 10.4.34.3, eigrp metric [90/4089856]
May 11 2016 22:43:24.405 EET: RT: no routes to 10.0.15.0, delayed flush
May 11 2016 22:43:24.405 EET: RT: delete subnet route to 10.0.15.0/29
May 11 2016 22:43:24.405 EET: RT: updating eigrp 10.0.15.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:43:24.405 EET: RT: rib update return code: 5
A4R4#
In urma debug-urilor rezulta timpul de convergenta: 22:42:47.892- 22:42:45.162= 2.730
In paralel folosind analizorul Wireshark rezulta: 22:42:47.932 – 22:42:45.136= 2.796
Figura 3.43 Captura Wireshark EIGRP
În final avem următoarele rezultate cu privire la convergența celor două protocoale și la volumul de date transmis
Tabel 3.5 Convergenta protocoale rutare
Constatăm că protocolul de rutare OSPF oferă un timp de convergență mult mai mic decât EIGRP. Ambele protocoale sunt scalabile fiindcă, odată cu creșterea în dimensiune a rețelei, perfomanțele nu se diminuează și procesele se adaptează rapid la schimbări
CONCLUZII
În telecomunicații un protocol este un ansamblu de reguli dedicat schimbului de date între sisteme de calcul. Un protocol definește sintaxa, semantica și sincronizarea comunicației de date digitale cu scopul ca un mesaj trimis să fie interpretat corect și să genereze un răspuns corespunzător. Un protocol trebuie să asigure un comportament specific, indiferent de modul de implementare. Protocolul poate fi implementat hardware, software sau mixt, este descris în standarde și trebuie să fie agreat de producătorii echipamentelor de comunicații. Stiva de protocoale OSI (Open Systems Interconnection) arată organizarea pe nivele ierarhice a protocoalelor de comunicații și conține nivelele: fizic, legături de date, rețea, transport, sesiune, prezentare și aplicație.
Protocoalele de rutare OSPF și EIGRP sunt folosite foarte des în domeniul rețelisticii pentru stabilirea traseului pe care urmează a fi transmise pachetele care conțin date și alte informații, între un nod sursă și un nod destinație. Cele mai importante avantaje ale protocolului OSPF sunt facilitățile de securitate, facilități de căi multiple, facilități în ceea ce priveste utilizarea metricilor de costuri diferite, suport integrat atît pentru rutarea unicast, cît și pentru cea multicast, convergența rapidă. EIGRP are toate avantajele flexibilității și ale configurării simple în timp ce îmbunătățește viteza și consumarea resurselor. Dealtfel, este capabil a fi un protocol unic atît pentru IP cît și pentru protocoale non- IP eliminînd nevoia de a folosi multiple protocoale de rutare într-o rețea multi-protocol.
În momentul alegerii unui protocol am putea avea preferințe fie pentru rutarea folosind starea legăturilor (link-state) sau pentru rutarea cu vectori distanță (distance-vector), dar alegerea doar în funcție de algoritmul folosit nu este recomandată. Voi prezenta și alte criterii de alegere care ne vor ajuta să selectăm protocolul care se potrivește cel mai bine rețelei pe care o gestionăm. Ar trebui să avem în vedere cât de repede protocolul se va adapta schimbărilor intervenite în retea. Aici intervine timpul de convergență, care este cantitatea de timp scursă de la intâlnirea unei schimbări în rețea până la restabilirea consistenței și modificarea tabelei de rutare. În mod ideal ne dorim ca acest timp să fie suficient de mic astfel încât să nu poată fi detectat de utilizatori. Un alt criteriu important este consumul de resurse, astfel protocolul de rutare trebuie să aibă suport pentru lungimi variabile de măști de subrețea. Trebuie să considerăm nu numai consumul de bandă realizat de mesajele protocolului, ci și câtă putere de procesare și memorie folosește ruterul. Un protocol cu starea legăturii va gestiona mai bine consumul de bandă, iar un protocol cu vectori distanță va gestiona consumul memoriei și al procesorului. Putem considera și modul în care protocolul este scalabil în functie de dimensiunile pe care le poate atinge rețeaua. Protocoalele care folosesc starea legăturilor scalează mai bine, dar câteva protocoale cu vectori distanță, cum ar fi EIGRP , au putut fi folosite și în retele cu mai mult de 1000 de rutere
În cadrul acestui proiect am prezentat o analiză comparativă între protocoalele de rutare OSPF și EIGRP folosind programul de simulare GNS3. Inițial am implementat o topologie simplă formată din 6 rutere, după care am realizat o topologie mai complexă formată din 30 de rutere pentru a analiza performanțele pentru fiecare protocol în parte și pentru a face o comparație între cele două. Rezultatele au aratat că protocolul OSPF a oferit un timp mai bun de convergență decât EIGRP și o rată de pierdere a pachetelor mai mică. Ambele protocoale sunt scalabile fiindcă, odată cu creșterea în dimensiune a rețelei, perfomanțele nu se diminuează și procesele se adaptează rapid la schimbări.
ANEXA 1
ANEXA 2
ANEXA 3
A1R4#debug ip routing
IP routing debugging is on
A1R4#
May 11 2016 01:20:58.509 EET: RT: updating ospf 10.0.45.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.509 EET: RT: closer admin distance for 10.0.45.0, flushing 1 routes
May 11 2016 01:20:58.509 EET: RT: add 10.0.45.0/29 via 10.1.34.3, ospf metric [110/432]
May 11 2016 01:20:58.546 EET: RT: updating ospf 10.0.34.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.546 EET: RT: closer admin distance for 10.0.34.0, flushing 1 routes
May 11 2016 01:20:58.546 EET: RT: add 10.0.34.0/29 via 10.1.34.3, ospf metric [110/372]
May 11 2016 01:20:58.584 EET: RT: updating ospf 10.0.15.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.584 EET: RT: closer admin distance for 10.0.15.0, flushing 1 routes
May 11 2016 01:20:58.584 EET: RT: add 10.0.15.0/29 via 10.1.34.3, ospf metric [110/492]
May 11 2016 01:20:58.621 EET: RT: updating ospf 192.168.5.6/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.622 EET: RT: closer admin distance for 192.168.5.6, flushing 1 routes
May 11 2016 01:20:58.622 EET: RT: add 192.168.5.6/32 via 10.1.34.3, ospf metric [110/497]
May 11 2016 01:20:58.622 EET: RT: updating ospf 192.168.5.5/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.622 EET: RT: closer admin distance for 192.168.5.5, flushing 1 routes
May 11 2016 01:20:58.622 EET: RT: add 192.168.5.5/32 via 10.1.34.3, ospf metric [110/561]
May 11 2016 01:20:58.622 EET: RT: updating ospf 192.168.5.4/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.622 EET: RT: closer admin distance for 192.168.5.4, flushing 1 routes
May 11 2016 01:20:58.622 EET: RT: add 192.168.5.4/32 via 10.1.34.3, ospf metric [110/625]
May 11 2016 01:20:58.622 EET: RT: updating ospf 192.168.5.3/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.622 EET: RT: closer admin distance for 192.168.5.3, flushing 1 routes
May 11 2016 01:20:58.622 EET: RT: add 192.168.5.3/32 via 10.1.34.3, ospf metric [110/561]
May 11 2016 01:20:58.622 EET: RT: updating ospf 192.168.5.2/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.622 EET: RT: closer admin distance for 192.168.5.2, flushing 1 routes
May 11 2016 01:20:58.622 EET: RT: add 192.168.5.2/32 via 10.1.34.3, ospf metric [110/497]
May 11 2016 01:20:58.622 EET: RT: updating ospf 192.168.5.1/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.622 EET: RT: closer admin distance for 192.168.5.1, flushing 1 routes
May 11 2016 01:20:58.622 EET: RT: add 192.168.5.1/32 via 10.1.34.3, ospf metric [110/433]
May 11 2016 01:20:58.622 EET: RT: updating ospf 192.168.4.6/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.622 EET: RT: closer admin distance for 192.168.4.6, flushing 1 routes
May 11 2016 01:20:58.622 EET: RT: add 192.168.4.6/32 via 10.1.34.3, ospf metric [110/437]
May 11 2016 01:20:58.622 EET: RT: updating ospf 192.168.4.5/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 192.168.4.5, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 192.168.4.5/32 via 10.1.34.3, ospf metric [110/501]
May 11 2016 01:20:58.623 EET: RT: updating ospf 192.168.4.4/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 192.168.4.4, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 192.168.4.4/32 via 10.1.34.3, ospf metric [110/553]
May 11 2016 01:20:58.623 EET: RT: updating ospf 192.168.4.3/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 192.168.4.3, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 192.168.4.3/32 via 10.1.34.3, ospf metric [110/493]
May 11 2016 01:20:58.623 EET: RT: updating ospf 192.168.4.2/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 192.168.4.2, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 192.168.4.2/32 via 10.1.34.3, ospf metric [110/433]
May 11 2016 01:20:58.623 EET: RT: updating ospf 192.168.4.1/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 192.168.4.1, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 192.168.4.1/32 via 10.1.34.3, ospf metric [110/373]
May 11 2016 01:20:58.623 EET: RT: updating ospf 10.5.56.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 10.5.56.0, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 10.5.56.0/29 via 10.1.34.3, ospf metric [110/560]
May 11 2016 01:20:58.623 EET: RT: updating ospf 10.5.45.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 10.5.45.0, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 10.5.45.0/29 via 10.1.34.3, ospf metric [110/624]
May 11 2016 01:20:58.623 EET: RT: updating ospf 10.5.34.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 10.5.34.0, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 10.5.34.0/29 via 10.1.34.3, ospf metric [110/624]
May 11 2016 01:20:58.623 EET: RT: updating ospf 10.5.23.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 10.5.23.0, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 10.5.23.0/29 via 10.1.34.3, ospf metric [110/560]
May 11 2016 01:20:58.623 EET: RT: updating ospf 10.5.16.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 10.5.16.0, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 10.5.16.0/29 via 10.1.34.3, ospf metric [110/496]
May 11 2016 01:20:58.623 EET: RT: updating ospf 10.5.12.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 10.5.12.0, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 10.5.12.0/29 via 10.1.34.3, ospf metric [110/496]
May 11 2016 01:20:58.623 EET: RT: updating ospf 10.4.56.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 10.4.56.0, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 10.4.56.0/29 via 10.1.34.3, ospf metric [110/500]
May 11 2016 01:20:58.623 EET: RT: updating ospf 10.4.45.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 10.4.45.0, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 10.4.45.0/29 via 10.1.34.3, ospf metric [110/564]
May 11 2016 01:20:58.623 EET: RT: updating ospf 10.4.34.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 10.4.34.0, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 10.4.34.0/29 via 10.1.34.3, ospf metric [110/552]
May 11 2016 01:20:58.623 EET: RT: updating ospf 10.4.23.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 10.4.23.0, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 10.4.23.0/29 via 10.1.34.3, ospf metric [110/492]
May 11 2016 01:20:58.623 EET: RT: updating ospf 10.4.16.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.623 EET: RT: closer admin distance for 10.4.16.0, flushing 1 routes
May 11 2016 01:20:58.623 EET: RT: add 10.4.16.0/29 via 10.1.34.3, ospf metric [110/436]
May 11 2016 01:20:58.624 EET: RT:
A1R4#updating ospf 10.4.12.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 01:20:58.624 EET: RT: closer admin distance for 10.4.12.0, flushing 1 routes
May 11 2016 01:20:58.624 EET: RT: add 10.4.12.0/29 via 10.1.34.3, ospf metric [110/432]
A1R4#
May 11 2016 01:21:26.230 EET: RT: del 10.0.15.0 via 10.1.34.3, ospf metric [110/492]
May 11 2016 01:21:26.230 EET: RT: delete subnet route to 10.0.15.0/29
A1R4#
ANEXA 4
A4R4#debug ip routing
IP routing debugging is on
A4R4#
May 11 2016 01:20:58.519 EET: RT: updating ospf 10.0.12.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.519 EET: RT: closer admin distance for 10.0.12.0, flushing 1 routes
May 11 2016 01:20:58.519 EET: RT: add 10.0.12.0/29 via 10.4.34.3, ospf metric [110/372]
May 11 2016 01:20:58.555 EET: RT: updating ospf 192.168.1.6/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.555 EET: RT: closer admin distance for 192.168.1.6, flushing 1 routes
May 11 2016 01:20:58.555 EET: RT: add 192.168.1.6/32 via 10.4.34.3, ospf metric [110/437]
May 11 2016 01:20:58.595 EET: RT: updating ospf 192.168.1.5/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.595 EET: RT: closer admin distance for 192.168.1.5, flushing 1 routes
May 11 2016 01:20:58.595 EET: RT: add 192.168.1.5/32 via 10.4.34.3, ospf metric [110/501]
May 11 2016 01:20:58.634 EET: RT: updating ospf 192.168.1.4/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.634 EET: RT: closer admin distance for 192.168.1.4, flushing 1 routes
May 11 2016 01:20:58.634 EET: RT: add 192.168.1.4/32 via 10.4.34.3, ospf metric [110/553]
May 11 2016 01:20:58.634 EET: RT: updating ospf 192.168.1.3/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.634 EET: RT: closer admin distance for 192.168.1.3, flushing 1 routes
May 11 2016 01:20:58.634 EET: RT: add 192.168.1.3/32 via 10.4.34.3, ospf metric [110/493]
May 11 2016 01:20:58.634 EET: RT: updating ospf 192.168.1.2/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.634 EET: RT: closer admin distance for 192.168.1.2, flushing 1 routes
May 11 2016 01:20:58.634 EET: RT: add 192.168.1.2/32 via 10.4.34.3, ospf metric [110/433]
May 11 2016 01:20:58.634 EET: RT: updating ospf 192.168.1.1/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.634 EET: RT: closer admin distance for 192.168.1.1, flushing 1 routes
May 11 2016 01:20:58.634 EET: RT: add 192.168.1.1/32 via 10.4.34.3, ospf metric [110/373]
May 11 2016 01:20:58.634 EET: RT: updating ospf 192.168.56.0/24 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.634 EET: RT: closer admin distance for 192.168.56.0, flushing 1 routes
May 11 2016 01:20:58.634 EET: RT: add 192.168.56.0/24 via 10.4.34.3, ospf metric [110/562]
May 11 2016 01:20:58.634 EET: RT: updating ospf 10.1.56.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.634 EET: RT: closer admin distance for 10.1.56.0, flushing 1 routes
May 11 2016 01:20:58.635 EET: RT: add 10.1.56.0/29 via 10.4.34.3, ospf metric [110/500]
May 11 2016 01:20:58.635 EET: RT: updating ospf 10.1.45.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.635 EET: RT: closer admin distance for 10.1.45.0, flushing 1 routes
May 11 2016 01:20:58.635 EET: RT: add 10.1.45.0/29 via 10.4.34.3, ospf metric [110/564]
May 11 2016 01:20:58.635 EET: RT: updating ospf 10.1.34.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.635 EET: RT: closer admin distance for 10.1.34.0, flushing 1 routes
May 11 2016 01:20:58.635 EET: RT: add 10.1.34.0/29 via 10.4.34.3, ospf metric [110/552]
May 11 2016 01:20:58.635 EET: RT: updating ospf 10.1.23.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.635 EET: RT: closer admin distance for 10.1.23.0, flushing 1 routes
May 11 2016 01:20:58.635 EET: RT:
A4R4#add 10.1.23.0/29 via 10.4.34.3, ospf metric [110/492]
May 11 2016 01:20:58.635 EET: RT: updating ospf 10.1.16.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 01:20:58.635 EET: RT: closer admin distance for 10.1.16.0, flushing 1 routes
May 11 2016 01:20:58.635 EET: RT: add 10.1.16.0/29 via 10.4.34.3, ospf metric [110/436]
May 11 2016 01:20:58.635 EET: RT: updating ospf 10.1.12.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
ANEXA 5
A1R4#debug ip routing
IP routing debugging is on
A1R4#
May 11 2016 22:42:45.374 EET: RT: updating eigrp 10.0.34.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.374 EET: RT: updating eigrp 10.0.34.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.374 EET: RT: rib update return code: 19
May 11 2016 22:42:45.395 EET: RT: updating eigrp 10.0.34.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.395 EET: RT: eigrp's 10.0.34.0/29 (via 10.1.34.3) metric changed from distance/metric [90 /4601856] to [90/4653056]
May 11 2016 22:42:45.395 EET: RT: updating eigrp 10.0.34.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.395 EET: RT: rib update return code: 19
May 11 2016 22:42:45.439 EET: RT: delete route to 10.0.15.0 via 10.1.34.3, eigrp metric [90/3603456]
May 11 2016 22:42:45.439 EET: RT: no routes to 10.0.15.0, delayed flush
May 11 2016 22:42:45.439 EET: RT: delete subnet route to 10.0.15.0/29
May 11 2016 22:42:45.439 EET: RT: updating eigrp 10.0.15.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.439 EET: RT: rib update return code: 5
May 11 2016 22:42:45.440 EET: RT: delete route to 10.4.34.0 via 10.1.34.3, eigrp metric [90/5549056]
May 11 2016 22:42:45.440 EET: RT: no routes to 10.4.34.0, delayed flush
May 11 2016 22:42:45.440 EET: RT: delete subnet route to 10.4.34.0/29
May 11 2016 22:42:45.440 EET: RT: updating eigrp 10.4.34.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.440 EET: RT: rib update return code: 5
May 11 2016 22:42:45.440 EET: RT: delete route to 10.4.56.0 via 10.1.34.3, eigrp metric [90/5113856]
May 11 2016 22:42:45.440 EET: RT: no routes to 10.4.56.0, delayed flush
May 11 2016 22:42:45.440 EET: RT: delete subnet route to 10.4.56.0/29
May 11 2016 22:42:45.440 EET: RT: updating eigrp 10.4.56.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.440 EET: RT: rib update return code: 5
May 11 2016 22:42:45.440 EET: RT: delete route to 192.168.4.5 via 10.1.34.3, eigrp metric [90/5241856]
May 11 2016 22:42:45.440 EET: RT: no routes to 192.168.4.5, delayed flush
May 11 2016 22:42:45.440 EET: RT: delete subnet route to 192.168.4.5/32
May 11 2016 22:42:45.440 EET: RT: updating eigrp 192.168.4.5/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.440 EET: RT: rib update return code: 5
May 11 2016 22:42:45.440 EET: RT: delete route to 10.5.12.0 via 10.1.34.3, eigrp metric [90/4115456]
May 11 2016 22:42:45.440 EET: RT: no routes to 10.5.12.0, delayed flush
May 11 2016 22:42:45.440 EET: RT: delete subnet route to 10.5.12.0/29
May 11 2016 22:42:45.440 EET: RT: updating eigrp 10.5.12.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.440 EET: RT: rib update return code: 5
May 11 2016 22:42:45.440 EET: RT: delete route to 192.168.5.4 via 10.1.34.3, eigrp metric [90/5267456]
May 11 2016 22:42:45.440 EET: RT: no routes to 192.168.5.4, delayed flush
May 11 2016 22:42:45.440 EET: RT: delete subnet route to 192.168.5.4/32
May 11 2016 22:42:45.440 EET: RT: updating eigrp 192.168.5.4/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.440 EET: RT: rib update return code: 5
May 11 2016 22:42:45.440 EET: RT: delete route to 192.168.4.4 via 10.1.34.3, eigrp metric [90/5677056]
May 11 2016 22:42:45.440 EET: RT: no routes to 192.168.4.4, delayed flush
May 11 2016 22:42:45.440 EET: RT: delete subnet route to 192.168.4.4/32
May 11 2016 22:42:45.440 Eet: Rt: Updating Eigrp 192.168.4.4/32 (0X0) :
Via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.440 EET: RT: rib update return code: 5
May 11 2016 22:42:45.440 EET: RT: delete route to 10.4.16.0 via 10.1.34.3, eigrp metric [90/4601856]
May 11 2016 22:42:45.440 EET: RT: no routes to 10.4.16.0, delayed flush
May 11 2016 22:42:45.440 EET: RT: delete subnet route to 10.4.16.0/29
May 11 2016 22:42:45.440 EET: RT: updating eigrp 10.4.16.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.440 EET: RT: rib update return code: 5
May 11 2016 22:42:45.441 EET: RT: delete route to 192.168.5.5 via 10.1.34.3, eigrp metric [90/4755456]
May 11 2016 22:42:45.441 EET: RT: no routes to 192.168.5.5, delayed flush
May 11 2016 22:42:45.441 EET: RT: delete subnet route to 192.168.5.5/32
May 11 2016 22:42:45.441 EET: RT: updating eigrp 192.168.5.5/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.441 EET: RT: rib update return code: 5
May 11 2016 22:42:45.441 EET: RT: delete route to 10.5.16.0 via 10.1.34.3, eigrp metric [90/4115456]
May 11 2016 22:42:45.441 EET: RT: no routes to 10.5.16.0, delayed flush
May 11 2016 22:42:45.441 EET: RT: delete subnet route to 10.5.16.0/29
May 11 2016 22:42:45.441 EET: RT: updating eigrp 10.5.16.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.441 EET: RT: rib update return code: 5
May 11 2016 22:42:45.441 EET: RT: delete route to 192.168.5.6 via 10.1.34.3, eigrp metric [90/4243456]
May 11 2016 22:42:45.441 EET: RT: no routes to 192.168.5.6, delayed flush
May 11 2016 22:42:45.441 EET: RT: delete subnet route to 192.168.5.6/32
May 11 2016 22:42:45.441 EET: RT: updating eigrp 192.168.5.6/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.441 EET: RT: rib update return code: 5
May 11 2016 22:42:45.441 EET: RT: delete route to 192.168.4.3 via 10.1.34.3, eigrp metric [90/5190656]
May 11 2016 22:42:45.441 EET: RT: no routes to 192.168.4.3, delayed flush
May 11 2016 22:42:45.441 EET: RT: delete subnet route to 192.168.4.3/32
May 11 2016 22:42:45.441 EET: RT: updating eigrp 192.168.4.3/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.441 EET: RT: rib update return code: 5
May 11 2016 22:42:45.441 EET: RT: delete route to 10.4.23.0 via 10.1.34.3, eigrp metric [90/5062656]
May 11 2016 22:42:45.441 EET: RT: no routes to 10.4.23.0, delayed flush
May 11 2016 22:42:45.441 EET: RT: delete subnet route to 10.4.23.0/29
May 11 2016 22:42:45.441 EET: RT: updating eigrp 10.4.23.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.441 EET: RT: rib update return code: 5
May 11 2016 22:42:45.441 EET: RT: delete route to 10.5.45.0 via 10.1.34.3, eigrp metric [90/5139456]
May 11 2016 22:42:45.441 EET: RT: no routes to 10.5.45.0, delayed flush
May 11 2016 22:42:45.441 EET: RT: delete subnet route to 10.5.45.0/29
May 11 2016 22:42:45.441 EET: RT: updating eigrp 10.5.45.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.441 EET: RT: rib update return code: 5
May 11 2016 22:42:45.441 EET: RT: delete route to 10.4.12.0 via 10.1.34.3, eigrp metric [90/4576256]
May 11 2016 22:42:45.441 EET: RT: no routes to 10.4.12.0, delayed flush
May 11 2016 22:42:45.441 EET: RT: delete subnet route to 10.4.12.0/29
May 11 2016 22:42:45.441 EET: RT: updating eigrp 10.4.12.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.441 EET: RT: rib update return code: 5
May 11 2016 22:42:45.441 EET: RT: delete route to 192.168.4.2 via 10.1.34.3, eigrp metric [90/4704256]
May 11 2016 22:42:45.441 EET: RT: no routes to 192.168.4.2, delayed flush
May 11 2016 22:42:45.441 EET: RT: delete subnet route to 192.168.4.2/32
May 11 2016 22:42:45.441 EET: RT: updating eigrp 192.168.4.2/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.442 EET: RT: rib update return code: 5
May 11 2016 22:42:45.442 EET: RT: delete route to 192.168.5.1 via 10.1.34.3, eigrp metric [90/3731456]
May 11 2016 22:42:45.442 EET: RT: no routes to 192.168.5.1, delayed flush
May 11 2016 22:42:45.442 EET: RT: delete subnet route to 192.168.5.1/32
May 11 2016 22:42:45.442 EET: RT: updating eigrp 192.168.5.1/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.442 EET: RT: rib update return code: 5
May 11 2016 22:42:45.442 EET: RT: delete route to 192.168.4.1 via 10.1.34.3, eigrp metric [90/4217856]
May 11 2016 22:42:45.442 EET: RT: no routes to 192.168.4.1, delayed flush
May 11 2016 22:42:45.442 EET: RT: delete subnet route to 192.168.4.1/32
May 11 2016 22:42:45.442 EET: RT: updating eigrp 192.168.4.1/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.442 EET: RT: rib update return code: 5
May 11 2016 22:42:45.442 EET: RT: delete route to 10.0.45.0 via 10.1.34.3, eigrp metric [90/4089856]
May 11 2016 22:42:45.442 EET: RT: no routes to 10.0.45.0, delayed flush
May 11 2016 22:42:45.442 EET: RT: delete subnet route to 10.0.45.0/29
May 11 2016 22:42:45.442 EET: RT: updating eigrp 10.0.45.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.442 EET: RT: rib update return code: 5
May 11 2016 22:42:45.442 EET: RT: delete route to 10.4.45.0 via 10.1.34.3, eigrp metric [90/5625856]
May 11 2016 22:42:45.442 EET: RT: no routes to 10.4.45.0, delayed flush
May 11 2016 22:42:45.442 EET: RT: delete subnet route to 10.4.45.0/29
May 11 2016 22:42:45.442 EET: RT: updating eigrp 10.4.45.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.442 EET: RT: rib update return code: 5
May 11 2016 22:42:45.442 EET: RT: delete route to 10.5.56.0 via 10.1.34.3, eigrp metric [90/4627456]
May 11 2016 22:42:45.442 EET: RT: no routes to 10.5.56.0, delayed flush
May 11 2016 22:42:45.443 EET: RT: delete subnet route to 10.5.56.0/29
May 11 2016 22:42:45.443 EET: RT: updating eigrp 10.5.56.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.443 EET: RT: rib update return code: 5
May 11 2016 22:42:45.443 EET: RT: delete route to 10.5.34.0 via 10.1.34.3, eigrp metric [90/5139456]
May 11 2016 22:42:45.443 EET: RT: no routes to 10.5.34.0, delayed flush
May 11 2016 22:42:45.443 EET: RT: delete subnet route to 10.5.34.0/29
May 11 2016 22:42:45.443 EET: RT: updating eigrp 10.5.34.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.443 EET: RT: rib update return code: 5
May 11 2016 22:42:45.443 EET: RT: delete route to 10.5.23.0 via 10.1.34.3, eigrp metric [90/4627456]
May 11 2016 22:42:45.443 EET: RT: no routes to 10.5.23.0, delayed flush
May 11 2016 22:42:45.443 EET: RT: delete subnet route to 10.5.23.0/29
May 11 2016 22:42:45.443 EET: RT: updating eigrp 10.5.23.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.443 EET: RT: rib update return code: 5
May 11 2016 22:42:45.443 EET: RT: delete route to 192.168.5.2 via 10.1.34.3, eigrp metric [90/4243456]
May 11 2016 22:42:45.443 EET: RT: no routes to 192.168.5.2, delayed flush
May 11 2016 22:42:45.443 EET: RT: delete subnet route to 192.168.5.2/32
May 11 2016 22:42:45.443 EET: RT: updating eigrp 192.168.5.2/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.443 EET: RT: rib update return code: 5
May 11 2016 22:42:45.443 EET: RT: delete route to 192.168.5.3 via 10.1.34.3, eigrp metric [90/4755456]
May 11 2016 22:42:45.443 EET: RT: no routes to 192.168.5.3, delayed flush
May 11 2016 22:42:45.443 EET: RT: delete subnet route to 192.168.5.3/32
May 11 2016 22:42:45.443 EET: RT: updating eigrp 192.168.5.3/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.443 EET: RT: rib update return code: 5
May 11 2016 22:42:45.443 EET: RT: delete route to 192.168.4.6 via 10.1.34.3, eigrp metric [90/4729856]
May 11 2016 22:42:45.444 EET: RT: no routes to 192.168.4.6, delayed flush
May 11 2016 22:42:45.444 EET: RT: delete subnet route to 192.168.4.6/32
May 11 2016 22:42:45.444 EET: RT: updating eigrp 192.168.4.6/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.444 EET: RT: rib update return code: 5
May 11 2016 22:42:45.706 EET: RT: updating eigrp 10.4.34.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.706 EET: RT: add 10.4.34.0/29 via 10.1.45.5, eigrp metric [90/6189056]
May 11 2016 22:42:45.706 EET: RT: updating eigrp 10.4.56.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.706 EET: RT: add 10.4.56.0/29 via 10.1.45.5, eigrp metric [90/5753856]
May 11 2016 22:42:45.706 EET: RT: updating eigrp 192.168.4.5/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.706 EET: RT: add 192.168.4.5/32 via 10.1.45.5, eigrp metric [90/5881856]
May 11 2016 22:42:45.706 EET: RT: updating eigrp 192.168.4.4/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.706 EET: RT: add 192.168.4.4/32 via 10.1.45.5, eigrp metric [90/6317056]
May 11 2016 22:42:45.706 EET: RT: updating eigrp 10.4.16.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.706 EET: RT: add 10.4.16.0/29 via 10.1.45.5, eigrp metric [90/5241856]
May 11 2016 22:42:45.707 EET: RT: updating eigrp 192.168.4.3/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.707 EET: RT: add 192.168.4.3/32 via 10.1.45.5, eigrp metric [90/5830656]
May 11 2016 22:42:45.707 EET: RT: updating eigrp 10.4.23.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.707 EET: RT: add 10.4.23.0/29 via 10.1.45.5, eigrp metric [90/5702656]
May 11 2016 22:42:45.707 EET: RT: updating eigrp 10.4.12.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.707 EET: RT: add 10.4.12.0/29 via 10.1.45.5, eigrp metric [90/5216256]
May 11 2016 22:42:45.707 EET: RT: updating eigrp 192.168.4.2/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.707 EET: RT: add 192.168.4.2/32 via 10.1.45.5, eigrp metric [90/5344256]
May 11 2016 22:42:45.707 EET: RT: updating eigrp 192.168.4.1/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.707 EET: RT: add 192.168.4.1/32 via 10.1.45.5, eigrp metric [90/4857856]
May 11 2016 22:42:45.707 EET: RT: updating eigrp 10.0.45.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.707 EET: RT: add 10.0.45.0/29 via 10.1.45.5, eigrp metric [90/5216256]
May 11 2016 22:42:45.707 EET: RT: updating eigrp 10.4.45.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.707 EET: RT: add 10.4.45.0/29 via 10.1.45.5, eigrp metric [90/6265856]
May 11 2016 22:42:45.718 EET: RT: updating eigrp 10.4.34.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.718 EET: RT: updating eigrp 10.4.34.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.718 EET: RT: del 10.4.34.0/29 via 10.1.45.5, eigrp metric [90/6189056]
May 11 2016 22:42:45.718 EET: RT: add 10.4.34.0/29 via 10.1.34.3, eigrp metric [90/6112256]
May 11 2016 22:42:45.718 EET: RT: updating eigrp 10.4.56.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.718 EET: RT: updating eigrp 10.4.56.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.718 EET: RT: del 10.4.56.0/29 via 10.1.45.5, eigrp metric [90/5753856]
May 11 2016 22:42:45.718 EET: RT: add 10.4.56.0/29 via 10.1.34.3, eigrp metric [90/5677056]
May 11 2016 22:42:45.718 EET: RT: updating eigrp 192.168.4.5/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.718 EET: RT: updating eigrp 192.168.4.5/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.718 EET: RT: del 192.168.4.5/32 via 10.1.45.5, eigrp metric [90/5881856]
May 11 2016 22:42:45.718 EET: RT: add 192.168.4.5/32 via 10.1.34.3, eigrp metric [90/5805056]
May 11 2016 22:42:45.718 EET: RT: updating eigrp 192.168.4.4/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.718 EET: RT: updating eigrp 192.168.4.4/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.718 EET: RT: del 192.168.4.4/32 via 10.1.45.5, eigrp metric [90/6317056]
May 11 2016 22:42:45.718 EET: RT: add 192.168.4.4/32 via 10.1.34.3, eigrp metric [90/6240256]
May 11 2016 22:42:45.718 EET: RT: updating eigrp 10.4.16.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.719 EET: RT: updating eigrp 10.4.16.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.719 EET: RT: del 10.4.16.0/29 via 10.1.45.5, eigrp metric [90/5241856]
May 11 2016 22:42:45.719 EET: RT: add 10.4.16.0/29 via 10.1.34.3, eigrp metric [90/5165056]
May 11 2016 22:42:45.719 EET: RT: updating eigrp 192.168.4.3/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.719 EET: RT: updating eigrp 192.168.4.3/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.719 EET: RT: del 192.168.4.3/32 via 10.1.45.5, eigrp metric [90/5830656]
May 11 2016 22:42:45.719 EET: RT: add 192.168.4.3/32 via 10.1.34.3, eigrp metric [90/5753856]
May 11 2016 22:42:45.719 EET: RT: updating eigrp 10.4.23.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.719 EET: RT: updating eigrp 10.4.23.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.719 EET: RT: del 10.4.23.0/29 via 10.1.45.5, eigrp metric [90/5702656]
May 11 2016 22:42:45.719 EET: RT: add 10.4.23.0/29 via 10.1.34.3, eigrp metric [90/5625856]
May 11 2016 22:42:45.719 EET: RT: updating eigrp 10.4.12.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.719 EET: RT: updating eigrp 10.4.12.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.719 EET: RT: del 10.4.12.0/29 via 10.1.45.5, eigrp metric [90/5216256]
May 11 2016 22:42:45.719 EET: RT: add 10.4.12.0/29 via 10.1.34.3, eigrp metric [90/5139456]
May 11 2016 22:42:45.719 EET: RT: updating eigrp 192.168.4.2/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.719 EET: RT: updating eigrp 192.168.4.2/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.719 EET: RT: del 192.168.4.2/32 via 10.1.45.5, eigrp metric [90/5344256]
May 11 2016 22:42:45.719 EET: RT: add 192.168.4.2/32 via 10.1.34.3, eigrp metric [90/5267456]
May 11 2016 22:42:45.719 EET: RT: updating eigrp 192.168.4.1/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.719 EET: RT: updating eigrp 192.168.4.1/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.719 EET: RT: del 192.168.4.1/32 via 10.1.45.5, eigrp metric [90/4857856]
May 11 2016 22:42:45.719 EET: RT: add 192.168.4.1/32 via 10.1.34.3, eigrp metric [90/4781056]
May 11 2016 22:42:45.719 EET: RT: updating eigrp 10.0.45.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.719 EET: RT: updating eigrp 10.0.45.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.719 EET: RT: del 10.0.45.0/29 via 10.1.45.5, eigrp metric [90/5216256]
May 11 2016 22:42:45.719 EET: RT: add 10.0.45.0/29 via 10.1.34.3, eigrp metric [90/5139456]
May 11 2016 22:42:45.719 EET: RT: updating eigrp 10.4.45.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.719 EET: RT: updating eigrp 10.4.45.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.719 EET: RT: del 10.4.45.0/29 via 10.1.45.5, eigrp metric [90/6265856]
May 11 2016 22:42:45.719 EET: RT: add 10.4.45.0/29 via 10.1.34.3, eigrp metric [90/6189056]
May 11 2016 22:42:45.742 EET: RT: updating eigrp 192.168.4.6/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.742 EET: RT: add 192.168.4.6/32 via 10.1.45.5, eigrp metric [90/5369856]
May 11 2016 22:42:45.784 EET: RT: updating eigrp 192.168.4.6/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.784 EET: RT: updating eigrp 192.168.4.6/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.784 EET: RT: del 192.168.4.6/32 via 10.1.45.5, eigrp metric [90/5369856]
May 11 2016 22:42:45.784 EET: RT: add 192.168.4.6/32 via 10.1.34.3, eigrp metric [90/5293056]
May 11 2016 22:42:45.838 EET: RT: updating eigrp 10.0.15.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.839 EET: RT: add 10.0.15.0/29 via 10.1.34.3, eigrp metric [90/5625856]
May 11 2016 22:42:45.839 EET: RT: updating eigrp 10.5.12.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.840 EET: RT: add 10.5.12.0/29 via 10.1.34.3, eigrp metric [90/5651456]
May 11 2016 22:42:45.840 EET: RT: updating eigrp 192.168.5.4/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.840 EET: RT: add 192.168.5.4/32 via 10.1.34.3, eigrp metric [90/6803456]
May 11 2016 22:42:45.840 EET: RT: updating eigrp 192.168.5.5/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.840 EET: RT: add 192.168.5.5/32 via 10.1.34.3, eigrp metric [90/6291456]
May 11 2016 22:42:45.840 EET: RT: updating eigrp 10.5.16.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.840 EET: RT: add 10.5.16.0/29 via 10.1.34.3, eigrp metric [90/5651456]
May 11 2016 22:42:45.840 EET: RT: updating eigrp 192.168.5.6/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.840 EET: RT: add 192.168.5.6/32 via 10.1.34.3, eigrp metric [90/5779456]
May 11 2016 22:42:45.840 EET: RT: updating eigrp 10.5.45.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.840 EET: RT: add 10.5.45.0/29 via 10.1.34.3, eigrp metric [90/6675456]
May 11 2016 22:42:45.840 EET: RT: updating eigrp 192.168.5.1/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.840 EET: RT: add 192.168.5.1/32 via 10.1.34.3, eigrp metric [90/5267456]
May 11 2016 22:42:45.840 EET: RT: updating eigrp 10.5.56.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.840 EET: RT: add 10.5.56.0/29 via 10.1.34.3, eigrp metric [90/6163456]
May 11 2016 22:42:45.840 EET: RT: updating eigrp 10.5.34.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.840 EET: RT: add 10.5.34.0/29 via 10.1.34.3, eigrp metric [90/6675456]
May 11 2016 22:42:45.840 EET: RT: updating eigrp 10.5.23.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.840 EET: RT: add 10.5.23.0/29 via 10.1.34.3, eigrp metric [90/6163456]
May 11 2016 22:42:45.840 EET: RT: updating eigrp 192.168.5.2/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.841 EET: RT: add 192.168.5.2/32 via 10.1.34.3, eigrp metric [90/5779456]
May 11 2016 22:42:45.841 EET: RT: updating eigrp 192.168.5.3/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.841 EET: RT: add 192.168.5.3/32 via 10.1.34.3, eigrp metric [90/6291456]
May 11 2016 22:42:45.843 EET: RT: updating eigrp 10.0.15.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.843 EET: RT: updating eigrp 10.0.15.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.843 EET: RT: rib update return code: 19
May 11 2016 22:42:45.843 EET: RT: updating eigrp 10.5.12.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.843 EET: RT: updating eigrp 10.5.12.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.843 EET: RT: rib update return code: 19
May 11 2016 22:42:45.843 EET: RT: updating eigrp 192.168.5.4/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.843 EET: RT: updating eigrp 192.168.5.4/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.843 EET: RT: rib update return code: 19
May 11 2016 22:42:45.843 EET: RT: updating eigrp 192.168.5.5/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.844 EET: RT: updating eigrp 192.168.5.5/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.844 EET: RT: rib update return code: 19
May 11 2016 22:42:45.844 EET: RT: updating eigrp 10.5.16.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.844 EET: RT: updating eigrp 10.5.16.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.844 EET: RT: rib update return code: 19
May 11 2016 22:42:45.844 EET: RT: updating eigrp 192.168.5.6/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.844 EET: RT: updating eigrp 192.168.5.6/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.844 EET: RT: rib update return code: 19
May 11 2016 22:42:45.844 EET: RT: updating eigrp 10.5.45.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.844 EET: RT: updating eigrp 10.5.45.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.844 EET: RT: rib update return code: 19
May 11 2016 22:42:45.844 EET: RT: updating eigrp 192.168.5.1/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.844 EET: RT: updating eigrp 192.168.5.1/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.844 EET: RT: rib update return code: 19
May 11 2016 22:42:45.844 EET: RT: updating eigrp 10.5.56.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.844 EET: RT: updating eigrp 10.5.56.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.844 EET: RT: rib update return code: 19
May 11 2016 22:42:45.844 EET: RT: updating eigrp 10.5.34.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.844 EET: RT: updating eigrp 10.5.34.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.844 EET: RT: rib update return code: 19
May 11 2016 22:42:45.844 EET: RT: updating eigrp 10.5.23.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.844 EET: RT: updating eigrp 10.5.23.0/29 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.844 EET: RT: rib update return code: 19
May 11 2016 22:42:45.844 EET: RT:
A1R4#updating eigrp 192.168.5.2/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.844 EET: RT: updating eigrp 192.168.5.2/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.844 EET: RT: rib update return code: 19
May 11 2016 22:42:45.844 EET: RT: updating eigrp 192.168.5.3/32 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:42:45.844 EET: RT: updating eigrp 192.168.5.3/32 (0x0) :
via 10.1.45.5 Se2/0 0
May 11 2016 22:42:45.844 EET: RT: rib update return code: 19
May 11 2016 22:43:24.568 EET: RT: delete route to 10.0.15.0 via 10.1.34.3, eigrp metric [90/5625856]
May 11 2016 22:43:24.568 EET: RT: no routes to 10.0.15.0, delayed flush
May 11 2016 22:43:24.568 EET: RT: delete subnet route to 10.0.15.0/29
May 11 2016 22:43:24.568 EET: RT: updating eigrp 10.0.15.0/29 (0x0) :
via 10.1.34.3 Se2/1 0
May 11 2016 22:43:24.568 EET: RT: rib update return code: 5
ANEXA 6
A4R4#debug ip routing
IP routing debugging is on
A4R4#
May 11 2016 22:42:47.499 EET: RT: delete route to 10.1.34.0 via 10.4.34.3, eigrp metric [90/5549056]
May 11 2016 22:42:47.499 EET: RT: no routes to 10.1.34.0, delayed flush
May 11 2016 22:42:47.499 EET: RT: delete subnet route to 10.1.34.0/29
May 11 2016 22:42:47.499 EET: RT: updating eigrp 10.1.34.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.499 EET: RT: rib update return code: 5
May 11 2016 22:42:47.499 EET: RT: updating eigrp 10.1.34.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.499 EET: RT: add 10.1.34.0/29 via 10.4.45.5, eigrp metric [90/5625856]
May 11 2016 22:42:47.499 EET: RT: delete route to 192.168.1.6 via 10.4.34.3, eigrp metric [90/4729856]
May 11 2016 22:42:47.499 EET: RT: no routes to 192.168.1.6, delayed flush
May 11 2016 22:42:47.499 EET: RT: delete subnet route to 192.168.1.6/32
May 11 2016 22:42:47.500 EET: RT: updating eigrp 192.168.1.6/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.500 EET: RT: rib update return code: 5
May 11 2016 22:42:47.500 EET: RT: updating eigrp 192.168.1.6/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.500 EET: RT: add 192.168.1.6/32 via 10.4.45.5, eigrp metric [90/4806656]
May 11 2016 22:42:47.500 EET: RT: delete route to 10.1.12.0 via 10.4.34.3, eigrp metric [90/4576256]
May 11 2016 22:42:47.500 EET: RT: no routes to 10.1.12.0, delayed flush
May 11 2016 22:42:47.500 EET: RT: delete subnet route to 10.1.12.0/29
May 11 2016 22:42:47.500 EET: RT: updating eigrp 10.1.12.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.500 EET: RT: rib update return code: 5
May 11 2016 22:42:47.500 EET: RT: updating eigrp 10.1.12.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.500 EET: RT: add 10.1.12.0/29 via 10.4.45.5, eigrp metric [90/4653056]
May 11 2016 22:42:47.500 EET: RT: delete route to 192.168.1.3 via 10.4.34.3, eigrp metric [90/5190656]
May 11 2016 22:42:47.500 EET: RT: no routes to 192.168.1.3, delayed flush
May 11 2016 22:42:47.500 EET: RT: delete subnet route to 192.168.1.3/32
May 11 2016 22:42:47.500 EET: RT: updating eigrp 192.168.1.3/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.500 EET: RT: rib update return code: 5
May 11 2016 22:42:47.500 EET: RT: updating eigrp 192.168.1.3/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.500 EET: RT: add 192.168.1.3/32 via 10.4.45.5, eigrp metric [90/5267456]
May 11 2016 22:42:47.500 EET: RT: delete route to 10.1.23.0 via 10.4.34.3, eigrp metric [90/5062656]
May 11 2016 22:42:47.500 EET: RT: no routes to 10.1.23.0, delayed flush
May 11 2016 22:42:47.500 EET: RT: delete subnet route to 10.1.23.0/29
May 11 2016 22:42:47.500 EET: RT: updating eigrp 10.1.23.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.500 EET: RT: rib update return code: 5
May 11 2016 22:42:47.500 EET: RT: updating eigrp 10.1.23.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.500 EET: RT: add 10.1.23.0/29 via 10.4.45.5, eigrp metric [90/5139456]
May 11 2016 22:42:47.500 EET: RT: delete route to 192.168.1.1 via 10.4.34.3, eigrp metric [90/4217856]
May 11 2016 22:42:47.500 EET: RT: no routes to 192.168.1.1, delayed flush
May 11 2016 22:42:47.501 EET: RT: delete subnet route to 192.168.1.1/32
May 11 2016 22:42:47.501 EET: RT: updating eigrp 192.168.1.1/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.501 EET: RT: rib update return code: 5
May 11 2016 22:42:47.501 EET: RT: updating eigrp 192.168.1.1/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.501 EET: RT: add 192.168.1.1/32 via 10.4.45.5, eigrp metric [90/4294656]
May 11 2016 22:42:47.501 EET: RT: delete route to 192.168.1.4 via 10.4.34.3, eigrp metric [90/5677056]
May 11 2016 22:42:47.501 EET: RT: no routes to 192.168.1.4, delayed flush
May 11 2016 22:42:47.501 EET: RT: delete subnet route to 192.168.1.4/32
May 11 2016 22:42:47.501 EET: RT: updating eigrp 192.168.1.4/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.501 EET: RT: rib update return code: 5
May 11 2016 22:42:47.501 EET: RT: updating eigrp 192.168.1.4/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.501 EET: RT: add 192.168.1.4/32 via 10.4.45.5, eigrp metric [90/5753856]
May 11 2016 22:42:47.501 EET: RT: delete route to 192.168.1.5 via 10.4.34.3, eigrp metric [90/5241856]
May 11 2016 22:42:47.501 EET: RT: no routes to 192.168.1.5, delayed flush
May 11 2016 22:42:47.501 EET: RT: delete subnet route to 192.168.1.5/32
May 11 2016 22:42:47.501 EET: RT: updating eigrp 192.168.1.5/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.501 EET: RT: rib update return code: 5
May 11 2016 22:42:47.501 EET: RT: updating eigrp 192.168.1.5/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.501 EET: RT: add 192.168.1.5/32 via 10.4.45.5, eigrp metric [90/5318656]
May 11 2016 22:42:47.501 EET: RT: delete route to 10.1.16.0 via 10.4.34.3, eigrp metric [90/4601856]
May 11 2016 22:42:47.501 EET: RT: no routes to 10.1.16.0, delayed flush
May 11 2016 22:42:47.501 EET: RT: delete subnet route to 10.1.16.0/29
May 11 2016 22:42:47.501 EET: RT: updating eigrp 10.1.16.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.501 EET: RT: rib update return code: 5
May 11 2016 22:42:47.502 EET: RT: updating eigrp 10.1.16.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.502 EET: RT: add 10.1.16.0/29 via 10.4.45.5, eigrp metric [90/4678656]
May 11 2016 22:42:47.502 EET: RT: delete route to 192.168.1.2 via 10.4.34.3, eigrp metric [90/4704256]
May 11 2016 22:42:47.502 EET: RT: no routes to 192.168.1.2, delayed flush
May 11 2016 22:42:47.502 EET: RT: delete subnet route to 192.168.1.2/32
May 11 2016 22:42:47.502 EET: RT: updating eigrp 192.168.1.2/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.502 EET: RT: rib update return code: 5
May 11 2016 22:42:47.502 EET: RT: updating eigrp 192.168.1.2/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.502 EET: RT: add 192.168.1.2/32 via 10.4.45.5, eigrp metric [90/4781056]
May 11 2016 22:42:47.502 EET: RT: delete route to 192.168.56.0 via 10.4.34.3, eigrp metric [90/5574656]
May 11 2016 22:42:47.502 EET: RT: no routes to 192.168.56.0, delayed flush
May 11 2016 22:42:47.502 EET: RT: delete network route to 192.168.56.0/24
May 11 2016 22:42:47.502 EET: RT: updating eigrp 192.168.56.0/24 (0x0)
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.502 EET: RT: rib update return code: 5
May 11 2016 22:42:47.502 EET: RT: updating eigrp 192.168.56.0/24 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.502 EET: RT: add 192.168.56.0/24 via 10.4.45.5, eigrp metric [90/5651456]
May 11 2016 22:42:47.502 EET: RT: delete route to 10.1.45.0 via 10.4.34.3, eigrp metric [90/5625856]
May 11 2016 22:42:47.502 EET: RT: no routes to 10.1.45.0, delayed flush
May 11 2016 22:42:47.502 EET: RT: delete subnet route to 10.1.45.0/29
May 11 2016 22:42:47.502 EET: RT: updating eigrp 10.1.45.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.502 EET: RT: rib update return code: 5
May 11 2016 22:42:47.502 EET: RT: updating eigrp 10.1.45.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.502 EET: RT: add 10.1.45.0/29 via 10.4.45.5, eigrp metric [90/5702656]
May 11 2016 22:42:47.502 EET: RT: delete route to 10.1.56.0 via 10.4.34.3, eigrp metric [90/5113856]
May 11 2016 22:42:47.502 EET: RT: no routes to 10.1.56.0, delayed flush
May 11 2016 22:42:47.502 EET: RT: delete subnet route to 10.1.56.0/29
May 11 2016 22:42:47.502 EET: RT: updating eigrp 10.1.56.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.502 EET: RT: rib update return code: 5
May 11 2016 22:42:47.502 EET: RT: updating eigrp 10.1.56.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.502 EET: RT: add 10.1.56.0/29 via 10.4.45.5, eigrp metric [90/5190656]
May 11 2016 22:42:47.534 EET: RT: updating eigrp 10.0.12.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.534 EET: RT: eigrp's 10.0.12.0/29 (via 10.4.34.3) metric changed from distance/metric [90 /4601856] to [90/4653056]
May 11 2016 22:42:47.534 EET: RT: updating eigrp 10.0.12.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.534 EET: RT: rib update return code: 19
May 11 2016 22:42:47.562 EET: RT: updating eigrp 10.0.12.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.563 EET: RT: updating eigrp 10.0.12.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.563 EET: RT: rib update return code: 19
May 11 2016 22:42:47.607 EET: RT: delete route to 10.1.34.0 via 10.4.45.5, eigrp metric [90/5625856]
May 11 2016 22:42:47.607 EET: RT: no routes to 10.1.34.0, delayed flush
May 11 2016 22:42:47.607 EET: RT: delete subnet route to 10.1.34.0/29
May 11 2016 22:42:47.607 EET: RT: updating eigrp 10.1.34.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.607 EET: RT: rib update return code: 5
May 11 2016 22:42:47.607 EET: RT: delete route to 192.168.1.6 via 10.4.45.5, eigrp metric [90/4806656]
May 11 2016 22:42:47.607 EET: RT: no routes to 192.168.1.6, delayed flush
May 11 2016 22:42:47.608 EET: RT: delete subnet route to 192.168.1.6/32
May 11 2016 22:42:47.608 EET: RT: updating eigrp 192.168.1.6/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.608 EET: RT: rib update return code: 5
May 11 2016 22:42:47.608 EET: RT: delete route to 10.1.12.0 via 10.4.45.5, eigrp metric [90/4653056]
May 11 2016 22:42:47.608 EET: RT: no routes to 10.1.12.0, delayed flush
May 11 2016 22:42:47.608 EET: RT: delete subnet route to 10.1.12.0/29
May 11 2016 22:42:47.608 EET: RT: updating eigrp 10.1.12.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.608 EET: RT: rib update return code: 5
May 11 2016 22:42:47.608 EET: RT: delete route to 192.168.1.3 via 10.4.45.5, eigrp metric [90/5267456]
May 11 2016 22:42:47.608 EET: RT: no routes to 192.168.1.3, delayed flush
May 11 2016 22:42:47.608 EET: RT: delete subnet route to 192.168.1.3/32
May 11 2016 22:42:47.608 EET: RT: updating eigrp 192.168.1.3/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.608 EET: RT: rib update return code: 5
May 11 2016 22:42:47.608 EET: RT: delete route to 10.1.23.0 via 10.4.45.5, eigrp metric [90/5139456]
May 11 2016 22:42:47.608 EET: RT: no routes to 10.1.23.0, delayed flush
May 11 2016 22:42:47.608 EET: RT: delete subnet route to 10.1.23.0/29
May 11 2016 22:42:47.608 EET: RT: updating eigrp 10.1.23.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.608 EET: RT: rib update return code: 5
May 11 2016 22:42:47.608 EET: RT: delete route to 192.168.1.1 via 10.4.45.5, eigrp metric [90/4294656]
May 11 2016 22:42:47.608 EET: RT: no routes to 192.168.1.1, delayed flush
May 11 2016 22:42:47.608 EET: RT: delete subnet route to 192.168.1.1/32
May 11 2016 22:42:47.608 EET: RT: updating eigrp 192.168.1.1/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.608 EET: RT: rib update return code: 5
May 11 2016 22:42:47.608 EET: RT: delete route to 192.168.1.4 via 10.4.45.5, eigrp metric [90/5753856]
May 11 2016 22:42:47.608 EET: RT: no routes to 192.168.1.4, delayed flush
May 11 2016 22:42:47.608 EET: RT: delete subnet route to 192.168.1.4/32
May 11 2016 22:42:47.608 EET: RT: updating eigrp 192.168.1.4/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.608 EET: RT: rib update return code: 5
May 11 2016 22:42:47.608 EET: RT: delete route to 192.168.1.5 via 10.4.45.5, eigrp metric [90/5318656]
May 11 2016 22:42:47.608 EET: RT: no routes to 192.168.1.5, delayed flush
May 11 2016 22:42:47.608 EET: RT: delete subnet route to 192.168.1.5/32
May 11 2016 22:42:47.608 EET: RT: updating eigrp 192.168.1.5/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.609 EET: RT: rib update return code: 5
May 11 2016 22:42:47.609 EET: RT: delete route to 10.1.16.0 via 10.4.45.5, eigrp metric [90/4678656]
May 11 2016 22:42:47.609 EET: RT: no routes to 10.1.16.0, delayed flush
May 11 2016 22:42:47.609 EET: RT: delete subnet route to 10.1.16.0/29
May 11 2016 22:42:47.609 EET: RT: updating eigrp 10.1.16.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.609 EET: RT: rib update return code: 5
May 11 2016 22:42:47.609 EET: RT: delete route to 192.168.1.2 via 10.4.45.5, eigrp metric [90/4781056]
May 11 2016 22:42:47.609 EET: RT: no routes to 192.168.1.2, delayed flush
May 11 2016 22:42:47.609 EET: RT: delete subnet route to 192.168.1.2/32
May 11 2016 22:42:47.609 EET: RT: updating eigrp 192.168.1.2/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.609 EET: RT: rib update return code: 5
May 11 2016 22:42:47.609 EET: RT: delete route to 192.168.56.0 via 10.4.45.5, eigrp metric [90/5651456]
May 11 2016 22:42:47.609 EET: RT: no routes to 192.168.56.0, delayed flush
May 11 2016 22:42:47.609 EET: RT: delete network route to 192.168.56.0/24
May 11 2016 22:42:47.609 EET: RT: updating eigrp 192.168.56.0/24 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.609 EET: RT: rib update return code: 5
May 11 2016 22:42:47.609 EET: RT: delete route to 10.1.45.0 via 10.4.45.5, eigrp metric [90/5702656]
May 11 2016 22:42:47.609 EET: RT: no routes to 10.1.45.0, delayed flush
May 11 2016 22:42:47.609 EET: RT: delete subnet route to 10.1.45.0/29
May 11 2016 22:42:47.609 EET: RT: updating eigrp 10.1.45.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.609 EET: RT: rib update return code: 5
May 11 2016 22:42:47.609 EET: RT: delete route to 10.1.56.0 via 10.4.45.5, eigrp metric [90/5190656]
May 11 2016 22:42:47.609 EET: RT: no routes to 10.1.56.0, delayed flush
May 11 2016 22:42:47.609 EET: RT: delete subnet route to 10.1.56.0/29
May 11 2016 22:42:47.609 EET: RT: updating eigrp 10.1.56.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.609 EET: RT: rib update return code: 5
May 11 2016 22:42:47.878 EET: RT: updating eigrp 10.1.34.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.878 EET: RT: add 10.1.34.0/29 via 10.4.45.5, eigrp metric [90/6189056]
May 11 2016 22:42:47.878 EET: RT: updating eigrp 192.168.1.6/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.878 EET: RT: add 192.168.1.6/32 via 10.4.45.5, eigrp metric [90/5369856]
May 11 2016 22:42:47.879 EET: RT: updating eigrp 10.1.12.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.879 EET: RT: add 10.1.12.0/29 via 10.4.45.5, eigrp metric [90/5216256]
May 11 2016 22:42:47.879 EET: RT: updating eigrp 192.168.1.3/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.879 EET: RT: add 192.168.1.3/32 via 10.4.45.5, eigrp metric [90/5830656]
May 11 2016 22:42:47.879 EET: RT: updating eigrp 10.1.23.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.879 EET: RT: add 10.1.23.0/29 via 10.4.45.5, eigrp metric [90/5702656]
May 11 2016 22:42:47.879 EET: RT: updating eigrp 192.168.1.1/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.879 EET: RT: add 192.168.1.1/32 via 10.4.45.5, eigrp metric [90/4857856]
May 11 2016 22:42:47.879 EET: RT: updating eigrp 192.168.1.4/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.879 EET: RT: add 192.168.1.4/32 via 10.4.45.5, eigrp metric [90/6317056]
May 11 2016 22:42:47.879 EET: RT: updating eigrp 192.168.1.5/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.879 EET: RT: add 192.168.1.5/32 via 10.4.45.5, eigrp metric [90/5881856]
May 11 2016 22:42:47.879 EET: RT: updating eigrp 10.1.16.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.879 EET: RT: add 10.1.16.0/29 via 10.4.45.5, eigrp metric [90/5241856]
May 11 2016 22:42:47.880 EET: RT: updating eigrp 192.168.1.2/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.880 EET: RT: add 192.168.1.2/32 via 10.4.45.5, eigrp metric [90/5344256]
May 11 2016 22:42:47.880 EET: RT: updating eigrp 192.168.56.0/24 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.880 EET: RT: add 192.168.56.0/24 via 10.4.45.5, eigrp metric [90/6214656]
May 11 2016 22:42:47.880 EET: RT: updating eigrp 10.1.45.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.880 EET: RT: add 10.1.45.0/29 via 10.4.45.5, eigrp metric [90/6265856]
May 11 2016 22:42:47.880 EET: RT: updating eigrp 10.1.56.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.880 EET: RT: add 10.1.56.0/29 via 10.4.45.5, eigrp metric [90/5753856]
May 11 2016 22:42:47.889 EET: RT: updating eigrp 10.1.34.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.890 EET: RT: updating eigrp 10.1.34.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.890 EET: RT: del 10.1.34.0/29 via 10.4.45.5, eigrp metric [90/6189056]
May 11 2016 22:42:47.890 EET: RT: add 10.1.34.0/29 via 10.4.34.3, eigrp metric [90/6112256]
May 11 2016 22:42:47.890 EET: RT: updating eigrp 192.168.1.6/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.890 EET: RT: updating eigrp 192.168.1.6/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.890 EET: RT: del 192.168.1.6/32 via 10.4.45.5, eigrp metric [90/5369856]
May 11 2016 22:42:47.890 EET: RT: add 192.168.1.6/32 via 10.4.34.3, eigrp metric [90/5293056]
May 11 2016 22:42:47.890 EET: RT: updating eigrp 10.1.12.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.890 EET: RT: updating eigrp 10.1.12.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.890 EET: RT: del 10.1.12.0/29 via 10.4.45.5, eigrp metric [90/5216256]
May 11 2016 22:42:47.890 EET: RT: add 10.1.12.0/29 via 10.4.34.3, eigrp metric [90/5139456]
May 11 2016 22:42:47.890 EET: RT: updating eigrp 192.168.1.3/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.890 EET: RT: updating eigrp 192.168.1.3/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.890 EET: RT: del 192.168.1.3/32 via 10.4.45.5, eigrp metric [90/5830656]
May 11 2016 22:42:47.890 EET: RT: add 192.168.1.3/32 via 10.4.34.3, eigrp metric [90/5753856]
May 11 2016 22:42:47.890 EET: RT: updating eigrp 10.1.23.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.890 EET: RT: updating eigrp 10.1.23.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.890 EET: RT: del 10.1.23.0/29 via 10.4.45.5, eigrp metric [90/5702656]
May 11 2016 22:42:47.890 EET: RT: add 10.1.23.0/29 via 10.4.34.3, eigrp metric [90/5625856]
May 11 2016 22:42:47.891 EET: RT: updating eigrp 192.168.1.1/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.891 EET: RT: updating eigrp 192.168.1.1/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.891 EET: RT: del 192.168.1.1/32 via 10.4.45.5, eigrp metric [90/4857856]
May 11 2016 22:42:47.891 EET: RT: add 192.168.1.1/32 via 10.4.34.3, eigrp metric [90/4781056]
May 11 2016 22:42:47.891 EET: RT: updating eigrp 192.168.1.4/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.891 EET: RT: updating eigrp 192.168.1.4/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.891 EET: RT: del 192.168.1.4/32 via 10.4.45.5, eigrp metric [90/6317056]
May 11 2016 22:42:47.891 EET: RT: add 192.168.1.4/32 via 10.4.34.3, eigrp metric [90/6240256]
May 11 2016 22:42:47.891 EET: RT: updating eigrp 192.168.1.5/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.891 EET: RT: updating eigrp 192.168.1.5/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.891 EET: RT: del 192.168.1.5/32 via 10.4.45.5, eigrp metric [90/5881856]
May 11 2016 22:42:47.891 EET: RT: add 192.168.1.5/32 via 10.4.34.3, eigrp metric [90/5805056]
May 11 2016 22:42:47.891 EET: RT: updating eigrp 10.1.16.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.891 EET: RT: updating eigrp 10.1.16.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.891 EET: RT: del 10.1.16.0/29 via 10.4.45.5, eigrp metric [90/5241856]
May 11 2016 22:42:47.892 EET: RT: add 10.1.16.0/29 via 10.4.34.3, eigrp metric [90/5165056]
May 11 2016 22:42:47.892 EET: RT: updating eigrp 192.168.1.2/32 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.892 EET: RT: updating eigrp 192.168.1.2/32 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.892 EET: RT: del 192.168.1.2/32 via 10.4.45.5, eigrp metric [90/5344256]
May 11 2016 22:42:47.892 EET: RT: add 192.168.1.2/32 via 10.4.34.3, eigrp metric [90/5267456]
May 11 2016 22:42:47.892 EET: RT: updating eigrp 192.168.56.0/24 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.892 EET: RT: updating eigrp 192.168.56.0/24 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.892 EET: RT: del 192.168.56.0/24 via 10.4.45.5, eigrp metric [90/6214656]
May 11 2016 22:42:47.892 EET: RT: add 192.168.56.0/24 via 10.4.34.3, eigrp metric [90/6137856]
May 11 2016 22:42:47.892 EET: RT: updating eigrp 10.1.45.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.892 EET: RT: updating eigrp 10.1.45.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.892 EET: RT: del 10.1.45.0/29 via 10.4.45.5, eigrp metric [90/6265856]
May 11 2016 22:42:47.892 EET: RT: add 10.1.45.0/29 via 10.4.34.3, eigrp metric [90/6189056]
May 11 2016 22:42:47.892 EET: RT: updating eigrp 10.1.56.0/29 (0x0) :
via 10.4.45.5 Se2/0 0
May 11 2016 22:42:47.892 EET: RT: updating eigrp 10.1.56.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:42:47.892 EET: RT: del 10.1.56.0/29 via 10.4.45.5, eigrp metric [90/5753856]
May 11 2016 22:42:47.892 EET: RT:
A4R4#add 10.1.56.0/29 via 10.4.34.3, eigrp metric [90/5677056]
A4R4#
May 11 2016 22:43:24.405 EET: RT: delete route to 10.0.15.0 via 10.4.34.3, eigrp metric [90/4089856]
May 11 2016 22:43:24.405 EET: RT: no routes to 10.0.15.0, delayed flush
May 11 2016 22:43:24.405 EET: RT: delete subnet route to 10.0.15.0/29
May 11 2016 22:43:24.405 EET: RT: updating eigrp 10.0.15.0/29 (0x0) :
via 10.4.34.3 Se2/1 0
May 11 2016 22:43:24.405 EET: RT: rib update return code: 5
A4R4#
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Analiza performanțelor de rutare în cazul protcoalelor OSPF și EIGRP [306343] (ID: 306343)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.