🥇Principes de fonctionnement du protocole BGP

Aujourd'hui, nous allons examiner le protocole BGP. Ne parlons pas trop longtemps de sa nécessité et de son utilisation en tant que seul protocole. Il y a pas mal d'informations à ce sujet, par exemple ici.

Alors, qu'est-ce que le BGP ? Le BGP est un protocole de routage dynamique, le seul protocole EGP (External Gateway Protocol). Ce protocole est utilisé pour établir le routage sur Internet. Examinons comment se construit le voisinage entre deux routeurs BGP.

Considérons le voisinage entre Router1 et Router3. Configurons-les à l'aide des commandes suivantes :

router bgp 10
  network 192.168.12.0
  network 192.168.13.0
  neighbor 192.168.13.3 remote-as 10

router bgp 10
  network 192.168.13.0
  network 192.168.24.0
  neighbor 192.168.13.1 remote-as 10

Le voisinage au sein d'un même système autonome — AS 10. Après avoir saisi les données sur le routeur, par exemple sur Router1, ce routeur tente de configurer les relations de voisinage avec le routeur Router3. L'état initial, lorsque rien ne se produit, s'appelle Idle. Dès que le BGP est configuré sur Router1, il commencera à écouter le port TCP 179 — il passera à l'état Connecter, et lorsqu'il essaie d'ouvrir une session avec Router3, il passera à l'état Actif.

Après l'établissement de la session entre Router1 et Router3, un échange de messages Open se produit. Lorsque ce message est envoyé par Router1, cet état sera appelé Open Sent. Et lorsqu'il reçoit un message Open de Router3, il passera à l'état Open Confirm. Examinons plus en détail le message Open :

Ce message contient des informations sur le protocole BGP utilisé par le routeur. En échangeant des messages Open, Router1 et Router3 communiquent des informations sur leurs configurations. Les paramètres suivants sont transmis :

Version: cela inclut la version BGP que le routeur utilise. La version actuelle du BGP est la version 4, décrite dans la RFC 4271. Deux routeurs BGP chercheront à négocier une version compatible ; en cas de désaccord, il n'y aura pas de session BGP.

Mon AS: cela inclut le numéro AS du routeur BGP ; les routeurs doivent se mettre d'accord sur le(s) numéro(s) AS et cela définit également s'ils fonctionneront en iBGP ou eBGP.

Hold Time: si le BGP ne reçoit aucun message keepalive ou update de l'autre côté pendant la durée du temps de maintien, il déclarera l'autre côté 'mort' et interrompra la session BGP. Par défaut, le temps de maintien est fixé à 180 secondes sur les routeurs Cisco IOS, le message keepalive est envoyé toutes les 60 secondes. Les deux routeurs doivent s'accorder sur le temps de maintien, sinon il n'y aura pas de session BGP.

Identifiant BGP: c'est l'ID local du routeur BGP qui est élu de la même manière que l'OSPF :

Utilisez l'ID de routeur qui a été configuré manuellement avec la commande bgp router-id.

Utilisez l'adresse IP la plus élevée sur une interface de boucle.

Utilisez l'adresse IP la plus élevée sur une interface physique.

Paramètres optionnels: ici, vous trouverez certaines capacités optionnelles du routeur BGP. Ce champ a été ajouté afin que de nouvelles fonctionnalités puissent être intégrées au BGP sans avoir à créer une nouvelle version. Vous y trouverez notamment :

prise en charge de MP-BGP (Multi Protocol BGP).

prise en charge du Route Refresh.

prise en charge des numéros AS à 4 octets.

Pour établir le voisinage, les conditions suivantes doivent être remplies :

Numéro de version. La version actuelle est 4.
Le numéro AS doit correspondre à celui que vous avez configuré. neighbor 192.168.13.3 remote-as 10.
L'ID du routeur doit être différent de celui du voisin.

Si l'un des paramètres ne satisfait pas ces conditions, le routeur enverra Notification un message indiquant l'erreur. Après l'envoi et la réception des messages Open, la relation de voisinage passe à l'état ESTABLISHED. À partir de ce moment, les routeurs peuvent échanger des informations sur les routes, ce qu'ils font par le biais de Mise à jour messages. Voici un message Update que Router1 envoie à Router3 :

