[prev in list] [next in list] [prev in thread] [next in thread] 

List:       net-snmp-coders
Subject:    Re: Bug with transient interfaces (ppp)?
From:       snmp () rigacci ! org
Date:       2005-11-26 18:34:39
Message-ID: 20051126183439.GA13568 () rigacci ! org
[Download RAW message or body]

> 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):

  public@localhost_       Descr   eth0    2
  public@localhost_       Descr   eth1    3
  public@localhost_       Descr   lo      1
  public@localhost_       Descr   ppp0    Dup
  public@localhost_       Descr   tun1    Dup
  public@localhost_       Descr   tun2    Dup
  public@localhost_       Descr   tun82   16
  public@localhost_       Eth             Dup
  public@localhost_       Eth     00-50-fc-fa-d0-89       3
  public@localhost_       Eth     00-50-fc-ff-31-6c       2
  public@localhost_       Ip      127.0.0.1       1
  public@localhost_       Ip      172.16.1.1      15
  public@localhost_       Ip      172.16.2.2      14
  public@localhost_       Ip      172.16.82.1     16
  public@localhost_       Ip      192.168.2.2     2
  public@localhost_       Ip      217.19.150.150  17
  public@localhost_       Name    eth0    2
  public@localhost_       Name    eth1    3
  public@localhost_       Name    lo      1
  public@localhost_       Name    ppp0    Dup
  public@localhost_       Name    tun1    Dup
  public@localhost_       Name    tun2    Dup
  public@localhost_       Name    tun82   16
  public@localhost_       Type    1       Dup
  public@localhost_       Type    23      Dup
  public@localhost_       Type    24      1
  public@localhost_       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
[prev in list] [next in list] [prev in thread] [next in thread]