Ethernet Switching BGP Oreilly

Traduit de Anglais vers Français - www.onlinedoctranslator.
com
Mise en réseau à l'échelle du Web
vers le cloud d'entreprise
NetQ
Applications tierces Applications Cumulus
Application Application Application
Système d'exploitation réseau

Cumulus Linux
Matériel ouvert
VS
Verrouillé, propriétaire
systèmes
Choix du client
Évolutivité économique
Conçu pour l'ère de l'automatisation
Ensembles d'outils standardisés
Choix et flexibilité
En savoir plus sur

cumulusnetworks.com/oreilly
BGP dans le centre de données
Dinesh G. Dutt
Pékin Boston Farnham Sébastopol Tokyo

BGP dans le centre de données
par Dinesh G. Dutt
Copyright © 2017 O'Reilly Media, Inc.. Tous droits réservés.
Imprimé aux États-Unis d'Amérique.
Publié par O'Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA
95472.
Les livres O'Reilly peuvent être achetés à des fins éducatives, commerciales ou promotionnelles. Des
éditions en ligne sont également disponibles pour la plupart des titres (http://oreilly.com/safari). Pour
plus d'informations, contactez notre service commercial corporatif/institutionnel : 800-998-9938 ou
corporate@oreilly.com.
Éditeurs : Courtney Allen et Décorateur d'intérieur: David Futato

Virginie Wilson Concepteur de couverture : Karen Montgomery
Éditeur de production : Kristen Brown Illustrateur : Rébecca Demarest

Éditeur de copie: Éditions Octal, Inc.
Juin 2017 : Première édition
Historique des révisions pour la première édition
2017-06-19 : Première version
Le logo O'Reilly est une marque déposée de O'Reilly Media, Inc. BGP dans le Data Center, l'image de
couverture et l'habillage commercial associé sont des marques déposées d'O'Reilly Media, Inc.
Bien que l'éditeur et l'auteur aient déployé des efforts de bonne foi pour s'assurer que les
informations et les instructions contenues dans cet ouvrage sont exactes, l'éditeur et l'auteur
déclinent toute responsabilité pour les erreurs ou omissions, y compris, sans limitation, la
responsabilité des dommages résultant de l'utilisation. ou la confiance accordée à ce travail.
L'utilisation des informations et des instructions contenues dans ce travail est à vos risques et périls.
Si des échantillons de code ou toute autre technologie que ce travail contient ou décrit sont soumis à
des licences open source ou aux droits de propriété intellectuelle d'autrui, il est de votre
responsabilité de vous assurer que votre utilisation de ceux-ci est conforme à ces licences et/ou droits.
978-1-491-98338-6
[LSI]
Table des matières
Préface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
1. Introduction aux réseaux de centres de données. . . . . . . . . . . . . . . . . . . . . . . . . . 1

Exigences d'un réseau de centre de données 2
Topologie du réseau Clos 4
Architecture réseau de Clos Networks 8
Modèles de connexion au serveur 10
Connectivité au monde extérieur 11
Prise en charge de l'architecture mutualisée (ou Cloud) 12
Conséquences opérationnelles de la conception de datacenters modernes 13
Choix du protocole de routage 14
2. Comment BGP a été adapté au centre de données. . . . . . . . . . . . . . . . . 15

Combien de protocoles de routage ? 16
BGP interne ou BGP externe 16
Numérotation ASN 17
Meilleur algorithme de chemin 21
Sélection de trajets multiples 22
Convergence lente due aux temporisateurs par défaut 24
Configuration par défaut du centre de données 25
Résumé 26
3. Construire une configuration BGP automatisable. . . . . . . . . . . . . . . . . . . 27

Les bases de l'automatisation de la configuration 27
Exemple de réseau de centre de données 28
Les difficultés de l'automatisation du BGP traditionnel 29
Redistribuer les itinéraires 34
v
Politique de routage 36
Utilisation des noms d'interface 42
comme voisins 45
4. Réinventer la configuration BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Le besoin d'adresses IP d'interface et à distance comme 48
Les nombres sur les interfaces numérotées 48
Interfaces non numérotées 50
BGP non numéroté 50
Une télécommande-comme par tout autre nom 58
Résumé 59
5. Gestion du cycle de vie BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Commandes show utiles 61
Se connecter au monde extérieur 66
Planification de la maintenance des nœuds 68
Débogage BGP 69
Résumé 71
6. BGP sur l'hôte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

L'essor des services virtuels 73
Modèles BGP pour l'appairage avec des serveurs 75
Logiciel de routage pour hôtes 79
Résumé 80
vi | Table des matières

Préface
Ce petit livret est le résultat des questions que j'ai fréquemment rencontrées
dans mon engagement avec divers clients, petits et grands, dans leur
parcours pour construire un centre de données moderne.
BGP dans le centre de données est une bête plutôt étrange, un peu comme le
titre de cette chanson de Sting, "An Englishman in New York". Alors que son
entrée dans le datacenter était plutôt inattendue, il s'est rapidement imposé
comme le protocole de routage de choix dans les déploiements de datacenter.
Étant donné la portée limitée d'un livret comme celui-ci, les objectifs du livre et
les hypothèses concernant le public sont essentiels. Le livre est conçu pour les
opérateurs de réseau et les ingénieurs qui maîtrisent la mise en réseau et les
rudiments de base de BGP, et qui souhaitent comprendre comment déployer
BGP dans le centre de données. Je ne m'attends pas à une connaissance avancée
du fonctionnement de BGP ou à une expérience avec une plate-forme de routeur
spécifique.
L'objectif principal de ce livre est de rassembler en un seul endroit la théorie et la

pratique du déploiement de BGP dans le datacenter. Je couvre la conception et
les effets d'une topologie Clos sur les opérations de réseau avant de discuter de
la façon d'adapter BGP au centre de données. Deux chapitres suivent où nous
allons construire un exemple de configuration pour un réseau Clos à deux
niveaux. Le but de cette configuration est d'être simple et automatisable. Nous
innovons dans ces chapitres avec des idées telles que BGP sans numéro. Le livre
se termine par une discussion sur le déploiement de BGP sur des serveurs afin de
gérer la construction d'applications de microservices et de services de pare-feu
virtuel et d'équilibrage de charge. Bien que je ne couvre pas les manuels
d'automatisation réels dans ce livre, le logiciel d'accompagnement sur GitHub
fournira un réseau virtuel sur un ordinateur portable robuste avec lequel vous
pourrez jouer.
vii
Les personnes qui ont vraiment payé le prix, alors que je me chargeais de la
rédaction de ce livret ainsi que de ma myriade d'autres tâches, étaient ma
femme Shanthala et ma fille Maya. Merci. Et cela n'a été qu'un plaisir et un
privilège de travailler avec l'ingénierie de Cumulus Networks, en particulier
l'équipe de routage, pour développer et travailler sur des idées pour rendre
BGP plus simple à configurer et à gérer.
Logiciel utilisé dans ce livre

Il existe de nombreuses suites de routage disponibles aujourd'hui,
certaines propriétaires et d'autres open source. J'ai choisi l'open source
FRRoutage suite de routage comme base de mes exemples de configuration. Il met en
œuvre de nombreuses innovations abordées dans ce livre. Heureusement, son langage
de configuration imite celui de nombreuses autres suites de routage de fournisseurs
traditionnels, vous pouvez donc facilement traduire les extraits de configuration dans
d'autres implémentations.
Les exemples d'automatisation répertoriés sur la page GitHub tous utilisent Ansible et
Vagrant. Ansible est un outil d'automatisation de serveur open source populaire qui est
très populaire auprès des opérateurs de réseau en raison de son modèle simple et
sans programmation. Vagrant est un outil open source populaire utilisé pour faire
tourner des réseaux sur un ordinateur portable à l'aide d'images VM de logiciels de
routeur.
viii | Préface
CHAPITRE 1
Introduction au centre de données

Réseaux
Un réseau existe pour répondre aux exigences de connectivité des applications,

et les applications répondent aux besoins commerciaux de leur organisation. En
tant que concepteur ou opérateur de réseau, il est donc impératif de comprendre
d'abord les besoins du centre de données moderne et la topologie du réseau qui
a été adaptée pour les centres de données. C'est là que notre voyage commence.
Mon objectif est que vous compreniez, d'ici la fin du chapitre, la conception d'un
réseau de centres de données moderne, compte tenu des besoins des
applications et de l'ampleur de l'opération.
Les centres de données sont beaucoup plus grands qu'ils ne l'étaient il y a dix ans, avec
des exigences d'application très différentes de celles des applications client-serveur
traditionnelles, et avec des vitesses de déploiement de quelques secondes au lieu de
plusieurs jours. Cela change la façon dont les réseaux sont conçus et déployés.
Le protocole de routage le plus couramment utilisé à l'intérieur du centre de

données est le Border Gateway Protocol (BGP). BGP est connu depuis des
décennies pour aider les systèmes connectés à Internet du monde entier à se
trouver. Cependant, il est également utile dans un seul centre de données. BGP
est basé sur des normes et pris en charge par de nombreux packages logiciels
libres et open source.
Il est naturel de commencer le parcours du déploiement de BGP dans le centre de données

avec la conception de réseaux de centres de données modernes. Ce chapitre est une réponse
à des questions telles que les suivantes :
1
• Quels sont les objectifs d'une conception de réseau de centre de données
moderne ?
• En quoi ces objectifs sont-ils différents d'autres réseaux tels que

l'entreprise et le campus ?
• Pourquoi choisir BGP comme protocole de routage pour exécuter le centre de données ?
Exigences d'un réseau de centre de données

Les centres de données modernes ont évolué principalement à partir des
exigences des pionniers à l'échelle du Web tels que Google et Amazon. Les
applications créées par ces organisations, principalement la recherche et le
cloud, représentent la troisième vague d'architectures d'applications. Les
deux premières vagues ont été les applications monolithiques à machine
unique et l'architecture client-serveur qui a dominé le paysage à la fin du
siècle dernier.
Les trois principales caractéristiques de cette troisième vague de candidatures sont les
suivantes :
Communication accrue de serveur à serveur

Contrairement aux architectures client-serveur, les applications de centre de
données modernes impliquent de nombreuses communications de serveur à
serveur. Les architectures client-serveur impliquaient des clients communiquant
avec des serveurs assez monolithiques, qui soit traitaient la demande
entièrement par eux-mêmes, soit communiquaient à leur tour au plus avec une
poignée d'autres serveurs tels que les serveurs de base de données. En revanche,
une application telle que la recherche (ou son incarnation plus populaire,
Hadoop), peut utiliser des dizaines ou des centaines de nœuds mappeurs et des
dizaines de nœuds réducteurs. Dans un cloud, les machines virtuelles (VM) d'un
client peuvent résider sur le réseau sur plusieurs nœuds, mais doivent
communiquer de manière transparente. Les raisons en sont diverses, du
déploiement de machines virtuelles sur les serveurs les moins chargés à
l'augmentation de la charge du serveur, en passant par l'équilibrage de charge.
Une architecture de microservices est un autre exemple dans lequel la
communication de serveur à serveur est accrue. Dans cette architecture, une
seule fonction est décomposée en blocs de construction plus petits qui
communiquent entre eux pour obtenir le résultat final. La promesse d'une telle
architecture est que chaque bloc peut donc être utilisé dans plusieurs
applications, et chaque bloc peut être amélioré, modifié et corrigé plus facilement
et indépendamment de l'autre.
2 | Chapitre 1 : Introduction aux réseaux de centres de données

blocs. Les communications de serveur à serveur sont souvent appeléesTrafic
Est-Ouest, car les diagrammes représentent généralement des serveurs
côte à côte. En revanche, le trafic échangé entre les réseaux locaux et les
réseaux externes est appeléTrafic Nord-Sud.
Escalader
S'il y a une image qui évoque un centre de données moderne, c'est bien l'échelle :
des rangées sur des rangées de machines sombres, bourdonnantes et
clignotantes dans une vaste pièce. Au lieu de quelques centaines de serveurs qui
représentaient un grand réseau dans le passé, les centres de données modernes
vont de quelques centaines à cent mille serveurs dans un seul emplacement
physique. Combinées à une communication accrue de serveur à serveur, les
exigences de connectivité à de telles échelles obligent à repenser la façon dont
ces réseaux sont construits.
Résilience
Contrairement aux anciennes architectures qui reposaient sur un
réseau fiable, les applications de centre de données modernes sont
conçues pour fonctionner en présence de pannes. L'objectif premier est
de limiter au maximum l'effet d'une défaillance. En d'autres termes, le «
rayon d'explosion » d'une défaillance doit être contraint. L'objectif est
une expérience de l'utilisateur final qui n'est généralement pas affectée
par les pannes de réseau ou de serveur.
Tout réseau de centre de données moderne doit satisfaire à ces trois exigences
applicatives de base. Les réseaux multi-locataires tels que les clouds publics ou privés
ont une considération supplémentaire : le déploiement et le démontage rapides d'un
réseau virtuel. Compte tenu de la rapidité avec laquelle les machines virtuelles (et
désormais les conteneurs) peuvent démarrer et se désintégrer, et la facilité avec
laquelle un client peut créer un nouveau réseau privé dans le cloud, le besoin d'un
déploiement rapide devient évident.
La conception de réseau traditionnelle a été mise à l'échelle pour prendre en charge plus
d'appareils en déployant des commutateurs (et des routeurs) plus grands. C'est lemise à
l'échelle modèle de mise à l'échelle. Mais ces gros commutateurs sont chers et principalement
conçus pour ne prendre en charge qu'une redondance bidirectionnelle. Le logiciel qui pilote
ces grands commutateurs est complexe et donc sujet à plus de pannes que de simples
commutateurs à facteur de forme fixe. Et le modèle scale-in ne peut évoluer que jusqu'à
présent. Aucun interrupteur n'est trop gros pour tomber en panne. Ainsi, lorsque ces
commutateurs plus gros tombent en panne, leur rayon d'explosion est assez grand. Parce que
les échecs peuvent être perturbateurs, voire catastrophiques, le logiciel qui alimente ces
« boîtes à dieux » essaie de réduire les risques d'échec en ajoutant encore plus de complexité ;
ainsi ils deviennent de manière contre-productive plus sujettes à l'échec
Exigences d'un réseau de centres de données | 3

par conséquent. Et en raison de la complexité accrue des logiciels dans ces boîtiers, les
changements doivent être lents pour éviter d'introduire des bogues dans le matériel ou
le logiciel.
Rejetant ce paradigme si peu satisfaisant en termes de fiabilité et de coût,

les pionniers à l'échelle du Web ont choisi une topologie de réseau
différente pour construire leurs réseaux.
Topologie du réseau Clos

Les pionniers à l'échelle du Web ont choisi une topologie de réseau appelée Clos
pour façonner leurs centres de données. Les réseaux Clos portent le nom de leur
inventeur, Charles Clos, un ingénieur en réseau de téléphonie, qui, dans les
années 1950, tentait de résoudre un problème similaire à celui rencontré par les
pionniers du Web : comment faire face à la croissance explosive de la télé‐
réseaux téléphoniques. Ce qu'il a proposé, nous l'appelons maintenant la
topologie ou l'architecture du réseau Clos.
Figure 1-1 montre un réseau Clos dans sa forme la plus simple. Dans le schéma,
les nœuds verts représentent les commutateurs et les nœuds gris les serveurs.
Parmi les nœuds verts, ceux du haut sontnœuds de la colonne vertébrale,
et les plus bas sont nœuds foliaires. Les nœuds spine connectent les nœuds feuilles
entre eux, tandis que les nœuds feuilles sont la manière dont les serveurs se
connectent au réseau. Chaque feuille est connectée à chaque nœud de la colonne
vertébrale, et, évidemment, vice versa. C'est tout !
Figure 1-1. Un réseau Clos simple à deux niveaux
Examinons cette conception un peu plus en détail. La première chose à noter est
l'uniformité de la connectivité : les serveurs sont généralement à trois sauts de
réseau de tout autre serveur. Ensuite, les nœuds sont assez homogènes : les
serveurs se ressemblent, de même que les commutateurs. Comme l'exigent les
applications modernes des centres de données, la matrice de connectivité est
assez riche, ce qui lui permet de gérer les pannes avec élégance. Parce que

il y a tellement de liens entre un serveur et un autre, qu'une seule panne, ou même
plusieurs pannes de liens, n'entraînent pas une perte complète de connectivité. Toute
défaillance de liaison n'entraîne qu'une perte fractionnelle de bande passante par
opposition à une perte beaucoup plus importante, généralement 50 %, qui est
courante dans les anciennes architectures de réseau avec redondance bidirectionnelle.
L'autre conséquence d'avoir de nombreux liens est que la bande passante

entre deux nœuds est assez importante. La bande passante entre les nœuds
peut être augmentée en ajoutant plus de spins (limité par la capacité du
commutateur).
Nous complétons nos observations en notant que les extrémités sont toutes
connectées à des feuilles et que les épines agissent simplement comme des
connecteurs. Dans ce modèle, la fonctionnalité est poussée vers les bords plutôt que
tirée dans les épines. Ce modèle de mise à l'échelle est appelé unmise à l'échelle
maquette.
Vous pouvez facilement déterminer le nombre de serveurs que vous pouvez

connecter dans un tel réseau, car la topologie se prête à quelques calculs
simples. Si nous voulons une architecture non bloquante, c'est-à-dire une
architecture dans laquelle il y a autant de capacité entre les feuilles et les épines
qu'il y en a entre les feuilles et les serveurs, le nombre total de serveurs pouvant
être connectés estm2 / 2, où m est le nombre de ports dans un commutateur. Par
exemple, pour un commutateur à 64 ports, le nombre de serveurs que vous
pouvez connecter est de 64 * 64 / 2 = 2 048 serveurs. Pour un commutateur à 128
ports, le nombre de serveurs passe à 128 * 128 / 2 =
8 192 serveurs. L'équation générale du nombre de serveurs pouvant
être connectés dans un simple réseau Leaf-Spine estn * m / 2, où m
est le nombre de ports sur un commutateur feuille, et m est le nombre de ports sur un
commutateur spine.
En réalité, les serveurs sont interconnectés à la feuille via des liaisons à bas débit et les
commutateurs sont interconnectés par des liens à haut débit. Un déploiement courant
consiste à interconnecter les serveurs aux départs via des liaisons 10 Gbit/s, tout en
interconnectant les commutateurs entre eux via des liaisons 40 Gbit/s. Compte tenu de
la montée en puissance des liaisons 100 Gbit/s, un déploiement en devenir consiste à
utiliser des liaisons 25 Gbit/s pour interconnecter les serveurs aux départs, et des
liaisons 100 Gbit/s pour interconnecter les commutateurs.
En raison des restrictions d'alimentation, la plupart des réseaux ont au plus 40 serveurs
dans un seul rack (bien que les nouvelles conceptions de serveurs repoussent cette
limite). Au moment d'écrire ces lignes, les commutateurs à vitesse de liaison supérieure
les plus courants ont au plus 32 ports (chaque port étant soit 40 Gbit/s, soit
Topologie du réseau Clos | 5

100 Gbit/s). Ainsi, le nombre maximum de serveurs que vous pouvez connecter
de manière pragmatique avec un simple réseau Leaf-Spine est de 40 * 32 =
1 280 serveurs. Cependant, des versions 64 ports et 128 ports sont attendues prochainement.
Bien que 1 280 serveurs soient assez grands pour la plupart des petites et
moyennes entreprises, comment cette conception nous amène-t-elle aux dizaines
de milliers ou centaines de milliers de serveurs tant vantés ?
Réseaux Clos à trois niveaux
Figure 1-2 illustre une étape vers la résolution du problème de mise à l'échelle défini
dans la section précédente. C'est ce qu'on appelle unréseau Clos à trois niveaux. Il ne
s'agit que d'un ensemble de réseaux feuille-spine (ou réseaux Clos à deux niveaux)
connectés par une autre couche de commutateurs spine. Chaque réseau à deux
niveaux est appelé uncosse ou grappe, et le troisième niveau d'épines reliant toutes les
gousses est appelé un épine interpode ou couche de la colonne vertébrale intercluster.
Très souvent, le premier niveau de commutateurs, ceux auxquels les serveurs se
connectent, sont appelés haut de rack (ToR) car ils sont généralement placés en haut
de chaque rack ; le niveau suivant de commutateurs est appelé feuilles et le dernier
niveau de commutateurs, ceux qui connectent les pods, est appelé épines.
Figure 1-2. Réseau Clos à trois niveaux
Dans un tel réseau, en supposant que les mêmes commutateurs sont utilisés à chaque
niveau, le nombre total de serveurs que vous pouvez connecter est m3 / 4. En supposant
des commutateurs à 64 ports, par exemple, nous obtenons 643 / 4 = 65 536 serveurs. En
supposant les numéros de port de commutateur et les serveurs par rack les plus
réalistes de la section précédente, nous pouvons construire 40 * 16 * 16 = 10 240
serveurs.
Les opérateurs de réseaux à grande échelle surmontent ces limitations basées sur les
ports de l'une des deux manières suivantes : soit ils achètent de gros commutateurs de
châssis pour les épines, soit ils séparent les câbles des liaisons à haut débit en

plusieurs liaisons à faible vitesse et construire des réseaux de capacité
équivalente en utilisant plusieurs épines. Par exemple, un commutateur 32 ports
40 Gbit/s peut généralement être divisé en un commutateur 96 ports 10 Gbit/s.
Cela signifie que le nombre de serveurs pouvant être pris en charge devient
désormais 40 * 48 * 96 = 184 320. Un commutateur 32 ports 100 Gbps peut
généralement être divisé en 128 liaisons 25 Gbps, avec un nombre de serveurs
encore plus élevé : 40 * 64 * 128 = 327 680. Dans un tel réseau à trois niveaux,
chaque ToR est connecté à 64 feuilles, chaque feuille étant connectée à 64 épines.
C'est fondamentalement la beauté d'un réseau Clos : comme la conception fractale, des
pièces de plus en plus grandes sont assemblées à partir des mêmes blocs de
construction. Les entreprises à l'échelle du Web n'hésitent pas à se tourner vers des
réseaux Clos à 4 ou même 6 niveaux pour contourner les limites d'échelle des blocs de
construction plus petits. Couplé à la prise en charge de plus en plus importante du
nombre de ports du silicium marchand, la prise en charge de centres de données
encore plus grands est tout à fait faisable.
Effets secondaires cruciaux des réseaux Clos
Plutôt que de s'appuyer sur des commutateurs réseau apparemment infaillibles, les
pionniers à l'échelle du Web ont intégré la résilience à leurs applications, permettant
ainsi au réseau de faire ce qu'il fait le mieux : fournir une bonne connectivité grâce à
une matrice de connectivité riche et de grande capacité. Comme nous l'avons vu
précédemment, cette interconnexion dense et à haute capacité réduit le rayon
d'explosion d'une panne.
Une conséquence de l'utilisation de commutateurs à facteur de forme fixe est

qu'il y a beaucoup de câbles à gérer. Les plus grands opérateurs de réseaux
disposent tous d'une technologie de vérification des câbles maison. Il existe un
projet open source appelé Prescriptive Topology Manager (PTM) que j'ai co-signé,
qui gère la vérification des câbles.
Une autre conséquence des commutateurs de forme fixe est qu'ils échouent de
manière simple. Un gros châssis peut tomber en panne de manière complexe car
il y a tellement de « pièces mobiles ». Les pannes simples simplifient le
dépannage et, mieux encore, permettent une épargne abordable, permettant
aux opérateurs d'échanger les commutateurs défaillants par des bons au lieu de
dépanner une panne dans un réseau actif. Cela ajoute encore à la résilience du
réseau.
En d'autres termes, la résilience devient une propriété émergente des pièces

travaillant ensemble plutôt qu'une caractéristique de chaque boîte.
Topologie du réseau Clos | 7

Construire un grand réseau avec uniquement des commutateurs à forme fixe signifie
également que la gestion des stocks devient simple. Étant donné que tout commutateur
réseau est comme un autre, ou qu'il existe tout au plus quelques variantes, il est facile de
stocker des périphériques de rechange et de remplacer un appareil défectueux par un autre
qui fonctionne. Cela rend le modèle d'inventaire du commutateur réseau ou du routeur
similaire au modèle d'inventaire du serveur.
Ces observations sont importantes car elles affectent la vie quotidienne d'un
opérateur de réseau. Souvent, nous n'intégrons pas un nouvel
environnement ou un nouveau choix dans tous les aspects de notre
réflexion. Ces dérivés de second ordre du réseau Clos aident un
gestionnaire de réseau à reconsidérer la gestion quotidienne des réseaux
différemment qu'auparavant.
Architecture réseau de Clos Networks

Un réseau Clos nécessite également une architecture réseau différente des
déploiements traditionnels. Cette compréhension est fondamentale pour
tout ce qui suit, car elle aide à comprendre en quoi les opérations réseau
doivent être différentes dans un réseau de centre de données, même si les
protocoles de mise en réseau restent les mêmes.
Dans un réseau traditionnel, ce que nous appelons les couches feuille-épine s'appelaient
couches d'agrégation d'accès du réseau. Ces deux premières couches de
réseau étaient connectées en utilisant le pontage plutôt que le routage. Le
pontage utilise le protocole Spanning Tree (STP), qui divise la riche matrice
de connectivité d'un réseau Clos en une arborescence sans boucle. Par
exemple, dansFigure 1-1, le réseau Clos à deux niveaux, même s'il existe
quatre chemins entre la feuille la plus à gauche et la feuille la plus à droite,
STP ne peut utiliser qu'un seul des chemins. Ainsi, la topologie se réduit à
quelque chose comme celle montrée dansFigure 1-3.
Figure 1-3. Connectivité avec STP

En présence de défaillances de liaison, la traversée du chemin devient encore plus
inefficace. Par exemple, si le lien entre la feuille la plus à gauche et la colonne
vertébrale la plus à gauche échoue, la topologie peut ressembler àFigure 1-4.
Figure 1-4. STP après un échec de liaison
Tracez le chemin entre un serveur connecté à la feuille la plus à gauche et un

serveur connecté à la feuille la plus à droite. Il zigzague d'avant en arrière entre
les racks. Il s'agit d'une connectivité hautement inefficace et non uniforme.
Le routage, quant à lui, est capable d'utiliser tous les chemins, tirant pleinement parti de la
riche matrice de connectivité d'un réseau Clos. Le routage peut également emprunter le
chemin le plus court ou être programmé pour emprunter un chemin plus long pour une
meilleure utilisation globale de la liaison.
Ainsi, la première conclusion est que le routage est le mieux adapté aux
réseaux Clos, et pas le pontage.
Un avantage clé tiré de cette conversion du pontage au routage est que

nous pouvons nous débarrasser des multiples protocoles, de nombreux
propriétaires, qui sont requis dans un réseau ponté. Un réseau ponté
traditionnel exécute généralement STP, un protocole de détection de lien
unidirectionnel (bien qu'il soit maintenant intégré à STP), un protocole de
distribution de réseau local virtuel (VLAN), un protocole de routage de
premier saut tel que Host Standby Routing Protocol. (HSRP) ou Virtual
Router Redundancy Protocol (VRRP), un protocole de routage pour
connecter plusieurs réseaux pontés et un protocole de détection de lien
unidirectionnel séparé pour les liens routés. Avec le routage, les seuls
protocoles de plan de contrôle dont nous disposons sont un protocole de
routage et un protocole de détection de lien unidirectionnel. C'est ça. Les
serveurs communiquant avec le routeur du premier saut auront une simple
passerelle anycast,
Architecture Réseau des Réseaux Clos | 9

En réduisant le nombre de protocoles impliqués dans l'exploitation d'un réseau,
nous améliorons également la résilience du réseau. Il y a moins de pièces
mobiles et donc moins de points à dépanner. Il devrait maintenant être clair
comment les réseaux Clos permettent de construire non seulement des réseaux
hautement évolutifs, mais aussi des réseaux très résilients.
Modèles d'attachement de serveur
Les entreprises à l'échelle du Web déploient serveurs à connexion unique— c'est-à-dire que
chaque serveur est connecté à une seule feuille ou ToR. Étant donné que ces entreprises
disposent d'une multitude de serveurs, la perte d'un rack entier en raison d'une panne de
réseau est sans conséquence. Cependant, de nombreux réseaux plus petits, y compris
certaines grandes entreprises, ne peuvent pas se permettre de perdre un rack entier de
serveurs en raison de la perte d'une seule feuille ou d'une seule référence. Par conséquent, ils
double attache les serveurs; chaque lien est rattaché à un TdR différent. Pour simplifier le
câblage et augmenter la mobilité du rack, ces deux termes de référence résident tous les
deux dans le même rack.
Lorsque les serveurs sont ainsi à double attachement, les doubles liens sont
agrégés en un seul lien logique (appelé canal de port dans le jargon des réseaux
ou liens dans le jargon des serveurs) à l'aide d'un protocole propriétaire.
Différents fournisseurs ont des noms différents pour cela. Cisco l'appelle Virtual
Port Channel (vPC), Cumulus l'appelle CLAG et Arista l'appelle Multi-Chassis Link
Aggregation Protocol (MLAG). Essentiellement, le serveur pense qu'il est connecté
à un seul commutateur avec une liaison (ou un canal de port). Les deux
commutateurs qui y sont connectés donnent l'illusion, du point de vue du
protocole principalement, qu'ils sont un seul commutateur. Cette illusion est
nécessaire pour permettre à l'hôte d'utiliser le standardProtocole de contrôle
d'agrégation de liens (LACP) pour créer le lien. LACP suppose que l'agrégation de
liens se produit pour les liens entre deux nœuds, alors que pour une fiabilité
accrue, les serveurs à double connexion fonctionnent sur trois nœuds : le serveur
et les deux commutateurs auxquels il est connecté. Étant donné que chaque
protocole LACP multinœud est la propriété du fournisseur, les hôtes n'ont pas
besoin d'être modifiés pour prendre en charge le LACP multinœud.Figure 1-5
montre un serveur à double connexion avec MLAG.

Figure 1-5. Double attache avec canal de port
Connectivité au monde extérieur

Comment un centre de données se connecte-t-il au monde extérieur ? La réponse
à cette question finit par surprendre beaucoup de monde. Dans les réseaux
moyens à grands, cette connectivité se fait par ce qu'on appelleTDR frontière ou
cosses de frontière. Figure 1-6 présente un aperçu.
Figure 1-6. Connexion d'un réseau Clos au monde extérieur via un pod
frontière
Le principal avantage des modules de bordure ou des feuilles de bordure est

qu'ils isolent l'intérieur du centre de données de l'extérieur. Les protocoles de
routage qui sont à l'intérieur du centre de données n'interagissent jamais avec le
monde extérieur, offrant une mesure de stabilité et de sécurité.
Cependant, les réseaux plus petits peuvent ne pas être en mesure de dédier des
commutateurs séparés uniquement pour se connecter au monde extérieur. De
tels réseaux peuvent se connecter au monde extérieur via les épines, comme
indiqué dansFigure 1-7. Le point important à noter est quetous les épines sont
connectées à Internet, pas certaines. Ceci est important car dans une topologie
Clos, toutes les épines sont créées égales. Si la connectivité au monde extérieur
se faisait uniquement via certaines des épines, ces épines deviendraient
Connectivité au monde extérieur | 11

encombré en raison d'un trafic excessif qui ne passe que par eux et non par
les autres épines. En outre, cela rendrait la résilience plus fragile étant
donné que la perte même d'une fraction des liens se connectant à ces
épines spéciales signifie que soit ces feuilles perdront un accès complet au
monde extérieur, soit fonctionneront de manière sous-optimale car leur
bande passante vers le monde extérieur sera réduit considérablement par
les défaillances de liaison.
Figure 1-7. Connecter un réseau Clos au monde extérieur via des épines
Prise en charge de l'architecture mutualisée (ou Cloud)
La topologie Clos est également adaptée à la construction d'un réseau pour prendre en
charge les clouds, publics ou privés. Les objectifs supplémentaires d'une architecture cloud
sont les suivants :
Agilité
Compte tenu de l'utilisation typique du cloud, au cours de laquelle les clients
lancent et détruisent rapidement des réseaux, il est essentiel que le réseau puisse
prendre en charge ce modèle.
Isolation
Le trafic d'un client ne doit pas être vu par un autre client.
Escalader
Un grand nombre de clients, ou locataires, doit être pris en charge.
Les solutions traditionnelles traitaient de la multilocation en fournissant l'isolation dans

le réseau, via des technologies telles que les VLAN. Les fournisseurs de services ont
également résolu ce problème en utilisant des réseaux privés virtuels

(VPN). Cependant, l'avènement de la virtualisation des serveurs, alias les machines virtuelles,
et maintenant les conteneurs, a changé la donne. Lorsque les serveurs étaient toujours
physiques ou que les VPN n'étaient pas configurés en quelques secondes ou minutes dans les
réseaux des fournisseurs de services, les technologies existantes étaient logiques. Mais les
machines virtuelles tournent plus vite que n'importe quel serveur physique, et, plus important
encore, cela se produit sans que le commutateur connecté au serveur soit au courant du
changement. Si les commutateurs ne peuvent pas détecter le démarrage et le ralentissement
des machines virtuelles, et donc un réseau de locataires, cela n'a aucun sens que les
commutateurs soient impliqués dans l'établissement et le démontage des réseaux clients.
Avec l'avènement du Virtual eXtensible Local Area Network (VXLAN) et des

tunnels IP-in-IP, les opérateurs cloud ont libéré le réseau de l'obligation de
connaître ces réseaux virtuels. En tunnelant les paquets client dans un
tunnel VXLAN ou IP-in-IP, le réseau physique a continué à acheminer les
paquets sur l'en-tête du tunnel, sans se soucier du contenu du paquet
interne. Ainsi, le réseau Clos peut être l'épine dorsale sur laquelle même les
réseaux cloud sont construits.
Conséquences opérationnelles de la conception de

datacenters modernes
Les choix faits dans la conception des centres de données modernes ont des
conséquences considérables sur l'administration des centres de données.
La plus évidente est qu'étant donné l'ampleur du réseau, il n'est pas possible de
gérer manuellement les centres de données. L'automatisation n'est rien de moins
qu'une exigence de survie de base. L'automatisation est beaucoup plus difficile,
voire impossible, si chaque bloc de construction est fabriqué à la main et unique.
Les modèles de conception doivent être créés pour que l'automatisation
devienne simple et reproductible. De plus, étant donné l'échelle, la fabrication
artisanale de chaque bloc rend le dépannage problématique.
Les réseaux multi-locataires tels que les clouds doivent également démarrer et détruire
rapidement les réseaux virtuels. Les conceptions de réseau traditionnelles basées sur
des technologies telles que le VLAN n'évoluent pas pour prendre en charge un grand
nombre de locataires et ne peuvent pas être mises en place ou arrêtées rapidement.
De plus, un déploiement aussi rapide nécessite une automatisation, potentiellement
sur plusieurs nœuds.
Non seulement les réseaux multi-locataires, mais les centres de données plus grands
nécessitent également la capacité de déployer de nouveaux racks et de remplacer les nœuds
défaillants dans des délais d'un ordre ou deux de grandeur inférieurs à ce qui est possible avec
Conséquences opérationnelles de la conception d'un centre de données moderne | 13

réseaux traditionnels. Ainsi, les opérateurs doivent trouver des
solutions qui permettent tout cela.
Choix du protocole de routage

Il semble évident qu'Open Shortest Path First (OSPF) ou Intermediate System-to-
Intermediate System (IS-IS) serait le choix idéal pour un protocole de routage pour
alimenter le centre de données. Ils sont tous deux conçus pour être utilisés au sein
d'une entreprise, et la plupart des opérateurs de réseaux d'entreprise sont familiarisés
avec la gestion de ces protocoles, au moins OSPF. OSPF, cependant, a été rejeté par la
plupart des opérateurs à l'échelle du Web en raison de son manque de prise en charge
multiprotocole. En d'autres termes, OSPF nécessitait deux protocoles distincts,
similaires principalement en termes de nom et de fonction de base, pour prendre en
charge les réseaux IPv4 et IPv6.
En revanche, IS-IS est un protocole bien mieux considéré qui peut router à la fois les
piles IPv4 et IPv6. Cependant, les bonnes implémentations IS-IS sont peu nombreuses,
limitant les choix de l'administrateur. En outre, de nombreux opérateurs ont estimé
qu'un protocole à état de liens était intrinsèquement inadapté à un réseau richement
connecté tel que la topologie Clos. Les protocoles d'état des liens ont propagé les
changements d'état des liens jusqu'aux routeurs les plus éloignés, c'est-à-dire les
routeurs dont l'état du chemin n'a pas changé suite aux changements.
BGP est entré dans une telle situation et a promis quelque chose que les deux autres
ne pouvaient pas offrir. BGP est mature, alimente Internet et est fondamentalement
simple à comprendre (malgré sa réputation contraire). De nombreuses
implémentations matures et robustes de BGP existent, y compris dans le monde de
l'open source. Il est moins bavard que ses cousins à état de liens et prend en charge
les multiprotocoles (c'est-à-dire qu'il prend en charge la publicité IPv4, IPv6, la
commutation multiprotocole par étiquette (MPLS) et les VPN de manière native). Avec
quelques ajustements, nous pouvons faire fonctionner BGP efficacement dans un
centre de données. L'équipe Azure de Microsoft a initialement mené la charge pour
adapter BGP au centre de données. Aujourd'hui, la plupart des clients avec qui je
m'engage déploient BGP.
La prochaine partie de notre voyage consiste à comprendre comment le modèle de

déploiement traditionnel de BGP a été modifié pour être utilisé dans le centre de données.

CHAPITRE 2
Comment BGP a été adapté

au centre de données
Avant son utilisation dans le centre de données, BGP était principalement, sinon
exclusivement, utilisé dans les réseaux de fournisseurs de services. En conséquence de son
utilisation principale, les opérateurs ne peuvent pas utiliser BGP à l'intérieur du centre de
données de la même manière qu'ils l'utiliseraient dans le monde des fournisseurs de services.
Si vous êtes un opérateur réseau, il est important de comprendre ces différences et leur
raison pour éviter les erreurs de configuration.
La connectivité dense du réseau du centre de données est un espace très différent de

la connectivité relativement clairsemée entre les domaines administratifs. Ainsi, un
ensemble de compromis différent est pertinent à l'intérieur du centre de données
qu'entre les centres de données. Dans le réseau du fournisseur de services, la stabilité
est préférée à la notification rapide des changements. Ainsi, BGP suspend
généralement l'envoi de notifications sur les modifications pendant un certain temps.
Dans le réseau de centres de données, les opérateurs souhaitent que les mises à jour
de routage soient aussi rapides que possible. Un autre exemple est qu'en raison de la
conception par défaut de BGP, de son comportement et de sa nature en tant que
protocole à vecteur de chemin, une seule défaillance de liaison peut entraîner un
nombre excessivement élevé de messages BGP passant entre tous les nœuds, ce qui
est mieux évité. Un troisième exemple est le comportement par défaut de BGP pour
construire un seul meilleur chemin lorsqu'un préfixe est appris à partir de nombreux
Autonomous SystemNumbers (ASN), car un ASN représente généralement un domaine
administratif séparé. Mais à l'intérieur du centre de données, nous voulons que
plusieurs chemins soient sélectionnés.
15
Deux personnes ont mis en place un moyen d'intégrer BGP dans le centre de données.
Leur travail est documenté dansRFC 7938.
Ce chapitre explique chacune des modifications apportées au comportement de

BGP et la justification du changement. Il n'est pas rare de voir des opérateurs de
réseau mal configurer BGP dans le centre de données avec un effet délétère, car
ils n'ont pas compris les motivations derrière les ajustements de BGP pour le
centre de données.
Combien de protocoles de routage ?

La différence la plus simple pour commencer est le nombre de protocoles qui
s'exécutent dans le centre de données. Dans le modèle de déploiement
traditionnel, BGP apprend les préfixes à annoncer à partir d'un autre protocole
de routage, généralement Open Shortest Path First (OSPF), Intermediate System-
to-Intermediate System (IS-IS) ou Enhanced Interior Gateway Routing Protocole
(EIGRP). Ceux-ci sont appelés protocoles de routage internes car ils sont utilisés
pour contrôler le routage au sein d'une entreprise. Il n'est donc pas surprenant
que les gens supposent que BGP a besoin d'un autre protocole de routage dans
le centre de données. Cependant, dans le centre de données, BGPest le protocole
de routage interne. Il n'y a pas de protocole de routage supplémentaire.
BGP interne ou BGP externe

L'une des premières questions que les gens se posent à propos de BGP dans le
centre de données est de savoir quel BGP utiliser : BGP interne (iBGP) ou BGP
externe (eBGP). Étant donné que l'ensemble du réseau est sous l'égide d'un seul
domaine administratif, iBGP semble être la réponse évidente. Cependant, ce n'est
pas le cas.
Dans le centre de données, eBGP est le modèle de déploiement le plus courant.

La raison principale est que eBGP est plus simple à comprendre et à déployer que
iBGP. iBGP peut prêter à confusion dans son meilleur algorithme de sélection de
chemin, les règles par lesquelles les routes sont transmises ou non, et sur quels
attributs de préfixe sont appliqués ou non. Il existe également des limitations
dans la prise en charge des trajets multiples par iBGP sous certaines conditions :
en particulier, lorsqu'une route est annoncée par deux nœuds différents.
Surmonter cette limitation est possible, mais fastidieux.
Un débutant est également beaucoup plus susceptible d'être confus par iBGP
que par eBGP en raison du nombre de boutons de configuration qui doivent être
16 | Chapitre 2 : Comment BGP a été adapté au centre de données

tourné pour obtenir le comportement souhaité. La plupart des boutons sont
incompréhensibles pour les nouveaux arrivants et ne font qu'ajouter à leur malaise.
Une forte raison non technique pour choisir eBGP est qu'il existe des
implémentations plus complètes et plus robustes d'eBGP que d'iBGP. La présence
de plusieurs implémentations signifie qu'un client peut éviter le verrouillage du
fournisseur en choisissant eBGP plutôt que iBGP. Cela était particulièrement vrai
jusqu'à la mi-2012 environ, lorsque les implémentations iBGP étaient boguées et
moins complètes que ce qui était nécessaire pour fonctionner dans le centre de
données.
Numérotation ASN
Le numéro de système autonome (ASN) est un concept fondamental dans BGP.
Chaque haut-parleur BGP doit avoir un ASN. Les ASN sont utilisés pour identifier
les boucles de routage, déterminer le meilleur chemin vers un préfixe et associer
les politiques de routage aux réseaux. Sur Internet, chaque ASN est autorisé à
parler avec autorité de préfixes IP particuliers. Les ASN sont disponibles en deux
versions : une version à deux octets et une version plus moderne à quatre octets.
Le modèle de numérotation ASN est différent de la façon dont ils sont attribués dans les
déploiements traditionnels hors centre de données. Cette section couvre les concepts sous-
jacents à la façon dont les ASN sont attribués aux routeurs au sein du centre de données.
Si vous choisissez de suivre la meilleure pratique recommandée d'utiliser eBGP

comme protocole, le schéma de numérotation ASN le plus évident est que
chaque routeur se voit attribuer son propre ASN. Cette approche conduit à des
problèmes, dont nous parlerons ensuite. Cependant, considérons d'abord les
chiffres utilisés pour l'ASN. Dans le peering Internet, les ASN sont attribués
publiquement et ont des numéros bien connus. Mais la plupart des routeurs au
sein du centre de données seront rarement voire jamais appairés avec un routeur
dans un domaine administratif différent (à l'exception des feuilles de frontière
décrites dansChapitre 1). Par conséquent, les ASN utilisés au sein du centre de
données proviennent de l'espace de numéro ASN privé.
ASN privés
Un ASN privé est un ASN destiné à être utilisé en dehors de l'Internet
mondial. Tout comme la plage d'adresses IP privées de 10.0.0.0/8, les ASN
privés sont utilisés dans la communication entre des réseaux non exposés
au monde extérieur. Un centre de données est un exemple d'un tel réseau.
Numérotation ASN | 17
Rien n'empêche un opérateur d'utiliser les ASN publics, mais cela n'est pas
recommandé pour deux raisons majeures.
Le premier est que l'utilisation d'ASN globaux peut dérouter les opérateurs et les
outils qui tentent de décoder les ASN en noms significatifs. Étant donné que de
nombreux ASN sont bien connus des opérateurs, un opérateur peut très bien
devenir confus, par exemple, en voyant l'ASN de Verizon sur un nœud au sein du
centre de données.
La deuxième raison est d'éviter les conséquences d'une fuite accidentelle des
informations BGP internes vers un réseau externe. Cela peut faire des ravages
sur Internet. Par exemple, si un centre de données utilisait l'ASN de Twitter en
interne et divulguait accidentellement un itinéraire prétendant, disons, que
Twitter faisait partie de l'AS_PATH1 pour une route accessible au public au sein du
centre de données, l'opérateur de réseau serait responsable d'un détournement
mondial massif d'un service bien connu. Les erreurs de configuration sont la
source numéro un ou numéro deux de toutes les pannes de réseau, et donc
éviter cela en n'utilisant pas les ASN publics est une bonne chose.
Les anciens ASN à 2 octets n'ont de l'espace que pour environ 1 023 ASN privés
(64512-65534). Que se passe-t-il lorsqu'un réseau de centre de données compte
plus de 1 023 routeurs ? Une approche consiste à dérouler la boîte à outils du
bouton BGP et à rechercher quelque chose appeléadmis-in. Une autre approche,
et beaucoup plus simple, consiste à passer à des ASN à 4 octets. Ces nouveaux
ASN prennent en charge près de 95 millions d'ASN privés (4200000000–
4294967294), plus que suffisant pour satisfaire un datacenter de toute taille en
activité aujourd'hui. Presque toutes les suites de routage, traditionnelles ou
nouvelles, propriétaires ou open source, prennent en charge les ASN de 4 octets.
Les problèmes de la chasse au sentier
Pour en revenir à la façon dont les ASN sont attribués à un locuteur BGP, le choix
le plus évident serait d'attribuer un ASN distinct pour chaque nœud. Mais cette
approche conduit à des problèmes inhérents aux protocoles chemin-vecteur. Les
protocoles à vecteur de chemin souffrent d'une variation d'un problème appelé
compter jusqu'à l'infini, subis par les protocoles vectoriels à distance. Bien que
nous ne puissions pas entrer ici dans tous les détails de la chasse au sentier, vous
1 Il s'agit d'informations supplémentaires transmises à chaque route, indiquant la liste des ASN
parcourus depuis l'origine de cette annonce.

peut jeter un oeil à une explication simple du problème à partir de la
topologie simple montrée dans Figure 2-1.
Figure 2-1. Un exemple de topologie pour expliquer la recherche de chemin
Dans cette topologie, tous les nœuds ont des ASN distincts.
Considérons maintenant l'accessibilité au préfixe 10.1.1.1 du point de
vue de R1. R2 et R3 annoncent l'accessibilité au préfixe 10.1.1.1 à R1.
L'AS_PATH annoncé par R2 pour 10.1.1.1 est [R2, R4], et l'AS_PATH
annoncé par R3 est [R3, R4]. R1 ne sait pas comment R2 et R3 ont eux-
mêmes appris cette information. Lorsque R1 apprend le chemin vers
10.1.1.1 de R2 et R3, il choisit l'un d'eux comme le meilleur chemin. En raison de
sa prise en charge locale du multiacheminement, ses tables de transfert
contiendront l'accessibilité à 10.1.1.1 via R2 et R3, mais dans la meilleure
sélection de chemin de BGP, seul l'un des R2 ou R3 peut gagner.
Supposons que R3 est choisi comme le meilleur chemin vers 10.1.1.1 par R1.
R1 annonce maintenant qu'il peut atteindre 10.1.1.1 avec l'AS_PATH [R1, R3,
R4] à R2. R2 accepte l'annonce, mais ne la considère pas comme un meilleur
chemin pour atteindre 10.1.1.1, car son meilleur chemin est le plus court
AS_PATH R4.
Maintenant, lorsque le nœud R4 meurt, R2 perd son meilleur chemin vers

10.1.1.1, et donc il recalcule son meilleur chemin via R1, AS_PATH [R1, R3, R4] et
envoie ce message à R1. R2 envoie également un message de retrait de route
pour 10.1.1.1 à R1. Lorsque le retrait de R3 vers la route 10.1.1.1 atteint R1, R1
retire également sa route vers 10.1.1.1 et envoie son retrait à R2. La séquence
exacte des événements peut ne pas être celle décrite ici en raison de la
synchronisation des échanges de paquets entre les nœuds et du fonctionnement
de BGP, mais il s'agit d'une approximation proche.
La version courte de ce problème est la suivante : parce qu'un nœud ne

connaît pas l'état de la liaison physique de tous les autres nœuds du réseau,
il ne sait pas si la route a vraiment disparu (parce que le nœud à la fin est lui-
même tombé en panne) ou est accessible par un autre chemin. Et
Numérotation ASN | 19
ainsi, un nœud poursuit la recherche de l'accessibilité à la destination via tous ses
autres chemins disponibles. C'est ce qu'on appelle la chasse au chemin.
Dans la topologie simple de Figure 2-1, ça n'avait pas l'air si mal. Mais dans
une topologie Clos, avec ses interconnexions denses, ce problème simple
devient assez important avec de nombreux échanges de messages
supplémentaires et une perte de trafic accrue due à une désinformation se
propageant plus longtemps que nécessaire.
Modèle de numérotation ASN
Pour éviter le problème de la recherche de chemin, le modèle de numérotation ASN pour les
routeurs dans une topologie Clos est le suivant :
• Tous les routeurs ToR se voient attribuer leur propre ASN.
• Les feuilles à travers une cosse ont un ASN différent, mais les feuilles à l'intérieur de
chaque cosse ont un ASN qui est unique à cette cosse.
• Les épines interpodes partagent un ASN commun.
Figure 2-2 présente un exemple de numérotation ASN pour un Clos à trois

niveaux.
Figure 2-2. Exemple de numérotation ASN dans une topologie Clos
Cette numérotation résout le problème de recherche de chemin. Dans BGP,

l'ASN est la façon dont un voisin en connaît un autre. DansFigure 2-1,
donnons à R2 et R3 le même ASN. Lorsque R1 a dit à R2 qu'il avait un chemin
vers 10.1.1.1 via R3, R2 a complètement rejeté ce chemin parce que le
champ AS_PATH contenait l'ASN de R3, qui était le même que R2, qui
indiquait une boucle de routage. Ainsi, lorsque R2 et R3 perdent leur lien
vers R4, et donc vers 10.1.1.1, le seul échange de message qui se produit est
qu'ils retirent leur annonce vers 10.1.1.1 de R1 et 10.1.1.1

est purgé de toutes les tables de transfert des routeurs. En revanche, compte tenu de
la numérotationFigure 2-2, les feuilles et les épines élimineront les chemins alternatifs
en raison de la logique de détection de boucle AS_PATH codée dans le calcul du
meilleur chemin de BGP.
Le seul inconvénient de cette forme de numérotation ASN est que

l'agrégation ou la récapitulation des routes n'est pas possible. Pour
comprendre pourquoi, revenons àFigure 2-1, avec R2 et R3 ayant le même
ASN. Supposons en outre que R2 et R3 ont appris d'autres préfixes, disons à
partir de 10.1.1.2/32-10.1.1.250/32 via des serveurs directement connectés
(non illustrés sur la figure). Au lieu d'annoncer 250 préfixes (10.1.1.1–
10.1.1.250) à R1, R2 et R3 décident d'agréger les routes et d'annoncer une
seule route 10.1.1.0/24 à R4. Désormais, si le lien entre R2 et R4 se rompt, R2
n'a plus de chemin vers 10.1.1.1/32. Il ne peut pas utiliser le chemin R1-R3-
R4 pour atteindre 10.1.1.1, comme expliqué précédemment. R1 a calculé
deux chemins pour atteindre 10.1.1.0/24, via R2 et R3. S'il reçoit un paquet
destiné à 10.1.1.1, il peut très bien choisir de l'envoyer à R2, qui n'a pas de
chemin pour atteindre 10.1.1.1 ; le paquet sera abandonné par R2,
provoquant une perte aléatoire de connectivité vers 10.1.1.1. Si au lieu de
résumer les routes, R2 et R3 envoient séparément la liste complète des 250
préfixes, lorsque le lien vers R4 se rompt, R2 n'a besoin de retirer que la
route vers 10.1.1.1, tout en conservant l'annonce aux 249 autres routes. R1
établira correctement une accessibilité unique à 10.1.1.1, via R3 ; mais il
maintient plusieurs chemins, via R2 et R3, pour les 249 autres préfixes. Ainsi,
la récapitulation d'itinéraire n'est pas possible avec ce schéma de
numérotation ASN.
Meilleur algorithme de chemin
BGP utilise un algorithme pour calculer le meilleur chemin vers un préfixe donné à
partir d'un nœud. Comprendre cela est fondamental pour comprendre comment le
transfert se produit dans un réseau routé BGP et pourquoi certains chemins sont
choisis par rapport à d'autres.
La sélection du meilleur chemin de BGP est déclenchée lorsqu'un nouveau message

