A server in-band IPMI communication method and system

Abstract

This invention discloses a server in-band IPMI communication method and system, relating to the field of server BMC technology. The server in-band IPMI communication method includes the following steps: generating an identifier for each node's operating system (OS) and sending it to the Baseboard Management Controller (BMC) for storage; when accessing the Intelligent Platform Management Interface (IPMI) across node OSs, the BMC verifies the identifier of the requesting node OS based on its stored node OS identifiers to determine whether access is permitted. This invention improves the robustness and security of server-side in-band IPMI access across node OSs.

Description

Technical Field

[0001] This invention relates to the field of server BMC technology, and more specifically to a server in-band IPMI communication method and system. Background Technology

[0002] In server management, in addition to out-of-band BMC (Board Management Controller) management, it also supports communication between the OS (Operating System) and BMC through the KCS channel of in-band IPMI (Intelligent Platform Management Interface). At this time, the IPMI driver is loaded under the OS, and IPMI communication with the BMC is carried out through the driver, including channel initialization and BMC interaction kernel thread.

[0003] In the current solution, the BMC management plane is accessed via KCS from the OS. Unlike out-of-band access, the IPMI protocol allows access to BMC's IPMI-related monitoring and management functions without requiring a BMC username and password. These functions include restarting the BMC, restarting the server, sensor detection, server monitoring logs, server alarm logs, and server SOL functions. While this solution is relatively secure on a single OS system, it presents significant security vulnerabilities when two or more independent OS nodes share a single BMC for monitoring. For example, a node running OS1 could access OS2's SOL output information, view business configuration output information, BMC monitoring and alarm information, sensor information, etc., without knowing OS2's system username and password. Furthermore, it could directly restart or shut down OS2, which constitutes a major security vulnerability. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the first aspect of this invention provides a server in-band IPMI communication method, which improves the robustness and security of server cross-node OS in-band IPMI access.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0006] A server in-band IPMI communication method, the method comprising the following steps:

[0007] An identifier for the operating system (OS) of each node is generated and sent to the baseboard management controller (BMC) for storage.

[0008] When accessing the Intelligent Platform Management Interface (IPMI) across node OSs, BMC verifies the identifier of the requesting node OS based on the identifier of the node OS stored in its own memory to determine whether access is permitted.

[0009] In some embodiments, when accessing the Intelligent Platform Management Interface (IPMI) across node OSs, the BMC performs identifier verification on the requesting node OS based on its stored node OS identifiers to determine whether access is permitted, including:

[0010] When a node OS receives an IPMI access request, it determines whether the request is a cross-node OS access to IPMI.

[0011] If it is a cross-node OS access to IPMI, send an IPMI access request to BMC with the identifier of the different node OS added;

[0012] After determining that the BMC is accessing IPMI across node OSs, it compares the identifier of the node OS stored in its own database with the identifier of the different node OS. If they are the same, the access is allowed.

[0013] In some embodiments, after the BMC determines that it is accessing IPMI across node OSs, before comparing whether the identifiers of the node OS stored in its own memory are the same as the identifiers of the different node OSs, the following steps are also included:

[0014] BMC checks the configured global switch for cross-node access policy. If the global switch is set to disallow access, the program exits.

[0015] If the global switch is set to allow access, then check the IPMI access resource policy switch of the node OS. If the IPMI access resource policy switch is set to disallow access, then the program exits.

[0016] If the IPMI access resource policy switch is set to allow access, then compare the identifier of the node OS stored in itself with the identifier of the OS of other nodes to see if they are the same.

[0017] In some embodiments, the IPMI access resource policy switch includes SOL, sensor viewing, alarm query, node restart, and node shutdown switches.

[0018] In some embodiments, it also includes:

[0019] When the BMC determines that the identifier of the node OS it stores is different from the identifier of the different node OS, the BMC records the illegal access security log of the different node OS IPMI.

[0020] When the number of recorded accesses exceeds the cross-node illegal access threshold configured in the BMC, a cross-node IPMI access security alarm is triggered in the BMC.

[0021] In some embodiments, generating the identifier of each node's operating system (OS) includes:

[0022] Use the unique MD5 checksum of the node hardware as the identifier of the node OS.

