On Wed, 23 Nov 2005 23:29:39 +0100 [EMAIL PROTECTED] wrote: SO> The internet connection is via dsl PPP, sometimes the link SO> disconnect and then reconnect automatically. We also have some SO> OpenVPN tunnels that sometimes disconnect/reconnect. SO> SO> This unfortunately leave snmpd whith a bad idea of interfaces SO> available on the system: SO> SO> # snmpwalk -c public -v1 127.0.0.1 | grep ifName SO> IF-MIB::ifName.1 = STRING: lo SO> IF-MIB::ifName.2 = STRING: eth0 SO> IF-MIB::ifName.3 = STRING: eth1 SO> IF-MIB::ifName.4 = STRING: ppp0 SO> IF-MIB::ifName.5 = STRING: tun1 SO> IF-MIB::ifName.8 = STRING: tun2 SO> IF-MIB::ifName.9 = STRING: ppp0 SO> IF-MIB::ifName.10 = STRING: ppp0 SO> IF-MIB::ifName.11 = STRING: ppp0 SO> IF-MIB::ifName.12 = STRING: tun2
I've been waiting for this message. What release are you using? SO> To solve the problem I have to restart snmpd. What happens after you restart snmpd? Do you get IF-MIB::ifName.1 = STRING: lo IF-MIB::ifName.2 = STRING: eth0 IF-MIB::ifName.3 = STRING: eth1 IF-MIB::ifName.4 = STRING: ppp0 IF-MIB::ifName.5 = STRING: tun1 IF-MIB::ifName.8 = STRING: tun2 or IF-MIB::ifName.1 = STRING: lo IF-MIB::ifName.2 = STRING: eth0 IF-MIB::ifName.3 = STRING: eth1 IF-MIB::ifName.5 = STRING: tun1 IF-MIB::ifName.11 = STRING: ppp0 IF-MIB::ifName.12 = STRING: tun2 SO> With the old Debian (snmpd 4.2.3) this problem did not exist. The old code was based entirely on the interface order. If you have to tunnels, bring them up as you normally would. Then take them down, and bring them up in the reverse order. The names and ifIndexes will remain the same, thus mrtg will continue to work. But suddenly the graphs are swapped, and you've got no way of knowing. The new code is based on the kernel's idea of the ifIndex. And the kernel has the same problem we do. If pppN or tunN goes down, and then comes back up, how do we know that it's the same 'interface'? For example, let's say you have 2 modems and connections to 2 sites... the connections are set to auto-connect on startup. Normally site A is ppp0, and site B is ppp1. But if line trouble causes disconnects, it's a toin-coss as to which might reconnect first, and thus get assigned ppp0. Suddenly your graphs could be graphing the wrong data again. I haven't really played with vlans/tunnels, but I'm guessing they are also numbered consecutively based on the order they come up, and numbers are re-used when interfaces go down. Now, why the the interface names are re-used but the kernel's ifIndex is not, I have no idea. So we're kind of in a pickle, and there's no easy answer. I can fix the code so that it doesn't continue to report multiple ifIndexes with the same ifName. It probably wouldn't be too hard to add a config option to assume that an interface of the same name is always the same, even if the kernel ifIndex changes. But I'd not want it to be the default. It would also mean that other apps that use/report the ifIndex would report the newer ifIndex, which wouldn't show up in a snmpwalk of the ifTable. Thoughts? opinions? -- NOTE: messages sent directly to me, instead of the lists, will be deleted unless they are requests for paid consulting services. Robert Story; NET-SNMP Junkie Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp> Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders> You are lost in a twisty maze of little standards, all different. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders