An optional global-scope identifier for this connectivity unit.
It MUST be a WWN for this connectivity unit
or 16 octets of value zero.
WWN formats requiring fewer than 16 octets
MUST be extended to 16 octets with trailing zero octets,
Left justified, zero filled,
If a WWN is used for connUnitId,
the same WWN MUST be used for connUnitGlobalId.
When a non-zero value is provided,
it SHOULD be persistent across agent and unit resets.
It SHOULD be globally unique.
It SHOULD be one of these FC-PH/PH3 formats:
IEEE (NAA=1)
IEEE Extended (NAA=2)
IEEE Registered (NAA=5).
IEEE Registered extended (NAA=6).
Use of the IEEE formats allows any IEEE-registered vendor
to assure global uniqueness independently.
The following are some references on IEEE WWN formats:
http://standards.ieee.org/regauth/oui/tutorials/fibreformat.html
http://standards.ieee.org/regauth/oui/tutorials/fibrecomp-id.html
If one or more WWNs are associated with the connUnit
via other management methods,
one of them SHOULD be used for connUnitGlobalId.
If there is not a WWN assigned specifically to the connUnit,
there is some merit, though not a requirement,
to using a WWN assigned to (one of)
its permanently attached FC/LAN interface(s).
This can not risk uniqueness, though.
As a counterexample, if your
agent runs in a host and the host has an HBA,
it is quite possible that agent, host, and HBA
will all be distinct connUnits, so the host
and agent can not use the WWN of the HBA.
Another example:
If your hub has a built-in Ethernet port, it
might be reasonable for the hub to use its MAC
address (prefixed with the appropriate
NAA) as its connUnitId. But if the
Ethernet were a replaceable PCCard, the hub
should have an independent ID.
Parsed from file FCMGMT-MIB.mib
Module: FCMGMT-MIB
An optional global-scope identifier for this connectivity unit.
It MUST be a WWN for this connectivity unit
or 16 octets of value zero.
WWN formats requiring fewer than 16 octets
MUST be extended to 16 octets with trailing zero octets,
Left justified, zero filled,
If a WWN is used for connUnitId,
the same WWN MUST be used for connUnitGlobalId.
When a non-zero value is provided,
it SHOULD be persistent across agent and unit resets.
It SHOULD be globally unique.
It SHOULD be one of these FC-PH/PH3 formats:
IEEE (NAA=1)
IEEE Extended (NAA=2)
IEEE Registered (NAA=5).
IEEE Registered extended (NAA=6).
Use of the IEEE formats allows any IEEE-registered vendor
to assure global uniqueness independently.
The following are some references on IEEE WWN formats:
http://standards.ieee.org/regauth/oui/tutorials/fibreformat.html
http://standards.ieee.org/regauth/oui/tutorials/fibrecomp_id.html
If one or more WWNs are associated with the connUnit
via other management methods,
one of them SHOULD be used for connUnitGlobalId.
If there is not a WWN assigned specifically to the connUnit,
there is some merit, though not a requirement,
to using a WWN assigned to (one of)
its permanently attached FC/LAN interface(s).
This can not risk uniqueness, though.
As a counterexample, if your
agent runs in a host and the host has an HBA,
it is quite possible that agent, host, and HBA
will all be distinct connUnits, so the host
and agent can not use the WWN of the HBA.
Another example:
If your hub has a built-in Ethernet port, it
might be reasonable for the hub to use its MAC
address (prefixed with the appropriate
NAA) as its connUnitId. But if the
Ethernet were a replaceable PCCard, the hub
should have an independent ID.
An optional global-scope identifier for this connectivity unit.
It MUST be a WWN for this connectivity unit
or 16 octets of value zero.
WWN formats requiring fewer than 16 octets
MUST be extended to 16 octets with trailing zero octets,
Left justified, zero filled,
If a WWN is used for connUnitId,
the same WWN MUST be used for connUnitGlobalId.
When a non-zero value is provided,
it SHOULD be persistent across agent and unit resets.
It SHOULD be globally unique.
It SHOULD be one of these FC-PH/PH3 formats:
IEEE (NAA=1)
IEEE Extended (NAA=2)
IEEE Registered (NAA=5).
IEEE Registered extended (NAA=6).
Use of the IEEE formats allows any IEEE-registered vendor
to assure global uniqueness independently.
The following are some references on IEEE WWN formats:
http://standards.ieee.org/regauth/oui/tutorials/fibreformat.html
http://standards.ieee.org/regauth/oui/tutorials/fibrecomp_id.html
If one or more WWNs are associated with the connUnit
via other management methods,
one of them SHOULD be used for connUnitGlobalId.
If there is not a WWN assigned specifically to the connUnit,
there is some merit, though not a requirement,
to using a WWN assigned to (one of)
its permanently attached FC/LAN interface(s).
This can not risk uniqueness, though.
As a counterexample, if your
agent runs in a host and the host has an HBA,
it is quite possible that agent, host, and HBA
will all be distinct connUnits, so the host
and agent can not use the WWN of the HBA.
Another example:
If your hub has a built-in Ethernet port, it
might be reasonable for the hub to use its MAC
address (prefixed with the appropriate
NAA) as its connUnitId. But if the
Ethernet were a replaceable PCCard, the hub
should have an independent ID.
Parsed from file FCMGMT-MIB-ipfc-07.txt
Company: None
Module: FCMGMT-MIB
An optional global-scope identifier for this connectivity unit.
It MUST be a WWN for this connectivity unit
or 16 octets of value zero.
WWN formats requiring fewer than 16 octets
MUST be extended to 16 octets with trailing zero octets,
Left justified, zero filled,
If a WWN is used for connUnitId,
the same WWN MUST be used for connUnitGlobalId.
When a non-zero value is provided,
it SHOULD be persistent across agent and unit resets.
It SHOULD be globally unique.
It SHOULD be one of these FC-PH/PH3 formats:
IEEE (NAA=1)
IEEE Extended (NAA=2)
IEEE Registered (NAA=5).
IEEE Registered extended (NAA=6).
Use of the IEEE formats allows any IEEE-registered vendor
to assure global uniqueness independently.
The following are some references on IEEE WWN formats:
http://standards.ieee.org/regauth/oui/tutorials/fibreformat.html
http://standards.ieee.org/regauth/oui/tutorials/fibrecomp_id.html
If one or more WWNs are associated with the connUnit
via other management methods,
one of them SHOULD be used for connUnitGlobalId.
If there is not a WWN assigned specifically to the connUnit,
there is some merit, though not a requirement,
to using a WWN assigned to (one of)
its permanently attached FC/LAN interface(s).
This can not risk uniqueness, though.
As a counterexample, if your
agent runs in a host and the host has an HBA,
it is quite possible that agent, host, and HBA
will all be distinct connUnits, so the host
and agent can not use the WWN of the HBA.
Another example:
If your hub has a built-in Ethernet port, it
might be reasonable for the hub to use its MAC
address (prefixed with the appropriate
NAA) as its connUnitId. But if the
Ethernet were a replaceable PCCard, the hub
should have an independent ID.
connUnitGlobalId OBJECT-TYPE SYNTAX FcGlobalId ACCESS read-only STATUS mandatory DESCRIPTION "An optional global-scope identifier for this connectivity unit. It MUST be a WWN for this connectivity unit or 16 octets of value zero. WWN formats requiring fewer than 16 octets MUST be extended to 16 octets with trailing zero octets, Left justified, zero filled, If a WWN is used for connUnitId, the same WWN MUST be used for connUnitGlobalId. When a non-zero value is provided, it SHOULD be persistent across agent and unit resets. It SHOULD be globally unique. It SHOULD be one of these FC-PH/PH3 formats: IEEE (NAA=1) IEEE Extended (NAA=2) IEEE Registered (NAA=5). IEEE Registered extended (NAA=6). Use of the IEEE formats allows any IEEE-registered vendor to assure global uniqueness independently. The following are some references on IEEE WWN formats: http://standards.ieee.org/regauth/oui/tutorials/fibreformat.html http://standards.ieee.org/regauth/oui/tutorials/fibrecomp-id.html If one or more WWNs are associated with the connUnit via other management methods, one of them SHOULD be used for connUnitGlobalId. If there is not a WWN assigned specifically to the connUnit, there is some merit, though not a requirement, to using a WWN assigned to (one of) its permanently attached FC/LAN interface(s). This can not risk uniqueness, though. As a counterexample, if your agent runs in a host and the host has an HBA, it is quite possible that agent, host, and HBA will all be distinct connUnits, so the host and agent can not use the WWN of the HBA. Another example: If your hub has a built-in Ethernet port, it might be reasonable for the hub to use its MAC address (prefixed with the appropriate NAA) as its connUnitId. But if the Ethernet were a replaceable PCCard, the hub should have an independent ID." ::= { connUnitEntry 2 }
connUnitGlobalId OBJECT-TYPE SYNTAX FcGlobalId ACCESS read-only STATUS mandatory DESCRIPTION "An optional global-scope identifier for this connectivity unit. It MUST be a WWN for this connectivity unit or 16 octets of value zero. WWN formats requiring fewer than 16 octets MUST be extended to 16 octets with trailing zero octets, Left justified, zero filled, If a WWN is used for connUnitId, the same WWN MUST be used for connUnitGlobalId. When a non-zero value is provided, it SHOULD be persistent across agent and unit resets. It SHOULD be globally unique. It SHOULD be one of these FC-PH/PH3 formats: IEEE (NAA=1) IEEE Extended (NAA=2) IEEE Registered (NAA=5). IEEE Registered extended (NAA=6). Use of the IEEE formats allows any IEEE-registered vendor to assure global uniqueness independently. The following are some references on IEEE WWN formats: http://standards.ieee.org/regauth/oui/tutorials/fibreformat.html http://standards.ieee.org/regauth/oui/tutorials/fibrecomp_id.html If one or more WWNs are associated with the connUnit via other management methods, one of them SHOULD be used for connUnitGlobalId. If there is not a WWN assigned specifically to the connUnit, there is some merit, though not a requirement, to using a WWN assigned to (one of) its permanently attached FC/LAN interface(s). This can not risk uniqueness, though. As a counterexample, if your agent runs in a host and the host has an HBA, it is quite possible that agent, host, and HBA will all be distinct connUnits, so the host and agent can not use the WWN of the HBA. Another example: If your hub has a built-in Ethernet port, it might be reasonable for the hub to use its MAC address (prefixed with the appropriate NAA) as its connUnitId. But if the Ethernet were a replaceable PCCard, the hub should have an independent ID." ::= { connUnitEntry 2 }
Vendor: Brocade
Module: FCMGMT-MIB (FAFCMGMT.mib)
Type: TABULAR
Access: read-only
Syntax: FcGlobalId
Automatically extracted from www.mibdepot.com
connUnitGlobalId OBJECT-TYPE SYNTAX FcGlobalId ACCESS read-only STATUS mandatory DESCRIPTION "An optional global-scope identifier for this connectivity unit. It MUST be a WWN for this connectivity unit or 16 octets of value zero. WWN formats requiring fewer than 16 octets MUST be extended to 16 octets with trailing zero octets, Left justified, zero filled, If a WWN is used for connUnitId, the same WWN MUST be used for connUnitGlobalId. When a non-zero value is provided, it SHOULD be persistent across agent and unit resets. It SHOULD be globally unique. It SHOULD be one of these FC-PH/PH3 formats: IEEE (NAA=1) IEEE Extended (NAA=2) IEEE Registered (NAA=5). IEEE Registered extended (NAA=6). Use of the IEEE formats allows any IEEE-registered vendor to assure global uniqueness independently. The following are some references on IEEE WWN formats: http://standards.ieee.org/regauth/oui/tutorials/fibreformat.html http://standards.ieee.org/regauth/oui/tutorials/fibrecomp_id.html If one or more WWNs are associated with the connUnit via other management methods, one of them SHOULD be used for connUnitGlobalId. If there is not a WWN assigned specifically to the connUnit, there is some merit, though not a requirement, to using a WWN assigned to (one of) its permanently attached FC/LAN interface(s). This can not risk uniqueness, though. As a counterexample, if your agent runs in a host and the host has an HBA, it is quite possible that agent, host, and HBA will all be distinct connUnits, so the host and agent can not use the WWN of the HBA. Another example: If your hub has a built-in Ethernet port, it might be reasonable for the hub to use its MAC address (prefixed with the appropriate NAA) as its connUnitId. But if the Ethernet were a replaceable PCCard, the hub should have an independent ID." ::= { connUnitEntry 2 }
connUnitGlobalId OBJECT-TYPE SYNTAX FcGlobalId ACCESS read-only STATUS mandatory DESCRIPTION "An optional global-scope identifier for this connectivity unit. It MUST be a WWN for this connectivity unit or 16 octets of value zero. WWN formats requiring fewer than 16 octets MUST be extended to 16 octets with trailing zero octets, Left justified, zero filled, If a WWN is used for connUnitId, the same WWN MUST be used for connUnitGlobalId. When a non-zero value is provided, it SHOULD be persistent across agent and unit resets. It SHOULD be globally unique. It SHOULD be one of these FC-PH/PH3 formats: IEEE (NAA=1) IEEE Extended (NAA=2) IEEE Registered (NAA=5). IEEE Registered extended (NAA=6). Use of the IEEE formats allows any IEEE-registered vendor to assure global uniqueness independently. The following are some references on IEEE WWN formats: http://standards.ieee.org/regauth/oui/tutorials/fibreformat.html http://standards.ieee.org/regauth/oui/tutorials/fibrecomp_id.html If one or more WWNs are associated with the connUnit via other management methods, one of them SHOULD be used for connUnitGlobalId. If there is not a WWN assigned specifically to the connUnit, there is some merit, though not a requirement, to using a WWN assigned to (one of) its permanently attached FC/LAN interface(s). This can not risk uniqueness, though. As a counterexample, if your agent runs in a host and the host has an HBA, it is quite possible that agent, host, and HBA will all be distinct connUnits, so the host and agent can not use the WWN of the HBA. Another example: If your hub has a built-in Ethernet port, it might be reasonable for the hub to use its MAC address (prefixed with the appropriate NAA) as its connUnitId. But if the Ethernet were a replaceable PCCard, the hub should have an independent ID." ::= { connUnitEntry 2 }
Internet Assigned Numbers Authority
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.3.94.1.6.1.1 | connUnitId | 0 | 0 | The unique identification for this connectivity unit among those within this proxy domain. The value MUST be unique within the pr… |
| 1.3.6.1.3.94.1.6.1.3 | connUnitType | 0 | 0 | The type of this connectivity unit. |
| 1.3.6.1.3.94.1.6.1.4 | connUnitNumports | 0 | 0 | Number of physical ports in the connectivity unit (internal/embedded, external). |
| 1.3.6.1.3.94.1.6.1.5 | connUnitState | 0 | 0 | Overall state of the connectivity unit. |
| 1.3.6.1.3.94.1.6.1.6 | connUnitStatus | 0 | 0 | Overall status of the connectivity unit. The goal of this object is to be the single poll point to check the status of the connu… |
| 1.3.6.1.3.94.1.6.1.7 | connUnitProduct | 0 | 0 | The connectivity unit vendor's product model name. |
| 1.3.6.1.3.94.1.6.1.8 | connUnitSn | 0 | 0 | The serial number for this connectivity unit. |
| 1.3.6.1.3.94.1.6.1.9 | connUnitUpTime | 0 | 0 | The number of centiseconds since the last unit initialization. |
| 1.3.6.1.3.94.1.6.1.10 | connUnitUrl | 0 | 0 | URL to launch a management application, if applicable. Otherwise empty string. In a standalone unit, this would be the same as the… |
| 1.3.6.1.3.94.1.6.1.11 | connUnitDomainId | 0 | 0 | 24 bit Fibre Channel address ID of this connectivity unit, right justified with leading zero's if required. This should be set to… |
| 1.3.6.1.3.94.1.6.1.12 | connUnitProxyMaster | 0 | 0 | A value of 'yes' means this is the proxy master unit for a set of managed units. For example, this could be the only unit with a … |
| 1.3.6.1.3.94.1.6.1.13 | connUnitPrincipal | 0 | 0 | Whether this connectivity unit is the principal unit within the group of fabric elements. If this value is not applicable, return… |
| 1.3.6.1.3.94.1.6.1.14 | connUnitNumSensors | 0 | 0 | Number of sensors in the connUnitSensorTable. |
| 1.3.6.1.3.94.1.6.1.15 | connUnitStatusChangeTime | 0 | 0 | The sysuptime timestamp in centiseconds at which the last status change occurred. |
| 1.3.6.1.3.94.1.6.1.16 | connUnitConfigurationChangeTime | 0 | 0 | The sysuptime timestamp in centiseconds at which the last configuration change occurred. |
| 1.3.6.1.3.94.1.6.1.17 | connUnitNumRevs | 0 | 0 | The number of revisions in the connUnitRevsTable. |
| 1.3.6.1.3.94.1.6.1.18 | connUnitNumZones | 0 | 0 | Number of zones defined in connUnitZoneTable. |
| 1.3.6.1.3.94.1.6.1.19 | connUnitModuleId | 0 | 0 | This is a unique id, persistent between boots, that can be used to group a set of connUnits together into a module. The intended … |
| 1.3.6.1.3.94.1.6.1.20 | connUnitName | 0 | 0 | A display string containing a name for this connectivity unit. This object value should be persistent between boots. |
| 1.3.6.1.3.94.1.6.1.21 | connUnitInfo | 0 | 0 | A display string containing information about this connectivity unit. This object value should be persistent between boots. |
| 1.3.6.1.3.94.1.6.1.22 | connUnitControl | 0 | 0 | This object is used to control the addressed connUnit. NOTE: 'Cold Start' and 'Warm Start' are as defined in MIB II and are not m… |
| 1.3.6.1.3.94.1.6.1.23 | connUnitContact | 0 | 0 | Contact information for this connectivity unit. Persistent across boots. |
| 1.3.6.1.3.94.1.6.1.24 | connUnitLocation | 0 | 0 | Location information for this connectivity unit.Persistent across boots. |
| 1.3.6.1.3.94.1.6.1.25 | connUnitEventFilter | 0 | 0 | This value defines the event severity that will be logged by this connectivity unit. All events of severity less than or equal to… |
| 1.3.6.1.3.94.1.6.1.26 | connUnitNumEvents | 0 | 0 | Number of events currently in the connUnitEventTable. |
| 1.3.6.1.3.94.1.6.1.27 | connUnitMaxEvents | 0 | 0 | Max number of events that can be defined in connUnitEventTable. |
| 1.3.6.1.3.94.1.6.1.28 | connUnitEventCurrID | 0 | 0 | The last used event id (connUnitEventIndex). |
| 1.3.6.1.3.94.1.6.1.29 | connUnitFabricID | 0 | 0 | A globally unique value to identify the fabric that this ConnUnit belongs to, otherwise empty string. This would typically be equ… |
| 1.3.6.1.3.94.1.6.1.30 | connUnitNumLinks | 0 | 0 | The number of links in the link table. |
| 1.3.6.1.3.94.1.6.1.31 | connUnitVendorId | 0 | 0 | The connectivity unit vendor's name. |