#50 IP address table

[Carlos Vicente]

[Note: I posted this on the snmp-info-users mailing list, but I'm not sure if it made it through. Also, the archives stopped sometime in October]

Dear all,

I was just enabling SNMP on a VMWare ESXi system, and noticed that I
wasn't getting the IP information from SNMP::Info.

I then learned that the IP-MIB has two tables for IP addresses, one is
said to be "deprecated":

ipAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpAddrEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The table of addressing information relevant to this
entity's IPv4 addresses.

        This table has been deprecated, as a new IP version-neutral
        table has been added.  It is loosely replaced by the
        ipAddressTable although several objects that weren't deemed
        useful weren't carried forward while another
        (ipAdEntReasmMaxSize) was moved to the ipv4InterfaceTable."
::= { ip 20 }

ipAddressTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpAddressEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains addressing information relevant to the
entity's interfaces.

        This table does not contain multicast address information.
        Tables for such information should be contained in multicast
        specific MIBs, such as RFC 3019.

        While this table is writable, the user will note that
        several objects, such as ipAddressOrigin, are not.  The
        intention in allowing a user to write to this table is to
        allow them to add or remove any entry that isn't

        permanent.  The user should be allowed to modify objects
        and entries when that would not cause inconsistencies
        within the table.  Allowing write access to objects, such
        as ipAddressOrigin, could allow a user to insert an entry
        and then label it incorrectly.

        Note well: When including IPv6 link-local addresses in this
        table, the entry must use an InetAddressType of 'ipv6z' in
        order to differentiate between the possible interfaces."
::= { ip 34 }

And it turns out that the VMWare system is using the new one only:

IP-MIB::ipAddressIfIndex.ipv4."192.168.0.90" = INTEGER: 4
IP-MIB::ipAddressIfIndex.ipv6."20:01:0d:b8:00:03:00:0d:00:00:00:00:00:00:00:90"
= INTEGER: 4

And since SNMP::Info appears to be using only the first table
(ip_index, ip_table, etc.), I'm wondering what to do here.

It seems that I could modify ip_index() and family to look into the
deprecated table first (since it's still so popular), and if no values
are returned, look into the other one.

Would that make sense, or is there a preferred approach?

Best,

cv

[Eric A. Miller]

What you've proposed makes sense. When overriding the ip_index, ip_table, and ip_netmask please make sure that the returned keys and values match what would be returned by the older table for backwards compatability.