Audit

Analysez l'état du réseau, recherchez dans les configurations et surveillez le comportement des équipements sans impacter la production, grâce au module Audit.

Compliance

Le module Compliance vérifie que l'état opérationnel des équipements respecte vos exigences. Vous décrivez une exigence sous forme de règle, Avalon l'exécute sur les équipements choisis et produit un rapport de conformité, planifiable et suivi dans le temps.

Une règle se construit visuellement en reliant des blocs. Elle ne modifie jamais la configuration : la conformité est en lecture seule.

Vue d'ensemble

Liste des règles de conformité avec leur dernier résultat et les actions disponibles.

La page Compliance Rules liste vos règles ; créez-en une avec New rule. Chaque règle propose ces actions :

• Edit (crayon) : ouvrir la règle dans le constructeur.
• Trend : afficher la tendance de conformité de la règle dans le temps.
• Duplicate : dupliquer la règle pour la décliner.
• Run : lancer l'audit sur une sélection d'équipements.
• Delete : supprimer la règle.

En dessous, le panneau Reports conserve l'historique des exécutions. Chaque rapport propose Show (affichage détaillé), export PDF et Excel, et suppression ; Delete all vide tout l'historique.

Le constructeur de règles

Une règle est un graphe orienté : les données circulent le long des liens, des sources (à gauche) vers les assertions (à droite). Dès qu'un bloc est raccordé à un bloc amont, il reçoit automatiquement la sortie de ce dernier et la transforme selon son rôle. Vous n'exécutez rien manuellement : Avalon parcourt le graphe dans l'ordre au moment de l'audit.

Composition d'une règle : sources à gauche, assertions à droite.

Chaque bloc a un rôle précis :

Bloc	Rôle
Source	D'où viennent les données : un template de collecte (lues sur l'équipement, connexion requise) ou une source de la base de données Avalon (Device, Device Ports), sans connexion.
Scope	Restreint les équipements audités selon leurs attributs d'inventaire (modèle, version, type d'équipement...). Les scopes sont évalués en premier : un équipement hors périmètre est écarté sans connexion (quand l'inventaire suffit à le déterminer) et n'entre pas dans le calcul des taux de conformité.
Filter	Restreint les lignes d'une source selon la valeur d'un champ (ex : ne garder que les ports trunk).
Join	Fusionne deux sources sur un champ commun (ex : interface) pour croiser leurs colonnes.
Assertion	L'exigence à vérifier : un champ, un opérateur, une valeur et un Quantifier.
Display	Choisit les colonnes affichées dans le rapport.

Raccordement des blocs

Chaque type de bloc accepte un nombre d'entrées défini, et certains sont obligatoires pour qu'une règle soit valide :

Bloc	Entrées	Sortie	Obligatoire
Source	Aucune (point de départ)	Oui	Oui, au moins une
Scope	Une seule	Non	Non (aucun, un ou plusieurs)
Filter	Une seule	Oui	Non
Join	Deux ou plus	Oui	Non (uniquement pour croiser des sources)
Assertion	Une seule	Non	Oui, au moins une
Display	Une seule	Non	Non

• Une même Source peut alimenter plusieurs blocs en aval : le même jeu de données sert alors à plusieurs branches (ex : une source de trust vérifiée par deux assertions différentes).
• Scope, Filter, Assertion et Display n'acceptent qu'une seule entrée : un second lien vers le même bloc est refusé.
• Vous pouvez (et devez, si besoin) placer plusieurs blocs Scope. Un équipement doit satisfaire tous les scopes pour entrer dans le périmètre (ET logique) : pratique pour combiner des critères, par exemple un modèle précis et un type d'équipement donné.
• Un Scope n'a pas de sortie : une Source (éventuellement filtrée) l'alimente et sa branche s'arrête là. Il sert uniquement à sélectionner les équipements audités ; il n'est donc jamais relié à un Join ni à une Assertion, qui ont leurs propres sources.
• Un Join ne sert que si vous croisez au moins deux sources sur un champ commun.

Assertion et Quantifier

L'assertion porte sur les lignes qui lui parviennent. Le Quantifier définit la règle de succès :

• ALL : toutes les lignes doivent satisfaire la condition.
• EXISTS : au moins une ligne doit la satisfaire.
• NONE : aucune ligne ne doit la satisfaire.

Sources de données

Trois familles de sources sont disponibles :

• Templates de collecte : les données lues sur l'équipement via un template de collecte (Switchports, VLANs, NAC, DHCP Snooping, DAI, MAC Address Table, Hardware...). La collecte nécessite une connexion à l'équipement. La liste complète et le détail des champs figurent sur la page Templates de collecte.
• Device : une ligne par équipement issue de l'inventaire (hostname, modèle, version, type d'équipement...). Aucune connexion requise, la source peut donc servir de scope.
• Device Ports : une ligne par port issue de l'inventaire. Expose notamment le champ is_managed_uplink : vrai pour les ports trunk (l2_8021q) reliés à un commutateur managé situé en amont (vers le cœur) ou sur un lien horizontal. Les agrégats sont remontés sous le nom de leur interface d'agrégation.

