différences entre as-OVERRIDE et ALLOWAS-IN

introduction

ALLOWAS-IN et as-OVERRIDE sont deux fonctionnalités similaires qui peuvent être utilisées dans un scénario où un as X (par exemple fournisseur) est connecté à un autre as Y (par exemple opérateur de transit / MPLS de backbone) via plusieurs sites / POP,. Pour mieux comprendre les deux fonctionnalités, il convient d’analyser le fonctionnement du contrôle des boucles dans le protocole BGP (RFC 4271).

la spécification du protocole BGP fournit plusieurs mécanismes de contrôle et de prévention des boucles. Dans un scénario iBGP (c’est-à-dire des sessions BGP dans un même AS) par exemple, la règle d’horizon divisé est l’un des mécanismes de contrôle et de prévention de boucle qui empêche les préfixes annoncés par un voisin iBGP (A) au voisin iBGP (B) d’être ré-annoncés par (B) à un troisième voisin iBGP (C). Il existe plusieurs solutions possibles pour “assouplir” cette règle (l’utilisation de réflecteurs de route en fait partie par exemple), mais elles ne seront pas abordées dans cet article.

déjà dans les scénarios eBGP (c’est-à-dire les sessions BGP entre différents Aces), le mécanisme de contrôle et de prévention de boucle le plus simple est l’analyse de l’attribut as_path. Essentiellement, si le pair eBGP(A) trouve son propre ASN dans l’attribut as_path du ou des préfixes annoncés par le pair eBGP(B) (et vice versa), le routeur rejette alors le préfixe afin d’éviter une boucle de routage possible. ALLOWAS-IN et as-OVERRIDE sont deux solutions similaires qui peuvent être utilisées dans ce cas, et à partir de ce moment, nous détaillerons dans quel genre de situations nous pouvons utiliser l’une ou l’autre.

ALLOWAS-IN

considérons le scénario de la figure 1 où AS 20 (fournisseur) est as 10 (en amont) client de transit. Des topologies de cette nature peuvent se produire avec une certaine fréquence, par exemple chez les fournisseurs d’accès Internet qui n’ont aucune connexion physique entre leurs POP IP et qui doivent acheter un transit IP auprès d’un amont pour fournir un accès Internet à leurs abonnés dans chaque POP/ localité.

Figure 1 : client (AS 20) connecté au FAI/EN AMONT (as 10) dans deux POP à des emplacements distincts.

dans ce scénario, R2 annoncera le préfixe 10.0.0.0/24 pour l’amont, et le chemin as_path de ce préfixe sera vu comme suit sur le routeur amont :

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

suivant le fonctionnement “normal” du protocole BGP (c’est-à-dire ignorant les filtres, les stratégies de routage, etc.).), l’attribut as_path du préfixe sera modifié en R1 avant d’être annoncé à nouveau vers ses pairs. La “nouvelle” liste de CHEMIN d’accès du préfixe ressemblera à quelque chose comme:

AS_PATH: 10 20 i

cependant, lorsque le message de mise à jour BGP qui porte le préfixe 10.0.0.0/24 atteint R3, R3 rejettera cette mise à jour en vue de remarquer la présence de son propre ASN (20 dans ce cas) dans l’attribut as_path de ce préfixe. Une alerte semblable à ceci peut être vue dans le journal du routeur R3 (plate-forme Cisco IOS, mode de débogage) :

c’est là que l’autorisation entre en jeu pour détendre cette restriction. ALLOWAS-IN est configuré sur le routeur du fournisseur, dans ce cas R3. L’effet est que simplement BGP acceptera la présence possible de la sienne COMME dans le chemin as_path des préfixes reçus en amont.

sur la plupart des plateformes (Cisco, Juniper, etc.) ALLOWAS-IN nécessite un paramètre, qui est le nombre maximal d’occurrences tolérées de son propre ASN dans l’attribut as_path associé aux préfixes reçus. Par exemple, dans Cisco IOS, si nous voulons permettre l’occurrence de jusqu’à 2 fois son propre ASN, dans les mises à jour de route reçues via le pair eBGP 1.1.1.1 (R1_Upstream), la configuration est la suivante:

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

