Templates de Configuration Catalyst Center

Les templates de configuration sous Catalyst Center permettent de déployer de la configuration sur un ou plusieurs équipements à la fois de manière automatisée. C’est le pilier central de la conformité de configuration sous Catalyst Center (Des nouveautés arrivent bientôt sur ce sujet 😊 ).

Il existe deux types de template de configuration :

Onboarding : template qui sont déployés sur les équipements en déploiement initial via la fonctionnalité ZTP (le fameux Day-0)

Day-N : template qui sont déployés, une ou plusieurs fois, sur des équipements déjà configurés

A travers cet article, nous allons découvrir la création et l’utilisation de templates via ce cas d’usage:

Identification des interfaces dont la description contient « 802.1X »
Configuration de l’interface en mode 802.1X + MAB

Au programme

Organisation des templates

Les templates sont disponibles via le menu Design > CLI Templates :

Les projets sont comparables à des dossiers et permettent d’organiser ses templates pour les retrouver plus facilement lorsque vous en aurez créé des centaines 😊

L’écriture des templates se fait sous le format classique Cisco CLI (IOS-XE, NX-OS, IOS-XR, IOS, etc.). Si besoin de faire des templates un peu plus avancés permettant d’utiliser des variables, d’utiliser des conditions ou des boucles, deux langages de templating sont supportés par Catalyst Center :

Jinja 2 : Le langage de template le plus couramment utilisé et que l’on retrouve par exemple dans Ansible. C’est ce langage que nous utiliserons ici.
Velocity : Langage de template connu des développeurs Java par exemple. C’était le premier langage supporté par Catalyst Center.

Création d’un template

Toujours depuis le menu Design > CLI Templates, on clique simplement sur Add et New Template:

Les variables

Pouvoir déployer de la configuration via un template sur tout un tas d’équipements c’est bien, mais si on pousse la même chose partout, c’est tout de suite moins sympa… C’est là qu’interviennent les variables 😊 Elles vont permettre, depuis un même template de configuration, d’adapter ce template à des équipements différents. Exemples de variables classiques:

Le hostname
L’adresse IP d’administration
Des Vlans spécifiques à un site
Le SNMP location
etc.

Avec le langage Jinja2, pour créer une variable, il suffit de la placer entre deux paires d’accolades {{ ma_variable }}:

L’on retrouvera ensuite dans l’onglet Variables toutes les variables déclarées. C’est là que l’on pourra définir de quel type elles doivent être, pour éviter qu’un opérateur ne renseigne une adresse IP là ou l’on attend un numéro de VLAN ou autres joyeusetés de ce genre 😊

Simulation

L’onglet Simulation permet de tester son template hors-prod afin de s’assurer de son comportement sans rien casser 😊 Autant dire que c’est une étape obligatoire avant déploiement d’un template sur des équipements distants.

Notre template devra identifier les interfaces pour laquelle la description contient « 802.1X » afin de leur pousser une configuration 802.1X + MAB. Modifions donc quelques descriptions sur les interfaces d’un de nos switch:

Depuis notre template, rendons-nous sous l’onglet Simulation afin de simuler la configuration qui serait déployer par notre template à ce stade:

Les descriptions des interfaces Gi1/0/1 et Gi1/0/3 de notre switch contiennent « 802.1X ». On croise donc les doigts pour que notre template applique bien la configuration 802.1X sur ces seules interfaces…
Et Tada 🥳🥳🥳
On voit au résultat de la simulation que la logique de notre template a bien fonctionné:

Sauvegarde et commit du template

