Cine a lucrat cu protocolul EIGRP a auzit cu siguranta de formula minune dupa care se calculeaza metrica. In opinia mea, cel care a inventat-o nu a avut in minte decat sa faca un lucru cat mai complicat cu putinta, ca sa le ia mai multi bani celor de la CISCO. Altfel eu nu-mi explic de ce se folosesc atat de multe variabile fara nici un fel de sens.
EIGRP metric = 256 * [K1 * bandwidth + (K2 * bandwidth) / (256 – load) + K3 * delay] * [K5 / (reliability + K4)]
Desi in 99.9% din cazuri K1=K3=1 si K2=K4=K5=0 deci formula se simplifica la 256 * (bandwidth + delay), lucrurile incurcate continua pentru ca trebuie sa tinem cont ca EIGRP bandwidth este 10^7 / Interface bandwidth (in kbps) iar EIGRP delay se calculeaza Interface delay ( apare in microsecunde) / 10 (practic ce setezi pe interfata aia se considera in calculul metricii pentru ca valoarea setata este in zeci de microsecunde). Mai mult decat atat, daca “tranzitam” mai multe link-uri de la sursa pana la destinatie, EIGRP bandwidth este de fapt [ 10^7 / valoarea minima dintre toate valorile bandwidth de pe traseu ] iar EIGRP delay este singurul care se insumeaza. Formula devine mai exact 256 * [ 10^7 / min (bandwidth ) + sum (delay)], unde bandwidth si delay sunt chiar valorile setate “de mana” pe interfata.
Acelasi lucru este valabil si cand facem redistribute dintr-un alt protocol in EIGRP si ni se cere sa specificam valorile bandwidth, delay …etc. Valorile introduse de noi acolo NU sunt EIGRP bandwidth si EIGRP delay ci trebuie sa le transformam dupa formulele de mai sus pentru a obtine corect metrica EIGRP. Asadar, comanda “redistribute ospf 1 metric 10000 100 ….” duce la o metrica de 256 * ( 10^7/10^4 + 100*10) = 256 * 2000 = 512000 si asta in cazul cel mai simplu posibil, cand avem K2=K4=K5=0. Deci daca exista o interfata de 1Mbps atunci valoarea bandwidth folosita in formula de calcul a metricii EIGRP este 10^7 / 10^3 = 10000.
Explicatia pentru care delay-ul a fost luat in calcul este ca link-urile cu delay mai mare trebuie sa aiba implicit o metrica mai mare si deci sa fie evitate. Evident ca nu se tine cont de delay-ul real, ar fi fost o nebunie fara margini ca in momentul in care creste delay-ul pe un link sa se modifice metrica, sa se mute traficul prin alta parte si tot asa. Practic, delay-ul se introduce pe fiecare interfata in parte “de mana”, cu comanda delay si pentru ca algoritmul minune sa coste mai multi bani pe cei de la CISCO, valoarea introdusa defineste zecile de microsecunde. Reliability ia valori intre 0 si 255 iar 255 inseamna ca link-ul e 100% reliable, load intre 1 si 255 iar MTU e de obicei 1500, dar dupa mintea mea nu influenteaza valoarea metricii EIGRP calculata dupa formula amintita mai sus indiferent cata matematica ai sti. Aceste ultime 3 valori insa sunt eliminate de cele 3 constante K2, K4 si K5 care in majoritatea cazurilor sunt 0.
In opinia mea, EIGRP-ul este un protocol potrivit pentru un “enterprise” fara MPLS TE, daca suntem atenti la faptul ca o buna convergenta (chiar mai buna ca la OSPF sau IS-IS) se obtine NU modificand timerii ca la celelalte doua protocoale ci asigurandu-ne in momentul in care facem design la topologie, ca vom avea FS (feasable succesor). De asemenea, poate balansa pe link-uri cu costuri inegale si acest lucru de asemenea reprezinta un plus. Formula dupa care se calculeaza metrica este insa o mare pacaleala.
MTU NU intervine in calcularea metricii EIGRP!
K5 are un termen specific, modificator, iar delay-ul este cumulat, nu numai cel de pe un link.
Apreciez EIGRP ca fiind foarte puternic tocmai prin granularitatea metricii suportand load-balancing pe linkuri de cost diferit, depasind la capitolul IGP, OSPF-ul in unele situatii, cu penalizarea ca trebuie sa ai in retea doar Cisco.
Suportul IP, AppleTalk si IPX e un avantaj in unele retele neomogene. De asemeni si sumarizarea manuala pe orice interfata.
Daca avem din start K5=0 ultima parte a ecuatiei se simplifica, asta e clar. O buna convergenta se obtine modificand Hold si Hello time.
Daca interfata prin care se stabileste vecinatatea pica si IOS-ul schimba starea ei in orice altceva decat Up/Up, atunci ruterul stie instantaneu ca vecinul i-a cazut. In unele situatii, interfata ramane Up/Up in timp ce conexiunea nu mai poate fi folosita. In astfel de cazuri, convergenta EIGRP se bazeaza pe expirarea Hold Timer, care e 15s pe link-uri FastEthernet si 60s pe T1.
Daca un Hello nu e receptionat in 15s, vecinatatea cade. Pentru astfel de situatii, se reduc Hello si Hold Timer, acceptand un consum al benzii mai mare in schimb.
O remarca: IOS permite Hold Timer mai mic decat Hello, caz in care vecinatatea cade si se ridica, ruta flappand.
Cu maximum-path si variance, routerul poate balansa traficul proportional cu metrica, asta insemnand ca o metrica mai mica trimite mai multe packete, celelalte rute fiind in tabela pentru o convergenta rapida in cazul in care ruta cea mai buna cade.
@Dan: foarte interesant comentariul tau, chiar mi-a placut; trebuie insa adaugate cateva observatii pentru ca lucrurile sa devina si mai clare decat atat. daca vrem sa fim exacti pana la capat, exista conditii in care MTU influenteaza alegerea “best path” in EIGRP (las pe altcineva sa dezvolte daca stie despre ce este vorba), modificarea “timerilor” poate imbunatati convergenta EIGRP asa cum ai spus tu, dar niciodata nu vei obtine convergenta mai buna ca la OSPF / IS-IS doar facand acest lucru, ci numai tinand cont de topologie si de “feasable succesor” asa cum am scris initial iar “dead-interval” poate fi setat mai mic decat “hello” si in OSPF (cu exact aceleasi consecinte).
Suportul IP, AppleTalk si IPX e un avantaj in unele retele neomogene, de acord cu asta, insa in ziua de astazi retelele au devenit neomogene la nivel de “vendor/hardware”, drept pentru care EIGRP-ul, ca de altfel orice protocol proprietar pierde serios teren. Chiar CISCO a scos EIGRP-ul de pe platformele cu IOS XR (CRS, ASR-9K) pentru ca nu-si mai are rostul intr-un mediu “service provider” … cat despre suportul pentru MPLS TE, asta chiar face diferenta fata de OSPF si IS-IS intr-un ISP.
Pentru ca mi s-a sugerat ca un exemplu concret face cat o mie de cuvinte o sa ma conformez:
Fie doua routere R1, R2 directe conectate, intre care ruleaza EIGRP si interfata Loopback0 configurata pe R2 cu adresa 2.2.2.2/32.
R1 (fa0/1) —–EIGRP—– (fa0/1) R2 (Lo0)
Ne propunem sa observam metrica EIGRP cu care apare 2.2.2.2/32 in tabela de rutare a lui R1.
R1, R2:
interface FastEthernet2/1bandwidth 100000
delay 10
R2:
interface Loopback0bandwidth 10000
ip address 2.2.2.2 255.255.255.255
delay 30
min (bandwidth) = min (100000, 10000) = 10000 kbps => EIGRP bandwidth = 10^7 / 10000 = 1000
sum (delay) = sum (10, 30) = 40 tens of microseconds => EIGRP delay = 40
EIGRP metric = 256 * (1000 + 40) = 266240
R1# sh ip ro 2.2.2.2Routing entry for 2.2.2.2/32
Known via "eigrp 100", distance 90, metric 266240, type internal
Redistributing via eigrp 100
Last update from 12.12.12.1 on FastEthernet0/1, 00:00:43 ago
Routing Descriptor Blocks:
* 12.12.12.1, from 12.12.12.1, 00:00:43 ago, via FastEthernet0/1
Route metric is 266240, traffic share count is 1
Total delay is 400 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Oricat am creste bandwidth de pe R1 (fa0/1), metrica nu se va modifica pentru ca minimum bandwidth va ramane tot timpul 10000 Kbit setat pe R2 / Lo0.
R1:
interface FastEthernet2/1bandwidth 150000
delay 10
R1# sh ip ro 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "eigrp 100", distance 90, metric 266240, type internal
Daca insa scadem bandwidth sub valoarea 10000 setata pe R2 / Lo0 se va modifica mininum bandwidth si implicit metrica:
R1:
interface FastEthernet2/1bandwidth 7000
delay 10
EIGRP metric = 256 * (10^7 / 7000 + 40) = 375954
R1# sh ip ro 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "eigrp 100", distance 90, metric 375954, type internal