[0023] In some embodiments, it also includes:

[0024] Configure the control routing chip connected to the BMC;

[0025] Each node CPU is connected to the control routing chip via two GPIOs. One GPIO is used for channel switching selection, and the other GPIO is used to indicate the status of the control routing chip.

[0026] A second aspect of the present invention provides a server in-band IPMI communication system that improves the robustness and security of server cross-node OS in-band IPMI access.

[0027] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0028] A server in-band IPMI communication system, comprising:

[0029] Baseboard Management Controller (BMC);

[0030] Multiple nodes are used to communicate with the BMC via IPMI, and the IPMI driver module of the OS of each node is used to generate the identifier of the OS of each node and send it to the baseboard management controller (BMC) for storage.

[0031] The BMC is also used to verify the identifier of the requesting node OS based on the identifier of the node OS stored in its own memory when accessing the Intelligent Platform Management Interface (IPMI) across node OSs, in order to determine whether access is allowed.

[0032] In some embodiments, when the BMC accesses the Intelligent Platform Management Interface (IPMI) across node OSs, it performs an identifier verification on the requesting node OS based on the identifier of the node OS stored in its own memory to determine whether access is allowed, including:

[0033] When a node OS receives an IPMI access request, it determines whether the request is a cross-node OS access to IPMI.

[0034] If it is a cross-node OS access to IPMI, send an IPMI access request to BMC with the identifier of the different node OS added;

[0035] After determining that the BMC is accessing IPMI across node OSs, it compares the identifier of the node OS stored in its own database with the identifier of the different node OS. If they are the same, the access is allowed.

[0036] In some embodiments, after the BMC determines that it is accessing IPMI across node OSs, before comparing whether the identifiers of the node OS stored in its own memory are the same as the identifiers of the different node OSs, the BMC is further configured to:

[0037] Check the configured global switch for cross-node access policy. If the global switch is set to disallow access, the program will exit.

[0038] If the global switch is set to allow access, then check the IPMI access resource policy switch of the node OS. If the IPMI access resource policy switch is set to disallow access, then the program exits.

[0039] If the IPMI access resource policy switch is set to allow access, then compare the identifier of the node OS stored in itself with the identifier of the OS of other nodes to see if they are the same.

[0040] Compared with the prior art, the advantages of the present invention are as follows:

[0041] The server-side in-band IPMI communication method of this invention utilizes a multi-channel LPC or ESPI channel mux switch chip to enable multi-node CPUs to share a single BMC chip for multi-node OS in-band IPMI communication. Status checks and control of the multi-channel switch chip are added to the IPMI driver module of the node OS, facilitating IPMI communication between the node OS and the BMC chip. Simultaneously, an MD5 checksum based on node hardware is added as a security verification value for cross-node IPMI access, incorporated into the IPMI parameters for cross-node IPMI access. The BMC automatically records the security verification MD5 values ​​of each node and verifies them against the MD5 parameters of the IPMI request for cross-node OS access, thereby achieving secure cross-node in-band IPMI communication and access. Furthermore, to enhance system flexibility and security, users can configure a global master switch for cross-node IPMI access and access control policies for different types of IPMI resources through the BMC. Users can also configure cross-node IPMI access security thresholds through the BMC, automatically recording unauthorized cross-node IPMI access security logs and triggering security alarms, improving system maintainability and security. Attached Figure Description

[0042] Figure 1 This is a flowchart of the server in-band IPMI communication method in an embodiment of the present invention;

[0043] Figure 2 yes Figure 1 Flowchart of step S2;

[0044] Figure 3 This is a structural block diagram of the server in-band IPMI communication system in an embodiment of the present invention;

[0045] Figure 4 This is the node OS IPMI initialization process in this embodiment of the invention;

[0046] Figure 5 This is the node OS IPMI request processing flow in this embodiment of the invention;

[0047] Figure 6 This is the BMC IPMI initialization process in this embodiment of the invention;

[0048] Figure 7 This is the BMC response node OS IPMI access process in this embodiment of the invention;

[0049] Figure 8 This is the BMC IPMI node access security log processing flow in this embodiment of the invention. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0051] See Figure 1 As shown in the figure, an embodiment of the present invention discloses a server in-band IPMI communication method, which includes the following steps:

[0052] S1. Generate the identifier of the operating system (OS) for each node and send it to the baseboard management controller (BMC) for storage.

[0053] S2. When accessing the Intelligent Platform Management Interface (IPMI) across node OSs, the BMC verifies the identifier of the requesting node OS based on the identifier of the node OS stored in its own memory to determine whether access is allowed.

[0054] For specific implementation details, please refer to [link / reference]. Figure 2 As shown, step S2 specifically includes the following steps:

[0055] S21. When a node OS receives an IPMI access request, it determines whether the request is a cross-node OS access to IPMI.

[0056] S22. If it is a cross-node OS access to IPMI, send an IPMI access request to BMC with the identifier of the different node OS.

[0057] S23. After determining that the IPMI access is a cross-node OS access, BMC compares the identifier of the node OS stored in itself with the identifier of the different node OS. If they are the same, access is allowed.

[0058] It's worth noting that currently, in-band IPMI communication lacks a unique node OS identifier, and the BMC cannot distinguish node OSs using a unique identifier. Users typically can only log in to the node OS using their respective OS username and password. However, currently, IPMI access under the in-band OS does not require entering the BMC username and password; users can directly access the BMC's resources and capabilities without any restrictions on cross-node access, posing a significant security risk.

[0059] To address this issue, this embodiment of the invention uses the unique MD5 checksum of the node hardware as the unique identifier of the node OS and applies it to the node's IPMI communication. Simultaneously, after the system boots up, the nodes automatically report their respective MD5 checksums to the BMC, which stores them in the storage medium.

[0060] It is understood that the embodiments of the present invention optimize the IPMI driver under the node OS and the IPMI module code of BMC, and add security verification parameters for cross-node IPMI access. By using the MD5 checksum of cross-node IPMI access as an additional parameter for IPMI cross-node access, the application security of cross-node IPMI access can be improved.

[0061] In some embodiments, after the BMC determines that it is accessing IPMI across node OSs, before comparing whether the identifiers of the node OS stored in its own memory are the same as the identifiers of the different node OSs, the following steps are also included:

[0062] BMC checks the global switch of the configured inter-node access policy. If the global switch is set to disallow access, the program exits. If the global switch is set to allow access, it checks the IPMI access resource policy switch of the node OS. If the IPMI access resource policy switch is set to disallow access, the program exits. If the IPMI access resource policy switch is set to allow access, it compares whether the identifier of the node OS stored in itself is the same as the identifier of the inter-node OS.

[0063] In other words, based on the above configuration, different security level policies can be set for different IPMI accesses across node OSs, including security switch policies for different IPMI accesses such as SOL, sensor viewing, alarm query, node restart, and node shutdown. It supports overall switch policy control for different IPMI accesses across node OSs, improving the flexibility and security of server cross-node IPMI access.

[0064] In addition, when the BMC determines that the identifier of the node OS it stores is different from the identifier of the different node OS, the BMC records the security log of illegal IPMI access of the different node OS; when the number of records exceeds the cross-node illegal access threshold configured by the BMC, the BMC triggers the security alarm for illegal IPMI access of the different node.

[0065] Currently, the server's in-band IPMI access does not support logging illegal access security logs or setting security thresholds, and cannot automatically trigger node IPMI access security alarms, resulting in poor system security and maintainability.

[0066] To address this issue, this invention adds a security log function for illegal cross-node IPMI access in the BMC, and also supports user configuration of security thresholds for illegal cross-node IPMI access. When illegal cross-node IPMI access exceeds the threshold, a security alarm will be automatically triggered, thereby improving the maintainability and security of illegal cross-node IPMI access on the server.

[0067] Furthermore, currently, BMC chips generally only have one LPC or ESPI interface to communicate with the server CPU, and do not support multiple nodes sharing a single BMC chip for node IPMI access. Each node needs to add a BMC chip to achieve multi-node IPMI in-band communication, which results in high hardware costs and complexity, and also wastes BMC resources.

[0068] This invention provides a hardware circuit device for IPMI in-band communication where multiple nodes share a single BMC. By controlling the routing chip through a multi-channel LPC or ESPI interface, it enables multiple nodes to share a single BMC chip for in-band IPMI communication. Simultaneously, the software can automatically identify and control the IPMI channel, thus realizing in-band IPMI communication where multiple nodes share a single BMC chip.

