Universitatea Politehnica din Bucuresti

Facultatea de Transporturi
Telecomenzi si Electronica in Transporturi







Studenti: Profesor indrumator:
Gologan Adriana Soriga Stefan
Radu Razvan
Tescan George

Border Gateway Protocol

BGP (Border Gateway Protocol) este protocolul de rutare folosit n nucleul
Internetului. El menine o tabel cu reele IP (sau "prefixe") care arat calea
folosit pentru a ajunge la reeaua 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 pstreaz toat calea). BGP nu
folosete aceleai metrici ca protocoalele de rutare folosite n interiorul AS-urilor,
ci ia decizii bazndu-se pe cale i pe politicile de rutare ale sistemului autonom din
care face parte.Protocolul a fost creat pentru a nlocui un alt protocol de rutare
(EGP) i pentru a permite rutarea descentralizat n Internet, fcnd inutil reeaua
de nucleu a acestuia, NSFNet. Din 1994, versiunea patru a protocolului este
folosit n Internet, toate versiunile anterioare fiind considerate depite. Cel mai
important progres al versiunii 4 a fost suportul pentru CIDR i folosirea agregrii
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 ambiguitile i a apropiat standardul de practicile curente din
industrie.Cei mai muli utilizatori de Internet nu folosesc n mod direct acest
protocol. Totui, deoarece majoritatea Internet Service Providerilor l folosesc
pentru a stabili rute ntre reelele respective, BGP este unul din cele mai importante
protocoale de pe Internet. Importana sa este comparabil cu a protocolului SS7
pentru stabilirea apelurilor telefonice ntre operatorii PSTN. Reelele IP de mari
dimensiuni folosesc BGP inclusiv n interiorul reelei, de exemplu pentru a lega
mai multe subreele 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).
Funcionare

Border Gateway Protocol este un protocol de rutare unic, deoarece, spre deosebire
de celelalte protocoale de rutare, stabilete i menine conexiuni ntre routerele
vecine folosind protocolul TCP. n cazul routerelor aflate n AS-uri diferite, o
conexiune BGP poate fi stabilit doar dac routerele sunt direct conectate.

Legtura se realizeaz pe portul TCP 179, fiind meninut prin mesaje periodice de
19 octei (intervalul implicit este de 60 de secunde).
eBGP i iBGP
Cnd BGP este rulat n interiorul unui sistem autonom, este folosit termenul iBGP
(Internal Border Gateway Protocol). Cnd este rulat ntre AS-uri, este numit eBGP
(External Border Gateway Protocol). n majoritatea ruterelor actuale, distana
administrativ (DA) pentru iBGP este mai mare (deci prioritatea este mai mic)
dect cea pentru alte protocoale de rutare intra-AS, care, la rndul lor, au D.A. mai
mare dect eBGP.Vecinii eBGP trebuie sa fie direct conectai pentru a fi realizat
conexiunea BGP, dar exist i excepii. De exemplu, implementrile Cisco au
opiunea "multihop", care permite realizarea de conexiuni eBGP ctre routere
nelegate direct. Aceast limitare nu exist pentru iBGP. Pentru a asigura rutarea
ntre toate nodurile din reea care ruleaz BGP poate fi folosit un protocol de rutare
IGP (OSPF, RIP etc.).n mod normal, un ruter iBGP menine sesiuni cu toate
celelalte routere iBGP din AS, formnd o topologie logica full-mesh (fiecare cu
fiecare). Acest lucru este necesar deoarece, pentru a preveni formarea de cicluri de
rutare, iBGP nu transmite rute nvate prin iBGP altor vecini care ruleaz iBGP.
Dac se dorete ca ruterele iBGP s schimbe rute BGP ntre ele, este necesar
configurarea de reflectori de rute (route reflectors) sau confederaii.Cnd un ruter
afl despre o ruta nou prin protocolul eBGP, va seta adresa urmtorului hop la
adresa ruterului vecin eBGP de la care a aflat ruta respectiv. Cnd se primesc rute
din interiorul AS-ului, adresa urmtorului hop rmne neschimbat.

