Blog Cisco France – Green IT

Blog Cisco France – Green IT > EnergyWise

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.

Tags: , , ,

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.

Tags: , , , , , ,