Le protocole BGP

Précédemment, nous avons étudié le routage dynamique interne, notamment OSPF. Ces protocoles de routage nécessitaient la connaissance complète de la topologie du réseau pour fonctionner efficacement. Cependant, gérer les millions de routes nécessaires au fonctionnement d’Internet avec ces méthodes s’avère complexe. Pour cette raison, un protocole différent est adopté pour le routage externe, plus adapté à ces exigences : le BGP.

Le routage interne, géré par des protocoles comme OSPF, s’occupe de la distribution de l’information de routage au sein d’un même système autonome. Ce processus est fondamental pour garder le réseau interne efficace. En revanche, le routage externe s’attaque à une problématique différente : comment router efficacement les paquets entre des systèmes autonomes distincts. Cette distinction est importante la gestion de réseaux à grande échelle, comme ceux des FAI.

BGP entre en jeu précisément dans ce contexte de routage externe. Contrairement à OSPF, BGP ne se base pas sur la connaissance de la topologie complète du réseau pour prendre des décisions de routage. Son rôle principal est l’annonce de routes entre systèmes autonomes différents. Ces annonces permettent à chaque AS de connaître les chemins disponibles pour atteindre des réseaux distants. BGP fonctionne sur le principe de la collaboration entre les AS : chaque AS annonce les préfixes IP qu’il peut atteindre, ainsi que les attributs de ces routes, permettant ainsi aux autres AS de prendre des décisions de routage informées.

Cette approche collaborative diffère radicalement de celle des protocoles de routage interne. BGP ne génère pas de routes par lui-même, mais transmet des informations sur les routes disponibles, laissant aux AS la responsabilité de choisir les chemins les plus appropriés selon leurs politiques de routage et leurs accords inter-AS. Cette méthode de routage est fondamentale pour gérer l’énorme et complexe réseau d’Internet, où des milliers de systèmes autonomes doivent communiquer efficacement tout en préservant leur autonomie opérationnelle et leur flexibilité dans la gestion du trafic.

L’établissement d’une session

Le principe de négociation des sessions dans le contexte du protocole BGP est un aspect indispensable de son fonctionnement. La négociation de session est intrinsèquement liée sa nature collaborative. BGP est conçu pour faciliter la négociation de routage entre deux entreprises distinctes, chacune gérant son propre système autonome. Cette négociation implique une série d’étapes coordonnées entre les administrateurs réseau de chaque entreprise pour réussir à établir un lien BGP.

Lorsqu’un administrateur réseau souhaite établir un lien BGP avec un autre AS, il doit d’abord configurer son routeur pour annoncer et accepter des routes spécifiques. Cette configuration comprend la définition des politiques de routage, des préfixes à annoncer, et des paramètres de sécurité, tels que les filtres de routage et les listes de contrôle d’accès. Ces politiques peuvent être influencées par divers facteurs, tels que les accords commerciaux, les considérations de sécurité, et les exigences de performance du réseau.

Pour que le lien BGP soit établi, les configurations de chaque côté doivent être compatibles et satisfaisantes pour les deux parties. Cela signifie que les deux administrateurs réseau doivent se mettre d’accord sur un ensemble de politiques et de paramètres techniques. Cette négociation peut nécessiter plusieurs itérations de configuration et de test pour assurer que les routes annoncées et acceptées répondent aux attentes de performance, de sécurité et de fiabilité des deux AS.

Une fois que les deux routeurs sont configurés et que les politiques de routage sont en place, une session BGP peut être établie. Cette session permet l’échange d’informations de routage entre les deux entreprises, permettant ainsi à chaque AS de mettre à jour ses tables de routage avec les chemins les plus efficaces vers les réseaux gérés par l’autre AS.

Router(config)# router bgp 100
Router(config-router)# neighbor 10.0.0.2 remote-as 200