dans l’exemple ci-dessus, nous effectuons la configuration de sorte que nous puissions apprendre des préfixes contenant au plus 2 occurrences de son propre ASN dans le champ as-PATH lorsqu’il s’écarte du voisin 1.1.1.1, ce qui répondrait au scénario du diagramme exposé précédemment. Il est important de noter que ALLOWAS-IN doit être configuré sur tous les routeurs clients sur lesquels on souhaite assouplir la règle de contrôle de boucle BGP !

regardons un exemple plus complet (et avec le mode de débogage activé sur la plate-forme Cisco IOS). Dans le terminal, il est possible de voir très clairement le message de MISE À JOUR BGP contenant la structure de données qui contient des informations sur le préfixe et le masque de sous-réseau (Informations d’accessibilité de la couche réseau – NLRI). Dans ce qui suit, on peut noter que le routeur a détecté la présence d’AS 20 dans l’attribut as_path du préfixe 10.0.0.0 / 24 annoncé par r1_upstream (voisin 1.1.1.1), mais a installé le préfixe dans la table de transfert (FIB) en raison de l’assouplissement de la restriction imposée par la configuration “allowas-in” pour le voisin 1.1.1.1:

AS-OVERRIDE

comme déjà mentionné, la fonctionnalité as-OVERRIDE est assez similaire à ALLOWAS-IN en ce qui concerne l’objectif souhaité qui est de détendre le contrôle de boucle de protocole BGP. Cependant, la grande différence entre les deux est qu’il modifie l’attribut as_path du préfixe en remplaçant la présence de l’ASN “causal” de la boucle par l’ASN de l’Amont lui-même. Par conséquent, AS-OVERRIDE est toujours configuré du côté amont (fournisseur de services) tandis que toute la configuration allowas-in est effectuée du côté client.

il convient également de noter que l’utilisation d’as-OVERRIDE est généralement associée à des scénarios VPN de couche 3 (L3VPN) sur un réseau MPLS géré. Dans ce type de scénario, le client dispose de plusieurs sites et utilise BGP comme protocole de routage entre son CE amont (Bord Client) et son PE (Bord fournisseur). Dans ce cas, l’as-OVERRIDE est appliqué sur les routeurs PE, et l’effet sera le remplacement de l’ASN CE par l’ASN PE avant que le ou les préfixes ne soient à nouveau annoncés aux autres PE du réseau MPLS.

dans le diagramme ci-dessus, le routeur CE/R3 recevrait le préfixe 10.0.0.0/24 avec l’attribut as-PATH “20 10” et puis je rejetterais l’annonce en raison du mécanisme de prévention des boucles BGP déjà discuté plus tôt. Cependant, si la configuration as-OVERRIDE est effectuée sur PE1, le routeur CE/R3 recevra le préfixe 10.0.0.0/24 avec l’attribut as-path “10 10”, et le préfixe sera donc installé sur le FIB. Il est extrêmement important de souligner que l’AS-OVERRIDE doit être configuré sur tous les routeurs PE pour assurer l’accessibilité des préfixes clients dans L3VPN !

d’un point de vue opérationnel, la configuration as-OVERRIDE est trop simple sur la plupart des routers.As un exemple, regardons la configuration sur Cisco IOS pour le scénario ci-dessus :

la configuration d’as-OVERRIDE réinitialisera dans la session BGP entre PE et CE. Dans ce qui suit, il sera possible de vérifier les préfixes créés ou annoncés par les routeurs CE de ce VPNv4 ne contient que l’ASN du PE (En amont) dans l’attribut AS_PATH:

l’utilisation de as-OVERRIDE doit être bien pensée et planifiée pour éviter des problèmes ou des incohérences dans l’acheminement des paquets, après tout nous nous relaxons Un mécanisme auxiliaire pour prévenir ces problèmes est l’utilisation du “Site d’origine – SoO” de la communauté étendue BGP pour identifier les préfixes IP que chaque site client VPN génère et annonce aux autres CE via L3VPN. Cependant, dans cet article, nous ne discuterons pas de ce sujet et c’est un sujet de recherche supplémentaire pour le lecteur.

auteurs: Daniel Damitoe Humberto Galiza

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.