az as-OVERRIDE és az ALLOWAS-in közötti különbségek

bevezetés

az ALLOWAS – IN és az as-OVERRIDE két hasonló funkció, amelyek alkalmazhatók olyan esetekben, amikor az egyik as X (pl. szolgáltató) csatlakozik egy másik as Y-hoz (pl. transit operator / backbone MPLS) több webhelyen/Pop-on keresztül,. Mindkét funkció jobb megértése érdekében helyénvaló elemezni, hogyan működik a hurkok vezérlése a BGP protokollban (RFC 4271).

a BGP protokoll specifikációja számos mechanizmust biztosít a hurok vezérléséhez és megelőzéséhez. Például egy iBGP-forgatókönyvben (azaz BGP-munkamenetek a-n belül) a split-horizon szabály az egyik hurokvezérlő és megelőzési mechanizmus, amely megakadályozza, hogy az IBGP-szomszéd (A) által az iBGP-szomszéd (B) által bejelentett előtagokat a (B) újból bejelentse egy harmadik iBGP-szomszédnak (C). Számos lehetséges megoldás áll rendelkezésre ennek a szabálynak a” lazítására ” (például az útvonal-reflektorok használata), de ezeket nem tárgyaljuk ebben a cikkben.

már az eBGP-forgatókönyvekben (azaz a különböző ász-ok közötti BGP-munkamenetekben) a legegyszerűbb hurokvezérlő és megelőzési mechanizmus az as_path attribútum elemzése. Lényegében, ha az eBGP peer(A) megtalálja a saját ASN-jét az eBGP peer(B) által hirdetett előtag (ok) as_path attribútumában (és fordítva), akkor az útválasztó elveti az előtagot, hogy elkerülje az esetleges útválasztási ciklust. Az ALLOWAS-IN és az AS-OVERRIDE két hasonló megoldás, amelyek ebben az esetben alkalmazhatók, és ettől a ponttól kezdve részletezzük, hogy milyen helyzetekben használhatjuk az egyiket vagy a másikat.

ALLOWAS-in

tekintsük az 1.ábrán látható forgatókönyvet, ahol AS 20 (szolgáltató) as 10 (upstream) tranzit kliens. Az ilyen jellegű topológiák bizonyos gyakorisággal előfordulhatnak, például olyan internetszolgáltatóknál, amelyeknek nincs fizikai kapcsolatuk az IP-Pop-ok között, és IP-tranzitot kell vásárolniuk egy Upstream-től, hogy internet-hozzáférést biztosítsanak előfizetőiknek minden PoP-ban/helységben.

1.ábra: kliens (AS 20) csatlakozik az internetszolgáltatóhoz / UPSTREAM (as 10) két Pop-ban, különböző helyeken.

ebben a forgatókönyvben az R2 bejelenti a 10.0.0.0/24 előtagot az Upstream útválasztón, és ennek az előtagnak az as_path-ja a következőképpen jelenik meg az upstream útválasztón:

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

a BGP protokoll “normál” működését követve (azaz figyelmen kívül hagyva a szűrőket, az útválasztási házirendeket stb.).), az előtag as_path attribútuma R1-re módosul, mielőtt újra hirdetik társai felé. Az előtag ” új ” as-PATH listája így fog kinézni:

AS_PATH: 10 20 i

amikor azonban a 10.0.0.0 / 24 előtagot hordozó BGP frissítési üzenet eléri az R3-At, az R3 elveti ezt a frissítést, mivel észreveszi a saját ASN (ebben az esetben 20) jelenlétét az előtag as_path attribútumában. Ehhez hasonló riasztás látható az R3 útválasztó naplójában (Cisco IOS platform, hibakeresési mód):

itt jön létre az ALLOWAS-IN, hogy enyhítse ezt a korlátozást. Az ALLOWAS-IN a Szolgáltató útválasztóján van konfigurálva, ebben az esetben R3. A hatás az, hogy egyszerűen a BGP elfogadja a saját lehetséges jelenlétét, mint az Upstream-től kapott előtagok as_path-jában.

a legtöbb platformon (Cisco, Juniper stb.) ALLOWAS-IN igényel paramétert, amely a maximális előfordulások száma tolerálható saját ASN a as_path attribútum társított kapott előtagokat. Például a Cisco IOS-ban, ha a saját ASN-jének akár 2-szeresét is meg akarjuk engedni, a peer eBGP 1.1.1.1 (R1_Upstream) útján kapott útvonalfrissítésekben a konfiguráció a következő:

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

