by Philippe Gervasi 10 avril 2018
Configurer manuellement les attributs spécifiques des pairs BGP sur des dizaines de routeurs n'a plus de sens. Il est moins logique de le faire à grande échelle. Une grande partie des coûts associés à la maintenance d'un réseau d'entreprise sont des dépenses opérationnelles, alors pourquoi passons-nous encore autant de temps avec des tâches que les administrateurs de serveurs ont compris comment automatiser il y a des décennies ?
L'un des points forts du Border Gateway Protocol, ou BGP, est qu'il est hautement paramétrable en ce sens qu'il existe de nombreux paramètres et options de configuration disponibles pour un ingénieur. BGP diffère des autres protocoles de routage en ce qu'il s'agit d'un vecteur de chemin plutôt que d'un vecteur de distance ou d'un état de liaison. Cela signifie que BGP peut prendre des décisions de sélection de chemin basées sur plus de facteurs qu'un IGP typique comme OSPF ou EIGRP.
En raison de sa capacité de réglage, BGP a fait son chemin du WAN au centre de données afin de segmenter des racks de serveurs ou même des serveurs individuels en domaines de couche 3 distincts. Considérez qu'un hôte ESXi robuste peut avoir des dizaines de serveurs en cours d'exécution en même temps. Non seulement BGP est omniprésent dans le WAN, mais il devient également une norme dans le centre de données.
NetBrain automatise ce que nous avons fait manuellement pendant des années. L'ancienne méthode n'a plus de sens, et vraiment, elle n'en a jamais eu.
Qu'un ingénieur utilise BGP dans le centre de données pour acheminer vers des hyperviseurs individuels ou dans le WAN pour acheminer vers des réseaux partout dans le monde, la configuration peut devenir complexe très rapidement. Par exemple, une conception de réseau courante consiste à utiliser un protocole BGP multiprotocole sur un cœur MPLS à l'aide de plusieurs VRF et d'un ou plusieurs IGP avec redistribution de routes. Dans un grand réseau, cela peut se transformer en des centaines de lignes de code par routeur pour créer des pairs, annoncer correctement les préfixes, sécuriser les connexions et faire passer le trafic en utilisant des chemins spécifiques.
Imaginez que vous copiez ce type de configuration sur routeur après routeur et que vous deviez vous souvenir exactement de l'adresse IP à modifier, du bouclage à utiliser, des ACL à inverser et des listes de préfixes à modifier. L'automatisation rend ce processus considérablement plus efficace et sans le risque associé à un ingénieur aux yeux troubles qui regarde quelques dizaines de fenêtres PuTTY.
Nous rencontrons le même problème lors de la construction d'un réseau iBGP entièrement maillé à grande échelle. Chaque haut-parleur BGP du maillage complet a besoin de la configuration complète. Lorsque vous ajoutez la complexité des protocoles de routage supplémentaires nécessaires à l'accessibilité, cela devient une aventure de copier-coller.
Les défis de l'automatisation de BGP
Dans les réseaux extrêmement étendus, une équipe de service informatique peut avoir quelques ingénieurs pointus utilisant des scripts EEM intégrés ou des scripts Python hors boîte. Historiquement, cependant, la plupart des périphériques réseau n'ont pas pris en charge beaucoup d'options de programmabilité intégrées ou non, de sorte que l'automatisation du réseau n'a jamais décollé.
Cela change enfin, cependant. Pendant un certain temps, les opérateurs de réseau aspiraient à un moyen plus simple de configurer un grand nombre d'appareils avec des configurations complexes, et les fournisseurs réagissent enfin. Bien que ce soit une excellente nouvelle, il y a des obstacles majeurs à surmonter.
- Premièrement, la plupart des réseaux exécutent une variété de plates-formes, y compris certains appareils hérités et des appareils de plusieurs fournisseurs. La création de scripts maison pour gérer ce type d'environnement est pour le moins difficile et, comme tout programmeur le sait, la maintenance de ces scripts via des actualisations matérielles et des modifications du réseau est souvent négligée.
- Deuxièmement, même si un réseau n'exécute qu'une petite variété de plates-formes du même fournisseur, il peut toujours y avoir une grande différence dans les options de programmabilité d'une version logicielle à l'autre. appareil à appareil. Par exemple, le NX-OS de Cisco propose Python et bash intégrés ainsi que des API ouvertes. Cisco IOS-XE évolue dans cette direction, mais ce n'est pas encore là où NX-OS en est.
- Troisièmement, le simple coût des développeurs nécessaires pour créer et maintenir des scripts personnalisés pour la gamme d'appareils que nous pourrions utiliser ne résout pas le problème de l'inefficacité et des dépenses opérationnelles élevées. En fait, cela peut même l'exaspérer. Ce dont nous avons besoin, c'est d'un Dynamic solution qui couvre une variété de plates-formes, une variété de versions logicielles et une variété d'options de programmabilité.
C'est pourquoi j'aime ce NetBrain fait. Ils ne construisent pas leurs propres commutateurs ou systèmes d'exploitation réseau : ils se concentrent sur la superposition pour tout gérer - et je veux dire tout - sans souffrir d'une configuration manuelle. Par conséquent, ils ne sont pas redevables au système d'exploitation d'un fournisseur particulier ou à un mécanisme d'automatisation particulier. Construit dans NetBrainLa plate-forme de est la capacité d'interagir par programmation avec des appareils de dizaines de fournisseurs de réseaux et de centaines de plates-formes. Et à mesure que les fournisseurs de réseaux continuent d'adopter le paradigme de l'automatisation du réseau, NetBrainLa plate-forme d'automatisation de n'en sera que plus robuste.
Surmonter les défis de l'automatisation de BGP
Jetez un œil à la capture d'écran ci-dessous de l'un des flux de travail BGP automatisés intégrés, appelé un Runbook. Notez spécifiquement qu'avec un flux de travail automatisé contenu dans un seul Runbook, je peux facilement vérifier une variété d'informations BGP en temps réel sur plusieurs appareils à la fois. Normalement, cela nécessite de se connecter à chaque périphérique et d'étudier la sortie de chaque commande show une par une. L'intégré Runbook me donne également la même visibilité sur le réseau, mais par programmation. Et gardez à l'esprit qu'il s'agit d'un élément de base intégré Runbook. Vous pouvez également créer des flux de travail personnalisés et beaucoup plus élaborés.
Grâce à Runbooks, vous vérifiez facilement une variété d'informations BGP en temps réel sur de nombreux appareils à la fois - au lieu de vous connecter à chaque appareil et d'étudier la sortie de chaque commande show une par une.
C'est bien beau, mais une conception BGP comme celle que j'ai mentionnée plus tôt avec couche après couche peut être difficile à visualiser même avec toutes ces sorties à notre disposition. Les diagrammes Visio multicouches auxquels les ingénieurs réseau doivent faire face n'aident pas beaucoup non plus, car il est difficile d'entasser autant d'informations dans un diagramme utilisable.
NetBrainL'abstraction d'automatisation de est visualisée à l'aide de Dynamic Maps, une technologie de base avec Runbooks. Dynamic Maps ne sont pas un Visio sophistiqué, cependant. Ils sont, comme leur nom l'indique, dynamiques dans la mesure où ils représentent l'état du réseau en temps réel. Chaque nœud est interactif, ce qui signifie que toutes les informations que nous fourrons généralement onglet après onglet d'un diagramme Visio obsolète sont disponibles sur un seul écran. De Dynamic Map un ingénieur peut découvrir de nouveaux appareils, obtenir une visibilité en temps réel presque instantanée, exécuter des fonctionnalités intégrées ou personnalisées Runbooks, ou explorez les appareils individuels si nécessaire.
Notez ci-dessous que les voisins iBGP sont automatiquement indiqués par une ligne pointillée après une découverte automatisée du réseau. NetBrain construit ça dynamic map pour vous, et chaque élément individuel, y compris les liens et les appareils, peut être analysé plus en détail.
Dans cette capture d'écran de NetBrainDans l'environnement d'essai de , les voisins BGP sont automatiquement indiqués par une ligne pointillée après une découverte automatisée du réseau.
Si vous devez vous concentrer sur un seul routeur tel que BGP-R1, il vous suffit de sélectionner l'appareil et de choisir la configuration BGP dans le menu pour obtenir une sortie automatique.
Le dépannage des relations de voisinage BGP commence généralement par la vérification des erreurs de configuration telles que le multisaut eBGP mal configuré. Notez dans le graphique ci-dessous que l'exécution du dépannage BGP intégré Runbook vérifie par programmation plusieurs erreurs de configuration courantes sur tous les appareils du réseau en un seul clic. Ici, nous pouvons voir que NetBrain a découvert une mauvaise configuration sur le routeur BGP-R3.
Bien que BGP puisse être un ours à configurer et à dépanner, il s'agit néanmoins d'un protocole de routage très puissant et il est peu probable qu'il soit remplacé de si tôt. Le fait qu'il soit si personnalisable le rend très utile, surtout à grande échelle. Nous avons juste besoin d'une meilleure façon de le gérer.
Expérimenter avec NetBraintechnologies de base utilisant le Essai instantané afin de voir de première main comment l'automatisation peut changer les opérations du réseau d'entreprise. Les laboratoires BGP ne sont pas aussi effrayants que l'exemple que j'ai donné plus tôt, mais ils montrent à quel point Dynamic Maps et Runbooks sont dans la gestion d'un domaine BGP.
NetBrain automatise ce que nous avons fait manuellement pendant des années. L'ancienne méthode n'a plus de sens, et vraiment, elle n'en a jamais eu. Automatisation par Dynamic Maps et Runbooks réduit les dépenses opérationnelles liées à la gestion d'un WAN d'entreprise exécutant BGP sans perdre aucun des avantages de notre protocole de routage le plus apprécié.