Ici, on indique les réseaux dont Router1 informe et les attributs de chemin, qui sont l'équivalent des métriques. Nous allons parler des attributs de chemin plus en détail. De plus, à l'intérieur de la session TCP, des messages Keepalive sont échangés. Ceux-ci sont envoyés, par défaut, toutes les 60 secondes. C'est le Keepalive Timer. Si aucun message Keepalive n'est reçu au cours du Hold Timer, cela signifiera une perte de connexion avec le voisin. Par défaut, il est de 180 secondes.

Tableau utile :

Nous avons compris comment les routeurs échangent des informations entre eux, maintenant essayons de comprendre la logique de fonctionnement du protocole BGP.

Pour annoncer un itinéraire dans la table BGP, comme dans les protocoles IGP, on utilise la commande network, mais la logique de fonctionnement diffère. Dans l'IGP, après avoir précisé l'itinéraire dans la commande network, l'IGP vérifie quels interfaces appartiennent à ce sous-réseau et les inclut dans sa table, alors que la commande network dans BGP vérifie la table de routage et recherche une correspondance exacte avec l'itinéraire dans la commande network. Lorsqu'une telle correspondance est trouvée, ces itinéraires seront ajoutés à la table BGP.

Recherchez un itinéraire dans la table de routage IP actuelle du routeur qui correspond exactement aux paramètres de la commande network ; si la route IP existe, mettez l'équivalent NLRI dans la table BGP locale.

Maintenant, élevons BGP sur tous les autres et voyons comment se fait le choix de l'itinéraire à l'intérieur d'un même AS. Une fois que le routeur BGP reçoit des itinéraires de son voisin, le choix de l'itinéraire optimal commence. Ici, il faut comprendre quel type de voisins il peut y avoir — internes et externes. Le routeur, selon la configuration, comprend si le voisin configuré est interne ou externe ? Si dans la commande :

neighbor 192.168.13.3 remote-as 10

Le paramètre remote-as spécifie l'AS configuré sur le routeur dans la commande router bgp 10. Les routes provenant d'un AS interne sont considérées comme internes, tandis que celles provenant d'un AS externe le sont comme externes. Une logique différente s'applique pour chaque type de route lors de leur réception et de leur envoi. Considérons la topologie suivante :

Un interface loopback est configuré sur chaque routeur avec l'ip : x.x.x.x 255.255.255.0 — où x est le numéro du routeur. Sur le Router9, nous avons un interface loopback avec l'adresse — 9.9.9.9 255.255.255.0. Nous allons l'annoncer via BGP et observer comment il se propage. Cette route sera transmise au Router8 et au Router12. Depuis le Router8, cette route atteindra le Router6, mais elle ne sera pas présente dans la table de routage du Router5. De même, sur le Router12, cette route apparaîtra dans la table, mais elle sera également absente sur le Router11. Tentons de comprendre cela. Examinons quelles données et paramètres Router9 transmet à ses voisins pour informer sur cette route. Le paquet ci-dessous sera envoyé du Router9 au Router8.

Les informations sur la route sont constituées d'attributs de chemin (Path attributes).

Les attributs de chemin sont classés en 4 catégories :

Très connus et obligatoires — tous les routeurs fonctionnant selon le protocole BGP doivent reconnaître ces attributs. Ils doivent être présents dans toutes les mises à jour (update).
Très connus et discrétionnaires — tous les routeurs fonctionnant selon le protocole BGP doivent reconnaître ces attributs. Ils peuvent être présents dans les mises à jour (update), mais leur présence n'est pas obligatoire.
Optionnels transitifs — ils peuvent ne pas être reconnus par toutes les implémentations de BGP. Si un routeur ne reconnaît pas un attribut, il marque la mise à jour comme partielle (partial) et la transmet à ses voisins, tout en conservant l'attribut non reconnu.
Optionnels non transitifs — ils peuvent ne pas être reconnus par toutes les implémentations de BGP. Si un routeur ne reconnaît pas un attribut, cet attribut est ignoré et est écarté lors de sa transmission aux voisins.

