Bug 616336 - [TAHI] ipAddressTable doesn't support snmpset operation.
Summary: [TAHI] ipAddressTable doesn't support snmpset operation.
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: net-snmp (Show other bugs)
(Show other bugs)
Version: 6.1
Hardware: All Linux
low
medium
Target Milestone: rc
: ---
Assignee: Jan Safranek
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks: 572236
TreeView+ depends on / blocked
 
Reported: 2010-07-20 08:05 UTC by Xiaoli Tian
Modified: 2011-05-19 14:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-19 14:13:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0729 normal SHIPPED_LIVE net-snmp bug fix update 2011-05-18 18:09:25 UTC

Description Xiaoli Tian 2010-07-20 08:05:14 UTC
Description of problem:

When I use the following command to create a new row with 3ffe:501:ffff:100::100 in ipAddressTable

“snmpset -v 2c -c IPv6ReadyLogo  localhost 1.3.6.1.2.1.4.34.1.10.2.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 5 "

It responses with the following error:
Error in packet.
Reason: inconsistentName (That object can not currently be created)
Failed object: IP-MIB::ipAddressRowStatus.ipv6."3f:fe:05:01:ff:ff:01:00:00:00:00:00:00:00:01:00"

Version-Release number of selected component (if applicable):
net-snmp-5.5-23.el6.x86_64
net-snmp-libs-5.5-23.el6.x86_64
net-snmp-utils-5.5-23.el6.x86_64
kernel-2.6.32-47.el6.x86_64

How reproducible:
Always


Steps to Reproduce:
1.Configure  rwcommunity and rocommunity  with your own community,
2.Start snmpd service
3.Run the command above :“snmpset -v 2c -c IPv6ReadyLogo  localhost 1.3.6.1.2.1.4.34.1.10.2.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 5 "
  
Actual results:
Failed to add a new row in ipAddresstable

Expected results:
Could add a new row 


Additional info:
My snmpd.conf and rc.local files are described as follows:
1)snmpd.conf
#sec.name source community
#com2sec local default IPv6Ready
com2sec local localhost IPv6Ready
com2sec6 local localhost IPv6Ready
#com2sec6 local default IPv6Ready
com2sec mynet 192.168.0.0/24 IPv6Ready
com2sec6 mynet 3ffe:501:ffff:100::/64 IPv6Ready
rwcommunity IPv6ReadyLogo
rwcommunity6 IPv6ReadyLogo
agentaddress udp6:161
agentaddress udp:161
trapcommunity IPv6Ready
#trapcommunity public
#agentaddress udp6:162
#agentaddress udp:162
#trapsink   192.168.0.20:162    public
#trap2sink udp6:[3ffe:501:ffff:100:21b:21ff:fe1c:5dd1]:162 IPv6Ready
trap2sink udp6:[3ffe:501:ffff:100:221:27ff:fe9d:f647]:162 IPv6Ready
#trap2sink udp6:[3ffe:501:ffff:100::20]:162 public
#createUser ipv6dod MD5 ipv6dodtest DES ipv6dodtestother
#rocommunity public 192.168.0.20
#rocommunity IPv6Ready 3ffe:501:ffff:100:21b:21ff:fe1c:5dd1
#rocommunity6 IPv6Ready 3ffe:501:ffff:100:21b:21ff:fe1c:5dd1
rocommunity6 IPv6Ready
rocommunity IPv6Ready
#rocommunity public 192.168.0.20
#snmpsink  localhost IPv6Ready
#snmpsink  localhost IPv6Ready
#authtrapenable 0
#snmp2sink 3ffe:501:ffff:100:21b:21ff:fe1c:5dd1 IPv6Ready
#snmp2sink 192.168.0.20 public
# sec.model sec.name
group mygroup v1 mynet
group mygroup v2c mynet
group mygroup usm mynet
group local v1 local
group local v2c local
#group local usm local

# Second, map the security name into a group name:
group   groupv3        usm          ipv6dod

master yes
# incl/excl subtree mask
view all included .1.3.6
#view all included .1 80
view all included .1
#view mib2 included .iso.org.dod.internet.mgmt.mib-2 fc
view all included .iso.org.dod.internet.mgmt.mib-2
#view all included  .iso   80
view all included .iso
# context sec.model sec.level prefix read write notify
#access mygroup "" any noauth exact mib2 none none
access mygroup "" any noauth exact all none none
access local "" any noauth exact all all all
access groupv3 "" any noauth exact all all all

# It is also possible to set the sysContact and sysLocation system
# variables through the snmpd.conf file:
syslocation raycom office, Redhat China Research and Development Centre
syscontact Xiaoli Tian  "xtian@redhat.com"
sysServices 72

2)rc.local

#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local
sysctl -w net.ipv6.conf.default.accept_dad=2
sysctl -w net.ipv6.conf.default.disable_ipv6=0
ifup eth0
#snmpd -f Lo -Ddump,verbose:inetNetToMediaTable|tee snmpd.log
snmpd udp:161
snmpd udp:162
snmpd udp6:161
snmpd udp6:162
snmpset -v 2c -c IPv6ReadyLogo localhost nsCacheTimeout.1.3.6.1.2.1.4.35 i 0
snmpset -v 2c -c IPv6ReadyLogo localhost nsCacheTimeout.1.3.6.1.2.1.5.29 i 0
snmpset -v 2c -c IPv6ReadyLogo localhost nsCacheTimeout.1.3.6.1.2.1.4.31.1 i 0

Comment 2 RHEL Product and Program Management 2010-07-20 08:37:54 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 3 Jan Safranek 2010-07-20 12:03:29 UTC
Net-SNMP does not support creation of IPv6 addresses, only IPv4 ones. I am not sure it is even possible to create an generic IPv6 address (Net-SNMP uses ioctl() for the IPv4). And if it is, it's quite lot of code on Net-SNMP side to add the missing functionality.

Comment 4 RHEL Product and Program Management 2010-07-20 12:17:15 UTC
This feature request has been proposed after Feature Freeze and we
are unable to resolve it in time for the current Red Hat Enterprise
Linux release. It has been denied for the current release and
proposed for the next Red Hat Enterprise Linux release.

Comment 5 Jan Safranek 2010-07-20 12:49:31 UTC
Looking at the kernel ioctls, it looks like it is possible to add ipv6 address. The kernel requires not only interface index and the IP address (both is known to Net-SNMP), but also prefix length of the IPv6 address. This cannot be set using simple snmpset and Net-SNMP does not have any clue what is the desired prefix length. Can Net-SNMP assume that it is always 128?

Comment 6 Xiaoli Tian 2010-07-21 01:10:07 UTC
(In reply to comment #3)
> Net-SNMP does not support creation of IPv6 addresses, only IPv4 ones. I am not
> sure it is even possible to create an generic IPv6 address (Net-SNMP uses
> ioctl() for the IPv4). And if it is, it's quite lot of code on Net-SNMP side to
> add the missing functionality.    

Hi,Jan

Could you tell me the correct command to create ipv4 address? I have tried using the following command to create one row 
"snmpset -v 2c -c IPv6ReadyLogo  localhost 1.3.6.1.2.1.4.34.1.10.1.4.10.0.0.3 i 5 "

But it failed with the following error:
Error in packet.
Reason: wrongValue (The set value is illegal or unsupported in some way)
Failed object: IP-MIB::ipAddressRowStatus.ipv4."10.0.0.3"

I have got ipAddressRowStatus via command
"snmpwalk -v 2c -c IPv6ReadyLogo  localhost 1.3.6.1.2.1.4.34.1.10 -Ob"

The result is as follows:
IP-MIB::ipAddressRowStatus.1.4.10.66.92.174 = INTEGER: active(1)
IP-MIB::ipAddressRowStatus.1.4.10.66.93.255 = INTEGER: active(1)
IP-MIB::ipAddressRowStatus.1.4.127.0.0.1 = INTEGER: active(1)
IP-MIB::ipAddressRowStatus.2.16.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 = INTEGER: active(1)
IP-MIB::ipAddressRowStatus.2.16.63.254.5.1.255.255.1.0.2.37.100.255.254.166.254.163 = INTEGER: active(1)
IP-MIB::ipAddressRowStatus.2.16.254.128.0.0.0.0.0.0.2.37.100.255.254.166.254.163 = INTEGER: active(1)

 It seems that the oid doesn't contain ifindex.

Comment 7 Xiaoli Tian 2010-07-21 01:18:16 UTC
(In reply to comment #5)
> Looking at the kernel ioctls, it looks like it is possible to add ipv6 address.
> The kernel requires not only interface index and the IP address (both is known
> to Net-SNMP), but also prefix length of the IPv6 address. This cannot be set
> using simple snmpset and Net-SNMP does not have any clue what is the desired
> prefix length. Can Net-SNMP assume that it is always 128?    

Hi,Jan 

 If we have to set the prefix length to a fixed value,as many test cases in TAHI show,64 may be a more common prefix length.But I think it's not the point to check.

Thanks .

xiaoli

Comment 8 Jan Safranek 2010-07-21 11:47:03 UTC
It's not so easy to create a row - you have to fill all required columns. Following command creates new interface, but due to bug in snmpd (see bug #616764), it returns error.

$ snmpset  localhost IP-MIB::ipAddressRowStatus.ipv4.4.10.34.25.162  integer 
createAndGo IP-MIB::ipAddressIfIndex.ipv4.4.10.34.25.162 i 1
IP-MIB::ipAddressStatus.ipv4.4.10.34.25.162 i 1
IP-MIB::ipAddressStorageType.ipv4.4.10.34.25.162 i 2

Error in packet.
Reason: (genError) A general failure occured
Failed object: IP-MIB::ipAddressRowStatus.ipv4."10.34.25.162"

But as I wrote, the interface *is* created, in my case it is lo:1 with IP address 10.34.25.162. It's netmask is 255.0.0.0, dunno where it is taken from - different IP addresses get different masks.

Comment 9 Jan Safranek 2010-07-21 11:56:04 UTC
(In reply to comment #7)
> (In reply to comment #5)
> > Looking at the kernel ioctls, it looks like it is possible to add ipv6 address.
> > The kernel requires not only interface index and the IP address (both is known
> > to Net-SNMP), but also prefix length of the IPv6 address. This cannot be set
> > using simple snmpset and Net-SNMP does not have any clue what is the desired
> > prefix length. Can Net-SNMP assume that it is always 128?    
> 
> Hi,Jan 
> 
>  If we have to set the prefix length to a fixed value,as many test cases in
> TAHI show,64 may be a more common prefix length.But I think it's not the point
> to check.

Well, the goal is not to be TAHI compliant but to do what network admin needs. The compliance is only nice bonus, right? Assumption of network prefixes should be based on real world use-case, not on artificial test suite.

Comment 10 Xiaoli Tian 2010-07-22 01:06:06 UTC
(In reply to comment #9)
> Well, the goal is not to be TAHI compliant but to do what network admin needs.
> The compliance is only nice bonus, right? Assumption of network prefixes should
> be based on real world use-case, not on artificial test suite.    

Hi,Jan
You are right,but I'm not so sure about the most common prefix length. According to this page:http://tools.ietf.org/html/draft-savolainen-stateless-pd-01 ,
it seems that 64 may be more common in real world,and you know that the ipv6address we always use consists of a 64  prefix  and physical address of a node.
But you could decide it :)

xiaoli

Comment 11 Xiaoli Tian 2010-07-22 01:14:54 UTC
Hi,Jan
As page http://www.getipv6.info/index.php/IPv6_Addressing_Plans said (FYI),
   1.  Separate address block for infrastructure from other uses (enterprise, loopbacks)
          * May mean two /48s per PoP
          * Document so that you can justify it in your Host Density ratio 
   2. Each individual site should receive a /48 assignment which 65536 subnets (2^16).
   3. Summary aggregates for groups of sites where it makes sense, but watch your HD ratio
   4. Any prefixes shorter than /48 will only be assigned when there is written justification to show that this prefix will meet the RIR HD ratio guidelines within 5 years.
   5. Each PoP is a site therefore assign a /48 for infrastructure
   6. No subnets will use prefixes longer than /64.
   7. Separate address block for router loop-back interfaces
          * Generally number all loopbacks out of one /64
          * /128 per loopback
          * Note that this recommendation violates RFC4291 - "IP Version 6 Addressing Architecture", which states that for addresses with other than binary 000 as their first 3 bits, the Interface Identifier must be 64 bits long. It isn't really necessary to save IPv6 address space by using /128s on loopbacks. For example, out of a /48, if you allowed for 16384 /64s for loopbacks, you'd still have 49 152 subnets left for links. If your network is big enough that that sort of addressing plan is not going to be large enough, then you probably won't have any issues with getting multiple /48s e.g. a /47 or /46. 
   8. Assign a /64 per LAN / VLAN / subnet
   9. Organizations with multiple /48 allocations should consider enterprise-wise aggregation levels of /60 or larger blocks for the administration of enterprise policies for common functions such as:
          * DMZ
          * Realtime traffic, such as voice & video
          * Network loopback addresses and Link space 
  10. IETF expects that you will assign a /64 for point-to-point links
          * Fewer typos because all subnets are the same size
          * You can use longer prefixes but what's the point?
          * /126 will break Mobile IPv6 Home Agent discovery
          * /112 leaves final 16 bits free for Node IDs
          * Use /64 unless you have read and understand RFC 3627
          * Note: on pure point-to-point links (e.g., SONET) anything shorter than /127 is vulnerable to ping-pong packet amplification as described in Maz's APNIC 26 presentation. (On Ethernet, this is at most a neighbor cache DoS) 
  11. The enterprise network should receive a prefix sufficient to provide a /48 allocation for each site (office/campus/PoP) at which the company has employees or systems.
  12. All customers get one /48 unless they can show that they need more than 65k subnets.
          * Host count is irrelevant.
          * Do not assign to customers from PoP aggregates
          * Define aggregate areas which contain several PoPs
          * Carry customer networks in iBGP
          * Aggregate only in eBGP
          * If you have lots of consumer customers you may want to assign /56s to private residence sites. 
  13. Expect the registry to allocate a /32 and reserve one /32
          * Plan for the time when you get a second allocation giving you a /31 aggregate.
          * If you get more than /32 first time round, ask the RIR how much is reserved so you can plan appropriately. 
  14. If you need private addresses, generate a ULA prefix as defined in RFC 4193
          * Use this handy web tool to generate one
          * Add it to the registry at the above site, if you want people to know that this is your private space
          * Make sure your internal registry people are aware of your ULA prefix(es) so that everybody uses it. 

Thanks
 
xiaoli

Comment 12 Jan Safranek 2010-07-28 08:58:19 UTC
Ok, let it be prefix /64. I'll try to prepare something for 6.1

Comment 13 Jan Safranek 2010-10-29 12:30:23 UTC
I've created experimental patch and published RHEL6 test packages at http://people.redhat.com/jsafrane/bugs/616336/

Please test if it passes the test suite now. On my RHEL6 machine, I can create new IPv6 address using this (long) command:
$ snmpset  -v2c -c public localhost IP-MIB::ipAddressRowStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0  integer  createAndGo IP-MIB::ipAddressIfIndex.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 1 IP-MIB::ipAddressStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 1 IP-MIB::ipAddressStorageType.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 2

The address can be deleted using:
$ snmpset  -v2c -c public rhel6 IP-MIB::ipAddressRowStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0  integer  destroy


Only the 'createAndGo' method of creating new rows is supported, 'createAndWait' is not implemented in Net-SNMP.

Comment 15 Xiaoli Tian 2010-11-01 08:09:08 UTC
(In reply to comment #13)
> I've created experimental patch and published RHEL6 test packages at
> http://people.redhat.com/jsafrane/bugs/616336/
> 
> Please test if it passes the test suite now. On my RHEL6 machine, I can create
> new IPv6 address using this (long) command:
> $ snmpset  -v2c -c public localhost
> IP-MIB::ipAddressRowStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 
> integer  createAndGo
> IP-MIB::ipAddressIfIndex.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 1
> IP-MIB::ipAddressStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 1
> IP-MIB::ipAddressStorageType.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 2
> 
> The address can be deleted using:
> $ snmpset  -v2c -c public rhel6
> IP-MIB::ipAddressRowStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 
> integer  destroy
> 
> 
> Only the 'createAndGo' method of creating new rows is supported,
> 'createAndWait' is not implemented in Net-SNMP.

Hi,Jan
I have tested this package:
http://people.redhat.com/jsafrane/bugs/616336/,

1) Yeah,IPv6Address could be created by the command 
snmpset  -v 2c -c IPv6ReadyLogo IPv6Testee IP-MIB::ipAddressRowStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0  i 4 IP-MIB::ipAddressIfIndex.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 2 IP-MIB::ipAddressStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 1 IP-MIB::ipAddressStorageType.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 2
IP-MIB::ipAddressRowStatus.ipv6."3f:fe:05:01:ff:ff:01:00:00:00:00:00:00:00:01:00" = INTEGER: createAndGo(4)
IP-MIB::ipAddressIfIndex.ipv6."3f:fe:05:01:ff:ff:01:00:00:00:00:00:00:00:01:00" = INTEGER: 2
IP-MIB::ipAddressStatus.ipv6."3f:fe:05:01:ff:ff:01:00:00:00:00:00:00:00:01:00" = INTEGER: preferred(1)
IP-MIB::ipAddressStorageType.ipv6."3f:fe:05:01:ff:ff:01:00:00:00:00:00:00:00:01:00" = INTEGER: volatile(2)
2)
However it seems that the following two fields could not be set to value 3("not ready" for ipAddressRowStatus and "invalid" for ipAddressStatus)

snmpset  -v 2c -c IPv6ReadyLogo IPv6Testee  IP-MIB::ipAddressRowStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 3
Error in packet.
Reason: wrongValue (The set value is illegal or unsupported in some way)
Failed object: IP-MIB::ipAddressRowStatus.ipv6."3f:fe:05:01:ff:ff:01:00:00:00:00:00:00:00:01:00"

snmpset  -v 2c -c IPv6ReadyLogo IPv6Testee  IP-MIB::ipAddressStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 3
Error in packet.
Reason: wrongValue (The set value is illegal or unsupported in some way)
Failed object: IP-MIB::ipAddressStatus.ipv6."3f:fe:05:01:ff:ff:01:00:00:00:00:00:00:00:01:00"

Thanks.

Comment 16 Jan Safranek 2010-11-01 11:27:45 UTC
(In reply to comment #15)
> 2)
> However it seems that the following two fields could not be set to value 3("not
> ready" for ipAddressRowStatus and "invalid" for ipAddressStatus)

In the Net-SNMP code I can clearly see that ipAddressStatus supports only 'preffered' (=1) state on snmpset operation. Is 'invalid' required by the test suite? What benefit to customer has adding invalid IP addresses?


And ipAddressRowStatus cannot be set using snmpset, see RFC 2579:
    
    RowStatus ::= TEXTUAL-CONVENTION
        STATUS       current
        DESCRIPTION
            ...
            Whereas five of the six values (all except `notReady') may
            be specified in a management protocol set operation, only
            three values will be returned in response to a management
            protocol retrieval operation

Only snmpd itself can set the status to 'notReady' when it has not enough information to add the IP address to physical network interface. And I am not sure if it can ever happen, since snmpd does not support createAndWait...

Comment 17 Xiaoli Tian 2010-11-02 02:13:58 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > 2)
> > However it seems that the following two fields could not be set to value 3("not
> > ready" for ipAddressRowStatus and "invalid" for ipAddressStatus)
> 
> In the Net-SNMP code I can clearly see that ipAddressStatus supports only
> 'preffered' (=1) state on snmpset operation. Is 'invalid' required by the test
> suite? What benefit to customer has adding invalid IP addresses?
> 
Hi,Jan
Thanks for your hard work to dig it, it's actually required by the test suite,but Maybe TAHI's test suite is not so perfect until now,and they may have some different understanding about the RFC, I'll talk about it with them.

> 
> And ipAddressRowStatus cannot be set using snmpset, see RFC 2579:
> 
>     RowStatus ::= TEXTUAL-CONVENTION
>         STATUS       current
>         DESCRIPTION
>             ...
>             Whereas five of the six values (all except `notReady') may
>             be specified in a management protocol set operation, only
>             three values will be returned in response to a management
>             protocol retrieval operation
> 
> Only snmpd itself can set the status to 'notReady' when it has not enough
> information to add the IP address to physical network interface. And I am not
> sure if it can ever happen, since snmpd does not support createAndWait...

Maybe TAHI need to modify their test suite.
Thanks.

Comment 20 errata-xmlrpc 2011-05-19 14:13:12 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0729.html


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