Ce document contient des réponses aux questions fréquemment posées et guide les utilisateurs vers des ressources utiles à propos du protocole SNMP et des problèmes SNMP lorsqu'ils sont liés à l'équipement Cisco.
A. Non, ce n'est pas un bug. IP-SNMP peut occuper 90 % du CPU sur le routeur lorsque celui-ci est légèrement chargé d'autres tâches ; cette situation n'est pas inhabituelle. IP-SNMP s'exécute à une priorité faible. Une utilisation CPU de 90 % ou plus signifie que le routeur dispose de la bande passante nécessaire pour passer plus de temps sur SNMP.
Cependant, en cas d'utilisation intensive, l'utilisation du processeur peut approcher 100 % et affamer les processus de faible priorité. Un exemple d'utilisation intensive est la récupération de tables volumineuses (telles que la récupération automatique de ipRouteTable et ipNetToMediaTable) par une application de gestion de réseau.
Dans certaines circonstances, le processus IP-SNMP peut consommer presque toutes les ressources du processeur. Le processus peut affamer d'autres processus et provoquer un comportement erratique dans le périphérique. Le symptôme le plus évident est la perte de connexions TCP au périphérique. La cause la plus probable du problème est l'envoi d'une série de requêtes SNMP au périphérique en un court laps de temps, ce qui entraîne la récupération de grandes quantités de données. Ce comportement est généralement associé à des mécanismes de détection automatique de réseau qui récupèrent périodiquement la totalité du cache ARP (Address Resolution Protocol) du périphérique et de la table de routage IP.
Certaines applications de gestion de réseau peuvent exacerber le problème. Certaines de ces applications, par défaut, effectuent la détection automatique aussi souvent que toutes les 5 minutes.
Une solution de contournement partielle consiste à identifier les périphériques qui effectuent la détection automatique et à modifier le comportement par défaut.
Une autre solution consiste à forcer le routeur à mettre fin prématurément aux requêtes pour la table de routage IP et le cache ARP à partir du serveur du système de gestion du réseau. Configurez le routeur pour qu'il réponde avec un message complet dès que le routeur reçoit le début d'une demande pour la table de routage IP ou le cache ARP. Reportez-vous au document Protocole de gestion de réseau simple (SNMP) IP qui entraîne une utilisation élevée du CPU pour un exemple de la façon d'effectuer cette configuration sur un routeur Cisco.
A. RFC 1573 IF-MIB implémente la prise en charge des sous-interfaces. (RFC 2233 et RFC 2863 RFC 1573 .) Il permet l'utilisation de VLAN, d'identificateurs de connexion de liaison de données (DLCI) Frame Relay et de circuits virtuels X.25 comme sous-interfaces pour apparaître dans le ifTable. RFC 1213 a introduit ifTable et RFC 1573 a amélioré ifTable. L'une des améliorations consiste à autoriser l'existence d'interfaces non physiques dans ifTable.
La prise en charge générique des sous-couches de ifTable est présente depuis la version 11.1(1) du logiciel Cisco IOS. Les groupes qui prennent en charge un type de support donné doivent déterminer (avec la direction de l'IETF (Internet Engineering Task Force)) si les sous-couches sont appropriées pour ce type de support. Les groupes doivent également déterminer comment soutenir ces sous-couches.
Sous-interface Pris en charge depuis... ATM Logiciel Cisco IOS Version 12.0(1)T Relais de trames Logiciel Cisco IOS version 11.1 LANE1 Logiciel Cisco IOS version 11.1
FE2
GE3
Logiciel Cisco IOS Version 12.0(21)S—(encapsulation IEEE 802.1Q)
Logiciel Cisco IOS Version 12.1(3)T : ID de bogue Cisco CSCdk25367 (clients enregistrés uniquement) (prise en charge de l'encapsulation Cisco Inter-Switch Link Protocol [ISL])
Logiciel Cisco IOS Version 12.1(7)E : ID de bogue Cisco CSCds76462 (clients enregistrés uniquement) (prise en charge de l'encapsulation Cisco ISL)
Logiciel Cisco IOS Version 12.2(6.8)—ID de bogue Cisco CSCds00250 (clients enregistrés uniquement) (encapsulation IEEE 802.1Q)
1 Émulation LAN
2 Fast Ethernet
3 Gigabit Ethernet
A. Suivez la procédure suivante :
tsMsgSend = .1.3.6.1.4.1.9.2.9.9 from the OLD-CISCO-TS-MIB tsMsgSend OBJECT-TYPE -- FROM OLD-CISCO-TS-MIB SYNTAX Integer { nothing(1), reload(2), messagedone(3), abort(4) } MAX-ACCESS read-write STATUS Mandatory DESCRIPTION "Sends the message. The value determines what to do after the message has completed." ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) cisco(9) local(2) lts(9) 9 }Sur le routeur Cisco, vous devez définir ces commandes pour prendre en charge la commande reload :
snmp-server community private RW snmp-server system-shutdownCet exemple montre comment recharger le routeur avec l'adresse IP 10.16.99.55 :
# ./snmpset 10.16.99.55 private .1.3.6.1.4.1.9.2.9.9.0 i 2 !--- This is an explanation of the variables that this command uses. 10.16.99.55 = ip address of your router private = R/W SNMP Community string of your router .1.3.6.1.4.1.9.2.9.9.0 = tsMsgSend SNMP MIB OID i = Integer as defined SYNTAX in the MIB 2 = reload command as defined in the MIB
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
26-Oct-2005 |
Première publication |