📄 rfc4544.txt
字号:
be useful for identifying performance, security, and fault problems
from a management station.
6.3. iscsiInstance
The iscsiInstanceAttributesTable is the primary table of the iSCSI
MIB module. Every table entry in this module is "owned" by exactly
one iSCSI instance; all other table entries in the module include
this table's index as their primary index.
Most implementations will include just one iSCSI instance row in this
table. However, this table exists to allow for multiple virtual
instances. For example, many IP routing products now allow multiple
virtual routers. The iSCSI MIB module has the same premise; a large
system could be "partitioned" into multiple, distinct virtual
systems.
This also allows a single SNMP agent to proxy for multiple
subsystems, perhaps a set of stackable devices, each of which has one
or even more instances.
The instance attributes include the iSCSI vendor and version, as well
as information on the last target or initiator at the other end of a
session that caused a session failure.
The iscsiInstanceSsnErrorStatsTable augments the attributes table and
provides statistics on session failures due to digest, connection, or
iSCSI format errors.
6.4. iscsiPortal
The iscsiPortalAttributesTable lists iSCSI portals that can be used
to listen for connections to targets, to initiate connections to
other targets, or to do both.
Bakke, et al. Standards Track [Page 7]
RFC 4544 iSCSI MIB May 2006
Each row in the table includes an IP address (either v4 or v6), and a
transport protocol (currently only TCP is defined). Each portal may
have additional attributes, depending on whether it is an initiator
portal, a target portal, or both. Initiator portals also have portal
tags; these are placed in corresponding rows in the
iscsiIntrPortalAttributesTable. Target portals have both portal tags
and ports (e.g., TCP listen ports if the transport protocol is TCP);
these are placed in rows in the iscsiTgtPortalAttributesTable.
Portal rows, along with their initiator and target portal
counterparts, may be created and destroyed through this MIB module by
a management station. Rows in the initiator and target portal tables
are created and destroyed automatically by the agent, whenever a row
is created or destroyed in the iscsiPortalAttributesTable, or if the
value of iscsiPortalRoles changes. Attributes in these tables may
then be modified by the management station if the agent
implementation allows.
When created by a management station, the iscsiPortalRoles attribute
is used to control row creation in the initiator and target portal
tables. Creating a row with the targetTypePortal bit set in
iscsiPortalRoles will cause the implementation to start listening for
iSCSI connections on the portal. Creating a row with the
initiatorTypePortal bit set in iscsiPortalRoles will not necessarily
cause connections to be established; it is left to the implementation
whether and when to make use of the portal. Both bits may be set if
the portal is to be used by both initiator and target nodes.
When deleting a row in the iscsiPortalAttibutesTable, all connections
associated with that row are terminated. The implementation may
either terminate the connection immediately or request a clean
shutdown as specified in [RFC3720]. An outbound connection (when an
iscsiInitiatorPortal is deleted) matches the portal if its
iscsiCxnLocalAddr matches the iscsiPortalAddr. An inbound connection
(when an iscsiTargetPortal is deleted) matches the portal if its
iscsiCxnLocalAddr matches the iscsiPortalAddr, and its
iscsiCxnLocalPort matches the iscsiTargetPortalPort.
Individual objects within a row in this table may not be modified
while the row is active. For instance, changing the IP address of a
portal requires that the rows associated with the old IP address be
deleted, and new rows be created (in either order).
Bakke, et al. Standards Track [Page 8]
RFC 4544 iSCSI MIB May 2006
6.5. iscsiTargetPortal
The iscsiTgtPortalAttributesTable contains target-specific attributes
for iSCSI portals. Rows in this table use the same indices as their
corresponding rows in the iscsiPortalAttributesTable, with the
addition of iscsiNodeIndex.
Rows in this table are created when the targetTypePortal bit is set
in the iscsiPortalRoles attribute of the corresponding
iscsiPortalAttributesEntry; they are destroyed when this bit is
cleared.
This table contains the TCP (or other protocol) port on which the
socket is listening for incoming connections. It also includes a
portal group aggregation tag; iSCSI target portals within this
instance sharing the same tag can contain connections within the same
session.
This table will be empty for iSCSI instances that contain only
initiators (such as iSCSI host driver implementations).
Many implementations use the same target portal tag and protocol port
for all nodes accessed via a portal. These implementations will
create a single row in the iscsiTgtPortalAttributeTable, with an
iscsiNodeIndex of zero.
Other implementations do not use the same tag and/or port for all
nodes; these implementations will create a row in this table for each
(portal, node) tuple, using iscsiNodeIndex to designate the node for
this portal tag and port.
6.6. iscsiInitiatorPortal
The iscsiIntrPortalAttributesTable contains initiator-specific
objects for iSCSI portals. Rows in this table use the same indices
as their corresponding entries in the iscsiPortalAttributesTable. A
row in this table is created when the initiatorTypePortal bit is set
in the iscsiPortalRoles attribute; it is destroyed when this bit is
cleared.
Each row in this table contains a portal group aggregation tag,
indicating which portals an initiator may use together within a
multiple-connection session.
This table will be empty for iSCSI instances that contain only
targets (such as most iSCSI devices).
Bakke, et al. Standards Track [Page 9]
RFC 4544 iSCSI MIB May 2006
Many implementations use the same initiator tag for all nodes
accessing targets via a given portal. These implementations will
create a single row in iscsiIntrPortalAttributeTable, with an
iscsiNodeIndex of zero.
Other implementations do not use the same tag and/or port for all
nodes; these implementations will create a row in this table for each
(portal, node) tuple, using iscsiNodeIndex to designate the node for
this portal tag and port.
6.7. iscsiNode
The iscsiNodeAttributesTable contains a list of iSCSI nodes, each of
which may have an initiator role, a target role, or both.
This table contains the node's attributes that are common to both
roles, such as its iSCSI name and alias string. Attributes specific
to initiators or targets are available in the iscsiTarget and
iscsiInitiator objects. Each row in this table that can fulfill a
target role has a corresponding row in the iscsiTarget table; each
entry that fulfills an initiator role has a row in the iscsiInitiator
table. Nodes such as copy managers that can take on both roles have
a corresponding row in each table.
This table also contains the login negotiations preferences for this
node. These objects indicate the values this node will offer or
prefer in the operational negotiation phase of the login process.
For most implementations, each entry in the table also contains a
RowPointer to the transport table entry in the SCSI MIB module that
this iSCSI node represents. For implementations without a standard
SCSI layer above iSCSI, such as an iSCSI proxy or gateway, this
RowPointer can point to a row in an implementation-specific table
that this iSCSI node represents.
6.8. iscsiTarget
The iscsiTargetAttributesTable contains target-specific attributes
for iSCSI nodes. Each entry in this table uses the same index values
as its corresponding iscsiNode entry.
This table contains attributes used to indicate the last failure that
was (or should have been) sent as a notification.
This table is augmented by the iscsiTargetLoginStatsTable and the
iscsiTargetLogoutStatsTable, which count the numbers of normal and
abnormal logins and logouts to this target.
Bakke, et al. Standards Track [Page 10]
RFC 4544 iSCSI MIB May 2006
6.9. iscsiTgtAuthorization
The iscsiTgtAuthAttributesTable contains an entry for each initiator
identifier that will be allowed to access the target under which it
appears. Each entry contains a RowPointer to a user identity in the
IPS Authorization MIB module, which contains the name, address, and
credential information necessary to authenticate the initiator.
6.10. iscsiInitiator
The iscsiInitiatorAttributesTable contains a list of initiator-
specific attributes for iSCSI nodes. Each entry in this table uses
the same index values as its corresponding iscsiNode entry.
Most implementations will include a single entry in this table,
regardless of the number of physical interfaces the initiator may
use.
This table is augmented by the iscsiInitiatorLoginStatsTable and the
iscsiInitiatorLogoutStatsTable, which count the numbers of normal and
abnormal logins and logouts from this initiator.
6.11. iscsiIntrAuthorization
The iscsiIntrAuthAttributesTable contains an entry for each target
identifier to which the initiator is configured to establish a
session.
Each entry contains a RowPointer to a user identity in the IPS
Authorization MIB module, which contains the name, address, and
credential information necessary to identify (for discovery purposes)
and authenticate the target.
6.12. iscsiSession
The iscsiSessionAttributesTable contains a set of rows that list the
sessions known to be existing locally for each node in each iSCSI
instance.
The session type for each session indicates whether the session is
used for normal SCSI commands or for discovery using the SendTargets
text command. Discovery sessions that do not belong to any
particular node have a node index attribute of zero.
Bakke, et al. Standards Track [Page 11]
RFC 4544 iSCSI MIB May 2006
The session direction for each session indicates whether it is an
Inbound session or an Outbound session. Inbound sessions are from
some other initiator to the target node under which the session
appears. Outbound sessions are from the initiator node under which
the session appears to a target outside this iSCSI instance.
Many attributes may be negotiated when starting an iSCSI session.
Most of these attributes are included in the session object.
Some attributes, such as the integrity and authentication schemes,
have some standard values that can be extended by vendors to include
their own schemes. These contain an object identifier, rather than
the expected enumerated type, to allow these values to be extended by
other MIB modules, such as an enterprise MIB module.
The iscsiSessionStatsTable includes statistics related to
performance; it counts iSCSI data bytes and PDUs.
For implementations that support error recovery without terminating a
session, the iscsiSessionCxnErrorStatsTable contains counters for the
numbers of digest and connection errors that have occurred within the
session.
6.13. iscsiConnection
The iscsiConnectionAttributesTable contains a list of active
connections within each session. It contains the IP addresses and
TCP (or other protocol) ports of both the local and remote sides of
the connection. These may be used to locate other connection-related
information and statistics in the TCP MIB module [RFC4022].
The attributes table also contains a connection state. This state is
not meant to directly map to the state tables included within the
iSCSI specification; they are meant to be simplified, higher-level
definitions of connection state that provide information more useful
to a user or network manager.
No statistics are kept for connections.
6.14. IP Addresses and TCP Port Numbers
The IP addresses in this module are represented by two attributes,
one of type InetAddressType, and the other of type InetAddress.
These are taken from [RFC4001], which specifies how to support
addresses that may be either IPv4 or IPv6.
Bakke, et al. Standards Track [Page 12]
RFC 4544 iSCSI MIB May 2006
The TCP port numbers that appear in a few of the structures are
described as simply port numbers, with a protocol attribute
indicating whether they are TCP ports or something else. This will
allow the module to be compatible with iSCSI over transports other
than TCP in the future.
6.15. Descriptors: Using OIDs in Place of Enumerated Types
The iSCSI MIB module has a few attributes, namely, the digest method
attributes, where an enumerated type would work well, except that an
implementation may need to extend the attribute and add types of its
own. To make this work, this MIB module defines a set of object
identities within the iscsiDescriptors subtree. Each of these object
identities is basically an enumerated type.
Attributes that make use of these object identities have a value that
is an Object Identifier (OID) instead of an enumerated type. These
OIDs can indicate either the object identities defined in this module
or object identities defined elsewhere, such as in an enterprise MIB
module. Those implementations that add their own digest methods
should also define a corresponding object identity for each of these
methods within their own enterprise MIB module, and return its OID
whenever one of these attributes is using that method.
6.16. Notifications
Three notifications are provided. One is sent by an initiator
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -