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
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