Exemples d'attributs BGP :

Très connus et obligatoires:
- Chemin de système autonome
- Prochain saut
- Origin
Très connus et discrétionnaires:
- Préférence locale
- Agrégat atomique
Optionnels transitifs:
- Agrégateur
- Communautés
Optionnels non transitifs:
- Discriminateur multi-sortie (MED)
- ID d'origine
- Liste de clusters

Dans ce cas, nous nous intéresserons surtout à Origin, Next-hop, AS Path. Étant donné que la route se transmet entre Router8 et Router9, c'est-à-dire à l'intérieur d'un même AS, elle est considérée comme interne et nous prêterons attention à Origin.

L'attribut Origin indique comment la route a été obtenue dans la mise à jour. Les valeurs possibles de l'attribut sont :

0 — IGP : NLRI obtenue à l'intérieur du système autonome d'origine;
1 — EGP : La NLRI a été apprise par le protocole Exterior Gateway Protocol (EGP). Ancêtre de BGP, il n'est plus utilisé.
2 — Incomplet : La NLRI a été apprise d'une autre manière.

Dans notre cas, comme on le voit, la valeur est 0. Lorsque ce chemin sera transféré à Router12, ce code sera 1.

Ensuite, Next-hop. L'attribut Next-hop.

C'est l'adresse IP du routeur eBGP à travers lequel le chemin mène au réseau de destination.
L'attribut change lorsqu'un préfixe est transféré vers une autre AS.

Dans le cas d'iBGP, c'est-à-dire au sein d'une même AS, le Next-hop sera celui qui a appris ou a informé sur ce chemin. Dans notre cas, ce sera 192.168.89.9. Mais lorsqu'il transfère ce chemin de Router8 à Router6, Router8 le changera et le remplacera par le sien. Le Next-hop sera donc 192.168.68.8. Cela nous conduit à deux règles :

Si un routeur transfère un chemin à son voisin interne, il ne modifie pas le paramètre Next-hop.
Si un routeur transfère un chemin à son voisin externe, il change le Next-hop pour l'IP de l'interface à partir de laquelle ce routeur effectue le transfert.

Cela nous amène à comprendre le premier problème — Pourquoi il n'y aura pas de chemin dans la table de routage sur Router5 et Router11. Examinons cela de plus près. Donc, Router6 a reçu des informations sur le chemin 9.9.9.0/24 et l'a ajouté avec succès à sa table de routage :

Router6#show ip route bgp
Codes : L - local, C - connecté, S - statique, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP externe, O - OSPF, IA - OSPF inter zone
       N1 - OSPF NSSA externe de type 1, N2 - OSPF NSSA externe de type 2
       E1 - OSPF externe de type 1, E2 - OSPF externe de type 2
       i - IS-IS, su - résumé IS-IS, L1 - IS-IS niveau-1, L2 - IS-IS niveau-2
       ia - OSPF inter zone, * - route par défaut candidate, U - route statique par utilisateur
       o - ODR, P - route statique téléchargée périodiquement, H - NHRP, l - LISP
       a - route d'application
       + - route répliquée, % - remplacement de prochain saut, p - remplacements de PfR

La passerelle de dernier recours n'est pas définie

      9.0.0.0/24 est sous-réseauté, 1 sous-réseau
B        9.9.9.0 [20/0] via 192.168.68.8, 00:38:25<source>
Maintenant, Router6 a transmis la route à Router5 et la première règle Next-hop n'a pas été modifiée. Autrement dit, Router5 doit ajouter  <b>9.9.9.0 [20/0] via 192.168.68.8</b> , mais il n'a pas de route vers 192.168.68.8 et donc cette route ne sera pas ajoutée, bien que l'information sur cette route soit conservée dans la table BGP :

<source><b>Router5#show ip bgp
La version de la table BGP est 1, l'ID du routeur local est 5.5.5.5
Codes d'état : s supprimé, d amorti, h historique, * valide, &gt; meilleur, i - interne,
              r échec RIB, S obsolète, m multipath, b chemin de secours, f RT-Filter,
              x meilleur-externe, a chemin additionnel, c RIB-compressé,
