You can configure the appliance as an SNMP-managed device so that an SNMP management station can send queries to the appliance and retrieve information from its MIBs. Note that you can download all Infoblox MIBs from Multi-Grid Manager, including MIBs that are specific to DNS and DHCP operations. Perform the following tasks to access the Infoblox MIBs:

1. Configure the appliance to accept queries, as described in Configuring SNMPv3 Users, see /wiki/spaces/mgmadminguide/pages/911186046.
2. Load the MIB files onto the management system. To obtain the latest Infoblox MIB files:
   1. From the Master Grid tab, select the Members tab -> master_grid_member checkbox, and then select Download -> SNMP MIBs from the Toolbar.
   2. In the Save As dialog box, navigate to a directory to which you want to save the MIBs.
   3. Click Save.
3. Use a MIB browser or SNMP management application to query the objects in each MIB.

The appliance allows read-only access to the MIBs. This is equivalent to the Get and Get Next operations in SNMP.

Loading the Infoblox MIBs

If you are using an SNMP manager toolkit with strict dependency checking, you must download the following Infoblox MIBs in the order they are listed:

1. IB-SMI-MIB.txt
2. IB-TRAP-MIB.txt
3. IB-PLATFORMONE-MIB.txt
4. IB-DNSONE-MIB.txt
5. IB-DHCPONE-MIB.txt

In addition, if the SNMP manager toolkit you use requires a different MIB file naming convention, you can rename the MIB files accordingly.

NET-SNMP MIBs

Infoblox appliances support NET-SNMP (formerly UCD-SNMP), a collection of applications used to implement the SNMP protocol. The NET-SNMP MIBs provide the top-level infrastructure for the SNMP MIB tree. They define, among other things, the objects in the SNMP traps that the agent sends when the SNMP engine starts and stops. For information about NET-SNMP and the MIB files distributed with NET-SNMP, refer to http://net-snmp.sourceforge.net/.

For SNMP traps to function probably, you must download the following NET-SNMP MIBs directly from http://net-snmp.sourceforge.net/docs/mibs/:

• NET-SNMP-MIB
• UCD-SNMP-MIB

---

Note: Ensure that you save the MIBs as text files in the directory to which you save all the other MIB files.

---

BGP4 MIB

Infoblox supports BGP4 (Border Gateway Protocol) for DNS anycast addressing. BGP is configured to send SNMP traps to neighboring routers, as defined in RFC4273 Definitions of Managed Objects for BGP-4. You must enable and configure the SNMP trap receiver on the Multi-Grid member for the member to send SNMP traps. For information, see /wiki/spaces/mgmadminguide/pages/911186298.
The BGP protocol service is configured to send SNMP queries about BGP runtime data. The information is returned using the following OIDs and definitions:

For each configured BGP peer (a, b, c, d), the information is returned using the following OIDs and definitions:

ibTrap MIB

Infoblox appliances send SNMP traps when events, internal process failures, or critical service failures occur. The ibTrap MIB defines the types of traps that the appliance sends and the value that each MIB object represents. The Infoblox SNMP traps report objects which the ibTrap MIB defines. 

---

Note: OIDs shown in the illustrations and tables in this section do not include the prefix .1.3.6.1.4.1.7779.

---

The ibTrap MIB comprises two trees, ibTrapOneModule and ibNotificationVarBind. The ibTraponeModule tree contains objects for the types of traps that the appliance sends. The ibNotificationVarBind tree contains objects that the Infoblox SNMP traps report. You cannot send queries for the objects in this MIB module. The objects are used only in the SNMP traps.

Figure 11.3 ibTrapOne MIB Structure

Interpreting Infoblox SNMP Traps

Depending on the SNMP management application your management system uses, the SNMP traps you receive may list the OIDs for all relevant MIB objects from both the ibTrapOneModule and ibNotificationVarBind trees. For OIDs that have string values, the trap lists the text. For OIDs that contain integers, you can use the tables in this section to find out the values. Some SNMP management applications list only the object names and their corresponding values in the SNMP traps. Whether or not your SNMP management application lists OIDs, you can use the tables in this section to find out the corresponding value and definition for each MIB object.
The following is a sample trap the appliance sends:

