Background: Know: Access allowed for an object, Recognize: SMI

Tag: Uncertain

Previous Next
 Examples of access

  The MAX-ACCESS clause defined in SMIv2 specifies the maximum allowed level of access for any implementation of the object,[1] which provides more control over how an object is accessed in contrast with the ACCESS clause defined in SMIv1.[2][3] This page lists mapping options of the access rights to the objects with examples, ordered from least to greatest: not-accessible, accessible-for-notify, read-only, read-write, read-create.

"not-accessible" Edit

  • ipv4InterfaceTable [4]
ipv4InterfaceTable OBJECT-TYPE
    SYNTAX     SEQUENCE OF Ipv4InterfaceEntry
    MAX-ACCESS not-accessible
    STATUS     current
           "The table containing per-interface IPv4-specific
    ::= { ip 28 }
This is the interior node which does not have any value (cf. scalar and aggregate objects).

"accessible-for-notify" Edit

  • snmpTrapOID [5]
    MAX-ACCESS accessible-for-notify
    STATUS     current
           "The authoritative identification of the notification
            currently being sent. This variable occurs as the second
            varbind in every SNMPv2-Trap-PDU and InformRequest-PDU."
    ::= { snmpTrap 1 }
This is the trap identification object which should only be accessible via a notification.
For the practical usage, see Notifications_exercise.

"read-only" Edit

  • ipv4InterfaceTableLastChange [4]
ipv4InterfaceTableLastChange OBJECT-TYPE
    SYNTAX     TimeStamp
    MAX-ACCESS read-only
    STATUS     current
           "The value of sysUpTime on the most recent occasion at which
            a row in the ipv4InterfaceTable was added or deleted, or
            when an ipv4InterfaceReasmMaxSize or an
            ipv4InterfaceEnableStatus object was modified.

            If new objects are added to the ipv4InterfaceTable that
            require the ipv4InterfaceTableLastChange to be updated when
            they are modified, they must specify that requirement in
            their description clause."
    ::= { ip 27 }
The value of this object should be updated automatically to reflect the timestamp the table was last modified.
  • ipReasmTimeout [6]
ipReasmTimeout OBJECT-TYPE
    ACCESS     read-only
    STATUS     mandatory
           "The maximum number of seconds which received
            fragments are held while they are awaiting
            reassembly at this entity."
    ::= { ip 13 }
See discussions on why ipReasmTimeout should be read-only.

"read-write" Edit

  • ipForwarding [4]
ipForwarding OBJECT-TYPE
                    forwarding(1),    -- acting as a router
                    notForwarding(2)  -- NOT acting as a router
    MAX-ACCESS read-write
    STATUS     current
           "The indication of whether this entity is acting as an IPv4
            router in respect to the forwarding of datagrams received
            by, but not addressed to, this entity.  IPv4 routers forward
            datagrams.  IPv4 hosts do not (except those source-routed
            via the host).

            When this object is written, the entity should save the
            change to non-volatile storage and restore the object from
            non-volatile storage upon re-initialization of the system.
            Note: a stronger requirement is not used because this object
            was previously defined."
    ::= { ip 1 }
The routing function of the entity could be enabled or disabled.
For the practical usage, see VLAN_configuration_exercise.

"read-create" Edit

  • ipAddressIfIndex [4]
ipAddressIfIndex OBJECT-TYPE
    SYNTAX     InterfaceIndex
    MAX-ACCESS read-create
    STATUS     current
           "The index value that uniquely identifies the interface to
            which this entry is applicable.  The interface identified by
            a particular value of this index is the same interface as
            identified by the same value of the IF-MIB's ifIndex."
    ::= { ipAddressEntry 3 }
Some entries that are not permanent could be added or modified.

Discussions Edit

Why should ipReasmTimeout be read-only? After all, this is a parameter that controls how the entity behaves and so it should be settable. For example in the environment where the network has long propagation delays, or the device has lots of buffer space available, a larger value would be more suitable. (The reason why it is a parameter is that it should reflect the maximum misordering/delay of fragments in the network; if it is too small then the receiver won't wait long enough, and if it is too large, then the receiver might waste buffer space holding parts of packets that will never be reassembled.  So it is useful to be able to adjust the parameter, but for some reason it is read-only.)


[clarification needed]

See also Edit

References Edit

  1. McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
  2. Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
  3. Rose, M. and K. McCloghrie, "Concise MIB definitions", STD 16, RFC 1212, March 1991.
  4. 4.0 4.1 4.2 4.3 Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006.
  5. Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996.
  6. McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991.