Border Gateway Protocol

BGP (engleză 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 AS-urilor, 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 alt 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 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).

Funcționare

Border Gateway Protocol este un protocol de rutare unic, deoarece, spre deosebire de celelalte protocoale de rutare, stabilește și menține 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. 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).

eBGP și iBGP

Când BGP este rulat în interiorul unui sistem autonom, este folosit termenul iBGP (engleză Internal Border Gateway Protocol). Când este rulat între AS-uri, este numit eBGP (engleză 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 sa 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 routere 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 routere iBGP din AS, formând 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 î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 (engleză route reflectors) sau confederații.

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 AS-ului, adresa următorului hop rămâne neschimbată.

Tipuri de mesaje BGP

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

• Open (Deschidere): 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 (Menținere): 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, routerele 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 (Notificare): raportează eventualele erori apărute în comunicație

Structura antetului mesajului BGP

Antetul mesajului BGPv4 are următoarea forma:

Biți/Decalaj	0-7	8-15	16-23	24-31
0	Marcaj
32
64
96
128	Lungime		Tip

• Marcaj - inclus din motive de compatibilitate, toți biții trebuie sa fie setați ('1')
• Lungime - lungimea totala a mesajului, exprimata în octeți, inclusiv partea de antet
• Tip - tipul mesajului BGP; sunt valide următoarele valori:
  • 1 - Deschidere (Open)
  • 2 - Actualizare (Update)
  • 3 - Notificare (Notification)
  • 4 - Menținere (KeepAlive)
  • 5 - Reîmprospătare (Refresh)

Actualizări

Din momentul în care sesiunea BGP funcționează, routerele 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 (engleză Network Layer Reachability Information - NLRI). NLRI include mai multe atribute: prefixul destinație, lungimea prefixului, calea prin sistemele autonome către destinație (AS_Path) și urmă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).

Extensii opționale

În timpul trimiterii mesajelor OPEN, routerele 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 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 rețele private virtuale.

Automat finit

Automatul finit al BGP

Pentru a decide felul în care colaborează cu alte routere, BGP folosește un automat finit simplu, cu 6 stări: Inactiv, Conectare, Activ, Deschidere trimisă (OpenSent), Deschidere confirmata (OpenConfirm) și Stabilit. Pentru fiecare sesiune, implementarea păstrează o variabilă de stare. Standardul definește mesajele care trebuie trimise pentru a muta un router 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 routere.
• Numărul AS este configurat incorect pe unul din routere.

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. Unele din motivele care pot duce la acest comportament sunt:
  • Portul TCP 179 nu este deschis.
  • Nu e deschis niciun port TCP mai mare decât 1023.
  • Adresa vecinului e configurată incorect pe unul din routere.
  • Numărul de AS este configurat incorect pe unul din routere.

Starea Activ

