Bug 114413 - (IT_36036) ipAdEntIfIndex from IP-MIB not correct
ipAdEntIfIndex from IP-MIB not correct
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: net-snmp (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
:
: 120713 (view as bug list)
Depends On:
Blocks: 122950 123574
  Show dependency treegraph
 
Reported: 2004-01-27 16:00 EST by Need Real Name
Modified: 2010-10-21 22:31 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-23 10:04:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Interface information, snmp commands and snmp server debug output (54.57 KB, text/plain)
2004-02-05 17:27 EST, Void Main
no flags Details
spec file to include the net-snmp-5.1.1-ipAdEntIfIndex.patch file (23.08 KB, text/plain)
2004-04-12 11:47 EDT, Void Main
no flags Details
RHAS3.1 spec file to include the net-snmp-5.1.1-ipAdEntIfIndex.patch file (21.89 KB, text/plain)
2004-04-12 14:37 EDT, Void Main
no flags Details

  None (edit)
Description Need Real Name 2004-01-27 16:00:56 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031030

Description of problem:
snmpwalk -c public -v 2c localhost interfaces

Issue above command - all looks good with ifIndex.1 (and .2 and .3) in
my case these are lo, eth0, and eth1 with values == 1, 2, and 3. 
These values are correct.

snmpwalk -c public -v 2c localhost ip

Then issue above command - note the ipAdEntIfIndex.nn.nn.nn.nn = ?

These should match up with the ifIndex values from the IF-MIB.  In my
case the ethn data is wrong.  "lo" shows correctly as 1 but then
"eth0" shows a 4 but should be 2 and "eth1" shows as 5 but should be 3.

Older levels of net-snmp work correctly - I tried 5.0.6-17 (old RH9).

Version-Release number of selected component (if applicable):
net-snmp-5.0.9-2.30E.1

How reproducible:
Always

Steps to Reproduce:
1.See above
2.
3.
    

Actual Results:  IF-MIB output of snmpwalk commands is correct.
IP-MIB output of snmpwalk commands is wrong.

Expected Results:  See problem desc.  The values for ifIndex from
IF-MIB should match up with the values for ipAdEntIfIndex from IP-MIB.
 These have always matched in older levels of net-snmp and ucd-snmp.


Additional info:

IF-MIB::ifIndex.2 = INTEGER: 2
...
IF-MIB::ifDescr.2 = STRING: eth0
...
after ip snmpwalk;
IP-MIB::ipAdEntIfIndex.10.100.167.170 = INTEGER: 4 

Note the value "4" is wrong - 10.100.167.170 is for eth0 and
theipAdEntIfIndex should be "2".
Comment 1 Phil Knirsch 2004-02-03 09:33:46 EST
Hmmm. This looks like you have more than 3 interfaces in your machine.
Could you append an output of

cat /proc/net/dev

to this bugreport please?

Thanks,

Read ya, Phil

PS: I just tried this on my current box and there the interfaces and
the relation between the ip output is correct (the indexs>).
Comment 2 Void Main 2004-02-03 10:05:34 EST
I have the same problem, on more than one Red Hat machine, on both
RHAS3UD1 and Fedora, and seems to only happen on Red Hat machines.
It's causing problems with apps I have written and with apps that I
have been using for years (cfgmaker included with MRTG for instance).
Here's what I just posted on HP's forums yesterday, but now I believe
it is a problem with Red Hat's included snmpd:

I just rebuilt a quad proc HP DL380 w/4GB with RHAS 3 Update 1 (was
previously running RHAS 2.1). We have 4 NICs on this machine, eth0 and
eth1 are the onboard NC7781 Gigabit ports using the tg3 module. eth2
and eth3 show up as Intel Ethernet Pro 100s and they are using the
e100 module. I am currently only using eth2 and eth3. eth0 and eth1
are not even plugged in or brought up.

The problem is when I query them via SNMP. If I snmpwalk them to get
the indexes, interface descriptions, and MAC addresses I get the
correct information:

Indexs:
$ snmpwalk -v 1 -c public myserver .1.3.6.1.2.1.2.2.1.1
iso.3.6.1.2.1.2.2.1.1.1 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.1.2 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.1.3 = INTEGER: 3
iso.3.6.1.2.1.2.2.1.1.4 = INTEGER: 4
iso.3.6.1.2.1.2.2.1.1.5 = INTEGER: 5

Descriptions:
$ snmpwalk -v 1 -c public myserver .1.3.6.1.2.1.2.2.1.2
iso.3.6.1.2.1.2.2.1.2.1 = STRING: "lo"
iso.3.6.1.2.1.2.2.1.2.2 = STRING: "eth0"
iso.3.6.1.2.1.2.2.1.2.3 = STRING: "eth1"
iso.3.6.1.2.1.2.2.1.2.4 = STRING: "eth2"
iso.3.6.1.2.1.2.2.1.2.5 = STRING: "eth3"

MAC Addresses:
$ snmpwalk -v 1 -c public myserver .1.3.6.1.2.1.2.2.1.6
iso.3.6.1.2.1.2.2.1.6.1 = ""
iso.3.6.1.2.1.2.2.1.6.2 = Hex-STRING: 00 0B CD 69 48 6B
iso.3.6.1.2.1.2.2.1.6.3 = Hex-STRING: 00 0B CD 69 48 6A
iso.3.6.1.2.1.2.2.1.6.4 = Hex-STRING: 00 0B CD 4B 10 9E
iso.3.6.1.2.1.2.2.1.6.5 = Hex-STRING: 00 0B CD 4B 10 9F

But when I query for the IP addresses associated with those interfaces
I get this:

IP Addresses:
$ snmpwalk -v 1 -c public myserver .1.3.6.1.2.1.4.20.1.2
iso.3.6.1.2.1.4.20.1.2.10.10.0.1 = INTEGER: 11
iso.3.6.1.2.1.4.20.1.2.10.10.1.1 = INTEGER: 10
iso.3.6.1.2.1.4.20.1.2.127.0.0.1 = INTEGER: 1


Now, in the above IP Address list the INTEGER that is returned should
be the index of the interface that the IP address is assocated with.
The 127.0.0.1 address does indeed match the lo interface which is
index 1, but there is no interface at index 10 and index 11. The
10.10.0.1 address should show up as index 5 and the 10.10.1.1 address
should show up as index 4. Any program that queries this server for
this information will not be able to match the IP address to an
interface. Simple examples of programs that will not get the correct
IP address for the interfaces that are up would be (but not limited
to) MRTG's cfgmaker script, or cacti snmp server graphing. In my case
it is a home brew (work brew) web application.

Does anyone else have this problem and better yet, does anyone know of
a solution to this problem? Or should I file this as a bug report to
Red Hat?

Here is the output from "cat /proc/net/dev":

 face |bytes    packets errs drop fifo frame compressed
multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:32997651   41056    0    0    0     0          0         0
32997651   41056    0    0    0     0       0          0
  eth0:       0       0    0    0    0     0          0         0    
   0       0    0    0    0     0       0          0
  eth1:       0       0    0    0    0     0          0         0    
   0       0    0    0    0     0       0          0
  eth2: 6801219  110967    0    0    0     0          0         0  
540355    1349    0    0    0     0       0          0
  eth3:  944894   16357    0    0    0     0          0         0    
 672      16    0    0    0     0       0          0
Comment 3 Phil Knirsch 2004-02-03 10:35:10 EST
Ahhhh! This sheds a little light into the darkness. Just to verify my
suspicion, could you put the output of a 

ifconfig -a

into this report?

Because what i suspect (and with which i probably could finally
reproduce the problem) is that when you do the snmpwalk over ip only
the configured devices are listed and from your output it looks as if
eth0 and eth1 both are not configured and used.

Thanks,

Read ya, Phil
Comment 4 Void Main 2004-02-03 10:46:46 EST
Here ya go (the DL380):

$ /sbin/ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:0B:CD:69:48:6B
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:11

eth1      Link encap:Ethernet  HWaddr 00:0B:CD:69:48:6A
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:15

eth2      Link encap:Ethernet  HWaddr 00:0B:CD:4B:10:9E
          inet addr:10.49.191.2  Bcast:10.49.191.127  Mask:255.255.255.128
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:119879 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4126 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:10215766 (9.7 Mb)  TX bytes:875814 (855.2 Kb)
          Interrupt:11 Base address:0x4000 Memory:f7ff0000-f7ff0038

eth3      Link encap:Ethernet  HWaddr 00:0B:CD:4B:10:9F
          inet addr:10.10.249.182  Bcast:10.10.249.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:16936 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:978463 (955.5 Kb)  TX bytes:756 (756.0 b)
          Interrupt:7 Base address:0x4040 Memory:f7df0000-f7df0038

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:41081 errors:0 dropped:0 overruns:0 frame:0
          TX packets:41081 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:33000035 (31.4 Mb)  TX bytes:33000035 (31.4 Mb)
Comment 5 Void Main 2004-02-03 11:40:17 EST
On a side note, HP suggested I try their version of ucd-snmpd (v4.2.5):

It is closer to working but still has a problem:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=416507
Comment 6 Void Main 2004-02-03 13:48:05 EST
Disregard comment #5, HP's ucd-snmpd v4.2.5 does indeed work 100% as
advertised.
Comment 7 Void Main 2004-02-05 17:27:57 EST
Created attachment 97503 [details]
Interface information, snmp commands and snmp server debug output

I have the same problem with machines running Fedora. I have attached all of
the information in the included attachment that has been requested above for
other machines. I also turned on debugging and included the snmpd debug output
associated with the snmp query returning the bad information. Don't know if
that will help.
Comment 8 Phil Knirsch 2004-02-06 05:17:49 EST
OK, i think thats enough info to get me started to fix that bug.

Thanks for collecting all the data. I´ll keep you posted on this
bugzilla entry about the status.

Read ya, Phil
Comment 9 Need Real Name 2004-02-06 10:25:49 EST
Looked at the code a little and found some interesting stuff:

1) ipAddr.c - uses ioctl call ==> ioctl(fd, SIOCGIFINDEX, ifr) to
obtain the index.  This "index" being returned does not match up with
the index from the snmpwalk of "interfaces".

