Dans cet article nous allons aborder une demande qui revient souvent pour beaucoup d’organisations et d’institutions : comment mettre à disposition le Wi-Fi uniquement pendant certains jours et certaines heures ?
Cette requête pourrait naître d’un objectif d’économies énergétiques, d’une politique de sécurité, ou encore d’une réglementation pour certains environnements. Pour partir de ce dernier besoin et d’un cas très concret, nous allons prendre l’exemple de la loi Abeille.
Comme son intitulé l’indique, la loi n° 2015-136 promulguée le 9 février 2015 et dite “Abeille”, du nom de la députée Laurence Abeille en étant à l’origine, a introduit une approche de sobriété, information et sensibilisation concernant l’exposition du public aux champs électromagnétiques. Plus particulièrement pour les enfants et dans le secteur de l’éducation, cette législation encadre certaines règles pour le déploiement des réseaux sans fil.
Qu’est-ce que ça veut donc dire pour nous qui faisons du Wi-Fi ?
Dans l’article 7 de cette loi, nous retrouvons les réglementations suivantes :
- Dans les établissements type crèches, haute-garderies, écoles maternelles, etc., l’installation des points d’accès Wi-Fi est interdite dans les espaces dédiés à l’accueil, au repos et aux activités des enfants de moins de trois ans.
- Dans les classes des écoles primaires, les accès sans fil doivent être désactivés lorsqu’ils ne sont pas utilisés pour les activités numériques pédagogiques.
- Dans les écoles primaires, toute nouvelle installation Wi-Fi doit faire l’objet d’une information préalable du conseil d’école.
Nous partageons ici une compréhension personnelle et non officielle du texte cité, abordée sous l’angle du Wi-Fi et dans un but purement informatif. Ce n’est donc pas un avis juridique : seuls les textes officiels font foi. Avant toute mise en conformité, le mieux reste d’en discuter avec un conseil juridique qualifié, qui saura vous accompagner sur votre contexte précis.
Si le respect des points 1 et 3 dépend principalement de la planification et l’installation des points d’accès, ainsi que d’une communication formelle auprès du conseil d’école, le 2ème point soulève des questions sur les options à utiliser pour configurer cette désactivation du Wi-Fi ponctuelle, ou peut-être même programmée.
Il faudrait d’abord clarifier la notion de “accès sans fil”, faisant l’objet de cette désactivation.
Est-ce la mise hors ligne complète des points d’accès de l’architecture Wi-Fi ?
Ou alors juste la désactivation des SSIDs ?
Ou encore l’extinction des radios des points d’accès ?
La mise hors ligne complète des APs représente la mesure la plus drastique, que nous déconseillons systématiquement, surtout pour des courtes périodes, pour plusieurs raisons. L’une d’entre elles étant qu’au moment de la remise en ligne des APs on risque d’introduire une charge additionnelle sur le reste du réseau filaire derrière, le temps que les APs obtiennent tous une adresse IP, retrouvent leur système de contrôle (qu’il soit on-premise ou cloud), se resynchronisent avec ce système, revérifient et éventuellement corrigent la planification automatique des radios, etc. Éteindre complètement les APs pour désactiver les accès sans fil serait un peu comme utiliser de la dynamite pour ouvrir une cacahuète : ça marche, mais ça entraîne des effets secondaires, qu’on pourrait éviter avec des techniques plus ajustées à la dimension du besoin.
Pour la petite digression, un autre cas où on évoque parfois cet extrême est le gain énergétique. Mettre hors ligne les APs est la façon la plus efficace de faire des économies énergétiques sur les bornes Wi-Fi. En revanche, pour les mêmes raisons qu’on vient de lister dans le paragraphe précédent, on peut introduire beaucoup d’autres problèmes collatéraux pour le bon fonctionnement du réseau en général. L’impact sur le business (indisponibilité du Wi-Fi pour les employés, arrêt d’une chaîne de production, déconnexion des patients ou des visiteurs, etc.) justifie rarement ce niveau de gain énergétique, alors que les APs Cisco optimisent déjà largement leur consommation réelle par rapport au budget PoE alloué par défaut par les switches. Peu d’organisations méritent de prendre des risques aussi élevés que ceux introduits par la mise hors ligne et le rallumage des APs tous les jours, ou en tout cas de manière très fréquente. Si un business très peu critique le permet, ou si l’extinction des APs doit survenir rarement et pour des périodes relativement longues, l’option technique en tout cas existe, pour la plupart en jouant typiquement sur le PoE des switches.
En revenant sur l’exemple de la loi Abeille, si on devait interpréter les “accès sans fil” par la notion des SSIDs (sans lesquels il n’y a pas d’accès sans fil), les architectures Cisco fournissent plusieurs options pour leur désactivation. Si elle doit être faite à la demande (par exemple, un enseignant cliquant sur un bouton physique/virtuel mis à disposition par l’école), des APIs existent à tout niveau pour piloter le réseau : en mode Catalyst, à la fois pour les contrôleurs 9800 et Catalyst Center, ou en mode Meraki aussi. La solution Cisco Spaces supporte par exemple l’intégration de balises tierces (Kontakt.io, Securitas Healthcare, Moko Smart, etc.), qui peuvent embarquer des boutons d’action et communiquent en BLE, en gardant ainsi toujours une connexion même si les SSIDs ou les radios Wi-Fi sont coupés. Quand le bouton d’action d’une balise dans une classe est déclenché, les radios BLE des APs Cisco récupèrent ce type de message et le transmettent à Cisco Spaces. Dans ce dernier un peut ensuite configurer un évènement pour déclencher une notification API vers un système externe, dès que cet appui sur le bouton d’action est détecté. Ce système externe pourra ensuite agir par APIs sur la configuration de l’infrastructure wireless.
D’un autre côté, pour une désactivation automatique et programmée, par exemple en dehors des horaires d’enseignement, dans les déploiements en mode Catalyst et au niveau du contrôleur 9800, nous pouvons créer un Calendar Profile définissant les plages horaires pendant lesquelles un SSID doit rester actif. Ce Calendar Profile s’applique ensuite sous le Policy Profile lié au WLAN Profile du SSID en question. La désactivation d’un Policy Profile entraîne automatiquement la non-diffusion du SSID du WLAN Profile, auquel il est lié. Un Calendar Profile peut être créé en interface graphique ou en ligne de commande aussi. Par exemple, pour un Calendar Profile qui garderait un SSID activé toutes les semaines du lundi au vendredi, de 8h à 17h :
wireless profile calender-profile name CALENDAR_PRFL_MON-FRI_8-17 day Monday day Tuesday day Wednesday day Thursday day Friday recurrance weekly start 08:00:00 end 17:00:00
Pour configurer ensuite ce Calendar Profile sous le Policy Profile, nous devons passer par la ligne de commande :
wireless profile policy POLICY_PRFL_STUDENTS shutdown calender-profile name CALENDAR_PRFL_MON-FRI_8-17 action wlan_enable no shutdown
Toujours pour les passionnés de la ligne de commande, nous pourrions également obtenir le même résultat en passant par les commandes Embedded Event Manager.
Par exemple, pour désactiver un WLAN Profile et son SSID du lundi au vendredi, à 17h :
event manager applet EEM_WLAN_SHUT_MON-FRI_17 event timer cron name CRON_MON-FRI_17 cron-entry "0 17 * * 1-5" maxrun 600 action 001 cli command "enable" action 002 cli command "conf t" action 003 cli command "wlan WLAN_PRFL_STUDENTS" action 004 cli command "shutdown"
Ensuite, pour le réactiver du lundi au vendredi, à 8h :
event manager applet EEM_WLAN_NO_SHUT_MON-FRI_8 event timer cron name CRON_MON-FRI_8 cron-entry "0 8 * * 1-5" maxrun 600 action 001 cli command "enable" action 002 cli command "conf t" action 003 cli command "wlan WLAN_PRFL_STUDENTS" action 004 cli command "no shutdown"
Plus de détails sur ces premières options du contrôleur 9800 sont disponibles également dans le document WLAN SSID Availability Configuration Guide.
De manière équivalente, avec Catalyst Center nous avons une option dédiée à la programmation des SSIDs, en définissant d’abord les plages horaires souhaitées (Design > Network Settings > Wireless > SSIDs > SSID Scheduler) :
Puis en appliquant cette programmation au Network Profile de type Wireless souhaité, sous les réglages du SSID (Design > Network Profiles > PROFILE_NAME > Edit > SSIDs) :
Les déploiements en mode Meraki disposent d’une option équivalente aussi, appelée SSID Availability.
Nous pouvons l’appliquer soit à tous les APs d’un Network, soit à certains seulement, qui dans ce cas doivent être étiquetés avec un Tag, à configurer au préalable (Wireless > Monitor > Access points) :
Une fois les APs étiquetés, nous pouvons programmer la disponibilité de nos SSIDs à ces APs de manière spécifique (Wireless > Configure > SSID Availability) :
D’un autre côté, la désactivation des radios, tout en gardant les APs connectés et opérationnels, pourrait être une option encore plus proche au sens de la demande de désactivation des accès sans fils de la loi Abeille, justement dans un objectif de sobriété d’exposition aux champs électromagnétiques.
De façon très similaire à la programmation d’un SSID, sur un contrôleur Catalyst 9800 nous pouvons réutiliser la notion de Calendar Profile, cette fois-ci à appliquer à un Power Profile pour la désactivation des radios. Nous commençons donc par la même configuration d’un Calendar Profile, que nous pouvons retrouver également par interface graphique (Configuration > Tags & Profiles > Calendar). Cette fois-ci, nous souhaitons en revanche paramétrer les périodes, pendant lesquelles les radios doivent rester désactivées : le Calendar Profile est donc configuré pour démarrer à 17h et s’arrêter à 8h, toujours du lundi au vendredi.
Si on devait s’arrêter ici, le vendredi à 17h les radios de nos APs se désactiveraient, mais en se réactivant automatiquement le samedi à 8h. Pour les garder éteintes pendant le weekend aussi, il faudrait donc créer un autre Calendar Profile, pour samedi et dimanche, toujours à affecter au même AP Join Profile et avec le même Power Profile ci-dessous. Nous allons ensuite configurer un Power Profile définissant les actions à programmer, comme l’extinction de toutes les interfaces radio (Configuration > Tags & Profiles > Power Profile) :
Il ne reste plus qu’à affecter ces deux profils dans un AP Join Profile (Configuration > Tags & Profiles > AP Join > PROFILE_NAME > AP > Power Management), qui lui il sera distribué aux APs, si pas déjà fait, à travers la notion de Site Tag :
Note : si d’un côté un Power Profile désactivant toutes les radios peut répondre à un besoin de réduction des émissions radio pour certains environnements ou institutions, d’un autre côté cela ne représente pas toujours une option très recommandée dans un objectif d’économies énergétiques. Même si moins drastique que mettre hors ligne les APs, éteindre les radios signifie couper complétement l’accès Wi-Fi pour tout le monde : pour des équipes de maintenance, des interventions d’urgence, des ouvertures non planifiées, etc. Encore une fois, pour des métiers peu critiques le permettant, cela pourrait rester viable ; mais pour la plupart des organisations où le Wi-Fi est fondamental pour le business, dans un souci d’économies énergétiques, nous conseillons plutôt la réduction du nombre d’antennes utilisées par les APs. Cette fonction offre la possibilité de toujours garder les radios actives, juste avec une seule antenne en émission/réception par exemple, pendant les heures creuses, et la possibilité pour ces mêmes radios de remonter aussi à pleine capacité si un certain nombre de terminaux commence à avoir besoin de se connecter. Tout cela se configure toujours au niveau d’un Power Profile, en paramétrant toutes les radios avec le mode de Spatial Streams 1×1, voire en forçant également l’uplink Ethernet à 1 Gbps (pour encore plus d’économies) :
En revenant à nouveau au cas de figure de la loi Abeille et toujours pour les passionnés de la ligne de commande, on peut implémenter la désactivation des radios avec les fonctions de scripting Embedded Event Manager (EEM). Dans les propositions suivantes il faudrait bien évidemment remplacer <SITE_TAG_NAME> avec le(s) nom(s) du/des Site Tag(s) souhaité(s). Pas toutes les radios listées dans les actions de désactivation/réactivation sont disponibles dans tous les modèles d’APs non plus : certaines commandes échoueront si elles restent incluses (elles n’affecteront pas la validité et les actions de ces scripts, mais pourraient générer des logs indésirés). Par exemple, pour désactiver toutes les radios de tous les APs dans le Site Tag <SITE_TAG_NAME>, du lundi au vendredi à 17h :
event manager applet EEM_RADIOS_SHUT_MON-FRI_17 event timer cron name CRON_MON-FRI_17 cron-entry "0 17 * * 1-5" maxrun 600 action 001 cli command "enable" action 002 cli command "terminal length 0" action 003 cli command "show ap tag summary | i <SITE_TAG_NAME>" action 004 foreach line "$_cli_result" "\n" action 005 regexp "^([^ ]+).*\r$" "$line" _match _AP_NAME action 006 if $_regexp_result eq "1" action 007 cli command "ap name $_AP_NAME dot11 24ghz shutdown" action 008 cli command "ap name $_AP_NAME dot11 24ghz slot 0 shutdown" action 009 cli command "ap name $_AP_NAME dot11 5ghz shutdown" action 010 cli command "ap name $_AP_NAME dot11 5ghz slot 1 shutdown" action 011 cli command "ap name $_AP_NAME dot11 5ghz slot 2 shutdown" action 012 cli command "ap name $_AP_NAME dot11 6ghz shutdown" action 013 cli command "ap name $_AP_NAME dot11 6ghz slot 2 shutdown" action 014 cli command "ap name $_AP_NAME dot11 6ghz slot 3 shutdown" action 015 cli command "ap name $_AP_NAME dot11 dual-band shutdown" action 016 cli command "ap name $_AP_NAME dot11 dual-band slot 0 shutdown" action 017 cli command "ap name $_AP_NAME dot11 dual-band slot 1 shutdown" action 018 cli command "ap name $_AP_NAME dot11 dual-band slot 2 shutdown" action 019 end action 020 end
Ensuite, pour (ré)activer toutes ces mêmes radios, du lundi au vendredi à 8h :
event manager applet EEM_RADIOS_NO_SHUT_MON-FRI_8 event timer cron name CRON_MON-FRI_17 cron-entry "0 8 * * 1-5" maxrun 600 action 001 cli command "enable" action 002 cli command "terminal length 0" action 003 cli command "show ap tag summary | i <SITE_TAG_NAME>" action 004 foreach line "$_cli_result" "\n" action 005 regexp "^([^ ]+).*\r$" "$line" _match _AP_NAME action 006 if $_regexp_result eq "1" action 007 cli command "ap name $_AP_NAME no dot11 24ghz shutdown" action 008 cli command "ap name $_AP_NAME no dot11 24ghz slot 0 shutdown" action 009 cli command "ap name $_AP_NAME no dot11 5ghz shutdown" action 010 cli command "ap name $_AP_NAME no dot11 5ghz slot 1 shutdown" action 011 cli command "ap name $_AP_NAME no dot11 5ghz slot 2 shutdown" action 012 cli command "ap name $_AP_NAME no dot11 6ghz shutdown" action 013 cli command "ap name $_AP_NAME no dot11 6ghz slot 2 shutdown" action 014 cli command "ap name $_AP_NAME no dot11 6ghz slot 3 shutdown" action 015 cli command "ap name $_AP_NAME no dot11 dual-band shutdown" action 016 cli command "ap name $_AP_NAME no dot11 dual-band slot 0 shutdown" action 017 cli command "ap name $_AP_NAME no dot11 dual-band slot 1 shutdown" action 018 cli command "ap name $_AP_NAME no dot11 dual-band slot 2 shutdown" action 019 end action 020 end
Catalyst Center permet des opérations similaire grâce à la notion de “Workflows”. Un workflow est un modèle de configuration pour pousser plusieurs réglages à plusieurs équipements en parallèle, notamment pour des APs et leurs radios ; un workflow peut également être programmé avec une certaine périodicité. Dans le mode opérationnel de Catalyst Center, afin d’obtenir une fréquence comme celle de tous les jours fériés de chaque semaine, il faut configurer un workflow pour chaque jour férié (du lundi au vendredi) et le programmer pour tourner toutes les semaines. Comme dans notre exemple chaque jour férié aura aussi besoin de deux workflows, un pour rallumer les radios à 8h et un pour les éteindre à 17h, tout cela donne un total de dix workflows (un pour le lundi à 8h, un pour le lundi à 17h, un pour le mardi à 8h, un pour le mardi à 17h, etc.). Ci-dessous nous allons détailler les étapes pour un seul workflow, les restants étant tout simplement des copies, avec juste une modification des jours et des heures.
Pour commencer, sous le menu Workflows dans l’interface de Catalyst Center, nous pouvons sélectionner le workflow Configure Access Points et le configurer avec une programmation (Schedule) :
Après une ultérieure page nous permettant de sélectionner les APs auxquels appliquer le workflow, nous pouvons ensuite définir les actions de désactivation des radios :
Une fois les réglages confirmés, nous pouvons programmer le workflow, dans l’exemple pour tourner à partir du prochain lundi (le 7 septembre 2026 au moment de l’écriture de cet article) à 17h et en le répétant toutes les semaines :
Même si le Dashboard Meraki n’expose pas une option par interface graphique pour programmer la désactivation des radios, nous pouvons répondre à ce besoin en jouant par exemple en APIs sur les réglages des RF Profiles affectés aux APs souhaités :
https://developer.cisco.com/meraki/api-v1/update-network-wireless-rf-profile
Beaucoup d’options existent, comme on voit, pour déclencher et programmer la désactivation et la réactivation du Wi-Fi, à plusieurs niveaux. N’hésitez pas à vous rapprocher de vos équipes avant-ventes Cisco, pour un accompagnement encore plus personnalisé par rapport à vos métiers.
Et une très bonne rentrée à tout le monde !
Authors