
Dans cet article, je vais essayer de détailler les différentes méthodes utilisées aujourd’hui pour influence le chemin d’entrée du trafic internet. Ses méthodes s’appliquent lorsque :
- L’entreprise dispose d’au moins deux routeurs Edges pour l’accès internet
- Le protocole BGP est utilisé entre les routeurs Edges de l’entreprise et ceux de/des opérateurs internet.
Le partage de charges du trafic internet entrant est une tâche assez complexe car on ne contrôle pas la décision que les routeurs opérateurs en face peuvent prendre lors de l’acheminement du trafic vers notre réseau, néanmoins il existe des mécanismes qui pourraient influencer le choix du chemin comme :
- L’AS Prepend
- Multi-Exit Descriminator (MED)
- Communities
Pour éclaircir le mode de fonctionnement de chaque option on va se baser sur l’architecture suivante :

Chaque routeur BGP associe l’AS dont il appartient à ses routes avant de les annoncées vers un voisin eBGP, cela permet :
- A chaque routeur BGP de bloquer toute type de route contenant son propre AS pour éviter les boucles. le principe est illustré dans la figure ci-dessous :

- À chaque routeur BGP de connaitre la distance ( calculé à la base de nombre d’AS traversé) entre lui et le routeur BGP qui a généré la route.
BGP AS-Prepend :
Cette fonctionnalité nous permettra de coller une ou plusieurs valeurs d’AS à une route avant de l’envoyer dans un chemin spécifique afin de faire croire aux routeurs distants que ce chemin est trop long.
Dans notre exemple ci-dessous, dans le but d’influencer la décision du routeur « D » à rejoindre le réseau 10.0.0.0/24 via B, j’ai configuré la fonctionnalité AS-Prepend pour attacher deux AS de plus à ma route quand elle est envoyée vers le routeur « B » et trois AS de plus quand elle est envoyée vers le routeur C.
Dans ce cas-là le routeur «D » voit la même route (10.0.0.0/24) avec deux AS-PATH différents et il préfère automatiquement le chemin avec l’AS-PATH le plus court, en l’occurrence via le routeur B.

Si on souhaite que le trafic à destination du 10.1.0.0/24 arrive par routeur « B » et celui à destination du 10.2.0.0/24 arrive par routeur « C », on doit configurer routeur « A » comme suit :
access-list 10 permit 10.0.0.0 0.0.0.255
access-list 11 permit 10.1.0.0 0.0.0.255
!
route-map AS-Prep-RB permit 10
match ip address 10
set as-path-prepend 65002 65002 65002
!
route-map AS-Prep-RC permit 10
match ip address 11
set as-path-prepend 65002 65002 65002
!
router bgp 65002
neighbor “B” remote-as 65001
neighbor “B” route-map AS-Prep-RB out
neighbor “C” remote-as 65001
neighbor “C” route-map AS-Prep-RC out
La configuration de l’AS-Prepend est supporté même si le routeur « A » est connecté à deux opérateurs différents (AS Différents).
Toutefois il faut faire attention car il y’a des cas ou l’AS-Prepend ne fonctionne pas, par exemple :
- L’opérateur internet applique des routes d’agrégation et donc tes réseaux sont englobés dans une route moins précise et n’est plus visible dans le réseau internet
- L’opérateur n’accepte pas ou réinitialise la configuration de l’AS-Prepend.
Il est très important de vérifier les politiques de routages utilisée par ton ISP avant d’appliquer cette configuration.
Multi-Exit Descriminator (MED)
MED, connu largement par le nom Metric, est un autre mécanisme d’influence du trafic entrant au sein de ton AS. Il faut considérer l’utilisation du MED seulement si tu es connecté à un seul ISP.
Le principe du MED est simple, plus la valeur MED est supérieure moins la route est attractive,
Partant de ce principe, si on souhaite dans notre exemple influencer l’entrée du trafic à destination du réseau 10.0.0.0/24 par le routeur « C », il faudra tout simplement associer une valeur MED supérieure à la route 10.0.0.0/24 avant de l’envoyer vers le routeur « B »
La figure ci-dessous illustre le principe :

