1 Protocolul OSPF. Generalităţi

Open Shortest Path First ( OSPF ) este un protocol cu starea legăturilor dezvoltat

pentru TCP/IP. Se foloseşte în reţele foarte mari şi dispune de cîteva avantaje faţă de

RIP. Similar cu Interior Gateway Routing Protocol (IGRP), OSPF a fost creat deoarece

la mijlocul anilor ’80, Routing Information Protocol ( RIP ) a devenit incapabil să

servească inter-reţele mari, eterogene.

OSPF are două mari caracteristici. Prima este că protocolul este deschis, ceea ce

înseamnă ca specificaţiile sale sunt de domeniu public. A doua caracteristică principală

este că se bazează pe algoritmul SPF (Shortest Path First).

OSPF detectează schimbări în topologie, cum ar fi eşecurile link-ului, foarte repede

şi converge pe o buclă de nouă-structură fără de rutare în câteva secunde. Aceasta

calculeaza calea cea mai scurtă pentru fiecare traseu folosind o metodă bazată

pe algoritmul lui Dijkstra.

Ideea principală este că în loc de a schimba informaţii despre distanţele pîna la

destinaţii (ca în cazul protocolului RIP ), toate nodurile vor menţine hărţi specifice ale

reţelei care sunt revizuite după fiecare schimbare din topologie. Aceste hărţi sunt mai

apoi folosite pentru a determina rute care sunt mai fiabile decît cele în cazul

protocoalelor cu vectori-distanţă. Rutele determinate de OSPF par a fi la fel de precise

ca şi cele determinate central, totuşi această determinare fiind distribuită. Astfel, spre

deosebire de RIP, OSPF împarte informaţiile despre vecinii săi cu întreaga reţea (cel

mult un singur system autonom). RIP nu încearcă să înveţe despre întreaga reţea

Internet, iar OSPF nu încearcă să se promoveze în întregul Internet.Nu aceasta este

menirea lor. Ele sunt protocoale de rutare interne, astfel slujba lor este de a construi

rutarea în cadrul unui sistem autonom.

Cele mai importante avantajeale protocolului OSPF sunt facilităţile de securitate,

facilităţi de căi multiple, facilităţi în ceea ce priveşte utilzarea metricilor de costuri

diferite, suport integrat atît pentru rutarea unicast cît şi pentru cea multicast, convergenţă

rapidă.

O reţea OSPF poate fi structurată, sau divizată, în zone de dirijare pentru a simplifica

procedurile administrative şi a optimiza traficul şi utilizarea resurselor.

Zonele sunt identificate prin numere de 32-biţi, exprimate fie pur şi simplu în

zecimal, sau de multe ori în octeţi-bazate pe dot-notaţie zecimale, familiare de la

notaţia IPv4. OSPF nu utilizează un protocol TCP/IP de transport (UDP, TCP), dar este

încapsulat direct în datagramele IP cu numărul de protocol 89. Acest lucru este în

contrast cu alte protocoale de rutare, cum ar fi de informare Routing Protocol (RIP),

sau Border Gateway Protocol (BGP).

OSPF propune soluţia următoarelor probleme:

creşterea vitezei de convergenţă;

accesibilitatea reţelei (rapid se determină routerele care nu răspund, iar topologia

reţelei se schimbă în modul respectiv);

utilizarea optimală a benzii de frecvenţă;

metoda alegerii căii.

1.1 Descrierea funcţionării protocolului

Protocolul OSPF funcţionează conform unui algoritm anumit

1. Routerele fac schimb cu pachete hello prin toate interfeţele, asupra cărora este activat

protocolul OSPF. Routerele care împart canalul comun de transmitere a datelor devin

vecini, atunci cînd ajung la înţelegerea asupra anumitor parametri, indicaţi în pachetele

lor hello.

2. La etapa următoare a funcţionării protocolului, routerele vor încerca să treacă în starea

de adiacenţă cu acele routere cu care se află în limitele unei relaţii directe (la distanţa de

un hop). Trecerea în starea de adiacenţă se determină conform tipului routerelor, care fac

schimb de pachete hello şi în dependenţă de tipul reţelei prin care se transmit pachetele

hello. OSPF determină cîteva tipuri de routere şi cîteva tipuri de reţele. Perechea de

routere care se află în starea de adiacenţă sincronizează între ei baza de date a stării

canalelor.

3. Fiecare router transmite anunţ despre starea canalului routerului cu care el se află în

starea de adiacenţă.

4. Fiecare router care a primit anunţul de la routerul adiacent, înscrie informaţia

transmisă în anunţ în baza de date a stării canalelor a routerului şi transmite o copie

