0

With respect to Juniper MX , can someone please explain what services does mib2d provide? There are many processes running on the Juniper MX depending on the services configured. These processes can be observed by running the command 'show system services extensive'. The well known services are rpd , l2ald , snmpd and mib2d.

What we observe that some monitoring system was sending too many SNMP queries to the MX resulting in increasing CPU Utilization. The top process that was contributing to high CPU Utilization was observed to be mib2d. Of course snmpd was also high but not like mib2d.

In the second scenario , we observed that there was excessive interface flapping. As a result MX KPI's were high. Again when we ran the command 'show system process extensive' , the top process was mib2d.

Hence the question becomes what services does mib2d provide? Is it related to snmp or physical interfaces?

This is required to know from the troubleshooting perspective because in case box CPU Utilization goes high and top process is mib2d , how can we know what is causing mib2d to go high? Is it only snmp & interfaces ? Or there are other services also?

Many Thanks !!!

1
  • As the name implies, it's the sub-agent handling the ISO MIB-2 portion of the tree. If you drop to the FreeBSD shell, you may be able to see it in the snmpd.conf file.
    – Ricky
    Oct 13 at 21:35
2

First, some context - snmpd isn't the only process involved in facilitating SNMP requests. It uses other processes as sub-agents to get data relevant to the particular statistic you're gathering. For example, if you are collecting RIB information, snmpd will talk to rpd to get the necessary data.

mib2d has a similar function except in this case it has two primary responsibilities.

  1. Assign SNMP index values to interfaces.
  2. Gather interface statistics and state from the kernel for snmpd.

In short, snmpd and mib2d work together to get interface data for SNMP.

SNMP is a very old protocol whose limitations have been known for over a decade. Lots of things can contribute to why you're seeing higher CPU. Most of these aren't even a vendor specific problem.

  1. Hardware platform.
  2. Software version.
  3. The polling interval - I'd keep interface polls to 5 minutes at the absolute fastest. If you have multiple polling stations, make it more like 10 minutes.
  4. The number of interfaces you're polling on each iteration - I've seen issues polling the ifMib when there are 10k+ subscriber interfaces on the device, this doesn't scale in just about any scenario. You can filter interfaces that you may not be interested in using set snmp filter-interfaces ....
  5. Polling method (i.e. snmpwalk vs. snmpbulkwalk) - You can find some more context about this here.

Frankly, there are more things to consider than this as well. My general recommendation is to move away from SNMP where possible (to streaming telemetry) or take time to finely tune your monitoring systems.

3
  • Thank you for the detailed answer. You mentioned that mib2d gathers interface statistics. We also observe mib2d going high during excessive interface flapping. Hence can we say that mib2d is directly related with interfaces. Can we assume this that If mi2bd goes high , there could be two possibilities , its the snmp server flooding the queries causing mib2d to work harder or it could be interface flapping? Oct 14 at 22:50
  • There are a lot of variables I’d need to understand to give you an authoritative answer, and this isn’t really the forum for that. However, both SNMP queries and interface flaps can cause mib2d utilization to go up. Oct 15 at 3:08
  • Thank you for the clarification. Oct 15 at 5:45
0

Can't really say for Juniper MX, but MIB generally refers to the management information base, the database you query via SNMP. mib2d is surely (at least part of) the SNMP daemon.

Instead of using extensive SNMP queries - polling - you should consider using SNMP traps more actively. That can significantly decrease CPU load. It's generally more efficient as it only transmits data when required and also enables the monitoring system to react more quickly.

So, instead of polling critical parameters every minute, you could slow down polling to maybe ten or fifteen minutes, and set up traps for critical thresholds - that would even speed up reaction time overall.

3
  • We mentioned snmp case to illustrate the mib2d daemon and to understand its nature. Definitely too much snmp would cause CPU to increase. We need to understand mib2d. Oct 13 at 8:58
  • Likely, you'd need to catalogue your SNMP queries and then reduce selected portions to see what the impact is/was. Even if you can gain considerable insight into the service daemon (which is somewhat unlikely, given that it's proprietary), it's usually rather hard to theorize the practical impact.
    – Zac67
    Oct 13 at 10:43
  • ... to theorize the practical impact of a given query.
    – Zac67
    Oct 13 at 11:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.