I can add some more insight to my original question.
After the first time I bounce the PPPoE daemon snmpd (version 5.5.1) returns
two ppp0 interfaces. After a few minutes the first one will disappear. Before
that could happen I decided to restart snmpd to see what it would return.
IF-MIB::ifIndex.15 = INTEGER: 15
IF-MIB::ifIndex.16 = INTEGER: 16
IF-MIB::ifIndex.17 = INTEGER: 17
IF-MIB::ifIndex.18 = INTEGER: 18
IF-MIB::ifDescr.15 = STRING: eth0.2222
IF-MIB::ifDescr.16 = STRING: eth0.3030
IF-MIB::ifDescr.17 = STRING: ppp0
IF-MIB::ifDescr.18 = STRING: ppp0
Restart snmpd at this point.
IF-MIB::ifIndex.15 = INTEGER: 15
IF-MIB::ifIndex.16 = INTEGER: 16
IF-MIB::ifIndex.18 = INTEGER: 18
IF-MIB::ifDescr.15 = STRING: eth0.2222
IF-MIB::ifDescr.16 = STRING: eth0.3030
IF-MIB::ifDescr.18 = STRING: ppp0
ppp0's index is 18 at this point and there is no longer an index 17.
Can you provide any insight as to why this is happening, or better yet how to
stop it?
Thank you.
---- On Tue, 05 Jun 2012 12:02:48 -0700 christopher.wu
<christopher...@zoho.com> wrote ----
>
> 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