Codes d'origine : i - IGP, e - EGP, ? - incomplet
Codes de validation RPKI : V valide, I invalide, N Non trouvé

     Réseau          Prochain Saut            Métier LocPrf Poids Chemin
 * i 9.9.9.0/24       192.168.68.8             0    100      0 45 i</b>

La même situation se produira entre Router11 et Router12. Pour éviter cela, il est nécessaire de configurer Router6 ou Router12, lors du transfert du chemin à leurs voisins internes, pour qu'ils définissent leur adresse IP comme Next-hop. Cela se fait en utilisant la commande :

neighbor 192.168.56.5 next-hop-self

Après cette commande, Router6 enverra un message de mise à jour où, pour les chemins, l'adresse IP de l'interface Gi0/0 de Router6 — 192.168.56.6 — sera spécifiée en tant que Next-hop, après quoi ce chemin sera ajouté à la table de routage.

Allons plus loin et voyons si ce chemin apparaît sur Router7 et Router10. Il ne sera pas présent dans la table de routage et nous pourrions penser que le problème réside dans le premier cas avec le paramètre Next-hop, mais si nous regardons la sortie de la commande show ip bgp, nous verrons que le chemin n'a pas été reçu même avec un Next-hop incorrect, ce qui signifie que le chemin n'a même pas été transféré. Cela nous amène à un autre principe :

Les chemins reçus des voisins internes ne sont pas transférés à d'autres voisins internes.

Puisque Router5 a reçu un itinéraire de Router6, il ne sera pas transmis à son autre voisin interne. Pour que la transmission ait lieu, il est nécessaire de configurer la fonction Route Reflector, ou de configurer des relations de voisinage entièrement connectées (Full Mesh), c'est-à-dire que Router5-7 seront voisins les uns des autres. Nous allons utiliser Route Reflector dans ce cas. Sur Router5, il est nécessaire d'utiliser cette commande :

neighbor 192.168.57.7 route-reflector-client

Le Route Reflector modifie le comportement du BGP lors de la transmission de l'itinéraire à un voisin interne. Si le voisin interne est indiqué comme route-reflector-client, alors ces clients se verront annoncer les itinéraires internes.

L'itinéraire n'est pas apparu sur Router7 ? N'oublions pas aussi le Next-hop. Après ces manipulations, l'itinéraire devrait être sur Router7, mais ce n'est pas le cas. Cela nous conduit à une autre règle :

La règle next-hop ne s'applique qu'aux itinéraires externes. Pour les itinéraires internes, le remplacement de l'attribut next-hop ne se produit pas.

Nous nous retrouvons donc dans une situation où il est nécessaire de créer un environnement à l'aide de la routage statique ou des protocoles IGP pour informer les routeurs de tous les itinéraires au sein de l'AS. Nous allons définir des itinéraires statiques sur Router6 et Router7, puis obtenir l'itinéraire souhaité dans la table du routeur. Dans l'AS 678, nous procéderons un peu différemment : nous définirons des itinéraires statiques pour 192.168.112.0/24 sur Router10 et 192.168.110.0/24 sur Router12. Ensuite, nous établirons des relations de voisinage entre Router10 et Router12. Nous configurerons également Router12 pour qu'il envoie son next-hop à Router10 :

neighbor 192.168.110.10 next-hop-self

En conséquence, Router10 recevra l'itinéraire 9.9.9.0/24, qui sera obtenu à la fois de Router7 et de Router12. Voyons quel choix fera Router10 :

Router10#show ip bgp
La version de la table BGP est 3, l'ID du routeur local est 6.6.6.6
Codes d'état : s supprimé, d amorti, h historique, * valide, > meilleur, i - interne,
              r échec RIB, S Obsolète, m multipath, b chemin de secours, f RT-Filter,
              x meilleur-externe, a chemin additionnel, c RIB-compressé,
Codes d'origine : i - IGP, e - EGP, ? - incomplet
Codes de validation RPKI : V valide, I invalide, N Non trouvé

     Réseau              Prochain saut            Métrique LocPrf Poids Chemin
 * > i 9.9.9.0/24       192.168.112.12           0    100       0      45 i

                               192.168.107.7                                0     123 45 i

