7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 1/16

1. Protocolul OSPF

OSPF(Open Shortest Path First reprezintă un tip de protocol de rutare în

interiorul unui SA (guvernate de un singur gestionar) după cum se prezintă în figura

1.1. Termenul “deschis” se referă la tipul de recomandare IETF, care este deschisă

 pentru modificări ulterioare.

Figura 1.1 Protocoale de rutare internă şi externă

Protocolul SPF permite utilizarea unor metrici multiple pentru calcularea

costului unei legături, cum ar fi: întârziere, debit, cost monetar şi eficienţă. OSPF a

fost elaborat pentru a oferi o alternativă la RIP care să rezolve problemele acestuia.

Versiunea cea mai utilizată de OSPF pentru IPv4 este definită de RFC 2328.

OSPF implementează un număr de funcţii pe care protocoalele de tip vector 

distanţă nu le prezintă. Astfel, OSPF a devenit cel mai utilizat protocol de rutare înreţelele de dimensiuni mari. Funcţiile care au contribuit la succesul standardului

OSPF:

• Echilibrarea încărcării reţelei pentru căi de cost egal (Equal cost load

 balancing): Utilizarea simultană a căilor multiple permite utilizarea mai eficientă a

resurselor reţelei.

•

Divizarea logică a reţelei (Logical partitioning of the network): Aceastăfuncţie reduce propagarea informaţiilor neactualizate în cazul unor condiţii

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 2/16

defavorabile (modificări de topologie). De asemenea, permite cumularea anunţurilor 

de rutare (aggregate routing announcements) care limitează anunţarea informaţiilor 

inutile.

• Mecanisme de autentificare: OSPF permite autentificarea fiecărui nod

care transmite mesaje de anunţare a rutelor. Aceasta previne ca surse frauduloase

(ruterele neautorizate) să modifice conţinutul tabelelor de rutare.

• Timp de convergenţă mai mic: OSPF permite propagarea instantanee a

informaţiilor despre modificarea rutelor. Astfel, actualizarea informaţiilor de

topologie se realizează mult mai rapid.

• Suportă CIDR şi VLSM: Aceste funcţii permit o alocare eficientă a

adreselor IP.

OSPF este un protocol de tip stare a legăturii (link state) după cum este

 prezentat în figura 1.2. Fiecare ruter OSPF execută algoritmul SPF (Shortest-Path

First), pentru a procesa informaţiile salvate în

 baza de date a stărilor legăturilor (link state database). Algoritmul generează arborele

de căi minime (shortest-path tree) care prezintă rutele optime către toate reţelele de

destinaţie.

Figura 1.2 Protocoale de rutare

OSPF utilizează o terminologie specifică pentru a descrie funcţionarea

 protocolului, în continuare vor fi descrise principalii termeni:Această divizare a reţelei în arii logice determină următoarele avantaje:

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 3/16

•Într-o arie, fiecare ruter menţine o bază de date a topologiei (topology

database) care descrie ruterele şi legăturile din această arie. Aceste rutere nu deţin

informaţii despre topologii aflate în exteriorul ariei, ci deţin numai rutele către aceste

destinaţii externe. Astfel, se reduc considerabil dimensiunile bazei de date a

topologiei, deţinute de fiecare ruter.

•Divizarea în arii reduce posibila creştere a numărului de actualizări de stare a

legăturilor. Astfel, cele mai multe LSA sunt distribuite numai în interiorul unei arii.

•Se reduce timpul de procesare CPU necesar pentru a menţine baza de date a

topologiei. Algoritmul SPF se limitează la a administra modificările numai dintr-o

arie.

 Aria coloană vertebrală (Backbone) sau aria 0

Toate reţelele OSPF conţin cel puţin o singură arie. Această arie este aria 0 sau

aria coloană vertebrală (backbone). Se pot adăuga şi alte arii, în funcţie de topologia

reală a reţelei sau de alte cerinţe de proiectare. În reţelele care conţin mai multe arii,

aria backbone se conectează fizic cu toate celelalte arii. Toate ariile vor anunţa

informaţiile de rutare, direct în backbone. Apoi, din backbone se vor transmite aceste

informaţii către celelalte arii. În figura 1.3 este reprezentat modelul unui sistem

autonom conform protocolului OSPF

Figura 1.3 Ariile şi tipuri de rutere OSPF

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 4/16

În figura 1.3 sunt ilustrate interacţiunile dintre ruterele OSPF. Astfel, în funcţie

de amplasarea şi rolul unui ruter în reţea există trei tipuri de rutere într-o reţea

OSPF:

• Ruterele de interior de arie, IA (Intra-area routers) - Aceste rutere sunt

amplasate, d.p.d.v. logic, în interiorul unei arii OSPF. Fiecare ruter de interior de arie

menţine o bază de date a topologiei, corespunzătoare numai ariei locale a acestuia.

• Ruterele de extremitate de arie, ABR (Area border routers) - Aceste rutere

se conectează, d.p.d.v. logic, cu una sau mai multe arii, dintre care una trebuie să fie

aria backbone. Astfel, un ruter ABR este utilizat pentru interconectarea mai multor 

arii. Fiecare ruter ABR menţine o bază de date a topologiei, separat pentru fiecare

arie la care se conectează. Ruterele ABR execută instanţe separate de algoritm OSPF

 pentru fiecare arie.

• Ruterele de extremitate de SA, ASBR (AS boundary routers) - Aceste rutere

sunt plasate, d.p.d.v. logic, la periferia unui sistem autonom OSPF. Astfel, un ruter 

ASBR funcţionează ca o poartă de acces (gateway), care anunţă căile de acces dintre

reţeaua OSPF şi alte domenii de rutare. Ruterele ASBR transmit spre interiorul SA,

mesajele de anunţare a rutelor LSA externe.

Fiecare ruter este identificat prin intermediul unui identificator unic de 32 de

 biţi, denumit ID ruter, RID (router ID). O soluţie des întâlnită de implementare a

RID constă în utilizarea celei mai mici adrese IP, configurate la ruter, drept RID-ul

său.

Ruterele care împart un segment comun de reţea pot stabili o relaţie de

învecinare la nivel logic. În acest caz, pentru a stabili o relaţie de învecinare, ruterele

trebuie să convină asupra următoarelor informaţii:

• ID arie: Ruterele trebuie să aparţină aceleiaşi arii OSPF.

• Autentificare: Dacă se defineşte o autentificare, atunci ruteree trebuie să

utilizeze aceeaşi parolă.

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 5/16

• Intervalele Hello şi intervalele moarte (dead): Ruterele trebuie să utilizeze

aceleaşi intervale de timp pentru funcţionarea protocolului Hello.

•Fanionul de arie ciot (stub): Ruterele trebuie să convină că aria este

configurată ca arie ciot.După ce două rutere au stabilit o relaţie de învecinare, se poate stabili o relaţie

de adiacenţă între aceştia. Ruterele vecine sunt considerate rutere adiacente după ce

şi-au sincronizat reciproc bazele de date de topologie. Sincronizarea bazelor de date

se realizează prin schimbul de mesaje de stare a legăturii.

Schimbul excesiv de mesaje de stare a legăturii dintre ruterele vecine poate crea

în reţea un volum semnificativ de trafic. Pentru a reduce acest trafic necesar 

sincronizării bazelor de date s-a impus ca un ruter să nu stabilească (neapărat)

adiacenţe cu fiecare ruter vecin. Astfel, în funcţie de tipul reţelei fizice, este

recomandat să se stabilească următoarele adiacenţe:

 Reţele punct-la-punct : Adiacenţa îi implică obligatoriu pe ambele rutere.

 Reţele de acces multiplu: Adiacenţele sunt stabilite numai între un ruter ordinar 

(oarecare, nu e DR sau BDR) şi un ruter desemnat (sau ruter desemnat de rezervă).

Fiecare reţea de acces multiplu stabileşte un ruter desemnat, DR (designated

router) şi un ruter desemnat de rezervă, BDR (backup designated router). Un DR 

îndeplineşte următoarele două funcţii pentru un segment de reţea:

- Stabileşte adiacenţe cu toate ruterele din reţeaua de acces multiplu. Astfel,

ruterul DR devine punctul focal de dirijare a LSA-urilor.

- Generează mesaje LSA, care anunţă fiecare ruter conectat în reţeaua de

acces multiplu.

Ruterul BDR stabileşte aceleaşi adiacenţe ca şi ruterul ales DR şi preia funcţiile

DR în cazul în care acesta din urmă se defectează. Fiecărui ruter i se asociază o

 prioritate reprezentată pe 8 biţi, care indică şansele ca ruterul respectiv să fie ales DR 

sau BDR. Un ruter cu prioritatea zero nu poate fi ales nici DR, nici BDR. Prioritatea

este configurată pentru fiecare interfaţă a ruterului.

Baza de date a stărilor legăturilor mai este denumită şi baza de date a topologiei

(topology database). Aceasta conţine setul de anunţuri de stare a legăturii care descrie

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 6/16

reţeaua OSPF şi fiecare conexiune externă. Fiecare ruter dintr-o arie menţine o copie

identică a bazei de date a stărilor legăturilor.

Pachetele OSPF sunt transmise în datagramele IP si nu sunt incapsulate în

 pachetele TCP sau UDP. Antetul IP contine în câmpul de identificare a protocolului

valoarea 89. De asemenea, valoarea câmpului care defineşte tipul serviciului (type of 

service) are valoarea 0. Acest mecanism este utilizat pentru a impune o procesare

specială a pachetelor. Atunci când este posibil, un ruter OSPF utilizează transmisia

multiplă (multicast) pentru a comunica cu ruterele vecine. În reţelele cu difuzare şi în

configuraţiile punct-la-punct, pachetele transmise au adresa de destinaţie de tip

multicast 224.0.0.5. În mediile fără difuzare pachetele sunt transmise cu adresa IP de

destinaţie a ruterului vecin (unicast).

Figura 1.4 Tipuri de pachete OSPF

Există cinci posibile tipuri diferite de pachete OSPF:

•  Hello - Acest tip de pachet este utilizat pentru descoperirea şi menţinerea

relaţiilor dintre vecini;

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 7/16

•  Descrierea bazei de date (Database description) - Acest tip de pachet descrie

setul de LSA-uri conţinute în baza de date a stărilor legăturilor, a ruterului;

•  Cerere stare legătură (Link state request) - Acest tip de pachet solicită o

variantă mai nouă a unei LSA de la un vecin;•  Actualizare stare legătură (Link state update) - Acest tip de pachet oferă o

variantă nouă a unei LSA către un vecin (eventual, care a efectuat o cerere);

•  Confirmare stare legătură (Link state acknowledgement) - Acest tip de

 pachet confirmă recepţionarea unei noi LSA.

2. Protocolul BGP (Border Gateway Protocol)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.

Cei mai mulţi utilizatori de Internet nu folosesc în mod direct acest protocol.

Totuşi, deoarece majoritatea Internet Service Providerilor îl folosesc pentru a stabili

rute între reţelele respective, BGP este unul din cele mai importante protocoale de pe

Internet. Importanţa sa este comparabilă cu a protocolului SS7 pentru stabilirea

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 8/16

apelurilor telefonice între operatorii PSTN. Reţelele IP de mari dimensiuni folosesc

BGP inclusiv în interiorul reţelei, de exemplu pentru a lega mai multe subreţele

suficient de mari pentru ca protocolul de rutare OSPF să-şi atingă limitele. Alt caz de

utilizare îl reprezintă conectarea mai multor puncte de prezenţă ale unui singur 

furnizor de acces Internet (acest caz este descris în RFC 1998).

Border Gateway Protocol este un protocol de rutare unic, deoarece, spre

deosebire de celelalte protocoale de rutare, stabileşte şi menţine conexiuni între

ruterele vecine folosind protocolul TCP. În cazul ruterelor aflate în ASuri diferite, o

conexiune BGP poate fi stabilită doar dacă ruterele sunt direct conectate. Legătura se

realizează pe  portul TCP 179, fiind menţinută prin mesaje periodice de 19 octeţi

(intervalul implicit este de 60 de secunde).

Cînd BGP este rulat în interioriul unui sistem autonom, este folosit termenul

iBGP (engleză  Internal Border Gateway Protocol ). Cînd este rulat între ASuri, este

numit eBGP ( External Border Gateway Protocol ). În majoritatea ruterelor  actuale,

distanţa administrativă (DA) pentru iBGP este mai mare (deci prioritatea este mai

mică) decît cea pentru alte protocoale de rutare intra-AS, care la rîndul lor au D.A.mai mare decît eBGP.

Vecinii eBGP trebuie să fie direct conectaţi pentru a fi realizată conexiunea

BGP, dar există şi excepţii. De exemplu, implementările Cisco au opţiunea

"multihop", care permite realizarea de conexiuni eBGP către rutere nelegate direct.

Această limitare nu există pentru iBGP. Pentru a asigura rutarea între toate nodurile

din reţea care rulează BGP poate fi folosit un protocol de rutare IGP (OSPF, RIP 

etc.).

În mod normal, un ruter iBGP menţine sesiuni cu toate celelalte rutere iBGP din

AS, formînd o topologie logică full-mesh (fiecare cu fiecare). Acest lucru este

necesar deoarece, pentru a preveni formarea de cicluri de rutare, iBGP nu transmite

rute învăţate prin iBGP altor vecini care rulează iBGP. Dacă se doreşte ca ruterele

iBGP să schimbe rute BGP între ele, este necesară configurarea de reflectori de rute

(route reflector) sau confederaţii.

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 9/16

Cînd un ruter află despre o ruta nouă prin protocolul eBGP, va seta adresa

următorului hop la adresa ruterului vecin eBGP de la care a aflat ruta respectivă. Cînd

se primesc rute din interiorul ASului, adresa următorului hop rămîne neschimbată.

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

• 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

Din momentul în care sesiunea BGP funcţionează, ruterele schimbă mesaje de

tip UPDATE cu privire la destinaţiile către care expeditorul oferă conectivitate. În

 protocolul BGP, descrierea unei rute este numită  Informaţie de cale de nivel reţea

( Network Layer Reachability Information - NLRI). NLRI include mai multe atribute:

 prefixul destinaţie, lungimea prefixului, calea de sisteme autonome către destinaţie şiurmătorul hop, precum şi multe alte informaţii care afectează felul cum tratează

destinatarul reţeaua respectivă.

Ruterele BGP anunţă apoi, prin actualizări ulterioare, noile reţele către care

oferă conectivitate, dar şi "retragerile" (reţelele care nu mai sunt accesibile).

În timpul trimiterii mesajelor OPEN, ruterele BGP pot negocia anumite

capabilităţi opţionale, printre care mai multe tipuri de corectare a erorilor şi extensii

multiprotocol. Dacă extensiile multiprotocol ale BGP sunt negociate în acest

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 10/16

moment, vorbitorul poate prefixa NRLI-ul pe care îl publică cu un prefix pentru

familia de adrese (IPv4, IPv6, VPNuri IPv4 şi IPv6, precum şi multicast).

Din ce în ce mai mult, BGP este utilizat ca protocol de rutare pentru rute care nu

fac parte din Internet, ca de exemplu reţele private virtuale.

Pentru a decide felul în care colaborează cu alte rutere, BGP foloseşte o maşină 

de stare simplă, cu 6 stări: Inactiv, Conectare, Activ, Deschidere trimisă (OpenSent),

OpenConfirm şi Stabilit . Pentru fiecare sesiune, implementarea păstrează o variabilă

de stare. Standardul defineşte mesajele care trebuie trimise pentru a muta un ruter 

dintr-o stare în alta. Prima stare este Inactiv.

Starea inactiv - în acest mod, BGP iniţializează toate resursele, refuză toate

încercările de conexiune BGP şi iniţiază o conexiune TCP către ruterul vecin:

• Iniţializează resursele procesului BGP;

• Încearcă să stabilească o conexiune TCP cu vecinul BGP;

• Aşteaptă o conexiune TCP de la vecin. Dacă apare o eroare în oricare stare a

maşinii, sesiunea BGP este încheiată şi maşina de stare revine în starea Inactiv.

Unele dintre motivele pentru care un ruter nu trece de această stare sunt:

• Portul TCP 179 nu e deschis.

• Nu e deschis niciun port TCP mai mare decât 1023.

• Adresa vecinului este configurată incorect pe unul din rutere.

• Numărul AS este configurat incorect pe unul din rutere.

Starea conectare - î n acestă stare, ruterul efectuează următoarele operaţii:

• Aşteaptă stabilirea conexiunii TCP.

• Dacă aceasta se termină cu succes, BGP trece rapid la starea OpenSent .

• Trimite un mesaj OPEN vecinului.

• Dacă apare o eroare, ruterul resetează un timer şi trece în starea  Activ până la

expirare.

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 11/16

Unele din motivele care pot duce la acest comportament sunt ca şi în cazul

 precedent

Starea active - în starea Activ se ajunge dacă eşuează tentativa de conectare la

ruterul vecin; în această stare, ruterul resetează timerul de conectare şi se

întoarce în starea Conectare. Dacă şi a doua tentativă eşuează, se trece înapoi în

stare  Inactiv. Dacă tot nu se poate stabili conexiunea, ruterul va pendula între

sările activă şi inactivă. Unele din motivele acestui comportament sunt:

• Portul TCP 179 nu este deschis.

• Nu e deschis niciun port TCP mai mare decât 1023.

• Eroare în configurarea BGP.

• Congestia reţelei.

• Interfaţă de reţea cu probleme.

Starea OpenSent:

• La intrarea în această stare, ruterul aşteaptă un mesaj OPEN de la vecinul său.

• După ce mesajul a fost primit, ruterul îl verifică.• Dacă există o nepotrivire între valorile câmpurilor mesajului OPEN de pe cele

2 rutere (e.g. altă versiune de BGP, nepotrivirea parolei MD5, un alt număr de AS

decât cel aşteptat), ruterul receptor va trimite o notificare în care va explica de ce a

apărut eroarea.

• Dacă nu sunt erori, este trimis un mesaj KEEPALIVE.

Starea OpenConfirm:

• Ruterul aşteaptă un mesaj KEEPALIVE de la vecin.

• Dacă mesajul este primit, BGP trece în starea următoare (Stabilit ).

• Dacă nu este primit mesajul KEEPALIVE, ruterul se întoarce în starea Inactiv.

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 12/16

Starea stabilit:

În această stare, procesul BGP poate primi şi trimite mesaje de tip KEEPALIVE,

UPDATE şi NOTIFICATION. Mesajele de tip UPDATE sunt trimise pentru a

schimba informaţia trimisă vecinului despre o anumită rută. Dacă apare o eroare într-

un mesaj UPDATE primit, ruterul trimite înapoi un mesaj NOTIFICATION, închide

conexiunea şi trece în starea Inactiv.

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

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

BGP

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

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 

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 13/16

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

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

(Specific Cisco).

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

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 14/16

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

• mărirea timpului de convergenţă al BGP• complicarea configurării rutelor. Totuşi, aceste metode sunt obişnuite pentru

reţelele BGP.

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.

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 15/16

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

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

7/16/2019 Protocolul OSPF Si BGP

http://slidepdf.com/reader/full/protocolul-ospf-si-bgp 16/16

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.