Tech Notes – Créer un proxy SNMP avec EnergyWise

Comme mentionné dans un article précédent, la version 2.8 d’EnergyWise intègre une nouvelle fonctionnalité : un proxy SNMP. Ainsi, il devient possible de piloter de manière transparente des systèmes SNMP (tel qu’une imprimante) comme s’ils étaient des terminaux supportant nativement EnergyWise. Cela mérite qu’on s’y intéresse !

Commençons par un schéma plutôt qu’une longue explication :

Dans la pratique, le proxy SNMP est configuré sur le port du switch sur lequel est connecté l’équipement SNMP. Un fichier xml présent sur le switch va permettre la traduction des requêtes EnergyWise en SNMP, et inversement. Une fois configuré, votre équipement SNMP sera pilotable via EnergyWise de manière complètement transparente, et pourra, par exemple, apparaître dans une plateforme de gestion EnergyWise. Bien évidemment, il sera nécessaire d’écrire un fichier de traduction pour chaque équipement SNMP différent que l’on souhaitera piloter. Pour cela, il vous faudra trouver la MIB de votre équipement, et en extraire les OIDs qui vous intéressent.

Configuration

La configuration se fait en deux étapes : la configuration du switch, puis la construction du fichier xml de traduction. Les exemples ci-dessous ont été effectués avec un commutateur Catalyst 2960S, l’équipement piloté via SNMP étant un routeur Cisco 1800S – à défaut d’avoir une imprimante sous la main!

Configuration du switch (CLI) :

1)      Uploader le fichier xml (voir plus bas pour la création de ce fichier) sur la mémoire flash (via tftp) :

#copy tftp://IP address/XML file

2)    Activer le serveur SNMP :

#configure terminal
#snmp-server manager

3)      Créer un alias pour le fichier xml :

#energywise proxy mapping map_name xml_file

4)       Configurer le proxy sur les interfaces :

#interface interface
#energywise proxy mapping map_name protocol protocol host host discovery-interval interval port port
#energywise proxy protocol protocol version version community-string community rights

 Ce qui donne dans mon cas :

#copy tftp://10.1.1.1/maprouter.xml flash:
#configure terminal
#snmp-server manager
#energywise proxy mapping map maprouter.xml
#interface G1/0/2
#energywise proxy mapping map protocol snmp host 10.0.0.101 discovery-interval 180
#energywise proxy protocol snmp version v2c community-string private RW

 C’est tout ! Il ne reste plus qu’à créer le fameux fichier xml.

Création du fichier xml de traduction

Je vais ici expliquer la structure du fichier xml, et essayer de vous de présenter une partie des différentes possibilités. Pour obtenir l’intégralité des fonctionnalités, reportez-vous au fichier pdf de configuration d’EnergyWise 2.8 fourni par Cisco, dont le lien se trouve à la fin de cet article.

Prérequis : s’armer de la MIB de l’équipement à piloter.

Structure globale :

<?xml version="1.0" ?>
<CiscoEnergyWise version="2.8">
                <interface protocol="snmp" version="v2c">
                               //On place ici une série de méthodes
                </interface>
</CiscoEnergyWise>

Les différentes méthodes :

Deux types d’actions sont possibles : les « Get » et les « Set ». « Get » pour récupérer une valeur, « Set » pour en modifier une.

La méthode Get :

<method name="fn_get_deviceType" action="constant">
                <constant type="string" value="Router" />
</method>
<method name="fn_get_name" action="oid">
                <oid name="cewEntName" action="get" value="1.3.6.1.4.1.9.2.1.3.0" />
</method>

On remarque que le nom de la méthode correspond à la fonction SNMP et qu’il est possible de renvoyer une valeur constante, ou de récupérer la valeur grâce à l’OID de la valeur qui nous intéresse.

La méthode Set :

<method name="fn_set_name" action="oid">
                <oid name="cewEntName" action="set" datatype="string" value="1.3.6.1.4.1.9.2.1.3.0" />
</method>
<method name="fn_set_level" action="oid">
                <oid name="cewEntEnergyLevel" action="set" value="1.3.6.1.1.11.2.3.0">
                               <mapping invalue="0" outvalue="1" />
                               <mapping invalue="1" outvalue="2" />
                               <mapping invalue="2" outvalue="3" />
                               <mapping invalue="3" outvalue="4" />
                               <mapping invalue="4" outvalue="5" />
                               <mapping invalue="5" outvalue="6" />
                               <mapping invalue="6" outvalue="7" />
                               <mapping invalue="7" outvalue="8" />
                               <mapping invalue="8" outvalue="9" />
                               <mapping invalue="9" outvalue="10" />
                               <mapping invalue="10" outvalue="11" />
                </oid>
</method>

Les méthodes Set s’écrivent dans le même esprit que les Get. On remarquera que la deuxième méthode comprend une nuance, puisque l’on traduit ici les levels EnergyWise en levels SNMP, grâce à la balise <mapping>.  Les applications de cette balise sont nombreuses, puisqu’elle va nous permettre de créer un lien entre des valeurs EnergyWise et des valeurs SNMP si ces dernières ne sont pas égales. Par exemple, dans le cas précédent, la valeur « level » EnergyWise 0 sera convertie en valeur SNMP 1. Si l’on souhaitait écrire la fonction Get correspondante (fn_get_level), il faudrait inverser les valeurs des « invalue » et des « outvalue », puisque c’est la traduction inverse qui s’effectuerait : un level 8 en SNMP vaudra un level 7 EnergyWise.

Conclusion

Si tout c’est bien passé, le système SNMP devrait s’afficher comme un endpoint Energwise classique grâce à la commande #show energywise children :

Il est aussi possible d’afficher les proxys SNMP configurés sur un commutateur grâce à la commande #show energywise proxies.

Enfin, vous pouvez effectuer des requêtes EnergyWise de manière transparente :

La configuration d’un proxy SNMP EnergyWise n’est pas très complexe, la difficulté résidant dans la création du fichier xml de traduction pour lequel il est nécessaire d’extraire les OIDs qui nous intéressent de la MIB du système SNMP. De plus, si vous possédez beaucoup d’équipements SNMP différents, il peut être fastidieux d’écrire un fichier xml pour chacun des équipements.