Comme nous le voyons, deux itinéraires et la flèche ( > ) indiquent que l'itinéraire sélectionné passe par 192.168.112.12.
Examinons comment se déroule le processus de sélection d'itinéraire :

Tout d'abord, lors de la réception de l'itinéraire, la disponibilité de son Next-hop est vérifiée. C'est pourquoi, lorsque nous avons reçu l'itinéraire sur Router5 sans configuration de Next-hop-self, cet itinéraire n'a pas été transmis pour traitement.
Le paramètre suivant est le poids. Ce paramètre n'est pas un attribut de chemin (PA) et n'est pas transmis dans les messages BGP. Il est configuré localement sur chaque routeur et est utilisé uniquement pour manipuler le choix de route sur le routeur lui-même. Prenons un exemple. Plus haut, nous avons montré que Router10 a choisi le route vers 9.9.9.0/24 via Router12 (192.168.112.12). Pour modifier le paramètre de poids, vous pouvez utiliser un route-map pour définir certains itinéraires, ou attribuer un poids à un voisin à l'aide de la commande :
```
 neighbor 192.168.107.7 weight 200       
```
Maintenant, tous les itinéraires de ce voisin auront ce poids. Voyons comment le choix de route changera après cette manipulation :
```
Router10#show bgp
*Mar  2 11:58:13.956: %SYS-5-CONFIG_I: Configuré depuis la console par console
La version de la table BGP est 2, l'ID du routeur local est 6.6.6.6
Codes d'état : s supprimé, d amorti, h historique, * valide, > meilleur, i - interne,
              r échec de RIB, S ancien, m multipath, b chemin de secours, f RT-Filter,
              x meilleur-externe, a chemin additionnel, c RIB-compressé,
Codes d'origine : i - IGP, e - EGP, ? - incomplet
Codes de validation RPKI : V valide, I invalide, N Non trouvé

     Réseau          Prochain Saut        Métrique LocPrf Poids      Chemin
 * >  9.9.9.0/24       192.168.107.7                        200      123 45 i
 * i                          192.168.112.12           0          100      0 45 i
```
Comme vous pouvez le voir, le chemin est maintenant choisi via Router7, mais cela n'aura aucun effet sur les autres routeurs.

En troisième position, nous avons — Local Preference. Ce paramètre est un attribut discrétionnaire bien connu, ce qui signifie que sa présence n'est pas obligatoire. Ce paramètre n'a d'effet que dans une seule AS et influence le choix de chemin uniquement pour les voisins internes. C'est pourquoi il n'est transmis que dans les messages Update destinés aux voisins internes. Dans les messages Update pour les voisins externes, il est absent. C'est pourquoi il a été classé comme bien connu et discrétionnaire. Essayons de l'appliquer sur Router5. Sur Router5, nous devrions avoir deux itinéraires pour 9.9.9.0/24 — un via Router6 et l'autre via Router7.

Regardons :

Router5#show bgp
La version de la table BGP est 2, l'ID du routeur local est 5.5.5.5
Codes d'état : s supprimé, d amorti, h historique, * valide, > meilleur, i - interne,
              r échec de RIB, S ancien, m multipath, b chemin de secours, f RT-Filter,
              x meilleur-externe, a chemin additionnel, c RIB-compressé,
Codes d'origine : i - IGP, e - EGP, ? - incomplet
Codes de validation RPKI : V valide, I invalide, N Non trouvé

     Réseau          Prochain Saut        Métrique LocPrf Poids Chemin
 * > i 9.9.9.0/24       192.168.56.6             0    100      0 45 i

Mais comme nous le voyons, il y a un itinéraire via Router6. Où est donc l'itinéraire via Router7 ? Peut-être qu'il n'est pas non plus sur Router7 ? Regardons :

Route#show bgp
La version de la table BGP est 10, l'ID du routeur local est 7.7.7.7
Codes d'état : s supprimé, d atténué, h historique, * valide, > meilleur, i - interne,
              r échec RIB, S Obsolète, m multipath, b chemin de secours, f RT-Filtre,
              x meilleur-externe, a chemin additionnel, c RIB-comprimé,