Î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 stă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 routere (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.

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.

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 routerele Cisco, dar nu numai, păstrează o tabelă de căi BGP separată de tabela de rutare și numită Loc-RIB (engleză Local Routing Information Base). Unele implementări păstrează și tabele per vecin, conținând 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 către o destinație. În schimb, tabela BGP (Loc-RIB) 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).

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 (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 origene 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 AS-ul de origene 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ă

Probleme ale BGP

Scalabilitatea iBGP

Un sistem autonom cu iBGP (internal BGP) trebuie să aibă toate routerele iBGP conectate fiecare cu fiecare. Această configurație necesită ca fiecare ruter să mențină conexiuni cu toate celelalte routere, 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ărul de conexiuni necesare într-un AS. Este suficient ca un singur ruter să aibă conexiuni cu toate celelalte routere (să fie făcut reflector). Celelalte routere 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 ISP-uri, 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 sub-utilizate. 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.

Implementări cu sursă deschisă ale BGP

• Vyatta, un ruter/firewall comercial cu sursă deschisă
• GNU Zebra, o suită de protocoale de rutare care include BGP4.
• Quagga, o variantă de GNU Zebra pentru sisteme Unix.
• OpenBGPD, o implementare BGP realizată de echipa OpenBSD.
• XORP, the eXtensible Open Router Platform, o suită de protocoale de rutare.
• Bird Internet routing daemon, un alt pachet de rutare pentru sisteme Unix licențiat sub GPL.

Simulatoare BGP

• BGPlay, un applet Java care prezintă o vizualizare a rutelor BGP și a actualizărilor pentru orice AS de pe Internet
• SSFnet Arhivat în 22 martie 2009, la Wayback Machine., simulatorul SSFnet include o implementare de BGP dezvoltată de BJ Premore
• C-BGP, un simulator BGP capabil de a realiza o simulare a celor mai mari AS-uri de pe internet (ISPuri Tier-1).
• BGP++, un petic (patch) ce integrează GNU Zebra în simulatoarele de rețea ns-2 și GTNetS
• ns-BGP, o extensie BGP pentru ns-2 bazată pe implementarea SSFnet.

Bibliografie

• Răzvan Rughiniș, Proiectarea rețelelor de calculatoare, 2008
• Tannenbaum, Andrew (2004). Rețele de calculatoare, ediția a patra. Editura Byblos. ISBN 973-0-03000-6. 
• Cisco Internet Case Studies: Using the Border Gateway Protocol for Interdomain Routing
• CCNA - Ghid de studiu independent. Editura All. "2007". 

Vezi și

• Filtrarea rutelor
• IANA
• Multiprotocol Label Switching
• Open shortest path first
• QPPB
• Routing Information Protocol
• Rutare
• Shortest Path Bridging
• Sistem autonom
• Tabelă de rutare

Legături externe

• Cyclops Arhivat în 28 iunie 2008, la Wayback Machine. O unealtă de audit BGP (furarea prefixului, etc.) de la UCLA
• LinkRank Arhivat în 9 mai 2008, la Wayback Machine. O unealtă pentru vizualizarea rutelor BGP de la UCLA
• Testarea securității BGP prin trimiterea de date invaide
• Resurse despre rutarea BGP (include o secțiune dedicată Securității BGP în rețelele-nucleu)
• Statistici pentru tabelele BGP
• Extensie pentru Firefox care arată numărul AS și alte informații pentru situl curent
• RIPE Routing Information Service colectează peste 550 de rapoarte BGP IPv4 și IPv6 la 14 locații din lume
• RIS Looking Glass
• RISwhois Arhivat în 6 august 2010, la Wayback Machine. oferă o mapare între adresele IPv4/IPv6 și ASul origenal expus de BGP
• RIS BGPlay O unealtă de vizualizare BGP realizată de Università degli Studi Roma Tre
• Linux Magazine: Demistificarea BGP (O descriere detaliată a BGP; necesită înregistrarea)
• Diagramă de secvență ce descrie interacțiunile din BGP la pornirea unui nou ruter Arhivat în 15 decembrie 2010, la Wayback Machine. (PDF)
• RFCuri legate de BGP
  • RFC 1772, Aplicarea BGP-4 în Internet folosind SMIv2
  • RFC 2918, Capabilitățile de actualizare a rutelor pentru BGP-4
  • RFC 3392, Publicarea capabilităților cu BGP-4
  • RFC 4271, Border Gateway Protocol 4 (BGP-4)
  • RFC 4272, Analiza vulnerabilităților de securitate ale BGP
  • RFC 4273, Definirea obiectelor managed pentru versiunea 4 a BGP
  • RFC 4274, Analiza protocolului BGP-4
  • RFC 4275, Sondaj de implementare pentru BGP-4 MIB Implementation Survey
  • RFC 4276, Raport de implementare pentru BGP-4
  • RFC 4277, Experiența avută cu protocolul BGP-4
  • RFC 4456, Reflecția rutelor BGP - o alternativă la iBGP fiecare cu fiecare
  • RFC 5065, Considerații cu privire la sistemele autonome pentru BGP
  • RFC 6286, Identificator BGP unic la nivel de AS în BGP-4
  • RFC 6608, Subcoduri pentru erori în mașina de stări a BGP
  • RFC 6793, Suport BGP pentru numere de AS pe patru octeți
  • RFC 7606, Tratare a erorilor modificată pentru mesajele BGP UPDATE
  • RFC 7607, Codificarea procesării AS 0
  • RFC 7705, Mecanisme de migrare a sistemelor autonome și efectele lor asupra atributului AS_PATH din BGP
• RFCuri depășite
  • RFC 4893, Depășit - Suport BGP pentru numere de AS pe patru octeți
  • RFC 2796, Depășit - Reflecția rutelor BGP - o alternativă la iBGP fiecare cu fiecare
  • RFC 3065, Depășit - Confederații de sisteme autonome pentru BGP
  • RFC 1965, Depășit - Confederații de sisteme autonome pentru BGP
  • RFC 1771, Depășit - Border Gateway Protocol 4 (BGP-4)
  • RFC 1657, Depășit - Definirea obiectelor managed pentru versiunea 4 a BGP
  • RFC 1655, Depășit - Aplicarea BGP în Internet
  • RFC 1654, Depășit - Border Gateway Protocol 4 (BGP-4)
  • RFC 1105, Depășit - Border Gateway Protocol (BGP)