[0069] Specifically, see Figure 3 As shown, the first part describes a hardware device for multiple nodes to share a single BMC chip for in-band IPMI communication. Different node CPUs are connected to the MUX chip via two GPIOs. One GPIO is used for channel selection and is configured as an output pin for the CPU. Its default high level indicates that the MUX chip channel is not selected. When the output is low, it indicates that the channel is selected, allowing LPC or ESPI communication with the BMC. The other GPIO is used for MUX chip status output, indicating the BUSY state. It is configured as an input pin for the CPU. When this GPIO input is low, it indicates that the MUX chip is idle, and the CPU can control MUX switching. When the input is high, it indicates that the MUX chip is busy, and the CPU cannot control MUX channel switching or communicate with the BMC via LPC or ESPI.

[0070] By adopting the above method, multiple nodes can share the BMC for in-band IPMI communication, saving hardware costs and realizing the communication and management functions of the multi-node in-band OS and BMC.

[0071] The following section describes the relevant processing flow of the node OS and BMC to further illustrate this invention:

[0072] See Figure 4 The diagram illustrates the node OS IPMI initialization process. Secure IPMI communication for the node is achieved by adding functionality to the IPMI driver module within the node OS. First, the node OS boots up and loads the IPMI driver. The driver entry point controls the MUX switch by reading the status GPIO value of the LPC or ESPI channel switching chip. When the channel is idle, it switches to connect the local node and the BMC chip; otherwise, it waits for the channel to become idle. After switching to the local node's IPMI channel, the IPMI driver reports the node's MD5 checksum to the BMC chip. The MD5 value is obtained as follows: the file ` / sys / firmware / dmi / tables / DMI` is selected as the base file for verification. The OS calculates the MD5 value of this file as the security checksum `md5sum / sys / firmware / dmi / tables / DMI`. The calculated MD5 value `555ac5d732cd9a940a167df347f79ff6` is used as the IPMI communication security checksum for the local node OS. Afterward, the node OS waits for the user to input the IPMI access command.

[0073] The IPMI request processing flow of the node OS is as follows: Figure 5 As shown, when a node OS receives a user's IPMI access command, it first determines whether it is a cross-node OS IPMI access command. If not, it uses GPIO to control the channel switching chip, selecting local node IPMI communication and entering the normal IPMI in-band communication access process. If it is a cross-node OS IPMI access command, it uses GPIO to control the channel switching chip, selecting local node IPMI communication. Simultaneously, it adds the MD5 checksum parameter of the different node OS to the end of the IPMI access command for security verification. Finally, the node OS sends the IPMI access command to the BMC, completing one IPMI access request processing flow.

[0074] The BMC IPMI software module initialization process is as follows: Figure 6As shown, the IPMI channel driver loads and waits for user input of the cross-node OS IPMI access policy. Upon receiving user input, it calls the cross-node OS IPMI access policy processing module to process the policy. The BMC waits for the node OS to send the node OS MD5 checksum, calls the node OS MD5 checksum storage processing module to store the node MD5 checksum in the BMC storage area, and then completes the traditional IPMI initialization process normally.

[0075] The IPMI access process of the BMC response node OS is as follows: Figure 7 As shown, the BMC first waits for IPMI access requests from the node OS to determine if they are from a different node OS. If not, it processes the IPMI access request according to the traditional procedure. If it is from a different node OS, the BMC first checks the global switch of the user-configured inter-node access policy. If access is not permitted, it directly returns a "global ipmi not permitted" message and the program exits. If the global switch is permitted, it then checks whether the node OS's IPMI resource access policy switch is permitted. If not, it directly returns an "ipmiresource not permitted" message and the program exits. Otherwise, it compares the MD5 checksum of the IPMI access request sent by the node OS. If it is equal to the inter-node OS MD5 checksum stored in the BMC, it proves that the access is secure, and the BMC responds normally to the node's IPMI access request. If the MD5 checksum fails, it directly returns a "secure key not permitted" message and the program exits.

