Go to main content
Sun Datacenter InfiniBand Switch 36 Product Notes for Firmware Version 2.1

Exit Print View

Updated: March 2017
 
 

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.

Subcommand Syntax
Description
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.

Scenario
Impact and Actions
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:

  1. Disable the new Subnet Manager.

  2. Set the new Subnet Manager priority to the lowest.

  3. Update the smnodes file with the smnodes command.

  4. Enable the new Subnet Manager.

After introducing the new Subnet Manager to the fabric:

  1. Update the fabric configuration with the fdconfig command.

  2. Update the fabric mapping with the createfabric command.

  3. Perform a smpartition start, then smpartition commit, then smsubnetprotection start, and finally, smsubnetprotection commit from the master Subnet Manager

  4. 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:

  1. 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.

  2. Do not change the current secret M_Key.

  3. Disable the new Subnet Manager.

  4. Set the new Subnet Manager priority to the lowest.

  5. Update the smnodes file with the smnodes command.

  6. Enable the new Subnet Manager.

After introducing the new Subnet Manager to the fabric:

  1. Update the fabric configuration with the fdconfig command.

  2. Update the fabric mapping with the createfabric command.

  3. Perform a smpartition start, then smpartition commit, then smsubnetprotection start, and finally, smsubnetprotection commit from the master Subnet Manager

  4. Set the secret M_key policy as desired from the master Subnet Manager.

  5. 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:

  1. Set the priority of one master Subnet Manager to lower than the other.

  2. Configure the soon-to-be master Subnet Manager of the combined subnets with partition information from both subnets with the smpartition command.

  3. 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.

  4. Do not change the current secret M_Key.

After physically merging the subnets:

  1. Update the smnode files for all smnodes of both subnets with the smnodes command.

  2. Configure both subnets with the new fabric configuration with the fdconfig command.

  3. Correlate both subnets to the new fabric mapping with the createfabric command.

  4. Perform a smpartition start, then smpartition commit, then smsubnetprotection start, and finally, smsubnetprotection commit from the now master Subnet Manager.

  5. 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.

Column Heading
Description
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.

  • C – The current secret M_Key.

  • S – The standby secret M_Key about to become current.

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.

Option
Purpose
–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->
Copyright © 2013, 2017, Oracle and/or its affiliates. All rights reserved. Legal Notices
Previous
Next