UPDATE est reçu d'un ou plusieurs de ses pairs. Les implémentations peuvent choisir
de mettre en mémoire tampon le déclenchement de cet algorithme afin qu'une seule
exécution traite toutes les mises à jour au lieu d'échanger rapidement les routes en
exécutant l'algorithme très fréquemment.
OSPF, IS-IS et d'autres protocoles de routage ont une métrique simple

permettant de décider lequel des chemins accepter. BGP en a huit !
Meilleur algorithme de chemin | 21

Bien que je les mentionne tous dans cette section, un seul compte pour le
centre de données : AS_PATH.
Vous pouvez utiliser cette phrase mnémotechnique lapidaire pour vous souvenir des algorithmes de
chemin BGP :
Les amateurs de lèvres sages appliquent des médicaments par voie orale tous les soirs.
J'ai entendu cela pour la première fois lors d'une présentation donnée par
mon ami et expert en BGP, Daniel Walton. Le véritable inventeur de
l'expression est un ingénieur Cisco, Denise Fishburne, qui a eu la gentillesse
de me laisser l'utiliser dans ce livre.Figure 2-3 illustre la correspondance
entre le mnémonique et les algorithmes réels.
Figure 2-3. Critères de sélection du meilleur chemin BGP
Pour ceux qui souhaitent en savoir plus, Article 9 de la RFC 4271 couvre chaque
métrique en détail sanglant. Les routes iBGP ont un critère de correspondance
supplémentaire au-delà de ces huit paramètres, mais une discussion de ces
paramètres dépasse le cadre de ce livre.
Sélection multi-chemins
Dans un réseau densément connecté tel qu'un réseau Clos, le multicheminement des
routes est une exigence fondamentale pour construire des réseaux robustes et
évolutifs. BGP prend en charge le multiacheminement, que les chemins aient des coûts
égaux ou inégaux, bien que toutes les implémentations ne prennent pas en charge le
multiacheminement à coût inégal. Comme décrit dans la section précédente, deux
chemins sont considérés comme égaux s'ils sont égaux dans chacun des huit critères.
L'un des critères est que les numéros AS dans AS_PATH correspondent exactement, pas
seulement qu'ils aient des chemins de longueur égale. Cette