Le bouton Save (ou le raccourci Ctrl-S) permet d’enregistrer son template à l’état de brouillon pour pouvoir continuer son développement ultérieurement. L’action du Commit permet elle d’indiquer que le template est prêt à être déployé sur des équipements.
Ci-dessous, notre template est sauvegardé (notez la case Save qui est grisée) mais non commité (voir le « Not Commited » à côté du nom du template.

On clique donc sur le bouton Commit, on inscrit un petit commentaire si on le souhaite, et notre template est ainsi prêt à se confronter à de vrais équipements 💪

Assignation du template à des équipements

Une fois le template finalisé, il est temps de l’appliquer à un ou plusieurs groupes d’équipements. On utilise pour cela des Network profiles. Deux choses à noter :

Un Template peut faire partie d’un ou plusieurs Network Profiles
Un Network Profile peut contenir un ou plusieurs templates de configuration

On accède aux Network Profiles via le menu Design > Network Profiles :

Commençons par créer un nouveau Network Profile de type Switching, qui s’appliquera donc, oh surprise, à des switches !

Notre template ne s’appliquera pas dans le cadre de la fonctionnalité ZTP (configuration initiale en sortie de carton) mais sur des équipements déjà configurés ; le fameux Day-N du cycle de vie.
Nous l’ajouterons donc à l’onglet Day-N Template(s) du Network Profile :

Appliquons maintenant ce profil à un ou plusieurs groupes de sites afin que les templates qui constituent notre profil puissent être appliqués aux équipements de ces sites :

Je l’applique ici à la zone LABNIPO qui inclue deux bâtiments:

Déploiement du template sur des équipements

L’application de toute configuration sous Catalyst Center passe par l’étape du Provisioning. Cela se passe depuis le menu Provision > Inventory. Seront appliqués sur les équipements, les paramètres définis dans les Network Settings et les Network Profiles, configurables tout deux depuis le menu Design.

A l’étape Advanced Configuration du provisioning, le système vous demandera de compléter les valeurs des variables de notre template :

On valide TOUJOURS la preview de configuration sur au moins un équipement afin de vous assurer que ce qui va être poussé sur les équipements correspond à ce que vous souhaitez. Ce serait dommage de se couper la main sur des équipements potentiellement à des centaines de kilomètres 😉

On valide que le provisioning s’est bien passé sur tous nos équipements :

Et comme on aime bien aller voir en vrai sur un équipement que la configuration est en place, on va valider la bonne configuration de nos interfaces Gi1/0/1 et Gi1/0/3 sur notre switch cobaye. Mais faisons le depuis Catalyst Center 😉

J’espère que l’article vous a plus et qu’il vous guidera dans l’automatisation et la standardisation de vos process via Catalyst Center.
Ci-dessous le template de configuration complet Jinja2 utilisé pour illustrer cet article.

Template de configuration complet au format Jinja2

vlan {{ VLAN_DATA_SECOURS }}
 name VLAN-DATA
vlan {{ VLAN_VOIX_SECOURS }}
 name VLAN-VOIX
!
service-template CRITICAL_VOICE
 voice vlan
service-template CRITICAL_DATA
 vlan {{ VLAN_DATA_SECOURS }}
service-template CRITICAL_ACCESS 
 access-group ACL-ALLOWALL
!
{#- Une confirmation est demandee pour le passage en aaa mode CPL "new-style" -#}
#INTERACTIVE
class-map type control subscriber match-any IN_CRITICAL_AUTH <IQ>yes<R>yes
#ENDS_INTERACTIVE
 match activated-service-template CRITICAL_VOICE
 match activated-service-template CRITICAL_DATA
 match activated-service-template CRITICAL_ACCESS
!
class-map type control subscriber match-none NOT_IN_CRITICAL_AUTH
 match activated-service-template CRITICAL_VOICE
 match activated-service-template CRITICAL_DATA
 match activated-service-template CRITICAL_ACCESS
!
class-map type control subscriber match-all AAA_SVR_DOWN_UNAUTHD_HOST
 match result-type aaa-timeout
 match authorization-status unauthorized
!
class-map type control subscriber match-all AAA_SVR_DOWN_AUTHD_HOST
 match result-type aaa-timeout
 match authorization-status authorized
!
class-map type control subscriber match-all DOT1X_NO_RESP
 match method dot1x
 match result-type method dot1x agent-not-found
!
class-map type control subscriber match-all MAB_FAILED
 match method mab
 match result-type method mab authoritative
!
class-map type control subscriber match-all DOT1X_FAILED
 match method dot1x
 match result-type method dot1x authoritative
!
policy-map type control subscriber DOT1X_MAB
 event session-started match-all
  10 class always do-until-failure
   10 authenticate using dot1x priority 10
 event authentication-failure match-first
  5 class DOT1X_FAILED do-until-failure
   10 terminate dot1x
   20 authenticate using mab priority 20
  10 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure
   10 clear-authenticated-data-hosts-on-port
   20 activate service-template CRITICAL_DATA
   30 activate service-template CRITICAL_VOICE
   40 activate service-template CRITICAL_ACCESS
   50 authorize
   60 pause reauthentication
  20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure   
   10 pause reauthentication
   20 authorize
  30 class DOT1X_NO_RESP do-until-failure
   10 terminate dot1x
   20 authenticate using mab priority 20
  40 class MAB_FAILED do-until-failure
   10 terminate mab
   20 authentication-restart 60
  60 class always do-until-failure
   10 terminate dot1x
   20 terminate mab
   30 authentication-restart 60
 event agent-found match-all
  10 class always do-until-failure
   10 terminate mab
   20 authenticate using dot1x priority 10
 event aaa-available match-all
  10 class IN_CRITICAL_AUTH do-until-failure
   10 clear-session
  20 class NOT_IN_CRITICAL_AUTH do-until-failure
   10 resume reauthentication
 event inactivity-timeout match-all
  10 class always do-until-failure
   10 clear-session
 event authentication-success match-all
  10 class always do-until-failure
   10 activate service-template DEFAULT_LINKSEC_POLICY_SHOULD_SECURE
 event violation match-all
  10 class always do-all
   10 restrict
!
template identity-template-dot1x-mab
 dot1x pae authenticator
 spanning-tree portfast
 spanning-tree bpduguard enable
 switchport access vlan {{ VLAN_DATA_SECOURS }}
 switchport mode access
 switchport voice vlan {{ VLAN_VOIX_SECOURS }}
 mab
 access-session host-mode multi-domain
 access-session control-direction in
 access-session closed
 access-session port-control auto
 authentication periodic
 authentication timer reauthenticate server
 service-policy type control subscriber DOT1X_MAB
!
{#- Parcours de toutes les interfaces sauf le port mgmt OoB et les interfaces L3 -#}
{% for int in __interface -%}
  {% if int.portName != "GigabitEthernet0/0" -%}
  {% if int.portMode != "routed" -%}
  {% if "802.1X" in int.description -%}
  interface {{ int.portName }}
   source template identity-template-dot1x-mab
   dot1x timeout tx-period 5
  !
{% endif -%}
{% endif -%}
{% endif -%}
{% endfor -%}