erot as-OVERRIDE-ja ALLOWAS-in

introduction

ALLOWAS-in ja AS-OVERRIDE ovat kaksi samanlaista toimintoa, joita voidaan käyttää skenaariossa, jossa yksi as X (esim.tarjoaja) on liitetty toiseen as Y: hen (esim. kauttakulkuoperaattori/backbone MPLS) useiden sivustojen / PoPs: ien kautta. Molempien toimintojen ymmärtämiseksi on aiheellista analysoida, miten BGP-protokollan (RFC 4271) silmukoiden ohjaus toimii.

BGP-protokollan spesifikaatio tarjoaa useita mekanismeja silmukkaohjaukseen ja estoon. IBGP-skenaariossa (eli BGP-istunnoissa samassa suhteessa kuin) esimerkiksi split-horizon-sääntö on yksi silmukkaohjaus-ja ehkäisymekanismeista, joka estää IBGP-naapurin (A) iBGP-naapurille (B) ilmoittamien etuliitteiden ilmoittamisen uudelleen (b) kolmannelle iBGP-naapurille (C). On olemassa useita mahdollisia ratkaisuja “rentoutua” tämän säännön (käyttämällä reitti-Heijastimet on yksi niistä esimerkiksi), mutta niitä ei käsitellä tässä artikkelissa.

jo eBGP-skenaarioissa (eli BGP-istunnoissa eri Ässien välillä) yksinkertaisin silmukkaohjaus-ja ehkäisymekanismi on as_path-attribuutin analyysi. Jos eBGP peer (a) löytää oman ASN: n eBGP peer(B): n mainostaman etuliitteen(et) as_path-attribuutissa (ja päinvastoin), reititin hylkää etuliitteen mahdollisen reitityssilmukan välttämiseksi. ALLOWAS-in ja as-OVERRIDE ovat kaksi samanlaista ratkaisua, joita voidaan käyttää tässä tapauksessa, ja siitä lähtien kerromme yksityiskohtaisesti, millaisissa tilanteissa voimme käyttää jompaakumpaa.

ALLOWAS-in

tarkastellaan kuviossa 1 olevaa skenaariota, jossa AS 20 (tarjoaja) on kuin 10 (alkupään) kauttakulkuasiakas. Tällaisia topologioita voi esiintyä jonkin verran, esimerkiksi Internet-palveluntarjoajilla, joilla ei ole fyysistä yhteyttä IP-Pop-ohjelmiensa välillä ja joiden on ostettava IP-transitio tuotantoketjun alkupäästä tarjotakseen internet-yhteyden Tilaajilleen kullakin PoP/paikkakunnalla.

Kuva 1: asiakas (AS 20) kytketty ISP / UPSTREAM (as 10) kahdessa Pop-järjestelmässä erillisissä paikoissa.

tässä skenaariossa R2 ilmoittaa etuliitteen 10.0.0.0/24 ylävirran reitittimessä, ja kyseisen etuliitteen as_path näkyy seuraavasti:

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

BGP-protokollan “normaalin” toiminnan jälkeen (eli suodattimien, reitityskäytäntöjen jne.huomiotta jättäminen.).), etuliitteen as_path-attribuutti muutetaan R1: ksi ennen kuin sitä mainostetaan uudelleen vertaistensa suuntaan. Etuliitteen “Uusi” as-PATH luettelo näyttää jotain:

AS_PATH: 10 20 i

kuitenkin, kun etuliitettä 10.0.0.0 / 24 kantava BGP-päivityssanoma saavuttaa R3: n, R3 hylkää tämän päivityksen, koska se huomaa oman ASN: nsä (tässä tapauksessa 20) esiintyvän kyseisen etuliitteen as_path-attribuutissa. Samanlainen hälytys on nähtävissä R3-reitittimen lokissa (Cisco IOS-alusta, debug-tila):

tässä on ALLOWAS-inin tehtävä tämän rajoituksen lieventämiseksi. ALLOWAS-IN on määritetty palveluntarjoajan reitittimeen, tässä tapauksessa R3. Seurauksena on, että yksinkertaisesti BGP hyväksyy oman mahdollisen läsnäolonsa, kuten ylävirtaan tulleiden etuliitteiden as_pathissa.

useimmilla alustoilla (Cisco, Juniper jne.) ALLOWAS-in vaatii parametrin, joka on oman ASN: n sietämien esiintymien enimmäismäärä vastaanotettuihin etuliitteisiin liittyvässä as_path-attribuutissa. Esimerkiksi Cisco IOS: ssä, jos haluamme sallia jopa 2 kertaa oman ASN: n esiintymisen, peer eBGP: n kautta vastaanotetuissa reittipäivityksissä 1.1.1.1 (R1_Upstream) kokoonpano on seuraava:

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

