5.1. Choosing EBGP as the Routing Protocol (Choisir EBGP comme protocole de routage)

5.1. Choosing EBGP as the Routing Protocol (Choisir EBGP comme protocole de routage)

REQ2 donnerait la préférence à la sélection d'un protocole de routage unique pour réduire la complexité et les interdépendances. Bien qu'il soit courant de s'appuyer sur un IGP dans cette situation, parfois avec l'ajout d'EBGP au niveau du dispositif bordant le WAN ou d'Internal BGP (IBGP) dans l'ensemble, ce document propose l'utilisation d'une conception EBGP uniquement.

Bien qu'EBGP soit le protocole utilisé pour presque tout le routage inter-domaines sur Internet et bénéficie d'un large soutien de la part des communautés de fournisseurs et de fournisseurs de services, il n'est généralement pas déployé comme protocole de routage principal dans le centre de données pour plusieurs raisons (dont certaines sont interdépendantes):

• BGP est perçu comme un "protocole uniquement pour WAN" et n'est pas souvent considéré pour les applications d'entreprise ou de centre de données.

• On pense que BGP a une convergence de routage "beaucoup plus lente" par rapport aux IGP.

• Les déploiements BGP à grande échelle utilisent généralement un IGP pour la résolution du prochain saut BGP car tous les nœuds de la topologie IBGP ne sont pas directement connectés.

• BGP est perçu comme nécessitant un overhead de configuration important et ne prend pas en charge la découverte automatique des voisins.

Ce document discute de certaines de ces perceptions, en particulier dans le cadre de la conception proposée, et met en évidence certains des avantages de l'utilisation du protocole tels que:

• BGP a moins de complexité dans certaines parties de sa conception de protocole -- les structures de données internes et la machine d'état sont plus simples par rapport à la plupart des IGP à état de liens tels que OSPF. Par exemple, au lieu d'implémenter la formation d'adjacence, la maintenance d'adjacence et/ou le contrôle de flux, BGP s'appuie simplement sur TCP comme transport sous-jacent. Cela remplit REQ2 et REQ3.

• L'overhead d'inondation des informations BGP est moindre par rapport aux IGP à état de liens. Étant donné que chaque routeur BGP calcule et propage uniquement le meilleur chemin sélectionné, une défaillance du réseau est masquée dès que le locuteur BGP trouve un chemin alternatif, qui existe lorsque des topologies hautement symétriques, telles que Clos, sont couplées à une conception EBGP uniquement. En revanche, la portée de propagation d'événements d'un IGP à état de liens est une zone entière, quel que soit le type de défaillance. De cette manière, BGP répond mieux à REQ3 et REQ4. Il convient également de mentionner que tous les IGP à état de liens largement déployés comportent des rafraîchissements périodiques des informations de routage alors que BGP n'expire pas l'état de routage, bien que cela affecte rarement les plans de contrôle des routeurs modernes.

• BGP prend en charge les prochains sauts tiers (résolus récursivement). Cela permet de manipuler le multichemin pour être basé sur des chemins non ECMP ou de transfert basé sur des chemins définis par l'application, par l'établissement d'une session de peering avec un "contrôleur" d'application qui peut injecter des informations de routage dans le système, satisfaisant REQ5. OSPF fournit une fonctionnalité similaire en utilisant des concepts tels que "Forwarding Address", mais avec plus de difficulté dans l'implémentation et beaucoup moins de contrôle de la portée de propagation de l'information.

• En utilisant un schéma d'allocation d'Autonomous System Number (ASN) bien défini et la détection de boucle AS_PATH standard, la "chasse au chemin BGP" (voir [JAKMA2008]) peut être contrôlée et les chemins complexes indésirables seront ignorés. Voir la section 5.2 pour un exemple de schéma d'allocation ASN fonctionnel. Dans un IGP à état de liens, atteindre le même objectif nécessiterait un support multi-(instance/topologie/processus), généralement non disponible dans tous les dispositifs DC et assez complexe à configurer et à dépanner. L'utilisation d'un domaine d'inondation unique traditionnel, que la plupart des conceptions DC utilisent, peut dans certaines conditions de défaillance choisir des chemins longs indésirables, par exemple en traversant plusieurs dispositifs de Tier 2.

• La configuration EBGP qui est implémentée avec une politique de routage minimale est plus facile à dépanner pour les problèmes de joignabilité réseau. Dans la plupart des implémentations, il est simple de visualiser le contenu du BGP Loc-RIB et de le comparer à la Routing Information Base (RIB) du routeur. De plus, dans la plupart des implémentations, un opérateur peut visualiser les structures Adj-RIB-In et Adj-RIB-Out de chaque voisin BGP, et donc les informations de Network Layer Reachability Information (NLRI) entrantes et sortantes peuvent être facilement corrélées des deux côtés d'une session BGP. Ainsi, BGP satisfait REQ3.