forskjeller mellom as-OVERRIDE og ALLOWAS-IN

introduksjon

ALLOWAS – IN og as-OVERRIDE er to lignende funksjoner som kan brukes i et scenario der en as X (f. eks. For bedre å forstå begge funksjonene er det hensiktsmessig å analysere hvordan kontrollen av løkker i BGP-protokollen (RFC 4271) fungerer.

bgp-protokollspesifikasjonen gir flere mekanismer for sløyfekontroll og Forebygging. I et iBGP-scenario (dvs. bgp-økter innenfor en same AS) er for eksempel split-horizon-regelen en av loop-kontroll-og forebyggingsmekanismer som forhindrer prefikser annonsert av en iBGP-nabo (A) til iBGP-naboen (B) fra å bli re-annonsert av (B) til en tredje iBGP-nabo (C). Det finnes flere mulige løsninger for å “slappe av” denne regelen (Ved Hjelp Av Rutereflektorer er en av dem for eksempel), men de vil ikke bli diskutert i denne artikkelen. BGP-økter mellom Forskjellige Ess) er den enkleste sløyfekontroll-og forebyggingsmekanismen analysen av as_path-attributtet. I hovedsak, hvis eBGP-peer (A) finner sin EGEN ASN i as_path-attributtet til prefikset(e) annonsert av eBGP-peer(B) (Og omvendt), forkaster ruteren prefikset for å unngå en mulig rutingsløkke. ALLOWAS-IN og as-OVERRIDE er to lignende løsninger som kan brukes i dette tilfellet, og fra det punktet vil vi detaljere i hvilke situasjoner vi kan bruke den ene eller den andre.

ALLOWAS – IN

vurder scenariet I Figur 1 HVOR AS 20 (leverandør) er som 10 (oppstrøms) transittklient. Topologier av denne typen kan forekomme med en viss frekvens, for Eksempel Hos Internett-leverandører som ikke har noen fysisk forbindelse mellom DERES IP-PoPs og trenger å kjøpe IP transit fra En Oppstrøms for å gi internett-tilgang til sine abonnenter i hver PoP/lokalitet.

Figur 1: klient (SOM 20) koblet TIL ISP / OPPSTRØMS (som 10) i to PoPs på forskjellige steder.

I dette scenariet vil R2 kunngjøre prefikset 10.0.0.0 / 24 For Oppstrøms, og as_path av dette prefikset vil bli sett på som følger på oppstrøms ruteren:

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

etter “normal” drift AV bgp-protokollen (dvs.ignorerer filtre, rutingspolicyer, etc.).), vil as_path-attributtet til prefikset bli endret Til R1 før det blir re-annonsert mot sine jevnaldrende. Prefiksens ” nye ” AS-PATH-liste vil se ut som noe:

AS_PATH: 10 20 i

men NÅR BGP-oppdateringsmeldingen som bærer prefikset 10.0.0.0 / 24 når R3, vil R3 forkaste denne oppdateringen med tanke på at Den vil merke tilstedeværelsen av sin EGEN ASN (20 i dette tilfellet) i as_path-attributtet til det prefikset. Et varsel som ligner dette kan ses I r3-ruterloggen (Cisco IOS platform, debug mode):

DETTE ER HVOR ALLOWAS-IN kommer inn i spill for å slappe av denne begrensningen. ALLOWAS-IN er konfigurert på leverandørens ruter, i dette tilfellet R3. Effekten er at bare BGP vil akseptere den mulige tilstedeværelsen av sin EGEN SOM i as_path av prefikser mottatt fra Oppstrøms.

på de fleste plattformer (Cisco, Juniper, etc.) ALLOWAS-IN krever en parameter, som er det maksimale antall forekomster som tolereres av sin EGEN ASN i as_path-attributtet som er knyttet til de mottatte prefiksene. For Eksempel, I Cisco IOS, hvis vi vil tillate forekomst av opptil 2 ganger SIN EGEN ASN, i ruteoppdateringer mottatt via peer eBGP 1.1.1.1 (R1_Upstream), er konfigurasjonen som følger:

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