La configuration du MED :
access-list 10 permit 10.0.0.0 0.0.0.255
access-list 11 permit 10.1.0.0 0.0.0.255
!
route-map Set-MED-10 permit 10
match ip address 10
set metric 10
!
route-map Set-MED-1000 permit 10
match ip address 11
set metric 1000
!
router bgp 65002
neighbor “B” remote-as 65001
neighbor “B” route-map Set-MED-1000 out
neighbor “C” remote-as 65001
neighbor “C” route-map Set-MED-10 out
La configuration du MED n’approuve pas automatiquement que ton trafic entrant est influencé car la plupart des opérateurs internet réinitialisent la configuration du MED, encore une fois il faut vérifier avec ton opérateur si les valeurs du MED ne sont pas réinitialisées dans son Backbone.
Communities:
L’utilisation du BGP communities est une différente approche pour influencer le trafic entrant mais seulement si ton routeur Edge est connecté avec deux ou plusieurs liens vers le même opérateur.
Les opérateurs mettent à disposition d’une manière publique des communities BGP lorsqu’on souhaite influencer notre trafic entrant.
Par exemple un opérateur internet pourra fournir deux BGP communites :
- 65001:500
- 65001:200
Ses valeurs Communities sont traduites chez l’opérateur par des valeurs Local-Preference à appliquer à chaque route afin d’influencer le trafic sortant de l’opérateur.
Imaginons que la community 65001:500 est traduite en Local-Preference 500 et la community 65001:200 est traduite en Local-Preference 200
Si on souhaite que le trafic à destination du 10.0.0.0/24 soit acheminé par le routeur « B » il faut qu’on associe simplement la community 65002:500 à la route avant de l’envoyer vers l’opérateur internet.
À la réception de la route l’opérateur vérifiera la community associée à la route est applique l’attribut Local-Preference de 500 au niveau du routeur « B » ce qui lui rend le point de sortie préférentiel vers le 10.0.0.0/24.
Le principe est illustré dans la figure ci-dessous :

Conclusion :
Dans cet article, on a vu les trois mécanismes offerts par le protocole BGP pour influencer le trafic entrant. Ses mécanismes présentent quelques limitations soit parce que l’opérateur internet ne les prennent pas en considération type AS-PREPEND et MED, soit par ce que le mécanisme n’est supporté que si l’ensemble des liens sont connecté à un seul opérateur.
Il existe heureusement un quatrième mécanisme plus efficace et ne nécessite aucune vérification de son support auprès de ton opérateur. Si tu connais de quoi je parle, merci de le mentionner dans la partie commentaire ci-dessous.
Si vous avez des questions, des remarques ou vous avez besoin d’un complément d’informations, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter directement à l’adresse : contact@mhd-experts.com.
Ahmed
juin 2, 2020Très bon article Driss!
Jouer sur la longueur du préfixe est peut être la 4ème option dont tu parles, n’est ce pas?
L’idée étant de segmenter le préfixe en 2 par exemple, anonncer le /24 d’un côté et 2 x /25 de l’autre.
Encore faut-il que ton/tes opérateur(s) autorise(nt) des préfixes longs.
Roux Blanc
juin 3, 2020Mes chers experts, si vous voulez montrer le bon exemple à suivre aux jeunes networkers qui vous lisent, pourquoi vous ne montrez pas directement la bonne manière de configurer le filtrage pour manipulation des routes/prefixes BGP c’est à dire avec des prefix-list. C’est bien plus précis, plus lisible quand on troubleshoot, ça plaît plus aux yeux. En plus ça m’aurait donner plus envie de me pencher sur l’autre question que de faire ce commentaire. Aggr aggr, soyez plus fin 😉
driss jabbar
juin 3, 2020C’est exactement ce que j’ai pensé !!!
driss jabbar
juin 3, 2020Une très bonne remarque. Merci
Khaled
juin 4, 2020Tres bon article.
Les prefix ca va marcher mais pas au-delà de /24. Comme IPv4 est saturé, pour limiter la taille des tables de routage les ISP limite /24 max les annonces
Donc segmenter un /23 en deux /24.
Annoncer le /23 sur les 2 ISP, et chaque /24 sur l ISP privilégié.
driss jabbar
juin 4, 2020Exactement, on peut pas annoncer aux opérateurs des /25, le minimum c’est du /24.Cela implique aussi que le client doit posséder son propre /23 et un AS public.
Mahamar
juin 7, 2020Article très intéressant !
Merci et bonne continuation
driss jabbar
juin 8, 2020Merci