MIB Discovery
1930 modules enregistrés
Chemin
MIX : 1 (iso). 3 (org). 6 (dod). 1 (internet). 2 (mgmt). 1 (mib-2). 159 (t11FabricLockMIB). 1 (t11FLockMIBObjects). 1 (t11FLockConfiguration). 1 (t11FLockTable). 1 (t11FLockEntry)
OID : 1.3.6.1.2.1.159.1.1.1.1
TXT : iso. org. dod. internet. mgmt. mib-2. t11FabricLockMIB. t11FLockMIBObjects. t11FLockConfiguration. t11FLockTable. t11FLockEntry
Enfants
Détails
OID1.3.6.1.2.1.159.1.1.1.1
Module T11-FC-FABRIC-LOCK-MIB (ietf)
Nomt11FLockEntry
Statuscurrent
DescriptionEach entry contains information specific to a current Fabric lock set up by a particular 'managing' switch on a particular Fabric. The 'managing switch' is identified by values of fcmInstanceIndex and fcmSwitchIndex. Server sessions for several different types of servers are defined in FC-GS-5. The behavior of a server with respect to commands received within a server session is specified for each type of server. For some types, parameter changes can only be made within the context of a session, and the setting up of a session requires that the Fabric be locked. A Fabric is locked by one switch, called the 'managing' switch, sending Acquire Change Authorization (ACA) requests to all other switches in the Fabric. For other applications, a Fabric lock is established by the 'managing' switch sending Enhanced Acquire Change Authorization (EACA) requests to other switches in the Fabric. Each EACA request includes an Application_ID value to identify the application requesting the lock. For the benefit of this MIB module, a distinct value of Application_ID has also been assigned/reserved (see ANSI INCITS T11/06-679v0, titled 'FC-SW-5 Letter to T11.5') as a means of distinguishing locks established via Acquire Change Authorization (ACA) requests. This additional assignment allows an Application_ID to be used to uniquely identify any active lock amongst all those established by either an EACA or an ACA. Whenever a Fabric is locked, by the sending of either an ACA or an EACA, a row gets created in the representation of this table for the 'managing' switch. In order to process SNMP SetRequests that make parameter changes for the relevant types of servers (e.g., to the Zoning Database), the SNMP agent must get serialized access to the Fabric (for the relevant type of management data), i.e., the Fabric must be locked by creating an entry in this table via an SNMP SetRequest. Creating an entry in this table via an SNMP SetRequest causes an ACA or an EACA to be sent to all other switches in the Fabric. The value of t11FLockApplicationID for such an entry determines whether an ACA or an EACA is sent. If an entry in this table is created by an SNMP SetRequest, the value of the t11FLockInitiatorType object in that entry will normally be 'snmp'. A row for which the value of t11FLockInitiatorType is not 'snmp' cannot be modified via SNMP. In particular, it cannot be deleted via t11FLockRowStatus. Note that it's possible for a row to be created by an SNMP SetRequest, but for the setup of the lock to fail, and immediately thereafter be replaced by a lock successfully set up by some other means; in such a case, the value of t11FLockInitiatorType would change as and when the lock was set up by the other means, and so the row could not thereafter be deleted via t11FLockRowStatus. FC-GS-5 mentions various error situations in which a Fabric lock is released so as to avoid a deadlock. In such situations, the agent removes the corresponding row in this table as and when the lock is released. This can happen for all values of t11FLockInitiatorType.