2)  Do a simple command ==> ip -s -f inet addr 
    on the same system and look at the left - the index number looks
suspicious and will probably match the bogus index number seen when
doing an snmpwalk of "ip" - do command as "root".

3)  I did the same command on a system running the 2.6.1 kernel and
(greatness) - the index number looks correct !!!

I haven't had time to look at the code for "interfaces" but my guess
would be that it uses a different method of obtaining the index values
(?) - since its index numbers are "1" for "lo", "2" for "eth0", etc.

So, this may be a combination of changes/errors/mods.  It is extremely
interesting that the command "ip -s -f inet addr" - when run on a
2.6.x kernel system - shows consistent 1, 2, 3 numbers (in my case). 
However, I have not run snmpd on this machine (my laptop).

Of course, the 2.6.1 kernel could have been built with different
options or the "ip" command could be different on the systems (one is
Fedora based and the other is RHEL).

Sorry I don't have more time ... thanks.
Comment 10 Void Main 2004-02-06 13:27:06 EST
I think you are on to something. Check this out on the first server I
listed in this thread (RHAS3UD1):

# ip link show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
6: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0b:cd:69:48:6b brd ff:ff:ff:ff:ff:ff
7: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0b:cd:69:48:6a brd ff:ff:ff:ff:ff:ff
10: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0b:cd:4b:10:9e brd ff:ff:ff:ff:ff:ff
11: eth3: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0b:cd:4b:10:9f brd ff:ff:ff:ff:ff:ff
Comment 11 Curtis Doty 2004-03-13 21:32:30 EST
Some more clues from a Fedora Core 1 system with two ethernet and an 
rp-pppoe using and net-snmp-5.1-2.1. In this case the eth0 is indeed 
used and carries the ppp0 but the eth0 has no IP address.