rompt le multiacheminement dans deux scénarios de déploiement courants au sein du centre
de données.
Le premier scénario de déploiement, dans lequel la même route peut être annoncée à partir
de différents ASN, est lorsqu'un serveur est à double connexion, avec un ASN distinct pour
chaque commutateur ToR, comme indiqué dans Figure 2-4. Sur la figure, les ellipses
représentent un canal de liaison ou de port ; c'est-à-dire que les deux liaisons sont conçues
pour ressembler à une liaison logique à plus grande vitesse vers les protocoles de couche
supérieure.
Figure 2-4. Serveur à double connexion
Supposons que les deux feuilles annoncent une route de sous-réseau vers
10.1.1.0/24, le sous-réseau du pont auquel le serveur est connecté. Dans ce
cas, chaque colonne voit la route vers 10.1.1.0/24 être reçue, l'une avec
AS_PATH de 64600 et l'autre avec un AS_PATH de 64601. Selon la logique des
chemins à coût égal, BGP exige non seulement que l'AS_PATH les longueurs
soient les mêmes, mais que les AS_PATH contiennent la même liste d'ASN.
Comme ce n'est pas le cas ici, chaque spine n'effectuera pas de trajets
multiples ; au lieu de cela, ils choisiront un seul des deux itinéraires.
Dans le deuxième scénario de déploiement, lorsque les services virtuels sont

déployés par des serveurs, plusieurs serveurs annoncent l'accessibilité à la même
adresse IP virtuelle de service. Étant donné que les serveurs sont connectés à
différents commutateurs pour assurer la fiabilité et l'évolutivité, les épines
recevront à nouveau une route de plusieurs ASN différents, pour lesquels les
longueurs AS_PATH sont identiques, mais les ASN spécifiques à l'intérieur du
chemin lui-même ne le sont pas.
Sélection multi-chemins | 23
Il existe plusieurs façons de résoudre ce problème, mais la plus simple
consiste à configurer un bouton qui modifie l'algorithme du meilleur chemin.
Le bouton s'appelle bestpath as-path multipath-relax. Qu'est-ce que c'est
fait est simple : lorsque les longueurs AS_PATH sont les mêmes dans les publicités de
deux sources différentes, l'algorithme du meilleur chemin saute la vérification de la
correspondance exacte des ASN, et procède à la correspondance sur les critères
suivants.
Convergence lente en raison des temporisateurs par défaut
Pour éviter de configurer explicitement chaque bouton, une pratique courante consiste
à supposer des valeurs sûres et conservatrices pour les paramètres qui ne sont pas
spécifiés. Les temporisateurs en particulier sont un bouton commun pour lequel les
valeurs par défaut sont supposées si l'opérateur ne fournit aucune information
spécifique. En termes simples, les minuteurs contrôlent la vitesse de communication
entre les pairs. Pour BGP, ces temporisateurs sont réglés par défaut pour
l'environnement du fournisseur de services, pour lequel la stabilité est préférée à la
convergence rapide. À l'intérieur du centre de données, bien que la stabilité soit
certainement appréciée, la convergence rapide est encore plus importante.
Il existe quatre temporisateurs qui régissent généralement la vitesse à laquelle

BGP converge lorsqu'une défaillance se produit ou lorsqu'il se remet d'une
défaillance (comme un lien redevenant disponible). Il est important de
comprendre ces temporisateurs car ils affectent la vitesse à laquelle les
informations se propagent sur le réseau, et leur réglage permet à un opérateur
d'atteindre des vitesses de convergence avec BGP qui correspondent à d'autres
protocoles de routage internes tels que Open Shortest Path First (OSPF). Nous
examinerons ces minuteries dans les sections suivantes.
Intervalle de publicité
BGP maintient un intervalle minimum par voisin. Les événements dans cette
fenêtre d'intervalle minimum sont regroupés et envoyés en une seule fois
lorsque l'intervalle minimum expire. Ceci est essentiel pour le code le plus
stable, mais cela permet également d'éviter des traitements inutiles en cas
de mises à jour multiples sur une courte durée. La valeur par défaut pour
cet intervalle est de 30 secondes pour les homologues eBGP et de 0 seconde
pour les homologues iBGP. Cependant, attendre 30 secondes entre les
mises à jour est tout à fait un mauvais choix pour un réseau richement
connecté comme ceux que l'on trouve dans le centre de données. 0 est le
choix le plus approprié car nous ne traitons pas de routeurs à travers

domaines. Ce changement à lui seul peut amener le temps de convergence
d'eBGP à celui d'autres protocoles IGP tels que OSPF.
Minuteries Keepalive et Hold
Dans chaque session BGP, un nœud envoie des messages keepalive périodiques
à son homologue. Si le pair ne reçoit pas de keepalive pendant une période
connue sous le nom de temps d'attente, le pair déclare la session comme morte,
abandonne la connexion et toutes les informations reçues sur cette connexion, et
tente de redémarrer la machine d'état BGP.
Par défaut, la minuterie keepalive est de 60 secondes et la minuterie d'attente est de

180 secondes. Cela signifie qu'un nœud envoie un message keepalive pour une session
toutes les minutes. Si le pair ne voit pas un seul message keepalive pendant trois
minutes, il déclare la session morte. Par défaut, pour les sessions eBGP pour lesquelles
l'homologue est à un seul saut de routage, si le lien échoue, cela est détecté et la
session est immédiatement réinitialisée. Ce que font les temporisateurs keepalive et
hold, c'est d'attraper toutes les erreurs logicielles par lesquelles le lien est actif mais est
devenu à sens unique en raison d'une erreur, comme dans le câblage. Certains
opérateurs activent un protocole appeléDétection de transfert bidirectionnel (BFD)
pour une détection inférieure à une seconde, ou au plus une seconde, d'erreurs dues à
des problèmes de câble. Cependant, pour détecter les erreurs dans le processus BGP
lui-même, vous devez ajuster ces minuteurs.
À l'intérieur du centre de données, trois minutes, c'est toute une vie. Les valeurs les plus
courantes configurées à l'intérieur du centre de données sont trois secondes pour keepalive
et neuf secondes pour le temporisateur d'attente.
Minuterie de connexion
C'est le moins critique des quatre temporisateurs. Lorsque BGP tente de se

connecter à un homologue mais échoue pour diverses raisons, il attend un
certain temps avant de tenter de se reconnecter. Cette période par défaut est de
60 secondes. En d'autres termes, si BGP est incapable d'établir une session avec
son homologue, il attend une minute avant de tenter à nouveau d'établir une
session. Cela peut retarder le rétablissement de la session lorsqu'un lien se
rétablit d'une défaillance ou qu'un nœud se met sous tension.
Configuration par défaut pour le centre de données
Lors du franchissement des frontières administratives et de confiance, il est

préférable de configurer explicitement toutes les informations pertinentes. De
plus, étant donné les attentes différentes de deux entreprises distinctes, presque
Configuration par défaut du centre de données | 25

rien n'est supposé dans BGP, chaque bouton devant être explicitement
configuré.
Lorsque BGP a été adapté pour une utilisation dans le centre de données, aucun
de ces aspects de BGP n'a été modifié. Ce n'est pas le protocole lui-même qui doit
être modifié, mais la façon dont il est configuré. Chaque bouton qui doit être
configuré frappe la terreur (ou du moins sème potentiellement la confusion) dans
l'esprit des débutants et des pratiquants intermédiaires. Même ceux qui
connaissent BGP ressentent le besoin de se tenir constamment à jour en raison
de la quantité de travail requise par BGP.
Un bon moyen d'éviter tous ces problèmes est de configurer de bonnes valeurs par
défaut afin que les utilisateurs n'aient pas besoin de connaître les boutons qui ne les
intéressent pas. L'implémentation BGP dans de nombreuses suites de routage
propriétaires est originaire du monde des fournisseurs de services, donc une telle
option n'est généralement pas disponible. Avec des suites de routage open source qui
sont orientées vers le centre de données, telles queFRRoutage, la configuration par
défaut évite à l'utilisateur d'avoir à configurer explicitement de nombreuses options.
De bons paramètres par défaut rendent également la taille de votre configuration

beaucoup plus gérable, ce qui facilite l'observation des configurations et garantit qu'il
n'y a pas d'erreurs. Au fur et à mesure que votre organisation se familiarise avec BGP
dans le centre de données, des configurations par défaut saines peuvent fournir la
base d'une automatisation fiable.
Voici les paramètres par défaut dans FRRouting for BGP. Ce sont les paramètres que je
pense être la meilleure pratique pour BGP dans le centre de données. Ce sont les
paramètres que j'ai vus utilisés dans à peu près tous les centres de données de
production que j'ai rencontrés.
• Multipath activé pour eBGP et iBGP

• Intervalle de publicité défini sur 0
• Minuteries Keepalive et Hold réglées sur 3s et 9s
• Modifications d'adjacence de journalisation activées
Sommaire
Ce chapitre a couvert les concepts de base derrière l'adaptation de BGP au centre de
données, tels que l'utilisation d'eBGP comme modèle de déploiement par défaut et la
logique derrière la configuration des ASN. Dans les deux prochains chapitres, nous
appliquerons ce que nous avons appris dans ce chapitre à la configuration des nœuds
dans une topologie Clos.

CHAPITRE 3
Construire un automatisable
Configuration BGP
Il ne suffit pas d'apprendre à configurer BGP. Un opérateur réseau doit

