EIGRP-facts.pdf

Cisco Networking Academy

www.infoacademy.net

I n f o a c a d e m y

Page 1

EIGRP (Enhanced Interior Gateway Routing Protocol) IPv4 v 1.8.8

1. Generalitati 2. Tabele EIGRP 3. Mesaje EIGRP 4. Conditii de stabilire a relatiei de vecinatate 5. Metrica 6. Algoritmul DUAL ; DUAL Finite State Machine 7. Load sharing 8. Sumarizare 9. Ruta default 10. Autentificare 11. Scalabilitate si optimizare 12. Filtrarea de rute 13. Troubleshooting 14. Miscelanee 15. Referinte

1. Generalitati EIGRP este un protocol IGP (Interior Gateway Protocol) proprietar Cisco de tip distance vector, capabil sa

trimita informatie de routare pentru IPv4, IPv6, IPX, AppleTalk. Este un protocol de routare classless, adica trimite NM in update-urile sale.

Algoritmul de rutare poarta denumirea de DUAL (Diffusing Update Algorithm) si are la baza cercetarile lui Dr.

J.J. Garcia-Luna-Aceves. Este un protocol menit sa inlocuiasa IGRP-ul, protocol classfull, si el proprietar Cisco, scoz din uz incepand cu IOS 12.2(13)T si 12.2(R1s4)S, cu care are in comun formula de calcul a metricii, unequal load sharing si conceptul de domeniu de routare (sau process domain).

Componentele EIGRP sunt: - PDM (Protocol Dependent Module), - mecanismul de (re)descoperire/mentinere a vecinilor EIGRP, - algoritmul DUAL si -

inseamna ca EIGRP schimba mesaje cu confirmare de primire (ex: Update) cat si mesaje fara confirmare de primire (ex: Ack), dupa caz.

EIGRP este proiectat sa foloseasca in

mesajele sale structuri tertiare de tip TLV (Type/Length/Value). Acest lucru, ca si proiectarea sa folosind module software (PDM), permite ulterior upgrade-uri facile.


www.infoacademy.net


Page 2

Pentru schimbul de mesaje in retelele IPv4 EIGRP foloseste header IPv4 cu protocol number 88, IP destinatie multicast well-known 224.0.0.10 sau unicast, IP-ul sursa este IP-ul principal al interfetei de iesire si un TTL de 2. In cazul retelelor Ethernet adresa MAC destinatie este 0100.5E00.000A .

EIGRP a fost proiectat sa permita schimbul de mesaje de control intr-o maniera eficienta, trimitand update-uri de routare doar cu informatia de noutate (incremental), doar cand este nevoie (flash), si doar router-elor

bounded). EIGRP permite limitarea BW utilizat de traficul propriu, fapt util in retele WAN Frame Relay unde CIR ul

(Commited Information Rate) unui VC (Virtual Circuit) este adesea mai mic decat AR (Access Rate) link-ului de acces. By-default, EIGRP foloseste pana la 50% din BW administrativ al interfetei/subinterfetei pentru generarea mesajelor sale, procent configurabil.

Este un protocol scalabil, utilizabil in retele atat medii cat si mari, ce presupune insa intr-o retea de dimensiuni mari o atentie deosebita alocata mentinerii stabilitati informatiei de routare (a se vedea discutia de la punctul 11).