tuturor routerelor adiacente lui.

5. Transmiţînd anunţurile prin zonă, toate routerele construiesc o baza de date identică a

stării canalelor routerelor.

6. Cînd baza de date este construită, fiecare router utilizează algoritmul "cea mai scurtă

cale primul", pentru determinarea graficului fără bucle, care va descrie cel mai scurt

drum la fiecare punct destinaţie cunoscut cu el în calitate de rădăcină. Acest grafic

reprezintă arborele căilor celor mai scurte.

7. Fiecare router construieşte tabela de routare din arborele său al celor mai scurte căi.

1.2 Zonele OSPF

Un domeniu OSPF este împărţit în zone care sunt etichetate cu 32-biţi de identificare

zonă. Zonele de identificare sunt de obicei, dar nu întotdeauna, scrise în dot-notaţia

zecimală de o adresă IPv4. Cu toate acestea, ele nu sunt adrese IP şi poate duplica, fără

conflict, nici o adresă IPv4. Mai multe tipuri de zonă sunt definite:

Zona Backbone

Zona coloana vertebrală (de asemenea cunoscut ca zona 0 sau zona 0.0.0.0) formele

de bază a unei reţele OSPF. Toate alte zone sunt conectate la acesta, şi inter-rutare zona

de lucru se întâmplă prin intermediul routere conectate la zona de coloana vertebrală şi

de a propriilor lor zone asociate. Aceasta este structura logică şi fizică pentru OSPF

"domeniu" şi este ataşat la toate zonele nenul în domeniul OSPF. Reţineţi că, în OSPF

pe termen Autonomous System Boundary Router (ASBR) este istorică, în sensul că

multe domenii OSPF pot coexista în acelaşi sistem de Internet vizibile autonome. Zona

coloana vertebrală este responsabilă pentru distribuirea informaţiilor de dirijare între

zone nonbackbone. Toate zonele OSPF trebuie să se conecteze la zona de coloana

vertebrală. Această conexiune, cu toate acestea, poate fi printr-un link virtuale. 

Zona Stub

O zona stub este o zonă care nu primeşte informaţie de la traseul extern

pentru sistemul autonom (AS), dar acceptă rutele de la alte zone. În cazul în care

routerelor din zona stub au nevoia de a transmite informaţia peste limitele sistemului

autonom atunci ei utilizează ruta implicită. 

Zona Stubby

O zona stubby este o zonă care nu primeşte informaţie de la traseul extern

pentru sistemul autonom (AS), dar acceptă rutele de la alte zone. În cazul în care

routerelor din zona stub au nevoia de a transmite informaţia peste limitele sistemului

autonom atunci ei utilizează ruta implicită. 

NSSA zona complet Stubby

Un plus de funcţionalitate standard a unui NSSA, numit-o zona NSSA total

Stubby. Este nevoie de pe atributele unui TSA, în sensul că tipul 3 şi 4 de tip rute de

sinteză nu sunt inundate în acest tip de domeniu. De asemenea, este posibil să se declara

o zonă atât complet Stubby nu şi-aşa-Stubby, ceea ce înseamnă că zona va primi doar

ruta implicită din zona 0.0.0.0, dar poate să conţină, de asemenea, un router sistem

autonom de frontieră (ASBR) care acceptă externe rutare de informare şi injecteaza-o în

zona locală, precum şi din zona locală în zona 0.0.0.0.

Redistribuirea într-o zonă NSSA creează un tip special de LSA, cunoscut sub numele de

tip 7, care poate exista doar într-o zonă NSSA. 

Zona de frontieră router

Un router zona de frontieră (ABR) este un router care conectează unul sau mai multe

zone la reţeaua principală coloana vertebrală. Acesta este considerat un membru al

tuturor zonelor acesta este conectat la. O ABR păstrează mai multe copii ale link-baza

de date de stat în memorie, unul pentru fiecare zonă în care acest router este conectat.

1.3 Header-ul OSPF:

000

1

0

2

0

3

0

4

0

5

0

6

0

7

0

8

0

9

1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

2

2

3

2

4

2

5

2

6

2

7

2

8

2

9

3

031

Versiune Tip Lungime

Router ID-ul

Zona ID-ul

Suma de control AuType

Autentificare:::

Data:::

Versiunea― numărul versiunii protocolului OSPF. Varianta actualăOSPF pentru

reţelele IPv4 este 2.

Tip― tipul pachetului OSPF. În RFC 2328 sunt descrise 5 tipuri de pachete.

Lungimea― 16 biţi. Dimensiunea pachetului OSPF, inclusiv antetul OSPF în octeţi.

