Bug 114413 (IT_36036)
| Summary: | ipAdEntIfIndex from IP-MIB not correct | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Need Real Name <dblankenship> |
| Component: | net-snmp | Assignee: | Radek Vokál <rvokal> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | brian.b, curtis, tao |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-09-23 14:04:32 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 122950, 123574 | ||
| Attachments: | |||
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>). 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
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 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)
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 Disregard comment #5, HP's ucd-snmpd v4.2.5 does indeed work 100% as advertised. 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.
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 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.
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
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).
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 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".
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? *** Bug 120713 has been marked as a duplicate of this bug. *** Fix in dist-3.0E-U3-HEAD. Not sure if this made U3 but will be in U4 if not. Go ahead and close this one... |
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".