Les itinéraires eBGP appris ne sont pas distribués aux voisins iBGP

8

J'ai (dans GNS3) trois Cisco 3640 exécutant 12.4 (23) connectés en série (R1 -> R2 -> R3). R1 et R2 sont des pairs eBGP, R2 et R3 sont des pairs iBGP. R1 annonce le réseau 192.168.1.0/24. R2 reçoit cette route, mais ne la communique pas à R3.

Les itinéraires appris d'eBGP ne devraient-ils pas être annoncés sur iBGP?

Voici la configuration complète telle que saisie:

loop0(R1)s0/0 <--> s0/0(R2)s0/1 <--> s0/1(R3)

R1:
configure terminal
interface s0/0
ip address 172.16.1.1 255.255.255.252
no shutdown
interface loopback0
ip address  192.168.1.1 255.255.255.0
router bgp 1
neighbor 172.16.1.2 remote-as 2
network 192.168.1.0 mask 255.255.255.0

R2:
configure terminal
interface s0/0
ip address 172.16.1.2 255.255.255.252
no shutdown
interface s0/1
ip address 172.16.1.5 255.255.255.252
no shutdown
router bgp 2
neighbor 172.16.1.1 remote-as 1
neighbor 172.16.1.6 remote-as 2

R3:
configure terminal
interface s0/1
ip address 172.16.1.6  255.255.255.252
no shutdown
router bgp 2
neighbor 172.16.1.5 remote-as 2

— user1038451
source

14

En supposant que vous n'avez aucun IGP configuré (comme EIGRP / OSPF / ISIS / RIP), alors l'explication la plus simple est que R3 n'a pas de route vers le prochain saut de 192.168.1.0/24 lorsque la mise à jour iBGP arrive à R3.

loop0(R1)s0/0 <-----------> s0/0(R2)s0/1 <-------------> s0/1(R3)
    AS 1                       AS 2                        AS 2

              --------->                  ----------->
              Prefix: 192.168.1.0/24      Prefix: 192.168.1.0/24
              AS-path: 1                  AS-path: 1
              Next-hop: 172.16.1.1        Next-hop: 172.16.1.1
              *via eBGP*                  *via iBGP*

Étant donné que iBGP ne réinitialise pas le tronçon suivant lorsqu'il reçoit la mise à jour de R1, le tronçon suivant (172.16.1.1) de 192.168.1.0/24 doit être accessible (voir Pourquoi les routeurs ignorent les chemins BGP pour plus de détails).

La façon la plus simple de tester cela est de configurer une statique sur R3:

ip route 172.16.1.0 0.0.0.3 172.16.1.5 name BAD_HACK_FOR_IBGP

C'est évidemment la mauvaise solution, mais c'est un test simple pour illustrer pourquoi les choses sont cassées (gardez à l'esprit que vous devrez peut-être attendre un peu que le scanner BGP du prochain saut s'exécute avant que la route de 192.168.1.0/24 soit installée) .

Il y a deux solutions possibles qui viennent à l'esprit, mais une seule a vraiment du sens dans la plupart des réseaux ...

Meilleure solution : configurer un IGP ... choisissez n'importe quel IGP que vous aimez et annoncez 172.16.1.0/30 dans AS 2 dans cet IGP
Solution facultative : configurez la session d'appairage entre R2 et R3 pour définirnext-hop-self

L'accessibilité au saut suivant est l'un des problèmes les plus fondamentaux lors de la compréhension du BGP; presque tout le monde rencontre ce problème lorsqu'ils expérimentent le protocole.

— Mike Pennington
source

1

Excellente explication. Je n'étais pas au courant que iBGP passe le prochain saut sans modification.

— user1038451

Mike, pourriez-vous fournir un exemple de cas où vous ne voudriez pas l'utiliser next-hop-self(autrement qu'en raison de la présence déjà d'un IGP annonçant l'adresse du prochain bond du pair eBGP)? J'allais d'abord poser une autre question à ce sujet, mais je pensais que ce serait un ajout facile à votre réponse. Ayant récemment testé BGP, et je continue de le faire, cela me rend curieux de savoir pourquoi ce next-hop-self n'est pas le comportement par défaut.

— Eddie

Je peux ajouter des informations à ce sujet, mais cela peut prendre quelques jours avant d'avoir le temps. Histoire courte: le coût IGP pour le prochain saut BGP fait partie de l'algorithme de sélection de chemin eBGP par défaut

— Mike Pennington

0

Vous devriez avoir à annoncer vos interfaces connectées sur R2. parce que le seul réseau 192.168.1.0 ne fait pas maintenant quel est le prochain saut. Vous pouvez vérifier avec "show ip bgp" sur R3.

Comme vous pouvez le voir 192.168.1.0 dans la table bgp R3 mais pas inséré dans la table de routage. Parce qu'il ne sait pas quel est le prochain saut

Solution:

Redistribuer les interfaces connectées sur R2
Dites au voisin EBGP celui qui est le prochain saut en tant que " voisin 172.16.1.2 prochain-saut-soi " sur R1 .

— Deniz KAYDIRAK
source