Router ID-ul― 32 de biţi. Identificatorul routerului, un număr unic de 32 de biţi care

identifică routerul în limitele sistemului autonom.

Zona ID-ul― 32 de biţi. Identificatorul zonei.

Checksum― 16 biţi. 

Suma de control care se calculează pentru întregul pachet inclusiv antetul.

AuType― 16 biţi. 

Identifica procedura de autentificare utilizată pentru pachetele de date. Valorile posibile:

0- autentificarea nu se utilizează

1- autentificare prin text deschis

2- autentificarea MD5.

Autentificare―cîmpul datelor de autentificare

Date― Lungime variabilă.

2 Protocolul BGP

BGP ( Border Gateway Protocol) este protocolul de rutare folosit în

nucleul Internetului. El menţine o tabelă cu reţele IP (sau "prefixe") care arată calea

folosită pentru a ajunge la reţeaua respectivă prin diferitele sisteme autonome (AS).

BGP este considerat din acest motiv un protocol de rutare vector-cale (spre deosebire de

protocoalele vector-distanţă, care nu păstrează toată calea). BGP nu foloseşte aceleaşi

metrici ca protocoalele de rutare folosite în interiorul ASurilor, ci ia decizii bazându-se

pe cale şi pe politicile de rutare ale sistemului autonom din care face parte.

Protocolul a fost creat pentru a înlocui un al protocol de rutare (EGP) şi pentru a

permite rutarea descentralizată în Internet, făcând inutilă reţeaua de nucleu a

acestuia, NSFNet. Din 1994, versiunea patru a protocolului este folosită în Internet, toate

versiunile anterioare fiind considerate depăşite. Cel mai important progres al versiunii 4

a fost suportul pentru CIDR şi folosirea agregării rutelor pentru a reduce

dimensiunea tabelelor de rutare. Din ianuarie 2006, BGPv4 este standardizat prin RFC

4271, care a trecut prin peste 20 de versiuni preliminare, bazate pe versiunea de BGP

din RFC 1771. RFC 4271 a corectat unele erori, a clarificat ambiguităţile şi a apropiat

standardul de practicile curente din industrie.

2.1 Tipuri de mesaje BGP

Protocolul BGP foloseşte patru tipuri de mesaje pentru a comunica între rutere[1]:

Open― mesajele iniţiale, folosite pentru stabilirea conexiunii între rutere; dacă un

ruter primeşte un mesaj Open şi este de acord cu conţinutul, trebuie să răspundă cu

un mesaj Keepalive.

Keepalive― mesaje de 19 octeţi trimise periodic (implicit la 60 de secunde - o treime

din timpul de hold-down) pentru menţinerea conexiunii deschise; aceste mesaje sunt

trimise fără confirmare, iar dacă intervalul de trimitere este setat la 0, nu se trimit

Update― (Actualizare): conţin căi către diversele reţele (accesibile, invalide sau

retrase), împreună cu atributele corespunzătoare; iniţial, ruterele BGP îşi trimit

reciproc întreaga tabelă de rutare; după actualizarea iniţială, se transmit actualizări

incrementale, pe măsură ce topologia reţelei se schimbă.

Notification― (Notificări): raportează eventualele erori apărute în comunicaţie.

2.2 Conectivitate şi învăţarea rutelor

În cea mai simplă metodă de configurare, toate ruterele dintr-un AS care rulează BGp

sunt conectate fiecare cu fiecare. Acest lucru provoacă grave probleme de scalabilitate,

deoarece numărul de conexiuni creşte cu pătratul numărului de rutere conectate. Pentru a

evita această problemă au fost oferite două soluţii: reflectorii de rute (RFC 4456) şi

confederaţiile (RFC 5065). Dacă nu este precizat altfel, în această secţiune se discută

situaţia conectării fiecare cu fiecare.

Tabela de rutare

Implementarea de BGP de pe ruterele Cisco, dar nu numai, păstrează o tabelă de căi

BGP separată de tabela de rutare şi numită Loc-RIB (Local Routing Information Base).

Unele implementări păstrează şi tabele per vecin, conţinând NLRIurile trimise/primite

de la acel vecin. Structura internă a acestor tabele nu este vizibilă vecinilor BGP, ci doar

pe ruterul local.

În tabela de rutare a ruterului sunt ţinute doar rutele optime către o destinaţie. În

schimb, tabela BGP va conţine toate rutele primite prin BGP. Trecerea unei rute din

tabela BGP în tabela de rutare se face astfel:

pentru eBGP, rutele sunt puse automat în tabela de rutare (dacă nu este direct

conectată).