Origine des champs

Dans les sélecteurs, chaque champ affiche sa source entre parenthèses (ex : Trust State (DAI Trust)) pour savoir d'où vient l'attribut vérifié.

Opérateurs

Opérateur	Signification
EQUALS / NOT_EQUALS	Égal / différent (insensible à la casse).
CONTAINS / NOT_CONTAINS	La valeur trouvée inclut / n'inclut pas ce qui est spécifié (ex : les VLANs d'un trunk incluent 10).
CONTAINS_ALL / CONTAINS_ANY	La valeur trouvée inclut toutes / au moins une des valeurs de la liste. Version multi-valeurs de CONTAINS, tokenisée pour les listes de VLANs (gère les plages 10-12).
IN / NOT_IN	La valeur trouvée fait partie / ne fait pas partie de la liste fournie (ex : le VLAN d'un port d'accès est 10 ou 20).
MATCHES / NOT_MATCHES	Correspond / ne correspond pas à une expression régulière (ex : une IP commençant par 192.168.254 ou 192.168.255 → 192.168.25[4,5]).
EXISTS / NOT_EXISTS	Le champ est renseigné / vide (ou, avec une valeur, présent / absent sur l'équipement).

Vérifier une liste de VLANs

Pour valider qu'une liste (ex : snooping_vlans) couvre bien un ensemble de VLANs, utilisez CONTAINS_ALL avec les VLANs du tenant. CONTAINS ne teste qu'une sous-chaîne et donnerait un faux positif (ex : 10 trouvé dans 100).

Jointures et éléments manquants

Un Join croise deux sources (ou plus) sur un champ commun (ex : interface). Le comportement actuel :

• Si une branche est filtrée (ex : les uplinks de Device Ports filtrés sur is_managed_uplink), elle définit l'ensemble testé. Les autres sources s'y greffent sur la clé : leurs colonnes sont ajoutées quand la clé correspond, laissées vides sinon. Une clé présente uniquement dans une source non filtrée est ignorée.
• Si aucune branche n'est filtrée, seules les clés présentes dans toutes les sources sont conservées (intersection).

Ainsi, un uplink sans trust garde sa ligne avec la colonne de trust vide : l'assertion trusted == yes échoue et il ressort non-conforme.

Planification, rapports et tendance

• Planification : une règle peut être exécutée périodiquement et envoyer un e-mail récapitulatif (la configuration SMTP doit être faite au préalable).
• Rapports : chaque exécution produit un rapport consultable, exportable en PDF et Excel. Le rapport documente la règle telle qu'auditée (définition figée au moment de l'exécution) et présente les résultats par assertion, avec le taux de conformité par équipement et global.
• Tendance : l'évolution de la conformité est tracée dans le temps depuis le premier rapport de la règle.

Rapport de conformité : définition de la règle et synthèse globale.

Résultats par équipement et détail par assertion.

Cas d'usage : DHCP snooping et Dynamic ARP Inspection (DAI)

Objectif : vérifier que le trust est positionné sur les bons ports (les liens vers les autres commutateurs) et que le snooping et la DAI couvrent les VLANs utilisateurs. Une même règle porte les deux features, via plusieurs assertions.

La règle complète : trust des uplinks et couverture des VLANs, pour le snooping et la DAI.

1. Le trust est sur les bons ports

1. Source Device Ports.
2. Filter : is_managed_uplink EQUALS true (ne garde que les liens montants et horizontaux).
3. Join sur interface avec DHCP Snooping Trust et DAI Trust.
4. Deux assertions (Quantifier ALL) : trusted EQUALS yes et trust_state EQUALS Trusted.

2. Le snooping et la DAI couvrent les VLANs déclarés

1. Source DHCP Snooping → assertion snooping_vlans CONTAINS_ALL [VLANs du tenant].
2. Source DAI → assertion dai_vlans CONTAINS_ALL [VLANs du tenant].

(Quantifier ALL pour les deux.)

Un port de confiance mal configuré ressort en Non-compliant, un équipement conforme en Compliant.

Agrégats de liens

Le trust s'applique sur l'agrégat. Avalon remonte automatiquement les ports physiques membres sous le nom de leur interface d'agrégation, aussi bien côté ports que côté sortie équipement, pour que la jointure tombe juste.

Data gathering

Récupérez des données d'état opérationnel (données non-configuration) de vos équipements en temps réel. Générez des rapports à l'échelle du réseau : tables d'adresses MAC, voisins CDP, VLANs, compteurs d'interface, etc.