également savoir comment s'y prendre pour automatiser le
déploiement de cette configuration.
Comme discuté dans « Conséquences opérationnelles de la conception d'un centre de

données moderne » à la page 13, le mantra de l'automatisation dans le centre de données est
simple : automatiser ou mourir. Si vous ne pouvez pas automatiser votre infrastructure
— et le réseau est un élément fondamental de l'infrastructure — vous
deviendrez tout simplement trop inefficace pour atteindre les objectifs
commerciaux. En conséquence, soit l'entreprise se ratatinera, soit évoluera
pour améliorer son infrastructure.
Dans ce chapitre, nous commençons le parcours de création d'une configuration BGP

automatisable. Nous ne montrerons pas l'automatisation avec un outil particulier tel
qu'Ansible, car les sites varient dans leur utilisation de ces outils et chacun a sa propre
syntaxe et sa propre sémantique qui méritent leur propre documentation. Au lieu de
cela, nous allons nous concentrer sur BGP.
Les bases de l'automatisation de la configuration
L'automatisation est possible lorsqu'il y a des modèles. Si nous ne pouvons pas trouver
de modèles, l'automatisation devient extrêmement difficile, voire impossible. La
configuration de BGP n'est pas différente. Nous devons rechercher des modèles dans
la configuration BGP afin de pouvoir les automatiser. Cependant, la détection de
modèles n'est pas suffisante. Les modèles doivent être robustes pour que
27
les changements ne deviennent pas dangereux. Il faut aussi éviter les doublons.
Dans la section qui suit, nous examinerons ces deux problèmes en détail et
verrons comment nous pouvons les éliminer.
Exemple de réseau de centre de données
Pour une grande partie du reste du livre, nous utiliserons la topologie dans Figure 3-1
pour montrer comment utiliser BGP. Cette topologie est une bonne représentation de la plupart des
réseaux de centres de données.
Figure 3-1. Exemple de réseau de centre de données
Dans notre réseau, nous configurons les éléments suivants :
• Les feuilles, feuille01 à feuille04

• Les épines, spine01 à spine02
• La sortie part, exit01 à exit02
• Les serveurs, server01 à server04
À l'exception des serveurs, tous les périphériques répertoriés sont des routeurs et le
protocole de routage utilisé est BGP.
28 | Chapitre 3 : Création d'une configuration BGP automatisable

Un petit rappel : la topologie que nous utilisons est un réseau
Clos, donc les nœuds feuille et spine sont tous des routeurs,
comme décrit dans Chapitre 1.
Noms d'interface utilisés dans ce livre

Les noms d'interface sont spécifiques à chaque plate-forme de routage.
Arista, Cisco, Cumulus et Juniper ont tous leur propre façon de nommer une
interface. Dans ce livre, j'utilise les noms d'interface utilisés sur Cumulus
Linux. Ces ports sont nommés swpX, où swp signifie switchport. Alors, dans
Figure 3-1, l'interface eth1 de server01 est connectée à l'interface swp1 de
leaf01. De même, l'interface swp51 de leaf01 est connectée à l'interface swp1
de spine01.
Ce chapitre configure deux routeurs : leaf01 et spine01. Nous pouvons

ensuite prendre cette configuration et l'appliquer à d'autres nœuds spine et
feuille avec leurs adresses IP et paramètres BGP spécifiques.
Les difficultés d'automatisation du BGP traditionnel

Exemple 3-1 montre les configurations les plus simples possibles de leaf01
et leaf02. Pour ceux qui découvrent BGP, quelques mots rapides sur
certaines des déclarations clés de la configuration :
routeur bgp 65000

C'est ainsi que vous spécifiez l'ASN pour ce haut-parleur BGP. Cela marque
également le début du bloc de configuration spécifique à BGP dans FRR.
ID de routeur bgp 10.0.254.1

Chaque haut-parleur de protocole de routage a un identifiant-routeur qui identifie
le locuteur. Cela est vrai pour tous les protocoles de routage, y compris BGP. De
mauvaises choses s'ensuivent si cet ID n'est pas unique dans la plupart des
protocoles, c'est donc une bonne pratique de garder cet unique en le rendant
identique à l'adresse IP de bouclage.
ISL de groupe de pairs voisin

Dans FRR, c'est une façon de définir un modèle de configuration.
Les difficultés d'automatisation du BGP traditionnel | 29

voisin ISL distant-comme 65500
Il s'agit de la spécification de l'ASN de l'extrémité distante. Les configurations BGP
traditionnelles l'exigent. Nous verrons comment nous pouvons simplifier cela
dans le prochain chapitre.
voisin 169.254.1.0 groupe de pairs ISL

C'est ainsi que vous indiquez au démon BGP que vous souhaitez
établir une session avec l'adresse IP spécifiée, en utilisant les
paramètres spécifiés dans le modèle de configuration ISL.
monodiffusion ipv4 de la famille d'adresses

Étant donné que BGP est un protocole de routage multiprotocole, le
adresse-famille bloc spécifie la configuration à appliquer pour un
protocole spécifique (dans ce cas, monodiffusion ipv4).
ISL voisin activé

BGP vous oblige à déclarer explicitement que vous souhaitez qu'il annonce
l'état de routage pour une famille d'adresses donnée' et c'est ce que Activer
Est-ce que.
réseau 10.0.254.1/32
Cela indique à BGP d'annoncer l'accessibilité au préfixe
10.0.254.1/32. Ce préfixe doit déjà être dans la table de
routage pour que BGP l'annonce.
chemins-maximum 64
Cela indique à BGP qu'il doit utiliser plusieurs chemins, s'ils sont disponibles, pour
atteindre un préfixe.
La signification des divers temporisateurs a été discutée dans « Convergence lente en

raison des temporisateurs par défaut » à la page 24.
Exemple 3-1. Mise en évidence de la configuration spécifique au routeur sur

leaf01 et leaf02
// configuration BGP de leaf01
fichier journal /var/log/frr/frr.log
routeur bgp 65000

identifiant de routeur bgp 10.0.254.1
bgp log-neighbor-changes bgp
pas de timers ipv4-unicast par
défaut bgp 3 9
groupe de pairs voisin ISL voisin
ISL distant-as 65500

intervalle d'annonce ISL voisin 0 Les
temporisateurs ISL voisins se connectent 5
voisin 169.254.1.0 voisin ISL de groupe de
pairs 169.254.1.64 groupe d'homologues ISL
famille d'adresses ipv4 unicast
ISL voisin activé
réseau 10.0.254.1/32
réseau 10.1.1.0/26
chemins-maximum 64
adresse-de-sortie-famille
routeur bgp 65001

défaut bgp 3 9
groupe de pairs voisin ISL voisin ISL distant en
tant que 65500 voisin ISL annonce-intervalle 0
les temporisateurs ISL voisins se connectent 5

pairs 169.254.1.64 groupe d'homologues ISL
famille d'adresses ipv4 unicast
ISL voisin activé
réseau 10.0.254.1/32
réseau 10.1.1.0/26
chemins-maximum 64
Regardons d'abord leaf01 par lui-même pour voir ce qui y est dupliqué. Par
exemple, 10.0.254.1 est spécifié deux fois, une fois avec /32 et une fois sans.
La première fois, elle est spécifiée comme adresse de passerelle par défaut
et la deuxième fois comme interface.
La configuration est moins sujette aux erreurs lorsqu'il y a le moins de

duplication possible. C'est une maxime bien connue dans le codage pour éviter
de dupliquer le code. La duplication est problématique car avec plus d'endroits
pour corriger la même information, il est facile d'oublier de corriger l'un des
multiples endroits lors d'une modification ou de la résolution d'un problème. La
duplication est également lourde car une seule modification se traduit par des
modifications devant être apportées à plusieurs endroits.
Considérez les effets de la duplication de l'adresse IP à travers l'interface et

à l'intérieur de BGP. Si l'adresse IP de l'interface change, une modification
correspondante doit également être effectuée dans la configuration BGP.

Sinon, vous perdrez la connectivité après le changement. Un autre exemple est que
nous avons modifié l'adresse de passerelle par défaut sur ce nœud et l'avons affectée à
un autre nœud, mais nous avons oublié la modification duidentifiant-routeur.
Vous vous retrouveriez avec deux routeurs ayant le même identifiant-routeur, ce qui
pourrait entraîner des difficultés de peering (mais uniquement dans iBGP, pas eBGP).
La même chose s'appliquerait également aux déclarations de réseau.
De plus, cette configuration suppose un seul VLAN ou sous-réseau pour

chacun des vantaux. S'il y avait plusieurs sous-réseaux, les répertorier
individuellement ne serait pas évolutif. Ou, même si vous le faisiez, la
configuration résultante serait trop longue pour être lisible.
Comparons maintenant la configuration à travers les épines, comme indiqué dans

Exemple 3-2.
Exemple 3-2. Mise en évidence de la configuration spécifique au routeur sur

spine01 et spine02
// configuration BGP de spine01
routeur bgp 65534

défaut bgp 3 9
voisin 169.254.1.1 distant-comme 65000
pairs 169.254.1.3 distant-comme 65001
voisin 169.254.1.7 groupe de pairs ISL bgp
bestpath as-path multipath-relax address-
family ipv4 unicast
ISL voisin activé
réseau 10.0.254.254/32
chemins-maximum 64
// configuration BGP de spine02

routeur bgp 65534
défaut bgp 3 9
voisin 169.254.1.1 distant en tant que
voisin 65000 169.254.1.1 voisin ISL de
groupe de pairs 169.254.1.3 distant-
comme 65001 voisin 169.254.1.3 voisin ISL
de groupe de pairs 169.254.1.5 distant-
comme 65002 voisin 169.254.1.5 voisin ISL
de groupe de pairs 169.254.1.5 distant-
comme 65003 voisin 169.254.1.7 groupe
de pairs ISL bgp bestpath as-path
multipath-relax address-family ipv4 unicast
ISL voisin activé
réseau 10.0.254.254/32
chemins-maximum 64
Les mêmes problèmes qui étaient présents dans la configuration à travers les feuilles
sont également présents dans la configuration à travers les épines.
Cependant, il y a quelques choses bien faites dans cette configuration :
• Les adresses IP d'interface ont un modèle. En supposant que 32 ports

spines (32 × 100 Gbit/s et 32 × 40 Gbit/s sont courants de nos jours), 64
adresses IP d'interface sont requises. L'utilisation de sous-réseaux /31
sur chaque interface nous permet d'allouer un sous-réseau /26 sur les
deux épines.
• Les sous-réseaux d'adresse de passerelle par défaut sont annoncés à partir

d'un sous-réseau commun, différent des sous-réseaux alloués aux hôtes
finaux.
• En supposant 40 hôtes par rack, ce qui est en soi une extension dans tous les centres de
données sauf les plus grands, dans la configuration réseau, nous avons alloué /26 sous-
réseaux pour chaque sous-réseau associé aux hôtes.
Pour résumer les difficultés avec les configurations entre les nœuds, nous voyons
que l'utilisation d'adresses IP signifie que nous dupliquons des informations à
plusieurs endroits, et donc la configuration devient fragile et non évolutive à
mesure que de nouvelles adresses IP sont ajoutées et supprimées.

Bien que la détection de modèles dans les adresses IP voisines soit possible, elle est
également fragile dans la mesure où des modifications ultérieures peuvent briser les
hypothèses intégrées à la reconnaissance de modèles. Par exemple, si nous supposons
que nous avons numéroté les adresses en série, l'ajout ultérieur d'une nouvelle
colonne vertébrale peut casser ce modèle. Ainsi, au lieu que l'ajout soit simple, chaque
changement serait fragile et devrait être traité spécialement.
Comment, alors, surmonter ces problèmes? Il est temps de déballer quelques

outils de l'armurerie.
Redistribuer les itinéraires
Éliminer la spécification d'adresses IP individuelles à annoncer via

réseau instructions, nous pouvons utiliser une commande différente :
redistribuer.
Depuis à peu près leur première introduction, toutes les suites de protocoles de
routage ont fourni une option pour prendre les préfixes d'un protocole et
l'annoncer dans un autre. Cette pratique s'appelleredistribuer les itinéraires.
Le format de commande général dans BGP ressemble à ceci :
redistribuer protocole le plan de route nom-route-map
Les protocole est l'une des valeurs suivantes :
statique
Annoncez les routes qui ont été configurées de manière statique.
connecté
Annoncer les routes associées aux adresses d'interface. Les liens sur ces
interfaces doivent être actifs et opérationnels lorsque cette configuration
s'exécute. Si un lien échoue, son adresse IP est immédiatement supprimée.
noyau
Ceci est spécifique aux systèmes d'exploitation Linux. Les routes peuvent
être configurées statiquement soit par une suite de routage - FRRouting,
bird ou quagga, par exemple - soit directement dans le noyau, soit via un
ensemble d'outils tel que iproute2 (leip famille de commandes) ou
directement via l'interface netlink vers le noyau lui-même.
ospf
Redistribuez les routes apprises via le protocole OSPF.

bgp
Redistribuez les routes apprises via le protocole BGP.
déchirure
Redistribuez les routes apprises via le protocole RIP (Routing

Information Protocol).
Certains autres protocoles moins courants peuvent également être représentés, tels que IS-IS.
Ainsi, pour annoncer les adresses IP d'interface de tous les VLAN sur la box
et la passerelle par défaut, il suffit de remplacer toutes les déclarations
réseau par une seule commande :
redistribuer connecté
La configuration sur leaf01 ressemblerait à ceci après le remplacement rapporter

travail déclarations avec redistribuer:

routeur bgp 65000
bgp router-id 10.0.254.1 bgp log-
neighbor-changes bgp pas de
timers ipv4-unicast par défaut
bgp 3 9

adresse-famille ipv4 unicast
ISL voisin activé
redistribuer connecté
chemins-maximum 64
Cependant, l'utilisation d'une déclaration de redistribution sans fioritures conduit

à des adresses potentiellement publicitaires qui ne devraient pas l'être, telles que
les adresses IP d'interface, ou à propager des erreurs de configuration. A titre
d'exemple de ce dernier, si un opérateur a accidentellement ajouté une adresse
IP de 8.8.8.8/32 sur une interface, le BGP annoncera l'accessibilité à cette adresse,
envoyant ainsi toutes les requêtes destinées au serveur DNS public, bien connu, à
ce malheureux routeur mal configuré.
Pour éviter tous ces problèmes, à peu près tous les protocoles de routage prennent en charge
une certaine forme de politique de routage.
Redistribuer les itinéraires | 35

Politique de routage
La politique de routage, dans sa forme la plus simple, spécifie quand accepter ou

rejeter les annonces de routage. Selon l'endroit où ils sont utilisés, l'acceptation ou le
rejet peuvent s'appliquer aux routes reçues d'un pair, aux routes annoncées à un pair
et aux routes redistribuées. Dans sa forme la plus complexe, la politique de routage
peut modifier les métriques qui affectent la sélection du meilleur chemin d'un préfixe,
et ajouter ou supprimer des attributs ou des communautés d'un préfixe ou d'un
ensemble de préfixes. Étant donné l'utilisation de BGP principalement pour connecter
différents domaines administratifs, BGP a les constructions de politique de routage les
plus sophistiquées.
Une politique de routage consiste généralement en une séquence d'instructions if-then-else, avec des
correspondances et des actions à entreprendre en cas de correspondance réussie.
Alors que nous avons jusqu'à présent évité l'utilisation de toute politique de routage, nous pouvons
maintenant voir la raison de leur utilisation avec BGP dans le centre de données.
Par exemple, pour éviter le problème de la publicité 8.8.8.8, comme

décrit dans la section précédente, le pseudocode pour la politique de
routage ressemblerait à ce qui suit (nous développons ce pseudocode
en syntaxe de configuration réelle à la fin de cette section) :
si le préfixe est égal à '8.8.8.8/32' alors rejeter sinon accepter
Dans une configuration où les routes connectées sont redistribuées, une