yllä olevassa esimerkissä suoritamme konfiguraation niin, että voimme oppia etuliitteitä, jotka sisältävät korkeintaan 2 oman ASN: n esiintymää as-PATH-kentässä, kun se lähtee naapurista 1.1.1.1, mikä vastaisi aiemmin paljastetun kaavion skenaariota. On tärkeää huomata, että ALLOWAS-IN on määritettävä kaikkiin asiakkaan reitittimiin, joihin halutaan höllentää BGP-silmukkaohjaussääntöä!

katsotaanpa täydellisempää esimerkkiä (ja debug-tila käytössä Ciscon IOS-alustalla). Päätelaitteessa on mahdollista nähdä melko selvästi BGP-PÄIVITYSVIESTI, joka sisältää tietorakenteen, joka sisältää tietoa etuliitteestä ja aliverkon maskista (Network Layer Reachability Information – NLRI). Seuraavassa voidaan todeta, että reititin havaitsi as 20: n läsnäolon etuliitteen 10.0.0.0/24 as_path-attribuutissa, jonka r1_upstream (naapuri 1.1.1.1) ilmoitti, mutta asensi etuliitteen huolintataulukkoon (FIB) johtuen “allowas-in” – konfiguraation naapurin 1.1.1.1 asettaman rajoituksen lieventämisestä.:

AS-OVERRIDE

kuten jo mainittiin, as-OVERRIDE-toiminto on melko samanlainen kuin ALLOWAS-in halutussa tavoitteessa, joka on höllentää BGP-protokollan silmukkaohjausta. Suuri ero näiden kahden välillä on kuitenkin se, että se muuttaa etuliitteen as_path-attribuuttia korvaamalla silmukan “kausaalisen” ASN: n läsnäolon itse ylävirran ASN: llä. Tämän seurauksena AS-OVERRIDE on aina määritetty ylävirtaan (palveluntarjoajan) puolella, kun taas kaikki allowas-in-Asetukset suoritetaan asiakkaan puolella.

on myös syytä huomata, että as-overriden käyttö liittyy yleensä Layer 3 VPN (L3VPN) – skenaarioihin hallitussa MPLS-verkossa. Tällaisessa skenaariossa asiakkaalla on useita sivustoja ja se käyttää BGP: tä reititysprotokollana sen alkupään CE: n (Customer Edge) ja PE: n (provider Edge) välillä. Tässä tapauksessa as-OVERRIDE on käytössä PE-reitittimissä, ja vaikutus on CE ASN: n korvaaminen PE ASN: llä ennen kuin etuliite(t) ilmoitetaan uudelleen muille PE: ille MPLS-verkossa.

yllä olevassa kaaviossa CE / R3-reititin saisi etuliitteen 10.0.0.0 / 24 as-PATH-attribuutilla “20 10” ja sitten hylkään ilmoituksen, koska BGP silmukka ehkäisymekanismi jo keskusteltu aiemmin. Jos kuitenkin as-OVERRIDE-konfiguraatio suoritetaan PE1: ssä, CE/R3-reititin saa etuliitteen 10.0.0.0 / 24 as-path-attribuutilla “10 10”, ja etuliite asennetaan siten FIB: hen. On erittäin tärkeää huomauttaa, että AS-OVERRIDE on määritettävä kaikissa PE-reitittimissä, jotta varmistetaan asiakkaan etuliitteiden saavutettavuus l3vpn: ssä!

operatiivisesta näkökulmasta as-OVERRIDE-konfiguraatio on liian yksinkertainen useimmilla nykyisillä routers.As esimerkki, katsotaanpa kokoonpano Cisco IOS edellä skenaario:

as-OVERRIDE kokoonpano nollautuu BGP istunnon PE ja CE. Seuraavassa on mahdollista tarkistaa etuliitteet peräisin tai ilmoitti CE reitittimet tämän VPNv4 sisältää vain ASN PE (ylävirtaan) attribuutissa AS_PATH:

as-ohitus on harkittava ja suunniteltava välttää ongelmia tai epäjohdonmukaisuuksia Huolinta paketteja, loppujen olemme rentouttava Apumekanismi näiden ongelmien ehkäisemiseksi on BGP-laajennetun yhteisön “Site of Origin-SoO” käyttö IP-etuliitteiden tunnistamiseen, jotka kukin VPN-asiakas sivusto on peräisin ja ilmoittaa muille CE: n kautta L3VPN. Tässä artikkelissa emme kuitenkaan käsittele tätä aihetta ja se on lukijalle ylimääräinen tutkimusaihe.

tekijät: Daniel Damitoe Humberto Galiza

Vastaa

Sähköpostiosoitettasi ei julkaista.