418:Jan 31 18:52:26 (none) snmptrapd[6087]: 2008-01-31 18:52:26 10.35.1.156 [UDP:
[10.35.1.156]:32772]: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1080)
0:00:10.80 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.7779.3.1.1.1.1.4.0
SNMPv2-SMI::enterprises.7779.3.1.1.1.2.1.0 = STRING: "10.35.1.156"
SNMPv2-SMI::enterprises.
7779.3.1.1.1.2.3.0 = STRING: "ntp_sync" SNMPv2-SMI::enterprises.7779.3.1.1.1.2.9.0 =
INTEGER: 15 SNMPv2-SMI::enterprises.7779.3.1.1.1.2.10.0 = INTEGER: 16
SNMPv2-SMI::enterprises.7779.3.1.1.1.2.11.0 = STRING: "The NTP service is out of
synchronization."

The sample trap lists the OIDs and their corresponding values that can help you identify the cause of an event or problem. To identify the possible cause and recommended actions for the trap, use the ibTrapDesc tables. For information, see table ibTrapDesc (OID 3.1.1.1.2.11.0).
You can interpret the sample trap as follows:
Using the ibTrapOneModule table, you find out OID 7779.3.1.1.1.1.4.0 represents an Object State Change trap. This trap includes the following objects: ibNodeName, ibOjectName, ibPreviousState, ibCurrentState, and ibtrapDesc. For each object, the trap displays the OID and its corresponding value. The following is how you can interpret the rest of the trap:

• ibNodeName (OID 7779.3.1.1.1.2.1.0)
  • Using the table, you find out OID 7779.3.1.1.1.2.1.0 represents the MIB object ibNodeName, which is the IP address of the appliance on which the trap occurred. Therefore, the statement "7779.3.1.1.1.2.1.0 = STRING: "10.35.1.156" SNMPv2-SMI::enterprises." tells you the IP address of the appliance on which the trap occurred.
• ibObjectName (OID 7779.3.1.1.1.2.3.0)
  • The statement "7779.3.1.1.1.2.3.0 = STRING: "ntp_sync" SNMPv2-SMI::enterprises." tells you the MIB object ibOjectName, which is the name of the object for which the trap was generated, has a value of "ntp_sync" that indicates NTP synchronization issues.
• ibPreviousState (OID 7779.3.1.1.1.2.9.0)
  • The statement "7779.3.1.1.1.2.9.0 = INTEGER: 15 SNMPv2-SMI::enterprises." tells you the MIB object ibPreviousState, which indicates the previous state of the appliance, has a value of 15. Using the table, you know that 15 represents "ntp-sync-up", which means the NTP server was up and running.
• ibCurrentState (OID 7779.3.1.1.1.2.10.0)
  • The statement "7779.3.1.1.1.2.10.0 = INTEGER: 16 SNMPv2-SMI::enterprises." tells you the MIB object ibCurrentState, which indicates the current state of the appliance, has a value of 16. Using the table, you know that 16 represents "ntp-sync-down", which means the NTP server is now out of sync.
• ibTrapDesc (OID 7779.3.1.1.1.2.11.0)
  • The last statement "7779.3.1.1.1.2.11.0 = STRING: "The NTP service is out of synchronization." states the description of the trap. Using the bookmark633 table for ibTrapDesc, you can find out the trap description and recommended actions for this problem.

Types of Traps (OID 3.1.1.1.1)

ibTrapOneModule defines the types of traps that the appliance can send. There are five types of SNMP traps.
The following table describe the types of traps and their objects in the ibTrapOneModule tree.

Table 11.2 ibTrapOneModule

Trap Binding Variables (OID 3.1.1.1.2)

