Configuration Basique De BGP

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

 

Topologie BGP

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 :

R4 BGP Log

 

Nous pouvons voir la liste des relations comme ceci :

R4 Show Ip BGP Summary

 

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 :

R1 Show Ip BGP Summary

 

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.

R1 Show Ip BGP Summary

 

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 :

R3 Routing Table

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 :

R1 Routing Table

 

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 :

R4 Routing Table

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 :

R3 Routing Table

 

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.

R1 BGP Table

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.

R1 BGP Table

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é :

R1 Routing Table

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).

R4 Routing Table

 

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, faite un ping depuis R4 vers 50.0.0.1.

Normalement, il devrait passer, non ?

Ping vers 50.0.0.1

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 :

Ajout Lien R1-R3

 

Configurer les interfaces.

Mettre en place 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 :

Ping vers 50.0.0.1

 

 

Tagués avec :
Publié dans BGP
7 commentaires pour “Configuration Basique De BGP
  1. ngoma dit :

    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.

  2. RED dit :

    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

  3. michou dit :

    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.

  4. Libouso dit :

    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.

    • Valentin Weber dit :

      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.

  5. Junior dit :

    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 .

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Le temps imparti est dépassé. Merci de saisir de nouveau le CAPTCHA.