Quelqu'un peut-il expliquer pourquoi nous avons besoin d'iBGP pour les routes lorsque nous avons les protocoles IGP (OSPF, RIP) pour la communication interne au sein de l'AS?
J'ai lu beaucoup d'articles et de livres, mais je n'ai pas pu trouver la réponse.
Réponses:
Quelqu'un peut-il m'expliquer quel est le besoin de communication IBGP pour les routes, lorsque nous avons les protocoles IGP (OSPF, RIP) pour la communication interne?
Appliquez des limites de confiance / contrôle: BGP a plus de façons de filtrer les pairs que les IGP (pour contrôler ce que vous publiez et recevez).
Structures de données flexibles (peu liées à la puce précédente): les communautés BGP , BGP communautés étendues , -pref locale , etc ... Ceux - ci font BGE une façon attrayante pour mettre en œuvre le routage personnalisées politiques au sein de votre propre système autonome (en utilisant iBGP).
Comme pour tout, il y a des compromis; l'évolutivité, le contrôle et la flexibilité que vous obtenez d'iBGP signifie que c'est un protocole convergent plus lent que les IGP (en général).
1 Évolutivité :
2 Exemple de routage iBGP :
Pour comprendre pourquoi vous pourriez vouloir iBGP, considérez cette entrée de routage au 4.2.2.2 ...
R2>sh ip bgp 4.2.2.2
BGP routing table entry for 4.0.0.0/9, version 3146
Paths: (32 available, best #7, table Default-IP-Routing-Table)
... <!-- extra BGP RIB entries deleted -->
7660 2516 3356, (aggregated by 3356 4.69.130.4)
203.181.248.168 from 203.181.248.168 (203.181.248.168)
Origin IGP, localpref 100, valid, internal, atomic-aggregate
Community: 2516:1030
3356, (aggregated by 3356 4.69.130.6)
4.69.184.193 from 4.69.184.193 (4.69.184.193)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2012
... <!-- extra BGP RIB entries deleted -->
Il y a 32 chemins à considérer ... Dans ce cas, BGP a choisi d'aller à 4.0.0.0/9 via 4.69.184.193 (notez le bestsous l'entrée RIB). Dans ce cas, BGP l'a choisi car cette route a la liste de chemins AS la plus courte. Cependant, toutes les routes ne seront pas préférées via AS3356 (attaché à R1). Certains peuvent être préférés sur R3 (via AS7660). iBGP vous donne la possibilité de savoir (à R2) la voie à suivre pour prendre le chemin BGP le plus court.
BGP route to 4.0.0.0/9 via
NH: 4.69.184.193 [Path: 3356]
-------->
eBGP w/ AS3356 }{ iBGP inside AS64000 }{ eBGP w/ AS7660
S1/0 S1/2 S2/1 S2/3 S3/2 S3/0
Peered w/ AS3356 +------+ +------+ +------+ Peered w/ AS7660
4.69.184.193 <------| R1 |---------| R2 |--------| R3 |-----> 203.181.248.168
+------+ +------+ +------+
| S2/0
|
^
^
| Ingress packet to 4.2.2.2
|
R1, R2 et R3 sont entièrement maillés iBGP. Lorsque iBGP annonce une route, le tronçon suivant reste inchangé . Cela signifie que je dois transporter le sous-réseau pour 4.69.184.193 dans OSPF ...
R2>sh ip route 4.69.184.193
Routing entry for 4.69.184.192/30
Known via "ospf 100", distance 110, metric 65536, type intra area
Last update from 192.0.2.109 on GigabitEthernet3/1, 1w0d ago
Routing Descriptor Blocks:
* 192.0.2.109, from 192.0.2.3, 1w0d ago, via Serial2/1
Route metric is 65536, traffic share count is 1
R2>
Ainsi, lorsqu'un paquet pour 4.2.2.2 arrive à R2, R2 l'envoie Serial2 / 1 parce que c'est là que iBGP nous dit que le prochain saut est.
IGP est généralement OSPF ou ISIS qui sont basés sur l'état des liens, cela nous donne toutes les informations du réseau, tout le monde connaît le réseau du point de vue de tout le monde, ce qui permet des options de convergence et des options d'ingénierie du trafic très intéressantes.
BGP est essentiellement vecteur de distance, il connaît une vue très limitée sur le réseau dans son ensemble. BGP gère très bien le filtrage et la modification des informations de routage.
Le protocole d'état de liaison est assez cher par rapport au vecteur de distance, il serait assez problématique de le mettre à l'échelle à la taille INET DFZ.
Donc, la raison pour laquelle nous avons les deux, c'est parce qu'à l'intérieur d'un réseau spécifique, nous avons une complexité suffisamment faible pour le gérer avec un protocole d'état de liaison, ce qui nous permet d'obtenir tous les avantages d'un haut degré de connaissance du réseau.
Mais comme il ne s'adapte pas à la taille d'Internet, nous avons besoin d'un autre réseau pour connecter ces nombreux îlots d'état de liaison.
Vous pouvez à l'intérieur de votre propre réseau transporter tous les préfixes (y compris le client) dans votre IGP, mais cela aura un impact négatif sur les performances IGP, tandis que tous les avantages de convergence et de TE peuvent être obtenus en transportant simplement les adresses de bouclage des routeurs principaux. L'ajout de préfixes client à IGP ne fait que nuire aux performances de votre réseau en rendant IGP inutilement complexe.
Une raison que j'ai vue assez souvent est la clarté: toutes les routes sont transportées dans un seul protocole de routage (BGP), IS-IS, OSPF ou RIP n'est utilisé que pour la contiguïté. Par conséquent, il n'est pas nécessaire de redistribuer les routes d'un protocole de routage à un autre.
iBGP n'est pas vraiment utilisé pour le routage interne, il est utilisé par tous vos routeurs eBGP pour partager leurs itinéraires.
Ex: Si vous regardez avec 3 autres réseaux, vous voulez que tous vos routeurs eBGP connaissent les routes reçues par les autres afin qu'ils puissent propager ces informations aux pairs si nécessaire / nécessaire (ouvrant ainsi la possibilité pour votre pair d'utiliser le transit via toi)