Codes d'origine : i - IGP, e - EGP, ? - incomplet
Codes de validation RPKI : V valide, I invalide, N Non trouvé

     Réseau                Prochain Saute            Métrique LocPrf  Poids    Chemin
 *>i 9.9.9.0/24       192.168.56.6             0     100           0      45 i

                              192.168.107.10                                  0     678 45 i

C'est étrange, tout semble en ordre. Pourquoi ne le transmet-il pas à Router5 ? Tout est dû à une règle de BGP :

Le routeur ne transmet que les routes qu'il utilise lui-même.

Router7 utilise la route via Router5, donc la route via Router10 ne sera pas transmise. Revenons à la Préférence Locale. Définissons la Préférence Locale sur Router7 et voyons comment Router5 réagira :

route-map BGP autoriser 10
 correspondre à l'adresse IP 10
 définir la préférence locale 250
liste d'accès 10 autoriser tout
routeur BGP 123
 voisin 192.168.107.10 route-map BGP dans</b>

Ainsi, nous avons créé une route-map, dans laquelle toutes les routes sont sélectionnées et avons demandé à Router7, lors de la réception, de modifier le paramètre de Préférence Locale à 250, par défaut 100. Regardons ce qui s'est passé sur Router5 :

Router5#show bgp
La version de la table BGP est 8, l'ID du routeur local est 5.5.5.5
Codes d'état : s supprimé, d atténué, h historique, * valide, > meilleur, i - interne,
              r échec RIB, S Obsolète, m multipath, b chemin de secours, f RT-Filtre,
              x meilleur-externe, a chemin additionnel, c RIB-comprimé,
Codes d'origine : i - IGP, e - EGP, ? - incomplet
Codes de validation RPKI : V valide, I invalide, N Non trouvé

     Réseau          Prochain Saute            Métrique LocPrf Poids        Chemin
 *>i 9.9.9.0/24       192.168.57.7             0          250      0 678 45 i

Comme nous le voyons maintenant, Router5 préfère la route via Router7. Le même phénomène se produira sur Router6, même s'il lui serait plus avantageux de choisir la route via Router8. Ajoutons également que la modification de ce paramètre nécessite un redémarrage de la voisine pour que le changement prenne effet. Lire ici. Nous avons compris la Préférence Locale. Passons au prochain paramètre.

Préférence de route avec le paramètre Next-hop 0.0.0.0, c'est-à-dire des routes locales ou agrégées. À ces routes, le paramètre Poids est automatiquement attribué après l'entrée de la commande network, égal au maximum — 32678 :

Router#show bgp
La version de la table BGP est 2, l'ID du routeur local est 9.9.9.9
Codes d'état : s supprimé, d atténué, h historique, * valide, > meilleur, i - interne,
              r échec RIB, S Obsolète, m multipath, b chemin de secours, f RT-Filtre,
              x meilleur-externe, a chemin additionnel, c RIB-comprimé,
Codes d'origine : i - IGP, e - EGP, ? - incomplet
Codes de validation RPKI : V valide, I invalide, N Non trouvé

     Réseau          Prochain Saute            Métrique LocPrf Poids    Chemin
 *>  9.9.9.0/24       0.0.0.0                  0            32768    i

Le chemin le plus court via AS. Le paramètre AS_Path le plus court est sélectionné. Plus le nombre d'AS traversés par la route est faible, meilleur est le chemin. Examinons la route vers 9.9.9.0/24 sur Router10 :

Routeur10#show bgp
La version de la table BGP est 2, l'ID du routeur local est 6.6.6.6
Codes d'état : s supprimé, d étouffé, h historique, * valide, > meilleur, i - interne,
              r échec RIB, S obsolète, m multipath, b chemin de secours, f RT-Filter,
              x meilleur-externe, a chemin-additionnel, c RIB-comprimé,
