forskelle mellem as-OVERRIDE og TILLADAS-in

introduktion

TILLADAS-in Og as-OVERRIDE er to lignende funktionaliteter, der kan anvendes i et scenario, hvor en som H (f.eks. udbyder) er forbundet til en anden som Y (f. eks. For bedre at forstå begge funktionaliteter er det hensigtsmæssigt at analysere, hvordan styringen af sløjfer i BGP-protokollen (RFC 4271) fungerer.

BGP-protokolspecifikationen indeholder flere mekanismer til sløjfekontrol og forebyggelse. I et iBGP-scenarie (dvs.BGP-sessioner inden for en samme som) er for eksempel split-horisont-reglen en af loop-kontrol-og forebyggelsesmekanismerne, der forhindrer præfikser, der er annonceret af en iBGP-nabo (A) til iBGP-naboen (B) fra at blive annonceret af (B) til en tredje iBGP-nabo (C). Der er flere mulige løsninger til rådighed for at” slappe af ” denne regel (ved hjælp af Rutereflektorer er en af dem for eksempel), men de vil ikke blive diskuteret i denne artikel.

allerede i eBGP-scenarier (dvs.BGP-sessioner mellem forskellige Esser) er den enkleste loop-kontrol-og forebyggelsesmekanisme analysen af as_path-attributten. I det væsentlige, hvis eBGP peer (a) finder sin egen ASN i as_path-attributten for præfikset(E), der er annonceret af eBGP peer(B) (og omvendt), kasserer routeren derefter præfikset for at undgå en mulig routingsløjfe. Tilladelses-og as-tilsidesættelse er to lignende løsninger, der kan anvendes i dette tilfælde, og fra det tidspunkt vil vi specificere i, hvilken slags situationer vi kan bruge den ene eller den anden.

tillad-i

overvej scenariet i Figur 1, hvor AS 20 (udbyder) er som 10 (opstrøms) transitklient. Topologier af denne art kan forekomme med en vis frekvens, for eksempel i internetudbydere, der ikke har nogen fysisk forbindelse mellem deres IP-Pop ‘ er og har brug for at købe IP-transit fra en opstrøms for at give internetadgang til deres abonnenter i hver PoP/lokalitet.

Figur 1: klient (som 20) forbundet til ISP / UPSTREAM (som 10) i to pop ‘ er på forskellige steder.

i dette scenario vil R2 annoncere præfikset 10.0.0.0/24 for opstrøms, og as_path for dette præfiks ses som følger på opstrøms router:

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

efter den “normale” drift af BGP-protokollen (dvs.ignorering af filtre, rutepolitikker osv.).), as_path attribut af præfikset vil blive ændret til R1, før det er re-annonceret mod sine jævnaldrende. Præfiksets ” nye ” as-PATH-liste vil se noget ud:

AS_PATH: 10 20 i

når BGP-opdateringsmeddelelsen, der bærer præfikset 10.0.0.0 / 24, Når R3, vil R3 kassere denne opdatering i betragtning af at den vil bemærke tilstedeværelsen af sin egen ASN (20 i dette tilfælde) i as_path-attributten for dette præfiks. En advarsel svarende til denne kan ses i R3 router log (Cisco IOS platform, debug mode):

det er her, hvor tilladelsen kommer i spil for at slappe af denne begrænsning. Tilladelsen er konfigureret på udbyderens router, i dette tilfælde R3. Effekten er, at simpelthen BGP vil acceptere den mulige tilstedeværelse af sin egen som i as_path af præfikser modtaget fra opstrøms.

på de fleste platforme (Cisco, Juniper, etc.) TILLADELSESINDGANG kræver en parameter, som er det maksimale antal forekomster, der tolereres af sin egen ASN i as_path-attributten, der er knyttet til de modtagne præfikser. For eksempel i Cisco IOS, hvis vi vil tillade forekomsten af op til 2 gange sin egen ASN, i ruteopdateringer modtaget via peer eBGP 1.1.1.1 (R1_Upstream) er konfigurationen som følger:

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

