Reflecția rutei BGP - o alternativă la IBGP-ul complet
Statutul documentului
Acest document conține specificațiile protocolului propus comunității Internet. Documentul servește drept invitație la discuție pentru a dezvolta și îmbunătăți protocolul. Stadiul actual al standardizării protocolului poate fi găsit în documentul "Standarde oficiale de protocol internet" (STD 1). Documentul poate fi distribuit fără restricții.
BGP 1 [1] este un protocol de rutare inter-domeniu dezvoltat pentru rețelele TCP / IP. În prezent, rețeaua BGP Internet Protocol este configurat astfel încât toate difuzoarele BGP într-un singur sistem trebuie să fie setat pe deplin de tip plasă a conexiunilor (complet tip plasă), precum și orice informații de rutare externă trebuie să fie comunicate tuturor celorlalte routere în acel AS. Acest lucru cauzează probleme serioase de scalare, care sunt descrise în detaliu împreună cu propuneri alternative în documente [2,3].
Acest document descrie metoda "Reflecției rutei" și utilizarea acesteia, slăbind cerința de conectivitate completă pentru IBGP.
1. Introducere
În prezent, Internetul BGP este configurat astfel încât toate nodurile BGP dintr-un AS să formeze un set complet de conexiuni conectate și orice informație de rutare externă trebuie să fie transmisă tuturor celorlalte routere din AS. Pentru n nodurile BGP din acest AS, este necesar să se organizeze n * (n-1) / 2 sesiuni IBGP unice. Evident, cerința de conectivitate completă devine imposibilă în sistemele în care un număr mare de noduri IBGP schimbă cantități semnificative de informații de rutare (acesta este cazul în majoritatea rețelelor moderne).
Această problemă de scalare și numeroase sugestii de reducere a clarității sunt descrise în detaliu în documente [2,3]. Acest document prezintă încă o altă versiune a eliminării conectivității complete, cunoscută sub numele de Reflecție a traseului. Această metodă permite difuzorului BGP (numit Reflector de rută) să anunțe rutele primite de la IBGP unor parteneri IBGP. Modifică conceptul de muncă general acceptat și adaugă două noi atribute non-transitive opționale BGP pentru a preveni buclele la actualizarea rutelor.
Acest document este o revizuire a RFC1966 [4] și include corecții editoriale, explicații și corecții bazate pe experiența utilizării reflexiilor rutelor. Lista modificărilor este prezentată în Anexă.
2. Cerințe de bază
Metoda "Reflecție rută" îndeplinește următoarele criterii.
Orice adăugare ar trebui să fie ușor de înțeles și ușor de configurat.
Ar trebui să existe posibilitatea migrării dintr-o configurație completă a rețelei fără a fi nevoie să modificați topologia sau AS. Metoda propusă în [3] introduce costuri prea mari în partea de management.
Aceste criterii se bazează pe experiența utilizării metodei în rețele foarte mari, cu o topologie complexă și o mulțime de conexiuni externe.
3. Reflecția rutelor
Ideea principală a metodei de reflecție (Rândul de reflecție) este foarte simplă. Luați în considerare exemplul prezentat în figura 1.
Figura 1: Sistem IBGP cu corp integral
În sistemul ASX autonom, există trei noduri IBGP (routere RTR-A, RTR-B, RTR-C). În cadrul modelului BGP existent, dacă RTR-A primește o rută externă și alege această rută ca fiind cea mai bună, trebuie să anunțe această rută externă atât la nodurile RTR-B, cât și la RTR-C. Nodurile RTR-B și RTR-C (ca noduri IBGP) nu vor reînnoi acest traseu de la IBGP către alți parteneri IBGP.
Dacă această politică este de a slăbi și de a permite nodului RTR-C face publicitate rute primite de la IBGP IBGP alți parteneri, atunci va re-face publicitate (sau reflecta) rute IBGP învățat de la RTR-A, nodul RTR-B și vice-versa. Acest lucru ar elimina organizarea sesiunii IBGP între nodurile RTR-A și RTR-B, așa cum se arată în figura 2.
Figura 2: IBGP cu reflexii ale traseului
Schema metodei de reflectare a rutei se bazează pe acest principiu.
4. Terminologie și concepte
Folosim termenul "reflecție ruta" pentru a descrie acțiunile unui vorbitor BGP care promovează rutele primite de la IBGP către alți parteneri IBGP. Dacă un difuzor BGP este denumit "Reflector de rută" (RR), acest lucru înseamnă că nodul "reflectă" rutele pe care le-a primit partenerilor săi.
Parteneri non-client.
Nodul RR reflectă rutele între aceste grupuri și poate reflecta rutele între clienți. Nodul RR, împreună cu clienții săi, formează un cluster (Cluster).
Persoanele non-Client trebuie să rămână conectate complet, dar această cerință este eliminată pentru clienți. Figura 3 prezintă un exemplu de rețea cu componente de bază RR, care ilustrează terminologia.
Figura 3: Componentele RR
Partenerii interni ai nodului RR sunt împărțiți în două grupuri:
5. Lucrarea metodei
Când RR primește o rută de la partenerul IBGP, acesta alege cea mai bună rută pe baza criteriilor sale. După selectarea celei mai bune căi, nodul trebuie să efectueze următoarele operații, în funcție de tipul de partener care a raportat cea mai bună cale:
Traseul este primit de la un partener care nu este client.
Reflectă ruta către toți clienții.
Traseul este primit de la client.
Reflectați ruta către toți partenerii non-clienți, precum și către partenerii-clienți (deoarece clienții nu pot fi pe deplin conectați).
Un sistem autonom poate include mai multe RR-uri. Nodul RR interpretează celelalte reflectoare RR, ca noduri BGP interne uzuale. Reflectorul RR poate fi configurat pentru a prezenta alte RR atât în numărul de clienți, cât și în rândul partenerilor care nu sunt clienți.
Într-o configurație simplă, rețeaua coloanei vertebrale poate fi împărțită în mai multe clustere. Fiecare reflector RR este ajustat la faptul că celelalte RR nu aparțin grupului de clienți (astfel, toate RR vor forma un sistem complet conectat). Clienții vor fi configurați să susțină sesiunile IBGP numai cu RR în grupul lor. Datorită reflectării rutelor, toate nodurile IBGP vor primi informații despre rutare reflectate.
Într-un sistem autonom, pot exista noduri BGP care nu înțeleg conceptul de rute de reflecție (le vom numi noduri BGP normale). Schema de oglindire a traseului permite coexistența cu nodurile BGP obișnuite. Astfel de noduri pot face parte dintr-un grup de clienți sau nu pot fi clienți ai RR. Aceasta oferă o oportunitate pentru o tranziție simplă și treptată de la modelul de lucru IBGP existent la modelul cu reflectarea rutelor. Puteți începe prin crearea unui cluster prin configurarea unui router ca RR desemnat și configurarea restului RR și a clienților săi ca parteneri normali ai IBGP. Treptat, pot fi create clustere suplimentare.
6. Excesul RR
De obicei, un grup de clienți va include un reflector RR. În acest caz, clusterul va fi identificat de valoarea ROUTER_ID a reflectorului RR. Cu toate acestea, o astfel de opțiune poate să nu furnizeze suficientă fiabilitate și o pluralitate de RR poate fi creată într-un singur grup pentru redundanță. Toate reflectoarele RR într-un singur cluster pot fi configurate astfel încât să utilizeze CLUSTER_ID-ul comun de 4 byte, care permite oricărui RR să respingă rutele primite de la alte RR în același cluster.
7. Prevenirea buclelor
Când se utilizează reflexia rutelor, este posibilă crearea unor bucle în timpul rezonanței ca urmare a unei configurații incorecte. Metoda "Reflecție rută" definește două atribute noi pentru detectarea și prevenirea unor astfel de bucle.
ORIGINATOR_ID este un atribut BGP opțional, intransist, cu codul de tip 9. Acest atribut este de 4 octeți în dimensiune și este creat de reflectorul RR în calea oglindită. Atributul va include ROUTER_ID-ul inițiatorului în AS-ul local. Speakerul BGP nu trebuie să creeze atributul ORIGINATOR_ID dacă acesta din urmă este deja prezent. Un router care recunoaște atributul ORIGINATOR_ID ar trebui să ignore ruta care conține valoarea sa ROUTER_ID ca ORIGINATOR_ID.
CLUSTER_LIST este un atribut BGP opțional, intransist, cu un cod de tip de 10. Acest atribut este o secvență de valori CLUSTER_ID reprezentând calea de reflecție pe care a fost transmis traseul. Formatul atributului este prezentat mai jos.
Câmpul Lungime 3 indică numărul de octeți.
Atunci când un RR reflectă o rută, acesta trebuie să adauge CLUSTER_ID locale la început (Prepend) CLUSTER_LIST. Dacă CLUSTER_LIST este gol, nodul trebuie să creeze o listă nouă. Utilizând acest atribut, RR poate detecta apariția buclelor în timpul transmiterii informațiilor de rutare ca urmare a erorilor de configurare. Dacă valoarea locală a CLUSTER_ID este prezentă în lista de cluster, anunțul primit trebuie ignorat.
8. Punerea în aplicare a metodei
Trebuie luate măsuri pentru a împiedica modificarea atributelor de trase descrise mai sus (mijloace de configurare) în timpul schimbului de informații despre rute între RR și clienți sau parteneri non-client. O astfel de schimbare a atributelor poate duce la apariția unor bucle de buclă.
În plus, atunci când un RR reflectă o rută, aceasta nu ar trebui să fie schimbat în calea atribute: NEXT_HOP, AS_PATH, LOCAL_PREF și MED, deoarece acest lucru poate duce la bucle de rutare.
9. Considerații privind configurarea și implementarea
BGP nu oferă clienților posibilitatea de a se identifica dinamic ca clienți RR. Cea mai ușoară modalitate de a face acest lucru este configurarea manuală a configurației.
Unul dintre punctele-cheie ale metodei de reflectare a rutelor în contextul problemei de scalare este că RR procesează informațiile primite și reflectă numai cel mai bun mod.
Alegerea rutei BGP poate fi afectată de valorile MED și IGP. Deoarece atributele MED nu sunt întotdeauna compatibile și pot fi diferite metrice IGP pentru fiecare router, în unele exemple de realizare, metoda de reflecție de reflecție topologie poate furniza la selectarea rezultatului traseului, cel al sistemului IBGP plin. Pentru a obține aceleași rezultate ar fi cu abordarea plasă completă IBGP ar trebui să vă asigurați că reflectoare de rută nu alege cel mai bun traseu pe baza valorilor IGP BGP, care diferă în mod semnificativ de IGP-metrici ale clienților lor, sau pe baza inconsistente MED atribute. Primul exemplu de realizare poate fi realizată prin ajustarea configurației, astfel încât intra metric prevalând dat IGP întotdeauna peste intercluster metric IGP și sprijină conectivitatea totală (mesh complet) din cluster. Pentru a implementa a doua opțiune, puteți utiliza oricare dintre următoarele metode:
setați nivelul de preferință pentru rutarea locală la MED pe ruterul de margine;
asigurați-vă că lungimile AS_PATH pentru diferite AS-uri diferă atunci când se utilizează lungimea căii ca criteriu de selecție;
a stabilit o politică bazată pe comunitate, a cărei utilizare va permite reflectorului să aleagă cea mai bună cale.
Se poate argumenta că a doua opțiune introduce restricții excesive și, în unele cazuri, nu va fi practică. Se poate argumenta, de asemenea, că, în absența buclelor de traseu, nu este necesar să se asigure că rezultatele selecției rutei coincid cu utilizarea reflecției și a unui sistem IBGP complet conectat.
Pentru a preveni bucle de rutare și să mențină rutare coerente este important să se ia în considerare cu atenție topologia rețelei atunci când aleg o topologie traseu de reflecție. În cazul general, topologia reflecției ar trebui să fie făcută de topologia congruentă a rețelei, atunci când există multe căi pentru acest prefix. Este comună de a utiliza POP bazate pe reflexie, în care fiecare POP își menține propriile sale reflectoare de rută care deservesc clienții în POP, și toate reflectoarele sunt pe deplin ochiuri. În plus, clienții reflectoarele din fiecare POP adesea complet discretizat pentru rutarea optimă în cadrul POP și interior (POP) metric este preferat în comparație IGP cu metrica IGP inter-POP.
10. Considerații privind securitatea
Această extensie BGP nu modifică securitatea inerentă IBGP [5].
11. Credite
13. Literatură
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Aplicație. Comparație cu RFC 1966
Explicat câțiva termeni asociați cu reflexia rutelor și a exclus menționarea rutelor și nodurilor EBGP.
Explicat și făcând mai brute bucle de rutare pentru destinatari (ca rezultat al reflecției).
Modul de adăugare a atributului CLUSTER_ID în lista CLUSTER_LIST a fost înlocuit de la "append" la "prepend" în conformitate cu codul implementat.
Capitolul "Probleme de configurare și implementare" a adăugat examinarea unor întrebări legate de implementarea metodei.
Permisele limitate acordate sunt perpetue și nu vor fi revocate de Societatea de Internet sau de succesorii săi sau de cesionari.
Acest document și informațiile conținute în acest document sunt furnizate „CA ATARE“ și Societatea Internet și de inginerie INTERNET TASK FORCE RENUNTA LA ORICE GARANȚII, EXPLICITE SAU IMPLICITE, INCLUSIV, DAR FĂRĂ A SE LIMITA LA ORICE GARANȚIE CARE UTILIZAREA, informațiile prezentate aici nu va ÎNCÃLCA DREPTURI SAU ORICE GARANTII COMERCIALE SAU POTRIVIRE PENTRU UN ANUMIT SCOP.
confirmare
Finanțarea funcțiilor Editorului RFC este asigurată de Societatea Internet.
1 Protocolul de frontieră pentru frontieră - protocolul de intrare a frontierei.
2 În original, se spune în mod eronat despre două atribute tranzitorii, care nu corespund definițiilor capitolului 7. Notă. Trans.
3 Câmpul Lungime este indicat în mod eronat în figură ca fiind un octet. Dimensiunea acestui câmp poate fi de 1 sau 2 octeți, în funcție de valoarea indicelui Lungime extinsă (vezi paragraful 4.3 din RFC 4271). Aproximativ Trans.
4 Acest document nu mai este valabil și a fost înlocuit cu RFC 4271. Traducerea este disponibilă pe site-ul www.protocols.ru. Aproximativ Trans.
5 În original, acest document este eronat numit "Confederații Autonome Sistem Limitat pentru BGP". Aproximativ Trans.