Each SNMP trap contains information about the event or the problem. The Infoblox SNMP traps include MIB objects and their corresponding values from the ibNotificationVarBind module. 2 The following table describes the objects in the ibNotificationVarBind module.

 Table 11.3 ibNotificationVarBind (OID 3.1.1.1.2)

Note: The OIDs shown in the following table do not include the prefix ".1.3.6.1.4.1.7779.".

Trap Severity (OID 3.1.1.1.2.2.0)

The object ibTrapSeverity defines the severity level for each Infoblox SNMP trap. There are five levels of severity.

ibProbableCause Values (OID 3.1.1.1.2.4.0)

The following table lists the values that are associated with the object ibProbableCause (OID 3.1.1.1.2.4.0). These values provide information about the events, such as software failures, that trigger traps.

 Table 11.4 ibProbableCause Values

ibSubsystemName Values (OID 3.1.1.1.2.9.0)

The following table lists the values that are associated with the object ibSubsystemName (OID 3.1.1.1.2.9.0). These values provide information about the subsystems that trigger the traps.

Table 11.5 ibSubsystemName Values

ibPreviousState (OID 3.1.1.1.2.9.0) and ibCurrentState (OID 3.1.1.1.2.10.0)

The ibPreviousState object indicates the state of the appliance before the event triggered the trap. The ibCurrentState object indicates the current state of the appliance. The following table shows the message and description for each state.

Table 11.6 ibPreviousState and ibCurrentState Values

ibTrapDesc (OID 3.1.1.1.2.11.0)

The ibTrapDesc object lists the trap messages of all Infoblox SNMP traps. This section lists all the SNMP traps by their trap types. Each trap table describes the trap message, severity, cause, and recommended actions.

---

Note: Contact Infoblox Technical Support for assistance when the recommended actions do not resolve the problems.

---

Equipment Failure Traps

Processing and Software Failure Traps

Threshold Crossing Traps

Object State Change Traps

Process Started and Stopped Traps

ibPlatformOne MIB

The ibPlatformOne MIB provides information about the CPU temperature of the appliance, the replication status, the average latency of DNS requests, DNS security alerts, CPU and memory utilization of the appliance, and the Infoblox service status. The image below illustrates the structure of the PlatformOne MIB. (Note that the OIDs in the illustration do not include the prefix .1.3.6.1.4.1.7779.)
The ibPlatformOne MIB contains the following objects:

• ibCPUTemperature (IbString) tracks the CPU temperature of the appliance.
• ibClusterReplicationStatusTable provides information in tabular format about the replication status of the appliance.
• ibNetworkMonitor provides information about the average latency of authoritative and nonauthoritative replies to DNS queries for different time intervals. It also provides information about invalid DNS responses that arrive on invalid ports or have invalid DNS transaction IDs.
• ibHardwareType (IbString) provides information about the hardware platform. For an Infoblox appliance, it provides the model number of the Infoblox hardware platform. For vNIOS appliances, it identifies whether the hardware platform is Riverbed or VMware.
• ibHardwareId (IbString) provides the hardware ID of the appliance.
• ibSerialNumber (IbString) provides the serial number of the Infoblox hardware platform.
• ibNiosVersion (IbString) provides the version of the software.
• ibSystemMonitor provides information about the CPU and memory utilization of the appliance.

The ibPlatformOne MIB also contains the following tables that provide status of the Infoblox services as well as system and hardware services on the appliance you query:

• ibMemberServiceStatusTable provides status of the Infoblox services, such as the DNS and DHCP services, on a queried appliance. 
• ibMemberNode1ServiceStatusTable provides status of the system and hardware services on a queried appliance. 
• ibMemberNode2ServiceStatusTable provides status of the system and hardware services on the passive node of an HA pair if the queried appliance is the VIP or the active node of an HA pair. For independent appliances and the passive nodes of HA pairs, this table does not display any status.

 Figure 11.4 ibPlatformOne MIB Structure

