verschillen tussen as-OVERRIDE en ALLOWAS-in

introductie

ALLOWAS-in en as-OVERRIDE zijn twee soortgelijke functionaliteiten die kunnen worden gebruikt in een scenario waarin een als X (bijvoorbeeld provider) is verbonden met een ander als Y (bijvoorbeeld transit operator / backbone MPLS) via meerdere sites/Pop ‘ s. Om beide functionaliteiten beter te begrijpen is het aangewezen om te analyseren hoe de besturing van lussen in het BGP-protocol (RFC 4271) werkt.

de BGP-protocolspecificatie biedt verschillende mechanismen voor loopcontrole en-preventie. In een iBGP-scenario (BGP-sessies binnen dezelfde AS) bijvoorbeeld, is de split-horizon-regel een van de loopbesturings – en preventiemechanismen die voorkomen dat voorvoegsels die door een IBGP-Buurman (A) aan de iBGP-buurman (B) zijn aangekondigd, opnieuw worden aangekondigd door (B) aan een derde iBGP-buurman (C). Er zijn verschillende mogelijke oplossingen beschikbaar om deze regel te” ontspannen ” (het gebruik van Route-Reflectoren is een van hen bijvoorbeeld), maar ze zullen niet worden besproken in dit artikel.

al in eBGP-scenario ‘ s (BGP-sessies tussen verschillende azen) is het eenvoudigste lusbesturings-en preventiemechanisme de analyse van het attribuut as_path. In wezen, als de eBGP peer (A) zijn eigen ASN vindt in het as_path attribuut van de prefix(s) geadverteerd door de eBGP peer(B) (en vice versa), de router dan verwijdert het prefix om een mogelijke routing lus te voorkomen. ALLOWAS-IN en as-OVERRIDE zijn twee soortgelijke oplossingen die in dit geval kunnen worden gebruikt, en vanaf dat punt zullen we in detail in wat voor soort situaties we kunnen gebruiken van de ene of de andere.

ALLOWAS-in

beschouw het scenario in Figuur 1 waarin AS 20 (provider) is als 10 (upstream) transit client. Topologieën van deze aard kunnen met enige frequentie optreden, bijvoorbeeld bij internetproviders die geen fysieke verbinding hebben tussen hun IP-Pop ‘ s en IP-transit van een Upstream moeten kopen om hun abonnees in elke PoP/locatie internettoegang te bieden.

figuur 1: client (als 20) verbonden met ISP / UPSTREAM (als 10) in twee Pop ‘ s op verschillende locaties.

in dit scenario zal R2 het prefix 10.0.0.0/24 voor Upstream aankondigen, en de as_path van dat prefix zal als volgt worden gezien op de upstream 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

na de “normale” werking van het BGP-protocol (dat wil zeggen het negeren van filters, routeringsbeleid, enz.).), zal het as_path attribuut van het voorvoegsel worden gewijzigd naar R1 voordat het opnieuw wordt geadverteerd naar zijn peers. De” nieuwe ” AS-pad lijst van het voorvoegsel zal er ongeveer uitzien als:

AS_PATH: 10 20 i

echter, wanneer het BGP-update-bericht dat het prefix 10.0.0.0 / 24 draagt R3 bereikt, zal R3 deze update verwerpen met het oog op de aanwezigheid van zijn eigen ASN (20 in dit geval) in het as_path-attribuut van dat prefix. Een waarschuwing vergelijkbaar met deze kan worden gezien in het R3 router log (Cisco IOS platform, debug mode):

Dit is waar ALLOWAS-IN in het spel komt om deze beperking te ontspannen. ALLOWAS-IN wordt geconfigureerd op de router van de provider, in dit geval R3. Het effect is dat gewoon BGP de mogelijke aanwezigheid van zijn eigen zal accepteren zoals in de as_path van voorvoegsels ontvangen van stroomopwaarts.

op de meeste platforms (Cisco, Juniper, etc.) ALLOWAS-IN vereist een parameter, dat is het maximum aantal gebeurtenissen getolereerd van zijn eigen ASN in de as_path attribuut geassocieerd met de ontvangen voorvoegsels. Bijvoorbeeld, in Cisco IOS, als we willen toestaan dat het optreden van maximaal 2 keer zijn eigen ASN, in route updates ontvangen via peer eBGP 1.1.1.1 (R1_Upstream) de configuratie is als volgt:

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

