Pourquoi utiliser iBGP dans un système autonome, si les protocoles IGP répondent au besoin de communication interne

22

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.

user2720323
la source

Réponses:

26

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?

  • Évolutivité 1 : imaginez que vous recevez 500 000 itinéraires EBGP dans plus d'un emplacement 2 et que vous devez influencer le point de sortie par itinéraire dans votre AS. BGP peut gérer beaucoup plus de routes que les protocoles IGP. Ainsi, iBGP est requis sauf si vous êtes prêt à redistribuer tous les itinéraires que vous avez appris via eBGP
  • 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).


Notes de fin:

1 Évolutivité :

  • Vous utilisez BGP parce que vous ne voulez pas transporter l'intégralité de votre table de routage Internet dans votre IGP (c'est-à-dire dans mon cas, OSPF) ...
  • OSPF n'a pas été conçu pour gérer plusieurs milliers de routes dans les tables BGP Internet ... si vous essayez d'utiliser OSPF à cette fin, cela cassera votre réseau. En utilisant l'exemple d'OSPF, les exigences de traitement / inondation LSA de 500 000 itinéraires utilisent trop de ressources dans vos routeurs. Nommez tout autre IGP (EIGRP, RIPv1 / 2, IS-IS, IGRP) et la même histoire est vraie.
  • Il y a eu des cas notoires où un FAI de niveau 1 a accidentellement redistribué sa table BGP dans son IGP (même lorsque la table Internet n'était qu'une petite fraction de sa taille actuelle) et cela a provoqué des pannes majeures. Des contre-mesures ont maintenant été implémentées dans les protocoles IGP ( comme celui-ci pour OSPF dans IOS ) pour empêcher la redistribution de BGP dans OSPF de provoquer une panne majeure.

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.

Mike Pennington
la source
Je ne sais pas si je comprends cette partie: «iBGP est requis, sauf si vous êtes prêt à redistribuer tous les itinéraires que vous avez appris via eBGP». Si nous avons deux routeurs eBGP frontaliers, le routeur A ne connaîtra pas les itinéraires que le routeur B a appris, ou vice versa. Ils doivent échanger les informations d'une manière ou d'une autre et cela se fait normalement en utilisant iBGP. Comment utiliseriez-vous eBGP pour cela? Je ne sais pas comment eBGP pourrait rendre A et B conscients des itinéraires que l'autre routeur a appris.
user4205580
La déclaration à laquelle vous faites référence suppose que vous avez des haut-parleurs non-eBGP. En supposant que vous ne pouvez pas simplement vivre avec des routes par défaut vers vos flux eBGP en amont, à ce stade, vous pouvez soit: A) redistribuer les préfixes eBGP dans votre IGP (généralement une mauvaise idée), ou B) utiliser iBGP. Ma réponse passe la plupart du temps à expliquer pourquoi iBGP est utile.
Mike Pennington
10

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.

ytti
la source
1
BGP est un protocole de vecteur de chemin , qui n'est pas le même qu'un protocole de vecteur de distance
Mike Pennington
3
Le vecteur de chemin est essentiellement un cas spécifique de vecteur de distance. Il est important de réaliser qu'ils sont très similaires en termes de complexité et de coût alors que l'état de la liaison est complètement différent. Extrait du livre BGP de Sam Halabi et Danny McPhersons, page 98 «Cette section ne serait pas complète sans mentionner que BGP tombe dans la catégorie des vecteurs de distance»
ytti
2
Le vecteur de chemin est similaire mais reste un algorithme différent. Vous pouvez en savoir plus à ce sujet dans le livre de Danny McPherson et Russ White, Practical BGP , publié en 2004. lien mobile
Mike Pennington
2
Quelle page affirme que BGP n'est pas un vecteur de distance?
ytti
2
Le chemin AS est un vecteur de distance. Oui, vous pouvez également manipuler les sélections de chemin avec d'autres paramètres. Sam et Danny ont donc mis cela comme vecteur de chemin en plus d'être vecteur de distance, je partage complètement leur point de vue sur la question. Il pourrait être amusant de consommer de la pinte pour discuter de la question, mais pas constructif.
ytti
7

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.

Teun Vink
la source
3

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)

Rémi Letourneau
la source