ibClusterReplicationStatusTable
ibClusterRepliactionStatusTable (object ID 3.1.1.2.1.2.1) provides information about the Master Grid replication status.
The following image shows the sub branches of ibClusterReplicationStatusTable.

 Figure 11.5 ibClusterReplicationStatusTable Objects

Table 11.7 ibClusterReplicationStatusTable Objects

ibNetwork Monitor

As shown in bookmark641, the ibNetwork Monitor has one subtree, ibNetworkMonitorDNS, that branches out into the following:

• ibNetworkMonitorDNSActive (Integer) reports on whether DNS latency monitoring is enabled. This is the only object in this branch. When you send a query for this object, the appliance responds with either "active" (1) or "nonactive" (0).
• ibNetworkMonitorDNSNonAA provides information about the average latency of nonauthoritative replies to DNS queries for 1-, 5-, 15-, and 60-minute intervals. 
• ibNetworkMonitorDNSAA provides information about the average latency of authoritative replies to DNS queries for 1-, 5-, 15-, and 60-minute intervals.
• ibNetworkMonitorDNSSecurity provides information about the invalid DNS responses that arrive on invalid ports or have invalid DNS transaction IDs. ibNetworkMonitorDNSSecurity branches out into the following:
  • ibNetworkMonitorDNSSecurityInvalidPort
  • ibNetworkMonitorDNSSecurityInvalidTxid
  • ibNetworkMonitorDNSSecurityInvalidPortOnly (Counter)
    • ibNetworkMonitorDNSSecurityInvalidPortCount (Counter)
  • ibNetworkMonitorDNSSecurityInvalidTxidOnly (Counter)
    • ibNetworkMonitorDNSSecurityInvalidTxidCount (Counter)
  • ibNetworkMonitorDNSSecurityInvalidTxidAndPort (Counter)

Figure 11.6 ibNetWorkMonitor Objects

Figure 11.7 ibNetworkMonitorDNSNonAA and ibNetworkMonitorDNSAA Subtrees

The following table describes the objects in ibNetworkMonitorDNSNonAA. You can send queries to retrieve values for these objects.

 Table 11.8 ibNetworkMonitorDNSNonAA Objects

The following table describes the objects in ibNetworkMonitorDNSAA. You can send queries to retrieve values for these objects.

Table 11.9 ibNetworkMonitorDNSAA Objects

The following table describes the objects in ibNetworkMonitorDNSSecurity. You receive SNMP traps with these objects when you enable the following:

• SNMP traps
• DNS network monitoring
• DNS alert monitoring

Table 11.10 ibNetworkMonitorDNSSecurity Objects

 
The following table describes the objects in ibNetworkMonitorDNSSecurityInvalidPort.

Table 11.11 ibNetworkMonitorDNSSecurityInvalidPort Objects

The following table describes the objects in ibNetworkMonitorDNSSecurityInvalidTxid.

Table 11.12 ibNetworkMonitorDNSSecurityInvalidTxid Objects

ibSystemMonitor

As shown in , ibSystemMonitor (object ID 3.1.1.2.1.2.8) has the following subtrees:

• • ibSystemMonitorCpu: Contains ibSystemMonitorCpuUsage (Integer) that reports the CPU usage of the appliance.
  • ibSystemMonitorMem: Contains ibSystemMonitorMemUsage (Integer) that reports the memory usage of the appliance.

Figure 11.8 ibSystemMonitor Objects

ibMemberServiceStatusTable

As shown in the following image, ibMemberServiceStatusTable (object ID 3.1.1.2.1.2.9) has one subtree, ibMemberServiceStatusEntry, which contains the following objects:

• ibServiceName (String) reports the names of the Infoblox services. 
• ibServiceStatus (Integer) reports the status of the Infoblox services.
• ibServiceDesc (String) describes the details of the status.

