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 operareintroducerea comenzilor de configurare. i 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 lor respectiv, modulul instalat pe ruter i, 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 interfaserial (2) a celui de -al doilea modul (1). Identificatorii numerici sunt consecutivi la nivel de modul interfa. Denumirile de interfee n i aceste forme sunt utilizate att n rezultatele comenzilor de interogare ct n construcia i 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
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).
1

4|Proiectarea reelelor 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 situa n care nu este gsit o imagine valid n Flash. ncrcarea imaginii ia 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 interfe ele 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 de pe un server ie 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.

5|Arhitectura unui ruter 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, securitate monitorizare, precum i o variet ate de servicii ce determin i 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 pot include: protocoale, algorit ile mi de criptare, suport pentru anumite tipuri de interfe etc. Sistemele de operare sunt mapate pe e, 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 interfe Ethernet, iar alt set va putea fi accesat n modul e 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 cea mai recent versiune a Cisco IOS este denumit i, 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.

6|Proiectarea reelelor 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 configuracurent. Pentru modificarea fiierului de ia 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 i modul te 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):
Router#configure terminal 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. De numele are semnificaie exclusiv local, pstrarea numelor implicite pe toate i

Pentru rapiditate se poate folosi i combinaia de taste CTRL-Z, echivalent comenzii end.

7|Arhitectura unui ruter echipamentele poate crea ambiguit chiar i ntr -o reea form at din cteva rutere. Schimbarea i numelui ruterului se face din modul global de configurare, prin comanda hostname:
Router#configure terminal Enter configuration commands, one per line. Router(config)#hostname Marketing Marketing(config)# End with CNTL/Z.

Un alt exemplu l reprezint setarea datei orei ceasului intern al ruterului, utile n principal i pentru identificarea momentelor de timp ale diverselor evenimente, att n timp real ct i 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 secven elor de comenzi dintr -un fi ier 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.

8|Proiectarea reelelor 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:
Marketing#copy running-config startup-config Destination filename [startup-config]? Building configuration... [OK] Marketing# show

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 Comenzile multiple ce nu pot coexista (spre ii. 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 situa de mai sus, se poate folosi comanda configure replace nvram:, ia 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 poatese ( i fi 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 fi de configuraie, fiind ierul vizibile la o simpl afiare a acestuia:
Marketing(config)#enable password cisco Marketing(config)#exit Marketing#show running-config Building configuration... Current configuration : 1570 bytes ! ! 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 este ie i extrem de uor reversibil (exist scripturi online care realizeaz decriptarea aproape instantaneu):
Marketing(config)#enable password cisco

9|Arhitectura unui ruter

Marketing(config)#service password-encryption Marketing#show running-config [...] ! 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 algoritm i se vor compara hash-urile rezultate. n acest fel, i 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 Marketing#show running-config Building configuration... [...] 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 u dedus. Dei cele dou moduri de configurare a parolei nu sunt mutual or 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 re din to pologia ea pe care o formeaz, sistemul lor de operare s nu poat fi accesat de ctre persoane neautorizate. Este recomandabil ca att terminalele virtuale ct consola s fie protejate prin parole. Aceste i 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 Enter configuration commands, one per line. 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 comenzile password si login se vor aplica celor 5 linii a simultan. Comanda login indic faptul c linia respectiv va cere o informa de autentificare ie 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 nainte sau dup afi 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 faptul c sistemul respectiv nu e ste accesibil in 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 afi la conectarea prin co nsol. Acela banner este afiat i la at, i 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 ei. Odat schimbat modul de prin comanda interface urmat de numelei nu mrul interfe configurare, toate comenzile ulterioare se vor aplica interfe menionate ca argument, pn la ei prsirea modului. Pentru ca o interfa s poat accepta pachete din reeaua la care este conectat, configuraia sa trebuie s con in 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 se face prin comanda e 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 Building configuration... Current configuration : 76 bytes !

12 | P r o i e c t a r e a r e e l e l o r
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 echipamente a scopului pe care aceste legturi le deservesc. i 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 Building configuration... Current configuration : 209 bytes ! 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 active ale ruterului. n acest fel, fiecare ruter poate identifica celelalte ele echipamente la care este conectat. CDP este activ n mod implicit pe toate interfe ele , dar nu poate schimba informa n ambele ii 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.

13 | A r h i t e c t u r a u n u i r u t e r
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 cu parametrul i detail, care va afi toate informaiile a 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(config-if)#end 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 Serial1/2 is administratively down, line protocol is down Encapsulation HDLC Sending CDP packets every 60 seconds Holdtime is 180 seconds Serial1/3 is administratively down, line protocol is down Encapsulation HDLC Sending CDP packets every 60 seconds Holdtime is 180 seconds

CDP este unul dintre puinele protocoale care extind semnificaia numelui (hostname) mai departe de ruterul local.

14 | P r o i e c t a r e a r e e l e l o r 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 nedocumentate, deoarece permite unei re 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 interfe elor de loopback n aceeai manier ca i pentru interfeele fizice. Utilizrile interfe elor 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 func ional , 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)#ip address 192.168.99.1 255.255.255.252 Marketing(config-if)#exit Marketing(config)#interface loopback 1 Marketing(config-if)#ip address 172.16.15.1 255.0.0.0 Marketing(config-if)#end 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

15 | A r h i t e c t u r a u n u i r u t e r
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 operare platforma pentru care este destinat, i 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.

16 | P r o i e c t a r e a r e e l e l o r
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 Serial1/0 is up, line protocol is up 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 administratively down down administratively down down up up

Tabelul returnat listeaz toate interfe (inclusiv cele virtuale, precum cea de loopback), ele adresele IP configurate, modul n care s-a realizat configurarea (NVRAM denot configurarea static o alt valoarea posibil ar fi fost DHCP), precum starea interfeei la nivel 1 (Status) i starea i 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.

17 | A r h i t e c t u r a u n u i r u t e r
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]: 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/7/9 ms

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 rutat se trimite napoi i 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 Type escape sequence to abort. 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.

18 | P r o i e c t a r e a r e e l e l o r 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 condi iile unui text pe mai multe pagini, fapt ce cauzeaz derularea automat la prima apariie a lui cuvant. Exemplu:
Engineering#show running-config Building configuration... Current configuration : 1475 bytes ! version 12.3 no service password-encryption ! hostname Engineering [fragment] --More--

Afiarea comenzilor permise este posibil n orice moment, chiar pentru comenzi parial i 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 ? afi eaz 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 doar variantele pentru urmtorul cuvnt din a 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.

19 | A r h i t e c t u r a u n u i r u t e r
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 respectiv, IOS va ncerca s afieze toate iul 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 considera irul 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> Engineering#conf t? terminal Engineering#conf t Enter configuration commands, one per line. Engineering(config)# End with CNTL/Z. Configure Configure Overwrite Configure from NV memory from a TFTP network host NV memory from TFTP network host from the terminal

Exemplul de mai sus demonstreaz faptul c irul 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.

20 | P r o i e c t a r e a r e e l e l o r 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 destina Ruta c orespunztoare va specifica fie adresa ruterului urmtor ii. (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 fiecare ruter de pe parcurs lund decizii n mod ie, independent cu privire la calea pe care o va urma pachetul, n continuare. n aceste condiii ruterele trebuie s aib informa consistente ntr -o anumit msur cu privire la rutele cunoscute. n caz ii contrar, dac un ruter prime un pachet pentru care nu cu noate calea spre destinaie, pachetul te 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, consisten informaiilor de rutare ntr -o topologie urmrete i scopul evitrii a buclelor de rutare, adic situa n care pachetele vor cicleaz ntre aceleai rutere, fr a mai ii 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.

22 | P r o i e c t a r e a r e e l e l o r

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.0/32 is subnetted, 1 subnets 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 192.168.0.0/16 is directly connected, Loopback0

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. elele cror a le aparin interfeele Rutele marcate ca fiind directly connected reprezint re 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 membr a reelei respective este nc activ. Masca de reea a a rutelor direct conectate este masca ce a fost configurat pe interfaa n cauz. n momentul n care un ruter prime un pachet IP pe una dintre interfee, adresa destinaie te 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 un pachet cu prime 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 LAN1 192.168.1.0/24 R1 R2 LAN2 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 s l indice pe R2 drept next-hop pentru destinatia LAN2 (n mod normal este necesar ruta simetric opus, de la R2 la LAN1, pentru a avea conectivitate bidirec ional). Cea mai simpl metod de a rezolva aceast situa este definirea unei rute statice spre ie 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:

10.0.0.0/24 is subnetted, 1 subnets C 10.0.0.0 is directly connected, Serial1/0 C 192.168.1.0/24 is directly connected, Loopback0 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 ruterului vecin, prin care trebuie s treac ei 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

24 | P r o i e c t a r e a r e e l e l o r pierdute. Este posibil crearea unei rute statice cu aceast destina pentru pachetele ce trebuie ie 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* 10.0.0.0/24 is subnetted, 1 subnets 10.0.0.0 is directly connected, Serial1/0 192.168.1.0/24 is directly connected, Loopback0 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 denumit quad-zero. Masca /0 permite acestei rute s i 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 bazat exclusiv pe ie rute statice sufer de lipsa scalabilit i de un risc tot mai mare de apariie a erorilor, pe msur ii ce reeaua crete. Protocoalele de rutare adreseaz acest neajuns propagnd rutele ial cunoscute ca rute (ini direct conectate) n tabelele de rutare ale tuturor ruterelor ce ruleaz acelaprotocol de rutare. i 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 redestinaie utiliznd ea algoritmi proprii. Un avantaj major al multor protocoale de rutare este faptul c informa de iile rutare actualizate sunt schimbate de fiecare dat cnd nea are loc o schimbare. Acest lucru re permite ruterelor s nve dinamic reelele nou conectate dar i s gseasc rute alternative n e 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

25 | F u n c i i l e u n u i r u t e r 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 este intervalul n care toate tabelele de rutare ale ele ruterelor ajung ntr-o stare de consisten, deci cnd toate ruterele cunosc destinaiile existente i rutele corecte spre acestea. n general, o ea este inutilizabil sau dificil de controlat ct timp re 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 le ii 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 re ct mai lung). n cazul n care rute din surse diferite ofer ci ea 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, distan admin istrativ desemneaz un grad de ncredere sau a 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 distan administrative este ntotdeauna preferat. Dac, spre exemplu, ei 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.

26 | P r o i e c t a r e a r e e l e l o r 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 anun dou sau mai multe rute spre aceeai destinaie, care e au aceeai distan administrativ, dar urmeaz ci diferite pn la reeaua respectiv. Pentru astfel de situa este nevoie de un procedeu de decizie ce implic n mod direct ii 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 ata ate 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 destinaie, dac i 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 nvate 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.

27 | F u n c i i l e u n u i r u t e r

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 n memorie ci doar distana i direcia spre fiecare ele 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 re prin faptul c fiecare ruter trimite la 30 de secunde ea 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 situa simpl n care comunicarea ntre reele devine ie imposibil datorit acestei limitri.

172.16.0.0/16 LAN1 10.1.0.0/24 R1 RIP Update: 10.0.0.0/8 Figura 2-3: Update RIP n exemplul de mai sus, dac ntre cele dou rutere se folose RIP, staiile din reeaua te 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 re elei 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. R2 LAN2 10.2.0.0/24

28 | P r o i e c t a r e a r e e l e l o r

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 efectiv procesul RIP, ci doar creeaz contextul pentru comenzile de te configurare ale acestuia. nchiderea unui protocol de rutare se face prinarea cuvntului ata 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)#network 100.0.0.0 R1(config-router)#network 110.0.0.0 R1(config-router)#network 120.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 va avea ca efect trunchierea adresei la lungimea ea 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).

29 | F u n c i i l e u n u i r u t e r 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/24 is subnetted, 1 subnets 100.0.0.0 [120/1] via 20.0.0.1, 00:00:26, Serial1/0 200.0.0.0/24 is directly connected, Loopback0 20.0.0.0/24 is subnetted, 1 subnets 20.0.0.0 is directly connected, Serial1/0 110.0.0.0/24 is subnetted, 1 subnets 110.0.0.0 [120/1] via 20.0.0.1, 00:00:23, Serial1/0 120.0.0.0/24 is subnetted, 1 subnets 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 n re respectiv. eaua 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 prin mpiedicarea trimiterii ii 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 rip R1(config-router)#passive-interface serial1/0

30 | P r o i e c t a r e a r e e l e l o r 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, i alte ca 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 este caracteri zat printr-o distan ie (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 lor de rutare de la vecini, un ii 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.

31 | F u n c i i l e u n u i r u t e r

2.2.3.1 Holddown timers

Dei folosirea de triggered updates accelereaz convergen acestea pot cauza efecte a, duntoare n anumite condi O astfel de situaie este reprezentat de interfe ii. ele 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 prime o rut cu o metric mai bun dect te 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 re pe aceeai interfa prin ea care a aflat despre acea reea. Logica din spatele acestei reguli este u de dedus. Atta timp ct un ruter afl pentru prima or oar despre o anumit re de la unul dintre vecini, se poate considera c vecinul respectiv este ea 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 unei reele nevalide va transmite a ruta ctre acea re n update -urile sale cu valoarea metricii 16, ceea ce denot n RIP o metric ea 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 informaia despre reeaua ea devenit inaccesibil, nemaifiind nevoie s se atepte expirarea unor timere.

2.2.4 RIPv2
RIPv2 este definit n RFC1723. Principala mbuntadus de RIPv2 este eliminarea ire funcionalitii exclusiv classful. RIPv2 poate s transporte rutele mpreun cu tile de reea m

32 | P r o i e c t a r e a r e e l e l o r corespunztoare dei, n mod implicit, sumarizarea la graniele classful este nc activ. n plus, RIPv2 eficientizeaz utilizarea traficului n ea prin folosirea adresrii multicas t n locul celei re 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 rip R2(config-router)#version 2

Comanda show ip protocols arat versiunea update-urilor trimise i primite (cmpurile Send i Recv):
R2#show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds, next due in 8 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 [...]

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 prefixul reelei pentru un ruter ce ruleaz in versiunea 1. Sumarizarea este activ n mod implicit si pe versiunea 2 a protocolului RIP. Mai exact, dac un ruter are interfe conectate la subreele ale aceleiai reele classful, RIPv2 va propaga n e continuare doar reeaua classful, considernd-o o sumarizare a celorlalte ele. Dezactivarea re sumarizrii se face prin comanda no auto-summary:
R2(config)#router rip 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 ce descriu iuni 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

33 | F u n c i i l e u n u i r u t e r 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 interfe cu scopul de a filtra traficu l se face conform regulii: un ACL e 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 instruc iuni 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 con ine doar aceast instruciune va bloca tot traficul din exterior spre reeaua local, mai puin traficul conexiunilor TCP iniiate din interior.

34 | P r o i e c t a r e a r e e l e l o r 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 avnd n vedere scopul su. Dac traficul este n i 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 func de frecvena apar iiei anumitor tipuri de trafic, pentru mbuntirea ie 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 destina ie. Totui, plasarea unui ACL trebuie fcut n funcie de tipul su: ACL-urile standard trebuie plasate ct mai aproape destina deoarece ele nu specific o ie 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.

35 | F u n c i i l e u n u i r u t e r 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 i din reeaua 172.19.0.0/16 iilor ctre orice destinaie, mai puin pentru staia 172.19.12.10:
R2(config)#access-list 10 deny host 172.19.12.10 R2(config)#access-list 10 permit 172.19.0.0 0.0.255.255

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 sta pentru care nu este ii, 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 R2(config)#access-list 10 permit 0.0.0.0 255.255.255.255

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 direc in pentru a determina ce adrese se pot conecta la aceste terminale). ia Pentru aplicarea unui ACL unuia sau mai multor terminale virtuale se folosete comanda access class, 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 trebui tears 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 a pachetului, precum i protocolul i numerele de port surs i ie destinaie de la nivelul transport. Simplificat, sintaxa ACL-urilor extinse este:

36 | P r o i e c t a r e a r e e l e l o r
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 ce nu se reduc doar la filtrarea traficului pe ri 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

37 | F u n c i i l e u n u i r u t e r 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 dorete 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)#ip access-list standard DENY_SERVERS R2(config-std-nacl)#7 deny host 192.168.100.99

Afiarea ACL-ului demonstreaz poziionarea corect a noului statement:

Standard IP access list DENY_SERVERS 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 se face n aceeai manier ca i la ACL -urile e 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 Standard IP access list 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 funciilor ACL -urilor n mai mult detaliu dect numele folosit pentru ACL. Facilitatea remark permite introducerea de comentarii ntr-un ACL:
R2(config)#ip access-list standard DENY_SERVERS R2(config-std-nacl)#remark ? LINE Comment up to 100 characters <cr> R2(config-std-nacl)#remark Blocheaza accesul serverelor S1, S15 si S99

38 | P r o i e c t a r e a r e e l e l o r 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 spa 127.0.0.0/8 (i altele) iar acestea nu pot fi cumprate sau re zervate de un iul anumit client. Pe lng adresele rezervate din considerente tehnice, RFC1918 stabile alte trei intervale de te 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 autorit Orice numr de reele private din i. 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 re ele locale, ce vor trebui rutate n Internet. De asemenea, se ridic i problema

39 | F u n c i i l e u n u i r u t e r traducerii inverse a pachetelor ce vin din Internet trebuie s ajung la anumite destinaii din i 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 nlocuiet e adresa surs privat din antetul IP cu o adres IP public, de regul, cea configurat pe interfa sa i reine aceast asociere. Pentru staiile din Internet, a 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 pentru ini a putea fi rutate mai departe spre sta ia 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 n momentul n care un numr de i staii mai mare dect numrul de adrese publice disponibile ncearc s trimit pachete n Internet la un moment dat, ceea ce e o situa ntlnit aproape n ie permanen. Deseori ruterul are o singur adres public, iar problema se datoreaz faptului c ruterul va putea re o singur ine asociere la un moment dat pentru acea adres. Dac dou ii ncearc s comunice n acelai sta 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 s comunice sta 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 numete 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 ct sursa ad resei de nivel 4 pentru pachetele care pleac din re local i va i eaua 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.

40 | P r o i e c t a r e a r e e l e l o r 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 re elei 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 public. i una Sintaxa comenzii este urmtoarea:
R2(config)#ip nat inside source static 192.168.1.1 89.221.57.81

192.168.1.1/24

192.168.1.2/24

89.221.57.81/30

89.221.57.82/30

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

Web Server

Comanda introduce o mapare permanent ntre adresa local 192.168.1.1 adresa public i 89.221.57.81. Pentru a defini direcia n care se realizeaz translatarea adreselor, trebuie i specificate interfeele inside (spre reeaua local) si cele de outside (spre Internet):

41 | F u n c i i l e u n u i r u t e r
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 din re eaua local 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:
R2(config)#access-list 1 permit 192.168.100.0 0.0.0.255

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.

42 | P r o i e c t a r e a r e e l e l o r

2.4.5 Port forwarding

ie Tehnica de port forwarding permite accesarea din exterior a unui port de pe o sta dintr -o 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 membri ai reelei dup adresa sa privat i va rspunde la i 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 interfa configurat cu acea adres, se prefer utilizarea variantei bazate pe numele a 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 reele 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 deibi pentru 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 totu faptul ca tehnologiile IPv4, CIDR i NAT, au reuit s rezolve o serie i 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,

44 | P r o i e c t a r e a r e e l e l o r 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 n elege 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 un IPv4 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 aceea IPv6 i de 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 n altul peste o de re 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 bii. i de Echipamentele de reea interpreteaz fluxurile de date la nivel de bii. Odat ce datele au fost

46 | P r o i e c t a r e a r e e l e l o r 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 i n notaie binar ar fi aproape imposibil de bi 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 observa este faptul c n IPv6 nu exist tipul de transmisie broadcast. Evoluia ie 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 direc ionarea 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 toate adresele destinaie din lume, o metod complet re nescalabil. n mod evident, ca i n cazul IPv4, exist nevoia unei structuri de adresare ierarhic n IPv6 folosind conceptul de masc de re Din cauza dimensiunii mari ai unei adrese IPv6 singura ea. notaie acceptat pentru masca de reea este folosind simbolul / urmat de un numr de la 0 la 128 ce semnific numrul de bi setai la valoarea 1 de la nceputul mtii, ca i n cazul IPv4. i 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 200::/3 din totalul de adrese IPv6. iul 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 bi ai adresei IPv6 au fost i mprii dup cum se observ n figura de mai jos: 64 b Global routing prefix 001 Global ID Figura 3-3: Structura adresei IPv6 Primii 3 bi i 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 bi se poate deduce i continentul, ara i mai apoi ISP -ul. Urmtorii bi pn la 64 (minim 16), vor fi oferii unei i, organizaii pentru crearea de subreele. Cu alte cuvinte, poriunea denumit Subnet ID va reprezenta echivalentul prii de subreea din IPv4. Ultimii 64 de bi i, 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. ISP Subnet Subnet ID Host = 64 b Interface ID

48 | P r o i e c t a r e a r e e l e l o r 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 acelai 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 prima vedere la 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 ale administratorului i s poat avea acces dir ect la ii 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 ( e.g address resolution) nu se mai poate ie 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 informa de tipul: adres server ii 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 sta poate comunica cu ie ruterul gateway pentru a ob ine 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 Un Interface ID are 64 de bii. Trebuie deci i. 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 re ea 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 folose o adres de multicast special te 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

50 | P r o i e c t a r e a r e e l e l o r

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 A

Reea IPv4 B

Reea IPv6

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 folosind tabela de ia 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 va ruta n funcie de i l 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 virtuale numite Tunnel (indexat de la 0). Pentru a trimite e 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 adres IP destina ie i 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 interfade tip Tunel a 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

52 | P r o i e c t a r e a r e e l e l o r 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 deoarece au nc orporat n protocol o metod prin care pot s o iei 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

Subnet

Interface ID

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 200.15.15.1 Insul IPv6 A Reea IPv4 B Prefix insul: 2002:D81A:10C1::/48 216.26.16.193 Insul IPv6

Tunnel0: 2002:C80F:F01::1/48

Tunnel0: 2002:D81A:10C1:200::1/64

Figura 3-6: Tunelarea 6to4 n afar de configura iile 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 bi (sunt difereniate prin biii de subnet) pachetul va pleca cu adres IPv6 surs: i

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 realizeaz ncapsularea pentru traficul de ntoarcere pe ruterul B. i 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 adresa de solicited-node i 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

54 | P r o i e c t a r e a r e e l e l o r 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 Ethernet2/1 is up, line protocol is up [] 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 interfa unui ruter folosind informaiile pe care vecinul a 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 Ethernet2/1 is up, line protocol is up 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 interfade 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 instan RIPNGR3 este activat pe interfeele fa0/1 i fa0/0. De a asemenea ruterul vecin va trimite rute default pe aceste interfe ca rezultat al comenzii ipv6 e
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 IPv6 peste un ele 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 configurat la un capt ie 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 Sange#sh ip int br E2/1 Interface Ethernet2/1 IP-Address 172.1.231.1 OK? Method Status YES NVRAM up OK? Method Status YES NVRAM up

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 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001::1, timeout is 2 seconds: Packet sent with a source address of 2001:200::1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/33/96 ms

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 realizate pentru instalarea unui tunel 6to4 ntre iile 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

56 | P r o i e c t a r e a r e e l e l o r
Leshrac(config-if)#ip address 172.1.231.2 255.255.255.252

Pentru ca metoda automat de descoperire a adreselor ie de ncapsulare s destina 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/1

Kobol

E2/2

Reea IPv4

Fa3/0

E2/2 E2/2

Earth Figura 3-7: Studiu de caz

Moon

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 is seteze 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 Kobol# sh ip int br e2/1 Interface Ethernet2/1 Caprica#sh ip int br e2/2 Interface Ethernet2/2 IP-Address 172.14.31.2 IP-Address 172.1.231.2 IP-Address 172.17.0.2 OK? Method Status YES NVRAM up OK? Method Status YES NVRAM up 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 ob inui biii 16 -48 din fiecare adres IPv6, se pot configura interfe de tunel cu ele 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

58 | P r o i e c t a r e a r e e l e l o r
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 ntre interfeele de ia acum posibil.

tunel este

Earth#ping 2002:AC11:0002:2::1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2002:AC11:2:2::1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/71/144 ms

Scopul final este ns posibilitatea de a da ping n interfe ele 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 interfa tunelului drept interfa de ieire. a 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 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:4::1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/46/156 ms

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

60 | P r o i e c t a r e a r e e l e l o r 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
1536 Kbps

768 Kbps

R3

1536 Kbps

R1

10.2.12.0/24 512 Kbps

R5
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: Bandwidth = 107 / min(bandwidth) = 107 / 512 = 19531 Delay = 3 x 20000 / 10 = 40000 / 10 = 4000 Metrica = 256 x (19531 + 4000) = 6023936

R4

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.

62 | P r o i e c t a r e a r e e l e l o r 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: Bandwidth = 107 / min(bandwidth) = 107 / 512 = 19531 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.

64 | P r o i e c t a r e a r e e l e l o r 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.

66 | P r o i e c t a r e a r e e l e l o r 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

10.1.0.0/16

172.16.10.0/2

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 R1(config-router)#network 172.16.7.0 0.0.0.255 R1(config-router)#network 10.1.0.0 0.0.255.255

Pentru ruterul R2 vor trebui introduse umtoarele comenzi:

R2(config)#router eigrp 101 R2(config-router)#network 172.16.5.0 0.0.0.255 R2(config-router)#network 172.16.7.0 0.0.0.255 R2(config-router)#network 172.16.10.0 0.0.0.255

Pentru ruterul R3 urmtoarele comenzi:

R3(config)#router eigrp 101 R3(config-router)#network 10.2.0.0 0.0.255.255 R3(config-router)#network 172.16.10.0 0.0.0.255 R3(config-router)#network 172.16.8.0 0.0.0.255

Pentru ruterul R4 urmtoarele comenzi:

R3(config)#router eigrp 101 R3(config-router)#network 172.16.6.0 0.0.0.255 R3(config-router)#network 10.1.0.0 0.0.255.255 R3(config-router)#network 172.16.8.0 0.0.0.255

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.

68 | P r o i e c t a r e a r e e l e l o r

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. 10.8.0.0/16 AS extern

172.16.1.1

R1

172.16.1.2

R2

10.8.1.1

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 R2(config)#router eigrp 102 R2(config-router)#network 172.16.1.0 0.0.0.255 R2(config-router)#network 10.8.0.0 0.0.255.255

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

172.18.2.1 Fa0/0

192.168.10.1/30

S0/1

172.20.3.1

R1

S0/1

192.168.10.2/30

R2

Fa0/0

Figura 4-5: Verificarea funcionrii EIGRP Configuraia de pe ruterul R1 este:

R1(config)#router eigrp 103 R1(config-router)#network 172.18.2.0 0.0.0.255 R1(config-router)#network 192.168.10.0

Iar configuraia de pe ruterul R2 este:

R2(config)#router eigrp 103 R2(config-router)#network 172.20.3.0 0.0.0.255 R2(config-router)#network 192.168.10.0

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 (ms) 17

RTO 2280

Q 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 Gateway of last resort is not set 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 variably subnetted, 2 subnets, 2 masks 192.168.10.0/30 is directly connected, Serial0/1 192.168.10.0/24 is a summary, 00:05:31, Null0

70 | P r o i e c t a r e a r e e l e l o r 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 172.18.0.0/16 is variably subnetted, 2 subnets, 2 masks D 172.18.0.0/16 is a summary, 00:05:31, Null0 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks 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:
R1#show ip protocols Routing Protocol is "eigrp 103" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set 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 Routing for Networks: 172.18.2.0/24 192.168.10.0 Routing Information Sources: 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

Coloanele tabelului au semnificaia urmtoare: 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 P 192.168.10.0/24, 1 successors, FD is 40512000 via Summary (40512000/0), Null0 P 172.18.0.0/16, 1 successors, FD is 28160 via Summary (40512000/0), Null0 P 172.18.2.0/24, 1 successors, FD is 28160 via Connected, FastEthernet0/0 P 172.20.0.0/16, 1 successors, FD is 40514560 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;