politique sûre serait d'accepter les routes qui appartiennent à ce centre de
données et d'en rejeter les autres. Les configurations que j'ai montrées
contiennent deux types de préfixes : 10.1.0.0/16 (en supposant qu'il existe de
nombreux sous-réseaux orientés vers l'hôte dans le réseau) et l'adresse IP de
bouclage du routeur, par exemple 10.0.254.1/32. Nous voyons également le sous-
réseau d'adresse d'interface, 169.254.0.0/16, qui ne doit pas être annoncé. Ainsi,
un premier essai d'une politique de routage serait le suivant :
si le préfixe est égal à 10.1.0.0/16 alors acceptez

else si le préfixe est égal à 10.0.254.1/32 alors accepter
sinon rejeter
Cependant, cela nous oblige à mettre une autre le plan de route clause pour
chaque routeur car chaque routeur a une adresse IP de bouclage différente. Si à
la place nous choisissons le sous-réseau à partir duquel ces adresses sont
allouées, 10.0.254.0/24, lele plan de route devient le même sur tous les routeurs.
Cependant, comme l'adresse IP de bouclage d'un routeur est contenue dans ce
sous-réseau et n'est pas égale à ce sous-réseau, nous ne pouvons pas utiliser
préfixe est égal. Au lieu de cela, nous introduisons un nouveau

qualificatif, fait parti, qui vérifie si une adresse IP appartient au sous-
réseau spécifié. Voici le pseudocode nouvellement réécrit pour la
politique de routage :
si le préfixe appartient à 10.1.0.0/16 alors acceptez

else si le préfixe appartient à 10.0.254.0/24 alors accepter
sinon rejeter
Mais cela accepterait toute personne annonçant accidentellement le sous-réseau

10.0.254.0/26, par exemple, lorsque les préfixes autorisés sont les adresses
précises des boucles de routeur, qui sont toutes des adresses /32. Comment
pouvons-nous régler cela? En ajoutant plus de qualificatifs :

else if (le préfixe appartient à 10.0.254.0/24 et
le masque d'adresse est égal à 32) puis
acceptez
sinon rejeter
Le qualificatif que nous avons ajouté, le masque d'adresse est égal, nous permet de faire
correspondre les adresses plus précisément en prenant en compte non seulement l'adresse,
mais également le masque d'adresse.
Étant donné que plusieurs de ces politiques de routage sont possibles, donnons un
nom à cette politique et en faisons une fonction ainsi :
ACCEPT_DC_LOCAL(préfixe) {

else si (10.0.254.0/24 contient le préfixe et
sous-réseau est égal à 32) puis
J'accepte
sinon rejeter
}
À peu près toutes les configurations de réseau que j'ai vues utilisent
toutes les majuscules pour le plan de route et liste-préfixe noms.
Bien qu'il ne s'agisse que d'un nom et que les opérateurs soient
libres de choisir leurs conventions—toutes les majuscules, camelCase
ou autre—il est utile d'être conscient des conventions.
Route-Maps
le plan de routeLes s sont un moyen courant d'implémenter des politiques de
routage. L'IOS de Cisco, NXOS, la suite de protocoles open source FRRouting,
Arista et d'autres prennent en chargele plan de routes. JunOS utilise une syntaxe
différente avec, selon certains, des mots-clés plus intuitifs. La suite de routage
open sourceOISEAU va plus loin et utilise un simple domaine spécifique
Politique de routage | 37
langage de programmation au lieu de cette combinaison de le plan de route
sable liste-préfixes. Les détails de la description dépassent le cadre de ce
livre, mais si vous êtes intéressé, vous pouvez trouver les détails sur les
pages Web de BIRD.
le plan de routes ont la syntaxe suivante :
le plan de route NOM (autoriser|refuser) [numéro_séquence]

rencontre classificateur
ensemble action
Cela attribue un nom à la stratégie, indique si les routes correspondantes seront

autorisées ou refusées, puis compare les entrées à un classificateur. Si un
rencontre la clause correspond avec succès à un classificateur, la ensemble
clause agit sur la route. L'optionnelnuméro de séquence ordonne que la
séquence de clauses soit exécutée dans un le plan de route.
Lorsque nous utilisons le permis mot-clé, le ensemble l'action est appliquée

lorsque le match réussit, mais lorsque nous utilisons le Nier mot-clé, le ensemble
l'action est appliquée lorsque la correspondance échoue. En d'autres termes,Nier fonctionne
comme un opérateur « pas » : s'il y a une correspondance, rejeter la route.
le plan de routes ont un "refuser" implicite à la fin. Ainsi, si aucune entrée ne

correspond, le résultat est de rejeter l'entrée.
Classificateurs dans les feuilles de route
le plan de routes sont livrés avec un riche ensemble de classificateurs. Vous pouvez utiliser une
grande variété de traits comme classificateurs, et différentes implémentations prennent en

charge différents sous-ensembles de ces classificateurs (certains prennent en charge tous et
plus). La liste enTableau 3-1 est extrait de la liste de FRRouting.
Tableau 3-1. Les classificateurs clés dans le champ de correspondance d'unle plan de route
comme-chemin Correspond à la valeur de AS_PATH de BGP
communauté Valeur de correspondance de la communauté d'un préfixe, le cas échéant Valeur de
communauté externe correspondance de la liste de communauté étendue de BGP Nom de
interface correspondance de l'interface de tronçon suivant de la route
ip, ipv6 Faire correspondre les informations IP telles que l'adresse IP, le prochain saut ou la source
préférence-locale Faire correspondre LOCAL_PREFERENCE de l'itinéraire
métrique Faire correspondre le champ métrique de la route Faire
origine correspondre l'attribut ORIGIN de la route Faire
pair correspondre les informations de l'homologue de la session

Comme exemple de politique de routage utilisant des préfixes IP comme classificateurs,
commençons par examiner comment deux préfixes sont définis :
ip prefix-list DC_LOCAL_SUBNET seq 5 permit 10.1.0.0/16 le 26 ip prefix-list

DC_LOCAL_SUBNET seq 10 permit 10.0.254.0/24 le 32
Ces commandes définissent ensemble une liste unique appelée RESEAU

DC_LOCAL_SUB qui contient deux préfixes : 10.1.0.0/16 et 10.0.254.0/24. Dans les deux
cas, faire correspondre n'importe quel préfixe à cette liste vérifie si le préfixe
correspond exactement ou s'il est contenu dans les préfixes fournis. Dans ce cas,
10.0.254.0/24 le 32 indique spécifiquement que toute correspondance doit être sur
un sous-réseau qui est /32. Même s'il est dit « inférieur ou égal à », dans IPv4, il
n'y a pas de sous-réseau inférieur à /32, et cela fonctionne donc comme une
correspondance exacte pour les préfixes /32 uniquement.
suite <nombre> est utilisé pour identifier l'ordre des correspondances. Par
exemple, si vous vouliez rejeter 10.1.1.1/32 mais autoriser 10.1.1.0/24, la bonne
façon de commander leliste-préfixes utilisant le numéro de séquence serait
comme suit :
ip prefix-list EXAMPLE_SEQ seq 5 deny 10.1.1.1/32 ip prefix list

EXAMPLE_SEQ seq 10 permit 10.1.1.0/24
Pour permettre aux clauses d'être insérées au milieu d'une commande existante, une
pratique courante consiste à séparer les numéros de séquence avec un certain écart. Dans
l'exemple, nous avons utilisé un écart de 5.
Maintenant, nous pouvons définir un le plan de route faire correspondre les deux préfixes avec le
DC_LOCAL_SUBNET Nom. Ce qui suit est lele plan de route équivalent du

pseudocode de politique de route if-then-else décrit plus tôt dans la
section de politique de routage, et inclut le redistribuer commande qui
prend en compte cette politique :
ip prefix-list DC_LOCAL_SUBNET seq 5 permit 10.1.0.0/16 le 26 ip prefix-list

DC_LOCAL_SUBNET seq 10 permit 10.0.254.0/24 le 32 route-map
ACCEPT_DC_LOCAL permit 10
correspondre à l'adresse IP DC_LOCAL_SUBNET
redistribuer la route-map connectée DC_LOCAL_SUBNET
Voici l'équivalent en pseudocode de ceci le plan de route:
DC_LOCAL_SUBNET(préfixe) {
if (le préfixe appartient à 10.1.1.0/26 et prefixlen <= 26 ou le préfixe

appartient à 10.0.254.0/24 et prefixlen <= 32) alors redistribue la
route connectée
}
Au lieu de préfixes IP, nous pouvons également utiliser n'importe lequel des autres
classificateurs. Par exemple, si tout ce que nous devons faire est d'annoncer l'adresse IP de
bouclage principale du routeur, les lignes de configuration sont les suivantes :
carte de route ADV_LO permis 10

interface de correspondance lo
redistribuer la route-map connectée ADV_LO
Notez que cela n'annoncera pas l'adresse hôte-local 127.xxx associée à

l'interface de bouclage, mais seulement les adresses IP accessibles
globalement.
Rédaction de politiques de route-map sécurisées
Il existe des manières sécurisées et non sécurisées d'écrire une politique de

routage. Le principe fondamental est le suivant : rejetez toujours tout ce qui n'est
pas explicitement autorisé. Considérons cela en regardant un exemple. Il n'est
pas rare de vouloir annoncer des adresses IP sur toutes les interfaces sauf celles
sur les interfaces de liaison montante (inter-commutateur)swp51 et swp52, et
l'interface de gestion, eth0. Voici une façon d'écrire la configuration :
route-map EXCEPT_ISL_ETH0 refuser 10

interface de correspondance swp51

interface de correspondance swp52

correspondre à l'interface eth0
route-map EXCEPT_ISL_ETH0 permis 40
redistribuer la route-map connectée EXCEPT_ISL_ETH0
Le final permis la configuration permet à travers n'importe quelle interface qui ne

correspond pas à l'un des nier la route-maps.
Voici l'équivalent en pseudo-code de ce le plan de route:

EXCEPT_ISL_ETH0(interface) {
si l'interface n'est pas swp51 et

l'interface n'est pas swp52 et
l'interface n'est pas eth0 alors
redistribuez connecté
}
L'avantage de cette approche est qu'elle vous permet de changer d'interface

librement et d'utiliser des adresses IP non contiguës pour celles-ci, sans
changer le le plan de route ou en modifiant la configuration BGP. Le dis‐

l'avantage est que toute nouvelle interface qui propose une adresse IP valide
verra son adresse IP immédiatement publiée, que l'administrateur l'ait voulu ou
non. Par conséquent, cela est considéré comme une approche non sécurisée que
vous ne devez jamais utiliser dans la configuration de la politique de routage.
L'alternative peut être fastidieuse s'il y a beaucoup d'interfaces dont les

adresses doivent être annoncées. Les implémentations typiques des suites
de routage ne permettent pas la spécification de plusieurs interfaces via une
syntaxe telle queswp1-49 (inclure toutes les interfaces de swp1 par
swp49). Dans de tels cas, le recours à l'utilisation d'adresses IP qui peuvent être
une liste plus petite peut être une option si l'adressage IP utilisé sur les interfaces
provient de quelques sous-réseaux seulement.
cartes de route dans BGP
Outre les itinéraires redistribués, vous pouvez appliquer le plan de routes à

plusieurs autres endroits pendant le traitement BGP. Voici quelques exemples:
• À l'aide de le plan de routes pour filtrer les préfixes à accepter

dans une annonce d'un voisin :
voisin 169.254.1.1 route-map NBR_RT_ACCEPT dans
• À l'aide de le plan de routes pour filtrer quelles routes quelles routes

annoncer à un voisin :
voisin 169.254.1.1 route-map NBR_RT_ADV en sortie
• Filtrage des itinéraires envisagés pour la publicité via un réseau

déclaration:
réseau 10.1.1.1/24 route-map ADV_NET
• Itinéraires par défaut de la publicité :
voisin foo default-originate route-map ONLY_NON_EXITS
Effet des route-maps sur le traitement BGP
BGP est un protocole de routage à vecteur de chemin et n'annonce donc pas les
mises à jour de route tant qu'il n'exécute pas l'algorithme du meilleur chemin. le
plan de routes sont appliqués à la réception et à l'envoi de paquets. Si un haut-
parleur BGP a des dizaines ou des centaines de voisins et qu'il y ale plan de routes
attaché à ces voisins, exécutant le le plan de route pour chaque voisin avant
d'annoncer la route devient gourmande en CPU et ralentit le
envoi de mises à jour. Un traitement de mise à jour lent peut également entraîner des temps de
convergence médiocres.
Par conséquent, groupe de pairss sont souvent utilisés avec le plan de routes pour
réduire considérablement la quantité de traitement que BGP doit effectuer avant
d'annoncer une route à ses voisins. Au lieu de s'appuyer uniquement sur des groupes
de pairs configurés par l'utilisateur, les implémentations construisent généralement
ces groupes de manière dynamique. C'est parce que même au sein d'un seulgroupe de
pairs, différents voisins peuvent prendre en charge différentes capacités (par exemple,
certains peuvent prendre en charge MPLS et d'autres pas). Ces informations ne
peuvent être déterminées que lors de l'établissement de la session. Ainsi, la
configuration de l'utilisateur n'aide pas ou impose une charge excessive à l'utilisateur
pour s'assurer que tous les voisins d'un groupe de pairs prennent en charge
exactement les mêmes capacités.
Ainsi, une implémentation qui prend en charge la création et la suppression

dynamiques de groupes de pairs place tous les voisins qui ont la même politique
de route sortante et les mêmes capacités dans un nouveau groupe de pairs créé
dynamiquement ou, plus précisément, un groupe de mise à jour dynamique. BGP
exécute la stratégie une fois pour un préfixe qui englobe l'ensemble du groupe
de pairs. Le résultat est ensuite automatiquement appliqué à chaque membre de
ce groupe de pairs construit dynamiquement. Cela permet aux implémentations
d'évoluer pour prendre en charge des centaines voire des milliers de voisins.
Utilisation des noms d'interface comme voisins
Comme nous utilisons des adresses /31 pour les adresses IP d'interface, il est
facile de déterminer l'adresse IP d'interface de l'homologue. Par exemple, si une
extrémité a une adresse IP de 169.254.1.0/31, l'adresse IP de l'extrémité de
l'interface est évidemment 169.254.1.1/31. De même, si une extrémité a une
adresse IP de 169.254.1.64/31, l'autre extrémité a une adresse IP de
169.254.1.65/31. La même chose serait vraie si les sous-réseaux /30 étaient utilisés
pour les adresses d'interface.
FRRouting utilise cette astuce pour permettre aux utilisateurs de substituer le

nom de l'interface dans les déclarations de voisin au lieu de spécifier des
adresses IP. Cela modifie la configuration du voisin dans leaf01 de

à:

voisin swp51 interface groupe d'homologues ISL
voisin swp52 interface groupe d'homologues ISL
Lorsque le code BGP dans FRRouting rencontre un nom d'interface dans la

déclaration de voisin, il vérifie si l'interface a une adresse IPv4 qui est un /30
ou un /31. Si tel est le cas, BGP identifie automatiquement l'adresse IP de
l'extrémité distante et lance une session BGP vers cette adresse IP. Si
l'adresse IP n'est pas un /30 ou /31 et qu'il existe une adresse IPv4 sur le
lien, le code imprime un avertissement et arrête d'essayer d'établir une
connexion.
L'utilisation de noms d'interface au lieu d'adresses IP rend la

configuration à travers les feuilles et les épines assez similaire, car
Exemple 3-3 spectacles.
Exemple 3-3. Configuration BGP des feuilles à l'aide des noms d'interface
ip prefix-list DC_LOCAL_SUBNET 5 permit 10.1.0.0/16 le 26 ip prefix-list

DC_LOCAL_SUBNET 10 permit 10.0.254.0/24 le 32 route-map
routeur bgp 65000

bgp 3 9
voisin swp51 groupe de pairs ISL

ISL voisin activé
redistribuer les routes-map DC_LOCAL connectées
maximum-paths 64

DC_LOCAL_SUBNET 10 permit 10.0.254.0/24 le 32
Utilisation des noms d'interface comme voisins | 43

route-map ACCEPT_DC_LOCAL permis 10
routeur bgp 65001

bgp 3 9

ISL voisin activé
redistribuer les routes-map DC_LOCAL connectées
maximum-paths 64
La configuration à travers les épines est également la même, à l'exception des

modifications apportées à la identifiant-routeur et l'ASN du voisin. Voici le résultat :
ip prefix-list ACCRT 5 permit 10.1.0.0/16 le 26 ip prefix-list

ACCRT 10 permit 10.0.254.0/24 le 32 route-map DC_LOCAL
permit 10
correspondre à l'adresse IP ACCRT
routeur bgp 65500

bgp router-id 10.0.254.254 bgp
log-neighbor-changes bgp pas
de timers ipv4-unicast par
défaut bgp 3 9
voisin swp1 distant-as 65000 voisin
swp1 groupe de pairs ISL voisin
swp2 distant-as 65001 voisin swp2
groupe de pairs ISL voisin swp3
distant-as 65002 voisin swp3
groupe de pairs ISL voisin swp4
distant-as 65003 voisin swp4
groupe de pairs ISL
bgp bestpath as-path multipath-relax
address-family ipv4 unicast
ISL voisin activé
redistribuer la route-map connectée DC_LOCAL

chemins-maximum 64
La même politique de routage est appliquée à travers la feuille et la colonne vertébrale.
L'utilisation de noms d'interface au lieu d'adresses IP ne se limite pas uniquement à la

configuration. Toutes les commandes show et clear pertinentes (nous en parlons dans
Chapitre 5) peut également prendre des noms d'interface.
L'utilisation de noms d'interface au lieu d'adresses IP prend en charge l'autre

principe cardinal d'une bonne configuration : la duplication réduite. Avec
les deux redistribuer connecté et voisin déclarations, la seule
L'endroit où l'adresse IP de l'interface est spécifiée est dans la configuration
de l'interface.
Si vous êtes familiarisé avec l'automatisation, vous pourriez vous demander comment le remplacement des adresses IP
par des noms d'interface le rend plus convivial pour l'automatisation. Pourquoi l'utilisation de variables pour gérer les
différences entre les routeurs ne suffit-elle pas ? En fin de compte, l'automatisation implique une sorte de logique de
programmation et, selon l'outil, la logique peut être simple ou complexe. Mais la simplicité du code d'automatisation est
cruciale pour réduire les erreurs. De nombreuses études montrent que les erreurs causées par l'opérateur sont la
deuxième raison la plus courante des pannes de réseau. Avec l'automatisation, nous introduisons un niveau d'abstraction
ainsi que la possibilité de faire des ravages sur un plus grand nombre de routeurs instantanément. Par exemple, une
approche du câblage peut être que l'opérateur utilise différents ports sur différentes feuilles pour connecter des liaisons
inter-commutateurs. Étant donné que les ports de chaque nœud sont différents, l'utilisation de variables par nœud pour
définir les ports de liaison montante peut entraîner une mauvaise conception du réseau physique. Mais ces variables
créent un niveau d'abstraction et masquent ainsi le problème si les opérateurs ne font pas attention. Avec un câblage
uniforme, l'opérateur peut éliminer le besoin de définir des variables pour les ports de liaison montante à travers les
différents nœuds. De même, bien que cela ne soit pas toujours possible, une configuration exempte d'adresses IP signifie
que la configuration peut être largement utilisée, telle que la réutilisation sur plusieurs pods ou dans l'installation de
nouveaux centres de données. l'opérateur peut éliminer le besoin de définir des variables pour les ports de liaison
montante à travers les différents nœuds. De même, bien que cela ne soit pas toujours possible, une configuration
exempte d'adresses IP signifie que la configuration peut être largement utilisée, telle que la réutilisation sur plusieurs
pods ou dans l'installation de nouveaux centres de données. l'opérateur peut éliminer le besoin de définir des variables
pour les ports de liaison montante à travers les différents nœuds. De même, bien que cela ne soit pas toujours possible,
une configuration exempte d'adresses IP signifie que la configuration peut être largement utilisée, telle que la réutilisation
sur plusieurs pods ou dans l'installation de nouveaux centres de données.
Sommaire
Ce chapitre a tiré les premiers coups pour rendre la configuration BGP plus conviviale
pour l'automatisation. Tout d'abord, nous avons utilisé la politique de routage pour
remplacer les adresses IP des déclarations de réseau individuelles par un seulredis
hommage connecté directive avec une feuille de route qui garantit que
Résumé | 45
seules les adresses appropriées sont annoncées. Ensuite, en nous appuyant sur
le petit nombre d'adresses couvertes par les sous-réseaux /30 et /31 (ce qui
facilite la détermination de l'adresse IP de l'extrémité distante une fois que
l'adresse IP de l'extrémité locale est connue), nous réduisons la configuration
pour utiliser des noms d'interface au lieu d'IP adresses pour identifier un pair.
Cependant, nous n'avons pas encore terminé. Ce que cette configuration cache,
c'est que les interfaces ont toujours besoin d'une configuration d'adresse IP,
même si elles sont cachées de la configuration BGP et non dupliquées. De plus, la
configuration repose toujours sur la connaissance de l'ASN du pair. DansChapitre
4, nous éliminons ces deux exigences.

CHAPITRE 4
Réinventer la configuration BGP
Ce chapitre montre comment la configuration du routeur peut être réduite en

éliminant complètement les adresses IP d'interface et en spécifiant le remote-as
de chaque voisin. Ces deux améliorations rendront la configuration d'un routeur
BGP dans le centre de données un jeu d'enfant et l'automatisation un jeu
d'enfant.
Dans chapitre 3, nous avons montré comment éliminer l'utilisation des adresses
IP de la configuration BGP. Cependant, l'opérateur doit toujours configurer les
adresses IP sur les interfaces pour le peering BGP. Étant donné que ces adresses
d'interface ne sont jamais utilisées pour autre chose que la configuration BGP et
que leurs informations ne sont jamais propagées via BGP, leur configuration est
un vestige insignifiant du monde des fournisseurs de services dans le centre de
données. Un autre problème mentionné vers la fin de
chapitre 3 sur l'automatisation de la configuration est la nécessité de connaître le
distant-comme du pair.
Après avoir éliminé ces deux exigences, nous nous retrouvons avec
une configuration homogène et sans duplication entre les nœuds,
le seul contenu spécifique au nœud étant l'ASN du nœud et son
identifiant-routeur. En d'autres termes, la configuration est très conviviale pour
l'automatisation et simple.
Pour atteindre ces objectifs, nous aurons besoin de comprendre un sujet presque aussi
ancien que le routage : les interfaces non numérotées, et comment nous adaptons cette
construction à BGP.
47
Le besoin d'adresses IP d'interface et d'adresses
distantes
Comme BGP fonctionne sur TCP/IP, il a besoin d'une adresse IP pour
créer une connexion. Comment identifier l'adresse de ce nœud distant
tout en n'allouant aucune adresse IP sur les interfaces ? Répondre à
cette question impliquera de comprendre une RFC moins connue et les
outils de configuration sans état fournis par IPv6. Il s'agit également de
comprendre le véritable cœur du routage.
Le deuxième problème est que chaque configuration BGP repose sur la

connaissance de l'ASN distant. Mais cet ASN n'est vraiment requis que pour
une seule chose : identifier si la session est régie par les règles du BGP
interne (iBGP) ou du BGP externe (eBGP).
Les nombres sur les interfaces numérotées

La configuration d'adresses IP sur une interface est-elle vraiment un gros
problème ? Combien peut-il y en avoir de toute façon ?
Considérez un simple Clos à deux niveaux avec 4 épines et 32 feuilles, un réseau

assez commun. Chaque épine a 32 liens, un à chaque feuille, et il y a 4 épines.
Cela nécessite 4 * 32 * 2 = 256 adresses IP (4 épines * 32 interfaces * 2 adresses
par interface, une pour chaque extrémité). Si le nombre de feuilles devenait 96 au
lieu de 32 - encore une fois ce qui n'est pas rare dans les réseaux de taille
moyenne - le nombre total d'adresses IP d'interface dont nous aurions besoin
serait de 4 * 96 * 2 = 768. Au fur et à mesure que nous augmentons l'échelle,
disons à 16 épines, le nombre total d'adresses passerait à 16
* 96 * 2 = 3 072.
Bien qu'il soit possible de dériver ces nombres de manière algorithmique, cela
peut être maladroit et sujet aux erreurs. Le code d'automatisation devient plus
délicat. Une approche très courante consiste à stocker les adresses d'interface
sous la forme d'une liste ou d'un groupe de variables, et dans le programme
d'automatisation, de lire à partir de ces variables pour affecter les adresses aux
interfaces. Cette méthode devient impossible à utiliser.
48 | Chapitre 4 : Réinventer la configuration BGP

Le plus triste dans tout cela est que ces adresses ne sont utilisées que pour des
sessions BGP. Alors pourquoi ne pas s'en débarrasser complètement ?
A part philosophique sur les interfaces numérotées
L'attribution d'une adresse IP à chaque point de terminaison d'interface adressable est

une pratique assez fondamentale dans une conception traditionnelle de couche 3 (L3).
Mais cette conception laisse la question de savoir à qui appartient une adresse IP :
l'interface ou le nœud ?
Une question pratique impliquée par cette confusion d'identité est la

suivante : « Un nœud peut-il répondre à une demande de protocole de
résolution d'adresse (ARP) reçue sur une interface pour une adresse IP
attribuée au nœud mais non attribuée à cette interface particulière ? » Les
routeurs ont répondu à cette question par un « Non » retentissant. Si vous
souhaitez activer un tel comportement sur un routeur, vous devez activer
une fonctionnalité appelée « proxy-arp ». Linux a répondu à la même
question par un « Oui » retentissant. Le raisonnement des implémenteurs de
Linux était qu'ils voulaient permettre la communication dans toute la mesure
du possible. Ainsi, le nœud est libre de répondre à une demande ARP pour
n'importe quelle adresse IP qu'il possède, quelle que soit l'interface sur
laquelle la demande ARP est reçue.
La conception du protocole ICMP (Internet Control Message Protocol) a

renforcé l'idée que les interfaces avaient besoin d'adresses IP. ICMP ne
signale que l'adresse IP du point de terminaison où le transfert de
paquets a échoué. Il ne signale pas, par exemple, le nom DNS du point
de terminaison. Pourquoi est-ce important, demandez-vous?
Traceroute. Traceroute est un outil ancien, puissant et populaire que les
gens utilisent pour déboguer les problèmes de connectivité dans le
réseau. Si la réponse ICMP rapporte l'adresse IP de l'interface, il est
possible d'identifier non seulement le nœud, mais également l'interface
entrante sur laquelle le paquet pauvre a été rejeté. Ces informations
peuvent ensuite être utilisées pour trouver la cause première du
manque de connectivité. L'une des questions les plus fréquentes qu'on
me pose est de savoir si traceroute fonctionne avec des interfaces non
numérotées (oui, c'est le cas,
Enfin, s'assurer que les deux extrémités d'une interface ont reçu des
adresses du même sous-réseau pourrait être une mauvaise façon de vérifier
un câblage correct.
Les numéros sur les interfaces numérotées | 49

Interfaces non numérotées
Les premiers architectes de réseau avaient également exploré l'autre branche
dans cette décision de conception : ne pas attribuer une adresse IP unique à
chaque interface d'un nœud. Une interface sans adresse IP propre était appelée
une interface « non numérotée ».
Ce n'est pas que l'interface n'a pas d'adresse IP ; il emprunte son adresse IP
à une autre interface. Mais si l'interface à laquelle l'adresse IP est
empruntée tombe en panne, son adresse IP ne peut plus être empruntée.
Pour éviter que les interfaces ne perdent subitement leurs adresses IP, les
interfaces empruntent l'adresse IP à une interface qui ne fait jamais défaut :
l'interface de bouclage.
Les routeurs peuvent répondre aux ARP sur des interfaces non numérotées avec
l'adresse MAC locale de l'interface reçue car l'interface a une adresse IP, même si
elle est empruntée. ICMP, avec traceroute, fonctionne toujours. Mais, si une
adresse IP n'est plus unique sur un nœud, ne perdons-nous pas la possibilité
d'identifier l'interface sur laquelle le paquet est entré dans un routeur ?
Les réseaux Clos sont principalement construits avec un seul lien entre
chaque paire de nœuds. Ainsi, il est trivial d'identifier les liens entre les
nœuds et ainsi de dériver l'identité de l'interface entrante ou de
l'interface sortante. Si un réseau Clos a de multiples liens parallèles
entre les nœuds, il est difficile d'identifier l'interface spécifique parmi les
liens parallèles à l'origine d'un problème de connectivité. Cependant,
plusieurs liens parallèles entre les nœuds d'un réseau Clos ne sont pas
courants pour diverses raisons, qui sont discutées dans
Chapitre 1.
Alors, comment les protocoles de routage traitent-ils les interfaces non numérotées ?
OSPF, qui fonctionne sur IP, fonctionne bien. La RFC OSPF originale a fourni
suffisamment de conseils sur la façon de faire fonctionner ce scénario. Même si la
plupart des fournisseurs ne l'implémentent pas, la suite de routage open source
FRRouting prend en charge la même pratique. L'OSPF non numéroté est déployé en
production sur de nombreux sites. IS-IS, qui ne fonctionne même pas sur IP, fonctionne
également très bien avec des interfaces non numérotées.
BGP non numéroté

Tout cela est bien beau, mais comment BGP peut-il fonctionner dans un
monde sans adresses IP d'interface ?

Dans le monde des protocoles de routage, il y a un problème de poule et d'œuf. Si le
protocole de routage est la façon dont vous annoncez l'accessibilité à une route,
comment un protocole de routage lui-même sait-il comment atteindre son
homologue ? De nombreux protocoles résolvent ce problème en s'appuyant sur une
adresse de multidiffusion spécifique au lien (la multidiffusion est limitée pour être
distribuée uniquement sur le lien). BGP ne peut pas le faire car BGP s'appuie sur TCP,
qui nécessite des paquets en monodiffusion, pas en multidiffusion. La solution de BGP
consiste à utiliser un sous-réseau partagé sur les liens de l'interface reliant les routeurs.
N'oubliez pas que le routage n'est requis que si l'adresse IP de

destination se trouve dans un sous-réseau différent de l'adresse IP
source. Par exemple, dans un sous-réseau 10.0.0.0/24, le trafic au
sein du même sous-réseau, disons 10.0.0.1 et 10.0.0.10, circulera
sans nécessiter de configuration de routage supplémentaire. Les
systèmes connectés par IP utilisent le protocole ARP pour déterminer
l'accessibilité au sein d'un sous-réseau. Un paquet de
10.0.0.1 à 10.0.0.10 ne nécessiteront pas de routage, mais
un paquet de 10.0.0.1 à 10.0.1.1 le fera. Le parcours pour le
10.0.0.0/24 sur l'interface est appelé une route connectée
car le sous-réseau est supposé être directement accessible
(ou connecté) sur ce lien.
Pour en revenir à la façon dont les pairs BGP parviennent à

communiquer, les configurations eBGP traditionnelles ont utilisé la
route connectée sur une interface pour atteindre un voisin sans autre
configuration. Si l'adresse IP du pair n'est pas accessible via un sous-
réseau connecté, le routeur ne sait pas comment atteindre l'adresse IP
du pair sans autre configuration (ou en exécutant un autre protocole de
routage qui annonce cette adresse). Par exemple, si chaque nœud se
voyait attribuer uniquement une adresse IP /32 (où /32 implique que le
nœud est la seule entité de ce réseau), BGP serait incapable de
communiquer avec l'homologue. Pour atteindre l'adresse de
l'homologue, une route pour ce /32 explicite est nécessaire. Une telle
configuration supplémentaire impose une charge supplémentaire
indue à l'utilisateur. Cette route configurée statiquement est sur les
pairs du nœud,
BGP a d'autres options, telles que l'utilisation de voisins dynamiques (que

nous abordons dans Chapitre 6), mais aucun d'entre eux ne simplifie la
configuration de manière significative pour l'utilisateur.
BGP non numéroté | 51

Alors, comment pouvons-nous, sans configuration utilisateur et en utilisant des
adresses d'interface, découvrir l'adresse IP du pair ?
Entrez IPv6, et une norme obscure, RFC 5549.
Annonce du routeur IPv6

Les architectes IPv6 ont conçu IPv6 pour fonctionner autant que possible
sans configuration explicite. À cette fin, chaque lien d'un réseau IPv6 se voit
automatiquement attribuer une adresse IP qui n'est unique que pour ce
lien. Une telle adresse est appelée lalier l'adresse IPv6 locale. L'adresse
locale de liaison (LLA) est garantie d'être accessible uniquement par les pairs
directement connectés, et uniquement sur cette interface. Typiquement, un
LLA est dérivé de l'adresse MAC sur le lien.
Pour s'assurer que les hôtes découvrent automatiquement les routeurs voisins,
un nouveau protocole au niveau des liaisons appelé annonce de routeur (RA) a
été introduit. Lorsqu'il est activé sur une interface, RA annonce périodiquement
les adresses IPv6 de l'interface, y compris le LLA. Ainsi, une extrémité peut
déterminer automatiquement l'adresse IPv6 de l'autre extrémité.
IPv6 et RA sont tous deux implémentés de nos jours sur les hôtes et les
routeurs. Cela semble donc être un pas dans la bonne direction pour rendre
les adresses des pairs automatiquement détectables.
Pour être clair, l'utilisation d'IPv6 LLA n'oblige pas les opérateurs à
commencer à déployer IPv6 dans leurs réseaux. Il n'y a pas non plus de
tunneling d'aucune sorte, IPv4 dans IPv6 ou autre, dans ce que nous
essayons d'utiliser ici. L'IPv6 LLA est utilisé uniquement pour établir une
connexion TCP pour démarrer une session BGP. Outre l'activation d'IPv6 sur
un lien, qui est généralement activée automatiquement, et l'activation de
l'annonce de routeur IPv6 sur le lien, aucune autre connaissance d'IPv6 n'est
attendue de l'opérateur.
Même si l'adresse IP de l'homologue a été automatiquement découverte et

qu'une session BGP peut être établie, cela ne suffit pas pour obtenir un
réseau complètement fonctionnel.
RFC 5549
Même si nous pouvons maintenant potentiellement établir un peering BGP
sans nécessiter d'adresse IP d'interface, la publicité des routes nécessite
également un moyen de spécifier comment atteindre le routeur annonçant
les routes. Dans BGP, cela est signalé explicitement dans l'annonce de route
via l'attribut NEXTHOP. La section précédente a montré comment cette

pourrait travailler avec RA pour établir une session BGP sur IPv6. Nous pouvons
atteindre notre objectif d'interface non numérotée si une route IPv4 peut utiliser
une adresse IPv6 comme prochain saut.
Comme expliqué dans Chapitre 1, BGP est une suite de routage

multiprotocole et permet de transférer les annonces et les retraits de
plusieurs familles d'adresses sur une seule connexion. Ainsi, les messages
BGP IPv4 UPDATE peuvent être transportés sur une connexion IPv6 TCP,
tout comme les messages IPv6 UPDATE peuvent être transportés sur une
connexion IPv4 TCP. La publicité des routes IPv4 ou IPv6 dans ce cas
n'implique aucune forme de tunneling, automatique ou autre.
Dans le message UPDATE annonçant l'accessibilité aux routes, BGP inclut

l'adresse IP du prochain saut associée aux routes annoncées. Dans le cas
d'IPv4, cela est porté en tant qu'attribut NEXTHOP dans la section des
attributs principaux d'un message BGP UPDATE (les attributs sont comme
des notes Post-it qui fournissent des informations supplémentaires sur la
route annoncée). L'adresse nexthop est de la même famille que la route elle-
même. En d'autres termes, les routes IPv4 sont annoncées avec les
prochains sauts IPv4 et les routes IPv6 sont annoncées avec les prochains
sauts IPv6. Lors du transport d'une route IPv4 sur une session eBGP sur une
interface sans adresse IPv4, quelle est l'adresse IP nexthop à annoncer ? La
seule adresse disponible sur cette interface est l'IPv6 LLA. EntrerRFC 5549.
La RFC 5549 est une RFC quelque peu obscure, inventée dans les premières
années d'un nouveau siècle. Son but est de permettre l'annonce d'une route IPv4
et le routage d'un paquet IPv4 sur un réseau IPv6 pur. Ainsi, il fournit un moyen
de transporter des routes IPv4 avec un prochain saut IPv6. Vous avez bien lu : les
routes IPv4 avec un prochain saut qui est une adresse IPv6.
Voici un récapitulatif rapide du fonctionnement du routage pour comprendre

cela. Imaginez que l'entrée de route pour 10.1.1.0/24 est avec un prochain saut de
20.1.1.1/30 et une interface sortante de swp1.
1. À la réception d'un paquet destiné à 10.1.1.1, le routage utilise cette

entrée de route et décide que l'adresse IP du prochain saut est
20.1.1.1/30, et que c'est notre appareil swp1.
2. Pour livrer le paquet à 20.1.1.1, le routeur a besoin de l'adresse MAC
correspondante de 20.1.1.1. Si le routeur n'a pas d'entrée ARP pour
20.1.1.1 dans son cache ARP, il exécute arp pour obtenir l'adresse MAC
de 20.1.1.1 sur l'interfaceswp1.

3. La réponse ARP du routeur voisin remplit le cache ARP avec
l'adresse MAC de 20.1.1.1 sur l'interface swp1.
4. Le routeur colle ensuite cette adresse MAC comme adresse MAC de
destination sur le paquet, avec l'adresse MAC source de l'interface swp1,
et envoie le paquet sur son petit bonhomme de chemin.
Excepté pour obtenir l'adresse MAC à mettre sur le paquet, l'adresse IP

nexthop n'est pas du tout utilisée dans le paquet.
Dans le cas d'IPv6 également, l'adresse IPv6 de nexthop est utilisée pour
identifier l'adresse MAC de nexthop, en utilisant l'équivalent IPv6 d'ARP :
Neighbor Discovery (ND). Même en IPv6, le transfert vers la destination d'origine
n'implique que l'adresse MAC du prochain saut. L'adresse IP nexthop est utilisée
uniquement pour obtenir l'adresse MAC du nexthop.
La RFC 5549 s'appuie sur cette observation et fournit un schéma de codage

pour permettre à un routeur d'annoncer des routes IPv4 avec un nexthop
IPv6.
Transfert avec RFC 5549

Mais attendez, dites-vous, lecteur avisé. La table de routage elle-même est
structurée autour de l'hypothèse que chaque route IPv4 a un prochain saut IPv4,
alors qu'une route IPv6 a un prochain saut IPv6. La RFC 5549 elle-même ne fait
rien d'autre que vous permettre de contourner un problème BGP. En continuant
plus loin, dites-vous sur un rouleau, cela ne nécessitera-t-il pas que le transfert de
route IPv4 atteigne la partie IPv6 de la pile, brisant la superposition, l'isolement
du protocole et Dieu sait quoi d'autre ? La solution ne nécessitera-t-elle pas un
support matériel, étant donné que le matériel fait à peu près ce qu'une
implémentation logicielle fait dans le routage des paquets ?
Une implémentation naïve exigerait en effet tout cela. Mais alors, il ne faut
pas être si naïf. Bien que la RFC 5549 ait été implémentée dans quelques
routeurs traditionnels, l'accès à la suite open source FRRouting nous permet
d'examiner de plus près comment fonctionne une implémentation non
naïve.
FRRouting implémente IPv6 RA nativement. IPv6 RA a également la possibilité de

transporter l'adresse MAC de l'expéditeur. FRRouting utilise cette option pour
annoncer sa propre adresse LLA et MAC. Lors de la réception d'un paquet RA, le
code RA du nœud voisin dans FRRouting obtient l'adresse MAC et le LLA IPv6
associé. Maintenant que l'adresse d'appairage de l'interface est connue,
FRRouting lance BGP en action pour démarrer la con‐

établissement de liaison. Ceci est également illustré par le diagramme chronologique
d'échange de paquets dansFigure 4-1.
Figure 4-1. Séquence chronologique des paquets non numérotés BGP
Une fois qu'une connexion a été établie avec succès, BGP reçoit une
annonce de route pour le 10.1.1.0/24 susmentionné de l'homologue avec le
LLA IPv6 de l'homologue (et l'adresse IPv6 globale si elle est configurée). Si
BGP sélectionne ce chemin comme le meilleur chemin à atteindre
10.1.1.0/24, il transmet cette route au processus Routing Information
dataBase (RIB) (appelé zebra dans FRRouting), avec le prochain saut
défini sur IPv6 LLA, cette information de prochain saut étant reçue dans
le message BGP UPDATE.
RIB est une collection de toutes les routes reçues de chaque

protocole de routage s'exécutant sur le nœud et des routes
configurées de manière statique. S'il y a plusieurs annonceurs pour
un itinéraire, le processus RIB en choisit un avec la valeur la plus
faible d'un champ appelé distance. Il existe des valeurs par défaut
pour la distance pour chaque protocole, mais l'utilisateur peut
également les modifier.
Lors de la réception d'une route pour 10.1.1.0/24 avec un LLA IPv6, supposons
que le RIB la sélectionne comme la meilleure route avec laquelle remplir la table
de transfert. Le processus RIB consulte désormais sa base de données pour voir

s'il dispose des informations relatives à l'adresse MAC associée à ce LLA
IPv6. Que cette adresse MAC soit 00:00:01:02:03:04. Le processus RIB
ajoute maintenant une entrée ARP statique pour 169.254.0.1 avec cette
adresse MAC, indiquant l'interface de peering. 169.254.0.1 est un LLA
IPv4, bien qu'il ne soit pas automatiquement affecté à une interface
comme l'est IPv6 LLA. FRRouting suppose que 169.254.0.1 est réservé (à
ce jour, cela ne peut pas être modifié via une option de configuration).
La raison de l'entrée ARP statique est que le routeur ne peut pas
exécuter ARP pour obtenir cette adresse ; cette adresse IP a été
attribuée implicitement par le routeur sans que son voisin ne sache rien
de cette attribution ; ainsi, le voisin ne peut pas répondre à l'ARP, car il
n'a pas l'adresse IP attribuée à l'interface.
Le processus RIB pousse ensuite la route dans la table de routage du noyau avec
un prochain saut de 169.254.0.1 et une interface sortante définie sur celle de
l'interface d'appairage. Ainsi, l'état final dans les tableaux ressemble à ceci :
ITINÉRAIRE : 10.1.1.0/24 via 169.254.0.1 dev swp1