ibMemberServiceStatusTable displays the current status of the Infoblox services on the appliance that you query. For an HA pair, this table displays the service status of the active node. If the appliance you query is the passive node of an HA pair, this table reflects the service status of the passive node, which can be "inactive" or "unknown."
You can also query ibMemberNode1ServiceStatusTable and ibMemberNode2ServiceStatusTable that display system and hardware status on the queried appliance.

 Figure 11.9 ibMemberServiceStatusTable Objects

 Service Status
When you query the service status on an appliance, the response includes the status of the services. The following table shows the values and descriptions of the status. Note that for internal Master Grid operations, the NTP service is always in the "working" state even if it has been disabled through the Infoblox GUI.

Table 11.13 ibServiceStates Values

System and Hardware Service Names
The following table lists the values and descriptions of the system and hardware services that appear in ibMemberServiceStatusTable, ibMemberNode1ServiceStatusTable, and ibMemberNode2ServiceStatusTable.

Table 11.14 Values of ibServiceNames

ibMemberNode1ServiceStatusTable

As shown in , ibMemberNode1ServiceStatusTable (object ID 3.1.1.2.1.2.10) has one subtree, ibMemberNode1ServiceStatusEntry, which contains the following objects:

• ibMemberNode1ServiceName (String) reports the names of the system and hardware services.
• ibMemberNode1ServiceStatus (Integer) reports the status of the services.
• ibMemberNode1ServiceDesc (String) describes the details of the status.

ibMemberNode1ServiceStatusTable displays the current status of the system and hardware services on the appliance that you query. For example, when you query an independent appliance, this table shows the information about the independent appliance. When you query the VIP of an HA pair, this table shows the information about the active node. For the active node of the HA pair, you can also query ibMemberNode2StatusTable to get the status of the passive node.

---

Note: For an independent appliance and the passive node of an HA pair, no information is returned when you query ibMemberNode2ServiceStatusTable.

---

Figure 11.10 ibMemberNode1ServiceStatusTable Objects

ibMemberNode2ServiceStatusTable

As shown in , ibMemberNode2ServiceStatusTable (object ID 3.1.1.2.1.2.11) has one subtree, ibMemberNode2ServiceStatusEntry, which contains the following objects:

• ibMemberNode2ServiceName (String) reports the names of the system and hardware services. For a list of service names, see .
• ibMemberNode2ServiceStatus (Integer) reports the status of the services.
• ibMemberNode2ServiceDesc (String) describes details of the status.

ibMemberNode2ServiceStatusTable displays the current status of the system and hardware services on the passive node of an HA pair when you query the VIP of the HA pair. For independent appliances and the passive nodes of HA pairs, this table does not display any status.

Figure 11.11 ibMemberNode2ServiceStatusTable Objects

ibDHCPOne MIB

The ibDHCPOne MIB provides information about address usage within a subnet, DHCP lease statistics, and DHCP packet counts. It includes two modules, ibDHCPModule for IPv4 data and ibDHCPv6Module for IPv6 data.

ibDHCPModule

The following image illustrates the structure of the ibDHCPModule. (Note that the OIDs shown in the illustration do not include the prefix .1.3.6.1.4.1.7779.) ibDHCPModule contains the following objects:

• ibDHCPSubnetTable provides statistical data about the DHCP operations of the appliance.

• ibDHCPStatistics maintains counters for different types of packets.
• ibDHCPDeferredQueuesize tracks the total number of deferred DDNS updates that are currently in the queue to be retried. When DDNS updates are deferred due to timeout or server issues, the DHCP server puts these updates in this queue.
• ibDHCPDDNSStats monitors the average latency for the DDNS updates in microseconds and the number of timeouts during different time intervals.

Figure 11.12 ibDHCPModule

ibDHCPSubnetTable
ibDHCPSubnetTable provides statistical data about the DHCP operations of the appliance. It contains the following objects:

Table 11.15 ibDHCPSubnetTable

Following is an example of the table as viewed through a MIB browser:

Figure 11.13 MIB Browser View 1

ibDHCPStatistics