$ /sbin/ip -o -f inet addr show
1: lo    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
4: eth1    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth1
5: ppp0    inet x.x.x.x peer y.y.y.y/32 scope global ppp0

And the ip mib uses the same index numbering:

$ snmptable -Cw 50 localhost ipAddrTable
SNMP table: IP-MIB::ipAddrTable

    ipAdEntAddr ipAdEntIfIndex  ipAdEntNetMask
      127.0.0.1              1       255.0.0.0
    192.168.0.1              4   255.255.255.0
        x.x.x.x              5 255.255.255.255

SNMP table IP-MIB::ipAddrTable, part 2

 ipAdEntBcastAddr ipAdEntReasmMaxSize
                1                   ?
                1                   ?
                0                   ?

But the interfaces mib uses a different indexing:

$ snmptable -Cw 64 localhost ifTable       
SNMP table: IF-MIB::ifTable

 ifIndex ifDescr           ifType ifMtu  ifSpeed   ifPhysAddress
       1      lo softwareLoopback 16436 10000000                
       2    eth0   ethernetCsmacd  1500 10000000 0:4:5a:9d:da:b8
       3    eth1   ethernetCsmacd  1500 10000000 0:4:5a:9d:e4:84
       4    ppp0              ppp  1492        0                

SNMP table IF-MIB::ifTable, part 2

 ifAdminStatus ifOperStatus ifLastChange ifInOctets
            up           up            ?    5668455
            up           up            ?  201625934
            up           up            ?   76713893
            up         down            ?  191191386