[0076] The BMC IPMI node access security log processing flow is as follows: Figure 8 As shown, the system waits for the user to configure the cross-node IPMI illegal access threshold. When the MD5 checksum of the cross-node IPMI access entered by the node OS is incorrect, the BMC will record the cross-node OS IPMI illegal access security log. When the number of times exceeds the cross-node illegal access threshold configured by the BMC, the BMC will trigger a cross-node IPMI access security alarm, prompting the BMC administrator that there is a security risk of illegal IPMI access in the current system.

[0077] In summary, the server in-band IPMI communication method of this invention, through the design of a multi-channel LPC or ESPI channel mux switch chip, enables multiple node CPUs to share a single BMC chip for multi-node OS in-band IPMI communication. Status checks and control of the multi-channel switch chip are added to the IPMI driver module of the node OS to achieve IPMI communication between the node OS and the BMC chip. Simultaneously, an MD5 checksum based on the node hardware is added as a security verification value for cross-node IPMI access, incorporated into the IPMI parameters for cross-node IPMI access. The BMC automatically records the security verification MD5 values ​​of each node and verifies them against the MD5 parameters of the IPMI request for cross-node OS access, thereby achieving secure cross-node in-band IPMI communication and access. Furthermore, to improve system flexibility and security, users can configure a global master switch for cross-node IPMI access and access control policies for different types of IPMI resources through the BMC. Users can also configure cross-node IPMI access security thresholds through the BMC, automatically recording unauthorized cross-node IPMI access security logs and triggering security alarms, thus improving system maintainability and security.

[0078] See Figure 3 As shown in the figure, this embodiment of the invention also discloses a server in-band IPMI communication system, including a baseboard management controller (BMC) and multiple nodes.

[0079] Among them, multiple nodes are used to communicate with the BMC via IPMI, and the IPMI driver module of the OS of each node is used to generate the identifier of the OS of each node and send it to the baseboard management controller (BMC) for storage.

[0080] The BMC is also used to verify the identifier of the requesting node OS based on the identifier of the node OS stored in its own memory when accessing the Intelligent Platform Management Interface (IPMI) across node OSs, in order to determine whether access is allowed.

[0081] In some embodiments, when the BMC accesses the Intelligent Platform Management Interface (IPMI) across node OSs, it performs an identifier verification on the requesting node OS based on the identifier of the node OS stored in its own memory to determine whether access is allowed, including:

[0082] When a node OS receives an IPMI access request, it determines whether the request is a cross-node OS access to IPMI.

[0083] If it is a cross-node OS access to IPMI, send an IPMI access request to BMC with the identifier of the different node OS added;

[0084] After determining that the BMC is accessing IPMI across node OSs, it compares the identifier of the node OS stored in its own database with the identifier of the different node OS. If they are the same, the access is allowed.

[0085] In some embodiments, after the BMC determines that it is accessing IPMI across node OSs, before comparing whether the identifiers of the node OS stored in its own memory are the same as the identifiers of the different node OSs, the BMC is further configured to:

[0086] Check the configured global switch for cross-node access policy. If the global switch is set to disallow access, the program will exit.

[0087] If the global switch is set to allow access, then check the IPMI access resource policy switch of the node OS. If the IPMI access resource policy switch is set to disallow access, then the program exits.

[0088] If the IPMI access resource policy switch is set to allow access, then compare the identifier of the node OS stored in itself with the identifier of the OS of other nodes to see if they are the same.

[0089] In some embodiments, the BMC is also used for:

[0090] When the BMC determines that the identifier of the node OS it stores is different from the identifier of the different node OS, the BMC records the illegal access security log of the different node OS IPMI.

[0091] When the number of recorded accesses exceeds the cross-node illegal access threshold configured in the BMC, a cross-node IPMI access security alarm is triggered in the BMC.

[0092] In some embodiments, the server in-band IPMI communication system further includes a control routing chip, which may be an LPC or an ESPI channel switching MUX chip.

[0093] Each node CPU is connected to the control routing chip via two GPIOs. One GPIO is used for channel switching and the other GPIO is used to indicate the status of the control routing chip. The control routing chip is also connected to the BMC.

