Introduction
Ce document décrit comment les fichiers de configuration sont créés à différentes parties du processus ZTD (Zero Touch Deployment) et les étapes à suivre pour revenir à n'importe quel fichier de configuration spécifique sur le routeur Connected Grid (CGR).
Conditions préalables
Conditions requises
Aucune spécification déterminée n'est requise pour ce document.
Components Used
Les informations de ce document sont basées sur le déploiement ZTD avec des CGR.
Il inclut CGR (CGR1120/CGR1240), Field Network Director (FND), Tunnel Provisioning Server (TPS) et Registration Authority (RA) en tant que composants.
FND et Cisco Connected Grid Network Management System (CG-NMS) sont interchangeables car CG-NMS est une version antérieure de FND.
Les informations de ce document sont créées à partir des périphériques d'un environnement de travaux pratiques spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est actif, comprenez l'impact potentiel des commandes.
Aperçu
Dans le monde de l'Internet des objets (IoT), la fonctionnalité ZTD est essentielle pour prendre en charge le déploiement de la configuration de millions de périphériques. FND prend en charge le ZTD pour les points CGE (Connected Grid End) et les CGR.
Services ZTD
ZTD for CGR offre une large gamme de services, notamment :
- Déploiement initial de CGR avec une configuration minimale et cohérente (appelé configuration de fabrication ou fichier express-config). Une fois déployée à son emplacement final, cette configuration permettra au routeur CGR de lancer le processus ZTD avec FND et de récupérer sa configuration finale.
- Gestion de la configuration CGR. Une fois entièrement déployé, FND intègre la possibilité de modifier n'importe quelle partie de la configuration CGR.
- Mécanisme de récupération CGR en cas d'échec du processus ZTD à n'importe quelle étape.
- Mise à niveau de l'image CGR.
Phases ZTD
Étape 1. Inscription CGR à l'infrastructure de clé publique de l'utilitaire
Étape 2. Provisionnement de la configuration du tunnel CGR
Étape 3. Enregistrement final CGR (provisionnement de la configuration des périphériques)
Il n'y a aucun mécanisme d'interrogation ou de découverte effectué par FND. Chaque phase est déclenchée par le CGR. Après les phases 1 et 2, FND crée un point de restauration afin de ramener le routeur CGR à une configuration fiable avant de passer à nouveau à la phase de configuration du tunnel ou du périphérique.
Résumé
Le tableau récapitule la phase de ZTD qui sera utilisée pour mettre en oeuvre différents services :
Fonctionnalité ou événement |
Inscription SCEP (Simple Certificate Enrollment Protocol) |
Provisionnement du tunnel |
Enregistrement de périphérique |
Commentaires |
Mise à jour de la configuration du périphérique |
Non |
Non |
Oui |
Le CGR va revenir à la configuration de phase 2 |
Déploiement initial CGR |
Oui |
Oui |
Oui |
|
Rechargement inattendu CGR |
Non |
Non |
Oui |
Le routeur CGR a été enregistré avant le rechargement |
Mise à niveau du micrologiciel |
Non |
Oui |
Oui |
Le routeur CGR va revenir à la configuration de phase 1 |
Configuration de fabrication ou réapprovisionnement en usine |
Non |
Oui |
Oui |
Le routeur CGR va revenir à la configuration de phase 1 |
Réapprovisionnement de la configuration du tunnel |
Non |
Oui |
Oui |
Le routeur CGR va revenir à la configuration de phase 1 |
Organisation des fichiers de configuration
Différents fichiers de configuration sont créés à différentes parties du processus. L'idée est de créer des points de confiance que FND peut utiliser pour restaurer la configuration CGR, au cas où il ne ferait pas confiance à l'état du CGR ou qu'il voudrait mettre à jour une partie spécifique de la configuration CGR. Ces fichiers de configuration sont stockés dans la mémoire flash CGR.
Name (nom) |
Définition |
Créateur |
Lors de la création |
configuration par défaut cisco |
Configuration à partir de Cisco Manufacturing. |
Cisco |
Usine Cisco |
Manufacturing-config (express-config) |
Préconfiguration requise pour lancer SCEP et ZTD. le fichier express-setup-config est créé une fois la configuration de fabrication appliquée. |
Tiers ou utilitaires |
Avant le déploiement final |
before-tunnel-config (ps-start-config) |
= Manufacturing-config après l'inscription à l'utilitaire PKI. La seule différence est maintenant que le serveur CGR https a été reconfiguré pour utiliser le certificat de l'utilitaire FAR appelé LDevID. Ce fichier est créé par FND avant l'application de la configuration du tunnel. Il s'agit du premier fichier de configuration approuvé et il est utilisé au cas où CGR devrait à nouveau passer par le provisionnement du tunnel dans le futur. |
FND |
Avant l'application de la configuration du tunnel |
before-register-config (configuration en or) |
= before-tunnel-config + Configuration du tunnel poussée par FND. Ce fichier est créé par FND comme deuxième point de confiance avant que la configuration du périphérique ne soit poussée. Ce fichier sera utilisé si la configuration du périphérique doit être modifiée. |
FND |
CGR sur le terrain, provisionnement post-tunnel |
Configuration finale |
= before-tunnel-config + Tunnel config + Device Config. = before-register-config + Device Config. Cette configuration est enregistrée de la manière habituelle, c'est-à-dire à la configuration de démarrage |
FND |
CGR sur le terrain, provisionnement post-tunnel |
Réapprovisionnement des CGR
Le réapprovisionnement sur CGR est effectué sur la configuration de restauration de certains fichiers de configuration.
Dans le FND IoT, exécutez ces actions de réapprovisionnement dans le volet Actions de réapprovisionnement de la page Tunnel Provisioning (Config > Tunnel Provisioning).
Réapprovisionnement en usine
Il s'agit également du reprovisionnement de la configuration de Fabrication.
Utilisez la fonction de reprovisionnement en usine du FND IoT pour modifier la configuration d'usine des CGR (express-setup-config).
Réapprovisionnement du tunnel
Cette fonction permet au NOC de l'utilitaire de modifier toute partie de la configuration du tunnel qui est poussée pendant la phase de mise en service du tunnel.
IoT FND rétablit la configuration du routeur CGR à celle définie dans le fichier modèle ps-start-config.
Résumé
En résumé, la configuration finale du routeur CGR est basée sur trois blocs différents, chacun avec des objectifs spécifiques.
Bloc de configuration |
Objectif |
Principales caractéristiques |
Modèle CG-NMS utilisé pour générer le bloc de configuration |
fichier Manufacturing-config |
Point de départ pour ZTD |
- Connexion au réseau de liaison - Déclencher l'inscription SCEP - Doit être en mesure d'atteindre RA |
Spécifications de fabrication ou d'utilité |
fichier before-tunnel-config |
Fournir un point d'annulation pour provisionner la nouvelle configuration de tunnel |
- Connexion au réseau de liaison - Doit pouvoir atteindre les serveurs TPS |
Ajout SCEP de RA |
fichier before-register-config |
Fournir un point d'annulation pour provisionner la nouvelle configuration de périphérique |
- Établir un chemin sécurisé avec FND - Éviter les fuites de trafic sur le réseau de liaison - Fournir le chemin de routage prévu à l'intérieur du tunnel |
Ajout de tunnel FAR |
device-config template (aucun fichier spécifique n'a été créé une fois cette configuration appliquée) |
Finaliser la configuration FAR |
- Configuration de l'interface maillée - Renforcement de la configuration - Toutes les fonctionnalités restantes ne sont pas requises pendant la phase de mise en service du tunnel. Certaines sont codées en dur dans FND et ajoutées au-dessus du modèle. |
Modèle de configuration de périphérique FAR |
Étapes derrière la restauration de la configuration à l'aide de FND
FND ou CG-NMS peut revenir à un fichier de configuration spécifique sur le routeur. Cette fonctionnalité est basée sur config replace
erasecat4000_flash:.
FND exploite cette fonctionnalité chaque fois qu'il rétablit CGR dans ses fichiers de configuration avant-tunnel-config ou avant-enregistrement-config, mais comme il peut échouer parfois, une logique est nécessaire pour récupérer d'un tel scénario. Cette logique est en fait implémentée via un script TCL dédié appelé no-config-replace.tcl (également intégré dans l'image Cisco IOS®). FND utilisera ce script chaque fois qu'il aura besoin de restaurer CGR dans un fichier de configuration spécifique. Le script a besoin de ces entrées.
Entrées |
Définition |
Valeur |
configFile |
Fichier de configuration à restaurer |
flash:/before-tunnel-config ou flash:/before-register-config |
NomProfil |
Profil CGNA à activer après le remplacement de la configuration |
cg-nms-tunnel ou cg-nms-register |
replaceFlag |
True signifie tenter de remplacer la configuration |
1 (VRAI) |
renommerFlag |
True signifie simplement renommer le fichier sans remplacer la configuration |
0 (FAUX) |
FND envoie ces commandes pour exécuter ce script sur le routeur CGR une seule fois. Dans cet exemple, FND souhaite restaurer la configuration du routeur CGR avant l'enregistrement des périphériques :
Informations connexes