ARP : 169.254.0.1 dev swp1 lladr 00:00:01:02:03:04 PERMANENT
À ce stade, tout est configuré pour que le transfert de paquets fonctionne

correctement. Plus précisément, la logique de transfert de paquets reste
inchangée avec ce modèle.
Si le lien tombe en panne ou que l'extrémité distante arrête de générer

un RA, le processus RA local retire le LLA et son MAC associé du RIB.
Cela amène le processus RIB à décider que le prochain saut n'est plus
accessible, ce qui l'amène à notifier le processus BGP que l'homologue
n'est plus accessible. RIB détruit également l'entrée ARP statique qu'il a
créée. La fin de la session provoque le retrait par BGP des routes
pointant vers cette interface de peering.
Résumer:
• BGP non numéroté utilise le LLA IPv6 de l'interface pour configurer une session BGP avec
un homologue.
• Le LLA IPv6 de l'extrémité distante est découvert via le protocole

d'annonce de routeur (RA) d'IPv6.
• RA fournit non seulement le LLA de l'extrémité distante, mais aussi son

adresse MAC correspondante.
• BGP utilise RFC 5549 pour coder les routes IPv4 comme accessibles sur un prochain
saut IPv6, en utilisant IPv6 LLA comme prochain saut.

• Le processus RIB programme une entrée ARP statique avec un LLA
IPv4 réservé, 169.254.0.1, avec l'adresse MAC définie sur celle
apprise via RA.
• BGP transmet les routes IPv4 du processus RIB avec le LLA IPv6
comme prochain saut.
• Le processus RIB convertit le nexthop en 169.254.0.1 et
l'interface sortante avant de programmer la route dans la table
de transfert.
Capacité BGP de négocier l'utilisation de la RFC 5549
Parce que l'encodage des routes IPv4 avec un prochain saut IPv6 n'est pas le modèle
habituel, la RFC 5549 définit une nouvelle capacité, appelée nexthop étendu,
pour négocier l'utilisation de la RFC 5549 sur une session de peering.
Comme c'est commun avec les capacités BGP, les deux côtés doivent
annoncer leur capacité à comprendre la RFC 5549 afin qu'elle soit utilisée
dans l'appairage BGP.
FRRouting active automatiquement RA sur une interface et permet

l'envoi de la capacité BGP Nexthop étendue, lorsqu'un peering BGP est
configuré pour être basé sur une interface qui n'a pas d'adresse IPv4.
Interopérabilité
Chaque pair eBGP définit le NEXTHOP sur sa propre adresse IP avant
d'envoyer une annonce de route.
Figure 4-2 montre un réseau hypothétique dans lequel les routeurs B et D

prennent en charge la RFC 5549, alors que les routeurs A et C ne le font pas.
Ainsi, il existe des adresses IP d'interface sur les liens entre B et A et entre B et C.
Lorsque A annonce l'accessibilité à 10.1.1.0/24, il fournit l'adresse IPv4 de son
interface d'appairage comme prochain saut. Lorsque B annonce l'accessibilité à
10.1.1.0/24, il définit son LLA IPv6 comme prochain saut lors de l'envoi de la route
à D, et définit l'adresse IPv4 de son interface comme prochain saut lors de l'envoi
de la route à C.
En sens inverse, si D annonce l'accessibilité à un préfixe

10.1.2.0/24, il utilise le LLA IPv6 de son interface pour l'envoyer à B. Lorsque
B l'annonce à A et C, il définit le nexthop comme étant celui de l'adresse IPv4
de l'interface d'appairage.

Figure 4-2. Interopérabilité avec RFC 5549
Une télécommande-comme par tout autre nom
Après avoir éliminé les adresses d'interface, la seule chose qui reste pour
atteindre l'objectif de la configuration simple et à l'emporte-pièce est la
nécessité de spécifier l'ASN du voisin via le à distance en tant que mot-clé d'une
configuration de voisin BGP.
Il y a deux utilisations principales pour spécifier l'ASN du voisin dans la

spécification du voisin :
• Dans l'esprit de la connexion entre les domaines administratifs, et lorsque des

dommages à grande échelle financière et mondiale sont possibles en se
connectant accidentellement au mauvais domaine administratif, il est essentiel de
vérifier l'intention de l'opérateur.
• Pour identifier si la session BGP sera régie par des règles iBGP ou
des règles eBGP.
Au sein du centre de données, parce que nous ne traversons pas les

domaines administratifs, la sécurité n'est plus une raison impérieuse de
spécifier l'ASN. Et, si la seule raison est d'identifier quelles règles régissent la
session, cela peut être fait par un simple champ non spécifique au voisin.
Sur la base de ce raisonnement, FRRouting a ajouté deux nouveaux

choix au mot-clé remote-as : externe et interne. « Externe » signifie que
vous prévoyez d'établir une connexion eBGP avec ce voisin, alors que
« interne » signifie que vous prévoyez d'établir une connexion iBGP.

tion. En réalité, vous pouvez même ignorer cette spécification car vous pouvez
identifier iBGP par rapport à eBGP par l'ASN reçu dans le message BGP OPEN.
Cependant, la commande remote-as aide à lancer la création de la structure de
données de l'homologue BGP, car il est facile de faire une faute de frappe dans la
spécification du voisin dans l'une des commandes et de créer accidentellement
un nouvel homologue BGP. Par exemple, s'il y avait un pair169.254.1.11 et qu'il y
avait une faute de frappe dans l'un des voisins com‐
mandats—les minuteries voisines 169.254.11.1 se connectent 9 à la place de
les temporisateurs voisins 169.254.1.11 se connectent 9-tu ne veux pas de BGP
pour commencer à lancer une nouvelle session voisine.
Sommaire
En éliminant les adresses IP d'interface et la spécification de la télécommande
exacte comme dans la spécification de commande de voisin, nous pouvons
arriver à une configuration, répertoriée dans Exemple 4-1, qui semble
remarquablement similaire à travers les feuilles et les épines illustrées dans
Figure 3-1. Les seules différences entre les nœuds sont indiquées en gras dans
l'exemple.
Exemple 4-1. Configuration BGP finale pour une feuille et une épine dans un réseau
Clos
// configuration feuille01

DC_LOCAL_SUBNET 10 permit 10.0.254.0/24 le 32 route-map
routeur bgp 65000

voisin groupe de pairs ISL voisin ISL distant en
tant que voisin externe interface swp51
groupe de pairs ISL voisin swp52 interface
groupe de pairs ISL adresse-famille ipv4
unicast
ISL voisin activé
redistribuer la route-map connectée ACCEPT_DC_LOCAL
// configuration spine01