i eksemplet ovenfor utfører vi konfigurasjonen slik at vi kan lære prefikser som inneholder maksimalt 2 forekomster av sin EGEN ASN i as-PATH-feltet når den går fra nabo 1.1.1.1, som ville møte scenariet i diagrammet som ble utsatt tidligere. DET er viktig å merke seg AT ALLOWAS-IN må konfigureres på alle klientrutere som man ønsker å slappe AV BGP loop control rule!

la oss se på et mer komplett eksempel (og med feilsøkingsmodus aktivert På Cisco IOS-plattformen). I terminalen er det mulig å se GANSKE tydelig BGP-OPPDATERINGSMELDINGEN som inneholder datastrukturen som bærer informasjon om prefikset og nettverksmasken (Network Layer Reachability Information – NLRI). I det følgende kan det bemerkes at ruteren oppdaget TILSTEDEVÆRELSEN AV AS 20 i as_path-attributtet til prefikset 10.0.0.0 / 24 annonsert av r1_upstream( nabo 1.1.1.1), men installerte prefikset i videresendingstabellen (FIB) på grunn av avslapping av begrensningen pålagt av” allowas-in ” – konfigurasjonen for nabo 1.1.1.1:

AS-OVERRIDE

som allerede nevnt er as-OVERRIDE-funksjonaliteten ganske lik ALLOWAS-IN angående ønsket mål som er å slappe AV bgp-protokollsløyfekontrollen. Den store forskjellen mellom de to er imidlertid at den endrer as_path-attributtet til prefikset ved å erstatte tilstedeværelsen av” kausative ” asn av sløyfen MED ASN Av Oppstrøms selv. SOM et resultat er AS-OVERRIDE alltid konfigurert på oppstrøms (tjenesteleverandør) – siden mens all allowas-in-konfigurasjon utføres på klientsiden. det er også verdt å merke seg at bruk av as-OVERRIDE vanligvis er assosiert Med Layer 3 VPN (L3VPN) scenarier på et administrert mpls-nettverk. I denne typen scenario har kunden flere områder og bruker BGP som en rutingsprotokoll mellom oppstrøms CE (Customer Edge) og pe (provider Edge). I dette tilfellet brukes as-OVERSTYRING PÅ PE-rutere, og effekten vil være erstatning AV CE ASN av PE ASN før prefikset (e) blir kunngjort til de ANDRE PE-ene i MPLS-nettverket.

I diagrammet ovenfor VIL CE / r3-ruteren motta prefikset 10.0.0.0 / 24 med as-PATH-attributtet “20 10” og da ville jeg avvise kunngjøringen på grunn av bgp loop prevention mechanism allerede diskutert tidligere. Men hvis as-OVERSTYRINGSKONFIGURASJONEN utføres PÅ PE1, VIL CE/R3-ruteren motta prefikset 10.0.0.0 / 24 med as-path-attributtet “10 10”, og prefikset vil derfor bli installert på FIB. DET er ekstremt viktig å påpeke AT AS-OVERRIDE må konfigureres på ALLE PE-rutere for å sikre at klientprefikser i L3VPN kan nås!

fra et operativt synspunkt er as-OVERSTYRINGSKONFIGURASJONEN for enkel på de fleste nåværende routers.As et eksempel, la oss se på konfigurasjonen På Cisco IOS for scenariet ovenfor:

as-OVERRIDE-konfigurasjonen tilbakestilles i bgp-økten MELLOM PE OG CE. I det følgende vil det være mulig å sjekke prefiksene som er oppstått eller annonsert AV CE-ruterne til Denne VPNv4 inneholder bare ASN AV PE (Oppstrøms) i attributtet AS_PATH:

bruken av as-OVERSTYRING må være godt gjennomtenkt og planlagt for å unngå problemer eller inkonsekvenser i videresending av pakker. En hjelpemekanisme for å forhindre disse problemene er bruken AV Bgp extended community “Site Of Origin-SoO” for å identifisere IP-prefikser som HVERT VPN-klientsted stammer fra og kunngjør til andre CE-er gjennom L3VPN. Men i denne artikkelen vil vi ikke diskutere dette emnet, og det er et ekstra forskningsemne for leseren.

forfattere: Daniel Damitoe Humberto Galiza

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.