Pour connaître la version IOS requise pour utiliser EnergyWise 2.8 sur vos commutateurs Cisco :

http://www.cisco.com/en/US/docs/switches/lan/energywise/version2_8/ios/release/notes/ol23554.pdf

Manuel de configuration d’EnergyWise 2.8 :

http://www.cisco.com/en/US/docs/switches/lan/energywise/version2_8/ios/configuration/guide/ew_v2_8.pdf

Le monde SNMP se contrôle maintenant via EnergyWise!

Baptiste.

Tech Notes – Piloter des équipements via des « URL actions » grâce à EnergyWise

Comme vous le savez déjà, EnergyWise permet de contrôler de nombreux types d’équipements, classiquement en ligne de commande (CLI) ou en passant par une interface de gestion. Mais cela est aussi possible via des URL actions : en effet, les commutateurs Cisco possèdent, de base, une interface web qui permet de leur envoyer des commandes (de type CLI) directement par un navigateur. Ainsi, il possible de contrôler un switch dans son ensemble, et donc, par extension, d’utiliser EnergyWise avec de simples URL actions.

Dès lors, on peut imaginer toute sorte d’applications et de scénarios en interfaçant des systèmes tiers avec EnergyWise. Par exemple, un contrôle d’accès tel qu’un lecteur de badge, ou encore une application pour smartphone capables d’allumer un ordinateur, un téléphone, ou une lampe, et ce, très facilement : c’est ce que nous allons voir.

Format des requêtes

Nous ne détaillerons pas ici le fonctionnement d’EnergyWise, chose qui a déjà été faite sur ce blog, mais il faut savoir qu’il est possible de jouer sur les attributs EnergyWise des équipements pour exercer une action sur un groupe ciblé de notre réseau.

Ci-dessous, un exemple  d’utilisation des URL actions pour la partie EnergyWise :

http://<HOST>/level/15/exec/-/energywise/query/importance/100/name/<NOM>/set/level/10/CR
http://<HOST>/level/15/exec/-/energywise/query/importance/50/keyword/<MOT-CLE>/set/level/10/CR

On remarque que les espaces, traditionnellement utilisés en CLI pour délimiter les différents mots qui composent une commande, ont été remplacés par des slashes.

A titre de comparaison, les deux requêtes HTTP ci-dessus correspondent respectivement à ces commandes EnergyWise :

Switch# energywise query importance 100 name <NOM> set level 10 CR
Switch# energywise query importance 50 keyword <MOT-CLE> set level 10 CR

Remplacez <HOST> par l’adresse du commutateur et <NOM> et <MOT-CLE> par les attributs EnergyWise correspondants.

Exemples d’applications

Interface avec un contrôle d’accès

Pour des fins de démonstration, nous avons développé quelques scénarios d’interactions croisées entre du contrôle d’accès et EnergyWise et un smartphone et EnergyWise en utilisant les URL actions. Soulevons le capot et regardons le code!

Dans le cas de l’application au lecteur de badge, on peut imaginer que la passerelle (modèle CIAC-GW-K9 de Cisco par exemple) envoie une « URL action » au commutateur lors de la détection de l’évènement « badge numéro uvwxyz détecté ». Ainsi,  il est possible d’automatiser la procédure d’allumage de la lumière, d’un PC, d’un téléphone (…) lorsqu’une personne entre dans une pièce (son bureau par exemple).

Pour plus d’informations sur l’intégration du contrôle d’accès avec les url actions, visitez : http://www.cisco.com/en/US/docs/security/physical_security/access_control/cpam/1_3_0/english/user_guide/12_integrate_cpam1_3.pdf

Script Python :

###############Import des librairies#################
#!c:/Python27/python.exe -u

import httplib
import urllib
import json
import socket
import urllib2
#################Un peu de html####################
print "Content-type: text/html\n"
print "<title>Allumage de la lampe</title>\n"
print "<h1>Commande execut&eacute;e!</h1>"
##################################################
#########Envoi de la commande vers le switch###########
headers1 = {"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8","User-Agent": "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1" , "Host": "10.1.190.4","Connection": "keep-alive","Accept-Language": "en-us,en;q=0.5", "Authorization" : "Basic XXXXXXXXX=" };
conn = httplib.HTTPConnection('10.1.1.1');
conn.connect();
params1 = urllib.urlencode({'username': 'admin', 'password': 'admin'})
conn.request("GET", "/level/15/exec/-/energywise/query/importance/100/name/SP*/set/level/10/CR", params1, headers1);

response = conn.getresponse();
raw = response.read();
################################################

Script ActionScript (pour application iphone par exemple) :

#############Définition des accès#####################
URLRequestDefaults.setLoginCredentialsForHost("10.1.1.1 ", "admin", "admin");
 ##########Envoi conditionné de la commande###########
function fl_ClickToGoToWebPage2(event:MouseEvent):void
 {
 if (listobj2 != "") {
 var request = new URLRequest("http://10.1.1.1/level/15/exec/-/energywise/query/importance/100/name/" + listobj2 + "/set/level/0/CR");
 request.contentType = "text/html";
 request.method = URLRequestMethod.GET;
 var loader = new URLLoader();
 loader.load(request);
 }
}
##################################################

Script Java (pour application Android par exemple) :

