Introduction

Tous les cas présentés 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 pas toujours évident d'utiliser systématiquement la notion d'AS Override, car il existe une règle générale connue dans le BGP « AS-Path split-horizon Rule » : Tout Update reçu par le BGP depuis un AS différent, contenant dans son « AS Path » le même AS dans lequel on se trouve : DROP !

On verra dans ce qui suit 3 cas différents : 

- Le premier cas montre l'utilité de la commande AS-Override lorsque les deux sites distants du Client se trouvent dans le même AS.

- Le deuxième cas montre l'utilité de la commande Allow-as-in lorsque les deux sites distants du Client se trouvent aussi 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 suivants contiennent une config IP-MPLS Service Provider implémentée. Tout ce qui est 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 même obligatoire avant de lire la suite ! 
L’image officielle Cisco suivante rappelle de manière simple cette notion de l’AS-PATH dans BGP : 

AS-Override 

La figure 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 .

La solution est un « 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 transmit 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 « 65100, 65100 ».

La commande à utiliser (au niveau de PE-02) est « as-override » :

Voilà, le Network est bien reçu ;) 

Allowas-in

Dans certains cas particuliers où le client veut recevoir -malgré tout- l’AS initial en duplication, tout en s’assurant par avance qu’aucune boucle ne se forme ou aucun effet de bord n’apparaisse, 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 qui est le même que l’AS final de destination de CE-02.

Aucune modification n’est donc apportée à l’AS Path.

La config est la suivante (CE-02) :

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 peut engendrer des Pbs de routage (Loops, flux asymétriques). Néanmoins, si on ne la conçoit pas, on n’aura pas de redondance !

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 : L'un des PEs ne va pas annoncer vers le CE connecté les Updates iBGP qui proviennent avec un même SoO depuis l’autre PE (qui les a reçus initialement en eBGP depuis son CE correspondant). 

Les Updates avec des SoS différents ou sans SoS configurés sont tout simplement annoncés.

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 du Neighbor CE.

Le problème présenté est le suivant en supposant que l'AS-Override est configuré au niveau des PEs (les CPEs du Client sont tous dans le même AS) :

Lorsque PE1-01 reçoit le prefix 192.168.10.0/24 de CE-01 et l’envoie par suite à PE2, ce dernier effectue une comparaison entre les deux valeurs de SoO configurées : 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é !

Sans SoO, l’Update arrive jusqu’à CE-02 (mais reste toujours non préférée). Dans le cas particulier ou le network 192.168.10.0/24 est KO au niveau CE-01 (non joignable pour x raisons), ce dernier l’apprend depuis CE-02 à travers l’OSPF et l’injecte vers BGP, la boucle expliquée précédemment se forme et le Network reste injoignable à cause de la Loop.

La configuration de soo est la suivante (sur chaque PE, avec le voisinage vers le CE) :