> 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 > > What release are you using?
snmpd 5.2.1.2-4 (Debian Testing on i386). > What happens after you restart snmpd? Duplicate interface are purged, but indexes are the last assigned: # snmpwalk -c public -v1 127.0.0.1 | grep ifName IF-MIB::ifName.1 = STRING: lo IF-MIB::ifName.2 = STRING: eth0 IF-MIB::ifName.3 = STRING: eth1 IF-MIB::ifName.14 = STRING: tun2 IF-MIB::ifName.15 = STRING: tun1 IF-MIB::ifName.16 = STRING: tun82 IF-MIB::ifName.17 = STRING: ppp0 > 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. With OpenVPN we can assign the interface name (tun0, tun1, ...) regardless of the order they bring up, we can also leave holes (you see above I have tun0, tun1 and tun82). With ppp interfaces this is not possible, as far I know. I'm not aware of MRTG internals, but I think that it add a problem on its own. It asks snmpd for interface descriptions to get the indexes, and then caches the results. So MRTG remains stuck to indexes it cached the first time, starting to display zero values when the interface goes donw/up (change index). If MRTG is started freshly (removing the cache info) when interfaces duplicates already exist, it is unable to choose the correct index. This is an example of cache file in this case (/var/lib/mrtg/_etc_mrtg_mrtg.cfg): [EMAIL PROTECTED] Descr eth0 2 [EMAIL PROTECTED] Descr eth1 3 [EMAIL PROTECTED] Descr lo 1 [EMAIL PROTECTED] Descr ppp0 Dup [EMAIL PROTECTED] Descr tun1 Dup [EMAIL PROTECTED] Descr tun2 Dup [EMAIL PROTECTED] Descr tun82 16 [EMAIL PROTECTED] Eth Dup [EMAIL PROTECTED] Eth 00-50-fc-fa-d0-89 3 [EMAIL PROTECTED] Eth 00-50-fc-ff-31-6c 2 [EMAIL PROTECTED] Ip 127.0.0.1 1 [EMAIL PROTECTED] Ip 172.16.1.1 15 [EMAIL PROTECTED] Ip 172.16.2.2 14 [EMAIL PROTECTED] Ip 172.16.82.1 16 [EMAIL PROTECTED] Ip 192.168.2.2 2 [EMAIL PROTECTED] Ip 217.19.150.150 17 [EMAIL PROTECTED] Name eth0 2 [EMAIL PROTECTED] Name eth1 3 [EMAIL PROTECTED] Name lo 1 [EMAIL PROTECTED] Name ppp0 Dup [EMAIL PROTECTED] Name tun1 Dup [EMAIL PROTECTED] Name tun2 Dup [EMAIL PROTECTED] Name tun82 16 [EMAIL PROTECTED] Type 1 Dup [EMAIL PROTECTED] Type 23 Dup [EMAIL PROTECTED] Type 24 1 [EMAIL PROTECTED] Type 6 Dup > 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. Best to report only the one with highest index? By the user's perspective, no problem if the ifIndex changes. Also considering the new ppp0 a totally different interface can make sense, at least it starts with new TX/RX counters... The problem is having multiple instances of the name ppp0, with the command "ifconfig" I see only one, so I expect the same from snmpd. -- Niccolo Rigacci Firenze - Italy ------------------------------------------------------- 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
