[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: questions on smilnt error

On Fri, 17 Oct 2003 Kalyan.Tata@nokia.com wrote:
> 	I have the following error in the MIB we are planning to submit.
> 	I can't seem to find a way to resolve this. I will appreciate 
> 	any help identifying what the problem is. 
> --- Snippet from MIB ---
>     vrrpAssoIpAddrEntry OBJECT-TYPE 
>         SYNTAX       VrrpAssoIpAddrEntry 
>         MAX-ACCESS   not-accessible 
>         STATUS       current 
>         DESCRIPTION 
>             "An entry in the table contains an IPv4 address that is 
>             associated with a virtual router. The number of rows for 
>             a given ifIndex and VrId will equal the number of IPv4 
>             addresses associated (e.g., backed up) by the virtual 
>             router (equivalent to 'vrrpOperIpAddrCount'). 
>             Rows in the table cannot be modified unless the value 
>             of `vrrpOperAdminState' is `disabled' and the 
>             `vrrpOperState' has transitioned to `initialize'." 
>         INDEX    { ifIndex, vrrpOperVrId, vrrpAssoIpAddrType,  
>                    vrrpAssoIpAddr } 
>         ::= { vrrpAssoIpAddrTable 1 } 
> ------ end snip ----
>                   File: VRRP-MIB
>                  Severity level requested: 6
> Line  Severity Problem 
>  407   5  index of row `vrrpAssoIpAddrEntry' can exceed OID size 
>           limit by  142subidentifier(s)

This is just a warning that the variable-length indices are not
sufficiently constrained in size to guarantee that the OID of a
column instance will never overflow the 128 sub-ID limit imposed by
the SMI and the SNMP.

You might be able to make the warning go away by putting in SIZE
constraints on the variable-length indices (certainly
vrrpAssoIpAddr, maybe vrrpOperVrId). But these days the MIB doctors
generally prefer to document the constraints in the row object
DESCRIPTION clause something like this:

| ipAddressPrefixEntry OBJECT-TYPE
|     SYNTAX     IpAddressPrefixEntry
|     MAX-ACCESS not-accessible
|     STATUS     current
|            "Inet prefix entry.
|             Implementors need to be aware that if the size of
|             of ipAddressPrefixPrefix exceeds 114 octets then
|             OIDs of instances of columns in this row will have
|             more than 128 sub-identifiers and cannot be accessed
|             using SNMPv1, SNMPv2c, or SNMPv3."
|     INDEX    { ipAddressPrefixIfIndex, ipAddressPrefixType,
|                ipAddressPrefixPrefix, ipAddressPrefixLength }
|     ::= { ipAddressPrefixTable 1 }

When there is nore than one variable-length index component, the
text might read something like this:

|             Implementors need to be aware that if the total number
|             of elements (octets or sub-identifiers) in
|             of inetCidrRouteDest, inetCidrRoutePolicy, and
|             inetCidrRouteNextHop exceeds 111 then OIDs of column
|             instances in this table will have more than 128 sub-
|             identifiers and cannot be accessed using SNMPv1, SNMPv2c,
|             or SNMPv3.

Notice that in the last case above it's impossible to cure the problem
with SIZE constraints since one of the variable-length indices is itself
an OID, which cannot have a SIZE constraint.