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.

%d blogueurs aiment cette page :