72 | P r o i e c t a r e a r e e l e l o r 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

172.16.1.0/16

192.168.2.0/24

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:
R1(config)#router eigrp 103 R1(config-router)#no auto-summary R2(config)#router eigrp 103 R2(config-router)#no auto-summary

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.

74 | P r o i e c t a r e a r e e l e l o r 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

R1

R3

10.8.2.0/24

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 R3 R4 30 20 40 15 10 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 eigrp 104 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

R1

R2
Figura 4-9: EIGRP Stub

172.16.3.0/24

Considerm topologia din figura 4-7 i urmtoarea configuraie:

R2(config)#interface s0/0 R2(config-if)#ip sumary-address eigrp 105 172.16.2.0 255.255.254.0 R2(config)#router eigrp 105 R2(config-router)#network 172.16.4.0 0.0.0.255 R2(config-router)#network 172.16.2.0 0.0.0.255

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

76 | P r o i e c t a r e a r e e l e l o r 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.
timp_sfarsit | duration secunde]
Router(config-keychain-key)#accept-lifetime timp_inceput [infinite |

Pas 8. Opional, se poate specifica o perioad de timp n care parola s fie folosit pentru pachetele trimise.
timp_sfarsit | duration secunde]
Router(config-keychain-key)#send-lifetime timp_inceput [infinite |

172.18.2.1 Fa0/0

S0/0

172.20.3.1

R1

S0/0

192.168.10.2

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 R1(config-keychain)#key 2 R1(config-keychain-key)#key-string cheie2 R1(config-keychain-key)#accept-lifetime 00:00:00 Oct R1(config-keychain-key)#send-lifetime 00:00:00 Oct 1

1 2009 infinite 2009 00:10:00 Oct 1

1 2009 infinite 2009 infinite

R1(config)#interface s0/0 R1(config-if)#ip authentication mode eigrp 106 md5 R1(config-if)#ip authentication key-chain eigrp 106 lant1 R1(config)#router eigrp 106 R1(config-router)#network 172.18.2.0 0.0.0.255 R1(config-router)#network 192.168.10.0 0.0.0.255

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:
R2(config)#key chain lant2 R2(config-keychain)#key 1 R2(config-keychain-key)#key-string cheie1 R2(config-keychain-key)#accept-lifetime 00:00:00 Oct R2(config-keychain-key)#send-lifetime 00:00:00 Oct 1 R2(config-keychain)#key 2 R2(config-keychain-key)#key-string cheie2 R2(config-keychain-key)#accept-lifetime 00:00:00 Oct R2(config-keychain-key)#send-lifetime 00:00:00 Oct 1

1 2009 infinite 2009 infinite 1 2009 infinite 2009 infinite

R2(config)#interface s0/0 R2(config-if)#ip authentication mode eigrp 106 md5 R2(config-if)#ip authentication key-chain eigrp 106 lant2 R2(config)#router eigrp 106 R2(config-router)#network 172.20.3.0 0.0.0.255 R2(config-router)#network 192.168.10.0 0.0.0.255

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:
R1#show ip eigrp neighbors IP-EIGRP neighbors for process 105 H Address Interface Hold Uptime Seq (sec) Num 0 192.168.10.2 Se0/0 12 00:10:20

SRTT (ms) 17

RTO

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)#key chain lant2

78 | P r o i e c t a r e a r e e l e l o r
R2(config-keychain)#key 2 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:

R2#show ip eigrp neighbors IP-EIGRP neighbors for process 106

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
E1/0 E3/0 E3/2 E1/0 Fa0/0

ISP

10.10.0.4/30

10.10.0.12/30

10.10.0.8/30
E3/2

10.10.0.0/30

E3/0

Fa0/0

Iai

Fa1/0

Fa1/0

Arad

10.10.0.20/30 141.23.17.0/25

Deva

141.23.17.128/26

141.23.17.192/26

Figura 4-11: Topologia reelei companiei AgiliCat

79 | E I G R P

4.4.1 Configurri de baz

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 up up up up up up up up 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 Arad#show ip interface brief | include up Ethernet0/0 10.10.0.10 FastEthernet1/0 10.10.0.21 Loopback0 141.23.17.1 Iasi#show ip interface brief | include up FastEthernet1/0 10.10.0.22 Ethernet3/0 10.10.0.14 Loopback0 141.23.17.129 Deva#show ip interface brief | include up FastEthernet0/0 10.10.0.2 Loopback0 141.23.17.193 YES manual up YES manual up YES manual up YES manual up YES manual up YES manual up YES manual up YES manual 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)#network 10.10.0.4 0.0.0.3 Bucuresti(config-router)#network 10.10.0.12 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)#network 10.10.0.20 0.0.0.3 Arad(config-router)#network 141.23.17.0 0.0.0.127 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)#network 10.10.0.12 0.0.0.3 Iasi(config-router)#network 141.23.17.128 0.0.0.63 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

80 | P r o i e c t a r e a r e e l e l o r 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 IP-EIGRP neighbors for process 24012 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

Q Cnt 2424 0 1920 0

RTO

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 Gateway of last resort is not set 141.23.0.0/16 is variably subnetted, 3 subnets, 2 masks 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 10.0.0.0/30 is subnetted, 5 subnets 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 10.10.0.8 is directly connected, Ethernet3/2 C 10.10.0.12 is directly connected, Ethernet3/0 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 IP-EIGRP Topology Table for AS(24012)/ID(10.10.0.17) [...] P 141.23.17.64/26, 1 successors, FD is 409600 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 IP-EIGRP Topology Table for AS(24012)/ID(141.23.17.65) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 0.0.0.0/0, 1 successors, FD is 307200 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 IP-EIGRP Topology Table for AS(24012)/ID(141.23.17.65) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 0.0.0.0/0, 2 successors, FD is 309760 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

82 | P r o i e c t a r e a r e e l e l o r 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 IP-EIGRP neighbors for process 24012 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 Gateway of last resort is 0.0.0.0 to network 0.0.0.0 141.23.0.0/16 is variably subnetted, 3 subnets, 2 masks 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 10.0.0.0/30 is subnetted, 5 subnets C 10.10.0.0 is directly connected, FastEthernet0/0 C 10.10.0.4 is directly connected, Ethernet1/0 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 Gateway of last resort is 10.10.0.5 to network 0.0.0.0 141.23.0.0/16 is variably subnetted, 3 subnets, 3 masks 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 10.0.0.0/30 is subnetted, 5 subnets D 10.10.0.0 [90/284160] via 10.10.0.5, 00:59:12, Ethernet1/0 C 10.10.0.4 is directly connected, Ethernet1/0 C 10.10.0.8 is directly connected, Ethernet3/2 C 10.10.0.12 is directly connected, Ethernet3/0 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 Gateway of last resort is 0.0.0.0 to network 0.0.0.0 141.23.0.0/16 is variably subnetted, 3 subnets, 3 masks 141.23.17.192/26 [90/156160] via 10.10.0.2, 00:10:12, FastEthernet0/0 141.23.17.0/24 [90/435200] via 10.10.0.6, 00:17:44, Ethernet1/0 10.0.0.0/30 is subnetted, 5 subnets C 10.10.0.0 is directly connected, FastEthernet0/0 C 10.10.0.4 is directly connected, Ethernet1/0 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

84 | P r o i e c t a r e a r e e l e l o r

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

86 | P r o i e c t a r e a r e e l e l o r 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 192.168.10.2 S0/1

R1
Starea Init

S0/0

R2

R1
Starea 2-Way

Hello Sunt ruterul cu ID 192.168.10.1

multicast 224.0.0.5

R2

R1

unicast 192.168.0.1 Hello Sunt ruterul cu ID 192.168.10.2 i am vecinul 192.168.10.1 Figura 5-1: Stabilirea comunicaiei bidirecionale

R2

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

88 | P r o i e c t a r e a r e e l e l o r 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 192.168.10.2 S0/1

R1

S0/0

R2

Starea Exstart

R1

DBD Eu sunt master pentru c am ID 192.168.10.1 DBD

R2

R1
Starea Exchange

Eu sunt master pentru c am ID mai mare

R2

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 192.168.10.2 E1 LSAck

R1

E0

R2

R1
Starea Loading LSR

Confirmarea pachetelor

R2

R1

Am nevoie de o informaie complet despre reeaua 192.168.11.0/24 LSU

R2

R1 R1
Starea Full

Informaia complet despre 192.168.11.0/24 LSAck Confirmarea actualizrii

R2 R2

Figura 5-3: Descoperirea rutelor

90 | P r o i e c t a r e a r e e l e l o r Stare Down 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

Init 2-Way

Ex-start

Exchange Loading Full

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 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

Hello DBD LSR LSU LSAck

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.

92 | P r o i e c t a r e a r e e l e l o r 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

Zona 0 (Backbone)

R2

Zona 3

R3 Zona 1 Zona 2

R7 R5

R4

R6
Figura 5-6: Organizarea ierarhic

R8

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 1 R2 Internal router R3 ABR R1 ABSR R4 ABR

Zona 2 R5 Internal router

Figura 5-7: Tipuri de rutere OSPF

94 | P r o i e c t a r e a r e e l e l o r 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 R1 Tip 1 Internal router R2

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 Tip 2 Internal router R2

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 Internal router R2 Tip 1/2 ABR R3

Zona 0 (Backbone) ABR R1 Tip 3 R4 Tip 3

Zona 2 Internal router R5

Figura 5-10: LSA 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 0 (Backbone) ABR R3 Tip 4 R1 ABR R4 Tip 4

Zona 2 Internal router R5

Figura 5-11: LSA 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.

96 | P r o i e c t a r e a r e e l e l o r

R6 Reea extern

ASBR R2 Tip 5

Zona 1

Zona 0 (Backbone) ABR R3 Tip 5 R1 ABR R4 Tip 5

Zona 2 Internal router R5

Figura 5-12: LSA 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 ABR R3

Zona 0 (Backbone)

ABR

Zona 2 Stub

R1

R4

R5

Extern

Extern Summary
Figura 5-13: Zona Stub

Default Summary

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.

98 | P r o i e c t a r e a r e e l e l o r

R Reea extern

Zona 1 ASBR R2 ABR R3

Zona 0 (Backbone)

ABR

Zona 2 Totally Stubby

R1

R4

R5

Extern

Extern Summary
Figura 5-14: Zona Totally Stubby

Default Default

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

ABR R3

Zona 0 (Backbone)

ABR

Zona 2

R1

R4

R5

LSA 7

LSA 5
Figura 5-15: Zona Not So Stubby

LSA 5

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.

100 | P r o i e c t a r e a r e e l e l o r

Zona 0 (Backbone) R1

Zona 1 Legtura virtual R2 R4

Zona 2

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 1 Legtura virtual R2 R4

Zona 0 (Backbone) R5

Figura 5-17: Legturi virtuale 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.

5.3 Configurarea protocolului

5.3.1 Configurri de baz
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 172.20.3.0/24

R1
11.0.0.0/8

S0/0

S0/0

R2

Fa0/0

Fa0/0

R3
10.0.0.0/8

Figura 5-18: : Configurare OSPF cu o singur zon Ruterul R1 va trebui configurat n felul urmtor:
R1(config)# router ospf 1 R1(config-router)# network 11.0.0.0 0.255.255.255 area 0 R1(config-router)# network 192.168.10.0 0.0.0.3 area 0

Pentru ruterul R2 vor trebui introduse umtoarele comenzi:

R2(config)# router ospf 2 R2(config-router)# network 192.168.10.0 0.0.0.3 area 0 R2(config-router)# network 172.20.3.0 0.0.0.255 area 0

Pentru ruterul R3 urmtoarele comenzi:

R3(config)# router ospf 50 R3(config-router)# network 172.20.3.0 0.0.0.255 area 0 R3(config-router)# network 10.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

172.20.3.0/24

10.0.0.0/8

R1
11.0.0.0/8

S0/0

S0/0

R2

Fa0/0

Fa0/0

R3

Zona 0

Zona 1

Figura 5-19: Configurare OSPF cu o mai multe zone

102 | P r o i e c t a r e a r e e l e l o r Ruterul R1 va trebui configurat n felul urmtor:

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

Pentru ruterul R2 vor trebui introduse umtoarele comenzi:

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

Pentru ruterul R3 urmtoarele comenzi:

R3(config)# router ospf 50 R3(config-router)# network 172.20.3.0 0.0.0.255 area 1 R3(config-router)# network 10.0.0.0 0.255.255.255 area 1

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: 1 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 1 0 State FULL/DR FULL/Dead Time 00:00:36 00:00:38 Address 172.20.3.2 192.168.10.1

104 | P r o i e c t a r e a r e e l e l o r 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 11.0.0.1 192.168.10.1 192.168.10.2 Age 1381 1460 2027 Seq# 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

Coloanele tabelului au semnificaia urmtoare: 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 R2

Zona 0 (Backbone)
192.168.10.0/30

ABR

Zona 2 Stub
172.20.3.0/24

R3

R4

Figura 5-20: : Configurare zon Stub Ruterul R3 va trebui configurat n felul urmtor:
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

Pentru ruterul R4 vor trebui introduse umtoarele comenzi:

R4(config)# router ospf 2 R4(config-router)# network 172.20.3.0 0.0.0.255 area 2 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. Ruterul R3 va trebui configurat n felul urmtor:
R3(config)# router ospf 1

106 | P r o i e c t a r e a r e e l e l o r
R3(config-router)# network 192.168.10.0 0.0.0.3 area 0 R3(config-router)# network 172.20.3.0 0.0.0.255 area 2 R3(config-router)# area 2 stub no-summary

Pentru ruterul R4 vor trebui introduse urmtoarele comenzi:

R4(config)# router ospf 2 R4(config-router)# network 172.20.3.0 0.0.0.255 area 2 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

R RIP

Zona 1 Not So Stubby ASBR R1

ABR R2

Zona 0 (Backbone)
192.168.10.0/30

ABR

Zona 2

172.20.3.0/24

R3

R4

Figura 5-21: Zona Not So Stubby Ruterul R2 va trebui configurat n felul urmtor:
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

