skillnader mellan as-OVERRIDE och ALLOWAS-in

introduktion

ALLOWAS-IN och as-OVERRIDE är två liknande funktioner som kan användas i ett scenario där en som X (t.ex. provider) är ansluten till en annan som Y (t. ex. transitoperatör / ryggrad MPLS) genom flera platser/PoPs,. För att bättre förstå båda funktionerna är det lämpligt att analysera hur kontrollen av slingor i BGP-protokollet (RFC 4271) fungerar.

BGP-protokollspecifikationen tillhandahåller flera mekanismer för loopkontroll och förebyggande. I ett iBGP-scenario (dvs. BGP-sessioner inom samma som) till exempel är split-horizon-regeln en av loop-kontroll-och förebyggande mekanismer som förhindrar prefix som tillkännages av en iBGP-granne (A) till iBGP-grannen (B) från att omannonseras av (B) till en tredje iBGP-granne (C). Det finns flera möjliga lösningar tillgängliga för att” slappna av ” denna regel (med hjälp av Ruttreflektorer är en av dem till exempel), men de kommer inte att diskuteras i den här artikeln.

redan i EBGP-scenarier (dvs. BGP-sessioner mellan olika ESS) är den enklaste loopkontroll-och förebyggande mekanismen analysen av as_path-attributet. I huvudsak, om EBGP peer (a) hittar sin egen ASN i as_path-attributet för prefixet / prefixen som annonseras av eBGP peer(B) (och vice versa), kasserar routern sedan prefixet för att undvika en möjlig routningsslinga. ALLOWAS-IN och as-OVERRIDE är två liknande lösningar som kan användas i det här fallet, och från den punkten kommer vi att beskriva i vilken typ av situationer vi kan använda den ena eller den andra.

ALLOWAS-in

tänk på scenariot i Figur 1 där AS 20 (provider) är som 10 (uppströms) transitklient. Topologier av detta slag kan förekomma med viss frekvens, till exempel i Internetleverantörer som inte har någon fysisk koppling mellan sina IP-Pop och behöver köpa IP-transitering från en uppströms för att ge Internetåtkomst till sina abonnenter i varje PoP/ort.

Figur 1: klient (AS 20) ansluten till ISP / uppströms (as 10) i två pop på olika platser.

i detta scenario kommer R2 att tillkännage prefixet 10.0.0.0 / 24 för uppströms, och as_path för det prefixet kommer att ses som följer på uppströmsroutern:

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 “normala” driften av BGP-protokollet (dvs. ignorera filter, routingpolicyer etc.).), kommer as_path-attributet för prefixet att ändras till R1 innan det annonseras om mot sina kamrater. Prefixets ” nya ” as-PATH-lista kommer att se ut som:

AS_PATH: 10 20 i

men när BGP-uppdateringsmeddelandet som bär prefixet 10.0.0.0 / 24 når R3, kommer R3 att kassera den här uppdateringen eftersom den kommer att märka närvaron av sin egen ASN (20 i det här fallet) i as_path-attributet för det prefixet. En varning som liknar detta kan ses i R3-routerloggen (Cisco IOS-plattformen, felsökningsläge):

det är här ALLOWAS-IN spelar in för att slappna av denna begränsning. ALLOWAS-IN är konfigurerad på leverantörens router, i detta fall R3. Effekten är att helt enkelt BGP kommer att acceptera den möjliga närvaron av sin egen som i as_path av prefix mottagna från uppströms.

på de flesta plattformar (Cisco,Juniper, etc.) ALLOWAS-In kräver en parameter, vilket är det maximala antalet förekomster som tolereras av sin egen ASN i as_path-attributet associerat med de mottagna prefixen. Till exempel, i Cisco IOS, om vi vill tillåta förekomsten av upp till 2 gånger sin egen ASN, i ruttuppdateringar mottagna via peer eBGP 1.1.1.1 (R1_Upstream) konfigurationen är som följer:

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

