Focus Expert | DevOps à la rescousse du Wi-Fi
Dans cet article nous allons explorer comment Cisco EEM (Embedded Event Manager), intégré dans les nouveaux contrôleurs wireless Catalyst 9800, permet d’automatiser des scripts pour l’activation d’un réseau Wi-Fi de backup en PSK (Pre-Shared Key) si le serveur RADIUS de notre SSID 802.1X principal n’est plus joignable.
Cette fonctionnalité est d’un côté similaire à l’option du Critical VLAN (appelée aussi « inaccessible authentication bypass ») pour les réseaux 802.1X filaires, mais maintenant appliquée sur le Wi-Fi. Même si une telle fonction n’existe pas nativement en Wi-Fi, EEM nous donne la possibilité d’en implémenter une version personnalisée.
EEM est une fonctionnalité logicielle supportée sur les systèmes d’exploitation Cisco IOS, IOS-XR, NX-OS et IOS-XE, qui permet de déclencher des actions suite à la reconnaissance d’événements spécifiques. Un événement peut être le résultat d’un IP SLA, un message syslog en console, un debug, etc. et les actions peuvent être des séquences de lignes de commande.
Grâce à EEM, nous pouvons par exemple détecter si une interface vient d’être désactivée, suite à une erreur de configuration par exemple, en surveillant des logs en console comme « GigabitEthernet1/0/45, changed state to administratively down ». Avec le même script nous pouvons ensuite lancer une série de commandes pour réactiver automatiquement cette interface : « enable », « conf t », « interface gi 1/0/45 » et « no shut ». Ce sont les mêmes commandes que nous utiliserions manuellement, mais maintenant automatisées par notre script EEM. Un tel script ressemble à l’exemple suivant en IOS-XE :
event manager applet EEM_INTERFACE_NO_SHUT event syslog pattern "Interface GigabitEthernet1/0/45, changed state to administratively down" action 1.0 cli command "enable" action 1.1 cli command "conf t" action 2.0 cli command "interface gi 1/0/45" action 3.0 cli command "no shut" action 4.0 cli command "end"
Vous pouvez trouver des ressources supplémentaires et d’autres exemples de configuration pour EEM dans les switches dans l’article suivant :
https://community.cisco.com/t5/network-architecture-documents/cisco-eem-basic-overview-and-sample-configurations/ta-p/3148479
Les contrôleurs wireless Catalyst 9800 annoncés récemment tournent sous IOS-XE et supportent EEM.
Dans beaucoup de déploiements Wi-Fi nous avons besoin d’une connectivité 24H/24, comme par exemple dans des sites où les employés se connectent principalement en wireless et où les ports Ethernet pourraient ne pas être assez nombreux pour connecter tous les terminaux. Ces réseaux WLAN d’entreprise sont souvent configurés avec une authentification 802.1X, en s’appuyant sur des serveurs RADIUS. Les réseaux Wi-Fi configurés en 802.1X ne permettent pas de se connecter avec d’autres techniques alternatives, comme en PSK ou même en mode ouvert. Si le service RADIUS n’est plus disponible, les clients déjà connectés peuvent rester connectés jusqu’à la prochaine authentification 802.1X (déclenchée par un timeout, une nouvelle association, une déconnexion, etc.), mais cette prochaine authentification est destinée à échouer. Des nouveaux clients ne pourront pas s’authentifier non plus tant que le service RADIUS restera indisponible.
Pour le 802.1X filaire, les switches Cisco supportent des services de backup, tels que l’affectation automatique des terminaux à un VLAN critique si les serveurs RADIUS ne sont plus disponibles. En revanche, en 802.1X sur le Wi-Fi, les terminaux doivent toujours passer par le 802.1X pour pouvoir se connecter. Cela signifie que, si le service RADIUS n’est plus disponible pendant assez longtemps, on pourrait faire face à une panne de réseau complète.
Grâce à EEM dans les contrôleurs wireless C9800 nous pouvons détecter si les serveurs RADIUS ne sont plus disponibles et activer automatiquement un SSID de backup pré-configuré et sécurisé en PSK, pour continuer à assurer la connexion au réseau. Notre SSID de backup peut être pré-configuré dans le C9800, par simplicité, au lieu d’exécuter à chaque fois toutes les commandes pour le créer/supprimer via le script EEM. Ce SSID devrait également être en PSK, précisément pour rester en backup en cas d’indisponibilité des serveurs RADIUS. Un autre détail à noter est qu’il ne faudrait pas configurer un tel SSID de backup / critique avec le même nom que notre SSID principal en 802.1X. Si on gardait le même nom, les terminaux pourraient ne pas choisir le bon SSID, en 802.1X ou en PSK, parmi ceux dans leur liste pré-configurée. Nous pourrions plutôt pré-configurer les terminaux avec deux SSID distincts, un en 802.1X et un en PSK, pour qu’ils soient toujours prêts à se connecter aux deux. Dans notre contrôleur wireless C9800, un seul de ces deux SSID sera actif à tout moment, afin que les clients ne risquent pas de basculer entre ces différents réseaux Wi-Fi, par exemple. Nous avons explicitement fait référence à une « pré-configuration » des clients avec le SSID en 802.1X et celui en PSK : des options de distribution des configurations sont en effet supportées pour le supplicant natif Windows via des Group Policy Objects (GPO) dans Active Directory, ou même en distribuant des profils pour le supplicant Network Access Module (NAM) de Cisco AnyConnect.
En résumant, les principaux ingrédients de notre recette EEM sont les suivants :
- Notre SSID principal en 802.1X, que nous appellerons « Enteprise_SSID » dans les prochains exemples, déjà configuré et activé dans le C9800.
- Notre SSID de backup en PSK, que nous appellerons « Backup_SSID » dans les prochains exemples, déjà configuré et désactivé dans le C9800.
- Les terminaux pré-configurés pour se connecter automatiquement au Enterprise_SSID et au Backup_SSID.
- Des options pour monitorer les serveurs RADIUS et détecter quand ils ne sont plus disponibles.
La configuration du Enterprise_SSID en ligne de commande ressemble en partie à la suivante (où « 1 » correspond à son index, dans cet exemple spécifique) :
wlan Enterprise_SSID 1 Enterprise_SSID … no shutdown
Le Backup_SSID n’aura pas la commande « no shutdown » explicitement affichée en CLI, car son état de shutdown est celui par défaut.
Voici un exemple de la séquence de commandes que nous devrions taper manuellement si nous voulions activer le Backup_SSID et désactiver le Enterprise_SSID :
My-C9800> My-C9800>enable My-C9800#conf t My-C9800(config)#wlan Backup_SSID My-C9800(config-wlan)#no shut My-C9800(config-wlan)#wlan Enterprise_SSID My-C9800(config-wlan)#shut My-C9800(config-wlan)#end My-C9800#
IOS-XE supporte des options spécifiques pour détecter si un serveur RADIUS n’est plus disponible. Dans cet article nous ne détaillerons pas les fonctions de chaque commande, mais vous pouvez trouver leurs spécifications complètes dans le guide suivant (plus précisément dans la section « RADIUS Server Failure Handling ») :
https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/identity-based-networking-services/whitepaper_C11-731907.html
Voici un exemple de configuration d’une série de tests pour un serveur RADIUS (les timeouts, les ressais et d’autres paramètres peuvent être modifiés en fonction de besoins plus précis) :
! Needed to enable RADIUS server testing capabilities aaa new-model ! Based on the detection "speed" and needs, you may want to modify these values radius-server dead-criteria time 20 tries 3 ! Deadtime is also needed to keep a RADIUS server in the "dead" state for some time and not to risk redeclaring it back "alive" too early radius-server deadtime 1 ! Replace <YOUR_RADIUS_SERVER> with the name of your RADIUS server radius server <YOUR_RADIUS_SERVER> automate-tester username RADIUS_AUTOMATE_TESTER idle-time 1
Il faut noter que ces options de test d’un serveur RADIUS, avec un utilisateur appelé « RADIUS_AUTOMATE_TESTER » dans l’exemple, peuvent par défaut causer des échecs d’authentification côté serveur RADIUS, en fonction de sa configuration. Ce comportement est prévu, car l’objectif principal de cet utilisateur de test n’est pas de s’authentifier, mais simplement d’obtenir une réponse du serveur RADIUS, afin d’en confirmer sa disponibilité.
Si ces tests échouent et le serveur RADIUS ne répond pas, en console IOS-XE nous devrions commencer à voir des logs similaires aux suivants :
%RADIUS-4-RADIUS_DEAD: RADIUS server 10.150.20.220:1812,1813 is not responding
Si un serveur RADIUS redevient disponible et est marqué à nouveau comme actif, le log correspondant en console ressemble au suivant :
%RADIUS-4-RADIUS_ALIVE: RADIUS server 10.150.20.220:1812,1813 is being marked alive
Avec tous ces réglages en place, nous sommes maintenant prêts à configurer notre script EEM pour obtenir la procédure suivante :
1. Le script surveille les logs en console contenant le message « %RADIUS-4-RADIUS_DEAD ».
2. Si ce type de message est détecté, le Backup_SSID est activé.
3. Le script se met en pause pendant 30 secondes pour permettre aux clients déjà connectés au Enterprise_SSID de rester connectés, tout en leur laissant le temps de commencer à détecter le Backup_SSID. On peut bien évidemment modifier ce temps de pause comme on le souhaite, voire ne pas le configurer du tout.
4. Le Enterprise_SSID est désactivé.
Ce script EEM ressemble au suivant :
event manager applet EEM_ENABLE_BACKUP_SSID event syslog pattern "%RADIUS-4-RADIUS_DEAD" maxrun 60 action 1.0 cli command "enable" action 1.1 cli command "conf t" action 2.0 cli command "wlan Backup_SSID" action 3.0 cli command "no shut" action 4.0 wait 30 action 5.0 cli command "wlan Enterprise_SSID" action 6.0 cli command "shut" action 7.0 cli command "end"
Comme ultérieure étape, on recommande également de configurer un deuxième script EEM, qui réactive le Enterprise_SSID lorsque le serveur RADIUS redevient disponible et désactive le Backup_SSID.
Ce script ressemble au suivant :
event manager applet EEM_ENABLE_ENTERPRISE_SSID event syslog pattern "%RADIUS-4-RADIUS_ALIVE" maxrun 60 action 1.0 cli command "enable" action 1.1 cli command "conf t" action 2.0 cli command "wlan Enterprise_SSID" action 3.0 cli command "no shut" action 4.0 wait 30 action 5.0 cli command "wlan Backup_SSID" action 6.0 cli command "shut" action 7.0 cli command "end"
Tous ces exemples peuvent bien évidemment être personnalisés davantage pour répondre à des besoins encore plus spécifiques.
Par exemple, si on ne se base que sur le log « %RADIUS-4-RADIUS_DEAD » et si le C9800 est configuré avec plusieurs serveurs RADIUS, dès qu’un seul serveur échoue le Backup_SSID peut s’activer même si d’autres serveurs RADIUS restent disponibles. Dans ce cas nous pourrions plutôt essayer de détecter le log « %RADIUS-4-RADIUS_DEAD: RADIUS server 10.150.20.220:1812,1813 is not responding », où 10.150.20.220 est l’IP du dernier serveur RADIUS utilisé par le C9800 dans une séquence de plusieurs (ce qui signifierait que tous les autres auraient déjà échoué avant). D’un autre côté, si les serveurs RADIUS se trouvent derrière un load balancer, il suffit de configurer l’adresse IP du load balancer en tant que le seul serveur RADIUS pour le C9800.
Nous espérons que cet exemple de configuration pourra vous fournir des idées sur le support de ce SSID de backup, ainsi que sur les avantages des fonctionnalités EEM des contrôleurs wireless C9800 pour encore plus de possibilités. N’hésitez pas à poster vos commentaires / questions et à bientôt avec le prochain article !
P.S. Si besoin vous pouvez retrouver ce même article en anglais à la page suivante :
https://community.cisco.com/t5/wireless-mobility-documents/automated-backup-ssid-with-eem-on-catalyst-9800-wireless/ta-p/3743838