Pentru ruterul R1 vor trebui introduse umtoarele comenzi:

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

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. Pentru ruterul R1 vor trebui introduse umtoarele comenzi:
R1(config)# router ospf 2 R1(config-router)# area 1 range 192.168.32.0 225.255.224.0 R1(config-router)# area 0 range 192.168.96.0 255.255.224.0

108 | P r o i e c t a r e a r e e l e l o r

Zona 1
172.20.32.0/24 pn la 172.20.63.0/24

ABR R1

Zona 0 (Backbone)
172.20.96.0/24 pn la 172.20.127.0/24

ABR R2

Zona 2
172.20.64.0/24 pn la 172.20.95.0/24

Figura 5-22: Sumarizarea pe ABR Ruterul R2 va trebui configurat n felul urmtor:

R2(config)# router ospf 1 R2(config-router)# area 0 range 192.168.96.0 255.255.224.0 R2(config-router)# area 2 range 192.168.64.0 255.255.224.0

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 R1

Zona 1

ABR Zona 0 (Backbone) R2

ABR

Zona 2 R4

R3

Figura 5-23: Sumarizarea rutelor externe pe ASBR Pentru ruterul R1 vor trebui introduse umtoarele comenzi:
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

172.20.3.0/24

192.168.10.0/24

ASBR R1

Zona 1

ABR Zona 0 (Backbone) R2

ABR

ASBR R4

Zona 2

R3

0.0.0.0 Cost 100

Figura 5-24: Rute default Pe ruterul R1 se vor introduce urmtoarele comenzi:

0.0.0.0 Cost 10

R1(config)# ip route 0.0.0.0 172.20.3.1 R1(config)# router ospf 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 ospf 2 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

110 | P r o i e c t a r e a r e e l e l o r 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 S0/1 192.168.10.2 172.20.3.1/24

R1

S0/0

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

Pentru a configura ruterul R2 trebuie introduse urmtoarele comenzi:

R2(config)# interface S0/1 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. Pentru a configura ruterul R1 trebuie introduse urmtoarele comenzi:
R1(config)# interface S0/0 R1(config-if)# ip ospf message-digest-key 1 md5 secret R1(config-if)# ip ospf autentication message-digest

111 | O S P F Pentru a configura ruterul R2 trebuie introduse urmtoarele comenzi:

R2(config)# interface S0/1 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:
R1# show ip ospf neighbor Neighbor ID Interface 192.168.10.2 Serial0/0 Pri 1 State FULL/Dead Time 00:00:36 Address 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: Send with youngest Key 1 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 00:59:42: OSPF: Send DBD to 192.168.10.2 on Serial0/0 seq 0x2126 opt 0x42 flag 0x3 len 72 00:59:42: OSPF: Send with youngest Key 1 00:59:42: OSPF: Send with youngest Key 1 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 00:59:42: OSPF: Rcv DBD from 192.168.10.2 on Serial0/0 seq 0x2126 opt 0x42 flag 0x0 len 32 mtu 1500 state EXCHANGE 00:59:42: OSPF: Send DBD to 192.168.10.2 on Serial0/0 seq 0x2127 opt 0x42 flag 0x1len 32 00:59:42: OSPF: Send with youngest Key 1 00:59:42: OSPF: Send with youngest Key 1 00:59:42: OSPF: Rcv DBD from 192.168.10.2 on Serial0/0 seq 0x2127 opt 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 00:59:43: OSPF: Send with youngest Key 1 00:59:45: OSPF: Send with youngest Key 1

Se poate observa c autentificarea s-a realizat cu succes i s-a format o adiacen ntre cei doi vecini.

112 | P r o i e c t a r e a r e e l e l o r

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

Zona 1 Legtura virtual R2

ID 10.1.1.1 192.168.10.0/24

Zona 0 (Backbone)
10.0.0.0/8

R1

R3
ID 10.2.2.2

R4

Figura 5-26: Legturi virtuale 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 area 1 virtual-link 10.1.1.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 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 0:00:08 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:
R2# show ip ospf neighbor Neighbor ID Interface 10.10.10.1 FastEth0/0 10.2.2.2 10.2.2.2 Serial0/0 Pri 1 0 0 State FULL/DR FULL/FULL/Dead Time 00:00:35 00:00:36 Address 10.1.1.2 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 (Link Data) Router Interface address: 10.1.2.2 Number of TOS metrics: 0 TOS 0 Metrics: 1 Router Link States (Area 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

114 | P r o i e c t a r e a r e e l e l o r
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 (Link Data) Router Interface address: 192.168.10.2 Number of TOS metrics: 0 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 Number of TOS metrics: 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 capabilit ilor 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 Mercury F0/0 S1/0 .1 .3 10.0.0.0/24 F0/0 .1 .1 S1/0 Earth Loopback0 Loopback1 Loopback2 Loopback3

172.30.0.0/30 S1/0

.2

.2 F0/0

172.20.0.0/24 Loopback0 Loopback1 Loopback8 .2 S1/0 .1 F0/0 Mars .2 F0/0 Jupiter

Venus

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

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 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 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 Mars#show ip interface brief Interface IP-Address FastEthernet0/0 192.168.0.1 Serial1/0 172.20.0.2 Jupiter#show ip interface brief Interface IP-Address FastEthernet0/0 192.168.0.2 OK? Method Status YES manual up YES manual up OK? YES YES YES YES YES YES YES YES YES YES YES OK? YES YES YES YES YES YES Method manual manual manual manual manual manual manual manual manual manual manual Method manual manual manual manual manual manual Status up up up up up up up up up up up Status up up up up up up Protocol up up Protocol up up up up up up up up up up up Protocol up up up up up up Protocol up up Protocol up

OK? Method Status YES manual up YES manual up OK? Method Status YES manual 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

116 | P r o i e c t a r e a r e e l e l o r
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 [...] 202.1.96.0/32 is subnetted, 1 subnets O 202.1.96.1 [110/66] via 192.168.0.1, 00:01:29, FastEthernet0/0 201.1.39.0/32 is subnetted, 1 subnets O 201.1.39.1 [110/67] via 192.168.0.1, 00:01:29, FastEthernet0/0 202.1.97.0/32 is subnetted, 1 subnets O 202.1.97.1 [110/66] via 192.168.0.1, 00:01:29, FastEthernet0/0 201.1.38.0/32 is subnetted, 1 subnets O 201.1.38.1 [110/67] via 192.168.0.1, 00:01:29, FastEthernet0/0 202.1.98.0/32 is subnetted, 1 subnets O 202.1.98.1 [110/66] via 192.168.0.1, 00:01:29, FastEthernet0/0 201.1.37.0/32 is subnetted, 1 subnets O 201.1.37.1 [110/67] via 192.168.0.1, 00:01:29, FastEthernet0/0 202.1.99.0/32 is subnetted, 1 subnets O 202.1.99.1 [110/66] via 192.168.0.1, 00:01:29, FastEthernet0/0 201.1.36.0/32 is subnetted, 1 subnets O 201.1.36.1 [110/67] via 192.168.0.1, 00:01:29, FastEthernet0/0 201.1.35.0/32 is subnetted, 1 subnets O 201.1.35.1 [110/67] via 192.168.0.1, 00:01:29, FastEthernet0/0 201.1.34.0/32 is subnetted, 1 subnets O 201.1.34.1 [110/67] via 192.168.0.1, 00:01:29, FastEthernet0/0 201.1.33.0/32 is subnetted, 1 subnets O 201.1.33.1 [110/67] via 192.168.0.1, 00:01:29, FastEthernet0/0 172.20.0.0/30 is subnetted, 1 subnets O 172.20.0.0 [110/65] via 192.168.0.1, 00:01:29, FastEthernet0/0 172.30.0.0/30 is subnetted, 1 subnets O 172.30.0.0 [110/130] via 192.168.0.1, 00:01:29, FastEthernet0/0 201.1.32.0/32 is subnetted, 1 subnets O 201.1.32.1 [110/67] via 192.168.0.1, 00:01:29, FastEthernet0/0 10.0.0.0/24 is subnetted, 1 subnets O 10.0.0.0 [110/66] via 192.168.0.1, 00:01:29, FastEthernet0/0 C 192.168.0.0/24 is directly connected, FastEthernet0/0 201.1.40.0/32 is subnetted, 1 subnets O 201.1.40.1 [110/67] via 192.168.0.1, 00:01:29, FastEthernet0/0

Se observ c toate elele incluse n OSPF, alturi de reelele direct conectate, au fost re 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 precum Router ID -ul pentru procesul de OSPF pot fi vizualizate prin i comanda show ip protocols. Spre exemplu, pentru ruterul Mercury:
Mercury#show ip protocols Routing Protocol is "ospf 1" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Router ID 172.30.0.1 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Maximum path: 4 Routing for Networks: 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 Routing Information Sources: 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 re eaua 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) una de tip BDR cu Earth. Din acest i 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 FastEthernet0/0 is up, line protocol is up 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 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:07 Index 2/2, flood queue length 0 Next 0x0(0)/0x0(0)

118 | P r o i e c t a r e a r e e l e l o r
Last flood scan length is 0, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 2, Adjacent neighbor count is 2 Adjacent with neighbor 172.30.0.1 (Designated Router) 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 re multiacces n cauz se face, n principiu, ea 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 priorit unui ruter este ip ospf priority, se introduce ii 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 ospf 1 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 *Mar 1 03:00:40.555: %OSPF-5-ADJCHG: Process 1, Nbr 201.1.40.1 on FastEthernet0/0 from 2WAY to DOWN, Neighbor Down: Interface down or detached *Mar 1 03:00:40.555: %OSPF-5-ADJCHG: Process 1, Nbr 202.1.99.1 on 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 *Mar 1 03:00:59.567: %OSPF-5-ADJCHG: Process FastEthernet0/0 from LOADING to FULL, Loading *Mar 1 03:01:00.611: %OSPF-5-ADJCHG: Process 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 Neighbor Count is 2, Adjacent neighbor count is 2 Adjacent with neighbor 172.30.0.1 Adjacent with neighbor 202.1.99.1 (Designated Router)

Ruterul Earth a fost BDR a devenit automat DR dup ce a pierdut adiacena cu DR i 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 FULL/ Dead Time 00:00:35 00:00:37 00:00:34 Address 172.20.0.2 10.0.0.3 10.0.0.2