Collecte de données

Interface de collecte de données avec filtres et historique des rapports.

Le formulaire de collecte vous permet de configurer votre requête :

1. Data : Sélectionnez un ou plusieurs types de données à collecter (ex : Switchports, MAC Address Table, NAC).
2. Sites : Sélectionnez les sites à interroger.
3. Quick select devices : Sélection rapide par type d'équipement.
4. Devices : Sélection fine des équipements individuels.
5. Send results to : (Optionnel) Sélectionnez un ou plusieurs destinataires pour recevoir le rapport par email. La configuration SMTP doit être effectuée au préalable.
6. Report mode : Le mode de regroupement du rapport (Per service ou Per device).
7. Fetch data : Lance la collecte sur les équipements sélectionnés.

Rapports

Chaque collecte génère un rapport consultable dans la section Reports. Un rapport contient :

• Report ID : Identifiant unique du rapport.
• Inventory : Nombre d'équipements et de services interrogés.
• Start time : Date et heure de lancement, avec la durée d'exécution.
• Status : Résultat de la collecte (success, error).

Actions disponibles :

• Show results : Affiche les résultats détaillés du rapport.
• Export : Télécharge les données au format CSV/Excel.
• Supprimer : Supprime le rapport de l'historique.

Visualisation des résultats

Résultats d'un rapport avec filtrage et pagination.

La section Results offre deux perspectives pour analyser les données. Vous pouvez basculer entre elles en utilisant les boutons Services et Devices :

• Services : Regroupe les données par type de collecte. Idéal pour les audits globaux (ex : "toutes les interfaces VLAN de tout le site").
• Devices : Regroupe les données par équipement. Idéal pour les vérifications ciblées sur un équipement spécifique.

Un champ Pattern permet de filtrer les résultats affichés.

Templates de collecte disponibles

Avalon fournit d'origine une série de templates (VLANs, Switchports, MAC Address Table, Hardware, NAC, DHCP Snooping, DAI...), utilisables ici en collecte comme dans les règles de Compliance.

Le détail de chaque template et de ses colonnes est décrit sur la page Templates de collecte.

Explore configurations

Recherchez des lignes de configuration spécifiques à travers des centaines de fichiers de sauvegarde sans avoir à les ouvrir individuellement.

Utilisation

• Pattern : Entrez une chaîne de texte ou une Regex (ex : telnet, password 7, 192.168.1.1).
• Scope : Sélectionnez les sites ou types d'équipements à rechercher.

Recherche de l'utilisation de 'telnet' à travers les sauvegardes de configuration du site.

Résultats

Le tableau affiche le statut de correspondance pour chaque équipement.

• Pattern match : Indique si la chaîne a été trouvée.
• Download : Vous pouvez télécharger le fichier de configuration spécifique directement depuis cette vue.

Compare configurations

L'outil Compare affiche un « Diff » visuel entre deux fichiers de configuration.

Utilisation

• Validation de changements : Comparer le running-config d'un équipement à deux dates différentes (ex : "Avant" vs "Après" maintenance).
• Standardisation : Comparer les configurations de deux équipements similaires (ex : ACCESS-1-1a vs ACCESS-1-1b).

Comparaison visuelle mettant en évidence les ajouts (vert) et suppressions (rouge).

Indicateurs visuels

• Vert Lignes présentes dans le fichier de droite mais absentes dans celui de gauche (Ajouts).
• Rouge Lignes présentes dans le fichier de gauche mais absentes dans celui de droite (Suppressions).

Devices logs

Recherchez dans les messages Syslog exportés par les équipements vers Avalon, depuis une interface centralisée.

Utilisation

Vous pouvez affiner la recherche en utilisant :

• Pattern : Recherche par mot-clé (ex : link-flap, OSPF, user-login).
• Time Window : Date de début et date de fin.
• Scope : Sites ou Équipements spécifiques.

Vue historique des messages syslog correspondant à un motif spécifique.

Mail alerts

Devices logs convient aux investigations historiques ; Mail alerts assure une surveillance proactive. Configurez Avalon pour envoyer une notification par email dès qu'un motif de log précis est détecté.

Créer une alerte

1. Alert Type : Actuellement prend en charge Device Logs.
2. Alert name : Un nom descriptif pour l'alerte.
3. Recipient / Send to : Sélectionnez l'adresse email à notifier.
4. Pattern : La Regex ou chaîne à surveiller (ex : root, fan fail).
5. Devices to watch : Définissez quels équipements surveiller.

Configuration d'une alerte proactive pour les changements de topologie STP.

Exemple d'email

Lorsqu'elle est déclenchée, l'email donne le contexte nécessaire au dépannage : l'IP de l'équipement, le motif correspondant et la ligne de log brute.

Mail déclenché par changement de Root STP.