CISCO-NHRP-EXT-MIB
AI MIB Summary
The CISCO-NHRP-EXT-MIB monitors Cisco-specific Next Hop Resolution Protocol (NHRP) operational states and triggers critical event notifications for Next Hop Clients (NHC), Next Hop Servers (NHS), and registration entities within Non-Broadcast Multi-Access (NBMA) networks. It extends standard RFC 2677 object definitions to track proprietary NHRP enhancements, including registration failures, peer connectivity anomalies, and server-client synchronization issues in DMVPN or legacy NBMA topologies.
This MIB module is an extension of the NHRP MIB module as defined in RFC 2677. It defines notifications associated with critical events in the Next Hop Resolution Protocol, NHRP, as defined in RFC 2332. This module also contains information about Cisco proprietary enhancements to the protocol.
Glossary of terms used in this MIB:
NBMA Non-Broadcast Multi-Access
NHRP Next Hop Resolution Protocol
Internetwork layer The media-independent layer(IP in case of TCP/IP networks)
Subnetwork layer The media-dependent layer underlying the internetwork layer, including the NBMA technology
NHC Next Hop Client - An entity which initiates NHRP requests of various types to obtain access to NHRP service.
NHS Next Hop Server - An entity providing the NHRP service within the NBMA cloud.
NHRC Next Hop Registration Client - An entity which initiates NHRP registration requests.
NHRS Next Hop Registration Server - An entity for which an NHRP registration request is destined.
NHP Next Hop Peer - Any two NHRP entities in an NBMA network which are not related by an NHRS-NHRC relationship(either of them has not registered with the other) are NHPs to each other.
Client Unless explicitly stated or obvious from context, a client refers to an NHC
Server Unless explicitly stated or obvious from context, a server refers to an NHS
Station A station refers to a host or router which contains an NHRP entity(NHC/NHS)
NHRC and NHRS are relevant to a client server model based on registrations alone, in which NHRC is a client and NHRS is a server.
In case the use of any term is not clear from context or not explicitly stated, they mean the same as in RFC 2332 and RFC 2677.
REFERENCE:
[1] RFC 2332 - NBMA Next Hop Resolution Protocol (NHRP) [2] RFC 2677 - Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)
Main OID:
ciscoNhrpExtMIB.1.3.6.1.4.1.9.9.680
26
Objects
Active
Status
6
Dependencies
Imported Objects
Objects
26 total| Object Name |
|---|
ciscoNhrpExtMIBThis MIB module is an extension of the NHRP MIB module as
defined in RFC 2677. It defines notifications associated with
critical events in the Next Hop Resolution Protocol, NHRP, as
defined in RFC 2332. This module also contains information about
Cisco proprietary enhancements to the protocol.
Glossary of terms used in this MIB:
NBMA Non-Broadcast Multi-Access
NHRP Next Hop Resolution Protocol
Internetwork layer The media-independent layer(IP in case
of TCP/IP networks)
Subnetwork layer The media-dependent layer underlying
the internetwork layer, including the
NBMA technology
NHC Next Hop Client - An entity which
initiates NHRP requests of various
types to obtain access to NHRP service.
NHS Next Hop Server - An entity providing
the NHRP service within the NBMA cloud.
NHRC Next Hop Registration Client - An
entity which initiates NHRP
registration requests.
NHRS Next Hop Registration Server - An
entity for which an NHRP registration
request is destined.
NHP Next Hop Peer - Any two NHRP entities in
an NBMA network which are not related by
an NHRS-NHRC relationship(either of them
has not registered with the other) are
NHPs to each other.
Client Unless explicitly stated or obvious
from context, a client refers to an NHC
Server Unless explicitly stated or obvious
from context, a server refers to an NHS
Station A station refers to a host or router
which contains an NHRP entity(NHC/NHS)
NHRC and NHRS are relevant to a client server model based on
registrations alone, in which NHRC is a client and NHRS is a
server.
In case the use of any term is not clear from context or not
explicitly stated, they mean the same as in RFC 2332 and
RFC 2677.
REFERENCE:
[1] RFC 2332 - NBMA Next Hop Resolution Protocol (NHRP)
[2] RFC 2677 - Definitions of Managed Objects for the NBMA
Next Hop Resolution Protocol (NHRP) MODULE-IDENTITY .1.3.6.1.4.1.9.9.680 |
cneNotifs OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.680.0 |
cneNotifNextHopRegServerUpThis notification signifies that the SNMP entity, acting as an
agent, has detected that one of its NHRP entities, acting as an
NHRC, has successfully registered with an NHRS to which it was
not already registered. NOTIFICATION-TYPE .1.3.6.1.4.1.9.9.680.0.1 |
cneNotifNextHopRegServerDownThis notification signifies that the SNMP entity, acting as an
agent, has detected that that one of its NHRP entities, acting
as a NHRC, has detected(by repeated registration retries or
learnt from some other source(e.g. from a lower layer protocol))
that the NHRS it was registered to, or was trying to register
to, is operationally down(from the NHRC's perspective).
This notification doesn't indicate that the concerned NHRP
server is down or unreachable or not even that it is unable to
provide (other)NHRP services. It just indicates that the NHRC
couldn't register successfully with the NHRS.
This notification will be be sent only once for a down event
i.e. two consecutive cneNotifNextHopRegServerDown notifications
(for the same NHRS) must always be interspersed by a
cneNotifNextHopRegServerUp notification(for the same NHRS). NOTIFICATION-TYPE .1.3.6.1.4.1.9.9.680.0.2 |
cneNotifNextHopRegClientUpThis notification signifies that the SNMP entity, acting as an
agent, has detected that one of its NHRP entities, acting as an
NHRS perceives that an NHRP entity(an NHRC), which was not
already registered, has just now successfully registered. NOTIFICATION-TYPE .1.3.6.1.4.1.9.9.680.0.3 |
cneNotifNextHopRegClientDownThis notification signifies that the SNMP entity, acting as an
agent, has detected that one of its NHRP entities, acting as an
NHRS perceives that an NHRP entity, acting as an NHRC, is no
more registered or failed to register.
This notification will be be sent only once for a down event
i.e. two consecutive cneNotifNextHopRegClientDown notifications
(for the same NHRC) must always be interspersed by a
cneNotifNextHopRegclientUp notification(for the same NHRC). NOTIFICATION-TYPE .1.3.6.1.4.1.9.9.680.0.4 |
cneNotifNextHopPeerUpThis notification signifies that the SNMP entity, acting as an
agent, has detected that one of its NHRP entities perceives that
it has learnt the protocol-to-NBMA address binding information
for an NBMA next hop(which it didn't have). An NHRP entity might
learn the same address binding information for a next hop peer
as part of multiple address resolutions; this notification
should be sent only when it first learns this address binding
information. NOTIFICATION-TYPE .1.3.6.1.4.1.9.9.680.0.5 |
cneNotifNextHopPeerDownThis notification signifies that the SNMP entity, acting as an
agent, has detected that one of its NHRP entities perceives that
it has lost the protocol-to-NBMA address binding information for
an NBMA next hop(which it earlier had).
An NHRP entity might maintain multiple cache entries, with the
same address binding information, for the same next hop peer
(corresponding to different destinations reachable via this next
hop peer); This notification will be be sent only when the
address binding information is lost meaning only when all such
entries are deleted.
This notification will be be sent only once for a 'down' event
i.e. two consecutive cneNotifNextHopPeerDown notifications
(for the same NHP) must always be interspersed by a
cneNotifNextHopUp notification(for the same NHP). NOTIFICATION-TYPE .1.3.6.1.4.1.9.9.680.0.6 |
cneNotifRateLimitExceededThis notification signifies that the
SNMP entity, acting in an agent role, has detected that one of
its NHRP entities(identified by the ifIndex) has been very
frequently reaching the threshold on the rate of NHRP protocol
messages exchanged in an NBMA network. It is left to each
individual implementation to determine the threshold frequency
of this event(threshold being reached on the rate of NHRP
protocol messages exchanged) which should result in a
notification.
The ifIndex object in this notification represents the use of a
generic ifIndex which reflects a specific NBMA subnetwork
related interface as determined by an implementation. NOTIFICATION-TYPE .1.3.6.1.4.1.9.9.680.0.7 |
cneObjects OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.680.1 |
cneGeneralObjects OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.680.1.1 |
cneNextHopDownReasonThis object represents the reason for the NHRP entity to
declare a next hop(NHRS or NHRC or NHP) as down.ro CiscoNextHopDownReasonCode .1.3.6.1.4.1.9.9.680.1.1.1 |
cneNHRPExceptionThis object represents the error code associated with the
protocol message exchange for the error notification
generated.ro CiscoNhrpErrorCode .1.3.6.1.4.1.9.9.680.1.1.2 |
cneClientObjects OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.680.1.2 |
cneClientStatExtTableThis table extends nhrpClientStatTable to provide additional
statistics related to NHRP clients. SEQUENCE OF CneClientStatExtEntry .1.3.6.1.4.1.9.9.680.1.2.1 |
cneClientStatExtEntryEach entry represents a conceptual row in cneClientStatExtTable
table and provides additional statistics related to an NHRP
client. CneClientStatExtEntry .1.3.6.1.4.1.9.9.680.1.2.1.1 |
cneClientStatRedirectRxThis object represents the number of NHRP Redirects received
by the client.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, at NHRP Client
re-initialization and at other times as indicated by the value
of nhrpClientStatDiscontinuityTime.ro Counter32 .1.3.6.1.4.1.9.9.680.1.2.1.1.1 |
cneServerObjects OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.680.1.3 |
cneServerStatExtTableThis table extends nhrpServerStatTable to provide additional
statistics related to NHRP servers. SEQUENCE OF CneServerStatExtEntry .1.3.6.1.4.1.9.9.680.1.3.1 |
cneServerStatExtEntryEach entry represents a conceptual row in cneServerStatExtTable
table and provides additional statistics related to an NHRP
server. CneServerStatExtEntry .1.3.6.1.4.1.9.9.680.1.3.1.1 |
cneServerStatRedirectTxThis object represents the number of NHRP Redirects sent by
the server.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, at NHRP Client
re-initialization and at other times as indicated by the value
of nhrpServerStatDiscontinuityTime.ro Counter32 .1.3.6.1.4.1.9.9.680.1.3.1.1.1 |
cneNotificationControlObjects OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.680.1.4 |
cneNotifEnableThis object is used to control the generation of notifications
defined in this MIB. The bits when set to 1 or 0 respectively
enable or disable the corresponding notification. The mapping
between the bits and the notifications are as follows.
nextHopRegServerUp(0): This bit enables/disables the
cneNotifNextHopRegServerUp
notification.
nextHopRegServerDown(1): This bit enables/disables the
cneNotifNextHopRegServerDown
notification.
nextHopRegClientUp(2): This bit enables/disables the
cneNotifNextHopRegClientUp
notification.
nextHopRegClientDown(3): This bit enables/disables the
cneNotifNextHopRegClientDown
notification.
nextHopPeerUp(4): This bit enables/disables the
cneNotifNextHopPeerUp notification.
nextHopPeerDown(5): This bit enables/disables the
cneNotifNextHopPeerDown notification.
rateLimitExceeded(6): This bit enables/disables the
cneNotifRateLimitExceeded
notification.rw Bits .1.3.6.1.4.1.9.9.680.1.4.1 |
cneConform OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.680.2 |
cneCompliances OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.680.2.1 |
cneGroups OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.680.2.2 |
More MIBs from Cisco
Browse all CiscoMIBs →CISCO-ENTITY-VENDORTYPE-OID-MIB
The CISCO-ENTITY-VENDORTYPE-OID-MIB maps Cisco-specific hardware component identifiers to the ENTITY-MIB's entPhysicalTable, enabling precise differentiation of physical device types such as line cards, power supplies, and fans within Cisco infrastructure. This mapping ensures that SNMP management systems can accurately correlate physical inventory entries with vendor-specific component definitions for accurate device discovery and monitoring.
7820 objects→
CISCO-UNIFIED-COMPUTING-EQUIPMENT-MIB
The CISCO-UNIFIED-COMPUTING-EQUIPMENT-MIB provides SNMP-based monitoring and management of Cisco Unified Computing System (UCS) hardware components, including chassis, blades, fabric interconnects, and power supplies. It exposes critical operational metrics such as device status, port states, temperature readings, fan speeds, and power consumption data for infrastructure health assessment.
3349 objects→
CISCO-UNIFIED-COMPUTING-ADAPTOR-MIB
The CISCO-UNIFIED-COMPUTING-ADAPTOR-MIB enables SNMP-based monitoring and management of physical and virtual network adapter interfaces, including link status, traffic counters, error statistics, and port configuration parameters, within the Cisco Unified Computing System (UCS) fabric interconnects and blade servers.
2840 objects→
CISCO-UNIFIED-COMPUTING-TC-MIB
The CISCO-UNIFIED-COMPUTING-TC-MIB module defines standard textual conventions and data type definitions required for monitoring Cisco Unified Computing System (UCS) hardware components, including server blades, fabric interconnects, and chassis resources. These definitions enable consistent interpretation of specific UCS metrics such as power supply status, fan speeds, thermal readings, and port utilization across SNMP management applications.
2614 objects→
CISCO-UNIFIED-COMPUTING-FABRIC-MIB
The CISCO-UNIFIED-COMPUTING-FABRIC-MIB enables SNMP-based monitoring and management of the Cisco UCS Fabric Interconnects and associated fabric switching infrastructure, exposing metrics for port states, link utilization, error counters, and fabric topology status. It facilitates granular visibility into the physical and logical fabric layers, including uplink/downlink interfaces, VLAN configurations, and fabric failover conditions within the unified computing environment.
2407 objects→
STARENT-MIB
The STARENT-MIB module provides SNMP management and monitoring capabilities for Cisco ASR 5000 and ASR 5500 multimedia core platforms, specifically exposing metrics related to 2G/3G/4G and WiFi subscriber sessions, inline service states, and carrier-class high-availability status.
2194 objects→