public void executeHttpGet() throws Exception {
try {
HttpClient client = new DefaultHttpClient();
HttpGet request = new HttpGet();
request.setURI(new URI("http://10.1.1.1/level/15/exec/-/energywise/query/importance/100/name/SP*/set/level/10/CR"));
request.addHeader(BasicScheme.authenticate(new UsernamePasswordCredentials("admin", "password"),"UTF-8", false));
client.execute(request);
} finally {
try {
in.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}

Aspects de sécurité

Pour accéder à ces scripts, il est conseillé de mettre en place des systèmes d’authentification sur les serveurs HTTP ou HTTPS les hébergeant, en utilisant, par exemple, des htaccess ou encore des sessions php. Cela de manière à empêcher n’importe qui d’exécuter ces scripts et donc de contrôler vos équipements.

En outre, de la même façon qu’avec une session CLI, les URL actions des commutateurs Cisco sont protégées par un mot de passe concernant (dans notre cas) le « Privileged EXEC mode » (auquel on accède grâce à la partie « level/15 » de la commande) et un login afin de pouvoir faire exécuter la commande envoyée.  Notez que l’on peut tout à fait créer des utilisateurs sur le switch et leur affecter un niveau de privilège inférieur à 15, puis, autoriser l’exécution de seulement certaines commandes (telles que EnergyWise par exemple) pour le niveau de privilège souhaité.

Par mesure de prudence, il faut également savoir que la définition des identifiants et mots de passes directement dans le script est déconseillée (contrairement à ce qui a été fait dans les scripts d’exemple précédents avec le : «URLRequestDefaults.setLoginCredentialsForHost(« 10.1.1.1 « , « admin », « admin ») », où les champs d’identification sont directement renseignés ). Pour plus de sécurité, il est préférable de privilégier l’utilisation de variables et de formulaires.

Pour plus d’informations sur les différentes possibilités de configuration du mode d’accès au commutateur, consultez : http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfpass.html

Les URL actions permettent d’activer très facilement EnergyWise à partir d’une multitude de systèmes. Nous sommes dans la magie de l’interopérabilité d’IP!
A vous de jouer pour développer vos propres applications!

Bon courage,
Baptiste.

EnergyWise v2.8 est disponible

EnergyWise s’enrichit et la version 2.8 est désormais disponible sur les Catalyst 2900, 3500 et 4500. La version 2.8 offre notamment deux nouvelles fonctionnalités: le suivi des paquets Wake On LAN et le proxy SNMP.

Le support du Wake on LAN était déjà disponible et la version 2.8 amène une amélioration de configuration. Le commutateur cache en effet l’adresse MAC des PC qui sont connectés lorsqu’ils se déclarent en Wake On LAN. Quand un paquet de réveil Wake On LAN est transmis, le commutateur ne fait suivre le broadcast qu’aux PC dans son cache et ajoute dynamiquement l’adresse MAC du PC au paquet Wake On LAN. Seuls les PC à réveiller reçoivent les paquets Wake On LAN.

Le Proxy SNMP permet à des équipements non EnergyWise d’être intégré au domaine. Le commutateur stocke la MIB du système SNMP connecté au commutateur et traduit les requêtes EnergyWise en SNMP. Il est ainsi possible d’ajouter au domaine EnergyWise des imprimantes ou des serveurs qui n’auraient pas d’agent EnergyWise natif.

Vous trouverez des informations détaillées dans le guide de configuration et les notes de mise à jour.
Olivier.

Tech Notes – Activer et configurer EnergyWise avec CiscoPrime LMS

Jusqu’à présent, nous avons testé EnergyWise à travers la CLI pour mieux cerner son fonctionnement mais dans le cadre d’un déploiement à grand échelle, un outil tel que CiscoPrime LMS s’impose.

Pour ceux qui ne connaissent pas, Cisco Prime LMS (LAN Management Solution) est une plateforme qui regroupe de nombreux outils destinées à la gestion d’un LAN. Parmi ces outils on trouve un « workcenter » EnergyWise que nous allons utiliser pour auditer le réseau et configurer EnergyWise.

Une fois connecté à votre LMS, dans le Work Center EnergyWise sélectionnez « Readiness Assessment ».

Cette page permet de faire un audit EnergyWise du réseau, de visualiser sur lesquels de nos équipements EnergyWise :

  • est activé
  • n’est pas activé
  • ne peut pas être activé car il n’existe pas d’IOS correspondant
  • n’est pas activé car requiert une mise à jour de l’IOS

La liste des équipements correspondant à la partie de camembert sélectionnée apparaît en bas

Dans le cas précédent, il s’agit de la liste des équipements sur lesquels la version d’IOS est bonne mais sur lesquels EnergyWise n’est pas activé. Je peux alors les sélectionner puis cliquer sur « Enable EnergyWise ». LMS vous emmène alors vers l’outil de configuration des domaines

Et c’est fini ! Vous avez mis à jour votre réseau et activé EnergyWise! Un jeu d’enfant non ?

Nous verrons par la suite comment intégrer les équipements et définir des politiques…

Matthieu.

Tech Notes – Pourquoi mettre EnergyWise dans des commutateurs ?

Mais quel est l’intérêt d’avoir des services EnergyWise qui tournent sur les commutateurs et ne pas avoir un serveur qui interroge directement des équipements intelligents à travers un réseau quelconque ?

Il existe plusieurs réponses :

  • Quid de l’extensibilité (« scalability ») ? Si jamais les serveurs commandaient directement les équipements alors il faudrait un certain nombre de serveurs pour supporter la charge de toutes les requêtes pour récupérer les données. Tout l’intérêt d’EnergyWise réside dans le fait que les commutateurs effectuent ce travail et le premier commutateur interrogé par la plateforme d’administration va agréger les réponses et envoyer une réponse synthétique à la plateforme d’administration, soulageant d’autant le réseau. Pour les politiques peu évoluées – par exemple éteindre les équipements à 22h00 – elles peuvent également être enregistrées directement sur le commutateur. Ainsi même si certains liens tombent, ces politiques continueront à être appliquées
  • Une fois qu’un équipement PoE est éteint, comment faire pour le rallumer sans intelligence sur le commutateur ? l’équipement ne peut plus recevoir de commande puisqu’il est éteint. On pourrait imaginer laisser un faible courant pour alimenter une CPU (« Central Processor Unit ») mais cela ne sera jamais aussi efficace que lors d’une extinction. Les fonctions de cache dans le commutateur (décrites dans la note Tech Notes – Les mécanismes d’autodécouverte d’EnergyWise ) permettent de conserver la topologie et les adjacences
  • Comment se passerait la découverte des équipements au niveau 2 ou 3 ? Les paquets de type broadcasts sont souvent bloqués par les commutateurs (entre VLAN par exemple), les empêchant d’atteindre la plateforme d’administration. Faudrait-il alors les entrer manuellement ? Une tâche titanesque !
  • dès lors qu’on touche au contrôle d’équipement, le besoin de sécurité grimpe en flèche ! Or l’utilisation d’un serveur global induirait une trop grande vulnérabilité de l’ensemble. EnergyWise utilise différents (3 pour être précis) mots de passe pour les communications entre commutateurs, entre équipements terminaux et commutateurs, entre commutateurs et plateformes d’administration. Ainsi si la plateforme est corrompue, on peut empêcher son action en changeant le mot de passe correspondant au niveau du commutateur. De plus les commutateurs ont une surface d’attaque réduite par rapport à des OS tels que Windows ou Linux sur lesquels tourneraient ces potentielles plateformes. L’aspect sécurité a été abordé dans un article précédent (Tech Notes – EnergyWise & la sécurité)
  • Utiliser le réseau offre aussi la possibilité d’ajouter de l’information contextuelle, de l’autoconfiguration. Comme on sait à quel port du commutateur l’équipement est relié et où se situe ce commutateur, on peut en déduire la localisation de l’équipement. Ou alors reconnaître automatiquement un équipement et ajouter un mot-clé correspondant. Et ainsi de suite.

L’approche EnergyWise se démarque clairement des protocoles traditionnels utilisés dans la gestion technique du bâtiment comme BACNet, ModBus, LonWorks ou KNX qui n’ont pas été conçu pour IP et son formidable système de couches indépendantes entre elles, ni pour tirer avantage du réseau. Ils demandent un réseau dédié et séparé et des passerelles vers les plateformes d’administration (qui utilisent IP) et reposent sur un modèle client serveur centralisé, bien loin du modèle distribué d’EnergyWise.

Matthieu.

Tech Notes – Les mécanismes d’autodécouverte d’EnergyWise

Les équipements appartenant à un même domaine EnergyWise vont s’autodécouvrir en envoyant des paquets contenant:

  • l’adresse IP (pour savoir à qui répondre)
  • le nom du domaine de l’équipement
  • le nom
  • le rôle
  • ce qu’il peut faire (« device capability code »)

Cet article va présenter les différentes techniques qui permettent l’autodécouverte et sont visibles sur cet écran :

La découverte de niveau 2

Cisco Discovery Protocol est un protocole propriétaire Cisco de la couche 2 (liaison de données) qui permet aux équipements Cisco de se découvrir automatiquement sans connexion IP. Ces paquets de découverte ne sont pas propagés et ne concerne donc que les voisins immédiat (« One-hop »). Sur un routeur/commutateur Cisco, on peut par exemple utiliser la commande #show cdp neighbors pour voir les équipements voisins (l’équivalent normalisé LLDP n’est pas encore supporté sur EnergyWise).
Les paquets de découverte sont envoyés toutes les 75 secondes au début puis leur fréquence diminue géométriquement  jusqu’à un maximum de 15 minutes.

La découverte de niveau 3

Cette découverte concerne les équipements qui embarquent une intelligence (« l’agent ») EnergyWise. La découverte se fait par des paquets UDP en suivant la même logique, avec pour destination un broadcast 255.255.255.255 et le port configuré sur l’équipement (par défaut 43440).
Le paquet contient également un port TCP sur lequel l’agent écoute pour que le commutateur puisse initier une communication avec lui et ainsi échanger des informations.

La configuration statique

Un grand classique : lorsque certains équipements ne peuvent pas se découvrir car séparés sur le WAN. On peut alors « forcer » leur découverte en les entrant manuellement en mode configuration :
Si la découverte échoue:
(config)# energywise neighbor <ip> <portSurLequelEcouter>
Par exemple
(config)# energywise neighbor 10.4.1.12 43440

Le système de cache

Les agents EnergyWise peuvent avant de s’éteindre ou de se placer en veille demander au commutateur de garder en cache leur présence. Le commutateur répondra alors à la place de l’équipement en cache quand une requête demandera sa consommation. Il restera alors en cache jusqu’à ce que l’un des événements suivants se produit:

  • un autre agent se connecte sur le même port
  • la commande #clear energywise endpoints [all | cached] est tapée
  • Energywise est désactivé

Le système de cache permet de maintenir la topologie du domaine EnergyWise inchangée lors des périodes de veille.

Les mécanismes d’autodécouverte d’EnergyWise simplifient le déploiement du réseau et son évolution qui est prise en compte dynamiquement.

Encore un avantage d’utiliser le réseau pour gérer l’énergie!

Matthieu.

Tech Notes – EnergyWise & la sécurité

EnergyWise est doté de 3 mécanismes de sécurité dans sa version actuelle:

  1. L’intégrité des paquets est garanti via une HMAC pour chaque paquet
  2. En option, on peut activer une protection anti-rejeu auquel cas les équipements doivent être synchronisés (via ntp).  Lors de l’activation (ou modification) du domaine, il suffit d’utiliser ntp-shared-secret au lieu de shared-secret.

Un dernier mécanisme moins robuste existe: un numéro de séquence est présent dans chaque paquet. Les commutateurs du domaine conservent ce numéro de séquence pour chaque voisin et plateforme d’administration. Si un paquet survient avec un numéro inférieur, il est ignoré.

On peut imaginer qu’à l’avenir EnergyWise proposera des mécanismes de chiffrement mais ce n’est pas encore le cas.

Comme nous avions pu le voir lors de l’activation, EnergyWise utilise 3 types de mot de passe:

  • un mot de passe partagé par les commutateurs d’un même domaine. Il doit donc être identique pour tous les commutateurs
  • un entre chaque commutateur et la plateforme d’administration. Ainsi si la plateforme d’administration est corrompue, on peut l’empêcher d’agir sur le commutateur en changeant le mot de passe de celui-ci (le mot de passe « management » )
  • pareillement, un mot de passe est nécessaire entre chaque commutateur et les équipements terminaux (le mot de passe « endpoint » ) qui va servir à négocier une clé d’authentification à partir d’un nonce. Tous les paquets compris entre le commutateur et un équipement terminal (téléphone EnergyWise, portable Lenovo…) contiennent un HMAC généré grâce à cette clé. Cette clé est renouvelée pour chaque session.

Pour davantage de sécurité, on peut vouloir désactiver EnergyWise sur certains ports. J’en ai déjà évoqué la possibilité à la fin de cet article.  Mais alors on ne récupère plus leur consommation ! EnergyWise permet une configuration plus fine: on peut en effet désactiver les requêtes « set » (c’est-à-dire celles qui vont agir sur les équipements) grâce a la commande

# no energywise allow query set

Si le commutateur reçoit une requête depuis un commutateur ou une plateforme du même domaine qui vise à changer un niveau d’énergie quelconque alors la requête sera ignorée.

On peut également entrer la commande # energywise allow query save pour sauvegarder les modifications effectuées par les requêtes.

Documentation sur la commande « energywise allow »


Le « Cisco EnergyWise Design Guide« donne  également des indications à respecter (mots de passe forts).

Matthieu.


Tech Notes – Mettre en place une politique récurrente sur une interface (CLI)

Il est possible d’installer des politiques récurrentes sur les commutateurs, c’est-à-dire changer les niveaux d’énergie sur une interface selon la date (semaine,jour, mois,heure, etc). Les récurrences sont associées à une interface (dès lors, nous les configurerons en mode interface « (config-if)# » ) et non à des filtres d’importance ou de nom comme les requêtes. Il ne faut donc pas changer l’équipement de port après configuration, ce qui peut s’avérer plutôt contraignant. En revanche, une fois la récurrence programmée, le commutateur peut perdre la communication avec la plateforme d’administration, la récurrence continuera à s’appliquer.

On peut voir les récurrences disponibles via la commande show energywise recurrences :

On a ici une récurrence qui éteint (« set level 0 » à 17h33) et rallume (« set level 10 ») le port PoE à  19h06.

En dessous, il y a aussi une partie « Alarms » sur laquelle on ne peut pas agir. Elle correspond aux « alarmes » enregistrées par un téléphone en mode « Power Save Plus» (aussi appelé « deep sleep mode », présenté dans un futur article).
La syntaxe de la commande est la suivante:

(config-if)# energywise level <level> recurrence importance <importance> at <minute> <heure> <joursDuMois> <moisDeLannee> <semaineDuMois>

Tous les paramètres sont décrits au format numérique à partir de 0. Ainsi  janvier sera représenté par le 0, février par 1, mars par 2 etc… Pareil pour les journées : 0 désigne lundi, 1 mardi etc… l’astérisque (« * ») symbolisant respectivement « tous les mois », »tous les jours », « tous les … ».
energywise level 10 recurrence importance 100  at 30 23 1-31 1,3,4 *
Cette récurrence se déclenche à 23h30 (30 23), du 1er au 31 du mois (1-31), les 1ère,3ème et 4ème mois de l’année,  pour tous les mois de l’année(*).

Note: Si le PoE est désactivé sur l’interface, la commande EnergyWise est tout de même exécutée. Si le niveau d’énergie EnergyWise est 0 au moment où l’administrateur réactive le PoE sur le port, celui-ci restera éteint.

A vos claviers!

Matthieu.

Tech Notes – Les requêtes EnergyWise

Maintenant que nous avons configuré quelques équipements EnergyWise, il est temps enfin de montrer la puissance des requêtes EnergyWise que l’on vante depuis le début sans jamais avoir pu les mettre à l’épreuve!

Les requêtes (« query »)

Il faut avant tout comprendre qu’une requête s’applique uniquement sur le domaine EnergyWise auquel appartient le commutateur d’où elle est lancée ! La commande « energywise query » a une syntaxe plutôt longue et variable, je vous encourage à abuser de l’autocomplétion (« ? » + touche « tabulation ») pour vous aider et voir les différentes possibilités.
Les requêtes fonctionnent essentiellement selon 2 modes:
– un mode pour récupérer la consommation des équipements
– un mode pour agir sur les équipements

La commande « energywise query analyze domain » va donner quelques informations sur le domaine auquel appartient le commutateur comme le nombre de commutateurs appartenant au domaine et le nombre d’équipements avec un agent EnergyWise, ceci n’inclut pas les interfaces.

Toutes les autres requêtes commencent par filtrer les équipements auxquels elles vont s’appliquer. Elles filtrent d’abord par importance :
energywise query importance <importanceMaxDesEquipementsAFiltrer> …
Ici je sélectionne tous les équipements qui ont une criticité (« importance ») inférieure ou égale à importanceMaxDesEquipementsAFiltrer. ainsi « energywise query importance 100 » sélectionne tous les équipements avec une importance <= 100 or 100 étant l’importance maximum, cela sélectionne tous les équipements.
Une fois que l’on a filtré par équipement, on peut filtrer soit par nom soit par mot clé (par commodité, on choisit importanceMaxDesEquipementsAFiltrer = 100):
energywise query importance 100 name <nomDesEquipements> …
energywise query importance 100 keywords <motCle> …
Les commandes EnergyWise supportent les « wildcards » (traduire  les masques ou joker), c’est-à-dire que la touche « * » désigne n’importe quel mot. Exemple : « name Phone* » sélectionne tous les équipements dont le nom commence par Phone, « name * » sélectionne tous les équipements, peu importe leur nom.

Note : depuis la CLI, les 2 commandes sont exclusives mais depuis une plateforme d’administration, on peut appliquer les filtres name ET keywords.

Une fois le filtre paramétré, nous avons 4 fonctions qui vont s’appliquer aux équipements sélectionnés par le filtre :

  • set level <niveauDEnergie> permet d’appliquer un niveau d’énergie
  • collect permet d’interroger les équipements de 2 manières:
    • collect usage: va récupérer les consommations des équipements comme j’ai déjà pu le montrer dans les précédents articles. On peut ajouter un filtre supplémentaire après pour sélectionner « all », « meter », « consumer », « producer » voire modifier le « timeout ».
    • collect delta va indiquer ce que l’on consommerait en plus ou en moins selon les niveaux d’énergie. Sur la capture d’écran suivante, on voit que si l’on passe aux niveaux d’énergie de 2 à 10, on consommera 15,4 W de plus et que si l’on passe au niveau d’énergie 0, notre consommation restera inchangée. On peut donc en déduire que ces interfaces sont au niveau d’énergie 0.
  • sum la commande sum additionne les résultats donnés par collect pour n’afficher qu’un seul nombre. Il faut néanmoins faire attention à ce nombre qui peut compter des consommations plusieurs fois (un équipement PoE avec un agent EnergyWise qui enverrait sa consommation au commutateur + l’interface qui mesure la consommation de cet équipement)
  • la commande wol comme Wake On Lan permet de redémarrer un ordinateur à distance
    energywise query importance 100 name Fa0/1 wol mac <MACdeLaMachineCiblee> [password <password> etc… avec une mac sous la forme XXXX.XXXX.XXXX

Note : on peut évidemment abréger les commandes EnergyWise comme toutes les commandes IOS. Par exemple : « ener q i 100 n * c d a » est l’équivalent de « energywise query importance 100 n * collect delta all »

Alors, êtes-vous convaincus des potentiels d’EnergyWise?

A vous de jouer maintenant!

Matthieu

Tech Notes – Attributs : application aux interfaces

Maintenant que vous avez mieux compris l’utilité de chacun des attributs, nous allons passer à la partie pratique, en ligne de commande toujours.
Si vous possédez des équipements EnergyWise, vous pouvez les configurer soit via votre plateforme d’administration soit par leur propre interface (certains proposent une interface Web par exemple). Nous allons configurer ce qui est le plus répandu, c’est-à-dire une interface PoE.

Configurer le commutateur

On peut attribuer, une importance, un nom, un rôle à un commutateur EnergyWise. Il faut néanmoins retenir qu’on ne peut pas éteindre le commutateur via EnergyWise. Evidemment il faut être en mode configuration. A noter qu’EnergyWise ne supporte pas les accents et est sensible à la casse (c’est-à-dire distingue les majuscules des minuscules) !
EnergyWise accepte les espaces pour le rôle seulement (quand l’autocomplétion affiche « LINE » et non «WORD » ) :

Pour configurer son commutateur, on entrera donc (peu importe l’ordre):

(config)# energywise name <monNom>
(config)# energywise role <monRole>
(config)# energywise importance <monImportance>
(config)# energywise keywords <mots-clés,séparés,par,des,virgules>

Soit par exemple:

(config)# energywise name commutateurFanlessDuServiceRH
(config)# energywise role Commutateur Cisco 48 ports:
(config)# energywise importance 80
(config)# energywise keywords Etage_1,service_rh,dedie

Configurer vos interfaces PoE

La configuration des interfaces suit la même logique que pour le commutateur, il faut juste se placer au bon niveau de configuration de l’IOS :
– si l’on désire configurer une interface : (config)# interface fa0/1
– si l’on désire configurer un ensemble d’interface :
– contiguës : (config)# interface range fa0/1 – 10 par exemple
– éparses : (config)# interface range fa0/1 ,fa0/10,fa0/12

On peut ensuite configurer l’interface comme décrit précédemment, en lui attribuant un rôle, un nom, des mots-clés etc…
On a accès à une commande supplémentaire energywise activitycheck qui va indiquer au commutateur de vérifier s’il n’y a pas d’appel en cours avant d’éteindre un téléphone PoE.

(config-if)# energywise activitycheck
(config-if)# energywise name telephoneDeLaDRH
(config-if)# energywise role telephone
(config-if)# energywise importance 80
(config-if)# energywise keywords Etage_1,service_rh

et évidemment no energywise activitycheck pour désactiver (ou bien no energywise name etc…).
Pareillement pour des raisons de sécurité, vous pouvez décider de désactiver EnergyWise sur certains ports : no energywise
Si vous faîtes un show energywise children provisioned en mode privilégié (#show energywise children provisioned) alors les interfaces devraient disparaître de l’affichage. Pour les réactiver, il suffit d’entrer « energywise »au niveau des interfaces concernées.

Attention : Quand vous désactivez le domaine EnergyWise sur le commutateur, vous perdrez toute votre configuration au niveau des interfaces. S’il s’agit de changer le nom de domaine, vous pouvez le faire directement via
#energywise domain <nouveauNomDeDomaine> security shared-secret 0 <motDePasseDuDomaine>

Matthieu.

Tech Notes – Les attributs d’EnergyWise

Ce qui caractérise EnergyWise , c’est la maîtrise fine de la consommation. Elle est rendue possible grâce à une série d’attributs qui permet de restreindre les requêtes EnergyWise aux équipements qui remplissent les conditions voulues. Cet article décrit chacun des attributs d’EnergyWise et la semaine prochaine nous verrons comment les exploiter pour affiner nos requêtes.

Les attributs accessibles en écriture

Les niveaux d’énergie

Le niveau d’énergie est un nombre compris entre 0 (éteint) et 10 (consommation d’énergie maximale) qui permet de contrôler le niveau de consommation d’un équipement. Deux cas se présentent :

  • L’équipement appartient à l’écosystème EnergyWise auquel cas il embarque un agent (un composant logiciel) EnergyWise.
  • L’équipement est un appareil PoE auquel cas le niveau d’énergie sera appliqué au niveau de l’interface du commutateur

Tous les niveaux n’ont pas besoin d’être implémentés. Ainsi dans les simples équipements PoE, seuls les modes ON (pour les niveaux d’énergie de 1 à 10) / OFF (niveau d’énergie 0)  existent. Quand on envoie une commande de niveau 0, le commutateur coupe le courant au niveau de l’interface
Les possibilités sont évidemment plus nuancées si l’équipement embarque un agent EnergyWise.

  • Un téléphone qui consommerait ~8W du niveau d’énergie 2 à 10, consommera ~1W au niveau 1 (veille)  et 0W au niveau 0.
  • Il existe des prises contrôlables qui exploitent chacun des niveaux d’énergie. Pour moduler l’intensité lumineuse d’une lampe par exemple (ceci peut trouver son utilité pour contrôler des radiateurs, des climatiseurs).

Encore peu d’équipements implémentent plus de 3 niveaux d’énergie différents. Il s’agit généralement de 0 (éteint), 1 pour la veille et 2-10 en marche mais il existe des équipements utilisant tout le spectre des niveaux d’énergie )

On peut déduire les correspondances entre consommation et niveau d’énergie pour un équipement  via la ligne de commande:

Chaque périphérique aura un niveau d’énergie délivré par le port PoE auquel il est connecté. Les niveaux énergétiques sont compris entre 0 et 10, en 0 le port ne délivre aucune puissance et en 10 il délivre la puissance maximale en adaptant la puissance au modèle et au type de l’appareil connecté. Un niveau de puissance ne correspond pas à une valeur particulière mais est adapté en fonction du périphérique qu’il alimente.

Par défaut, les ports PoE des commutateurs sont au niveau 10. L’appareil recevra la puissance délivrée par le port PoE et son état de veille dépendra du niveau d’énergie appliqué.

Importance

L’importance est un nombre compris entre 1 et 100 qui qualifie la criticité de l’équipement. Un téléphone de sécurité aura une importance maximale (100) pour éviter qu’il ne soit accidentellement mis en veille ou même éteint par EnergyWise (auquel cas on devrait même désactiver EnergyWise sur le port). Inversement, les équipements dits de « confort » (lampe d’agrément) auront des importances faibles (entre 1 et 40 par exemple).

Attributs textuels

Il existe 3 attributs textuels (c’est-à-dire sous forme de chaînes de caractères) facultatifs dont le choix est complètement  libre : les mots-clés, le rôle  :

  • Le nom (« name ») correspond à l’identité de l’équipement au sein du domaine («Lampe de chevet du directeur»)
  •  Les mots-clés (« keywords ») permettent d’associer plus d’informations à un appareil («etage3», «service RH» …)
  • Le rôle (« role ») donne la fonction de l’équipement au sein du réseau EnergyWise («Telephone»,«Multiprise», «Ordinateur», etc…)

Ces attributs vont contribuer à mieux décrire le réseau et permettront également de restreindre certaines commandes sur certains équipements seulement, c’est-à-dire une granularité fine. A votre entreprise de normaliser ces champs comme elle l’entend : met-on l’étage en mot-clé ? si oui, écrit-on « etage1 », « etage_un » ou bien « etage_01 » (par exemple). Les caractères accentués ne sont pas acceptés, mais les espaces le sont.

En fait il existe un autre champ textuel non accessible en ligne de commande, mais que certaines plateformes de management acceptent, il s’agit du « Device Type », une chaîne de caractère libre elle aussi à laquelle on peut attribuer par exemple la valeur « Multiprise » ou « ordinateur ».

Les attributs accessibles en lecture seule

L’indice de confiance que l’on peut accorder à la consommation affichée

Le commutateur peut également qualifier la consommation d’un équipement comme on le voit sur cette capture:

  • Maximum: Imaginez un vieux commutateur incapable de mesurer la consommation de ses ports PoE. S’il s’agit d’un port PoE, nous pouvons être sûrs que la consommation n’excédera pas 15W
  • Presumed: On utilise une valeur approximative de celle qui devrait être consommée. Ainsi on sait que tel ordinateur consomme généralement entre 80 et 100 W, on lui attribuera donc une consommation présumée de 90 W
  • Trusted: l’équipement mesure lui-même sa consommation et la communique au commutateur qui lui fait alors confiance.
  • Unknown: Consommation inconnue
  • Actual: Disponible sur les équipements les plus récents, le commutateur est capable de mesurer la consommation sur demande.

Les catégories d’équipements

  • Consumer: Comme un commutateur, un téléphone et la majorité des équipements
  • Producer: pour les équipements producteurs (je n’en ai jamais encore rencontré mais il pourrait s’agir de panneaux solaires EnergyWise ou bien d’un onduleur par exemple)
  • Meter: Une sonde qui va mesurer la consommation (le cas pour les multiprises par exemple, les interfaces PoE).

Rendez-vous donc la semaine prochaine pour assigner aux interfaces PoE les attributs précédents et la découverte des requêtes EnergyWise !

Matthieu.

Tech Notes – Activation d’EnergyWise

En tout premier lieu, activons EnergyWise.

L’activation d’EnergyWise sur le réseau Cisco peut s’effectuer à travers Cisco Prime LMS ou simplement via l’interface console (CLI). Nous traiterons dans cet article de l’activation via l’interface console. Je fais l’hypothèse que vous savez vous connecter à l’équipement (ssh/telnet/console) et passer en mode privilégié (« # »)/configuration ( « (config)# » ) sur l’IOS.

EnergyWise demande une version logicielle minimum d’IOS. Vous trouverez les versions correspondantes dans l’article précédent.

Les exemples qui suivent proposent une configuration par défaut mais en utilisant « ? » vous pourrez voir les autres possibilités.
Pour activer complètement EnergyWise, il faut configurer un « domaine » EnergyWise. Un équipement (commutateur/routeur) ne peut appartenir qu’à un seul domaine EnergyWise. Les équipements appartenant à un même domaine EnergyWise peuvent s’interroger entre eux (« Quelle est la consommation électrique du domaine ? ») ou bien agir les uns sur les autres (« Eteindre tous les appareils de faible criticité »). Il est recommandé de configurer un domaine EnergyWise pour un bâtiment, ce qui correspond à une continuité de distribution électrique, mais vous êtes libre d’organiser autrement votre gestion électrique. Vous êtes limité par le nombre de points à gérer dans un même domaine. Au delà de 10 000 équipements, il est conseillé de subdiviser le domaine.

Pour configurer complètement EnergyWise, il faut entrer 3 commandes:

  1. une commande pour créer le domaine ce qui va permettre aux équipements de communiquer entre eux. Les équipements ont besoin d’un mot de passe pour vérifier l’intégrité des messages. Ce mot de passe est donc commun à tous les commutateurs du domaine.
  2. une commande pour attribuer un mot de passe propre à la communication entre les agents (comme des téléphones/PDU/PC) directement connectés au commutateur et le commutateur. Il peut être différent pour chaque commutateur d’un même domaine.
  3. Un troisième mot de passe est nécessaire pour la communication entre un serveur d’administration EnergyWise et le commutateur. Il peut être également différent au sein des commutateurs d’un même domaine.

Les « // » précèdent mes commentaires


// soit on précise une IP (VLAN associée au commutateur)
 (config)# domain <nomDuDomaine> security shared-secret 0 <motDePasse0> protocol udp port 43440 ip <ipv4>

// soit on précise une interface du switch (on peut aussi préciser les 2)
 (config)# domain <nomDuDomaine> security shared-secret 0 <motDePasse0> protocol udp port 43440 interface monInterface

// Configure le mot de passe EnergyWise pour les communications entre les agents et le commutateur
 (config)# energywise endpoint security shared-secret 0 <motDePasse1>

// "showroom42" étant le mot de passe permettant aux commutateurs de communiquer avec un tiers programme  de management
 (config)# energywise management security shared-secret 0 <motDePasse2>

Note: On peut utiliser 3 fois le même mot de passe dans le cadre des tests.

Il est possible de vérifier que le domaine a bien été créé avec la commande show energywise domain

 # show energywise domain
 Name : name
 Domain : ewz
 Protocol : udp
 IP : x.x.x.x
 Port : 43440

Vous pouvez voir les commutateurs voisins (appartenant au même domaine) en entrant la commande « show energywise neighbors »

De même pour les agents directement connectés au commutateur via la commande  » show energywise children »

Félicitations vous venez d’activer EnergyWise !

Matthieu.

Tech Notes – Présentation des plates-formes supportées

Energywise est un protocole réseau lancé par Cisco en 2009 destiné à mieux connaître sa consommation électrique pour éventuellement mieux la contrôler,  soit pour réaliser des économies, soit pour délester (si le prix de l’électricité augmente trop, ou lors d’un basculement sur groupe électrogène de secours par exemple).

Je suppose que vous connaissez les principes de base d’EnergyWise. Plusieurs articles du blog vous les rappellent comme “EnergyWise expliqué en vidéo” ou “EnergyWise s’étoffe” et vous pouvez toujours vous réferer à http://www.cisco.com/go/energywise.

Reposant d’abord sur une implémentation SNMP (appelée « phase 1 », à partir de l’IOS 12.2(50)SE), la version actuelle fonctionne avec son propre protocole (« phase 2 »). Nous en sommes actuellement à la phase 2.5.
Le protocole permet à la fois d’interroger le réseau (« Combien consomme mon bâtiment ? », « Combien consomment mes équipements non critiques ? », « Combien consommerai-je si je passais au niveau d’énergie supérieure » ) et de le piloter:

  • soit en contrôlant l’énergie envoyée sur les ports PoE ce qui permet de gérer directement n’importe quel équipement PoE (caméra/téléphone IP/Point d’accès,…)
  • soit en envoyant des commandes aux équipements compatibles EnergyWise qui vont réagir à cette commande (pour une multiprise,  il pourra s’agir d’éteindre ou de modifier la puissance délivrée à la prise par exemple).

EnergyWise est installé de base avec l’IOS (sans coût de licence supplémentaire) et est disponible sur les plates-formes indiquées ici, c’est-à-dire pour faire court sur l’ensemble des commutateurs Catalyst et sur les routeurs ISR G2 (Integrated Services Router de deuxième génération).

EnergyWise est une technologie qui évolue vite, c’est pourquoi avant d’attaquer les tutoriaux qui suivent, je vous conseille d’installer l’IOS avec la version d’EnergyWise la plus récente.

Attention: La série d’IOS 15.X bien que plus récente ne contient pas les dernières versions d’EnergyWise. A l’heure où je vous écris, il faut installer la 12.2(58) qui prend mieux en compte le mode « Power Save Plus » par exemple.

Pour connaître la version d’EnergyWise sur votre équipement, vous pouvez entrer la commande:

#show energywise version

dont la sortie se lit comme suit:

EnergyWise is Enabled
IOS Version:  12.2(58)SE2
EnergyWise Specification:  (rel2_7)4.0.28

La 1ère ligne indique si EnergyWise est activé, la 2nde la version de l’IOS (abrégée par rapport à un « show version »). La dernière ligne (celle qui nous intéresse) indique la spécification/branche supportée (« rel2_7 » ici) ainsi qu’un numéro de release (« 4.0.28 ») qui correspond au numéro de commit du code source.

Vous avez mis à jour votre IOS? Alors nous pouvons passer à l’activation!

Matthieu.

Tech Notes – EnergyWise pas à pas

Bonjour,

Je m’appelle Matthieu Coudron et j’ai passé ces derniers mois chez Cisco France à travailler sur EnergyWise. A travers mes différentes recherches, j’ai pu constater la richesse du site cisco.com, à tel point que l’essentiel se retrouve parfois noyé dans la masse d’informations. Ce que je propose ici, c’est une série d’articles courts – des Tech Notes – sur des points précis, plutôt techniques, autour d’EnergyWise (configuration/fonctionnement/intégration avec l’écosytème,..). Ces articles vous permettront de comprendre rapidement l’essentiel et, si vous désirez en apprendre davantage, vous pourrez vous rendre sur les différents liens dont je parsèmerai les articles.

Nous commencerons par les diverses méthodes d’activation, puis, au fil des articles nous aborderons la mise en oeuvre de politiques, la construction de rapports, nous traiterons de fonctions avancées ou encore de solutions de l’écosystème.

Je m’efforcerai de garder un rythme de publication d’un article par semaine. Soyez donc aux aguets des Tech Notes le jeudi après-midi!

Matthieu.

%d blogueurs aiment cette page :