2009 Carte PR PDF

1 A rhite ctura unui rute r
1.1 Componentele unui ruter

Dac ne reprezentm un ruter ca un dispozitiv similar unui calculator, nu vom fi deloc departe
de realitate. Simplificnd, un ruter este un dispozitiv ce realizeaz interconectarea ntre dou sau
mai multe reele. Prin intermediul ruterelor, pachetele de date pot traversa graniele reelelor,
parcurgnd oricte reele este necesar pentru a ajunge la destinaie. De fapt, necesitatea de rutare
a pachetelor a existat dinaintea construirii primului ruter ca dispozitiv dedicat acestei sarcini.
Funcia principal a unui ruter este aceea de a ruta pachete sau, altfel spus, de a executa un
algoritm ce are drept scop determinarea cii pe care un pachet de reea trebuie s o urmeze pn la
destinaie.
Adevrata utilitate a unui dispozitiv de rutare este demonstrat n momentul n care acesta
interconecteaz cel puin dou reele. O modalitate uor accesibil de a realiza o funcie de rutare
ntre dou reele este aceea ce a folosi un calculator cu dou plci de reea, conectate la reele
diferite. Toate sistemele majore de operare pentru sisteme desktop (Windows, Linux, Mac OS)
suport, deseori nativ, funcii de rutare. Spre exemplu, ICS (Internet Connection Sharing) din
sistemele Windows reprezint funcia de rutare. Pe sistemele Linux, rutarea se activeaz prin
setarea variabilei ip_forward din fiierul /proc/sys/net/ipv4.
Folosirea unui calculator drept nlocuitor pentru un ruter este posibil, uor de implementat,
dar deseori ineficient. Performana traficului ntre reele (i n Internet, deopotriv) depinde ntr-o
mare msur de performana ruterelor pe care pachetele le traverseaz. Timpul pe care un ruter l
folosete pentru a lua deciziile de rutare i pentru a executa funciile diverselor servicii pe care le
ruleaz reprezint cea mai semnificativ ntrziere n traficul de reea.
Ruterele, pe de alt parte, sunt dispozitive concepute special pentru a realiza ct mai eficient
funciile de rutare precum i alte servicii necesare n reea. Din acest motiv, arhitectura hardware a
ruterelor este considerabil diferit de cea a unui calculator desktop, spre exemplu. Cu toate
acestea, un ruter deine o serie de componente ce se regsesc n interiorul oricrui calculator: un
procesor (CPU) aritmetico-logic, o memorie volatil (RAM), precum i zone de stocare permanent a
datelor (ROM, NVRAM, Flash). De asemenea, ruterul comunic n exterior prin interfee iar ntreaga
sa funcionalitate este controlat de un sistem de operare ce ruleaz n permanen.
2|Proiectarea reelelor
1.1.1 Memoriile unui ruter

1.1.1.1 Memoria RAM
Ca i n cazul calculatoarelor uzuale, memoria RAM este folosit pentru a stoca instruciunile i
datele ce particip n operaiile executate de procesor la un moment dat. n cazul ruterelor Cisco, n
timpul secvenei de iniializare ntregul coninut al sistemului de operare este ncrcat n memoria
RAM. Dac sistemul de operare prezint capabiliti extinse (servicii sau protocoale suplimentare),
n mod implicit consumul su de memorie va fi mai ridicat.
Modificarea parametrilor unui ruter, deci configurarea sa prin intermediul sistemului de
operare, are ca efect pstrarea acestor modificri ntr-un fiier special localizat n RAM, ce
stocheaz configuraia curent, denumit i running configuration sau running-config. n afara
cazului n care configuraia unui ruter este salvat ntr-o memorie permanent, aceasta se pierde
mpreun cu ntregul coninut al memoriei RAM la repornirea ruterului.
Pe lng sistemul de operare i configuraia curent, memoria RAM stocheaz o multitudine de
variabile, structuri de date, statistici i alte date temporare utilizate de serviciile ce ruleaz pe
ruterul respectiv. Memoria RAM stocheaz tabela de rutare a unui ruter, aceasta fiind o baz de
date cu toate destinaiile cunoscute de ruter, folosit pentru rutarea pachetelor. Printre alte
informaii stocate n memoria RAM se numr cache-ul ARP ce pstreaz asocierile adres MAC
adres IP pentru toate reelele Ethernet la care este conectat ruterul, statistici ale pachetelor i
strilor conexiunilor, precum i mesaje de log.
1.1.1.2 Memoria ROM

Memoria ROM este o form de memorie non-volatil, de dimensiuni foarte mici. Ea stocheaz
n permanen instruciunile necesare iniializrii ruterului: activarea diferitelor module, efectuarea
de teste hardware, etc. Instruciunile (sau programul) de iniializare mai poart denumirea de
bootstrap.
De asemenea, memoria ROM stocheaz instruciuni primare pentru diagnostice, utile mai ales
n cazul funcionrii anormale a ruterului, precum i o versiune minimal a sistemului de operare
(numit ROMMonitor sau rommon) ce permite, printre altele, nlocuirea sistemului de operare
instalat pe un ruter.
Software-ul din memoria ROM poart denumirea de firmware i, de regul, nu necesit
rescrieri sau actualizri.
1.1.1.3 Memoria Flash

Din moment ce memoria Flash este memoria non-volatil cu cea mai mare dimensiune dintr-un
ruter, principalul ei scop este acela de a pstra n permanen o copie nealterat a sistemului de
operare. La iniializarea unui ruter, sistemul de operare este citit din memoria Flash, eventual
decomprimat i ncrcat n memoria RAM.
Conceptual, memoria Flash reprezint echivalentul unui hard disk, cu un sistem de fiiere
propriu ce permite stocarea i altor fiiere pe lng sistemul de operare propriu-zis. Mai mult chiar,
o memorie Flash suficient de mare poate stoca mai multe sisteme de operare.
Memoria Flash este deseori implementat sub forma unor module SIMM sau plci PCMCIA ce
pot fi uor nlocuite fr a deschide fizic carcasa ruterului.
3|Arhitectura unui ruter
1.1.1.4 Memoria NVRAM

Memoria NVRAM este o memorie permanent de mici dimensiuni folosit de ruter pentru a
stoca fiierul de configurare ce va fi ncrcat n memoria RAM dup iniializarea sistemului de
operare. Configuraia unui ruter poate fi salvat n NVRAM pentru a fi pstrat i ncrcat la fiecare
pornire a ruterului. Fiierul comenzilor de configurare din NVRAM poart numele de startup
configuration sau startup-config.
Memoria NVRAM poate fi rescris de oricte ori este necesar o salvare a configuraiei curente.
1.1.2 Interfeele unui ruter

1.1.2.1 Porturi de management
Spre deosebire de celelalte interfee, porturile de management nu sunt folosite pentru
transportarea traficului de reea ci doar pentru administrare. Ele nu necesit o configuraie IP i pot
fi accesate printr-o conexiune direct de la portul serial al unui calculator, folosind un cablu de tip
crossover.
Dei accesarea sistemului de operare al unui ruter poate fi fcut prin orice interfa a sa, att
de management ct i de reea, configurarea iniial a unui ruter trebuie fcut printr-un port de
management.
Portul de consol ofer administratorului o interfa n linie de comand (CLI Command Line
Interface) pentru accesarea sistemului de operare
i introducerea comenzilor de configurare.
Aceeai interfa poate fi accesat i prin Telnet sau SSH pe un ruter configurat corespunztor, dar
astfel de conexiuni, ce implic trafic de pachete, trebuie fcute prin interfe ele de reea1.
1.1.2.2 Interfeele de reea

n general, o interfa de reea a unui ruter reprezint un conector fizic ce suport trafic de
pachete. Interfeele pot fi conectate la o multitudine de medii de transmisie (cupru, fibr optic,
wireless), fiecare avnd diferite standarde, ceea ce creeaz o varietate considerabil de tipuri de
interfee.
Interfeele sunt considerate conexiuni spre reele diferite i pot fi configurate cu adrese IP i
mti de reea corespunztoare. Sistemul de operare al ruterului nu va permite configurarea a dou
interfee diferite cu aceeai pereche de parametri de adres IP i masc de reea, ceea ce ar cauza
apartenena a dou interfee la aceeai reea. Interfeele de reea pot accepta att pachete IP
destinate ctre ruterul local, ct i pachete cu alte destinaii, ce vor fi rutate n funcie de
informaiile din tabela de rutare.
Interfeele unui ruter sunt identificate n mod unic printr-un nume, ce desemneaz tipul lor,
urmat de unul sau mai multe numere ce indic numrul lori, respectiv, modulul instalat pe ruter
din care aceasta face parte. Spre exemplu, Ethernet0 desemneaz prima (0) interfa Ethernet a
unui ruter, n timp ce Serial 1/2 indic a treia interfa
serial (2) a celui de -al doilea modul (1).
Identificatorii numerici sunt consecutivi la nivel de modul
i interfa. Denumirile de interfee n
aceste forme sunt utilizate att n rezultatele comenzilor de interogare ct
i n construcia
comenzilor, ca parametri.
Conform denumirii lor, interfeele LAN sunt folosite pentru a conecta ruterul la reele locale
Ethernet, similar cu modul n care un calculator se conecteaz la o reea local prin intermediul
1
Mai mult chiar, unele rutere i switchuri suport i configurarea prin intermediul unei interfee web sau a
unor aplicaii specializate, precum Cisco Security Device Manager (SDM).
plcii sale de reea. Din punctul de vedere al reelei, interfaa LAN se comport ca orice alt staie
direct ataat segmentului de reea respectiv: interfaa deine o adres unic MAC de nivel 2, i
trimite cereri ARP precum i rspunsuri la acestea cu adresa sa configurat de nivel 3.
O interfa Ethernet folosete un conector de tip RJ-45 ce suport cablare UTP (Unshielded
Twisted Pair). Din punctul de vedere al tipului de cablu folosit, interfaa se comport asemenea unei
plci de reea, deci va necesita un cablu crossover la conectarea cu un PC sau un alt ruter sau un
cablu straight-through la conectarea cu un port al unui switch.
Interfeele WAN sunt folosite pentru conexiuni cu reele ntinse pe arii geografice mai mari.
Diferitele tipuri de interfee WAN se datoreaz n principal diferitelor tipuri de ncapsulri de nivel 2
suportate, cum sunt HDLC (High-Level Data Link Control), PPP, sau Frame Relay. Pentru reele WAN,
adresarea la nivelul legtur de date se face prin metode proprii fiecrui protocol, adresarea MAC
fiind folosit doar n reele Ethernet.
1.1.3 Procesul de iniializare al unui ruter

Strile prin care un ruter trece n timpul iniializrii sale, imediat dup pornire, pot fi rezumate
n urmtoarele etape:
Efectuarea POST (Power-On Self Test) reprezint un proces de execuie a unor instruciuni de
test cu scopul de a determina funcionarea corespunztoare a tuturor componentelor hardware.
POST este rulati cu scopul de a detecta hardware -ul instalat n ruter: capacitatea memoriilor,
prezena interfeelor i tipul lor, etc. O mare parte a echipamentelor (nu doar ruterele) folosesc
acest procedeu la iniializare iar instruciunile sunt stocate de regul n memoria ROM.
Execuia programului Bootstrap are drept scop localizarea imaginii sistemului de operare ce va
fi ncrcat n RAM. Programul de Bootstrap este, de asemenea, localizat n memoria ROM.
ncrcarea sistemului de operare se realizeaz, de cele mai multe ori, prin copierea imaginii
sistemului de operare din Flash n memoria RAM. Imaginea mai poate fi ncrcati prin reea, de
pe un server TFTP (Trivial File Transfer Protocol), n cazul n care ruterului i se specific explicit
aceast metod sau n situaia n care nu este gsit o imagine valid n Flash. ncrcarea imaginii
poate fi fcut n paralel cu decompresia ei, pentru imagini stocate n form arhivat. Unele rutere
pot rula imaginea sistemului de operare direct din memoria Flash.
Lipsa unei imagini a sistemului de operare va avea ca rezultat ncrcarea unui sistem de operare
minimal, direct din ROM, oferind posibilitatea administratorului de a instala o imagine
corespunztoare.
ncrcarea fiierului de configurare se realizeaz n vederea configurrii sistemului de operare
ncrcat. Acesta nu conine dect o configuraie de baz, implicit, ce nu permite niciun fel de trafic
prin interfeele sale. Fiierul de configurare ( startup-config) poate conine comenzile necesare
pentru configurarea interfeelor ruterului, a rutelor, parolelor, serviciilor suplimentare i a oricror
ali parametri suportai de ruter. Fiierul de configurare este cutat n memoria NVRAM i ncrcat
n RAM, unde va fi referit ca running-config (configuraia curent). Comenzile ncrcate din fiierul
de configurare au efect imediat.
Dac memoria NVRAM este vid, ruterul va cuta s ncarce o configura
ie de pe un server
TFTP. Dac nu va fi gsit niciun server TFTP, ruterul va oferi utilizatorului, prin interfa
a de
administrare, accesul la setup mode, adic posibilitatea s rspund la o serie de ntrebri de
configurare, introducnd astfel o configuraie minimal n running-config.

Dac administratorul este conectat la consola ruterului, procesul prezentat mai sus poate fi
observat ncepnd cu finalizarea cu succes a POST-ului.
1.2 Sistemul de operare

Sistemul de operare produs de ctre Cisco pentru echipamentele sale (rutere
i switchuri
deopotriv) este numit Cisco IOS (Internetwork Operating System) i cuprinde toate funciile de
rutare, switching, securitatei monitorizare, precum i o variet ate de servicii ce determin
capabilitile echipamentelor ce l ruleaz.
Cisco IOS este disponibil ntr-o multitudine de versiuni, fiecare beneficiind de capabilit
i
orientate spre anumite platforme hardware. Facilit
ile pot include: protocoale, algorit
mi de
criptare, suport pentru anumite tipuri de interfe
e, etc. Sistemele de operare sunt mapate pe
anumite serii de modele de ruterei switchuri att din punctul de vedere al capabilitilor fiecrei
platforme ct i datorit limitrilor hardware specifi ce seriilor de modele (ncrcarea memoriei
RAM, gradul de utilizare a procesorului).
Interfaa caracteristic pentru Cisco IOS este linia de comand, n mod text, accesibil prin
conexiuni directe la porturile de management precum
i prin protocoale ca Tel
net sau SSH.
Comenzile de configurare i monitorizare sunt introduse n mod text i sunt grupate n moduri ce
stabilesc contextul valid pentru fiecare comand. Spre exemplu, un anumit set de comenzi va fi
disponibil n modul de configurare a unei interfee Ethernet, iar alt set va putea fi accesat n modul
de configurare al serviciului DHCP de pe un ruter.
Similar sistemelor Linux, comenzile pot fi executate n moduri privilegiate corespunztoare.
Cisco IOS permite configurarea de pn la 15 nivele de privilegii, precum i implementarea de
conturi de utilizator asociate acestor nivele. Nivelul inferior al acestor privilegii permite doar
executarea unui set limitat de comenzi, din gama comenzilor de monitorizare, n timp ce nivelul
superior permite executarea oricrei comenzi de configurarei monitorizare, indiferent de efectul
potenial fatal al acestora.
La momentul scrierii acestei cr
i, cea mai recent versiune a Cisco IOS este denumit
12.4(24)T. Notaia are urmtoarea semnificaie:
12 reprezint versiunea major;
4 reprezint versiunea minor, iar mpreun cu versiunea major formeaz partea de
maintenance release a versiunii;
24 reprezint numrul release-ului, urmat uneori de un numr de release interimar.
T reprezint un train, adic un set de capabiliti orientate spre un anumit segment de
pia. Spre exemplu, T reprezint Technology, S reprezint Service provider, amd.
Train-urile sunt excepii de la varianta mainline, cea mai stabil dar cu setul cel mai
restrns de capabiliti.
1.2.1 Moduri de configurare

Modurile de configurare din Cisco IOS sunt similare unor contexte i determin ce comenzi sunt
valide i pot fi introduse la un moment dat.
Prima clasificare a modurilor de configurare ale unui ruter se face din prisma nivelurilor de
securitate:
Modul User EXEC permite doar execuia comenzilor de interogare a strii ruterului;
Modul Privileged EXEC permite i execuia comenzilor de modificare a configuraiei unui
ruter.
Modul accesat n mod implicit n urma conectrii la un ruter este modul User EXEC, indicat n
linia de comand printr-un prompt format din numele ruterului (Router, n mod implicit) urmat de
caracterul >. Pentru trecerea n modul privilegiat se folose
te comanda
enable iar pentru
revenirea n modul User EXEC, comanda disable. Trecerea n modul privilegiat poate fi protejat
printr-o parol i este indicat de simbolul # ataat numelui ruterului:
Router con0 is now available.
Press RETURN to get started.
Router>enable
Router#disable
Router>
n modurile User EXEC i Privileged EXEC pot fi executate comenzi de interogare a ruterului, dar
nu pot fi executate comenzi ce modific configura
ia curent. Pentru modificarea fiierului de
configurare din memorie este necesar intrarea ntr-un mod special de configurare, accesibil doar
din modul privilegiat, prin comanda configure terminal. Modul se mai nume
te i modul
global de configurare deoarece din el deriv toate celelalte moduri de configurare.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#enable password cisco
Router(config)#exit
Router#disable
Router>enable
Password: [administratorul introduce parola corect: cisco]
Router#
n exemplul de mai sus se observ c intrarea n modul de configurare este reflectat n

modificarea prompt-ului, n Router(config)#. Comanda enable password configureaz
ruterul s interogheze utilizatorul pentru o parol valid (cisco, n exemplul de fa) nainte de a
permite accesul la modul privilegiat (denumit uneori i modul enable datorit comenzii).
Modurile de configurare n Cisco IOS sunt indicate prin modificarea prompt-ului i formeaz o
ierarhie avnd modul (config) la baz. Pentru revenirea la modul imediat superior se poate folosi
comanda exit. De asemenea, comanda end va ntoarce ntotdeauna prompt-ul pn la nivelul
Privileged EXEC, indiferent de adncimea nivelului de configurare curent 1.
Urmtorul exemplu demonstreaz navigarea prin modurile de configurare al unui protocol de
rutare (config-router), respectiv al unei interfee (config-if):
Enter configuration commands, one per line.
Router(config)#router rip
Router(config-router)#exit
Router(config)interface Ethernet0
Router(config-if)end
Router#
End with CNTL/Z.
1.2.2 Sistemul de fiiere
1.3 Configuraii de baz

Numele oricrui ruter este, n mod implicit Router i este vizibil n orice prompt al liniei de
comand. Dei numele are semnificaie exclusiv local, pstrarea numelor implicite pe toate
Pentru rapiditate se poate folosi i combinaia de taste CTRL-Z, echivalent comenzii end.

echipamentele poate crea ambiguiti chiar i ntr -o reea form at din cteva rutere. Schimbarea
numelui ruterului se face din modul global de configurare, prin comanda hostname:
Router(config)#hostname Marketing
Marketing(config)#
End with CNTL/Z.
Un alt exemplu l reprezint setarea dateii orei ceasului intern al ruterului, utile n principal
pentru identificarea momentelor de timp ale diverselor evenimente, att n timp reali ct
n
1
jurnalele (log-urile) de sistem. Un exemplu de setare a datei este urmtorul :
Marketing#clock set 01:44:00 20 September 2009
Marketing#
Marketing#show clock
01:44:07.495 UTC Sun Sep 20 2009
Dup cum se observ, comanda clock set nu a fost introdus n modul global de configurare,
dei comanda show clock arat c aceasta a fost executat corect. Acest lucru se datoreaz
faptului c toate comenzile introduse n modul global de configurare au drept efect modificarea
configuraiei curente din memoria RAM a ruterului (running-config). Aceast configuraie poate fi
salvat n orice moment n memoria NVRAM pentru a fi ncrcat la fiecare repornire a ruterului. n
consecin, setarea datei la valoarea introdus ca argument al comenzii clock set la fiecare ncrcare
a configuraiei nu ar avea sens. Comanda acioneaz doar asupra procesului ce gestioneaz ceasul
ruterului i doar o singur dat, la momentul execuiei.
Comanda show clock este una dintre numeroasele comenzi de interogare disponibile n linia
de comand a Cisco IOS. Comenzile de acest tip sunt rezervate pentru modurile User EXEC i
Privileged EXEC, nefiind permise n niciunul dintre modurile de configurare.
Configuraia curent poate fi afiat prin comanda show running-config. Att runningconfig ct i startup-config au o structur care pstreaz comenzile ntr-o form asemntoare celei
n care au fost introduse, grupate dup modurile corespunztoare. Aceast structur faciliteaz
copierea secvenelor de comenzi dintr -un fiier de configurare i introducerea lor direct la
terminalul utilizat.
Marketing#show running-config
Building configuration...
Current configuration : 1466 bytes
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Marketing
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip subnet-zero
!
!
no ip domain lookup
[...]
1
n practic se folosete NTP (Network Time Protocol) pentru setarea ceasului.
n mod similar se poate lista configura
ia salvat n NVRAM, folosind comanda
startup-config.
Salvarea configuraiei din RAM n NVRAM se realizeaz folsind comanda copy:
show
Marketing#copy running-config startup-config

Destination filename [startup-config]?
[OK]
Marketing#
Aceeai comand realizeaz i copierea comenzilor din startup-config n running-config, cu

diferena c, n acest caz, comenzile din startup-config vor fi introduse peste cele din runningconfig, combinnd efectiv cele dou configura
ii. Comenzile multiple ce nu pot coexista (spre
exemplu comanda hostname) se suprascriu, pstrnd efectul celei mai recente comenzi, dup cum
e de ateptat, dar alte comenzi vor fi introduse peste cele deja prezente, putnd s creez e efecte
nedorite. Practic, comanda copy startup-config running-config este echivalent copierii
linie cu linie a fiierului din NVRAM n linia de comand.
Pentru a evita situaia de mai sus, se poate folosi comanda configure replace nvram:,
care va nlocui complet configuraia curent cu cea din NVRAM. Doar versiunile mai recente de IOS
suport aceast comand.
1.3.1 Protejarea accesului la ruter

n afara configuraiilor de reea ce asigur funcionarea unui ruter, restricionarea accesului la
un ruter reprezint unul dintre primele obiective ce trebuie avute n vedere, pentru a reduce
riscurile de securitate.
1.3.1.1 Protejarea modului privilegiat

Dup cum s-a artat anterior, accesul la modul privilegiat de configurare poate
i sefi (
recomand a fi) protejat printr-o parol. Comanda enable password permite administratorului s
specifice o parol pentru acest scop, dar dezavantajul ei const n faptul c aceast comand,
mpreun cu parola dat drept argument, sunt stocate necriptat n
ierul
fi de configuraie, fiind
vizibile la o simpl afiare a acestuia:
Marketing(config)#enable password cisco
Marketing(config)#exit
!
! Last configuration change at 01:57:34 UTC Sun Sep 20 2009
!
version 12.3
hostname Marketing
!
enable password cisco
!
[...]
O prim variant de securizare att a parolei de enable ct i a altor parole stocate necriptat n
fiierul de configurare, este activarea serviciului de criptare a parolelor prin comanda service
password encryption. Algoritmul de criptare aplicat este unul bazat pe transpozi
ie i este
extrem de uor reversibil (exist scripturi online care realizeaz decriptarea aproape instantaneu):
Marketing(config)#enable password cisco

Marketing(config)#service password-encryption
[...]
!
hostname Marketing
!
enable password 7 02050D480809
[...]
Algoritmul de criptare este denotat de numrul 7. Aceast criptare este uneori ntlnit n
documentaii sub numele de Cisco Type 7 Encryption i nu este considerat o msur de
securitate solid.
Metoda cea mai sigur de stocare a parolei de enable este calcularea unui hash MD5 din textul
parolei i stocarea acestuia n fiierul de configurare. La introducerea unei parole n prompt-ul de
login, acesteia i se va aplica acela
i algoritm i se vor compara hash-urile rezultate. n acest fel,
parola nu este efectiv re
inut, iar algoritmul MD5 asigur faptul c parola iniial nu poate fi
dedus din hash. Pentru a proteja parola n acest fel se folosete comanda enable secret, ca n
exemplul de mai jos:
Marketing(config)#enable secret cisco
The enable secret you have chosen is the same as your enable password.
This is not recommended. Re-enter the enable secret.
Marketing(config)#enable secret class
Marketing(config)#exit
[...]
version 12.3
service password-encryption
!
hostname Marketing
!
enable secret 5 $1$pL39$AX6DY0RveVsZGtpUiOGfa1
enable password 7 02050D480809
Din comenzile anterioare se observ n primul rnd faptul c parola configurat cu enable
secret nu poate avea aceeai valoare cu cea configurat cu enable password, tocmai pentru c
cea din urm poate fi uor dedus. Dei cele dou moduri de configurare a parolei nu sunt mutual
exclusive n fiierul de configurare, n momentul n care comanda enable secret a fost introdus,
ruterul va ignora parola configurat n enable password i o va verifica doar pe cea din enable
secret.
Fiierul de configurare reine doar hash-ul parolei i desemneaz existena unui hash MD5 prin
codul 5 introdus naintea parolei. De asemenea, configuraia curent conine acum i comanda de
activare a serviciului de criptare, service password-encryption.
1.3.1.2 Protejarea liniilor de acces la ruter

S-a menionat deja faptul c una dintre metodele de a accesa interfaa sistemului de operare al
unui ruter este conectarea direct la portul de consol al acestuia. Consola nu este catalogat de
ctre IOS ca o interfa deoarece nu particip n procesul de rutare a pachetelor, ci este considerat
o linie de acces (line).
De asemenea, un ruter suport conexiuni de la distan
, folosind protocoalele Telnet i SSH,
care ofer un acces similar la linia de comand a sistemului de operare. Aceste conexiuni sunt
realizate, n ultim instan, prin una sau mai multe interfee de reea ale ruterului, configurate
pentru traficul de pachete.
10 | P r o i e c t a r e a r e e l e l o r
Ruterul gestioneaz o serie de terminale virtuale ce func
ioneaz asemenea unor interfee
aflate la capetele conexiunilor Telnet sau SSH sosite prin oricare dintre interfeele fizice al ruterului.
Terminalele virtuale poart denumirea vty i sunt numerotate asemenea interfeelor. n mod
implicit exist 5 terminale, de la vty0 la vty4, dar pot fi configurate mai multe. n momentul n care
un administrator se conecteaz prin Telnet sau SSH la un ruter, el va ocupa unul dintre aceste
terminale virtuale atta timp ct conexiunea sa TCP va fi activ.
Este de dorit ca, din moment ce ruterele sunt accesibile din (teoretic) orice reea din to pologia
pe care o formeaz, sistemul lor de operare s nu poat fi accesat de ctre persoane neautorizate.
Este recomandabil ca att terminalele virtuale ct
i consola s fie protejate prin parole. Aceste
parole vor restriciona nu doar accesul la modul p rivilegiat, ci i la modul User EXEC, astfel c un
utilizator care ncearc s acceseze linia de comand fr o parol valabil nu va putea executa nicio
comand pe ruterul respectiv.
Configurarea parolelor pe toate liniile accesibile este exemplificat n cele ce urmeaz:
Marketing#configure terminal
Marketing(config)#line vty 0 4
Marketing(config-line)#password cisco
Marketing(config-line)#login
Marketing(config-line)#exit
Marketing(config)#line console 0
Marketing(config-line)#password cisco
Marketing(config-line)#login
Marketing(config-line)#end
Marketing#
End with CNTL/Z.
Se observ c liniile de acces au un mod de configurare separat, aflat imediat sub modul global
de configurare.
Comanda line vty 0 4 specific faptul c noul mod de configurare va afecta toate cele 5
terminale virtuale (de la 0 la 4),adar
a
comenzile password si login se vor aplica celor 5 linii
simultan. Comanda login indic faptul c linia respectiv va cere o informa
ie de autentificare
nainte de a autoriza accesul. Configurarea comenzii password fr comanda login va avea ca
efect omiterea autentificrii iar configurarea comenzii login fr password va face autentificarea
imposibil (ruterul va atepta la infinit o parol inexistent).
Mai jos este inclus sec
iunea corespunztoare din fiierul de configurare. Parolele au fost
criptate datorit comenzii service password-encryption introduse anterior:
Marketing#show running-config | begin line
line con 0
exec-timeout 0 0
password 7 01100F175804
logging synchronous
login
line aux 0
line vty 0 4
password 7 104D000A0618
login
!
1.3.1.3 Configurarea mesajelor de ntmpinare

Mesajele de ntmpinare (banner) reprezint texte ce suntate
afi nainte sau dup
autentificarea prin o linie de acces. Scopurile lor sunt diversei pot include notificri pentru ali
administratori sau utilizatori, sau informaii despre ruterul la care s-a ncercat conectarea. n orice
11 | A r h i t e c t u r a u n u i r u t e r
caz, un banner minimal trebuie s specifice cel pu
in faptul c sistemul respectiv nu e ste accesibil
persoanelor neautorizate i astfel s nu invite potenialii atacatori.
MoTD, sau Message of The Day este un banner ce este afiat naintea autentificrii att pe vty uri ct i la consol. Un astfel de banner se configureaz n modul urmtor:
Marketing(config)#banner motd *
Enter TEXT message. End with the character '*'.
Acces neautorizat!
Acest ruter este proprietatea companiei X.
*
Marketing(config)#end
Marketing#exit
Marketing con0 is now available
Press RETURN to get started.
Acces neautorizat!
Acest ruter este proprietatea companiei X.
User Access Verification
Password:
Marketing>
Banner-ele pot ocupa linii multiple, de aceea se folosete un caracter delimitator la nceputul i
sfritul mesajului, caracter ce nu trebuie s se regseasc n corpul su. Se observ momentul n
care textul banner-ului este afiat, la conectarea prin co nsol. Acelai banner este afiat i la
conectarea la unul dintre terminalele virtuale.
1.3.2 Configurarea unei interfee

Pentru configurarea interfeelor de reea se folosete un mod specific de configurare, accesat
prin comanda interface urmat de numelei nu mrul interfeei. Odat schimbat modul de
configurare, toate comenzile ulterioare se vor aplica interfe
ei menionate ca argument, pn la
prsirea modului.
Pentru ca o interfa s poat accepta pachete din reeaua la care este conectat, configuraia
sa trebuie s conin cel puin o adres IP i o masc de reea. n plus, implicit, toate interfeele
unui ruter sunt nchise, deci o interfa trebuie activat nainte sau dup ce i se ataeaz o adres:
Marketing(config)#interface serial1/0
Marketing(config-if)#ip address 10.0.0.1 255.255.255.0
Marketing(config-if)#no shutdown
Sep 20 05:15:59.811: %LINK-3-UPDOWN: Interface Serial1/0, changed state to
up
Sep 20 05:16:00.815: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial1/0, changed state to up
Marketing(config-if)#
Asignarea unei adrese IPv4 unei interfe

e se face prin comanda
ip address, urmat de
adresa IP doriti masca de reea corespunztoare. Ruterul nu va permite configurarea a dou
interfee cu adrese ale cror subneturi se suprapun.
Interfeele neconfigurate au un set de comenzi implicite n configuraia curent, precum cel din
exemplul urmtor:
Marketing#show running-config interface serial 1/2
!
interface Serial1/2
no ip address
shutdown
serial restart-delay 0
end
Prefixul no naintea comenzilor anuleaz efectul comenzii respective. Starea implicit a unei
interfee este shutdown, n care interfaa nu particip sub nicio form la traficul de reea. Din
aceast cauz, activarea unei interfee pr esupune eliminarea acestei comenzi din configuraie, prin
comanda no shutdown. n mod similar, spre exemplu, se poate elimina o adres configurat pe o
anumit interfa, prin comanda no ip address, care este, de fapt, un parametru al strii
implicite pentru interfeele neconfigurate.
Sep 20 05:15:59.811: %LINK-3-UPDOWN: Interface Serial1/0, changed state to
up
Sep 20 05:16:00.815: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial1/0, changed state to up
Cele dou mesaje returnate de ruter indic faptul c o conexiune punct la punct a fost stabilit
prin interfaa serial 1/0. Primul mesaj este emis ca rezultat al activrii interfeei, indicnd faptul c
legtura la nivel fizic a fost stabilit, iar al doilea confirm efectuarea legturii la nivelul legtur de
a cu
date (data link). Cu alte cuvinte, protocolul (ncapsularea) de la nivelul 2 a realizat adiacen
interfaa de la cellalt capt.
O practic util n reelistic, n special n reelele cu mai muli administratori, este meninerea
unei eviden e a legturilor ntre echipamentei a scopului pe care aceste legturi le deservesc.
Etichetarea cablurilor poate fi o prim etap, dar Cisco IOS permite administratorilor introducerea
de descrieri direct la nivelul interfeelor, folosind comanda description:
Marketing(config)#interface serial1/0
Marketing(config-if)#description Engineering Link
Marketing(config-if)#end
Marketing#show running interface serial 1/0
!
interface Serial1/0
description Engineering Link
ip address 10.0.0.1 255.255.255.0
end
1.3.2.1 Protocolul CDP

Un protocol extrem de util pentru verificarea legturilor dintre echipamente Cisco este
protocolul CDP (Cisco Discovery Protocol). CDP schimb periodic pachete de informaii cu vecinii si,
pe toate interfe
ele active ale ruterului. n acest fel, fiecare ruter poate identifica celelalte
echipamente la care este conectat.
CDP este activ n mod implicit pe toate interfeele , dar nu poate schimba informaii n ambele
sensuri dect cu echipamente Cisco 1. Prin faptul c CDP trimite implicit informaii despre
dispozitivul local pe toate interfeele, protocolul poate fi considerat o bre de securitate deoarece
ofer unui potenial atacator detalii importante despre echipamentele existente n reea.
Spre exemplu, pentru legtura punct la punct configurat anterior, vecinul ruterului Marketing
apare din perspectiva sa n felul urmtor, ca rezultat al comenzii show cdp neibghors:
1
Protocoalele a cror funcionalitate depinde de echipamentele sau protocoalele unui anumit productor se
numesc protocoale proprietare.
Marketing#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID
Engineering
Local Intrfce
Ser 1/0
Holdtme
179
Capability
R S
Platform
3640
Port ID
Ser 1/0
Comanda afieaz ca rezultat un tabel n care listeaz toi vecinii detectai care ruleaz, de
asemenea, CDP. n cazul de fa, ruterul local, Marketing a detectat prin interfaa Serial1/0 (cmpul
1
Local Intrfce) pe ruterul Engineering , a crui interfa corespondent este tot Serial 1/0 (Port
ID). Ruterul Engineering este un model 3640 i are capabiliti de ruter i switch.
Comanda poate fi completat
i cu parametrul
detail, care va afi
a toate informaiile
cunoscute despre vecini:
Marketing#show cdp neighbors detail
------------------------Device ID: Engineering
Entry address(es):
IP address: 10.0.0.2
CLNS address: 49.0000.1111.2222.4444.00
Platform: cisco 3640, Capabilities: Router Switch
Interface: Serial1/0, Port ID (outgoing port): Serial1/0
Holdtime : 154 sec
Version :
Cisco Internetwork Operating System Software
IOS (tm) 3600 Software (C3640-JK9O3S-M), Version 12.3(22), RELEASE
SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by cisco Systems, Inc.
Compiled Wed 24-Jan-07 18:02 by ccai
advertisement version: 2
VTP Management Domain: ''
Printre alte detalii, comanda poate informa cu privire la adresa IP a vecinuluii, de asemenea,
poate afia versiunea sistemului de operare pe care acesta l ruleaz.
CDP poate fi activat sau dezactivat att la nivel global, pentru toate interfeele ruterului, ct i
pentru fiecare interfa n parte. La nivel global, comenzile sunt cdp run i no cdp run, iar la
nivel de interfa, comenzile sunt cdp enable i no cdp enable.
Marketing(config)#cdp run
Marketing(config)#int serial1/0
Marketing(config-if)#no cdp enable
Marketing#show cdp interface
Serial1/1 is administratively down, line protocol is down
Encapsulation HDLC
Sending CDP packets every 60 seconds
Holdtime is 180 seconds
Encapsulation HDLC
Encapsulation HDLC
CDP este unul dintre puinele protocoale care extind semnificaia numelui (hostname) mai departe de
ruterul local.
n exemplul de mai sus, CDP a fost activat la nivel global prin comanda cdp run i apoi
dezactivat la nivelul interfeei Serial 1/0. n consecin, interfaa Serial 1/0 nu mai apare n lista
interfeelor comenzii show cdp interface, care trimit i primesc mesaje CDP.
Comanda show cdp menioneaz faptul c mesajele CDP se trimit, n mod implicit, la 60 de
secunde iar un ruter este eliminat din tabelele CDP ale vecinilor dup 180 de secunde (holdtime) de
inactivitate.
CDP poate fi folosit la explorarea ele
unei nedocumentate,
re
deoarece permite
administratorului s determine echipamentele i conexiunile dintre ele la fiecare pas.
1.3.2.2 Interfee de loopback

Interfeele loopback sunt interfee virtuale, create n software, de ctre sistemul de operare i
nu au nicio component hardware asociat. Adresele IP pot fi asignate interfeelor de loopback n
aceeai manier ca i pentru interfeele fizice.
Utilizrile interfeelor loopback pot fi numeroase, dar n multe cazuri sunt folosite pentru
asignarea unei adrese IP unui ruter n mod global, fr ca aceast adres s depind de o interfa
fizic anume. Avantajul const n faptul c ruterul poate fi adresat dup adresa configurat pe o
interfa loopback indiferent de care interfee fizice sunt active la un moment dat. De asemenea,
interfeele loopback sunt folosite de unele protocoale de rutarei sunt deseori create n procesele
de testare ale reelelor i protocoalelor.
O interfa de loopback este complet emulat de ctre sistemul de operare, astfel c va fi
activ atta timp ct ruterul este funcional , chiar dac nu are nicio interfa fizic activ. Un ruter
poate avea oricte interfee de loopback, n limita resurselor sale hardware. Crearea unei interfee
loopback se face n momentul n care este accesat modul de configurare al interfe ei:
Marketing(config)#interface loopback 0
Marketing(config-if)#exit
Marketing(config)#interface loopback 1
Marketing#
Interfeele loopback nu necesit activarea prin comanda no shutdown.
1.3.3 Verificarea configuraiilor de baz

n exemplele anterioare s-a artat faptul c ntregul set de comenzi ce descriu configuraia din
memoria RAM sau NVRAM poate fi vizualizat prin comenzile show running-config i show
startup-config.
O comand ce sumarizeaz o mare parte din informaiile ce caracterizeaz din punct de vedere
fizic ruterul curent este show version:
Engineering#show version
Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-IK9O3S3-M), Version 12.3(9e), RELEASE
SOFTWARE ()
Copyright (c) 1986-2005 by cisco Systems, Inc.
Compiled Thu 11-Aug-05 22:59 by ssearch
Image text-base: 0x80008098, data-base: 0x819E5F60
ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)
R1 uptime is 5 weeks, 5 days, 10 hours, 42 minutes
System returned to ROM by reload
System image file is "flash:c2600-ik9o3s3-mz.123-9e.bin"
This product contains cryptographic features and is subject to United
[ linii omise]
cisco 2620 (MPC860) processor (revision 0x102) with 61440K/4096K bytes of
memor.
Processor board ID JAD04480AND (1263225075)
M860 processor: part number 0, mask 49
Bridging software.
X.25 software, Version 3.0.0.
Basic Rate ISDN software, Version 1.1.
1 FastEthernet/IEEE 802.3 interface(s)
2 Low-speed serial(sync/async) network interface(s)
1 ISDN Basic Rate interface(s)
32K bytes of non-volatile configuration memory.
16384K bytes of processor board System flash (Read/Write)
Configuration register is 0x2102
n afar de versiunea efectiv a sistemului de operarei platforma pentru care este destinat,
comanda show version informeaz cu privire la o multitudine de parametri hardware ai ruterului:
Versiunea programului de bootstrap i a bootloader-ului;
Timpul de rulare (uptime);
Ultimul mod de pornire: restartare, pornire simpl, iniializare din ROM, etc;
Numele fiierului sistemului de operare i locul din care acesta a fost ncrcat;
Modelul procesorului i frecvena procesorului;
Memoria RAM disponibil (afiat sub forma X / Y unde X reprezint memoria disponibil
proceselor i sistemului de operare, Y este memoria pentru buffer-ul de pachte iar suma lor
reprezint cantitatea total de memorie RAM instalat);
Numrul de interfee de reea instalate, cu tipurile acestora;
Mrimea memoriei NVRAM;
Mrimea memoriei Flash;
Valoarea registrului de configurare 1 - singura modalitate de a vizualiza aceast valoare.
Aceeai comand este disponibil i pe o varietate de alte echipamente Cisco, precum
switchuri i firewall-uri.
Dei comanda show version afieaz numrul i tipul tuturor interfeelor ruterului, nu ofer
informaii despre parametrii configurabili ai acestora. Informaii detaliate despre fiecare interfa a
unui ruter pot fi ob
inute prin comenzile show interfaces si show ip interfaces. Prima
comand listeaz cu preponderen parametrii de nivel 2 i statistici la nivel de pachete i octei iar
cea de-a doua afieaz parametrii ce privesc configuraia IP i diverse protocoale active pe interfaa
respectiv. Ambele comenzi vor afia informaii despre toate interfeele ruterului i suport cte o
interfa specificat drept parametru pentru a reduce cantitatea de informaii afiat.
Exemplu show interface serial 1/0:
Engineering#show interface serial 1/0
Serial1/0 is up, line protocol is up
Hardware is M4T
Internet address is 10.0.0.2/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
1
Registrul de configurare reprezint o valoare de 2 octei ale cror valori, n diferite combinaii, desemneaz
un anumit comportament la pornirea ruterului (metode de iniializare, localizarea sistemului de operare sau a
fiierului de configurare, etc). Spre exemplu, valoarea 0x2142(hex) va cauza ignorarea fiierului de configurare
din NVRAM. Valoarea uzual este 0x2102. Practic, el funcioneaz asemenea unui set de jumper-i de pe o
plac de baz.
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Restart-Delay is 0 secs
Last input 00:00:03, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1000 bits/sec, 0 packets/sec
5 minute output rate 2000 bits/sec, 0 packets/sec
879 packets input, 644263 bytes, 0 no buffer
Received 878 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
939 packets output, 664067 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 output buffer failures, 0 output buffers swapped out
3 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
Exemplu show ip interface serial 1/0:

Engineering#show ip interface serial1/0
Internet address is 10.0.0.2/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
De regul este util afiarea facil a strii tuturor interfeelor, cu cei mai importani parametri,
n special pentru procesele de troubleshooting. Pentru a lista pe scurt strile tuturor interfeelor i
adresele configurate, se poate folosi comanda show ip interface brief:
Engineering#show
Interface
Serial1/0
Serial1/1
Serial1/2
Serial1/
Loopback0
ip interface brief
IP-Address
OK?
10.0.0.2
YES
unassigned
YES
unassigned
YES
unassigned
YES
192.168.2.1
YES
Method
NVRAM
NVRAM
NVRAM
NVRAM
NVRAM
Status
Protocol
up
up
administratively down down
up
up
Tabelul returnat listeaz toate interfe

ele (inclusiv cele virtuale, precum cea de loopback),
adresele IP configurate, modul n care s-a realizat configurarea (NVRAM denot configurarea static
o alt valoarea posibil ar fi fost DHCP), precum
i starea interfeei la nivel 1 (Status) i starea
protocolului de nivel 2 (Protocol). La nivel fizic, o interfa ce nu a fost nc activat manual va afia
administratively down iar o interfa ce nu poate realiza o legtur datorit unei erori va afia
down.
Cisco IOS ncorporeaz i utilitarele clasice de testare a conectivitii, precum ping i
traceroute. Comanda ping trimite 5 pachete ICMP Echoi afieaz statisticile pachetelor Echo Reply primite:
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms
Cele 5 semne de exclamare reprezint cele 5 pachete Echo-Reply primite cu succes. Simbolurile
mai pot cuprinde . (punct), ceea ce denot un timeout sau un U, care reprezint un mesaj
Unreachable.
De asemenea, comanda ping poate fi introdus i fr argumentul adresei destinaie, pentru a
efectua ceea ce se numete un ping extins:
Router1#ping
Protocol [ip]:
Target IP address: 12.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 20.0.0.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
!!!!!
Se poate observa c n acest caz pot fi configurai mai muli parametri, majoritatea fiind opiuni
ale antetului IP.
Comanda traceroute este folosit pentru a descoperi ruta pe care un pachet o parcurge pn
la destinaie. Pachetele ICMP trimise cu traceroute primesc succesiv valori din ce n ce mai mari
ale cmpului TTL, ncepnd cu valoarea 1 ceea ce cauzeaz pachetului s expire la primul ruter
ntlnit. n momentul n care cmpul TTL ajunge la 0, pachetul nu mai este rutati se trimite napoi
spre surs un pachet ICMP Time Exceeded. Celelalte pachete vor expira peste un numr tot mai
mare de hopuri, pn la destinaia propriu-zis.
Exemplu traceroute:
Router1#traceroute 34.0.0.4
Tracing the route to 34.0.0.4
1 12.0.0.2 4 msec 4 msec 4 msec
2 23.0.0.3 20 msec 16 msec 16 msec
3 34.0.0.4 16 msec * 16 msec
1.3.4 Faciliti ale liniei de comand

Interfeele n linie de comand au fost ntotdeauna cel mai uor extensibile i adaptabile.
Totui, o limitare important rmne faptul c interaciunea n ambele sensuri se face exclusiv n
mod text, iar pentru un administrator aceast limitare se traduce n introducerea dificil a
comenzilor complexe i imposibilitatea memorrii mulimii tutu ror comenzilor disponibile la un
moment dat.
Cisco a introdus o serie de faciliti care accelereaz att procesul de scriere a comenzilor ct i
cel de memorare a sintaxei lor, descrise sumar n cele ce urmeaz.
O serie de comenzi suport parametri implicii, n special pentru confirmri sau atunci cnd
opiunile sunt reduse, ca n exemplul comenzii reload, care repornete ruterul i cere o confirmare
nainte de a se executa:
Engineering#reload
Proceed with reload? [confirm]
Opiunile ntre paranteze ptrate sunt implicite i pot fi alese doar prin apsarea tastei Enter.
Pentru alte opiuni este necesar scrierea lor explicit.
Rezultatele unor comenzi pot avea lungimi considerabile, astfel c textul lor se poate extinde
pe pagini multiple. Prezena textului --More-- la finalul unei pagini indic faptul c utilizatorul
poate apsa tasta Enter pentru a derula nc o linie sau tasta Space pentru a trece la pagina
urmtoare 1. De asemenea, este disponibil i funcia de cutare pentru astfel de rezultate, obinut
prin tastarea /cuvant n condiiile unui text pe mai multe pagini, fapt ce cauzeaz derularea
automat la prima apariie a lui cuvant.
Exemplu:
Engineering#show running-config
!
version 12.3
no service password-encryption
!
hostname Engineering
[fragment]
--More--
Afiarea comenzilor permise este posibil n orice moment, chiar

i pentru comenzi parial
introduse. Pentru aceasta, se folosete caracterul ? fr a fi urmat de tasta Enter. Spre exemplu:
Engineering(config)#?
Configure commands:
aaa
Accounting.
aal2-profile
access-list
alarm-interface
alias
alps
appletalk
arap
arp
async-bootp
atm
backhaul-session-manager
banner
--More--
Authentication, Authorization and

Configure AAL2 profile
Add an access list entry
Configure a specific Alarm Interface Card
Create command alias
Configure Airline Protocol Support
Appletalk global configuration commands
Appletalk Remote Access Protocol
Set a static ARP entry
Modify system bootp parameters
Enable ATM SLM Statistics
Configure Backhaul Session Manager
Define a login banner
Apsarea lui ? afieaz automat toate comenzile disponibile pentru acel context, n ordine
alfabetic i urmate de o scurt descriere (pentru exemplul de mai sus, contextul reprezint
rdcina modului de configurare). Deoarece majoritatea comenzilor n Cisco IOS sunt formate din
mai multe cuvinte/parametri, caracterul ? va afi
a doar variantele pentru urmtorul cuvnt din
comand. Spre exemplu:
Engineering(config)#banner ?
LINE
c banner-text c, where 'c' is a delimiting character
1
Comportamentul este similar cu cel al utilitarului more din Linux.
exec
incoming
login
motd
prompt-timeout
slip-ppp
Set
Set
Set
Set
Set
Set
EXEC process creation banner

incoming terminal line banner
login banner
Message of the Day banner
Message for login authentication timeout
Message for SLIP/PPP
n exemplul de mai sus, prin comanda banner ? se cere listarea tuturor argumentelor ce pot
urma comenzii banner. Este necesar introducerea unui spaiu naintea lui ? pentru a obine lista
urmtorilor parametri. Dac nu se introduce spa
iul respectiv, IOS va ncerca s afieze toate
comenzile care ncep cu irul de caractere introdus pn la semnul ?, ca n exemplul urmtor:
Engineering#co?
configure connect
copy
Conform rezultatului de mai sus, comenzile configure, connect i copy sunt toate
comenzile ce ncep cuirul de caractere co i pot fi introduse n modul Privileged EXEC. Acelai
procedeu poate fi aplicat pentru orice parametru al unei comenzi, nu doar pentru primul.
n unele cazuri, un ir de caractere urmat de semnul ? va afia un singur rezultat posibil. Spre
exemplu, deducnd din rezultatul de mai sus, comanda conf? va afia o singur comand posibil,
configure. Pentru aceste cazuri, IOS va considerairul de caractere neambiguu ca fiind suficient
pentru a identifica o singur comand i l va considera corect.
Engineering#conf?
configure
Engineering#conf ?
memory
network
overwrite-network
terminal
<cr>
Configure
Configure
Overwrite
Configure
from NV memory
from a TFTP network host
NV memory from TFTP network host
from the terminal
Engineering#conf t?
terminal
Engineering#conf t
Engineering(config)#
End with CNTL/Z.
Exemplul de mai sus demonstreaz faptul cirul conf t este irul minimal ce identific n
mod unic comanda configure terminal. Este util determinarea scurtturilor de acest tip
pentru comenzile uzuale deoarece scurteaz considerabil procesul de configurare. (alte exemple:
en pentru enable, int pentru interface, ip add pentru ip address, no sh pentru no
shutdown, etc).
De asemenea, pentru cazurile comenzilor incomplete dar care nu cauzeaz ambiguit
i, IOS
permite completarea automat a comenzii folosind tasta Tab. Spre exemplu,irul conf urmat de
tasta Tab se va transforma n configure, dar acest lucru nu va influena cu nimic efectul comenzii,
tasta Tab oferind doar un feedback vizual i o confirmare a unicitii comenzii.
Alte scurtturi utile ale liniei de comand:
Ctrl-Z ntoarce promptul n modul Privileged EXEC;
Sgeile sus i jos reiau n ordine invers ultimele comenzi executate;
Ctrl-R repet irul de caractere introdus pn n acel moment, util atunci cnd tastarea unei
comenzi e ntrerupt de mesajele ruterului;
Ctrl-A duce cursorul la nceputul liniei;
Ctrl-E duce cursorul la sfritul liniei.
Un important mod de a scurta timpul de introducere a comenzilor este definirea alias-urilor ce
funcioneaz asemenea unor abrevieri ale comenzilor dorite. Un exemplu de definire al unui alias:
Router(config)#alias exec s show ip int brief
Comanda anterioar creeaz un alias al comenzii show ip interface brief, denumit s,

pentru modul EXEC. Din acest moment, comanda va putea fi apelat mult mai simplu, prin tasta s
urmat de Enter. Pentru a vizualiza alias-urile configurate i cele implicite se poate folosi comanda
show aliases.
2 Func ii le unui rute r
2.1 Rutarea
Prin intermediul interfeelor de reea, ruterele interconecteaz reele distincte i stabilesc dup
diferite criterii ce ci vor urma pachetele pentru a ajunge la destinaie. n mod concret, un ruter va
analiza cel puin adresa destinaie a protocolului de nivel 3 (IP) i va cuta n tabela de rutare o rut
care corespunde acestei destinaii. Ruta c orespunztoare va specifica fie adresa ruterului urmtor
(next-hop), sau o interfa de ieire, dac ruterul e direct conectat la reeaua destinaie. n mod
evident, funcionarea corect a procesului de rutare este strns legat de construirea corect a
tabelei de rutare i introducerea rutelor pentru toate destinaiile necesare.
Un ruter este considerat un hop n calea unui pachet. Un pachet poate parcurge o
multitudine de hopuri pn la destina
ie, fiecare ruter de pe parcurs lund decizii n mod
independent cu privire la calea pe care o va urma pachetul, n continuare. n aceste condiii ruterele
trebuie s aib informaii consistente ntr -o anumit msur cu privire la rutele cunoscute. n caz
contrar, dac un ruter primete un pachet pentru care nu cu noate calea spre destinaie, pachetul
nu va putea fi trimis mai departe.
Asigurarea consistenei rutelor ntr-o topologie cu mai multe rutere se poate face n dou
moduri:
manual, prin configurarea individual a rutelor (rutare static);
automat, folosind protocoale de rutare ce comunic informaiile despre fiecare reea
cunoscut tuturor celorlalte rutere i calculeaz cele mai scurte ci spre acestea.
Totodat, consistena informaiilor de rutare ntr -o topologie urmre
te i scopul evitrii
buclelor de rutare, adic situaii n care pachetele vor cicleaz ntre aceleai rutere, fr a mai
ajunge la destinaie, datorit unei configuraii defectuoase.
n cazul configurrii manuale a rutelor, administratorul trebuie s se asigure c buclele de
rutare nu se pot forma. Pe de alt parte folosirea unui protocol de rutare aduce avantajul
mecanismelor de evitare a buclelor construite n fiecare dintre aceste protocoale.
n antetul protocolului IP, cmpul TTL este decrementat cu 1 la fiecare hop pe care pachetul l
traverseaz, deci de fiecare dat cnd acesta este rutat. Pachetul nu mai este trimis mai departe
cnd aceast valoare ajunge la 0. Acest cmp elimin totodat i situaia n care un pachet ar cicla la
infinit ntr-o bucl de rutare.
2.1.1 Tabela de rutare

Tabela de rutare reprezint o structur de date ce stocheaz informa
ii despre destinaiile
cunoscute de un ruter. Practic, dac nicio rut din tabela de rutare nu poate indica o cale spre o
anumit reea, un ruter nu va putea trimite pachete spre acea reea (destinaia e considerat
unreachable).
O rut ofer urmtoarele informaii:
reeaua pe care o adreseaz, indicat printr-o adres de reea i masca respectiv;
interfaa de ieire sau adresa next-hop-ului ce duce spre destinaie;
originea rutei: direct conectat, configurat static sau nvat printr-un protocol de rutare;
metrica i distana administrativ sunt parametri folosii pentru a distinge ntre rute
multiple spre aceeai destinaie.
Originea rutei nu influeneaz modul de construire a tabelei de rutare.
Comanda de vizualizare a tabelei de rutare este show ip route:
Engineering#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
level-2
ia - IS-IS inter area, * - candidate default, U - per-user static
route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
S
R
C
O
C
R
C
221.54.2.0/24 [1/0] via 10.0.0.1

192.168.99.0/24 [120/1] via 10.0.0.1, 00:00:03, Serial1/0
10.0.0.0/24 is subnetted, 1 subnets
10.0.0.0 is directly connected, Serial1/0
199.0.0.1 [110/65] via 10.0.0.1, 00:14:25, Serial1/0
89.0.0.0/8 is directly connected, Loopback1
172.0.0.0/8 [120/1] via 10.0.0.1, 00:00:03, Serial1/0
n prima parte a tabelei de rutare sunt listate codurile ce desemneaz originea rutei iar cea mai
mare parte dintre ele indic protocoale de rutare.
Rutele marcate ca fiind directly connected reprezint reelele cror a le aparin interfeele
active ale ruterului. Reelele direct conectate sunt automat introduse n tabela de rutare, alturi de
interfeele de ieire corespunztoare. n ultim instan, reeaua oricrei destinaii accesibile este
direct conectat la o interfa a unui ruter iar scopul rutelor i al protocoalelor de rutare este, de
fapt, de a gsi drumul spre ruterul care are reeaua respectiv direct conectat.
Un ruter poate ruta n mod implicit ntre toate reelele direct conectate, ncepnd cu momentul
n care interfeele respective au adrese IP configurate. Rutele direct conectate persist n tabela de
rutare atta timp ct interfa
a membr a reelei respective este nc activ. Masca de reea a
rutelor direct conectate este masca ce a fost configurat pe interfaa n cauz.
n momentul n care un ruter primete un pachet IP pe una dintre interfee, adresa destinaie
din antetul pachetului va fi cutat n tabela de rutare, de la cele mai particulare prefixe la cele mai
generale. n cazul n care se gsete o rut ce corespunde destinaiei cutate se consider dou
cazuri:
dac ruta specific o interfa de ieire, pachetul e trimis direct pe interfaa respectiv;
23 | F u n c i i l e u n u i r u t e r
dac ruta specific adresa unui next-hop, ruterul va mai face o cutare n tabela de rutare
pentru a determina interfaa de ieire a rutei direct conectate la reeaua al crui membru e
next-hop-ul respectiv.
Spre exemplu, pentru tabela de rutare anterioar, dac ruterulte
prime
un pachet cu
destinaia 221.54.2.40, aceast destinaie va corespunde primei rute (statice), care specific faptul
c pachetele spre aceast destinaie trebuie trimise la next-hop-ul 10.0.0.1. Ruterul caut apoi o
reea direct conectat pentru destinaia 10.0.0.1 i gsete cea de-a treia rut, spre 10.0.0.0/24, cu
interfaa de ieire Serial1/0, pe care va fi trimis i pachetul.
2.1.2 Rutarea static

S-a menionat anterior faptul c rutele direct conectate ale interfeelor active sunt incluse
automat n tabela de rutare iar un ruter poate s ruteze n mod implicit ntre aceste reele, fr
configurri suplimentare. Aceast facilitate este, ns, util doar pentru reele aflate la o distan de
un singur hop una de cealalt.
10.0.0.0/24
LAN2
LAN1
192.168.1.0/24
R1
R2
192.168.2.0/24
Figura 2-1: Rutarea ntre reele direct conectate

Pentru scenariul de mai sus, lund n considerare doar rutele direct conectate, ruterul R1 nu va
cunoate nicio rut spre reeaua LAN2 din spatele lui R2 deoarece nu i cunoate dect rutele
direct conectate: cea spre LAN1 i spre reeaua dintre R1 i R2. n acest caz, R1 necesit o rut care
i ruta
s l indice pe R2 drept next-hop pentru destinatia LAN2 (n mod normal este necesar
simetric opus, de la R2 la LAN1, pentru a avea conectivitate bidirec ional).
Cea mai simpl metod de a rezolva aceast situa
ie este definirea unei rute statice spre
reeaua LAN2, ca n exemplul de mai jos:
R1(config)#ip route 192.168.2.0 255.255.255.0 10.0.0.2
Tabela de rutare a ruterului R1 afieaz acum:

C
C
S
192.168.2.0/24 [1/0] via 10.0.0.2
R1 va putea trimite pachetele cu destinaia LAN2 ctre R2, acesta din urm identificnd reeaua
destinaie a pachetelor ca fiind una dintre reelele sale direct conectate.
Sintaxa comenzii ip route conine reeaua spre care se definete ruta, mpreun cu masca
aferent. Ultimul parametru poate fi adresa interfe
ei ruterului vecin, prin care trebuie s treac
traficul, sau direct numele unei interfee de ieire. Definirea unei rute statice nu depinde de
distana dintre ruterul curent i destinaia n cauz.
Tabela de rutare poate fi folosit i ca filtru de pachete pe baza destinaiei. Cisco IOS definete
interfaa virtual Null0, supranumit i bit bucket. Pachetele trimise spre aceast interfa
vor fi
pierdute. Este posibil crearea unei rute statice cu aceast destina
ie pentru pachetele ce trebuie
filtrate nainte de a ajunge la destinaie:
R1(config)#ip route 110.0.0.0 255.0.0.0 null0
R1#show ip route
[...]
S
110.0.0.0/8 is directly connected, Null0
O categorie special de rute statice o reprezint rutele default. O rut default este conceput
astfel nct s se potriveasc oricrei destinaii. Exist dou situaii n care se folosesc rutele default:
1. Tabela de rutare este parcurs de la rutele cele mai particulare la cele mai generale, deci de
la mtile de reea cele mai lungi la cele mai scurte; ruta default este cea mai general rut
i va fi folosit atunci cnd destinaia unui pachet nu este gsit n niciuna din celelalte rute
ale tabelei de rutare.
2. Dac ruterul are o singur legtur spre un alt ruter este inutil re
inerea mai multor rute,
toate cu aceeai destinaie de ieire; pentru un astfel de ruter, o rut default este suficient
pentru toate pachetele destinate n afara reelelor sale direct conectate.
O rut default este marcat n tabela de rutare prin simbolul *. Exemplul urmtor
demonstreaz crearea unei rute default:
R1(config)#ip route 0.0.0.0 0.0.0.0 serial1/0
R1(config)#do show ip route
Codes: C - connected, S - static, R - RIP, [...]
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
C
C
S
S*

192.168.2.0/24 [1/0] via 10.0.0.2
0.0.0.0/0 is directly connected, Serial1/0
O rut de tipul 0.0.0.0 0.0.0.0 este denumiti quad-zero. Masca /0 permite acestei rute s
accepte orice destinaie; neavnd o zon de reea n adres, masca specific faptul c toi biii si
pot lua orice valori.
2.1.3 Protocoale de rutare

Rutarea static poate fi preferat n topologii mici deoarece ofer control deplin i introduce un
overhead minim din punctul de vedere al procesrii. Pe de alt parte, o solu
ie bazat exclusiv pe
rute statice sufer de lipsa scalabilitii i de un risc tot mai mare de apariie a erorilor, pe msur
ce reeaua crete.
Protocoalele de rutare adreseaz acest neajuns propagnd rutele ial
(ini cunoscute ca rute
direct conectate) n tabelele de rutare ale tuturor ruterelor ce ruleaz acela
i protocol de rutare.
Ruterele schimb ntre ele informaii de rutare i adaug automat informaiile necesare la propriile
tabele de rutare.
Protocoalele de rutare determin cea mai bun cale spre fiecare
earedestinaie utiliznd
algoritmi proprii. Un avantaj major al multor protocoale de rutare este faptul c informa
iile de
rutare actualizate sunt schimbate de fiecare dat cnd nea
re are loc o schimbare. Acest lucru
permite ruterelor s nvee dinamic reelele nou conectate dar i s gseasc rute alternative n
cazul n care unele legturi devin inutilizabile.
n comparaie cu rutele definite static, protocoalele de rutare necesit mult mai puin efort de
mentenan din partea administratorului, dar configurarea lor presupune cunotine mai avansate
ale fiecrui protocol de rutare folosit. Totui, protocoalele de rutare sunt mult mai costisitoare
pentru resursele de procesor i memorie ale ruterelor. n consecin, multe reele implementeaz o
schem hibrid, care combin rutarea static i protocoalele de rutare.
Timpul de convergen al unei re
ele este intervalul n care toate tabelele de rutare ale
ruterelor ajung ntr-o stare de consisten, deci cnd toate ruterele cunosc destinaiile existente i
rutele corecte spre acestea. n general, o ea
re este inutilizabil sau dificil de controlat ct timp
converge, de aceea protocoalele de rutare urmresc s ating un timp de convergen ct mai mic.
Convergena ine i de topologie, ca ntreg, din moment ce fiecare ruter depinde de informa
iile
transmise de vecinii si, dari de fiecare ruter n parte, deoarece fiecare ruter ce particip ntr-un
protocol de rutare trebuie s calculeze independent cile cele mai bune spre toate destina
ii
le
cunoscute, urmnd s introduc aceste rute n tabela de rutare.
2.1.3.1 Parametrii rutelor

Indiferent de originea unei rute, n tabela de rutare sunt ntotdeauna preferate rutele mai
particulare (cu o masc de reea ct mai lung). n cazul n care rute din surse diferite ofer ci
spre aceeai destinaie, alegerea celei mai bune rute trebuie fcut i dup alte criterii.
Pn n acest moment s-a artat faptul c rutele pot proveni din trei tipuri diferite de surse:
rutele direct conectate, care sunt automat adugate la tabela de rutare, rutele definite static
i
rutele nvate prin intermediul protocoalelor de rutare. n aceste situaii apar deseori mai multe
rute spre aceeai destinaie, dar cu origini diferite. Spre exemplu, pot exista o rut static i o rut a
unui protocol de rutare spre aceeai destinaie, dou rute de la protocoale de rutare diferite sau
chiar dou rute nvate prin acelai protocol de rutare care duc, prin ci diferite, spre aceeai reea.
Elementul folosit pentru a distinge ntre originile rutelor este numit distan administrativ.
Din punctul de vedere al ruterului, distana admin istrativ desemneaz un grad de ncredere sau
preferin asupra anumitor rute, n detrimentul altora. n practic, distana administrativ
determin o ierarhie bine definit a tuturor modurilor posibile n care o rut poate fi originat.
Cteva dintre cele mai des ntlnite valori ale distanei administrative sunt urmtoarele:
Metod / Protocol
Distan administrativ (AD)
Rut direct conectat
0
Rut static
1
EIGRP sumarizat
5
BGP extern
20
EIGRP intern
90
OSPF
110
IS-IS
115
RIP
120
EIGRP extern
170
BGP intern
200
Origine necunoscut
255
Figura 2-2: Tabelul distanelor administrative
O valoare mai mic a distanei administrative este ntotdeauna preferat. Dac, spre exemplu,
un protocol de rutare introduce o rut n tabela de rutarei administratorul configureaz ulterior o
rut static spre aceeai destinaie, cea de -a doua o va nlocui pe cea dinamic datorit distan
ei
administrative.
Problema legturilor multiple spre aceeai destina ie rmne chiar i dup ce s-a luat o decizie
pe baza distanei administrative. n reelele n care poriuni din topologie formeaz bucle deseori se
ntmpl ca un protocol de rutare s anune dou sau mai multe rute spre aceeai destinaie, care
au aceeai distan administrativ, dar urmeaz ci diferite pn la reeaua respectiv.
Pentru astfel de situa
ii este nevoie de un procedeu de decizie ce implic n mod direct
drumurile pe care pachetele le pot lua pn la destina
ie.
Metrica reprezint o metod de
cuantificare a legturilor dintre rutere. Metricile sunt valori numerice ataate rutelor ce au ca scop
diferenierea rutelor provenite de la acelai protocol de rutare. Fiecare protocol de rutare are
propria sa metod de calculare a metricii, iar calcularea acesteia presupune implicarea unor
parametri precum numrul de rutere pn la destinaie, sau limea de band a fiecrei legturi.
n momentul n care un protocol de rutare determin dou rute spre aceea
i destinaie, dac
cele dou rute au metrici diferite, va fi preferat ruta cu metrica cea mai mic. Este posibil ca dou
rute s aib chiari aceeai metric, chiar dac urmeaz trasee diferite. n acest caz, rmne la
latitudinea administratorului i a capabilitilor protocolului de rutare dac r utele multiple vor fi
folosite n paralel, ntr-o schem de load balancing, sau nu.
Distana administrativ i metrica pot fi vizualizate n tabela de rutare prin comanda show ip
route i sunt notate sub forma [AD/metric] pentru ficare rut:
R 192.168.8.0/24 [120/2] via 192.168.4.1, 00:00:26, Serial0/0/1
Exemplul de mai sus este al unei rute nv

ate prin RIP (R), spre reeaua 192.168.8.0/24. Ruta
are distana administrativ 120 (implicit pentru protocolul RIP) i metrica 2.
2.1.3.2 Clasificarea protocoalelor de rutare

Un domeniu de rutare, denumit i sistem autonom, cuprinde o topologie de rutere aflate sub o
administraie comun. De regul aceste rutere ruleaz acelai protocol de rutare. Internetul este
structurat ca o reea de sisteme autonome, deci protocoalele de rutare se mpart n dou categorii:
IGPs: Interior Gateway Protocols sunt protocoalele de rutare ce ruleaz n interiorul unui
sistem autonom;
EGPs: Exterior Gateway Protocols sunt protocoalele de rutare ce ruleaz ntre sisteme
autonome distincte.
IGP-urile pot fi mprite n alte dou categorii, dup modul lor de funcionare
Protocoale distance-vector. Rutele sunt anunate ca vectori caracterizai prin distan i
direcie. Distana este dat de metrica protocolului respectiv, care poate fi chiar i numrul
de hopuri pn la destinaie. Direcia este dat de interfaa de ieire sau de adresa nexthop-ului. Exemple: RIP, RIPv2.
Protocoale link-state. Rutele sunt stocate nu doar din perspectiva ruterului curent, dar
fiecare instan a unui protocol de rutare link-state pstreaz i o topologie intern a
reelei, pe care o deduce din informaiile schimbate cu vecinii si. Toate ruterele ce ruleaz
acelai protocol link-state trebuie s cunoasc aceeai topologie a reelei. Fiecare ruter
calculeaz rutele cele mai bune din aceast topologie, pentru a le introduce n tabela de
rutare, n mod independent. Exemple: EIGRP, OSPF, IS-IS.
2.2 RIP
2.2.1 Descrierea protocolului
RIP este cel mai vechi protocol de rutare nc utilizat. Este un protocol de tip distance vector,
deci nu pstreaz o topologie a ntregii re
ele n memorie ci doar distana i direcia spre fiecare
destinaie.
Funcionarea protocolului este relativ simpl. RIP va trimite ntregul coninut al tabelei de
rutare pe toate interfeele ce particip n pro cesul de RIP, sub forma unor mesaje de broadcast de
nivel 3, la fiecare 30 de secunde. Din moment ce ruterele nu propag mesajele broadcast, fiecare
ruter va emite mesajele de broadcast n mod periodic, ctre to i vecinii si.
Din cele de pn acum se deduc o serie de dezavantaje ale lui RIP. n primul rnd, overhead-ul
pe care protocolul l impune traficului de reea prin faptul c fiecare ruter trimite la 30 de secunde
toat tabela sa de rutare tuturor vecinilor si poate deveni extrem de repede inacceptabil pentru
reele cu mai mult de cteva rutere. Pe de alt parte, din moment ce mesajele RIP-ului sunt
broadcast, nu exist o metod de a izola acest trafic pentru a nu ncrca inutil alte dispozitive din
reea (ca staiile, spre exemplu) cu procesarea acestor mesaje de broadcast. n plus, broadcast-urile
pot prezenta i un risc de securitate, fiind uor interceptabile de la orice staie conectat n reea.
RIP este, de asemenea, i singurul protocol exclusiv classful disponibil n Cisco IOS. Acest lucru
nseamn c reelele anunate prin RIP vor fi anunate fr masca lor corespunztoare, i tuturor
acestor reele, la primirea lor de ctre un alt ruter, li se va ataa masca implicit a clasei din care fac
parte reelele respective.
Exemplul de mai jos demonstreaz o situaie simpl n care comunicarea ntre reele devine
imposibil datorit acestei limitri.
172.16.0.0/16
LAN2
LAN1
10.1.0.0/24
R1
RIP Update: 10.0.0.0/8
R2
10.2.0.0/24
Figura 2-3: Update RIP

n exemplul de mai sus, dac ntre cele dou rutere se folosete RIP, staiile din reeaua
10.1.0.0/24 nu vor putea comunica cu cele din reeaua 10.2.0.0/24. Acest lucru se ntmpl datorit
faptului c R2 primete prin RIP un update de la R1 pentru reeaua 10.0.0.0/8 (clasa A) n timp ce R2
are deja reeau a 10.2.0.0/24 direct conectat, un subnet al reelei 10.0.0.0/8, cu o masc de reea
mai lung dect cea primit prin update. Reeaua sa are un prefix mai lung, deci e mai precis, i nu
va permite rutei anunate de RIP s fie stocat n tabela de rutare.
Deoarece mtile de reea nu sunt transmise n update-urile RIP, diferenierea dintre reele se
face la nivel classful.
Metrica folosit de RIP este cea a hop-count-ului. Practic, rutele sunt evaluate din punctul de
vedere al metricii n funcie de numrul de rutere (hopuri) pe care le traverseaz pn la destinaie.
Metrica maxim suportat de RIP este 15, valoarea 16 fiind folosit pentru a desemna o metric
infinit sau o rut unreachable.
2.2.2 Configurarea protocolului

nainte de configurarea oricrui protocol de rutare trebuie s existe, n prealabil, o configuraie
IP a cel puin unei interfee active. Cu alte cuvinte, tabela de rutare a unui ruter trebuie s conin
cel puin reelele direct conectate.
Minimal, configurarea RIP are dou etape:
intrarea n modul de configurare a protocolului de rutare prin comanda router rip;
definirea interfeelor ce particip n protocolul de rutare prin comenzi de tip network.
Router(config)#router ?
bgp
Border Gateway Protocol (BGP)
eigrp
Enhanced Interior Gateway Routing Protocol (EIGRP)
isis
ISO IS-IS
iso-igrp IGRP for OSI networks
mobile
Mobile routes
odr
On Demand stub Routes
ospf
Open Shortest Path First (OSPF)
rip
Routing Information Protocol (RIP)
Router(config)#router rip
Router(config-router)#
Ajutorul oferit de linia de comand poate fi folosit i pentru a lista toate protocoalele de rutare
suportate de ruter, ca n exemplul de mai sus. Se observ c intrarea n modul de configurare al
unui protocol de rutare este reflectat i in modul de conf igurare al prompt-ului: config-router.
Comanda nu porne
te efectiv procesul RIP, ci doar creeaz contextul pentru comenzile de
configurare ale acestuia. nchiderea unui protocol de rutare se face prinarea
ata cuvntului
no
nainte de comanda router i numele protocolului dorit. Ex: no router rip. nchiderea unui
protocol de rutare are ca efect i eliminarea configuraiilor acestuia.
nainte ca protocolul s poat efectiv funciona, ruterul trebuie s tie ce interfee vor fi folosite
pentru a comunica cu ruterele vecine i ce reele vor fi anunate n protocolul de rutare. Comanda
network specific aceste informaii, urmat de adresa classful a uneia sau mai multor reele direct
conectate.
Exemplu:
R1(config)#router rip
Router(config-router)#do show ip int brief
Interface
IP-Address
OK? Method Status
Serial1/0
20.0.0.1
YES manual up
Loopback0
100.0.0.1
YES manual up
Loopback1
110.0.0.1
YES manual up
Loopback2
120.0.0.1
YES manual up
R1(config-router)#network 20.0.0.0
R1(config-router)#
Protocol
up
up
up
up
Comand network are dou efecte distincte:

activeaz RIP pe toate interfeele ce se ncadreaz n adresa de reea specificat ca
parametru pentru a putea primi i trimite update-uri RIP;
anun reelele respectivelor interfee n update-urile RIP.
Introducerea unei adrese de subre
ea va avea ca efect trunchierea adresei la lungimea
prefixului clasei respective. Cu alte cuvinte, comanda network 192.168.12.64 introdus pentru
o interfa din reeaua 192.168.12.64/26 va lua n considerare doar adresa 192.168.12.0, cu masca
sa classful (/24).
Activarea protocolului RIPi pe R2, mpreun cu adugarea reelei 20.0.0.0 prin comanda
network, va afia urmtoarea tabel de rutare:
R
C
C
R
R

100.0.0.0 [120/1] via 20.0.0.1, 00:00:26, Serial1/0
110.0.0.0 [120/1] via 20.0.0.1, 00:00:23, Serial1/0
120.0.0.0 [120/1] via 20.0.0.1, 00:00:21, Serial1/0
Se observ c rutele spre reelele direct conectate ale lui R1 au fost propagate pe R2 cu metrica
1 (un hop).
Pentru vizualizarea informaiilor generale despre toate protocoalele de rutare care ruleaz la
un moment dat, exist comanda show ip protocols. Comanda afieaz interfeele active n
fiecare protocol de rutare, comenzile network introduse i vecinii cu care se realizeaz schimbul de
informaii.
R1#show ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 24 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Redistributing: rip
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
Serial1/0
2
2
Loopback0
2
2
Loopback1
2
2
Loopback2
2
2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
20.0.0.0
30.0.0.0
100.0.0.0
110.0.0.0
120.0.0.0
Routing Information Sources:
Gateway
Distance
Last Update
Gateway
Distance
Last Update
20.0.0.2
120
02:00:07
Distance: (default is 120)
n unele situaii, precum cele n care o reea local format din staii trebuie anunat n
protocolul de rutare, nu este necesar trimiterea update-urilor de rutare pe acea interfa deoarece
nu mai exist rutere care s ruleze RIP neaua
re respectiv.
n general, este de dorit evitarea
traficului inutil n aceste segmente att pentru c el poate reprezenta un risc de securitate, putnd
fi interceptat de ctre staii, ct i pentru c staiile vor trebui s proceseze broadcast-urile de nivel
3 pn la nivelul transport, pentru a realiza c mesajele respective nu le sunt adresate.
Comanda passive-interface adreseaz aceste situa
ii prin mpiedicarea trimiterii
broadcast-urilor cu informaii de rutare pe interfeele dorite. Chiar daca o interfaa este pasivizat
n acest fel, ea poate s fie inclus n continuare n update-urile de rutare.
Exemplu:
R1(config-router)#passive-interface serial1/0
Ruterele configurate cu o rut default vor folosi aceast rut de fiecare dat cnd parcurgerea
tabelei de rutare pentru destinaia unui pachet nu va returna nicio alt rut. n acest caz, pachetul
va fi trimis spre next-hop-ul sau interfaa de ieire indicat de ruta default.
Este destul de probabil ca un sistem autonom care ruleaz RIP s aib o singur conexiune cu
exteriorul, spre Internet, de exemplu. Pentru ca toate rutere s poat trimite pachete spre Internet
prin aceast conexiune, ele vor trebui configurate individual cu cte o rut default. RIP, icaalte
protocoale de rutare, ofer posibilitatea propagrii unei astfel de rute default alturi de celelalte
rute ale domeniului de rutare. Avantajul const ntr-o administrare mult mai facili n faptul c
ruta respectiv va deveni rut default n mod automat pe toate ruterele pe care va fi instalat.
Pentru ca o rut default s poat fi propagat ntr-un domeniu de rutare RIP, un ruter ce are
deja definit o rut default trebuie configurat cu urmtoarea comand:
R1(config-router)#default-information originate
Ruterul va ncepe s se anune pe sine ca fiind next-hop-ul rutei default i va fi folosit de ctre
toi vecinii ca destinaie pentru pachetele destinate n afara reelei. Pentru a propaga o rut default
chiar i n absena unei rute default din tabela de rutare se poate aduga parametrul always
comenzii de mai sus.
2.2.3 Caracteristici ale protocoalelor distance-vector

Termenul distance-vector desemneaz faptul c ruterele ce ruleaz astfel de protocoale rein
doar o imagine local a topologiei, n care fiecare destina
ie este caracteri zat printr-o distan
(metric) i o direcie (interfa de ieire sau adres next-hop).
n general, protocoalele distance-vector trimit ntreaga tabel de rutare la intervale periodice,
tuturor vecinilor, folosind mesaje broadcast. La primirea informa
ii lor de rutare de la vecini, un
ruter incrementeaz metrica rutelor primite i le instaleaz pe cele necunoscute n propria tabel de
rutare, mpreun cu adresa next-hop a ruterului de la care au fost primite. Protocoalele de rutare
distance-vector folosesc algoritmul Bellman-Ford pentru calcularea cilor celor mai scurte ctre
destinaiile cunoscute.
Avantajele protocoalelor distance-vector constau n uurina de administrare i configurare i
consumul redus de resurse. n mod evident, orice protocol de rutare folosete mai multe resurse
dect o implementare bazat exclusiv pe rutare static, dar protocoalele distance-vector utilizeaz
mai puin memorie i putere de procesare dect cele link-state.
n acelai timp, unul dintre cele mai mari dezavantaje ale acestor protocoale este convergena
greoaie, deoarece timpul de convergen depinde de update-urile periodice. O consecin a acestei
limitri este i scalabilitatea redus, deoarece pe msur ce o reea crete, durata de propagare a
unei modificri, deci a convergenei, crete. Problema convergenei este una important deoarece
n timpul stabilirii convergenei unui protocol, tabelele de rutare pot conine informaii
inconsistente ce pot duce la stabilirea unor bucle rutare.
O soluie pentru accelerarea convergenei este folosirea de triggered updates, adic mesaje de
update trimise nu doar periodic, dup un anumit interval, cii la apariia unui anumit eveniment ce
indic schimbri n topologia reelei. Chiar i cu aceast facilitate, timpul de convergen al acestor
protocoale este situat mult peste cel al protocoalelor link-state.
2.2.3.1 Holddown timers

Dei folosirea de triggered updates accelereaz convergena, acestea pot cauza efecte
duntoare n anumite condi
ii. O astfel de situaie este reprezentat de interfeele instabile
(flapping), a cror legtur oscileaz ntre up i down fie din cauza unei erori de nivel 2 fie din cauza
unei imperfeciuni de proiectare sau instalare la nivelul fizic. Reacia pre a rapid a unui ruter la
fiecare astfel de schimbare a strii unei interfee poate cauza bucle de rutare din cauza timpului de
propagare a modificrii.
Ruterele folosesc un timp de ateptare ( holddown timer) pentru a evita reinstaurarea imediat
a unei rute picate, n urma unui update de rutare sosit de la un vecin ce poate s nu fi aflat despre
modificarea survenit.
Funcionarea holddown timers poate fi redus la urmtoarele etape:
1. o reea este declarat inaccesibil printr -un mesaj al unui vecin, iar ruterul ce prime
te
informaia consider ruta ca fiind posibil nedisponibil i pornete holddown timer-ul;
2. ruterul ignor toate update-urile despre acea rut cu metrici egale sau mai defavorabile n
perioada holddown timer-ului;
3. ruterul accept reinstaurarea rutei doar dac primete o rut cu o metric mai bun dect
cea veche; o metric mai bun asigur faptul c vecinii ruterului au aflat despre modificare
i au calculat alte ci spre destinaie, deci nu exist riscul unei bucle.
O rut marcat ca fiind posibil inaccesibil va fi folosit pentru a trimite pachete deoarece
situaia poate fi cea prezentat anterior, a unei interfee instabile.
2.2.3.2 Split horizon

Split horizon reprezint o alt tehnic de evitare a buclelor de rutare. Regula split horizon
enun faptul c un ruter nu trebuie s trimit informaii despre o reea pe aceeai interfa prin
care a aflat despre acea reea.
Logica din spatele acestei reguli este uor de dedus. Atta timp ct un ruter afl pentru prima
oar despre o anumit reea de la unul dintre vecini, se poate considera c vecinul respectiv este
mai aproape de acea reea i va afla despre eventualele modificri ale sale mai repede dect ruterul
care a aflat despre ea din update-urile vecinului. n consecin, primul ruter nu are dreptul s trimit
informaii despre aceste rute vecinului su, evitnd riscul de a-i suprascrie tabela de rutare cu
informaii neactualizate.
2.2.3.3 Route poisoning

n cazul n care un ruter detecteaz c o reea direct conectat nu mai este disponibil, nu o va
mai introduce n update-urile de rutare. Vecinii si vor pstra ruta pe durata holddown timer-ului,
pn cnd aceasta va expira din tabela de rutare din lipsa update-urilor. Acest proces poate fi
accelerat prin tehnica route poisoning.
Folosind route poisoning, un ruter ce detecteaz prezen
a unei reele nevalide va transmite
ruta ctre acea reea n update -urile sale cu valoarea metricii 16, ceea ce denot n RIP o metric
infinit, adic o reea unreachable. Ruta astfel primit de ctre vecini va fi, de asemenea, trimis
mai departe cu metrica 16, astfel propagndu-se n ntreaga re
ea informaia despre reeaua
devenit inaccesibil, nemaifiind nevoie s se atepte expirarea unor timere.
2.2.4 RIPv2
RIPv2 este definit n RFC1723. Principala mbunt
ire adus de RIPv2 este eliminarea
funcionalitii exclusiv classful. RIPv2 poate s transporte rutele mpreun cu tile
m de reea
corespunztoare dei, n mod implicit, sumarizarea la graniele classful este nc activ. n plus,
RIPv2 eficientizeaz utilizarea traficului n ea
re prin folosirea adresrii multicas t n locul celei
broadcast, spre adresa 224.0.0.9.
Configurarea RIPv2 este identic cu cea pentru RIP. Comanda network are aceeai semnificaie
ca i n prima versiune, dar rutele direct conectate vor fi anunate folosindu-se mtile de reea de
pe interfeele respective. Singura diferen const n specificarea versiunii sub modul de configurare
al protocolului de rutare:
R2(config-router)#version 2
Comanda show ip protocols arat versiunea update-urilor trimise i primite (cmpurile

Send i Recv):
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 8 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
Serial1/0
2
2
[...]
Un comportament interesant al celor dou versiuni ale protocolului RIP este faptul c versiunea
1 este forward-compatible cu versiunea 2. Cu alte cuvinte, un ruter care ruleaz versiunea 1 va
trimite doar update-uri classful, dar va putea primi update-uri classless, de la un ruter care ruleaz
versiunea 2 (dei le va interpreta tot classful). Acest lucru este posibil datorit structurii mesajelor
de update care permit ignorarea cmpurilor ce con
in prefixul reelei pentru un ruter ce ruleaz
versiunea 1.
Sumarizarea este activ n mod implicit si pe versiunea 2 a protocolului RIP. Mai exact, dac un
ruter are interfe
e conectate la subreele ale aceleiai reele classful, RIPv2 va propaga n
continuare doar re
eaua classful, considernd-o o sumarizare a celorlalte ele.
re Dezactivarea
sumarizrii se face prin comanda no auto-summary:
R2(config-router)#no auto-summary
Posibilitatea sumarizrii rutelor este o facilitate deseori util pentru c ajut la reducerea
tabelelor de rutare i accelerarea procesului de decizie al ruterelor. Din aceast cauz RIPv2 permite
i configurarea sumarizrii manuale, n condiiile n care cea automat este dezactivat. Comanda
pentru sumarizare se introduce pe interfaa care va trimite ruta sumarizat iar sintaxa ei este:
R1(config-if)#ip summary-address rip 96.0.0.0 255.0.0.0
Adresa i masca reprezint ruta sumarizat. RIP nu permite dect sumarizarea n adrese de
reea cu masca cel puin egal cu masca implicit a clasei reelei sumarizate.
2.3 Liste de acces (ACLs)

O list de acces (ACL Access Control List) reprezint un set de instruc
iuni ce descriu
parametrii dup care sunt selectate anumite tipuri de trafic n vederea filtrrii, inspectrii sau
procesrii ntr-un mod diferit. Una dintre principalele utilizri ale listelor de acces, ce va fi descris
n continuare, este aplicarea lor pe interfeele de reea ale unui ruter cu scopul de a putea specifica
care tipuri de trafic sunt permise prin interfeele respective i care nu.
Aplicarea ACL-urilor pe interfee cu scopul de a filtra traficu l se face conform regulii: un ACL
pentru fiecare protocol al fiecrei direcii a fiecrei interfee . Deci un ruter cu dou interfee, care
ruleaz IP, IPX i AppleTalk poate suporta 2 interfee x 2 direcii x 3 protocoale = 12 ACL-uri.
Un ruter nu are, n mod implicit, niciun ACL configurat, iar traficul este permis necondi
ionat
att la intrare ct i la ieire, din toate interfeele. Prezena unui ACL la intrarea unei interfee, spre
exemplu, are ca efect filtrarea traficului nainte ca pachetele acestuia s ajung n procesul de
rutare sau s fie supuse altor prelucrri. Pachetele care trec cu succes de ACL vor fi singurele ce vor
fi preluate de ruter.
2.3.1 Modul de funcionare a listelor de acces

Un ACL conine o serie de teste care analizeaz antetele de niv el 3 i 4 ale pachetelor. Fiecare
test este urmat de o decizie binar: permit sau deny.
Cnd un ACL este aplicat pe o interfa
, toate pachetele care circul n sensul respectiv vor fi
confruntate cu testele din ACL. Parcurgerea elementelor unui ACL se face secvenial i se oprete n
momentul n care se determin c traficul se ncadreaz ntr-unul dintre teste, moment n care se
aplic aciunea corespunztoare testului respectiv. Dac aciunea este permit, pachetul este lsat s
treac la fel ca i n li psa unui ACL. Dac aciunea este deny, pachetul este ignorat fr a se trimite
vreun fel de notificri.
Pentru cazul n care un pachet nu se ncadreaz n condiiile niciunui test din ACL, pachetul este
ignorat, ca i n cazul unei aciuni explicite de deny. ACL-urile au o aciune implicit de deny la
sfritul lor, ce nu poate fi eliminat i care se aplic tuturor pachetelor ce nu sunt acoperite de
condiiile ACL-ului. Din acest motiv aplicarea unui ACL vid are ca efect blocarea complet a traficului
i, totodat, un ACL care nu conine nicio condiie care s permit traficul este echivalent cu un ACL
vid care blocheaz orice pachet.
Fiecare test din cadrul unui ACL este executat n mod independent
i poate conine criterii
legate de parametrii de nivel 3 sau 4 ai pachetelor. Spre exemplu, un ACL aplicat pe o interfa
a
unui ruter conectat la o reea local, pe direcia in, poate fi citit n felul urmtor:
blocheaz traficul TCP al tuturor staiilor din LAN ctre portul 80 al oricrei destinaii =
reeaua local nu va mai avea acces la servere web;
blocheaz tot traficul ICMP al staiei X spre serverul Y = filtrarea se face pe baza protocolului
ICMP;
blocheaz traficul IP (TCP+UDP) al tuturor staiilor mai puin cea a efului de departament la
serverele altor departamente n intervalul orar 09-17 = ACL-ul este activ ntr-un anumit
interval orar;
permite tot traficul.
Ultima condiie este necesar din cauza instruciunii implicite de deny de la sfritul ACL -ului.
Lipsa ultimei instruciuni are ca efect crearea unui ACL creat doar din instruciuni de deny, ceea ce
este echivalent cu blocarea complet a traficului din interior spre exterior.
Un exemplu al unui ACL aplicat pe interfaa dinspre exterior, pentru a proteja accesul la reeaua
local, poate fi urmtorul:
permite traficul din exterior spre LAN doar pentru conexiuni deja stabilite din interior =
filtrarea analizeaz procesul de handshake al TCP.
Un ACL care conine doar aceast instruciune va bloca tot traficul din exterior spre reeaua
local, mai puin traficul conexiunilor TCP iniiate din interior.
n mod evident, ordinea instruciunilor dintr -un ACL este extrem de important. Spre exemplu,
n primul ACL, prezena lui permite tot traficul la nceputul ACL -ului ar fi fcut toate celelalte
instruciuni inutile deoarece decizia s-ar fi aplicat din start tuturor pachetelor.
De asemenea, un ACL trebuie proiectat
i avnd n vedere scopul su. Dac traficul este n
preponderen permis, cu mici excepii, ACL-ul va fi construit din statement-uri de deny urmate de
un statement care permite tot restul traficului. n mod similar, dac traficul este permis doar pentru
cteva excepii, statement-urile vor acoperi aceste excepii iar restul traficului va fi ignorat de ctre
statement-ul implicit al fiecrui ACL.
Din moment ce un ACL este parcurs pentru fiecare pachet n parte, se recomand i rearanjarea
intrrilor acestuia n funcie de frecvena apar iiei anumitor tipuri de trafic, pentru mbuntirea
performanei.
2.3.2 Tipuri de liste de acces

Dup structura lor, ACL-urile se mpart n dou categorii:
ACL-uri standard, care pot filtra traficul doar pe baza informaiei din cmpul de adres
surs al pachetelor;
ACL-uri extinse, care pot filtra traficul pe baza tuturor parametrilor de adresare de nivel 3
sau 4.
La creare, ACL-urile primesc un numr de identificare folosit att pentru a distinge ntre mai
multe ACL-uri configurate pe acelai ruter ct i pentru a stabili ce tip de ACL se creeaz:
numerele n intervalele [1, 99] i [1300, 1999] sunt ale ACL-urilor standard;
numerele n intervalele [100, 199] i [2000, 2699] sunt ale ACL-urilor extinse.
Intervalele neasignate aparin altor protocoale de nivel 3. Intervalele de mai sus se refer doar
la protocolul IP.
n principiu, un ACL poate fi plasat oriunde n calea unui pachet, de la surs pn la destinaie.
Totui, plasarea unui ACL trebuie fcut n funcie de tipul su:
ACL-urile standard trebuie plasate ct mai aproape destina
ie deoarece ele nu specific o
destinaie anume, iar plasarea lor aproape de surs poate s blocheze traficul i spre alte destinaii
dect cele intenionate.
ACL-urile extinse trebuie plasate ct mai aproape de surs deoarece ele cuprind att
informaiile despre surs ct i despre destinaie iar filtrarea pachetelor mai trziu, pe parcurs, ar
crea trafic inutil n reea.
Conceptele de sursi destinaia din cadrul ACL -urilor standardi extinse au sens doar n
momentul n care ACL-ul este aplicat unei interfee i i se specific sensul (in sau out).
2.3.3 Configurarea listelor de acces standard

ACL-urile standard filtreaz doar pe baza sursei, deci acesta va fi singurul criteriu de decizie.
Sursa pachetelor se specific sub forma unei adrese i a unui wildcard mask.
Pentru adrese de reea, un wildcard mask este calculat ca fiind inversul binar al mtii de reea.
Pentru clarificare, iat cteva exemple de coresponden e ntre network mask i wildcard mask:
masc 255.255.0.0 -> wildcard 0.0.255.255
masc 255.255.255.192 -> wildcard 0.0.0.63
masc 255.252.0.0 -> wildcard 0.3.255.255
ntr-o astfel de comparaie, wildcard mask-urile pot fi considerate echivalente (ca utilitate) cu
mtile de reea. n realitate, ns, excepia intervine n faptul c un wildcard mask poate conine
iruri discontinue de bii de 1, n timp ce acest lucru nu este permis n cazul mtilor de reea.
Spre exemplu, pentru crearea unui ACL standard cu identificatorul 10, care permite accesul
tuturor staiilor din reeaua 192.168.2.0/24 spre orice destinaie, se folosete urmtoarea comand:
R2(config)#access-list 10 permit 192.168.2.0 0.0.0.255
Crearea ACL-ului are loc odat cu primul statement introdus. ACL-ul poate fi continuat. Spre
exemplu, urmtoarele dou comenzi permit accesul tuturor sta
iilor i din reeaua 172.19.0.0/16
ctre orice destinaie, mai puin pentru staia 172.19.12.10:
R2(config)#access-list 10 deny host 172.19.12.10
Comenzile suplimentare vor fi adugate la ACL-ul precedent, cu numrul 10, n ordinea n care
au fost introduse.
Cuvntul host poate fi folosit pentru a desemna adresa unei singure staii, pentru care nu este
nevoie de un wildcard mask. Urmtoarele statement-uri sunt, deci, echivalente:
R2(config)#access-list 10 deny host 172.19.12.10
R2(config)#access-list 10 deny 172.19.12.10 0.0.0.0
De asemenea, cuvntul any poate fi folosit pentru a desemna orice surs (sau destina
ie,
pentru ACL-urile extinse). Urmtoarele statement-uri sunt echivalente:
R2(config)#access-list 10 permit any
Vizualizarea ACL-urilor configurate poate fi realizat prin comanda show access-lists.

Aceeai comand afieaz i numrul pachetelor ce au fcut match pe una dintre condiiile fiecrui
ACL, facilitnd astfel determinarea ACL-urilor greit configurate sau aplicate.
Aplicarea unui ACL standard pe o interfa
se execut prin comanda la nivel de interfa ip
access-group urmat de numrul ACL-ului de aplicat i direcia sa. Exemplu:
R2(config-if)#ip access-group 10 in
Din momentul aplicrii toate pachetele vor fi supuse testelor din ACL-ul respectiv.
ACL-urile standard pot fi aplicate i terminalelor virtuale ale ruterului (de obicei, acest lucru se
realizeaz doar n direcia in pentru a determina ce adrese se pot conecta la aceste terminale).
Pentru aplicarea unui ACL unuia sau mai multor terminale virtuale se folose
te comanda accessclass, ca n exemplul urmtor:
R2(config)#line vty 0 4
R2(config-line)#acces
R2(config-line)#access-class 10 in
Atenie, statement-urile dintr-un ACL standard nu pot fi intercalate, deci dac se dore
te
inserarea unui statement n mijlocul unui ACL sau editarea unuia, lista va trebuitears i refcut
n ordinea corect. E recomandabil ca ACL-urile s fie create separat, ntr-un editor de texte, pn la
definitivarea lor.
2.3.4 Configurarea listelor de acces extinse

n plus, pe lng verificarea adresei surs a pachetului, ACL-urile extinse introduc posibilitatea
de a verifica adresa destina
ie a pachetului, precum i protocolul i numerele de port surs i
destinaie de la nivelul transport.
Simplificat, sintaxa ACL-urilor extinse este:
access-list
[numar]
[informatii_destinatie]
deny/permit
[protocol]
[informatii_sursa]
unde:
[numar] reprezint numrul ACL-ului i trebuie s fie din intervalul ACL-urilor extinse;
[protocol] poate cuprinde, printre altele, ip, tcp, udp, icmp, protocoale de rutare i altele.
Prin IP se consider att TCP ct i UDP;
[informatii_sursa] i [informaii_destinaie] pot avea valorile any, host [adres], adres
i/sau operatori pentru porturi, servicii i flag-uri;
o operatorii pentru porturi sunt disponibili doar pentru protocoalele TCP sau UDP i
includ, printre altele, eq (equal), gt (greater than), lt (less than), neq (not equal),
range, etc, urmai de numele unui serviciu sau numrul unui port;
o flag-urile se refer la cmpuri ale antetelor de nivel 3 sau 4 i includ: rst, ack,
established, syn, tos, etc.
Un exemplu de ACL extins este urmtorul:
Router(config)#access-list 101 deny tcp host 192.168.2.1 any eq telnet
Router(config)#access-list 101 permit tcp 192.168.2.0 0.0.0.255 any eq www
Router(config)#access-list 101 deny icmp any host 10.0.0.1 echo
ACL-ul de mai sus conine trei statement-uri, dup cum urmeaz:

primul mpiedic accesul staiei 192.168.2.1 la portul 23 al oricrui server;
al doilea statement permite toate conexiunile TCP iniiate din reeaua 192.168.2.0/24 ctre
orice server web;
al treilea blocheaz pachetele de tip ICMP Echo de la orice sta ie ctre staia 10.0.0.1.
Aplicarea ACL-urilor extinse pe interfee sau terminale virtu ale se face la fel cai n cazul ACL urilor standard, prin comenzile ip access-group i access-class.
Comanda show access-lists afieaz intrrile din lista 101, mpreun cu numerele de
secven corespunztoare:
Extended IP access list 101
10 deny tcp host 192.168.2.1 any eq telnet
20 permit tcp 192.168.2.0 0.0.0.255 any eq www
30 deny icmp any host 10.0.0.1 echo
2.3.5 Configurarea listelor de acces cu nume

ACL-urile au o multitudine de ntrebuin
ri ce nu se reduc doar la filtrarea traficului pe
interfeele ruterelor. n momentul n care ACL-urile devin diverse i numeroase n configuraia unui
ruter, evidena bazat pe numerele devine dificil de urmrit, n special pentru administratorii ce nu
au creat configuraia respectiv.
Named ACL-urile nlocuiesc identificatorul numeric cu un nume dat de administrator, ce poate
conine n cteva cuvinte scopul ACL-ului respectiv. Mai mult dect att, ACL-urile cu nume suport
inserarea de statement-uri n orice poziie liber fr a mai fi necesar rescrierea ntregii liste. ACLurile cu nume pot fi att standard ct i extended.
Spre exemplu, urmtorul exemplu arat crearea unui named ACL standard:
R2(config)#ip access-list standard DENY_SERVERS
R2(config-std-nacl)#deny host 192.168.100.1
R2(config-std-nacl)#deny host 192.168.100.15
R2(config-std-nacl)#permit any
ACL-ul nou format afiat de comanda show access-lists apare n felul urmtor:
Standard IP access list DENY_SERVERS
10 deny
192.168.100.1
20 deny
192.168.100.15
30 permit any
n acest moment, dac se dore

te restricionarea traficului pentru o nou staie, ACL -ul ar
trebui rescris din moment ce adugarea unei noi reguli de deny s-ar face dup regula permit any, i
nu ar mai avea efect. Introducerea unui nou statement se realizeaz prin specificarea unui numr
liber de secven pe care acesta s fie introdus:
R2(config-std-nacl)#7 deny host 192.168.100.99
Afiarea ACL-ului demonstreaz poziionarea corect a noului statement:

7 deny
192.168.100.99
10 deny
192.168.100.1
20 deny
192.168.100.15
30 permit any
n mod complet similar se creeaz i ACL-urile extended cu nume. Spre exemplu:

R2(config)#ip access-list extended PERMIT_WELL_KNOWN
R2(config-ext-nacl)#permit tcp 192.168.100.0 0.0.0.255 any range 1 1024
R2(config-ext-nacl)#deny ip any any
Aplicarea named ACL-urilor pe interfe

e se face n aceeai manier ca i la ACL -urile
numerotate, cu diferena c n locul numrului se folosete numele.
2.3.6 Ordonarea i documentarea listelor de acces

n special n cazul named ACL-urilor, inserarea continu de statement-uri n poziiile libere din
numerele de secven poate duce la un moment dat la imposibilitatea adugrii de noi intrri.
Pentru aceste cazuri dar i pentru reorganizarea din punctul de vedere al lizibilitii ACL-urilor, Cisco
a introdus o facilitate de reordonare a numerelor de secven pentru ACL-uri.
Reordonarea funcioneaz pentru orice tip de ACL, standard, extended sau named.
Spre exemplu, pentru a reordona ACL-ul DENY_SERVERS creat anterior ncepnd de la numrul
de secven 20 cu increment de 5, se folosete comanda urmtoare:
R2(config)#ip access-list resequence DENY_SERVERS 20 5
R2(config)#do show access-lists DENY_SERVERS
20 deny
192.168.100.15
25 deny
192.168.100.1
30 deny
192.168.100.99
35 permit any
De asemenea, este deseori util documentarea func

iilor ACL -urilor n mai mult detaliu dect
numele folosit pentru ACL. Facilitatea remark permite introducerea de comentarii ntr-un ACL:
R2(config-std-nacl)#remark ?
LINE Comment up to 100 characters
<cr>
R2(config-std-nacl)#remark Blocheaza accesul serverelor S1, S15 si S99
n running-config, comentariul apare ca un statement al ACL-ului:
ip access-list standard DENY_SERVERS
deny
192.168.100.15
deny
192.168.100.1
deny
192.168.100.99
permit any
remark Blocheaza accesul serverelor S1, S15 si S99
2.4 Translatarea de adrese

2.4.1 Adrese publice i private
Toate adresele IP utilizate n Internet trebuie nregistrate la o autoritate regional. Pentru
Europa, aceasta este RIPE; pentru Statele Unite ale Americii, autoritatea este ARIN. Din cele trei
clase ale protocolului IP utilizabile pentru adresarea unicast (A, B i C) unele intervale de adrese sunt
rezervate pentru moduri speciale de adresare, cum ar fi ruta default 0.0.0.0/0 sau adresele
loopback din spaiul 127.0.0.0/8 (i altele) iar acestea nu pot fi cumprate sau re zervate de un
anumit client.
Pe lng adresele rezervate din considerente tehnice, RFC1918 stabilete alte trei intervale de
adrese, cte unul din fiecare clas, al adreselor private, ce nu trebuie rutate n Internet. Acestea
sunt:
Pentru clasa A: 10.0.0.0/8 cu intervalul 10.0.0.0 10.255.255.255
Pentru clasa B: 172.16.0.0/12 cu intervalul 172.16.0.0 172.31.255.255
Pentru clasa C: 192.168.0.0/16 cu intervalul 192.168.0.0 192.168.255.255
ntr-un mediu izolat, al unui laborator, aceste adrese pot fi folosite pentru orice scopuri
mpreun cu toate celelalte adrese utilizabile ale claselor A,B sau C. Pentru rutarea n Internet, ns,
RFC1918 specific faptul c aceste adrese nu sunt acceptate n antetele pachetelor. Cu alte cuvinte,
n Internet nu trebuie s fie permis adresarea pe baza adreselor private.
Din moment ce aceste adrese sunt rezervatei nu sunt permise n Internet, ele pot fi folosite
independent n orice reea local ; spaiile pot fi mprite n subreele dup necesiti iar utilizarea
lor nu necesit niciun fel de aprobare din partea unei autoriti. Orice numr de reele private din
lume poate folosi aceste adrese.
Observaie: trebuie avut n vedere faptul c aceste adrese nu prezint niciun fel de proprieti
speciale ce le mpiedic a fi utilizate n Internet. RFC1918 specific doar faptul c politica ISP-urilor
nu trebuie s permit rutarea lor.
Avantajul major al acestor adrese este gradul de flexibilitate pe care l permit. Fiecare companie
poate s i creeze propria sa schem de adresare n interiorul su, fr a fi nevoit s ob
in
aprobri i s cumpere efectiv aceste adrese de la o autoritate regional. De aseme nea, aceste
adrese permit creterea nengrdit a reelelor chiar i n contextul actual, n care adresele publice
disponibile IPv4 devin insuficiente.
2.4.2 Prezentarea conceptelor

Marele dezavantaj al acestor adrese st n nsi natura lor privat. Din moment ce ele nu pot fi
rutate n Internet, reelele cu adresare privat vor avea nevoie de un mecanism special pentru a le
putea oferi o modalitate de a comunica i n exterior. Acest mecanism trebuie sa traduc adresele
private n adrese publicei s foloseasc aceste adrese publice pentru ncapsularea pachetelor IP
provenite din reele locale, ce vor trebui rutate n Internet. De asemenea, se ridic i problema
traducerii inverse a pachetelor ce vin din Internet
i trebuie s ajung la anumite destinaii din
reelele locale.
NAT (Network Address Translation) reprezint un mecanism care adreseaz problemele de
mai sus. n lipsa NAT, staiile din reelele locale nu ar putea avea acces la Internet deoarece adresele
lor private nu sunt acceptate ca surs n mesajele trimisei nici ca destinaie n mesajele ateptate
ca rspuns 1.
NAT trebuie s ruleze pe ruterul (sau serverul) ce reprezint gateway-ul spre Internet al unei
reele locale. Ruterul care ruleaz NAT trebuie s fie configurat cu una sau mai multe adrese publice
pe interfaa conectat la Internet. n momentul n care o staie din reeaua local trimite un mesaj
spre Internet, ruterul i nlocuie
t e adresa surs privat din antetul IP cu o adres IP public, de
regul, cea configurat pe interfa
a sa i reine aceast asociere. Pentru staiile din Internet,
comunicaia va aprea ca i cum ar avea loc doar ntre ruterul gateway al reelei i destinaia din
Internet. Sarcina ruterului care ruleaz NAT este aceea de a ruta modifica antetul de nivel 3 att
pentru pachetele trimise din LAN cti pentru pachetele primite din Internet pe adresa sa public
(rescriindu-le cu adresele private iale
ini pentru
a putea fi rutate mai departe spre
ia sta
corespunztoare).
Fenomenul de rescriere a antetelor descris mai sus are loc ct timp staia respectiv efectueaz
trafic spre Internet prin conexiuni ini
iate local. Pachetele venit din Internet vor putea ajunge l a
staia corect doar dac fac parte dintr-o conexiune iniiat din LAN. n caz contrar, ruterul nu
cunoate asocierea ntre o adres privat i o adres public i nu va trimite pachetele spre nicio
staie, deoarece ele vor prea c i sunt adresate lui.
Dei imposibilitatea adresrii din Internet poate fi de multe ori un dezavantaj, n realitate ea
reprezint o msur destul de solid de securitate, comportamentul fiind asemntor unui firewall
simplu ce nu permite dect conexiunile iniiate de staia local.
Din pcate, mecanismul descris mai sus creeaz dificult
i n momentul n care un numr de
staii mai mare dect numrul de adrese publice disponibile ncearc s trimit pachete n Internet
la un moment dat, ceea ce e o situa
ie ntlnit aproape n
permanen. Deseori ruterul are o
singur adres public, iar problema se datoreaz faptului c ruterul va puteaine
re o singur
asociere la un moment dat pentru acea adres. Dac dou ii
stancearc s comunice n acelai
timp, ele vor suprascrie asocierea de adrese din ruter n permanen
, rezultnd n pierderi de
pachete suferite de ctre ambele staii. n mod intuitiv, rezolvarea acestui neajuns poate consta n
cumprarea attor adrese publice IP cte sunt necesare pentru ca toateiile
sta s comunice
n
acelai timp. Evident, aceast metod este extrem de costisitoare, uneori imposibil de aplicat, nu
ofer absolut niciun avantaj i, n plus, introduce un overhead prin utilizarea redundant a NAT-ului.
Metoda cea mai rspndit de implementare a NAT-ului se nume
te PAT (Port Address
Translation). n practic, metoda este att de rspndit nct referirea tehnologiei NAT, n ziua de
astzi, se refer aproape exclusiv la PAT.
PAT ofer posibilitatea multiplexrii conversaiilor sosite de la staii diferite din interiorul reelei
locale peste o singur adres public. Dup cum i spunei numele, PAT realizeaz multiplexarea la
nivel de porturi, deci la nivelul transport. Un ruter care ruleaz PAT va suprascrie att sursa adresei
de nivel 3 cti sursa ad resei de nivel 4 pentru pachetele care pleac dineaua
re local i va
suprascrie adresele destinaiile de nivel 3 i 4 pentru pachetele-rspuns venite din Internet. Aadar,
1
n plus, adresarea privat la nivelul Internetului ar fi imposibil i datorit faptului c aceleai adrese private
sunt refolosite n milioane de reele locale.
un ruter PAT va menine asocieri ntre perechi de tipul [IP surs privat, port surs] i [IP surs public,
port surs].
Un ruter ce ruleaz PAT va suprascrie adresa surs privat de nivel 3 cu cea public pentru
pachetele trimise n Internet i va ncerca s pstreze acelai port surs din pachetul iniial. Porturile
surs sunt, n marea majoritate a cazurilor, alese la ntmplare de ctre aplicaii, dar sunt extrem de
importante pentru c ele informeaz staiile-destinaie pe ce port s trimit rspunsurile. Ruterul va
ncerca s conserve acest port, daci portul corespunztor al inte rfeei sale publice este liber. n
eventualitatea n care dou staii ncearc s comunice cu acelai port surs, ruterul va nlocui unul
dintre ele cu primul gsit liber i va respecta noua asociere format.
Ruterul va menine deschise porturile asociate staiilor pentru a putea primi traficul de rspuns
destinat reelei locale. Datorit asocierilor reinute n memorie, un ruter va ti s direcioneze
traficul primit ctre staiile corecte deoarece o pereche [adres IP, numr port] va identifica n mod
unic o anumit conexiune de pe o anumit staie din reeaua local.
2.4.2.1 Terminologia adreselor n NAT

Datorita modificrii adreselor IP n pachetele supuse procesului de NAT, diferite adrese sunt
denumite n funcie de originea lor i de punctul de referin:
Inside local: adrese private, n interiorul reelei locale;
Inside global: adresa IP public ce este ataat traficului unei staii din reeaua local cnd
iese n Internet prin ruterul NAT. Poate fi chiar adresa public de pe interfaa ruterului.
Outside global: adresa IP public asignat unei staii din Internet. Aceast adres nu se
modific n procesul de NAT deoarece trebuie conservat pn cnd pachetele ajung la
destinaie.
Outside local: de cele mai multe ori egal cu outside global, este adresa local a unei staii
din Internet. Nu are relevan n cazul n care NAT se aplic doar adreselor surs.
2.4.3 Configurarea NAT

2.4.3.1 NAT static
Realizarea de NAT static presupune o mapare 1 la 1 ntre o adres privat
i una public.
Sintaxa comenzii este urmtoarea:
R2(config)#ip nat inside source static 192.168.1.1 89.221.57.81
192.168.1.1/24
89.221.57.81/30
192.168.1.2/24
Surs: 192.168.1.1:27081
Destinaie: 89.221.57.83:80
NAT
Figura 2-4: NAT static
Surs:
89.221.57.81:27081
D i i
89.221.57.82/30
Web
Server
Comanda introduce o mapare permanent ntre adresa local 192.168.1.1

i adresa public
89.221.57.81. Pentru a defini
i direcia n care se realizeaz translatarea adreselor, trebuie
specificate interfeele inside (spre reeaua local) si cele de outside (spre Internet):
R2(config)#int fast1/0
R2(config-if)#ip nat inside
R2(config-if)#int fast0/0
R2(config-if)#ip nat outside
Comanda de verificare show ip nat translations arat asocierea static definit:

R2#sh ip nat trans
Pro Inside global
global
--- 89.221.57.81
Inside local
192.168.1.1
Outside local
---
Outside
---
2.4.3.2 NAT dinamic

Realizarea de NAT dinamic ofer un surplus de flexibilitate, n sensul c permite definirea
adreselor mai multor staii din reeaua local, ce vor fi translatate, precum i definirea unei mulimi
de adrese publice n care acestea vor putea fi translatate.
Drept exemplu de configurare, se va considera c toate adresele
eauadinlocal
re
192.168.100.0/24 vor putea fi translatate la adresele publice din intervalul 200.100.99.226
200.100.99.240.
Pentru definirea listei de adrese private ce vor fi supuse procesului de NAT, se creeaz un ACL
ce trebuie s permit doar adresele dorite:
Mulimea adreselor publice se definete prin crearea unui pool de adrese ce cuprinde prima i
ultima adres:
R2(config)#ip nat pool MYPOOL 200.100.99.226 200.100.99.240 netmask
255.255.255.224
n final, se configureaz procesul NAT s opereze cu ACL-ul si pool-ul definite anteriori se

marcheaz interfeele de inside i de outside:
R2(config)#ip nat inside source list 1 pool MYPOOL
R2(config)#int fast1/0
R2(config-if)#ip nat inside
R2(config-if)#int fast0/0
R2(config-if)#ip nat outside
2.4.4 Configurare PAT

Configurarea PAT este similar configurrii de NAT dinamic i poate fi realizat n dou moduri:
folosind doar adresa public de pe interfaa conectat la Internet;
folosind un pool de adrese publice.
Pentru ambele cazuri, comanda primete argumentul suplimentar overload.
Exemplu folosind adresa IP public de pe interfa:
R2(config)#ip nat inside source list 1 interface FastEthernet 0/0 overload
Exemplu folosind un pool predefinit de adrese publice:

R2(config)#ip nat inside source list 1 pool MYPOOL overload
n cazul n care se opteaz pentru folosirea unui pool de adrese publice, adresele suplimentare
vor fi utilizate doar pentru cazurile n care apar conflicte cu privire la numerele de port n momentul
stabilirii de noi conexiuni.
2.4.5 Port forwarding

ie dintr -o
Tehnica de port forwarding permite accesarea din exterior a unui port de pe o sta
reea privat aflat n spatele unui ruter care ruleaz NAT.
Pentru a putea realiza acest lucru, ruterul NAT trebuie configurat astfel nct s direc
ioneze
toate conexiunile iniiate pe un anumit port al su de pe interfaa spre Internet spre un alt port al
unei staii din reeaua intern.
Spre exemplu, o staie cu adresa 192.168.12.13 care ruleaz un server web ntr -o reea local
va putea fi accesat de ctre ceilal
i membri ai reelei dup adresa sa privat i va rspunde la
conexiunile iniiate pe portul TCP 80. Deoarece staia se afl n reeaua privat 192.168.0.0/16, ea
nu va putea fi accesat din exterior. n consecin
, ruterul NAT poate fi configurat astfel nct s
redirecteze toate conexiunile externe iniiate pe portul su 80 al interfeei publice spre portul 80 al
staiei 192.168.12.13, fcnd astfel portul din interiorul reelei accesibil din Internet.
Nu exist restricii cu privire la alegerea porturilor ce vor fi forward-ate.
Exemplul de mai jos reprezint modul de configurare al scenariului anterior. Pentru acest
exemplu, portul TCP 8080 de pe ruter va fi forward-at i va trimite conexiunile spre portul 80 al
staiei 192.168.12.13 din LAN:
R2(config)# ip nat inside source static tcp 192.168.12.13 80 interface
FastEthernet0/0 8080
Observaie: n general, la configurarea NAT, atunci cnd exist opiunea de a specifica o adres
public sau interfaa configurat cu acea adres, se prefer utilizarea variantei bazate pe numele
interfeei pentru a nu crea dificulti n cazul n care adresa IP public oferit de ctre ISP se
schimb periodic. Specificnd o interfa i nu o anumit adres IP, ruterul va folosi de fiecare dat
adresa IP existent la momentul respectiv, indiferent de valoarea ei.
3 IP v6
Versiunea a 6-a a protocolului IP a fost introdus de IETF n anul 1992 ca o propunere de

rezolvare a problemei spaiului limitat de adrese al IPv4. n ultimii 17 ani acest protocol a cunoscut o
evoluie continu, pe baza experienei dobndite n perioada de dezvoltare a versiunii a 4-a a
protocolului.
ncepnd cu IPv6 au fost efectuate o serie de modificri n modul de utilizare a unui protocol de
nivel 3. n re
ele moderne adresarea IP nu se dorete a fi folosit doar pentru laptop -uri i
computere, ci se intenioneaz integrarea unor dispozitive precum: telefoane mobile, televizoare,
radio-uri, etc., extinznd conectivitatea la Internet pentru o multitudine de alte dispozitive. O
cantitate aproape inepuizabil de adrese IP este asigurat de IPv6 prin folosirea unei adresri pe
128 de bii.
Dei extinderea substanial a spaiului de adresare este cel mai cunoscut aspect al
protocolului, IPv6 introduce multe alte mbuntiri fa de predecesorul su. n dezvoltarea sa s-au
urmrit identificarea problemelor de func
ionare, scalabilitate i securitate a versiunii a 4-a i
repararea lor folosind soluii simple i eficiente. Printre noile faciliti introduse, merit menionate:
un antet mult mai simplu aliniat la 64 deibipentru optimizarea citirii pe noile procesoare x64,
configurarea automat a adreselor pe interfa (autoconfig), agregarea, securitatea ncorporati
capabilitile de multihoming.
Evoluia pn n prezent a Internetului i a adresrii bazate pe IPv4 demonstreaz faptul c o
migrare complet a Internetului la IPv6 pe termen lung este inevitabil. Migrarea spre un nou
protocol este extrem de dificil i, mai ales, de durat. De aceea IPv6 propune multiple variante de
coexisten cu IPv4. Acestea includ diferite tehnici de tunelare, o form special de NAT ce poate
translata adrese v4 n adrese v6 i inclusiv rutere ce ruleaz ambele versiuni ale protocolului i pot
comunica prin ambele protocoale.
Trebuie specificat totui faptul ca tehnologiile IPv4, CIDR i NAT, au reuit s rezolve o serie
dintre problemele insuficienei adreselor IPv4, astfel c migrarea la IPv6 va continua ca un proces
lent. Schimbarea unui protocol de o asemenea rspndire este un lucru extrem de greu de fcut,
preferndu-se ntotdeauna varianta care funcioneaz n prezent i care a reuit s supravieuiasc
multor ncercri de-a lungul timpului.
Capitolul ce urmeaz i propune realizarea unei introduceri n lumea protocolului IPv6 cu
descrierea caracteristicilor principale, a protocoalelor de rutare cu suport IPv6, iar n ncheiere,
tehnici de interconectare a reelelor IPv4 cu reele IPv6.
3.1 Protocolul IPv6

3.1.1 Antetul IPv6
Pentru a putea nelege motivaia pentru modificrile aduse antetului IPv6, se vor analiza mai
nti facilitile oferite de IPv4.
Ver.
HLEN
ToS
Total Length
Identification
Flag
Fragment Offset
s
Time to Live
Protocol
Header Checksum
Source IP Address
Destination IO Address
IP Options (if any)
Padding
Data
...
Figura 3-1: Antetul IPv4
n momentul standardizrii protocolului IPv4 reelele erau fundamental diferite fa de cele din
ziua de astzi. n primul rnd, mediile de transmisie nu aveau aceeai calitate 1 iar din aceast cauz
interferenele din partea mediului erau mult mai mari dect n prezent. O dovad a acestor
probleme din trecut este cmpul Header Checksum, folosit pentru verificarea apariiei unei erori n
antetul IP. n prezent, probabilitatea apariiei unei erori de transmisie exact n cei 20 de bytes ai
antetului IP este aproape inexistent ns n continuare fiecare dispozitiv de reea consum timp de
procesor calculnd checksum-ul antetului i verificndu-l cu cel din pachet. Acesta este un exemplu
de cmp al antetului IPv4 ce a devenit complet redundant n prezen, ns exist i alte cmpuri ce sau dovedit a fi ineficiente n comportamentul fluxurilor de date actuale. n aceast categorie se
nscriu i cmpurile folosite pentru fragmentare.
Cnd un pachet urmeaz s fie transmis pe o legtur cu un MTU 2 mai mic dect dimensiunea
sa, acesta va trebui fragmentat n mai multe pachete. In mod evident, la destinaie pachetul iniial
va trebui reasamblat. Pentru ca acest lucru s fie posibil, antetul ine
IPv4 un
re
flag (More
Fragments) de fragmentare i punctele de fragmentare ale datelor folosind cmpurile: Flags i
Fragment Offset. Situaiile n care este nevoie de fragmentare n reelele actuale sunt foarte puine
ns pentru orice transmisie IPv4, cmpul Fragment Offset alturi de bitul de fragmentare sunt
incluse n mod inutil n pachet.
Antetului IPv4 are 12 cmpuri distincte, avnd n total o dimensiune de 20 bytes ce poate fi
extins prin cmpul Options cu dimensiune variabil.
n contrast, antetul IPv6 pstreaz doar 5 cmpuri din cele 12 ale predecesorului su. Acestea
sunt aliniate la 64 de bii n vederea optimizrii procesrii pentru procesoarele pe 64 de bii. Antetul
1
2
http://en.wikipedia.org/wiki/Category_5_cable
MTU = Maximum Transmission Unit
45 | I P v 6
IPv6 are o structur modular, separnd mai clar cmpurile obligatorii de cele opionale sau rar
utilizate. Antetul de baz IPv6 are structura de mai jos:
Version
Traffic class
Flow label
Payload length
Next header
Hop limit
Source address
Destination address
Figura 3-2: Antetul de baz IPv6
Lungimea antetului de baz IPv6 este de 40 bytes din cauza adreselor sursi destinaie ce
ocup 18 bytes fiecare. Cmpurile din figura de mai sus au urmtoarele roluri:
Version: versiunea protocolului IP; n cazul IPv6 cmpul are mereu valoarea 6.
Traffic class: 8 bii folosii pentru definirea ToS (Type of Service) n implementarea QoS
(Quality of Service). Funcia acestor bii este comun cu cea din IPv4.
Flow label: este folosit de ctre sursa unei transmisii pentru a marca identitatea unui flux
de date. Alturi de adresa surs i adresa destinaie, label-ul poate fi folosit n tehnici de
QoS sau Multilayer Switching pentru a obine un timp mai bun de switching al pachetelor.
Payload length: echivalentul lui Total Length din IPv4. Este folosit pentru specificarea
dimensiunii pachetului.
Next header: echivalentul cmpului Protocol din IPv4. Este folosit pentru specificarea
protocolului de nivel superior, ncapsulat n pachet.
Hop limit: echivalentul cmpului TTL din IPv4. Este folosit pentru specificarea numrului
maxim de hopuri peste care un pachet poate fi rutat. Cmpul este decrementat de ctre
fiecare ruter de pe parcurs, la primirea pachetului.
Source address: adresa IPv6 surs exprimat pe 128 de bii
Destination address: adresa IPv6 destinaie exprimat pe 128 de bii
Pe lng antetul de baz, IPv6 poate fi extins cu antete opionale utile n diferite scenarii.
Printre exemple se numr antetul de fragmentare sau antetul de AH/ESP ce ofer suport integrat
IPSec n IPv6.
n general, fragmentarea produs de IPv4 afecteaz performana reelei
i de aceea IPv6
introduce o nou tehnic numit Path MTU Discovery (PMD). Folosind aceast tehnologie, IPv6
poate deduce care este cea mai mic valoarea MTU de la un punctea
de nre altul peste o
infrastructur de nivel 3. Valoarea determinat va fi folosit pentru toate transmisiile realizate pe
acea rut evitndu-se astfel fragmentarea pachetului. PMD nu este nc o tehnologie matur, de
aceea IPv6 folosete n continuare antetul de extensie pentru fragmentare; dac PMD nu
funcioneaz sau nu poate fi folosit din cauza constrngerilor asupra resurselor de calcul, se
ataeaz acest antet care reine numerotarea i offset-ul fragmentelor unui pachet.
IPv6 are, de asemenea, suport nativ pentru IPSec prin protocoalele AH (Authentication Header)
i ESP (Encapsulated Security Payload). AH este folosit numai pentru autentificare iar ESP este
folosit n scenariile n care este nevoie de confidenialitatea a datelor. Multe tehnici de autentificare
sau securizare folosite anterior n protocoale (ex: autentificarea n protocoale de rutare) s-au mutat
acum n IPv6 si pot fi fcute direct peste protocolul de nivel 3.
3.1.2 Reprezentarea adreselor IPv6

Pe orice mediu de transmisie, fie c se folosesc pentru codificare nivele de tensiune (pe cupru),
fie c se folosesc semnale de lumin (pe fibr optic), pachetele sunt transmise n unit
i de bii.
Echipamentele de reea interpreteaz fluxurile de date la nivel de bii. Odat ce datele au fost
procesate ele sunt reinute n memorie ntr-un numr de bytes, cea mai mic unitate adresabil de
memorie. Pentru un dispozitiv hardware, limbajul binar este nativ. Situaia este diferit n limbajul
uman unde exprimarea unei adrese IPv4 n 32 de ibi n notaie binar ar fi aproape imposibil de
reinut i dificil de comunicat. Astfel n IPv4 s-a preferat notaia zecimal care exprima o adres IP n
doar 4 numere zecimale, cu valori ntre 0 i 255.
Dei sistemul zecimal de exprimare a numerelor era potrivit pentru 32 de bii, la trecerea la
IPv6 i adrese de 128 de bii acesta nu a mai fost scalabil.
IETF a hotrt ca modul de reprezentare a adreselor IPv6 s fie fcut n hexazecimal.
Reprezentarea hexazecimal are avantajul unei lungimi relativ reduse a adresei IPv6. Un exemplu de
astfel de adres ar fi FE80:0000:00DD:0000:0000:ED01:00F1:1134.
Se poate observa ci n form hexa o adres IPv6 este greu de citit i d e reinut. Din acest
motiv IETF a adoptat anumite convenii menite s fac o adres IPv6 mai uor de citit i exprimat n
limbaj uman:
Literele A-F folosite n sistemul hexazecimal vor fi case-insensitive la folosirea ntr-o adres
IPv6
Mai multe cifre 0 consecutive folosite la nceputul unui grup 1 din adresa IPv6 pot fi omise.
Dac grupul este format numai din cifre 0, acestea pot fi abreviate ntr-o singur cifr 0.
Folosirea repetat i continu a cifrei 0 n mai multe grupuri din adresa IPv6 poate fi
abreviat folosind simbolul ::. Aceast prescurtare poate fi folosit ns o singur dat n
exprimarea unei adrese IPv6.
Se va lua ca exemplu adresa de mai sus: FE80:0000:00DD:0000:0000:ED01:00F1:1134.
Aceasta poate fi reprezentat n mai multe forme valide folosind conveniile de mai sus:
FE80:0:DD:0:0:ED01:F1:1134
FE8::DD:0:0:ED01:F1:1134
FE80:0:DD::ED01:F1:1134
Se poate observ c a treia scriere este cea mai scurt, deci cea mai eficient. Trebuie avut n
vedere faptul c notaia :: poate fi utilizat o singur dat n scrierea unei adrese IPv6. n mod
contrar, nu ar mai putea fi determinat forma iniial a adresei 2.
3.1.3 Structura adreselor IPv6

Trei tipuri diferite de adrese IPv6 au fost definite n cadrul RFC-ului 3513: unicast, multicast i
anycast. Prima observaie este faptul c n IPv6 nu exist tipul de transmisie broadcast. Evoluia
protocoalelor multicast de-a lungul anilor a deschis posibilitatea nlocuirii broadcast-ului cu deja
existentul multicast IPv6.
3.1.3.1 Adresarea anycast

Un nou tip de adres n IPv6 este anycast. Aceasta permite configurarea aceleiai adrese pe mai
multe noduri de reea. Presupunnd c pe aceste noduri de reea ruleaz un serviciu ce folosete o
baz de date comun distribuit, un ruter din Internet poate alege n decizia de rutare calea cea mai
scurt ctre nodul cel mai apropiat ce ofer respectivul serviciu. Astfel se poate realiza un serviciu
1
Prin definirea unui grup din adresa IPv6 se nelege o grupare de cifre hexa cuprinse ntre delimitatorii :,
echivalentul a 2 bytes
2
Sistemele de operare ce interpreteaz adrese IPv6 introduc bii de zero n locul structurii :: pn la
atingerea totalului de 128 de bii. Cu dou astfel de structuri ar fi imposibil de determinat numrul de zerouri
ce trebuie introduse n locul fiecreia.
47 | I P v 6
distribuit n mai multe puncte din Internet iar direcionarea eficient ctre serviciu se va putea face
de la nivel 3. O aplicaie interesant pentru adresarea anycast este n tunelare. Un ruter poate alege
n funcie de o adres anycast cea mai rapid ieire din tunel.
3.1.3.2 Adresarea unicast

Adresarea unicast este elementul fundamental al oricrui tip de transmisie n Internet. O
adres IPv6 are o dimensiune de 128 de bii iar o structur de adresare plat pentru IPv6 ar nsemna
ca fiecare ruter din Internet sin
re toate adresele destinaie din lume, o metod complet
nescalabil. n mod evident, ca i n cazul IPv4, exist nevoia unei structuri de adresare ierarhic n
IPv6 folosind conceptul de masc de reea. Din cauza dimensiunii mari ai unei adrese IPv6 singura
notaie acceptat pentru masca de reea este folosind simbolul / urmat de un numr de la 0 la
128 ce semnific numrul de bii setai la valoarea 1 de la nceputul mtii, ca i n cazul IPv4.
Exemplu: 2001:410:0:1::/64.
Adresele unicast pot fi de trei tipuri, n funcie de domeniul lor de vizibilitate(scope) n reea:
global unicast IP-urile din aceast categorie poart numele de global unicast addresses
(GUAs)
link-local IP-urile din aceast categorie poart numele de link-local addresses
unique-local IP-urile din aceast categorie poart numele de unicast local addresses
(ULAs)
Global unicast sunt echivalentul IP-urilor publice n IPv4, fiind rutabile n tot Internetul.
Conform RFC-ului 3587, acestor adrese le este rezervat spa
iul 200::/3 din totalul de adrese IPv6.
Avnd la dispoziie un numr att de mare de adrese, unul dintre principalele scopuri ale modului
de adresare global a fost realizarea unei scheme de agregare. Cei 128 de bii ai adresei IPv6 au fost
mprii
dup
cum
se
observ
n
figura
de
mai
jos:
64 b
Global routing prefix
001
ISP
Host = 64 b
Subnet
Subnet ID
Interface ID
Global ID
Figura 3-3: Structura adresei IPv6
Primii 3 bii vor avea ntotdeauna valoarea 001 pentru a indica o adres rutabil conform
standardului din RFC. Urmtorii n bii unde n<45 vor fi identificatorul ISP-ului ce ofer respectivul IP.
n funcie de modul n care IANA deleg adresele ISP-urilor, din primii 48 de bii se poate deduce
continentul, ara i mai apoi ISP -ul. Urmtorii bi
i, pn la 64 (minim 16), vor fi oferii unei
organizaii pentru crearea de subreele. Cu alte cuvinte, poriunea denumit Subnet ID va
reprezenta echivalentul prii de subreea din IPv4.
Ultimii 64 de bii, numii Interface ID n IPv6, vor reprezenta partea de host ce va identifica n
mod unic o interfa din punct de vedere global. Acetia pot fi, la rndul lor, mprii n subreele,
dup necesitile fiecrei organizaii.
n standardul IPv6 nu exist o limitare a numrului de adrese ce se pot configura pe o interfa.
Fa de IPv4, un ruter poate avea n acelai timp multiple adrese IP pe aceeai interfa incluznd o
adrese globale, anycast i link-local.
Adresele link-local au un rol foarte important n noua versiune a protocolului IP. Cnd un
dispozitiv IPv6 pornete, el primete automat prin intermediul stivei TCP/IP(v6) o adres pe care o
poate folosi pentru comunicarea pe acela
i link cu orice vecin al su. Astfel 2 dispozitive IPv6 nu
necesit intervenia administratorului pentru a putea comunica ntre ele pe acelai link. Network
Discovery Protocol este un bun exemplu n acest sens. NDP este un protocol ce rezid n Control
Plane 1 n IPv6. El este folosit pentru multe dintre func
ionalitile IPv6 pe un segment de reea:
autoconfig, multicast address resolution (echivalentul lui ARP n IPv4) etc. Toate mesajele pe care
NDP le folosete pentru a uura configurarea iniial a reelei folosesc adrese IPv6 link-local.
Adresele link-local sunt recunoscute uor deoarece folosesc prefixul FE80::/10. Urmtorii 54 de
bii pn la Interface ID sunt ntotdeauna 0 iar Interface ID-ul este generat din adresa MAC folosind
metoda EUI-64. Aceast metod va fi descris n urmtorul subcapitol: Network Discovery Protocol.
Un exemplu de adres link local este: FE80::204:6DFF:FE7F:7C1A/10.
Adresele ULA reprezint echivalentul adreselor IPv4 private n IPv6.iDe
la prima vedere
standardul IPv6 nu ar prea s aib nevoie de acestea din cauza spaiului imens pe care IPv6 l pune
la dispoziie, adresele private au alte avantaje politice. nc din IPv4 ele au oferit unei companii un
mod de delimitare a reelei, de creare a unei zone de confort.
3.1.3.3 Adresarea multicast

Tipul de transmisie multicast joac un rol extrem de important n IPv6, fiind folosit pentru toate
tipurile de transmisii ce utilizau nainte broadcast. O adres multicast poate fi recunoscut uor prin
prefixul FF00::/8. Cel mai bun exemplu pentru nlocuirea broadcast cu multicast este procesul de
address resolution realizat n IPv4 prin ARP. Mai multe detalii privind despre func
ionarea acestuia
vor fi oferite n capitolul ce urmeaz.
3.1.4 Network Discovery Protocol

NDP a fost pentru prima dat publicat acum 10 ani pentru a introduce n IPv6 capacitatea de
autoconfigurare. Cu alte cuvinte, s-a dorit ca la instalarea unei staii noi ntr-o reea IPv6, aceasta s
se poat configura singur, fr interven
ii ale administratorului i s poat avea acces dir ect la
reea. IPv4 poate realiza aceleai funcii, ns prin utilizarea unui protocol extern: DHCP. n
comparaie IPv6 ofer funcionalitate out-of-the-box fr a avea nevoie de protocoale externe. Este
adevrat ns c IPv6 autoconfig nu ofer toate avantajele DHCP 2, ns ofer conectivitatea de baz
necesar.
Deoarece n IPv6 nu se mai pot folosi transmisii broadcast, protocolul ARP ce ndeplinea rolul
de realizare a perechilor IP-MAC pentru fiecare sta
ie ( e.g address resolution) nu se mai poate
folosit. Ca i nlocuitor, IPv6 definete NDP care, prin intermediul unor mesaje de tip Neighbor
Discovery si Neighbor Solicitation, realizeaz cu succes address resolution folosind adrese multicast
link-local.
Control Plane acea component a IPv6 care se ocup cu managementul pachetelor definite de protocol
pentru negocierea anumitor parametri. Data Plane se ocup cu rutarea i comutarea traficului IPv6.
2
Exist o varianta DHCP i pentru IPv6 numit DHCPv6 care preia toate funcionalitile DHCP i le aduce n
lumea IPv6
49 | I P v 6
3.1.4.1 Autoconfig
O interfa poate fi configurat pentru acces la reeaua local i global, n IPv6, n mai multe
moduri:
Automat stateless: prin intermediul IPv6 autoconfig
Manual: prin intermediul interveniei administratorului. n acest tip de configurare
administratorul poate aleag s configureze ntreaga adres IPv6 (reea+subreea+interface
ID) sau doar partea de reea i subreea, lsnd ultimii 64 de bii s fie generai prin metoda
EUI-64.
Automat stateful: configurarea prin intermediul DHCPv6
Pentru IPv6, IETF mai propune o tehnologie stateless de configurare a informaiilor pe interfa,
numit DHCP-lite. Acesta este un server DHCP ce poate oferi doar informaii de tipul: adres server
DNS, nume domeniu, adres server SIP etc. Metoda aceasta nu poate oferi interfeei o adres IP sau
o masc de reea1.
Configurarea automat stateless este cea care va face subiectul paragrafelor ce urmeaz.
Folosind mesaje de tip Router Advertisement si Router Solicitation o staie poate comunica cu
ruterul gateway pentru a obine de la acesta adresa i masca de reea folosite pe respectivul
segment. De asemenea poate instala ruterul respectiv ca adres de gateway. Explicaia de nivel
nalt a acestui proces este destul de simpl ns n spate se realizeaz schimbul de mesaje complexe
bazate pe adrese link-local funcionale i verificate pe baza DAD (Duplicate Address Detection).
n acest punct al configurrii automate stateless staia a obinut de la ruter o adres de reea.
Rmne de configurat doar Interface ID-ul pentru a putea realiza o comunicaie din punct de vedere
al nivelului 3.
Generarea Interface ID-ului este fcut de ctre staie pe baza adresei MAC, folosind o metod
standard numit EUI-64. O adres MAC are 48 de bi
i. Un Interface ID are 64 de bii. Trebuie deci
adugai cumva 16 bii n adresa MAC pentru a obine un Interface ID valid. Metoda EUI-64 specific
realizarea acestei operaii prin introducerea secvenei FFFE la mijlocul adresei MAC.
O adres MAC 0090AACE0198 va deveni astfel 0090AAFFFECE0198. Administratorul de reea
poate alege implementarea configurrii semi-automate prin care el doar specific primii 64 de bii ai
adresei IPv6, urmnd ca poriunea de host s fie completat prin EUI-64.
3.1.4.2 Address resolution

IPv6 nglobeaz protocolul ARP n propria implementare. Prin intermediul NDP i a mesajelor de
Neighbor Discovery i Neighbor Solicitation IPv6 realizeaz o tabel de asociere ntre adrese MACi
adrese IP.
n locul adresei de broadcast FF:FF:FF:FF:FF:FF, IPv6 folosete o adres de multicast special
numit solicited-node multicast. Acest tip de adresare este derivat din adresa de nivel 3 a destinaiei
i presupune ca orice destinaie ce folosete IPv6 s asculte la nivel 2 pentru adresa sa solicitednode multicast.
Prefixul unei adrese solicited-node multicast este ntotdeauna FF02::1:FF00:0000/104 iar ultimii
24 de bii sunt luai din ultimii bii ai adresei IPv6 configurate pe respectiva interfa.
Pentru adresa IPv6 2001:100:ABC:1:0:0:AABB:CCDD/64 adresa solicited-node multicast va fi
FF02::1:FFBB:CCDD.
Pentru mai multe informaii despre DHCP-lite se recomand consultarea RFC-ului 3736
3.2 Implementarea IPv6

Unul din avantajele IPv6 este chiar timpul su lung de dezvoltare. Pentru c protocolul IPv4 nc
reuete s ofere suport Internetului, Ipv6 are ndeajuns de mult timp pentru a se forma i a fi testat
n toate aspectele sale: securitate, mobilitate, tunelare, rutare etc.
n privina capitolului de rutare, n prezent, toate protocoalele de rutare includ suport pentru
IPv6.
3.2.1 Rutarea IPv6

Datorit simplitii sale, RIP a fost primul protocol care a obinut suport pentru rutare IPv6.
Noul protocol de rutare a fost numit RIPng (next generation).
RIPng a motenit simplitatea predecesorului su. Din acest motiv arhitecii RIPng nu au dorit s
adauge funcionaliti, astfel c RIPng nu aduce mbuntiri spectaculoase fa de varianta sa IPv4.
Principalele avantaje pe care RIPng le aduce sunt:
Doi vecini RIPng nu trebuie s fie n acelai subnet pentru a putea comunica rute. Dei
condiia ca doua rutere vecine s fie n acelai subnet este valabil n RIPng dup cum era i
n RIP, aceast condiie e deja ndeplinit prin utilizarea adreselor link-local;
Pentru c IPv6 nu folosete broadcast-uri, RIPng ruleaz direct peste multicast, adresa
FF02::9;
n IPv4 securizarea update-urilor RIP se face folosind mecanisme de autentificare ale RIP. n
IPv6 exist deja suport inerent pentru IPSec, deci autentificarea vine din protocolul de nivel
3;
n cadrul RIP nu se puteau rula instane diferite ale protocolului pe acelai link. Cisco IOS
ofer posibilitatea rulrii de 4 instane RIP pe acelai link.
Un exemplu de configurare pentru multiple instane RIPng va fi prezent n capitolul 4.3.
3.2.2 Interconectarea reelelor IPv4 cu reele IPv6

Trecerea de la IPv4 la IPv6 este un proces de durat. Din pcate nu este posibil ca toate
companiile i ISP-urile s migreze simultan toate reelele pe IPv6. Trebuie s existe metode prin care
o organizaie s i poat trece treptat reeaua pe IPv6 deoarece, pn la o migrare complet, se va
trece printr-o perioad n care cele dou tipuri de reele vor trebui s coexiste.
De la primele implementri IPv6 s-a inut cont de aceast problem la care s-au gsit multiple
soluii:
rutere dual-stack acestea pot rula n acelai timp i IPv4 i IPv6;
tehnici de tunelare dac ntre dou reele IPv6 exist rutere care ruleaz numai IPv4 va
trebui fcut un tunel cu antet IPv4 n care s fie ascuns pachetul IPv6;
NAT-PT (NAT Protocol Translation) implementeaz o metod de comunicare ntre o
staie ce ruleaz numai IPv6 i o staie ce ruleaz numai IPv4.
3.2.2.1 Tunelarea IPv6 peste o reea IPv4

Soluie care este de departe cea mai folosit n reelele actuale i asupra creia se va concentra
capitolul de fa este tunelarea. Aceast tehnic presupune ncapsularea pachetelor IPv6 cu antete
IPv4. Adresele din antetul Ipv4 sunt de fapt adresele sursi destinaie ale ruterelor d e border care
sunt capetele tunelului. Se va studia un exemplu de tunelare generic pe topologia de mai jos:
51 | I P v 6
Reea
IPv6
Reea
IPv6
Reea IPv4
A
Antet
IPv6
Date
Antet
IPv4
Antet
IPv6
Date
Antet
IPv6
Date
Figura 3-4: Tunelare IPv6 peste o reea IPv4

Cnd pachetul cu antet IPv6 ajunge la ruterul A, acesta verific destina
ia folosind tabela de
rutare. Dac destinaia este cunoscut prin tunel atunci ruterul ncapsuleaz pachetul cu un antet
IPv4 astfel:
Surs: adresa sa IPv4 dinspre reeaua IPv4
Destinaie: adresa IPv4 a ruterului B dinspre reeaua IPv4
Dup ncapsulare pachetul este rutat n Internetul IPv4 pn cnd acesta ajunge la ruterul B.
Pentru c pachetul a venit prin tunel, ruterul B va elimina antetul IPv4
i l va ruta n funcie de
tabela de rutare IPv6.
n mare, exist dou criterii dup care se clasific tunelele n IPv6:
Dac tunelul este manual sau automat
Dac tunelul este point-to-point sau point-to-multipoint
Dei exist multe tipuri de tunele ce pot fi configurate pentru diferite nevoi de interconectare
IPv6 IPv4, toate sunt construite urmrind civa pai de baz:
1. Asigurarea conectivitii IPv4 ntre capetele tunelului dac nu exist conectivitate ntre
adresele cu care pachetul IPv6 este ncapsulat, tunelul va fi terminat;
2. Se creeaz o interfa de tip Tunnel n Cisco IOS introducerea traficului n tunel se face
prin crearea unei interfe
e virtuale numite Tunnel (indexat de la 0). Pentru a trimite
traficul prin tunel i a realiza ncapsularea, n tabela de rutare IPv6 trebuie s existe o rut
care, pentru o anumit destinaie, are interfaa tunelului ca interfa de ieire;
3. Se configureaz sursa tunelului adresa IP surs care va fi folosit pentru ncapsularea
IPv4. Aceast adres trebuie setat n cellalt capt al tunelului ca
i adres IP destina ie
pentru tunel;
4. Se configureaz o destinaie a tunelului (opional n cazul tunelelor automate) adresa IP
destinaie a tunelului; reprezint adresa IP surs a captului cellalt de tunel;
5. Configurarea unei adrese IPv6 pentru interfa
a de tip Tunel
interfaa de tip tunel
funcioneaz ca o prelungire a reelei IPv6 i de aceea trebuie s aib o adres IPv6 dintr-un
subnet separat;
6. Configurarea modului de tunelare n acest ultim pas se configureaz tipul de tunel: MCT,
GRE, 6to4, ISATAP etc.
Tunelele point-to-point precum MCT (Manually Configured Tunnel) sau GRE (Generic Router
Encapsulation) trebuie configurate pentru fiecare pereche de surs destinaie. Cu alte cuvinte
pentru fiecare tunel trebuie creat o nou interfaa de tunel n ambele capete. n anumite situaii
astfel de tunele nu scaleaz, fiind nevoie de mult efort administrativ pentru configurarea lor.
Soluia n aceste cazuri este utilizarea tunelelor automate. Aceste tipuri de tunele nu au nevoie
de specificarea destina
iei deoarece au nc orporat n protocol o metod prin care pot s o
determine automat. Efortul de configurare se reduce astfel la crearea unei singure interfe
e de
tunel n care trebuie specificat doar sursa tunelului indiferent de numrul de tunele necesar. Astfel
de tunele poart numele de point-to-multipoint. n cele ce urmeaz se va studia modul de
funcionare al unui tunel automat point-to-multipoint: Tunelul 6to4.
3.2.2.2 Tunelarea 6to4

Dac se dorete un tunel automat i scalabil prima observaie este c trebuie s existe o
metod de descoperire a adresei IP destinaie cu care trebuie ncapsulat pachetul.
Pentru a avea aceast funcionalitate, tunelele 6to4 definesc un prefix special ce trebuie folosit
n cadrul reelelor IPv6 ce doresc s comunice: 2002::/16. Orice insul IPv6 ce dorete s comunice
cu alt insul trebuie s aib adrese IPv6 create astfel:
2002
32 de bii ai adresei
IPv4 surs a tunelului
Interface ID
Subnet
Figura 3-5: Formatul unei adrese 6to4

Dup cum se observ din figura de mai sus, o adres 6to4 trebuie creat folosind cei 32 de bii
ai adresei surs de tunel. Adresa IPv6 de tunel pentru fiecare dintre cele dou capete ale tunelului
trebuie s foloseasc acest format de adresare pentru a fi posibil extragerea adresei IPv4, folosit
de tunel la ncapsulare. Cei 16 bii de subnet pot fi folosii n interiorul fiecrei insule pentru a aloca
adrese n acelai format cu primii 48 de bii comuni n toate reelele. n continuare se va analiza un
scenariu simplu pentru a evidenia comportamentul unui tunel 6to4.
Prefix insul: 2002:C80F:F01::/48
Prefix insul: 2002:D81A:10C1::/48
200.15.15.1
Insul
IPv6
216.26.16.193
Insul
IPv6
Reea IPv4
A
Tunnel0: 2002:C80F:F01::1/48
Tunnel0: 2002:D81A:10C1:200::1/64
Figura 3-6: Tunelarea 6to4

n afar de configuraiile din figur fiecare ruter mai are o rut spre 2002::/16 care are ca
interfa de ieire Tunnel0. Se va presupune c o staie din insula legat la ruterul A va trimite un
ping ctre o staie din insula B. Pentru c toate subreele din spatele ruterului A folosesc aceiai 48
de bii (sunt difereniate prin biii de subnet) pachetul va pleca cu adres IPv6 surs:
53 | I P v 6
2002:C80F:F01::X. Cnd va ajunge la ruterul A acesta l va trimite prin interfaa de tunel. nainte de a
putea ns trimite pachetul n tunel, ruterul A trebuie s realizeze ncapsularea IPv4 de tunel. Adresa
IP surs este configurat pe tunel ns adresa IP destinaie trebuie dedus. Ruterul analizeaz
adresa IPv6 destinaie a pachetului i extrage cei 32 de biii dintre bitul 16 i bitul 48 care reprezint
adresa IPv4 a celuilalt capt de tunel. Pachetul este acum ncapsulati poate fi trimis peste reeaua
IPv4.
n mod asemntor se realizeazi ncapsularea pentru traficul de ntoarcere pe ruterul B.
Configuraiile pentru tunele MCT, GRE i 6to4 vor putea fi gsite n subcapitolul Studiu de Caz.
3.3 Configurarea IPv6

3.3.1 Configurarea adresrii
n mod implicit o interfa de ruter dual-stack ruleaz doar IPv4. Prin aceasta se nelege c nu
va procesa pachetele trimise pe adresele de multicast FF02::1, FF02::2
i adresa de solicited-node
multicast. De asemenea, nu este posibil rutarea pachetelor ce folosesc antete IPv6.
Pentru a activa o interfa n protocolul IPv6 se folosete comanda ipv6 enable. Odat cu
activarea se genereaz i o adres link-local dup algoritmul descris n primul capitol.
Leshrac(config)#int Ethernet 2/1
Leshrac(config-if)#ipv enable
Leshrac(config-if)#^Z
Leshrac#sh ipv int Ethernet 2/1
Ethernet2/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::CE01:AFF:FE1C:21
No global unicast address is configured
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF1C:21
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
Hosts use stateless autoconfig for addresses.
Acelai efect ca i cel de mai sus poate fi obinut prin setarea unei adrese IPv6 pe interfa
.
Dup cum se poate vedea mai jos, un ruter accept mai multe adrese IPv6 pe aceea i interfa:
Leshrac(config)#int ethernet 2/1
Leshrac(config-if)#ipv add 2001::1/64
Leshrac(config-if)#ipv add 2001:100::2/64
Leshrac(config-if)#ipv add 2001:200::3/64
Leshrac(config-if)#^Z
Leshrac#sh ipv int br
[...]
Ethernet2/1
[up/up]
FE80::CE01:AFF:FE1C:21
2001::1
2001:100::2
2001:200::3
[...]
Pentru a activa NDP i rutarea de pachete IPv6, trebuie folosit comanda:

Leshrac(config)#ipv6 unicast-routing
n primul capitol de Design s-au discutat modurile prin care un administrator poate seta adrese
IP pe o interfa IPv6. Unul dintre acestea era metoda semi -automat prin care administratorul
specific adresa de reea i partea de subnet ns las ruterul s i
genereze propriul Interface ID
unic pe legtur.
Leshrac(config-if)#ipv address 2001:400::/64 eui-64
Leshrac(config-if)#do sh ipv int Ethernet2/1
[]
2001:400::CE01:AFF:FE1C:21, subnet is 2001:400::/64 [EUI]
[]
Fiind date dou rutere legate printr-o conexiune point-to-point, folosind Stateless autoconfiguration se poate configura automat interfaa unui ruter folosind informaiile pe care vecinul
su le poate furniza despre adresa i masca de reea a legturii respective.
Sange(config)#int e2/1
Sange(config-if)#ipv6 address autoconfig
Sange(config-if)#do sh ipv int e2/1
IPv6 is enabled, link-local address is FE80::CE0D:AFF:FE1C:21
Global unicast address(es):
2001::CE0D:AFF:FE1C:21, subnet is 2001::/64 [PRE/TEN]
Pentru a configura o adres anycast administratorul trebuie s specifice explicit acest fapt
ruterului deoarece adresele anycast sunt extrase din spaiul adreselor unicast.
Sange(config-if)#ipv address 2003::1/64 anycast
3.3.2 Configurri de rutare

Rutarea static funcioneaz n IPv6 n acelai mod ca i n IPv4 cu excepia definirii unei rute pe
un mediu multiacces dat prin interfa
de ieire. n IPv4, la de
finirea unei astfel de rute,
posibilitatea de a trimite pachete pe acea interfa
depindea de capacitatea ruterului vecin de a
face Proxy ARP. Cum n IPv6 nu mai exist ARP, toate rutele statice date pe un mediu multiacces
(Ethernet) trebuie date cu next-hop n locul interfeei de ieire.
Leshrac(config)# ipv route 2002::/16 2003:100::1
n toate protocoalele de rutare IPv6 configuraiile la nivelul modului (config-router)# s-au

mutat n modul (config-if)#. Principalul element adus protocolului RIPng ce se reflect n
configuraii este posibilitatea de a rula pn la 4 instane diferite de RIPng pe aceeai legtur.
Instana se definete prin intrarea n modul (config-router)# iar activarea se face la nivel de
interfa prin asocierea cu un parametru ce definete instana.
RouterR3#configure terminal
RouterR3(config)#ipv6 router rip RIPNGR3
RouterR3(config-rtr)#int fastethernet0/1
RouterR3(config-if)#ipv6 address 2001:410:ffff:1::1/64
RouterR3(config-if)#ipv6 rip RIPNGR3 enable
RouterR3(config-if)#ipv6 rip default-information originate
RouterR3(config-if)#int fastethernet0/0
RouterR3(config-if)#ipv6 address 2001:410:ffff:2::1/64
RouterR3(config-if)#ipv6 rip RIPNGR3 enable
RouterR3(config-if)#ipv6 rip default-information originate
RouterR3(config-if)#exit
n exemplul de mai sus instana RIPNGR3 este activat pe interfeele fa0/1 i fa0/0. De
asemenea ruterul vecin va trimite rute default pe aceste interfee ca rezultat al comenzii ipv6
rip default-information originate.
55 | I P v 6
3.3.3 Configurri de interconectare IPv4-IPv6

Se va prezenta mai nti configurarea unui tunel MCT (Manually Configured Tunnel). Acesta
este cel mai simplu tunel point-to-point ce poate realiza interconectarea de re
ele IPv6 peste un
Internet IPv4. Deoarece acest tip de tunel nu este o soluie scalabil, el este folosit pentru a conecta
un numr limitat de reele IPv6.
Urmnd paii descrii n capitolul 4.2.2.1 se va prezenta configurarea unui astfel de tunel n cele
dou capete ale sale.
Leshrac(config)# interface Tunnel0
Leshrac(config-if)# no ip address
Leshrac(config-if)# ipv6 address 2001::1/64
Leshrac(config-if)# tunnel source Ethernet2/1
Leshrac(config-if)# tunnel destination 172.1.231.1
Leshrac(config-if)# tunnel mode ipv6ip
Sange(config)# interface Tunnel0
Sange(config-if)# no ip address
Sange(config-if)# ipv6 address 2001:200::1/64
Sange(config-if)# tunnel source Ethernet2/1
Sange(config-if)# tunnel destination 172.1.231.2
Sange(config-if)# tunnel mode ipv6ip
Din output-ul de mai jos se poate observa c adresa tunel destina

ie configurat la un capt
este adresa de pe tunnel source al celuilalt capt.
Leshrac#sh ip int br Eth 2/1
Interface
IP-Address
Ethernet2/1
172.1.231.2
OK? Method Status

YES NVRAM up
Sange#sh ip int br E2/1

Interface
Ethernet2/1
OK? Method Status

YES NVRAM up
IP-Address
172.1.231.1
Pn n acest punct ambele interfeele de tunel au fost configurate corect i sunt n starea up.
Totui, cnd se ncearc trimiterea unui ping dintr-o interfa de tunel n cealalt, aceasta nu
funcioneaz. Problema este foarte uor de intuit: nu exist rut n tabela de rutare IPv6. Dup
adugarea unei rute pe fiecare dintre rutere pentru reelele IPv6 remote, ping-ul va funciona.
Sange(config)#ipv route 2001::/64 Tunnel0
Leshrac(config)#ipv route 2001:200::/64 Tunnel0
Sange#ping ipv 2001::1 source Tunnel 0

Sending 5, 100-byte ICMP Echos to 2001::1, timeout is 2 seconds:
Packet sent with a source address of 2001:200::1
!!!!!
Soluia de tunel MCT sau GRE este cea mai bun cnd se pune problema unei rezolvri rapide.
Pentru soluii permanente i scalabile sunt preferate tunelele automate.
n continuare se vor prezenta configura
iile realizate pentru instalarea unui tunel 6to4 ntre
dou insule IPv6.
Mai nti se vor configura adresele IPv4 pe interfeele legate la reeaua IPv4.
Sven(config)#interface FastEthernet3/0
Sven(config-if)#ip address 172.14.31.2 255.255.255.252
Leshrac(config)#interface Ethernet2/1
Leshrac(config-if)#ip address 172.1.231.2 255.255.255.252
Pentru ca metoda automat de descoperire a adreselor ie

destina
de ncapsulare s
funcioneze, va trebui s obinem echivalentul n hexazecimal al fiecrei adrese IP:
172.14.31.2 -> AC0E:1F02 -> Adresa IPv6 pentru Sven va fi 2002:AC0E:1F02:xxxx::x/64
172.1.231.2 -> AC01:EF02 -> Adresa IPv6 pentru Leshrac va fi 2002:AC01:EF02:xxxx::x/64
Configuraiile de tunel sunt urmtoarele:
Leshrac(config)# interface Tunnel0
Leshrac(config-if)# no ip address
Leshrac(config-if)# no ip redirects
Leshrac(config-if)# ipv6 address 2002:AC01:EF02:2::2/64
Leshrac(config-if)# tunnel source Ethernet2/1
Leshrac(config-if)# tunnel mode ipv6ip 6to4
Sven(config)# interface Tunnel0
Sven(config-if)# no ip address
Sven(config-if)# no ip redirects
Sven(config-if)# ipv6 address 2002:AC0E:1F02:4::2/64
Sven(config-if)# tunnel source FastEthernet3/0
Sven(config-if)# tunnel mode ipv6ip 6to4
Tot ce trebuie adugat pentru ca a face posibil comunicarea ntre cele 2 rutere este o rut
2002::/16 cu interfa de ieire Tunnel0 pe fiecare dintre capetele tunelului.
3.4 Studiu de caz

n studiul de caz ce urmeaz se va realiza proiectarea i instalarea a 3 reele IPv6 ncepnd de la
o infrastructur IPv4. n final va trebui ca toate reele IPv6 s poat comunica ntre ele peste IPv4.
Caprica
E2/2
Kobol
E2/1
Reea IPv4
Fa3/0
E2/2
E2/2
Earth
Moon
Figura 3-7: Studiu de caz

Primul pas n configurarea reelei l constituie insula creat din ruterele Earth i Moon. Reeaua
dintre Earth i Moon trebuie configurat cu adrese IPv6 din spaiul 2001:100::/64. Earth trebuie
configurat manual n timp ce Moon trebuie isseteze
parametrii de nivel 3 p
rin stateless
autoconfig.
57 | I P v 6
Earth(config)#int ethernet 2/2
Earth(config-if)#ipv6 address 2001:100::1/64
Moon(config)#int e2/2
Moon(config-if)#ipv address autoconfig
Earth#sh ipv int br
[]
Ethernet2/2
[up/up]
FE80::CE06:8FF:FE74:22
2001:100::1
Moon#sh ipv int br
[]
Ethernet2/2
[up/up]
FE80::CE0F:8FF:FE74:22
2001:100::CE0F:8FF:FE74:22
Ruterele Caprica i Kobol vor deine fiecare cte o interfa de loopback prin care o s simuleze
o reea Ethernet:
Caprica: Loopback1 -> 2001:3::1/64
Kobol: Loopback1 -> 2001:4::1/64
Caprica#sh ipv int br Lo1
Loopback1
[up/up]
FE80::CE09:8FF:FE74:0
2001:3::1
Kobol(config)#int lo1
Kobol(config-if)#ipv address 2001:4::1/64
Kobol(config-if)#exit
Kobol(config)#do sh ipv int br Lo1
Loopback1
[up/up]
FE80::CE01:8FF:FE74:0
2001:4::1
Deoarece se dorete implementarea unei soluii scalabile administratorul de reea a luat decizia
utilizrii unui tunel automat 6to4. Urmtorul pas n configurare va necesita traducerea n
hexazecimal a adreselor IPv4 de pe ruterele Earth, Kobol, Caprica. Adresele IPv4 corespunztoare
sunt:
Earth#sh ip int br fa3/0
Interface
FastEthernet3/0
IP-Address
172.14.31.2
OK? Method Status

YES NVRAM up
Kobol# sh ip int br e2/1

Interface
Ethernet2/1
IP-Address
172.1.231.2
OK? Method Status

YES NVRAM up
Caprica#sh ip int br e2/2

Interface
Ethernet2/2
IP-Address
172.17.0.2
OK? Method Status

YES NVRAM up
Pentru fiecare dintre cele 3 rutere traducerile vor fi:

Earth: AC0E:1F02
Kobol: AC01:E702
Caprica: AC11:0002
Odat obinui biii 16 -48 din fiecare adres IPv6, se pot configura interfe
ele de tunel cu
adresele IP corespunztoare.
Kobol(config)# interface Tunnel0
Kobol(config-if)# ipv6 address 2002:AC01:EF02:2::2/64
Kobol(config-if)# tunnel source Ethernet2/1
Kobol(config-if)# tunnel mode ipv6ip 6to4
Caprica(config)# interface Tunnel1
Caprica(config-if)# ipv6 address 2002:AC11:0002:2::1/64
Caprica(config-if)# tunnel source Ethernet2/2
Caprica(config-if)# tunnel mode ipv6ip
Earth(config)# interface Tunnel0
Earth(config-if)# ipv6 address 2002:AC0E:1F02:4::2/64
Earth(config-if)# tunnel source FastEthernet3/0
Earth(config-if)# tunnel mode ipv6ip 6to4
Interfeele de tunel sunt n acest moment n starea up i sunt pregtite pentru rutare. Singura
component care lipsete sunt rutele statice care s introduc traficul IPv6 n tunel. Pentru a
comunica ntre interfeele de tunel avem nevoie de rute ctre reeaua 2002::/16.
Kobol(config)# ipv6 route 2002::/16 Tunnel0
Earth(config)# ipv6 route 2002::/16 Tunnel0
Caprica(config)# ipv6 route 2002::/16 Tunnel0
Dup cum se poate vedea n rezultatul de mai jos, comunica

ia ntre interfeele de
acum posibil.
tunel este
Earth#ping 2002:AC11:0002:2::1
Sending 5, 100-byte ICMP Echos to 2002:AC11:2:2::1, timeout is 2 seconds:
!!!!!
Scopul final este ns posibilitatea de a da ping n interfeele de Loopback ale ruterelor Caprica
i Kobol i n reeaua IPv6 din spatele ruterului Earth.
Toate aceste reele au aceiai 16 bii deci, teoretic, problema s-ar putea rezolva prin instalarea
unei rute 2001::/16 pe fiecare ruter de border, avnt interfaa tunelului drept interfa de ieire.
Problema cu aceast soluie este c ruterele de border nu vor ti cu ce IP destinaie s ncapsuleze
pachetului cnd l introduc n tunel deoarece ping-ul se d ntr-o adres 2001::/16 i nu ntr -o
adres 6to4. Pentru a face aceast schem s func
ioneze trebuie s se ofere fiecrui ruter de
border n mod explicit un next-hop din spaiul 6to4.
Acest lucru se poate face cel mai simplu desemnnd unul dintre trei rutere ca hub 6to4 i
configurnd pe celelalte 2 rute statice cu next-hop, hub-ul. Astfel cele 2 rutere vor deduce IP-ul
destinaie pentru ncapsulare din ruta static, iar hub-ul va realiza rutarea ntre adrese 6to4.
Se va considera ruterul Earth ca fiind hub-ul topologiei i se vor defini rute statice pe Caprica i
Kobol. De asemenea, se va configura o rut default pe Moon pentru ca acesta s poat avea acces la
celelalte insule.
Caprica(config)# ipv6 route 2001::/16 2002:AC0E:1F02:4::2
Kobol(config)# ipv6 route 2001::/16 2002:AC0E:1F02:4::2
Moon(config)# ipv6 route ::/0 2001:100::1
Rezultatul final este faptul c un ping de pe Moon pe interfa

a
demonstra conectivitatea.
de loopback a lui Kobol va
Moon#ping 2001:4::1
Sending 5, 100-byte ICMP Echos to 2001:4::1, timeout is 2 seconds:
!!!!!
4 EIGRP
4.1 Prezentarea protocolului

Enhanced Interior Routing Protocol (EIGRP) este un protocol de rutare proprietar Cisco. EIGRP a
fost descris ca fiind un protocol de rutare hibrid, deoarece combin caracteristicile protocoalelor
bazate pe vectori de distan cu algoritmii protocoalelor bazate pe starea conexiunilor. Totui, o
descriere mai corect ar fi cea de protocol avansat bazat pe vectori de distan.
Fa de protocoalele bazate pe vectori de distan RIP v1 i IGRP, EIGRP ofer: convergen
rapid, consum redus de lime de band, suport pentru protocoale rutate multiple i suport pentru
CIDR i VLSM. Aceste caracteristici sunt obinute prin folosirea unor mecanisme specifice
protocoalelor bazate pe starea legaturii, cum ar fi actualizare parial i de descoperire a vecinilor.
O limitare nsemnat provine din natura proprierar a protocolului, EIGRP fiind o soluie de
rutare pentru reele ce conin doar echipamente Cisco. A doua limitare o reprezint natura
neierarhic a protocolului, scalabilitatea protocolului recomandndu-l pentru implementri de sub
1000 de rutere.
Cu toate acestea EIGRP ofer, cel mai adesea, timpi de convergen mai redui dect OSPF, mai
ales n cazul unui grad ridicat de redundan. Acest lucru este realizat prin identificarea unor rute
viabile, nu doar a celor mai bune ci precum n cazul protocoalelor clasice de rutare.
n plus, complexitatea de configurare i administrare a EIGRP este semnificativ mai sczut
dect cea impus de ctre OSPF.
4.1.1 Caracteristici ale EIGRP

Cele mai importante caracteristici ale protocolului de rutare EIGRP sunt: convergena rapid,
suportul pentru VLSM, actualizrile pariale i suportul pentru protocoale rutate multiple.
Convergena rapid este dat de faptul ca ruterul stocheaz tabelele de rutare ale tuturor
vecinilor, iar atunci cand o rut dispare, va folosi o rut alternativ. n cazul n care nu are o astfel de
rut, i va ntreba vecinii dac cunosc o rut alternativ. ntrebarea se propag pn cnd este
descoperit o rut, sau se determin ca o rut alternativ nu exist.
Suportul pentru VLSM permite folosirea mtilor de lungime diferit pentru aceeai reea i
suportul pentru subreele discontinue. EIGRP este un protocol de rutare classless, ceea ce nseamn
c atunci cnd anun o rut ctre o reea, trimite i masca de reea.
Spre deosebire de celelalte protocoale bazate pe vectori de distan, EIGRP nu trimite
actualizri periodice, ci actualizri pariale, declanate de evenimentele din reea. Actualizrile sunt
trimise numai cnd calea sau metrica pentru o anumit destinaie se schimb, i conin doar
informaii despre rutele modificate. EIGRP are un comportament diferit fa de protocoalele bazate
pe starea legturilor, acestea din urm trimind actualizrile ctre toate ruterele din reea. EIGRP
folosete pachete unicast i multicast pentru a propaga actualizarea doar ctre ruterele care au
nevoie s cunoasc acea informaie. Toate aceste mecanisme duc la un consum mai mic de lime
de band.
EIGRP deine o serie de componente specifice, care l difereniaz de celelalte protocoale de
rutare: module indepedente de protocol, Reliable Transport Protocol (RTP), mecanismul de
descoperire a vecinilor i Diffusing Update Algorithm (DUAL).
Modulele independente permit ca EIGRP s suporte mai multe protocoale de nivel reea,
precum IP, AppleTalk i IPX. Aceste module sunt responsabile cu cerinele specifice nivelului reea.
RTP va garanta livrarea ordonat a pachetelor EIGRP tuturor vecinilor, dei, din motive de eficien,
doar anumite pachete vor avea livrarea garantat. RTP folosete o combinaie ntre transmisia
unicast i multicast.
4.1.2 Descoperirea vecinilor EIGRP

Exist dou probleme n legatur cu actualizrile sigure folosite de EIGRP. Pe de o parte, ruterul
nu tie cte pachete de tip Ack s atepte, deoarece nu cunoaste numrul de echipamente rutere
din reea. Pe de alt parte, ruterul nu tie dac o actualizare pierdut nseamn c nu exist nici o
informaie nou, sau c vecinul este deconectat.
Aceste probleme sunt adresate de ctre protocolul EIGRP folosind noiunea de vecini.
Pachetele de tip Hello sunt folosite pentru a construi o tabel de vecini pe fiecare ruter. Dac un
vecin nu trimite pachete Hello o anumit perioad de timp (hold time), atunci vecinul este scos din
tabela EIGRP i se produce o reconvergen a rutrii.
Un proces EIGRP ncepe cu descoperirea vecinilor. Apoi, va trimite actualizri n mod multicast
i va atepta confirmri unicast. Tabela cu vecinii va fi folosit pentru a verifica care dintre acetia
nu au confirmat. Ruterul va trimite actualizrile n mod unicast tuturor vecinilor care nu au
confirmat. Dup 16 actualizri trimise ctre un vecin fr a primi o confirmare, ruterul l va terge
din tabela de vecini. Atunci cnd vecinul este reconectat i trimite din nou pachete Hello, va fi
reintegrat in procesul de selectare a cilor optime.
4.1.3 Calculul metricii EIGRP

EIGRP folosete o metric compus asemntoare celei folosite de IGRP. Aceast metric are
urmtoarele componente: limea de band (bandwidth), latena (delay), sigurana (reliability) i
ncrcarea (load). Singura diferen ntre cele dou protocoale este c metrica EIGRP este egal cu
metrica IGRP nmulit cu 256, deoarece se folosesc 32 de bii n loc de 24.
Componentele privind limea de band i latena sunt considerate n mod implicit n calculul
metricii. Bandwidth se refer la cea mai mic lime de band de pe calea ctre destinaie. Delay se
refer la suma latenelor de pe fiecare legtur din calea ctre destinaie. n plus, pot fi avute n
vedere n calculul metricii i variabile privind sigurana i ncrcarea. Reliability este calculat ca
fiind cel mai slab nivel de siguran de pe calea ctre destinaie, fiind estimat prin schimbul de
mesaje keepalive. Load se refer la cel mai defavorabil nivel de ncrcare de pe calea ctre
destinaie, estimat prin rata pachetelor i prin limea de band configurat.
Formula complet pentru calculul metricii este:
metrica = 256 x [K1 x Bandwidth + (K2 x Bandwidth)/(256 Load) + K3 x Delay] x [K5/(Reliability
+ K4)]
61 | E I G R P
Aceast formul este folosit pentru valori nenule a factorului K5. n cazul n care K5 este 0
formula de calcul a metricii este:
metrica = 256 x [K1 x Bandwidth + (K2 x Bandwidth)/(256 Load) + K3 x Delay]
n mod implicit K2=K4=K5=0 i K1=K3=1. n aceast situaie singurii factori ce intr n
componena metricii sunt limea de band i latena interfeei. Formula de calcul a metricii devine:
metrica = 256 x (Bandwidth + Delay)
Parametrii K pot fi modificai, dar este necesar o planificare atent, deoarece modificarea
acestor valori poate cauza probleme de convergen.
Bandwidth este calculat dup formula Bandwidth =
107 / min(bandwith), unde
min(bandwidth) nseamn limea de band minim ntlnit pe calea ctre destinaie, exprimat n
Kbps.
Delay este calculat dup formula Delay = delays / 10, unde delays nseamn suma latenelor
legturilor de pe calea ctre destinaie, exprimate n microsecunde.
De exemplu, n topologia din figura 4-1,limile de band sunt reprezentate n figur iar latena
pentru fiecare legtur este egal cu 20000.
R2
768 Kbps
R3
1536 Kbps
1536 Kbps
R1
10.2.12.0/24
512 Kbps
R5
R4
Figura 4-1: Calculul metricii
Calculm costul cii de la R1 la reeaua 10.2.12.0/24:

Bandwidth = 107 / min(bandwidth) = 107 / 768 = 13020
Delay = 3 x 20000 / 10 = 60000 / 10 = 6000
Metrica = 256 x (13020 + 6000) = 4869120
Calculm costul cii de la R5 la reeaua 10.2.12.0/24:
Delay = 3 x 20000 / 10 = 40000 / 10 = 4000
Metrica = 256 x (19531 + 4000) = 6023936
4.1.4 Maina de stri finite DUAL

Diffusing Update Algorithm Finite State Machine (DUAL FSM) permite ruterului s identifice
cile care nu conin bucle. Pentru fiecare destinaie sunt determinate toate cile fr bucle, ruta de
cost minim va promova n tabela de rutare.
Un ruter ce primete un pachet de actualizare va extrage secvenial fiecare rut. Metrica unei
rute din pachetul de actualizare va fi modificat n conformitate cu parametrii legturii (interfeei)
pe care a fost primit actualizarea. Rezultatul obinut va fi comparat cu restul informaiilor de rutare
pentru respectiva destinaie. Metrica cea mai mic pentru o destinaie poart numele de distan
viabil.
Un succesor reprezint un ruter adiacent prin care trece calea cu distana viabil minim. Ruta
de cost minim este introdus n tabela de rutare. Implicit pot exista n tabela de rutare maximum 4
rute cu acelai cost minim, dar ruterul poate fi configurat pentru a accepta ase rute de cost minim
pentru fiecare destinaie.
Un succesor viabil este un ruter vecin prin care trece o cale care are o distan viabil mai mare
dect a succesorului curent, dar care are o distan raportat mai mic dect distana viabil a
succesorului curent. Aceste rute nu vor fi introduse n tabela de rutare, dar vor fi pstrate n tabela
de topologie (prezentat mai jos) ca rute de backup.
Dac o rut care trece prin succesorul curent devine invalid, sau dac un vecin i schimb
metrica, DUAL verific existena succesorilor viabili pentru acea destinaie. Dac exist cel puin un
succesor viabil, nu se declaneaz recalcularea rutei. Dac nu exist nici un succesor viabil, se
recalculeaz ruta pentru a determina un nou succesor.
De exemplu, n topologia din figura 4-1, pe R1 algoritmul DUAL consider dou ci pentru
destinaia 10.2.12.0/24, una prin ruterul R2 i una prin ruterul R5.
Este calculat distana viabil pentru cele dou rute: pentru R2 este 4869120 iar pentru R5 este
6023936. Rezult c R2 este succesorul pentru aceast destinaie. Pentru a afla dac R5 este un
succesor viabil trebuie calculat distana raportat a rutei prin R5:
Delay = 3 x 20000 / 10 = 20000 / 10 = 2000
Metrica = 256 x (19531 + 2000) = 5511936
Distana raportat este mai mare dect distana viabil a succesorului, deci R5 nu poate fi un
succesor viabil. Prin urmare, dac ruta prin R2 devine invalid, ruterul R1 trebuie s declaneze
recalcularea rutei.
4.1.5 Tabelele EIGRP

Protocolul EIGRP construiete i menine 3 tabele: tabela cu vecinii, tabela de topologie i
tabela de rutare. Tabela cu vecini conine informaii despre ruterele adiacente i este folosit
pentru a verifica primirea confirmrilor de la toi vecinii. Tabela de topologie conine toate cile din
reea. Cele mai bune ci din tabela de topologie sunt introduse n tabela de rutare.
Cnd un ruter descoper i formeaz o adiacen cu un vecin nou, introduce n tabela cu vecini
adresa i interfaa pe care vecinul poate fi accesat. Tabela cu vecini este asemntoare tabelei de
adiacen a protocoalelor de rutare bazate pe starea conexiunii, deoarece asigur comunicaia
bidirecional ntre vecinii direct conectai. Un interval de hold time este anunat odat cu pachetul
Hello, fiind timpul n care vecinul este considerat accesibil. Dac acest interval expir fr s fi fost
primit nici un pachet Hello, atunci DUAL va fi anunat de schimbarea de topologie. Pentru fiecare
protocol de nivel 3 (IPv4, IPv6, IPX i AppleTalk) se construiete o tabel de vecini separat, iar
informaiile despre vecini, rute i costuri nu sunt partajate ntre protocoale.
Cnd un ruter stabilete o legtur de adiacen cu un nou vecin, i va trimite un pachet Update
cu rutele pe care le cunoate. Noul vecin de asemenea i va trimite rutele cunoscute de el. Aceste
informaii sunt introduse n tabela de topologie, care va conine toate rutele anunate de ctre
63 | E I G R P
ruterele adiacente. Este important de observat c vor fi anunate doar rutele care apar n tabela de
rutare, aceasta fiind o caracteristic specific protocoalelor de rutare bazate pe vectori de distan.
n tabela de topologie este stocat distana raportat i distana viabil pentru fiecare rut n parte.
Tabela de topologie se modific doar atunci cnd o rut direct conectat sau o interfa se schimb,
sau cnd un vecin anun o modificare a unei rute. O destinaie poate avea ataat n tabel fie o
stare activ, fie o stare pasiv. O destinaie se afl n starea activ dac n acel moment se
recalculeaz ruta, iar n caz contrar destinaia se afl ntr-o stare pasiv. Recalcularea este efectuat
atunci cnd ruta ce trece prin succesorul curent devine nevalid i nu exist un succesor viabil.
Recalcularea debuteaz prin trimiterea pachetelor de tip Query (definite mai jos) la toi vecinii.
Acest proces se va repeta n mod recursiv la toi vecinii care nu au o rut ctre destinaie. Cnd
ruterul primete rspuns de la toi vecinii va trece destinaia n modul pasiv i va alege un succesor.
Ruterul compar toate distanele viabile pentru o anumit destinaie i selecteaz ruta cu cea
mai mic distan viabil. Aceast rut de cost minim identific i ruterul succesor, i va fi plasat in
tabela de rutare. Distana viabil a acestei rute devine metrica EIGRP pentru destinaia respectiv.
4.1.6 Formatul pachetelor EIGRP

Protocolul EIGRP folosete 5 tipuri de pachete pentru comunicarea ntre rutere: Hello, Update,
Ack, Query i Reply. Pachetele sunt ncapsulate direct n IP.
Rolul pachetelelor Hello este de a identifica i verifica vecinii. Pachetele de tip Hello sunt trimise
de ctre ruterele care ruleaz EIGRP la intervale fixe dar configurabile, numite intervale Hello.
Aceste intervale depind de limea de band a interfeei. Pachetele sunt trimise prin transmisie
multicast la adresa 224.0.0.10 i nu sunt confirmate de ctre destinaie. Fiecare ruter stocheaz n
tabela cu vecini informaiile din pachetele Hello primite de la vecinii si. Dac nici un pachet Hello
nu este primit ntr-un interval de Hold (Hold time), ruterul consider ca vecinul nu mai este
accesibil. n mod implicit, intervalul Hold este de trei ori mai mare decat intervalul Hello, dar ambele
pot fi configurate. Spre deosebire de OSPF, EIGRP nu necesit ca intervalele s fie egale pentru doi
vecini care comunic, ci acestea i nva reciproc intervalele. Pentru o lime de band de pn la
1.544 Mbps, de exemplu n cazul Multipoint Frame Relay, intervalul Hello este de 60 de secunde iar
intervalul Hold este de 180 de secunde. Pentru limi de band mai mari de 1.544 Mbps, de
exemplu T1 sau Ethernet, intervalul Hello este de 5 secunde iar intervalul Hold este de 15 secunde.
Pachetele de tip Update sunt folosite pentru a anuna rutele. Atunci cnd un nou vecin este
descoperit, ruterele trimit pachete Update prin transmisie unicast, pentru ca ruterul vecin s-i
construiasc tabela de topologie. De asemenea, ele sunt trimise prin multicast atunci cnd se
modific o rut. Dac se primete un Update care anun c o cale nu mai exist, ruterul i va
ntreba vecinii prin multicast dac mai au o cale spre aceeai destinaie. Dac un anume vecin nu
rspunde, l va ntreba din nou printr-un pachet unicast. Va renuna dupa ce a ncercat de 16 ori fr
s fi primit nici un rspuns. Pachetele de tip Update sunt trimise n mod sigur, deoarece necesit
confirmare din partea destinaiei. Pachetele de tip Query sunt folosite atunci cnd un ruter are
nevoie de informaii specifice de la vecinii si. Atunci cnd un ruter i pierde succesorul pentru o
anumit destinaie i nu are nici un succesor viabil, plaseaz ruta n starea activ i trimite un pachet
de tip Query prin transmisie multicast ctre toi vecinii si. Pachetele de tip Update sunt trimise n
mod sigur.
Pachetele de tip Reply sunt folosite pentru a rspunde prin unicast la pachetele de tip Query.
Rspunsul este c exist o cale alternativ sau nu exist nici o cale spre acea destinaie. Pachetele
de tip Reply sunt trimise n mod sigur.
Pachetele Ack sunt trimise pentru a confirma pachetele transmise n mod sigur, mai exact
pachetele de tip Update, Query i Reply. Pachetele de confirmare sunt trimise n mod unicast.
4.2 Concepte avansate

4.2.1 Sumarizarea rutelor
Sumarizarea rutelor determin o dimensiune mai mic a tabelei de rutare, iar procesul de
actualizare a rutelor consum mai puin lime de band. Sumarizarea automat a rutelor la
grania clasei din care face parte reeaua este configurat implicit pentru rutele nvate prin EIGRP.
EIGRP nu sumarizeaz reelele care nu particip la rutare.
n anumite cazuri sumarizarea automat nu este potrivit, de exemplu n cazul reelelor
discontinue. n aceste situaii, sumarizarea automat trebuie dezactivat.
Pot fi configurate manual sumarizri de orice dimensiune n reeaua intern, ct timp o rut
mai specific exist n tabel. Cnd ruta specific va fi scoas din tabela de rutare, ruta sumarizat
va fi de asemenea scoas.
4.2.2 Echilibrarea traficului

Echilibrarea traficului (load balancing) de cost egal este procesul prin care ruterul distribuie
traficul ctre toate interfeele care au asociate rute cu metrici egale ctre aceeai destinaie.
Procesul de load balancing conduce la folosirea tuturor rutelor ctre aceai destinaie i crete
limea de band efectiv. EIGRP face n mod implicit echilibrarea traficului pentru toate cile de
cost egal, plasnd cel mult patru rute de cost egal n tabela de rutare. Ruterul poate fi ns
configurat s accepte maximum ase rute de cost egal.
O caracteristic important a protocolului EIGRP este faptul c poate echilibra traficul pe mai
multe rute de cost diferit, innd cont de o valoare a variaiei acceptabile a metricilor folosite n
procesul de load balancing. Mai precis, vor fi acceptate toate rutele cu metrica mai mic dect
valoarea obinut prin nmulirea valorii variaiei cu metrica rutei de cost minim. Aceste rute trebuie
de asemenea s aib distana raportat mai mic dect distana viabil a succesorului. Prin urmare,
procesul de load balancing poate folosi doar succesori i succesori viabili. Aceast condiie previne
buclele de rutare.
4.2.3 Scalabilitatea EIGRP n reele mari

EIGRP este un protocol scalabil deoarece, odat cu creterea n dimensiune a reelei,
performana nu se diminueaz i procesul se ajusteaz rapid la schimbri. Protocolul ofer soluii
pentru asigurarea scalabilitii n reele mari, de exemplu prin folosirea ruterelor stub pentru a
limita domeniul n care se trimit pachete de tip Query.
Urmtorii factori pot afecta scalabilitatea unei reele: cantitatea de informaie schimbat ntre
rutere, numrul de rutere, adncimea topologiei i numrul de ci alternative prin reea. Cu ct
cantitatea de informaie este mai mare, cu att ruterele trebuie s trimit mai mult informaie
atunci cnd apare un vecin nou sau atunci cnd sunt schimbri de topologie. Consumul de resurse
pe un ruter este legat direct de numrul de rutere aflate n acea reea.
Adncimea unei topologii se refer la numrul de hopuri pe care informaia trebuie s le
parcurg pentru a ajunge la toate ruterele din reea. Latena propagrii i a procesului de
investigare prin pachete Query ncetinesc convergena reelei cu ct adncimea este mai mare. Este
recomandat limita maxim de 7 hopuri.
65 | E I G R P
O reea ar trebui s ofere ci alternative pentru a nu exista vulnerabilitatea unui punct singular
de eec (single point of failure). Cu toate acestea, prea multe ci alternative pot duce la probleme
de convergen, deoarece procesul de rutare trebuie s exploreze toate cile pentru rutele
pierdute.
4.2.4 EIGRP Queries

n cazul n care o rut devine nevalid i nu exist succesor viabil n tabela de topologie, va
trebui gsit o cale alternativ pentru acea destinaie. Ruta intr n starea activ i ruterul trimite
pachete de tip Query ctre toi vecinii si, n afar de vecinul prin care trecea ruta declarat
nevalid, ntrebnd dac au o rut ctre destinaia specificat.
Dac vecinul care a primit un Query are o rut alternativ, va trimite un pachet Reply coninnd
ruta. Dac vecinul nu are nici o rut ctre destinaie trimite pachete Query la toi vecinii si
ntrebnd de o cale alternativ. Astfel pachetele de tip Query se propag prin reea formnd un
arbore de cereri. Cnd un ruter are o rut alternativ oprete propagarea pachetelor pentru ramura
respectiv. Totui, pe celelalte ramuri propagarea nu este oprit.
Ruterul trebuie s primeasc toate rspunsurile de la vecinii si pentru a putea calcula noul
succesor. Abia dup aceea va putea iei din starea activ i intra din nou n starea pasiv. Dac
ruterul nu primete toate rspunsurile ntr-o perioad maxim de 3 minute, va intra n starea Stuck
in Active (SIA). Rutele aflate n SIA reprezint una dintre probleme cele mai mari ale unei reele
EIGRP. O rut intrat n starea SIA determin resetarea legturii cu vecinul care nu rspunde, ceea
ce conduce la intrarea in starea activ a tuturor rutelor care treceau prin vecinul respectiv.
Motivele pentru care o rut poate intra n starea SIA sunt:
ruterul vecin nu poate rspunde deoarece procesorul este folosit intensiv sau nu poate fi
alocat memorie pentru a procesa cererea i a livra un rspuns;
legtura dintre ruter i vecinul su are probleme i pachetele Query i Reply sunt pierdute;
o defeciune poate cauza funcionarea unidirecional a legturii;
exist prea multe ci alternative prin reea, fapt ce determin probleme de convergen iar
ruta intr n SIA deoarece ateapt rspunsurile pentru toate pachetele Query propagate pe
toate cile alternative.
4.2.5 EIGRP Stub

Un ruter este stub dac este conectat la un ruter de nivel central (core), dar traficul din core nu
trece prin el.
Un ruter stub EIGRP i va anuna vecinii despre faptul c este stub iar vecinii vor nceta s-i mai
trimit pachete de tip Query. n schimb, ruterul care are conectat un ruter stub va rspunde n locul
acestuia. Cu toate acestea, ruterul stub va primi anunuri cu rute exact ca un ruter normal.
Configurarea unui ruter ca stub va duce la creterea scalabilitii reelei i la minimizarea
utilizrii memoriei i a procesorului ruterului respectiv, fiind o configuraie potrivit pentru ruterele
ncete i cu memorie puin.
4.2.6 Autentificarea EIGRP

Pentru a garanta sursa informaiilor pe care le primete un ruter EIGRP, protocolul permite
autentificarea vecinilor nainte de a schimba informaii de rutare cu acetia.
Protocolul EIGRP suport dou tipuri de autentificare: parole simple i MD5. Parolele simple
sunt trimise n clar i potrivite cu cheia destinatarului. Ele nu ofer sigurana, deoarece oricine
poate captura traficul are acces i la aceast cheie.
Dat fiind c parolele simple nu sunt potrivite pentru securizarea comunicaiei, se recomand
folosirea parolelor criptate prin MD5. MD5 este o funcie criptografic de tip rezumat (hash)
unidirecional prin care se obine o valoare de lungime fix de 128 de bii. Cheile criptate cu MD5
sunt sigure deoarece din traficul capturat nu se poate obine cheia iniial.
Folosind o cheie criptat prin MD5 n fiecare pachet, EIGRP previne acceptarea de ctre ruter a
informaiilor false i neautorizate. Pentru autentificarea prin MD5, un identificator de cheie i o
cheie de autenificare trebuie specificate pentru ambele rutere care comunic. Fiecare identificator
de cheie are ataat o cheie distinct. Mai multe chei pot fi grupate ntr-un lan de chei (key chain).
Pentru fiecare identificator de cheie se poate specifica un interval de timp n care cheia este valid.
Cnd se primete un pachet de autentificare, se parcurge lanul de chei de la identificatorul cel mai
mic la cel mai mare pentru a se identifica cheia potrivit.
4.3 Configurarea protocolului

4.3.1 Configurri de baz
Pentru a configura protocolul de rutare EIGRP este necesar parcurgerea urmtorilor pai:
Pas 1. Activarea procesului EIGRP i specificarea unui numr de sistem autonom. Cel mai
adesea el nu are o legtur direct cu numrul sistemului autonom din care face parte ruterul,
sigura constrngere fiind ca aceai valoare s fie configurat pe fiecare dintre ruterele din cadrul
reelei EIGRP.
Router(config)#router eigrp numar_AS
Pas 2. Specificarea reelelor care fac parte din sistemul autonom. Aceast comand indic ce
interfee particip la rutarea prin EIGRP i ce reele sunt anunate de ctre ruter.
Router(config-router)#network retea [masca_wildcard]
Masca poate fi specificat pentru a identifica anumite subreele ale unei clase de reea i poate
fi introdus n formatul invers sau n formatul normal de masc de reea.
Pas 3. Poate fi definit limea de band a unei legturi. Aceast valoare configurat nu
afecteaz viteza actual a legturii, dar este folosit pentru calculele efectuate de protocolul de
rutare. Folosind urmtoarea comand, limea de band este specificat n Kbps:
Router(config-if)#bandwidth valoare
Dac nu este specificat n mod explicit limea de band pentru o legatur serial, protocolul
va presupune c limea de band este cea pentru o legtura T1. Dac legtura fizic este mai
nceat, ruterul poate s nu mai convearg sau actualizrile pot fi pierdute.
Pentru exemplificarea folosirii acestor comenzi, se va considera urmtorul exemplu de
configurare. Se va folosi topologia din figura 4-2. Cele 4 rutere trebuie configurate ca aparinnd
aceluiai sistem autonom cu numrul 101. Reeaua 172.16.9.0/24 nu trebuie s fac parte din
reeaua EIGP.
67 | E I G R P
172.16.9.0/24
172.16.5.0/24
172.16.7.0/24
192.168.80.0/24
172.16.10.0/2
10.1.0.0/16
10.2.0.0/16
172.16.8.0/24
172.16.6.0/24
Figura 4-2: Exemplu de configurare

Ruterul R1 va trebui configurat n felul urmtor:
R1(config)#router eigrp 101
R1(config-router)#network 192.168.80.0 0.0.0.255
Pentru ruterul R2 vor trebui introduse umtoarele comenzi:

Pentru ruterul R3 urmtoarele comenzi:


S-au specificat doar reelele care sunt direct conectate. Mti de tip wildcard au fost folosite
pentru a indica subreelele adresei de clasa B 172.16.0.0. Dac nu s-ar fi specificat mtile ruterul ar
fi stocat adresele reelelor sumarizate la nivel de clas. De exemplu R1 ar fi stocat reelele
192.168.80.0, 172.16.0.0 i 10.0.0.0. n aceast situaie reeaua 172.16.9.0/24 ar fi fost inclus
automat n reeaua EIGRP.
4.3.2 Propagarea rutei implicite

Se poate crea o rut implicit EIGRP folosind urmtoarea comand:
Router(config)#ip default-network retea
Ruterul pe care a fost configurat o rut implicit va include n anunul su aceast rut.
Ruterele din reea vor folosi ruterul next-hop ctre acea reea pentru a introduce n tabela de rutare
ruta implicit. De aceea reeaua destinaie trebuie s fie accesibil de pe ruterul iniial pentru ca s
poat fi anunat ctre celelalte rutere. De asemenea, destinaia trebuie sa fie cunoscut de
ruterele din reea pentru a putea fi stocat ruta implicit. n concluzie reeaua destinaie trebuie s
fie declarat n procesul EIGRP sau s existe o rut static redistribuit n EIGRP.
Mai multe rute implicite pot fi configurate, iar ruterele care primesc anunurile vor folosi
metrica EIGRP pentru a decide care este cea mai bun rut.
172.16.1.1
R1
172.16.1.2
R2
10.8.1.1
10.8.0.0/16
AS extern
Figura 4-3: Figura 4-4: Propagarea rutei implicite

Folosind topologia din figura 4-3, se va configura o rut implicit pe R2, i se va observa
propagarea ei pe ruterul R1. Configuraia care trebuie efectuat pe ruterul R2 este:
R2(config)#ip default-network 10.8.0.0
Folosind comanda ip default-network 10.8.0.0, pe ruterul R1 a fost configurat reeaua

10.8.0.0/16 ca fiind candidat pentru rolul de reea implicit. Comanda va genera n mod automat
urmtoarea rut static: ip route 10.8.0.0 255.255.0.0 10.8.1.1.
Dup cum se observ, reeaua extern 10.8.0.0/16 a fost declarat n procesul EIGRP, deci va fi
cunoscut de ctre ruterele din sistemul autonom 102.
Observm tabela de rutare pe ruterul R2:
R2#show
Gateway
C
S*
ip route
of last resort is not set
172.16.1.0/24 is directly connected, Ethernet0/0
10.8.0.0/16 [1/0] via 10.8.1.1
Ruta implicit este nvat prin EIGRP de ctre ruterul R1 care va avea urmtoarea tabel de
rutare:
R1#show
Gateway
C
D*
ip route
of last resort is 172.16.1.2 to network 10.8.0.0
172.16.1.0/24 is directly connected, Ethernet0/0
10.8.0.0/16 [90/10486122] via 172.16.1.2 00:00:10 Ethernet0/0
Se poate observa c n tabela de rutare se va instala o rut implicit ctre reeaua 10.8.0.0/16
care poate fi accesat de pe ruterul R1 prin adresa next-hop 172.16.1.2 care aparine ruterului R2.
4.3.3 Verificarea funcionrii EIGRP

Se va folosi topologia din figura 4-5.
69 | E I G R P
192.168.10.1/30
172.18.2.1
Fa0/0
R1
S0/1
S0/1
192.168.10.2/30
172.20.3.1
R2
Fa0/0
Figura 4-5: Verificarea funcionrii EIGRP

Configuraia de pe ruterul R1 este:
Iar configuraia de pe ruterul R2 este:

Tabela cu vecinii se poate poate vizualiza folosind urmtoarea comand:

R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 103
H Address
Interface
Hold Uptime
Seq
(sec)
0 192.168.10.2
Se0/1
12
00:10:20
SRTT
RTO
(ms)
17
2280
Cnt
0
Num
14
Coloanele tabelului au semnificaia urmtoare:

H este un numr folosit pentru a identifica vecinii, i a stoca ordinea n care au fost nvai;
Address este adresa IP a vecinului;
Interface este interfaa de pe ruterul local pe care poate fi accesat vecinul;
Hold este intervalul maxim n care ruterul ateapt un rspuns de la vecin pn s considere
legtura nevalid. Primirea unui pachet de tip Hello reseteaz acest interval;
Uptime este timpul scurs de la adugarea vecinului;
SRTT (smoothed round-trip time) este timpul mediu n care un pachet EIGRP ajunge la
vecin i un packet Ack este primit de ruterul local;
RTO (retransmission timeout) este intervalul de timp n care ruterul ateapt un pachet de
confirmare de la vecin pn s retransmit un pachet trimis n mod sigur;
Q Cnt (queue count) este numrul de pachete care se afl n coad ateptnd s fie trimise
vecinului. Dac numrul este mai mare dect 0, este posibil s fie o congestie;
Seq Num este numrul de secven a ultimului pachet de tip Update, Query sau Reply
primit de la vecin.
Tabela de rutare va fi inspectat folosind comanda show ip route:
R1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
D
D
C
C
D
172.20.0.0/16 [90/40514560] via 192.168.10.2, 00:07:09, Serial0/1

172.18.0.0/16 is variably subnetted, 2 subnets, 2 masks
172.18.0.0/16 is a summary, 00:05:31, Null0
172.18.2.0/24 is directly connected, FastEthernet0/0
192.168.10.0/24 is a summary, 00:05:31, Null0
Iar pentru a obine doar rutele EIGRP din tabela de rutare se folosete urmtoarea comand:
R1#show ip route eigrp
D
172.20.3.0/16 [90/40514560] via 192.168.10.2, 00:07:09, Serial0/1
D
172.18.0.0/16 is a summary, 00:05:31, Null0
D
192.168.10.0/24 is a summary, 00:05:31, Null0
EIGRP va introduce n tabela de rutare 3 tipuri de rute: interne, externe i sumarizate. Cele
interne vor fi reprezentate prin litera D, cele externe prin literele D EX.
Dup adresa reelei, ntre paranteze ptrate se afl doua numere. Primul numr reprezint
distana administrativ care pentru rute EIGRP interne este 90 i pentru rute EIGRP externe este
170. Al doilea numr reprezint metrica rutei care este egal cu distana viabil din tabela de
topologie.
Cmpul urmtor va specifica adresa ruterului next-hop ctre destinaia respectiv. Aceast
adres este egal cu adresa succesorului din tabela de topologie.
Urmeaz un cmp care reprezint timpul scurs de la ultimul anun despre acest rut. n EIGRP
rutele nu sunt trimise periodic, doar atunci cnd se schimb adiacenele.
Ultimul cmp este interfaa pe care pachetele pentru acea destinaie trebuie trimise. Rutele
sumarizate n mod automat au asociat interfaa Null0 care este o interfa software. Aceast
configuraie previne rutarea pachetelor destinate unor subreele care fac parte din ruta sumarizat,
dar care nu exist n realitate i nu exist rut specific pentru ele.
Comanda show ip protocols ofer informaii despre toate protocoalele de rutare dinamice
care ruleaz pe ruter:
Routing Protocol is "eigrp 103"
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 100
EIGRP NFS-aware route hold timer is 240s
Automatic network summarization is in effect
Automatic address summarization:
192.168.10.0/24 for Serial0/1
Summarizating with metric 40512000
172.18.0.0/16 for FastEthernet0/0
Summarizating with metric 28160
Maximum path: 4
172.18.2.0/24
192.168.10.0
Gateway
Distance
Last Update
(this router)
90
00:01:08
192.168.10.2
90
00:01:08
Distance: internal 90 external 170
Folosind comanda anterioar pot fi vizualizai parametri K, numrul de hopuri i variaia.

Ruterele trebuie s aib aceleai valori K pentru a putea stabili o adiacen.
Se poate observa c sumarizarea automat este activat i faptul ca ruterul poate face load
balancing pentru patru rute de cost egal.
71 | E I G R P
De asemenea, se poate determina pentru ce reele sunt rutate pachete. Dac atunci cnd a
fost introdus comanda network s-a specificat un wildcard mask, reeaua este reprezentat cu
prefix, altfel este stocat reeaua la nivel de clas.
Seciunea Routing Information Sources identific ruterele cu care s-a stabilit o adiacen,
incluznd i ruterul local.
Sunt precizate i distanele administrative pentru rutele EIGRP interne i externe.
Comanda show ip eigrp interfaces ofer informaii despre interfeele configurate
pentru EIGRP:
R1#show ip eigrp interfaces
IP-EIGRP interfaces for process 103
Int
Fa0/0
Se0/1
Peers
0
1
Xmit Queue
Un/Reliable
0/0
0/0
Mean
SRTT
0
10
Pacing Time
Un/Reliable
0/1
10/380
Multicast
Flow Timer
0
424
Pending
Routes
0
0

Interface este interfaa pe care este configurat EIGRP;
Peers este numarul de vecini direct conectai pe acea interfa;
Xmit Queue Un/Reliable este numrul de pachete aflate n cozile de transmisie;
Mean SRTT este valoarea medie a parametrului SRTT;
Pacing Time Un/Reliable este timpul folosit pentru a determina cnd trebuie trimis un
pachet;
Multicast Flow Timer este numrul maxim de secunde n care ruterul trimite pachete EIGRP
de tip multicast;
Pending Routes este numrul de rute folosite pentru pachetele care se afl n cozile de
transmisie.
Tabela de topologie poate fi vizualizat folosind comanda:
R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(103)/ID(192.168.10.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.10.0/30, 1 successors, FD is 40512000
via Connected, Serial0/1
via Summary (40512000/0), Null0
via Summary (40512000/0), Null0
via Connected, FastEthernet0/0
via 192.168.10.2 (40514560/28160), Serial0/1
Din comanda anterioar se poate observa c sistemul autonom este 103 iar identificatorul
ruterului R1 este 192.168.10.1. Identificatorul se alege dup urmtorul algoritm: dac exist adrese
configurate pe interfeele de loopback, se va alege cea mai mare adres, iar dac nu sunt
configurate adrese pe interfeele de loopback, se va alege cea mai mare adres dintre interfeele
configurate.
Prima coloan reprezint starea rutei respective, care poate fi:
P (Passive) reeaua este accesibil, ruta se poate instala n tabela de rutare;
A (Active) reeaua nu este accesibil, ruta nu poate fi instalat n tabela de rutare. Exist
pachete de tip Query trimise pentru aceast rut;
U (Update) ruterul a primit un pachet de tip Update cu aceast reea sau ruterul ateapt
un pachet Ack pentru un Update;
Q (Query) ruterul a trimis un pachet Query pentru aceast reea sau ruterul ateapt un
pachet Ack pentru un Query;
R (Reply status) ruterul genereaz un pachet Reply pentru acest reea sau ateapt un
packet Ack pentru un Reply;
S (Stuck-in-active status) ruta este n starea SIA. Exist probleme de convergen.
Pentru fiecare destinaie este indicat numrul de succesori, distana viabil (FD), adresa
ruterului next hop urmat de un set de dou numere reprezentnd distana viabil i distana
raportat.
Pentru a obine numrul de pachete EIGRP primite i trimise se folosete comanda:
R1# show ip eigrp traffic
IP-EIGRP Traffic Statistics for AS 103
Hellos sent/received: 218/205
Updates sent/received: 7/23
Queries sent/received: 2/0
Replies sent/received: 0/2
Acks sent/received: 21/14
Se observ c au fost trimise 218 pachete i au fost primite 205 pachete de tip Hello.
4.3.4 Configurarea sumarizrii

Dup cum s-a precizat n subcapitolul 4.2.1, protocolul EIGRP realizeaz sumarizarea la grania
clasei n mod implicit.
Revenind la figura 4-2, ruterul R4 are conectat reeaua 10.1.0.0/16 iar ruterul R3 are
conectat reeaua 10.2.0.0/16. Dac sumarizarea automat este activat, ruterul R4 va anuna
ruterul R3 c are o rut ctre reeaua 10.0.0.0/8, iar ruterul R3, pentru c se consider direct
conectat la 10.0.0.0/8, va ignora anunul. n aceast situaie trebuie dezactivat sumarizarea
automat.
Urmtoarea comand dezactiveaz sumarizarea automat pentru procesul EIGRP:
Router(config-router)#no auto-summary
Pentru a anuna c un anumit interval de adrese se poate accesa printr-o anumit interfa se
folosete comanda:
Router(config-if)#ip summary-address eigrp numar_AS adresa_IP masca
73 | E I G R P
10.4.0.0/16
10.5.0.0/16
192.168.2.0/24
172.16.1.0/16
R1
R3
S1/1
R4
172.16.2.0/16
10.6.0.0/16
R2
10.7.0.0/16
Figura 4-6: Sumarizare manual
Folosind topologia din figura 4-5, o exemplificare a sumarizrii manuale este urmtoarea:
R3(config)#interface s1/1
R3(config-if)#ip summary-address eigrp 103 10.4.0.0 255.255.252.0
Comanda anterioar determin ca reeaua 10.4.0.0/14 s fie accesibil de pe ruterul R4 prin

interfaa s1/1 a ruterului R3.
Pe ruterul R1 i R2 trebuie dezactivat sumarizarea automat:
4.3.5 Configurarea balansrii traficului

Procesul de load balancing a fost prezentat n subcapitolul 4.2.2. Pe un ruter se pot configura
numrul maxim de rute de cost egal i variaia metricii rutelor de cost diferit.
Configurarea numrului maxim de rute de cost egal care pot fi introduse n tabela de rutare se
face prin comanda urmtoare:
Router(config-router)#maximum-paths maxim
Aceast configuraie va duce la realizarea de load balancing pe rutele de cost egal din tabela de
rutare.
De exemplu, pentru a accepta 6 rute de cost egal, ruterul trebuie configurat n modul urmtor:
Router(config-router)#maximum-paths 6
Pentru a dezactiva load balancing se va preciza valoarea maxim ca fiind 1.

Gradul de echilibrare este stabilit prin urmtoarea comand:
Router(config-router)#variance multiplicator
Aceast configurare permite introducerea n tabela de rutare a rutelor cu metrica mai mic
dect valoarea obinut nmulind multiplicatorul cu metrica cea mai mic pentru acea destinaie.
Multiplicatorul poate lua o valoare ntre 1 si 128. Valoarea implicit este 1, ceea ce permite doar
load balancing pentru rutele de cost egal.
R2
10.8.2.0/24
R3
R1
R4
Figura 4-7: Load balancing cu costuri inegale
Considerm topologia din figura 4-6. Tabela de topologie conine urmtoarele rute ctre
destinaia 10.8.2.0/24:
Vecin
Distan viabil
Distan raportat
R2
30
15
R3
20
10
R4
40
30
Figura 4-8: Coninutul tabelei de topologie

Ruta succesor va trece prin R3 deoarece are cea mai mic distan viabil. Succesorul viabil este
R1, deoarece are distana raportat mai mic dect distana viabil a succesorului. R4 nu este un
succesor viabil.
Iniial doar ruta prin R2 este introdus n tabela de rutare. Pentru ca ruta prin R1 sa fie
introdus n tabela de rutare i ruterul sa fac load balancing ntre cele dou rute, trebuie s se
configureze o valoare a variaiei care, nmulit cu distana viabil a succesorului, s dea o valoare
mai mare dect distana viabil a rutei prin R1. Acest valoare este 2, deoarece 2 x 20 > 30. Ruta
prin R4 nu va putea fi introdus n tabela de rutare, chiar dac configurm variaia ca fiind 3,
deoarece R4 nu este un succesor viabil.
Se vor efectua urmtoarele configurri:
R1(config-router)#variance 2
4.3.6 Configurarea ruterului stub

Noiunea de ruter stub a fost definit n subcapitolul 4.2.5. Pentru a configura un ruter ca fiind
stub, se va folosi urmtoarea comand:
Router(config-router)#eigrp stub [receive-only | connected | static |
summary]
Pentru a configura un ruter stub s trimit rutele direct conectate se va folosi argumentul
connected. Aceast opiune este activat n mod implicit. Dac rutele direct conectate nu sunt
configurate prin comanda network, vor trebui redistribuite n EIGRP prin comanda redistribute
connected.
75 | E I G R P
Argumentul static poate fi folosit pentru a determina ruterul s trimit rutele statice care au
fost redistribuite n protocolul EIGRP prin comanda redistribute static.
Pentru ca un ruter stub s trimit rute sumarizate trebuie folosit argumentul summary. Vor fi
trimise att rutele sumarizate n mod automat, dar i cele sumarizate folosind comanda ip
summary-address.
Comanda eigrp stub folosit cu argumentul receive-only va mpiedica ruterul sa trimit orice
rut cunoscut ctre alt ruter din reea. Dac exist o singur interfa pe ruter, este recomandat
folosirea acestei comenzi, deoarece ruterul nu are alte rute dect cele primite pe legtura cu restul
reelei. Argumentul receive-only nu se poate folosi mpreun cu celelalte argumente.
172.16.2.0/24
172.16.4.0/24
R2
R1
172.16.3.0/24
Figura 4-9: EIGRP Stub

Considerm topologia din figura 4-7 i urmtoarea configuraie:
R2(config-if)#ip sumary-address eigrp 105 172.16.2.0 255.255.254.0
Se poate observa c reeaua 172.16.3.0/24 nu a fost specificat procesului EIGRP, dar este
creat o rut sumarizat care conine i reeaua respectiv.
Dac se va introduce comanda urmtoare, se va anuna ctre ruterul R1 doar reeaua
172.16.2.0/24, deoarece ea a fost specificat procesului EIGRP.
R2(config-router)#eigrp stub connected
Comanda urmtoare va determina ruterul R2 s nu trimit nici o rut, deoarece nu a fost

configurat i redistribuit nici o rut static.
R2(config-router)#eigrp stub static
Ruterul R2 va trimite o rut sumarizat 172.16.2.0/23 ctre R1:

R2(config-router)#eigrp stub summary
Comanda urmtoare va opri orice anun ctre ruterul R1:

R2(config-router)#eigrp stub receive-only
4.3.7 Configurarea autentificrii

Conceptele teoretice legate de autentificarea n cadrul protocolului EIGRP au fost prezentate n
subcapitolul 4.2.6. Pentru a configura autentificarea prin MD5 pentru EIGRP trebuie parcuri
urmtorii pai:
Pas 1. Intrarea n modul de configurare a interfeei pentru care se activeaz autentificarea.
Pas 2. Configurarea autentificrii prin MD5 pentru EIGRP.
Router(config-if)#ip authentication mode eigrp numar_AS md5
Pas 3. Specificarea lanului de chei folosit n autentificare
Router(config-if)#ip authentication key-chain eigrp numar_AS nume_lant
Pas 4. Intrarea n modul de configurare al cheilor.

Router(config)#key chain nume_lant
Pas 5. Specificarea identificatorului pentru cheie.

Router(config-keychain)#key identificator
Pas 6. Specificarea cheii (parolei).

Router(config-keychain-key)#key-string parola
Pas 7. Opional, se poate specifica o perioad de timp n care parola s fie valabil pentru
pachetele primite.
Router(config-keychain-key)#accept-lifetime timp_inceput [infinite |
timp_sfarsit | duration secunde]
Pas 8. Opional, se poate specifica o perioad de timp n care parola s fie folosit pentru
pachetele trimise.
Router(config-keychain-key)#send-lifetime timp_inceput [infinite |
timp_sfarsit | duration secunde]
S0/0
172.18.2.1
Fa0/0
R1
S0/0
192.168.10.2
172.20.3.1
R2
Fa0/0
Figura 4-10: Autentificare prin MD5

Considerm topologia din figura 4-8. Pachetele EIGRP ntre cele dou rutere trebuie s fie
criptate prin MD5.
Ruterul R1 trebuie configurat n modul urmtor:
R1(config)#key chain lant1
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string cheie1
R1(config-keychain-key)#accept-lifetime 00:00:00 Oct
R1(config-keychain-key)#send-lifetime 00:00:00 Oct 1
2009
1 2009 infinite
2009 00:10:00 Oct 1
1 2009 infinite
2009 infinite
R1(config-if)#ip authentication mode eigrp 106 md5
R1(config-if)#ip authentication key-chain eigrp 106 lant1
Ruterul R1 va accepta pachetele EIGRP cu identificatorul cheii egal cu 1 sau cu 2 i le va verifica

valoarea MD5. Orice alte pachete vor fi ignorate. De asemenea ruterul R1 va trimite pachete
77 | E I G R P
folosind cheia 1 timp de 10 minute n intervalul specificat, iar dup expirarea intervalului pentru
cheia 1, va folosi exclusiv cheia 2.
Ruterul R2 trebuie configurat n modul urmtor:
1 2009 infinite
2009 infinite
1 2009 infinite
2009 infinite
R2(config-if)#ip authentication mode eigrp 106 md5
R2(config-if)#ip authentication key-chain eigrp 106 lant2
Ruterul R1 va accepta pachetele EIGRP cu identificatorul cheii egal cu 1 sau cu 2 i le va verifica

valoarea MD5. Orice alte pachete vor fi ignorate. De asemenea ruterul R1 va trimite pachete
folosind doar cheia 1 pentru c este prima n list i nu poate expira, prin urmare, cheia 2 nu va fi
folosit niciodata pentru a trimite pachete.
n cazul n care cheile nu se potrivesc, nu se poate forma o adiacen ntre cei doi vecini.
Pentru a verifica dac s-a format o adiacen se verific tabela cu vecini:
H Address
Interface
Hold Uptime
Seq
(sec)
Num
0 192.168.10.2
Se0/0
12
00:10:20
SRTT
RTO
(ms)
17
Q
Cnt
2280
14
De asemenea, atunci cnd s-a format o nou adiacen se va afia mesajul:

R1#
*Oct 1 00:00:59.503 GMT: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 106: Neighbor
192.168.10.2 (Serial0/0) is up: new adjacency
Pentru depanarea autentificrii prin MD5 se poate folosi comanda debug eigrp packets,
care va afia informaii legate de pachetele EIGRP primite i trimise:
R2#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB,
SIAQUERY,SIAREPLY)
R2#
*Oct 1 16:38:38.321: EIGRP: received packet with MD5 authentication,
key id = 2
*Oct 1 16:38:38.321: EIGRP: Received HELLO on Serial0/0 nbr
192.168.10.2
*Oct 1 16:38:38.321:
AS 106, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0 peerQ un/rely 0/0
Se observ c ruterul R2 primete de la R1 pachete EIGRP cu autentificare prin MD5, cu un

identificator de cheie 2, iar autentificarea are loc cu succes.
Se fac urmtoarele configurri pe ruterul R2:
R2(config-keychain-key)#key-string altacheie
Se observ c autentificarea pachetelor primite de la ruterul R1 nu mai poate avea loc deoarece
ruterul R1 va trimite identificatorul de cheie 2 (cheia 1 a expirat dup primele 10 minute), dar
parolele configurate pe cele dou rutere sunt diferite:
R2#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB,
SIAQUERY, SIAREPLY)
R2#
*Oct 1 16:50:18.749: EIGRP: pkt key id = 2, authentication mismatch
*Oct 1 16:50:18.749: EIGRP: Serial0/0: ignored packet from
192.168.10.1, opcode = 5 (invalid authentication)
*Oct 1 16:50:18.749: EIGRP: Dropping peer, invalid authentication
*Oct 1 16:50:18.749: EIGRP: Sending HELLO on Serial0/0
*Oct 1 16:50:18.749:
AS 106, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0
*Oct 1 16:50:18.753: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 106: Neighbor
192.168.10.1 (Serial0/0) is down: Auth failure
ntre cele dou rutere nu se mai poate stabili o adiacen:

4.4 Studiu de caz

Pentru a evidenia modul de configurare EIGRP, se propune urmtorul scenariu. Compania
AgiliCat urmeaz s conecteze toate sediile deinute. Pentru infrastructura de reea, o cerin
crucial este timpul de raspuns foarte mic i convergena ct mai rapid a protocolului de rutare n
cazul apariiei unor probleme.
tiind c protocolul EIGRP, n cazul unei implementri eficiente, poate rspunde instant la
modificri aprute n topologie, s-a luat decizia de a-l folosi n reeaua companiei. n implementarea
soluiei se va urmri n primul rnd micorarea timpului de rspuns la modificri ale reelei, precum
i optimizarea informaiei din tabelele de rutare, prin manipularea rutelor. n figura 4-9 este
prezentat topologia peste care va trebui s ruleze protocolul.
Bucureti
ISP
E1/0
10.10.0.4/30
E3/0
E3/2
10.10.0.12/30
10.10.0.8/30
E3/0
Iai
Fa1/0
Fa0/0
10.10.0.0/30
Fa0/0
E3/2
Fa1/0
E1/0
Arad
Deva
10.10.0.20/30
141.23.17.128/26
141.23.17.0/25
141.23.17.192/26
Figura 4-11: Topologia reelei companiei AgiliCat
79 | E I G R P

Ruterele fac parte din acelai sistem autonom: 24012. Compania are alocat spaiul de adrese
141.23.17.0/24, subnetat precum se vede n schema topologiei. Pentru legturile dintre rutere se
folosete spaiul de adrese 10.10.0.0/24. Ruterul ISP nu aparine companiei, el fiind folosit pentru
redistribuirea informaiilor EIGRP n protocolul folosit n interiorul ISP i nu prezint interes din
punct de vedere al configurrii. Configuraia IP a interfeelor este prezentat mai jos:
ISP#show ip interface brief | include up
FastEthernet0/0
10.10.0.1
Ethernet1/0
10.10.0.5
YES manual up
YES manual up
up
up
Bucuresti#show ip interface brief | include up

Ethernet1/0
10.10.0.6
YES manual up
Ethernet3/0
10.10.0.13
YES manual up
Ethernet3/2
10.10.0.9
YES manual up
up
up
up
Arad#show ip interface brief | include up

Ethernet0/0
10.10.0.10
FastEthernet1/0
10.10.0.21
Loopback0
141.23.17.1
YES manual up
YES manual up
YES manual up
up
up
up
Iasi#show ip interface brief | include up

FastEthernet1/0
10.10.0.22
Ethernet3/0
10.10.0.14
Loopback0
141.23.17.129
YES manual up
YES manual up
YES manual up
up
up
up
Deva#show ip interface brief | include up

FastEthernet0/0
10.10.0.2
Loopback0
141.23.17.193
YES manual up
YES manual up
up
up
Se activeaz procesul EIGRP 24012 pe toate ruterele. Se dezactiveaz sumarizarea automat pe

care o face protocolul. Pe routerul ISP se genereaz o rut default ce va fi apoi transmis celorlalte
rutere. Se foloseste Null0 ca interfa de ieire pentru a simula o legtur la Internet. Pachetele ce
merg pe ruta default vor fi de fapt aruncate.
ISP(config)#ip route 0.0.0.0 0.0.0.0 null0
ISP(config)#router eigrp 24012
ISP(config-router)#network 10.10.0.0 0.0.0.3
ISP(config-router)#network 10.10.0.4 0.0.0.3
ISP(config-router)#no auto-summary
ISP(config-router)#redistribute static
Bucuresti(config)#router eigrp 24012
Bucuresti(config-router)#network 10.10.0.8 0.0.0.3
Bucuresti(config-router)#no auto-summary
Arad(config)#router eigrp 24012
Arad(config-router)#network 10.10.0.8 0.0.0.3
Arad(config-router)#no auto-summary
Iasi(config)#router eigrp 24012
Iasi(config-router)#network 10.10.0.20 0.0.0.3
Iasi(config-router)#no auto-summary
Deva(config)#router eigrp 24012
Deve(config-router)#network 10.10.0.0 0.0.0.3
Deva(config-router)#network 141.23.17.192 0.0.0.63
Deva(config-router)#no auto-summary
Pentru a verifica funcionarea corect a protocolului de rutare, se pot verifica foarte rapid
adiacenele care s-au format ntre vecini:
Iasi#show ip eigrp neighbors
H
Address
Interface
1
0
10.10.0.13
10.10.0.21
Et3/0
Fa1/0
Hold Uptime
SRTT
(sec)
(ms)
14 00:07:37 404
10 00:07:50 320
RTO
Q
Cnt
2424 0
1920 0
Seq
Num
29
25
Se observ din output-ul de mai sus c routerul Iai a stabilit adiacene EIGRP cu vecinii si,
Bucureti i Arad. Verificarea se poate continua asemntor pentru toate routerele.
Dup ce s-a constatat c procesul a fost pornit cu succes pe toate echipamentele, trebuie
inspectat tabela de rutare pentru a vedea dac toate rutele care ne ateptm s existe au fost
propagate.
Bucuresti#sh ip route
141.23.17.128/26 [90/409600] via 10.10.0.14, 00:00:24, Ethernet3/0
141.23.17.192/26 [90/412160] via 10.10.0.5, 00:00:12, Ethernet1/0
141.23.17.0/25 [90/409600] via 10.10.0.10, 00:01:05, Ethernet3/2
D
10.10.0.0 [90/284160] via 10.10.0.5, 00:00:12, Ethernet1/0
C
10.10.0.4 is directly connected, Ethernet1/0
C
C
D
10.10.0.20 [90/284160] via 10.10.0.14, 00:00:12, Ethernet3/0
[90/284160] via 10.10.0.10, 00:00:12, Ethernet3/2
D*EX 0.0.0.0/0 [170/281600] via 10.10.0.5, 00:00:04, Ethernet1/0
D
D
D
Rutarea fiind asigurat, este momentul s ne punem problema optimizrii timpilor de

convergen a reelei.
4.4.2 Optimizarea timpilor de convergen folosind DUAL

Protocolul EIGRP permite reinerea n tabela de topologie a unor rute de rezerv, denumite
rute viabile, ce vor promova n tabela de rutare automat, cnd nici un ruter succesor nu mai este
accesibil. Aceste rute vor folosi ca urmtor hop rutere denumite succesori viabili (Feasible Successor
- FS).
Trebuie s manipulm metrica anumitor rute astfel nct s respecte condiia de FS. Astfel,
pentru ruterul Bucureti trebuie ca interfaa Loopback de pe Iai s fie cunoscut direct via Ethernet
3/0 i, ca rut de rezerv, prin ruterul Arad, via Ethernet 3/2.
Pentru ruterul Iai trebuie garantat ieirea ctre ISP prin Arad n eventualitatea n care ruta
direct prin Bucureti nu mai este accesibil.
Vom analiza n primul rnd tabela de topologie EIGRP pentru ruterul Bucureti, pentru a vedea
care este starea rutelor ce ne intereseaz.
Bucuresti#sh ip eigrp topology
[...]
via 10.10.0.14 (409600/128256), Ethernet3/0
via 10.10.0.10 (412160/156160), Ethernet3/2
81 | E I G R P
Se pot face o serie de observaii privind rezultatul acestei comenzi. n primul rnd, ruta este
marcat ca P(assive), ceea ce nseamn c este stabil, nu se face n acest moment o recalculare a
sa i c a fost propus spre promovare ctre tabela de rutare.
Se precizeaz apoi c fiecare rut are un succesor, asta nseamn c un singur router este
folosit n acest moment pentru trimiterea mai departe a pachetelor.
Totui, sunt precizate dou rute ctre reeaua 141.23.17.64. Una dintre ele, cea de cost total
mai mic (40960) este ruta direct de la Bucureti la Iai, a doua fiind ruta de rezerv prin Arad.
Faptul c aceast rut de rezerv apare n tabela de topologie nseamn c ea va fi folosit n cazul
n care ruta mai bun nu mai este accesibil. Se observ c este respectat regula de alegere a FS,
costul total al celei mai bune rute fiind mai mare dect distana raportat de primul vecin pe ruta de
rezerv (409600 > 156160).
Se poate trage de aici concluzia c ruterul Bucureti are deja o rut de rezerv ctre reeaua
141.23.17.64/26.
Se pune acum aceeai problem pentru ruta default de pe routerul Iai. Se va analiza tabela de
topologie EIGRP pentru a vedea dac ruta prin Arad a fost promovat ca rut de rezerv.
Iasi#show ip eigrp topology
via 10.10.0.13 (307200/281600), Ethernet3/0
Se observ c ruta prin Arad nu ndeplinete constrngerea de metric pentru a putea fi

promovat ca rut de rezerv. n acest caz, va trebui alterat metrica rutelor pentru a ndeplini
condiia.
Cea mai simpl metod de a face acest lucru este creterea costului rutei directe ctre
Bucureti, astfel nct noua metric a acestei rute s fie mai mare dect metrica raportat de Arad.
Pentru a crete costul rutei ctre Bucureti, o metod rapid este declararea unei limi de band
mai mic pe interfaa dintre Iai i Bucureti, ceea ce va aduce o penalizare de cost rutei directe
ctre Bucureti.
Iasi(config)#interface ethernet 3/0
Iasi(config-if)#bandwidth 9900
n acest moment, a fost declarat o lime de band de doar 9.9Mb/s pe legtura de 10Mb/s
Eth3/0. Doar limea de band declarat a fost modificat, traficul pe interfa nefiind limitat n nici
un fel la 9Mb/s.
Trebuie vzut acum rezultatul n tabela de topologie pe care l-a avut configuraia fcut.
Iasi#show ip eigrp topology
Iasi#sh ip eigrp topology
via 10.10.0.13 (309760/281600), Ethernet3/0
via 10.10.0.21 (309760/307200), FastEthernet1/0
Se observ c noua metric a legturii directe ctre Bucureti este egal cu metrica prin Arad.
n acest moment, routerul Iai are doi succesori ctre 0.0.0.0/0 i va putea face balansare pe cele
dou ci. Dac nu ne dorim acest comportament, se poate crete la 9901kb/s limea de band pe
interfa pentru ca ruta folosit s fie cea prin Bucureti i cea prin Arad s fie de rezerv, sau se
poate declara o lime de band de 8999kb/s pentru ca ruta prin Arad s fie cea principal.
4.4.3 Optimizarea timpilor de convergen folosind reele Stub

n cazul n care o reea nu mai este accesibil i nu exist rut de rezerv, procesul EIGRP
plaseaz ruta respectiv n starea Active i caut o alt cale de a ajunge la reea. Aceast cutare se
face trimind vecinilor si pachete prin care acetia sunt interogai cu privire la o eventual rut
alternativ ctre reeaua n cauz.
Totui, pentru o anumit categorie de rutere, rspunsul la aceste interogri va fi tot timpul c
nu dispun de o cale alternativ. Acestea sunt routerele Stub, exemplu fiind routerul Deva din
topologie. Aceste rutere sunt identificabile prin faptul c au un singur vecin cu care schimb
informaii de rutare, n cazul de fa informaii EIGRP.
Pentru a nu se mai consuma timp i resurse interognd acest router, el poate fi declarat ca
Stub, ca n exemplul urmtor:
Deva(config)#router eigrp 24012
Deva(config-router)#eigrp stub connected summary
Opiunile de connected i summary permit routerului Stub s trimit vecinilor si informaii

despre reelele direct conectate i s sumarizeze reele (fie manual, fie automat).
Pentru a vedea rezultatul comenzii date anterior, pe routerul local se folosete comanda:
Deva#show ip protocols
Routing Protocol is "eigrp 24012"
[...]
EIGRP stub, connected, summary
Pe vecinul routerului Deva, ISP, acest lucru este vizibil inspectnd vecinii EIGRP:
ISP#show ip eigrp neighbors detail
H
Address
Interface
0
Hold Uptime
SRTT
(sec)
(ms)
10.10.0.2
Fa1/0
10 00:10:10 128
Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 2
Stub Peer Advertising ( CONNECTED SUMMARY ) Routes
Suppressing queries
RTO
Q Seq
Cnt Num
768 0 90
Se observ c ISP are activat opiunea de suppressing queries (nu se trimit interogri) ctre
ruterul Deva.
4.4.4 Minimizarea dimensiunii tabelei de rutare

Urmtoarea discuie pleac de la tabela de rutare a routerului ISP.
ISP#show ip route
141.23.17.128/26 [90/435200] via 10.10.0.6, 00:31:35, Ethernet1/0
141.23.17.192/26 [90/156160] via 10.10.0.2, 00:10:12, FastEthernet0/0
141.23.17.0/25 [90/435200] via 10.10.0.6, 01:51:21, Ethernet1/0
C
10.10.0.0 is directly connected, FastEthernet0/0
C
D
10.10.0.8 [90/307200] via 10.10.0.6, 03:35:03, Ethernet1/0
D
10.10.0.12 [90/307200] via 10.10.0.6, 03:07:54, Ethernet1/0
D
10.10.0.20 [90/309760] via 10.10.0.6, 03:37:11, Ethernet1/0
S* 0.0.0.0/0 is directly connected, Null0
D
D
D
83 | E I G R P
Dac reelele din 10.0.0.0/8 fac parte dintr-un spaiu privat de adrese i vor fi filtrate pentru a
nu ajunge in Internet, nu la fel stau lucrurile cu reelele din 141.23.0.0/16. Rutele ctre aceste reele
urmnd s fie trimise mai departe ctre vecini, trebuie avut grij ca ele s fie sumarizate ct mai
atent, pentru a micora dimensiunea tabelei de rutare.
Sumarizarea poate introduce ns probleme la rndul ei, dac ruterul ce face sumarizarea nu
are rute ctre toate prile componente ale supranetului.
De exemplu, pentru topologia de fa, rutele ctre 141.23.17.0/25 i 141.23.17.128/26 pot fi
sumarizate pe ruterul Bucureti la 141.23.17.0/24. Acest lucru se realizeaz ca n exemplul urmtor:
Bucuresti(config)#interface ethernet 1/0
Bucuresti(config-if)#ip summary-address eigrp 24012 141.23.17.0
255.255.255.0
Comanda de sumarizare este dat n modul interfa, reeaua sumarizat fiind trimis doar
vecinului/vecinilor de pe interfaa respectiv. n acest moment, tabela de rutare a routerului
Bucureti s-a modificat astfel:
Bucuresti#show ip route
141.23.17.128/26 [90/409600] via 10.10.0.14, 00:57:52, Ethernet3/0
141.23.17.192/26 [90/412160] via 10.10.0.5, 00:59:12, Ethernet1/0
141.23.17.0/25 [90/409600] via 10.10.0.10, 00:59:12, Ethernet3/2
141.23.17.0/24 is a summary, 00:01:27, Null0
D
10.10.0.0 [90/284160] via 10.10.0.5, 00:59:12, Ethernet1/0
C
C
C
D
10.10.0.20 [90/284160] via 10.10.0.14, 00:57:54, Ethernet3/0
[90/284160] via 10.10.0.10, 00:57:54, Ethernet3/2
D*EX 0.0.0.0/0 [170/281600] via 10.10.0.5, 00:59:12, Ethernet1/0
D
D
D
D
n tabela de rutare a aprut o rut ctre 141.23.17.0/24 ce are ca urmtor hop Null0, adic
pachetele vor fi aruncate.
Totui, acest lucru nu se ntmpl datorit faptului c tabela de rutare este sortat descresctor
dup dimensiunea mtii. Astfel, se observ c cele 3 rute reale ctre reelele din 141.23.17.0/24
vor fi verificate nainte de ruta sumarizat i pachetele vor fi rutate corect de ctre Bucureti.
Rutele ctre toate reelele din tabela de rutare care sunt incluse n supra-reea sunt nlocuite cu
ruta care duce ctre Null0. Astfel, Bucureti nu va mai trimite ctre ISP rute ctre 141.23.17.0/25
sau 141.23.17.128/26, ci doar ctre 141.23.17.0/24. Tabela de rutare a lui ISP va arta astfel:
ISP#show ip route
141.23.17.0/24 [90/435200] via 10.10.0.6, 00:17:44, Ethernet1/0
C
C
D
10.10.0.8 [90/307200] via 10.10.0.6, 04:17:40, Ethernet1/0
D
10.10.0.12 [90/307200] via 10.10.0.6, 03:50:31, Ethernet1/0
D
10.10.0.20 [90/309760] via 10.10.0.6, 04:19:48, Ethernet1/0
S* 0.0.0.0/0 is directly connected, Null0
D
D
5 OSP F
5.1 Prezentarea protocolului

5.1.1 Link state vs. distance vector
Prima soluie de rutare dinamic standardizat de IETF a fost protocolul RIP. Chiar i prin
optimizrile aduse de versiunea a doua, limitrile de scalabilitate au determinat cutarea unei
soluii adecvate reelelor de mari dimensiuni. O soluie eficient n termeni de consum de band i
timp de convergen trebuia s se ndeprteze de la paradigma protocoalelor bazate pe vectori de
distan.
OSPF este un protocol bazat pe starea conexiunilor (link-state), standardizat de IETF la
nceputul anilor `90. Acesta este un protocol open standard: OSPF v.1 a fost definit n 1995 prin RFC
1850, modificat apoi n OSPF v.2 prin RFC 2328 (1998), iar n anul 2008 RFC 5340 a actualizat
protocolul la versiunea 3, introducnd schimbri semnificative pentru adaptarea la IPv6.
Caracteristicile importante ce recomand OSPF n faa RIP in de diferenele tradiionale dintre
protocoalele distance vector i cele link-state. Astfel, dei RIP poate oferi soluii eficiente de rutare
pentru reele de mici dimensiuni, creterea complexitii reelei se traduce n penaliti nsemnate
asupra timpului de convergen. OSPF ofer un timp de convergen de ordinul secundelor, cel mai
adesea cu dou ordine de mrime mai mic dect cel oferit de RIP.
Funcionalitatea RIP n reelele mari i eterogene este afectat de limitarea capacitii sale de
rutare la ci de maximum 15 hopuri, orice destinaie mai ndeprtat fiind considerat inaccesibil.
n schimb protocolul OSPF nu prezint aceast limitare.
De asemenea, RIP v.1 nu este compatibil cu Variable Length Subnet Masks (VLSM), spre
deosebire de OSPF, care permite adresarea VLSM i CIDR (Classless Inter-Domain Routing). OSPF va
trimite n actualizri i masca de reea, pe lng reeaua destinaie.
n cazul OSPF, dup stabilirea adiacenei cu vecinii i schimbarea informaiilor de rutare,
actualizrile pentru protocoalele link-state se fac incremental, preciznd doar schimbrile aprute,
spre deosebire de protocoalele distance vector ce vor trimite informaii complete de rutare vecinilor
la fiecare actualizare. Transmiterea periodic a tabelei de rutare n ntreaga reea conduce la o
convergen lent. n plus, ntr-o reea stabil, consumul de band pentru schimbarea informaiilor
de rutare este mult mai sczut pentru OSPF, actualizrile fiind trimise doar n cazul unor schimbri
de topologie, i nu la intervale fixe de timp, precum n cazul RIP.
Protocoalele distance vector sunt vulnerabile n cazul modificrilor din reea, deoarece n
timpul n care se realizeaz convergena crete probabilitatea unor rutri suboptimale sau a unor
bucle infinite. Intervalul cel mai vulnerabil pentru OSPF este perioada iniial de descoperire a
reelei, n care actualizrile LSA pot ocupa o proporie considerabil a limii de band. n ansamblu,
ns, OSPF este mult mai stabil n faa schimbrilor de topologie, datorit faptului c fiecare ruter
are o imagine de ansamblu a reelei i ruteaz pachetele independent, conform propriilor decizii.
Principalul avantaj al protocoalelor distance vector l reprezint complexitatea redus a
configurrii i ntreinerii unei astfel de soluii. n plus, cerinele hardware n termeni de memorie i
timp de procesare sunt semnificativ mai reduse pentru un protocol de tip distance vector.
O alt limitare a protocoalelor bazate pe vectori distan const n faptul c ruterele nu au o
imagine de ansamblu asupra topologiei reelei, deoarece proceseaz doar informaiile coninute n
tabelele de rutare ale vecinilor direct conectai. Ruterele care ruleaz OSPF obin o imagine
complet asupra reelei, denumit n continuare tabela de topologie, dat fiind c acumuleaz
informaii de topologie de la toate celelalte rutere.
Deoarece ruterul care ruleaz OSPF dispune de o reprezentare complet a topologiei reelei, va
selecta cea mai bun rut conform unui algoritm Dijkstra Shortest Path First (SPF). Rutele sunt
ierarhizate conform costului (metricii) acestora, fiind selectat ruta cu costul cel mai redus. Implicit,
costul unei interfee este calculat ca fiind invers proporional cu limea de band a acesteia; n
acest caz, este folosit valoarea declarat a limii de band, nu valoarea real. Totui, este posibil
ca metrica reelei s fie setat explicit la o valoare anume, ceea ce permite optimizarea deciziilor
ruterului n funcie de situaia real a reelei. Desigur, este posibil ca ruta cu cel mai mic numr de
hopuri, care ar fi fost selectat de un protocol distance vector, s aib un cost mai mare dect o rut
mai lung dar care traverseaz legturi cu lime de band mai mare.
Un alt avantaj al OSPF fa de RIP este prevenirea buclelor de trafic. Acestea pot aprea atunci
cnd modificrile din topologia reelei se propag lent. De exemplu, un ruter neinformat de eecul
unui segment din reea poate trimite pachetele pe o cale ce nu mai este valabil, n timp ce ruterul
urmtor de pe aceast cale le va trimite napoi, fiind informat despre schimbare, pentru a ajunge la
destinaie pe o alt cale. Bucla de trafic poate disprea fie dac primul ruter ajunge la o
reprezentare adecvat a cilor spre destinaie, fie dac sunt implementate mecanisme adiionale
pentru a preveni, detecta i elimina buclele de trafic. n cazul OSPF, propagarea rapid a
informaiilor privind modificrile din topologia reelei previne apariia unor astfel de situaii, astfel
nct rutele calculate de OSPF nu conin bucle de trafic.
Reelele RIP sunt plate deoarece nu exist conceptul de zone, n timp ce OSPF suporta att
implementri plate: single-area (SA), ct i implementri ierarhice: multi-area (MA) permitnd
mprirea logic n zone pentru a limita inundarea ntregii reele cu actualizri atunci cnd se
modific topologia.
OSPF funcioneaz diferit n funcie de tipul de reea, definit ca fiind unul dintre urmtoarele
trei: reele punct-la-punct, reele multiacces broadcast, precum Ethernet, i reele multiacces fr
capacitate de broadcast, precum Frame Relay sau ATM. Toate reelele multiacces au ca trstur
comun necesitatea alegerii unui ruter responsabil cu actualizrile (un DR i un BDR, conform
procesului descris n continuare).
Performanele OSPF n ceea ce privete convergena i latena sunt datorate caracteristicilor
cheie precum independena deciziilor ruterelor i organizarea ierarhic a reelei. n continuare va fi
87 | O S P F
analizat funcionarea OSPF i rolul acestor trsturi, pornind de la etapa iniial a formrii relaiilor
de adiacen, pn la selectarea rutelor optime i actualizarea informaiilor de rutare.
5.1.2 Funcionarea protocolului

Funcionarea procesului OSPF pe un ruter se desfoar n cinci etape:
1. identificarea vecinilor ruterului i stabilirea relaiilor de adiacen;
2. n cazul reelelor multiacces: selectarea unui ruter responsabil de actualizri i a unui ruter
de backup;
3. descoperirea rutelor;
4. selectarea rutelor optime ctre destinaie;
5. actualizarea informaiilor de rutare.
nainte de a face schimb de informaii, dou rutere vecine trebuie s se identifice i s
stabileasc o relaie de adiacen. Acest proces are loc cu ajutorul pachetelor de tip Hello, prin care
se stabilesc i se menin relaii bidirecionale. O relaie bidirecional cu un anumit vecin este
stabilit n momentul n care un ruter se recunoate pe sine n lista vecinilor din pachetul Hello
primit de la acel vecin.
Un pachet Hello conine urmtoarele informaii: identificatorul ruterului, intervalele Hello i
Dead, lista vecinilor, identificatorul zonei, prioritatea ruterului, adrese IP ale ruterelor DR si BDR,
informaia de autentificare i marcajul de zon stub.
Fiecare ruter are un identificator OSPF, constnd dintr-un numr de 32 de bii, exprimat n
general n forma zecimal specific adreselor IP. Alegerea OSPF_ID se va face la iniializarea
procesului OSPF. Acest identificator poate fi configurat explicit. Dac nu exist o astfel de setare,
identificatorul OSPF va fi cea mai mare adres IP a interfeelor de loopback; dac nu exist nici
interfee de loopback configurate, valoarea OSPF_ID va fi iniializat cu valoarea celei mai mari
adrese IP dintre adresele interfeelor active. Acest identificator este folosit att la stabilirea
relaiilor bidirecionale, ct i n schimbul de mesaje de actualizare.
Starea Down
192.168.10.1
R1
192.168.10.2
S0/0
S0/1
R2
Starea Init
R1
multicast 224.0.0.5
Hello
Sunt ruterul cu ID 192.168.10.1
R2
Starea 2-Way
R1
unicast 192.168.0.1
Hello
Sunt ruterul cu ID 192.168.10.2 i am vecinul 192.168.10.1
R2
Figura 5-1: Stabilirea comunicaiei bidirecionale

Odat cu pornirea unui proces OSPF pe un ruter, acesta trece din starea Down n starea Init,
trimind pachete Hello ctre vecini. Spre deosebire de protocoalele distance vector care folosesc
pachete de broadcast, OSPF iniiaz procesul de identificare a vecinilor folosind adresa multicast
specific 224.0.0.5. Configuraia implicit n reelele Ethernet presupune trimiterea de mesaje Hello
ctre ruterele vecine la fiecare 10 secunde (intervalul Hello). Ruterele vecine ce ruleaz OSPF vor
aduga ruterul care a iniiat comunicaia n tabela de vecini i i vor rspunde cu un pachet Hello, de
tip unicast. Dup cum se observ n figura 5-1, adresa IP a ruterului care a iniiat procesul de
adiacen este inclus de altfel n pachetul Hello de rspuns, pentru a confirma validitatea
schimbului de mesaje. n momentul recepionrii rspunsului ruterul trece n starea 2-Way. n
aceast stare, ruterul completeaz o tabel de adiacen cu informaii privind toi vecinii cu care au
stabilit o legtur bidirecional.
n reelele multiacces precum Ethernet, Frame-Relay sau ATM, urmeaz etapa de selectare a
ruterului desemnat pentru actualizri (DR Designated Router) i a ruterului de backup (Backup
Designated Router BDR). Cele dou rutere au rolul de a media schimbul informaiilor de
actualizare. Mai precis, toate actualizrile sunt trimise doar ctre DR i BDR, nu i ctre restul
ruterelor din reeaua multiacces. Dac informaia din pachetul de actualizare este nou, DR va
propaga mesajul ctre toate ruterele. Rolul BDR este de a pstra adiacene cu toate ruterele din
reea (ca i DR), i de a prelua rolul de DR dac acesta din urm devine inactiv.
DR i BDR sunt selectate pe baza prioritii OSPF atribuite ruterului. Prioritatea unui ruter de a
deveni DR se stabilete la nivel de interfa, putnd fi configurat ntre 0 i 255. Prioritatea implicit
este 1, iar valorile mai mari sunt preferate n selecie. Prioritatea 0 indic faptul c ruterul nu este
eligibil pentru a deveni DR sau BDR. Dac ruterele au aceeai prioritate, de exemplu valoarea 1, va fi
ales ca DR ruterul cu cel mai mare OSPF_ID. Ruterul BDR este cel cu urmtoarea valoare n ordine
descresctoare. Alegerea DR este nepreemptiv: dac un ruter cu o prioritate mai mare sau cu o
valoare mai mare a OSPF_ID devine activ dup ce un alt DR a fost ales deja, alegerea rmne stabil
pn n momentul n care DR devine inactiv. n aceast situaie BDR promoveaz i se reface
alegerea pentru un nou ruter de backup. Este de asemenea important de observat c statutul de DR
i BDR se refer de fapt la interfaa unui ruter, nu la ruterul propriu-zis (un ruter poate fi DR pe un
segment de retea, BDR pe un altul, si poate sa nu aiba nici unul dintre aceste roluri pe alte
segmente multiacces direct conectate).
192.168.10.1
R1
192.168.10.2
S0/0
S0/1
R2
Starea Exstart
R1
DBD
Eu sunt master pentru c am ID 192.168.10.1
R2
DBD
R1
Eu sunt master pentru c am ID mai mare
R2
Starea Exchange
DBD
R1
R1
Rezumatul tabelei mele de topologie

DBD
Rezumatul tabelei mele de topologie
R2
R2
89 | O S P F
Figura 5-2: Descoperirea rutelor
Dup ce a fost finalizat alegerea ruterului desemnat, procesul OSPF intr n starea Ex-start
(Exchange Start) i iniiaz relaia de comunicare cu DR i BDR, relaia avnd o structur asimetric
de master-slave. Aceast ierarhie este necesar pentru a stabili iniiatorul comunicrii (master), cel
care va incrementa numrul de secven al pachetelor de actualizare. Ruterul master este cel cu cea
mai mare adres IP; acesta poate fi ruterul DR dar i un alt ruter, deoarece este posibil ca DR s fi
fost selectat pe baza prioritii, de exemplu, i s aib o adres IP mai mic, ajungnd n ipostaza de
slave n relaia cu unul dintre vecini.
Dup cum se observ n figura 5-2, odat stabilite rolurile n comunicare, ruterele adiacente
schimb pachete Database Description (DBD) n starea Exchange, trimind astfel informaii
condensate privind starea tabelei de topologie a fiecruia. Ruterul master va incrementa numrul
de secven a pachetelor DBD pe msur ce sunt trimise, permind detectarea schimbrilor
recente n informaiile privind topologia reelei. Dac un ruter observ, pe baza informaiilor din
pachetele DBD, c tabela sa conine date ce nu mai sunt de actualitate, solicit primirea pachetelor
de update (LSU), ca n figura 5-3. Ruterul intr apoi n starea Loading, de schimb de informaii
privind starea legturilor din reea. Odat ce tabelele de topologie sunt sincronizate, ruterele ajung
n starea Full de adiacen deplin. n cazul reelelor Ethernet, starea Full se realizeaz doar n
relaia dintre un ruter i vecinii DR i BDR respectivi. Toate celelalte relaii de vecintate vor fi
conservate n starea 2-Way.
192.168.10.1
R1
192.168.10.2
E0
E1
R2
LSAck
R1
Confirmarea pachetelor
R2
Starea Loading
LSR
R1
Am nevoie de o informaie complet despre reeaua 192.168.11.0/24
R2
LSU
R1
R1
Informaia complet despre 192.168.11.0/24

LSAck
Confirmarea actualizrii
Starea Full
Figura 5-3: Descoperirea rutelor
R2
R2
Stare
Down
Init
2-Way
Ex-start
Exchange
Loading
Full
Aciuni caracteristice
Ruterul nu a trimis pachete Hello pentru o perioad mai lung dect intervalul permis
(denumit interval Dead), sau ruterul a fost eliminat manual din configuraia reelei.
Ruterele pot trimite pachete Hello ctre vecinii aflai n starea Down.
Ruterul a iniiat o comunicaie prin trimiterea unui mesaj Hello pe adresa multicast
Ruterul a stabilit o relaie bidirecional cu vecinul su, ca urmare a primirii unui
rspuns Hello valid (identificat prin prezena adresei sale IP) sau a unui pachet
Database Descriptor (DBD). Ruterul decide dac rmne n aceast stare sau dac i
modific relaia de vecintate la nivelul Full.
Stabilirea statutului de master / slave pentru iniierea comunicrii ntre rutere; n
cazul reelelor multiacces statutul se stabilete n relaia dintre rutere i DR, respectiv
BDR.
n principal are loc schimbul de pachete DBD.
Pe baza informaiilor din DBD sunt solicitate actualizri ale strii legturilor, fiind
transmise pachete LSR, LSU i LSAck.
Stare de adiacen deplin: informaiile de rutare sunt sincronizate.
Figura 5-4: Starile protocolului OSPF
5.1.3 Tabelele OSPF

Informaiile de care dispune procesul OSPF sunt structurate n trei tabele, i anume tabela de
adiacen, tabela de topologie i tabela de rutare.
Ca urmare a stabilirii relaiilor bidirecionale cu ruterele vecine ce ruleaz OSPF, un ruter va
completa tabela de adiacen (Adjacency database sau Neighbor table). Dac unul dintre vecini nu
trimite pachete Hello pentru o perioad mai lung dect intervalul permis (interval Dead) tabela de
adiacen este actualizat prin tergerea acestuia i se invalideaz toate cile care treceau prin acel
vecin. Intervalul Dead este setat implicit cu o valoare de patru ori mai mare dect intervalul la care
se trimit pachetele Hello.
Tabela de topologie sau tabela topologic (Link-state database LSDB, sau Topological
database) conine o imagine detaliat a ntregii reele, constnd n toate mesajele de actualizare a
strii legturilor, mai exact strile tuturor legturilor ruterelor din reea. LSDB este sincronizat
periodic cu tabelele celorlalte rutere din reea, sau din aria respectiv n cazul OSPF Multi-area,
ceea ce nseamn ca ruterele au o tabel de topologie identic. Fiecare proces OSPF dispune de o
tabel de topologie, pe baza creia ia deciziile de selectare a cilor optime ce vor fi promovate n
tabela de rutare.
n cazul OSPF Single Area, pentru a selecta ruta optim ctre o destinaie, ruterul aplic
algoritmul Dijkstra SPF, situndu-se la rdcina arborelui i cutnd ruta cu metrica cea mai sczut.
Ruta optim este adugat la tabela de rutare (Routing table sau Forwarding database). n cazul
primirii unei actualizri de la un ruter vecin, tabela de topologie este modificat iar algoritmul SPF
este rulat pentru recalcularea rutelor optime. Fiecare ruter are o tabel de rutare unic, ce reflect
poziia sa n topologie.
n cazul n care reeaua este segmentat n arii diferite, fiind implementat OSPF Multi-area,
construirea tabelei de rutare se realizeaz difereniat pentru destinaiile din propria zon i cele din
zonele externe. n primul rnd, ruterul va calcula rute optime ctre destinaiile din zona n care se
afl, i le va aduga n tabela de rutare. Apoi, ruterul va prelucra informaiile privind reele aflate n
alte zone OSPF i va selecta cile de cost minim. n final sunt analizate destinaiile externe reelei
OSPF. De asemenea, n cazul n care un ruter dispune de o ruta inter-zonal i o rut intra-zonal
ctre o aceeai destinaie, va fi pstrat ruta intra-zonal. n cel de-al treilea pas, ruterul va calcula
91 | O S P F
rutele optime ctre destinaiile aflate n afara reelei OSPF, cu excepia situaiei n care este situat
ntr-o arie de tipul stub sau totally stubby (definite mai jos).
5.1.4 Formatul pachetelor OSPF

n subcapitolul 5.1.2 au fost prezentate etapele funcionrii protocolului OSPF. Conform datelor
prezentate anterior, exist 5 tipuri de pachete OSPF, folosite pentru stabilirea relaiilor de adiacen
i pentru actualizarea tabelei topologice. n timp ce adiacena este realizat prin mesaje Hello, care
au un TTL egal cu 1, actualizarea se realizeaz prin comunicarea de informaii Link-State
Advertisement (LSA), incluse n pachete Link-State Update (LSU). Solicitarea unei LSA se realizeaz
prin pachete LSR Link State Request, iar confirmarea primirii se realizeaz prin pachete Link-State
Acknowledgement (LSAck). Pachetele DBD (Database Description) reprezint o prezentare succint
a tabelei topologice a unui ruter, incluznd lista tuturor ruterelor cunoscute i ultimul numr de
secven pentru fiecare.
Pachetele OSPF sunt ncapsulate direct n cmpul de date IP, fr a apela la un alt protocol de
nivel transport precum TCP sau UDP; prin urmare, OSPF va folosi propria schem de confirmare a
recepionrii mesajelor, bazat pe un pachet special, i anume LSAck. Identificatorul protocolului
OSPF n antetul IP este 89.
Cmp
Versiunea
Tipul
Lungime
ID-ul ruterului
ID-ul ariei
Sum de control
Tipul autentificrii
Autentificarea
Date
Hello
DBD
LSR
LSU
LSAck
Informaii
Versiunea 2 sau 3
Identific unul dintre cele 5 tipuri de pachete
Lungimea pachetului n octei
Identific ruterul surs al pachetului
Identific aria surs a pachetului
Valoare folosit pentru a verifica integritatea pachetului
Specific una dintre cele trei posibiliti: nici o autentificare,
parole n clar, sau mesaje criptate Message Digest 5 (MD5)
Folosit n procesul autentificrii
Lista vecinilor cunoscui
Rezumatul tabelei de topologie
Tipul de LSU solicitat i ID-ul ruterului care dispune de
informaie
Informaia complet de actualizare, inclusiv pentru mai
multe LSA
Cmp gol
Figura 5-5: Structura unui pachet OSPF
Actualizrile sunt trimise fie ca urmare a sesizrii unor modificri n topologia reelei, fie ca
urmare a expirrii informaiilor. Mesajele de actualizare LSA conin un cmp de vrst, ceea ce
permite expirarea lor dup o anumit durat prestabilit, setat implicit la 1800 de secunde.
Ruterul care a emis actualizarea expirat o retrimite, cu un numr de secven incrementat, ntr-un
pachet LSU, ce poate include mai multe intrri LSA.
De asemenea, ruterul care observ o modificare a topologiei reelei informeaz ruterele vecine,
sau, n cazul reelelor multiacces, informeaz DR care ulterior trimite mesajul ctre ruterele din aria
respectiv (LSA flood). Fiecare ruter compar LSA primit cu cele deja disponibile n tabela de
topologie; dac informaia este nou, o adaug; dac un LSA similar este deja nregistrat, compar
numrul de secven i pstreaz nregistrarea cea mai recent.
OSPF folosete adresarea multicast i unicast. De exemplu, odat ce un ruter a sesizat
modificarea topologiei, va trimite pachete LSU ctre adresa de multicast 224.0.0.5 (pentru All Link
State Routers) adres folosit i n starea Init de stabilire a relaiilor de adiacen prin
transmiterea pachetelor Hello.
n cazul reelelor multiacces, ruterul care a sesizat o modificare va trimite o actualizare pe
adresa de multicast 224.0.0.6, adres pe care ascult doar DR i BDR. n cazul n care pachetul de
actualizare reprezint o informaie nou, DR va retrimite pachetul tuturor vecinilor pe adresa
224.0.0.5.
5.1.5 OSPF Multi-area

Scalabilitatea OSPF se datoreaz n mare msur posibilitii de a segmenta reeaua n mai
multe arii, cu avantaje semnificative pentru timpul de convergen al protocolului i timpul de
rspuns al rutrii.
Cu ct o reea este mai mare, cu att tabela topologic i tabela de rutare conin mai multe
intrri. Numrul de ci poteniale spre aceeai destinaie crete odat cu dimensiunea reelei, n
consecin calculele SPF necesare obinerii rutei optime devin mai complexe. Astfel crete consumul
de resurse de memorie i procesor dar i de lime de band din cauza actualizrilor mai frecvente.
In plus, datorita modului de functionare al protocoalelor link-state, orice schimbare in retea, va fi
propagata catre toate ruterele care trebuie sa recalculeze fiecare legatura din intreaga tabela de
topologie.
Pentru a simplifica reprezentrile topologice i calculul rutelor optime, reeaua poate fi
structurat n zone (sau arii). O arie reprezint o mulime logic de rutere, legturi i reele OSPF,
fiind reprezentat printr-un identificator propriu. n cazul OSPF Multi-Area, ruterele vor menine o
tabel topologic detaliat doar pentru aria n care sunt situate, ceea ce reduce substanial
dimensiunea LSDB precum i cantitatea de informaie propagat prin LSA. Mai precis, propagarea
LSA detaliate poate fi restrns la graniele ariei, ceea ce nseamn c schimbrile topologice vor
afecta doar zona n care apar. Ruterele vor trebui s cunoasc doar informaiile despre vecinii aflai
n aceeai arie, informaiile despre restul reelei putnd fi sumarizate. Nu n ultimul rnd,
segmentarea pe arii permite reducerea dimensiunea tabelei de rutare prin sumarizare, precum i a
frecvenei rulrii algoritmului SPF.
Identificatorul unei arii este un numr exprimat pe 32 de bii, cel mai adesea sub forma unei
singure valori n notaie zecimal. O practic frecvent este ca ariile s fie identificate n funcie de
adresa IP a principalului ruter. Totui, identificatorul unei arii nu este o adres IP, din punct de
vedere funcional, i prin urmare poate coincide cu o adres IP fr a crea confuzii.
OSPF Multi-area se bazeaz pe un model ierarhic pe doua nivele. Aria 0 (supranumita si aria de
backbone sau aria de tranzit) este intotdeauna zona centrala; toate celelalte arii se ataseaza la
aceasta. Aria 0 formeaza nivelul de sus al ierarhiei, iar celelalte zone ramase, nivelul de jos; acest
design ofera suport pentru sumarizare intern posibila doar intre arii si pentru minimizarea
numarul din tabela de rutare. Zonele normale sunt cele care includ utilizatorii finali, fiind definite n
special dup criterii utilitariste, de exemplu pe criterii geografice sau organizaionale. De regula, o
zon normal nu este folosita pentru a transporta trafic intre zone. Un exemplu de topologie
mprit pe zone este reprezentat n figura 5-6.
93 | O S P F
R1
R2
Zona 0 (Backbone)
Zona 3
R7
R3
R5
Zona 1
Zona 2
R4
R8
R6
Figura 5-6: Organizarea ierarhic
Ruterele OSPF Multi-area pot fi clasificate n funcie de rolul lor n comunicarea intra- i
inter-arii. Un ruter intern (Internal Router) este cel care, dup cum sugereaz i numele, are toate
interfeele n aceeai zon. Un ruter de margine, abreviat ABR (Area Border Router) are interfee n
dou sau mai multe zone, pe care astfel le conecteaz. Un ASBR (Autonomous System Boundary
Router) conecteaz un alt protocol de rutare la reeaua OSPF. Denumirea poate fi nelatoare,
deoarece OSPF nu este folosit pentru a ruta ntre sisteme autonome diferite, fiind un IGP. Prin
urmare, orice ruter care distribuie un alt protocol de rutare ntr-o reea OSPF este un ASBR.
Ruterele de backbone (Backbone Router) au cel puin o interfa n aria 0, participnd astfel la
conectarea zonelor normale cu zona 0. Un ruter poate ndeplini roluri multiple: de exemplu, un
ruter backbone poate fi un Internal Router, un ABR sau un ASBR. Ruterele care conecteaz mai
multe zone pstreaz cte o tabel de topologie distinct pentru fiecare dintre ele. Pe de alt parte,
toate ruterele dintr-o arie trebuie s aib o tabel de topologie identic.
R6
Reea extern
Zona 0 (Backbone)
Zona 2
Zona 1
R2
Internal router
R3
ABR
R1
ABSR
Figura 5-7: Tipuri de rutere OSPF
R4
ABR
R5
Internal router
Proiectarea unei reele OSPF ierarhice trebuie s in cont de resursele disponibile la nivelul
fiecrei zone definite (precum memorie sau CPU), precum i de tipul legturilor, stabilitatea
acestora i a dispozitivelor de interconectare, i de alte particulariti ale reelei. Exist nite
recomandri generale ale Cisco privind configurarea OSPF Multi-area, precum: un numr maxim de
50 de rutere n fiecare zon, un numr maxim de 60 de vecini pentru fiecare ruter, cel mult 3 zone
per ruter, i evitarea situaiilor n care un ruter este ales DR sau BDR n dou sau mai multe LAN-uri.
Desigur, aceste recomandri trebuie avute n vedere n contextul mai larg definit de resursele
disponibile, de cerinele utilizatorilor i de designul de ansamblu al reelei.
5.1.6 Tipuri de LSA

Comunicarea n cazul OSPF Multi-area se realizeaz prin mai multe tipuri de mesaje LSA,
clasificate n funcie de ruterul care le iniiaz i de informaia pe care o conin. Mesajele LSA
primite de un ruter formeaz tabela sa de topologie (LSDB). Ele descriu ntreaga topologie a unei
reele sau a unei zone OSPF.
LSA de tipul 1, Router Link LSA, sunt generate de fiecare ruter, sunt transmise doar n interiorul
ariei, i informeaz toate ruterele din aria respectiv cu privire la starea legturilor ruterului surs.
Pentru fiecare legtur sunt precizate tipul, ID-ul ruterului urmtor, adresa interfeei ruterului,
precum i metrica. LSA de tip 1 nu trec dincolo de ABR.
Zona 1
Internal router
Internal router
R1
R2
Tip 1
Figura 5-8: LSA tip 1

LSA de tipul 2, Network Link LSA, este generat pentru o reea de tip multiacces, de ctre DR.
LSA2 conine o list a identificatorilor OSPF a tuturor ruterelor legate la respectiva reea multiacces.
Altfel spus, un LSA2 conine toate adresele ruterele din reea cu care DR are stabilit o relaie de
adiacen, inclusiv acesta. Ca i LSA1, LSA2 nu trece de graniele ariei.
Zona 1
Internal router
Internal router
R3
DR
R1
Internal router
R2
Tip 2
Figura 5-9: LSA tip

LSA de tipul 3, Network Summary LSA, este iniiat de ABR i conine informaiile propagate
anterior prin intermediul LSA1 i LSA2 cu privire la reelele incluse n aria respectiv. Mai precis,
LSA3 descrie reelele de destinaie conectate cu ABR, specificnd masca acestora precum i metrica.
95 | O S P F
Informaiile sunt trimise n zona 0 ctre celelalte ABR, pentru a propaga rutele ctre zonele locale
conectate la ABR-ul iniiator. Ruterele de grani vor regenera LSA3 i vor transmite apoi
informaiile n interiorul zonelor din care fac parte. Astfel, informaiile dintr-un LSA3 sunt propagate
n ntregul sistem autonom OSPF. Setarea implicit a ABR este ca informaia din LSA3 s nu fie
sumarizat, ceea ce poate duce la o cretere semnificativ a traficului de actualizare. LSA3 pot
include ns i informaii sumarizate manual, ceea ce este recomandabil pentru a spori
scalabilitatea.
Zona 1
ABR
ABR
Internal router
R2
Zona 2
Zona 0 (Backbone)
R3
R1
R5
R4
Tip 3
Tip 1/2
Internal router
Tip 3

LSA de tipul 4, Network Summary LSA, este generat de un ruter ABR la primirea unui LSA1 ce
descrie un ASBR. LSA de tipul 4 identific ruterul ASBR i ofer o rut ctre el. Pentru tot traficul
rutat n exteriorul sistemului autonom, sunt necesare informaii despre ruterul ASBR care ofer
accesul ctre rutele externe. Ruterul ASBR din figura 5-11 trimite un LSA1 cu bitul extern setat prin
care se identific a fi ASBR. Cnd un ABR primete un astfel de LSA, construiete un LSA4 i l trimite
n zona 0 (Backbone). Urmtoarele rutere ABR vor regenera LSA4 i l vor trimite n zonele la care
sunt conectate. Aceste LSA vor conine identificatorul ruterului ASBR care a trimis primul LSA1.
R6
Reea extern
ASBR
R2
Tip 1
Zona 1
Zona 2
Zona 0 (Backbone)
ABR
ABR
R3
R1
Tip 4
Internal router
R5
R4
Tip 4

LSA de tipul 5, External Link LSA, descrie o rut ctre o reea extern sistemului autonom OSPF.
LSA5 este generat de ctre ASBR i este propagat n tot sistemul autonom. Identificatorul este cel al
reelei externe i nu se schimb pe parcursul propagrii prin reea. Sumarizarea pentru rutele
externe nu este activat n mod implicit, dar se recomand sumarizarea lor la nivelul ruterului ASBR.
R6
Reea extern
ASBR
Zona 1
R2
Zona 2
Zona 0 (Backbone)
ABR
ABR
R3
Tip 5
R1
Tip 5
Internal router
R5
R4
Tip 5

Costul unei rute externe depinde de tipul configurat pe ASBR. Exist dou tipuri de rute externe
n ceea ce privete costul: tipul O E1 i tipul O E2. Pentru tipul O E1, costul se calculeaz adugnduse la costul extern, costul fiecrei legturi pe care pachetul o traverseaz. Acest tip se folosete
atunci cnd mai multe rutere ASBR anun rute ctre aceeai destinaie, pentru a evita rutarea
suboptimal. n mod implicit, este activat tipul O E2, al crui cost este egal cu costul extern i
rmne neschimbat. Se va folosi acest tip atunci cnd un singur ASBR anun o rut ctre o anumit
destinaie.
LSA de tip 6, Multicast LSA, este folosit pentru aplicaii multicast, dar nu este implementat pe
ruterele Cisco.
LSA de tip 7, NSSA External LSA, este generat pe ASBR n cadrul unei zone NSSA i va fi trimis
doar n acea zon. LSA7 va fi convertit n LSA5 de ctre ABR.
5.2 Concepte avansate

5.2.1 Tipuri de zone
OSPF faciliteaz scalabilitatea folosind o organizare ierarhic a comunicrii. Am vzut ca zonele
sunt difereniate n zone normale i zone de tranzit, care includ i zona 0 (de backbone). La rndul
lor, zonele normale sunt difereniate n funcie de gradul i de tipul de deschidere ctre exterior.
Exist patru tipuri de zone normale: zone standard, zone Stub, zone de tip Totally Stubby i zone de
tip Not-So-Stubby.
Zonele standard sunt cele care accept toate tipurile de update-uri i sumarizri, fr restricii.
n cazul unor reele extinse, este ns posibil ca overhead-ul introdus de LSA3, LSA4 i LSA5 s fie
semnificativ.
Extinznd principiul izolrii, conform cruia a fost proiectat i segmentarea reelei OSPF n
zone, unele dintre ariile normale pot fi definite ca fiind Stub sau Totally Stubby, adic arii care nu
mai particip la transferul de informaie detaliat privind zonele externe.
97 | O S P F
Zonele Stub nu accept informaii cu privire la rutele din afara sistemului OSPF, i prin urmare
mesajele LSA4 i LSA5 sunt filtrate. Ruterele din astfel de zone vor folosi ruta default pentru a
accesa reelele din afara sistemului OSPF. Ruterul ABR de la grania zonei Stub va genera un LSA3
pentru a anuna o rut implicit n interiorul zonei. Pentru destinaiile externe sistemului autonom
se va folosi aceast rut default. Zonele stub nu pot conine rutere ASBR.
R
Reea extern
Zona 1
ASBR
R2
Extern
Zona 0 (Backbone)
ABR
R3
R1
Zona 2 Stub
ABR
R5
R4
Extern
Default
Summary
Summary
Figura 5-13: Zona Stub

La un nivel i mai ridicat de izolare, zonele de tip Totally Stubby nu accept informaii cu privire
la rutele externe sistemului autonom sau rute sumarizate din alte zone. n concluzie, zonele de tip
Totally Stubby nu accept nici LSA3, nici LSA4 i LSA5. n ariile Totally Stubby sunt permise doar LSA3
care indic ruta default pentru accesul ctre exterior. Ruta default va fi folosit pentru a accesa
toate destinaiile externe sistemului autonom sau externe acestei zone. De asemenea, zonele de tip
Totally Stubby nu pot conine ASBR.
Zonele de tip Not So Stubby (NSSA Not So Stubby Areas) sunt o modificare proprietar Cisco
a ariilor Stub sau Totally Stubby, pentru a permite accesul acestora ctre reele din afara sistemului
OSPF. Prin urmare, un ASBR poate fi inclus ntr-o NSSA. Dat fiind c mesajele LSA5 sunt blocate n
cazul ariilor Totally Stubby, NSSA import rute externe i le comunic n interiorul su prin LSA7,
care sunt apoi convertite de ABR n LSA5 i apoi propagate mai departe n reeaua OSPF.
Zonele NSSA pot fi de dou tipuri: Stub sau Totally Stubby. Comportamentul celor dou tipuri
de zone este identic cu cel al zonelor normale Stub i Totally Stubby, exceptnd poteniala prezen
a unui ASBR n zon.
R
Reea extern
Zona 1
ASBR
R2
Zona 0 (Backbone)
ABR
R3
Extern
R1
ABR
Zona 2 Totally Stubby
R5
R4
Extern
Default
Summary
Default
Figura 5-14: Zona Totally Stubby

Pachetele LSA de tip 7 sunt descrise n tabela de rutare ca O N1 i O N2. N1 nseamn c
metrica este calculat ca n cazul tipului E1, iar pentru N2 metrica este calculat ca n cazul E2, iar
N2 este folosit n mod implicit.
R
Reea extern
Zona 1 Not So Stubby

ASBR
R2
LSA 7
ABR
R3
Zona 0 (Backbone)
R1
LSA 5
Zona 2
ABR
R5
R4
LSA 5
Figura 5-15: Zona Not So Stubby

Prin urmare, ariile Stub i Totally Stubby au urmtoarele caracteristici distinctive: nu sunt arii de
backbone, nu includ ASBR, i ruterele din interiorul lor, inclusiv ABR, trebuie s fie configurate ca
rutere stub nainte de stabilirea adiacenelor. De asemenea, n general ariile Stub i Totally Stubby
99 | O S P F
sunt conectate cu restul reelei prin intermediul unui punct de acces (ABR) unic, dei este posibil s
fie conectate prin mai multe ABR-uri, dac rutele suboptimale sunt acceptabile.
Configurarea unei zone ca Stub sau Totally Stubby duce la micorarea tabelei de topologie i de
rutare, ceea ce duce la consum mai mic de memorie pe ruterele din acea zon.
De asemenea, este important ca ariile Stub i Totally Stubby s nu fie utilizate ca arii de tranzit
pentru legturile virtuale inclusiv pentru cele proiectate temporar sau ca soluii de backup.
5.2.2 Sumarizarea rutelor

Principalele beneficii ale sumarizrii rutelor sunt creterea scalabilitii i reducerea consumului
de memorie i procesor. O reea OSPF poate scala pn la dimensiuni destul de mari datorit
sumarizrii rutelor.
Sumarizarea rutelor const n agregarea mai multor rute ntr-un singur anun. Astfel se reduce
numrul de pachete LSA care propag prin reea, dar i dimensiunea tabelei de topologie i de
rutare, ceea ce rezult n reducerea consumului de memorie i procesor pe ruter.
Dac nu se sumarizeaz rutele, fiecare LSA specific este propagat n zona de backbone i apoi
mai departe n celelalte zone. Atunci cnd ar fi generat un LSA, toate ruterele ar trebui s-i refac
tabela de topologie i s construiasc arborele SPF.
Atunci cnd se sumarizeaz rutele, doar rute sumarizate vor fi propagate n zona de backbone.
Prin urmare, atunci cnd o legtur devine invalid, schimbarea de topologie nu este propagat n
zona de backbone sau n celelalte zone.
OSPF pune la dispoziie dou tipuri de sumarizare: ntre zone i extern. Sumarizarea rutelor
ntre zone diferite ale aceluiai sistem autonom poate fi configurat pe ABR i se aplic pentru toate
rutele din fiecare zon. n general nu se aplic rutelor externe. Pentru sumarizarea eficient a
rutelor, reelele trebuie s aib asignate adrese continue.
Sumarizarea rutelor externe poate fi configurat pe ASBR i se aplic numai rutelor externe
injectate n OSPF prin redistribuie. De asemenea, este necesar ca rutele sumarizate s corespund
unor adrese de reea continue.
5.2.3 Autentificarea n OSPF

Pentru a preveni primirea de actualizri neautorizate, este necesar folosirea autentificrii
vecinilor. Autentificarea se face la primirea fiecrui pachet de actualizare primit prin trimiterea unei
parole cunoscute de ambele rutere care comunic. Ruterul verific fiecare pachet OSPF primit
pentru a autentifica sursa actualizrii.
n mod implicit, nu este activat autentificarea n cadrul protocolului OSPF, dar acesta suport
dou metode de autentificare ce pot fi configurate: o parol simpl trimis n clar, i autentificarea
prin MD5.
Metoda autentificrii prin MD5 include folosirea unui numr de secven n fiecare pachet
OSPF pentru a proteja ruterele mpotriva atacurilor de tip replay.
5.2.4 Legturi virtuale

n cazul OSPF Multi-area este necesar ca toate zonele s fie conectate cu aria de backbone. n
situaiile n care nu exist legturi fizice care s permit acest lucru, pot fi folosite legturi virtuale.
De exemplu, legturile virtuale pot conecta o arie cu aria 0 prin intermediul unei zone de tranzit.n
figura 5-16, zona 2 nu poate fi direct conectat la zona de backbone, deci o legtur virtual este
folosit pentru a asigura o cale ctre zona 0, fiind folosit zona 1 ca zon de tranzit.
Zona 0 (Backbone)
R1
Zona 2
Zona 1
Legtura virtual
R2
R4
R5
Figura 5-16: Legturi virtuale

De asemenea, dac dou reele OSPF sunt combinate ntr-o reea comun, cele dou arii de
backbone vor putea fi unificate printr-o legtur virtual pentru a deveni o singur arie 0. Un
exemplu este reprezentat n figura 5-17.
Zona 0 (Backbone)
R1
Zona 0 (Backbone)
Zona 1
Legtura virtual
R2
R4
R5

Pachetele de tip Hello sunt trimise peste legturile virtuale n acelai mod ca peste legturile
standard, la intervale de 10 secunde. Actualizrile folosind pachete LSA funcioneaz diferit. n
general un LSA se retransmite la intervale de 30 de minute. Pachetele LSA transmise pe o legtur
virtual au setat opiunea DoNotAge (DNA) care le mpiedic s expire. Acest mecanism este
folosit pentru a preveni inundarea excesiv a legturii virtuale.
Recomandrile Cisco sunt ca legturile virtuale s nu fie planificate ca o cale stabil de acces la
aria 0, ci s fie folosite temporar, de exemplu pentru soluii de back-up, sau pentru alte situaii care
necesit o intervenie rapid.

Pentru a configura protocolul de rutare OSPF este necesar parcurgerea urmtorilor pai:
1. Activarea procesului OSPF pe ruter folosind comanda router ospf specificnd un numr
de proces unic pe ruter, spre deosebire de EIGRP pentru care trebuia specificat numarul sistemului
autonom. Identificatorul procesului trebuie s fie un numr ntre 1 i 65535. Numarul de proces are
doar relevan local, de aceea nu este necesar configurarea aceluiai numr de proces pe toate
ruterele din reea. Rularea mai multor procese OSPF pe un singur ruter nu este recomandat din
cauza consumului excesiv de memorie i procesor.
R(config)# router ospf id_proces
101 | O S P F
2. Identificarea interfeelor care sunt incluse n procesul OSPF folosind comanda network.
Aceast comand indentific i zona din care face parte ruterul.
R(config-router)# network adresa_ip masca_wildcard area id_zona
Adresa reelei este folosit pentru a determina pe ce legturi s trimit actualizri, pe ce

legturi s asculte actualizri i ce reele s anune. Masca specificat trebuie s fie de tip wildcard.
Identificatorul zonei poate fi n format decimal sau n formatul asemntor adresei IP: A.B.C.D.
O alternativ la metoda anterioar de configurare este comanda ip ospf area care se va
introduce direct pentru o anumit interfa.
R(config-if)# ip ospf id_proces area id_zona [secondaries none]
Folosirea parametrului secondaries previne anunarea adreselor secundare de pe acea

interfa.
Pentru exemplificarea folosirii acestor comenzi, se va considera urmtorul exemplu de
configurare. Se va folosi topologia din figura 5-18, i se va configura OSPF cu o singur zon.
192.168.10.0/30
R1
S0/0
S0/0
172.20.3.0/24
R2
Fa0/0
Fa0/0
11.0.0.0/8
R3
10.0.0.0/8
Figura 5-18: : Configurare OSPF cu o singur zon

R1(config)# router ospf 1
R1(config-router)# network 11.0.0.0 0.255.255.255 area 0


Se va folosi topologia din figura 5-19, pentru a exemplifica configurarea OSPF pentru mai multe
zone.
192.168.10.0/30
R1
11.0.0.0/8
S0/0
Zona 0
S0/0
172.20.3.0/24
R2
Fa0/0
Fa0/0
Zona 1
Figura 5-19: Configurare OSPF cu o mai multe zone
10.0.0.0/8
R3


Exist dou metode de modificare a costului unei legturi:

1. Prin modificarea limii de band declarate, cu consecine asupra tuturor protocoalelor ce
folosesc aceast informaie:
R(config-if)# bandwidth valoare
2. Prin stabilirea explicit a costului, ceea ce afecteaz doar metrica OSPF:

R(config-if)# ip ospf cost valoare
Atunci cnd pornete, procesul OSPF alege un identificator al ruterului. Acest identificator
poate fi:
cea mai mare adres IP configurat pe una dintre interfeele active
cea mai mare adres IP configurat pe o interfa de loopback
un identificator configurat manual
Dac este configurat un identificator, are prioritate la alegere n faa adreselor IP de pe
interfeele active sau de loopback. Daca nu este configurat un identificator, adresa IP a interfeei de
loopback are prioritate n faa adreselor de pe interfeele active, chiar daca au adresa IP mai mare.
n cazul n care nu este configurat nici o adres pe intefaa de loopback, se va alege cea mai mare
adres IP de pe una din interfeele active.
Comanda prin care se configureaz identificatorul ruterului este urmtoarea:
R(config-router)# router-id adresa_ip
Identificatorul ruterului trebuie s fie o valoare pe 32 de bii cu format de adres IP. De

asemenea, trebuie s fie unic n sistemul autonom.
Dac un alt identificator a fost deja selectat trebuie forat reselecia prin comanda:
R# clear ip ospf process
Trebuie reinut faptul c aceast comand ntrerupe temporar funcionarea reelei.
5.3.2 Verificarea funcionrii OSPF

Folosind topologia din figura 5-19, se poate verifica dac OSPF a fost configurat n mod corect
folosind comenzile prezentate n continuare.
Pentru a verifica identificatorul ruterului i ali parametri OSPF se folosete comanda show ip
ospf:
103 | O S P F
R1# show ip ospf
Routing Process "ospf 1" with ID 192.168.10.1
Supports only single TOS(TOS0) routes
Supports opaque LSA
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
LSA group pacing timer 100 secs
Interface flood pacing timer 55 msecs
Retransmission pacing timer 100 msecs
Number of external LSA 0. Checksum Sum 0x0
Number of opaque AS LSA 0. Checksum Sum 0x0
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 2. 2 normal 0 stub 0 nssa
External flood list length 0
Area BACKBONE(0)
Number of interfaces in this area is 2
Area has message digest authentication
SPF algorithm executed 4 times
Area ranges are
Number of LSA 2. Checksum Sum 0x29BEB
Number of opaque link LSA 0. Checksum Sum 0x0
Number of DCbitless LSA 1
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Pentru a verifica dac interfeele sunt incluse n ariile OSPF se va folosi comanda show ip
ospf interface:
R2# show ip ospf interface Fa0/0

FastEthernet0/0 is up, line protocol is up
Internet Address 172.20.3.1/24, Area 0
Process ID 2, Router ID 192.168.10.2, Network Type BROADCAST, Cost:
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 172.20.3.2, Interface address 172.20.3.2
Backup Designated router (ID) 192.168.10.2, Interface address
172.20.3.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:06
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 2, maximum is 2
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.20.3.2 (Designated Router)
Suppress hello for 0 neighbor(s)
Comanda anterioar afieaz informaii despre identificatorul procesului, identificatorul

ruterului, tipul reelei, DR i BDR, intervale de timp configurate i vecinii cu care a format o
adiacen.
Ruterele care ruleaz OSPF nu trimit i nu primesc actualizri dac nu s-au format adiacene cu
vecinii cu care urmeaz s comunice. Adiacenele formate se pot verifica folosind comanda show
ip ospf neighbor:
R2# show ip ospf neighbor
Neighbor ID
Interface
172.20.3.2
FastEth0/0
192.168.10.1
Serial0/0
Pri
State
Dead Time
Address
FULL/DR
00:00:36
172.20.3.2
FULL/-
00:00:38
192.168.10.1
Prima intrare n tabel reprezint adiacena format pe interfaa FastEthernet. Starea FULL
nseamn c tabelele de topologie au fost schimbate ntre ruterele vecine iar DR nseamn ca
ruterul vecin este DR pentru reeaua respectiv, de aceea i prioritatea este 1. A doua linie
reprezint adiacena cu vecinul aflat pe legtura serial. Lipsa parametrului DR/BDR/DROTHER se
datoreaz faptului c legtura este serial, deoarece doar pe legturi multi-acces se alege DR i
BDR.
Tabela de topologie se poate afia folosind comanda show ip ospf database. Se vor afia
toate LSA-urile grupate dup tip pentru fiecare zon n parte.
R1# show ip ospf database
OSPF Router with ID(192.168.10.1) (Process ID 1)
Router Link States(Area 0)
Link ID
count
11.0.0.1
192.168.10.1
192.168.10.2
ADV Router
Age
Seq#
11.0.0.1
192.168.10.1
192.168.10.2
1381
1460
2027
0x8000010D
0x800002FE
0x80000090
Checksum Link
0xEF60
0xEB3D
0x875D
1
2
2
Summary Net Link States(Area 0)

Link ID
172.20.3.0
10.0.0.0
ADV Router
192.168.10.2
192.168.10.2
Age
1323
1461
Seq#
0x8000005B
0x8000005B
Checksum
0xA8EE
0x7AC1

Link ID este identificatorul LSA-ului
ADV Router este ruterul care a generat acest LSA
Age este varsta LSA-ului n secunde
Seq# este numrul de secven al LSA-ului. Iniial este 0x80000001 i crete la fiecare
actualizare
Checksum este suma de control a pachetului LSA
Link count este numarul de legturi direct conectate i este folosita doar pentru LSA de tip
Router. Legturile seriale se pun ca 2 legturi iar toate celelalte tipuri se pun ca o legtur.
Cele mai bune rute vor fi instalate n tabela de rutare. Pentru a afia tabela de rutare se
folosete comanda show ip route:
R1# show ip route ospf
O IA
10.0.0.0/8
[110/782] via 192.168.10.2,
00:00:52, Serial0/0
O IA
172.20.3.0/24 [110/74] via 192.168.10.2, 00:00:49, Serial0/0
Se pot observa rutele nvate de R1 prin intermediul lui R2. Notaia este O IA (Inter-Area)
deoarece rutele provin din alt zon. Pentru rute din aceeai zona se folosete notaia O, pentru
rute externe E1 i E2, iar pentru rute externe provenite dintr-o zon NSSA, N1 i N2.
Pentru a vizualiza infomaii despre protocolul de rutare i parametri cum ar fi intervale de timp,
metrici, reele, se folosete comanda show ip protocols.
5.3.3 Configurarea unei zone Stub

Pentru a obine o zon Stub, este necesar configurarea fiecrui ruter din zon folosind
comanda stub.
R(config-router)# area id_zona stub
Pentru a defini costul rutei default trimise n zona Stub se va folosi urmtoarea comand pe
ruterul ABR de la grania zonei Stub:
105 | O S P F
R(config-router)# area id_zona default-cost cost
Costul implicit al rutei este 1, iar comanda anterioar accept o valoare ntre 0 i 16777215.
Folosind topologia din figura 5-20, se va configura zona 2 ca fiind Stub. Ruterul R4 nu va primi
informaii despre reeaua extern, dar va putea primi rute sumarizate. O rut default va fi injectat
de ctre ruterul R3 n zona Stub pentru a putea accesa reeaua extern.
R
Reea extern
Zona 1
ASBR
R1
ABR
Zona 0 (Backbone)
ABR
192.168.10.0/30
R2
Zona 2 Stub
172.20.3.0/24
R3
R4
Figura 5-20: : Configurare zon Stub

R3(config)# router
R3(config-router)#
R3(config-router)#
R3(config-router)#
ospf 1
network 192.168.10.0 0.0.0.3 area 0
network 172.20.3.0 0.0.0.255 area 2
area 2 stub

R4(config-router)# area 2 stub
Zona Stub se va forma n momentul n care toate ruterele care aparin de acea zon au fost
configurate folosind comanda area stub.
5.3.4 Configurare zon Totally Stubby

Dup cum a fost prezentat n subcapitolul 5.2.1, o zon Totally Stubby va opri pachetele LSA de
tip 3, 4 i 5. O zon Totally Stubby va fi setat, mai nti, prin configurarea fiecruiruter din zon, n
afar de ABR, pentru a face parte din zona Stub:
R(config-router)# area id_zona stub
Apoi, se va configura ruterul ABR folosind opiunea no-summary, ceea ce va opri toate
pachetele LSA de tip Summary s intre n zon:
R(config-router)# area id_zona stub no-summary
Folosind aceeai topologie din figura 5-20, se va configura zona 2 ca fiind Totally Stubby.
R3(config-router)# area 2 stub no-summary
Pentru ruterul R4 vor trebui introduse urmtoarele comenzi:

R4(config-router)# area 2 stub
5.3.5 Configurare zon Not So Stubby

Noiunea de zon NSSA a fost prezentat n subcapitolul 5.2.1. NSSA este o zon Stub n care
este permis prezena unui ruter ASBR. O zon va fi definit ca fiind NSSA dac toate ruterele din
zon vor fi configurate folosind urmtoarea comand:
R(config-router)# area id_zona nssa [no-summary]
Folosind topologia din figura 5-21, se va configura zona 1 ca fiind NSSA. Ruterul R1 va
redistribui rute RIP n OSPF i va genera un LSA de tip 7. Ruterul R2 va converti LSA7 n LSA5. Ruterul
2 trebuie configurat s sumarizeze rutele externe redistribuite din RIP, astfel nct subreelele
10.1.0.0/16, 10.2.0.0/16 i 10.3.0.0/16 vor fi sumarizate ca 10.0.0.0/8 i va fi trimis un singur LSA n
zona 0. Pentru ca ruterul R2 s genereze o rut default de tipul *O N2 pentru zona NSSA, se va
folosi opiunea default-information-originate a comenzii area nssa.
10.1.0.0/16
10.2.0.0/16
10.3.0.0/16
RIP
Zona 1 Not So Stubby

ASBR
ABR
Zona 0 (Backbone)
ABR
Zona 2
192.168.10.0/30
R1
172.20.3.0/24
R2
R3
Figura 5-21: Zona Not So Stubby

R2(config)# router
R2(config-router)#
R2(config-router)#
R2(config-router)#
R2(config-router)#
ospf 1
summary-address 10.0.0.0 255.0.0.0
network 192.168.10.0 0.0.0.3 area 0
network 172.20.3.0 0.0.0.255 area 1
area 1 nssa default-information-originate

R1(config)# router
R1(config-router)#
R1(config-router)#
R1(config-router)#
R1(config-router)#
ospf 2
redistribution rip subnets
default metric 150
network 172.20.3.0 0.0.0.255 area 1
area 1 nssa
R4
107 | O S P F
Pentru ca zona 1 s fie NSSA Totally Stubby, se va folosi opiunea no-summary a comenzii
area nssa. Astfel se va genera automat i o rut default *O N2 pentru zona NSSA, deci nu mai
este necesar folosirea opiunii default-information-originate.
Folosind comanda urmtoare se vor putea vizualiza zonele normale, Stub i NSSA:
R# show ip ospf
Urmtoarea comand afieaz detalii despre LSA de tip 7 din tabela de topologie:
R# show ip ospf database nssa-external
Rutele externe redistribuite de un ASBR din cadrul unei zone NSSA se vor vizualiza folosind
comanda urmtoare:
R# show ip route
5.3.6 Configurarea sumarizrii

OSPF nu realizeaz sumarizarea automat a rutelor la nivel de clas. Comenzile necesare pentru
a configura sumarizarea sunt diferite n funcie de tipul de sumarizare. Tipurile de sumarizri au fost
definite n capitolul 5.2.2.
Sumarizarea ntre zone se realizeaz pe ABR folosindu-se comanda area range care va
determina ruterul s sumarizeze rutele dintr-o anumit zon nainte de a le injecta n zona de
backbone ca LSA de tip 3.
R(config-router)# area id_zona range adresa masca [advertize | notadvertize] [cost cost]
Zona specificat n comanda anterioar este zona din care provin rutele care vor fi sumarizate.
Opiunea not-advertize va opri generarea pachetelor LSA de tip 3, fapt ce va determina
ascunderea reelelor ce fac parte din intervalul specificat de restul zonelor. Opiunea cost este
folosit pentru a configura manual metrica rutei sumarizate care va fi folosit n calculul STP. Costul
specificat trebuie s fie mai mare dect 0 i mai mic dect 16777215.
Sumarizarea rutelor externe se realizeaz pe ASBR nainte de a fi injectate n OSPF ca LSA de tip
5. Se va folosi urmtoarea comand:
R(config-router)# summary-address adresa masca [not-advertize] [tag
eticheta]
Opiunea not-advertize se va folosi pentru a opri redistribuirea intervalului de adrese

specificat. Eticheta va fi folosit pentru a controla redistibuia folosint route maps.
Se va folosi topologia din figura 5-22. Se va configura sumarizare pe cele dou rutere ABR.
Intervalul de adrese de la 172.20.32.0/24 pn la 172.20.63.0/24 va fi sumarizat n intervalul
172.20.32.0/19. Intervalul de adrese de la 172.20.64.0/24 pn la 172.20.95.0/24 va fi sumarizat n
intervalul 172.20.64.0/19. Intervalul de adrese de la 172.20.96.0/24 pn la 172.20.127.0/24 va fi
sumarizat n intervalul 172.20.64.0/19.
R1(config-router)# area 1 range 192.168.32.0 225.255.224.0
Zona 1
Zona 0 (Backbone)
ABR
172.20.32.0/24
pn la
172.20.63.0/24
172.20.96.0/24
pn la
172.20.127.0/24
R1
ABR
R2
Zona 2
172.20.64.0/24
pn la
172.20.95.0/24
Figura 5-22: Sumarizarea pe ABR

Folosind topologia din figura 5-23, se va configura sumarizarea rutelor externe pe ABSR. Rutele
externe primite prin RIP vor fi redistribuite n OSPF pe ruterul R1. Intervalul de adrese de la
172.20.32.0/24 pn la 172.20.63.0/24 va fi sumarizat n intervalul 172.20.32.0/19.
172.20.32.0/24
pn la
172.20.63.0/24
R
RIP
ASBR
Zona 1
ABR
ABR
Zona 0 (Backbone)
R1
R2
R3
Zona 2
R4
Figura 5-23: Sumarizarea rutelor externe pe ASBR

R1(config)# router
R1(config-router)#
R1(config-router)#
R1(config-router)#
ospf 2
redistribution rip subnets
default metric 150
summary-address 172.20.32.0 255.255.224.0
Dac exist o singur ieire din sistemul autonom, n locul redistribuirii rutelor externe n OSPF,
se poate injecta o singur rut default. Pentru a genera o rut default se va folosi comanda:
R(config-router)# default-information originate [always] [metric
metrica] [metric-type tip] [route-map nume]
109 | O S P F
n mod normal aceast comand folosit fr parametri va determina anunarea unei rute
default doar dac pe ruterul respectiv exist deja o ruta default configurat. Folosirea opiunii
always a comenzii default-information originate, va determina anunarea unei rute
default fr ca aceasta s existe n mod explicit n tabela de rutare.
Metrica va specifica costul rutei default, care n mod implicit este 1. Tipul metricii a fost definit
n subcapitolul 5.1.6 i poate fi de tipul E1 sau E2. Se poate specifica un nume de route map.
O rut default va aprea n tabela de topologie ca un LSA extern de tipul 5.
Se va folosi topologia din figura 5-24 pentru a se exemplifica configurarea rutelor default.
ISP1
ISP2
192.168.10.0/24
172.20.3.0/24
Zona 1
ASBR
ABR
ABR
Zona 0 (Backbone)
R1
R2
R3
0.0.0.0 Cost 100
Zona 2
ASBR
R4
0.0.0.0 Cost 10
Figura 5-24: Rute default
Pe ruterul R1 se vor introduce urmtoarele comenzi:

R1(config)# ip route 0.0.0.0 172.20.3.1
R1(config-router)# default-information originate cost 100
Iar pe ruterul R4 urmtoarele comenzi:

R4(config)# ip route 0.0.0.0 192.168.10.1
R4(config-router)# default-information originate cost 10
Va fi preferat calea ctre ISP2 deoarece metrica specificat pentru ruta default prin ISP2 este
mai mic dect ruta default prin ISP1.
5.3.7 Configurarea autentificrii

Pentru a configura OSPF s foloseasc o parol simpl pentru a autentifica ruterele vecine
trebuie parcuri urmtorii pai:
1. Configurarea unei parole care sa fie folosit n comunicaia cu ruterele vecine. Comanda
trebuie introdus pentru fiecare interfa n parte, astfel o parol distinct poate fi configurat
pentru fiecare interfa. Parola trebuie sa corespund pentru interfeele de pe rutere care formeaz
o legtur.
R(config-if)# ip ospf authentication-key parola
Parola trebuie s fie un ir de maxim 8 caractere.
2. Specificarea tipului autentificrii.
R(config-if)# ip ospf authentication [message-digest | null]
Comanda anterior folosit fr nici o opiune va determina autentificarea folosind parola

simpla, trimis n clar. Pentru a se folosi autentificarea prin MD5 se va specifica opiunea messagedigest iar pentru a dezactiva autentificarea se folosete opiunea null.
Se va folosit topologia din figura 5-24, pentru a configura autentificarea prin parola simpl ntre
ruterele R1 i R2.
172.18.2.1/24
Fa0/0
192.168.10.1
R1
S0/0
S0/1
192.168.10.2
172.20.3.1/24
R2
Fa0/0
Figura 5-25: Autentificarea n OSPF

Pentru a configura ruterul R1 trebuie introduse urmtoarele comenzi:
R1(config)# interface S0/0
R1(config-if)# ip ospf authentication-key parola
R1(config-if)# ip ospf autentication

R2(config-if)# ip ospf authentication-key parola
R2(config-if)# ip ospf autentication
Pentru configura autentificarea MD5, o cheie i un identificator de cheie trebuie specificate pe

fiecare ruter. Urmtorii pai trebuie parcuri:
1. Asignarea unei chei i a unui identificator de cheie pe fiecare interfa. O cheie diferit poate
fi configurat pe fiecare interfa n parte. Cheia trebuie sa corespund pentru interfeele de pe
rutere care formeaz o legtur. Acelai identificator de cheie pe ruterul vecin trebuie s aib
ataat aceeai cheie pentru a se realiza autentificarea. Identificatorii de cheie permit tranziiile
ntre chei fr a opri comunicaia pe acea legtur.
R(config-if)# ip ospf message-digest-key id_cheie md5 cheie
Identificatorul cheii trebuie s fie un numr ntre 1 i 255 iar cheia poate s aib pn la 16
caractere. Cheia va fi folosit pentru a genera un rezumat al fiecrui pachet OSPF. Rezumatul va fi
ataat la pachet.
2. Specificarea tipului autentificrii.
R(config-if)# ip ospf authentication message-digest
O comand alternativ care configureaz tipul autentificrii la nivel de zon este urmtoarea:
R(config-router)# area id_zona authentication [message-digest]
Se va folosi topologia din figura 5-24, pentru a configura autentificarea prin MD5 ntre ruterele
R1 i R2.
R1(config-if)# ip ospf message-digest-key 1 md5 secret
R1(config-if)# ip ospf autentication message-digest
111 | O S P F
R2(config-if)# ip ospf message-digest-key 1 md5 secret
R2(config-if)# ip ospf autentication message-digest
n cazul n care autentificare are loc cu succes, se va stabili adiacena ntre cele dou rutere, i
se vor trimite actualizri.
Se va verifica dac ruterele au stabilit o adiacen folosind comanda urmtoare:
Neighbor ID
Interface
192.168.10.2
Serial0/0
Pri
State
Dead Time
Address
FULL/-
00:00:36
192.168.10.2
Pentru a verifica trimiterea de actualizri se poate determinadac ruta ctre 172.20.3.0/24 se

afl n tabela de rutare folosind comanda show ip route sau se poate da ping ctre adresa
172.20.3.1.
Pentru identificarea problemelor n legtur cu autentificarea n OSPF se va folosi comanda
urmtoare:
R1# debug ip ospf adj
00:59:42: OSPF: Send with youngest Key 1
00:59:42: OSPF: 2 Way Communication to 192.168.10.2 on Serial0/0,
state 2WAY
00:59:42: OSPF: Send DBD to 192.168.10.2 on Serial0/0 seq 0x2125 opt
0x42 flag 0x7len 32
00:59:42: OSPF: Rcv DBD from 192.168.10.2 on Serial0/0 seq 0x11F3 opt
0x42 flag 0x7 len 32 mtu 1500 state EXSTART
00:59:42: OSPF: First DBD and we are not SLAVE
00:59:42: OSPF: Rcv DBD from 192.168.10.2 on Serial0/0 seq 0x2125 opt
0x42 flag 0x2 len 72 mtu 1500 state EXSTART
00:59:42: OSPF: NBR Negotiation Done. We are the MASTER
0x42 flag 0x3 len 72
00:59:42: OSPF: Database request to 192.168.10.2
00:59:42: OSPF: sent LS REQ packet to 192.16.10.2, length 12
0x42 flag 0x0 len 32 mtu 1500 state EXCHANGE
0x42 flag 0x1len 32
0x42 flag 0x0 len 32 mtu 1500 state EXCHANGE
00:59:42: OSPF: Exchange Done with 192.168.10.2 on Serial0/0
00:59:42: OSPF: Synchronized with 192.168.10.2 on Serial0/0, state
FULL
00:59:42: %OSPF-5-ADJCHG: Process 10, Nbr 192.168.10.2 on Serial0/0
from
LOADING to FULL, Loading Done
00:59:43: OSPF: Build router LSA for area 0, router ID 172.18.2.1,
seq 0x80000010
Se poate observa c autentificarea s-a realizat cu succes i s-a

format o adiacen ntre cei doi vecini.
5.3.8 Configurarea legturilor virtuale

O legtur virtual se va crea folosind comanda:
R(config-router)# area id_zona virtual-link id_ruter [authentication
[message-digest | null]] [hello-interval secunde] [retransmit-interval
secunde] [transmit-delay secunde] [dead-interval secunde]
[[authentication-key parola] | [message-digest-key id_cheie md5 cheie]]
Zona specificat n comanda anterioar este zona de tranzit prin care trece legtura virtual.
Identificatorul ruterului se refer la identificatorul vecinului din captul cellalt al legturii virtuale.
Parametri de autentificare se folosesc n mod asemntor cu cei folosii impreun cu comanda ip
ospf, descrii n capitolul anterior. Opiunea hello-interval specific numrul de secunde ntre dou
mesaje de tip Hello transmise pe legtura virtual, valoarea implicit fiind de 10 secunde.
Retransmision-interval se refer la intervalul de timp ntre dou retransmisii de LSA, valoarea
implicit fiind de 5 secunde. Transmit-delay este timpul estimat pentru a transmite un pachet de tip
LSU pe interfa, valoarea implicit fiind de 1 secund. Dead-interval este intervalul de timp care
trebuie s treac fr s se primeasc nici un pachet de tip Hello, pentru ca vecinul s fie considerat
inaccesibil.
Folosind topologia din figura 5-25, se va configura o legtur virtual ntre ruterele R2 i R3 prin
zona de tranzit 1 care leag doua zone de backbone.
Zona 0 (Backbone)
10.0.0.0/8
R1
Zona 0 (Backbone)
Zona 1
10.0.0.0/8
Legtura virtual
R2
ID 10.1.1.1
192.168.10.0/24
R3
R4
ID 10.2.2.2

Pe ruterul R2 trebuie introduse urmtoarele comenzi:
R2(config)# router
R2(config-router)#
R2(config-router)#
R2(config-router)#
ospf 1
network 10.0.0.0 0.255.255.255 area 0
network 192.168.10.0 0.0.0.255 area 1
area 1 virtual-link 10.2.2.2
Iar pe ruterul R3 urmtoarele comenzi:

R3(config)# router
R3(config-router)#
R3(config-router)#
R3(config-router)#
ospf 2
network 10.0.0.0 0.255.255.255 area 0
network 192.168.10.0 0.0.0.255 area 1
Pe fiecare ruter trebuie s se specifice identificatorul ruterului vecin.

Pentru a verifica dac legtura virtual functioneaz n mod corect se folosete comanda:
R2# show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 10.2.2.2 is up
Transit area 0.0.0.1, via interface Serial0/0, Cost of using 781
Transmit Delay is 1 sec, State POINT_TO_POINT
Adjacency State FULL
Index 1/2, retransmission queue length 0, number of retransmission 1
113 | O S P F
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 1, maximum is 1
Last retransmission scan time is 0 msec, maximum is 0 msec
Prima linie din output specific dac legtura virtual este activ sau nu. Apoi sunt specificate
informaii despre aria de tranzit, interfaa spre vecin, costul legturii, intervalele configurate i
starea adiacenei.
Folosind comanda show ip ospf neighbor se poate verifica dac s-a stabilit o adiacen cu
vecinul de la cellalt capt al legturii virtuale:
Neighbor ID
Interface
10.10.10.1
FastEth0/0
10.2.2.2
10.2.2.2
Serial0/0
Pri
State
Dead Time
Address
FULL/DR
00:00:35
10.1.1.2
0
0
FULL/FULL/-
00:00:36
192.168.10.2
192.168.10.2
OSPF_VL0
Se observ c s-a stabilit o adiacen cu ruterul care are identificatorul 10.1.2.1 prin legtura
virtual numit OSPF_VL0. De asemenea s-a stabilit o adiacen cu acelai ruter prin legtura
direct.
Se poate verifica dac ruterele schimb LSA-uri folosind urmtoarea comand:
R2# show ip ospf database router 10.1.2.1
OSPF Router with ID (10.1.1.1) (Process ID 1)
Router Link States (Area 0)
Routing bit set on this LSA
LS age: 1 (DoNotAge)
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.2.2.2
Advertising Router: 10.2.2.2
LS Seq Number: 80000003
Checksum: 0xD5DF
Length: 48
Area Border Router
Number of Links: 2
Link connected to: a Virtual Link
(Link ID) Neighboring Router ID: 10.1.1.1
(Link Data) Router Interface address: 192.168.10.2
Number of TOS metrics: 0
TOS 0 Metrics: 781
Link connected to: a Transit Network
(Link ID) Network/subnet number: 10.1.2.2
TOS 0 Metrics: 1
Routing bit set on this LSA
LS age: 1688
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.2.2.2
Advertising Router: 10.2.2.2
LS Seq Number: 80000008
Checksum: 0xCC81
Length: 48
Area Border Router
Virtual Link Endpoint
Number of Links: 2
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 10.1.1.1
TOS 0 Metrics: 781
Link connected to: a Stub Network
(Link ID) Network/subnet number: 192.168.10.0
(Link Data) Network Mask : 255.255.255.0
TOS 0 Metrics: 781
5.4 Studiu de caz

5.4.1 Topologie
Pentru scenariul de mai jos, compania LinkinState decide implementarea protocolului OSPF n
reeaua sa. Compania dorete observarea reelei n cadrul OSPF Single-area, dup care va converti
topologia ntr-una Multi-area.
Testarea capabilitilor protocolului OSPF se va face pe o topologie de 5 rutere cu dou
segmente multiacces FastEthernet i dou segmente point-to-point cu linii seriale.
202.1.[96..99].0/24
10.0.0.0/24
Mercury
F0/0
S1/0
.1
Earth
F0/0
.3
.1
172.30.0.0/30
.2
.2 F0/0
S1/0
Venus
Loopback0
Loopback1
Loopback2
Loopback3
.1 S1/0
172.20.0.0/24
Loopback0
Loopback1
Loopback8
.2
S1/0
.1
F0/0
Mars
.2
F0/0
192.168.0.0/24
201.1.[32..40].0/24
Figura 5-27: Topologie studiu de caz
Topologia de mai sus prezint urmtoarea schem de adresare:
Reeaua switched dintre Earth, Venus i Mercury: 10.0.0.0/24 cu adresele:
Earth FastEthernet 0/0: 10.0.0.1/24
Venus FastEthernet 0/0: 10.0.0.2/24
Mercury FastEthernet 0/0: 10.0.0.3/24
Legtura point-to-point dintre Mercury i Venus: 172.30.0.0/30
Mercury Serial 1/0: 172.30.0.1/30
Venus Serial 1/0: 172.30.0.2/30
Legtura point-to-point dintre Earth i Mars: 172.20.0.0/30
Earth Serial 1/0: 172.20.0.1/30
Jupiter
115 | O S P F
Mars Serial 1/0: 172.20.0.2/30
Legtura FastEthernet dintre Mars i Jupiter: 192.168.0.0/24
Mars FastEthernet 0/0: 192.168.0.1/24
Jupiter FastEthernet 0/0: 192.168.0.2/24
Interfee loopback configurate pe ruterele Venus i Earth, ce simuleaz alte reele ale
topologiei i a cror schem de adresare este descris n output-urile urmtoare.
5.4.2 Configurri OSPF Single-area

Se verific schema de adresare i configurarea interfeelor corespunztoare:
Mercury#show ip interface brief
Interface
IP-Address
FastEthernet0/0
10.0.0.3
Serial1/0
172.30.0.1
OK? Method Status

YES manual up
YES manual up
Protocol
up
up
Venus#show ip interface brief

Interface
IP-Address
FastEthernet0/0
10.0.0.2
Serial1/0
172.30.0.2
Loopback0
201.1.32.1
Loopback1
201.1.33.1
Loopback2
201.1.34.1
Loopback3
201.1.35.1
Loopback4
201.1.36.1
Loopback5
201.1.37.1
Loopback6
201.1.38.1
Loopback7
201.1.39.1
Loopback8
201.1.40.1
OK?
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
Method
manual
manual
manual
manual
manual
manual
manual
manual
manual
manual
manual
Status
up
up
up
up
up
up
up
up
up
up
up
Protocol
up
up
up
up
up
up
up
up
up
up
up
Earth#show ip interface brief

Interface
IP-Address
FastEthernet0/0
10.0.0.1
Serial1/0
172.20.0.1
Loopback0
202.1.96.1
Loopback1
202.1.97.1
Loopback2
202.1.98.1
Loopback3
202.1.99.1
OK?
YES
YES
YES
YES
YES
YES
Method
manual
manual
manual
manual
manual
manual
Status
up
up
up
up
up
up
Protocol
up
up
up
up
up
up
Mars#show ip interface brief

Interface
IP-Address
FastEthernet0/0
192.168.0.1
Serial1/0
172.20.0.2
OK? Method Status

YES manual up
YES manual up
Protocol
up
up
Jupiter#show ip interface brief

Interface
IP-Address
FastEthernet0/0
192.168.0.2
OK? Method Status

YES manual up
Protocol
up
Pentru fiecare ruter n parte, se pornete procesul OSPF i se introduc reelele direct conectate.
Interfeele membre ale acestor reele vor participa n procesul de OSPF respectiv, vor realiza
adiacene cu ali vecini prin reelele respective i vor schimba update-uri de rutare.
OSPF poate rula o multitudine de procese independente. Ruterele adiacente nu necesit acelai
numr de proces configurat pentru a putea comunica. Comenzile de mai jos exemplific pornirea
procesului OSPF pentru Mercury i Earth:
Mercury(config)#router ospf 1
Mercury(config-router)#network 10.0.0.3 0.0.0.255 area 0
Mercury(config-router)#network 172.30.0.0 0.0.0.3 area 0
Earth(config)#router ospf 1
Earth(config-router)#network 10.0.0.0 0.0.0.255 area 0
Earth(config-router)#network 172.20.0.0 0.0.0.3 area 0
Pentru a include n OSPF toate interfeele loopback configurate pe Venus i Earth se pot folosi
comenzi network mai generice:
Venus(config-router)#net 201.1.0.0 0.0.255.255 area 0
Earth(config-router)#net 202.1.0.0 0.0.255.255 area 0
Se verific tabela de rutare pe Jupiter:

Jupiter#sh ip route
[...]
O
202.1.96.1 [110/66] via 192.168.0.1, 00:01:29, FastEthernet0/0
O
O
O
O
O
O
O
O
O
O
O
O
O
O
C
O
Se observ c toate elele

re
incluse n OSPF, alturi de reelele direct conectate, au fost
inserate n tabela de rutare a lui Jupiter.
5.4.2.1 Adiacene, DR, BDR

Identificatorii ruterelor dintr-o reea OSPF sunt setai automat la valoarea celei mai mari adrese
IP configurate pe o interfa
activ (loopback, dac exist cel puin una). Configurarea local a
protocoalelor de rutare precumi Router ID -ul pentru procesul de OSPF pot fi vizualizate prin
comanda show ip protocols. Spre exemplu, pentru ruterul Mercury:
Mercury#show ip protocols
Routing Protocol is "ospf 1"
Router ID 172.30.0.1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
10.0.0.0 0.0.0.255 area 0
117 | O S P F
172.30.0.0 0.0.0.3 area 0
Gateway
Distance
192.168.0.1
110
192.168.0.2
110
202.1.99.1
110
201.1.40.1
110
Distance: (default is 110)
Last Update
00:09:22
00:04:08
00:04:08
00:04:08
Pentru celelalte rutere, Router ID-urile alese automat sunt urmtoarele:

Mercury: Router ID 172.30.0.1
Venus: Router ID 201.1.40.1
Earth: Router ID 202.1.99.1
Mars: Router ID 192.168.0.1
Jupiter: Router ID 192.168.0.2
Schimbarea de update-uri de rutare ntre rutere vecine OSPF se face doar dup stabilirea unei
adiacene. Comanda show ip ospf neighbors din exemplul urmtor listeaz starea
adiacenelor ruterului Venus pe interfeele sale participante in OSPF:
Venus#show ip ospf neighbors
Neighbor ID
Pri
State
172.30.0.1
1
FULL/DR
202.1.99.1
1
FULL/BDR
172.30.0.1
0
FULL/ -
Dead Time
00:00:35
00:00:31
00:00:33
Address
Interface
10.0.0.3 FastEthernet0/0
10.0.0.1 FastEthernet0/0
172.30.0.1
Serial1/0
Pentru Venus, Mercur este un vecin conectat printr-o legtur point-to-point, pentru care
stabilirea unui DR/BDR nu este necesar. Pentru reeaua switched dintre Venus, Mercur i Earth,
fiind un mediu multiacces, se alege un DR i un BDR care vor reprezenta aceast reea prin LSA-urile
lor. Din output-ul de mai sus se poate observa c Venus a stabilit o adiacen de tip DR cu vecinul cu
ID-ul 172.30.0.1 (adic Mercury, conform listei de mai sus)
i una de tip BDR cu Earth. Din acest
output se deduce faptul c Mercury a fost ales DR iar Earth a fost ales BDR al segmentului
multiacces respectiv.
Din perspectiva lui Mercury, i acesta a stabilit dou tipuri de relaii de adiacen cu Venus, prin
legtura serial i cea multiacces. n segmentul de reea dintre cele trei rutere, Venus se afl n
relaia DROTHER cu Mercury deoarece nu este nici DR i nici BDR.
Mercury#show ip ospf neighbors
Neighbor ID
201.1.40.1
201.1.40.1
202.1.99.1
Pri
0
1
1
State
FULL/ FULL/DROTHER
FULL/BDR
Dead Time
00:00:38
00:00:39
00:00:35
Address
Interface
172.30.0.2
Serial1/0
10.0.0.2
FastEthernet0/0
10.0.0.1
FastEthernet0/0
Parametrii OSPF configurai pe fiecare interfa, precum i situaia DR/BDR pe segmentul

respectiv, pot fi vizualizate prin comanda show ip ospf interface. Exemplificare pentru
Mercury:
Venus#show ip ospf interface fastethernet0/0
Internet Address 10.0.0.2/24, Area 0
Process ID 1, Router ID 201.1.40.1, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DROTHER, Priority 1
Designated Router (ID) 172.30.0.1, Interface address 10.0.0.3
Backup Designated router (ID) 202.1.99.1, Interface address 10.0.0.1
oob-resync timeout 40
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Adjacent with neighbor 202.1.99.1 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
Alegerea DR-ului i a BDR-ului pe segmentul de reea multiacces n cauz se face, n principiu,

pe baza prioritii configurate pe fiecare interfa. Din moment ce prioritile celor 3 rutere sunt la
valoarea implicit (1), decizia se ia pe baza Router ID-ului. Dup cum se poate observa, ide
prioritile se afl la valorile implicite, ruterul ales ca DR nu este ruterul cu Router ID-ul cel mai
mare. Acest lucru se datoreaz faptului c cele 3 rutere nu au pornit simultan, astfel c primul ruter
s-a declarat DR. Alegerea DR-ului n OSPF nu e preemptiv, deci un ruter cu un Router ID superior
sau o prioritate mai bun nu va deveni DR atta timp ct nu este primul ruter care porne
te pe
segmentul respectiv.
Comanda pentru modificarea prioritii unui ruter este ip ospf priority, se introduce
explicit pe interfaa conectat la segmentul multiacces i accept valori ntre 0 i 255. De asemenea,
pentru alterarea manual a deciziei de alegere a DR/BDR pe baza Router ID-urilor, acestea pot fi
modificate prin comanda urmtoare:
Mercury(config-router)#router-id 172.30.0.1
n momentul de fa, ruterul Mercury este DR iar ruterul Earth este BDR. Pentru a putea fora
alegerea ruterului Earth ca DR pentru segmentul Ethernet se va realiza resetarea procesului de
OSPF pe ruterul Mercury, ceea ce va avea ca efect i resetarea adiacenelor cu celelalte rutere.
Mercury#clear ip ospf process
Reset ALL OSPF processes? [no]: y
Mesajele de syslog indic adiacenele czute:

Mercury#
*Mar 1 03:00:40.551: %OSPF-5-ADJCHG: Process 1, Nbr 201.1.40.1 on
Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
FastEthernet0/0 from 2WAY to DOWN, Neighbor Down: Interface down or
detached
FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or
detached
Dup cteva secunde, adicenele revin pentru fiecare vecin n parte:

*Mar 1 03:00:40.607: %OSPF-5-ADJCHG: Process
Serial1/0 from LOADING to FULL, Loading Done
FastEthernet0/0 from LOADING to FULL, Loading
FastEthernet0/0 from LOADING to FULL, Loading
1, Nbr 201.1.40.1 on
1, Nbr 201.1.40.1 on
Done
1, Nbr 202.1.99.1 on
Done
Analiznd rezultatul de pe interfaa lui Venus, obinem urmtoarele informaii:

Venus#sh ip ospf inte fa0/0 | inc Adj
Adjacent with neighbor 172.30.0.1
Ruterul Earth a fost BDR

i a devenit automat DR dup ce a pierdut adiacena cu DR
precedent.
-ul
119 | O S P F
Identificarea ruterelor dintr-o topologie OSPF dup Router ID poate fi dificil. OSPF pune la
dispoziie o metod de rezolvare a adreselor IP din output-urile comenzilor sale astfel nct n locul
acestora s fie afiate, spre exemplu, hostname-urile ruterelor vecine.
Spre exemplu, pentru ruterul Earth se folosete urmtoarea comand:
Earth(config)#ip ospf name-lookup
n continuare, se definesc intrri statice pentru toate Router ID-urile ruterelor vecine:
Earth(config)#ip host Mercury 172.30.0.1
Earth(config)#ip host Venus 201.1.40.1
Earth(config)#ip host Mars 192.168.0.1
Putem testa rezultatul prin comanda urmtoare:

Earth(config)#do show ip ospf neighbors
Neighbor ID
Pri
Interface
Mars
0
Serial1/0
Mercury
1
FastEthernet0/0
Venus
1
FastEthernet0/0
State
Dead Time
Address
00:00:35
172.20.0.2
FULL/DROTHER
00:00:37
10.0.0.3
FULL/BDR
00:00:34
10.0.0.2
FULL/
Pentru topologia de mai sus sunt transmise doar dou tipuri de LSA-uri, de tip 1 i 2. Se poate
verifica acest lucru de pe orice ruter:
Earth#sh ip ospf database
Link ID
172.30.0.1
192.168.0.1
192.168.0.2
201.1.40.1
202.1.99.1
ADV Router
172.30.0.1
192.168.0.1
192.168.0.2
201.1.40.1
202.1.99.1
Age
1430
237
160
1450
1449
Seq#
0x80000012
0x8000000A
0x80000008
0x80000012
0x80000011
Checksum
0x0064E7
0x00B877
0x00EA93
0x0062B8
0x003FE5
Link count
3
3
1
12
7
Net Link States (Area 0)

Link ID
10.0.0.1
192.168.0.2
ADV Router
202.1.99.1
192.168.0.2
Age
1429
160
Seq#
Checksum
0x80000002 0x00D039
0x80000007 0x0092F4
Se observ faptul c LSA-urile de tip 2 sunt transmise de ctre DR-urile fiecrei re

ele
multiacces (reeaua 10.0.0.0/24 cu ruterul Earth, respectiv reeaua 192 .168.0.0/24 cu ruterul
Jupiter).
5.4.2.2 Rute default, redistribuire

Pentru a configura ruterul Mercury s injecteze o rut default n topologie se
tefolose
comanda urmtoare:
Mercury(config-router)#default-information originate
Verificnd oricare tabel de rutare, chiar i a vecinilor, se observ c ruta default nu a fost
propagat:
Venus#show ip route | include Gateway
Mercury nu va propaga o rut default atta timp ct el nsui nu deine o rut default n tabela
sa de rutare. Pentru a nu ine cont de aceast condiie, comanda poate fi introdus n felul urmtor:
Mercury(config-router)#default-information originate always
Venus#show ip route
[]
[]
O*E2 0.0.0.0/0 [110/1] via 10.0.0.3, 00:00:03, FastEthernet0/0
Evident, se poate definii o rut default propriu -zis pe ruterul Mercury, iar defaultinformation originate va propaga acea rut.
Pentru a analiza modul de redistribuire a rutelor, se va crea o rut static spre o destinaie
fictiv i se va redistribui n procesul de OSPF:
Mercury(config)#ip route 99.99.99.99 255.255.255.255 null0
Mercury(config-router)#redistribute static subnets
re
Parametrul subnets este obligatoriu pentru a evita redistribuirea exclusiv a elelor
classful.
Rutele externe vor aprea n mod implicit n tabela de rutare ca fiind rute de tip O E2. Ca
i n
exemplul anterior, n care o rut default a fost injectat n topologie, redistribuirea este echivalent
cu introducerea n OSPF a unor rute din exteriorul domeniului su de rutare. Pentru confirmare, se
poate verifica tabela de rutare de pe Venus, care indic LSA-urile de tip 5 corespunztoare rutei
default i celei redistribuite:
Venus#show ip ospf database
Link ID
172.30.0.1
192.168.0.1
192.168.0.2
201.1.40.1
202.1.99.1
ADV Router
172.30.0.1
192.168.0.1
192.168.0.2
201.1.40.1
202.1.99.1
Age
1010
1725
1672
1133
1025
Seq#
0x80000016
0x8000000C
0x8000000A
0x80000015
0x80000014
Checksum
0x0062E3
0x00B479
0x00E695
0x005CBB
0x0039E8
Link count
3
3
1
12
7

Link ID
10.0.0.1
192.168.0.2
ADV Router
202.1.99.1
192.168.0.2
Age
1025
1672
Seq#
Checksum
0x80000005 0x00CA3C
0x80000009 0x008EF6
Type-5 AS External Link States

Link ID
0.0.0.0
99.99.99.99
ADV Router
172.30.0.1
172.30.0.1
Age
487
254
Seq#
Checksum Tag
0x80000002 0x0030B5 1
0x80000001 0x000344 0
Metrica rutei redistribuite, din perspectiva lui Venus, spre exemplu, este 20. Verificnd aceeai
rut i pe Jupiter, se constat c aceasta continu s aib aceeai valoare, constant, indiferent de
ruterul care o introduce n tabela de rutare:
Venus#show ip route ospf
[...]
O E2
121 | O S P F
Jupiter#show ip route ospf
[...]
O E2
Metrica implicit, de 20, a rutelor externe poate fi modificat att global cti pentru rutele
explicit redistribuite. n cazul de fa, urmtoarele dou comenzi introduse pe Mercury au acelai
rezultat:
Mercury(config-router)#default-metric 99
Mercury(config-router)#redistribute static subnets metric 99
[...]
O E2
O valoare constant a metricii este suficient n momentul n care exist un singur ASBR n
topologie, deoarece nu exist o alternativ pentru ieirea spre rute externe. Dac, ns, mai multe
ASBR-uri introduc rute externe ctre acelea
i destinaii, ruterele trebuie s poat alege cea mai
eficient cale spre o anumit destina
ie extern. Pentru aceasta, rutele redistribuit
e pot fi
convertite la tipul E1, care adun la metrica implicit
i suma metricilor din interiorul domeniului
OSPF 1:
Mercury(config-router)#redistribute static subnets metric 99 metric-type 1
Comanda introdus ca i anterior, cu parametrul metric-type 1, va introduce ruta extern

ca o rut E1. Rezultatul poate fi confirmat pe Venus i Jupiter:
Venus#show ip route ospf
[...]
O E1
[...]
O E1
Pentru Venus, ruta are valoarea 100 deoarece acesta adaug 1 (108/108 pentru reele
FastEthernet) la metrica 99 de redistribuire. Jupiter vede reeaua cu metrica 165, obinut din 99 +
2x1 + 64, adic dou segmente FastEtherneti un segment de linie serial (10 8/(1544*103) = 64
Kbps pentru o linie serial de vitez T1).
5.4.3 Configurare OSPF Multi-area

Pentru a converti topologia anterioar la una Multi-area, se vor face urmtoarele modificri:
Interfeele loopback definite pe ruterul Venus vor fi trecute n Area 100;
Interfeele loopback definite pe ruterul Earth vor fi trecute n Area 200;
Reeaua multiacces dintre Mercury, Venus i Earth rmne n Area 0, mpreun cu legtura
dintre Mercury i Venus;
Legtura dintre Earth i Mars devine Area 7;
Reeaua dintre Mars i Jupiter devine extensie pentru Area 7.
Se observ faptul c aceeai comand este folosit cu acelai efect i de ctre IS-IS.
Area 0
202.1.[96..99].0/24
10.0.0.0/24
Mercury
F0/0
S1/0
.1
Earth
F0/0
.3
.1
172.30.0.0/30
.2
.2 F0/0
S1/0
Venus
Loopback0
Loopback1
Loopback2
Loopback3
Area 200
.1 S1/0
172.20.0.0/24
Loopback0
Loopback1
Loopback8
Area 7
.2
S1/0
.1
F0/0
Mars
.2
F0/0
192.168.0.0/24
Jupiter
201.1.[32..40].0/24
Area 100
Figura 5-28: Topologie multi-area
Configuraia de baz pentru OSPF Multi-area, pe cele 5 rutere, este urmtoarea:
Mercury#sh run | b router
router ospf 1
router-id 172.30.0.1
redistribute static metric 99 metric-type 1 subnets
network 10.0.0.0 0.0.0.255 area 0
network 172.30.0.0 0.0.0.3 area 0
default-information originate always
default-metric 99
Venus#sh run | b router
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 172.30.0.0 0.0.0.3 area 0
network 201.1.0.0 0.0.255.255 area 100
Earth#sh run | b router
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 172.20.0.0 0.0.0.3 area 7
network 202.1.0.0 0.0.255.255 area 200
Mars#sh run | b router
router ospf 1
network 172.20.0.0 0.0.0.3 area 7
network 192.168.0.0 0.0.0.255 area 7
Jupiter#sh run | b router
router ospf 1
network 192.168.0.0 0.0.0.255 area 7
ntr-o topologie Multi-area, reelele din arii diferite sunt anunate prin LSA -uri de tip 3
(summary). Pentru ruterul Jupiter din area 7, spre exemplu, elele
re
din ariile 0, 100 i 200 sunt
primite ca summary LSA, dup cum se observ i din link state database-ul su:
Jupiter#sh ip ospf data
123 | O S P F

Link ID
192.168.0.1
192.168.0.2
202.1.99.1

ADV Router
Age
192.168.0.1
27
192.168.0.2
58
202.1.99.1
337
Seq#
0x80000005
0x80000004
0x80000004
Link ID
192.168.0.2

ADV Router
Age
192.168.0.2
58
Seq#
Checksum
0x80000003 0x009AF0
Link ID
10.0.0.0
172.30.0.0
201.1.32.1
201.1.33.1
201.1.34.1
201.1.35.1
201.1.36.1
201.1.37.1
201.1.38.1
201.1.39.1
201.1.40.1
202.1.96.1
202.1.97.1
202.1.98.1
202.1.99.1
Summary Net Link States (Area 7)

ADV Router
Age
Seq#
202.1.99.1
337
0x80000003
202.1.99.1
337
0x80000003
202.1.99.1
337
0x80000003
202.1.99.1
337
0x80000003
202.1.99.1
337
0x80000003
202.1.99.1
337
0x80000003
202.1.99.1
340
0x80000003
202.1.99.1
340
0x80000003
202.1.99.1
340
0x80000003
202.1.99.1
340
0x80000003
202.1.99.1
340
0x80000003
202.1.99.1
1580
0x80000004
202.1.99.1
1580
0x80000004
202.1.99.1
1580
0x80000004
202.1.99.1
1580
0x80000004
Link ID
172.30.0.1
Summary ASB Link States (Area 7)

ADV Router
Age
Seq#
Checksum
202.1.99.1
340
0x80000003 0x0062DA
Link ID
0.0.0.0
99.99.99.99

ADV Router
Age
172.30.0.1
676
172.30.0.1
928
Checksum
0x00C272
0x00F28F
0x00C78E
Link count
3
1
2
Checksum
0x0026D9
0x00EA17
0x00FB21
0x00F02B
0x00E535
0x00DA3F
0x00CF49
0x00C453
0x00B95D
0x00AE67
0x00A371
0x0020BB
0x0015C5
0x000ACF
0x00FED9
Seq#
Checksum Tag
0x8000000E 0x0018C1 1
0x8000000A 0x0086E8 0
n continuare, rutele redistribuite sunt primite prin LSA-uri de tip 5.

De asemenea, LSA-urile de tip 3 creeaz rute de tip inter-area (IA) vizibile i n tabela de rutare:
Jupiter#sh ip route
[...]
O IA
202.1.96.1 [110/66] via 192.168.0.1,
O IA
201.1.39.1 [110/67] via 192.168.0.1,
O IA
202.1.97.1 [110/66] via 192.168.0.1,
O IA
201.1.38.1 [110/67] via 192.168.0.1,
O IA
202.1.98.1 [110/66] via 192.168.0.1,
[...]
01:09:56, FastEthernet0/0
5.4.3.1 Sumarizarea rutelor

Ruterele Venus i Earth sunt ABR-uri ce conecteaz ariile 100, respectiv 200 la backbone (Area
0). ABR-urile pot realiza sumarizare inter-area. n cazul de ,
fa este convenabil sumarizarea
reelelor de loopback de pe ambele rutere ntr-o singur reea generic, urmnd ca doar aceast
reea s fie anunat n Area 0.
Venus#show ip interface brief | inc Loop
Loopback0
201.1.32.1
YES NVRAM
up
up
Loopback1
201.1.33.1
YES NVRAM up
Loopback2
201.1.34.1
YES NVRAM up
Loopback3
201.1.35.1
YES NVRAM up
Loopback4
201.1.36.1
YES NVRAM up
Loopback5
201.1.37.1
YES NVRAM up
Loopback6
201.1.38.1
YES NVRAM up
Loopback7
201.1.39.1
YES NVRAM up
Loopback8
201.1.40.1
YES NVRAM up
Venus#conf t
Venus(config)#router ospf 1
Venus(config-router)#area 100 range 201.1.32.0 255.255.240.0
up
up
up
up
up
up
up
up
Pe Venus, reelele interfeelor looback au fost sumarizate la adresa 201.1.32.0/20. Acest prefix
este acum vizibil att n Area 0 cti n celelalte arii. O sumariza re similar se realizeaz i pentru
reelele ruterului Earth:
Earth#show ip int brief | inc
Interface
IP-Address
Loopback0
202.1.96.1
Loopback1
202.1.97.1
Loopback2
202.1.98.1
Loopback3
202.1.99.1
Earth#conf t
Enter configuration commands,
Earth(config)#router ospf 1
Earth(config-router)#area 200
Loop
OK? Method
YES NVRAM
YES NVRAM
YES NVRAM
YES NVRAM
Status
up
up
up
up
one per line.
Protocol
up
up
up
up
End with CNTL/Z.
range 202.1.96.0 255.255.252.0
Earth anun n Area 0 reeaua sumarizat 202.1.96.0/22. n final, rutele sumarizate sunt
anunate n toate celelalte arii:
Jupiter#sh ip route
[...]
O E1
O
O IA
O IA
C
O IA 202.1.96.0/22 [110/66] via 192.168.0.1, 00:01:27, FastEthernet0/0
5.4.3.2 Arii Stub

Presupunnd c ruterele din aria 7 sunt mai pu
in performante, se poate lua decizia de a
converti aceast arie ntr-un Stub. Se specific acest lucru pe toate ruterele care au celinpuo
interfa n aria respectiv. Drept rezultat, aria 7 nu va mai primi rutele anunate prin LSA-uri de tip
5 (rutele externe, redistribuite) i va primi doar o rut default n locul lor. Configurarea se face prin
comenzile urmtoare:
Earth(config-router)#area 7 stub
Mars(config-router)#area 7 stub
Jupiter(config-router)#area 7 stub
Se observ c, n tabela de rutare a lui Jupiter, cele dou rute externe au fost nlocuite de o rut
default, inter-area:
Jupiter(config-router)#do sh ip route
125 | O S P F
O
O IA
O IA
C
O*IA
O IA
O IA

Mai mult chiar, ruterele din aria 7 pot primi o rut default pentru toate rutele din afara ariei 7,
nu doar cele externe. Pentru aceasta, se specific pe ABR (Earth) faptul c aceast arie nu va
accepta LSA-uri de tip 3, crend astfel o arie Totally Stubby:
Earth(config-router)#area 7 stub no-summary
Dup cum se observi din sintaxa comenzii, ABR -ul nu va mai injecta n aria 7 rutele de tip
summary (tip 3) cu excep
ia unei singure rute, cea default. Comanda poate fi da t doar pe ABR
deoarece acesta este responsabil cu introducerea LSA-urilor de tip 3.
Tabela de rutare de pe Jupiter arat acum doar rutele direct conectate, cele locale (din Area 7),
precum i ruta default ce indic direcia spre ABR:
Jupiter(config-router)#do sh ip route
O
C
O*IA 0.0.0.0/0 [110/66] via 192.168.0.1, 00:00:05, FastEthernet0/0
De asemenea, n link state database LSA-ul rutei default este singurul LSA de tip 3:
Jupiter#sh ip ospf data
Link ID
192.168.0.1
192.168.0.2
202.1.99.1

ADV Router
Age
192.168.0.1
674
192.168.0.2
389
202.1.99.1
682
Seq#
0x80000008
0x80000007
0x80000007
Link ID
192.168.0.2

ADV Router
Age
192.168.0.2
389
Seq#
Checksum
0x80000006 0x00B2D7
Link ID
0.0.0.0

ADV Router
Age
Seq#
Checksum
202.1.99.1
264
0x80000002 0x00C844
Checksum
0x00DA59
0x000B76
0x00DF75
Link count
3
1
2
Pentru a putea pstra caracteristica de Stub a ariei 7, dar a permite injectarea de rute externe,
aceasta poate fi configurat ca o arie Not-So-Stubby (NSSA). O arie NSSA ce nu accept dect o rut
default pentru rutele externe i cele din alte arii este o arie NSSA Totally Stubby. Singurele LSA -uri
acceptate ntr-o astfel de arie sunt cele de tip 1, 2, ruta default ca singurul LSA de tip i
3 LSA -urile
de tip 7 reprezentnd rutele externe injectate prin aria NSSA.
Earth(config-router)#no area 7 stub
Earth(config-router)#area 7 nssa no-summary
Mars(config-router)#no area 7 stub
Mars(config-router)#area 7 nssa
Jupiter(config-router)#no area 7 stub
Jupiter(config-router)#area 7 nssa
Pentru a demonstra prezena LSA-urilor de tip 7 se redistribuie o rut static de pe Jupiter:
Jupiter(config)#ip route 133.33.33.0 255.255.255.0 null0
Jupiter(config)#router ospf 1
Jupiter(config-router)#redistribute static subnets metric 180
Tabela de rutare de pe Mars arat aceast rut anun

at printr -un LSA de tip 7 ca fiind de tip
N2:
Mars(config-router)#do sh ip route
C
C
O N2
O*IA 0.0.0.0/0 [110/65] via 172.20.0.1, 00:10:01, Serial1/0
De asemenea, n baza sa de date link-state, ruta este identificat printr-un LSA de tip 7:
Mars(config-router)#do sh ip ospf data
Link ID
192.168.0.1
192.168.0.2
202.1.99.1
ADV Router
192.168.0.1
192.168.0.2
202.1.99.1
Age
676
676
685
Seq#
0x8000000B
0x80000009
0x8000000A
Checksum
0x005CCC
0x0094E0
0x0067E0
Link count
3
1
2

Link ID
192.168.0.2
ADV Router
192.168.0.2
Age
677
Seq#
Checksum
0x80000008 0x00364A

Link ID
0.0.0.0
ADV Router
202.1.99.1
Age
711
Seq#
Checksum
0x80000004 0x004CB6
Type-7 AS External Link States (Area 7)

Link ID
133.33.33.0
ADV Router
192.168.0.2
Age
682
Seq#
Checksum Tag
0x80000001 0x000C4B 0
Deoarece LSA-urile de tip 7 nu sunt permise dect n ariile de tip NSSA, la prsirea acestora
ABR-urile le convertesc n LSA-uri de tip 5. n consecin, Mercury, spre exemplu, va primi ruta spre
133.33.33.0/24 cu tipul E2:
Mercury#sh ip route
[...]
O E2
ntr-adevr, ruta este anunat printr-un LSA de tip 5, conform bazei de date de pe Mercury:
Mercury#sh ip ospf database | begin Type-5
Link ID
0.0.0.0
99.99.99.99
133.33.33.0
ADV Router
172.30.0.1
172.30.0.1
202.1.99.1
Age
403
655
880
Seq#
0x80000010
0x8000000C
0x80000001
Checksum
0x0014C3
0x0082EA
0x00D1CA
Tag
1
0
0
127 | O S P F
5.4.3.3 Autentificare
Pentru demonstrarea capabilitilor de autentificare OSPF, pachetele protocolului de rutare vor
fi autentificate dup urmtoarea schem:
Area 0: autentificare MD5; ruterele vor calcula un hash pe baza parolei i a coninutului fiecrui
pachet iar parola nu va fi transmis clear-text. De asemenea, pachetele vor fi protejate mpotriva
atacurilor de tip replay prin numere de secven.
Area 7: autentificare clear-text; parola va fi transmis n clar mpreun cu pachetele.
Exemplificare pentru Area 0 i 7: ruterele Mercury, Earth i Mars:
Mercury:
Mercury#show run
interface FastEthernet0/0
ip address 10.0.0.3 255.255.255.0
ip ospf message-digest-key 1 md5 cisco
!
interface Serial1/0
ip address 172.30.0.1 255.255.255.252
!
router ospf 1
router-id 172.30.0.1
area 0 authentication message-digest
redistribute static metric 99 metric-type 1 subnets
network 10.0.0.0 0.0.0.255 area 0
network 172.30.0.0 0.0.0.3 area 0
default-information originate always
default-metric 99
Earth:
Earth#show run
ip address 10.0.0.1 255.255.255.0
!
interface Serial1/0
ip address 172.20.0.1 255.255.255.252
ip ospf authentication
ip ospf authentication-key ciscokey
!
router ospf 1
area 7 authentication
area 7 nssa no-summary
area 200 range 202.1.96.0 255.255.252.0
network 10.0.0.0 0.0.0.255 area 0
network 172.20.0.0 0.0.0.3 area 7
network 202.1.0.0 0.0.255.255 area 200
Mars:
Mars#show run
ip address 192.168.0.1 255.255.255.0
ip ospf authentication-key ciscolan
!
interface Serial1/0
ip address 172.20.0.2 255.255.255.252
!
router ospf 1
area 7 nssa
network 172.20.0.0 0.0.0.3 area 7
network 192.168.0.0 0.0.0.255 area 7
Indiferent de metoda de autentificare folosit, cheia trebuie s fie aceeai doar ntre vecinii din
acelai segment, dup cum se observ din configuraia lui Mars, care are configurate cheile
ciscolan i ciscokey pe interfee diferite aflate n aceeai arie.
5.4.3.4 Legturi virtuale

Configurarea unei legturi virtuale este util n una dintre situaiile urmtoare:
Imposibilitatea fizic a conectrii unei arii la aria de backbone (Area 0);
Conectarea a dou arii de backbone separate.
Area 0
202.1.[96..99].0/24
10.0.0.0/24
Mercury
F0/0
S1/0
.1
Earth
F0/0
.3
.1
172.30.0.0/30
.2
.2 F0/0
S1/0
Venus
Loopback0
Loopback1
Loopback2
Loopback3
Area 200
.1 S1/0
Virtual link
172.20.0.0/24 Area 7
Loopback0
Loopback1
Loopback8
.2
S1/0
Area 0
.1
.2
F0/0
Mars
F0/0
192.168.0.0/24
Jupiter
201.1.[32..40].0/24
Area 100
Figura 5-29: Topologie multi-area cu virtual link
Pentru topologia curent, legtura dintre Marsi Jupiter va fi trecut n Area 0 iar legtura
dintre Earth i Mars va rmne n Area 7. Cele dou arii 0 distincte trebuie conectate cu o legtur
virtual configurat ntre Earthi Mars. Totodat, trebuie avute n vedere dou elemente de
configuraie ce trebuie rezolvate nainte ca legtura s fie funcional:
Area 7 nu poate fi arie de tranzit pentru o legtur virtual atta timp ct este o arie Stub (de
orice fel), deoarece ariile stub nu pot conine rute externe i, deci, nu pot fi folosite corect drept arii
de tranzit.
Dup configurarea segmentului dintre Marsi Jupiter ca membru n Area 0, interfeele din
acest segment trebuie configurate cu aceiai parametri de autentificare ca i Area 0. De asemenea,
legtura virtual trebuie sa specifice faptul c vor fi transportate pachete autentificate.
n continuare sunt exemplificate configura
iile relevante pentru crearea legt urii virtuale
pentru ruterele Earth, Mars i Jupiter:
129 | O S P F
Earth:
Earth#show run
interface Serial1/0
ip address 172.20.0.1 255.255.255.252
!
router ospf 1
area 7 virtual-link 192.168.0.1 message-digest-key 1 md5 cisco
area 200 range 202.1.96.0 255.255.252.0
network 10.0.0.0 0.0.0.255 area 0
network 172.20.0.0 0.0.0.3 area 7
network 202.1.0.0 0.0.255.255 area 200
Mars:
Mars#show run
ip address 192.168.0.1 255.255.255.0
!
interface Serial1/0
ip address 172.20.0.2 255.255.255.252
!
router ospf 1
area 7 virtual-link 202.1.99.1 message-digest-key 1 md5 cisco
network 172.20.0.0 0.0.0.3 area 7
network 192.168.0.0 0.0.0.255 area 0
Jupiter:
Jupiter#show run
ip address 192.168.0.2 255.255.255.0
!
router ospf 1
area 7 nssa
redistribute static metric 180 subnets
network 192.168.0.0 0.0.0.255 area 0
Configurarea parial sau lipsa configurrii unei legturi virtuale n condiiile n care legtura
dintre Mars i Jupiter este n Area 0 are ca efect emiterea repetat a urmtorului mesaj de syslog:
*Mar 1 14:04:46.824: %OSPF-4-ERRRCV: Received invalid packet: mismatch
area ID, from backbone area must be virtual-link but not found from
172.20.0.1, Serial1/0
De asemenea, lipsa unei legturi virtuale mpiedic ruterele din Area 0, definit ntre Mars
i
Jupiter, s comunice LSA-uri cu restul sistemului autonom. n consecin
, tabela de rutare a lui
Jupiter va afia doar rutele statice, direct conectate, precum i ruta direct conectat a lui Mars:
Jupiter(config-if)#do sh ip route
O IA
C
S
133.33.33.0 is directly connected, Null0
Dup configurarea legturii virtuale, tabela de rutare a lui Jupiter eaz

afi rutele comunicate
din toate ariile:
Jupiter#sh ip route
O E1
O IA
O
O
C
S
133.33.33.0 is directly connected, Null0
O observaie important n acest caz este faptul c Jupiter vede acum ruta spre reeaua
10.0.0.0, din Area 0 dintre Mercury, Venusi Earth, ca fiind anunat prin LSA -uri de tip 2. Datorit
legturii virtuale, Jupiter are acum interfaa FastEthernet0/0 conectat direct la Area 0. Segmentele
ariei 0 conectate de legturi virtuale formeaz o singur arie continu de backbonei nu genereaz
rute inter-area.
Jupiter(config-if)#do sh ip ospf data | begin Net
Link ID
10.0.0.1
192.168.0.2
ADV Router
202.1.99.1
192.168.0.2
Age
51
1839
Seq#
Checksum
(DNA) 0x80000018 0x00A44F
0x80000001 0x009EE
6 IS-IS
6.1 Componentele protocolului

6.1.1 ISO vs. IETF
La nceputul anilor `80 succesul DARPA a dus la dezvoltarea a numeroase reele de calculatoare,
mai ales n jurul universitilor americane. Trecerea de la o infrastructur de comunicaie ce trebuia
s asigure conectivitate pentru cteva noduri (precum n cazul DARPA), la o reea cu sute de mii de
participani a adus n discuie problema standardizrii.
Soluia propus de IETF a fost stiva de protocoale TCP/IP. n cadrul acestui model, IETF a propus
mai nti dou protocoale de rutare: un protocol bazat pe vectori de distan, RIP i un protocol
bazat pe starea conexiunilor, OSPF. Extinderea Internetului spre o reea de sute de milioane de
participani a fcut necesar introducerea unui nou nivel de ierarhizare a informaiilor de rutare,
prin gruparea n sisteme autonome, i prin protocolul BGP.
O soluie istoric anterioar modelului IETF a fost propus de ISO, prin stiva de protocoale OSI.
Protocolul rutat din cadrul acestui model este CLNP, iar protocolul de rutare este ISIS. n SUA,
pentru mai bine de 15 ani, toate sistemele diniile
institu
guvernamentale trebuiau s fie
compatibile ISO, cu alte cuvinte, s ofere suport pentru CLNP i ISIS. Cu toate acestea, succesul de
care s-au bucurat standardele IETF, au limitat numrul implementrilor de ISIS.
ISIS ofer o schem de adresare ierarhic, cu un spaiu de adrese mult mai mare dect cel oferit
de IPv4. Overheadul impus de schimbul informaiilor de rutare este redus (mai sczut dect n cazul
OSPF). Astfel, prin extinderea suportului pentru adresarea IPv4, i prin standardizarea IETF, ISIS a
devenit un concurent puternic pentru OSPF. Varianta standardizat, cu suport pentru IP, poart
denumirea de Integrated ISIS, iar pe parcursul acestei cri, prin ISIS ne vom referi varianta extins
pentru integrarea cu adresarea IPv4.
Dei mult mai popular n SUA, exist numeroase implementri de ISIS, n nucleu unor furnizori
de servicii Internet din Romnia. Una dintre cele mai impresionante soluii ISIS este reeaua de
peste 1000 de rutere din Vodafone Romnia.
6.1.2 Rutarea cu IS-IS

Protocoalele de rutare sunt grupate n dou categorii: protocoale de rutare n interiorul
sistemului autonom (IGP), i protocoale inter-AS, denumite generic EGP. ISIS a fost proiectat s
ofere reguli pentru publicarea informaiilor de rutare att ntre echipamente aflate n cadrului
aceluiai AS, ct i pentru sisteme aflate n sisteme autonome diferite. Mai mult chiar, ISIS stabilete
reguli pentru prin care ruterul de ieire din reeaua local poate fi cunoscut de staiile din LAN. Cu
alte cuvinte, ntr-o reea ISO, conectivitatea end-to-end se realizeaz doar printr-un singur protocol,
ce ndeplinete trei obiective distincte: rutarea inter-AS, intra-AS i n LAN.
Rutarea inter-domenii, sau rutarea inter-AS, este realizat de un proces separat. Acest proces
poart numele de rutare de nivel 3.
Pentru asigurarea rutrii ierarhice n cadrul aceluiai sistem autonom, ISIS grupeaz sistemele
n arii, folosind dou procese diferite de rutare. Rutarea de nivel 1 ofer conectivitate intra-area.
Conectivitatea tuturor ariilor se realizeaz prin procesul de rutare de nivel 2.
n terminologia ISO, staiile poart denumirea de end-system (ES), iar ruterele sunt numite
intermediate-system (IS), deci operaiile de rutare sunt realizate exclusiv de ctre IS-uri. Astfel,
conectivitatea la nivelul reelei locale este realizat de o component a protocolului ISIS, denumit
ES-IS. ES-IS nu i gsete corespondentul n Integrated ISIS, n reelele IPv4 funcia aceasta fiind
realizat de protocolul ARP.
n figura 6-1 sunt prezentate cele patru procese de rutare folosite de ISIS. Integrated ISIS a
pstrat neschimbate procesele de rutare de nivel 1 i 2. Rutarea de nivel 3, bazat pe IDRP (InterDomain Routing Protocol) a fost abandonat n favoarea BGP, iar rutarea de nivel 0 a fost nlocuit
de ARP (n reele Ethernet).
Rutare de nivel 3 ntre domenii diferite
Domeniu
IS
IS
Area3
Area1
Rutare de nivel 2 ntre ariile
aceluai domeniu.
IS
IS
Rutare de nivel 1 ntre IS-uri din

aceeeai arie.
ES
Rutare de nivel 0 ntre ES i IS.
ES
Figura 6-1: Rutarea n ISIS
6.1.3 IS-IS vs. OSPF

Pentru muli dintre furnizorii de servicii Internet, dorina implementrii unei soluii bazate pe
un protocol neproprietar se traduce n alegerea dintre ISIS i OSPF. Din acest motiv acest subcapitol
va ncerca s pun n balan avantajele i limitrile celor dou protocoale.
Numeroase caracteristici sunt comune celor dou protocoale, pn la nivelul la care ISIS are
mai multe similariti dect diferene fa de OSPF. n terminologia OSPF, ISIS poate fi descris ca
fiind OSPF ce folosete doar arii totally stubby. De asemenea, ca i restul protocoalelor moderne
de rutare, ambele suport VLSM i ofer o convergen rapid.
133 | I S - I S
OSPF i ISIS partajeaz n primul rnd proprietile protocoalelor link-state: de la actualizrile
incrementale, generate la apariia unor modificri de topologie, pn la pstrarea a trei tabele
distincte: de adiacene, de topologie i de rutare.
Tabela de adiacen va fi creat i meninut n ambele protocoale pe baza schimbrii de
pachete de Hello. Dup stabilirea adiacenelor, vor fi trimise pachete de actualizare ntre vecini,
acestea fiind confirmate att n OSPF, ct i n ISIS. Pe baza actualizrilor se creeaz tabela de
topologie, ce va conine toate informaiile de rutare din cadrul reelei. Pentru selectarea celor mai
bune ci, ambele protocoale vor construi arborele minim de acoperire folosind algoritmul Dijkstra
SPF. Cele mai bune rute determinate n urma acestui proces vor fi pstrate n tabela rutare.
n cadrul fiecrei reele multiacces (precum reelele Ethernet) att OSPF, ct i ISIS, vor alege un
ruter responsabil cu meninerea consistenei informaiilor de rutare. Acest ruter se numete n
OSPF Designated Router (DR), iar n ISIS Designated IS (DIS). OSPF, spre deosebire de ISIS, va mai
alege i un ruter de siguran ce poate prelua funciile DR-ului cnd acesta nu mai este accesibil:
Backup Designated Router (BDR), dar n ISIS nu exist un echivalent pentru un astfel de ruter.
Cea mai relevant asemnare ntre cele dou protocoale este organizarea ierarhic, n arii, a
informaiilor de rutare. Implementarea ariilor este totui diferit ntre OSPF i ISIS. n OSPF, ruterele
sunt situate la graniele dintre arii, astfel c o legtur ntre dou rutere poate aparine doar unei
singure arii la un moment dat. n ISIS, un ruter, mpreun cu toate interfeele sale, poate face parte
doar dintr-o sigur arie, iar capetele unei conexiuni se pot afla n arii ISIS diferite, astfel c graniele
dintre arii se afl pe legturile dintre rutere.
Modelul de ierarhizare a ariilor din OSPF, n care aria sa central (area 0) interconecteaz toate
celelalte arii, a fost mprumutat i n ISIS, care introduce conceptul de backbone area, format din
rutere ce pot transporta rute i pachete ntre arii diferite ale topologiei ISIS, asemenea ABR-urilor
din OSPF.
Sumarizarea adreselor pentru ambele protocoale se va realiza doar ntre arii, spre deosebire de
EIGRP unde sumarizarea se poate realiza, la nivel de interfa, n orice punct al reelei.
Similar cu OSPF, ISIS suport load balancing ntre maximum 6 rute spre aceeai destinaie.
Rutele trebuie s aib aceeai distan administrativ i acelai cost (suma metricilor). ISIS nu
suport load balancing pentru rute de cost inegal.
Comparnd eficiena celor dou soluii, trebuie analizat numrul de pachete de actualizare,
precum i overhead-ul implicat de procesul de ncapsulare. Principalul avantaj al ISIS l reprezint
numrul sczut de pachete de actualizare (LSP) trimise ntre vecini, cel mai adesea, mult mai mic
dect n cazul unei implementri OSPF. n termeni de ncapsulare, Integrated ISIS ruleaz direct
peste nivelul legtur de date, spre deosebire de OSPF ce ruleaz peste IP.
Reversul medaliei l reprezint puternica integrare a OSPF cu tehnologiile IPv4, larga sa
rspndire, n termeni de echipamente, personal calificat i informaii disponibile.
Metrica folosit de OSPF este calculat pe baza limii de band declarate (bandwidth), o
interfa serial avnd un cost mult mai ridicat dect o interfa Ethernet. n ISIS, metrica implicit
pentru toate interfeele este 10, iar modificarea manual a costurilor pentru fiecare interfa este
singurul mod de a reflecta (cel puin teoretic) capacitatea unei legturi.
Flexibilitatea i uurina de extindere a protocolului sunt avantaje deseori citate n favoarea
ISIS. Relevana acestei diferene este totui limitat, atta vreme ct OSPF rspunde att cerinelor
implementrilor IPv4 prin OSPFv2, ct i cerinelor IPv6 prin OSPFv3.
6.1.4 Adresarea ISO

Protocolul de la nivelul reea propus de ISO este CLNP (Connectionless Network Protocol) i, n
genereal, ofer aceleai servicii nivelului transport ca i protocolul IP. Datagramele CLNP sunt
procesate n funcie de antet, suport fragmentare, un echivalent TTL, opiuni suplimentare,
precum i alte similitudini cu protocolul IP. Serviciile asigurate prin intermediul protocolului CLNP
sunt comasate n CLNS, sau Connectionless Network Service.
Iniial, ISIS a fost conceput pentru a funciona exclusiv n reele cu trafic CLNS. Apariia
Integrated ISIS a extins acoperirea ISIS si asupra protocolului IP. Dei Integrated ISIS este, n
continuare, capabil s ruteze trafic CLNS, el transport, n prezent, doar trafic IP. Cu toate acestea,
ISIS folosete n continuare adresele CLNS drept identificatoare pentru rutere, ceea ce duce la
crearea tabelelor de topologie interne protocolului bazate pe adrese CLNS. n consecin, o
topologie funcional ISIS presupune configurarea adreselor CLNS pe fiecare ruter (IS), dar acest
lucru se face cu scop pur administrativ, fr a influena rutarea pachetelor IP sau propagarea
actualizrilor de rutare.
Adresele ISO (CLNS) se prezint n dou forme, n funcie de dispozitivul care este adresat:
Network Service Access Point (NSAP)
Network Entity Title (NET)
O adres CLNS poate avea de la 8 la 20 de octei (adresele IP au doar 4) i cuprinde 3 pri:
Area: echivalentul adresei de reea a unui subnet IP, descrie un grup sau o zon;
ID: echivalentul zonei de staie (host) dintr-o adres IP, identific un anumit dispozitiv din
membrii grupului;
SEL: la nivel de staie, cmpul SEL identific un proces din staia respectiv, similar unui
numr de port TCP sau UDP.
IDP
AFI (1 octet)
DSP
System ID
IDI
HODSP
(1-8 octei)
AREA
ID
Figura 6-2: Cmpurile unei adrese ISO
NSEL (1 octet)
SEL
Din punctul de vedere al tipului de rutare, adresa este mprit n zona IDP (Inter Domain
Part), responsabil cu rutarea extern, ntre sisteme autonome i zona DSP (Domain Specific Part),
ale crei informaii sunt folosite pentru rutarea n interiorul unui sistem autonom. Informaiile
pentru cele dou modele de rutare prezente n cadrul unei singure adrese ISO arat faptul c
schema de adresare n contextul CLNS este una global.
Primul octet al adresei, cmpul AFI (Address Family Identifier) are ca scop specificarea
autoritii ce stabilete formatul adresei, iar cmpul IDI (Initial Domain Identifier) indic o anumit
organizaie n interiorul unui AFI, dar nu intervine n procesul de rutare iar prezena sa e opional.
Cele mai folosite valori pentru AFI sunt:
39: cod regional
47: cod internaional
49: adrese private, nerutate n Internet, asemntoare adreselor private ale protocolului IP,
din RFC 1918.
Cmpul HODSP (High-Order DSP) identific o arie din cadrul unui sistem autonom. Toate
ruterele din interiorul unei arii trebuie s aib acelai cod n cmpul de arie din adresele ISO
configurate.
135 | I S - I S
Cmpul System ID indic un ES sau un IS din interiorul unei arii i poate avea 6 sau 8 octei,
poate fi specificat manual sau poate fi dedus din adresa MAC sau cea IP. Indiferent de metoda
folosit, System ID-urile din interiorul unei arii, ale ruterelor ce efectueaz rutare de nivel 1, trebuie
s fie unice. De asemenea, ruterele ce efecteaz rutare de nivel 2 trebuie s aib System ID-uri
unice ntre toate ruterele de nivel 2.
Ultimul cmp, NSEL, are un octet i identific serviciul cruia i este adresat pachetul. Valoarea
cmpului NSEL stabilete tipul de adresei ISO. Astfel, dac NSEL are valoarea 0x00, adresa ISO este
de tip NET iar acest tip de adres este folosit pentru a identifica rutere (IS-uri). Orice alt valoare
face ca adresa ISO s fie de tip NSAP, utilizabil de ctre orice alt dispozitiv sau, n general, de ES-uri.
Din moment ce un ruter, mpreun cu toate interfeele sale, poate s fac parte doar dintr-o
singur arie, adresele ISO se asigneaz la nivel de ruter i nu de interfa. O implementare clasic de
ISIS nu necesit mai mult de o adres ISO de tip NET configurat pe fiecare ruter, dar pot fi
configurate pn la un maxim de 3 adrese. Adresele multiple sunt folosite n contextul migrrii unui
ruter dintr-o arie n alta, deci pot diferi prin numrul ariei, dar condiia pentru adrese multiple este
ca toate s aib acelasi System ID.
Un exemplu de adres NET este urmtorul:
49.0005.AA00.0301.16CD.00
Cmpurile adresei pot fi identificate de la dreapta spre stnga astfel:

Ultimul octet reprezint cmpul NSEL i este setat la valoarea 00, ceea ce indic o adres de
ruter (NET).
Urmtorii 6 octei ( AA00.0301.16CD ) reprezint System ID-ul, ce identific n mod unic un
ruter ISIS.
Cei 3 octei rmai, de la nceputul adresei ISO ( 49.0005 ) , reprezint numrul ariei. Primul
octet, cu valoarea 49, indic faptul c adresa este una privat. Datorit adresrii private, ce
nu impune restricii cu privire la structura adresei, cmpul IDI a putut fi omis, pentru
simplificare.
Motivul pentru care o adres ISO trebuie citit de la dreapta spre stnga se datoreaz faptului
c identificatorul pentru arie poate avea lungimi variabile, n timp ce toate celelalte cmpuri vor fi
ntotdeauna constante. Spre exemplu, urmtoarea adres ISO este una valid:
49.0015.801f.8ff0.0000.0000.0c00.1234.00
Pentru acest exemplu, se identific, de la dreapta spre stnga, primul octet ca fiind cmpul
NSEL (00), urmtorii 6 octei ca fiind cmpul de System ID (0000.0c00.1234), iar urmtorii 9
octei vor funciona ca identificator pentru arie (49.0015.801f.8ff0.0000).
6.2 Funcionarea IS-IS

6.2.1 Mesaje
Spre deosebire de OSPF, mesajele schimbate ntre rutere au ntotdeauna acelai tip, indiferent
de coninut. n locul LSA-urilor trimise pentru fiecare informaie ce trebuie actualizat, n OSPF, ISIS
trimite toate informaiile de rutare ntr -un singur pachet ncapsulat direct n cadrul de la nivelul
legtur de date. Pachetele ISIS conin un antet de 8 octei urmat de un numr variabil de cmpuri,
numite TLV (Type-Length-Value) ce descriu informaiile necesare pentru rutare.
Alte dou tipuri de hello-uri sunt ISH (Intermediate System Hello) i ESH (End System Hello). lSHurile sunt folosite de ctre IS-uri pentru a se anua ES-urilor iar ESH-urile sunt folosite de ctre ES-uri
pentru a se ata
a ruterelor pe care le vor folosi pe post de gateway. Din moment ce sta
iile
configurate cu protocolul IP nu efectueaz rutare de nivel 0, ele nu vor rspunde ISH-urilor, deci
aceste hello-uri nu vor fi folosite, iar ruterele vor considera ceaz
ata la topologie un ntreg
segment de reea n locul unor ES-uri particulare.
Informaiile de rutare ncapsulate, n ISIS, se numesc LSP-uri (Link State Packet) i contin lista
adiacenelor i a strilor vecinilor unui ruter. Deoarece adiacen
ele se stabilesc separat pentru
nivelurile 1 i 2, LSP -urile sunt, de asemenea, transmise astfel nct informa
ia de nivel 1 este
separat de cea de nivel 2. Astfel, un ruter de nivel 1 va transmite LSP-uri tuturor ruterelor din aria
sa, pe cnd un ruter de nivel 2 va transmite LSP-uri tuturor ruterelor de nivel 2 din domeniul su (i,
eventual, de-a lungul mai multor arii).
Pentru sincronizarea bazelor de date ntre rutere, modificrile n topologie sunt anunate iniial
doar ca SNP-uri (Sequence Number Packet). Un SNP cuprinde o list condensat a tuturor LSP-urilor
dintr-un ruter i este trimis doar vecinilor direct conectai. La primirea unui SNP, vecinii pot verifica
rapid dac informaiile din SNP sunt mai recente dect cele din propria baz de date
i pot cere
informaii actualizate, ce vor fi primite sub forma unor LSP-uri. Mesajele SNP pot lista ntreaga baz
de date a strilor legturilor unui ruteri se vor numi CSNP ( Complete SNP) sau pot lista doar un
subset al lor, ca n cazul apariiei unor modificri izolate n topologie, i se vor numi PSNP (Partial
SNP).
6.2.2 Adiacene
nainte ca doi vecini ISIS s poat schimba rute, ei trebuie s stabileasc o adiacen
valid.
Principalul tip de mesaj ce realizeaz adiacena ntre dou rutere este mesajul de tip IIH
(Intermediate-to-Intermediate Hello), ce func
ioneaz asemenea unui protocol de tip hello,
ntlnit att n OSPF cti n EIGRP. IIH -urile sunt schimbate doar ntre rutere adiacente
i sunt
trimise separat pentru nivelurile 1 i 2 de rutare. n consecin, dac dou rutere pot ruta att intraarea ct i inter-area, ele pot stabili maxim dou adiacene: una la nivelul 1 i alta la nivelul 2.
Deoarece mediile point-to-point i broadcast funcioneaz diferit, adiacenele se formeaz
diferit. O reea point -to-point implic doar dou noduri ce pot comunica, n timp ce o re
ea de tip
broadcast este una multiacces, n care pot exista o multitudine de rutere L1i L2, ceea ce creeaz
necesitatea generrii de hello-uri pentru fiecare nivel n parte.
Stabilirea adiacenelor pe medii point-to-point se face dup ce fiecare parte a primit cte un
pachet hello. Ruterele schimb apoi CSNP-uri i i sincronizeaz bazele de date. Adiacena este
meninut apoi un timp nedefinit prin schimb periodic de mesaje hello, la fiecare 10 secunde. Dac
de la un vecin nu se primesc mesaje hello timp de 30 de secunde, el este considerat deconectat iar
din baza de date local se elimin toate intrrile i rutele ce depind de acel vecin.
Mediile broadcast stabilesc un DIS, echivalent al DR-ului din OSPF, responsabil pentru ntreaga
reea. Alegerea unui DIS minimizeaz cantitatea de trafic de rutare ce traverseaz acel segment i
evit situaiile de sincronizare ce nu ar fi necesar e ntre mai rutere multiple responsabile pentru
acelai segment. DIS-ul este singurul ruter responsabil pentru trasnmiterea LSP-urilor ce cuprin
informaii despre segmentul de reea respectiv.
DIS-ul creeaz un pseudonod, asemenea unui ruter virtual care reprezint ntreaga reea
multiacces. Hello-urile DIS-ului se trimit de 3 ori mai repede dect cele ale altor rutere, la 3.3
secunde, pentru a detecta rapid erorile. Dac DIS-ul nu mai poate funciona, un nou ruter este ales
n locul su dup criteriul prioritii celei mai mari sau, dac acestea sunt egale, dup cel mai mare
SNPA (Subnetwork Point of Attachment). Pentru segmente Ethernet, SNPA-ul reprezint valoarea
adresei MAC de pe interfa, iar pentru segmente conectate la reele Frame Relay, SNPA-ul este
137 | I S - I S
valoarea identificatorului de circuit de pe interfaa respectiv (DLCI). Prioritatea implicit pentru
fiecare interfa este 64 i poate primi valori ntre 1 i 127.
ISO descrie cele 4 niveluri de rutare, specificate anterior: nivelul 0, ntre ES-uri i IS-uri; nivelul
1, n interiorul unei zone; nivelul 2, ntre zone diferite; nivelul 3, ntre sisteme autonome distincte.
Integrated IS-IS e responsabil doar pentru nivelurile 1 i 2. Un ruter ISIS se ncadreaz ntr-una dintre
categoriile: L1, L2 sau L12, n funcie de tipul sau tipurile de rutare pe care le poate efectua.
IS
L1
L2
L1-2
Area3
IS
L1-2
L1
Area1 L1-2
Area 0001
Area 0003
L1
L1-2
L1
Area 0002
Figura 6-3: Topologie i zone IS-IS
6.2.3 Backbone L2
Rutarea de nivel 2 se realizeaz numai ntre ruterele capabile de rutare de nivel 2 (L2) sau ntre
rutere ce pot ruta att la nivel 1 ct i la nivel 2 (L12). Aceste rutere formeaz zona de backbone
ntr-o topologie ISIS. De regul, backbone-ul se ntinde de-a lungul mai multor arii deoarece scopul
su este de a realiza rutarea ntre arii distincte. Orice dispozitiv (IS sau ES) care dorete s trimit
trafic unei destinaii dintr-o alt arie dect a sa trebuie s foloseasc un ruter L2 sau L12 pe post de
gateway. Rutarea inter-area, la nivel 2, se face pe baza identificatorilor de arie din adresele NET.
Backbone-ul n sine nu reprezint o arie separat, ca n cazul OSPF, ci este reprezentat ca un
graf de rutere cu cel puin un nod n fiecare arie din domeniu. n mod automat, fiecare ruter din
backbone va face parte dintr-o arie specific, stabilit de cmpul Area ID din adresa NET.
Dei chiar i un ruter L2 va face parte dintr-o anumit arie, el nu va putea trimite pachetele
direct spre o destinaie L1 din aria sa deoarece el va menine doar adiacene de nivel2, cu ruterele
L2 i L12 i i va construi corespunztor baza de date din informaiile de nivel 2 ale acestora.
6.2.4 Funcionare L1
Un ruter L1 va cunoate n baza sa de date doar destinaiile din aria sa curent. De asemenea,
el va stabili adiacene i se va sincroniza doar cu alte rutere L1 sau L12 din aria sa. Traficul trimis de
astfel de rutere, spre o destinaie din aceeai arie, nu necesit rutare la nivel 2. Pachetele pot urma
o cale format doar din rutere L1 (eventual L12) pn la destinaie.
Ruterele L1 vor trebui s foloseasc un ruter L12 pentru a putea comunica i cu alte destinaii,
din afara ariei lor. Ele vor primi din partea ruterelor L12 o rut implicit (default) i vor trimite celui
mai apropiat ruter L12 toate pachetele destinate altor arii.
n interiorul unei arii, ruterele L1 trebuie s aib acelai numr de arie i numere distincte de
System ID pentru a putea identifica dac destinaia unui pachet se afl n aceeai arie sau nu, deci
dac trebuie cutat n baza de date cu legturi de nivel 1 sau dac pachetul trebuie trimis la ruterul
L12 local.
Protocolul ISIS nu permite ca sumarizarea rutelor s fie fcut n interiorul unei arii, deci
ruterele R1 nu sunt capabile de sumarizare.
6.2.5 Funcionarea L12

Un ruter L12 menine dou baze de date separate pentru a ine evidena strii legturilor i
topologiilor la ambele niveluri de rutare. El face parte din backbone-ul domeniului ISIS i va stabili
adiacene cu toate ruterele L2 i L12 vecine. De asemenea, el va cunoate att destinaiile de nivel
2, pentru fiecare arie diferit, ct i destinaiile de nivel 1 ale ariei din care face parte.
Ruterele L12 vor primi pachetele din interiorul ariei lor, pentru a le ruta spre alte arii. Aceste
pachete vor fi trimise de ctre ruterele L12 spre alte rutere din backbone, pn cnd acestea ajung
la un ruter L12 ce face parte att din backbone ct i din aria destinaie.
Sumarizarea ruterelor se face de ctre ruterele L12 i se aplic rutelor din aria la care este
ataat ruterul respectiv. Rutele sumarizate sunt introduse n backbone alturi de rutele altor rutere
L12 i L2. De aceea, dac exist mai mult de un ruter L12 ce ofer acces spre exteriorul unei arii,
sumarizarea trebuie configurat pe toate aceste rutere. Altfel, ruterele din backbone vor folosi doar
rutele nesumarizate pentru a accesa aria respectiv, deoarece acestea din urma vor fi mai specifice
i, deci, preferate n tabelele de rutare.

Primul pas n configurarea IS-IS l reprezint planificarea schemei de adresare. Spre deosebire
de o reea IP, prin configurarea adreselor ISO va fi stabilit tipul de adiacen ce se poate forma ntre
dou rutere. Astfel, pornind de la topologia reelei vor trebui determinate ariile n care vor fi
grupate ruterele, cu alte cuvinte, ruterele ce vor rula doar L1 (cel mai adesea datorit resurselor
hardware limitate), L2 (pentru optimizarea funcionrii ruterelor de backbone) sau L12 (pentru
asigurarea conectivitii ruterelor L1 la backbone).
Ruterele sunt grupate n arii, pentru fiecare arie fiind definit un prefix.
Pentru fiecare ruter, adresa CLNS va cuprinde prefixul (identificatorul ariei), urmat de
identificatorul de sistem (unic la nivel de arie) i n final un octet cu valoarea 0. Ultimul cmp din
adresa CLNS l reprezint NSEL, valoare acestuia fiind 0 pentru adresa unui ruter.
Planificarea adreselor IP nu va avea un impact asupra funcionrii IS-IS. Din acest motiv
alocarea adreselor IP urmrete n general obinerea unui grad ct mai ridicat de sumarizare.
Setarea adresei va fi realizat n cadrul protocolului de rutare:
Cluj(config)#router isis
Cluj(config-router)#net 49.0001.aaaa.aaaa.aaaa.00
Pentru a defini interfeele pe care ruleaz IS-IS va trebui activat protocolul n modul de
configurare a interfeei respective:
139 | I S - I S
Cluj(config)#interface serial 0/0
Cluj(config-if)#ip router isis
Prin activarea protocolului pe o interfa, ruterul va trimite i va primi actualizri pe respectiva

interfa. n plus reeaua din care face parte interfaa va fi inclus n pachetele de actualizare
trimise vecinilor.
Pe ruterele Cisco, modul implicit este L12, deci toate ruterele vor stabili cte dou adiacene
ntre ele i fiecare va fi capabil de rutare att la nivel 1 ct i la nivel 2. n general, topologia poate fi
lsat sub forma iniial, format din rutere L12, dar, dei acest lucru simplific efortul de
configurare, reeaua va fi de dou ori mai ncrcat din cauza hello-urilor i mesajelor de rutare
(LSP-uri i SNP-uri), iar ruterele vor folosi de dou ori mai mult memorie i putere de procesare,
ceea ce nu e ntotdeauna o situaie acceptabil ntr-o reea activ.
Schimbarea tipului unui ruter se face n modul global de configurare al protocolului de rutare,
ca n exemplul urmtor:
Cluj(config-router)#is-type level-1
Parametrii acceptai de comanda is-type sunt: level-1, level-1-2 i level-2-only.

Nivelul de rutare poate fi setat i n mod particular, pe interfee, n momentul n care se dorete
ca ruterul s stabileasc adiacene diferite n funcie de vecini 1. n exemplul urmtor, interfaa
serial 0/0 va putea stabili adiacene doar cu o interfa de tip L1 sau L12, iar interfaa serial 0/1 va
putea stabili adiacene doar cu o interfa de tip L2 sau L12:
Cluj(config)#interface serial 0/0
Cluj(config-if)#isis circuit-type level-1
Cluj(config-if)#interface serial 0/1
Cluj(config-if)#isis circuit-type level-2-only
Metricile atribuite de ctre protocolul de rutare fiecrei interfee au valoarea implicit de 10 i

se calculeaz independent pentru nivelul 1 i 2 de rutare. Pentru modificarea metricilor la nivel de
interfa se folosete comanda isis metric, urmat de valoarea noii metrici i tipul adiacenei
pentru care se aplic:
R1(config)#interface serial1/0
R1(config-if)#isis metric 25 level-1
R1(config-if)#isis metric 30 level-2
Metrica setat pe o interfa este singurul parametru folosit la calcularea rutelor ce vor fi
introduse n tabela de rutare. Ruterele calculeaz costul destinaiilor adunnd incremental metricile
rutelor primite n LSP-uri cu valorile setate pe interfeele respective.
DIS-ul unui segment multiacces este ales pe baza prioritii. Implicit, un ruter n ISIS are
priritatea 64 pe toate interfeele. Pentru modificarea prioritii la o valoare ntre 1 i 127 se
folosete comanda isis priority, ca n exemplul urmtor:
R1(config-if)#ip route isis
R1(config-if)#isis priority 127
1
Setarea unei interfee pentru un anumit mod de rutare este util n special pentru ruterele de
tip L12. Acestea vor trimite LSP-uri pe interfeele configurate pentru rutare L1 cu un bit (ATT) setat
astfel nct ruterele L1 ce vor primi aceste LSP-uri vor considera automat ruterul L12 drept gateway
i vor instala o rut default ctre acesta, din moment ce tranzitarea ntre arii se face prin rutere L2 i
L12.
Pentru a realiza sumarizarea rutelor, pe un ruter de tip L12, se folosete comanda summaryaddress, urmat de adresa sumarizat i masca corespunztoare. Ruterul L12 va anuna altor arii
doar ruta sumarizat.
Spre exemplu, dac un ruter L12 anun n ISIS urmtoarele petru reele cu masca /24, acestea
pot fi sumarizate ntr-o singur reea cu masca /22:
200.99.104.0 /24
200.99.105.0 /24
200.99.106.0 /24
200.99.107.0 /24
Pentru sumarizarea reelelor de mai sus, se folosete comanda:
Cluj(config-router)#summary-address 200.99.104.0 255.255.255.252
Se observ faptul c sumarizarea se execut direct n modul de configurare al protocolului de

rutare i nu pe o interfa specific.
Ca majoritatea celorlalte protocoale de rutare, ISIS suport autentificare pentru a nu permite
alterarea tabelelor de rutare din partea dispozitivelor ce nu aparin topologiei ISIS. ISIS permite
configurarea de parole pentru fiecare legtura n parte, la nivel de arie i la nivel de domeniu. Dac
un ruter nu deine parola necesar acesta nu va putea executa operaiile corespunztoare: nu va
putea stabili o adiacen pe un link, nu va putea deveni membru al unei arii sau nu va putea deveni
membru al unui domeniu de nivel 2.
Autentificarea la nivel de interfa poate fi realizat pentru nivelul 1 sau 2 de rutare, n
particular, sau pentru ambele simultan. Dac nu este specificat nivelul pentru care se face
autentificare, se aceasta se aplic pentru ambele niveluri. Parolele sunt transportate n mesajele de
tip hello ale protocolului, fapt ce separ procesele de autentificare dintre cele dou niveluri. Pentru
determinarea tipului de adiacen dintre doi vecini se poate folosi comanda show clns
neighbor. La nivel de arie sau de domeniu autentificarea reprezint un singur proces comun
pentru ambele niveluri.
Exemplu de autentificare la nivel de interfa:
R1(config-if)#isis password ISISPASSWORD
Exemplu de autentificare la nivel de arie:

R2(config)#router isis
R2(config-router)#area-password AREAPASS
Exemplu de autentificare la nivel de domeniu:

R2(config-router)#router isis
R2(config-router)#domain-password DOMAINPASS
Pentru funcionarea procesului de autentificare i, implicit, a protocolului de rutare n contextul

autentificat, toate ruterele trebuie s posede informaii consistente de autentificare la nivel de
legtur (link), arie sau domeniu, dup caz.
6.3.1 Comenzi de verificare

Trei dintre cele mai utile comenzi pentru verificarea funcionrii protocolului ISIS sunt
urmtoarele:
show clns neighbors
141 | I S - I S
show clns interface
show isis database
Comanda show clns neighbors include informaii din tabela de vecini a protocolului mpreun
cu starea legturior cu acetia:
R1#show clns neighbors
System Id
Interface SNPA
State Holdtime Type Protocol
0000.0000.000D Et0
00e0.1e3d.d56f Up
8
L1
IS-IS
1111.2222.3333 Se1/0
*HDLC*
Up
23
L1L2 IS-IS
n exemplul de mai sus, RouterA are doi vecini, identificai prin valoarea System ID configurat
prin adresele NET de pe fiecare ruter. Cmpul interface specific interfaa prin care ruterul este
conectat la fiecare vecin. Cmpul SNPA (Subnetwork Point of Attachment) indic tipul legturii de
nivel 2 pe care ruterul o are cu vecinul respectiv. Pentru reele Ethernet, SNPA-ul indic adresa MAC
a interfeei. Pentru interfaa Serial1/0, SNPA indic protocolul point-to-point de pe interfa, HDLC.
Pentru mai multe detalii, ce includ durata pentru care interfaa a fost activ, adresa zonei i
adresa IP a vecinului, se poate aduga parametrul detail comenzii:
R1#show clns neighbors detail
System Id
Interface
SNPA
R2
Se1/0
*HDLC*
Area Address(es): 49.0000
IP Address(es): 10.1.1.2*
Uptime: 01:30:00
NSF capable
State
Up
Holdtime
21
Type Protocol
L1L2 IS-IS
Comanda show clns interface afiseaza informatiile specifice fiecrei interfee ce ruleaz
ISIS. Comanda accept ca parametru i numele unei interfee pentru a filtrarea rezultatului:
R1#show clns interface serial 1/0
Checksums enabled, MTU 1500, Encapsulation HDLC
ERPDUs enabled, min. interval 10 msec.
CLNS fast switching enabled
CLNS SSE switching disabled
DEC compatibility mode OFF for this interface
Next ESH/ISH in 23 seconds
Routing Protocol: IS-IS
Circuit Type: level-1-2
Interface number 0x0, local circuit ID 0x100
Neighbor System-ID: R2
Level-1 Metric: 25, Priority: 64, Circuit ID: R2.00
Level-1 IPv6 Metric: 10
Number of active level-1 adjacencies: 1
Level-2 Metric: 30, Priority: 64, Circuit ID: R1.00
Next IS-IS Hello in 8 seconds
if state UP
Protocolul de rutare indicat (IS-IS) arat faptul c ruterul a realizat doar adiacene cu alte
rutere. Lipsa rutrii de tip CLNS are drept efect i absena protocolului de rutare ES-IS. circuit
type indic faptul c pe interfaa Serial1/0 se ncearc realizarea de adiacene L1 i L2, iar
realizarea lor este confirmat de numrul 1 din dreptul ambelor tipuri de adiacene. De asemenea,
se poate observa i faptul c metricile sunt calculate separat pentru fiecare tip de adiacen, ceea
ce duce la calcularea unor tabele de topologie diferite pentru rutarea de tip L1 i cea de tip L2.
Comanda show isis database afieaz informaiile obinute prin LSP-uri din baza de date
local:
R1#show isis database
IS-IS Level-1 Link State Database:
LSPID
LSP Seq Num LSP Checksum
R1.00-00
* 0x00000013
0x723A
R2.00-00
0x00000011
0x3497
IS-IS Level-2 Link State Database:
LSPID
LSP Seq Num LSP Checksum
R1.00-00
* 0x00000015
0x8006
R2.00-00
0x00000012
0x5866
LSP Holdtime
701
596
ATT/P/OL
0/0/0
0/0/0
LSP Holdtime
742
677
ATT/P/OL
0/0/0
0/0/0
Indentificatorul de sub cmpul LSPID afieaz identificatorul ruterului care a originat LSP-ul,
urmat de o valoare care este diferit de zero dac LSP-ul a originat de la un pseudonod i de o alt
valoare care indic dac LSP-ul a fost fragmentat, dac este diferit de zero. Holdtime-ul indic
timpul, n secunde, pentru care LSP-ul respectiv va mai fi valid n memoria ruterului. Bitul ATT este
setat de ctre un ruter L12 atunci cnd se anun drept default gateway pentru o zon L1. Pentru a
afia i coninutul LSP-urilor (rutele anunate, mpreun cu metricile), se poate aduga parametrul
detail comenzii.
Cteva dintre comenzile de debug ce pot fi folosite pentru urmrirea n timp real a
evenimentelor ISIS dintr-un ruter sunt urmtoarele:
debug isis adj-packets afieaz informaii legate de evoluia relaiilor de adiacen
cu toi vecinii unui ruter, inclusiv pachetele hello trimise i primite, precum i eventualele
schimbri n starea legturilor.
debug isis spf-events afieaz calculele efectuate de algoritmul SPF (Shortest Path
First) pentru calcularea rutelor spre destinaii, mpreun cu toate informaiile ce particip la
calcularea topologiei, provenite din LSP-uri.
debug isis update-packets afieaz CSNP-urile, PSNP-urile i LSP-urile primite i
emise de ruter.
6.4 Studiu de caz

n urmtorul scenariu, furnizorul de servicii ScaleMore, observnd consumul de memorie de la
nivelul ruterelor din reea, decide migrarea protocolului de rutare de la EIGRP la IS-IS. Datorit
metricii inferioare a IS-IS configurarea noului protocol poate fi fcut fr a afecta informaiile de
rutare ce ajung n tabela de rutare.
Pentru evaluarea pailor de configurare a IS-IS n cadrul reelei ScaleMore departamentul de
proiectare decide testarea mecanismelor de propagare a informaiilor de rutare n cadrul unei
topologii cu trei rutere, prezentat n Figura 6-4. Testele vor urmrii modalitile de alterare a
informaiilor de rutare, precum i mecanismele de asigurare a autenticitii vecinilor IS-IS.
Cluj
Arad
Iai
192.168.1.0/30
10.0.1.0/24
10.0.3.0/24
10.0.2.0/24
SW0
172.17.123.0/24
Figura 6-4 Topologia reelei de test
143 | I S - I S

Ruterele fac parte din acelai domeniu: 49.0001. Cluj va avea SystemID aaaa.aaaa.aaaa, Arad
bbbb.bbbb.bbbb, iar Iai cccc.cccc.cccc.
Cele trei rutere fac parte din reeaua FastEthernet 172.17.123.0/24. ntre Arad i Iai este
configurat o legtur serial ce va primi adrese din spaiul: 192.168.1.0/30. Fiecare rutere va avea
configurat o interfa de loopback conform topologiei. Configuraia IP a interfeelor este rezumat
mai jos:
Cluj#show ip interface brief | include up
FastEthernet0/0
172.17.123.1
Loopback0
10.0.1.1
YES manual up
YES manual up
up
up
Arad#show ip interface brief | include up

FastEthernet0/0
172.17.123.2
Serial1/0
192.168.1.1
Loopback0
10.0.2.1
YES manual up
YES manual up
YES manual up
up
up
up
Iasi#show ip interface brief | include up

FastEthernet0/0
172.17.123.3
Serial1/0
192.168.1.2
Loopback0
10.0.3.1
YES manual up
YES manual up
YES manual up
up
up
up
Conform informaiilor de domeniu i System ID, pe rutere se va activa protocolul de rutare ISIS,
se vor include interfeele active n procesul ISIS i vor fi configurate adresele NET ca n exemplul
urmtor:
Cluj(config-router)#net 49.0001.aaaa.aaaa.aaaa.00
Cluj(config-router)#interface fastethernet 0/0
Cluj(config-if)#interface loopback0
Arad(config)#router isis
Arad(config-router)#net 49.0001.bbbb.bbbb.bbbb.00
Arad(config-router)#interface serial1/0
Arad(config-if)#ip router isis
Arad(config-if)#interface loopback0
Arad(config-if)#interface fastethernet0/0
Iasi(config)#router isis
Iasi(config-router)#net 49.0001.cccc.cccc.cccc.00
Iasi(config-router)#interface serial1/0
Iasi(config-if)#ip router isis
Iasi(config-if)#interface fastethernet0/0
Iasi(config-if)#interface loopback0
Primul pas pentru verificarea funcionrii protocolului de rutare este verificarea stabilirii
adiacenelor. Pentru exemplificare, se vor analiza informaiile de pe ruterul Iai:
Iasi#show clns neighbors
System Id
Cluj
Arad
Arad
Interface
Fa0/0
Fa0/0
Se1/0
SNPA
cc00.300c.0000
cc01.300c.0000
*HDLC*
State
Up
Up
Up
Holdtime
24
28
20
Type
L1L2
L1L2
L1L2
Protocol
IS-IS
IS-IS
IS-IS
Conform rezultatului de mai sus, se observ faptul c ruterul Iai a stabilit adiacene de tip L1L2
cu vecinii si deoarece toate ruterele, n mod implicit, ruteaz att la nivel 1 ct i la nivel 2. Pentru
ruterul Iai, ruterul Cluj este accesibil prin intermediul legturii multiacces FastEthernet, la care este
conectat cu interfaa FastEthernet0/0. Ruterul Arad este accesibil att prin reeaua FastEthernet
(interfaa FastEthernet0/0) ct i prin legtura serial direct (interfaa Serial1/0) dintre ruterele
Arad i Iai.
Adugnd parametrul detail comenzii anterioare, rezultatul informeaz asupra numrului ariei
fiecrui vecin, adresei IP a interfeei ce a stabilit adiacena i durata de via a adiacenei:
Iasi#show clns neighbors detail
System Id
Interface
SNPA
Cluj
Fa0/0
cc00.300c.0000
IP Address(es): 172.17.123.1*
Uptime: 00:01:08
NSF capable
Arad
Fa0/0
cc01.300c.0000
IP Address(es): 172.17.123.2*
Uptime: 00:01:08
NSF capable
Arad
Se1/0
*HDLC*
IP Address(es): 192.168.1.1*
Uptime: 00:01:15
NSF capable
State
Up
Holdtime
28
Type Protocol
L1L2 IS-IS
Up
24
L1L2 IS-IS
Up
25
L1L2 IS-IS
Se recomad consultarea relaiilor de adiacen i pe celelalte rutere:

luj#show isis neighbors
System Id
Arad
Arad
Iasi
Iasi
Type
L1
L2
L1
L2
Interface
Fa0/0
Fa0/0
Fa0/0
Fa0/0
IP Address
172.17.123.2
172.17.123.2
172.17.123.3
172.17.123.3
State
UP
UP
UP
UP
Holdtime
24
23
9
8
Circuit Id
Iasi.01
Iasi.01
Iasi.01
Iasi.01
IP Address
172.17.123.1
172.17.123.1
172.17.123.3
172.17.123.3
192.168.1.2
State
UP
UP
UP
UP
UP
Holdtime
26
29
7
8
23
Circuit Id
Iasi.01
Iasi.01
Iasi.01
Iasi.01
00
Arad#show isis neighbors

System Id
Cluj
Cluj
Iasi
Iasi
Iasi
Type
L1
L2
L1
L2
L1L2
Interface
Fa0/0
Fa0/0
Fa0/0
Fa0/0
Se1/0
Comanda show isis neighbors listeaz separat fiecare tip de adiacen realiat cu fiecare
vecin. Se observ c, pentru segmentul FastEthernet, ntre fiecare dou rutere s-a stabilit cte o
pereche de adiacene deoarece mesajele Hello se trimit independent pentru cele dou niveluri de
rutare. Pentru legtura serial se trimite un singur tip de mesaj Hello ce stabilete adiacena
necesar.
De asemenea, din rezultatul comenzilor show clns neighbors i show isis neighbors se deduce
faptul c ruterul Iai este DIS pentru segmentul FastEthernet. Iai are cea mai mare adres MAC
(valoarea SNPA) pe segmentul respectiv iar valoarea Iasi.01 a identificatorului de circuit arat c
acesta este pseudonodul segmentului multiacces.
n acest moment, tabelele de rutare trebuie s conin rute spre toate reelele cu interfee
active din topologie:
Cluj#show ip route isis
145 | I S - I S
i L1
i L1
10.0.2.0 [115/20] via 172.17.123.2, FastEthernet0/0

i L1
[115/20] via 172.17.123.3, FastEthernet0/0
Arad#show ip route isis
i L1
[115/20] via 192.168.1.2, Serial1/0
i L1
Iasi#show ip route isis
i L1
[115/20] via 192.168.1.1, Serial1/0
i L1
Din moment ce metricile nu au fost nc alterate i sunt constante pentru toate tipurile de
interfee, calcularea rutelor n ISIS este echivalent cu determinarea numrului de hop-uri pn la
destinaie realizat de protocolul RIP, ceea ce determin introducerea de rute alternative, cu
distane administrative i metrici egale n tabela de rutare.
6.4.2 Controlul procesului de alegere DIS

Rezultatul comenzii show clns interface executat pe ruterul Iai arat c acesta a fost ales DIS
pentru segmentul de reea FastEthernet (Circuit ID are valoarea Iasi.01):
Iasi#show clns interface fast0/0
Checksums enabled, MTU 1497, Encapsulation SAP
Level-1 Metric: 10, Priority: 64, Circuit ID: Iasi.01
Level-2 Metric: 10, Priority: 64, Circuit ID: Iasi.01
Next IS-IS LAN Level-1 Hello in 1 seconds
Next IS-IS LAN Level-2 Hello in 715 milliseconds
Procedeul de alegere al unui DIS pentru un segment multiacces compar nti valorile
prioritilor configurate pe fiecare interfa a unui ruter conectat la segmentul respectiv. n cazul
de fa, prioritile tuturor interfeelor sunt setate la valorile implicite, de 64, deci alegerea s-a fcut
dup valoarea SNPA (adresa MAC) cea mai mare de pe segment, ruterul Iasi ctignd rolul de DIS.
Prioritatea unei intefee pentru un segment multiacces poat fi modificat direct din modul de
configurare al interfeei, ca n exemplul urmtor:
Arad(config)#int fast 0/0
Arad(config-if)#isis priority ?
<0-127> Priority value
Arad(config-if)#isis priority 100
Comanda anterioar schimb prioritatea interfeei FastEthernet a ruterului Arad la o valoare
mai mare de 64. n consecin, comanda show clns interface va indica pe fiecare ruter noul
DIS:
Iasi#show clns interface fast0/0
Level-1 Metric: 10, Priority: 64, Circuit ID: Arad.02
Comanda isis priority urmat de un parametru numeric schimb prioritatea unei

interfee pentru ambele niveluri de rutare. Pentru o configurare mai granular, prioritatea poate fi
schimbat doar pentru un anumit nivel de rutare, ca n exemplul urmtor:
Cluj(config)#interface fastethernet0/0
Cluj(config-if)#isis priority 125 ?
level-1 Specify priority for level-1 routing
level-2 Specify priority for level-2 routing
<cr>
Cluj(config-if)#isis priority 125 level-1
Ruterului Cluj i-a fost modificat prioritatea pentru nivelul 1 de rutare de la valoarea implicit,
de 64, la cea de 125. Drept urmare, noua valoare pentru nivelul 1 este mai mare dect cea de 100
configurat pe ruterul Arad iar ruterul Cluj devine DIS pentru nivelul 1 de rutare pentru segmentul
FastEthernet:
Level-1 Metric: 10, Priority: 64, Circuit ID: Cluj.01
Informaiile cu privire la DIS-ul i pseudonodul corespunztor unui segment sunt vizibile i

consistente pentru orice interfa conectat la segmentul multiacces respectiv.
147 | I S - I S
6.4.3 Alterarea metricilor

ISIS folosete o metric implicit i constant la valoarea 10 pentru toate interfeele. n
momentul n care un ruter primete o rut pe o anumit interfa, valoarea metricii de pe interfaa
respectiv este adunat la metrica deja primit, iar noua valoare intr n calculele pentru tabela de
rutare.
Analiznd tabela de rutare a ruterului Cluj se observ c acesta primete dou rute cu aceeai
distan administrativ i aceeai metric spre destinaia 192.168.1.0/30 (legtura punct la punct
dintre Arad i Iai) i le introduce pe ambele n tabela de rutare. Cele dou rute provin de la ruterele
Arad i Iai, capetele segmentului.
Cluj#show ip route isis | begin 192.168.1.0
i L1
[115/20] via 172.17.123.3, FastEthernet0/0
Dac, spre exemplu, se dorete doar utilizarea rutei prin Iasi se poate altera metrica de pe
interfaa serial a ruterului Iasi la o valoare mai mic dect cea implicit, pentru ca ruterul Cluj s
primeasc ruta de la Iasi cu un cost mai mic dect cea de la Arad i s o introduc doar pe aceasta n
tabela de rutare:
Iasi(config)#interface serial1/0
Iasi(config-if)#isis metric 5 level-1
Dup cteva secunde, tabela de rutare de pe ruterul Cluj pentru destinaia 192.168.1.0/30 va
arta o singur destinaie:
Cluj#show ip route isis | begin 192.168.1.0
i L1
Costul iniial de 20 era dat de suma metricilor de pe interfaa Serial1/0 a ruterului Iasi i
interfaa FastEthernet0/0 a ruterului Cluj. Modificarea costului de pe interfaa serial a ruterului Iasi
la valoarea 5 are ca efect introducerea n tabela de rutare a ruterului Cluj a unei rute de cost 15.
6.4.4 Autentificarea n IS-IS

Autentificarea mesajelor schimbate ntre rutere are drept scop protejarea informaiilor de
rutare mpotriva eventualilor atacatori ce pot introduce rute nevalide n topologie.
La nivelul unei segment de reea, autentificarea se face direct pe interfeele conectate la
segmntul respectiv:
Cluj(config)#interface fastethernet0/0
Cluj(config-if)#isis password CISCO
*Mar 1 02:40:29.707: %CLNS-4-AUTH_FAIL: ISIS: LAN IIH authentication
failed
Configurarea autentificrii pe interfaa FastEthernet0/0 a ruterului Cluj rezult ntr-un mesaj

syslog ce anun c autentificare eueaz. Eroarea se datoreaz faptului c niciun alt membru al
segmentului nu a fost configurat pentru autentificare. Euarea autentificrii la nivelul unui segment
duce la imposibilitatea stabilirii complete a adiacenelor. Starea ruterului Cluj este vzut ca fiind
INIT, i nu UP, pentru ceilali doi vecini ai si:
Arad#show clns neighbors
System Id
Protocol
Cluj
Interface
SNPA
State
Holdtime
Type
Fa0/0
cc00.300c.0000
Init
29
L1L2 IS-IS
Iasi
Iasi
Fa0/0
Se1/0
cc02.300c.0000
*HDLC*
Up
Up
28
22
L1L2 IS-IS
L1L2 IS-IS
n consecin, rutele nvate de la ruterul Cluj sunt eliminate din tabelele de rutare ale
vecinilor. Se observ c reeaua interfeei de loopback a ruterului Cluj lipsete din tabela celorlaltor
rutere:
Iasi#show ip route isis
i L1
10.0.2.0 [115/15] via 192.168.1.1, Serial1/0
Autentificarea la nivel de interfa poate fi particularizat pentru un anumit nivel de rutare prin
comanda isis password CISCO level-1 sau isis password CISCO level-2.
Autentificarea incorect pentru un anumit nivel de rutarea poate fi verificat prin comanda show
isis neighbors, care arat starea adiacenelor de nivel 1 i 2 pentru fiecare vecin.
n plus, autentificarea poate fi realizat la nivel de arie i la nivel de domeniu. Configurarea
complet a tuturor celor trei tipuri de autentificare este acoperit n urmtoarea secven:
Arad(config)#interface fastethernet0/0
Arad(config-if)#isis password CISCO
Iasi(config)#interface fastethernet0/0
Iasi(config-if)#isis password CISCO
Cluj(config-router)#area-password AREAPASS
Cluj(config-router)#domain-password DOMPASS
Arad(config)#router isis
Arad(config-router)#area-password AREAPASS
Arad(config-router)#domain-password DOMPASS
Iasi(config)#router isis
Iasi(config-router)#area-password AREAPASS
Iasi(config-router)#domain-password DOMPASS
7 Optimiz area rut rii
Pn n anul 2000 majoritatea rutrii din Internet era fcut prin intermediul rutelor statice.
Fa de protocoalele de rutare dinamice, acestea nu aveau probleme de convergen sau de
securitate, singurul lor dezavantaj fiind efortul administrativ mare de a le ntreine. Odat cu anul
2000 Internetul a cunoscut o cretere remarcabil iar nevoia pentru un mecanism dinamic pentru a
propaga rute a devenit evident. Protocoalele de rutare ncorporau deja posibilitatea de
autentificare, iar timpul de convergen foarte bun n cazul protocoalelor link-state le-au promovat
n rndul reelelor Enterprise i ISP. Singurele cazuri din prezent n care rutarea static este nc
preferat sunt n reelele foarte mici sau reelele cu cerine mari de securitate.
Un protocol de rutare trebuie s fie ct mai eficient n deciziile de rutare i determinare a cilor.
Tehnicile de optimizare a rutrii sunt mecanisme ce funcioneaz peste protocolul de rutare i
care modific comportamentul implicit al direcionrii pachetelor n funcie de politicile
administratorului.
7.1 Redistribuia ntre multiple protocoale de rutare

Comunicarea rutelor ntre diferite protocoale de rutare este unul din cele mai complexe
subiecte din rutarea IP. Cu toate c folosirea unui singur protocol de rutare n ntreaga reea a unei
companii este ntotdeauna soluia preferat i de asemenea i cea mai ntlnit, apar cteva cazuri
n care trebuie realizat comunicarea rutelor ntre protocoale de rutare diferite. Aceast
comunicare de rute poart numele de redistribuie. Dei la nivel de comenzi de configurare
redistribuia se face foarte uor, un administrator de reea trebuie s cunoasc foarte bine teoria deloc trivial - din spatele procesului. Greelile ce pot fi fcute n redistribuie dein recordul (alturi
de protocolul BGP) la raportul dintre dimensiunea extrem de mic a greelii i impactul devastator
pe care l poate avea asupra reelei.
Nevoia de redistribuie ntre dou protocoale de rutare poate aprea din multiple motive:
Fuziunea a dou sau mai multe companii ce folosesc protocoale diferite;
Utilizarea unei reele n care exist rutere de la productori diferii ce ruleaz protocoale
proprietare (ex. rutere Cisco ce ruleaz EIGRP);
Utilizarea unei reele n care unele rutere nu sunt ndeajuns de puternice nct s suporte
rularea protocolului dominant (OSPF sau EIGRP) i sunt forate ctre un protocol de rutare
mai simplu (RIPv2);
7.1.1 Conceptul de redistribuie

Din punctul de vedere al sistemului de operare IOS, un protocol de rutare ruleaz ca i orice alt
proces de pe ruter. Pentru c majoritatea protocoalelor de rutare funcioneaz crend adiacene
ntre dispozitive diferite de reea, singura metod prin care dou protocoale de rutare pot schimba
date ntre ele este prin comunicaie ntre procese pe acelai sistem de operare/ruter (IPC 1).
Astfel, la redistribuia ntre dou protocoale de rutare, ambele trebuie s ruleze pe acelai ruter
care va juca rolul unui punct de redistribuie n reea.
Redistribuia poate fi definit prin cele dou procese de mai jos:
1. Toate rutele din tabela de rutare nvate prin protocolul de rutare din care se face
redistribuia vor fi anunate n protocolul n care se face redistribuia.
2. Toate rutele reelelor direct conectate care fac parte din protocolul de rutare din care se
face redistribuia vor fi anunate n protocolul de rutare n care se face redistribuia.
OSPF -> EIGRP
OSPF
R1
EIGRP
R2
O 172.20.113.192/26 [110/74]
O 172.20.114.192/26 [110/74]
C 141.85.68.200/30 is directly
connected
D 10.10.1.0 /24 [90/ 284160]
D 10.10.1.0 /24 [90/ 153750]
R3
D EX 172.20.114.192/26 [ 170/
261200]
D EX 172.20.113.192/26
[170/261200]
D EX 141.85.68.200/30 [170/261200]
D 10.10.1.0 /24 [90/ 281030]
Figura 7-1: Tabelele de rutare dup redistribuie

Figura de mai sus prezint tabelele de rutare ale lui R2 i R3 n urma redistribuirii
unidirecionale OSPF -> EIGRP folosind ruterul R2 ca punct de redistribuie. Exist mai multe
observaii importante ce trebuie realizate pe baza acestui exemplu:
Tabela de rutare a lui R2 a rmas neschimbat n urma redistribuirii. Acest comportament
este normal deoarece R2 avea toate rutele, att OSPF ct i EIGRP, n RAM, naintea
schimbului de rute.
Pentru c ruterul R3 are o adiacen valid cu R2, acesta din urm i-a comunicat noile rute
primite din domeniul OSPF
Exist protocoale de rutare care difereniaz prin distan administrativ rutele interne de
cele externe. Pe R3, protocolul EIGRP seteaz n acest caz o distan administrativ de 170.
Acest comportament ajut n evitarea rutrii suboptimale i n alegerea cii cele mai bune
ctre aceeai destinaie cunoscut . Aceste mecanisme vor fi prezentate n urmtorul
subcapitol.
Toate reelele externe au intrat n protocolul EIGRP cu aceeai metric. Acest
comportament este rezultatul unei pierderi de informaii de metric, inevitabil la trecerea
1
http://en.wikipedia.org/wiki/Inter-process_communication
151 | O p t i m i z a r e a r u t r i i
dintr-un protocol n altul. Metricile EIGRP i OSPF nu sun compatibilei de aceea EIGRP
utilizeaz o metric de intrare (seed metric) pe care o seteaz oricrei rute externe. Aceasta
metric de intrare este apoi incrementat n interiorul domeniului EIGRP funcie de
parametrii bandwidth i delay.
Atenie! Metrica de intrare nu este setat n mod implicit de ctre
niciun protocol de rutare n afar de OSPF i trebuie setat manual
folosind comanda default-metric sau la redistribuie. Dac acest lucru nu
este fcut redistribuia nu va funciona.
Metrica implicit a protocolului OSPF este 20.
n exemplul anterior se realizeaz o redistribuie unidirecional. n funcie de politica reelei,

acest proces poate fi bidirecional prin transmiterea rutelor din OSPF n EIGRP i invers.
Pe lng redistribuia ntre dou protocoale de rutare diferite se mai poate realiza i
redistribuirea rutelor statice sau direct conectate ntr-un protocol de rutare dinamic. n acest caz
toate protocoalele folosesc o metric de intrare implicit, nefiind nevoie ca aceasta s fie specificat
manual.
Metricile implicite pentru fiecare protocol de rutare pot fi consultate n tabelul de mai jos:
Protocol surs
Protocol destinaie
RIP
EIGRP
OSPF
ISIS
BGP (MED)
Connected
1
Metrica int
20 (E2)
0
0
Static
1
Metrica int
20 (E2)
0
0
RIP
infinite
20 (E2)
0
Metric IGP
EIGRP
infinite
20 (E2)
0
Metric IGP
OSPF
Infinite
Infinite
20 (E2)
0
Metric IGP
ISIS
Infinite
Infinite
20 (E2)
0
Metric IGP
BGP
infinite
infinite
1 (E2)
0
Metric IGP
Figura 7-2: Metrici de redistribuire
7.1.2 Problema rutrii suboptimale

Se va considera un scenariu de fuziune a dou companii. Compania A folosete RIPv2 ca i
protocol de rutare iar compania B, OSPF. Din motive de eficien a direcionrii fluxurilor de trafic
prin reea, s-a stabilit ca redistribuia ntre cele dou reele s se fac n cel puin dou puncte. De
asemenea, ambele companii doresc toate informaiile de rutare prin ambele puncte astfel nct
administratorul a decis s implementeze redistribuie bidirecional.
Se va presupune reeaua 10.10.10.0/24 direct conectat la unul din ruterele companiei A.
Administratorul va configura mai nti redistribuia pe ruterul R2 iar apoi pe R4. Astfel reeaua
10.10.10.0 va fi transmis prin ruterul R2 n domeniul OSPF. Ruterul R3 va trimite imediat mai
departe aceast reea ctre R4 cci OSPF folosete mesaje de update declanate de evenimente. n
acest moment, R4 are deja aceast reea n tabela de rutare cunoscut prin RIP cu o distan
administrativ de 120. Aceeai reea a venit ns din partea OSPF cu o distan administrativ de
110. Astfel ruterul va lua decizia de a instala n tabela de rutare ruta ce trece prin compania B,
ignornd calea mai scurt, direct prin ruterul R1, deoarece distana administrativ a protocolului
OSPF este mai bun dect a lui RIP. Orice trafic ctre reeaua 10.10.10.0/24 ce va ajunge de acum la
R4 va fi rutat suboptimal prin ruterul R3.
RIP
LAN
R2
OSPF
Compania B
Compania A
R1
R3
10.10.10.0/24
R4
Figura 7-3: Rutare suboptimal

Acest fenomen poart numele de route feedback i apare ntotdeauna cnd o rut trece dintrun protocol cu distana administrativ mare ntr-un protocol cu distana administrativ mai mic i
apoi napoi n protocolul iniial prin alt punct de redistribuie n reea.
Se ridic totui unele ntrebri n continuarea scenariului de mai sus:
1. De ce fenomenul de route-feedback se produce la R4 i nu la R2 ?
2. R4 este i el punct de redistribuie bidirecional. De ce nu redistribuie ruta 10.10.10.0 din
RIP n OSPF, urmnd ca i R2 s aib route-feedback?
3. R4 va face rutare suboptimal doar pentru reeaua 10.10.10.0/24 ?
1. Motivul pentru care R4 ajunge s fac rutarea suboptimal, i nu R2, este pentru c cel din
urm a fost primul ruter pe care s-a activat redistribuia. Orice protocol de rutare din prezent,
inclusiv RIPv2, are facilitatea transmiterii update-urilor declanate de evenimente; astfel reeaua
10.10.10.0/24 a ajuns printr-un mesaj de update OSPF mult mai repede dect a reuit R4 s
iniializeze procesul de redistribuie.
2. Chiar dac R4 este punct de redistribuie bidirecional, odat ce acesta a instalat n tabela
de rutare o rut OSPF ctre 10.10.10.0/24, nu mai poate redistribui aceast rut din RIP n OSPF
pentru c nu mai cunoate aceast rut prin primul din cele dou protocoale. Este aplicat regula
definit astfel: pentru a putea redistribui o rut din protocolul X n protocolul Y, acea rut trebuie s
fie prezent n tabela de rutare ca fiind cunoscut prin protocolul X.
3. Nu doar reeaua 10.10.10.0 va fi afectat de route feedback. Att reeaua dintre R1 si R2 ct
i oricare alt reea din compania A ce nu este direct conectat la R4 va fi susceptibil la aceast
problem.
Pentru evaluarea exemplului de mai sus este foarte important conceptul cheie de distan
administrativ. Definim astfel problema:
Faptul ca ruterul R4 nu a putut face diferena ntre rute interne domeniului OSPF si
rute ce au fost redistribuite n OSPF a produs rutarea suboptimal.
Dup cum s-a precizat n observaiile fcute la Figura 5-1, exist protocoale care pot face n
mod implicit diferena ntre rute externe i interne prin intermediul distanei administrative.
Se va presupune acelai scenariu de mai sus, nlocuind ns protocolul OSPF cu EIGRP. Cnd
ruta ctre reeaua 10.10.10.0/24 va fi introdus n EIGRP prin ruterul R2, distana sa administrativ
va fi setat la valoarea 170, implicit pentru rutele externe EIGRP. Ruterul R4 va alege acum ntre o
rut cu distana 170 (EIGRP) i o alt rut cu distana 120 (RIP). Este evident faptul c fenomenul de
route feedback nu va mai aprea, cci R4 va alege calea corect, prin RIP.
Dei EIGRP rezolv problema rutrii suboptimale definite mai sus, aceast soluie nu este
aplicabil n toate cazurile.
Pentru a obine o definiie complet a problemei se va extinde scenariul adugnd un domeniu
OSPF adiacent domeniului EIGRP.
R2
RIP
LAN
EIGRP
OSPF
Compania B
Compania A
R1
R3
11.11.11.0/24
10.10.10.0/24
R4
Figura 7-4: Rutare suboptimal 2

Ruterul R3 va fi unicul punct de redistribuie bidirecional dintre EIGRP i OSPF. O reea
oarecare 11.11.11.0/24 va fi introdus astfel n EIGRP i va primi o distan administrativ de 170,
ca orice alt rut extern. Ruta va fi apoi redistribuit prin R2 sau R4 (depinde care dintre cele dou
este mai rapid) n compania A. Se va presupune c ruterul R2 este mai rapid i ca a fost primul ce a
introdus 11.11.11.0/24 n RIP. Ruta va fi deci transmis prin domeniul RIP pn la ruterul R4.
Ca i n cazul anterior, ruterul R4 va avea deja o rut ctre 11.11.11.0/24 cu distana
administrativ 170 prin domeniul EIGRP. Ruta venit de la R1 prin RIP va avea ns distana
administrativ 120 deci R4 o va prefera pe aceasta. Astfel se va produce din nou rutare suboptimal
pentru orice trafic ce ajunge la ruterul R4 fiind destinat reelei 11.11.11.0/24. Devine astfel evident
nevoia unui mecanism de identificarea uoar a unor reele redistribuite i de manipularea
acestora.
n capitolele ce urmeaz se vor prezenta metodele cele mai folosite n rezolvarea problemei
descrise mai sus.
7.1.3 Bucle de rutare

Buclele de rutare sunt un caz particular i mult mai grav al rutrii suboptimale. Acestea pot
aprea n reele ce conin cel puin trei protocoale diferite de rutare i se rezolva adesea cu destul
de mult efort administrativ. Apariia buclelor de rutare nu se va discuta ns n acest capitol
deoarece conceptul depete scopul acestei cri. Mai multe informaii legate de acest subiect pot
fi obinute din cri de specialitate 1.
7.2 Manipularea rutrii

7.2.1 Manipularea update-urilor de rutare
Mesajele pe care orice protocol de rutare l are n comun este update-ul de rutare. Fie c se
numete LSA sau LSP, c se trimite la un interval fix de timp sau c este declanat de o schimbare n
reea, acesta este folosit de orice protocol pentru a transmite adrese de reea i metricile ataate
acelor adrese. Prin manipularea mesajelor de update se influeneaz cantitatea de informaie pe
care un ruter o are la dispoziie pentru a lua o decizie de direcionare, rezolvndu-se implicit i
problemele de rutare suboptimal sau buclele de rutare.
Cisco IOS conine mai multe mecanisme prin care se pot controla rutele att n procesul de
redistribuie ct i n afara acestuia. n acest sens, capitolele ce urmeaz vor prezenta:
Comanda passive-interface pasivizeaz o interfa pentru un protocol de rutare.n funcie
de tipul protocolului de rutare, efectele comenzii sunt diferite.
Comanda distance poate schimba distana administrativ pentru anumite rute nvate
dintr-un protocol specific
Mecanismul distribute-list principalul mecanism de filtrare de rute
Mecanismul route-map se folosete att n cele mai avansate tehnici de prevenire a
rutrii suboptimale (route tagging) ct i n traffic engineering i n protocolul BGP
7.2.1.1 Pasivizarea interfeelor

Cea mai puin complex i n acelai timp cea mai radical metod de manipulare a updateurilor de rutare este pasivizarea unei interfee. n funcie de protocolul de rutare folosit, o interfa
pasivizat se poate comporta n diferite moduri. Pasivizarea unei interfee se face n Cisco IOS prin
comanda passive-interface la nivel de interfa.
Protocoale distance-vector
Un protocol distance-vector va nceta s trimit update-uri de rutare pe o interfa pasivizat,
ns va continua s le primeasc. Acest lucru este foarte important n protocoale precum RIP
deoarece n acesta comanda network nu poate activa protocolul dect pe reele classful.
Pentru a exemplifica acest comportament se va folosi topologia de mai jos.
n figura 7-5 ruterul R1 este direct conectat la dou rutere de nivel distribuie i la o reea
local. Fiind o reea de dimensiune mic, pentru comunicarea de rute ntre cele 3 rutere se
folosete protocolul RIP. La introducerea comenzii network, procesul RIP va fi activat pe toate
interfeele ruterului R1 deoarece comanda network se activeaz pe reele classful. Astfel, pe
interfaa Fa0/0 vor fi trimise mesaje de update ce nu vor ajunge pe niciun alt ruter. Mai mult, aceste
mesaje pot reprezenta un risc de securitate cci comunic oricrei staii de pe reeaua local rute
cunoscute prin RIP.
Cisco.Press.CCIE.Routing.and.Switching.Exam.Certification.Guide.3rd.Edition.Nov.2007
Soluia pentru aceast problem este pasivizarea interfeei Fa0/0, fapt ce va duce la suprimarea
update-urilor trimise pe acea interfa.
R2
R3
11.11.11.192/30
11.11.11.196/30
R1
Fa0/0
11.11.12.0/24
Figura 7-5: passive-interface RIP
Protocoale link-state
n cazul link-state, pasivizarea unei interfee duce att la blocarea mesajelor de update
direcionate spre ruter, ct i la blocarea mesajelor de hello. Activarea comenzii passiveinterface ntre dou rutere va duce astfel la pierderea adiacenei ntre acestea. Utilitatea
comenzii este aceeai ca i n cazul distance-vector, ns cu un scenariu puin diferit. Dei orice
protocol link-state permite specificarea unui wildcard mask pentru identificarea reelei exacte pe
care se dorete activarea protocolului, cteodat legturile ctre un ruter sau switch de nivel 3 sunt
prea numeroase pentru a se introduce comanda network pentru fiecare reea n parte. n astfel de
situaii, de multe ori se prefer activarea la nivel de supernet i dezactivarea ctorva interfee pe
care nu se dorete rularea protocolului.
11.11.11.128/28
11.11.11.96/28
11.11.11.16/28
R1
Fa0/0
11.11.11.80/28
11.11.11.32/28
11.11.11.48/28
11.11.11.64/28
Figura 7-6: Passive-interface link-state

n figura de mai sus, pentru a activa OSPF pe toate interfeele n afar de cea dinspre reeaua
11.11.11.64/28, se folosete comanda network 11.11.11.0 0.0.0.255 [area 0], dup care
se pasivizeaz interfaa Fa0/0. Acest mod de operare este mult mai rapid dect folosirea a apte
comenzi network.
7.2.1.2 Schimbarea distanei administrative

La orice redistribuie de rute intervin pierderi de informaie n distana administrativ i metrica
unei reele. Se va reaminti topologia dat ca exemplu n capitolul 5.1.3:
RIP
LAN
R2
OSPF
Compania B
Compania A
R1
R3
10.10.10.0/24
R4
Figura 7-7: Rutare suboptimal

Ca i n cazul anterior, se va presupune R2 ca fiind primul punct n care se realizeaz
redistribuie bidirecional. La intrarea n spaiul OSPF, ruta 10.10.10.0 i pierde distana
administrativ de 120 i metrica de 1 hop, urmnd ca acestea s fie setate la valorile implicite
oferite de OSPF. Ruterul R4 va ajunge astfel s efectueze o comparaie ntre o rut RIP ctre
10.10.10.0 cu distana 120 i o rut OSPF ctre aceeai reea cu o distana 110. Alegerea incorect a
drumului se face datorit distanei administrative. Aici intervine mecanismul de schimbare a
distanei administrative folosind comanda distance. Aceasta ofer dou funcionaliti:
Identificarea unor reele afectate de comanda distance , folosind un ACL
Modificarea distanei administrative pentru reele identificate pentru a preveni o decizie
suboptimal de rutare
Prin comanda distance, n procesul OSPF de pe ruterul R4 se vor identifica toate reelele RIP
ce nu sunt direct conectate la acest ruter i li se va schimba distana administrativ la o valoare mai
mic de 110 nainte de introducerea lor n tabela de rutare. Cu aceast modificare, R4 va alege
ntotdeauna calea corect indicat de noua distan administrativ configurat. Identificarea
reelelor pentru care distana administrativ va fi schimbat n rutele asociate se face folosind o
list de acces. Dei pn la capitolul acesta ACL-urile au fost folosite doar pentru a bloca sau
permite trafic, acestea sunt, de fapt, mecanismul general folosit n IOS pentru identificarea rutelor
i destinaiilor.
Deoarece la redistribuia bidirecional nu se poate determina care dintre cele dou rutere de
border va iniia primul procesul de redistribuie, mecanismul de schimbare a distanei
administrative trebuie aplicat pe ambele rutere.
Sintaxa i aplicarea comenzii distance va fi studiat n capitolul 5.3.
7.2.1.3 Filtrarea rutelor

Fa de mecanismul de schimbare a distanei administrative, filtrare de rute nu presupune
modificarea metadatelor unei rute ci pur i simplu mpiedicarea nvrii rutei de ctre protocol. n
Cisco IOS acest scop este atins folosind distribute-list.
Aplicnd conceptul n topologia anterioar, R4 va folosi un distribute-list pentru a identifica
reele provenite din RIP pe care le primete de la R3 i apoi pentru a le filtra din tabela de rutare.
Astfel R4 nu va ajunge niciodat la procesul de alegere ntre o rut RIP i alta OSPF ctre aceeai
reea, cci va cunoate ntotdeauna doar rute RIP ctre reelele din domeniul RIP i doar rute OSPF
ctre reelele din domeniul OSPF.
Identificarea reelelor ce trebuie filtrate ntr-un distribute-list se face ca i n comanda distance,
folosind un ACL. Mai multe detalii de sintax vor fi oferite n capitolul 5.3
Comportamentul de filtrare a unui distribute-list este ns diferit pentru protocoale distancevector i link-state.
n protocoalele distance-vector un distribute-list va filtra complet rutele identificate astfel nct
acestea nu se vor gsi niciunde n memoria ruterului. Protocoalele link state pstreaz rutele
primite n tabela de topologie, ns ct timp distribute-list-ul este activ, nu le promoveaz niciodat
n tabela de rutare.
7.2.2 Policy-based routing

Rutarea IGP 1 are ca principal scop gsirea celei mai bune rute bazate pe o metric relevant,
ctre o destinaie posibil. Cteodat sunt necesare unele excepii de la aceast regula, excepii
generate de anumite decizii de politic. Procesul prin care o decizie a protocolului de rutare este
suprascris de o politic ce a fost configurat manual poart numele de rutare bazat pe politic
sau Policy-based routing (PBR).
7.2.2.1 Route-maps
n Cisco IOS, Policy-based routing este implementat folosind route-map-uri. Un route-map are o
logic asemntoare cu structurile if/then/else folosite n limbajele de programare.
Pentru a identifica diferite tipuri de trafic, un route-map folosete comenzi match care pot
folosi n spate liste de acces sau diferite criterii de rutare (ex: interfaa de intrare a pachetelor).
Dup ce anumite pachete au fost identificate, route-map-ul poate specifica i anumite aciuni
pentru acele pachete folosind comenzi set. Acest aspect este cel care face din route-map un
instrument foarte puternic. Route-map-urile sunt folosite n realizarea mai multor configuraii:
PBR
Manipularea atributelor BGP
Controlul redistribuirii
Figura de mai jos prezint structura unui route-map.
http://en.wikipedia.org/wiki/Interior_gateway_protocol
route-map my_map permit 10

{match statement1 statement2 }
{match statement3 statement4 }
{ set action1 }
route-map my_map deny 20
{match statement 1}
route-map my_map permit 30
{set action_default}
Figura 7-8: Structura unui route-map
Un route-map este construit din mai multe reguli ce sunt parcurse secvenial, precum regulile
unui ACL. Fiecare regul este precedat de cuvntul cheie route-map, numele route-map-ului,
aciunea global (permit/deny) i un index relevant n ordinea n care se proceseaz intrrile din
route-map.
Dup cum se poate observa, intrrile de mai sus conin indeci din zece n zece uniti. Acest
mod de a scrie un route-map este un best practice ce permite inserarea facil a altor intrri
intermediare n cazul n care se dorete modificarea logicii route-map-ului. Pentru ca sistemul de
operare s poat lega toate regulile route-map-ului ntr-o list, va trebuie ca fiecare regul s aib
acelai nume cu cel al route-map-ului (n cazul de mai sus: my_map).
Fiecare regul are una sau mai multe comenzi match care reprezint modul de identificare a
traficului. Fiecare comand match poate avea mai multe argumente. Se prezint astfel dou cazuri
de evaluare logic a statement-urilor:
Dac exist mai multe statement-uri n cadrul unei singure comenzi match, se va aplica I
LOGIC ntre acestea. Cu alte cuvinte trebuie ca toate aseriunile despre respectivul trafic s
fie adevrate pentru a face o potrivire cu acea regul.
Dac exist mai multe comenzi match n cadrul unei reguli, se va aplica SAU LOGIC ntre
acestea. Cu alte cuvinte trebuie ca cel puin o comand match s fie evaluat ca fiind
adevrat pentru a face o potrivire cu acea regul.
Dup ce s-a realizat o potrivire cu o anumit regul, procesorul va ncerca s execute aciunea
precizat de comanda set. Prin aceasta se pot schimba atribute ale rutei sau se poate suprascrie
logica de rutare a protocolului de rutare (PBR). Dac nu exist nicio regul set sau toate regulile set
prezente au fost aplicate, se va aplica aciunea global. Aceasta poate fi permit sau deny, ns n
funcie de mecanismul ce folosete route-map-ul cele dou cuvinte cheie au diferite interpretri.
Ca i exemplu, dac mecanismul este PBR, o aciune global permit va nsemna c acest trafic
este introdus n PBR i este rutat n funcie de politica aplicat n comanda set. Dac aciunea
global este deny, nseamn ca acest tip de trafic nu trebuie s fie rutat n funcie de politic i
trebuie introdus n procesul normal de rutare.
n contrast, dac mecanismul este controlul redistribuirii, o aciune global deny va nsemna c
respectiva ruta nu va fi redistribuit. Mai multe detalii despre acest proces vor fi oferite n
urmtorul capitol.
Ambele directive (set i match) pot lipsi dintr-o regul de route-map. Dac directiva set lipsete
nseamn c administratorul nu dorete alterarea acelui trafic n niciun mod. Lipsa directivei match
este echivalent cu un statement de tipul match any. Cu alte cuvinte, orice trafic va fi potrivit cu
acea regul.
Ca i un ACL, orice route-map are la sfritul listei de reguli o regul invizibil care identific tot
traficul i care are aciunea global deny. Acesta este motivul pentru care n route-map-ul
exemplificat mai sus ultima regul nu conine directiva match (pentru a face potrivire cu orice fel de
trafic) i are ca aciune global permit. Acest mod de configurare depinde ns de logica route-mapului. Dac acesta a fost construit pentru a permite doar cteva pachete specifice, regula logic
invizibil match none de la sfrit va fi potrivit. Dac se dorete ns potrivirea pe toate pachetele
n afar de cteva reele, se va aduga o regul ca ultima din exemplu.
7.3 Configurri n optimizarea rutrii

7.3.1 Configurarea redistribuirii ntre protocoale de rutare
Exist o singur comand prin care se realizeaz redistribuia i anume comanda
redistribute. Aceast comand este implementat n modul (config-router)# i, n funcie
de politicile de rutare, poate primi o serie de parametri ce pot influena metrici, tipuri de rute
redistribuite sau reele specifice pentru a fi redistribuite.
Partea uor confuz n efectuarea configurrilor de redistribuie este realizarea diferenei ntre
protocolul n care se face redistribuia i protocolul din care se face redistribuia. Cel mai simplu
mod de a reine este prin urmtoarea regul:
Protocolul n care se realizeaz redistribuia este protocolul dat ca parametru comenzii

router, iar protocolul din care se realizeaz redistribuia este protocolul dat ca parametru
comenzii redistribute.
Pentru aplicarea acestei reguli se va considera urmtorul exemplu de redistribuie a
protocolului RIP n OSPF.
Waters(config)# router ospf 1
Waters(config-ruter)#redistribute rip
% Only classful networks will be redistributed
Urmrind regula de mai sus, pentru c se dorea redistribuia n OSPF s-a folosit comanda ruter
ospf 1, iar pentru c protocolul redistribuit era RIP, acesta a fost dat ca parametru comenzii
redistribute. Se poate observa c la comanda de redistribuie sistemul de operare a returnatun
mesaj de avertizare. Dat n aceast form, comanda va introduce n OSPF doar reele classful (A, B
sau C). Pentru a rezolva aceast problem trebuie adugat cuvntul cheie subnets.
De asemenea, comanda redistribute nu a precizat mai sus nicio metric de intrare n
protocol (seed metric). Pe lng ISIS, doar n OSPF se pot redistribui rute din alt protocol fr a
preciza manual metrica de intrare. Orice rut extern adus n OSPF va avea o metric implicit de
20 i un metric-type E2. Este recomandat ca n topologii i scenarii reale s fie modificai aceti
parametrii pentru a asigura o difereniere ntre multiplele rute de ieire din arie (dac acestea
exist) folosind parametrii: metric i metric-type.
EIGRP folosete o metric construit din maxim 5 variabile: bandwidth, delay, reliability, load,
MTU. n mod implicit sunt folosite doar bandwidth i delay cu valorile configurate pe fiecare
interfa. Calculul metricii se realizeaz dup formula EIGRP:
EIGRP Metric = 256*([K 1 *Bw + K 2 *Bw/(256-Load) + K 3 *Delay]*[K 5 /(Reliability + K 4 )])
Datorit constantelor K setate la 0 pentru valorile load, reliability sau delay, acestea nu vor
participa n mod implicit n formul.
n general EIGRP poate fi configurat pentru a fi destul de exact folosind doar metricile implicite.
Cnd se redistribuie orice protocol de rutare n EIGRP trebuie specificate toate variabilele ce
formeaz metrica, chiar dac vor fi folosite toate.
Waters(config)# router eigrp 100
Waters(config-ruter)#redistribute ospf 1 metric 10000 100 255 1 1500
La redistribuia n EIGRP doar rutele direct conectate i cele statice sunt introduse cu o metric
de intrare valid. Valoarea acesteia este calculat cu parametrii bandwidth i delay ai interfeei
direct conectate, respectiv interfeei de ieire a rutei statice.
ISIS are un comportament prin care seteaz metrica oricrei rute externe la valoarea 0. Acest
lucru nu nseamn ca refuz s o redistribuie deoarece o metric de 0 este valid n ISIS. La
redistribuia ISIS n alt protocol de rutare se poate opta pentru introducerea rutelor level-1, level-2,
level-1-2.
R1(config-ruter)#redistribute isis ?
WORD
ISO routing area tag
level-1
IS-IS level-1 routes only
level-1-2 IS-IS level-1 and level-2 routes
level-2
IS-IS level-2 routes only
...
Pn n acest moment s-au discutat comenzile de care este nevoie pentruine

a ob
o
redistribuie funcional ntre oricare dou protocoale de rutare. Exist ns situaii n care, dei e
nevoie de redistribuie, nu se dorete transferul tuturor rutelor dintr-un protocol n altul din motive
administrative sau politice. Folosind conceptele de route-map discutate n capitolul anterior se pot
controla rutele ce vor fi redistribuite. Comanda redistribute poate primi sub orice protocol de
re specifice ce se doresc
a fi
rutare parametrul route-map prin care se pot identificaele
redistribuite. Astfel se produce un fel de filtrare a rutelor prin evitarea redistribuirii unor re ele.
Se va analiza comportamentul unei astfel de tehnici de filtrare n configurarea redistribu
iei
protocolului RIP n OSPF.
router ospf 1
redistribute rip subnets route-map RIP_TO_OSPF
!
ip access-list standard RIP_TO_OSPF
permit 10.1.1.0 0.0.0.255
permit 192.4.5.0 0.0.0.255
permit 141.99.56.0 0.0.0.255
!
route-map RIP_TO_OSPF permit 10
match ip address RIP_TO_OSPF
set metric +10
Deoarece redistribuia se face n OSPF, acesta este protocolul dat ca i parametru comenzii
router. Comanda redistribute este dat cu parametrul subnets alturi de route-map-ul cu
numele RIP_TO_OSPF. Mai jos este definit acest route-map care face potrivire pe regula 10 cu o list
de acces ce poart acelai nume. Aciunea pentru aceast intrarea este incrementarea metricii de
intrare n OSPF cu valoarea 10 (deci n mod implicit intrarea n OSPF se va face cu metrica 30).
Aciunea global a intrrii din route-map este permit. Prin acest cuvnt cheie se specific realizarea
redistribuiei dac i numai dac reelele ce se doresc a fi redistribuite se regsesc n lista de acces
RIP_TO_OSPF. Dac reeaua ce se dorete redistribuit nu poate fi identificat de lista de acces de
mai sus, ruterul va procesa urmtoarea intrare din route-map care este de fapt intrarea implicit
invizibil ce aplic aciunea deny pe orice reea. Astfel vor fi redistribuite doar reelele pe care se
face potrivirea n intrarea 10 a route-map-ului.
7.3.2 Configurarea filtrrii rutelor

Una dintre cele mai cunoscute
i utilizate metode de filtrare a rutelor este mecanismul
distribute-list. Acest tip special de list de acces este folosit pentru a identificaele
re din
updateurile de rutare ale protocoalelori pentru a aplica pachetelor ce transport aceste update-uri una
dintre cele dou aciuni implicite ale unei liste de acces uzuale: permit sau deny. n comparaie cu o
list de acces simpl, un distribute-list este folosit pentru a filtra rute n locul pachetelor de date.
Un distribute-list poate fi aplicat ntr-un dintre cele dou modaliti:
Filtru de intrare: n acest caz distribute-list-ul poate specifica doar interfaa de intrare pe
care s fie filtrate update-urile. n cazul n care aceast interfa nu este specificat pentru
un filtru de intrare, acesta se va aplica pe toate interfeele ruterului.
Filtru de ieire: n acest caz distribute-list-ul poate specifica att interfaa de ieire ct i
protocolul de rutare n care nu trebuie trimise rutele specificate.
Pentru a observa comportamentul unui distribute-list se vor analiza urmtoarele configurri
care previn trimiterea update-urilor ce conin reelele 10.10.1.0/24 i 192.168.1.0/24 n cadrul
protocolului RIPv2.
router rip
network 18.0.0.0
distribute-list filter_private in Serial1/0
!
ip access-list standard filter_private
deny
10.10.1.0 0.0.0.255
deny
192.168.1.0 0.0.0.255
permit any
!
Pentru a identifica reelele ce trebuie filtrate, comenzii distribute-list i-a fost dat ca parametru
lista de acces numit filter_private. Direcia de filtrare a fost specificat ca fiind in, activ doar
pe interfaa Serial1/0. Astfel ruterul va filtra reelele specificate n lista de acces la intrarea updateurilor de rutare pe interfa
a sa Serial1/0. Este necesar mult atenie la configurarea unui
distribute-list deoarece, fa de un route-map, unde potrivirea rutelor se fcea folosind directiva
permit din ACL, n acest caz specificarea rutelor ce se doresc filtrate se face cu deny.
Una din cele mai frecvente gre
eli realizate n configurri de filtrare este omiterea directivei
permit any de la finalul listei de acces. Deoarece un ACL are n mod implicit o directiv deny any la
sfritul ei, administratorul de reea trebuie s introduc un permit any la sfritul unui distributelist pentru a permite orice alte update-uri dect cele filtrate.
Atenie! Aplicarea unui distribute-list pe direcia de ieire pe o interfa nu este posibil

dect pentru protocoalele distance-vector i EIGRP.
7.3.3 Configurarea PBR

Dup cum s-a discutat n capitolul 5.2.2, mecanismul de PBR se configureaz n Cisco IOS
folosind route-map-uri. Ca i n s ituaia prezent n capitolul 5.3.1, prima parte a route-map-ului
este folosit pentru a face potrivire cu traficul interesant. Aceast potrivire se face prin intermediul
unei liste de acces cu directive permit. Partea din route-map prin care se face de fapt Policy-Based
Routing este comanda set. Prin intermediul acesteia se poate specifica suprascrierea deciziei de
rutare prin forarea pachetului spre un anumit vecin sau pe o anumita interfa
de ieire. Dup
crearea route-map-ului i al listei de acces folosite pentru potrivire, administratorul trebuie s indice
interfaa pe care PBR va fi activat. Pe fiecare interfa a ruterului poate exista o singura politic de
PBR.
n exemplul de mai jos, ruterul va trimite toate pachetele cu adres surs
eaua
din re
10.10.1.0/24 i adres destinaie 141.85.57.1 pe interfaa de ieire Serial1/0 indiferent de decizia pe
care protocolul de rutare o ia.
interface Serial1/1
ip address 18.7.15.1 255.255.255.0
ip policy route-map web_server
!
ip access-list extended web_server
permit ip 10.10.1.0 0.0.0.255 host 141.85.57.1
!
route-map web_server permit 10
match ip address web_server
set interface Serial1/0
!
O greeal des ntlnit n configurarea PBR este setarea interfeei de ieire n cazul n care
aceasta folosete tehnologie de tip Ethernet. Dei Proxy -ARP este activ n mod implicit pe rutere
Cisco, acesta nu va interveni n rezolvarea problemi iar ruterul nu va ti cu ce adres MAC destinaie
trebuie s trimit. Se recomand ca, la rutarea traficului spre o interfa Ethernet, comanda s
specifice dirct next-hop-ul, i nu interfaa de ieire.
De asemenea, trebuie reinut c traficul generat local nu este trecut n mod implicit prin filtrul
de PBR. Acest comportament este motenit de la ACL-uri unde traficul generat local pe ruter nu este
afectat de ctre ACL. Cisco ofer ns o alt variant prin care se pot configura politici pentru trafic
local. Acest lucru se face din modul global de configurare din IOS prin comanda: ip local-policy
route-map <route-map-name>.
7.4 Studiu de caz

Urmtorul scenariu este propus pentru a exemplifica modul de aplicare a conceptelor de
optimizare a rutrii ntr-o reea complex. Topologia, prezentat in figura 5-7, pretinde o serie de
zone, n fiecare dintre acestea rulnd cte un protocol de rutare diferit. Vor trebui realizate
configurrile pentru ca reeaua s convearg i pentru a respecta o serie de cerine privind modul n
care se face rutarea.
OSPF
RIP
Fa0/
10.0.0.0/30
Fa0/
R2
Fa1/
10.0.0.4/30
Fa0/
10.0.0.8/30
Fa1/
Fa1/
R1
L0
E0/0
D1
10.0.0.16/30
E0/0
84.34.18.0/25
R3
L0
E2
10.0.0.24/30
E0/2
Internet
E1
E0/1
10.0.0.20/30
Fa1/
Fa1/
10.0.0.12/30
L0
E0/0
D2
E0/3
10.0.0.28/30
E0/0
84.34.18.128/25
Figura 7-9: Propagarea rutei implicite
E0/0
E3
L0
7.4.1 Configurri iniiale

Pentru reeaua de test a fost alocat spaiul de adrese 84.34.18.0/23 pentru reelele conectate
la rutere; pentru legturile dintre echipamentele de reea se folosete spaiul de adrese
10.0.0.0/24.
R1#show ip interface brief | include up
FastEthernet0/0
10.0.0.1
FastEthernet1/0
10.0.0.9
Loopback0
84.34.18.1
YES manual up
YES manual up
YES manual up
up
up
up
R2#show ip interface brief | include up

FastEthernet0/0
10.0.0.2
FastEthernet1/0
10.0.0.5
YES manual up
YES manual up
up
up
R3#sh ip interface brief | include up

FastEthernet0/0
10.0.0.6
FastEthernet1/0
10.0.0.13
Loopback0
84.34.18.129
YES manual up
YES manual up
YES manual up
up
up
up
D1#show ip interface brief | include up

Ethernet0/0
10.0.0.17
FastEthernet1/0
10.0.0.10
YES manual up
YES manual up
up
up
D2#show ip interface brief | include up

Ethernet0/0
10.0.0.21
FastEthernet1/0
10.0.0.14
YES manual up
YES manual up
up
up
E1#show ip interface brief | include up

Ethernet0/0
10.0.0.18
Ethernet0/1
10.0.0.22
Ethernet0/2
10.0.0.25
Ethernet0/3
10.0.0.29
YES
YES
YES
YES
up
up
up
up
up
up
up
up

Ethernet0/0
10.0.0.26
Loopback0
84.34.19.1
YES manual up
YES manual up
up
up

Ethernet0/0
10.0.0.30
Loopback0
84.34.19.5
YES manual up
YES manual up
up
up
manual
manual
manual
manual
Interfeele Loopback0 de pe E2 i E3, ce simuleaz legtura ctre Internet, au fost configurate

cu adrese din spaiul 84.34.18.0/23.
Ruterele R1, R2 i R3 sunt slabe ca putere de procesare i memorie, aa c s-a luat decizia rulrii
protocolului RIP n respectiva zon din reea. E1, E2 i E3 fac parte din nucleul reelei de fa, pe
aceste rutere fiind necesar rularea protocolul OSPF. E2 i E3 vor asigura de asemenea i legtura
ctre Internet a reelei.
D1(config)#router rip
D1(config-router)#no auto-summary
D1(config-router)#version 2
D1(config-router)#network 10.0.0.0
D1(config-router)#passive-interface ethernet 0/0
D1(config-router)#exit
D1(config)#router ospf 1
D1(config-router)#network 10.0.0.16 0.0.0.3 area 0
D2(config-router)#no auto-summary
D2(config-router)#version 2
D2(config-router)#network 10.0.0.0
D2(config-router)#passive-interface ethernet 0/0
D2(config-router)#network 10.0.0.20 0.0.0.3 area 0
E1(config)#router ospf 1
E1(config-router)#network 10.0.0.0 0.255.255.255 area 0
E2(config)#ip route 0.0.0.0 0.0.0.0 loopback 0
E2(config-router)#default-information originate
E3(config)#ip route 0.0.0.0 0.0.0.0 loopback 0
E3(config-router)#default-information originate
De amintit faptul c, datorit comportamentului classful pe care l are protocolul RIP la activare,
se introduc automat n protocol toate reelele direct conectate ce fac parte, n cazul de fa, n
10.0.0.0/8. Pentru ca ruterele D1 i D2 s nu trimit update-uri RIP pe legturile ctre E1, au fost
pasivizate aceste interfee din modul de configurare RIP.
Au fost configurate 2 rute default pentru reea, una pe E2 i una pe E3, ce au fost introdue apoi
n OSPF pentru a fi propagate.
n acest moment, n cele dou zone din reea rutele sunt propagate. Tabela de rutare pe D1
(mpreun cu D2 sunt singurele ce cunosc att rute RIP ct i OSPF) arat astfel:
D1#show ip route
C
R
R
R
O
10.0.0.24 [110/20] via 10.0.0.18, 00:04:09, Ethernet0/0
O
10.0.0.28 [110/20] via 10.0.0.18, 00:04:09, Ethernet0/0
C
O
10.0.0.20 [110/20] via 10.0.0.18, 00:04:09, Ethernet0/0
O*E2 0.0.0.0/0 [110/1] via 10.0.0.18, 00:04:09, Ethernet0/0
R
R
Pe R1, tabela de rutare arat astfel:
R1#sh ip route
C
R
C
R
C
R
R
R

84.34.18.0 is directly connected, Loopback0
Pe E1, tabela de rutare arat astfel:

E1#sh ip route
C
C
C
C
O*E2 0.0.0.0/0 [110/1] via 10.0.0.30, 00:00:00, Ethernet0/3
[110/1] via 10.0.0.26, 00:00:00, Ethernet0/2
7.4.2 Redistribuirea protocoalelor de rutare

Dup cum se observ din tabelele de rutare ale celor 3 rutere, cele dou zone sunt complet
izolate din punct de vedere al rutrii. Pentru a rezolva aceast problem, trebuie fcut
redistribuirea informaiei de rutare ntre RIP i OSPF.
n cazul de fa se dorete realizarea redistribuirii n ambele sensuri, att pe D1 ct i pe D2,
pentru a folosi la maxim redundana oferit de topologie. n continuare se prezint configuraiile ce
sunt necesare pentru a realiza acest lucru:
D1(config-router)#redistribute rip subnets
D1(config-router)#redistribute ospf 1 metric 1
D2(config-router)#redistribute rip subnets
n momentul n care se redistribuie un protocol in OSPF este important argumentul subnets.

Dac acesta nu este precizat, se vor distribui numai clasele majore de IP, nu i subreelele acestora.
La redistribuirea n RIP este obligatorie specificarea unei metrici pentru rutele ce vor fi
importate. Dac aceast metric nu este specificat, se va presupune metrica 16 (infinit) i rutele nu
vor aprea n tabela de rutare i nici nu vor fi comunicate altor rutere.
Dup realizarea redistribuiei, tabela de rutare pe R1 i E1 arat astfel:
R1#sh ip route
C
R
C

R
C
R
R
R
R
R
R*

E1#show ip route
O E2
O E2
O E2
O E2
O E2
O E2
C
C
C
C
O*E2

84.34.18.0 [110/20] via 10.0.0.17, 00:15:39, Ethernet0/0
84.34.18.128 [110/20] via 10.0.0.17, 00:15:39, Ethernet0/0
10.0.0.8 [110/20] via 10.0.0.17, 00:15:39, Ethernet0/0
10.0.0.12 [110/20] via 10.0.0.21, 00:15:39, Ethernet0/1
10.0.0.0 [110/20] via 10.0.0.17, 00:15:39, Ethernet0/0
10.0.0.4 [110/20] via 10.0.0.17, 00:15:39, Ethernet0/0
0.0.0.0/0 [110/1] via 10.0.0.30, 00:15:39, Ethernet0/3
[110/1] via 10.0.0.26, 00:15:39, Ethernet0/2
7.4.3 Probleme la redistribuie

Dei la o prim privire redistribuirea pare s se fi fcut fr probleme, la o mai atent analiz a
tabelelor de rutare din zona RIP pot fi identificate cteva probleme. De exemplu, ruta ctre reeaua
10.0.0.12/30 are ca next hop D1, urmnd apoi s treac prin E1 i D2, dei ar fi fost mult mai rapid
s aib ca next hop pe R2.
Acest comportament poart numele de rutare suboptimal i poat s apar n cazul
configurrii incorecte a redistribuirii. Problema se datoreaz faptului c redistribuia a fost realizat
n ambele direcii i n dou puncte distincte. D1 ia rute din zona RIP pe care le include n OSPF iar
D2 le trimite napoi n RIP. Att D1 ct i D2 vor prefera rutele ce trec prin OSPF datorit distanei
administrative mai mici i vor trimite mai departe ctre R1 i R3 rutele suboptimale. Dac R1 i R3
prefer aceste rute n detrimentul celor interne mai bune (pe baza metricii), se ajunge la rutare
suboptimal.
Pentru a remedia aceast problem, exist o serie de soluii. Una dintre acestea const n a face
rutele RIP reintroduse n zona OSPF neatractive, fie prin mrirea metricii fie prin mrirea distanei
administrative. O alt soluie se bazeaz pe filtrarea rutelor ce sunt redistribuite, pentru a nu trimite
RIP napoi n zona RIP.
7.4.3.1 Evitarea rutrii suboptimale prin redistribuirea de rute neatractive

n momentul n care se face redistribuirea din OSPF n RIP, metrica rutelor introduse este setat
la o valoare ridicat. Rutele ctre zona OSPF, fiind singurele pe care ruterele le au la dispoziie, chiar
dac au cost ridicat, vor fi folosite. Rutele suboptime, ns, vor fi nlocuite de rutele interne zonei
RIP, ce au metric mai mic.
R1#sh ip route
C
R
C
R
C
R
R
R
R
R
R*

Se observ foarte repede rutele ce au fost primite de la OSPF (metrica = 5) i rutele interne
zonei RIP.
7.4.3.2 Evitarea rutrii suboptimale prin filtrarea rutelor

Pentru a nu trimite rute napoi n RIP i a risca rutare suboptimal, se poate folosi un distributelist pentru ca ABR-urile OSPF s nu mai promoveze ctre tabelele de rutare rute OSPF ctre reele
din zona RIP. Un exemplu de configurare pentru reeaua de fa:
D1(config)#access-list 10 deny 84.34.18.0 0.0.0.255
D1(config)#access-list 10 permit any
D1(config-router)#distribute-list 10 in ethernet 0/0
Distribute-list se configureaz n protocolul ce trebuie redistribuit, n cazul nostru OSPF i

filtreaz toate rutele RIP ce ajung de la vecinii OSPF. Tabela de rutare a lui R1 devine:
R1#sh ip route
C
R
C
R
C
R
R
R
R
R
R*

Se observ dispariia rutelor suboptimale datorit filtrrii rutelor; metrica cu care se injecteaz
rute n RIP a fost setat napoi la 1.
7.4.4 Policy Based Routing

Se pune acum problema implementrii unor politici de rutare n reeaua de test. Cum reeaua
dispune de dou ieiri ctre Internet, se dorete folosirea uneia dintre acestea pentru traficul critic
generat de ctre R3, cealalt fiind folosit pentru restul traficului.
Pentru a implementa o astfel de cerin, se folosete un route-map prin care sunt specificate
politicile dorite. n cazul de fa, se va face match pe o serie de adrese IP surs ce vor fi rutate apoi
conform instruciunilor din set. PBR se va implementa pe ruterul E1.
E1(config)#access-list 10 permit 84.34.18.128 0.0.0.127
E1(config)#access-list 10 permit host 10.0.0.6
E1(config)#access-list 10 permit host 10.0.0.13
E1(config)#access-list 20 deny 84.34.18.128 0.0.0.127
E1(config)#access-list 20 deny host 10.0.0.6
E1(config)#access-list 20 deny host 10.0.0.13
E1(config)#access-list 20 permit any
E1(config)#route-map pbr 10
E1(config-route-map)#match ip address 10
E1(config-route-map)#set interface ethernet 0/2
E1(config)#route-map pbr 20
E1(config-route-map)#match ip address 20
E1(config-route-map)#set interface ethernet 0/3
Prima parte a route-map-ului va trimite ctre Ethernet 0/2 (ieirea spre Internet prin E2) toate
pachetele ce vin de la adresele IP ale lui R3 sau din reeaua acestuia de loopback. Dac ne-am fi
oprit aici din configurare, pentru orice alt IP se va ajunge la rutare normal, existnd anse ca i alte
pachete s fie trimise ctre ruterul E2. Pentru a nu exista astfel de probleme, se face match explicit
pe restul traficului i acesta este trimis ctre ruterul E3.
Folosind debug ip policy pe ruterul E1, se poate vedea rezultatul configurrilor fcute:
R3#ping 23.23.23.23
E1#
*Mar 1 01:23:19.483: IP: s=10.0.0.13 (Ethernet0/1), d=23.23.23.23,
len 100, FIB policy match
*Mar 1 01:23:19.483: IP: s=10.0.0.13 (Ethernet0/1), d=23.23.23.23
(Ethernet0/2), len 100, FIB policy routed
R1#ping 23.23.23.23
E1#
*Mar 1 01:23:32.071: IP: s=10.0.0.9 (Ethernet0/0), d=23.23.23.23, len
100, FIB policy match
*Mar 1 01:23:32.071: IP: s=10.0.0.9 (Ethernet0/0), d=23.23.23.23
(Ethernet0/3), len 100, FIB policy routed
8 B GP
8.1 Protocolul BGP

8.1.1 Sisteme autonome
La nceputurile anilor '80, ruterele care constituiau ARPANET-ul (predecesorul Internetului
modern) rulau un protocol de rutare distance-vector cunoscut sub numele GGP (Gateway-toGateway Protocol). Pe msur ce reeaua cretea, arhitecii si au constatat c acest protocol nu
oferea scalabilitatea necesar.
Eric Rosen, n RFC827, identific o serie de probleme legate de aceast abordare:
overhead-ul dat de algoritmul de rutare crete exponenial cu creterea dimensiunilor
reelei;
rularea protocolului de rutare pe o varietate de platforme diferite (hardware i/sau
software) face administrarea (i izolarea problemelor) aproape imposibil;
rezistena la schimbare crete odat cu extinderea reelei (orice schimbare trebuie aprobat
de toi administratorii).
Ca urmare, RFC827 propune o soluie inovatoare: migrarea ARPANET de la structura monolitic
spre o structur modular - un sistem de subreele autonome interconectate. Aceste subreele au
fost denumite sisteme autonome (Autonomous System - AS).
Un AS reprezint o colec
ie de rutere (i eventual alte echipamente de reea) aflate sub un
control administrativ comun. Fiecare AS este identificat printr-un numr unic la nivel global. Aceste
i autoritate care aloc
numere (AS Numbers, pe scurt ASN) sunt alocate de ctre IANA (aceea
adresele IP).
Iniial numerele de AS erau valori ntregi pe 16 bii (valori de la 0 la 65535), dar n momentul
actual (2009) este n curs de desf
urare procesul de trecere la ASN pe 32 de bii. Acestea sunt
reprezentate n format x.y, unde xi y sunt numere pe 16 bii. n noul format, vechile ASN (pe 16
bii) sunt notate ca 0.y.
Protocoalele de rutare discutate pn acum (RIP, OSPF, EIGRP, Integrated IS-IS) ruleaz de
obicei n interiorul unui AS, fiind cunoscute ca IGPs (Interior Gateway Protocols). Pentru
comunicarea rutelor ntre sistemele autonome se folose
te o nou clas de protocoale, aa
-
numitele EGPs (Exterior Gateway Protocols). Din aceast clas fac parte EGP (care practic nu se mai
folosete astzi) i Border Gateway Protocol (BGP).
La ora actual, practic toat rutarea ntre ISP este realizat prin BGP versiunea 4ie(nota
BGPv4).
8.1.2 Cnd este necesar BGP?

Deseori reelele mari sunt mprite n mai multe domenii de rutare, fiecare rulnd propriul su
protocol de rutare. O greeal frecvent este aceea de a considera c ntotdeauna n astfel de cazuri
este necesar rularea BGP ntre domeniile respective. De multe ori ns, o astfel de decizie nu face
altceva dect s complice administrarea reelei.
Din punct de vedere al interconectrii lor, sistemele autonome se mpart n dou categorii:
single-homed AS (au o singur conexiune ctre un alt sistem autonom). n aceast categorie
intr majoritatea reelelor mici (i multe dintre reelele medii de tip enterprise);
multi-homed AS (dou sau mai multe conexiuni ctre alte sisteme autonome) - reelele de
tip ISP, sau reele de enterprise cu conexiuni multiple la Internet.
n cazul sistemelor autonome single-homed, BGP nu ofer niciun fel de beneficiu. Cea mai bun
soluie n acest caz este folosirea unei rute implicite (default), generat local sau injectat de ctre
ISP. Complexitatea BGP devine util doar n cazul unui AS multi-homed, cnd prin manipularea
atributelor BGP devine posibil selectarea cilor de intrare/ie ire din AS pentru pachetele de date.
8.1.3 BGP - noiuni de baz

Spre deosebire de IGP-urile studiate pn acum, BGP nu se ncadreaz complet ntr-una din
clasele distance-vector sau link-state. Cel mai corect, BGP este descris ca un path vector
protocol.
Dac n cazul IGP-urilor rutele urmreau ruterele individuale prin care treceau pachetul, BGP
adopt o viziune de ansamblu asupra reelei, n care fiecare AS este considerat un hop (indiferent
dac pachetele traverseaz un singur ruter sau 100 la trecerea prin acel AS). Pentru fiecareea
re
destinaie, BGP reine lista de AS-uri care vor trebui traversate de un pachet pentru a ajunge la acea
reea (AS_PATH), precum i next-hop-ul (vectorul, sau direcia n care trebuie trimise pachetele cu
respectiva destinaie). De aici numele de path vector protocol.
Figura 8-1: AS Path

De exemplu, dac n Fig. 1 reeaua 10.12.14.0/24 se afl n AS100 i este anunat n BGP, un
ruter care vorbete BGP din AS400 va vedea reeaua cu un AS_PATH avnd valoarea 300 200 100.
171 | B G P
Existena AS-Path permite de asemenea evitarea foarte uoar a buclelor de rutare. Dac u n
ruter BGP primete un update care conine propriul su ASN n AS_PATH, va ignora update-ul
respectiv.
O alt deosebire fa de IGP-uri este reprezentat de modul n care BGP descoper vecinii. n
BGP nu exist un sistem de descoperire automat a vecinilor (prin pachete broadcast/multicast).
Vecinii sunt configurai manual pe fiecare ruter, prin specificarea adresei lor IP i a sistemului
autonom din care fac parte. Comunicaia cu vecinii este ntotdeauna unicast, iar protocolul folosit
pentru comunicaie este TCP, port 179.
Sesiunea TCP este stabilit la nceperea comunica
iei ntre doi vecini, moment n care se
transmit tabelele de rutare complete. Ulterior, vecinii BGP vor transmite doar update-uri
incrementale (doar lista cu modificrile aprute n tabelele de rutare). Folosirea TCP garanteaz
existena unei conexiuni sigure, i ca urmare nu este necesar trimiterea de update-uri complete
periodice.
De asemenea, folosirea TCP i IP unicast nseamn c vecinii BGP nu trebuie s fie ntotdeauna
direct conectai. O alt implicaie important a folosirii TCP i IP unicast n conexiunile dintre vecinii
BGP este faptul c realizarea unei conexiuni TCP este posibil
i pentru vecinii ce nu sunt direct
conectai, ci sunt situai la mai multe hopuri distan, dar cunosc rutele necesarei pot comunica
prin intermediul altor rutere (aceast abordare prezint unele particularit
i, care vor fi discutate
ulterior).
Dac n cazul IGP-urilor decizia de selecie a unei anumite ci se face pe baza unei metrici (hopcount, bandwidth, cost, composite metric, etc), n cazul BGP nu exist o singur metric. Fiecare
update de rutare conine o serie de atribute, iar pe baza acestora (i a politicii de rutare existente n
AS-ul respectiv) BGP decide care este cea mai bun cale spre diferitele destinaii. O list a celor mai
frecvente atribute, precumi procesul efectiv de decizie, vor fi prezentate mai trziu n cadrul
acestui capitol.
8.1.4 iBGP vs eBGP.

n funcie de sistemul autonom n care se afl ruterele, conexiunile BGP se mpart n dou
categorii:
eBGP (external BGP) - conexiuni BGP realizate ntre dou rutere aflate n AS-uri diferite;
iBGP (internal BGP) - conexiuni BGP realizate ntre dou rutere aflate n acelai AS.
Trebuie menionat c iBGP nu este un IGP, i nu poate fi folosit n locul unui IGP pentru rutarea
n interiorul unui AS. iBGP are doar scopul de a transporta informaiile BGP ntre ruterele de grani
ale unui sistem autonom (numrul mare de rute cunoscute de ctre BGP face imposibil
transmiterea lor printr-un IGP).
Fiecare din cele dou variante de BGP are propriile mecanisme de evitare a buclelor de rutare:
eBGP - un update care conine AS-ul propriu n AS-PATH este ignorat;
iBGP - un update primit de la un vecin iBGP nu va fi trimis mai departe ctre un alt vecin
iBGP.
Ca o consecin a celui de -al doilea mecanism, este necesar ca ntr-un AS n care mai multe
rutere ruleaz BGP conexiunile iBGP s fie full-mesh (fiecare ruter care vorbete BGP trebuie s
stabileasc o adiacen cu fiecare alt ruter BGP din acelai AS). Drept urmare, numrul de conexiuni
iBGP va crete exponenial odat cu creterea numrului de rutere BGP din AS. Pentru 50 de rutere
BGP aflate n acelai AS, vor exista 50*49/2 = 1225 conexiuni iBGP. Exist soluii pentru scderea
numrului de conexiuni necesare (route-reflectors sau confederations), dar acestea necesit
configurri adiionale.
8.1.5 Next-hop
O alt particularitate a BGP este reprezentat de faptul c atunci cnd o rut primit prin eBGP
este trimis mai departe prin iBGP, next-hop-ul rutei rmne nemodificat. Acest lucru poate crea
probleme atunci cnd reelele folosite pentru conectarea la provider nu sunt anunate n IGP.
De exemplu, n figura 2, reeaua clientului este conectat la ISP prin reeaua 172.27.11.0/30.
Orice rut primit de client de la ISP va fi primit de R3 cu next-hop 172.27.11.1. n momentul n
care ruta este trimis de R3 ctre R1 prin iBGP, R3 nu se anun
pe sine ca next -hop, ci pstreaz
next-hop-ul original. Ca urmare, R1 va primi rutele cu next-hop 172.27.11.1.
innd cont c IGP-ul folosit n reeaua clientului (OSPF, de exemplu) nu va rula i pe legtura
dintre client i ISP, reeaua 172.27.11.0/30 nu va aprea n tabelele de rutare de pe ruterele R1 i
R2. Din acest motiv, R1 nu va ti cui trebuie s trim it pachetele destinate reelelor externe (tie c
trebuie s le trimit ctre 172.27.11.1, dar nu
tie cum s ajung la 172.27.11.1). Pentru a evita
aceast problem, ruterele nu instaleaz o rut primit prin BGP n tabela de rutare dect dac
next-hop-ul rutei este valid i au o rut ctre el.
Pentru rezolvarea acestei probleme exist dou variante:
anunarea reelelor de interconectare n IGP;
configurarea ruterelor de edge s schimbe next-hop-ul la anunarea rutelor n iBGP
(folosind comanda neighbor cu parametrul next-hop-self, descris n capitolul de
configurare).
Figura 8-2: eBGP i iBGP

Figura 2 prezint de asemenea o alt problem, specific AS-urilor de tranzit. Un AS de tranzit
(transit AS) este conectat la 2 sau mai multe alte AS-uri, i transport traficul dintre acestea. De
obicei, AS-urile furnizorilor de Internet (ISPs) sunt AS-uri de tranzit.
ntr-un AS de tranzit, iBGP are scopul de a comunica informaii ntre ruterele de grani, pentru
ca aceste informaii s fie transmise mai departe ctre AS-urile vecine. Dar faptul c vecinii de iBGP
nu sunt ntotdeauna direct conectai poate crea o situaie particular.
173 | B G P
De exemplu, s presupunem c n AS 65100 se afl re
eaua 10.0.0.0/8. Prefixul respe ctiv este
anunat n BGP i trimis mai departe ctre R3, R1 i R4. Toate acestea vor instala prefixul n tabela
de rutare (inclusiv R1, care l va instala cu adresa R3 ca next-hop).
n momentul n care din AS 65300 se trimite un pachet ctre un IP din 10.0.0.0/8, pachetul va
ajunge la R1. R1 verific tabela de rutare, i gsete adresa R3 (192.168.3.3) ca next-hop. Dar adresa
respectiv nu este direct conectat, motiv pentru care R1 va face o nou parcurgere a tabelei de
rutare - de data aceasta cutnd next-hop-ul ctre 192.168.3.3. Este gsit adresa R2 (192.168.4.2),
care este direct conectat. R1 ncapsuleaz pachetul, i l trimite ctre R2.
Pachetul ajunge la R2, iar acesta va cuta n tabela sa de rutare o rut ctre destina
ie. Dar R2
nu ruleaz dect IGP-ul din AS 65200 (OSPF, n exemplul nostru), nui BGP. Ca urmare, R2 nu are
nici o rut spre destinaie, i va face discard la pachet. Astfel, dei toate tabelele de rutare BGP par
corecte, R2 acioneaz efectiv ca o gaur neagr (black hole) n care dispare traficul de tranzit.
Teoretic, o soluie pentru aceast problem ar fi reprezentat de redistribuia rutelor din BGP
n IGP. Dup cum am men
ionat ns mai devreme, aceasta nu este o soluie scalabil (numrul
foarte mare de rute transportate de BGP nu poate fi suportat de nici unul din IGP-urile actuale). Ca
urmare, este necesar rularea iBGP pe toate ruterele din AS,i ca urmare realizarea unui full-mesh
iBGP ntre toate ruterele din AS, cu toate problemele discutate mai devreme. De menionat este c
n implementrile reale a AS-urilor de tranzit se folosete MPLS pentru a evita rularea BGP pe toate
ruterele ISP-ului.
8.1.6 Tabele BGP

n deciziile de rutare pe care protocolul BGP le ia sunt folosite trei tabele importante: de
adiacen, de rutare i tabela BGP (tabela de topologie).
Pentru ca BGP s realizeze o adiacen trebuie configurat explicit pentru fiecare vecin cu care
se dorete acest lucru. Adiacenele BGP se creeaz folosind portul 179 TCP i se menin folosind
mesaje TCP keepalive o dat la 60 de secunde. Dup stabilirea adiacenei, ruterele BGP fac schimb
de informaii de rutare din tabela de rutare. Toate rutele primite de BGP sunt pstrate n tabela BGP
ns doar cea mai bun rut este promovat n tabela de rutare.
Ruta cea mai bun este aleas dup un proces de decizie de 11 pai, descris n cele ce urmeaz.
Rutele eBGP au o distan administrativ de 20 n timp ce rutele iBGP au 200.
8.2 Implementarea politicilor BGP

Dup cum s-a menionat i n capitolul anterior, BGP este un protocol folosit strict pentru
implementarea unor politici de rutare pentru o organizaie. Fa de orice alt protocol de rutare ce
este interesat de gsirea celui mai scurt drum ctre destina
ie, BGP poate controla direcionarea
traficului ctre anumite destinaii i chiar ctre AS-ul propriu.
Pentru a putea configura politici BGP se folosesc route-map-uri care, n funcie de anumite
reele destinaie, modific atribute BGP ce pot influena rute.
8.2.1 Atribute BGP

Spre deosebire de IGP-uri, BGP nu folosete o singur m etric pentru a decide cea mai bun
cale spre o anumit destinaie. n schimb, BGP se bazeaz pe aa numitele atribute. Fiecare update
BGP conine, pe lng prefixul destinaie, i o serie de atribute care caracterizeaz acel prefix.
Atributele sunt mprite n urmtoarele categorii:
Well-known mandatory
Well-known discretionary
Optional transitive
Optional non-transitive
Un atribut well-known trebuie s fie recunoscut de orice implementare BGP care respect
standardele, n timp ce un atribut optional poate s nu fie recunoscut de unele implementri (un
atribut optional care nu este recunoscut va fi pur i simplu ignorat).
Atributele well-known pot fi mandatory (trebuie s fie incluse ntotdeauna, n orice update
BGP), sau discretionary (pot lipsi din unele update-uri).
Dac un atribut opional este transitive, un ruter BGP care nu l recunoate va trimite atributul
mai departe, nemodificat, ctre vecinii si BGP. Un atribut optional non-transitive, n schimb, nu va
fi trimis mai departe de ctre un ruter care nu l recunoate.
Atributele opionale care sunt recunoscute de ctre un ruter BGP pot fi trimise sau nu mai
departe ctre vecinii si, n funcie de semnificaia atributului.
Atributele BGP specificate n RFC1771 sunt urmtoarele:
ORIGIN - Well-known mandatory
AS_PATH - Well-known mandatory
NEXT_HOP - Well-known mandatory
LOCAL_PREF - Well-known discretionary
ATOMIC_AGGREGATE - Well-known discretionary
AGGREGATOR - Optional transitive
COMMUNITY - Optional transitive
MULTI_EXIT_DISC(MED) - Optional nontransitive
ORIGINATOR_ID - Optional nontransitive
CLUSTER_LIST - Optional nontransitive
8.2.1.1 ORIGIN
Atributul ORIGIN este un atribut well-known mandatory care specific originea update-ului de
rutare. Variantele posibile pentru acest atribut sunt:
IGP (notat i) - prefixul a fost nvat printr-un IGP (RIP, OSPF, EIGRP, etc), i injectat
ulterior n BGP prin comanda network;
EGP (notat e) - prefixul a fost nvat prin EGP. Cum EGP nu mai este folosit astzi, nu se
mai ntlnesc prefixe cu ORIGIN e;
Unknown (notat ?) - sunt prefixe nvate din alte surse. Rutele care sunt redistribuite n
BGP (prin comanda redistribute) sunt marcate cu ORIGIN ?.
Dac un ruter BGP prime
te mai multe rute ctre aceeai destinaie, cu ORIGIN diferit, va
prefera rutele n ordinea de mai sus (sunt preferate rutele i, apoi e,
i ultimele sunt ?).
Notaie: i > e > ?
8.2.1.2 AS_PATH
Atributul AS_PATH este un atribut well-known mandatory care conine lista de ASN-uri care vor
trebui traversate pentru a ajunge la destinaia specific at n update. Fiecare ruter BGP care trimite
ruta ctre un vecin eBGP va aduga n list propriul su ASN. Adugarea se face la nceputul listei
(prepending), astfel nct ntotdeauna lista din AS_PATH va ncepe cu cel mai apropiat AS,
i se va
ncheia cu AS-ul n care a originat update-ul.
Relund exemplul din Fig.1, n care o rut din AS100 este anunat prin BGP:
n momentul n care ruta este anunat n BGP din AS100, ruterul care o anun i adaug
propriul ASN n AS_PATH;
175 | B G P
Pentru fiecare ruter care anun ruta ctre un vecin eBGP, ASN-ul ruterului va fi adugat la
nceputul listei. Astfel, un ruter BGP din AS 300 va vedea ruta cu AS_PATH=200 100, iar n AS
400 AS_PATH va fi 300 200 100.
Ca o metod de evitare a buclelor n rutarea inter-AS, un ruter nu va accepta un update eBGP
care conine propriul ASN n AS_PATH. Acesta este unul din atributele importante care se pot
manipula din configuraii.
8.2.1.3 NEXT_HOP
Atributul NEXT_HOP (well-known, mandatory) conine adresa IP a urmtorului ruter pe calea
ctre destinaie. Trebuie menionat c adresa IP din NEXT_HOP nu aparine ntotdeauna unui ruter
vecin:
Dac ruterul care anun prefixul i ruterul care l primete sunt n AS-uri diferite (eBGP),
NEXT_HOP va fi setat la adresa IP a ruterului care anun prefixul;
Dac ruterul care anun prefixul i ruterul care l primete sunt n acelai AS (iBGP), i
prefixul aparine acelui AS, NEXT_HOP este adresa ruterului care a anunat ruta;
Dac ruterul care anun prefixul i ruterul care l primete sunt n acelai AS (iBGP), i
prefixul aparine unui alt AS, NEXT_HOP va fi adresa ruterului extern care a anunat ruta. Un
alt mod de a formula aceast regul este urmtorul: La trecerea din eBGP n iBGP,
NEXT_HOP nu se modific.
8.2.1.4 LOCAL_PREF
Atributul LOCAL_PREF (Local Preference) este un atribut well-known discretionary folosit doar
n update-uri iBGP (nu se trimite ctre alte AS-uri). Acest atribut este folosit pentru a comunica
preferina pentru o anumit rut. Dac un ruter BGP primete mai multe rute ctre aceeai
destinaie cu LOCAL_PREF diferite, va prefera ruta cu LOCAL_PREF mai mare. Acesta este unul din
atributele importante care se pot manipula din configuraii.
8.2.1.5 MULTI_EXIT_DISC (MED)

LOCAL_PREF nu afecteaz dect traficul care prsete un AS. MULTI_EXIT_DISC (pe scurt MED)
este un atribut optional non-transitive care permite unui AS s influeneze traficul su de intrare.
MED conine o valoare pe 16 bii, cunoscut i ca INTER_AS Metric (n terminologia BGPv2 i
BGPv3). Un ruter care primete mai multe rute care difer prin MED va prefera ruta cu MED mai mic
(spre deosebire de LOCAL_PREF, unde o valoare mai mare este preferat). Aceasta deoarece MED
este considerat o metric, i ca la orice metric, valorile mai mici sunt considerate mai bune.
Folosirea MED pentru manipularea traficului de intrare n AS are o serie de limitri, principala
fiind dat de faptul c MED nu se transmite mai departe de AS-ul vecin. Ca urmare, MED nu poate fi
utilizat n cazul unui AS legat la 2 sau mai multe AS-uri diferite (de exemplu o reea de enterprise
legat la 2 ISP), deoarece nici unul dintre AS-urile vecine nu va ti care este valoare MED primit de
celelalte AS-uri. Din acest motiv, n general se prefer alte metode pentru influenarea traficului de
intrare, bazate pe manipularea AS_PATH.
8.2.1.6 COMMUNITY
Atributul COMMUNITY este un atribut optional transitive utilizat pentru a simplifica aplicarea
de politici de rutare. Iniial un atribut specific Cisco, a fost standardizat n RFC1997. Atributul
identific un prefix ca fcnd parte dintr-o anumit comunitate - un set de prefixe caracterizate
prin proprieti comune. De exemplu, un ISP poate seta un anumit COMMUNITY pentru toate rutele
clienilor si, urmnd ca ulterior s aplice valori particulare pentru LOCAL_PREF i MED pe baza
acestui atribut.
Atributul are ca valoare un set de 4 octe
i. Conform RFC 1997, acesta este de forma AA:NN primii 2 octei identific AS-ul, iar ultimii 2 sunt identificatorul comunitii.
Exist cteva valori predefinite pentru COMMUNITY, cu semnifica ie particular:
NO_EXPORT - rutele marcate cu aceast comunitate nu sunt anunate ctre vecini eBGP (nu
prsesc AS-ul), cu excepia vecinilor care fac parte din aceeai confederaie;
NO_ADVERTISE - rutele marcate astfel nu sunt anunate ctre nici un fel de vecini BGP (fie
ei iBGP sau eBGP);
LOCAL_AS - rutele marcate astfel nu sunt anunate ctre nici un fel de vecini eBGP (nici
ctre vecini din aceeai confederaie).
8.2.1.7 ORIGINATOR_ID, CLUSTER_LIST

ORIGINATOR_ID i CLUSTER_LIST sunt atribute optional non-transitive folosite de ctre routereflectors pentru prevenirea buclelor de rutare. Route-reflector-ii reprezint rutere BGP cu o
configuraie special, folosite pentru a scdea numrul de adiacene iBGP necesare ntr-un sistem
autonom.
8.2.1.8 WEIGHT
Dei nu este un atribut BGP propriu-zis, WEIGHT (sau Administrative weight) reprezint un alt
factor care influeneaz decizia BGP. Parametrul WEIGHT este specific Cisco, i se aplic doar pe
ruterul pe care este configurat (nu este comunicat ctre alte rutere). Valoarea sa este un numr pe
16 bii (ntre 0 i 65.535), valorile mai mari fiind preferate. Implicit, rutele generate local au WEIGHT
32.768, iar cele primite de la un vecin au WEIGHT 0. Acesta este unul din atributele importante care
se pot manipula din configuraii.
8.2.2 Procesul de decizie BGP

Dup cum s-a menionat mai devreme, fiecare prefix primit prin BGP va fi nsoit de o serie de
atribute. n momentul n care un ruter BGP prime
te mai multe update-uri referitoare la aceeai
destinaie, va trebui s aleag cea mai bun cale spre destinaia respectiv. Pentru aceasta, ruterul
compar atributele n ordinea urmtoare:
1. WEIGHT. Valorile mai mari sunt preferate;
2. LOCAL_PREF. Valorile mai mari sunt preferate;
3. Locally originated - se prefer rutele originate local;
4. AS_PATH - se prefer un AS_PATH mai scurt;
5. ORIGIN. Ordinea preferinei este: i>e>?;
6. MED. Se prefer valoarea cea mai mic. Aceast comparaie se va face doar dac rutele
comparate provin din acelai AS;
7. Se prefer rutele primite prin eBGP fa de cele primite prin iBGP;
8. IGP to NEXT_HOP. Se prefer ruta cu metrica IGP cea mai mic pn la NEXT_HOP;
9. Dac toi parametrii de mai sus sunt egali i BGP este configurat s instaleze mai multe rute
n tabela de rutare (prin comanda bgp maximum-paths), toate rutele se vor instala n
tabel. Dac BGP nu este configurat pentru multipathing, se merge mai departe;
10. Oldest external route. Dac ambele rute sunt externe, se prefer ruta cea mai veche. Acest
pas are scopul de a minimiza route-flapping-ul (modificrile repetate ale rutei ctre aceeai
destinaie);
11. Ruter ID. Se alege ruta venit de la ruterul cu BGP RouterID cel mai mic.
177 | B G P
Paii sunt parcuri n ordinea menionat, pn cnd se alege o singur rut ca fiind cea mai
bun. Un atribut nu va fi comparat dect dac toate atributele listate naintea lui au valori egale (de
exemplu, dou rute nu vor fi comparate pe baza AS_PATH dect daca au WEIGHT
i LOCAL_PREF
egale, i nici una nu a fost originat local).
Trebuie menionat c odat parcurs procesul de decizie, un ruter BGP va anuna ctre vecini
doar cea mai bun cale (nu toate cile posibile).
8.2.3 Scalarea BGP

Problema din cauza creia se creeaz guri negre de rutare se datoreaz faptului c nu exist
un full-mesh iBGP n AS. Motivul pentru care exist aceast problem este regula de prevenire a
buclelor n iBGP. Conform acestei reguli, un ruter ce ruleaz iBGP nu are voie s transmit unui
vecin iBGP o rut primit prin iBGP.
Aceast regul poate fi depit printr-o metod de scalare ce presupune folosirea unor rutere
speciale n implementarea BGP numite route-reflectors. Aceste rutere au posibilitatea de a defini
anumii clieni BGP pentru care s realizeze o excepie de la regula de prevenire a buclelor iBGP.
Ruterele dintr-un AS se vor mpri astfel n 3 categorii
Ruterele route-reflectors ruterele care reflect rute iBGP la clienii desemnai;
Ruterele clieni route-reflectors ruterele care primesc rute prin iBGP de la route-reflectors;
Ruterele normale iBGP rutere care trebuie s fie conectate n full-mesh pentru a nu
genera guri negre de rutare.
Folosirea acestei metode de scalare presupune ca grupul de clieni route-reflectors s aib doar
o relaie de adiacen cu ruterul route-reflector, deoarece acesta le va trimite toate rutele pe care le
obine fie prin eBGP sau iBGP. n acelai timp, ruterele ce nu sunt clieni route -reflectors vor trebui
s aib relaii iBGP full-mesh att ntre ei ct i cu ruterul route-reflector pentru a preveni posibilele
guri negre.
Aceast metod de scalare BGP a avut parte de o implementare extrem de elegant n
protocol. Deoarece n toat strategia de mai sus, doar route-reflector-ul este cel ce ncalc regula
iBGP pentru bucle, toat configuraia se realizeaz pe acesta. Configuraia const n definirea unei
liste de clieni pentru care route-reflector-ul s fac excepia mai sus menionat.
R2
AS 100
R1
E2/1
E2/2
R3
E2/2
E2/1
R4
Figura 8-3: Route Reflectors

n topologia de mai sus se consider urmtoarele adiacene iBGP: R1 R2, R1 R4, R2 R3, R3R4. Ruterele R1i R3 sunt ruterele care comunic cu alte AS -uri n afara AS 100. Aparent exist
adiacene care s uneasc toate ruterele din AS ns pentru c nu exist full-mesh unele rutere nu
vor afla toate informaiile din AS.
Cnd un update eBGP va veni la ruterul R1 acesta l va trimite la ruterele cu care are sesiuni
iBGP. Astfel R2 i R4 vor primi update-ul prin iBGP ns nu vor putea s l dea mai departe lui R3
deoarece ar nclca regula de evitare a buclelor.
Configurnd pe R2 ca route-reflector i pe R3 ca i client route-reflector, R2 va putea trimite
toate rutele primite de la un non-client (R1) la toi clienii si (R3).
n ncheierea acestui subcapitol se va atrage ia
atenasupra unei greeli des ntlnite n
configuraiile de route-reflectors. Cnd se folosete aceast metod toate ruterele care sunt non clieni trebuie s fie conectai n full-mesh. Deoarece un route-reflector trimite toate rutele de la un
non-client doar la clienii si, neatenia n configurare poate s duca la rutere non-clieni ce nu
cunosc ntreag informaie de rutare BGP.

Dei BGP este unul dintre cele mai complexe protocoale din lumea reelelor de calculatoare, el
este relativ uor de configurat din punct de vedere al sintaxei. Motivul principal este faptul c Cisco
a grupat n IOS cea mai mare parte dintre toate configura
iile BGP ntr
-o singur comand:
neighbor.
Pentru a porni procesul BGP pe un ruter trebuie dat aceeai comand ca i n cazul oricrui alt
protocol de rutare: router. n cazul BGP aceast comand primete ca i parametru att cuvntul
cheie bgp ct i un numr de AS. Cel din urm argument are rolul de a i indica procesului de BGP n
ce AS se afl. Ca exemplu, n output-ul de mai jos, procesul BGP este pornit pentru AS-ul 100:
R1(config)#router bgp 100
R1(config-router)#
Realizarea unei configuraii BGP poate fi n general mprit n dou categorii: realizarea
adiacenei ntre vecini i politici BGP. Configuraiile avansate BGP introduc multe alte cerine de
scalabilitate sau configurare cu alte protocoale (MPLS, IPv6 etc.), ns aceast introducere va trata
doar configurarea adiacenelor i a politicilor de baz.
8.3.1 Configurarea adiacenelor BGP

Adiacenele BGP pot fi de 2 tipuri: iBGP sau eBGP. Se va ncepe cu iBGP. Presupunnd o reea
precum cea din figura de mai jos, cerina este de a realiza o sesiune iBGP ntre ruterul R1 i R2. De
asemenea se va presupune c ntre cele 4 rutere exist deja conectivitate prin IGP-ul OSPF.
Cea mai rapid metod de a realiza sesiunea iBGP ntre cele 2 rutere dorite este alegerea unuia
dintre IP-urile de pe o interfa i folosirea acestuia n comanda neighbor.
R1(config-router)#neighbor 11.0.0.1 remote-as 100
Dup cum se observ, ambele comenzi au folosit pe lng IP-ul vecinului BGP i cuvntul cheie
remote-as urmat de un numr de AS. Acest numr de AS mpreun cu numrul de AS dat ca
parametrul comenzii router i spune protocolului dac sesiunea ce se dore
te stabilit este iBGP
sau eBGP. Dac numerele de AS sunt identice n cele 2 comenzi, protocolul BGP va nelege c
ruterele vecine se afl n acelai AS i va porni o sesiune iBGP. n caz contrar o adiacen eBGP va fi
creat.
179 | B G P
R2
OSPF
10.0.0.1
Lo0
R1
11.0.1.1
E2/2
R3
Lo0
E2/2
E2/1
10.0.1.1
E2/1
iBGP
R4
11.0.0.1
Figura 8-4: Adiacene iBGP
Not: pentru a se stabili o sesiune de adiacen BGP trebuie s existe conectivitate ntre
ruterul pe care se d comanda neighbor i adresa IP a vecinului. n cazul de mai sus
aceast adiacen este asigurat de protocolul OSPF.
Odat cu executarea comenzilor de mai sus sesiunea iBGP va fi creat cu succes. O posibil
problem poate aprea ns, dac una dintre interfe
ele celor dou rutere va ncepe s fac
1
flapping sau se va deconecta. Acest lucru se poate ntmpla din multiple motive, de la condiiile de
mediu sau o defeciune hardware, pn deconectarea accidental a unor cabluri. Oricare din aceste
aciuni va avea ca rezultat distrugerea adiacenei BGP. La oricare alt protocol de rutare acest lucru
ar fi uor remediat deoarece adiacena s-ar reconstrui repede iar cantitatea de rute trimis nu ar fi
att de mare. BGP poate ajunge la o tabel de rutare de peste 300 000 de rute, n care restabilirea
unei adiacene are costuri mari traduse n downtime.
Pentru a preveni astfel de situaii, o recomandare este folosirea interfeei de loopback de pe
fiecare ruter pentru a stabili adiacenele. Motivul este faptul c interfeele de loopback exist doar
n software i nu sunt supuse problemelor mediului fizic. Atenie ns, acest lucru va funciona doar
dac adresa IP a interfeei de loopback a vecinului BGP este cunoscut n tabela de rutare printr-un
protocol IGP sau printr-o rut static. n cazul de mai sus, daca administratorul dore
te realizarea
unei sesiuni BGP folosind interfe
ele de loopback, va trebui s introduc re
elele de loopback n
OSPF.
R1(config)#router ospf 1
R1(config-router)#redistribute connected route-map all_loopbacks subnets
R1(config-router)#exit
R1(config)#route-map all_loopbacks permit 10
R1(config-route-map)#match interface Loopback0
R1(config-route-map)#exit
R1(config-router)# neighbor 11.0.1.1 remote-as 100
R3(config-router)#redistribute connected route-map all_loopbacks subnets
R3(config)#route-map all_loopbacks permit 10
R3(config-route-map)#match interface Loopback0
1
Fenomenul n care o interfa oscileaz ntre strile up/down.
R3(config-router)# neighbor 10.0.1.1 remote-as 100
Sigurana adiacenei ce este dorit prin crearea sesiunii iBGP peste loopback-uri introduce ns
unele complicaii n configurare. Dup comenzile date mai sus se va observa c adiacena iBGP nu sa realizat. Dac s-ar da comanda debug ip bgp s-ar observa c IOS raporteaz o nepotrivire ntre
adresa surs a pachetelor BGP i adresa de neighbor cu care vecinul respectiv este cunoscut.
Aceast problema este normali apare din cauza faptului c fiecare vecin n mod implicit
folosete adresa IP de pe interfaa de ieire a pachetelor ca i adres IP surs n pachetele BGP.
Cnd pachetele ajung la ruterul vecin acesta le refuz deoarece se tepta
a
s vad IP -ul configurat
n comanda neighbor (IP-ul interfeei de loopback a vecinului) n cmpul de IP surs al pachetului.
Pentru a rezolva aceast problem i a obine adiacena iBGP trebuie dat comanda neighbor
cu argumentul update-source i interfaa a crei adres IP s fie folosit ca i adres surs n
pachete (n cazul de fa, Loopback0).
R1(config-router)#neighbor 11.0.1.1 update-source Lo0
R3(config-router)#neighbor 10.0.1.1 update-source Lo0
iBGP mai are doar un singur mic detaliu de configurat

i este gata pentru funcionare n
majoritatea topologiilor BGP. Dei sesiunea iBGP funcioneaz corect, la introducerea unor rute din
eBGP n iBGP va aprea o problem de conectivitate.
Se va presupune c ruterul R1 din figura de mai sus ruleaz i eBGP cu un ruter numit R_ext din
alt AS i c primete de la acesta rute BGP. Cnd eBGP transmite rute, schimb automat informaia
de next-hop pentru rutele respective. Acest lucru nseamn c atunci cnd R_extte
dore
s
transmit rute ctre R1, va schimba adresa next-hop-ului la adresa de pe interfaa sa de ieire ctre
R1. Prin aceast ac
iune R_ext i indic lui R1 faptul c reelele din rutele tran smise se gsesc
undeva dincolo de el. Comportamentul este ct se poate de normal pentru orice protocol de rutare.
iBGP nu schimb ns aceast informaie la transmiterea rutelor. Astfel, cnd R1 va trimite lui
R3 rutele nvate de la R_ext, next-hop-ul va rmne neschimbat la adresa IP a lui R_ext. Acest
lucru nseamn c R3 nu va putea s instaleze niciodat aceste rute n tabela de rutare deoarece nu
are conectivitate ctre next-hop. Prima reacie n scopul rezolvrii acestei probleme ar putea fi
configurarea unei rute statice pe R3 pentru reeaua dintre R1 i R_ext. Dei aceast rut static ar
rezolva problema, nu este o soluie scalabil i nici o practic indicat. Un ruter din interiorul unui
AS nu ar trebui s aib rute statice ctre reele din exteriorul AS-ului; pentru acest lucru exista BGP.
Soluia cea mai bun este configurare iBGP pentru a avea acelai comportament de schimbare
a next-hop-ului ca i eBGP. Acest lucru se realizeaz prin comanda neighbor cu parametrul nexthop-self.
R1(config-router)#neighbor 11.0.1.1 next-hop-self
8.3.2 Configurarea adiacenelor eBGP

n cazul eBGP configuraiile sunt asemntoare cu iBGP ns nu exist complicaii introduse de
informaia de next-hop deoarece eBGP schimb n mod implicit adresa next-hop la transmiterea
unei rute.
181 | B G P
AS 100
AS 200
10.0.0.1
Lo0
R1
E2/2
E2/1
10.0.1.1
11.0.1.1
eBGP
E2/1
R3
Lo0
E2/2
11.0.0.1
Figura 8-5: Configurarea adiacenei eBGP

Se vor folosi aceleai rutere ca protagoniti ai scenariului dar de data aceasta n AS-uri diferite.
Pentru ca numrul de AS dat n comanda router este diferit de cel folosit n comanda
iona n aceast form fr orice alt
neighbor, IOS va porni o sesiune de eBGP. Sesiunea va func
modificare.
Exist ns cazuri n care cele 2 rutere de mai sus sunt legate prin 2 cabluri pentru redundan
.
ntrebarea ce se pune n acest caz este: ce IP va fi folosit n fiecare capt pentru crearea adiacenei?
Dac se va folosi oricare dintre IP-urile de pe legturile fizice se va risca pierderea adiacenei ca i n
cazul iBGP din aceleai motive enumerate n subcapitolul anterior. Soluia va fi di n nou folosirea
unei interfee de loopback. Deoarece ntre AS-uri nu ruleaz nici un protocol IGP, fiecare ruter va
trebui s defineasc o rut static pentru reeaua n care se gsete loopback-ul vecinului.
R1(config)#ip route 11.0.1.0 255.255.255.0 11.0.0.1
R1(config-router)#neighbor 11.0.1.1 update-source Loopback 0
R3(config)#ip route 10.0.1.0 255.255.255.0 10.0.0.1

n acest moment, att rutele statice cti vecinii au fost configurai corect. eBGP nu va ridica
ns adiacena cu vecinul su. Problema const n modul n care eBGP a fost implementat n cod. n
mod implicit, programatorii BGP au presupus c o adiacen
eBGP va fi ntotdeauna fcut ntre
rutere direct conectate cci ntre AS-uri nu ruleaz niciun protocol IGP. Astfel toate pachetele de
stabilire de adiacen eBGP au un TTL implic it cu valoarea 1. Dac se folosesc interfe
ele de
Loopback pentru stabilirea adiacen
elor, TTL -ul va fi decrementat la rutarea spre loopback iar
pachetul va fi aruncat.
Pentru a rezolva aceast ultim problem de adiacen
se folosete comanda neighbor cu
parametrul ebgp-multihop urmat de valoarea TTL pe care pachetele de adiacen ar trebui s o
aib.
R1(config-router)#neighbor 11.0.1.1 ebgp-multihop 2
R3(config-router)#neighbor 10.0.1.1 ebgp-multihop 2
8.3.3 Configurarea politicilor BGP

Manipulnd atributele, o organizaie poate controla fluxul de date care intr i care iese din
propriul AS. Exist multe moduri prin care aceste politici se pot realiza, cele mai populare fiind:
modificarea local preference, AS-PATH prepend, modificarea MED, modificarea weight. n capitolul
de studiu de caz se vor prezenta aceste politici aplicate pe o topologie ntlnit n implementri
reale.
Indiferent de tipul de atribut ce se dore
te modificat, BGP are nevoie de folosirea unui routemap pentru realizarea acestui lucru.
R1(config-router)#neighbor 11.0.1.1 route-map policy_google in
Se poate observa c n comanda de mai sus pentru vecinul 11.0.1.1 se aplic o politic de tip
out. Acest parametru i indic protocolului BGP faptul c route-map-ul numit policy_out va influena
atributele rutelor ce intr n AS-ul propriu.
Se va presupune o topologie n care ruterul R1 este conectat la dou IPS-uri diferite i dorete
s aleag mereu ISP-ul identificat prin vecinul BGP 11.0.1.1 pentru traficul spre google.ro.
n acest caz, interesant este atributul weight. Acesta poate fi folosit pentru a lua o decizie local
pe un ruter privind direc
ia n care traficul s se ndrepte n afara AS -ului. Valoarea implicita a
atributului pentru orice rut primit este 32768. Setarea unei valori mai mari va face ruta mai
atractiv i n acelai timp preferat n primul pas din procesul de decizie BGP. Configuraiile pentru
ndeplinirea scopului descris mai sus pentru traficul ce se ndreapt spre google.ro sunt:
R1(config)#route-map policy_google permit 10
R1(config-route-map)#match ip address google_ips
R1(config-route-map)#set weight 40000
R1(config-router)#neighbor 11.0.1.1 route-map policy_google in
R1(config-router)#^Z
R1(config)#ip access-list standard google_ips
R1(config-std-nacl)#permit 209.85.229.104 0.0.127.255
Se creeaz mai nti un route-map n care se face potrivirea pe IP-urile folosite de google.ro
printr-o list de acces standard.
Route-map-ul seteaz valoarea weight la 40000 pentru a face aceast rut prioritar altora
i
apoi acesta este ataat vecinului 11.0.1.1. Astfel toate rutele spre google venite de la acel ISP vor fi
preferate i alese ca i ieire din AS-ul propriu.
Dac se dorete ca i traficul de ntoarcere de la google s vin pe aceeai legtur trebuie
manipulat AS-Path-ul, ns mai multe despre aceast operaie vor fi descrise n capitolul urmtor.
183 | B G P
8.3.4 Interpretarea tabelelor de topologie BGP

Cea mai important comand din BGP este show ip bgp. Cu ajutorul acesteia se poate
vizualiza tabela BGP de topologie n care sunt prezente next-hop-ul pentru fiecare rut alturi de
cteva din cele mai importante atribute BGP.
R2#show ip bgp
BGP table version is 3, local router ID is 150.0.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*>i151.0.1.0/24
*>i152.0.8.0/22
Next Hop
150.0.1.1
150.0.1.1
Metric LocPrf Weight Path

0
100
0 i
0
100
0 i
Ruta cea mai bun este indicat prin folosirea semnului >. Toate rutele de mai sus au o
metric de 0i un local-preference de 100. Semnificaia i -ului din stnga este c ruta a fost
nvat prin iBGP. Dac reeaua ar fi venit de la o rut eBGP acel spaiu dintre > i IP-ul reelei ar
fi fost lsat gol. n partea din dreapt este listat AS-PATH-ul rutei n form: AS X AS Y AS Z i/?.
Numrul de AS cel mai din dreapta este cel ce a originat ruta. n output-ul de mai sus nu apare
niciun AS n list ceea ce nseamn c ruta este intern. Ultimul simbol din list poate fi i sau ?,
n funcie de modul n care a fost introdus aceast rut n BGP: prin comanda network (i) sau
prin comanda redistribute (?).
8.4 Studiu de caz

Pentru exemplificare vom prezenta o configura
ie BGP n topologia din figura 3. n acest
scenariu, compania noastr (Sky's The Limit) folosete dou conexiuni la Internet (multi-homed AS)
pentru asigurarea redundanei. Ca urmare, compania a decis implementarea BGP pentru a asigura
rutarea corect.
Figura 8-6: : Topologie studiu de caz
Iniial, ambele conexiuni au fost oferite de ctre acela
i ISP (ISP2), dar acest lucru a dus la
apariia unui single point of failure n reeaua companiei - este vorba de R4, a crui defectare ar
putea compromite complet legtura la Internet. Ca urmare, compania a decis achiziionarea unei a
treia legturi, oferit de un alt ISP (ISP1). Aceast a treia legtur este pltit n funcie de traficul
utilizat i va fi folosit doar atunci cnd se pierde complet conectivitatea cu ISP2.
8.4.1 Configuraii de baz

n reeaua companiei ruleaz deja un IGP (OSPF), care anun reelele interne (cele aparinnd
192.168.0.0/16).
Primul pas n configurarea BGP este pornirea procesului de rutare (cu specificarea AS-ului din
care face parte ruterul), i config urarea vecinilor. Pentru fiecare vecin se specific o adres IPi AS ul din care acesta face parte.
De cele mai multe ori, adiacen
ele eBGP se stabilesc ntre vecini direct conectai, folosind
adresele IP de pe interfeele direct conectate. Dac IP folosit pentru stabilirea unei adiacene eBGP
nu este direct conectat, este obligatorie folosirea comenzii neighbor cu parametrul ebgp-multihop.
SP1(config-if)#router bgp 65200

SP1(config-router)#neighbor 172.16.1.2 remote-as 65100
*Mar 1 00:09:40.075: %BGP-5-ADJCHANGE: neighbor 172.16.1.2 Up
SP2(config)#router bgp 65300



Adiacenele iBGP pot fi stabilite ntre adresele direct conectate (cazul SP2-SP3), sau ntre
adresele altor interfe
e, n mod frecvent fiind folosite n acest scop adresele interfeelor de
loopback.
Deoarece adresa destinaie configurat pe unul dintre rutere trebuie s fie aceeai cu adresa IP
surs folosit de vecinul su, n cazul adiacenelor formate folosind interfeele de loopback devine
obligatorie configurarea manual a adresei IP folosite n update-uri, prin comanda neighbor cu
parametrul update-source.
n exemplul nostru, ruterele R1
i R4 au configurate interfe
ele Loopback 0 cu adresele IP
192.168.100.1/32, respectiv 192.168.100.4/32.
185 | B G P
SP2(config-router)#router bgp 65300
Pentru a verifica starea adiacenelor, se poate folosi comanda show ip bgp neighbors, sau
show ip bgp summary.
R4#show ip bgp neighbors
BGP neighbor is 172.16.2.1, remote AS 65300, external link
BGP version 4, remote router ID 172.16.11.2
BGP state = Established, up for 00:13:38
Last read 00:00:37, last write 00:00:37, hold time is 180, keepalive
interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent
Rcvd
Opens:
1
1
Notifications:
0
0
Updates:
0
0
Keepalives:
15
16
Route Refresh:
0
0
Total:
16
17
Default minimum time between advertisement runs is 30 seconds
R4#show ip bgp summary

BGP router identifier 192.168.2.2, local AS number 65100
BGP table version is 1, main routing table version 1
Neighbor
State/PfxRcd
172.16.2.1
172.16.2.5
192.168.100.1
AS MsgRcvd MsgSent
4 65300
4 65300
4 65100
19
17
8
18
17
8
TblVer
1
1
1
InQ OutQ Up/Down

0
0
0
0 00:15:21
0 00:13:50
0 00:04:07
0
0
0
n cazul comenzii show ip bgp summary, un vecin pentru care conexiunea BGP a fost
stabilit cu succes va avea n ultima coloan un numr reprezentnd numrul prefixelor primite de
la vecinul respectiv. Dac n coloana respectiv apare un text (Active / Init / etc), conexiunea nu a
fost (nc) stabilit pentru vecinul respectiv.
Urmtorul pas n configurarea BGP o reprezint selectarea rutelor care vor fi anun
ate. Spre
deosebire de IGP-uri, n BGP prefixele anunate sunt selectate manual, prin comanda network. O
alt variant este cea a redistribuirii rutelor din alt protocol n IGP, prin comanda redistribute.
Diferena dintre cele dou abordri este dat de atributul ORIGIN - rutele injectate prin comanda
network vor avea ORIGIN internal (i), n timp ce rutele redistribuite vor avea ORIGIN unknown (?).
Pentru ca o rut s fie injectat cu succes n BGP, este obligatoriu ca prefixul respectiv s existe
n tabela de rutare a ruterului pe care s-a configurat comanda network. Dac prefixul (adresa de
reea sau masca) nu corespund cu o rut existent, reeaua nu va fi anunat.
n exemplul nostru, ruterul R1 va anuna adresele de loopback din interiorul AS 65100 (adresele
interfeelor de pe Loopback0 de pe R1 i R4). Ambele adrese exist deja n tabela de rutare a lui R1 adresa proprie este direct conectat, n timp ce adresa R4 este primit prin OSPF. Ca urmare, este
posibil anunarea respectivelor prefixe n BGP.
n plus, SP1 va anuna prefixul 172.16.11.0/30 (direct conectat), iar SP2 va anuna 10.0.1.0/30
(tot direct conectat).
R1(config-router)#network 192.168.100.1 mask 255.255.255.255
R1(config-router)#network 192.168.100.4 mask 255.255.255.255
SP1(config-router)#network 172.16.11.0 mask 255.255.255.252
SP2(config-router)#network 10.0.1.0 mask 255.255.255.252
Pentru a verifica faptul c rutele sunt transmise corect, vom studia tabela BGP de pe rutere,
folosind comanda show ip bgp. Toate cele patru rute injectate vor trebui s apar pe toate
ruterele care vorbesc BGP.
Pentru a obine mai multe detalii despre o rut, se poate folosi varianta show ip bgp X.X.X.X
(unde X.X.X.X este adresa de reea despre care se doresc mai multe detalii).
R4#show ip bgp
Network
* i10.0.1.0/30
*
*>
* i172.16.11.0/30
*>
r>i192.168.100.1/32
r>i192.168.100.4/32
Next Hop
172.16.1.1
172.16.2.1
172.16.2.5
172.16.1.1
172.16.2.1
192.168.100.1
192.168.1.2

0
100
0 65200 65300 i
0
0 65300 i
0 65300 i
0
100
0 65200 i
0 65300 65200 i
0
100
0 i
193
100
0 i
Comanda show ip bgp este una din cele mai utile comenzi pentru troubleshooting atunci
cnd se folosete BGP. Ea permite vizualizarea tuturor prefixelor cunoscute prin BGP, mpreun cu:
starea acestora (primul simbol de pe fiecare linie);
cea mai bun cale ctre o destinaie, n cazul n care sunt cunoscute mai multe ci spre
aceeai reea. Cea mai bun cale este marcat cu >, i va fi cea care va intra n tabela de
rutare (paii urmai pentru alegerea celei mai bune ci au fost descrii ntr-o seciune
anterioar);
o list cu cele mai importante atribute: NEXT_HOP, WEIGHT, LOCAL_PREF, AS_PATH
(Path), ORIGIN (simbolul de la finalul Path), MED (Metric).
n exemplul de mai sus, dou prefixe (cele aparinnd 192.168.0.0/16) sunt marcate ca r (RIBFailure). Aceasta nu este o eroare - pur i simplu acestea sunt cunoscute deja de ctre ruter printrun alt protocol (192.168.100.4 este direct conectat, iar 192.168.100.1 este primit prin OSPF),
i ca
urmare nu vor mai fi adugate n tabela de rutare (RIB-Routing Information Base) de ctre iBGP
(care are o distan administrativ mai mare dect celelalte protocoale).
Pentru a verifica introducerea celor mai bune ci n tabela de rutare, folosim comanda show
ip route (cu varianta show ip route bgp, pentru a arta doar rutele cunoscute prin BGP):
187 | B G P
R4#show ip route bgp
B
172.16.11.0 [20/0] via 172.16.2.1, 00:13:08
B
10.0.1.0 [20/0] via 172.16.2.5, 00:11:51
Revenind la tabela BGP de pe R1, observm o alt problem menionat n seciunea iBGP vs
eBGP - R4 anun rutele primite de la ISP cu NEXT_HOP nemodificat, i ca urmare R1 nu are o rut
ctre NEXT_HOP-ul respectiv (adresele legturilor ctre ISP nu sunt anunate n OSPF):
R1#show ip bgp
Network
*> 10.0.1.0/30
* i
*> 172.16.11.0/30
* i
*> 192.168.100.1/32
*> 192.168.100.4/32
Next Hop
172.16.1.1
172.16.2.5
172.16.1.1
172.16.2.1
0.0.0.0
192.168.1.2
Metric LocPrf Weight

0
0
100
0
0
0
0
100
0
0
32768
193
32768
Path
65200
65300
65200
65300
i
i
65300 i
i
i
65200 i
R1#show ip bgp 10.0.1.0

BGP routing table entry for 10.0.1.0/30, version 2
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
65200 65300
172.16.1.1 from 172.16.1.1 (172.16.11.1)
Origin IGP, localpref 100, valid, external, best
65300
172.16.2.5 (inaccessible) from 192.168.100.4 (192.168.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
Cea mai simpl soluie pentru aceast problem este configurarea R1 (i a oricrui alt ruter care
primete rute prin eBGP i le anun mai departe n iBGP) pentru a modifica NEXT_HOP. Comanda
folosit este neighbor ... next-hop-self (dat pentru fiecare vecin iBGP al ruterului
respectiv).

Rezultatul este c rutele sunt acum primite cu un NEXT_HOP care este intern (din AS 65100),i
cunoscut prin OSPF.
R1#show ip bgp
Network
* 10.0.1.0/30
*>i
*> 172.16.11.0/30
*> 192.168.100.1/32
*> 192.168.100.4/32
Next Hop
172.16.1.1
192.168.100.4
172.16.1.1
0.0.0.0
192.168.1.2
Metric LocPrf Weight

0
0
100
0
0
0
0
32768
193
32768
Path
65200 65300 i
65300 i
65200 i
i
i
Aceeai configuraie este necesar i pentru SP2 i SP3:
SP2(config-router)#neighbor 10.0.1.2 next-hop-self

SP3(config-router)#neighbor 10.0.1.1 next-hop-self
n acest moment, configuraia de baz pare complet. Tabelele de rutare sunt corect populate
(prin OSPF, respectiv BGP),i complete. Totui, mai exist o problem important, care afecteaz
comunicaia prin reea:
R1#show ip route
B
C
B
C
O
O
C
O

172.16.11.0 [20/0] via 172.16.1.1, 00:19:32
10.0.1.0 [200/0] via 192.168.100.4, 00:12:42
192.168.2.0 [110/192] via 192.168.1.2, 00:54:03, Serial0/0
192.168.100.4 [110/193] via 192.168.1.2, 00:54:03, Serial0/0
192.168.3.0/24 [110/128] via 192.168.1.2, 00:54:03, Serial0/0
R1#ping 10.0.1.1 source Lo0

Packet sent with a source address of 192.168.100.1
U.U.U
Success rate is 0 percent (0/5)
Ruta exist, dar pachetele de date trimise ctre destina

ia respectiv se pierd. Este vorba din
nou de o problem specific BGP, provenit din faptul c adiacenele BGP se pot realiza ntre rutere
care nu sunt direct conectate fizic.
n cazul nostru, adiacena iBGP dintre R1 i R4 sare peste R2 i R3. n schimb, pachetele de
date trimise de la R1 ctre R4 vor trebui ns s treac prin R2i R3. n momentul n care pachetul
de ping cu destinaie 10.0.1.1 ajunge la R2, acesta nu cunoate o rut ctre destinaia respectiv (R2
nu vorbete BGP, i ca urmare nu va avea rute ctre destina
iile din afara AS -ului propriu). Ca
urmare, toate pachetele de date cu respectiva destinaie vor fi discarded.
Exist dou soluii principale pentru aceast problem, fiecare soluie avnd o serie de
dezavantaje:
Redistribuirea rutelor primite prin BGP n IGP-ul folosit (n cazul nostru redistribuirea din
BGP n OSPF). Soluia are dezavantajul lipsei de scalabilitate - practic nici un IGP nu va putea
s proceseze numrul imens de rute transportate de BGP (peste 290.000 de prefixe n
2009);
Rularea BGP pe toate ruterele din sistemul autonom. De multe ori singura solu ie posibil
(mai ales n cazul AS-urilor de tranzit). Dezavantajul ei este dat de faptul c iBGP necesit
crearea unui full-mesh ntre toate ruterele din AS. Ca urmare, numrul de adiacene iBGP
necesare va crete exponenial cu numrul de rutere din sistemul autonom.
Deoarece n exemplul nostru se primesc doar dou rute din afara AS, vom alege prima variant
- redistribuirea rutelor n IGP.
189 | B G P
R4(config-router)#redi
R4(config-router)#redistribute bgp 65100 sub
R4(config-router)#redistribute bgp 65100 subnets
Rezultat - acum traficul traverseaz n mod corect R2 i R3:

R1#ping 10.0.1.1 source Lo0
Packet sent with a source address of 192.168.100.1
!!!!!
8.4.2 Manipularea atributelor BGP

Configurrile de baz fiind realizate, putem trece la implementarea politicii de rutare din AS
65100. Implementarea realizat va trebui s satisfac urmtoarele cerine:
legtura R4-SP3 este legtura principal la Internet a AS65100;
legtura R4-SP2 este legtura secundar (folosit doar atunci cnd legtura principal
cade);
legtura R1-SP1 va fi folosit doar atunci cnd se pierd ambele legturi de pe R4.
Pentru o implementare corect a politicii, trebuie ca legturile s fie folosite n acest mod att
de traficul care prsete AS -ul, ct i de traficul de intrare . Acest lucru presupune modificarea
deciziei unor rutere care aparin altor AS-uri (AS 65200, AS 65300) prin setri realizate doar n AS-ul
propriu (AS 65100).
n BGP, politica de rutare se implementeaz prin modificarea atributelor rutelor primite,
respectiv trimise prin BGP. n acest scop se folosesc route-maps (descrise n capitolul de route
optimization).
Pentru a afecta traficul de ieire se poate modifica atributul LOCAL_PREFERENCE. Ne vom folosi
de faptul c valoarea implicit a acestuia este 100, i vom seta noile valori astfel:
pentru rutele primite de la SP2, LOCAL_PREF=50;
pentru rutele primite de la SP1, LOCAL_PREF=30.
R4(config)#route-map LP_50 permit 10
R4(config-route-map)#set local-preference 50
R4(config-router)#neighbor 172.16.2.1 route-map LP_50 in
!! Orice modificare a politicii de rutare necesit reiniializarea
!! adiacenei BGP!
R4#clear ip bgp *
R1(config)#route-map LP_30 permit 10

R1(config-route-map)#set local-preference 30
R1(config-route-map)#router bgp 65100
R1(config-router)#neighbor 172.16.1.1 route-map LP_30 in
R1#clear ip bgp *
Rezultatul l putem observa att n tabela BGP, cti n tabela de rutare. De exemplu, n cazul
R4, calea preferat de ieire din AS va fi prin SP3:
R4#show ip bgp
Network
* 10.0.1.0/30
*>
* 172.16.11.0/30
*>
r>i192.168.100.1/32
r>i192.168.100.4/32
Next Hop
172.16.2.1
172.16.2.5
172.16.2.1
172.16.2.5
192.168.100.1
192.168.100.1

0
50
0 65300
0 65300
50
0 65300
0 65300
0
100
0 i
193
100
0 i
i
i
65200 i
65200 i
R4#show ip route bgp

B
172.16.11.0 [20/0] via 172.16.2.5, 00:04:44
B
10.0.1.0 [20/0] via 172.16.2.5, 00:04:57
O problem mai dificil este reprezentat de modificarea cii urmate de traficul de intrare n
AS. n cazul SP2 i SP3 (rutere care fac parte din acelai AS - 65200), problema poate fi rezolvat prin
modificarea MED. Valorile mai mici pentru MED sunt preferate,i ca urmare vom seta MED la 50
pentru legtura R4-SP3, i la 100 pentru R4-SP2.
Setrile vor fi realizate pentru rutele care sunt trimise ctre vecinii din alte AS-uri (outbound
route-maps).
R4(config)#route-map MED_50 permit 10
R4(config-route-map)#set metric 50
R4(config)#route-map MED_100 permit 10
R4(config-route-map)#set metric 100
R4(config-router)#neighbor 172.16.2.5 route-map MED_50 out
R4(config-router)#neighbor 172.16.2.1 route-map MED_100 out
R4#clear ip bgp *
Rezultat - SP2 va trimite pachetele destinate AS100 via SP3:

SP2#show ip bgp
Network
Next Hop
*> 10.0.1.0/30
0.0.0.0
0
32768 i
r> 172.16.11.0/30
172.16.11.1
0
0 65200
*>i192.168.100.1/32 10.0.1.2
50
100
0 65100
*
172.16.2.2
100
0 65100
*
172.16.11.1
0 65200
*>i192.168.100.4/32 10.0.1.2
50
100
0 65100
*
172.16.2.2
100
0 65100
*
172.16.11.1
0 65200
SP2#show ip route bgp
B
192.168.100.4 [200/50] via 10.0.1.2, 00:00:48
B
192.168.100.1 [200/50] via 10.0.1.2, 00:00:48
i
i
i
65100 i
i
i
65100 i
191 | B G P
Problema principal a MED este faptul c acesta nu este transmis la urmtoarele sisteme
autonome. Ca urmare, nu este posibil modificarea deciziei AS 65200 (sau a altor AS-uri, aflate mai
departe) folosind doar MED.
n aceste cazuri, solu
ia preferat este modificarea AS_PATH. Acesta este modificat prin
adugarea la nceputul su (prepending) a ASN-ului propriu, repetat de un numr de ori. Cu ct
numrul de repetiii va fi mai mare, cu att ruta respectiv va fi considerat mai puin bun de ctre
ruterele din alte AS-uri. n general (n Internet), este suficient un AS-Path prepending de 3 sau 4 ori.
Este obligatoriu ca ASN-ul folosit pentru prepending s fie ASN-ul propriu!
R1(config)#route-map PREPEND permit 10
R1(config-route-map)#set as-path prepend 65100 65100 65100
R1(config-route-map)#router bgp 65100
R1(config-router)#neighbor 172.16.1.1 route-map PREPEND out
R1#clear ip bgp *
Rezultatul configuraiei se observ pe SP1 - ruta prin R1 are un AS_PATH mai lung dect ruta
alternativ (prin SP2), i ca urmare SP1 va trimite pachetele destinate AS 65100 ctre SP2:
SP1#show ip bgp
Network
Next Hop
* 10.0.1.0/30
172.16.1.2
65100 65100 65300 i
*>
172.16.11.2
*> 172.16.11.0/30
0.0.0.0

0 65100 65100
0
0
0 65300 i
32768 i
SP1#show ip route bgp

B
10.0.1.0 [20/0] via 172.16.11.2, 01:54:03
B
192.168.100.4 [20/0] via 172.16.11.2, 00:00:51
B
192.168.100.1 [20/0] via 172.16.11.2, 00:00:51
Trebuie menionat aici faptul c modificarea traseului traficului de intrare se putea face numai
prin AS_PATH prepending (de exemplu prin prepending de 2 ori pe SP3,i de 3 ori pe SP1), i
aceasta este n general soluia preferat. Varianta folosirii MED a fost prezentat doar ca exemplu
didactic.
9 IP M ulti cast
Conceptul de multicast s-a nscut la sfritul anilor 1980 cnd Steve Deering a lucrat la un
proiect ce presupunea transmiterea unui mesaj de la un calculator la un grup de calculatoare peste
o infrastructura de nivel 3. Analiznd protocoalele de rutare existente n acel moment, Deering a
tras concluzia c acestea pot fi extinse pentru a implementa ceea ce el a numit Layer 3
Multicasting. n urma unei perioade de cercetare a fost publicat lucrarea Multicast Routing in a
Datagram Network n care erau definite componentele principale ale unei infrastructuri multicast,
protocoalele multicast i funcionalitile lor. n capitolul ce urmeaz se vor analiza cerinele unei
reele multicast moderne i protocoale ce au evoluat din 1991, de la publicarea lucrrii mai sus
menionate, pn n prezent.
Plecnd de la conceptul de baz a lui Dr. Deering, infrastructurile din prezent pot lua forme
extrem de complexe ns cea mai simpl definiie a conceptului de IP multicast este:
Trimiterea unui mesaj de la o singur surs la mai multe destinaii selectate folosind un
singur flux de date peste o reea de nivel 3.
9.1 De ce avem nevoie de multicast ?

Pentru a rspunde la aceast ntrebare se vor analiza alternativele pe care protocolul IP le
ofer. Dac se dorete trimiterea unui mesaj de la o singur surs la o singur destinaie, se poate
folosi un mesaj unicast. Dac se dore
te trimiterea unui mesaj de la o sing ur surs la toate
destinaiile dintr-o subreea, se va folosi un mesaj broadcast. ns dac se dorete trimiterea unui
mesaj de la o surs (sau chiar mai multe) la multiple destinaii ntr-un singur stream de date, peste o
reea de nivel 3, cel mai eficient mecanism este IP multicast.
Ca i popularitate, transmiterea de multicast este folosit din ce n ce mai mult n reele
moderne pentru streaming de video, jocuri multiplayer, transmiterea de radio etc. De asemenea n
IPv6 multicast joaca un rol important deoarece transmisiile de tip broadcast nu mai sunt
implementate.
9.2 Funcionarea multicast

In cele ce urmeaz se va realiza un studiu de caz pentru a motiva existena tipului multicast de
transmisie de date, fa de folosirea unicast sau broadcast pentru a ndeplini acelai scop.
Video
Streaming
R1
S0/0
Fa0/1
Layer 3
S0/0
SW2
SW1
Fa0/2
Fa0/1
R2
A1
A2
A3
B1
B2
B3
Figura 9-1: Infrastructur IP

n topologia de mai sus se dore
te transmiterea unui
stream video de la Serverul direct
conectat la ruterul R1, peste Internet, la multiple staii destinaie conectate la SW1 i SW2.
Cazul 1: unicast
Paradigma unicast folosete o singur surs i destinaie. Plecnd de la aceast definiie, pentru
a putea atinge scopul definit mai sus, serverul de Video Streaming va trebui s transmit n streamuri diferite. Dac se noteaz valoarea limii de band necesar pentru a transmite stream-ul video
cu b, rezult o band total de n*b ce trebuie consumat pe ntreaga rut de surs la destinaie. Se
concluzioneaz faptul c aceast soluie este ineficient i greu scalabil.
Cazul 2: broadcast
Fa de unicast, broadcast-ul are avantajul transmiterii unui singur stream. Problemele apar
ns din modul n care dispozitivele de reea trateaz broadcast-urile. Un ruter nu poate s trimit
pachete broadcast n mod implicit dintr-o reea de nivel 3 n alta, iar odat configurat acest
comportament, pachetele se vor duce n toate direciile chiar dac destinaiile pentru acel stream
sunt doar cteva staii izolate ntr-o reea local. Aceast problem apare ca o consecin a faptului
c o adres de broadcast se identific cu o reea local, nu cu unul sau mai multe grupuri selectate
de multicast.
Cazul 3: multicast
Pentru a putea transmite multicast este nevoie att de infrastructura de nivel 3 multicast, ct i
de suport din partea nivelului aplicaie. Cu alte cuvinte att la surs ct i la destinaie este instalat
aplicaia de multicast care s trimit pachete cu adresa destinaie adresa grupului de multicast i
care s tie s primeasc i s interpreteze aceste pachete la destinaie. Transmisia multicast are
nevoie de urmtoarele componente pentru a funciona corect:
195 | I P M u l t i c a s t
O clas special de adrese din care se vor delega adrese pentru fiecare grup multicast.
Aceasta este identificat ca fiind clasa D din protocolul IP: 224.0.0.0 239.255.255.255.
Adresele clasei D pot fi uor recunoscute prin primii 4 bii ai primului octet: 1110;
Fiecare grup trebuie s fie identificat de o adres din spaiul clasei D. O astfel de adres nu
poate fi folosit dect ca adres destinaie, niciodat ca adres surs. Fa de IP unicast,
multicast nu este folosit pentru a identifica
ii sta
sau echipamente, ci doar grupuri
destinaie;
Aplicaia multicast trebuie instalat pe toate staiile ce doresc s primeasc stream-ul de la
server. De asemenea, aceasta trebuie configurat s asculte pe aceea
i adres IP pe care
serverul trimite traficul;
O metod standard de a calcula o adres de nivel 2 dintr-o adres de multicast de nivel 3.
Pentru c n stiva TCP/IP se verific mai nti adresa MAC, trebuie s existe o asociere ntre
o adres multicast de nivel 3 i adresa multicast de nivel 2. Cu alte cuvinte, cnd o aplicaie
client de multicast pornete i este configurat cu adresa IP a grupului de multicast, ea va
deduce n mod standard o adresa MAC din adresa iIPva configura placa de reea s
asculte pe acea adres MAC pentru traficul de la server.
Un mecanism prin care staiile dintr -o reea local s poat semnala ruterului gateway
faptul c doresc s primeasc trafic pentru un grup semnalat. Totodat, trebuie s existe o
metod prin care o staie s poat prsi un grup de multicast. Aceste funcionaliti sunt
oferite prin intermediul protocolului Internet Group Management Protocol (IGMP).
Un protocol de rutare multicast care s transmit stream-ul peste infrastructura de nivel 3.
Cele mai cunoscute protocoale ce ndeplinesc acest scop sunt: Distance Vector Multicast
Routing Protocol (DVMRP), Protocol Independent Multicast (PIM), Multicast OSPF (MOSPF).
Urmrind paii de mai jos se va oferi o imagine de ansamblu asupra funcionrii unei transmisii
multicast n Figura 1-1 de la surs la destina
ie. n capitolele ulterioare se va pune accept pe
implementarea fiecrui protocol menionat.
1. Serverul video va transmite un singur stream de trafic multicast ctre adresa special
multicast 224.0.1.120, ce identific grupul din care fac parte sta iile A1, A2 i B2.
2. Pentru direcionarea stream-ului de la ruterul R1 la R2 peste Internet, se va folosi un
protocol de rutare multicast care va transmite traficul doar acelor rutere care fac parte din
cea mai scurta cale de la R1 la R2.
3. Staiile A1, A2 i B2 vor folosi protocolul IGMP pentru a i specifica ruterul R2 c doresc s
primeasc trafic pentru grupul multicast 224.0.1.120. Ruterul va lua deci decizia
direcionrii traficului multicast primit ctre interfeele Fa0/1 i Fa0/2. Pentru a trimite ns
trafic ntr-o reea local, R2 trebuie s elimine antetul de nivel 2 de pe legtura serial S0/0
i s ncapsuleze cu un antet Ethernet (o adres MAC surs i destinaie). Traficul multicast
nu are ca destinaie o singur staie (adres MAC unicast) sau toate staiile (adresa MAC
FFFF:FFFF:FFFF), astfel nct ruterul va utiliza adresa MAC destinaie: 0x0100.5e00.0178 din
adresa de nivel 3: 224.0.1.120.
4. Odat instalate, pentru a primi trafic pentru grupul 224.0.1.120, aplica
iile client de pe
staiile A1, A2, B2 vor configura placa de reea pentru a asculta pe adresa MAC
0x0100.5e00.0178.
5. Switchurile Sw1 i Sw2 vor primi traficul multicast de la R2 i, pentru c n mod implicit nu
au adresa 0x0100.5e00.0178 n tabela CAM, vor face flooding, trimind traficul la toate
staiile din LAN. Astfel traficul va ajunge att la staiile care au cerut prin IGMP acest stream
ct i la staiile care nu doreau s fac parte din grupul multicast 224.0.1.120
i care vor
ignora pachetele primite la nivel 2 (plcile lor de reea nu ascult pe adresa
0x0100.5e00.0178). Acest comportament ineficient poate fi mpiedicat folosind protocoale
precum Cisco Group Management Protocol (CGMP) sau IGMP Snooping care pot indica
switchului pe ce porturi se afl staiile care doresc trafic multicast pentru un anumit grup.
6. R2 va continua s trimit trafic pe ambele interfee FastEthernet pn cnd stream-ul se va
termina sau pn cnd toate staiile de pe oricare dintre segmentele LAN vor prsi grupul
de multicast 224.0.1.120 folosind un mesaj de IGMP Leave.
Un ultim detaliu de men
ionat n aceast introducere este c traficul multicast funcioneaz
numai peste UDP.
9.3 Adresarea multicast

Existena unui spaiu de adrese IP alocat transmisiilor multicast este vital n funcionarea
conceptului de IP Multicast. n paradigma unicast, o adres IP reprezenta un nod ea
n rei de
aceea se realizai asignarea acesteia pe o interfa a respectivului nod. n contrast, o adres
multicast reprezint un grup de destinatari i nu este niciodat asignat unui dispozitiv. Singurul loc
n care acest tip de adres este folosit este n cmpul de IP destina
ie din antetul IP pentru ca
dispozitivele de rutare s recunoasc acel pachet ca fcnd parte dintr-un stream de la sursa:
IP_SURS i destinat grupului: IP_DESTINAIE.
Organizaia IANA (Internet Assigned Numbers Authority) a alocat ntreaga clasa D pentru
utilizarea n aplicaii multicas t: 224.0.0.0 239.255.255.255. Primii patru bii sunt mereu 1110 iar
ultimii 28 de bii reprezint o adresare plat (o adres multicast nu are o masc de reea).
9.3.1 Structura adreselor multicast

Internet Assigned Numbers Authority (IANA) este organizaia ce controleaz asignarea adreselor
multicast ctre noi aplicaii emergente. Pentru a nu rmne fr adrese IP, IANA este reticent la
oferirea adreselor din clasa D. O aplica
ie trebuie s fie nu numai stabil i bine construit, ci s
demonstreze i o acoper ire considerabil a pie
ei. Adresele multicast se mpart n urmtoarele
categorii:
Adresele permanente
Adrese multicast permanente se aloc din spa
iul de adrese 224.0.0.0 224.0.1.255. Aceste
adrese sunt asociate de ctre IANA protocoalelor i aplicaiilor bine cunoscute. Ele se mpart n dou
subtipuri funcie de criteriul: dac sunt direcionate de ruter sau nu.
Spaiul de adrese 224.0.0.0 224.0.0.255 sunt cunoscute ca fiind adrese multicast locale pentru
c nu sunt direcionate niciodat de ctre un ruter. n aceast categorie intr adresele folosite de
diferitele protocoale de rutare:
EIGRP: 224.0.0.9
RIPv2: 224.0.0.10
OSPF: 224.0.0.5 i 224.0.0.6
Restul spaiului (224.0.1.0 224.0.1.255) este alocat celor mai cunoscute aplicaii multicast i
sunt direcionate de ctre rutere peste reele de nivel 3:
224.0.1.1 NTP
224.0.1.75 SIP
Adresele private
Echivalentul din unicast al adreselor private, adresele multicast iul
din spa
239.0.0.0
239.255.255.255 este folosit n domenii private de administrare, fiind responsabilitatea
administratorului de re
ea (i a ISP -urilor, n ultim instan
) s nu permit direcionarea
pachetelor ce conin astfel de adrese ntr-o reea public.
Adresele Source Specific Multicast
Adresele SSM se aloc din spaiul de adrese 232.0.0.0 232.255.255.255 i sunt folosite n
cazuri n care destina
ia dorete s aib posibilitatea de a selecta sursa de la care dorete s
primeasc trafic. Acest mecanism poate fi folosi i pentru a limita ncercrile de DoS. Dac una
dintre sursele traficului de multicast devine compromis i ncepe s trimit trafic nedorit,
utilizatorul poate comunica protocolului faptul c nu dorete s primeasc trafic de la respectiva
surs.
Adresele GLOP
Spaiul de adrese pentru acest tip special de multicast este: 233.0.0.0 233.255.255.255. Ideea
adreselor GLOP a fost conceput pentru a da posibilitatea fiecrui deintor al unui AS s poat
folosi 255 de adrese multicast proprii, unice la nivel global. Implementarea este foarte simpl: primii
8 bii ai unei adrese GLOP sunt mereu 233, dup care urmeaz cei 16 bii ai numrului AS i apoi 8
bii pe care fiecare organizaie i poate varia pentru a obine 255 de adrese multicast, rutabile la
nivel global. n mod implicit, IANA permite existena acestor adrese de multicast n Internet fr a fi
nevoie de o procedur de nchiriere sau mapare a adresei.
Adresele transient
Restul spaiului multicast este format din adrese rutabile la nivel global, ns temporare. Dac o
organizaie dorete s nchirieze o adres multicast pentru o anumit perioad/transmisie, IANA
ofer o procedur de lease/unlease care face posibil acest lucru.
9.3.2 Maparea adreselor multicast IP la adrese MAC

Dup cum s-a specificat n capitolul 1.2, adresarea multicast se face att la nivel 3 ct i la nivel
2, cea din urm fiind dedus printr-o formul din cea dinti. Configurarea unei aplicaii pentru
utilizarea unei adrese IP multicast genereaz automat o adres MAC pe care placa ea
de re
va
asculta pentru cadre ce fac parte din stream. Construirea unei astfel de adrese se face astfel:
Partea OUI a adresei MAC este mereu: 01005E;
Bitul 24 este mereu 0
Ultimii 23 de bii ai adresei MAC sunt identici cu ultimii 23 de bii ai adresei IP.
`
8 bii
24 bii
224
1100 0000
0000 0001
0001 1000
01005E
0100 0000
0000 0001
0001 1000
24 bii
24 bii
Figura 9-2: Maparea dintre o adres multicast i o adres MAC

Pentru a exemplifica acest procedeu a fost folosit adresa multicast 224.192.1.24. Primii 8 bii
ai adresei IP sunt scrii n zecimal i primii 24 de ibi ai adresei MAC sunt s crii n hexazecimal din
motive de ergonomie.
9.4 Gestiunea grupurilor multicast n LAN

n cele de mai jos se va reveni asupra scenariului prezentat n capitolul 1.2 Funcionarea
multicast. Se va considera momentul din transmisie n care traficul multicast a ajuns prin seriala
S0/0 la R2. Ruterul va trebui s poat s rspund la urmtoarele ntrebri:
Este cineva pe orice segment LAN direct conectat care dorete acest stream video ?
Dac exist cel puin un destinatar al stream-ului pe care dintre interfeele Ethernet ar
trebui s fie transmis traficul multicast ?
S0/0
SW2
SW1
Fa0/2
Fa0/1
R2
A1
A2
A3
B1
B2
B3
Figura 9-3: Managementul traficului n LAN

ntrebrile de mai sus definesc, de fapt, iile
func de baz pe care protocolul
IGMPv2 le
implementeaz. n topologia de mai sus, ns, nu doar ruterul are responsabilitatea de decizie.
Implementarea unei soluii multicast complete presupune ca switchurile din figur s cunoasc
porturile pe care se afl staiile care fac parte din grupul multicast i s trimit stream-ul de la ruter
doar pe acele porturi. Pentru a avea un astfel de comportament, un switch trebuie s ruleze unul
din protocoalele: Cisco Group Management Protocol (CGMP) sau IGMP Snooping.
9.4.1 IGMP v2
IGMP este protocolul ce a evoluat din descrierea lui Deering. Dei n prezent protocolul a ajuns
la versiunea a 3-a, aceast carte va trata versiunea a 2-a cci este cea folosit n 99% dintre cazuri n
implementrile din industrie. IGMPv3 nu este suportat deocamdat pe niciun sistem de operare i
suportul din partea aplicaiilor este i el foarte limitat. n contrast, IGMPv1 este o versiune veche i
ineficient a protocolului care va fi menionat doar n conturarea evoluiei facilitilor din IGMPv2.
Rolurile de baz ale protocolului IGMP sunt urmtoarele:
Oferirea unui mecanism prin care o staie s poat informa ruterul gateway de faptul c
dorete s primeasc trafic multicast pentru un anumit grup;
Oferirea unui mecanism prin care o staie s poat informa ruterul gateway c dorete s
prseasc un grup;
IGMPv2 funcioneaz direct peste protocolul IP (urmtorul antet dup IP), avnd numrul de
protocol 2. Toate mesajele folosite n protocol au cmpul TTL egal cu 1 pentru a limita raza acestora
la reeaua local.
9.4.2 Antetul IGMPv2

Pentru a explica mecanismul de nregistrare la un grup de multicast, se va prezenta mai nti
antetul IGMPv2:
32 bii
Type
Group Address
MRT
IGMP checksum
Figura 9-4: Structura Antetului IGMPv2

Cmpul Type este folosit pentru codificarea diferitelor tipuri de mesaje IGMP. Se amintesc:
0x11 Membership Query este mesajul folosit de ruter pentru a interoga existen a
destinatarilor pentru un grup de multicast pe un segment de reea. Exist dou tipuri de
query-uri folosite n IGMPv2: General Membership Query i Group-Specific Query.
0x16 Membership Report este folosit de staii pentru a semnala ruterului c cel puin un
destinatar al unui grup specific de multicast exist pe segmentul de re ea.
0x17 Leave Group este folosit pentru a semnala ruterului gateway faptul c un destinatar
nu mai dorete s primeasc trafic multicast.
Cmpul MRT (Maximum Response Time) are o valoare ntre 0.1i 25.5 secunde i este folosit
pentru optimizarea procesului de nregistrare la un grup i se va detalia n acest subcapitol. Acesta
este exprimat n antet n zecimi de secunde: o valoare de 30 va nsemna 3 secunde. n mod implicit,
valoarea este de 10 secunde ntr-un General Membership Query.
Cmpul IGMP checksum este folosit ca i orice alt checksum din protocoale de comunicaie
pentru a verifica integritatea mesajului.
Cmpul Group Address este poate cel mai semnificativ din antet n n
elegerea funcionalitii
de nregistrare IGMPi este setat la diferite valori funcie de mesajul folosit. Spre exemplu, un
General Membership Query va seta acest cmp la valoarea 0.0.0.0 cci dorete s descopere orice
destinatar al oricrui grup multicast pe un anumit segment.
9.4.3 nregistrarea la un grup de multicast

Cele 2 mesaje folosite n nregistrarea la un grup multicast sunt: General Membership Query i
Membership Report. n continuare se vor prezenta paii din procesul de trimitere a primului dintre
aceste dou mesaje:
General Membership Query
General
Membership
Query: Exist
vreun destinatar
ar oricrui grup
General
Membership
Query: Exist
vreun destinatar
ar oricrui grup
SW2
SW1
Fa0/2
Fa0/1
R2
A1
A2
A3
B1
Figura 9-5: nregistrarea la un grup multicast
B2
B3
1. nainte de a se trimite orice mesaj IGMPv2, aplicaia multicast client se va porni pe staiile
A1, A2 i B2 care sunt destinatarii pentru stream-ul de multicast trimis din Internet. Odat
pornit, administratorul va trebui s configureze adresa IP multicast pe care va func
iona
transmisia (aceeai adres care este setat i pe componenta server a aplicaiei). Se va
presupune adresa 227.1.1.1. n acest moment placa de re ea va asculta pe 3 adrese MAC:
o 01.00.5E.01.01.01, adresa MAC obinut din derivarea adresei IP 227.1.1.1 (prin
procesul descris n capitolul 1.3.2);
o 01.00.5E.00.00.01, adresa MAC obinut din derivarea adresei IP 224.0.0.1 pe care
toate echipamentele (staii i rutere) ascult n mod implicit;
o BIA (Burned In Address), adresa nativ a plcii de reea
2. Odat pornit i la fiecare 60 de secunde, ruterul R2 va trimite un General Membership
Query cu adresa IP destinaie: 224.0.0.1 (all-hosts). n acest mesaj cmpul Group Address va
fi setat la valoarea 0.0.0.0. Cu alte cuvinte, ruterul va trimite un astfel de mesaj pe fiecare
segment Ethernet la care este conectat, cu inten
ia de a verifica dac exist cel puin un
destinatar pentru orice grup de multicast. Cai mesajel e de Report i Leave, un General
Membership Query va avea valoarea TTL egal cu 1.
Membership Report
Un mesaj IGMPv2 Report este folosit de ctre o ie
sta pentru a semnala ruterului faptul c
dorete s primeasc trafic multicast pentru un anumit grup. Acest tip de mesaj poate fi trimis sub
dou forme:
Membership Report solicitat este trimis ca rspuns la un Membership Query coninnd n
cmpul Group Address, adresa grupului pentru care staia dorete s primeasc trafic
multicast;
Membership Report nesolicitat este trimis imediat ce aplicaia multicast a fost configurat
de administrator s primeasc trafic pentru un grup identificat printr-o adres IP. Acest
comportament este dat de aplicaie; exist aplicaii care ateapt un Membership Query de
la ruter i altele care trimit direct acest tip de mesaj pentru a face nscrierea mai rapid.
n continuare se va trata cazul unui report solicitat. Un raport nesolicitat funcioneaz n acelai
mod doar c nu este un rspuns la un pachet de Query.
SW2
SW1
Fa0/2
Fa0/1
R2
A1
A2
- Am primit un query.
- Calculez RT(A1) =
random (MRT)
- Voi rspunde cnd
RT expir dac n acel
moment nu a
rspuns cineva de pe
acest segment deja.
A3
B1
- Calculez RT(A2) =
random (MRT)
- Voi rspunde cnd
RT expir dac n acel
moment nu a
rspuns cineva de pe
acest segment deja.
B2
- Calculez RT(B1) =
random (MRT)
- Voi rspunde cnd
RT expir dac n acel
moment nu a
rspuns cineva de pe
acest segment deja.
Figura 9-6: Calcularea MRT
B3
Mesajul de General Membership Query va ajunge la toate staiile din reea cci a fost trimis cu
adresa IP destinaie 224.0.0.1. Toate staiile care fac parte dintr -un grup oarecare vor dori s
rspund deoarece cmpul Group Address a fost setat la valoarea 0.0.0.0 (any group). O problem
apare n momentul n care neaua
re local sunt foarte multe staii care doresc un
stream
multicast. Dac toate ar rspunde n acelai timp cu un Membership Report solicitat la fiecare 60 de
secunde, ruterul ar avea foarte multe pachete de procesat. O a doua problem este faptul c
ruterul nici nu are nevoie, de fapt, s primeasc 40 de Report-uri de la 40 de staii care se afl pe
acelai segment, deoarece un singur mesaj ar fi suficient pentru a putea trimite stream-ul pe acea
interfa Ethernet. Faptul ca sunt 40 de staii pe segment ce doresc stream-ul sau una singur nu
reprezint nicio diferen pentru ruter. Pentru a rezolva aceste dou probleme se folosete cmpul
MRT din General Membership Query alturi de un comportament numit Report Supression.
Cnd un destinatar multicast primete un mesaj de query, el extrage valoarea exprimat n zeci
de secunde din cmpul MRT [1.4.2]. n continuare, calculeaz o valoare numit Response Time dup
formula: RT = random(MRT). Protocolul va porni acum un timer cu valoarea RT iar cnd acest timer
va expira, staia va trimite mesajul de Membership Report. Acest algoritm mpiedic problema de
rafal de mesaje Report descris mai sus
i asigur o distribuie relativ juniform de mesaje de
Report n timp, dac exist mai multe grupuri pe acelai segment Ethernet.
n continuare persist problema mesajelor redundante trimise de toate
iilestade pe
un
segment care fac parte dintr-un grup. Pentru a rezolva acest lucru, IGMPv2 specific adresa IP
destinaie a unui mesaj de Membership Report ca fiind adresa grupului de multicast pentru care
dorete s primeasc trafic; n cazul de fa: 227.1.1.1.
Se va presupune c ntr-o reea exist 30 de staii ce doresc trafic pentru grupul 227.1.1.1. Cnd
vor primi un General Query, toate vor calcula un RT. Staia care a obinut cel mai mic RT, va trimite
un Report cu cmpul Group Address setat la valoarea 227.1.1.1 i cu adresa IP destinaie setat tot
la valoarea 227.1.1.1. Acest Report va fi primit de ruteri de toate celelalte 29 de staii, mesajul
fiind trimis pe adresa grupului. Cnd cele 29 de sta
ii vor primi mesajul de Membership Report nu
vor mai trimite la rndul lor mesaje de Report considernd ca un singur mesaj a fost suficient pentru
a ajunge la ruter. Acest comportament poart numele de Report Supression.
SW2
Fa0/1
A1
A2
R2
A3
A expirat timer-ul RT. Trimit

un Report cu adres IP
destinaie = 227.1.1.1
- Nu a expirat nc RT-ul,
ns cineva de pe
segment a trimis deja un
Report.
Figura 9-7: Report Supression
9.4.4 Prsirea unui grup de multicast

Mecanismul IGMP Leave este unul dintre principalele motivele pentru care versiunea a doua a
protocolului a fost creat. n IGMPv1, prsirea unui grup de multicast era fcut dac un Report nu
era primit n urma trimiterii a 3 mesaje de General Membership Query. Un mesaj de query era
trimis o data la 30 de secunde deci unui ruter necesita 90 de secunde pentru a concluziona c
nimeni de pe segment nu mai dorete stream-ul multicast.
Ca rspuns la aceast metod ineficient, IGMPv2 include un mesaj special de prsire a unui
grup, numit Leave Group, prin care o staie poate informa ruterul c nu mai dorete trafic multicast.
Cu acest mecanism, un ruter poate determina dac mai exist cineva pe segment carete
dore
stream-ul n doar 3 secunde.
Pentru a reui aceast performan, IGMPv2 folosete, pe lng mesajul Leave i mesajul
Group-Specific Query, prin care interogheaz un segment de reea pentru a vedea dac mai exist
cel puin un destinatar pentru un grup specific. n continuare se vor prezenta paii din procesul de
prsire a unui grup multicast.
R1
R2
Fa0/1
SW2
A1
227.1.1.1
A2
A3
Figura 9-8: Prsirea unui grup de multicast

1. A1 i A2 fac parte din grupul 227.1.1.1. Staia A1 dorete s prseasc grupul multicast.
2. A1 trimite un mesaj de tip IGMPv2 Leave ctre adresa IP destinaie 224.0.0.2 (all routers)
pentru a semnala tuturor ruterelor multicast de pe segment c dorete s prseasc
grupul pe care l-a completat n cmpul Group Address.
3. Ruterul R1, responsabil cu managementul IGMP pentru grupul 227.1.1.1, va trimite un
mesaj de tip Group-Specific Query cu cmpul Group Address setat la valoarea 227.1.1.1,
pentru a analiza dac mai exist cineva pe acel segment care dorete s primeasc trafic
pentru acel grup.
4. Deoarece A2 nc dorete trafic pentru acest grup, va rspunde cu un Membership Report.
Mecanismul de Report Supression descris anterior se va folosi i n acest caz.
5. R1 va primi Report-ul i va concluziona c tre buie s trimit n continuare trafic pe acel
segment.
Dac pe segment nu ar fi existat alt ie
sta care s necesite trafic pentru grupul 227.1.1.1,
ruterul ar fi aplicat un algoritm care n maxim 3 secunde poate s concluzioneze dac mai trebuie s
trimit sau nu trafic multicast pe acel segment Ethernet. Acest algoritm define te dou constante:
Last Member Query Interval este o valoare de timp i este egal cu valoarea cmpului MRT.
ntr-un mesaj de tip Group-Specific Query cmpul MRT are n mod implicit o valoare de o
secund.
Last Member Query Count este un numr ntreg pozitiv folosit n algoritm, al crui
pseudocod e descris mai jos. Valoarea sa implicit este 2.
Cnd ruterul va primi un mesaj de Leave va trimite automat un Group-Specific Query. Dac nu
va primi un Report n intervalul definit de Last Member Query Interval, va continua s trimit
mesaje Group-Specific Query i s atepte intervalul Last Member Query Interval pentru fiecare
query de numrul de ori definit de variabila Last Member Query Count. Pseudocodul pentru aceast
operaie este prezentat mai jos.
Do {
Send a Group-Specific Query ;
Last_Member_Query_Count -- ;
While (Last Member Query Count != 0 &&
no_answer_in Last Member Query Interval )
Se poate observa uor din cele de mai sus c bucla programatic se va repeta de 3 ori numrndi
primul mesaj Group-Specific Query trimis ca rspuns la mesajul de Leave.
9.5 Optimizri ale transmiterii multicast n LAN

Se va considera urmtoarea topologie n care staiile A1 i A2 au anunat printr-un Membership
Report faptul c vor s primeasc stream-ul 227.1.1.1.
SW2
Fa0/1
Fa0/1
R2
A5
A1 227.1.1.1
A4
A2
A3
Figura 9-9: Tratarea traficului multicast de ctre un switch

Pentru c exist cel puin o staie pe i nterfaa Fa0/1 a ruterul R2 care dorete s primeasc
trafic multicast, ruterul R2 direcioneaz n reeaua local stream-ul primit din Internet. Cnd acest
trafic ajunge la switchul SW2, acesta introduce cadrele multicast n procesul de comutare folosind
tabela CAM. Aceast tabel con
ine o mapare ntre adresele MAC surs ale staiilor din reeaua
local i porturile pe care aceste staii se afl. Astfel, cnd un cadru intr n procesul de comutare,
switchul inspecteaz tabela sa CAMi ncearc s caute o mapare pentru adresa MAC destinaie a
cadrului. Dac aceast adres nu este gsit n tabel, switchul trimite cadrul pe toate porturile n
afar de cel pe care acesta a sosit, pentru a garanta transmisia pn la destina ie.
Revenind la scenariul din topologie, traficul multicast ajunge la switch cu adresa MAC destinaie
01.00.5E.01.01.01. Problema switchului este c acesta nu va gsi niciodat o mapare n tabela sa
CAM pentru aceast adres sau orice alt adres multicast, pentru c acestea nu se asigneaz
niciodat ca adrese surs. Concluzia este ca switchul va trata orice trafic multicast n acelai mod: l
va trimite pe toate interfeele sale. n cazul n care este vorba de o reea local de 100 de staii, ns
doar 2 din ele fac parte din grupul multicast, ocuparea inutil a reelei nu este de dorit.
Pentru a rezolva aceast problem se folosesc dou protocoale: Cisco Group Management
Protocol (CGMP) i IGMP Snooping. Prezentarea n detaliu a celor dou protocoale depete scopul
acestei cri astfel c n cele ce urmeaz se va face o trecere sumar prin func
ionarea de baz a
fiecrui protocol.
9.5.1 Cisco Group Management Protocol

CGMP este un protocol proprietar Cisco ce funcioneaz la nivelul 2. Pentru a-i ndeplini scopul
acesta trebuie s ruleze att pe ruter ct i pe switch. Ideea dup care CGMP a fost creat presupune
o comunicare ntre ruteri switch prin care ruterul i indic switchului adresele MAC ale staiilor
care vor s primeasc multicast. Ruterul cunoate aceste adrese MAC din comunicaia IGMP pe care
o are cu fiecare staie ce dorete s fac parte din grupul de multicast.
Odat cu adresele MAC ale sta
iilor dintr -un anumit grup, switchul prime
te de la ruter i
adresa MAC multicast a grupului. Astfel acesta caut n tabela CAM porturile pe care cunoa
te
adresele MAC ale staiilor i creeaz mapri noi ntre adresa MAC de multicast a grupului i porturile
fiecrei staii.
9.5.2 IGMP Snooping

IGMP Snooping este o alternativa la solu
ia Cisco pentru problema
flooding-ului 1 pe care
switchul l face n mod implicit cu orice trafic multicast. Cea mai mare diferen ntre acest protocol
i CGMP este c IGMP Snooping nu trebuie rulat dect pe switch. Acest comportament i-a ctigat
n timp popularitate fa de CGMP, care ocup mai mult band i implic procesare din partea
ruterului.
IGMP Snooping i ofer switchului inteligena de care are nevoie pentru a putea interpreta
mesajele IGMP pe care le comut ntre staii i ruter. Astfel switchul poate s nvee pe ce porturi se
afl staiile ce fac parte dintr-un anumit grup i s evite procesul de flooding. Pe lng aceast
funcionalitate de baz, sunt adugate i diferite optimizri pentru IGMP. Spre exemplu cnd
switchul primete un mesaj IGMP Leave pentru un anumit grup, el va cuta n tabela CAM i va
decide dac mai exist cel puin o staie n grupul respectiv. n caz afirmativ nu va mai comuta
mesajul de Leave la ruter pentru a evita schimbul de mesaje Group-Specific Query i Membership
Report pe care ruterul i staiile ar urma s l fac n urma unui mesaj IGMP Leave.
n present, IGMP Snooping este protocolul preferat att de Cisco ct i de ali productori
pentru c resursele de reea consumate sunt mult mai mici i pentru c adaug mai multe
optimizri pentru IGMP.
http://www.ciscopress.com/articles/article.asp?p=101629&seqNum=2
9.6 Rutarea multicast

Principalul atribut al unui protocol de rutare unicast este propagarea rutelor n mod dinamic
ntre mai multe rutere. Pentru a atinge acest scop, orice IGP (Interior Gateway Protocol) pornete
prin a anuna reelele sale direct conectate tuturor vecinilor si pentru ca acetia s le anune mai
departe. Astfel dup un anumit timp de convergen ce depinde de protocolul folosit, toate ruterele
vor cunoate cea mai scurt cale ctre orice destinaie, pe baza metricii folosite.
Din acest comportament reiese faptul c un protocol de rutare IGP unicast nu ar putea
niciodat s direcioneze trafic multicast din cauza faptului c adresele de multicast nu se asigneaz
niciodat pe interfee.
Un protocol de rutare multicast nu este interesat de propagarea reelelor direct conectate, ci
de construirea celei mai bune ci de la sursa de multicast la destinaia de multicast peste o reea de
nivel 3. Exist dou tipuri de protocoale de rutare multicast folosite n implementri reale:
Protocoale dense sunt preferate n momentul n care exist cel puin un destinatar n
fiecare subreea dintr-o anumit arie geografic.
Protocoale sparse sunt preferate n momentul n care destinatarii multicast sunt grupai n
puine subreele dintr-o anumit arie geografic.
n prezent cele mai cunoscute protocoale de rutare multicast sunt: Protocol Independent
Multicast Dense Mode (PIM-DM), Protocol Independent Multicast Sparse Mode (PIM-SM), Multicast
OSPF (MOSPF), Distance Vector Multicast Routing Protocol (DVMRP). Dintre acestea PIM-SM i
PIM-DM conduc detaat n topul de popularitate, MOSPF i DVMRP nefiind nici mcar suportate
complet pe rutere Cisco.
9.6.1 PIM-DM
Motivul pentru care protocolul PIM (Protocol Independent Multicast) este att de popular n
ambele forme ale sale (Dense Mode
i Spa
rse Mode) este pentru c este se bazeaz pe
implementarea protocoalelor de rutare unicast pentru a gsi cea mai scurt cale ctre
destinaie/surs. Dup cum s-a menionat n subcapitolul anterior [1.6], construirea unei ci optime
ntre destinaie i surs este unul dintre scopurile principale ale unui protocol de rutare multicast.
PIM evit reinventarea roii i folosete orice rut din tabela de rutare pentru a determina calea
optim fr a lua n considerare ce protocol de rutare unicast a generat acea rut. Dezavantajul
competitorului DVMRP, n acest caz, este c aduce overhead-ul unei implementri interne de
protocol de rutare unicast, foarte asemntor cu RIPv2, care s fac determinarea cii. De cealalt
parte, MOSPF introduce o dependen
de protoc olul de rutare unicast OSPF pentru a putea
funciona. Astfel, ca i n multe alte situaii din lumea reelelor de calculatoare, simplitatea ctig.
PIM a fost la nceput un protocol proprietar Cisco, ns a fost deschis ctre standardizare prin
RFC-urile 2362, 3446 si 3973. Asemenea altor protocoale de rutare, acesta folose
te mesaje hello
trimise la adresa 224.0.0.13 i un proces de creare de adiacene. Aceste detalii depesc ns scopul
acestei cri i nu vor fi aprofundate
Protocoalele dense presupun n funcionarea lor c aplicaia multicast folosit este att de
popular nct exist cel puin un destinatar n fiecare subnet al ariei de transmisie. Din acest motiv
un ruter care ruleaz un protocol dense va trimite n mod implicit traficul multicast pe toate
interfeele n afar de interfaa pe care acesta a venit. Dac funcionarea dense ar fi ns limitat la
acest comportament, traficul multicast ar traversa tot Internetul. Din aceast cauz, n orice
protocol dense exist posibilitatea ca un ruter s poat refuza traficul multicast pentru un anumit
grup pentru a evita extinderea stream-ului n direcii n care acesta nu are destinatari. nainte de
detalierea acestei operaii se vor defini:
router upstream este un ruter vecin care se afl mai aproape de surs dect ruterul n
discuie;
router downstream este un ruter vecin care se afl mai departe de surs dect ruterul n
discuie.
Exist dou situaii n care un ruter multicast nu va dori traficul multicast de la un ruter
upstream.
Ruterul n discuie nu are niciun vecin downstream care s doreasc traficul multicast;
Ruterul nu cunoate nici o staie dintr-o subreea direct conectat care s doreasc traficul
multicast.
Dac ambele condiii de mai sus se aplic, ruterul va trimite un mesaj numit prune ruterului
upstream, informndu-l s nu mai trimit trafic multicast ctre el. Astfel se realizeaz o restrngere
a ariei n care stream-ul e transmis, pentru a trimite doar ctre destinaiile valide.
Comportamentul descris mai sus este comun tuturor protocoalelor dense i este respectat i de
PIM-DIM.
9.6.2 Reverse Path Forwarding Check

Chiar dac exist un mecanism n protocoale dense i implicit n PIM-DIM, prin care un ruter
poate specifica unui vecin upstream faptul c nu dorete trafic multicast, da c ntr-un graf un nod
trimite n mod implicit trafic pe toate muchiile n afar de cea pe care traficul a venit, vor aprea n
mod inevitabile bucle. Pentru a nu avea aceast problem, nainte de a trimite trafic n toate
direciile, un ruter analizeaz adresa IP surs a pachetelor multicast
i caut reeaua
corespunztoarea acelei adrese n tabela de rutare. Dac n tabela de rutare, ruterul are ca interfa
de ieire ctre adresa de reea determinat aceeai interfa pe care a primit pachetele multicast,
stream-ul este unul valid i va fi trimis pe toate interfeele n afar de cea pe care a sosit. Dac ns
ruta ctre sursa traficului este pe o interfa
diferit de interfaa pe care pachetele multicast au
venit la ruter, acesta le arunc i trimite un mesaj prune vecinului pentru a i spune s nu mai trimit
trafic pe acea legtur cci l trimite n bucl.
Figura 1-8 prezint o topologie n care mesajul prune este folosit pentru a limita transmiterea
traficului multicast n PIM-DM.
Server de Streaming
Cea mai scurt

cale de la R2
la Serverul de
Streaming
conform
protocolului
de rutare.
R1
Prune: nici un ruter

downstream sau un host
direct conectat nu
dorete trafic
S1/1
R2
Send multicast!
R3
S1/0
Prune: interfaa pe
care primesc traficul
multicast (S1/0) nu e
interfaa de ieire
ctre sursa traficului
multicast (S1/1)
No multicast
No multicast
No multicast
Figura 9-10: Mesaje prune n PIM-DM

n topologia de mai sus ruterele R2i R3 trimit mesaje de prune, ns din motive diferite. n
paii ce urmeaz se vor analiza aceste motive pentru fiecare dintre cele dou rutere:
1. Ruterul R1 primete stream-ul de la server i pentru c ruleaz PIM -DM, trimite traficul pe
toate interfeele n afar de cea pe care l-a primit.
2. Ruterul R3 primete stream-ul de la R1 i aplic testul RPF. Pentru c cea mai scurt cal e a
lui R3 ctre server este prin R1, testul este trecut cu succes. Prin urmare R3 aplic
comportamentul dense i trimite pachetele multicast spre ruterul R2, considerat
deocamdat de ctre R3, un ruter downstream.
3. Ruterul R2 primete stream-ul de la ruterul R3 i aplic testul RPF. Pentru c cea mai scurt
cale de la R2 la surs este prin ruterul R1, testul este picat. Astfel R2 trimite un mesaj de
prune ruterul R3.
4. Ruterul R3 nu este direct conectat la nicio staie care s doreasc stream-ul iar R2 tocmai a
specificat faptul c nu dorete trafic multicast de la el. Neavnd alt destinatar pentru trafic,
R3 trimite un mesaj de prune ctre R1 spunndu-i acestuia s nu mai trimit stream-ul.
5. Ca i R3, i R2 primete pachetele multicast de la R1, ns pentru c este direct conectat la o
staie care dorete acele pachete i pentru c testul RPF ctre R1 este trecut cu succes,
accept traficul.
Cnd un mesaj de tip prune este primit de ctre un ruter ce ruleaz PIM-DM, acesta i pune
interfaa n modul pruned (nu mai trimite trafic multicast)i o pstreaz astfel timp de 3 minute.
Dup acest interval ruterul scoate interfa
a din modul acest mod i ncepe s trimit din nou
multicast pe ea. Dac ruterul downstream n continuare nu are nicio destinaie creia s i trimit
multicast, acesta va trebui s trimit din nou un mesaj prune i s continue acest proces din 3 n 3
minute.
9.6.3 Source-Based Trees

Comportamentul implicit pe care PIM-DM l are n legtur cu trimiterea traficului n toate
direciile i a l restriciona mai apoi cu mesaje prune creeaz ceea ce standardul nume
te un
source-based tree sau shortest-path tree (SPT). Acest arbore definete cea mai scurt cale de la
surs ctre toate destinaiile, avnd sursa ca rdcin. Pentru fiecare grup de multicast i fiecare
surs diferit, va exista un SPT definit astfel (IP_SURS, IP_GRUP). Aceasta este notaia folosit att
n standard cti n output-ul comenzilor Cisco IOS. Ace
ti arbori sunt cu adevrat relevani n
comparaia dintre dense i sparse i vor fi detaliai ntr-un subcapitol ulterior.
9.6.4 Mesajul graft

Situaia prezentat n topologia de mai jos este o continuare a procesului din figura 1-8.
Ruterul R3 trimise un mesaj de tip prune iar R1 i setase interfaa S1/1 n modul pruned.
Server de Streaming
R1
Graft: am o destinaie
multicast. Scoate
interfaa din modul
pruned i trimite
stream-ul
S1/1
S1/1
R2
Send multicast!
R3
S1/0
Send multicast!
No multicast
No multicast
Figura 9-11: Mesajul graft n PIM-DM

Una dintre staiile direct conectate la ruterul R3 trimite un mesaj IGMP Membership Report
pentru primi trafic pentru grupul n care serverul de streaming trimite multicast. Ruterul R3
concluzioneaz astfel c exist un destinatar pentru traficul de multicast pentru care el a trimis un
mesaj de prune. Pentru ca staia din LAN s nu atepte un timp maxim de 3 minute nainte de putea
primi stream-ul, ruterul R3 trimite un mesaj de tip graft lui R1. Cnd ruterul R1 prime
te acest
mesaj, el scoate automat interfaa sa din modul pruned i ncepe s trimit trafic ct timp stream-ul
este nc activ sau pn cnd va primi iar
i un mesaj prune (ex: cazul n care staia ar t rimite un
IGMP Leave-Group).
9.6.5 PIM-SM
Protocoalele sparse sunt recomandate n standard spre a fi folosite n momentul n care
destinaiile multicast sunt localizate n puine subreele din aria geografic. PIM Sparse Mode a fost
optimizat ns de Ciscoi es te n momentul de fa
singurul protocol multicast pe care Cisco l
recomand pentru orice fel de topologie. Metodologia pe care sparse o folosete n distribuia
multicast este complet opus celei dense. Dac un ruter ce ruleaz PIM-SM primete trafic multicast
pentru un anumit grup, nu l va trimite pe niciun port pn cnd un ruter downstream sau o staie
dintr-o reea direct conectat nu va cere acest trafic. Dac n PIM-DM era nevoie de un mesaj prune
pentru a opri trimiterea traficului, n PIM-SM este nevoie de un mesaj join pentru a ncepe
trimiterea acestuia.
Starea implicit a unei interfe
e de ruter multicast sparse este not forwarding. Odat ce se
primete un mesaj join pe o interfa, aceasta n modul forwarding timp de 3 minute i trimite trafic
multicast pe acea legtur. Dup cele 3 minute join-ul va trebui realizat din nou. n protocolul real
exist optimizri pentru a nu avea un stream intermitent o dat la 3 minute.
Transmiterea de trafic multicast n modul sparse are 2 pai:
Transmiterea de trafic de la ruterul direct conectat la sursa multicast la un ruter special
numit Rendezvous Point (RP);
Transmiterea de trafic de la RP la destinaiile multicast din diferite subreele.
RP-ul este cel mai important concept din transmisia multicast sparse. Traficul multicast
transmis de la surs va fi trimis mai nti ctre RP, iar apoi RP-ul va direciona pachetele ctre
diferitele destinaii multicast. O topologie multicast sparse poate fi vzut astfel ca avnd dou
seciuni: un SPT pentru fiecare grup/surs care are ca rdcin sursa multicast i ca unic frunz RPul i un shared tree sau Root-Path Tree (RPT) prin care RP-ul trimite trafic ctre toate destinaiile
dintr-un grup sau mai multe. Acest RPT este simbolizat prin (*, IP_GRUP). Cu alte cuvinte, pentru
destinaiile finale, traficul va veni mereu prin punctul central RP indiferent de sursa multicastului.
9.6.6 Funcionarea PIM-SM: SPT i RPT

Se va presupune urmtoarea topologie:
JOIN-SP T (3)
Register - Stop(1)
Register (1)
R1
R2
R3 = RP
Server
Join (2)
Join (2)
Multicasttraffic (3)
Join (2)
R6
R4
IGMP MR (2)
S1
R5
IGMP MR(2)
S2
Figura 9-12: Crearea SPT-ului n PIM-SM
nainte ca o topologie sparse s poat funciona, toate ruterele din reea trebuie s cunoasc
cine este RP-ul. Acest lucru se poate face static, configurnd adresa RP-ului pe fiecare ruter, sau
dinamic prin protocolul Auto-RP sau Bootstrap Router(BSR). n capitolul de configurri de baz se va
prezenta configurarea static a unui RP.
Pe figura de mai sus evenimentele au fost secven
ializate folosind un numr de secven ce
urmeaz fiecrui mesaj.
Serverul direct conectat la ruterul R1 ncepe s trimit un stream pentru grupul 227.1.1.1. R1 va
reaciona imediat la aceast aciune i va ncepe s trimit mesaje Register ctre RP(R3) anunndul c exist un stream activ la care el este direct conectat. Mesajele Register sunt trimise ca unicast
ctre RP, ns n cmpul de date conin chiar pachetele de multicast ale stream-ului. RP-ul va primi
mesajul dar pentru c nu cunoate nicio destinaie valid pentru acest grup (nu a primit niciun join
pentru 227.1.1.1), l va arunca i va trimite napoi un mesaj Register-Stop prin care l va opri pe R1
din procedura de nregistrare timp de 1 minut. Dup acest interval R1 va ncepe s trimit iiar
Register.
Ct timp RP-ul refuz procedura de register, staiile S1 i S2 trimi t un mesaj de IGMP
Membership Report pentru grupul 227.1.1.1. R6 i R4 reacioneaz trimind un mesaj join ctre RP.
Odat cu primirea unui mesaj de join pentru grupul 227.0.0.1, RP-ul nu va mai trimite Register-Stop
ctre R1, iar la urmtorul mesaj Register, va extrage pachetul multicast din cel unicast i l va trimite
pe interfaa ctre R4. n acelai timp va ncepe procedura de nregistrare la SPT pentru a crea un
drum multicast end-to-end. Cu alte cuvinte RP-ul va ncepe s trimit mesaje join ctre R1 pentru ca
acesta din urm s poat s trimit direct stream-ul multicast (fr a l ncapsula n unicast). Acest
ultim pas este necesar din cauza regulii de baz din modul sparse: un ruter nu poate trimite
multicast dect dac acesta e cerut printr-un mesaj join.
Astfel se creeaz doi arbori ce compun topologia multicast sparse. Arborele de la surs la RP
este un SPT pentru c este diferit func
ie de locaia sursei. Arborele de la RP la destinaii este un
RPT pentru c este partajat de mai multe grupuri care folosesc acelai ruter ca RP.
9.6.7 Optimizarea PIM-SM: SPT switchover

n continuarea scenariului din figura 1-12 se va aduga o legtur ntre ruterele R1 i R6.
R1
R2
R3 = RP
Server
R6
R4
R5
S1
S2
Figura 9-13: SPT Switchover
Traficul multicast este transmis acum de la R1 ctre RP pe un Shortest-Path Tree, iar apoi de la
RP la staiile S1 i S2 pe un Root-Path Tree. Pentru a ajunge de la R1 la R6, pachetele multicast
trebuie s treac prin 6 hopuri. n PIM-SM, comportamentul RP-ului de a putea face join pe un SPT
este posibil pe orice ruter. n cazul acesta, R6 se va uita n tabela de rutarei va vedea c ruta prin
R1 este mult mai bun dect ruta care l duce prin RPT cu vecinul R5. El va trimite un mesaj de join
ctre R1 i se va nregistra la un SPT care s aduc traficul multicast doar peste un hop. Procedura
va funciona ns acum R6 va primi pachete multicast att prin SPT ct i prin RPT. Pentru a folosi
doar SPT-ul, R6 va trimite un mesaj prune ctre RP spunndu-i c nu mai dorete pachete pentru
grupul 227.1.1.1 de la sursa IP_Server. Pentru c R4 nc face join pe acest grup, RP va continua s
trimit trafic pe interfaa sa ctre R4, ns R5 va vedea mesajul prune de la R6 i va face i el prune
astfel nct traficul prin RPT va ajunge doar la R4.
Aceast optimizare este de fapt motivul pentru care Cisco recomand PIM-SM pentru orice fel
de topologie. Dac exista 100 de surse grupate n pu
ine subreele i nc 10 ce se afl n direcia
diametral opus, se va plasa RP-ul aproape de cele 100, iar celelalte sta
ii vor face switchover pe
SPT-ul ctre sursa multicast. Astfel nu mai conteaz iile
dac sunt
destina
sau nu
dispersate/grupate, algoritmul va func
iona ntotdeauna optim ct timp ct RP -ul este selectat
eficient.
9.7 Configurri de baz

n protocoalele multicast partea teoretic ce presupune
elegerea
n conceptelor este
ntotdeauna mult mai complex dect cea de configurare. Activarea protocoalelor PIM sau IGMP se
face dintr-o singur comand, urmnd ca implementarea din spatele protocolului s preia toat
munca de funcionare.
Pentru a activa PIM n dense-mode se va folosi comanda din modul interfa:
(config-if)# ip pim dense-mode
n cazul sparse-mode, pe lng activare, trebuie specificati identitate a (adresa IP) RP-ului.
Acest lucru poate fi configurat static sau dinamic prin Auto-RP sau BSR. Setarea dinamic a RP-ului
depete ns scopurile acestei cri, un scurt exemplu fiind dat doar n capitolul de studiu de caz.
Pentru configurarea PIM sparse-mode n mod static se folosesc comenzile:
(config)# ip pim rp-address <ip_address>
(config-if)# ip pim sparse-mode
Un ruter Cisco are inclus n sistemul de operare posibilitatea de a se comporta ca i un client de

multicast. Pentru a face acest lucru trebuie configurat IGMP la nivel de interfa:
(config-if)#ip igmp join-group 225.1.1.1
Odat cu aplicarea acestei comenzi ruterul va ncepe s trimit mesaje de Membership Report
sau Membership Leave i va putea s fac parte din grupul de multicast 225.1.1.1.
Atenie! Pentru ca ruterul vecin s poat rspunde la cereri IGMP din partea clientului,
acesta trebuie s aib PIM activat pe respectiva interfa.
n contextul optimizrii multicast n reeaua local, IGMP snooping ofer posibilitatea activrii
pe un VLAN specific al acestei funcionaliti:
(config)# ip igmp snooping [vlan x]
Un protocol de rutare multicast determin pe ce interfe

e s trimit copii ale pachetelor
multicast primite. Toate informaiile necesare pentru a ruta pachetele multicast sunt re inute n
tabela multicast care mai este numiti tabela de rutare multicast. Aceste informaii pot fi afiate
folosind comanda show ip mroute.
Sintaxa comenzii este:
show ip mroute [group-name | group-address] [source] [summary]
[count] [active kbps]
n continuare se vor urmri exemple de output ale acestei comenzi pe care se vor discuta
diferiii parametrii.
Router# show ip mroute 233.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set
Timers: Uptime/Expires
Interface state: Interface, Next-Hop, State/Mode
(*, 233.1.1.1), uptime 0:57:31, expires 0:02:59, RP is 0.0.0.0,
flags: DC
Incoming interface: Null, RPF neighbor 0.0.0.0
Outgoing interface list:
Ethernet0, Forward/Dense, 0:57:31/0:02:52
FastEthernet1, Forward/Dense, 0:56:55/0:01:28
FastEthernet2, Forward/Dense, 0:56:45/0:01:22
(172.16.16.1/32, 233.1.1.1), uptime 20:20:00, expires 0:02:55,
flags: C
Incoming interface: FastEthernet1, RPF neighbor 10.20.30.1
Ethernet0, Forward/Dense, 20:20:00/0:02:52
Pentru comanda de mai sus se vor descrie mai nti parametrii, iar apoi interpretarea pentru
tabela de rutare multicast.
9.7.1 Parametrii
Flag-uri:
D Dense: Intrarea opereaz n modul dense;
S Sparse: Intrarea opereaz n modul sparse;
C Connected: Un membru al grupului multicast este prezent pe o interfa direct
conectat; Un calculator se conecteaz folosind mesaje IGMP.
L Local: Un ruter este membru al unui grup multicast;
P Pruned: O rut a fost trecut n starea pruned. Cisco IOS pstreaz aceast informaie n
cazul n care un membru downstream dorete s se alture sursei.
R-RP-bit setat: Intrarea (S,G) indic ctre Rendevous Point (RP). RP este de obicei o stare
pruned in interiorul arborelui pentru o surs.
F Register : Indic faptul c are loc o nregistrare pentru surs multicast.
T SPT-bit setat: Pachetele au ajuns pe drumul cel mai scurt.
H Hardware stwitched: Interfaa de ieire este Hardware Switched datorita IP multicast
MLS.
Timers: sunt de forma Uptime/Expires.
Interface state: indic starea interfeelor de intrare i de ieire:
Interface: tipul i numrul interfeei de intrare/ieire.
Next-hop sau VCD. Next-hop specific adresa IP a vecinului. VCD specific numrul unui
circuit virtual.
State/Mode. State: pachetele sau de tip prune sau null vor fi forwardate pe o interfa
dac sunt restricii printr-o list de acces sau o limit TTL. Mode precizeaz dac o
interfa opereaz n modul dense, sparse sau sparse-dense.
Intrri n tabela multicast:
(*,224.0.255.1), (198.92.37.100/32, 224.0.255.1): intrri in tabela de rutare multicast.
Intrarea const n adresa IP a ruterului surs urmat de adresa IP a grupului multicast. Un
asterisc (*) n locul ruterului surs indic toate sursele. Intrrile sunt de forma (S,G).
Uptime: de cat timp (o:m:s) intrarea se afl n tabela de rutare multicast.
Expires: n cat timp (o:m:s) intrarea va fi eliminat din tabela de rutare multicast de pe
interfaa de ieire.
RP: adresa ruterului rendevous point. Pentru rutere care opereaz n sparse mode,
aceast adres va fi 0.0.0.0 .
Income interface: interfaa pe care se ateapt un pachet de la surs. Dac pachetul este
primit pe alt interfa, acesta este ignorat.
RPF neighbor: adresa IP a ruterului ctre surs. Tunneling indic faptul c acest ruter
trimite date la RP ncapsulate n pachete Register. Numrul hexa din paranteze indic cu ce
RP se nregistreaz.
Dvmrp sau Mroute: indic dac informaia RPF a fost obinut de la tabela de rutare DVMRP
sau prin rute configurate static mroute.
Outgoing interface list: Interfeele pe care vor fi trimise pachetele.
Next hop sau VCD: specific adresa IP a urmtorului ruter spre asculttori. VCD este
numrul circuitului virtual.
Forward / (Dense sau Sparse): indic faptul c pachetele vor fi trimise pe interfaa de ieire
dac nu sunt restricii datorate listelor de acces sau limitrilor TTL. Dup slash (/) se afl
modul n care interfaa opereaz (sparse sau dense).
9.7.2 Interpretarea tabelei mroute

Intrarea care ncepe cu (*, 233.1.1.1) este o intrare din arborele multicast partajat. Mai este
referit i ca (*,G). n cazul nostru, G este 233.1.1.1 adresa grupului. PIM-DM nu folosete aceste
intrri pentru a comuta pachete ci doar listeaz interfeele cu rol n multicast (primesc informa ii
prin IGMP sau sunt vecini PIM) ca interfee de ieire.
Intrarea care ncepe cu (172.16.16.1, 233.1.1.1) este referit ca o intrare (S,G). S este sursa iar G
este grupul multicast. Aceast intrare este un arbore multicast cu surs specific pentru un anumit
grup multicast. Comanda va afia cte o astfel de intrare pentru fiecare surs i grup.
Se va observa faptul c urmtorul hop folosit n rutarea unicast apare ca vecinul RPF (Reverse
Path Forwarding) i interfaa de intrare apare ca interfa RPF. Aceast interfa (FastEthernet1) i
urmtorul hop (10.20.30.1) sunt folosite de procesul de rutare pentru a trimite un pachet ctre
surs (172.16.16.1).
Interfeele de ieire (n cazul nostru doar Ethernet0) indic faptul c orice pachet venit de la
sursa 172.16.16.1, cu o adres destina
ie mu lticast 233.1.1.1i neap rat venite pe interfa
a
FastEthernet1 a ruterului va fi trimis ctre Ethernet0 .
9.8 Studiu de caz

n studiul de caz ce urmeaz se va analiza opera
ia realizat de un cercettor tiinific ce
dorete s nregistreze statistici pe baza transferurilor multicast. nainte de putea msura ns
performane i compara coeficieni de ncrcare a reelei, cercettorul trebuie s configureze
reeaua pentru transmisii multicast. Administratorul de reea al companiei n care se face acest
proiect i-a oferit cercettorului oea
re IPv4 peste care ruleaz EIGRP. Urmeaz realizarea
implementrii multicast peste aceast reea.
R1
F0/0
Fa0/
R3
R5
Fa0/0
S1/1
F0/0
R2
S1/2
S1/1
S1/0
S1/2
F0/0
S1/0
R6
F0/0
R4
Figura 9-14: Studiu de caz
9.8.1 Configurarea PIM-DM

Mai nti se dorete configurarea ntr -un protocol dense mode. Alegerea fcut de cercettor
este protocolul PIM-DM. Folosind aceast opiune el trebuie s trimit trafic multicast de la sursa R1
pn la destinaiile R5 i R6. Aceste dou rutere din urm vor simula clien
i de multicast pentru
diferite grupuri folosind comanda ip igmp join-group.
Se va ncepe cu configurarea PIM-DM pe segmentele R2-R3, R2-R4, R3-R4 i pe interfeele
Fa0/0 ale ruterelor R2, R3, R4. Interfe
ele F0/0 specificate trebuie activate n PIM pentru a putea
realiza schimburi de mesaje cu clienii multicast R5 i R6. Dei este uor neintuitiv activarea PIM pe
o interfa pentru a putea schimba mesaje IGMP, acesta este modul n care IP Multicast a fost
implementat n Cisco IOS.
R2(config)# ip multicast-routing
R2(config)# int Serial1/1
R2(config-if)# ip pim dense-mode
R2(config-if)# int Serial1/0
R2(config-if)# int Fa0/0
n continuare se va configura R6 pentru a primi trafic multicast pentru grupul 225.1.1.1.
R6(config)#int fa0/0
R6(config-if)#ip igmp join-group 225.1.1.1
Acum c infrastructura este pregtit pentru transmisia multicast n modul dense, cercettorul
va simula transferul de date pentru grupul 225.1.1.1 folosind un ping extins.
R1#ping
Protocol [ip]:
Target IP address: 225.1.1.1
Repeat count [1]: 5
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
request
request
request
request
request
0
1
2
3
4
from
from
from
from
from
10.1.46.6,
10.1.46.6,
10.1.46.6,
10.1.46.6,
10.1.46.6,
600
124
112
176
164
ms
ms
ms
ms
ms
Se poate observa faptul c stream-ul a fost transmis cu succes. Analiznd output-ul comenzii
show ip mroute pe ruterele din topologie, cercettorul dore
te s descopere drumul pe care
pachetele de multicast l-au urmat n reea.
Pe ruterul R2 se poate observa cum interfa
a serial 1/0 a fost pus n modul prune. Motivul
pentru acest rezultat este comportamentul implicit al protocolului PIM-DM de a trimite trafic pe
toate interfeele. Cnd ruterul R3 a primit trafic multicast pentru grupul 225.1.1.1, pentru c nu
exist nicio staie direct conectat care s doreasc traficul i niciun ruter downstream care s cear
trafic, acesta a trimis un mesaj un mesaj de prune vecinului su, R2.
R2#sh ip mroute
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 225.1.1.1), 00:06:06/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Serial1/0, Forward/Dense, 00:02:54/00:00:00
(10.1.12.1, 225.1.1.1), 00:02:09/00:01:01, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Serial1/1, Prune/Dense, 00:02:08/00:00:51
Pe ruterul R3, interfa

a Serial1/2 a fost pus n modul pruned ns dintr-un motiv complet
diferit fa de exemplul precedent. Cnd ruterul R3 a primit pentru prima oar trafic multicast de la
R2 a respectat comportamentul dense trimind traficul pe toate interfeele sale. Astfel traficul
multicast pentru 225.1.1.1 a ajuns de la R3 la R4. Cnd R4 a primit acest trafic, i-a aplicat testul RPF.
Pentru c acest test a fost picat (calea cea mai scurt de la R4 la surs este prin R2, nu prin R3)
ruterul R4 i-a trimis un mesaj de prune lui R3 specificndu-i oprirea stream-ului. n acel moment, R3
a neles c nu exist nimeni downstream care s doreasc traficul trimis de el i a luat dou aciuni:
A introdus interfaa sa Serial1/2 n modul pruned;
A trimis mesajul prune menionat n exemplul de mai sus ctre R2 spunndu-i acestuia s nu
mai trimit trafic.
R3#sh ip mroute
Advertisement,
(*, 225.1.1.1), 00:01:10/stopped, RP 0.0.0.0, flags: D
(10.1.12.1, 225.1.1.1), 00:01:10/00:02:02, flags: PT
Incoming interface: Serial1/1, RPF nbr 10.1.23.2
Serial1/2, Prune/Dense, 00:01:10/00:01:53
Se va realiza acum ataarea ruterului R5 ca i destinatar pentru grupul 225.1.1.1:

R5(config)#int fa0/0
R5(config-if)#ip igmp join-group 225.1.1.1
Se pot observa schimbrile din output-ul comenzilor sh ip mroute: ruterul R3 nu mai are
interfaa ctre R2 n modul pruned deoarece are un destinatar valid; cu toate acestea, interfa
a
dinspre R4 este n continuare n modul pruned deoarece drumul ce se formeaz prin link-ul R3-R4
are un cost ineficient i pica testul RPF att pe R3 ct i pe R4.
R3#sh ip mr
Advertisement,
(*, 225.1.1.1), 00:03:59/stopped, RP 0.0.0.0, flags: DC
FastEthernet0/0, Forward/Dense, 00:00:35/00:00:00
(10.1.12.1, 225.1.1.1), 00:00:23/00:02:54, flags: T
Serial1/2, Prune/Dense, 00:00:23/00:02:39, A
FastEthernet0/0, Forward/Dense, 00:00:23/00:00:00
9.8.2 Configurarea PIM-SM

Dup realizarea msurtorilor pentru PIM-DM, cercettorul n cauz a trecut la analiza unui
protocol sparse. Deoarece comportamentul de realizare a arborilor de acoperire multicast este
diferit n cele dou cazuri era clar nevoia configurrii unei infrastructuri PIM-SM pentru ca testele
de performan s fie relevante.
Pentru nceput, toate interfeele sunt trecute din PIM dense n PIM sparse folosind comanda ip
pim sparse-mode. Pentru a crea o topologie pe care comportamentul SPT Switchover s poat fi
uor observabil, cercettorul a nchis temporar interfaa dintre R2 i R4. De asemenea R3 a fost ales
pentru rolul de RP din reea. Configurarea acestuia va fi fcut static pe toate dispozitivele din reea
folosind ca i adres de RP, o adres a unui loopback a lui R3. Se va folosi adresa de loopback ca RP
deoarece aceasta este o interfa
virtual permanent activ. Prima regul a transmiterii de
multicast este ns conectivitatea end-to-end IPv4, astfel c cercettorul este obligat s introduc
reeaua de loopback n protocolul EIGRP.
! configurarea loopback-ului
R3#conf t
R3(config)#int lo0
R3(config-if)#ip add
*Mar 1 00:45:07.395: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Loopback0, changed state to up
R3(config-if)#ip address 150.1.1.1 255.255.255.0
R3(config-if)#exit
R3(config-router)#net
! schimbarea din dense-mode n sparse mode; aceast schimbare trebuie

! fcut inclusiv pe R2 i R3 chiar dac acest lucru este omis din
! exemplu
R4(config)#int serial 1/0
R4(config-if)#ip pim sparse-mode
R4(config-if)#int ser1/2
R4(config-if)#ip pim sparse- mode
R4(config-if)#int fa0/0
R4(config-if)#ip pim sparse- mode
! configurarea static a adresei RP-ului

R2(config)#ip pim rp-address 150.1.1.1
Dup cum se observ mai sus, configurarea RP-ului trebuie fcut inclusiv pe RP pentru ca
sparse-mode s funcioneze. Deoarece se folosete PIM -SM, o interfa nu va mai aprea ca fiind
pruned n tabela de rutare multicast, ci puri simplu nu va mai aprea dac nu se primete nici un
mesaj de join-tree.
R3#sh ip mroute
Advertisement,
(*, 225.1.1.1), 00:21:14/00:03:18, RP 150.1.1.1, flags: SJC
FastEthernet0/0, Forward/Sparse, 00:17:50/00:02:49
Serial1/1, Forward/Sparse, 00:21:14/00:00:00
(10.1.12.1, 225.1.1.1), 00:00:36/00:02:37, flags: T
Pentru a analiza opera

ia de SPT Switchover care este ultimul concept pe care cercettorul
dorete s l testeze, se va analiza mai nti comanda sh ip mroute pe ruterul R4.
R4#sh ip mroute
Advertisement,
(*, 225.1.1.1), 00:51:23/stopped, RP 150.1.1.1, flags: SJC
(10.1.12.1, 225.1.1.1), 00:00:06/00:02:55, flags: JT
Se poate observa din adresa de RPF a vecinului (RPF nbr 10.1.34.3) faptul c tot traficul
multicast trece de la R4 la R3i invers. n acest moment se va da no shutdown pe legtura dintre
R2 i R4 unde EIGRP este deja pornit. PIM -SM va folosi metricile EIGRP pentru ai da seama c
drumul prin R2 este mai bun acum dect drumul prin R3. Astfel va trimite prune ctre arborele
shared i se va ataa unui arbore SPT cu sursa de multicast ca rdcin.
R4#sh ip mroute
Advertisement,
(*, 225.1.1.1), 00:46:10/stopped, RP 150.1.1.1, flags: SJC
(10.1.12.1, 225.1.1.1), 00:00:13/00:02:57, flags: JT
Cuprins
1
Arhitectura unui ruter ................................................................................................................... 1
1.1
Componentele unui ruter...................................................................................................... 1
1.1.1
Memoriile unui ruter ..................................................................................................... 2
1.1.2
Interfeele unui ruter .................................................................................................... 3
1.1.3
Procesul de iniializare al unui ruter ............................................................................. 4
1.2
Sistemul de operare .............................................................................................................. 5
1.2.1
Moduri de configurare .................................................................................................. 5
1.2.2
Sistemul de fiiere ......................................................................................................... 6
1.3
Configuraii de baz .............................................................................................................. 6
1.3.1
Protejarea accesului la ruter ......................................................................................... 8
1.3.2
Configurarea unei interfee......................................................................................... 11
1.3.3
Verificarea configuraiilor de baz .............................................................................. 14
1.3.4
Faciliti ale liniei de comand .................................................................................... 17
2 Funciile unui ruter ...................................................................................................................... 21
2.1
Rutarea ................................................................................................................................ 21
2.1.1
Tabela de rutare .......................................................................................................... 22
2.1.2
Rutarea static ............................................................................................................ 23
2.1.3
Protocoale de rutare ................................................................................................... 24
2.2
RIP........................................................................................................................................ 27
2.2.1
Descrierea protocolului ............................................................................................... 27
2.2.2
Configurarea protocolului ........................................................................................... 28
2.2.3
Caracteristici ale protocoalelor distance-vector ......................................................... 30
2.2.4
RIPv2 ............................................................................................................................ 31
2.3
Liste de acces (ACLs)............................................................................................................ 32
2.3.1
Modul de funcionare a listelor de acces .................................................................... 33
2.3.2
Tipuri de liste de acces ................................................................................................ 34
2.3.3
Configurarea listelor de acces standard ...................................................................... 34
2.3.4
Configurarea listelor de acces extinse......................................................................... 35
2.3.5
Configurarea listelor de acces cu nume ...................................................................... 36
2.3.6
Ordonarea i documentarea listelor de acces............................................................. 37
2.4
Translatarea de adrese ........................................................................................................ 38
2.4.1
Adrese publice i private ............................................................................................. 38
2.4.2
Prezentarea conceptelor ............................................................................................. 38
2.4.3
Configurarea NAT ........................................................................................................ 40
2.4.4
Configurare PAT .......................................................................................................... 41
2.4.5
Port forwarding ........................................................................................................... 42
3 IPv6 .............................................................................................................................................. 43
3.1
Protocolul IPv6 .................................................................................................................... 44
3.1.1
Antetul IPv6 ................................................................................................................. 44
3.1.2
Reprezentarea adreselor IPv6 ..................................................................................... 45
3.1.3
Structura adreselor IPv6 .............................................................................................. 46
3.1.4
Network Discovery Protocol........................................................................................ 48
ii | P r o i e c t a r e a r e e l e l o r
3.2
Implementarea IPv6 ............................................................................................................ 50
3.2.1
Rutarea IPv6 ................................................................................................................ 50
3.2.2
Interconectarea reelelor IPv4 cu reele IPv6 ............................................................. 50
3.3
Configurarea IPv6 ................................................................................................................ 53
3.3.1
Configurarea adresrii ................................................................................................. 53
3.3.2
Configurri de rutare ................................................................................................... 54
3.3.3
Configurri de interconectare IPv4-IPv6 ..................................................................... 55
3.4
Studiu de caz........................................................................................................................ 56
4 EIGRP ........................................................................................................................................... 59
4.1
Prezentarea protocolului ..................................................................................................... 59
4.1.1
Caracteristici ale EIGRP................................................................................................ 59
4.1.2
Descoperirea vecinilor EIGRP ...................................................................................... 60
4.1.3
Calculul metricii EIGRP................................................................................................. 60
4.1.4
Maina de stri finite DUAL ......................................................................................... 61
4.1.5
Tabelele EIGRP ............................................................................................................. 62
4.1.6
Formatul pachetelor EIGRP ......................................................................................... 63
4.2
Concepte avansate .............................................................................................................. 64
4.2.1
Sumarizarea rutelor ..................................................................................................... 64
4.2.2
Echilibrarea traficului .................................................................................................. 64
4.2.3
Scalabilitatea EIGRP n reele mari .............................................................................. 64
4.2.4
EIGRP Queries .............................................................................................................. 65
4.2.5
EIGRP Stub ................................................................................................................... 65
4.2.6
Autentificarea EIGRP ................................................................................................... 65
4.3
Configurarea protocolului ................................................................................................... 66
4.3.1
Configurri de baz...................................................................................................... 66
4.3.2
Propagarea rutei implicite ........................................................................................... 68
4.3.3
Verificarea funcionrii EIGRP ..................................................................................... 68
4.3.4
Configurarea sumarizrii ............................................................................................. 72
4.3.5
Configurarea balansrii traficului ................................................................................ 73
4.3.6
Configurarea ruterului stub ......................................................................................... 74
4.3.7
Configurarea autentificrii .......................................................................................... 75
4.4
Studiu de caz........................................................................................................................ 78
4.4.1
Configurri de baz...................................................................................................... 79
4.4.2
Optimizarea timpilor de convergen folosind DUAL ................................................. 80
4.4.3
Optimizarea timpilor de convergen folosind reele Stub ......................................... 82
4.4.4
Minimizarea dimensiunii tabelei de rutare ................................................................. 82
5 OSPF............................................................................................................................................. 85
5.1
Prezentarea protocolului ..................................................................................................... 85
5.1.1
Link state vs. distance vector....................................................................................... 85
5.1.2
Funcionarea protocolului ........................................................................................... 87
5.1.3
Tabelele OSPF .............................................................................................................. 90
5.1.4
Formatul pachetelor OSPF........................................................................................... 91
5.1.5
OSPF Multi-area........................................................................................................... 92
5.1.6
Tipuri de LSA ................................................................................................................ 94
5.2
Concepte avansate .............................................................................................................. 96
iii | C u p r i n s
5.2.1
Tipuri de zone .............................................................................................................. 96
5.2.2
Sumarizarea rutelor..................................................................................................... 99
5.2.3
Autentificarea n OSPF................................................................................................. 99
5.2.4
Legturi virtuale .......................................................................................................... 99
5.3
Configurarea protocolului ................................................................................................. 100
5.3.1
Configurri de baz ................................................................................................... 100
5.3.2
Verificarea funcionrii OSPF .................................................................................... 102
5.3.3
Configurarea unei zone Stub ..................................................................................... 104
5.3.4
Configurare zon Totally Stubby ............................................................................... 105
5.3.5
Configurare zon Not So Stubby ............................................................................... 106
5.3.6
Configurarea sumarizrii ........................................................................................... 107
5.3.7
Configurarea autentificrii ........................................................................................ 109
5.3.8
Configurarea legturilor virtuale ............................................................................... 112
5.4
Studiu de caz ..................................................................................................................... 114
5.4.1
Topologie ................................................................................................................... 114
5.4.2
Configurri OSPF Single-area..................................................................................... 115
5.4.3
Configurare OSPF Multi-area .................................................................................... 121
6 IS-IS ............................................................................................................................................ 131
6.1
Componentele protocolului .............................................................................................. 131
6.1.1
ISO vs. IETF ................................................................................................................ 131
6.1.2
Rutarea cu IS-IS.......................................................................................................... 131
6.1.3
IS-IS vs. OSPF ............................................................................................................. 132
6.1.4
Adresarea ISO ............................................................................................................ 134
6.2
Funcionarea IS-IS.............................................................................................................. 135
6.2.1
Mesaje ....................................................................................................................... 135
6.2.2
Adiacene .................................................................................................................. 136
6.2.3
Backbone L2 .............................................................................................................. 137
6.2.4
Funcionare L1 ........................................................................................................... 137
6.2.5
Funcionarea L12 ....................................................................................................... 138
6.3
6.3.1
Comenzi de verificare ................................................................................................ 140
6.4
Studiu de caz ..................................................................................................................... 142
6.4.1
Configurri de baz ................................................................................................... 143
6.4.2
Controlul procesului de alegere DIS .......................................................................... 145
6.4.3
Alterarea metricilor ................................................................................................... 147
6.4.4
Autentificarea n IS-IS ................................................................................................ 147
7 Optimizarea rutrii .................................................................................................................... 149
7.1
Redistribuia ntre multiple protocoale de rutare............................................................. 149
7.1.1
Conceptul de redistribuie ........................................................................................ 150
7.1.2
Problema rutrii suboptimale ................................................................................... 151
7.1.3
Bucle de rutare .......................................................................................................... 154
7.2
Manipularea rutrii ........................................................................................................... 154
7.2.1
Manipularea update-urilor de rutare ........................................................................ 154
7.2.2
Policy-based routing .................................................................................................. 157
7.3
Configurri n optimizarea rutrii ...................................................................................... 159
iv | P r o i e c t a r e a r e e l e l o r
7.3.1
Configurarea redistribuirii ntre protocoale de rutare .............................................. 159
7.3.2
Configurarea filtrrii rutelor ...................................................................................... 161
7.3.3
Configurarea PBR ....................................................................................................... 161
7.4
Studiu de caz...................................................................................................................... 162
7.4.1
Configurri iniiale ..................................................................................................... 163
7.4.2
Redistribuirea protocoalelor de rutare ..................................................................... 165
7.4.3
Probleme la redistribuie........................................................................................... 166
7.4.4
Policy Based Routing ................................................................................................. 167
8 BGP ............................................................................................................................................ 169
8.1
Protocolul BGP................................................................................................................... 169
8.1.1
Sisteme autonome..................................................................................................... 169
8.1.2
Cnd este necesar BGP? ............................................................................................ 170
8.1.3
BGP - noiuni de baz ................................................................................................ 170
8.1.4
iBGP vs eBGP. ............................................................................................................ 171
8.1.5
Next-hop .................................................................................................................... 172
8.1.6
Tabele BGP................................................................................................................. 173
8.2
Implementarea politicilor BGP .......................................................................................... 173
8.2.1
Atribute BGP .............................................................................................................. 173
8.2.2
Procesul de decizie BGP............................................................................................. 176
8.2.3
Scalarea BGP .............................................................................................................. 177
8.3
8.3.1
Configurarea adiacenelor BGP ................................................................................. 178
8.3.2
Configurarea adiacenelor eBGP ............................................................................... 180
8.3.3
Configurarea politicilor BGP ...................................................................................... 182
8.3.4
Interpretarea tabelelor de topologie BGP ................................................................. 183
8.4
Studiu de caz...................................................................................................................... 183
8.4.1
Configuraii de baz ................................................................................................... 184
8.4.2
Manipularea atributelor BGP .................................................................................... 189
9 IP Multicast ................................................................................................................................ 193
9.1
De ce avem nevoie de multicast ? ..................................................................................... 193
9.2
Funcionarea multicast ...................................................................................................... 194
9.3
Adresarea multicast........................................................................................................... 196
9.3.1
Structura adreselor multicast .................................................................................... 196
9.3.2
Maparea adreselor multicast IP la adrese MAC ........................................................ 197
9.4
Gestiunea grupurilor multicast n LAN .............................................................................. 198
9.4.1
IGMP v2 ..................................................................................................................... 198
9.4.2
Antetul IGMPv2 ......................................................................................................... 198
9.4.3
nregistrarea la un grup de multicast ........................................................................ 199
9.4.4
Prsirea unui grup de multicast ............................................................................... 202
9.5
Optimizri ale transmiterii multicast n LAN ..................................................................... 203
9.5.1
Cisco Group Management Protocol .......................................................................... 204
9.5.2
IGMP Snooping .......................................................................................................... 204
9.6
Rutarea multicast .............................................................................................................. 205
9.6.1
PIM-DM ..................................................................................................................... 205
9.6.2
Reverse Path Forwarding Check ................................................................................ 206
9.6.3
Source-Based Trees ................................................................................................... 207
v|Cuprins
9.6.4
Mesajul graft ............................................................................................................. 208
9.6.5
PIM-SM ...................................................................................................................... 208
9.6.6
Funcionarea PIM-SM: SPT i RPT ............................................................................. 209
9.6.7
Optimizarea PIM-SM: SPT switchover....................................................................... 210
9.7
Configurri de baz ........................................................................................................... 211
9.7.1
Parametrii .................................................................................................................. 212
9.7.2
Interpretarea tabelei mroute .................................................................................... 213
9.8
Studiu de caz ..................................................................................................................... 213
9.8.1
Configurarea PIM-DM ............................................................................................... 214
9.8.2
Configurarea PIM-SM ................................................................................................ 217

2009 Carte PR PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

2009 Carte PR PDF

Încărcat de

Drepturi de autor:

Formate disponibile

1 A rhite ctura unui rute r

1.1 Componentele unui ruter

1.1.1 Memoriile unui ruter

1.1.1.2 Memoria ROM

1.1.1.3 Memoria Flash

3|Arhitectura unui ruter

1.1.1.4 Memoria NVRAM

1.1.2 Interfeele unui ruter

1.1.2.2 Interfeele de reea

1.1.3 Procesul de iniializare al unui ruter

5|Arhitectura unui ruter

1.2 Sistemul de operare

1.2.1 Moduri de configurare

n exemplul de mai sus se observ c intrarea n modul de configurare este reflectat n

End with CNTL/Z.

1.2.2 Sistemul de fiiere

1.3 Configuraii de baz

7|Arhitectura unui ruter

End with CNTL/Z.

n practic se folosete NTP (Network Time Protocol) pentru setarea ceasului.

Marketing#copy running-config startup-config

Aceeai comand realizeaz i copierea comenzilor din startup-config n running-config, cu

1.3.1 Protejarea accesului la ruter

1.3.1.1 Protejarea modului privilegiat

9|Arhitectura unui ruter

1.3.1.2 Protejarea liniilor de acces la ruter

End with CNTL/Z.

1.3.1.3 Configurarea mesajelor de ntmpinare

1.3.2 Configurarea unei interfee

Asignarea unei adrese IPv4 unei interfe

1.3.2.1 Protocolul CDP

1.3.2.2 Interfee de loopback

Interfeele loopback nu necesit activarea prin comanda no shutdown.

1.3.3 Verificarea configuraiilor de baz

Exemplu show ip interface serial 1/0:

Tabelul returnat listeaz toate interfe

1.3.4 Faciliti ale liniei de comand

Afiarea comenzilor permise este posibil n orice moment, chiar

Authentication, Authorization and

Comportamentul este similar cu cel al utilitarului more din Linux.

EXEC process creation banner

End with CNTL/Z.

Comanda anterioar creeaz un alias al comenzii show ip interface brief, denumit s,

2 Func ii le unui rute r

2.1.1 Tabela de rutare

221.54.2.0/24 [1/0] via 10.0.0.1

2.1.2 Rutarea static

Figura 2-1: Rutarea ntre reele direct conectate

Tabela de rutare a ruterului R1 afieaz acum:

10.0.0.0/24 is subnetted, 1 subnets

2.1.3 Protocoale de rutare

2.1.3.1 Parametrii rutelor

Exemplul de mai sus este al unei rute nv

2.1.3.2 Clasificarea protocoalelor de rutare

RIP Update: 10.0.0.0/8

Figura 2-3: Update RIP

2.2.2 Configurarea protocolului

Comand network are dou efecte distincte:

100.0.0.0/24 is subnetted, 1 subnets

2.2.3 Caracteristici ale protocoalelor distance-vector

2.2.3.1 Holddown timers

2.2.3.2 Split horizon

2.2.3.3 Route poisoning