Documentation des politiques de routage : exportation et analyse de la configuration AudioCodes ARM

1. Le Rôle de l'ARM : Centralisation et Intelligence

Vous m'avez indiqué être déjà familier avec l'ARM, nous allons donc nous concentrer sur la validation de vos connaissances et la structure de sa configuration dans le contexte de votre audit. L'ARM agit comme un "cerveau" de routage externe pour votre réseau de SBC.

En résumé, au lieu de configurer des tables de routage complexes sur chaque SBC, vous définissez des politiques globales sur l'ARM. Quand un SBC reçoit un appel qui nécessite une décision de routage complexe, il interroge l'ARM qui lui indique la meilleure route à suivre. Votre tâche d'audit consiste à cartographier ces politiques globales.

2. Anatomie d'une Politique de Routage sur l'ARM

Pour analyser la configuration, il faut d'abord comprendre sa structure. Une politique de routage sur l'ARM se compose de deux grandes parties : la topologie (le "quoi") et les règles de routage (le "comment").

La Topologie : Les Briques du Réseau

La topologie dans l'ARM est une représentation virtuelle de votre réseau de voix.

Les principaux objets à connaître sont :

• Nodes : Représentent vos SBC AudioCodes qui sont gérés par l'ARM.
• VoIP Peers : Désignent les entités externes connectées à vos SBC, comme vos Trunks SIP opérateurs (PSTN), vos PBX, etc. C'est souvent la destination finale d'un appel.
• Connections : Les liens logiques entre deux Nodes (SBC).
• Peer Connections : Les liens logiques entre un Node et un VoIP Peer. C'est l'équivalent d'un "IP Group" sur le SBC.

Votre premier travail d'analyse sera d'identifier à quoi correspondent ces objets dans votre infrastructure réelle (ex: "VoIP Peer 'Orange_SIP_Trunk'" correspond bien à votre trunk opérateur Orange).

Les Règles de Routage : Le Cœur de la Logique

C'est ici que se trouve l'intelligence. L'ARM utilise une hiérarchie simple mais puissante pour organiser ses décisions.

3. Extraire la Configuration pour l'Analyse

Maintenant que vous savez quoi chercher, voyons comment l'obtenir. Il existe plusieurs méthodes pour extraire les politiques de routage.

Méthode 1 : Sauvegarde Complète via l'Interface Graphique

C'est la méthode la plus directe pour obtenir une archive complète de la configuration.

1. Connectez-vous à l'interface web de l'ARM.
2. Dans la barre d'outils en haut à droite, cliquez sur l'icône de menu (souvent représentée par le nom d'utilisateur ou une icône de profil).
3. Sélectionnez l'option "Save Configuration".
4. Cela téléchargera un fichier ARM_Configuration.zip.

Ce fichier contient une sauvegarde de la base de données interne de l'ARM. Bien qu'il ne soit pas destiné à être lu directement par un humain, il constitue un excellent instantané pour l'archivage et peut être fourni au support AudioCodes en cas de besoin. Pour notre audit, il est utile comme sauvegarde, mais la méthode suivante est plus pratique pour l'analyse.

Méthode 2 : L'API "Analytics" (Méthode Recommandée)

L'ARM dispose d'une fonctionnalité très utile qui expose sa configuration via des "vues" de base de données, accessibles par des outils externes. C'est la méthode idéale pour créer une documentation structurée.

Une fois cette API activée, vous pouvez utiliser un client de base de données (comme DBeaver, MySQL Workbench, ou même un connecteur Excel/PowerBI) pour vous connecter à la base de données MariaDB de l'ARM avec l'utilisateur analytics. Vous pourrez alors exporter le contenu des vues Routing rules view et Routing groups view sous forme de fichiers CSV. Vous obtiendrez ainsi un inventaire propre et complet de toutes vos règles de routage.

4. Analyser les Données et Documenter les Politiques

Une fois que vous avez exporté les données (par exemple, via l'API Analytics), le travail d'analyse commence. L'objectif est de traduire ces données brutes en une description compréhensible de votre plan de routage.

Je vous suggère d'utiliser une feuille de calcul (Excel, Google Sheets) avec les colonnes suivantes, en vous basant sur les informations des vues Routing groups et Routing rules :

Ce tableau vous permet de visualiser d'un coup d'œil :

• L'ordre d'évaluation (grâce aux priorités de groupe et de règle).
• Les conditions précises qui déclenchent une règle.
• La destination exacte de l'appel (le VoIP Peer qui représente votre Trunk SIP).

C'est ce document qui constituera la base de votre plan d'action pour le décommissionnement des routes. Vous saurez exactement quelles règles sont liées au CUCM et lesquelles devront être modifiées pour pointer vers Webex Calling ou être supprimées.

Conclusion de la Leçon

Félicitations ! Vous avez maintenant une méthodologie complète pour auditer la couche de routage la plus stratégique de votre infrastructure.

Points clés à retenir :

• L'ARM centralise l'intelligence du routage en se basant sur une topologie virtuelle et une hiérarchie de règles.
• La logique d'évaluation est séquentielle : l'ARM applique la première règle qui correspond en parcourant les groupes et les règles par ordre de priorité.
• L'export de la configuration est possible via une sauvegarde de la GUI, mais la méthode recommandée pour l'analyse est l'API Analytics qui fournit des données structurées.
• La documentation finale doit prendre la forme d'un tableau qui traduit les règles de configuration en une logique métier claire, en liant conditions et actions.

Vous disposez maintenant de tous les éléments pour finaliser la cartographie complète de vos flux d'appels, des règles locales sur les SBC aux politiques globales sur l'ARM.

Prochaine étape :
Nous avons couvert en profondeur le routage, qui est le flux de service principal. Cependant, pour décommissionner un système en toute sécurité, il faut aussi identifier tous les services et systèmes annexes qui en dépendent. Dans la prochaine leçon, nous allons créer un inventaire des dépendances pour chaque système (DNS, NTP, LDAP, intégrations CTI, messagerie vocale).