Codes d'origine : i - IGP, e - EGP, ? - incomplet
Codes de validation RPKI : V valide, I invalide, N non trouvé

     Réseau          Prochain saut            Métrique LocPrf Poids Chemin
 *   9.9.9.0/24     192.168.107.7                           0           123 45 i
 *>i                     192.168.112.12           0    100       0       45 i

Comme vous pouvez le voir, le routeur 10 a choisi le chemin via 192.168.112.12 parce que pour ce chemin, le paramètre AS_Path ne contient que 45, tandis que dans l'autre cas, il contient 123 et 45. C'est donc intuitif.

Le paramètre suivant est l'origine. IGP (chemin obtenu par BGP) est préférable à EGP (chemin obtenu par un prédécesseur BGP, qui n'est plus utilisé), et EGP est préférable à Incomplet ? (obtenu par une autre méthode, par exemple la redistribution).
Le paramètre suivant est le MED. Nous avons eu le Weight, qui ne fonctionnait qu'au niveau local sur le routeur. Il y avait la Local Preference, qui fonctionnait uniquement au sein d'un système autonome. Comme vous pouvez le deviner, le MED est le paramètre qui sera transmis entre les systèmes autonomes. C'est très bon. article à propos de ce paramètre.

Aucun autre attribut ne sera utilisé, mais si deux chemins ont les mêmes attributs, on utilise les règles suivantes :

Choisissez le chemin passant par le voisin IGP le plus proche.
Choisissez le chemin le plus ancien pour le chemin eBGP.
Choisissez le chemin passant par le voisin avec le plus petit ID de routeur BGP.
Choisissez le chemin passant par le voisin avec la plus petite adresse IP.

Examinons maintenant la question de la convergence BGP.

Voyons ce qui se passe si par exemple le routeur 6 perd le chemin 9.9.9.0/24 via le routeur 9. Désactivons l'interface Gi0/1 du routeur 6, qui comprendra tout de suite que la session BGP avec le routeur 8 a été rompue et que le voisin est parti, ce qui signifie que le chemin, obtenu de lui, n'est plus valide. Le routeur 6 envoie immédiatement des messages de mise à jour, indiquant le réseau 9.9.9.0/24 dans le champ des Chemins Retirés. Dès que le routeur 5 reçoit un tel message, il l'envoie au routeur 7. Mais comme le routeur 7 a un chemin via le routeur 10, il enverra immédiatement une mise à jour avec le nouveau chemin en réponse. Si la détection de la chute du voisin par l'état de l'interface échoue, il faudra attendre le déclenchement du Hold Timer.

Confédération.

Si vous vous en souvenez, nous avons parlé de l'utilisation fréquente de la topologie pleinement connectée. Avec un grand nombre de routeurs dans un même AS, cela peut poser de gros problèmes, pour éviter cela, il est nécessaire d'utiliser des confédérations. Un AS est divisé en plusieurs sub-AS, ce qui permet à chacun de fonctionner sans nécessiter une topologie pleinement connectée.

Voici le lien vers cette lab., et ici configuration pour GNS3.

Par exemple, avec une telle topologie, nous aurions dû lier tous les routeurs dans l'AS 2345 entre eux, mais en utilisant la confédération, nous pouvons établir des relations de voisinage uniquement entre les routeurs qui sont directement connectés les uns aux autres. Discutons-en en détail. Si nous avions uniquement l'AS 2345, alors laForge aurait informé les routeurs de Picard à propos de son chemin Données et Worf, mais ils n'auraient pas informé le routeur Crusher . De plus, les routes que le routeur lui-même laForgepropage, ne seraient pas transmises Crusher ni Worfpar lui, ni Données.

Il aurait fallu configurer un Route-Reflector ou des relations de voisinage pleinement connectées. En divisant l'AS 2345 en 4 sub-AS (2, 3, 4, 5) pour chaque routeur, nous obtenons finalement une autre logique de fonctionnement. Tout est très bien décrit ici.

Sources :

CCIE Routing and Switching v5.0 Official Cert Guide, Volume 2, Fifth Edition, Narbik Kocharians, Terry Vinson.
Site xgu.ru
Site GNS3Vault.

Source : habr.com

Les principes de fonctionnement du protocole BGP