i ovenstående eksempel udfører vi konfigurationen, så vi kan lære præfikser, der højst indeholder 2 forekomster af sin egen ASN i as-PATH-feltet, når det afviger fra nabo 1.1.1.1, hvilket ville opfylde scenariet for diagrammet, der blev eksponeret tidligere. Det er vigtigt at bemærke, at tilladelsen skal konfigureres på alle klientroutere, som man ønsker at slappe af BGP loop control-reglen!

lad os se på et mere komplet eksempel (og med debug-tilstand aktiveret på Cisco IOS-platformen). I terminalen er det muligt at se ganske tydeligt BGP – opdateringsmeddelelsen, der indeholder datastrukturen, der bærer information om præfiks og undernetmaske (information om Netværkslagets rækkevidde-NLRI). I det følgende kan det bemærkes, at routeren registrerede tilstedeværelsen af AS 20 i as_path-attributten til præfikset 10.0.0.0 / 24, Der blev annonceret af r1_upstream (nabo 1.1.1.1), men installerede præfikset i videresendelsestabellen (FIB) på grund af lempelsen af den begrænsning, der blev pålagt af” tilladas-in ” – konfigurationen for nabo 1.1.1.1:

AS-OVERRIDE

som allerede nævnt er as-OVERRIDE-funktionaliteten meget lig TILLADAS-in med hensyn til det ønskede mål, som er at slappe af BGP protocol loop control. Den store forskel mellem de to er imidlertid, at den ændrer as_path-attributten for præfikset ved at erstatte tilstedeværelsen af den “forårsagende” ASN af sløjfen med ASN af selve opstrøms. Som et resultat konfigureres AS-OVERRIDE altid på opstrøms (tjenesteudbyder) side, mens Al tilladelseskonfiguration udføres på klientsiden.

det er også værd at bemærke, at brugen af as-OVERRIDE generelt er forbundet med Layer 3 VPN (L3VPN) scenarier på et administreret MPLS-netværk. I denne type scenarie har kunden flere steder og bruger BGP som en routingprotokol mellem dets opstrøms CE (Customer Edge) og PE (provider Edge). I dette tilfælde anvendes as-OVERRIDE på PE-routere, og effekten vil være udskiftning af CE ASN med PE ASN, før præfikset / præfikserne genannonceres til de andre PE ‘ er i MPLS-netværket.

i diagrammet ovenfor ville CE / R3-routeren modtage præfikset 10.0.0.0 / 24 Med as-PATH-attributten “20 10” og så ville jeg afvise meddelelsen på grund af BGP-sløjfeforebyggelsesmekanismen, der allerede er diskuteret tidligere. Men hvis as-OVERRIDE-konfigurationen udføres på PE1, modtager CE / R3-routeren præfikset 10.0.0.0 / 24 med AS-path-attributten “10 10”, og præfikset vil derfor blive installeret på FIB. Det er ekstremt vigtigt at påpege, at AS-OVERRIDE skal konfigureres på alle PE-routere for at sikre opnåelsen af klientpræfikser inden for L3VPN!

fra et operationelt synspunkt er as-OVERRIDE-konfigurationen for enkel på mest aktuelle routers.As et eksempel, lad os se på konfigurationen på Cisco IOS til ovenstående scenario:

as-OVERRIDE-konfigurationen nulstilles i BGP-sessionen mellem PE og CE. I det følgende vil det være muligt at kontrollere de præfikser, der stammer fra eller annonceres af CE-routerne i denne VPNv4, indeholder kun ASN for PE (opstrøms) i attributten AS_PATH:

brugen af as-OVERRIDE skal være gennemtænkt og planlagt for at undgå problemer eller uoverensstemmelser i videresendelsen af pakker, når alt kommer til alt slapper vi af En hjælpemekanisme til forebyggelse af disse problemer er brugen af det BGP – udvidede samfund “oprindelsessted-SoO” til at identificere de IP-præfikser, som hvert VPN-klientsted stammer fra og annoncerer til andre CE ‘ er gennem L3VPN. Men i denne artikel vil vi ikke diskutere dette emne, og det er et yderligere forskningsemne for læseren.

forfattere: Daniel Damitoe Humberto

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.