L'internet rapide et permanent

Outils pour utilisateurs

Outils du site

Vous êtes ici : L'internet rapide et permanent » SNMP » Analyse du protocole

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
215snmp:60_sniffs [le 11/07/2010 à 16:45] – prof215snmp:60_sniffs [le 30/06/2018 à 15:43] (Version actuelle) – prof
Ligne 70: Ligne 70:
 Nous ne referons pas la manipulation en v2c, le résultat étant le même. Nous ne referons pas la manipulation en v2c, le résultat étant le même.
 ===== snmpwalk ===== ===== snmpwalk =====
 +Voyons maintenant la branche ''system'' en entier, avec la commande ''snmpwalk'' :
 +<code>
 +$ snmpwalk -v 1 -c public -Ot 172.16.252.2 SNMPv2-MIB::system
 +SNMPv2-MIB::sysDescr.0 = STRING: ProCurve J4899B Switch 2650, revision H.10.35, ROM H.08.02 (/sw/code/build/fish(mkfs))
 +SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.11.2.3.7.11.44
 +DISMAN-EVENT-MIB::sysUpTimeInstance = 1123840470
 +SNMPv2-MIB::sysContact.0 = STRING: sysop
 +SNMPv2-MIB::sysName.0 = STRING: ProCurve Switch 2650-1
 +SNMPv2-MIB::sysLocation.0 = STRING: 
 +SNMPv2-MIB::sysServices.0 = INTEGER: 74
 +</code>
  
 +Wireshark a vu une suite de commandes :
 +<code>
 +No.     Time        Source                Destination           Protocol Info
 +      1 0.000000    192.168.0.16          172.16.252.2          SNMP     get-next-request 1.3.6.1.2.1.1
 +      2 0.101794    172.16.252.2          192.168.0.16          SNMP     get-response 1.3.6.1.2.1.1.1.0
 +      3 0.101915    192.168.0.16          172.16.252.2          SNMP     get-next-request 1.3.6.1.2.1.1.1.0
 +      4 0.172930    172.16.252.2          192.168.0.16          SNMP     get-response 1.3.6.1.2.1.1.2.0
 +      5 0.173003    192.168.0.16          172.16.252.2          SNMP     get-next-request 1.3.6.1.2.1.1.2.0
 +      6 0.244100    172.16.252.2          192.168.0.16          SNMP     get-response 1.3.6.1.2.1.1.3.0
 +      7 0.244174    192.168.0.16          172.16.252.2          SNMP     get-next-request 1.3.6.1.2.1.1.3.0
 +      8 0.315341    172.16.252.2          192.168.0.16          SNMP     get-response 1.3.6.1.2.1.1.4.0
 +      9 0.315412    192.168.0.16          172.16.252.2          SNMP     get-next-request 1.3.6.1.2.1.1.4.0
 +     10 0.389045    172.16.252.2          192.168.0.16          SNMP     get-response 1.3.6.1.2.1.1.5.0
 +     11 0.389109    192.168.0.16          172.16.252.2          SNMP     get-next-request 1.3.6.1.2.1.1.5.0
 +     12 0.460725    172.16.252.2          192.168.0.16          SNMP     get-response 1.3.6.1.2.1.1.6.0
 +     13 0.460787    192.168.0.16          172.16.252.2          SNMP     get-next-request 1.3.6.1.2.1.1.6.0
 +     14 0.532128    172.16.252.2          192.168.0.16          SNMP     get-response 1.3.6.1.2.1.1.7.0
 +     15 0.532189    192.168.0.16          172.16.252.2          SNMP     get-next-request 1.3.6.1.2.1.1.7.0
 +     16 0.624758    172.16.252.2          192.168.0.16          SNMP     get-response 1.3.6.1.2.1.2.1.0
 +</code>
 +Pas la peine de détailler, nous voyons bien une suite de ''get-next-request'' émises par le client, suivies des ''get-response'' de l'agent SNMP du switch. Nous avons ici 8 trames d'interrogation et 8 trames de réponses. Si l'on désire parcourir une branche importante, le réseau va avoir du travail.
 +===== snmpbulkwalk =====
 +Innovation de la version 2c, observons la différence :
 +  $ snmpbulkwalk -v 1 -c public -Ot 172.16.252.2 SNMPv2-MIB::system
 +  snmpbulkwalk: Cannot send V2 PDU on V1 session
 +
 +Juste pour vérifier que cette commande ne peut fonctionner si l'on utilise SNMP v1.
 +<code>
 +$ snmpbulkwalk -v 2c -c public -Ot 172.16.252.2 SNMPv2-MIB::system
 +SNMPv2-MIB::sysDescr.0 = STRING: ProCurve J4899B Switch 2650, revision H.10.35, ROM H.08.02 (/sw/code/build/fish(mkfs))
 +SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.11.2.3.7.11.44
 +DISMAN-EVENT-MIB::sysUpTimeInstance = 1123894614
 +SNMPv2-MIB::sysContact.0 = STRING: sysop
 +SNMPv2-MIB::sysName.0 = STRING: ProCurve Switch 2650-1
 +SNMPv2-MIB::sysLocation.0 = STRING: 
 +SNMPv2-MIB::sysServices.0 = INTEGER: 74
 +</code>
 +A première vue, nous obtenons exactement le même résultat qu'avec ''snmpwalk''. Cependant, voici ce qu'a vu Wireshark en vue condensée :
 +<code>
 +No.     Time        Source                Destination           Protocol Info
 +      1 0.000000    192.168.0.16          172.16.252.2          SNMP     getBulkRequest 1.3.6.1.2.1.1
 +      2 0.077623    172.16.252.2          192.168.0.16          SNMP     get-response 1.3.6.1.2.1.1.1.0 1.3.6.1.2.1.1.2.0 1.3.6.1.2.1.1.3.0 1.3.6.1.2.1.1.4.0 1.3.6.1.2.1.1.5.0 1.3.6.1.2.1.1.6.0 1.3.6.1.2.1.1.7.0 1.3.6.1.2.1.2.1.0 1.3.6.1.2.1.2.2.1.1.1 1.3.6.1.2.1.2.2.1.1.2
 +</code>
 +Deux trames seulement. Voyons maintenant le détail :
 +<html><pre class="code">
 +Frame 1 (83 bytes on wire, 83 bytes captured)
 +...
 +Simple Network Management Protocol
 +    version: v2c (1)
 +    community: public
 +    data: getBulkRequest (5)
 +        <span class="bhly">getBulkRequest</span>
 +            request-id: 112026182
 +            non-repeaters: 0
 +            max-repetitions: 10
 +            variable-bindings: 1 item
 +                1.3.6.1.2.1.1: Value (Null)
 +                    <span class="bhly">Object Name: 1.3.6.1.2.1.1 (iso.3.6.1.2.1.1)</span>
 +                    Value (Null)</span>
 +</pre></html>
 +
 +La requête est ici ''getBulkRequest'' et elle est unique. Tout le détail de la branche se trouve dans une seule réponse :
 +
 +<html><pre class="code">
 +Frame 2 (353 bytes on wire, 353 bytes captured)
 +...
 +Simple Network Management Protocol
 +    version: v2c (1)
 +    community: public
 +    data: get-response (2)
 +        <span class="bhly">get-response</span>
 +            request-id: 112026182
 +            error-status: noError (0)
 +            error-index: 0
 +<span class="bhly">            variable-bindings: 10 items
 +                1.3.6.1.2.1.1.1.0: 50726F4375727665204A3438393942205377697463682032...
 +                    Object Name: 1.3.6.1.2.1.1.1.0 (iso.3.6.1.2.1.1.1.0)
 +                    Value (OctetString): 50726F4375727665204A3438393942205377697463682032...
 +                1.3.6.1.2.1.1.2.0: 1.3.6.1.4.1.11.2.3.7.11.44 (iso.3.6.1.4.1.11.2.3.7.11.44)
 +                    Object Name: 1.3.6.1.2.1.1.2.0 (iso.3.6.1.2.1.1.2.0)
 +                    Value (OID): 1.3.6.1.4.1.11.2.3.7.11.44 (iso.3.6.1.4.1.11.2.3.7.11.44)
 +                1.3.6.1.2.1.1.3.0: 1123894614
 +                    Object Name: 1.3.6.1.2.1.1.3.0 (iso.3.6.1.2.1.1.3.0)
 +                    Value (Timeticks): 1123894614
 +                1.3.6.1.2.1.1.4.0: 7379736F70
 +                    Object Name: 1.3.6.1.2.1.1.4.0 (iso.3.6.1.2.1.1.4.0)
 +                    Value (OctetString): 7379736F70
 +                1.3.6.1.2.1.1.5.0: 50726F43757276652053776974636820323635302D31
 +                    Object Name: 1.3.6.1.2.1.1.5.0 (iso.3.6.1.2.1.1.5.0)
 +                    Value (OctetString): 50726F43757276652053776974636820323635302D31
 +                1.3.6.1.2.1.1.6.0: <MISSING>
 +                    Object Name: 1.3.6.1.2.1.1.6.0 (iso.3.6.1.2.1.1.6.0)
 +                    Value (OctetString): <MISSING>
 +                1.3.6.1.2.1.1.7.0: 74
 +                    Object Name: 1.3.6.1.2.1.1.7.0 (iso.3.6.1.2.1.1.7.0)
 +                    Value (Integer32): 74
 +                1.3.6.1.2.1.2.1.0: 55
 +                    Object Name: 1.3.6.1.2.1.2.1.0 (iso.3.6.1.2.1.2.1.0)
 +                    Value (Integer32): 55
 +                1.3.6.1.2.1.2.2.1.1.1: 1
 +                    Object Name: 1.3.6.1.2.1.2.2.1.1.1 (iso.3.6.1.2.1.2.2.1.1.1)
 +                    Value (Integer32): 1
 +                    Object Name: 1.3.6.1.2.1.2.2.1.1.2 (iso.3.6.1.2.1.2.2.1.1.2)
 +                    Value (Integer32): 2</span>
 +</pre></html>
 +Deux trames qui font le même boulot que les 16 précédentes avec ''snmpwalk'', le réseau va apprécier. De quoi convaincre d'utiliser plutôt v2c, quand c'est possible.
Analyse du protocole: Dernière modification le: 11/07/2010 à 16:45 par prof