ibDHCPStatistics maintains counters for different types of packets. The counters always start with zero when the DHCP service is restarted. Therefore, the numbers reflect the total number of packets received since the DHCP service was last restarted on the appliance. The ibDHCPStatistics module contains the following objects:

Table 11.16 ibDHCPStatistics

ibDHCPDDNSStats

ibDHCPDDNSStats monitors the average latency for the DHCP DDNS updates in microseconds and the number of timeouts during different time intervals. The ibDHCPDDNSStats module contains the following objects:

Table 11.17 ibDHCPStatistics

 ibDHCPv6Module

The following emage illustrates the structure of the ibDHCPv6Module, which contains the following objects:

• ibDHCPv6SubnetTable provides statistical data about the DHCPv6 operations of the appliance.
• ibDHCPv6Statistics maintains counters for different types of packets. 
• ibDHCPv6DeferredQueuesize tracks the total number of deferred DDNS updates that are currently in the queue to be retried. When DDNS updates are deferred due to timeout or server issues, the DHCP server puts these updates in this queue.
• ibDHCPv6DDNSStats monitors the average latency for the DDNS updates in microseconds and the number of timeouts during different time intervals.

Figure 11.14 ibDHCPv6Module

 ibDHCPv6SubnetTable
ibDHCPSubnetTable provides statistical data about the DHCPv6 operations of the appliance. It contains the following objects:

Table 11.18 ibDHCPSubnetTable

ibDHCPv6Statistics

ibDHCPv6Statistics maintains counters for different types of packets. The counters always start with zero when the DHCP service is restarted. Therefore, the numbers reflect the total number of packets received since the DHCP service was last restarted on the appliance. The ibDHCPv6Statistics module contains the following objects:

Table 11.19 ibDHCPv6Statistics

ibDHCPv6DDNSStats

ibDHCPv6DDNSStats monitors the average latency for the DHCPv6 DDNS updates in microseconds and the number of timeouts during different time intervals. The ibDHCPv6DDNSStats module contains the following objects:

Table 11.20 ibDHCPStatistics

ibDNSOne MIB

The ibDNSOne MIB provides statistical information about the DNS processes and about the views and zones in the database. The following image illustrates the structure of the ibDNSOne MIB. (Note that the OIDs shown in the illustration do not include the prefix 1.3.6.1.4.1.7779.) The ibDNSOne MIB contains four subtrees, ibZoneStatisticsTable, ibZonePlusViewStatisticsTable, ibDDNSUpdateStatistics, and ibBindZoneTransferCount (Counter64).

Figure 11.15 ibDNSOne MIB

ibZoneStatisticsTable
ibZoneStatisticsTable provides statistical data about the DNS operations on the appliance. The syntax of these objects uses a Counter64 format. In some cases, the counter format may not be compatible with SNMP toolkits that use a 32-bit counter. Ensure that you reconfigure or update these tools to use the Counter64 format.
ibZoneStatisticsTable contains the following objects:

Table 11.21 ibZoneStatisticsTable

ibZonePlusViewStatisticsTable

ibZonePlusViewStatisticsTable provides statistical data about DNS views and their zones. It contains the following objects:

Table 11.22 ibZonePlusViewStatisticsTable

Following is an example of the table as viewed through a MIB browser:

Figure 11.16 MIB Browser View

ibDDNSUpdateStatistics

ibDDNSUpdateStatistics provides statistical data about DDNS updates. The counters always start with zero when the DNS service is restarted. They report the total numbers since the DNS service was last restarted.
ibDDNSUpdateStatistics contains the following objects:

Table 11.23 ibDDNSUpdateStatistics

ibBindZoneTransferCount

ibBindZoneTransferCount (Counter64) provides the total number of successful zone transfers from an Infoblox primary or secondary DNS server to a DNS client, since the DNS service was last restarted. Note that this counter tracks the number of successful full zone transfers (AXFRs) and incremental zone transfers (IXFRs).