DC_LOCAL_SUBNET 10 permit 10.0.254.0/24 le 32
Résumé | 59
route-map ACCEPT_DC_LOCAL permis 10
routeur bgp 65534

voisin groupe de pairs ISL voisin ISL distant
en tant que voisin externe interface swp1
groupe de pairs ISL voisin swp2 interface
groupe de pairs ISL voisin interface swp3
groupe de pairs ISL voisin interface swp4
groupe de pairs ISL adresse-famille ipv4
unicast
ISL voisin activé
redistribuer la route-map connectée ACCEPT_DC_LOCAL
C'est loin de la configuration BGP d'origine spécifique au nœud. La configuration

est également extrêmement triviale pour automatiser à l'aide d'outils tels que
Ansible, Puppet ou Chef. Cela est dû non seulement à l'élimination d'à peu près
toutes les informations spécifiques au routeur via l'utilisation de noms
d'interface, mais aussi, plus important encore, la configuration de chaque routeur
contient des informations qui sont entièrement locales au routeur, sans aucune
information sur le pair.
Jusqu'à présent, nous nous sommes concentrés sur la configuration de BGP dans une
topologie Clos. Nous n'avons pas décrit comment visualiser les résultats de notre
configuration, gérer BGP après la configuration initiale, ou comment configurer BGP
pour connecter une topologie Clos au monde extérieur. Ceux-ci sont au centre de
Chapitre 5.

CHAPITRE 5
Gestion du cycle de vie BGP
Jusqu'à présent, ce livre a préparé le terrain pour créer une configuration simple
et automatisable pour un réseau de centre de données utilisant BGP. Mais nous
venons de passer par la configuration initiale d'un routeur Leaf ou Spine. Comme
tout opérateur de réseau le sait, le travail est loin d'être terminé une fois le
réseau déployé. Les routeurs doivent être mis à niveau, des correctifs de sécurité
doivent être appliqués, de nouveaux routeurs doivent être installés, et que Dieu
nous aide tous, et si BGP refuse de se comporter ? Ce chapitre aborde ces
questions.
Commandes show utiles

Jusqu'à présent, nous n'avons discuté que de la configuration de BGP, sans voir
les fruits de notre travail. Cette section couvre deux des commandes les plus
utiles et les plus courantes utilisées pour afficher l'état de BGP. Cette section est
destinée à aider les opérateurs de réseau qui découvrent BGP à démarrer (bien
que certains anciens maîtres puissent également apprendre une ou deux choses
nouvelles), et à souligner les différences par rapport au fonctionnement
traditionnel, sans être une référence complète. Il existe de nombreux documents
en ligne et imprimés sur les différentsspectacle commandes utilisées dans BGP.
Affichage des informations de session BGP
La commande la plus populaire pour voir le statut de BGP est montrer ip bgp
somme mary. Figure 5-1 montre un exemple de sortie pour la commande pour la
topologie de référence dans ce livre (basé sur FRRoutage).
61
Figure 5-1. Montrer le réseau
Cette commande affiche uniquement la sortie des sessions IPv4 BGP. Lorsque
BGP a commencé sa vie, il n'y avait qu'IPv4 et le mot-cléip était sans ambiguïté
quant au protocole auquel il faisait référence. Depuis l'avènement d'IPv6 et avec
l'évolution de BGP pour prendre en charge plusieurs protocoles, nous avons
également besoin d'une commande pour afficher les sessions IPv6.
Conformément au modèle AFI/SAFI, leafficher bgp les commandes ont évolué pour
Support afficher le résumé de la monodiffusion bgp ipv4 et montrer bgp ipv6 uni
résumé du casting. Pour de nombreux opérateurs, cependant, la simple mémoire
musculaire les oblige à taper afficher le résumé ip bgp.
Voici les points clés à noter dans cette sortie :
• Tous les voisins avec lesquels ce routeur est censé peerer sont répertoriés
(contrairement à d'autres protocoles comme OSPF).
• L'état de chaque session est répertorié. Si une session est dans l'état
Établi, au lieu du nom de l'état, le nombre de préfixes acceptés de
l'homologue est affiché.
• Le temps de disponibilité de chaque session est affiché (ou son temps d'arrêt, si la
session n'est pas à l'état Établi).
• Des informations telles que l'ID du routeur du nœud et l'ASN sont également
affichées.
La version du BGP (la colonne « V » dans Figure 5-1) est archaïque, étant donné
que toutes les implémentations BGP utilisées aujourd'hui, en particulier dans le
centre de données, exécutent la version 4 du protocole. Les champs restants sont
pour la plupart inintéressants à moins qu'il n'y ait un problème.
Une différence à noter dans la sortie précédente par rapport à ce que vous
pourriez voir dans à peu près toutes les autres implémentations (sauf ExaBGP)
est l'affichage du nom d'hôte de l'homologue. Ceci est basé sur uneÉbauche de
l'IETF qui a défini une nouvelle capacité BGP, appelée nom d'hôte,
qui permet aux opérateurs d'annoncer le nom d'hôte ainsi que le
62 | Chapitre 5 : Gestion du cycle de vie BGP

Message ouvert BGP. Cela simplifie le débogage car il est plus facile de
se souvenir des noms d'hôtes que des noms d'interface. L'Internet
Assigned Numbers Authority (IANA) a émis un identifiant de capacité
standard à utiliser pour cette capacité.
Donc tout spectacle ou dégager La commande peut prendre un nom d'hôte au lieu
d'un voisin. L'utilisation de noms d'hôtes dans les commandes simplifie
potentiellement le dépannage, car il est beaucoup plus intuitif de dire « montrez-
moi l'état de ma session avec l'hôteX» que « me montrer l'état de ma session avec
l'adresse IP X,» ou « me montrer l'état de ma session sur l'interface X."
Dans FRRouting, nous pouvons utiliser des noms d'hôtes dans n'importe quelle
commande qui ne configure pas une session BGP. La raison de la restriction est que le
nom d'hôte n'est pas connu jusqu'à ce que les capacités BGP soient négociées et les
noms d'hôte échangés.
Pour obtenir des informations détaillées sur un voisin, vous pouvez utiliser le com‐
mandat afficher les voisins ip bgp nom_voisin. La sortie de ce
La commande contient des informations supplémentaires, telles que la dernière
fois que la session a été réinitialisée, la raison de la réinitialisation et le nombre
de messages BGP UPDATE envoyés et reçus. Exemple 5-1 présente un exemple
de sortie de leaf01 pour le voisin spine01.
Exemple 5-1. Exemple de sortie montrant les détails de la session d'appairage BGP
avec un voisin
Voisin BGP sur swp51 : fe80::4638:39ff:fe00:5c, distant AS 65000, local AS

64513, lien externe
Nom d'hôte : spine01
Membre de la structure de groupe de pairs pour les paramètres
de session BGP version 4, ID de routeur distant 10.254.0.254
État BGP = Établi, actif pour 00:02:36 Dernière lecture 00:00:00,
Dernière écriture 00:02:35
Le temps d'attente est de 9, l'intervalle de keepalive est
de 3 secondes
4 octets AS : AddPath annoncé et reçu :
IPv4 Unicast : RX annoncé IPv4 Unicast et reçu IPv6 Unicast : RX

annoncé IPv6 Unicast et reçu Extended nexthop : annoncé et
reçu
Adresser les familles par pairs :
Monodiffusion IPv4
Rafraîchissement de la route : annoncé et reçu (ancien et
nouveau) Famille d'adresses IPv4 Unicast : annoncé et reçu
Famille d'adresses IPv6 Unicast : annoncé et reçu Capacité de
nom d'hôte : annoncé et reçu
Commandes show utiles | 63

Capacité de redémarrage gracieux : annoncé et reçu
La minuterie de redémarrage à distance est de 120
secondes Familles d'adresses par pair :
rien
Informations de redémarrage gracieux :
Envoi de fin de RIB : IPv4 Unicast, IPv6 Unicast Réception
de fin de RIB : IPv4 Unicast, IPv6 Unicast Statistiques des
messages :
La profondeur d'inq est 0
La profondeur de sortie est 0
Envoyé Rcvd
Ouvre : 4 5
Notifications : 4 2
Mises à jour: 40 25
Keepalives : 26962 26959
Rafraîchir l'itinéraire : 0 0
Aptitude: 0 0
Le total: 27010 26991
Le temps minimum entre les exécutions de la publicité est de 0 seconde
Pour la famille d'adresses : membre du groupe

d'homologues de la matrice IPv4 Unicast
Groupe de mise à jour 1, sous-groupe 1
Longueur de la file d'attente de paquets 0
Attribut de communauté envoyé à ce voisin (les deux) 5

préfixes acceptés

Envoi de fin de RIB : IPv4 Unicast, IPv6 Unicast Réception
de fin de RIB : IPv4 Unicast, IPv6 Unicast Statistiques des
messages :
La profondeur d'inq est 0
La profondeur de sortie est 0
Envoyé Rcvd
Ouvre : 4 5
Notifications : 4 2
Mises à jour: 40 25
Keepalives : 26988 26985
Rafraîchir l'itinéraire : 0 0
Aptitude: 0 0
Le total: 27036 27017
Le temps minimum entre les exécutions de la publicité est de 0 seconde


préfixes acceptés


préfixe accepté
Connexions établies 3 ; abandonné 2

Dernière réinitialisation 00:03:57, en raison de l'envoi de NOTIFICATION (résolution de
collision Cease/Connection)
Message reçu qui a poussé BGP à envoyer une NOTIFICATION :
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00660104 FDE80009 0AFE00FE 49020601
04000100 01020601 04000200 01020805
06000100 01000202 02800002 02020002
06410400 00FDE802 0A450800 01010100
02010102 0B490907 7370696E 65303100
02044002 00
Hôte local : fe80::4638:39ff:fe00:5b, Port local : 179 Hôte étranger :
fe80::4638:39ff:fe00:5c, Port étranger : 52191 Nexthop : 10.254.0.1
Nexthop global : fe80::4638:39ff:fe00:5b

Nexthop local : fe80::4638:39ff:fe00:5b
Connexion BGP : réseau partagé
Minuterie de nouvelle tentative de connexion BGP en
secondes : 10 Fil de lecture : activé Fil d'écriture : désactivé
Affichage des routes échangées
Une autre commande courante consiste à voir la liste des routes calculées et
dans la table de routage de BGP. La commande pour cela estafficher l'ip bgp ou
montrer bgp ipv4 monodiffusion. Figure 5-2 montre la sortie de cette
commande sur leaf01 de la topologie de référence.
Les champs clés sont le préfixe lui-même, les prochains sauts possibles
et l'AS_PATH associé à chaque préfixe. Cet écran n'affiche que 8 préfixes
sur 12 car les deux autres n'ont pas été acceptés. Les causes fréquentes
de rejet des préfixes sont soit des décisions de politique, soit la
détection d'une boucle AS_PATH (la boucle AS_PATH a été détectée dans
ce cas). L'astérisque (*) en début de ligne indique que l'itinéraire est
valide ; c'est le nexthop est accessible. Ensuite, un signe égal (=) indique
que la route a plusieurs chemins utilisables à coût égal.
Commandes show utiles | 65

Figure 5-2. Routes BGP comme on le voit sur leaf01 de la topologie de référence
Vous pouvez utiliser la même commande avec un préfixe spécifique pour

obtenir les détails de l'annonce de préfixe reçue. Par exemple,Figure 5-3
représente la sortie de la commande afficher l'adresse IP bgp 10.254.0.3.
Figure 5-3. Préfixe annoncé
En utilisant cela, un opérateur de réseau peut examiner de près pour

déterminer les détails d'un préfixe, tels que les attributs reçus pour un
préfixe et à qui d'autre le préfixe a été annoncé.
Se connecter au monde extérieur

L'une des choses dont nous n'avons pas discuté est la façon dont nous annonçons les
itinéraires en dehors du centre de données. Cette tâche relève également généralement de la
compétence d'un opérateur de réseau de centre de données.

Utilisons la topologie de référence que nous avons utilisée tout au long de ce livre, telle que
présentée dans Figure 5-4.
Figure 5-4. Topologie de référence utilisée dans ce livre
exit01 et exit02 sont les deux nœuds qui délimitent l'intérieur du centre
de données de l'extérieur. Ils sont connectés au nœud intitulé
l'Internet; il s'agit du commutateur de périphérie du centre de données, qui est le
commutateur d'appariement avec le monde extérieur. exit01 et exit02 sont appelésfeuilles de

frontière ou feuilles de sortie (la frontière part peut-être dans une cosse frontière dans un
réseau de Clos à trois niveaux comme décrit dans Chapitre 1).
Les feuilles de frontière remplissent deux fonctions principales : supprimer les ASN
privés et éventuellement agréger les routes internes du centre de données et annoncer
uniquement les routes récapitulatives vers les routeurs de périphérie.
Vous supprimez les ASN privés du chemin via la commande hennir

bor nom_voisin remove-private-AS all.
Vous pouvez résumer les itinéraires et annoncer uniquement l'agrégat via le

commander adresse-agrégat itinéraire-résumé résumé uniquement.
Le mot-clé résumé uniquement spécifie que les routes individuelles ne doivent pas
être envoyées. Sans cette option, les routes récapitulatives ainsi que les routes
individuelles sont annoncées. Lorsqu'une route est agrégée et que seule la route
récapitulative est annoncée, l'intégralité de l'AS_PATH est également supprimée,
sauf indication contraire.
Se connecter au monde extérieur | 67

Planification de la maintenance des nœuds
Le cycle de vie d'un routeur implique généralement la mise à niveau du logiciel.

La mise à niveau peut couvrir l'ensemble du routeur, uniquement le logiciel de
routage ou tout autre logiciel pertinent qui fait que le routeur perd sa session
d'appairage avec les voisins lors de son redémarrage. Si les voisins d'un routeur
continuent de transférer le trafic pendant que le routeur redémarre, le trafic peut
être interrompu et entraîner une perte de trafic inutile. Pour éviter cela, surtout
lorsque l'opérateur sait que le nœud va être démantelé, il est utile de permettre
aux voisins de contourner le routeur. Par exemple, si spine01 doit être mis à
niveau, vous devez demander à toutes les feuilles d'ignorer spine01 dans leur
meilleur calcul de chemin et envoyer tout le trafic à spine02 uniquement pendant
ce temps pour assurer un flux de trafic fluide. De même, dans le cas des feuilles
avec des serveurs à double connexion, il serait utile que les spines évitent
d'envoyer du trafic vers la feuille en cours de mise à niveau et n'utilisent que la
feuille de travail. De cette manière, les routeurs peuvent être mis à niveau, un
boîtier à la fois, sans entraîner de perte de trafic inutile.
Comme discuté dans Chapitre 1, un centre de données moderne compte

plus de deux nœuds de colonne vertébrale, quatre étant les plus courants,
en particulier dans les moyennes et grandes entreprises. Avec quatre
nœuds, lorsqu'une colonne vertébrale est mise hors service pour
maintenance, le réseau peut continuer à fonctionner à 75 % de sa capacité.
Dans une conception de réseau d'entreprise traditionnelle, il n'y a que deux
nœuds de colonne vertébrale, ce qui entraînerait une perte de capacité plus
importante lorsqu'une seule colonne vertébrale est mise hors service. Il est
vrai que les serveurs ne fonctionneraient qu'à la moitié de leur capacité s'ils
étaient en double connexion. C'est pourquoi certaines grandes entreprises
utilisent des serveurs à double connexion uniquement pour le basculement,
et non avec les deux liens actifs en même temps. Les centres de données à
l'échelle du Web résolvent ce problème en ne connectant que des serveurs
individuellement et en ayant tellement de racks que le démontage d'un seul
rack n'est pas un gros problème.
Le moyen le plus courant et le plus interopérable de drainer le trafic consiste à

forcer les routes à être annoncées à partir du nœud avec un ASN supplémentaire
ajouté à l'annonce, ce qui entraîne une augmentation de la longueur AS_PATH
par rapport aux pairs du nœud. Par exemple, une route annoncée par leaf01 est
considérée par leaf03 comme ayant plusieurs chemins, un via spine01 et l'autre
via spine02, tous deux avec une longueur AS_PATH de

2. Si nous voulons mettre à niveau spine02, nous pouvons augmenter sa longueur
AS_PATH et leaf03 cessera d'utiliser spine02 pour atteindre leaf01.
En règle générale, le propre ASN du nœud est utilisé pour ajouter des ASN
supplémentaires. Voici un exemple d'extrait de configuration sur spine01
préfixant son propre ASN dans ses annonces à tous les voisins :
carte de route SCHED_MAINT permis 10

définir le préfixe du chemin d'accès 65000 65000
carte de route ISL voisine SCHED_MAINT sortie
Figure 5-5 montre la sortie pour le même préfixe utilisé dans Figure
5-4, sauf que l'une des épines, spine02, a annoncé un chemin plus
long que l'autre, et par conséquent ce chemin n'a pas été
sélectionné.
Il existe d'autres méthodes pour indiquer qu'un routeur BGP échoue, mais toutes
les implémentations ne prennent pas en charge ces méthodes, j'ai donc choisi de
parler du modèle le plus pris en charge.
Figure 5-5. Un chemin non choisi
Débogage BGP
Comme tout autre logiciel, BGP se comportera parfois de manière imprévisible en
raison d'un bogue ou d'une incompréhension de la part de l'opérateur. Une solution
courante à un tel problème consiste à activer le débogage et à consulter les journaux
de débogage pour déterminer la cause du comportement imprévisible.
Différents logiciels de routeur fournissent différents boutons à ajuster pendant le

débogage. Dans FRRouting, la commandedéboguer bgp est la passerelle
Débogage BGP | 69
pour comprendre ce qui se passe avec BGP. De nombreuses options sont répertoriées
sousdéboguer, mais trois en particulier sont essentiels :
événements-voisins
Ceci est utilisé pour déboguer n'importe quelle session et signaler des problèmes.
Le débogage peut concerner toutes les sessions ou uniquement une session
spécifique. Des informations telles que l'extrémité qui a initié la connexion, les
transitions de la machine d'état BGP et les capacités échangées peuvent toutes
être consultées dans le journal de débogage avec cette option activée.
meilleur chemin
Ceci est utilisé pour déboguer le calcul du meilleur chemin. Si vous l'activez pour
un préfixe spécifique, les journaux afficheront la logique suivie pour sélectionner
le meilleur chemin pour un préfixe, y compris la sélection multichemin.
Figure 5-6 montre un exemple de l'extrait d'un journal. C'est
pour déboguer le même préfixe montré dansFigure 5-3 et
Figure 5-5. Comme nous l'avons vu, vous pouvez également utiliser les journaux de
débogage pour mieux comprendre le fonctionnement de la logique de sélection du
meilleur chemin de BGP. Dans ce cas, comment un AS_PATH plus long empêche la
sélection d'un chemin.
Figure 5-6. Exemple de journal de débogage montrant le calcul du meilleur chemin
Mises à jour
Ceci est utilisé pour déboguer les problèmes impliquant soit la publicité, soit
la réception de publicités de préfixes avec un voisin. Vous pouvez spécifier
un seul préfixe, tous les préfixes ou tous les préfixes pour un seul voisin afin
d'examiner de plus près la cause première d'un problème. Les journaux de
débogage vous montrent non seulement les préfixes qui ont été acceptés,
mais également ceux qui ont été rejetés. Par exemple, étant donné que les
spines partagent le même ASN, l'adresse IP de bouclage d'un spine ne peut
pas être vue par les autres spines. Pour voir cela en action, en émettant
déboguer bgp mises à jour préfixe
10.254.0.253/32, nous obtenons la sortie montrée par Exemple 5-1 dans le
fichier journal.

Exemple 5-2. Préfixe rejeté à cause de la boucle ASN
2017/05/20 15:09:54.112100 BGP : MISE À JOUR rcvd swp2 avec attr : , origine i,
mp_nexthop fe80::4638:39ff:fe00:2e(fe80::4638:39ff:fe00:2e), chemin
64514 65000 65000 65000 64515
2017/05/20 15:09:54.112165 BGP: swp2 rcvd MISE À JOUR environ 10.254.0.3/32
- - REFUSÉ en raison de : as-path contient notre propre AS ;
mp_nexthop fe80::4638:39ff:fe00:57(fe80::4638:39ff:fe00:57), métrique
0, chemin 64515
2017/05/20 15:09:54.113471 BGP: swp3 rcvd 10.254.0.3/32
mp_nexthop fe80::4638:39ff:fe00:43(fe80::4638:39ff:fe00:43), chemin
64516 65000 65000 65000 64515
mp_nexthop fe80::4638:39ff:fe00:5b(fe80::4638:39ff:fe00:5b), chemin
64513 65000 65000 65000 64515
2017/05/20 15:09:54.162440 BGP : u3 : s6 envoyer la MISE À JOUR avec attr : , origine i,
mp_nexthop ::(::), chemin 64515
2017/05/20 15:09:54.162788 BGP: u3:s6 envoyer MISE À JOUR 10.254.0.3/32
2017/05/20 15:09:54.214657 BGP: swp4 rcvd MISE À JOUR avec attr: , origine i,
mp_nexthop fe80::4638:39ff:fe00:43(fe80::4638:39ff:fe00:43), chemin
64516 65000 64515
2017/05/20 15:09:54.14803 BGP: swp4 rcvd UPDATE environ 10.254.0.3/32
mp_nexthop fe80::4638:39ff:fe00:2e(fe80::4638:39ff:fe00:2e), chemin
64514 65000 64515
mp_nexthop fe80::4638:39ff:fe00:5b(fe80::4638:39ff:fe00:5b), chemin
64513 65000 64515
Sommaire
Ce chapitre a fourni des informations sur certains des outils et tâches moins
fréquents, mais néanmoins critiques, pour la gestion et le dépannage des
déploiements BGP dans un centre de données. À ce stade, vous devriez, espérons-
le, posséder une bonne compréhension des réseaux de centre de données, de
BGP et de la configuration et de la gestion d'un réseau Clos dans le centre de
données.
Résumé | 71
Chapitre 6 couvre l'extension du routage BGP jusqu'à l'hôte, ce qui est également
de plus en plus déployé en tant que solution dans le centre de données en raison
de l'augmentation des services virtuels, entre autres utilisations.

