smsubnetprotection Command
Manages the secret M_Key.
Syntax
smsubnetprotection subcommand
[–h]
This hardware command has subcommands that determine its functionality.
This table describes the subcommands and provides
their syntax.
|
|
start
[–force][–addonly|–deleteonly][–override-inconsistent-partition-configurations][–override-unavailable-smnodes][–tid]
|
Initiates a new configuration based upon a currently
used configuration. Use the –force
option or –override-unavailable-smnodes
option to bypass the partition daemon check.
|
list active|modified
|
Displays a list of active secret M_Keys, the current
secret M_Key, and the enabled status, or displays a list
of pending M_Keys and the M_Key to be assigned to
current status.
|
listlocalmkey
|
Displays the current local M_Key for an I4 switch chip
without a corresponding Subnet Manager and its
status.
|
listcurrenttid
|
Lists the current transaction ID.
|
setlocalsecretmkey
m_key
|
Sets the secret M_Key locally for an I4 switch chip
without a corresponding Subnet Manager.
|
clearlocalmkey
|
Clears the local secret M_Key.
|
add m_key [–tid
tid]
|
Adds an M_Key to the configuration.
|
delete m_key
[–tid
tid]
|
Deletes an M_Key from the configuration.
|
undo [–tid
tid]
|
Reverts the previous add,
delete, or
set-current operation.
|
set-current m_key
[–tid
tid]
|
Sets the current M_Key.
|
commit
[–force][–override-inconsistent-partition-configurations][–override-unavailable-smnodes][–tid
tid]
|
Commits the modified configuration to become the
active configuration. Use the –force
option or –override-unavailable-smnodes
option to bypass the partition daemon check. See Options.
|
abort [–tid
tid]
|
Abruptly ends the configuration session. All modified
configuration information is lost, and the active
configuration remains unchanged.
|
setreplicationpassword
password [–tid
tid]
|
Configures the replication (and encryption)
password.
|
enablesecretmkey
[–force][–override-inconsistent-partition-configurations][–override-unavailable-smnodes]
|
Enables secret M_Key functionality. Use the
–force option or
–override-unavailable-smnodes option
to bypass the partition daemon check. See Options.
|
disablesecretmkey
[–force][–override-inconsistent-partition-configurations][–override-unavailable-smnodes]
|
Disables secret M_Key functionality. Use the
–force option or
–override-unavailable-smnodes option
to bypass the partition daemon check. See Options.
|
|
where:
-
m_key is the management key (16
hexadecimal digits).
-
tid is the transaction ID
(0 to 4294967295).
-
password is encryption string for M_Key
replication (8 alphanumeric characters).
Description
This hardware command manages the secret M_Key and its implementation. The
secret M_Key is a passphrase used by trusted Subnet Managers to securely
perform activities (enabling ports, setting parameters, and so on) on the I4
switch chips as well as any end node in the InfiniBand fabric.
A readable M_Key is an M_Key operating in a mode, where the node that
possesses the M_Key permits the value of the M_Key to be read through
in-band operations on the InfiniBand fabric, without first specifying the
current readable M_Key value. The secret M_Key is an M_Key that cannot be
obtained in-band by way of the InfiniBand fabric without first knowing the
current secret M_Key value.
Use the smsubnetprotection command and its subcommands
to create and manage the list of secret M_Keys. When configuring a list of
secret M_Keys, you first enable secret M_Key functionality with the
enablesecretmkey subcommand. Then you initiate the
configuration session on the master Subnet Manager with the
smsubnetprotection start command. During the session,
you add or delete secret M_Keys to the configuration, set the current secret
M_Key, and list the M_Keys configured.
Note -
There is a maximum of 10 secret M_Keys for the configuration.
To end the session, you must use the smsubnetprotection
commit command to make the configuration active. Once
committed, the configuration is automatically distributed to all Subnet
Managers in the InfiniBand fabric.
Note -
You cannot both add and delete secret M_Keys within a single
configuration session. You must perform these actions in separate
configuration sessions.
Should a local secret M_Key be created for an I4 switch chip without a
corresponding Subnet Manager, that secret M_Key is only recognized by that
I4 switch chip, and is unrecognized by the other I4 switch chips in the
InfiniBand fabric.
Because of the complexity of the secret M_Key functionality, this table
describes the impact of certain scenarios and actions you can take.
|
|
Setting up secret M_Key in a mixed firmware
fabric.
|
If the master Subnet Manager has firmware 2.1, only
other Subnet Managers with firmware 2.1 can administrate
the fabric. For Subnet Managers with firmware 2.0 or
lower, the fabric “disappears”.
If the master Subnet Manager has firmware 2.0 or
lower, you can only set up local secret M_Keys for the
I4 switch chips on their respective Subnet Managers with
firmware 2.1.
Both situations are unsupported and not recommended.
|
Downgrading firmware after secret M_Key has been
enabled.
|
If the master Subnet Manager is downgraded to firmware
2.0 or lower and there is a standby Subnet Manager with
firmware 2.1, the secret M_Key is maintained through the
standby Subnet Manager during the master Subnet
Manager's reboot. After the reboot, the situation
becomes as in the first scenario.
If you downgrade any other Subnet Manager to firmware
2.0 or lower, the situation becomes as in the first
scenario.
Before you downgrade any firmware, disable secret
M_Key.
Note -
Readable M_Key is not affected by a downgrade from
firmware 2.1 to 2.0.
|
Upgrading from a lower firmware version.
|
Do not enable secret M_Key until all Subnet Managers
in the fabric are at firmware version 2.1 or
higher.
|
Introducing a new Subnet Manager with firmware 2.1 or
higher, yet no secret M_Key policy, into a secret M_Key
fabric.
|
Before introducing the new Subnet Manager to the
fabric:
-
Disable the new Subnet Manager.
-
Set the new Subnet Manager priority to the
lowest.
-
Update the smnodes file with the
smnodes command.
-
Enable the new Subnet Manager.
After introducing the new Subnet Manager to the
fabric:
-
Update the fabric configuration with the
fdconfig command.
-
Update the fabric mapping with the
createfabric command.
-
Perform a smpartition
start, then smpartition
commit, then smsubnetprotection
start, and finally,
smsubnetprotection commit from
the master Subnet Manager
-
Return the priority of the new Subnet Manager
to its previous value.
|
Secret M_Key values are mismatched.
|
If you add a Subnet Manager with one set of secret
M_Keys to a fabric with a different set of secret
M_Keys, the added Subnet Manager is not recognized.
Before introducing the new Subnet Manager to the
fabric:
-
Update the fabric’s master Subnet Manager's
list of known secret M_Keys to include the secret
M_Keys already configured for the new Subnet
Manager, with the smsubnetprotection
add command.
-
Do not change the current secret M_Key.
-
Disable the new Subnet Manager.
-
Set the new Subnet Manager priority to the
lowest.
-
Update the smnodes file with the
smnodes command.
-
Enable the new Subnet Manager.
After introducing the new Subnet Manager to the
fabric:
-
Update the fabric configuration with the
fdconfig command.
-
Update the fabric mapping with the
createfabric command.
-
Perform a smpartition
start, then smpartition
commit, then smsubnetprotection
start, and finally,
smsubnetprotection commit from
the master Subnet Manager
-
Set the secret M_key policy as desired from
the master Subnet Manager.
-
Return the priority of the new Subnet Manager
to its previous value.
|
Merging two or more subnets into one fabric.
|
If each subnet is configured with different secret
M_Key policies, then the subnets will not
“see” each other and will act
independently.
If one subnet is without a secret M_Key policy, then
the subnet with a secret M_Key policy controls the
subnet without.
If each subnet is configured with identical secret
M_Key policies, they merge into a single subnet.
Before physically merging the subnets:
-
Set the priority of one master Subnet Manager
to lower than the other.
-
Configure the soon-to-be master Subnet Manager
of the combined subnets with partition information
from both subnets with the
smpartition command.
-
Update the soon-to-be master Subnet Manager's
list of known secret M_Keys to include the secret
M_Keys already configured for the other subnet,
with the smsubnetprotection add
command.
-
Do not change the current secret M_Key.
After physically merging the subnets:
-
Update the smnode files for all smnodes of
both subnets with the smnodes
command.
-
Configure both subnets with the new fabric
configuration with the fdconfig
command.
-
Correlate both subnets to the new fabric
mapping with the createfabric
command.
-
Perform a smpartition
start, then smpartition
commit, then smsubnetprotection
start, and finally,
smsubnetprotection commit from
the now master Subnet Manager.
-
Set the secret M_key policy as desired from
the master Subnet Manager.
|
|
This table describes each of the columns of the output of the
smsubnetprotection command.
|
|
Mkey
|
Secret M_Keys provided by the user for trusted
devices.
|
Untrusted Mkey
|
Secret M_Keys generated from user input, for untrusted
devices.
|
Smkey
|
SMKeys are used in communication between the Subnet
Managers.
|
Attribute
|
The attribute of the M_Key.
|
|
The smsubnetprotection command is available from the
/SYS/Fabric_Mgmt Linux shell target of the Oracle
ILOM CLI interface.
Options
This table describes the options to the
smsubnetprotection command and their purposes.
|
|
–force
|
Specifies the action to bypass the partition daemon
check and perform the operation even though not all
smnodes are available or communicating with the
management network. The –force option is
synonymous with the
–override-unavailable-smnodes
option.
|
–addonly
|
Specifies that the session is only to add secret
M_Keys to the configuration.
|
–deleteonly
|
Specifies that the session is only to delete secret
M_Keys from the configuration.
|
–override-inconsistent-partition-configurations
|
Specifies that the check for partition consistency
across smnodes is bypassed. Before updating the secret
M_Key configuration, all smnodes to use that secret
M_Key must have the same partition configuration. If
not, the user is warned of such situation during the
secret M_Key configuration update. This option overrides
the check, and permits the secret M_Key configuration to
be used, regardless of the consequences. Use of this
option compromises the integrity of your fabric.
|
–override-unavailable-smnodes
|
Specifies the action to bypass the partition daemon
check and perform the operation even though not all
smnodes are available or communicating with the
management network. The
–override-unavailable-smnodes option
is synonymous with the –force
option.
|
–tid
|
Specifies the transaction ID. The transaction ID adds
an additional layer of security to the
smsubnetprotection command. The
identifier is a 32-bit unsigned integer, returned when
the secret M_Key configuration is created
(smsubnetprotection start) with
the –tid option. This
identifier is then required for all subsequent actions
to the secret M_Key configuration. Use of the
transaction ID mediates changes to the secret M_Key
configuration by multiple users.
|
|
Example
This example shows how to display the active secret M_Keys with the
smsubnetprotection command.
FabMan@switch_name->smsubnetprotection list active
# File_format_version_number 1
# Sun DCS IB mkey config file
# This file is generated, do not edit
# secretmkey=enabled
# nodeid=o4nm2-m36-6
# time=15 Sep 03:54:46
# checksum=378d9b09744e1d8b8ba6ae868c99d0c9
#! commit_number : 3
Mkey Untrusted Mkey Smkey Attribute
------------------ ------------------ ------------------ ---------
0x00abcdefabcdef01 0x1aa45124fee612ae 0x15fc26aea300f831
0x00abcdefabcdef02 0x4ccd8230de6cd348 0x3fc7e6ad701a8a2a
0x00abcdefabcdef03 0x9baa1debcc74de5e 0x1b253003600d137b C
FabMan@switch_name->