Modèles pour le provisionnement Netconf

Workflow général de modification d’un modèle

Les étapes suivantes décrivent le flux de travail général pour modifier un modèle Jinja fourni et s’assurer que le provisionnement souhaité prend effet :

1. Décidez des propriétés utilisateur nécessaires et de leurs valeurs.

2. Modifiez le modèle Jinja approprié pour inclure ces propriétés.

3. Redémarrez netconfd pour que les modifications puissent prendre effet :

4. Provisionnez ou modifiez le LSP à l’aide de l’interface utilisateur Web et incluez les propriétés utilisateur et leurs valeurs dans l’onglet Propriétés utilisateur de la fenêtre Provisionner le LSP ou Modifier LSP.

5. Vérifiez la configuration du routeur.

Présentation des modèles de provisionnement Netconf

Il existe deux types de modèles fournis dans le répertoire des modèles :

• Les modèles d’encodage sont destinés à un usage interne uniquement et ne doivent jamais être modifiés ou supprimés. Tous ces modèles ont « encoding » dans leur nom (lsp-modify-encoding.hjson, par exemple).

• Les modèles de configuration permettent de transformer les clés de document JSON en instructions de configuration d’appareil. Ces modèles peuvent être modifiés et utilisés comme modèles pour créer de nouveaux modèles. Actuellement, ces modèles ont tous « junos » dans leur nom, (lsp-modify-junos.hjson, par exemple), bien que, tant que vous utilisez le suffixe .hjson, vous puissiez nommer les nouveaux modèles selon vos préférences.

Exigences du modèle

Gardez à l’esprit les exigences du modèle suivantes :

• Si vous créez un nouveau modèle, assurez-vous que l’utilisateur PCS dispose de l’autorisation de fichier Unix pour le lire.

• Les fichiers modèles sont des documents hjson, donc leurs noms de fichiers doivent avoir le suffixe .hjson.

• Le démon Netconf (NETCONFD) doit être redémarré pour que les modifications de modèle soient appliquées :

• Le format texte est pris en charge pour les instructions de configuration d’appareil. Le format XML est pris en charge pour modifier les périphériques Cisco IOS XR.

• Lorsque vous mettez à niveau une build NorthStar, les modèles fournis dans la nouvelle build remplacent ceux qui étaient fournis avec la build d’origine. Vous pouvez éviter la perte de vos modifications de modèle en sauvegardant vos modèles dans un autre répertoire du serveur avant la mise à niveau de NorthStar, ou en enregistrant vos fichiers modifiés avec des noms de fichiers différents.

Structure du modèle

Chaque modèle possède deux types d’attributs :

• Attributs de clé de routage qui décrivent le type de provisionnement pour lequel le modèle doit être utilisé. La valeur de routing-key n’est pas fixée dans NETCONFD, mais les clés suivantes sont actuellement convenues entre NETCONFD et ConfigServer pour le provisionnement LSP :

  • rest_eventd_request_key

    Utilisez-le pour ajouter un nouveau LSP.

  • rest_eventd_update_key

    À utiliser pour modifier un LSP existant.

  • rest_eventd_delete_key

    Utiliser pour supprimer un LSP

• Attributs de profil d’appareil qui définissent l’appareil à provisionner à l’aide du modèle.

  Vous pouvez utiliser n’importe quel attribut de profil d’appareil (Administration > Device Profile) tel que routerType (champ Fournisseur dans Profil d’appareil), modèle, etc. NETCONFD tente de faire correspondre les attributs du modèle avec les attributs des profils d’appareils ciblés.

• Attributs de propriétés utilisateur qui définissent des éléments tels que les attributs de mappage de service.

  Les propriétés utilisateur sont un mécanisme générique qui vous permet de « baliser » les LSP avec des propriétés supplémentaires. Les propriétés utilisateur peuvent notamment marquer un LSP avec le nom vpn, l’adresse IP source et l’adresse IP du groupe associés au MVPN associé (pour le mappage de service).

  Dans le modèle Jinja, lorsque ces propriétés utilisateur sont définies, un ensemble correspondant d’instructions (lié au mappage de service) est également généré. La prise en charge dans le corps REST et dans l’interface utilisateur Web est la même. Dans le corps REST, vous incluez les propriétés utilisateur sous « userParameters », tandis que dans l’interface utilisateur web, vous les incluez dans l’onglet Propriétés utilisateur de la fenêtre LSP Provisionner (ou modifier).

Les tableaux 1, 2 et 3 détaillent les clés de document JSON prises en charge pour ajouter des LSP, modifier des LSP, supprimer des LSP et modifier des liens.

Modèles de macros

Les modèles Jinja prennent en charge les macros pour définir des fonctions réutilisables. Le répertoire de modèles NorthStar comprend les macros répertoriées dans le Tableau 4.

Exemples de modèles Jinja pour le mappage de services

Dans l’extrait de modèle Jinja suivant, les instructions relatives au mappage de service du LSP P2MP au MVPN multicast sont provisionnées avec le LSP si le LSP a associé la propriété utilisateur « vpn-name ».

Dans l’extrait de modèle Jinja suivant, l’instruction relative au mappage de service du LSP au CCC-VPN est provisionnée avec le LSP si le LSP lui a associé la propriété utilisateur « ccc-vpn-name ».

Exemple de modèle Jinja pour les LSP SR

Voici un exemple d’extrait de modèle Jinja utilisé pour les LSP SR provisionnés par NETCONF. Si une valeur SID de liaison est spécifiée, un SID SR LSP de liaison est provisionné. Sans SID de liaison spécifié, un SID SR LSP standard non contraignant est provisionné.