Are avantajele unei configurari simple (cel putin minimal) - similare cu cea a RIP-ului, a unui timp de convergenta foarte mic (mai ales a folosirii unor minime resurse de BW, RAM, CPU si a faptului ca poate tine cont de BW-rile diferite din interretea in alegerea caii optime.

Fiind un protocol de rutare classless poate fi utilizat in interretele cu design IP de tip SLSM, VLSM, subretele discontinue cat si classless (superretele).

Dezavantajul principal al EIGRP este caracterul proprietar.

2. Tabele EIGRP

EIGRP intretine 2 tabele proprii, anume tabela cu vecini (neighbor table) (topology table). 1. Neighbor table contine o lista a routerelor vecine EIGRP (routere direct conectate logic sau si fizic [1])

impreuna cu caracteristici de interes ale acestora, anume: - Handle: ordinea descoperirii vecinilor de catre routerul nostru. - Address: IP-ul sursa al mesajelor vecinului (IP-ul sau principal). - Interface: Numele interfetei locale catre vecin. - Hold: Timpul pana la pierderea relatiei de vecinatate in absenta oricarui mesaj EIGRP de la vecin. - Uptime: Timpul trecut de cand am stabilit ultima data relatia de vecinatate. - SRTT (Smooth Round Trip Time): Timpul (in ms) mediu necesar primirii confirmarii unui

mesaj reliable trimis vecinului. Se poate schimba in timp. Depinde de BW si de CPU vecin. - RTO (Retransmision Time Out): Timpul de asteptare pana la retransmiterea unui mesaj reliable unicast

anterior trimis vecinului si pentru care nu am primit confirmarea. Poate varia intre 200ms si 5000ms. Valoarea sa este data de formula: 6 * SRTT (dar intre limitele anterioare).

- Q Count (queue): Numarul de mesaje ce urmeaza a fi trimise reliable catre vecin. DUAL transmite aceste mesaje in ordine; daca nu s-a primit confirmarea pentru primul dintre ele nu se vor trimite celelalte. Se utilizeaza o fereastra de confirmare de un mesaj.

- Seqence Number: Ultimul numar de secventa primit de la vecin in mesajele sale trimise reliable catre noi.

- Numarul de prefixe primit de la vecin. - Configurari speciale ale vecinului, de exemplu EIGRP STUB. - Configurare locala statica (am folosit comanda neighbor) - Versiunea majora si minora a IOS-ului si versiunea EIGRP a vecinului.


www.infoacademy.net


Page 3

[1] -direct conectat, adesea la multe routere fizice distanta.

TTL-ul de 2 permite schimbul de mesaje cu 1 router la un vecin-fizic distanta, daca utilizam mesaje EIGRP unicast acesta este caz special rar intalnit in practica.

Un prim pas in troubleshooting-ul EIGRP este vizualizarea tabelei cu vecini: Router# show ip eigrp [] neighbors [detail | static] []

2. Topology table [2] contine: - retele de configurarea locala a EIGRP prin comanda network , - retele invatate de EIGRP de la vecinii sai, - retele redistribuite (manual sau automat) din alt protocol de rutare (static, OSPF, EIGRP alt ASN, sa) prin

comanda redistribute si comanda network , - retele rezultate in urma sumarizarii (automate sau manuale) prin comanda auto-summary si ip

summary-address. [2] tehnic, tabela nu contine informatii topologice ce ar permite reconstructia topologica (harta) a retelei. Acest lucru este valabil doar in cazul protocoalelor de tip link-state. Prefixele din tabela topologica contin informatii asociate, utile algoritmului DUAL in calculul rutei optime, cat si in evitarea buclelor de rutare. Acestea sunt: FD (Feasible Distance) si RD (Reported Distance), starea rutei (Activa sau Pasiva), detalii despre metrica in format vectorial (BW, delay, load ...), tipul rutei (Interna sau Externa), NEXT-HOP cat si sursa update-ului de routare (router-ul de la care a parvenit Update-ul; pot diferi aceste ultime doua adrese IP), timpul trecut de la ultimul Update, flag-uri asociate (Q query, R Reply, U

interfata de iesire, sa.


www.infoacademy.net


Page 4

3. Mesaje EIGRP EIGRP foloseste pentru schimbul de informatii IPv4 mesajele: Hello, Update, Query, Ack, Reply, Request, SIA

Query, SIA Reply, Goodbye.

Fiecare din aceste mesaje are un header EIGRP de forma: Version versiunea EIGRP (curent 3), Opcode tipul de pachet (1 Update, 3 Query, 4 Reply, 5 Hello/Ack, 10 SIA Query, SIA Reply), Checksum se aplica asupra intregului mesaj EIGRP, fara

headerul IP, Flags 0x00000001 Init si 0x00000002 Conditional Receive, bit

folosit de algoritmul proprietar in schimbarea reliable a mesajelor multicast,

Sequence numar pe 32 de biti folosit de RTP pentru schimbul reliable de mesaje, ACK ultimul numar de secventa (transmis pe 32 de biti) al mesajelor reliable primite de la vecinul caruia ii

trimitem acest Ack. Un mesaj cu Ack number egal cu 0 este defapt un mesaj Hello. AS (Autonomous System) process-domain-ul EIGRP, TLV (Type Length Value) ce urmeaza contin informatii de interes pentru:

- alegerea rutei optime (prefixe interne IPv4 TLV 0x0102 sau externe IPv4 TLV 0x0103), - negocierea vecinatatii (TLV 0x0001), - pentru schimbul reliable de mesaje (TLV 0x0003 si 0x0005), - altele.

Principalele mesaje EIGRP utilizate pentru IP: Hello [type 5] este folosit pentru descoperirea, mentinerea si redescoperirea vecinilor EIGRP. Se trimite unreliable si, de regula, multicast. Acknowledgment [type 5] este folosit la confirmarea primirii de mesaje de tip Update, Query si Reply, SIA Query, SIA Reply. Este in fapt un mesaj Hello fara date (TLV-uri). EIGRP este proiectat sa trimita la nevoie si confirmari prin intermediul mesajelor Update, Query si Reply folosindu-se de acelasi camp Ack din headerul EIGRP ca si mesajul Ack. Update [type 1] este folosit pentru a propaga informatia de routare. Sunt trimise reliable si multicast


www.infoacademy.net


Page 5

exceptii: in retele point-to-point unde se trimit unicast si in urma descoperirii unui nou vecin. Daca, odata trimise multicast, nu se primeste un Ack de la un vecin, se va retransmite dupa multicast flow timer acel Update respectivului vecin sub forma unicast.

dupa cum s-a mentionat deja. Ele contin TLV-uri ce descriu prefixele EIGRP. Query/Reply [type 3/4] sunt folosite pentru interogarea/primirea raspunsului la interogarea anterioara a routerelor vecine in scopul finalizarii operatiilor DUAL difuzate. Ambele mesaje se trimit reliable. Query-urile pot fi trimise atat multicast cat si unicast. Reply-urile se trimit doar unicast.

Daca algoritmul DUAL cere ca schimbul de mesaje sa se realizeaza reliable iar unul din vecini nu trimite un Ack in timp util, routerul nostru va retransmite de 16 ori acelasi mesaj respectivului vecin sub forma de unicast. Time-out-ul intre retransmisiile unicast este redat de RTO-ul calculat local pentru respectivul router. Daca in final nu primim un Ack vom renunta la relatia de vecinatate dupa intervalul de timp egal cu maximul dintre Hold-time si timpul necesar retransmisiei de 16 ori a mesajului initial. Intervalul de timp necesar celor 16 retransmisii este de regula intre 50 de 80 sec.

Intervalul de timp necesar trecerii de la multicast la unicast este specificat de multicast flow timer. Atat acesta cat si RTO sunt calculate per vecin tinand cont de SRTT.

4. Conditii de stabilire a relatiei de vecinatate - Aceleasi valori ale K-urilor, - Acelasi tip/configurari de autentificare, - Acelasi numar de sistem autonom, intre 1 si 65535 (0 este o valoare nepermisa), - IP-ul sursa al Hello-ului (ce va fi intodeauna IP-ul principal al interfetei) sa faca parte dintr-unul din

spatiile de adrese IP de pe interfata corespunzatoare a celuilalt router (inclusiv dintr-un spatiu de adrese IP secundar),

- Network Mask-uri identice (sau cel putin corespunzatoare) configurate pe interfetele celor 2 vecini. - In IOS-urile recente (> 15.0) router ID-ul (RID-ul) routerelor vecine trebuie sa fie unic.

Acesti parametrii (exceptand NM si RID) se trimit in mesajele Hello, ei determinand stabilirea sau nu a

relatiei de vecinatate. In absenta acestei relatii se vor ignora de catre ambii orice mesaje EIGRP primite de la celalalt vecin.

5. Metrica Metrica in EIGRP este reprezentata in doua feluri: metrica compusa (se regaseste in RIB si in EIGRP

topology table; este folosita intern si nu este trimisa in mesajele EIGRP) si metrica vectoriala (se regaseste in RIB, in EIGRP topology table si in TLV-urile din update-urile de routare). Aceste TLV-uri, pentru prefixele IPv4, folosesc type-ul 0x0102 pentru rutele interne si 0x0103 pentru rutele externe. Formula de calculare a metricii compuse este:

-Load) + (K3* Valorile default ale K1, K2.. K5 sunt: K1 = K3 = 1 ; K2 = K4 = K5 = 0. Acestea pot lua valori intre 0 si

255 inclusiv. Se configureaza prin comanda:


www.infoacademy.net


Page 6

Router(config-router)# metric weights 0 se reseteaza la valorile default printr-una din comenzile:

Router(config-router)# no metric weights sau Router(config-router)# default metric weights

si se vizualizeaza prin comanda: Router# show ip protocols

Prin design, se cere ca valorile K-urilor configurate pe routerele din process domeniul de routare EIGRP sa fie identice! In absenta indeplinirii acestei conditii routerele configurate cu EIGRP nu vor stabili relatii de vecinatate.

K1 reda ponderea BW administrativ in metrica, K2 reda ponderea Load-ului in metrica, K3 reda ponderea DLY administrativ in metrica, K4 si K5 redau ponderea RLY in metrica.

Daca K5 = 0 (default) se va ignora in calculul metricii fractia (K5/K4+RLY). Daca setezi toate K-urile la valoarea 0 metrica va deveni constanta, si egala cu unu. Exista in acest

moment potentialul de acceptare de rute in topology table si RIB ce vor introduce bucle de routare. Tinand cont de valorile default ale K-urilor, metrica EIGRP devine:

Atat BW cat si DLY sunt valori administrative stabilite manual sau configurate la o anumita

valoare default de catre IOS in functie de tipul de interfata si de parametrii de functionare ai acesteia.

RLY (Reliability) si Load (Incarcare) sunt valori ce reflecta gradul de eroare minim (pe directia de out) pe cale, respectiv gradul de incarcare maxim (pe directia de out) pe cale. Ele sunt calculate pentru fiecare interfata la fiecare 5 secunde fiind o medie ponderata exponential a ultimelor 5 minute. Se transmit in Update-ul EIGRP insa, pentru a evita schimbarea frecventa a metricii (o crestere a acesteia ar putea duce ruta in holddown), nu sunt luate by-default in calcul pentru obtinerea metricii. Odata stabilite de catre EIGRP pentru un prefix ele nu vor fi schimbate de EIGRP decat daca:

o DLY sau/si BW sunt modificate manual pe acea interfata o Se descopera un nou vecin pe acea interfata

IGRP, unde RLY si Load erau parametrii trimisi in mod regulat in Update-urile de routare. In cazul EIGRP ei sunt trimisi doar in cazurile mai sus. Corespunzator, nu au semnificatie in EIGRP si se recomanda a nu fi folositi.

7/BW_min_pe_cale (kbps)

router-ul nostru printr-o interfata FastEthernet unde BW este 100.000 kbps este: 10.000.000/100.000 =100 (ys)

router-ul nostru printr-o interfata FastEthernet unde DLY este 100 ys este: 100/10 = 10 Tinand cont de cele de mai sus, metrica EIGRP pentru o interfata FastEthernet direct conectata va


www.infoacademy.net


Page 7

fi: 256 * (100+10) = 28.160

BW-ul minim pe cale este BW-ul cel mai mic pe interfetele routerelor intermediare intre segmentul de retea respectiv si routerul nostru. Se recomanda ca el sa reflecte BW real al interfetei. Exceptia o reprezinta interfetele NBMA (Frame Relay sau ATM) si ISDN PRI, unde BW administrativ se recomanda a fi suma de CIR-uri pentru VC-urile terminate la acea interfata/subinterfata multipoint. Pentru subinterfata point-to-point se pastreaza recomandarea ca BW-ul administrativ sa fie egal cu BW real (CIR).

In cazul interfetelor din familia Ethernet (Ethernet, FastEthernet, GigabitEthernet sa) speed-ul

configurat manual, autonegociat sau detectat se reflecta automat (este identic) in BW administrativ al interfetei. In cazul interfetelor seriale, clock-rate-ul real nu se reflecta in BW administrativ, acesta din urma avand o valoare default, dependenta de tipul interfetei (adesea 128 kbps sau 1544 kbps). BW administrativ se configureaza manual pe interfata/subinterfata prin comanda:

Router(config-if)# bandwidth Router(config-subif)# bandwidth

Odata modificat manul BW-ul se vor influenta (probabil nedorit) si alte configuratii din IOS de

exemplu costul OSPF, calcule QoS specifice acelei interfete, statistici raportate de SNMP, rezultatul calculului incarcarii acelei interfete sa, asa incat Cisco recomanda sa nu fie folosit BW administrativ pentru routing policy (alegerea rutei optime) in EIGRP.

DLY este suma delay-urilor configurate sau stabilite drept default de IOS pe interfetele routerelor intermediare intre segmentul de retea respectiv si routerul nostru. Se configureaza pe interfata / subinterfata:

Router(config-if)# delay Router(config-subif)# delay

Valoarea precizata in ys (microsecunde) va fi multiplicata de IOS cu 10. Pentru ca modificarea

valorii delay nu atrage dupa sine modificarea si altor parametrii din IOS, Cisco recomanda folosirea delay-ului in scopul influentarii manuale a metricii in EIGRP.

Daca se doreste emularea de catre EIGRP a metricii protocolului de routare RIP se va configura K3

egal cu unu, iar toate celelalte K-uri egale cu zero, cat si un delay constant, pe fiecare interfata, egal cu unu. Se vizualizeaza valorile BW si DLY associate unei interfete prin comanda:

Router# show interface | include BW

T

Media Bandwidth (kbps) Bandwidth EIGRP Delay (ys) Delay EIGRP

Null 10.000.000 1 0 0 Loopback 8.000.000 1 5.000 500 Gigabit Ethernet 1.000.000 10 10 1 Fast Ethernet 100.000 100 100 10 Ethernet 10.000 1.000 1.000 100 HSSI 45.045 222 20.000 2.000 T1 1.544 6.476 20.000 2.000 WIC 2 A/S 128 78.125 20.000 2.000


www.infoacademy.net


Page 8

DS0 64 156.250 20.000 2.000 56K 56 178.571 20.000 2.000 Tunnel 9 1.111.111 500.000 50.000

In cazul RLY se tine cont de valoarea minima, in cazul Load se tine cont de valoarea maxima. Desi se transmit in Update-rile de routare, IP MTU si Hop-count nu sunt folosite in calculul metricii. IP MTU-ul transmis este cel mai mic IP MTU pe cale. Hop-count este incrementat cu 1 de routerul ce primeste acel Update. Hop-count-ul asociat unui

prefix direct conectat este 0. BW, cat si DLY, se transmit in TLV-urile routelor IPv4 interne sau externe folosind campuri pe 32 de

biti. RLY, Load, Hop-count se transmit in campuri de 8 biti. MTU se transmite intr-un camp de 24 de biti ! Metoda utilizata de EIGRP pentru a trimite intr-un Update/Query/Reply o informatie de routare ce

identifica un prefix unreacheable este ca DLY-ul asociat acestuia sa fie maxim, adica 232-1. In TLV-urile pentru rutele interne si externe EIGRP transmite (intr-un camp de 32 de biti) NEXT

HOP-ul respectivului prefix. Adesea, acesta va avea valoarea 0.0.0.0 adica NEXT HOP pentru router-ul vecin va fi routerul nostru, ce publica in propriul Update acest prefix.

In alegerea rutei optime, by default, EIGRP prefera caile de tip intern cailor de tip extern. Daca

schimbam insa distanta administrative locala de la valorile default (90 pentru rute interne si 170 pentru rute externe) reducand valoarea AD pentru rute externe sub cea pentru rute interne, EIGRP va prefer caile de tip extern. De unde concluzia ca EIGRP se foloseste de AD in calculul propriu de alegere a rutei optime !!

Modificarea metricii EIGRP (realizata cel mai adesea prin manipularea parametrului delay) poate

avea drept scop: - instalarea in RIB a unui prefix in detrimentul altuia traffic engineering, - instalarea in RIB a unui prefix impreuna cu acelasi prefix dar cunoscut prin alt vecin introducem

redundanta la nivelul RIB, scazand astfel timpul de convergenta, - reducerea sau cresterea BW folosit de EIGRP pentru propriile mesaje pe o interfata utilizat

adesea in scopul disponibilizarii latimii de banda pe o interfata de WAN de mica viteza in beneficiul traficului de date

6. Algoritmul DUAL ; DUAL Finite State Machine Algoritmul de rutare DUAL (Diffusing Update Algorithm) are la baza cercetarile lui E.W. Dijkstra si C.S.

Scholten. Principala contributie este insa adusa de J.J. Garcia-Luna-Aceves. Spre deosebire de algoritmii de routare Bellman-Ford-Fulkerson si Dijkstra ce realizeaza calcule locale routerului, DUAL se foloseste la nevoie si de celelalte routere din interretea pentru a obtine informatia de routare necesara (trimite interogari vecinilor la care acestia raspund imediat sau interogand la randul lor proprii vecini) diffusing computations. Desigur, si DUAL poate realiza calcule locale routerului numite local computations. -o interfata acesta va genera mesaje Hello pe acea interfata cu scopul descoperirii noastre de catre vecinii imediati ai routerului nostru si in scopul instiintarii


www.infoacademy.net


Page 9

acestora asupra parametrilor EIGRP proprii: ASN, valori K-uri, hold-time, sa. In urma primirii unui mesaj Hello de la un vecin va urma un schimb de mesaje reliable de tip Update in scopul propagarii informatiilor de routare. Split-horizont este un mechanism folosit (by default) de EIGRP de o maniera similara RIP-ului.

Metrica (composite) calculata pentru fiecare prefix obtinut depinde de metrica (vectoriala) primita si de metrica (vectoriala) a interfetei noastre catre vecin.

Strans legat de metrica, EIGRP introduce termeni noi: Feasible Distance (FD) metrica cea mai buna pe care o avem pentru un prefix anume, Succesor routerul vecin prin care avem metrica cea mai buna (FD) pentru un prefix, Reported Distance/Advertised Distance (RD/AD) metrica pe care ne-o comunica un router vecin direct

conectat pentru un prefix, Feasible Condition (FC) este conditia ca un router sa fie considerat drept router de backup pentru un prefix

anume, formulata prin expresia: RD publicat de vecin pentru prefix sa fie strict mai mic decat FD nostru pentru acelasi prefix (metrica pentru un prefix raportata de respectivul router trebuie sa fie strict mai mica decat metrica noastra cea mai buna pentru acel prefix). Este conditia care impiedica alegerea de catre routerul nostru a unui vecin direct conectat drept next-hop pentru un prefix pentru care acesta ar introduce o bucla de routare (routing loop).

Feasible Succesor un router vecin noua ce indeplineste conditia de fezabilitate (FC) pentru un anumit prefix, Routa Pasiva (P) este un prefix pentru care DUAL are cel putin un successor in topology table, Routa Activa (A) este un prefix pentru care DUAL a pierdut succesorul/succesorii si nu are routere feasible-

succesor in tabela topologica.

DUAL Finite State Machine: DUAL recunoaste o serie de Input Events (IE) ce induc reevaluarea listei de succesori/feasible succesori prin calcule locale sau difuzate. Aceste IE sunt:

o Schimbarea costului EIGRP pentru un link direct conectat, o Schimbarea starii (up/down) a unui link direct conectat, o Primirea unui packet de tip Update, o Primirea unui packet de tip Query, o Primirea unui packet de tip Reply.

PAS 1: Ori de cate ori se produce un IE se realizeaza un calcul local prin care se recalculeaza metrica tuturor

succesorilor fezabili pentru respectivul(ele) prefix(e). - In cazul in care succesorul fezabil cu metrica cea mai mica este diferit de succesorul curent, succesorul

fezabil va inlocui succesorul curent (~200 ms). - In cazul in care noul FD va fi mai mic decat FD-ul current din RIB, aceasta din urma va fi inlocuit de noul

FD in RIB. - In cazul in care noul FD este diferit de FD-ul current se vor trimite Update-uri vecinilor ce vor descrie

noua metrica pentru respectivul prefix. Cat timp se realizeaza un calcul local ruta va ramane Pasiva ceea ce inseamna ca ruta va fi pastrata in RIB si

va fi folosita pentru comutarea de pachete. Daca in urma calcului DUAL se gaseste un successor, ruta va ramane mai departe Pasiva in tabela topologica EIGRP.

PAS 2: Daca NU se gaseste un succesor fezabil in urma calculului local, si s-a pierdut succesorul, DUAL va


www.infoacademy.net


Page 10

initia un calcul difuz si va schimba starea rutei in Activ. Pana cand calculul difux nu va fi incheiat routerul nu va putea sa:

o Schimbe succesorul prefixului, o Schimbe metrica publicata a prefixului, o Schimbe FD-ul prefixului din RIB, o Inceapa un alt calcul difuz pentru acelasi prefix.

Calculul Activ incepe prin trimiterea de mesaje Query cu o metrica infinita tuturor vecinilor direct conectati. Fiecare vecin, la primirea acestui mesaj va incepe propriul calcul local. In urma acestuia:

o Daca vecinul are unul sau mai multi succesori fezabili ii va comunica printr-un mesaj Reply routerului nostru metrica sa cea mai buna (a succesorului sau).

o Daca vecinul nu are nici-un successor fezabil va schimba la randul lui starea prefixului in Activ si va interoga prin mesaje Query proprii vecini, mai putin pe routerul nostru.

Daca unul sau mai multi succesori fezabili se regasesc in tabela topologica, DUAL ii va alege pe aceia cu

metrica cea mai mica. Daca nu se gaseste nici-un successor fezabil se va trece ruta in active si se vor interoga vecinii. Se va pastra ruta in active pana la venirea raspunsurilor de la toti vecinii, sau pana la trecerea intervalului de timp active-timer. Daca calculul difuzat nu a produs un successor se va declara ruta unreacheable.

Daca pierdem calea prin succesor catre un prefix si avem un feasible succesor in tabela topologica, se va

promova acesta la rolul de successor. El va fi instalat in locul vechiului succesor in RIB si se vor trimite Update-uri pe toate interfetele de interes EIGRP routerelor vecine pentru instiintarea schimbarii metricii. Metrica din RIB va corespunde metricii actualului succesor, insa FD-ul din tabela topologica va ramane in continuare cel al succesorului anterior al acestui prefix, acum pierdut.

Cand o informatie de routare din tabela topologica are metrica incrementata (primim un update cu noua metrica de la successor) sau routerul succesor a devenit inaccesibil si nu exista feasible succesor, ruta va intra in Activ, trimitandu-se pe toate interfetele (unde am descoperit anterior vecini EIGRP) Query-uri pentru interogarea acestora despre cai posibile alternative catre respectivul/respectivele prefixe.

Rutele marcate drept active in topology table se pastreaza in RIB fie pana la alegerea unui nou succesor, fie scoaterea din tabela de routare datorita inexistentei unei/unor cai alternative catre respectivul(ele) prefix(e). Daca am marcat o ruta drept activa si inca nu am primit toate Reply-urile, nu vom scoate ruta din activ, chiar daca prefixul respectiv a devenit intre timp reachable. Rutele devenite active, au metrica schimbata temporar (pana la primirea tuturor raspunsurilor) la valoarea de 232-1. Orice raspuns (Reply) pozitiv va fi preferat (metrica compusa va fi mai mica) in raport cu aceasta metrica maxima.

Daca am trimis mesaje de tip Query routerelor vecine si in intervalul de Active Timer (configurabil - by-default egal cu 3 minute-) nu primim Reply de la unul sau mai multi vecini (vezi mai jos posibile motive) se va renunta la relatia de vecinatate cu respectivul router, cautandu-se acum succesori fezabili pentru prefixele invatate anterior de la acestia. Potential, in absenta succesorilor fezabili, aceste prefixe vor intra in activ, trimitandu-se noi Query-uri vecinilor ramasi (trafic ce ar putea sa contribuie la posibilele congestii (temporare sau de durata) din interretea.

Router(config-router)# timers active-time { disabled | } intre 1 si 65535


www.infoacademy.net


Page 11

Motive pentru ca un router sa intarzie trimiterea de mesaje Reply sunt:

- Procesor utiliziat pentru realizarea altor taskuri (ex: afisarea de mesaje de logging in consola, trimiterea de mesaje TTL exceeded, sa). Insuficient RAM.

- Latime de banda mica, combinat cu un trafic mare de date, ce duc la intarzierea mesajelor de control. - Link de calitate indoielnica: erori, pierderi de mesaje. - Canal de comunicatii cu delay de transport considerabil (ex: link-uri satelit). - Domeniu de routare mare, combinat cu redundanta ridicata multi vecini de la care se asteapta

raspuns. - BW administrativ foarte mic configurat artificial pe interfete (din motive legate, de exemplu, de

influentare a metricii) EIGRP trimite mesaje pe o interfata folosind, by-default, nu mai mult de 50% din BW administrativ disponibil. In acest ultim caz este dezirabila specificarea latimii de banda maxima pe care o poate folosi EIGRP la nivelul acelei interfete/subinterfete ca fiind mai mare de acei 50% disponibili by default:

Router(config-if)# ip bandwidth-percent eigrp intre 1 si 999999

Schimbul de mesaje EIGRP se poate realize reliable (cazul mesajelor Update, Query si Reply) sau unreliable (cazul mesajelor Hello si Ack). In schimbul de mesaje reliable se folosesc numere de secventa pentru pastrarea ordinii de tratare a mesajelor relativ la ordinea de generare a mesajelor.

7. Load sharing

EIGRP poate trimite spre instalare in tabela de routare IPv4 pana la 32 (IOS 15.0) rute de cost egal sau/si inegal. Numarul lor este by-default de 4. EIGRP este unul din cele 3 protocoale de routare IPv4 capabile de unequal load sharing celelalte 2 sunt IGRP (obsolete) si BGP. Comanda de configurare a numarului maxim de alternative per prefix este:

Router(config-router)# maximum-paths nr intre 1 si 32 Cele trei conditii ca EIGRP sa considere cai multiple de cost inegal sunt: 1. Metrica vecinului (AD) sa fie strict mai mica decat metrica mea cea mai buna (FD) pentru

respectivul prefix. Cu alte cuvinte, routerul vecin sa indeplineasca conditia de fezabilitate: AD < FD

2. Metrica mea prin vecin inmultita cu varianta sa fie mai mica sau egala cu metrica mea cea mai buna (FD) pentru respectivul prefix. By-default varianta este egala cu 1, adica se permite doar equal cost load sharing.

Varianta se configureaza prin comanda: Router(config-router)# variance nr intre 1 si 128

Metrica_mea_prin_vecin * variance


www.infoacademy.net


Page 12

de instalat in RIB decat ii permite propria configuratie (de exemplu are de instalat 5 route insa maximum-paths este 3) astfel:

In primul rand EIGRP va instala mereu in RIB caile de cost minim. Apoi, by-default, EIGRP va instala rute cu metrica mai mare doar in limitele de mai sus.

Metoda de switching din IOS (process switching, fast switching, CEF sa) va comuta acum pachetele in raport

cu ponderea (traffic share) acelor rute, asta insemnand: cu cat metrica este mai mica cu atat aceasta pondere este mai mare si invers. Pondere mare inseamna un numar mai mare de pachete comutate prin acel vecin. Pentru fiecare prefix ponderea se calculeaza impartind metrica cea mai mare la celelalte metrici catre acelasi prefix. Daca numarul obtinut nu este intreg, se va rotunjii in jos pana la primul numar intreg. Ponderea este vazuta in output-ul lui show ip route x.y.z.k si al lui show ip cef x.y.z.k .

Alternativ, se poate configura ca EIGRP sa instaleze in RIB (din nou, in limita numarului de alternative

permise) pe langa caile de cost minim, alternativele prin interfete diferite. Exemplu: EIGRP poate instala maxim 3 rute per prefix. Daca are 5 cai de cost egal catre prefixul X iar 3

dintre acestea au drept interfata de iesire acelasi link, in vreme ce celalalte 2 au fiecare propriul link de iesire, se vor instala acum in RIB 1 cale din primele 3 cat si celelalte 2 fiecare va avea un alt link de iesire ceea ce va insemna cresterea numarului de pachete ce pot fi serializate in acelasi timp catre destinatii din acel prefix, fapt dezirabil.

Comanda necesara configurarii comportamentului in discutie al EIGRP este: Router(config-router)# traffic-share { balanced | min across-interfaces }

Parametrul balanced este default-ul. El cere folosirea ponderilor (traffic share) pentru trimiterea

proportionala a pachetelor catre reteaua destinatie: pondere mare numar mare de pachete comutate prin vecin.

Parametrul min accross-interfaces cere ca sa se instaleze in RIB si caile alternative dar sa nu se foloseasca acestea pentru comutarea de trafic. Doar caile de cost minim vor fi folosite pentru switching-ul de pachete. Avantajul unei astfel de configurari este timpul mic de convergenta necesar EIGRP in momentul pierderii succesorului feasible succesor se gaseste deja in RIB !

8. Sumarizare By-default, auto-sumarizarea este pornita [1]. Aceasta are drept efect sumarizarea in Update-uri a prefixelor

situate la limita de retea classfull (similar RIPv1 si default RIPv2) cu conditia ca cel putin un prefix suport al rutei auto-sumarizate sa fie direct conectat (si de interes EIGRP) la router-ul nostru.

[1]

Incepand cu versiunea de IOS 15.0 auto-sumarizarea este by-default oprita.

EIGRP trimite NM real (cel configurat pe interfete) in cazul designului IP in inter-retea de tip VLSM, SLSM si

classfull traditional, deci nu este nevoie in aceste cazuri de oprire a auto-sumarizarii. Singurul caz in care auto-sumarizarea impiedica obtinerea conectivitatii generale (full reachability) este cazul designului IP de tip subretele discontinue. Aici se va deconfigura auto-sumarizarea prin comanda:

Router(config-router)# no auto-summary EIGRP permite sumarizarea manuala per interfata/subinterfata la nivelul oricarui router din interretea

similar RIPv2 si disimilar OSPF (unde este permisa doar pe ABR si ASBR). Conditia ca sumarizarea manuala sa


www.infoacademy.net


Page 13

functioneze este existenta in tabela topologica EIGRP a cel putin o ruta suport a sumarizarii manuale (conectata, redistribuita, invatata prin EIGRP. Spre deosebire de auto-sumarizare, conditia ca respective ruta suport sa fie direct conectata NU exista)

Se poate sumariza manual in acelasi spatiu de adrese classfull de mai multe ori pe aceeasi interfata/subinterfata, configuratie utila atunci cand avem de sumarizat prefixe ce redau spatii de adrese cont in aceeasi retea classfull.

Metrica vectoriala a sumarizarii manuale este stabilita de ruta suport cu metrica composite cea mai mica. Atentie! Daca ruta suport cu metrica cea mai mica va face flapping, atunci si sumarizarea va fi instabila

datorita schimbarii constante a metricii asociate acesteia. In scopul evitarii acestui scenariu se recomanda utilizarea unei interfete de loopback (ex: cu un NM egal cu 32) drept ruta suport cu metrica cea mai mica a sumarizarii (ex: i se va asocia manual un delay egal cu unu). Alternativ, putem folosii o ruta statica de discard redistribuita drept sursa a metricii sumarizarii.

Daca NM-ul sumarizarii manuale este mai mic decat NM natural al retelei classfull din care face parte, se va

trimite in Update catre vecin/vecini doar superreteaua manual configurata, nu si auto-sumarizarea la limita de retea classfull (indiferent daca auto-sumarizarea este pornita sau nu).

Daca NM-ul sumarizarii este mai mare decat NM natural al retelei clasfull din care face parte si, in plus, auto-sumarizarea este pornita (default), se va trimite catre vecin/vecini in Update atat sumarizarea manuala cat si reteaua classfull rezultata din auto-sumarizare. Pentru a se trimite doar sumarizarea manuala va trebui oprita auto-sumarizarea.

Atat in cazul auto-sumarizarii cat si in cel al sumarizarii manuale se vor crea in EIGRP topology table, cat si

in RIB, rute de discard (rute ce au drept interfata de iesire interfata Null 0) pentru respectivele prefixe sumarizate. Scopul lor este de a evita buclele de routare devenite posibile prin publicarea prin intermediul

a unui spatiu de adrese IP mai mare decat, poate, cel efectiv cunoscut in RIB-ul local.

In cazul pornirii auto-sumarizarii se va crea o ruta de discard pentru rutele auto-sumarizate. Rute de discard se vor crea si in cazul sumarizarii manuale. In cazul opririi auto-sumarizarii si al folosirii doar a sumarizarii manuale se vor crea rute de discard doar pentru rutele sumarizate manual.

Distanta administrativa default a rutelor de discard este de 5. Ea nu este configurabila in cazul rutelor de

discard rezultate din auto-sumarizare, insa poate fi configurata la orice valoare in 1 si 255 [2] pentru rutele de discard rezultate din sumarizarea manuala. Se va dori modificarea acesteia la o valoa re mare (eventual 255) in cazul, de exemplu, al trimiterii de catre un router HUB, prin sumarizare manuala, a prefixului 0.0.0.0/0 catre un router spoke, ruta de discard rezultata din sumarizare avand drept efect posibil pierderea propriei rute default din RIB-ul HUB-ului daca aceasta avea o distanta administrativa mai mare decat 5 (ex: daca a instalat-o eBGP

). Router(config-if)# ip summary-address eigrp []

[2] se aduce aminte ca AD (administrative distance) 255 inseamna ca acea ruta NU va fi instalata in RIB Nu este necesar ca auto-sumarizarea sa fie pornita sau oprita pe toate routerele din interretea se va

aprecia in functie de situatia particulara. Ca urmare a sumarizarii, vecinii vor avea o tabela topologica EIGRP si un RIB mai redus se conserva RAM,


www.infoacademy.net


Page 14

cautarea in RIB va fi mai scurta se conserva CPU, finalmente, se conserva BW in segmentul dintre routere prin trimiterea unor Update-uri mai mici. Un alt efect, poate cel mai important, este reducerea domeniului de propagare a Query-urilor in retea routerul vecin, la primirea unui Query despre o ruta suport a sumarizarii trimise anterior lui, va raspunde imedia , reducand astfel probabilitatea ca routerele de la care se asteapta Reply-uri sa ajunga SIA (Stuck In Active).

Dezavantajele sumarizarii sunt: posibila rutare neoptima datorata pierderii informatiilor detaliate de

routare, folosirea ineficienta a resurselor (se arunca pachetul catre o destinatie unreachable mai departe de sursa decat daca s-ar fi cunoscut prefixele (unreacheable) in amanunt), bucle de routare (pachete trimise noua pe seama sumarizarii publicata routerului vecin pot fi forwardate la randul nostru pe seama unei alte rute sumarizate, posibil 0.0.0.0/0, inapoi, routerului respectiv), necesitatea unui design IP agregabil in prealabil.

Vizualizarea configurarii auto-sumarizarii cat si a sumarizarilor manuale (interfata, metrica) se obtine prin

comanda: Router# show ip protocols

Informatia de rutare rezultata in urma sumarizarii (manuale sau automate) este mereu de tip intern, chiar

si atunci cand sumarizezi (doar manual) prefixe de tip extern - prefixele externe nu pot fi auto-sumarizate. Ex: -uri pe o interfata

configurata in subnetul 33.33.33.0/24 nu va produce autosumarizarea prefixului la 10.0.0.0/8 vecinul EIGRP il va primii tot sub forma 10.1.1.0/24, informatie de routare interna.

Si in cazul sumarizarii manuale a rutelor externe se va crea pe routerul ce sumarizeaza o ruta de discard EIGRP interna cu AD 5.

Repetam conditia ca cel putin o ruta suport a sumarizarii manuale a rutelor externe sa fie direct conectata NU exista.

Doar pe interfetele fizice LAN/WAN si pe interfetele Virtual-Template poate fi configurata o sumarizare

manuala ce indica catre un leak-map un route-map ale carui permite-uri si access-list/prefix-list-uri (ce identifica prefixe prin permit) accepta propagarea in Update-uri a prefixelor ce altfel ar fi sumarizate (si deci care nu ar fi trimise), reusindu- fost suprimate.

Router(config-if)# ip summary-address eigrp leak-map

9. Ruta default Retelele candidate-default sunt scoase in evidenta in output-ul show ip route * in dreptul lor. Exista mai multe metode de a genera un candidate default [1] in EIGRP: 1. Sumarizare manuala per interfata la 0.0.0.0/0. Are avantajele reducerii domeniului de Query si Update,

al configurarii per interfata, dar si dezavantajele posibilei pierderi propriei rute default din RIB (rezolvata prin modificare AD default a rutei de discard), cat si a pierderii la routerele vecine a informatiilor de routare detaliate (rezolvata prin folosirea de leak-map-uri). Prefixul 0.0.0.0/0 primit de routerul vecin va fi de tip intern.

2. Redistributia 0.0.0.0/0 din RIB unde a fost instalata de alt process de routare (static, OSPF, BGP, EIGRP alt AS). Ruta default va fi publicata tuturor vecinilor EIGRP. Va avea o metrica corespunzatoare


www.infoacademy.net


Page 15

configuratiei de redistribuire (daca exista) sau o metrica construita automat, in cazul rutelor connected si static. Prefixul 0.0.0.0/0 primit de routerul vecin va fi de tip extern. Exemplu paricular in cazul redistributiei rutelor statice:

Router(config)# ip route 0.0.0.0 0.0.0.0 10.0.0.1 s1/0/0 Router(config-router)# redistribute static

3. Marcarea unei retele conectate sau statice, aparent direct conectate, de tip classfull din RIB ca ruta candidate-default cu ajutorul comezii Router(config)# ip default-network are drept efect, daca aceasta retea este de interes EIGRP (este prinsa de comanda network sau redistribuita), propagarea sa catre vecini ca ruta candidate-default (apare marcata printr-un bit in TLV-ul intern sau extern corespunzator). Prefixul primit de routerul vecin va fi de tip intern sau extern. Routerul vecin va alege, dintre potential mai multe routere candidate-default, unicul sau default-gateway.

4. Daca exista in tabela de routare o ruta 0.0.0.0/0 statica aparent direct conectata (nu are IP next hop

configurat) si se foloseste in configuratia EIGRP comanda network 0.0.0.0, se va propaga in Update-urile EIGRP o ruta interna, de tip 0.0.0.0/0, indiferent daca interfata de iesire este sau nu catre un vecin EIGRP. De evitat acest gen de configuratie (cu exceptia, poate, a laboratorului) datoriprea mare a comenzii network mentionate toate interfetele routerului up si up si configurate cu IP, prezente si viitoare, vor fi de interes pentru EIGRP. La fel, de interes pentru EIGRP, vor fi si toate rutele statice fara next-hop din RIB. In tabela topologica a routerului sursa a prefixului 0.0.0.0/0 acesta va apare via Rstatic . Prefixul primit de routerul vecin va fi de tip intern.

[1] se folosesc rutele candidate default pentru alegerea gateway- ndu-se o logica redata la sfarsitul acestui document [2] .

paralel in scop de load-balancing. [2] - http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094374.shtml In cazul in care un router are in RIB ruta 0.0.0.0/0 de tip extern si este configurat prin sumarizare manuala cu AD > 170 pe o interfata sa trimita 0.0.0.0/0 de tip intern, el va prefera sa trimita 0.0.0.0/0 de tip extern si nu intern!

10. Autentificare Autentificarea EIGRP este de 2 tipuri, anume null (default) si md5.

-chains) ce pot contine una sau mai multe parole valide in momente diferite de timp. Key-chain-ul asociat unei interfete pentru EIGRP poate diferi de cel utilizat pentru o a doua, a trei interfata. Configuratia key-chain-urilor, cat si managementul cheilor, este similara celor folosite in cazul RIPv2.

Router(config-if)# ip authentication mode eigrp md5
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094374.shtmlhttp://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094374.shtml


www.infoacademy.net


Page 16

Router(config-if)# ip authentication key-chain eigrp

Numarul cheii cat si parola utilizata (ce este case sensitive [1]) trebuie sa fie identice in configurarea vecinilor EIGRP de pe acelasi link pentru a se obtine/mentine relatia de vecinatate.

Daca intr-un key-chain avem 2 sau mai multe chei ce sunt valide la un moment dat, atunci, daca , se va folosi cheia numeric cea mai mica, iar daca va fi vo , atunci se vor

accepta mesaje EIGRP cu oricare dintre cheile valide.

Configurarea pe o interfata doar a mode-ului sau doar a key-chain-ului este insuficienta pentru schimbarea autentificarii default (null) pe respectiva interfata ambele comenzi de mai sus sunt necesare.

Se vizualizeaza key-chain-urile configurate in running-config cu: Router# show key chain [],

iar key-chain-urile active pe o interfata cu: Router# show ip eigrp [] interface detail []

In anumite versiuni vechi de IOS conta indexul numarului de cheie din key-chain. Exemplu: desi ambele routere dispun de o cheie comuna (111) si o parola comuna (cisco), daca pozitia cheii este 1 pentru R1 si 2 pentru R2, autentificare nu se realizeaza cu succes. Este necesara configurarea corecta a timpului pe toate routerele din process-domain-ul EIGRP. Cea mai scalabila metoda este utilizarea procolului NTP. Exemplu de configurare minimala:

Router(config)# clock timezone RO 2 Router(config)# clock summer-time recurring RO 4 sunday mar 1:00 4 sunday oct 1:00 Router(config)# ntp server ro.pool.ntp.org

[1] Atentie la posibile caractere tip s la sfarsit ce ar intra in constitutia parolei.

Numarul maxim de caractere din parola este 80. Parola nu poate incepe cu o cifra.

11. Scalabilitate si optimizare Se numeste EIGRP Topology Depth totalitatea routerelor pe care trebuie sa le traverseze un Query

sau un Update de routare in process domain-ul EIGRP in scopul propagarii informatiei de routare. Este dezirabila reducerea acestuia in scopul scaderii timpului de convergenta. Acest lucru se obtine prin:

1. Filtrarea prefixelor catre vecini; astfel reducem dimensiunea domeniului de Query. Se realizeaza de regula prin distribute-lists,

2. Sumarizarea de prefixe catre vecini unidirectional (prin sumarizare manuala) sau omnidirectional (prin sumarizare automata). Utilizarea si eficienta sa depinde de preexistenta unui design IP ierarhic in inter-retea si a unei topologii ierarhice; prin sumarizare reducem dimensiunea atat a domeniului de Update cat si a celui de Query,

3. Utilizarea functionalitatii EIGRP Stub; reducem astfel dimensiunea domeniului de Query, 4. Utilizarea unei versiuni recente de EIGRP ce cunoaste mecanismul SIA Query/Reply; astfel

schimbarile din RIB reflecta cu exactitate punctul din interretea cu dificultati in convergenta. Configuratia de tip EIGRP Stub are urmatoarele efecte, in general benefice:


www.infoacademy.net


Page 17

- vecinii direct conectati routerului nostru nu ne trimit Query-urile pe care le primesc/genereaza, eliminand astfel intervalul (posibil mare) de timp necesar generarii unui Query si apoi primirii unui Reply intr-o retea WAN redundanta si cu latime mica de banda. Acesti vecini vor considera ca au primit deja un raspuns cu metrica infinita.

- prefixele invatate de la un router vecin nu sunt propagate altui router vecin. Drept rezultat routerul meu nu va deveni un router de tranzit pentru acele prefixe. Acest fapt este adesea dezirabil in cazul retelelor WAN lente. Exceptia de la aceasta regula este realizata de leak-maps, necesara in unele cazuri (ex: retelele hub & spoke redundante)

- routerul configurat drept stub va trimite in update-urile sale de routare catre vecinii imediati doar tipurile de prefixele de interes EIGRP precizate in configurarea EIGRP stub. By default, se vor trimite vecinilor atat prefixele direct conectate cat si cele sumarizate local. Sintaxa corespunzatoare este:

Router(config-router)# eigrp stub [connected|static|redistribute|receive-only|summary] leak-map


www.infoacademy.net


Page 18

- Evitam utilizarea EIGRP in retele de dimensiuni foarte mari, cu multipla redundanta, cu link-uri de latime mica de banda si/sau unreliable si cu routere cu reduse resurse RAM si CPU. In IOS-urile recente (ex: 15.0) este posibila configurarea odata cu EIGRP a BFD (Bidirectional

Forwarding Detection) ce are drept rezultat grabirea convergentei in cazul pierderii legaturilor intre routere direct conectate intre ele la layer 2 OSI la un interval de timp de sute de msec (!) .

Sintaxa EIGRP necesara este:

Router(config-router)# bfd all-interfaces

Tabelul ce urmeaza descrie timpul de convergenta necesar diferitelor protocoale de routare cu sau fara optimizari. Drept regula generala, EIGRP cu FS (Feasible Successor) are un timp de convergenta mai mic decat OSPF, ce are un timp de convergenta mai mic decat EIGRP fara FS:

12. Filtrarea de rute In scopul reducerii topology depth (scaderii timpului de convergenta) putem utiliza filtrarea de rute in EIGRP. Metodele pe care le avem la dispozitie permit filtrarea de rute pe directa de IN (filtram prefixe ce

si pe directia de OUT ise vecinilor). Pentru filtrarea prefixelor pe IN (inbound, intrare in router) dispunem de:

o modificarea AD a unui prefix primit astfel incat: sa fie preferata (poate doar temporar) o alta sursa de informatie de rutare pentru

respectivul prefix pe routerul nostru vom configura un AD mai mare pentru prefixul

Documents

EIGRP-facts.pdf