a fenti példában úgy hajtjuk végre a konfigurációt, hogy megtanulhassuk azokat az előtagokat, amelyek legfeljebb 2 saját ASN előfordulását tartalmazzák az as-PATH mezőben, amikor eltér az 1.1.1.1 szomszédtól, amely megfelelne a korábban bemutatott diagram forgatókönyvének. Fontos megjegyezni, hogy az ALLOWAS-IN-t minden olyan kliens útválasztón be kell állítani, amelyen a BGP hurok vezérlési szabályát szeretné lazítani!

nézzünk egy teljesebb példát (és a hibakeresési mód engedélyezve van a Cisco IOS platformon). A terminálon világosan látható a BGP frissítési üzenet, amely tartalmazza az előtagról és az alhálózati maszkról információt hordozó adatstruktúrát (Network Layer Reachability Information – Nlri). A következőkben meg lehet jegyezni, hogy az útválasztó észlelte az AS 20 jelenlétét a 10.0.0.0/24 előtag as_path attribútumában, amelyet az r1_upstream (1.1.1.1 szomszéd) jelentett be, de az előtagot a továbbítási táblába (FIB) telepítette, mivel enyhült az 1.1.1.1 szomszéd “allowas-in” konfigurációja által előírt korlátozás:

as-OVERRIDE

mint már említettük, az as-OVERRIDE funkció meglehetősen hasonló az ALLOWAS-IN-hez a kívánt cél tekintetében, amely a BGP protokoll hurok vezérlésének lazítása. A kettő közötti nagy különbség azonban az, hogy módosítja az előtag as_path attribútumát azáltal, hogy a hurok “okozati” ASN jelenlétét maga az Upstream ASN-jével helyettesíti. Ennek eredményeként az AS-OVERRIDE mindig az upstream (szolgáltató) oldalon van konfigurálva, míg az összes allowas-in konfiguráció a kliens oldalon történik.

azt is érdemes megjegyezni, hogy az as-OVERRIDE használata általában a 3.réteg VPN (L3VPN) forgatókönyveihez kapcsolódik egy felügyelt MPLS hálózaton. Ebben a forgatókönyvben az ügyfélnek több telephelye van, és a BGP-t használja útválasztási protokollként az upstream CE (Ügyfélél) és a PE (szolgáltató él) között. Ebben az esetben az AS-OVERRIDE-t alkalmazzák a PE útválasztókon, és a hatás a CE ASN helyettesítése a PE ASN-vel, mielőtt az előtag(ok) újra megjelennek az MPLS hálózat többi PE-jének.

a fenti ábrán a CE / R3 router a 10.0.0.0 / 24 előtagot kapja az as-PATH attribútummal “20 10”, majd elutasítom a bejelentést a korábban már tárgyalt BGP hurok-megelőzési mechanizmus miatt. Ha azonban az as-OVERRIDE konfigurációt PE1-en hajtják végre, akkor a CE/R3 útválasztó megkapja a 10.0.0.0 / 24 előtagot az as-path attribútummal “10 10”, ezért az előtag telepítve lesz a FIB-re. Rendkívül fontos kiemelni, hogy az AS-OVERRIDE-t minden PE útválasztón konfigurálni kell, hogy biztosítsák az ügyfél előtagok elérhetőségét az L3VPN-en belül!

működési szempontból az AS-OVERRIDE konfiguráció túl egyszerű a legtöbb aktuális routers.As például nézzük meg a Cisco IOS konfigurációját a fenti forgatókönyvhöz:

az as-OVERRIDE konfiguráció visszaáll a PE és a CE közötti BGP munkamenetben. A következőkben ellenőrizni lehet A VPNV4 CE útválasztói által létrehozott vagy bejelentett előtagokat, amelyek csak a PE (Upstream) ASN-jét tartalmazzák az as_path attribútumban:

Az as-OVERRIDE használatát jól át kell gondolni és meg kell tervezni, hogy elkerüljük a csomagok továbbításának problémáit vagy következetlenségeit, elvégre pihentető Egy kiegészítő mechanizmus megelőzésére ezeket a problémákat a használata a BGP kiterjesztett közösség “Site of Origin – SoO” azonosítani az IP előtagok, hogy minden VPN kliens oldalon származik, és bejelenti, hogy más CE keresztül L3VPN. Ebben a cikkben azonban nem tárgyaljuk ezt a témát, ez egy további kutatási téma az olvasó számára.

szerzők: Daniel Damitoe Humberto Galiza

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.