First off, apologies for what will be a lengthy post, but I wanted to include
as much background as possible to help with a potential answer.
When we were running net-snmp version 5.2.5.1 (on an embedded Linux system) we
encountered a customer that complained that their SNMP poller was complaining
of “unknown” interfaces from the SNMP results we were returning. After some
research I realized that there were problems with the interfaces being returned
when PPPoE connections are used. PPPoE connections seem to get assigned a new
IP address relatively frequently (compared to DHCP). I can easily recreate this
by just killing the running pppd daemon. When I do that the new IP address
assigned to the ppp0 interface is returned by ipAdEntIfIndex with an index
number that has increased by one. However, the values returned by ifNumber,
ifDescr, ifIndex, etc all remain the same. Therefore ipAdEntIfIndex is using an
index number that references an interface that does not exist.
I studied the SNMP code and fixed it by modifying the
netsnmp_access_interface_ioctl_ifindex_get() function. Instead of just
returning ifrq.ifr_ifindex, I compare that value to what the
Interface_Index_By_Name() function would return for that interface. If they
don't match then I force the correct value to be returned. I added the code in
“NEW_CODE”.
DEBUGMSGTL(("access:interface:ioctl", "ifindex_get\n"));
rc = _ioctl_get(fd, SIOCGIFINDEX, &ifrq, name);
if (rc < 0) {
DEBUGMSGTL(("access:interface:ioctl",
"ifindex_get error on inerface '%s'\n", name));
return 0;
}
#ifdef NEW_CODE
returnValue = ifrq.ifr_ifindex;
if (NULL != strstr(name, "ppp"))
{
foundIndex = Interface_Index_By_Name(name, sizeof(name));
if (foundIndex != returnValue && foundIndex > 0)
{
snmp_log(LOG_DEBUG, "%s %d would have returned [%s] iface index %d but will
use %d.\n",
__func__, __LINE__, name, returnValue, foundIndex);
returnValue = foundIndex;
}
}
#endif
That worked great and then customer was happy. Later we updated to net-snmp
version 5.5.1. I noticed that this area of code was completely different and
that snmpd was acting differently in this scenario. When I bounce the pppd
daemon snmpd will temporarily report two different ppp0 interfaces, even though
the /proc/net/dev file shows only one instance of ppp0. The newer instance has
an index value of one more than the old instance.
IF-MIB::ifDescr.15 = STRING: eth0.2222
IF-MIB::ifDescr.16 = STRING: eth0.3030
IF-MIB::ifDescr.19 = STRING: ppp0
IF-MIB::ifDescr.20 = STRING: ppp0
IF-MIB::ifNumber.0 = INTEGER: 18
# cat dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets
errs drop fifo colls carrier compressed
lo: 42034 429 0 0 0 0 0 0 42034 429 0 0 0 0 0 0
teql0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
tunl0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
gre0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
eth0: 928024 5397 0 0 0 0 0 0 2323119 5846 0 0 0 0 0 0
eth1: 1630819 2335 0 9 0 0 0 0 350976 2319 0 0 0 0 0 0
ipsec0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ipsec1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ipsec2: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ipsec3: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
mast0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
eth0.4069: 852516 5398 0 0 0 0 0 0 2318569 5803 0 0 0 0 0 0
eth0.666: 0 0 0 0 0 0 0 0 1572 14 0 0 0 0 0 0
eth0.888: 0 0 0 0 0 0 0 0 498 5 0 0 0 0 0 0
eth0.2222: 0 0 0 0 0 0 0 0 1532 14 0 0 0 0 0 0
eth0.3030: 0 0 0 0 0 0 0 0 498 5 0 0 0 0 0 0
ppp0: 5636 31 0 0 0 0 0 0 7856 36 0 0 0 0 0 0
After a few minutes the 'old' ppp0 will disappear in the SNMP results
returned. As this process repeats the index value for ppp0 keeps getting higher
and higher. However, ipAdEntIfIndex and all of the interface stats (ifNumber,
ifDescr, ifIndex, etc) all consistently refer to the current new value.
IF-MIB::ifDescr.15 = STRING: eth0.2222
IF-MIB::ifDescr.16 = STRING: eth0.3030
IF-MIB::ifDescr.20 = STRING: ppp0
IF-MIB::ifNumber.0 = INTEGER: 17
I decided to keep this code the way it was since testing with the customer
showed that their tool was fine with this behavior.
Unfortunately now I have a completely different customer with a similar
complaint. Their netflow tool (which creates reports based on SNMP polling
results) is complaining about “unmanaged” interfaces. I strongly suspect this
is being caused by ppp0's continuously increasing index numbers. Can you
provide any insight as to why this is happening, or better yet how to stop it?
I did recently find an old bug report ([ net-snmp-Bugs-1238857 ] ipAdEntIfIndex
out of sync with ifIndex) that suggests compiling with “--enable-mfd-rewrites”,
but that didn't change anything for me.
Thank you
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
