2017-07-10 3 views
-2

Il y a 2 types d'alarme linkDownpiège linkDown SNMP ne pas avoir le nécessaire varbinds

linkDown (CISCO-GENERAL-traps) 1.3.6.1.2.1.11.0.2 linkDown (IF-MIB) 1.3.6.1. 6.3.1.1.5.3

linkDown de CISCO mib-GENERAL-TRAPPES contient varbinds ci-dessous 1.ifIndex 2.ifDescr 3.ifType 4.locIfReason

linkDown de Si-MIB mib contient le ci-dessous varbinds 1.ifIndex 2.ifAdminStatus 3.ifOperStatus

Mais le linkDown que j'ai reçu des appareils de ME1200 a le dessous varbinds 1.IfIndex 2.IfDesc 3.IfType 4.lifTable , Depuis le piège SNMP doesn Ne contient pas de locIfReason et IfAdminStatus, je ne pouvais pas traiter ce piège linkDown. La variable varBind contient les informations relatives à l'état de l'administrateur, mais ma question est pourquoi locIfReason et IfAdminStatus varbind ne sont pas disponibles?. Comment obtenir le varbind IfAdminStatus de l'appareil?

+0

Si les appareils ME1200 se comportent mal, contactez votre fournisseur. Ce n'est pas une question de programmation qui correspond au format de StackOverflow, elle risque donc d'être supprimée. – Jolta

Répondre

0

Cet OID pour CISCO-GENERAL-TRAPS (actuellement CISCOTRAP-MIB?) LinkDown ne semble pas correct. Offhand, je trouve une définition SMIv1 TRAP-TYPE pour cela, pas un NOTIFICATION-TYPE, ce qui signifie qu'il a été défini avec un entier (pas un OID), et son OID serait déterminé par RFC 2576 règles de traduction. Dans la MIB SMIv1 que j'ai trouvée, leur version de linkDown est définie avec ENTERPRISE "snmp", ce qui (comme Andrew dit plus haut) signifie qu'ils redéfinissent plutôt le piège standard dans cette MIB; ils auraient dû utiliser leur propre OID d'ENTREPRISE, ce qui l'aurait rendu unique.

Les règles de conversion RFC 2576 exigent que les interruptions avec "snmp" ENTERPRISE soient mappées à l'un des OID standard. Selon ces règles, 1.3.6.1.2.1.11.0.2 ne serait pas l'OID correct pour CISCO-GENERAL-TRAPS: linkDown, ce serait la même chose que la norme (1.3.6.1.6.3.1.1.5.3). C'est-à-dire, si le module importé (ou autrement défini "snmp" avec l'OID standard), mais il ne le fait pas, donc je ne peux que supposer qu'il s'agit d'une version modifiée de la MIB où cela a été corrigé. 1.3.6.1.2.1.11 est l'OID de "snmp", de sorte que le 1.3.6.1.2.1.11.0.2 serait l'OID s'il était converti selon les règles pour les interruptions autre que ENTERPRISE "snmp". Quelque part le long du chemin, il a été converti de manière incorrecte, en plus de surcharger la définition du piège standard.

0

Les linkDown et linkUp pièges sont générique. Ces pièges sont définis dans la RFC standard et ont ensemble prédéfini de liaisons variables:

linkDown NOTIFICATION-TYPE 
    OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 
    STATUS current 
    DESCRIPTION 
      "A linkDown trap signifies that the SNMP entity, acting in 
      an agent role, has detected that the ifOperStatus object for 
      one of its communication links is about to enter the down 
      state from some other state (but not from the notPresent 
      state). This other state is indicated by the included value 
      of ifOperStatus." 
    ::= { snmpTraps 3 } 

linkUp NOTIFICATION-TYPE 
    OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 
    STATUS current 
    DESCRIPTION 
      "A linkUp trap signifies that the SNMP entity, acting in an 
      agent role, has detected that the ifOperStatus object for 
      one of its communication links left the down state and 
      transitioned into some other state (but not into the 
      notPresent state). This other state is indicated by the 
      included value of ifOperStatus." 
    ::= { snmpTraps 4 } 

Le Cisco ne devrait pas avoir modifié ces pièges car il n'est pas autorisé. Au lieu de cela, ils devraient avoir défini des pièges spécifiques à l'entreprise.