CHAPITRE 6
BGP sur l'hôte
L'avènement du centre de données moderne a révolutionné à peu près tout ce

que nous savons sur l'informatique et les réseaux. Qu'il s'agisse de l'essor des
bases de données NoSQL, des nouvelles architectures applicatives et des
microservices, ou des réseaux Clos avec le routage comme rubrique
fondamentale plutôt que le pontage, ils ont chacun bousculé des idées
jusqu'alors bien vues. Cela a également affecté la façon dont les services tels que
les pare-feu et les équilibreurs de charge sont déployés.
Ce chapitre examine comment le nouveau modèle de services déplace le routage

jusqu'au serveur et comment nous configurons BGP sur l'hôte pour
communiquer avec le ToR ou le commutateur feuille.
La juridiction traditionnelle des administrateurs de réseau s'est terminée au

niveau du commutateur ToR. Les administrateurs de serveur géraient la
configuration et la gestion du serveur. Dans le nouvel ordre mondial, soit des
administrateurs de serveur et de réseau distincts ont été remplacés par un seul
opérateur de centre de données complet, soit les administrateurs de réseau
doivent travailler conjointement avec les administrateurs de serveur pour
configurer également le routage sur les hôtes. Dans les deux cas, il est important
pour un opérateur de centre de données de s'assurer que la configuration de
BGP sur l'hôte ne compromet pas l'intégrité du réseau.
L'essor des services virtuels

Dans les réseaux de centres de données traditionnels, la frontière entre le pontage et
le routage, la passerelle L2 à L3, était l'endroit où des services tels que le pare-feu et les
équilibreurs de charge étaient déployés. La limite était un ajustement naturel
73
parce que la frontière représentait en quelque sorte la séparation du client du
serveur. Il était logique d'attribuer des pare-feu à cette limite pour protéger les
serveurs des clients malveillants ou non autorisés. De même, les serveurs
frontaux des équilibreurs de charge, généralement des serveurs Web, prennent
en charge un modèle évolutif. Cette conception s'étendait également aux pare-
feux, où les équilibreurs de charge faisaient face à une rangée de pare-feu
lorsque la bande passante du trafic dépassait la capacité d'un seul pare-feu.
Ces pare-feu et équilibreurs de charge étaient généralement des appliances, qui

étaient généralement mises à l'échelle avec le modèle de mise à l'échelle ; c'est-à-dire
acheter des appareils de plus en plus gros pour prendre en charge le volume croissant
de trafic.
Le réseau Clos a détruit toute frontière naturelle de ce type, et avec sa grande échelle, le
centre de données moderne a rendu les modèles de mise à l'échelle impraticables. Dans le
nouveau monde, les services sont fournis par des machines virtuelles (VM) s'exécutant sur des
hôtes finaux ou des hôtes finaux non virtualisés. Deux services populaires fournis de cette
manière sont les services d'équilibrage de charge et de pare-feu. Dans ce modèle, au fur et à
mesure que le volume du trafic monte et descend, les machines virtuelles peuvent être
augmentées ou réduites dynamiquement pour gérer les besoins changeants du trafic.
Adresses Anycast
Étant donné que les serveurs (ou VM) fournissant un service peuvent apparaître
n'importe où dans le centre de données, l'adresse IP ne peut plus être limitée à
un seul rack ou routeur. Au lieu de cela, plusieurs racks pourraient
potentiellement annoncer la même adresse IP. Avec la capacité de transmission
ECMP du routage, les paquets seraient acheminés vers l'un des nœuds les plus
proches offrant le service. Ces adresses IP d'extrémité n'ont pas de rack ou de
commutateur unique auquel elles peuvent être associées. Ces adresses IP qui
sont annoncées par plusieurs points de terminaison sont appeléestout cast
Adresses IP. Ce sont des adresses IP unicast, ce qui signifie qu'elles sont
envoyées à une seule destination (par opposition aux adresses multidestinations
telles que la multidiffusion ou la diffusion), mais la destination choisie est
déterminée par le routage, et différents points de terminaison choisissent
différents nœuds offrant le même service.
Les sous-réseaux sont généralement attribués par rack. Comme nous en avons discuté dans
Chapitre 1, 40 serveurs par rack se traduisent par des termes de référence annonçant un sous-
réseau /26. Mais comment un ToR découvre-t-il ou annonce-t-il une adresse hors sous-réseau
qui est une adresse IP de service anycast ? La configuration de routage statique n'est pas
acceptable. BGP vient à nouveau à la rescousse.
74 | Chapitre 6 : BGP sur l'hôte

Modèles BGP pour le peering avec des serveurs
Il existe deux modèles de peering avec des serveurs. Le premier est le modèle non
numéroté BGP décrit dansChapitre 4. La seconde implique une fonctionnalité prise en
charge par BGP appeléevoisins dynamiques. Nous examinerons chaque modèle, en
énumérant les avantages et les inconvénients des deux. Mais nous commençons par
regarder ce qui est commun aux deux modèles : le schéma de numérotation ASN, et
l'échange de route entre le serveur et le ToR.
Affectation ASN
Le déploiement le plus courant que j'ai vu consiste à dédier un ASN pour
tous les serveurs. Les avantages de cette approche sont qu'elle est simple à
configurer et à automatiser, et qu'elle simplifie l'identification et le filtrage
des routes à partir du serveur. Les deux principaux inconvénients de cette
approche sont 1) la complexité de la configuration sur le serveur augmente
si nous devons annoncer autre chose que la route par défaut vers l'hôte, et
2) le suivi de quel serveur a annoncé une route devient plus délicat car tous
les serveurs partagent la même ASN.
Une autre approche consisterait à attribuer un seul ASN pour tous les serveurs
connectés au même commutateur, mais des ASN distincts pour des commutateurs
distincts. Dans un centre de données moderne, cela se traduit par un serveur ASN
séparé par rack. L'avantage de ce modèle est qu'il semble désormais que les serveurs
ne sont qu'un autre niveau d'un réseau Clos. Les principaux inconvénients de ce
modèle sont les mêmes que ceux du modèle précédent, bien que nous puissions
restreindre une annonce de route à un rack spécifique.
L'approche finale consiste à traiter chaque serveur comme un nœud distinct et à

attribuer des ASN distincts pour chaque serveur. Bien que quelques clients que je
connais utilisent cette approche, cela semble exagéré. Les principaux avantages
de cette approche sont qu'elle s'adapte parfaitement au modèle prescrit pour un
réseau Clos, et qu'il est facile de déterminer quel serveur a annoncé une route.
Compte tenu du grand nombre de serveurs, l'utilisation d'ASN de 4 octets semble
être la chose prudente à faire avec cette approche.
Modèle d'échange d'itinéraires
Parce que chaque hôte est maintenant un routeur de premier ordre, toutes sortes de
mauvaises choses peuvent arriver si nous ne contrôlons pas les routes qu'un
commutateur accepte d'un hôte. Par exemple, un hôte peut annoncer accidentellement
ou par malveillance la route par défaut (ou toute autre route qu'il ne possède pas),
acheminant ainsi le trafic vers la mauvaise destination. Un autre
Modèles BGP pour le peering avec des serveurs | 75

la chose à éviter est de s'assurer que le commutateur ToR (ou feuille) ne pense
jamais que l'hôte est un nœud de transit ; c'est-à-dire un avec une connectivité à
d'autres nœuds. Cette erreur entraînerait une perte de trafic importante car un
hôte n'est pas conçu pour gérer des charges de trafic de centaines de gigabits
par seconde. Enfin, le routeur connecté au serveur n'annonce que la route par
défaut. Ceci afin d'éviter de pousser trop de routes vers l'hôte, ce qui pourrait
remplir sa table de routage et faire perdre à l'hôte de précieux cycles en essayant
d'exécuter le meilleur algorithme de chemin à chaque fois qu'une route change
(par exemple, lorsqu'un commutateur ToR perd la connectivité à un interrupteur
à feuille ou à colonne vertébrale).
Pour gérer tous ces scénarios, nous utilisons des politiques de routage comme décrit
dans chapitre 3. L'extrait de configuration suivant montre comment nous pouvons
accomplir chacune des tâches susmentionnées via l'utilisation de la politique de
routage, comme démontré ici :
ip prefix-list ANYCAST_VIP seq 5 permit 10.1.1.1/32

ip prefix-list ANYCAST_VIP seq 10 permit 20.5.10.110/32
ip prefix-list DEFONLY seq 5 permit 0.0.0.0/0
carte de route ACCEPT_ONLY_ANYCAST permis 10

correspondre à la liste de préfixes d'adresses IP ANYCAST_VIP
carte de route ADVERTISE_DEFONLY permis 10

correspondre à la liste de préfixes d'adresses IP DEFONLY
carte de route du serveur voisin ACCEPT_ONLY_ANYCAST

dans la carte de route du serveur voisin ADVERTISE_DEFONLY
sortie par défaut du serveur voisin
Dans cette configuration, la déclaration de voisin avec le route-map

ACCEPT_ONLY_ANYCAST dit que les seules annonces de route acceptées
d'un voisin appartenant au groupe de pairs serveur sont les adresses IP
anycast répertoriées dans le Liste de préfixes ANYCAST_VIP.
De même, la déclaration de voisin avec le route-map ADVER
TISE_DEFONLY spécifie que BGP annonce uniquement la route par
défaut à tout voisin appartenant au groupe de pairs serveur.
Schémas d'appairage BGP pour les serveurs Edge
Maintenant que nous avons établi l'importance d'inclure des serveurs de périphérie
tels que des équilibreurs de charge et des pare-feu dans votre configuration de
routage, nous pouvons examiner deux modèles BGP pour le faire : voisins dynamiques
et BGP non numéroté. Chaque modèle a des limites, alors regardez par-dessus

les sous-sections suivantes et choisissez celle qui répond le mieux aux
besoins de votre centre de données.
Voisins dynamiques
Parce que BGP fonctionne sur TCP, tant que l'un des pairs initie une connexion,
l'autre extrémité peut rester passive, attendant silencieusement qu'une
connexion arrive, tout comme un serveur Web attend une connexion d'un
navigateur ou d'un autre client.
Les voisins dynamiques BGP sont une fonctionnalité prise en charge dans certaines
implémentations où une extrémité est généralement passive. On lui dit simplement de
quel sous-réseau IP accepter les connexions et il est associé à un groupe de pairs qui
contrôle les caractéristiques de la session de peering.
Rappelez-vous que les serveurs d'un rack partagent généralement un sous-réseau avec
les autres serveurs du même rack. À titre d'exemple, supposons qu'un groupe de 40
serveurs connectés à un commutateur ToR se trouve dans le sous-réseau 10.1.0.0/26.
Une configuration typique des voisins dynamiques BGP sur un ToR ressemblera à ceci :
serveurs voisins groupes de pairs serveurs

voisins distants en tant que 65530
plage d'écoute bgp 10.1.0.0/26 serveurs de groupe de pairs
À ce stade, le démon BGP commencera à écouter passivement sur le port

179 (le port BGP bien connu). S'il reçoit une connexion de n'importe qui dans
le sous-réseau 10.1.0.0/26 qui indique que son ASN est 65530, le démon BGP
acceptera la demande de connexion et une nouvelle session BGP est établie.
Côté serveur, l'adresse IP de peering du commutateur est généralement celle de

la passerelle par défaut. Pour le sous-réseau 10.1.0.0/26, l'adresse de passerelle
est généralement 10.1.0.1. Ainsi, la configuration BGP sur le serveur peut être la
suivante :
ISL voisin groupe d'homologues ISL voisin

distant en tant que voisin externe 10.1.0.1
ISL de groupe d'homologues
À ce stade, le démon BGP exécuté sur le serveur initiera une

connexion au commutateur, et dès que la connexion est établie, le
reste de la machine d'état BGP procède comme d'habitude.
Malheureusement, les fonctionnalités de voisins dynamiques ne sont actuellement pas prises
en charge sur une interface ; c'est-à-dire que tu ne peux pas direbgp ecoute inter
face aux serveurs de groupe de pairs vlan10. Il n'est pas non plus possible d'utiliser le
Modèles BGP pour le peering avec des serveurs | 77

nom d'interface côté serveur, car l'astuce consistant à utiliser des noms
d'interface (décrite dans chapitre 3) ne fonctionne qu'avec les adresses de sous-
réseau /30 ou /31, alors que ce qui est utilisé ici est une adresse /26.
Vous pouvez limiter le nombre de pairs que le modèle de voisin dynamique

prend en charge via la commande limite d'écoute du voisin nombre-limite.
Par exemple, en configurant limite d'écoute bgp 20, vous n'autorisez que
20 voisins dynamiques à être établis à un moment donné.
Le principal avantage de ce modèle est qu'il fonctionne bien avec les

serveurs à connexion unique, et lorsque les serveurs sont démarrés via le
Environnement d'exécution de pré-démarrage (PXE). Figure 6-1 présente ce
modèle.
Figure 6-1. BGP Voisin dynamique sur un sous-réseau partagé
Modèle non numéroté BGP
Tout comme l'établissement de session BGP entre routeurs, une session

BGP peut être établie entre un serveur et un commutateur en utilisant BGP
non numéroté. Rappel deChapitre 4 que BGP non numéroté fonctionne
dans la suite FRRouting sans nécessiter aucune modification dans le noyau
Linux.
Le modèle de configuration avec BGP non numéroté, illustré dans

Figure 6-2, est différent de la version voisine dynamique.

Figure 6-2. Modèle de peering non numéroté BGP avec des hôtes
Contrairement au modèle de sous-réseau partagé de voisins dynamiques, le modèle

non numéroté BGP n'a pas de sous-réseau partagé. Tout comme un routeur, l'adresse
IP du serveur est indépendante de l'interface et généralement attribuée à l'adresse de
bouclage. Chaque serveur peut se voir attribuer une adresse /32 indépendante. Étant
donné que l'adresse locale de liaison IPv6 (LLA) est utilisée pour l'appairage avec le
routeur, un sous-réseau partagé n'est pas nécessaire.
La configuration du côté du commutateur ressemblera à ceci :

serveurs de groupe de pairs voisins serveurs
voisins distants en tant que voisins serveurs de
groupes de pairs swp1 voisins serveurs de
groupes de pairs swp2 voisins
...
Et la configuration côté serveur est similaire :

voisin eth0 distant-comme externe
Le principal avantage de cette approche est que vous pouvez créer un centre de
données purement routé, sans pontage. Ce modèle prend également en charge
les serveurs à double connexion, sans qu'il soit nécessaire d'exécuter un LACP
multinœud propriétaire. Le principal inconvénient de cette approche est que les
serveurs démarrés par DHCPv4 ou PXE sont difficiles à prendre en charge car il
n'y a pas de pile de routage pendant le démarrage PXE, mais le commutateur ne
sait pas comment transférer les paquets vers un serveur spécifique. Il existe des
solutions possibles, mais l'explication dépasse le cadre du livre.
Le modèle non numéroté BGP sur une interface partagée est théoriquement
possible lorsque le lien partagé est entre un commutateur et un groupe de
serveurs, mais n'est actuellement pas mis en œuvre.
Logiciel de routage pour les hôtes
Si vous maîtrisez bien la conception de réseaux, vous reconnaîtrez qu'en

réalité, le BGP exécuté sur le serveur n'a vraiment besoin que d'un haut-
parleur BGP et n'a pas à implémenter un protocole de routage complet avec
Logiciel de routage pour hôtes | 79

calcul du meilleur chemin, programmation des routes dans la table de routage,
etc. Les pionniers à l'échelle du Web l'ont reconnu et ont utilisé des logiciels tels
queExaBGP, qui n'a fonctionné que comme haut-parleur BGP, pendant
longtemps.
Aujourd'hui, des suites de routage open source plus complètes telles que
FRRoutage et Routage BIRD sont disponibles pour une utilisation sur les
serveurs Linux et BSD. FRRouting prend en charge les voisins BGP non
numérotés et dynamiques. Les exemples utilisés dans ce chapitre reposent
sur FRRouting.
Sommaire
Ce chapitre a montré comment étendre l'utilisation de BGP jusqu'aux hôtes. Avec
l'avènement de suites de routage puissantes et complètes telles que FRRouting, il
est possible de configurer BGP simplement en utilisant BGP non numéroté, ce qui
rend trivial l'automatisation de la configuration BGP sur tous les serveurs. Si vous
ne pouvez pas vivre avec les limitations actuelles de BGP non numéroté ou si
vous préférez un peering BGP plus traditionnel, les voisins dynamiques BGP sont
une solution alternative. De plus, nous avons montré comment limiter les
dommages pouvant être causés par des serveurs annonçant des itinéraires
incorrects dans le réseau, par inadvertance ou par inadvertance.

A propos de l'auteur
Dinesh G. Dutt est le scientifique en chef de Cumulus Networks. Il a travaillé

dans l'industrie des réseaux au cours des 20 dernières années, principalement
chez Cisco Systems, où il était Fellow. Il a été impliqué dans les technologies de
mise en réseau des entreprises et des centres de données, y compris la
conception de nombreux ASIC qui alimentent les méga-commutateurs de Cisco
tels que Cat6K et la famille de commutateurs Nexus. Il a également de
l'expérience dans les réseaux de stockage depuis ses années chez Andiamo
Systems et dans la conception de FCoE. Il est co-auteur de TRILL et VxLAN, et a
déposé plus de 40 brevets.

Ethernet Switching BGP Oreilly

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ethernet Switching BGP Oreilly

Transféré par

Droits d'auteur :

Formats disponibles

Traduit de Anglais vers Français - www.onlinedoctranslator.

Application Application Application

Système d'exploitation réseau

En savoir plus sur

Pékin Boston Farnham Sébastopol Tokyo

par Dinesh G. Dutt

Copyright © 2017 O'Reilly Media, Inc.. Tous droits réservés.

Imprimé aux États-Unis d'Amérique.

Éditeurs : Courtney Allen et Décorateur d'intérieur: David Futato

Éditeur de production : Kristen Brown Illustrateur : Rébecca Demarest

Juin 2017 : Première édition

Historique des révisions pour la première édition

2017-06-19 : Première version

1. Introduction aux réseaux de centres de données. . . . . . . . . . . . . . . . . . . . . . . . . . 1

2. Comment BGP a été adapté au centre de données. . . . . . . . . . . . . . . . . 15

3. Construire une configuration BGP automatisable. . . . . . . . . . . . . . . . . . . 27

4. Réinventer la configuration BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5. Gestion du cycle de vie BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6. BGP sur l'hôte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

vi | Table des matières

L'objectif principal de ce livre est de rassembler en un seul endroit la théorie et la

Logiciel utilisé dans ce livre

Introduction au centre de données

Un réseau existe pour répondre aux exigences de connectivité des applications,

Le protocole de routage le plus couramment utilisé à l'intérieur du centre de

Il est naturel de commencer le parcours du déploiement de BGP dans le centre de données

• En quoi ces objectifs sont-ils différents d'autres réseaux tels que

Exigences d'un réseau de centre de données

Communication accrue de serveur à serveur

2 | Chapitre 1 : Introduction aux réseaux de centres de données

Exigences d'un réseau de centres de données | 3

Rejetant ce paradigme si peu satisfaisant en termes de fiabilité et de coût,

Topologie du réseau Clos

Figure 1-1. Un réseau Clos simple à deux niveaux

4 | Chapitre 1 : Introduction aux réseaux de centres de données

L'autre conséquence d'avoir de nombreux liens est que la bande passante

Vous pouvez facilement déterminer le nombre de serveurs que vous pouvez

Topologie du réseau Clos | 5

Réseaux Clos à trois niveaux

Figure 1-2. Réseau Clos à trois niveaux

6 | Chapitre 1 : Introduction aux réseaux de centres de données

Effets secondaires cruciaux des réseaux Clos

Une conséquence de l'utilisation de commutateurs à facteur de forme fixe est

En d'autres termes, la résilience devient une propriété émergente des pièces

Topologie du réseau Clos | 7

Architecture réseau de Clos Networks

Figure 1-3. Connectivité avec STP

8 | Chapitre 1 : Introduction aux réseaux de centres de données

Figure 1-4. STP après un échec de liaison

Tracez le chemin entre un serveur connecté à la feuille la plus à gauche et un

Un avantage clé tiré de cette conversion du pontage au routage est que

Architecture Réseau des Réseaux Clos | 9

Modèles d'attachement de serveur

10 | Chapitre 1 : Introduction aux réseaux de centres de données

Connectivité au monde extérieur

Le principal avantage des modules de bordure ou des feuilles de bordure est

Connectivité au monde extérieur | 11

Prise en charge de l'architecture mutualisée (ou Cloud)

Un grand nombre de clients, ou locataires, doit être pris en charge.

Les solutions traditionnelles traitaient de la multilocation en fournissant l'isolation dans

12 | Chapitre 1 : Introduction aux réseaux de centres de données

Avec l'avènement du Virtual eXtensible Local Area Network (VXLAN) et des

Conséquences opérationnelles de la conception de