Aruba
Migration d'Aruba AirWave vers Central : Le Guide Technique 2026
AirWave est un logiciel moribond, et tout ingénieur s'accrochant à une instance AMP (AirWave Management Platform) sur site en 2026 gère une dette technique, pas un réseau. Aruba AirWave a atteint son apogée fonctionnelle il y a des années ; le passage à Aruba Central n'est pas seulement un rafraîchissement d'interface utilisateur, c'est un pivot architectural fondamental passant du polling hérité basé sur SNMP à un modèle de télémétrie en streaming basé sur WebSocket. Si vous n'avez pas commencé votre migration, vous êtes déjà en retard sur la transition AOS-10.
Le Crépuscule d'AirWave : Pourquoi 2026 est la Date Limite Incontournable
HPE Aruba a annoncé la fin d'AirWave depuis des années, mais la dure réalité se manifeste avec la sortie des Access Points des séries 600 et 700 et de l'architecture AOS-10. AirWave a été conçu pour l'ère AOS-6 et AOS-8 — une ère de silos « Controller-Managed » ou « Instant ». AirWave peine avec le volume considérable de télémétrie généré par les radios Wi-Fi 6E et Wi-Fi 7 modernes. Plus important encore, AOS-10 abandonne le plan de contrôle du contrôleur de mobilité local au profit d'un modèle de passerelle cloud-native, qu'AirWave ne peut tout simplement pas orchestrer.
Si vous restez sur AirWave (AMP 8.3.x), vous êtes bloqué dans le monde d'AOS-8.4/8.10. Vous perdez la capacité d'effectuer du Radio Resource Management (RRM) piloté par l'IA, vous perdez la visibilité granulaire de ClientMatch, et vous êtes contraint de gérer des environnements haute densité avec des outils conçus en 2012. La dette technique liée à la maintenance d'une appliance AMP de taille XL (probablement exécutée sur un R740 ou DL380 vieillissant) dépasse le coût d'abonnement à Central si vous tenez compte de la consommation électrique, du refroidissement et du travail manuel de réglage fin des profils RF.
Delta Architecturale : Polling vs. Télémétrie en Streaming
Le plus grand choc pour les ingénieurs passant d'AirWave à Central est le tableau de bord « Health ». Dans AirWave, vos données sont aussi anciennes que votre dernier intervalle de polling SNMP (généralement 5 à 10 minutes). Si un AP tombe en panne, AirWave pourrait ne pas vous alerter avant plusieurs minutes, après que le polling manqué ne déclenche un seuil. Dans Central, l'AP maintient une connexion WebSocket persistante (HTTPS/443) vers l'Aruba Cloud.
Les principales différences dans le plan de données incluent :
- Surveillance Stateful : Central sait le moment exact où un client échoue un three-way handshake. AirWave ne connaît que le « Client Count » (nombre de clients).
- Autorité de Configuration : Dans AirWave, vous pouviez choisir entre les modes Monitor-Only et Config-Mode. Dans Central, le cloud est la source de vérité (Source of Truth). Toute modification CLI locale sur un switch ou un AP sera écrasée par le sync-timer de Central.
- Rétention : AirWave vous limitait par l'espace disque. Central offre 30 jours de données standard avec des options de rapports à long terme via AI Insights.
La Transformation AOS-10 : La Vraie Raison de Migrer
Le passage à Central coïncide généralement avec une mise à niveau vers AOS-10. C'est là que la plupart des migrations deviennent « sanglantes ». AOS-10 élimine le processus d'élection de « Virtual Controller » (VC) traditionnel trouvé dans les Instant APs. Chaque AP dans un environnement AOS-10 est un participant égal, communiquant directement avec le cloud Central pour ses instructions de plan de contrôle. Cela supprime la latence de « redémarrage de VC » observée dans les grands clusters IAP gérés par AirWave.
! Legacy AOS-8 IAP Config (AirWave managed)
iap-master-election
virtual-controller-ip 10.1.10.5
!
! New AOS-10 Central Logic
! No VC IP. APs use 'aruba-central' point-of-presence.
! Management via:
(AP)# show ap-env
(AP)# show ap debug cloud-server
Phase de Migration 1 : Parité et Stratégie des Modèles
Vous ne pouvez pas simplement « importer » un fichier .cfg d'AirWave dans Central. Vous avez deux choix : les UI Groups ou les Template Groups. Si vous venez d'un environnement AirWave où vous utilisiez des « Groups et Folders » pour modifier en masse des périphériques, les Template Groups dans Central vous sembleront familiers mais frustrants. Dans Central, un Template Group est un bloc CLI « tout ou rien ». Une seule erreur de syntaxe dans votre mappage de %variable%, et vous coupez la connectivité de l'ensemble du site.
Nous recommandons à la plupart des entreprises de migrer vers les UI Groups. Cela vous permet d'utiliser l'interface graphique de Central pour la configuration, garantissant que le XML envoyé aux APs est toujours valide. Si vous avez plus de 500 sites distants identiques, alors et seulement alors devriez-vous considérer les Template Groups avec des téléchargements de variables .csv. Consultez notre guide sur AOS-10 Gateway Clustering pour savoir comment gérer la transition des passerelles pendant cette phase.
Phase de Migration 2 : Le Processus d'Onboarding (Greenfield vs. Brownfield)
Pour une migration brownfield, vous devez supprimer les paramètres AirWave de vos APs/Switches. Si vos appareils sont configurés pour pointer vers AirWave via DHCP Option 43 ou DNS (airwave.yourdomain.com), vous devez supprimer ces enregistrements. Une fois que l'appareil peut atteindre activate.arubanetworks.com via le port 443, il vérifiera son MAC/Serial par rapport à votre compte Central et tirera sa nouvelle configuration.
Basculement des Périphériques Étape par Étape :
- Attribuer les Licences : Assurez-vous que le MAC/Serial est dans le « Greenhouse » de Central et qu'une licence Foundation ou Advanced est appliquée.
- Déplacer vers un Groupe : Attribuez le périphérique à son groupe UI/Template préconfiguré.
- Effacer les Infos AirWave : Sur le CLI de l'appareil local :
no communication-monitor apetno amp-server. - Redémarrer : Cela force l'appareil à réinitialiser le handshake d'Activate.
La Liste de ce qui "Va Planter" : Préparation au Support Post-Migration
La migration n'est pas sans accroc. Voici ce qui posera problème au Jour 1 :
- Formatage des Rapports : Les rapports PDF d'AirWave sont personnalisables. Les rapports de Central sont plus rigides. Si votre direction s'attend à un PDF spécifique de « Weekly Wireless Health », vous devrez peut-être construire un tableau de bord personnalisé en utilisant l'API Central et PowerBI.
- Latence VisualRF : Le VisualRF d'AirWave était local et réactif. Les plans d'étage de Central nécessitent une bande passante uplink constante. Les fichiers CAO volumineux pour les plans d'étage sur une liaison MPLS de 10 Mbps seront lents.
- Gestion des Switches : Si vous utilisez des switches AOS-S (2930F/M, 5400R), l'« Configuration Audit » de Central est notoirement sensible aux commandes manuelles 'write memory'. Vous devez former votre NOC à cesser d'utiliser la CLI.
- Lien Interne : Examinez notre analyse des pièges d'intégration entre ClearPass et Central pour vous assurer que votre RADIUS CoA (Change of Authorization) ne soit pas impacté lorsque l'AP bascule vers son nouveau plan de gestion.
Analyse des Coûts : La Pilule Amère de l'Abonnement
AirWave était essentiellement « gratuit » une fois que vous aviez acheté la licence VM et les licences AP uniques, plus de faibles frais de support annuels. Central est une charge Opex récurrente. Une licence Foundation standard d'un an par nœud AP/Switch coûte généralement entre 100 et 150 USD MSRP. Pour un environnement de 500 APs, cela représente une ligne budgétaire annuelle de plus de 50 000 $.
Cependant, vous devez calculer le TCO (Total Cost of Ownership). La gestion d'un serveur AirWave nécessite :
- Calcul/stockage hyperviseur (AirWave est gourmand en ressources — 8 vCPU et 32 Go de RAM minimum pour de petites installations).
- Patching et durcissement de sécurité RHEL/CentOS.
- Vérification manuelle des sauvegardes.
Conclusion : Pas de Retour en Arrière Possible
La transition d'AirWave vers Central est inévitable. D'ici 2026, AirWave sera un outil de surveillance hérité incapable de prendre en charge les exigences de haut débit et de faible latence d'une entreprise Wi-Fi 7. La migration exige un changement de mentalité : passer d'une approche de « gestionnaire de boîtes » à une approche d'« orchestrateur de politiques ». Si vous avez besoin d'aide pour votre migration site par site ou d'une validation architecturale de haut niveau pour votre conception AOS-10, consultez nos services professionnels et notre équipe d'ingénierie sur techleague.io.
Questions fréquentes
Quelle est la principale différence technique entre AirWave et Central ?+
AirWave est un outil de surveillance on-premise basé sur SNMP, adapté aux contrôleurs AOS-8. Central est une plateforme de gestion cloud-native utilisant la télémétrie WebSocket, essentielle pour AOS-10 et le hardware Wi-Fi 7.
Puis-je réutiliser mes licences AirWave pour Aruba Central ?+
Non. Central nécessite ses propres licences d'abonnement (Foundation ou Advanced). Vos licences AirWave existantes ne sont pas transférables, bien que HPE propose souvent des crédits de migration ou des programmes 'Bridge' lors des renouvellements de hardware.
Quel est l'impact d'AOS-10 sur la migration ?+
AOS-10 est le système d'exploitation cloud-native pour les APs/Gateways Aruba. Il est géré exclusivement par Central, éliminant le besoin de Virtual Controllers locaux et permettant de véritables capacités de microbranch.
Mes plans d'étage VisualRF migreront-ils automatiquement ?+
Les cartes VisualRF ne migrent pas directement. Vous devez exporter les plans d'étage d'AirWave et les réimporter dans la section 'Floorplans' de Central, ce qui nécessite généralement une recalibration de l'échelle et du placement des APs.
Comment gérer la parité de configuration pour de grandes stacks de switches ?+
Central fournit une fonctionnalité 'Config Audit' qui identifie la différence entre la configuration cloud souhaitée et l'état de l'appareil local. Vous pouvez consulter le log 'Push' pour voir exactement quelles commandes CLI n'ont pas été exécutées.
Dois-je utiliser les UI Groups ou les Template Groups dans Central ?+
Utilisez les UI Groups. Les Template Groups sont sujets aux erreurs de syntaxe qui peuvent provoquer des pannes généralisées. Les UI Groups offrent une méthode plus sûre et vérifiée pour pousser la configuration à des hardware divers.
Qu'advient-il de mes APs legacy (AP-305/315) ?+
Les APs existants comme les séries 300 et 500 peuvent rejoindre Central mais nécessitent un flash de firmware vers une version prise en charge par Central (AOS-8.10 ou AOS-10). Les nouvelles séries AP-600/700 devraient passer directement à AOS-10.