FULL/DROTHER FULL/BDR

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 OSPF Router with ID (202.1.99.1) (Process ID 1) Router Link States (Area 0) 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 (re eaua 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 folose te 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 Gateway of last resort is not set

120 | P r o i e c t a r e a r e e l e l o r Mercury nu va propaga o rut default atta timp ct el nsu nu deine o rut default n tabela i 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 [] Gateway of last resort is 10.0.0.3 to network 0.0.0.0 [] O*E2 0.0.0.0/0 [110/1] via 10.0.0.3, 00:00:03, FastEthernet0/0

Evident, se poate defini o rut default propriu -zis pe ruterul Mercury, iar defaulti information 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 ospf 1 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 n i 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 OSPF Router with ID (201.1.40.1) (Process ID 1) Router Link States (Area 0) 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

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 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 [...] 99.0.0.0/32 is subnetted, 1 subnets O E2 99.99.99.99 [110/20] via 10.0.0.3, 00:01:05, FastEthernet0/0

121 | O S P F
Jupiter#show ip route ospf [...] 99.0.0.0/32 is subnetted, 1 subnets O E2 99.99.99.99 [110/20] via 192.168.0.1, 00:01:55, FastEthernet0/0

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 Jupiter#show ip route ospf [...] 99.0.0.0/32 is subnetted, 1 subnets O E2 99.99.99.99 [110/99] via 192.168.0.1, 00:01:55, FastEthernet0/0

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 destinaii, ruterele trebuie s poat alege cea mai i eficient cale spre o anumit destinaextern. Pentru aceasta, rutele redistribuit ie e pot fi convertite la tipul E1, care adun la metrica implicit suma metricilor din interiorul domeniului i 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 [...] 99.0.0.0/32 is subnetted, 1 subnets O E1 99.99.99.99 [110/100] via 10.0.0.3, 00:00:06, FastEthernet0/0 Jupiter#show ip route ospf [...] 99.0.0.0/32 is subnetted, 1 subnets O E1 99.99.99.99 [110/165] via 192.168.0.1, 00:00:15, FastEthernet0/0

Pentru Venus, ruta are valoarea 100 deoarece acesta adaug 1 (108/108 pentru re ele FastEthernet) la metrica 99 de redistribuire. Jupiter vede reeaua cu metrica 165, obinut din 99 + 2x1 + 64, adic dou segmente FastEthernet un segment de linie serial (10 8/(1544*103) = 64 i 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.

122 | P r o i e c t a r e a r e e l e l o r

Area 0 Mercury F0/0 S1/0 .1 .3 10.0.0.0/24 F0/0 .1 Earth

202.1.[96..99].0/24 Loopback0 Loopback1 Loopback2 Loopback3 Area 200

.1 S1/0 Area 7 .2 S1/0 .1 F0/0 Mars .2 F0/0 Jupiter

172.30.0.0/30 S1/0

.2

.2 F0/0

172.20.0.0/24 Loopback0 Loopback1 Loopback8

Venus

192.168.0.0/24

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, re elele din arii diferite sunt anunate prin LSA -uri de tip 3 (summary). Pentru ruterul Jupiter din area 7, spre exemplu, elele din ariile 0, 100 i 200 sunt re 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

OSPF Router with ID (192.168.0.2) (Process ID 1) Link ID 192.168.0.1 192.168.0.2 202.1.99.1 Link ID 192.168.0.2 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 Link ID 172.30.0.1 Link ID 0.0.0.0 99.99.99.99 Router Link States (Area 7) ADV Router Age 192.168.0.1 27 192.168.0.2 58 202.1.99.1 337 Net Link States (Area 7) ADV Router Age 192.168.0.2 58 Seq# 0x80000005 0x80000004 0x80000004 Checksum 0x00C272 0x00F28F 0x00C78E Link count 3 1 2

Seq# Checksum 0x80000003 0x009AF0 Checksum 0x0026D9 0x00EA17 0x00FB21 0x00F02B 0x00E535 0x00DA3F 0x00CF49 0x00C453 0x00B95D 0x00AE67 0x00A371 0x0020BB 0x0015C5 0x000ACF 0x00FED9

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

Summary ASB Link States (Area 7) ADV Router Age Seq# Checksum 202.1.99.1 340 0x80000003 0x0062DA Type-5 AS External Link States ADV Router Age 172.30.0.1 676 172.30.0.1 928 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 [...] 202.1.96.0/32 is subnetted, 1 subnets O IA 202.1.96.1 [110/66] via 192.168.0.1, 201.1.39.0/32 is subnetted, 1 subnets O IA 201.1.39.1 [110/67] via 192.168.0.1, 202.1.97.0/32 is subnetted, 1 subnets O IA 202.1.97.1 [110/66] via 192.168.0.1, 201.1.38.0/32 is subnetted, 1 subnets O IA 201.1.38.1 [110/67] via 192.168.0.1, 202.1.98.0/32 is subnetted, 1 subnets O IA 202.1.98.1 [110/66] via 192.168.0.1, 201.1.37.0/32 is subnetted, 1 subnets [...]

01:09:56, FastEthernet0/0 01:18:10, FastEthernet0/0 01:09:56, FastEthernet0/0 01:18:10, FastEthernet0/0 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 , este convenabil sumarizarea fa reelelor de loopback de pe ambele rutere ntr-o singur re generic, urmnd ca doar aceast ea reea s fie anunat n Area 0.
Venus#show ip interface brief | inc Loop Loopback0 201.1.32.1 YES NVRAM up up

124 | P r o i e c t a r e a r e e l e l o r
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 Enter configuration commands, one per line. End with CNTL/Z. 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 ct n celelalte arii. O sumariza re similar se realizeaz i pentru i 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 End with CNTL/Z. Protocol up up up up

one per line.

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 [...] 99.0.0.0/32 is subnetted, 1 subnets O E1 99.99.99.99 [110/165] via 192.168.0.1, 00:01:22, FastEthernet0/0 172.20.0.0/30 is subnetted, 1 subnets O 172.20.0.0 [110/65] via 192.168.0.1, 01:30:54, FastEthernet0/0 172.30.0.0/30 is subnetted, 1 subnets O IA 172.30.0.0 [110/130] via 192.168.0.1, 01:30:54, FastEthernet0/0 10.0.0.0/24 is subnetted, 1 subnets O IA 10.0.0.0 [110/66] via 192.168.0.1, 01:30:54, FastEthernet0/0 C 192.168.0.0/24 is directly connected, FastEthernet0/0 O*E2 0.0.0.0/0 [110/1] via 192.168.0.1, 00:01:22, FastEthernet0/0 O IA 202.1.96.0/22 [110/66] via 192.168.0.1, 00:01:27, FastEthernet0/0 O IA 201.1.32.0/20 [110/67] via 192.168.0.1, 00:07:58, FastEthernet0/0

5.4.3.2 Arii Stub

Presupunnd c ruterele din aria 7 sunt mai pu performante, se poate lua decizia de a in converti aceast arie ntr-un Stub. Se specific acest lucru pe toate ruterele care au cel pu in o 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 Gateway of last resort is 192.168.0.1 to network 0.0.0.0 172.20.0.0/30 is subnetted, 1 subnets

125 | O S P F
O O IA O IA C O*IA O IA O IA 172.20.0.0 [110/65] via 192.168.0.1, 00:00:12, FastEthernet0/0 172.30.0.0/30 is subnetted, 1 subnets 172.30.0.0 [110/130] via 192.168.0.1, 00:00:12, FastEthernet0/0 10.0.0.0/24 is subnetted, 1 subnets 10.0.0.0 [110/66] via 192.168.0.1, 00:00:12, FastEthernet0/0 192.168.0.0/24 is directly connected, FastEthernet0/0 0.0.0.0/0 [110/66] via 192.168.0.1, 00:00:12, FastEthernet0/0 202.1.96.0/22 [110/66] via 192.168.0.1, 00:00:12, FastEthernet0/0 201.1.32.0/20 [110/67] via 192.168.0.1, 00:00:12, FastEthernet0/0

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 excepia 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 Gateway of last resort is 192.168.0.1 to network 0.0.0.0 172.20.0.0/30 is subnetted, 1 subnets O 172.20.0.0 [110/65] via 192.168.0.1, 00:06:50, FastEthernet0/0 C 192.168.0.0/24 is directly connected, FastEthernet0/0 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 OSPF Router with ID (192.168.0.2) (Process ID 1) Link ID 192.168.0.1 192.168.0.2 202.1.99.1 Link ID 192.168.0.2 Link ID 0.0.0.0 Router Link States (Area 7) ADV Router Age 192.168.0.1 674 192.168.0.2 389 202.1.99.1 682 Net Link States (Area 7) ADV Router Age 192.168.0.2 389 Seq# 0x80000008 0x80000007 0x80000007 Checksum 0x00DA59 0x000B76 0x00DF75 Link count 3 1 2

Seq# Checksum 0x80000006 0x00B2D7

Summary Net Link States (Area 7) ADV Router Age Seq# Checksum 202.1.99.1 264 0x80000002 0x00C844

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 LSA -urile 3 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

126 | P r o i e c t a r e a r e e l e l o r 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 printr -un LSA de tip 7 ca fiind de tip at N2:
Mars(config-router)#do sh ip route Gateway of last resort is 172.20.0.1 to network 0.0.0.0 172.20.0.0/30 is subnetted, 1 subnets C 172.20.0.0 is directly connected, Serial1/0 C 192.168.0.0/24 is directly connected, FastEthernet0/0 133.33.0.0/24 is subnetted, 1 subnets O N2 133.33.33.0 [110/180] via 192.168.0.2, 00:10:01, FastEthernet0/0 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 OSPF Router with ID (192.168.0.1) (Process ID 1) Router Link States (Area 7) 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

Net Link States (Area 7) Link ID 192.168.0.2 ADV Router 192.168.0.2 Age 677 Seq# Checksum 0x80000008 0x00364A

Summary Net Link States (Area 7) 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 133.33.33.0 [110/180] via 10.0.0.1, 00:12:25, FastEthernet0/0 O IA 202.1.96.0/22 [110/2] via 10.0.0.1, 00:13:09, FastEthernet0/0 O IA 201.1.32.0/20 [110/2] via 10.0.0.2, 00:13:09, FastEthernet0/0

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 Type-5 AS External Link States 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 ip ospf message-digest-key 1 md5 cisco ! 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 interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.0 ip ospf message-digest-key 1 md5 cisco ! 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 0 authentication message-digest 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 interface FastEthernet0/0 ip address 192.168.0.1 255.255.255.0 ip ospf authentication ip ospf authentication-key ciscolan ! interface Serial1/0 ip address 172.20.0.2 255.255.255.252 ip ospf authentication ip ospf authentication-key ciscokey ! router ospf 1 area 7 authentication

128 | P r o i e c t a r e a r e e l e l o r
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 Mercury F0/0 S1/0 .1 .3 10.0.0.0/24 F0/0 .1 .1 S1/0 Earth 202.1.[96..99].0/24 Loopback0 Loopback1 Loopback2 Loopback3 Area 200

Virtual link

172.30.0.0/30 S1/0

.2

.2 F0/0

172.20.0.0/24 Area 7 Loopback0 Loopback1 Loopback8 .2 S1/0 .1 F0/0 Mars Area 0 .2 F0/0 Jupiter 192.168.0.0/24

Venus

201.1.[32..40].0/24 Area 100 Figura 5-29: Topologie multi-area cu virtual link Pentru topologia curent, legtura dintre Mars Jupiter va fi trecut n Area 0 iar legtura i dintre Earth i Mars va rmne n Area 7. Cele dou arii 0 distincte trebuie conectate cu o legtur virtual configurat ntre Earth Mars. Totodat, trebuie avute n vedere dou elemente de i 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 Mars Jupiter ca membru n Area 0, interfeele din i 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 relevante pentru crearea legt urii virtuale iile 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 ip ospf authentication ip ospf authentication-key ciscokey ! router ospf 1 area 0 authentication message-digest area 7 authentication 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 interface FastEthernet0/0 ip address 192.168.0.1 255.255.255.0 ip ospf authentication ip ospf authentication-key ciscolan ip ospf message-digest-key 1 md5 cisco ! interface Serial1/0 ip address 172.20.0.2 255.255.255.252 ip ospf authentication ip ospf authentication-key ciscokey ! router ospf 1 area 0 authentication message-digest area 1 virtual-link 202.1.99.1 area 7 authentication 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 interface FastEthernet0/0 ip address 192.168.0.2 255.255.255.0 ip ospf authentication ip ospf authentication-key ciscolan ip ospf message-digest-key 1 md5 cisco ! router ospf 1 area 0 authentication message-digest area 7 authentication 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:

130 | P r o i e c t a r e a r e e l e l o r
Jupiter(config-if)#do sh ip route Gateway of last resort is not set 172.20.0.0/30 is subnetted, 1 subnets O IA 172.20.0.0 [110/65] via 192.168.0.1, 00:00:07, FastEthernet0/0 C 192.168.0.0/24 is directly connected, FastEthernet0/0 133.33.0.0/24 is subnetted, 1 subnets S 133.33.33.0 is directly connected, Null0

Dup configurarea legturii virtuale, tabela de rutare a lui Jupiter eaz rutele comunicate afi din toate ariile:
Jupiter#sh ip route Gateway of last resort is 192.168.0.1 to network 0.0.0.0 99.0.0.0/32 is subnetted, 1 subnets O E1 99.99.99.99 [110/165] via 192.168.0.1, 00:00:33, FastEthernet0/0 172.20.0.0/30 is subnetted, 1 subnets O IA 172.20.0.0 [110/65] via 192.168.0.1, 00:00:33, FastEthernet0/0 172.30.0.0/30 is subnetted, 1 subnets O 172.30.0.0 [110/130] via 192.168.0.1, 00:00:33, FastEthernet0/0 10.0.0.0/24 is subnetted, 1 subnets O 10.0.0.0 [110/66] via 192.168.0.1, 00:00:33, FastEthernet0/0 C 192.168.0.0/24 is directly connected, FastEthernet0/0 133.33.0.0/24 is subnetted, 1 subnets S 133.33.33.0 is directly connected, Null0 O*E2 0.0.0.0/0 [110/1] via 192.168.0.1, 00:00:33, FastEthernet0/0 O IA 202.1.96.0/22 [110/66] via 192.168.0.1, 00:00:33, FastEthernet0/0 O IA 201.1.32.0/20 [110/67] via 192.168.0.1, 00:00:34, FastEthernet0/0

O observa important n acest caz este faptul c Jupiter vede acum ruta spre reeaua ie 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 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 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 guvernamentale trebuiau s fie institu 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

132 | P r o i e c t a r e a r e e l e l o r 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 Rutare de nivel 2 ntre ariile aceluai domeniu. Rutare de nivel 1 ntre IS-uri din aceeeai arie. ES Rutare de nivel 0 ntre ES i IS. Figura 6-1: Rutarea n ISIS

Area1

IS

IS

ES

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.

134 | P r o i e c t a r e a r e e l e l o r

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 acela tip, indiferent i de coninut. n locul LSA-urilor trimise pentru fiecare informaie ce trebuie actualizat, n OSPF, ISIS trimite toate informa iile 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 ruterelor pe care le vor folosi pe post de gateway. Din moment ce sta a iile configurate cu protocolul IP nu efectueaz rutare de nivel 0, ele nu vor rspunde ISH-urilor, deci

136 | P r o i e c t a r e a r e e l e l o r aceste hello-uri nu vor fi folosite, iar ruterele vor considera c ata la topologie un ntreg eaz 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 se stabilesc separat pentru ele nivelurile 1 i 2, LSP -urile sunt, de asemenea, transmise astfel nct informa de nivel 1 este ia 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 informa iile din SNP sunt mai recente dect cele din propria baz de date pot cere i informaii actualizate, ce vor fi primite sub forma unor LSP-uri. Mesajele SNP pot lista ntreaga baz de date a strilor legturilor unui ruter se vor numi CSNP ( Complete SNP) sau pot lista doar un i subset al lor, ca n cazul apari unor modificri izolate n topologie, i se vor numi PSNP (Partial iei 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 adiacen ntre dou rutere este mesajul de tip IIH a (Intermediate-to-Intermediate Hello), ce func ioneaz asemenea unui protocol de tip hello, ntlnit att n OSPF ct n EIGRP. IIH -urile sunt schimbate doar ntre rutere adiacente sunt i i 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 de tip ea broadcast este una multiacces, n care pot exista o multitudine de rutere L1 L2, ceea ce creeaz i 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 L1-2 L2 Area3

IS

L1-2 L1 Area 0001 L1 L1-2

Area1 L1-2 Area 0003

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

138 | P r o i e c t a r e a r e e l e l o r 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.

6.3 Configurarea protocolului

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: 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 Cluj(config)#router isis Cluj(config-router)#is-type level-1

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)#interface serial1/0 R1(config-if)#ip route isis R1(config-if)#isis priority 127

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.

140 | P r o i e c t a r e a r e e l e l o r 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 isis 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)#interface serial1/0 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 Serial1/0 is up, line protocol is up 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 Level-2 IPv6 Metric: 10 Number of active level-2 adjacencies: 1 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:

142 | P r o i e c t a r e a r e e l e l o r
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 LSP Holdtime 742 677 ATT/P/OL 0/0/0 0/0/0 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 192.168.1.0/30 10.0.1.0/24 10.0.3.0/24 Iai

10.0.2.0/24

SW0

172.17.123.0/24 Figura 6-4 Topologia reelei de test

143 | I S - I S

6.4.1 Configurri de baz

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 Arad#show ip interface brief | include up FastEthernet0/0 172.17.123.2 Serial1/0 192.168.1.1 Loopback0 10.0.2.1 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 YES manual up YES manual up YES manual up YES manual up YES manual up up up up up 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 isis Cluj(config-router)#net 49.0001.aaaa.aaaa.aaaa.00 Cluj(config-router)#interface fastethernet 0/0 Cluj(config-if)#ip router isis Cluj(config-if)#interface loopback0 Cluj(config-if)#ip router isis 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)#ip router isis Arad(config-if)#interface fastethernet0/0 Arad(config-if)#ip router isis 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)#ip router isis Iasi(config-if)#interface loopback0 Iasi(config-if)#ip router isis

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

144 | P r o i e c t a r e a r e e l e l o r 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 Area Address(es): 49.0001 IP Address(es): 172.17.123.1* Uptime: 00:01:08 NSF capable Arad Fa0/0 cc01.300c.0000 Area Address(es): 49.0001 IP Address(es): 172.17.123.2* Uptime: 00:01:08 NSF capable Arad Se1/0 *HDLC* Area Address(es): 49.0001 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

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 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

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 10.0.0.0/24 is subnetted, 3 subnets

145 | I S - I S
i L1 i L1 10.0.2.0 [115/20] via 172.17.123.2, FastEthernet0/0 10.0.3.0 [115/20] via 172.17.123.3, FastEthernet0/0 192.168.1.0/30 is subnetted, 1 subnets i L1 192.168.1.0 [115/20] via 172.17.123.2, FastEthernet0/0 [115/20] via 172.17.123.3, FastEthernet0/0 Arad#show ip route isis 10.0.0.0/24 is subnetted, 3 subnets i L1 10.0.3.0 [115/20] via 172.17.123.3, FastEthernet0/0 [115/20] via 192.168.1.2, Serial1/0 i L1 10.0.1.0 [115/20] via 172.17.123.1, FastEthernet0/0 Iasi#show ip route isis 10.0.0.0/24 is subnetted, 3 subnets i L1 10.0.2.0 [115/20] via 172.17.123.2, FastEthernet0/0 [115/20] via 192.168.1.1, Serial1/0 i L1 10.0.1.0 [115/20] via 172.17.123.1, FastEthernet0/0

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 FastEthernet0/0 is up, line protocol is up Checksums enabled, MTU 1497, Encapsulation SAP 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 35 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x1, local circuit ID 0x1 Level-1 Metric: 10, Priority: 64, Circuit ID: Iasi.01 Level-1 IPv6 Metric: 10 Number of active level-1 adjacencies: 2 Level-2 Metric: 10, Priority: 64, Circuit ID: Iasi.01 Level-2 IPv6 Metric: 10 Number of active level-2 adjacencies: 2 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

146 | P r o i e c t a r e a r e e l e l o r 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 FastEthernet0/0 is up, line protocol is up Checksums enabled, MTU 1497, Encapsulation SAP 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 2 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x1, local circuit ID 0x1 Level-1 Metric: 10, Priority: 64, Circuit ID: Arad.02 Level-1 IPv6 Metric: 10 Number of active level-1 adjacencies: 2 Level-2 Metric: 10, Priority: 64, Circuit ID: Arad.02 Level-2 IPv6 Metric: 10 Number of active level-2 adjacencies: 2 Next IS-IS LAN Level-1 Hello in 7 seconds Next IS-IS LAN Level-2 Hello in 8 seconds

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:
FastEthernet0/0 is up, line protocol is up Checksums enabled, MTU 1497, Encapsulation SAP 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 4 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x1, local circuit ID 0x1 Level-1 Metric: 10, Priority: 64, Circuit ID: Cluj.01 Level-1 IPv6 Metric: 10 Number of active level-1 adjacencies: 2 Level-2 Metric: 10, Priority: 64, Circuit ID: Arad.02 Level-2 IPv6 Metric: 10 Number of active level-2 adjacencies: 2 Next IS-IS LAN Level-1 Hello in 850 milliseconds Next IS-IS LAN Level-2 Hello in 435 milliseconds

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 192.168.1.0/30 is subnetted, 1 subnets i L1 192.168.1.0 [115/20] via 172.17.123.2, FastEthernet0/0 [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 192.168.1.0/30 is subnetted, 1 subnets i L1 192.168.1.0 [115/15] via 172.17.123.3, FastEthernet0/0

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 Fa0/0 SNPA cc00.300c.0000 State Init Holdtime 29 Type L1L2 IS-IS

148 | P r o i e c t a r e a r e e l e l o r
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 10.0.0.0/24 is subnetted, 2 subnets 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 isis 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);

150 | P r o i e c t a r e a r e e l e l o r

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 R2 EIGRP R3

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]

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.

