| | 1 | = Observations trace de "TRAP" SNMP = |
| | 2 | |
| | 3 | Sur cette trace, nous pouvons visualiser 4 messages Trap SNMP, envoyé par l'agent SNMP sur le port 162 de serveur1. |
| | 4 | |
| | 5 | == Comment provoquer ces messages? == |
| | 6 | |
| | 7 | J'ai débranché le cable se trouvant sur le port 1 du switch. 1 seconde plus tard, je pouvais déjà visualiser les messages TRAP arriver périodiquement au niveau de serveur1. Chacun des messages à une valeur de request-id différente, ce qui montre qu'il ne s'agit pas un message dupliqué. |
| | 8 | |
| | 9 | == Qu'est ce qu'un message "TRAP"? == |
| | 10 | |
| | 11 | Une fois défini, si un certain évènement se produit, comme par exemple le dépassement d'un seuil, l'agent envoie un paquet UDP à un serveur. Ce processus d'alerte est utilisé dans les cas où il est possible de définir simplement un seuil d'alerte. Les traps SNMP sont |
| | 12 | envoyés en UDP/162. |
| | 13 | |
| | 14 | Au niveau du switch, nous avons entré les receveurs potentiels de messages TRAP |
| | 15 | {{{ |
| | 16 | #!rst |
| | 17 | configure snmp add trapreceiver 10.40.3.2 |
| | 18 | }}} |
| | 19 | |
| | 20 | Il est même possible d'entrer un suffixe, si l'on souhaite qu'un sous-reseau reçoive le message! Mais dans ce cas la commande serait un peu différente. |
| | 21 | |
| | 22 | == Quel est le message "TRAP" actuel? == |
| | 23 | On visualise 5 objets par message envoyé: |
| | 24 | * L'objet sysuptime.0 (1.3.6.1.2.1.1.3.0) qui indique depuis combien de temps le switch est allumé. Celui permettera de comparer 2 messages TRAP ou bien de déterminer à quel moment un message TRAP a été envoyé. On apprend que les 2 premiers messages ont été envoyé en même temps et les 2 derniers également. Comme SNMP repose sur UDP cela doit être pour maximiser la probabilité de ce reception du message. |
| | 25 | * L'objet snmpTrapOID.0 détermine la raison du message TRAP: dans les 2 premiers TRAP les messages signalent que un port est deconnecté (linkDown), dans les 2 autres, qu'un port est connecté (link up): On peut alors déduire quand un port à été déconnecté puis reconnecté. (Il s'agit d'un très bon anti-vol! je vous laisse deviner comment le mettre en place) |
| | 26 | * Tous les objets suivants sont identiques ifIndex, IfAdminStatus et IfOperStatus. "If" est une abbréviation qui signifie Interface. |
| | 27 | {{{ |
| | 28 | #!rst |
| | 29 | IfIndex est une nombre unique (plus grand que 0) qui identifie chaque interface pour avoir une identification de cette interface avec SNMP. |
| | 30 | IfAdminStatus indique l'état désiré d'un port: 1 pour Actif, 2 pour désactivé. |
| | 31 | IfOperStatus indique l'etat actuel d'un port: 1 Pour inactif, 2 pour actif. |
| | 32 | }}} |
| | 33 | |
| | 34 | * Ainsi, on comprend que le port 1 est concerné par chacun des messages, qu'il devrait être activé mais qu'il ne l'ai pas dans les 2 premiers messages! (On confirme ainsi le but de ces messages) |
| | 35 | * Dans les 2 derniers messages, on apercoit que le port est connecté :-) |