in het bovenstaande voorbeeld voeren we de configuratie uit zodat we prefixen kunnen leren die ten hoogste 2 exemplaren van zijn eigen ASN bevatten in het as-PATH veld wanneer het afwijkt van buurman 1.1.1.1, wat zou voldoen aan het scenario van het diagram dat eerder werd getoond. Het is belangrijk op te merken dat ALLOWAS-IN moet worden geconfigureerd op alle client routers waarop men de BGP loop control regel wil ontspannen!

laten we eens kijken naar een completer voorbeeld (en met debug Mode ingeschakeld op het Cisco IOS platform). In de terminal is het mogelijk om heel duidelijk het BGP UPDATE bericht te zien met daarin de gegevensstructuur die informatie bevat over het voorvoegsel en het subnetmasker (Network Layer Reachability Information – NLRI). In het volgende kan worden opgemerkt dat de router de aanwezigheid van AS 20 in de as_path attribuut van het prefix 10.0.0.0/24 aangekondigd door r1_upstream (buurman 1.1.1.1), maar installeerde het prefix in de forwarding table (FIB) als gevolg van de versoepeling van de beperking opgelegd door de” allowas-in ” configuratie voor buurman 1.1.1.1:

AS-OVERRIDE

zoals reeds vermeld, is de as-OVERRIDE functionaliteit vergelijkbaar met ALLOWAS-IN wat betreft het gewenste doel, namelijk het ontspannen van de lusbesturing van het BGP-protocol. Het grote verschil tussen de twee is echter dat het het as_path attribuut van het voorvoegsel wijzigt door de aanwezigheid van de “causatieve” ASN van de lus te vervangen door de ASN van de stroomopwaartse zelf. Als gevolg hiervan wordt AS-OVERRIDE altijd geconfigureerd aan de upstream-zijde (serviceprovider), terwijl alle allowas-in-configuratie wordt uitgevoerd aan de clientzijde.

Het is ook vermeldenswaard dat het gebruik van as-OVERRIDE over het algemeen geassocieerd wordt met L3vpn-scenario ‘ s (Layer 3 VPN) op een beheerd MPLS-netwerk. In dit soort scenario ‘ s heeft de klant meerdere locaties en gebruikt hij BGP als routeringsprotocol tussen zijn upstream CE (Customer Edge) en PE (provider Edge). In dit geval wordt as-OVERRIDE toegepast op PE routers, en het effect zal de vervanging van de CE ASN door de PE ASN zijn voordat de prefix(s) opnieuw worden aangekondigd aan de andere PE ‘ s in het MPLS netwerk.

in het diagram hierboven zou de ce / R3 router het voorvoegsel 10.0.0.0 / 24 ontvangen met het as-PATH attribuut “20 10” en dan zou ik de aankondiging als gevolg van het BGP loop preventie mechanisme al eerder besproken. Echter, als de as-OVERRIDE configuratie wordt uitgevoerd op PE1, zal de ce/R3 router het prefix 10.0.0.0 / 24 ontvangen met het as-path attribuut “10 10”, en het prefix zal daarom op de FIB worden geïnstalleerd. Het is uiterst belangrijk om erop te wijzen dat AS-OVERRIDE moet worden geconfigureerd op alle PE routers om de bereikbaarheid van client voorvoegsels binnen L3VPN te garanderen!

vanuit operationeel oogpunt is de configuratie van AS-OVERRIDE te eenvoudig op de meeste huidige routers.As een voorbeeld, laten we eens kijken naar de configuratie op Cisco IOS Voor het bovenstaande scenario:

de as-OVERRIDE configuratie zal resetten in de BGP sessie tussen PE en CE. In het volgende zal het mogelijk zijn om de voorvoegsels te controleren die zijn ontstaan of aangekondigd door de CE routers van deze VPNv4 bevat alleen de ASN van de PE (Upstream) in het attribuut AS_PATH:

het gebruik van as-OVERRIDE moet goed doordacht en gepland zijn om problemen of inconsistenties in het doorsturen van pakketten te voorkomen, tenslotte zijn we aan het ontspannen Een hulpmechanisme om deze problemen te voorkomen is het gebruik van de BGP extended community “Site of Origin – SoO” om de IP-voorvoegsels te identificeren die elke VPN-client-site afkomstig is en aankondigt aan andere CE ‘ s via L3VPN. In dit artikel zullen we dit onderwerp echter niet bespreken en het is een aanvullend onderzoeksonderwerp voor de lezer.

auteurs: Daniel Damitoe Humberto Galiza

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.