pentru iBGP, ruta este pusă în tabela de rutare dacă sunt îndeplinite mai multe

condiţii:

o există o înregistrare în tabela de rutare către următorul hop din calea BGP

o ruta este aflata şi prin intermediul unui IGP sau sincronizarea este

dezactivată.

Un anumit ruter BGP poate accepta căi BGP de la mai mulţi vecini şi poate trimite

actualizări aceloraşi vecini sau altora. O greşeală frecventă în ceea ce priveşte BGP este

să se spună că "BGP transmite politici". De fapt, BGP transmite doar informaţii pe care

procesele BGP le aplică unor reguli pentru a lua decizii de rutare. Unele din aceste

informaţii sunt destinate explicit folosirii în decizia de rutare: comunităţile şi multi-exit

discriminators (MED).

Selecţia rutelor

Standardul specifică mai mulţi factori de selecţie a rutelor decât pentru orice alt

protocol de rutare. Primul factor este că next-hopul este accesibil (există în tabela de

rutare).

Apoi, pentru fiecare vecin, procesul BGP aplică diferite criterii (standardizate sau

specifice implementării) pentru a decide care rute vor ajunge în Adj-RIB-In. Doar o rută

către fiecare destinaţie va ajunge în tabelă, indiferent de câte sunt trimise de vecin. De

asemenea, procesul va şterge din Adj-RIB-In toate rutele retrase de vecin.

Când tabela Adj-RIB-In se schimbă, procesul analizează noile rute pentru a vedea

dacă sunt mai bune decât cele aflate deja în Loc-RIB şi le înlocuieşte dacă este cazul.

Dacă o rută este retrasă de vecin şi nu există o altă rută către destinaţie, ea este ştearsă şi

din Loc-RIB şi din tabela de rutare (cu excepţia cazului în care un alt protocol de rutare

are şi el acestă rută).

Criterii de selecţie

După ce a verificat că vecinul este accesibil, procesul BGP ia decizia de rutare conform

următorului algoritm:

1. Dacă nu există decât o singură rută către o anumită destinaţie, va fi folosită

această rută.

2. Dacă există mai multe rute, va fi folosită cea cu atributul weight mai mare.

3. Dacă atributele weight sunt egale, se va folosi atributul Local Preference superior

4. În cazul în care există egalitate şi la Local Preference, se preferă ruta ce are ca

punct de origine ruterul local.

5. Dacă nu există o astfel de rută, este analizat atributul AS_Path şi este aleasă cea

mai scurtă cale (e.g. calea AS1-AS2-AS3 e mai scurtă decât AS4-AS5-AS6-AS7)

6. La egalitate AS_Path, se alege ruta cu ASul de origine cel mai mic

7. În caz de egalitate şi după acest criteriu, se alege ruta cu MED cel mai mic

8. Dacă atributele MED sunt egale, se prefera ruta eBGP, apoi rutele de confederaţie

externe ţi în cele din urmă rutele iBGP

9. Dacă nu există nicio rută externă, se alege ruta IGP care are cel mai scăzut cost

către următorul ruter BGP (unele implementări ofertă posibilitatea de echilibrare a

încărcării între rute cu cost egal)

10.Se preferă ruta primită de la ruterul cu identificatorul BGP cel mai mic

11.În cele din urmă se preferă ruta ce vine de la vecinul cu adresa IP cea mai mică

2.3 Probleme ale BGP

Scalabilitatea iBGP

Un sistem autonom cu iBGP (internal BGP) trebuie să aibă toate ruterele iBGP

conectate fiecare cu fiecare. Această confirguraţie necesită ca fiecare ruter să menţină

conexiuni cu toate celelalte rutere, ceea ce poate cauza o degradare a performanţelor în

cazul reţelelor mari.

Reflectorii şi confederaţiile pot reduce numărul de conexiuni iBGP şi automat

încărcarea. În plus, confederaţiile pot fi folosite la implementarea unei politici mai

amănunţite.

Reflectorii reduc numărule de conexiuni necesare într-un AS. Este suficient ca un

singur ruter să aibă conexiuni cu toate celelalte rutere (să fie făcut reflector). Celelalte

rutere din acel sistem autonom vor fi apoi configurate să se conecteze la reflector.

Confederaţiile sunt seturi de sisteme autonome. În practică, doar unul din numerele

AS va fi vizibil din Internet. Confederaţiile sunt folosite în cadrul reţelelor foarte mari în

care un număr de AS mai mare este configurat pentru a ascunde alte numere de AS mai

mici. Confederaţiile pot fi folosite împreună cu reflectorii, fiecare din ele fiind utile în

anumite situaţii.

