Règles d'ingénierie¶

Les Règles d'ingénierie permettent des déploiements conditionnés par des filtres avancés. Les configurations sont appliquées uniquement aux équipements ou interfaces qui répondent à des critères techniques spécifiques.

Composition de règles et orchestration de services¶

Une règle d'ingénierie regroupe un ou plusieurs services à exécuter en séquence.

Conteneur de règle vide — Initialisation d'une nouvelle règle avant d'ajouter des services.

Sélection de services et catalogue¶

Avalon permet de sélectionner parmi différents types de services :

Avalon templates & Custom services : Services de gestion fournis par Avalon (création d'utilisateurs, configuration RADIUS etc.) et vos propres modèles Jinja2 activés pour les règles d'ingénierie.

Ces deux types de services sont mélangés dans la même interface de sélection et accessible en cliquant sur le bouton + Add service

Service natif fourni par Avalon :¶

Sélection de service natif — Accès aux modèles natifs d'Avalon comme User ou RadiusServer.

Service custom créé par l'utilisateur :¶

Sélection de service personnalisé — Sélection d'un service custom.

Dans les deux cas, les paramètres du service doivent être remplis dans cette fenêtre.

Warning

Ceci implique qu'il n'est pas possible de configurer différentes valeurs pour un même paramètre (hors paramètre de type Interfaces).

Configured Services : Services préconfigurés avec des paramètres prédéfinis.

Sélection de services préconfigurés — Choix parmi les services préconfigurés existants.

Dans ce cas de figure, les paramètres ont déjà été renseignés à la création de l'instance globale du service.

Instanciation et paramètres¶

Lorsque vous sélectionnez un service, vous devez définir ses paramètres. Vous pouvez regrouper plusieurs services au sein de la même règle.

Définition de paramètres — Configuration de paramètres spécifiques pour un service au sein de la règle.

Paramètres multi-services — Une seule règle gérant plusieurs services et leurs paramètres respectifs.

Glisser-Déposer¶

Les services sont exécutés de haut en bas. Vous pouvez réorganiser en glissant verticalement pour respecter les dépendances (ex : créer un utilisateur avant de l'assigner à RADIUS).

Ordre des services — Utilisation du glisser-déposer pour définir la priorité d'exécution.

Séquence finalisée — La séquence de règle finalisée prête pour le déploiement conditionnel.

Priorité d'exécution multi-règles¶

Avalon prend en charge l'exécution séquentielle de plusieurs règles. L'ordre est vertical : la règle en haut s'exécute en premier.

Hiérarchie de règles — Orchestration de plusieurs règles pour une session d'exécution en masse.

En cliquant sur Run, vous sélectionnez le site cible et le mode de déploiement (Dry Run ou Deploy). La connexion aux équipements suit la cascade de résolution des identifiants.

Déclenchement de règles en masse — Configuration du déploiement à l'échelle du site pour un groupe de règles.

Le moteur de filtrage¶

Les conditions déterminent quel équipement ou interface recevra la configuration.

Logique basée sur la base de données¶

Le moteur de filtrage fait correspondre les règles avec la base de données Avalon, et non avec des données récupérées en temps réel.
Il est important de planifier des tâches Autodiscovery fréquentes pour garantir que la base de données reflète l'état actuel du réseau.

Catégories de conditions¶

Les filtres sont organisés en deux catégories :

Device : Cible les attributs au niveau matériel (modèle d'équipement, VLANs globaux).
Interface : Cible les attributs spécifiques au port (nom d'interface, type, VLAN configuré).

Catégories de filtres — Sélection entre filtres au niveau équipement et au niveau interface.

Filtres disponibles au niveau équipement :

Device model - Filtrer selon le modèle matériel spécifique (ex : Catalyst 9300, Nexus 9000)
VLAN on device - Cibler les équipements ayant un VLAN spécifique configuré

Filtres disponibles au niveau interface :

IP on interface - Correspondre aux interfaces avec des adresses IP ou sous-réseaux spécifiques
VLAN on interface - Cibler les interfaces associées à des VLANs spécifiques
Interface type - Filtrer par catégorie d'interface :
- l2_access - Ports d'accès Layer 2
- l2_8021q - Ports trunk Layer 2 (802.1Q)
- l3_main - Interfaces routées Layer 3
- l3_subif - Sous-interfaces Layer 3
- svi - Switch Virtual Interfaces (interfaces VLAN)
Interface name - Correspondre selon les modèles de nommage d'interface (ex : GigabitEthernet1/0/1)
Native VLAN - Cibler les interfaces trunk avec un VLAN natif spécifique
Template name - Filtrer les interfaces selon les modèles de service personnalisé appliqués

Types d'interface personnalisés

Des types d'interface supplémentaires peuvent être ajoutés à Avalon sur demande pour correspondre aux exigences spécifiques de votre architecture réseau.

Référence des opérateurs¶

Avalon fournit plusieurs opérateurs. Chaque opérateur existe également en version NOT (ex : NOT EQUALS, NOT IN, NOT MATCHES).

Opérateurs simples :

EQUALS : Effectue une correspondance d'égalité stricte.
CONTAINS : Correspond si la valeur trouvée inclut la chaîne spécifiée. Ex : un port trunk "contient" les VLANs X et Y, même si d'autres VLANs sont présents.
IN : Correspond si la valeur trouvée est incluse dans la liste fournie. Ex : vérifier si le VLAN d'un port d'accès est soit X soit Y.

Opérateurs Regex :

MATCHES : Permet l'utilisation d'expressions régulières. Ex : pour cibler une interface source avec une IP commençant par 192.168.254 ou 192.168.255, la valeur pourrait être : 192.168.25[4,5].

Opérateurs simples — Opérateurs pour vérifications d'égalité et d'inclusion standard.

Opérateurs Regex — Correspondance de motifs avancée utilisant les expressions régulières.

Exemple pratique : Mise à jour de description de port¶

Dans ce scénario, nous mettons à jour la description de tous les ports Access configurés sur les VLANs 10 ou 20 dans le Bâtiment B1.

Étape 1 : Configuration de règle¶

La règle est définie avec un service (LOOP_OVER_INTERFACES) et deux conditions :

Interface type EQUALS l2_access.
VLAN on interface IN [10, 20].

Filtre de type — Filtrage pour les types de port 'l2_access'.

Filtre VLAN — Ciblage de VLANs utilisateur spécifiques.

Logique finale — La règle finalisée combinant les paramètres de service avec les filtres d'interface.

Étape 2 : Sélection du périmètre¶

Lors du déclenchement de la règle, nous sélectionnons le Bâtiment B1 qui contient des commutateurs d'accès et d'agrégation.

Étape 3 : Dry Run¶

Lors du déclenchement d'un dry run, Avalon identifie que seuls ACCESS-1-1a, ACCESS-1-1b, et ACCESS-1-2 contiennent des ports correspondant à ces critères.

Résumé du Dry Run — Identification des équipements correspondants dans le périmètre B1.

Examinons les résultats pour ACCESS-1-1a

Détails du Dry Run — Examen de la configuration rendue pour les interfaces ciblées.

Étape 4 : Construire la confiance¶

En utilisant WebSSH, nous vérifions que les ports récupérés par le dry run correspondent à notre règle :

Vérification de l'état initial — Vérification de l'état du port via CLI avant déploiement.

Étape 5 : Déploiement et vérification finale¶

Une fois le service déployé, une vérification via WebSSH confirme que la description a été correctement appliquée aux interfaces ciblées. La piste d'audit complète est conservée dans la section Transaction History.

Vérification de l'état final — Déploiement réussi confirmé via vérification CLI post-déploiement.

Historique d'exécution — Journaux d'audit montrant le succès de toutes les transactions générées par la règle.

Vous pouvez également consulter l'historique de déploiement du service dans la sous-section de la section Inventory.

Dans cet exemple, il s'agissait d'un Custom Service, vous accéder à l'historique de ce service via Inventory / Network Services / Custom Services :