Tipuri de mesaje BGP
Protocolul BGP folosete patru tipuri de mesaje pentru a comunica ntre rutere:
Open (Deschidere): mesajele iniiale, folosite pentru stabilirea conexiunii
ntre rutere; dac un ruter primete un mesaj Open i este de acord cu
coninutul, trebuie s rspund cu un mesaj Keepalive.
Keepalive (Meninere): mesaje de 19 octei trimise periodic (implicit la 60
de secunde - o treime din timpul de hold-down) pentru meninerea
conexiunii deschise; aceste mesaje sunt trimise fr confirmare, iar dac
intervalul de trimitere este setat la 0, nu se trimit.
Update (Actualizare): conin ci ctre diversele reele (accesibile, invalide
sau retrase), mpreun cu atributele corespunztoare; iniial, routerele BGP
i trimit reciproc ntreaga tabel de rutare; dup actualizarea iniial, se
transmit actualizri incrementale, pe msur ce topologia reelei se schimb.
Notification (Notificare): raporteaz eventualele erori aprute n
comunicaie
Actualizri
Din momentul n care sesiunea BGP funcioneaz, routerele schimb mesaje de tip
UPDATE cu privire la destinaiile ctre care expeditorul ofer conectivitate. n
protocolul BGP, descrierea unei rute este numit Informaie de cale de nivel reea
(Network Layer Reachability Information - NLRI). NLRI include mai multe
atribute: prefixul destinaie, lungimea prefixului, calea prin sistemele autonome
ctre destinaie (AS_Path) i urmtorul hop, precum i multe alte informaii care
afecteaz felul cum trateaz destinatarul reeaua respectiv.Ruterele BGP anun
apoi, prin actualizri ulterioare, noile reele ctre care ofer conectivitate, dar i
"retragerile" (reelele care nu mai sunt accesibile).
Extensii opionale
n timpul trimiterii mesajelor OPEN, routerele BGP pot negocia anumite
capabiliti opionale, printre care mai multe tipuri de corectare a erorilor i
extensii multiprotocol. Dac extensiile multiprotocol ale BGP sunt negociate n
acest moment, vorbitorul poate prefixa NRLI-ul pe care l public cu un prefix
pentru familia de adrese (IPv4, IPv6, VPN-uri 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 reele private virtuale.
Automat finit

Pentru a decide felul n care colaboreaz cu alte routere, BGP folosete un automat
finit simplu, cu 6 stri: Inactiv, Conectare, Activ, Deschidere trimis (OpenSent),
Deschidere confirmata (OpenConfirm) i Stabilit. Pentru fiecare sesiune,
implementarea pstreaz o variabil de stare. Standardul definete mesajele care
trebuie trimise pentru a muta un router dintr-o stare n alta. Prima stare este Inactiv.




Automatul finit al BGP

Starea I nactiva
n acest mod, BGP iniializeaz toate resursele, refuz toate ncercrile de
conexiune BGP i iniiaz o conexiune TCP ctre ruterul vecin:
Iniializeaz resursele procesului BGP;
ncearc s stabileasc o conexiune TCP cu vecinul BGP;
Ateapt o conexiune TCP de la vecin. Dac apare o eroare n oricare stare a
mainii, sesiunea BGP este ncheiat i maina 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 dect 1023.
Adresa vecinului este configurat incorect pe unul din routere.
Numrul AS este configurat incorect pe unul din routere.
Starea Conectare
n acest stare, ruterul efectueaz urmtoarele operaii:
Ateapt 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 pn la
expirare. Unele din motivele care pot duce la acest comportament sunt:
o Portul TCP 179 nu este deschis.
o Nu e deschis niciun port TCP mai mare dect 1023.
o Adresa vecinului e configurat incorect pe unul din routere.
o Numrul de AS este configurat incorect pe unul din routere.
o
Starea Activa

n starea Activ se ajunge dac eueaz 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 eueaz, se trece napoi n stare Inactiv. Dac
tot nu se poate stabili conexiunea, ruterul va pendula ntre strile activ i inactiv.
Unele din motivele acestui comportament sunt:
Portul TCP 179 nu este deschis.
Nu e deschis niciun port TCP mai mare dect 1023.
Eroare n configurarea BGP.
Congestia reelei.
Interfa de reea cu probleme.
Starea OpenSent
La intrarea n aceast stare, ruterul ateapt un mesaj OPEN de la vecinul
su.
Dup ce mesajul a fost primit, ruterul l verific.
Dac exist o nepotrivire ntre valorile cmpurilor mesajului OPEN de pe
cele 2 routere (e.g. alt versiune de BGP, nepotrivirea parolei MD5, un alt
numr de AS dect cel ateptat), ruterul receptor va trimite o notificare n
care va explica de ce a aprut eroarea.
Dac nu sunt erori, este trimis un mesaj KEEPALIVE.
Starea OpenConfirm
Ruterul ateapt un mesaj KEEPALIVE de la vecin.
Dac mesajul este primit, BGP trece n starea urmtoare (Stabilit).
Dac nu este primit mesajul KEEPALIVE, ruterul se ntoarce n starea
Inactiv.
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 informaia 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.
Conectivitate i nvarea 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 numrul de conexiuni crete cu ptratul numrului de rutere
conectate. Pentru a evita aceast problem au fost oferite dou soluii: reflectorii
de rute (RFC 4456) i confederaiile (RFC 5065). Dac nu este precizat altfel, n
aceast seciune se discut situaia conectrii fiecare cu fiecare.
Tabela de rutare
Implementarea de BGP de pe routerele Cisco, dar nu numai, pstreaz o tabel de
ci BGP separat de tabela de rutare i numit Loc-RIB (Local Routing
Information Base). Unele implementri pstreaz i tabele per vecin, coninnd
NLRI-urile 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 ctre o destinaie. n
schimb, tabela BGP (Loc-RIB) va conine 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 condiii:
o exist o nregistrare n tabela de rutare ctre urmtorul hop din calea
BGP
o ruta este aflata i prin intermediul unui IGP sau sincronizarea este
dezactivat
Un anumit ruter BGP poate accepta ci BGP de la mai muli vecini i poate trimite
actualizri acelorai vecini sau altora.
O greeal frecvent n ceea ce privete BGP este s se spun c "BGP transmite
politici". De fapt, BGP transmite doar informaii pe care procesele BGP le aplic
unor reguli pentru a lua decizii de rutare. Unele din aceste informaii sunt destinate
explicit folosirii n decizia de rutare: comunitile i multi-exit discriminators
(MED).
Selecia rutelor
Standardul specific mai muli factori de selecie a rutelor dect 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 implementrii) pentru a decide care rute vor ajunge n
Adj-RIB-In. Doar o rut ctre fiecare destinaie va ajunge n tabel, indiferent de
cte sunt trimise de vecin. De asemenea, procesul va terge din Adj-RIB-In toate
rutele retrase de vecin.Cnd tabela Adj-RIB-In se schimb, procesul analizeaz
noile rute pentru a vedea dac sunt mai bune dect cele aflate deja n Loc-RIB i le
nlocuiete dac este cazul. Dac o rut este retras de vecin i nu exist o alt rut
ctre destinaie, ea este tears i din Loc-RIB i din tabela de rutare (cu excepia
cazului n care un alt protocol de rutare are i el acest rut).
Criterii de selecie
Dup ce a verificat c vecinul este accesibil, procesul BGP ia decizia de rutare
conform urmtorului algoritm:
1. Dac nu exist dect o singur rut ctre o anumit destinaie, 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 dect AS4-AS5-
AS6-AS7)
6. La egalitate AS_Path, se alege ruta cu AS-ul 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
confederaie externe i n cele din urm rutele iBGP
9. Dac nu exist nicio rut extern, se alege ruta IGP care are cel mai sczut
cost ctre urmtorul ruter BGP (unele implementri ofert posibilitatea de
echilibrare a ncrcrii 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
mica.
Probleme ale BGP

Scalabilitatea iBGP
Un sistem autonom cu iBGP (internal BGP) trebuie s aib toate routerele iBGP
conectate fiecare cu fiecare. Aceast configuraie necesit ca fiecare ruter s
menin conexiuni cu toate celelalte routere, ceea ce poate cauza o degradare a
performanelor n cazul reelelor mari.
Reflectorii i confederaiile pot reduce numrul de conexiuni iBGP i automat
ncrcarea. n plus, confederaiile pot fi folosite la implementarea unei politici mai
amnunite.
Reflectorii reduc numrul de conexiuni necesare ntr-un AS. Este suficient ca un
singur ruter s aib conexiuni cu toate celelalte routere (s fie fcut reflector).
Celelalte routere din acel sistem autonom vor fi apoi configurate s se conecteze la
reflector.
Confederaiile sunt seturi de sisteme autonome. n practic, doar unul din numerele
AS va fi vizibil din Internet. Confederaiile sunt folosite n cadrul reelelor foarte
mari, n care un numr de AS mai mare este configurat pentru a ascunde alte
numere de AS mai mici. Confederaiile pot fi folosite mpreun cu reflectorii,
fiecare din ele fiind utile n anumite situaii.
Totui, aceste opiuni pot introduce la rndul lor anumite probleme, printre care:
oscilaia rutelor - att confederaiile ct i reflectorii sunt expuse
pericolului oscilaiilor (variaii periodice n alegerea cii optime spre
anumite destinaii). Pentru a fi evitate, trebuie folosite anumite reguli de
design care afecteaz att BGP, ct i protocolul de rutare intern.
rutare sub-optim
mrirea timpului de convergen al BGP
complicarea configurrii rutelor. Totui, aceste metode sunt obinuite
pentru reelele BGP.
Dimensiunea tabelei de rutare
Una din cele mai mari probleme ntmpinate de BGP, dar i de ntreaga
infrastructur Internet, provine de la creterea rapid a tabelei globale de rutare
(care conine toate rutele din Internet). Pe msur ce cerinele de memorie i de
putere de procesare cresc, ruterele mai vechi nu mai fac fa, utilitatea lor scznd
considerabil. Mult mai important, cutarea ntr-o tabel de mari dimensiuni
dureaz mai mult i provoac instabilitate n cazul schimbrilor importante de
topologie.
Pn la sfritul anului 2001, creterea tabelei de rutare era exponenial, ceea ce
crea ameninarea unor probleme grave de conexiune. Pentru a evita acest lucru s-
au luat o serie de msuri ntre ISP-uri, printre care utilizarea CIDR i agregarea
rutelor. Acest lucru a provocat o cretere liniar pn n 2004, cnd creterea a
devenit din nou exponenial datorit cererii de conexiuni redundante din partea
reelelor de mici dimensiuni. n ianuarie 2009, tabela de rutare global avea
aproximativ 300.000 intrri
[10]
.
Agregarea rutelor este un procedeu des folosit pentru a reduce dimensiunea
tabelelor de rutare. S spunem c sistemul autonom AS1 are spaiul de adrese
172.16.0.0/16, care ar ocupa o intrare n tabela de rutare, dar datorit cerinelor
clienilor, dorete s anune i trei rute specifice: 172.16.0.0/18, 172.16.64.0/18 i
172.16.128.0/18. Reeaua 172.16.192.0/18 nu e utilizat, aa 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 ctre prefixul 172.16.192.0/18, le
va trimite ctre 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 anune
c nu exist destinaia respectiv).
Dac AS1 renun la ruta 172.16.0.0/16, vor mai rmne 3 rute anunate. AS2 va
vedea cele trei rute i poate s le pstreze pe toate sau s agrege 172.16.0.0/18 i
172.16.64.0/18 n 172.16.0.0/17, reducnd numrul 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 ctre aceast reea, va eua nc din reeaua AS2.
Echilibrarea ncrcrii
Un alt factor care cauzeaz mrirea dimensiunii tabelei de rutare este echilibrarea
ncrcrii pentru reele cu mai multe legturi externe. Dac un ISP i public
reeaua ctre toi vecinii BGP, una sau mai multe dintre legturi pot fi
congestionate, pe cnd celelalte sunt sub-utilizate. Acest lucru se ntmpl n cazul
n care toi vecinii consider acele legturi ca optime. Ca i celelalte protocoale de
rutare, BGP nu detecteaz congestia.Pentru a evita aceast problem,
administratorii reelelor respective mpart blocul de adrese pe care l administreaz
n sub-blocuri i public pe fiecare legtur BGP un alt bloc de adrese. Acest lucru
duce la mrirea numrului de intrri din tabelele BGP.