i ovanstående exempel utför vi konfigurationen så att vi kan lära oss prefix som innehåller högst 2 förekomster av sin egen ASN i As-PATH-fältet när det avgår från granne 1.1.1.1, vilket skulle uppfylla scenariot för diagrammet som exponerats tidigare. Det är viktigt att notera att ALLOWAS-IN måste konfigureras på alla klientroutrar där man vill koppla av BGP loop control rule!

låt oss titta på ett mer komplett exempel (och med felsökningsläge aktiverat på Cisco IOS-plattformen). I terminalen är det möjligt att tydligt se BGP – uppdateringsmeddelandet som innehåller datastrukturen som innehåller information om prefixet och subnätmasken (Network Layer Reachability Information-NLRI). I det följande kan det noteras att routern upptäckte närvaron av AS 20 i as_path-attributet för prefixet 10.0.0.0/24 som tillkännagavs av r1_upstream( neighbor 1.1.1.1), men installerade prefixet i vidarebefordringstabellen (FIB) på grund av avslappningen av begränsningen som införts av” allowas-in ” – konfigurationen för neighbor 1.1.1.1:

AS-OVERRIDE

som redan nämnts är AS-OVERRIDE-funktionaliteten ganska lik ALLOWAS-in när det gäller det önskade målet som är att slappna av BGP-protokollets loopkontroll. Den stora skillnaden mellan de två är emellertid att den modifierar as_path-attributet för prefixet genom att ersätta närvaron av slingans “orsakande” ASN med ASN för uppströms själv. Som ett resultat är AS-OVERRIDE alltid konfigurerad på uppströms (tjänsteleverantör) sida medan alla allowas-in konfiguration utförs på klientsidan.

det är också värt att notera att användningen av as-OVERRIDE i allmänhet är associerad med Layer 3 VPN (L3VPN) scenarier på ett hanterat MPLS-nätverk. I denna typ av scenario har kunden flera webbplatser och använder BGP som ett routingprotokoll mellan dess uppströms CE (Customer Edge) och PE (provider Edge). I detta fall tillämpas as-OVERRIDE på PE-Routrar, och effekten kommer att ersätta CE ASN med PE ASN innan prefixet(erna) återannonseras till de andra PE: erna i MPLS-nätverket.

i diagrammet ovanför skulle ce / R3-routern få prefixet 10.0.0.0 / 24 Med as-PATH-attributet “20 10” och då skulle jag avfärda meddelandet på grund av BGP-slingförebyggande mekanism som redan diskuterats tidigare. Men om AS-OVERRIDE-konfigurationen utförs på PE1, kommer ce / R3-routern att få prefixet 10.0.0.0 / 24 Med as-path-attributet “10 10”, och prefixet kommer därför att installeras på FIB. Det är oerhört viktigt att påpeka att AS-OVERRIDE måste konfigureras på alla PE-routrar för att säkerställa att klientprefix inom L3VPN kan nås!

ur operativ synvinkel är AS-OVERRIDE-konfigurationen för enkel på de flesta aktuella routers.As ett exempel, låt oss titta på konfigurationen på Cisco IOS för ovanstående scenario:

as-OVERRIDE-konfigurationen återställs i BGP-sessionen mellan PE och CE. I det följande kommer det att vara möjligt att kontrollera prefixen som har sitt ursprung eller meddelats av CE-routrarna för denna VPNv4 innehåller endast ASN för PE (uppströms) i attributet AS_PATH:

användningen av as-OVERRIDE måste vara väl genomtänkt och planerad för att undvika problem eller inkonsekvenser vid vidarebefordran av paket, trots allt slappnar vi av En hjälpmekanism för att förhindra dessa problem är användningen av BGP extended community “site of Origin – SoO” för att identifiera IP-prefix som varje VPN-klientwebbplats har sitt ursprung och meddelar till andra CE: er via L3VPN. Men i den här artikeln kommer vi inte att diskutera detta ämne och det är ett ytterligare forskningsämne för läsaren.

författare: Daniel Damitoe Humberto Galiza

Lämna ett svar

Din e-postadress kommer inte publiceras.