SNMP table IF-MIB::ifTable, part 3

 ifInUcastPkts ifInNUcastPkts ifInDiscards ifInErrors
         46842              ?            0          0
        381245              ?            0          0
        305649              ?            0          0
        327377              ?            0          0

SNMP table IF-MIB::ifTable, part 4

 ifInUnknownProtos ifOutOctets ifOutUcastPkts ifOutNUcastPkts
                 ?     5668971          46846               ?
                 ?   101128833         390554               ?
                 ?   199356400         308661               ?
                 ?    90489205         336687               ?

SNMP table IF-MIB::ifTable, part 5

 ifOutDiscards ifOutErrors ifOutQLen              ifSpecific
             0           0         0 SNMPv2-SMI::zeroDotZero
             0           0         0 SNMPv2-SMI::zeroDotZero
             0           0         0 SNMPv2-SMI::zeroDotZero
             0           0         0 SNMPv2-SMI::zeroDotZero

Obviously something isn't jiving between ipAdEntIfIndex and ifIndex. 
The ppp0 is over the unaddressed eth0. But also notice that net-snmp 
thinks the ppp0 is down (it's actually up).
Comment 13 Phil Knirsch 2004-04-08 11:03:49 EDT
Kaj J. Niemi actually stumbled accross the same problem in bug

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119106

I'll verify if this patch (or a slightly modified one) applies to the
current RHEL3 version of net-snmp and make a package ready for one of
the next Updates.

Read ya, Phil
Comment 14 Void Main 2004-04-12 11:47:46 EDT
Created attachment 99329 [details]
spec file to include the net-snmp-5.1.1-ipAdEntIfIndex.patch file

Fedora Core 1 spec file to include the net-snmp-5.1.1-ipAdEntIfIndex.patch
file. Place the patch in the SOURCES build tree after installing the
net-snmp-5.1-2.1.src.rpm then put this net-snmp.spec file in the SPECS
directory and "rpmbuild -ba net-snmp.spec".
Comment 15 Void Main 2004-04-12 14:37:30 EDT
Created attachment 99337 [details]
RHAS3.1 spec file to include the net-snmp-5.1.1-ipAdEntIfIndex.patch file

Advanced Server 3 update 1 spec file to include the
net-snmp-5.1.1-ipAdEntIfIndex.patch file. Place the patch in the SOURCES build
tree after installing the  net-snmp-5.0.9-2.30E.1.src.rpm then put this
net-snmp.spec file in the SPECS directory and "rpmbuild -ba net-snmp.spec".

The patch file can be found in the other thread that Phil links, or hopefully
this link will work:
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=98840&action=view

It appears this fixes the issues in both Fedora Core 1 (see message right above
this one for FC1) and in Red Hat Advanced Server 3 update 1, at least in the
limited testing I have performed so far. I agree with the other poster about
hoping this makes it into FC2. How does one submit it?
Comment 16 Phil Knirsch 2004-04-15 09:46:55 EDT
*** Bug 120713 has been marked as a duplicate of this bug. ***
Comment 24 Larry Troan 2004-08-04 22:35:47 EDT
Fix in dist-3.0E-U3-HEAD. Not sure if this made U3 but will be in U4
if not.
Comment 26 Brian Baker 2004-09-08 11:16:19 EDT
Go ahead and close this one...

Note You need to log in before you can comment on or make changes to this bug.