Totuşi, aceste opţiuni pot introduce la rândul lor anumite probleme, printre care:

oscilaţia rutelor - atât confederaţiile cât şi reflectorii sunt expuse pericolului

oscilaţiilor (variaţii periodice în alegerea căii optime spre anumite destinaţii).

Pentru a fi evitate, trebuie folosite anumite reguli de design care afectează atât

BGP, cât şi protocolul de rutare intern

rutare sub-optimă

mărirea timpului de convergenţă al BGP

complicarea configurării rutelor. Totuşi, aceste metode sunt obişnuite pentru

reţelele BGP.

Dimensiunea tabelei de rutare

Una din cele mai mari probleme întâmpinate de BGP, dar şi de întreaga infrastructură

Internet, provine de la creşterea rapidă a tabelei globale de rutare (care conţine toate

rutele din Internet). Pe măsură ce cerinţele de memorie şi de putere de procesare cresc,

ruterele mai vechi nu mai fac faţă, utilitatea lor scăzând considerabil. Mult mai

important, căutarea într-o tabelă de mari dimensiuni durează mai mult şi provoacă

instabilitate în cazul schimbărilor importante de topologie.

Până la sfârşitul anului 2001, creşterea tabelei de rutare era exponenţială, ceea ce crea

ameninţarea unor probleme grave de conexiune. Pentru a evita acest lucru s-au luat o

serie de măsuri între ISPuri, printre care utilizarea CIDR şi agregarea rutelor. Acest

lucru a provocat o creştere liniară până în 2004, când creşterea a devenit din nou

exponenţială datorită cererii de conexiuni redundante din partea reţelelor de mici

dimensiuni. În ianuarie 2009, tabela de rutare globală avea aproximativ 300.000 intrări.

Agregarea rutelor este un procedeu des folosit pentru a reduce dimensiunea tabelelor

de rutare. Să spunem că sistemul autonom AS1 are spaţiul de adrese 172.16.0.0/16, care

ar ocupa o intrare în tabela de rutare, dar datorită cerinţelor clienţilor, doreşte să anunţe

şi trei rute specifice: 172.16.0.0/18, 172.16.64.0/18 şi 172.16.128.0/18. Reţeaua

172.16.192.0/18 nu e utilizată, aşa că AS1 n-o anunţă. În total, AS1 anunţă deci 4 rute.

AS2 va vedea cele 4 rute de la AS1 şi depinde doar de implementarea sa dacă va

prelua toate rutele sau doar cea mai mare (172.16.0.0/16). Dacă AS2 vrea să trimită date

către prefixul 172.16.192.0/18, le va trimite către ruterele din AS1 pe ruta generală

172.16.0.0/16, iar ruterul BGP din AS1 va decide ce face cu ele (dacă trimite sau nu un

mesaj prin care să anunţe că nu există destinaţia respectivă).

Dacă AS1 renunţă la ruta 172.16.0.0/16, vor mai rămâne 3 rute anunţate. AS2 va

vedea cele trei rute şi poate să le păstreze pe toate sau să agrege 172.16.0.0/18 şi

172.16.64.0/18 în 172.16.0.0/17, reducând numărul de rute la două. În acest caz, ruta

172.16.192.0/18 nu se află în tabela de rutare şi orice tentativă de a trimite date către

această reţea, va eşua încă din reţeaua AS2.

Echilibrarea încărcării

Un alt factor care cauzează mărirea dimensiunii tabelei de rutare este echilibrarea

încărcării pentru reţele cu mai multe legături externe. Dacă un ISP îşi publică reţeaua

către toţi vecinii BGP, una sau mai multe dintre legături pot fi congestionate, pe când

celelalte sunt subutilizate. Acest lucru se întâmplă în cazul în care toţi vecinii consideră

acele legături ca optime. Ca şi celelalte protocoale de rutare, BGP nu detectează

congestia.

Pentru a evita această problemă, administratorii reţelelor respective împart blocul de

adrese pe care îl administrează în sub-blocuri şi publică pe fiecare legătură BGP un alt

bloc de adrese. Acest lucru duce la mărirea numărului de intrări din tabelele BGP.

Concluzie: Din punct de vedere logic, OSPF se aseamănă cu o pânză de păianjen sau

o topologie stea de mai multe zone conectate cu Area 0. OSPF permite transferul şi de

marcare a traseelor externe, injectat într-un sistem autonom. Acest lucru ţine evidenţa

rute externe injectat de protocoale de exterior, cum ar fi BGP.

Un nou portal informaţional!

Dacă deţii informaţie interesantă si doreşti să te imparţi cu noi

atunci scrie la adresa de e-mail : support@sursa.md