152 | P r o i e c t a r e a r e e l e l o r

RIP

R2

OSPF

LAN

Compania A R1

Compania B 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.

153 | O p t i m i z a r e a r u t r i i 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.

RIP

R2

EIGRP

OSPF

LAN

Compania A R1

Compania B 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.

154 | P r o i e c t a r e a r e e l e l o r

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

155 | O p t i m i z a r e a r u t r i i 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 R1 Fa0/0

11.11.11.196/30

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.16/28

11.11.11.96/28

R1 Fa0/0

11.11.11.32/28

11.11.11.80/28 11.11.11.64/28

11.11.11.48/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

156 | P r o i e c t a r e a r e e l e l o r 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

R2

OSPF

LAN

Compania A R1

Compania B 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.

157 | O p t i m i z a r e a r u t r i i

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

158 | P r o i e c t a r e a r e e l e l o r

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

159 | O p t i m i z a r e a r u t r i i 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.

160 | P r o i e c t a r e a r e e l e l o r
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 pentru a ob ine 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 a fi rutare parametrul route-map prin care se pot identificaele specifice ce se doresc 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 acela nume. Aciunea pentru aceast intrarea este incrementarea metricii de i 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.

161 | O p t i m i z a r e a r u t r i i

7.3.2 Configurarea filtrrii rutelor

Una dintre cele mai cunoscute utilizate metode de filtrare a rutelor este mecanismul i distribute-list. Acest tip special de list de acces este folosit pentru a identificaele din re 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 con reelele 10.10.1.0/24 i 192.168.1.0/24 n cadrul in 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 sa Serial1/0. Este necesar mult atenie la configurarea unui a 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 realizate n configurri de filtrare este omiterea directivei eli 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 ieire. Dup de 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.

162 | P r o i e c t a r e a r e e l e l o r n exemplul de mai jos, ruterul va trimite toate pachetele cu adres surs din re eaua 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 interfe de ieire n cazul n care ei 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. RIP 10.0.0.8/30 Fa1/ Fa1/ R1 L0 84.34.18.0/25 E0/1 10.0.0.20/30 R3 L0 Fa1/ Fa1/ 10.0.0.12/30 D2 E0/0 OSPF

Fa0/ 10.0.0.0/30 Fa0/ R2 Fa1/ 10.0.0.4/30 Fa0/

E0/0 D1 10.0.0.16/30 E0/0 E1

E2 10.0.0.24/30 E0/2 E0/3 10.0.0.28/30 E0/0 E3 L0

E0/0

L0

Internet

84.34.18.128/25 Figura 7-9: Propagarea rutei implicite

163 | O p t i m i z a r e a r u t r i i

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 R2#show ip interface brief | include up FastEthernet0/0 10.0.0.2 FastEthernet1/0 10.0.0.5 R3#sh ip interface brief | include up FastEthernet0/0 10.0.0.6 FastEthernet1/0 10.0.0.13 Loopback0 84.34.18.129 D1#show ip interface brief | include up Ethernet0/0 10.0.0.17 FastEthernet1/0 10.0.0.10 D2#show ip interface brief | include up Ethernet0/0 10.0.0.21 FastEthernet1/0 10.0.0.14 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 E2#show ip interface brief | include up Ethernet0/0 10.0.0.26 Loopback0 84.34.19.1 E3#show ip interface brief | include up Ethernet0/0 10.0.0.30 Loopback0 84.34.19.5 YES manual up YES manual up YES manual up YES manual up YES manual up YES manual up YES manual up YES manual up YES manual up YES manual up up up up up up up up up up up

YES manual up YES manual up YES YES YES YES manual manual manual manual up up up up

up up up up up up up up up up

YES manual up YES manual up YES manual up YES manual up

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.
R1(config)#router rip R1(config-router)#no auto-summary R1(config-router)#version 2 R1(config-router)#network 10.0.0.0 R1(config-router)#network 84.0.0.0 R2(config)#router rip R2(config-router)#no auto-summary R2(config-router)#version 2 R2(config-router)#network 10.0.0.0 R3(config)#router rip R3(config-router)#no auto-summary R3(config-router)#version 2 R3(config-router)#network 10.0.0.0

164 | P r o i e c t a r e a r e e l e l o r
R3(config-router)#network 84.0.0.0 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 rip 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)#exit D2(config)#router ospf 1 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 ospf 1 E2(config-router)#network 10.0.0.0 0.255.255.255 area 0 E2(config-router)#network 84.0.0.0 0.255.255.255 area 0 E2(config-router)#default-information originate E3(config)#ip route 0.0.0.0 0.0.0.0 loopback 0 E3(config)#router ospf 1 E3(config-router)#network 10.0.0.0 0.255.255.255 area 0 E3(config-router)#network 84.0.0.0 0.255.255.255 area 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 Gateway of last resort is 10.0.0.18 to network 0.0.0.0 84.0.0.0/25 is subnetted, 2 subnets 84.34.18.0 [120/1] via 10.0.0.9, 00:00:16, FastEthernet1/0 84.34.18.128 [120/3] via 10.0.0.9, 00:00:16, FastEthernet1/0 10.0.0.0/30 is subnetted, 8 subnets C 10.0.0.8 is directly connected, FastEthernet1/0 R 10.0.0.12 [120/3] via 10.0.0.9, 00:00:16, FastEthernet1/0 R 10.0.0.0 [120/1] via 10.0.0.9, 00:00:16, FastEthernet1/0 R 10.0.0.4 [120/2] via 10.0.0.9, 00:00:16, FastEthernet1/0 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 10.0.0.16 is directly connected, Ethernet0/0 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:

165 | O p t i m i z a r e a r u t r i i
R1#sh ip route Gateway of last resort is not set C R C R C R R R 84.0.0.0/25 is subnetted, 2 subnets 84.34.18.0 is directly connected, Loopback0 84.34.18.128 [120/2] via 10.0.0.2, 00:00:23, FastEthernet0/0 10.0.0.0/30 is subnetted, 6 subnets 10.0.0.8 is directly connected, FastEthernet1/0 10.0.0.12 [120/2] via 10.0.0.2, 00:00:23, FastEthernet0/0 10.0.0.0 is directly connected, FastEthernet0/0 10.0.0.4 [120/1] via 10.0.0.2, 00:00:23, FastEthernet0/0 10.0.0.16 [120/1] via 10.0.0.10, 00:00:01, FastEthernet1/0 10.0.0.20 [120/3] via 10.0.0.2, 00:00:23, FastEthernet0/0

Pe E1, tabela de rutare arat astfel:

E1#sh ip route Gateway of last resort is 10.0.0.30 to network 0.0.0.0 10.0.0.0/30 is subnetted, 4 subnets C 10.0.0.24 is directly connected, Ethernet0/2 C 10.0.0.28 is directly connected, Ethernet0/3 C 10.0.0.16 is directly connected, Ethernet0/0 C 10.0.0.20 is directly connected, Ethernet0/1 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 ospf 1 D1(config-router)#redistribute rip subnets D1(config-router)#exit D1(config)#router rip D1(config-router)#redistribute ospf 1 metric 1 D2(config)#router ospf 1 D2(config-router)#redistribute rip subnets D2(config-router)#exit D2(config)#router rip D2(config-router)#redistribute ospf 1 metric 1

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 Gateway of last resort is 10.0.0.10 to network 0.0.0.0 C R C 84.0.0.0/25 is subnetted, 2 subnets 84.34.18.0 is directly connected, Loopback0 84.34.18.128 [120/2] via 10.0.0.2, 00:00:00, FastEthernet0/0 10.0.0.0/30 is subnetted, 8 subnets 10.0.0.8 is directly connected, FastEthernet1/0

166 | P r o i e c t a r e a r e e l e l o r
R C R R R R R R* 10.0.0.12 [120/1] via 10.0.0.10, 00:00:09, FastEthernet1/0 10.0.0.0 is directly connected, FastEthernet0/0 10.0.0.4 [120/1] via 10.0.0.2, 00:00:00, FastEthernet0/0 10.0.0.24 [120/1] via 10.0.0.10, 00:00:09, FastEthernet1/0 10.0.0.28 [120/1] via 10.0.0.10, 00:00:09, FastEthernet1/0 10.0.0.16 [120/1] via 10.0.0.10, 00:00:09, FastEthernet1/0 10.0.0.20 [120/1] via 10.0.0.10, 00:00:09, FastEthernet1/0 0.0.0.0/0 [120/1] via 10.0.0.10, 00:00:09, FastEthernet1/0

E1#show ip route Gateway of last resort is 10.0.0.30 to network 0.0.0.0 O E2 O E2 O E2 O E2 O E2 O E2 C C C C O*E2 84.0.0.0/25 is subnetted, 2 subnets 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.0/30 is subnetted, 8 subnets 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 10.0.0.24 is directly connected, Ethernet0/2 10.0.0.28 is directly connected, Ethernet0/3 10.0.0.16 is directly connected, Ethernet0/0 10.0.0.20 is directly connected, Ethernet0/1 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.
D1(config)#router rip D1(config-router)#redistribute ospf 1 metric 5 D2(config)#router rip D2(config-router)#redistribute ospf 1 metric 5 R1#sh ip route

167 | O p t i m i z a r e a r u t r i i
Gateway of last resort is 10.0.0.10 to network 0.0.0.0 C R C R C R R R R R R* 84.0.0.0/25 is subnetted, 2 subnets 84.34.18.0 is directly connected, Loopback0 84.34.18.128 [120/2] via 10.0.0.2, 00:00:15, FastEthernet0/0 10.0.0.0/30 is subnetted, 8 subnets 10.0.0.8 is directly connected, FastEthernet1/0 10.0.0.12 [120/2] via 10.0.0.2, 00:00:15, FastEthernet0/0 10.0.0.0 is directly connected, FastEthernet0/0 10.0.0.4 [120/1] via 10.0.0.2, 00:00:15, FastEthernet0/0 10.0.0.24 [120/5] via 10.0.0.10, 00:00:04, FastEthernet1/0 10.0.0.28 [120/5] via 10.0.0.10, 00:00:04, FastEthernet1/0 10.0.0.16 [120/1] via 10.0.0.10, 00:00:04, FastEthernet1/0 10.0.0.20 [120/3] via 10.0.0.2, 00:00:15, FastEthernet0/0 0.0.0.0/0 [120/5] via 10.0.0.10, 00:00:04, FastEthernet1/0

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 deny 10.0.0.0 0.0.0.3 D1(config)#access-list 10 deny 10.0.0.4 0.0.0.3 D1(config)#access-list 10 deny 10.0.0.8 0.0.0.3 D1(config)#access-list 10 deny 10.0.0.12 0.0.0.3 D1(config)#access-list 10 permit any D1(config)#router ospf 1 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 Gateway of last resort is 10.0.0.10 to network 0.0.0.0 C R C R C R R R R R R* 84.0.0.0/25 is subnetted, 2 subnets 84.34.18.0 is directly connected, Loopback0 84.34.18.128 [120/2] via 10.0.0.2, 00:00:16, FastEthernet0/0 10.0.0.0/30 is subnetted, 8 subnets 10.0.0.8 is directly connected, FastEthernet1/0 10.0.0.12 [120/2] via 10.0.0.2, 00:00:16, FastEthernet0/0 10.0.0.0 is directly connected, FastEthernet0/0 10.0.0.4 [120/1] via 10.0.0.2, 00:00:16, FastEthernet0/0 10.0.0.24 [120/1] via 10.0.0.10, 00:00:15, FastEthernet1/0 10.0.0.28 [120/1] via 10.0.0.10, 00:00:15, FastEthernet1/0 10.0.0.16 [120/1] via 10.0.0.10, 00:00:15, FastEthernet1/0 10.0.0.20 [120/1] via 10.0.0.10, 00:00:15, FastEthernet1/0 0.0.0.0/0 [120/1] via 10.0.0.10, 00:00:15, FastEthernet1/0

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.

168 | P r o i e c t a r e a r e e l e l o r 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 de rutere (i eventual alte echipamente de reea) aflate sub un ie 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 o nou clas de protocoale, aa te -

170 | P r o i e c t a r e a r e e l e l o r 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 4 (nota ie 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 fiecare re ea 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 prime un update care conine propriul su ASN n AS_PATH, va ignora update-ul te 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. Comunica cu vecinii este ntotdeauna unicast, iar protocolul folosit ia pentru comunicaie este TCP, port 179. Sesiunea TCP este stabilit la nceperea comunica ntre doi vecini, moment n care se iei 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 pentru vecinii ce nu sunt direct i conectai, ci sunt situai la mai multe hopuri distan, dar cunosc rutele necesarei pot comunica prin intermediul altor rutere (aceast abordare prezint unele particularit care vor fi discutate i, 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 acela AS, vor exista 50*49/2 = 1225 conexiuni iBGP. Exist soluii pentru scderea i

172 | P r o i e c t a r e a r e e l e l o r 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 cum s ajung la 172.27.11.1). Pentru a evita tie 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 Dar R2 ie. nu ruleaz dect IGP-ul din AS 65200 (OSPF, n exemplul nostru), nu BGP. Ca urmare, R2 nu are i 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 men ionat 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 adiacen ruterele BGP fac schimb ei, 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 BGP poate controla direcionarea ie, 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 folose o singur m etric pentru a decide cea mai bun te 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

174 | P r o i e c t a r e a r e e l e l o r 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 recunoa va trimite atributul te 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 mai multe rute ctre aceeai destinaie, cu ORIGIN diferit, va te 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 destina specific at n update. Fiecare ruter BGP care trimite ia 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, se va i 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 influen area 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

176 | P r o i e c t a r e a r e e l e l o r 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 Conform RFC 1997, acesta este de forma AA:NN i. 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 influen eaz 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 mai multe update-uri referitoare la aceea te i 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 WEIGHTLOCAL_PREF i 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 configura se realizeaz pe acesta. Configuraia const n definirea unei ia liste de clieni pentru care route-reflector-ul s fac excepia mai sus menionat. R2 AS 100 R1 E2/1 E2/2 R4 R3

E2/2 E2/1

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

178 | P r o i e c t a r e a r e e l e l o r 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 asupra unei greeli des ntlnite n aten te configuraiile de route-reflectors. Cnd se folose 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.

8.3 Configurarea protocolului

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 ntr iile BGP -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 prime ca i parametru att cuvntul te 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 re ea precum cea din figura de mai jos, cerin este de a realiza o sesiune iBGP ntre ruterul R1 i R2. De a 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 R3(config-router)#neighbor 10.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 dorete 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 10.0.0.1 Lo0 R1

OSPF 11.0.1.1

E2/2 E2/1

iBGP

E2/1 E2/2

R3

Lo0

10.0.1.1

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 celor dou rutere va ncepe s fac ele 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 realizarea te unei sesiuni BGP folosind interfe de loopback, va trebui s introduc re ele 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 bgp 100 R1(config-router)# neighbor 11.0.1.1 remote-as 100 R3(config)#router ospf 1 R3(config-router)#redistribute connected route-map all_loopbacks subnets R3(config-router)#exit R3(config)#route-map all_loopbacks permit 10 R3(config-route-map)#match interface Loopback0 R3(config-route-map)#exit
1

Fenomenul n care o interfa oscileaz ntre strile up/down.

180 | P r o i e c t a r e a r e e l e l o r
R3(config)#router bgp 100 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 normal apare din cauza faptului c fiecare vecin n mod implicit i 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 s vad IP -ul configurat a 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 gata pentru funcionare n i este 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 s dore 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 informa la transmiterea rutelor. Astfel, cnd R1 va trimite lui ie R3 rutele nv ate 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 solu scalabil i nici o practic indicat. Un ruter din interiorul unui ie 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 R3(config-router)#neighbor 10.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 10.0.0.1 Lo0 R1

AS 200 11.0.1.1 eBGP E2/1 E2/2 11.0.0.1 R3 Lo0

E2/2 E2/1

10.0.1.1

Figura 8-5: Configurarea adiacenei eBGP Se vor folosi aceleai rutere ca protagoniti ai scenariului dar de data aceasta n AS-uri diferite.
R1(config)#router bgp 100 R1(config-router)#neighbor 11.0.0.1 remote-as 200 R3(config)#router bgp 200 R3(config-router)#neighbor 10.0.0.1 remote-as 100

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 bgp 100 R1(config-router)#neighbor 11.0.1.1 remote-as 200 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 R3(config)#router bgp 200 R3(config-router)#neighbor 10.0.1.1 remote-as 100 R3(config-router)#neighbor 10.0.1.1 update-source Loopback 0

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 de ele Loopback pentru stabilirea adiacen elor, TTL -ul va fi decrementat la rutarea spre loopback iar pachetul va fi aruncat.

182 | P r o i e c t a r e a r e e l e l o r 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 organiza poate controla fluxul de date care intr i care iese din ie 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 dorete modificat, BGP are nevoie de folosirea unui route map 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 n care traficul s se ndrepte n afara AS -ului. Valoarea implicita a ia 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-route-map)#exit R1(config)#router bgp 100 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 R1(config-std-nacl)#permit 74.125.77.104 0.0.255.255 R1(config-std-nacl)#permit 216.239.59.104 0.0.31.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 dore ca i traficul de ntoarcere de la google s vin pe aceeai legtur trebuie te 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 configuraie 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

184 | P r o i e c t a r e a r e e l e l o r Iniial, ambele conexiuni au fost oferite de ctre acelaISP (ISP2), dar acest lucru a dus la i 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 achizi ionarea 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 eBGP se stabilesc ntre vecini direct conectai, folosind ele 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.
R1(config)#router bgp 65100 R1(config-router)#neighbor 172.16.1.1 remote-as 65200

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

SP2(config)#router bgp 65300 SP2(config-router)#neighbor 172.16.11.1 remote-as 65200 SP2(config-router)#neighbor 172.16.2.2 remote-as 65100 *Mar 1 00:15:17.595: %BGP-5-ADJCHANGE: neighbor 172.16.11.1 Up

SP3(config)#router bgp 65300 SP3(config-router)#neighbor 172.16.2.6 remote-as 65100

R4(config)#router bgp 65100 R4(config-router)#neighbor 172.16.2.1 remote-as 65300 R4(config-router)#neighbor 172.16.2.5 remote-as 65300 *Mar 1 00:16:41.983: %BGP-5-ADJCHANGE: neighbor 172.16.2.1 Up *Mar 1 00:18:13.351: %BGP-5-ADJCHANGE: neighbor 172.16.2.5 Up

Adiacenele iBGP pot fi stabilite ntre adresele direct conectate (cazul SP2-SP3), sau ntre adresele altor interfe n mod frecvent fiind folosite n acest scop adresele interfeelor de e, loopback. Deoarece adresa destinaie configurat pe unul dintre rutere trebuie s fie aceeai cu adresa IP surs folosit de vecinul su, n cazul adiacen elor 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 R4 au configurate interfe Loopback 0 cu adresele IP i ele 192.168.100.1/32, respectiv 192.168.100.4/32.

185 | B G P
R1(config)#router bgp 65100 R1(config-router)#neighbor 192.168.100.4 remote-as 65100 R1(config-router)#neighbor 192.168.100.4 update-source Loopback 0 R4(config)#router bgp 65100 R4(config-router)#neighbor 192.168.100.1 remote-as 65100 R4(config-router)#neighbor 192.168.100.1 update-source Loopback 0 SP2(config-router)#router bgp 65300 SP2(config-router)#neighbor 10.0.1.2 remote-as 65300 SP3(config-router)#router bgp 65300 SP3(config-router)#neighbor 10.0.1.1 remote-as 65300 *Mar 1 00:28:58.919: %BGP-5-ADJCHANGE: neighbor 10.0.1.1 Up

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 V AS MsgRcvd MsgSent 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

4 65300 4 65300 4 65100

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 Spre ate. deosebire de IGP-uri, n BGP prefixele anun ate 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.

186 | P r o i e c t a r e a r e e l e l o r 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 anun prefixul 172.16.11.0/30 (direct conectat), iar SP2 va anuna 10.0.1.0/30 a (tot direct conectat).
R1(config)#router bgp 65100 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 bgp 65200 SP1(config-router)#network 172.16.11.0 mask 255.255.255.252 SP2(config)#router bgp 65300 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 BGP table version is 7, local router ID is 192.168.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 * 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 Metric LocPrf Weight Path 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), ca i 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 172.16.0.0/30 is subnetted, 3 subnets B 172.16.11.0 [20/0] via 172.16.2.1, 00:13:08 10.0.0.0/30 is subnetted, 1 subnets 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 BGP table version is 5, local router ID is 192.168.100.1 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 *> 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).
R1(config)#router bgp 65100 R1(config-router)#neighbor 192.168.100.4 next-hop-self

R4(config)#router bgp 65100 R4(config-router)#neighbor 192.168.100.1 next-hop-self

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 BGP table version is 6, local router ID is 192.168.100.1 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 * 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

188 | P r o i e c t a r e a r e e l e l o r Aceeai configuraie este necesar i pentru SP2 i SP3:

SP2(config-router)#router bgp 65300 SP2(config-router)#neighbor 10.0.1.2 next-hop-self

SP3(config-router)#router bgp 65300 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.0.0/30 is subnetted, 2 subnets 172.16.11.0 [20/0] via 172.16.1.1, 00:19:32 172.16.1.0 is directly connected, Serial0/1 10.0.0.0/30 is subnetted, 1 subnets 10.0.1.0 [200/0] via 192.168.100.4, 00:12:42 192.168.1.0/24 is directly connected, Serial0/0 192.168.2.0/30 is subnetted, 1 subnets 192.168.2.0 [110/192] via 192.168.1.2, 00:54:03, Serial0/0 192.168.100.0/32 is subnetted, 2 subnets 192.168.100.4 [110/193] via 192.168.1.2, 00:54:03, Serial0/0 192.168.100.1 is directly connected, Loopback0 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 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.1, timeout is 2 seconds: 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 respectiv se pierd. Este vorba din ia 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, adiacen iBGP dintre R1 i R4 sare peste R2 i R3. n schimb, pachetele de a date trimise de la R1 ctre R4 vor trebui ns s treac prin R2 R3. n momentul n care pachetul i 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 din afara AS -ului propriu). Ca iile 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 ospf 1 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 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.1, timeout is 2 seconds: Packet sent with a source address of 192.168.100.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/67/120 ms

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-route-map)#exit R4(config)#router bgp 65100 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(config-router)#^Z 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:

190 | P r o i e c t a r e a r e e l e l o r
R4#show ip bgp BGP table version is 14, local router ID is 192.168.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 * 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 Metric LocPrf Weight Path 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 172.16.0.0/30 is subnetted, 3 subnets B 172.16.11.0 [20/0] via 172.16.2.5, 00:04:44 10.0.0.0/30 is subnetted, 1 subnets 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, ca urmare vom seta MED la 50 i 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)#exit R4(config)#route-map MED_100 permit 10 R4(config-route-map)#set metric 100 R4(config-route-map)#exit R4(config)#router bgp 65100 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(config-router)#^Z R4#clear ip bgp *

Rezultat - SP2 va trimite pachetele destinate AS100 via SP3:

SP2#show ip bgp BGP table version is 30, local router ID is 172.16.11.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 Next Hop Metric LocPrf Weight Path *> 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 192.168.100.0/32 is subnetted, 2 subnets 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 preferat este modificarea AS_PATH. Acesta este modificat prin ia 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(config-router)#^Z 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 BGP table version is 25, local router ID is 172.16.11.1 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 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 Metric LocPrf Weight Path 0 65100 65100 0 0 0 65300 i 32768 i

SP1#show ip route bgp 10.0.0.0/30 is subnetted, 1 subnets B 10.0.1.0 [20/0] via 172.16.11.2, 01:54:03 192.168.100.0/32 is subnetted, 2 subnets 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, de 3 ori pe SP1), i i aceasta este n general soluia preferat. Varianta folosirii MED a fost prezentat doar ca exemplu didactic.

192 | P r o i e c t a r e a r e e l e l o r

9 IP M ulti cast

Conceptul de multicast s-a nscut la sfr itul 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 destina selectate folosind un ii 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 trimiterea unui mesaj de la o sing ur surs la toate te destinaiile dintr-o subreea, se va folosi un mesaj broadcast. ns dac se dore trimiterea unui te 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.

194 | P r o i e c t a r e a r e e l e l o r

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 Fa0/1 R2 Fa0/2 SW1

