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 :
