[PYTHON] J'ai essayé d'utiliser PyEZ et JSNAPy. Partie 4: Automatisez la configuration du FAI avec PyEZ et JSNAPy
J'ai essayé d'utiliser PyEZ et JSNAPy. C'est le dernier épisode de. Cette fois, je présenterai le contenu de l'automatisation du travail de paramétrage de l'appairage eBGP qui est courant dans le travail de backbone ISP utilisant PyEZ et JSNAPy.
J'ai essayé d'utiliser PyEZ et JSNAPy. Partie 1: Présentation J'ai essayé d'utiliser PyEZ et JSNAPy. Partie 2: J'ai essayé d'utiliser PyEZ J'ai essayé d'utiliser PyEZ et JSNAPy. Partie 3: J'ai essayé d'utiliser JSNAPy J'ai essayé d'utiliser PyEZ et JSNAPy. Partie 4: Automatiser la configuration du FAI avec PyEZ et JSNAPy
Que faire dans l'épisode final
Profitant de ce que j'ai appris dans la partie I, je vais essayer d'automatiser le travail de peering BGP, qui est l'une des tâches qui se produisent fréquemment dans le backbone du FAI.
L'appairage BGP est une opération de connexion eBGP pour connecter les routeurs de l'organisation qui possède le numéro AS. En entrant les paramètres eBGP alors que les routeurs sont directement connectés les uns aux autres dans un centre de données spécifique, les informations d'itinéraire sont échangées et le trafic est échangé.
Le déroulement du travail d'appairage BGP est le suivant.
- Négociations entre organisations / organisation du câblage sur site
- Câblage des câbles
- Paramètres d'interface
- Confirmation de la communication
- Saisie des paramètres eBGP
- Confirmation de la publicité de l'itinéraire
- Vérifiez l'état de la transition du trafic
Cette fois, nous automatiserons les étapes 3 à 6 du travail de paramétrage logique. Ensuite, au lieu d'automatiser soudainement tout le processus, nous avons procédé en partant du principe que le réglage / la confirmation fonctionnait juste avant que la validation ne soit automatisée, et que la validation puisse être effectuée ou non était semi-automatisée en laissant cela à l'appréciation de l'opérateur.
Configuration système automatisée
Ceci est une image de configuration du système.
Ici, l'histoire est de saisir les paramètres d'interface et les paramètres eBGP dans le routeur JUNOS "Firefly 1" qui n'a pas été configuré via la bibliothèque PyEZ et la bibliothèque JSNAPy.
Dans ce système, le travailleur crée le "fichier de scénario" suivant comme alternative au manuel de procédure de travail et à la configuration du routeur que le travailleur a traditionnellement créé. En chargeant ce fichier de scénario dans le programme d'exécution de scénario, le processus de configuration du routeur et de vérification de l'état du réseau peut se dérouler selon la procédure prévue par l'opérateur. Dans ce système, le travailleur ne peut travailler qu'en créant ce fichier de scénario sans créer à l'avance le manuel de procédure conventionnel et la configuration du routeur, le but est donc de réduire la charge sur le travailleur et le réviseur.
Fichier de scénario
purpus: |
Ce travail est effectué par ABC Co., Ltd.(AS65002)Et le routeur exploité par
Le but est de créer un pair privé à la base A.
L'échange d'itinéraire est reçu un itinéraire à la fois/Sera envoyé et dépend du travail
L'impact du réseau est supposé être mineur.
operator: Taiji Tsuchiya
operation_date: 20161115
hosts:
management_ipaddress: 192.168.34.16
hostname: firefly1
model: firefly-perimeter
username: user1
password: password1
scenario:
- test_hostname
- test_model
- test_interface:
interface_name: ge-0/0/2
interface_status: up
- set_add_interface:
interface_name: ge-0/0/2
interface_address_ipv4: 192.168.35.1
interface_subnet_ipv4: 30
interface_description: AS65002_peer
- test_interface:
interface_name: ge-0/0/2
interface_status: up
- set_add_bgp_neighbor:
interface_name: ge-0/0/2
neighbor_asnum: 65002
neighbor_address_ipv4: 192.168.35.2
neighbor_description: AS65002_peer
- test_bgp_neighbor:
neighbor_address_ipv4: 192.168.35.2
neighbor_status: Established
- set_add_bgp_policy_external:
external_policy_name: AS65002_export
advertised_route_address_ipv4: 10.10.10.0
advertised_route_subnet_ipv4: 24
interface_name: ge-0/0/2
neighbor_address_ipv4: 192.168.35.2
- sleep_10sec
- test_bgp_received_route:
neighbor_address_ipv4: 192.168.35.2
received_route_address_ipv4: 10.10.30.0
received_route_subnet_ipv4: 24
- test_bgp_advertised_route:
neighbor_address_ipv4: 192.168.35.2
advertised_route_address_ipv4: 10.10.10.0
advertised_route_subnet_ipv4: 24
En regardant le fichier de scénario ci-dessus, vous pouvez avoir du mal à le lire à première vue car il est plein de mots anglais. Le fichier de scénario se compose d'une combinaison du "nom de procédure" requis lors du travail sur le routeur et des "paramètres" nécessaires pour cela. .. La procédure commençant par "set _..." indique le travail de paramétrage du routeur et la procédure commençant par "test _..." indique le travail de confirmation du routeur.
De ceux qui font habituellement des manuels de procédures de travail et des configurations de routeurs et de ceux qui sont inspectés, si vous lisez fermement le fichier de scénario, vous pouvez imaginer quel type de procédure vous essayez de réaliser. Et je pense que vous pouvez avoir l'impression que c'est beaucoup plus facile que de préparer la configuration du routeur.
En tant que concept de conception de ce système, «Il est préférable de simplifier les informations à l'extrême limite comme un fichier de scénario plutôt qu'un manuel de procédure de travail plein de japonais ordinaire, pour les points que le créateur / réviseur devrait vérifier à l'origine. Nous mettons en œuvre un tel système avec l'idée qu'il peut être possible de concentrer notre attention sur l'inspection (car il n'y a pas d'éléments de confirmation inutiles).
À ce stade, j'ai parlé de "le worker ne fait pas de configuration de routeur dans ce système", mais vous vous êtes peut-être demandé "comment faire une configuration d'entrée?". Dans ce système, la configuration du routeur contient à l'avance les fichiers modèles suivants pour plusieurs modèles à l'intérieur du système, et génère automatiquement la configuration du routeur en se référant au fichier modèle correspondant à chaque procédure à appeler. Est implémenté.
Fichier modèle_Pour la configuration de voisin BGP
protocols {
bgp {
family inet {
unicast;
}
group {{ interface_name }} {
type external;
neighbor {{ neighbor_address_ipv4 }} {
description {{ neighbor_description }};
peer-as {{ neighbor_asnum }};
}
}
}
}
Le fichier de configuration du routeur est automatiquement généré en faisant correspondre les paramètres (format YAML) extraits du fichier de scénario au fichier modèle ci-dessus (format Jinja2). En extrayant les paramètres du fichier de scénario et en générant la configuration du routeur pour chaque procédure, l'opérateur peut éviter les problèmes du travail de pré-création de la configuration de routeur conventionnelle.
Paramètres du modèle(Extrait du fichier de scénario)
- set_add_bgp_neighbor:
interface_name: ge-0/0/2
neighbor_asnum: 65002
neighbor_address_ipv4: 192.168.35.2
neighbor_description: AS65002_peer
Fichier de configuration du routeur généré automatiquement
protocols {
bgp {
family inet {
unicast;
}
group ge-0/0/2 {
type external;
neighbor 192.168.35.2 {
description AS65002_peer;
peer-as 65002;
}
}
}
}
En suivant le flux ci-dessus et en exécutant la procédure de configuration du routeur et la procédure de confirmation du routeur extraites et générées à partir du fichier de scénario dans l'ordre, le travail peut se poursuivre dans l'ordre prévu par le travailleur. ..
Résultat de l'exécution du programme
Le programme d'automatisation final est publié sur GitHub. https://github.com/taijiji/scenarioJUNOS
Si vous exécutez le programme avec firefly1 (paramètre d'interface non implémenté, paramètre eBGP non implémenté) et firely2 (paramètre d'interface terminé, paramètre eBGP terminé), l'opération sera la suivante. L'écran de gauche montre le système d'automatisation, le coin supérieur droit montre le routeur Firefly1 et le coin inférieur droit montre le routeur Firefly2.
Les lettres vertes indiquent "la partie où la normalité est confirmée", les lettres rouges indiquent "la partie où l'anomalie est confirmée", et les lettres noires indiquent "la partie où l'opérateur veut prendre une décision".
Le résultat de l'exécution du programme s'affiche comme indiqué ci-dessous.
↓ J'ose mettre NG ici pour démonstration. Il faut des dizaines de secondes pour établir une session BGP, vous devez donc dormir et attendre avant qu'elle ne devienne établie.
Il peut être ennuyeux de voir beaucoup de personnages affichés, mais pendant le travail réel, il suffit de se concentrer sur les "caractères jaunes" et "les caractères rouges" qui peuvent provoquer des anomalies, et les caractères verts sont concentrés. Il n'est pas nécessaire de confirmer. Cela réduira considérablement le fardeau du travailleur. Les travailleurs peuvent alors travailler avec tous leurs nerfs concentrés sur la détection des anomalies dangereuses sur lesquelles ils devraient se concentrer le plus.
Résumé
Cette fois, nous avons pu construire un système automatisé basé sur un fichier de scénario qui simplifie le manuel des procédures de travail conventionnelles. En utilisant PyEZ et JSNAPy, j'ai pu construire ce système en environ deux semaines de travail réel sans me coincer dans un grand mur. (Environ la moitié de ce temps était le temps de charger le document.)
PyEZ est une bibliothèque très collaborative, et la documentation est bien organisée, donc il n'y avait presque pas de colmatage. (Si j'ose le donner, je viens de traverser sans savoir que le port utilisé pour NETCONF sur SSH est TCP830.)
JSNAPy a été très utile pour créer des outils de test. Pouvoir implémenter ce système sans aucune expression régulière m'a aidé à l'implémenter rapidement. Cependant, comme l'outil lui-même est nouveau, la documentation n'a pas encore été préparée et j'y ai été accro à plusieurs reprises. En particulier, il était difficile de comprendre les moyens de spécifier le xpath et d'obtenir les résultats du test, et j'ai souvent eu le sentiment que «je veux obtenir de tels résultats de test, mais comment puis-je écrire le fichier de test? En fait, il n'y a aucun moyen de le faire, alors j'ai souvent noté les conditions de test auxquelles je pouvais penser, je les ai exécutées et j'ai adopté celles qui fonctionnaient bien tout en regardant les résultats. J'imagine qu'à mesure que le nombre d'exemples de fichiers de test augmentera à l'avenir, le nombre de dépendances ici diminuera. Il y a certaines choses que nous ne pouvons pas faire pour créer un fichier de test en moins de temps. Par exemple, comment obtenir le résultat quand test_ping ou test_traceroute échoue, Des éléments de confirmation un peu compliqués tels que "instruction conditionnelle pour confirmer que d'autres que la route cible n'est pas reçue / transmise (double refus)" et "comment confirmer que BGP ne fonctionne pas" n'ont pas encore été implémentés. J'ai fait.
Enfin, en ce qui concerne le programme de démonstration que j'ai réalisé cette fois, bien qu'il n'ait pas été entièrement implémenté faute de temps, j'ai pu transmettre la forme idéale de travail en réseau pour la prochaine génération avec une image concrète à travers la démo. Je suis contente.
Les problèmes liés à l'introduction de ce système sont "si les opérateurs et les réviseurs accepteront ce fichier de scénario au format YAML" et "si le même mécanisme peut être déployé sur les routeurs d'autres entreprises en tant qu'outil compatible avec plusieurs fournisseurs". Il reste encore quelques problèmes. Dans ce domaine, je pense que ce serait bien si nous pouvions progressivement améliorer le système en fonction des besoins du site d'exploitation tout en introduisant effectivement le système.
Recommended Posts