diferențele dintre as-OVERRIDE și ALLOWAS-IN

introducere

ALLOWAS-IN și AS-OVERRIDE sunt două funcționalități similare care pot fi utilizate într-un scenariu în care unul as X (de exemplu, furnizorul) este conectat la altul ca Y (de exemplu, operatorul de tranzit / mpl-urile coloanei vertebrale) prin mai multe site-uri/POP-uri,. Pentru a înțelege mai bine ambele funcționalități, este adecvat să analizăm modul în care funcționează controlul buclelor din Protocolul BGP (RFC 4271).

specificația protocolului BGP oferă mai multe mecanisme pentru controlul și prevenirea buclei. Într-un scenariu iBGP (adică sesiuni BGP în cadrul aceluiași ca) de exemplu, regula orizontului divizat este unul dintre mecanismele de control și prevenire a buclei care împiedică prefixele anunțate de un vecin iBGP (a) vecinului iBGP (B) să fie re-anunțate de (B) unui al treilea vecin iBGP (C). Există mai multe soluții posibile disponibile pentru a “relaxa” această regulă (utilizarea reflectoarelor de traseu este una dintre ele, de exemplu), dar acestea nu vor fi discutate în acest articol.

deja în scenariile eBGP (adică sesiuni BGP între diferiți ași) cel mai simplu mecanism de control și prevenire a buclei este analiza atributului as_path. În esență, dacă peer-ul eBGP(A) își găsește propriul ASN în atributul as_path al prefixului(prefixelor) promovat de peer-ul eBGP (B) (și invers), routerul aruncă apoi prefixul pentru a evita o posibilă buclă de rutare. ALLOWAS – IN și AS-OVERRIDE sunt două soluții similare care pot fi utilizate în acest caz și, din acel moment, vom detalia în ce fel de situații putem folosi una sau alta.

ALLOWAS-IN

luați în considerare scenariul din Figura 1 Unde AS 20 (furnizor) este As 10 (upstream) client de tranzit. Topologii de această natură pot apărea cu o anumită frecvență, de exemplu, la furnizorii de Internet care nu au nicio legătură fizică între IP Pop-urile lor și trebuie să achiziționeze IP transit de la un Upstream pentru a oferi acces la internet abonaților lor în fiecare PoP/localitate.

Figura 1: client (AS 20) conectat la ISP / UPSTREAM (as 10) în două Pop-uri în locații distincte.

În acest scenariu, R2 va anunța prefixul 10.0.0.0/24 pentru Upstream, iar as_path-ul acelui prefix va fi văzut după cum urmează pe routerul upstream:

R1_Upstream#sh ip bgp 10.0.0.0/24 Network Next Hop Metric LocPrf Weight Path*> 10.0.0.0/24 100.64.0.2 100 20 i

în urma funcționării “normale” a protocolului BGP (adică ignorând filtrele, politicile de rutare etc.).), atributul as_path al prefixului va fi modificat la R1 înainte de a fi re-anunțat către colegii săi. Lista” nouă ” ca cale a prefixului va arăta cam așa:

AS_PATH: 10 20 i

cu toate acestea, atunci când mesajul de actualizare BGP care poartă prefixul 10.0.0.0 / 24 ajunge la R3, R3 va renunța la această actualizare, având în vedere că va observa prezența propriului ASN (20 în acest caz) în atributul as_path al acelui prefix. O alertă similară cu aceasta poate fi văzută în Jurnalul routerului R3 (platforma Cisco IOS, modul de depanare):

aici intră în joc ALLOWAS-IN pentru a relaxa această restricție. ALLOWAS-IN este configurat pe routerul furnizorului, în acest caz R3. Efectul este că pur și simplu BGP va accepta posibila prezență proprie ca în as_path de prefixe primite din amonte.

pe majoritatea platformelor (Cisco, Juniper etc.) ALLOWAS-In necesită un parametru, care este numărul maxim de apariții tolerate de propriul ASN în atributul as_path asociat cu prefixele primite. De exemplu, în Cisco IOS, dacă dorim să permitem apariția de până la 2 ori a propriului ASN, în actualizările rutelor primite prin peer eBGP 1.1.1.1 (R1_Upstream) configurația este după cum urmează:

R3# conf tR3# (config) router bgp 20R3# (config-router) neighbor 1.1.1.1 allowas-in 2

în exemplul de mai sus, realizăm configurația astfel încât să putem învăța prefixe care conțin cel mult 2 apariții ale propriului ASN în câmpul as-PATH atunci când se îndepărtează de vecinul 1.1.1.1, care ar satisface scenariul diagramei expuse anterior. Este important să rețineți că ALLOWAS-IN trebuie să fie configurat pe toate routerele client pe care se dorește relaxarea regulii de control a buclei BGP!

să ne uităm la un exemplu mai complet (și cu modul de depanare activat pe platforma Cisco IOS). În terminal este posibil să vedeți destul de clar mesajul de actualizare BGP care conține structura de date care transportă informații despre prefix și masca de subrețea (Network Layer Reachability Information – NLRI). În cele ce urmează se poate observa că routerul a detectat prezența AS 20 în atributul as_path al prefixului 10.0.0.0 / 24 anunțat de r1_upstream( vecinul 1.1.1.1), dar a instalat prefixul în tabelul de redirecționare (FIB) datorită relaxării restricției impuse de configurația” allowas-in ” pentru vecinul 1.1.1.1:

as-OVERRIDE

după cum sa menționat deja, funcționalitatea as-OVERRIDE este destul de similară cu ALLOWAS-IN în ceea ce privește obiectivul dorit, care este de a relaxa controlul buclei protocolului BGP. Cu toate acestea, marea diferență dintre cele două este că modifică atributul as_path al prefixului prin înlocuirea prezenței ASN-ului “cauzal” al buclei cu ASN-ul amonte în sine. Ca rezultat, as-OVERRIDE este întotdeauna configurat pe partea upstream (furnizor de servicii), în timp ce toate allowas-in configurație este efectuată pe partea de client.

de asemenea, este demn de remarcat faptul că utilizarea as-OVERRIDE este în general asociată cu scenariile Layer 3 VPN (L3VPN) pe o rețea MPLS gestionată. În acest tip de scenariu, clientul are mai multe site-uri și folosește BGP ca protocol de rutare între CE-ul său din amonte (marginea clientului) și pe (marginea furnizorului). În acest caz, as-OVERRIDE se aplică pe routerele PE, iar efectul va fi înlocuirea CE ASN cu PE ASN înainte ca prefixul(prefixele) să fie reanunțat la celelalte PE din rețeaua MPLS.

în diagrama de deasupra routerului CE / R3 ar primi prefixul 10.0.0.0 / 24 cu atributul as-PATH “20 10” și apoi aș respinge anunțul din cauza mecanismului de prevenire a buclei BGP deja discutat mai devreme. Cu toate acestea, dacă configurația as-OVERRIDE este efectuată pe PE1, routerul CE/R3 va primi prefixul 10.0.0.0 / 24 cu atributul as-path “10 10” și, prin urmare, prefixul va fi instalat pe FIB. Este extrem de important să subliniem că AS-OVERRIDE trebuie configurat pe toate routerele PE pentru a asigura accesibilitatea prefixelor clientului în cadrul L3VPN!

Din punct de vedere operațional, configurația as-OVERRIDE este prea simplă pe cele mai actuale routers.As un exemplu, să ne uităm la configurația pe Cisco IOS pentru scenariul de mai sus:

configurația as-OVERRIDE se va reseta în sesiunea BGP între PE și CE. În cele ce urmează, va fi posibil să verificați prefixele originare sau anunțate de routerele CE ale acestui VPNv4 conține doar ASN-ul PE (în amonte) în atributul AS_PATH:

utilizarea as-OVERRIDE trebuie să fie bine gândită și planificată pentru a evita problemele sau inconsecvențele în redirecționarea pachetelor, la urma urmei ne relaxăm și ne relaxăm Un mecanism auxiliar pentru prevenirea acestor probleme este utilizarea comunității extinse BGP “Site of Origin-SoO” pentru a identifica prefixele IP pe care fiecare site client VPN le provine și le anunță altor CE prin L3VPN. Cu toate acestea, în acest articol nu vom discuta acest subiect și este un subiect suplimentar de cercetare pentru cititor.

autori: Daniel Damitoe Humberto Galiza

Lasă un răspuns

Adresa ta de email nu va fi publicată.