[0094] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for in-band IPMI communication of a server, the method comprising: The method comprises the following steps: An identifier of each node operating system (OS) is generated and sent to a baseboard management controller (BMC) for storage; When an intelligent platform management interface (IPMI) is accessed across node OSs, the BMC performs an identifier check on a node OS requesting access based on the identifier of the node OS stored by the BMC to determine whether access is allowed; The generation of the identifier of each node operating system (OS) comprises: The unique md5 check value of node hardware is used as the identifier of the node OS; The identifier check performed by the BMC on the node OS requesting access based on the identifier of the node OS stored by the BMC when an intelligent platform management interface (IPMI) is accessed across node OSs to determine whether access is allowed comprises: When the node OS receives an IPMI access request, it determines whether the request is for IPMI access across node OSs; If the request is for IPMI access across node OSs, the node OS sends an IPMI access request to the BMC to add the identifier of the different node OS; After the BMC determines that the request is for IPMI access across node OSs, it compares the identifier of the node OS stored by the BMC with the identifier of the different node OS, and if they are the same, access is allowed; After the BMC determines that the request is for IPMI access across node OSs, before comparing the identifier of the node OS stored by the BMC with the identifier of the different node OS, the following steps are further included: The BMC checks a configured different node access strategy global switch, and if the global switch is set to not allow access, the program exits; If the global switch is set to allow access, the node OS further checks a node OS IPMI access resource strategy switch, and if the IPMI access resource strategy switch is set to not allow access, the program exits; If the IPMI access resource strategy switch is set to allow access, the identifier of the node OS stored by the BMC is compared with the identifier of the different node OS.

2. The method of claim 1, wherein: The IPMI access resource strategy switch comprises an SOL, a sensor viewing, an alarm query, a node restart and a node shutdown switch.

3. The method of claim 1, wherein the server in-band IPMI communication method is characterized by, Further included are: When the BMC determines that the identifier of the node OS stored by the BMC and the identifier of the different node OS are not the same, the BMC records a different node OS IPMI illegal access security log; When the number of records exceeds a cross-node illegal access threshold value configured by the BMC, a different node IPMI access security alarm of the BMC is triggered.

4. The method of claim 1, wherein the server in-band IPMI communication method is characterized by, Further included are: A control routing chip connected to the BMC is provided; Each node CPU is connected to the control routing chip through two GPIOs, one GPIO is used for channel switching selection, and the other GPIO is used for indicating the state of the control routing chip.

5. A server in-band IPMI communication system, comprising: Included are: A baseboard management controller (BMC); A plurality of nodes configured to communicate with the BMC through an intelligent platform management interface (IPMI), and an IPMI driver module of the OS of each node is configured to generate an identifier of each node operating system (OS) and send the identifier to the baseboard management controller (BMC) for storage; The BMC is further configured to perform an identifier check on a node OS requesting access based on the identifier of the node OS stored by the BMC when an intelligent platform management interface (IPMI) is accessed across node OSs to determine whether access is allowed; The IPMI driver module generates an identifier of each node operating system (OS) by comprising: A unique md5 check value of node hardware is taken as an identification of the node OS; When the BMC accesses an intelligent platform management interface (IPMI) across node OSs, the BMC performs identification verification on a node OS requesting access based on the identification of the node OS stored by the BMC to determine whether to allow access, including: When the node OS receives an IPMI access request, it determines whether the request is for access to the IPMI across node OSs; If the request is for access to the IPMI across node OSs, the node OS sends an IPMI access request to the BMC, in which an identification of a different node OS is added; After the BMC determines that the request is for access to the IPMI across node OSs, the BMC compares the identification of the node OS stored by the BMC with the identification of the different node OS, and if the identifications are the same, the access is allowed; After the BMC determines that the request is for access to the IPMI across node OSs, before the BMC compares the identification of the node OS stored by the BMC with the identification of the different node OS, the BMC is further configured to: Check a configured global switch of a different node access strategy, and if the global switch is set to not allow access, the program exits; If the global switch is set to allow access, the BMC further checks an IPMI access resource strategy switch of the node OS, and if the IPMI access resource strategy switch is set to not allow access, the program exits; If the IPMI access resource strategy switch is set to allow access, the BMC compares the identification of the node OS stored by the BMC with the identification of the different node OS.

Images