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 :
Le monde SNMP se contrôle maintenant via EnergyWise!
Baptiste.