A1

A2

A3

B1 Figura 9-1: Infrastructur IP

B2

B3

n topologia de mai sus se dore transmiterea unui te 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 destina Se ie. 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 re ea 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 re local, nu cu unul sau mai multe grupuri selectate ea 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 destina niciodat ca adres surs. Fa de IP unicast, ie, multicast nu este folosit pentru a identifica sta echipamente, ci doar grupuri ii sau 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 adres IP pe care i 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 porne i este configurat cu adresa IP a grupului de multicast, ea va te deduce n mod standard o adresa MAC din adresa i va configura placa de reea s IP 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 sta s poat prsi un grup de multicast. Aceste funcionaliti sunt ie 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 func ionrii unei transmisii multicast n Figura 1-1 de la surs la destina n capitolele ulterioare se va pune accept pe ie. 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 destina o singur staie (adres MAC unicast) sau toate staiile (adresa MAC ie 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 client de pe iile 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 care vor i 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.

196 | P r o i e c t a r e a r e e l e l o r 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 eare de n i 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 antetul IP pentru ca ie din 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 bi i 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 aplica emergente. Pentru a nu rmne fr adrese IP, IANA este reticent la ii oferirea adreselor din clasa D. O aplica trebuie s fie nu numai stabil i bine construit, ci s ie demonstreze i o acoper ire considerabil a pie Adresele multicast se mpart n urmtoarele ei. categorii: Adresele permanente Adrese multicast permanente se aloc din spa de adrese 224.0.0.0 224.0.1.255. Aceste iul 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 direc ionate 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 spa din 239.0.0.0 239.255.255.255 este folosit n domenii private de administrare, fiind responsabilitatea administratorului de re (i a ISP -urilor, n ultim instan s nu permit direcionarea ea ) 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 dorete s aib posibilitatea de a selecta sursa de la care dorete s ia

197 | I P M u l t i c a s t 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 aplica pentru ii utilizarea unei adrese IP multicast genereaz automat o adres MAC pe care placa ea re de 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 01005E

1100 0000 0100 0000

0000 0001 0000 0001

0001 1000 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 i ai adresei MAC sunt s crii n hexazecimal din bi motive de ergonomie.

198 | P r o i e c t a r e a r e e l e l o r

9.4 Gestiunea grupurilor multicast n LAN

n cele de mai jos se va reveni asupra scenariului prezentat n capitolul 1.2 Func ionarea 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 Fa0/1 R2 Fa0/2 SW1

A1

A2

A3

B1

B2

B3

Figura 9-3: Managementul traficului n LAN ntrebrile de mai sus definesc, de fapt, iile de baz pe care protocolul func IGMPv2 le implementeaz. n topologia de mai sus, ns, nu doar ruterul are responsabilitatea de decizie. Implementarea unei solu multicast complete presupune ca switchurile din figur s cunoasc ii 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:

199 | I P M u l t i c a s t

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 pa din procesul de trimitere a primului dintre ii 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

Fa0/1 R2

Fa0/2

SW1

A1

A2

A3

B1

B2

B3

Figura 9-5: nregistrarea la un grup multicast

200 | P r o i e c t a r e a r e e l e l o r 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 de a verifica dac exist cel pu un ia in destinatar pentru orice grup de multicast. Ca mesajel e de Report i Leave, un General i Membership Query va avea valoarea TTL egal cu 1. Membership Report Un mesaj IGMPv2 Report este folosit de ctre o ie pentru a semnala ruterului faptul c sta 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. SW1

SW2

Fa0/1 R2

Fa0/2

A1

A2

A3

B1

B2

B3

- 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.

- Am primit un query. - Calculez RT(A2) = random (MRT) - Voi rspunde cnd RT expir dac n acel moment nu a rspuns cineva de pe acest segment deja.

- Am primit un query. - 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

201 | I P M u l t i c a s t 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 n re local sunt foarte multe staii care doresc un eaua 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 sta care se afl pe ii 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 asigur o distribuie relativ juniform de mesaje de i Report n timp, dac exist mai multe grupuri pe acelai segment Ethernet. n continuare persist problema mesajelor redundante trimise de toate sta pe iile de 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 vor primi mesajul de Membership Report nu ii 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 R2

A1

A2

A3 - Nu a expirat nc RT-ul, ns cineva de pe segment a trimis deja un Report.

A expirat timer-ul RT. Trimit un Report cu adres IP destinaie = 227.1.1.1

Figura 9-7: Report Supression

202 | P r o i e c t a r e a r e e l e l o r

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 re pentru a vedea dac mai exist ea cel puin un destinatar pentru un grup specific. n continuare se vor prezenta pa din procesul de ii prsire a unui grup multicast.

R1 SW2

R2 Fa0/1

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 dore s prseasc te 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 care s necesite trafic pentru grupul 227.1.1.1, sta 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:

203 | I P M u l t i c a s t 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 o mapare ntre adresele MAC surs ale staiilor din reeaua ine 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 destina a ie

204 | P r o i e c t a r e a r e e l e l o r 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 acela mod: l i 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 dintr -un anumit grup, switchul prime de la ruter i iilor te adresa MAC multicast a grupului. Astfel acesta caut n tabela CAM porturile pe care cunoate 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 Cisco pentru problema ia 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

205 | I P M u l t i c a s t

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 mesaje hello te 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

206 | P r o i e c t a r e a r e e l e l o r grup pentru a evita extinderea stream-ului n direc n care acesta nu are destinatari. nainte de ii 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 condi ii 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.

207 | I P M u l t i c a s t

Server de Streaming

R1

Cea mai scurt cale de la R2 la Serverul de Streaming conform protocolului de rutare.

Prune: nici un ruter downstream sau un host direct conectat nu dorete trafic

S1/1 R2 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

R3

Send multicast!

Figura 9-10: Mesaje prune n PIM-DM n topologia de mai sus ruterele R2 R3 trimit mesaje de prune, ns din motive diferite. n i 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 sta care s doreasc stream-ul iar R2 tocmai a ie 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 din modul acest mod i ncepe s trimit din nou a 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 un te

208 | P r o i e c t a r e a r e e l e l o r source-based tree sau shortest-path tree (SPT). Acest arbore definete cea mai scurt cale de la surs ctre toate destina iile, 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 arbori sunt cu adevrat relevani n ti 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 S1/1
Graft: am o destinaie multicast. Scoate interfaa din modul pruned i trimite stream-ul

S1/1 R2 S1/0 R3

Send multicast!

Send multicast!

No multicast

No multicast

Figura 9-11: Mesajul graft n PIM-DM Una dintre sta iile 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 acest te 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 un mesaj prune (ex: cazul n care sta ar t rimite un i ia 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 Cisco es te n momentul de fa singurul protocol multicast pe care Cisco l i 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

209 | I P M u l t i c a s t pentru a opri trimiterea traficului, n PIM-SM este nevoie de un mesaj join pentru a ncepe trimiterea acestuia. Starea implicit a unei interfe de ruter multicast sparse este not forwarding. Odat ce se e 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 Server R2 R3 = RP

Join (2) Join (2) R6 IGMP MR (2) Multicasttraffic (3) R5 Multicasttraffic (3) Join (2)

Multicasttraffic (3) R4 IGMP MR(2)

S1

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.

210 | P r o i e c t a r e a r e e l e l o r 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 con chiar pachetele de multicast ale stream-ului. RP-ul va primi in mesajul dar pentru c nu cunoa nicio destinaie valid pentru acest grup (nu a primit niciun join te 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 i iar Register. Ct timp RP-ul refuz procedura de register, sta iile 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 de locaia sursei. Arborele de la RP la destinaii este un ie 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 Server

R2

R3 = RP

R6 R5

R4

S1 Figura 9-13: SPT Switchover

S2

Traficul multicast este transmis acum de la R1 ctre RP pe un Shortest-Path Tree, iar apoi de la RP la sta iile S1 i S2 pe un Root-Path Tree. Pentru a ajunge de la R1 la R6, pachetele multicast

211 | I P M u l t i c a s t 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 rutare va vedea c ruta prin i 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 dore pachete pentru te 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 subreele i nc 10 ce se afl n direcia ine diametral opus, se va plasa RP-ul aproape de cele 100, iar celelalte sta vor face switchover pe ii SPT-ul ctre sursa multicast. Astfel nu mai conteaz iile sunt sau nu dac destina 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 n conceptelor este elegerea 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 specificat identitate a (adresa IP) RP-ului. i 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 re eaua 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 trimit copii ale pachetelor e s multicast primite. Toate informaiile necesare pentru a ruta pachetele multicast sunt re inute n

212 | P r o i e c t a r e a r e e l e l o r 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 Outgoing interface list: 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.

213 | I P M u l t i c a s t 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. a Forward / (Dense sau Sparse): indic faptul c pachetele vor fi trimise pe interfa 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 ie ire (n cazul nostru doar Ethernet0) indic faptul c orice pachet venit de la sursa 172.16.16.1, cu o adres destina mu lticast 233.1.1.1i neap rat venite pe interfa ie a FastEthernet1 a ruterului va fi trimis ctre Ethernet0 .

9.8 Studiu de caz

n studiul de caz ce urmeaz se va analiza operarealizat de un cercettor tiinific ce ia 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

214 | P r o i e c t a r e a r e e l e l o r proiect i-a oferit cercettorului oea IPv4 peste care ruleaz EIGRP. Urmeaz realizarea re implementrii multicast peste aceast reea. R1

F0/0 R3 S1/1 F0/0 S1/1 S1/0 S1/0 R4 S1/2

Fa0/ R5 Fa0/0

R2

S1/2 F0/0 F0/0

R6

Figura 9-14: Studiu de caz

9.8.1 Configurarea PIM-DM

Mai nti se dore configurarea ntr -un protocol dense mode. Alegerea fcut de cercettor te este protocolul PIM-DM. Folosind aceast opiune el trebuie s trimit trafic multicast de la sursa R1 pn la destina iile R5 i R6. Aceste dou rutere din urm vor simula clien de multicast pentru i 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 F0/0 specificate trebuie activate n PIM pentru a putea ele 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)# ip pim dense-mode R2(config-if)# int Fa0/0 R2(config-if)# ip pim dense-mode R3(config)# ip multicast-routing R3(config)# int Serial1/1 R3(config-if)# ip pim dense-mode R3(config-if)# int Serial1/2 R3(config-if)# ip pim dense-mode R3(config-if)# int Fa0/0 R3(config-if)# ip pim dense-mode R4(config)# ip multicast-routing R4(config)# int Serial1/1 R4(config-if)# ip pim dense-mode R4(config-if)# int Serial1/2 R4(config-if)# ip pim dense-mode R4(config-if)# int Fa0/0 R4(config-if)# ip pim dense-mode

215 | I P M u l t i c a s t 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]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 225.1.1.1, timeout is 2 seconds: 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 s descopere drumul pe care te pachetele de multicast l-au urmat n reea. Pe ruterul R2 se poate observa cum interfa serial 1/0 a fost pus n modul prune. Motivul a 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 IP Multicast Routing Table 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 Timers: Uptime/Expires 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 Outgoing interface list: Serial1/0, Forward/Dense, 00:02:54/00:00:00 Serial1/1, Forward/Dense, 00:03:07/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 Outgoing interface list: Serial1/1, Prune/Dense, 00:02:08/00:00:51 Serial1/0, Forward/Dense, 00:02:09/00:00:00

Pe ruterul R3, interfaa 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

216 | P r o i e c t a r e a r e e l e l o r 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 IP Multicast Routing Table 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 Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 225.1.1.1), 00:01:10/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Serial1/1, Forward/Dense, 00:01:10/00:00:00 Serial1/2, Forward/Dense, 00:01:10/00:00:00 (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 Outgoing interface list: 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 IP Multicast Routing Table 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 Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 225.1.1.1), 00:03:59/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Dense, 00:00:35/00:00:00

217 | I P M u l t i c a s t
Serial1/1, Forward/Dense, 00:03:59/00:00:00 Serial1/2, Forward/Dense, 00:03:59/00:00:00 (10.1.12.1, 225.1.1.1), 00:00:23/00:02:54, flags: T Incoming interface: Serial1/1, RPF nbr 10.1.23.2 Outgoing interface list: 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 Enter configuration commands, one per line. End with CNTL/Z. 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 eigrp 100 R3(config-router)#net R3(config-router)#network 150.1.1.0 0.0.0.255 R3(config-router)#exit

! 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 R4(config)#ip pim rp-address 150.1.1.1 R3(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.

218 | P r o i e c t a r e a r e e l e l o r
R3#sh ip mroute IP Multicast Routing Table 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 Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 225.1.1.1), 00:21:14/00:03:18, RP 150.1.1.1, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:17:50/00:02:49 Serial1/1, Forward/Sparse, 00:21:14/00:00:00 Serial1/2, Forward/Sparse, 00:21:14/00:03:18 (10.1.12.1, 225.1.1.1), 00:00:36/00:02:37, flags: T Incoming interface: Serial1/1, RPF nbr 10.1.23.2 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:00:36/00:02:48

Pentru a analiza operaia 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 IP Multicast Routing Table 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 Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 225.1.1.1), 00:51:23/stopped, RP 150.1.1.1, flags: SJC Incoming interface: Serial1/2, RPF nbr 10.1.34.3 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:51:23/00:02:51 (10.1.12.1, 225.1.1.1), 00:00:06/00:02:55, flags: JT Incoming interface: Serial1/2, RPF nbr 10.1.34.3 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:00:06/00:02:53

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.

219 | I P M u l t i c a s t
R4#sh ip mroute IP Multicast Routing Table 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 Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 225.1.1.1), 00:46:10/stopped, RP 150.1.1.1, flags: SJC Incoming interface: Serial1/2, RPF nbr 10.1.34.3 Outgoing interface list: Serial1/0, Forward/Sparse, 00:32:15/00:00:00 FastEthernet0/0, Forward/Sparse, 00:46:10/00:01:58 (10.1.12.1, 225.1.1.1), 00:00:13/00:02:57, flags: JT Incoming interface: Serial1/0, RPF nbr 10.1.24.2 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:00:13/00:02:46

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 Configurarea protocolului ................................................................................................. 138 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 Configurarea protocolului ................................................................................................. 178 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