Déroutement SNMP pour surveiller le changement de contiguïté EIGRP du Nexus 7000

Options de téléchargement

PDF (213.7 KB)
Consulter à l'aide d'Adobe Reader sur un grand nombre d’appareils
ePub (167.9 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
Mobi (Kindle) (278.6 KB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils

Mis à jour:23 août 2017

ID du document:211527

À propos des traductions

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Contenu

Introduction

Exemple

Introduction

Ce document décrit le déroutement de Protocole SNMP (Simple Network Management Protocol) pour surveiller le changement de contiguïté de Protocole EIGPR (Enhanced Interior Gateway Routing Protocol) du Nexus 7000. Le Nexus prend en charge seulement deux déroutements pour déroutements EIGRP-MIB, cEigrpAuthFailureEvent et cEigrpRouteStuckInActive, mais aucun SNMP pour des voisins EIGRP haut/bas (cEigrpNbrDownEvent).

Un contournement viable pour générer des déroutements SNMP pour surveiller des modifications de contiguïté EIGRP serait de configurer deux scripts EEM - un pour le voisin et un pour le voisin vers le bas - déclenchés basé sur le modèle de Syslog.

Exemple

event manager applet EIGRP_TRAP_nbr_dwn event syslog pattern "EIGRP-5-NBRCHANGE_DUAL.*down" action 1.1 snmp-trap strdata "EIGRP Neighbor Down" event manager applet EIGRP_TRAP_nbr_up event syslog pattern "EIGRP-5-NBRCHANGE_DUAL.*up" action 1.1 snmp-trap strdata "EIGRP Neighbor Up"

Vous pouvez alors tester en agitant une interface de la couche 3 (vous pouvez créer un test Switch Virtual Interface (SVI) pour vérifier quant à pour ne pas perturber la Connectivité) :

2017 Jul 12 15:51:06 N7K-AGG2 %EIGRP-5-NBRCHANGE_DUAL:  eigrp-10 [4049] (default-base) IP-EIGRP(0) 10: Neighbor 10.10.10.84
 (Vlan1064) is down: holding time expired
2017 Jul 12 15:51:10 N7K-AGG2 %EIGRP-5-NBRCHANGE_DUAL:  eigrp-10 [4049] (default-base) IP-EIGRP(0) 10: Neighbor 10.10.10.84
 (Vlan1064) is up: new adjacency

Confirmez que le Nexus envoie ces derniers correctement et vérifiez votre outil de surveillance SNMP - la sortie pourrait différer légèrement et elle dépend de l'outil utilisé :

Vous pouvez également passer en revue ces déroutements SNMP par l'intermédiaire d'une capture Wireshark :

Note: Il dépend de la version de Wireshark, la chaîne ne sera pas en texte lisible pour l'homme mais peut être filtré par l'intermédiaire de « snmp.value.octets contient « l'EIGRP ».

Vous pouvez également vérifier que le Nexus envoie ces derniers sur le gestionnaire encastré d'événement (EEM) déclenchant avec Ethanalyzer. Voyez l'exemple :

N7K-A-Admin# ethanalyzer local interface mgmt display-filter snmp limit-c 0

Capturing on mgmt0
2017-07-12 15:43:37.431067 10.122.140.96 -> 172.18.121.3 SNMP 278 snmpV2-trap 1.3.6.1.2.1.1.3.0 1.3.6.1.6.3.1.1.4.1.0 1.3.6.1.4.1.9.10.134.1.2.3.1.2.1 1.3.6.1.4.1.9.10.134.1.2.3.1.6.1 1.3.6.1.4.1.
9.10.134.1.2.3.1.7.1 1.3.6.1.4.1.9.10.134.1.2.3.1.9.1 1.3.6.1.4.1.9.10.134.1.2.3.1.10.1 1.3.6.1.4.1.9.10.134.1.2.3.1.11.1

Note: Pré NX-OS 7.x ne nous donne pas l'option de configurer le snmp-server enable traps syslog qui te permettra à leur tour pour surveiller le log se connectant entier lui-même filtre alors pour les messages EIGRP. Cette caractéristique a été ajoutée dans des releases, 7.x et plus tard.