Vous avez assimilé la théorie sur le protocole BGP ?
Voyons comment le mettre en place de manière basique.
Nous verrons plus tard des configurations plus complexes.
1) La topologie à utiliser
Voici la topologie que nous utiliserons tout au long de cette mise en pratique.
Le but sera de voir les configurations de base de BGP.
Trois Autonomous System sont à connecter grâce à BGP.
2) Configuration de base
La configuration de base à mettre en place afin de suivre cet article est la suivante :
- Adresses IP
- Interfaces Loopback
- OSPF sur R1, R2 et R3
Une fois cela fait, vous pouvez passer à la suite : la configuration de BGP !
3) Relations de voisinage BGP
Bien, voyons comment créer une relation de voisinage BGP entre deux routeurs
Relation eBGP
Tout d’abord, entrer dans le mode BGP en spécifiant le numéro d’AS :
R1(config)#router bgp 300
Puis ajouter une relation de voisinage :
R1(config-router)#neighbor 14.0.0.4 remote-as 100
On spécifie l’IP du voisin ainsi que son AS
Il faut maintenant faire de même sur R4 :
R4(config)#router bgp 100 R4(config-router)#neighbor 14.0.0.1 remote-as 300
Comme nous l’avions dit, BGP est un protocole lent.
Après un certain temps, la relation BGP va apparaitre :
Nous pouvons voir la liste des relations comme ceci :
Faisons de même pour R3 et R5 :
R3(config)#router bgp 300 R3(config-router)#neighbor 35.0.0.5 remote-as 200
R5(config)#router bgp 200 R5(config-router)#neighbor 35.0.0.3 remote-as 300
Les relations sont créées. Ce sont des relations eBGP car elles se mettent en place entre deux Autonomous System.
Relation iBGP
Il est aussi possible de mettre en place des relations iBGP (au sein d’un même AS).
Nous allons donc mettre en place une relation iBGP entre R1 et R3. Le but est qu’ils s’échangent leurs routes BGP sans qu’il soit nécessaire d’utiliser de la redistribution.
Vous pourrez constater qu’il n’est pas nécessaire que les routeurs soient directement connectés pour qu’une relation se forme.
Pour une relation iBGP, il est conseillé d’utiliser une IP de Loopback comme IP de voisin.
Pourquoi ? Car si nous utilisons une IP d’interface, et que celle-ci tombe en panne, la relation BGP disparait. Bien sûr, cela est utile que si notre réseau dispose de liens redondants vers ce voisin.
Si nous avions un lien direct entre R1 et R3 (en plus du lien R1 -> R2 -> R3), et que nous utilisions 10.0.23.3 comme IP de voisin pour R3, la relation BGP disparaitrait si le lien R1 -> R2 -> R3 tombait (alors qu’il reste le lien R1 -> R3).
Ici nous n’avons qu’un lien reliant R1 et R3. Mais voyons tout de même comment faire une relation de voisinage avec une IP de Loopback.
Sur R1 et R3, ajouter une interface de Loopback. Ne pas oublier d’inclure cette interface dans le processus OSPF.
R1(config)#interface loopback 0 R1(config-if)#ip address 1.1.1.1 255.255.255.255 R1(config)#router ospf 1 R1(config-router)#network 1.1.1.1 0.0.0.0 area 0
R3(config)#interface loopback 0 R3(config-if)#ip address 3.3.3.3 255.255.255.255 R3(config)#router ospf 1 R3(config-router)#network 3.3.3.3 0.0.0.0 area 0
Ensuite, configurer la relation BGP :
R1(config)#router bgp 300 R1(config-router)#neighbor 3.3.3.3 remote-as 300
R3(config)#router bgp 300 R3(config-router)#neighbor 1.1.1.1 remote-as 300
Un « Show ip bgp summary » vous montrera que la relation n’est pas UP :
Cela tient au fait que quand R3 envoie un message à R1, le message a pour source 10.0.23.3 (l’IP de l’interface qui envoie le message).
Or R1 s’attend à recevoir des messages de 3.3.3.3
Il faut donc changer la source des messages pour cette relation de voisinage :
R1(config-router)#neighbor 3.3.3.3 update-source loopback 0 R3(config-router)#neighbor 1.1.1.1 update-source loopback 0
Un peu de patience et la relation devrait apparaitre.
Relation eBGP avec IP de Loopback
Finissons par une petite particularité, la mise en place de relation eBGP avec une IP de Loopback.
Si vous faites ceci, il faut ajouter une commande (en plus de la relation de voisinage avec IP de Loopback). La voici en exemple pour R5 :
R3(config-router)#neighbor 5.5.5.5 ebgp-multihop 2
Il est nécessaire d’utiliser cette commande, car par défaut, une relation eBGP ne peut pas s’établir sur une distance de plus de 1 saut.
Il faudra appliquer la même commande sur R5.
Il faut aussi que les deux routeurs sachent comment joindre l’IP de Loopback. Dans l’exemple, R5 doit avoir une route vers 3.3.3.3 (et inversement pour R5).
L’utilisation d’une IP de Loopback pour une relation eBGP est utile si vous possédez un lien redondant (double lien) vers le voisin.
4) Distribution de route
Solution 1 : La commande Network
Les relations de voisinage sont en place, c’est une bonne chose.
Par contre, il manque quelque chose :
Les routes ne sont pas redistribuées par BGP.
La commande « Neighbor » ne fait qu’établir la relation BGP.
Pour annoncer des réseaux (les inclurent dans le processus BGP), voici la procédure :
R4(config)#router bgp 100 R4(config-router)#network 40.0.0.0 mask 255.255.255.0 R4(config-router)#network 40.0.1.0 mask 255.255.255.0 R4(config-router)#network 40.0.2.0 mask 255.255.255.0
Contrairement aux autres protocoles, la commande « Network » ne fait qu’ajouter des réseaux au processus. Elle ne permet pas de créer une relation avec un voisin.
Voici le résultat :
A ce stade, vous vous demandez surement pourquoi nous n’avons pas annoncé le réseau 40.0.0.0 /22.
Simplement parce que BGP ne peut annoncer une route que si elle est présente dans la table de routage.
Or, voici la table de routage de R4 :
La route 40.0.0.0 /22 n’existe pas. Nous ne pouvons donc pas l’annoncer avec BGP.
Ensuite, annoncez les réseaux de R5 :
R5(config-router)#network 50.0.0.0 mask 255.255.255.0 R5(config-router)#network 50.0.1.0 mask 255.255.255.0 R5(config-router)#network 50.0.2.0 mask 255.255.255.0
Solution 2 : la redistribution
La deuxième solution consiste à utiliser la redistribution de route.
Ici rien de bien nouveau. Voyons tout de même un exemple pour BGP.
Nous allons ajouter deux interfaces de Loopback sur R5, de manière à créer de nouvelles routes.
R5(config)#interface loopback 3 R5(config-if)#ip address 50.1.0.1 255.255.255.0 R5(config-if)#interface loopback 4 R5(config-if)#ip address 50.1.1.1 255.255.255.0
Le but est que R5 annonce ces routes en BGP.
Profitons-en pour faire une redistribution propre :
R5(config)#access-list 10 permit 50.1.0.0 0.0.0.255 R5(config)#access-list 10 permit 50.1.1.0 0.0.0.255
R5(config)#route-map BGPRedistribution R5(config-route-map)#match ip address 10
R5(config)#router bgp 200 R5(config-router)#redistribute connected route-map BGPRedistribution
Voici le résultat :
5) Distribution des routes par iBGP
Nous avons mis en place la distribution de route par BGP.
R4 annonce ses routes à R1, et R5 annonce ses routes à R3.
Mais il y a un problème que vous aurez peut être remarqué : R1 et R3 ne s’échange pas de route par BGP.
La relation iBGP entre R1 et R3 ne semble pas permettre la redistribution des routes apprises par eBGP.
Vous pouvez voir cela sur la table de routage juste au-dessus.R3 ne connait pas les réseaux 40.0.0.0 /22
En réalité, R1 connait les routes, mais il ne les places pas dans sa table de routage.
Il n’y a pas de chevron devant la route. Elle n’est donc pas mise dans la table de routage.
Mais pourquoi donc ?
Il y a deux raisons.
1er raison : Un routeur n’apprend pas une route par iBGP (et ne la redistribue pas) tant qu’il n’a pas appris cette même route par un protocole de routage interne (type OSPF).
Dans notre topologie, R1 n’apprendra pas la route pour 50.0.0.0 /24 par iBGP (donc venant de R3), tant qu’il n’a pas reçus une MAJ OSPF contenant une route vers cette même destination.
Cette règle était valable sur les anciens routeurs Cisco. Pour l’annuler, il faut entrer la commande « no synchronization ».
Un « Show run » vous permettra de savoir si la commande est activée par défaut.
Si ce n’est pas le cas, il faut l’entrer sur R1 et R3.
2e raison : Quand eBGP annonce une route, il change le Next-Hop. Quand iBGP annonce une route, il ne change pas le next hop.
Qu’est-ce que cela pose comme problème ?
Et bien R3 va annoncer une route à R1, ayant pour destination 50.0.0.0 /24, et pour Next Hop 35.0.0.5.
Hors R1 n’a pas la moindre idée de comment joindre 35.0.0.5.
Il ne va donc pas placer cette route dans sa table de routage.
La commande « Show bgp » vous permet de voir les routes avec leurs Next-Hop.
Il va donc falloir changer le Next-Hop au moment où R3 annonce les routes à R1.
La manipulation est simple :
R3(config)#router bgp 300 R3(config-router)#neighbor 1.1.1.1 next-hop-self
R3 va changer le Next-Hop par son IP quand il va redistribuer des routes à R1.
Pareil pour R1 :
R1(config)#router bgp 300 R1(config-router)#neighbor 3.3.3.3 next-hop-self
Voyons si cela a marché :
En effet, R1 connait maintenant les routes redistribuées par R3 (et inversement pour R1).
Au passage, vous noterez que R4 a aussi appris les routes (pareil pour R5).
6) Les trous noirs causés par BGP
Aviez-vous remarqué que vous avez créé un trou noir ? Ou plutôt que je vous ai fait créer un trou noir ?
Bon certes, le terme est un peu fort, mais tout de même.
Pour constater les dégâts, faites un ping depuis R4 vers 50.0.0.1.
Normalement, il devrait passer, non ?
Et bien non …
Et pourquoi ? Car R2 ne connait pas la route vers 50.0.0.0 /22.
Et pourquoi ne connait-il pas la route ? Car celle-ci a été annoncée en BGP. La MAJ est venue de R5, elle est passée par R3 puis a traversé R2 (sans que celui-ci ne la prenne en compte), puis elle est arrivée à R1 (puis R4).
Au final, R2 a bien reçu la MAJ. Sauf que comme il n’utilise pas BGP (et donc qu’il n’a pas de relation de voisinage), il ne la pas assimilé. Il s’est contenté de la dirigé vers sa destination (R1).
Mais comment empêcher le trou noir ?
3 solutions :
- Mettre en place un lien direct entre R1 et R3
- Redistribuer les routes BGP dans OSPF (R2 va donc les assimiler)
- Mettre en place BGP sur R2
La mise en place d’un lien est la solution la plus simple est la plus performante. Il faut tout de même que le câblage soit réalisable.
La redistribution de route est une bonne solution si R2 est capable de supporter toutes les routes. Dans cet exemple, il n’y a pas beaucoup de route. Mais imaginez une topologie avec de très grandes tables de routage (ce qui arrive quand on se connecte à un FAI).
Il faut donc voir si R2 possède suffisamment de ressources.
De plus, le routeur de destination doit connaitre la route de retour.
Par exemple, pour aller de R1 à R5, la redistribution permet à R1 de connaitre 50.0.0.0 /22, mais il faut que R5 connaisse la route pour revenir à 10.0.12.0 /24.
Il en est de même pour l’utilisation de BGP. A la différence près que BGP conserve toutes les routes reçues. Si R1 et R3 envoient des routes pour la même direction, R2 va toutes les conserver. Puis il va mettre la meilleure dans la table de routage.
Si R1 et R3 envoient des routes similaires, cette solution est plus gourmande que la redistribution.
Libre à vous de choisir la solution adéquate.
Vous devriez être capable de faire fonctionner les trois.
Pour ma part, je vais faire simple. Je vais placer un lien entre R1 et R3.
Néanmoins, je vous encourage à tenter unes des deux autres solutions.
Il y a un ou deux pièges à éviter. La mise en place peut donc être intéressante.
Il faut bien faire attention. Pour que les solutions fonctionnent il faut que les routes soient connues de tous les routeurs.
Voici pour la mise en place d’un lien :
Ajouter le lien :
Configurer les interfaces.
Mettre en place de l’OSPF entre R1 et R3 (pour que le meilleur chemin vers 3.3.3.3 soit le lien Ethernet).
Inclure les réseaux 14.0.0.0 /24, 35.0.0.0 /24 et 10.0.13.0 /24 dans le processus BGP.
Voici le résultat :
j’ai lu ce document attentivament, j’en est tiré profit car la configuration du protocole BGP est l’objet de la dernière capitre de mon travail de fin d’étude. merci beaucoup.
Bonjour ,
Il ya juste une erreur :
Distribution des routes par iBGP :1 ere raison :c’est pas a cause de la commande no auto-summury
mais plutot la commande no synchro
Bonjour,
Effectivement, j’ai corrigé l’article.
Merci
Bonsoir,
Merci pour votre article il est très riche.
Dans la section des trous noirs, si on veut Redistribuer les routes BGP dans OSPF est ce qu’on garde le BGP dans R1 et R3 et rajoute dans R2 (dans le process OSPF on mets redistribute bgp 300 subnets) ?
je l’ai testé comme ça, mais ça ne marche pas (R2 n’apprend pas les réseaux 40.0.0.0/22 et 50.0.0.0/22) 🙁
Merci d’avance et bonne continuation.
Bonjour,
J’ai fait la simulation , mais je bloque au niveau de OSPF, je l’ai bien mis en place sur R1 et R3 ,mais ils n’arrivent pas à ce joindre pour monter l’adjacence iBGP . Lors d’un sh ip bgp summary l’état est toujours sur « never » malgré le fait que j’ai fait un update-source … J’ai essayé d’activer OSPF sur R2 ce qui ne devrait pas être nécessaire vu que celui à acces au deux réseau via ses interfaces ( je l’ai activé car de toute manière c’est nécessaire pour la topologie).
Merci de ton aide.
Bonjour,
Qu’avez vous appliqué comme configuration sur R1 et R3 ? L’activation d’OSPF sur R2 est nécessaire, comme indiqué dans la partie 2 : Configuration de base.
Bonjour ,
Votre article est super riche et aisé à comprendre tellement bien fait.
Merci infiniment car cet article a levé la zone d’ombre que j’avais sur le concept BGP.
Bonne continuation .
Bonjour,
Merci pour ce tutoriel parfait.
J’ai juste galéré pour la partie « trous noirs » pour configurer BGP sur R2.
Il faut d’après ce que je comprends ajouter les réseaux 10.0.12.0 ; 10.0.23.0 ; 14.0.0.0 ; 35.0.0.0 sur R1 et R3 pour annoncer les réseaux de jonction.
Cordialement
Bonjour,
En fait, pour le problème du trou noir, il faut que R2 connaisse les routes vers 40.0.X.X et 50.0.X.X.
Par exemple, quand R1 veut router un paquet vers 50.0.X.X, il sait qu’il doit l’envoyer à R3. Hors, il n’a pas de lien direct vers R3, donc il route le paquet vers R2. R2 reçoit un paquet à destination de 50.0.X.X, et comme il n’a pas de route vers ce réseau, il drop le paquet.
Donc une des solutions est d’ajouter (d’une manière ou d’une autre) les routes vers 40.0.X.X et 50.0.X.X
Bonjour, j utilise cisco pakcketer tracer student sur ma tablette er quand je veux faire de l ibgp, celui ci me dit qu il n es pas supporter sur cette version, quelqu un connaitrais un contournement
Bonjour,
Bon des configurations avancées comme celle-ci, je vous conseille d’utiliser GNS3. Vous trouverez toutes les informations sur internet.
Bonjour
Merci pour ce doc .Mais pour moi impossible de pinguer malgré le EBGP entre R2-R4 et R2-R5
R2 :
R2# sh bgp
Network Next Hop Metric LocPrf Weight Path
*> 10.0.12.0/24 0.0.0.0 0 32768 i
*> 10.0.23.0/24 0.0.0.0 0 32768 i
*> 40.0.0.0/24 4.4.4.4 0 0 100 i
*> 40.0.1.0/24 4.4.4.4 0 0 100 i
*> 40.0.2.0/24 4.4.4.4 0 0 100 i
*> 50.0.0.0/24 5.5.5.5 0 0 200 i
*> 50.0.1.0/24 5.5.5.5 0 0 200 i
*> 50.0.2.0/24 5.5.5.5 0 0 200 i
*> 50.1.0.0/24 5.5.5.5 0 0 200 ?
*> 50.1.1.0/24 5.5.5.5 0 0 200 ?
R5# sh bgp
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.0.12.0/24 2.2.2.2 0 0 300 i
*> 10.0.23.0/24 2.2.2.2 0 0 300 i
* 40.0.0.0/24 2.2.2.2 0 300 100 i
*> 35.0.0.3 0 300 100 i
* 40.0.1.0/24 2.2.2.2 0 300 100 i
*> 35.0.0.3 0 300 100 i
* 40.0.2.0/24 2.2.2.2 0 300 100 i
*> 35.0.0.3 0 300 100 i
*> 50.0.0.0/24 0.0.0.0 0 32768 i
*> 50.0.1.0/24 0.0.0.0 0 32768 i
*> 50.0.2.0/24 0.0.0.0 0 32768 i
*> 50.1.0.0/24 0.0.0.0 0 32768 ?
*> 50.1.1.0/24 0.0.0.0 0 32768 ?
R4#sh bgp
Network Next Hop Metric LocPrf Weight Path
*> 10.0.12.0/24 2.2.2.2 0 0 300 i
*> 10.0.23.0/24 2.2.2.2 0 0 300 i
*> 40.0.0.0/24 0.0.0.0 0 32768 i
*> 40.0.1.0/24 0.0.0.0 0 32768 i
*> 40.0.2.0/24 0.0.0.0 0 32768 i
* 50.0.0.0/24 2.2.2.2 0 300 200 i
*> 14.0.0.1 0 300 200 i
* 50.0.1.0/24 2.2.2.2 0 300 200 i
*> 14.0.0.1 0 300 200 i
* 50.0.2.0/24 2.2.2.2 0 300 200 i
*> 14.0.0.1 0 300 200 i
* 50.1.0.0/24 2.2.2.2 0 300 200 ?
*> 14.0.0.1 0 300 200 ?
* 50.1.1.0/24 2.2.2.2 0 300 200 ?
*> 14.0.0.1 0 300 200 ?
Pouvez-vous SVP me dire ou ça bloque merci d’avance
Bonjour,
Avez-vous bien utilisé la commande « next-hop self » ?
Je vous renvoie à la partie 5 pour l’explication par rapport à cette commande.
Bonjour et merci pour ces articles !
Une petite question: est-il possible avec la commande network de ne distribuer que deux IP unitaires en /32 ?
Comme ceci:
network 10.2.0.2 255.255.255.255
network 10.2.0.3 255.255.255.255
Mon réseau est 10.2.0.1/255.255.255.248
Mon routeur est bien en directly connected avec 10.2.0.1/255.255.255.248.
Mais Je n’ai pas réussi à faire fonctionner.
J’ai du passer par la commande
network 10.2.0.1/255.255.255.248
Que celà ne tienne, je me suis dis que j’allais filtrer avec des prefix-list pour n’envoyer que les 2 /32 qui intéressent mais quenini.. Ma prefix List doit correspondre au réseau déclaré dans la commande network.
Si vous avez une petite idée 🙂 merci;
Florian.
Bonjour,
Je n’ai jamais rencontré ce besoin. Si vous arrivez à créer une route statique pour chaque /32, vous pouvez les redistribuer en BGP.
Bonjour
Merci énormément pour votre travail, parfaitement expliqué
je vouderais bien ajouter une 3eme solution pour le Trou Noir, celle de configurer du MPLS entre les routeurs R1,R2,et R3. Ce qui se traduit par du BGP Free Core.
Merci
Bonjour, Merci pour votre tuto, ça m’a vraiment permise d’avancer. en fait, je travaille sur un projet scolaire avec BGP actu et je bloque quelque part (au niveau des trous noirs). en fait, dans votre config, iBGP n’est pas activer sur R2, dans ma config, il est activé sur tous les routeurs de mon AS. Mais après avoir activé eBGP, j’arrive pas à avoir des pings entre les autres routeurs de mon AS et un routeur externe.
Bonjour,
Le plus simple est de consulter les tables de routage sur tous les routeurs et de voir où il manque la route sur le chemin.
Autre piste, avez-vous passé la commande « no synchronization » sur R2 ? Voir section 5) Distribution des routes par iBGP
Bonsoir, merci d’avoir répondu. Mais j’ai passé la commande « no synchro ». Je vous explique un peu mon topo.
J’ai 4 routeurs. R1,R2 et R3 sont dans le meme AS (AS 123). R4 dans un AS différent (AS 400)
iBGP est activé entre R1, R2 et R3, ça fonctionne sans soucis. R4 est connecté physiquement à R2 puis on a dans l’AS 123 R2-R1-R3. Maintenant le problème se pose au niveau de R4. Il a été demandé d’annoncer le réseau de R4 dans BGP à travers R2 mais pas par son loopback. Ce qui a été fait. Mais je R3 n’arrive pas à pinger R4. J’ai utilisé le next-hop-self mais là je vois le réseau de R4 sur la table de routage de R3 et sur sa table BGP mais sans plus. Voici mes configs:
R1#sh run | sec bgp
router bgp 123
bgp log-neighbor-changes
network 10.1.1.0 mask 255.255.255.0
neighbor 10.2.2.2 remote-as 123
neighbor 10.2.2.2 update-source Loopback0
neighbor 10.3.3.3 remote-as 123
neighbor 10.3.3.3 update-source Loopback0
R2#sh run | sec bgp
router bgp 123
bgp log-neighbor-changes
network 10.2.2.0 mask 255.255.255.0
neighbor 10.1.1.1 remote-as 123
neighbor 10.1.1.1 update-source Loopback0
neighbor 10.3.3.3 remote-as 123
neighbor 10.3.3.3 update-source Loopback0
neighbor 10.3.3.3 next-hop-self
neighbor 24.24.24.4 remote-as 400
R3#sh run | sec bgp
router bgp 123
bgp log-neighbor-changes
network 10.3.3.0 mask 255.255.255.0
neighbor 10.1.1.1 remote-as 123
neighbor 10.1.1.1 update-source Loopback0
neighbor 10.2.2.2 remote-as 123
neighbor 10.2.2.2 update-source Loopback0
neighbor 10.2.2.2 next-hop-self
R4#sh run | sec bgp
router bgp 400
bgp log-neighbor-changes
network 10.4.4.0 mask 255.255.255.0
neighbor 24.24.24.2 remote-as 123
Merci de votre aide.
bonjour,
j’ai une question:
le réseaux 14.0.0.0/24 et le réseaux 35.0.0.0/24 ne sont pas annoncés ni par ospf ni par BGP, pourquoi ? et merci beaucoup pour ce site et ces effort
Bonjour,
Ces réseaux ne seront annoncés en OSPF ou BGP que si ils ont été inclus dans le process (commande network).
Et si vous souhaitez annoncer une route apprise en OSPF dans du BGP (ou l’inverse), il faut faire de la redistribution.
Bonsoir,
Ce tuto est vraiment incroyable merci d’avance pour le travail et l’aide à la compréhension de ce protocole.
Je suis bloqué à la partie trou noir, quand j’essai n’importe laquelle des trois technique je n’arrive pas à faire fonctionner le routage entre R4 et R5.
Serait-il possible d’avoir de l’aide ou un exemple par rapport à cela ?
Merci d’avance
Bonjour,
Je vous invite à vérifier les configurations, puis à étudier les tables de routage de chaque routeur.
Mais surtout, si vous avez choisi d’ajouter un lien entre R1 et R3, assurez-vous que ce lien soit préféré pour passer de R1 à R3.