BGP: AS-Override, Allow-as-in et Site-of-Origin (SoO)
Introduction
Tous les cas présents dans cet article contiennent une Infra IP-MPLS simplifiée d’un Opérateur X avec eBGP implémenté entre les PEs et CEs d’un Client Spécifique.
Ce n’est toujours pas systématique d'utiliser directement et rapidement la notion d'AS Override, puisqu’il existe la fameuse règle générale de BGP « AS-Path split-horizon Rule » : Si un Site voit son propre AS dans l’AS-PATH reçu, il rejette la route !
On verra dans ce qui suit 3 cas différents :
- Le premier et deuxième exemple montrent l'utilité des commandes AS-Override et Allow-as-in lorsque deux sites distants d’un Client se trouvent dans le même AS.
- Le troisième cas montre l'utilité de la commande Site-of-Origin (SoO) lorsqu'une boucle iBGP-eBGP se forme au niveau des intercos PE(s)-CE(s) avec l'AS-Override déjà configuré.
Remarques :
- Les Labs qui suivent contiennent une config IP-MPLS d’un Service Provider implémentée. Tout l’OSPF, LDP, VRFs (RDs et RTs), MP-BGP et routage entre PEs-CEs est déjà configuré.
- Une connaissance de l'attribut "AS-Path" dans BGP est fortement recommandée et essentielle avant de lire la suite ! L’image officielle Cisco ci-dessous rappelle de manière simple cette notion de l’AS-PATH dans BGP :
AS-Override
Vu la protection anti-boucle assurée par BGP quand un Site reçoit son propre AS dans l'AS Path (Block), le mécanisme ajouté manuellement d'AS-Override au niveau de PE permet de remplacer le numéro d’AS du client dans l’AS-PATH par son propre AS (Celui de l'opérateur).
La démarche est la suivante :
L'Update du Network 192.16810.0/24 provenant du CE-01, traversant l’IP-MPLS de l’opérateur et transmis par PE-02, n’est pas accepté par CE-02 car il contient déjà dans son AS Path l’AS 65200 (même AS du CE-02) : Block.
Voir Outputs :
| PE-01 : |
|---|
| PE-02 : |
|---|
| CE-02 : |
|---|
La solution de « contournement » c’est l’AS-Override : On va remplacer au niveau du PE-02 l’AS de CE-01 (65200) par celui de l’Opérateur (65100) dans le champ « AS-Path » :
Le PE-02 détecte que l’AS de son neighbor CE-02 se trouve dans l’AS Path du Network à annoncer, sans « as-override », il transmet l’Update (puis CE-02 le bloque), mais avec « as-override », il remplace le champ 65200 par celui de son propre AS : 65100.
En utilisant ce correctif, CE-02 ne va pas bloquer l’Update car il va recevoir exactement « 65100, 65100 ».
La commande à utiliser (au niveau de PE-02) est « as-override ».
Voir commande et Outputs :
| PE2 : |
|---|
router bgp 65100
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 65100
neighbor 1.1.1.1 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
exit-address-family
!
address-family ipv4 vrf Client-A
neighbor 10.10.200.2 remote-as 65200
neighbor 10.10.200.2 activate
neighbor 10.10.200.2 as-override
no synchronization
exit-address-family
Voilà ! Le Network est bien réçu :)
Allowas-in
Dans certains cas particuliers où le client veut recevoir -malgré tout- l’AS initial en duplication dans l’AS-Path, tout en s’assurant par avance qu’aucune boucle ne se forme, on peut utiliser la commande « allowas-in ».
Cette commande s’applique au niveau du CE-02 dans l’exemple précédant, elle « contredit » la règle par défaut de « AS-Path split-horizon Rule » de BGP, et permet donc d’accepter les Networks provenant d’un AS similaire à son propre AS interne ..
Aucune modification n’est donc apportée à l’AS Path. On utilise cela dans des environnements multi-homing ou certaines phases de migration …
La config est la suivante (CE-02) :
router bgp 65200 neighbor 10.10.200.1 allowas-in
Remarque (Comparaison entre as-override et allowas-in) :
| As-Override | Allowas-In |
|---|---|
| Configuré sur le PE | Configuré sur le CE |
| Modifie l’AS-PATH | Ne modifie pas l’AS-PATH |
| Solution côté Service Provider | Solution côté Customer |
| Protection complète contre les boucles | Peut créer des boucles si mal utilisé par l’IT Team |
Site of Origin (SoO)
Avec AS-Override, on a pu éliminer le problème de duplication d’AS déjà existant dans le champ « AS-Path ». Donc pas de Pb si le client possède plusieurs sites distants dans un même AS. Cependant, dans certaines architectures redondantes, le client possède deux CPEs dans le même site qui forment une boucle avec les PEs auxquels ils sont connectés.
La figure ci-dessous illustre un cas particulier d’une topologie : La boucle formée par les CEs peut engendrer des Pbs de routage (Loops, flux asymétriques). Une route peut revenir vers son CE d’origine via un autre chemin.
Il faut trouver alors un mécanisme Layer 3 - en analogie avec le Spanning-tree Layer 2 - qui évite ces Pbs de routage dus aux boucles BGP entre PEs-CEs : C’est le Site-of-Origin (soo).
Le concept est simple : SoO ajoute une étiquette spéciale à la route et permet d’identifier de quel site provient une route X afin de l’autoriser ou bloquer. Les Updates avec des SoO différents ou sans SoO configurés sont tout simplement annoncés (permis).
Pour expliquer plus techniquement et clairement le concept : le PE attache un SoO à une route venant d’un site (CE). Si cette route revient vers le même site à travers un autre chemin, le PE voit le même SoO. Il bloque la route !
Il est à noter que le SoO est un « extended community » de MP-BGP transféré avec les Updates vpn4. Il s’écrit de la même manière que les RTs/RDs. Il est appliqué aux Updates reçus au niveau du PE provenant de son Neighbor CE.
L’exemple suivant illustre un design où l'AS-Override est déjà configuré au niveau des PEs, les CEs du Client sont tous dans le même AS :
Lorsque PE1-01 reçoit le préfixe 192.168.10.0/24 de CE-01, il lui attribut le SoO configuré et l’envoie par suite à PE2 en Update BGP, ce dernier effectue une comparaison entre les deux valeurs de SoO qu’il trouve: celle qui correspond au voisinage PE-01/CE-01 (envoyée) et celle pour PE-02/CE-02 (actuelle configurée sur PE-02). Si les deux valeurs sont similaires, l’Update n’est pas transférée vers CE-02 et une boucle de routage est évité !
La configuration de SoO est la suivante (sur chaque PE, côté voisinage BGP avec le CE) :
| PE-01 | PE-02 |
|---|---|
|
router bgp 100 |
router bgp 100 |
Plusieurs architectures et designs nécessitent la maitrise de « soo », parmi lesquelles on cite : Le Multi-homing CEs vers PEs (vus plus haut), les Backdoor links entre sites, les migrations MPLS, les design avec DMVPN et MPLS en // …
Recap Final
AS-Override : "Je modifie l’AS pour que le client accepte"
Allowas-In : "J’accepte quand même si je vois mon AS"
SoO : "Je marque la route pour éviter qu’elle ne revienne encore chez elle"
Ce contenu t’a plu ? T'as trouvé utile ?
Tu peux m’offrir alors un Super Café ☕☕:)
Ton soutien me permet de continuer à créer des ressources gratuites et utiles :)
✔ Soutien volontaire
✔ Aucun abonnement
✔ Paiement 100% sécurisé
🔒 Paiement sécurisé via Stripe
Ajouter un commentaire
Commentaires
Si nous avons l'entière disposition pour mettre en place les AS que nous voulons à travers un MPLS. Mais qu'une erreur a été faite et que le même AS a été mis pour deux sites. Est-il préférable de changer l'AS d'un des sites concernés ou mettre en place l'AS Override?