A method and system for monitoring and managing switch configuration based on dual-channel unified access

Abstract

The application discloses a switch configuration monitoring and management method and system based on a dual-channel unified access. A unified command execution interface is defined to abstract and isolate an SSH channel and a serial port channel, decouple upper-layer business and a transmission mode, perform echo filtering, configuration segment segmentation and type classification on CLI output, analyze and generate a structured configuration snapshot, intelligently select a single full collection or a module collection strategy according to a monitoring module set, execute a degradation fallback of include filtering when there is no result, convert a graphical configuration request into a CLI command sequence through a device adapter and issue the CLI command sequence, automatically complete login, Boot interruption, credential filling and page closing when connected with a serial port, support dynamic switching to an SSH connection after issuing an SSH service configuration through the serial port, push device output to a front-end terminal for rendering based on an SSE protocol, automatically refresh a monitoring view after executing a configuration type command, and realize single-machine integrated deployment by adopting a desktop sidecar embedded architecture to embed a back-end service.

Description

Technical Field

[0001] This application relates to network device management technology, specifically to a method and system for monitoring and managing switch configuration based on dual-channel unified access. Background Technology

[0002] In enterprise network operation and maintenance scenarios, H3C Comware series switches are typically managed through a command-line interface (CLI). Maintenance personnel need to manually enter various commands to complete daily operation and maintenance by using a serial port console or SSH remote login.

[0003] In their research and practice of existing technologies, the inventors discovered the following shortcomings in current management methods: Serial port and SSH channels are disconnected; new devices require on-site IP configuration and SSH activation before remote management is possible, making it impossible to complete the closed-loop process of serial port initialization, SSH activation, and connection mode switching within a unified interface; CLI output is unstructured plain text, making it difficult to integrate with graphical interfaces; serial port interaction has poor stability, with the mixing of device startup, pagination prompts, command echoes, and prompts causing automated scripts to easily block or misjudge, and the half-duplex nature of serial ports lacks session multiplexing and command serialization control mechanisms; some older devices use outdated SSH algorithms, often causing general clients to fail to connect due to algorithm negotiation failures; monitoring and configuration operations are separated, and graphical and command-line interfaces are disconnected, resulting in monitoring views not automatically synchronizing after configuration changes, and the two sets of tools lacking unified channels; long command output uses a traditional request-response model, preventing users from perceiving execution progress in real time.

[0004] Therefore, it is necessary to provide a method and system for monitoring and managing switch configuration based on dual-channel unified access to solve the above-mentioned technical problems. Summary of the Invention

[0005] The purpose of this application is to provide a switch configuration monitoring and management method and system based on dual-channel unified access, which solves the problem of isolation between serial port and SSH connection and realizes dynamic switching of connection mode; it parses unstructured configuration output into structured data, improving configuration management efficiency; and it supports real-time streaming push of device output, enhancing the operation and maintenance interaction experience.

[0006] Firstly, this application provides a method for configuring, monitoring, and managing switches based on dual-channel unified access, including: Instantiate a command execution object for the corresponding channel based on the connection type, wherein the connection type is either a Secure Shell Protocol (SSH) connection or a serial port connection, and the command execution object implements a unified command execution interface; Send command-line interface (CLI) commands to the switch through the unified command execution interface, and receive the text output returned by the switch; The text output is processed by echo filtering, configuration segment segmentation, and segment type classification, and a structured configuration snapshot is generated by parsing. Based on the requested set of monitoring modules, select either a single full data collection mode or a module-by-module data collection mode to acquire monitoring data, and execute a downgrade rollback command for modules with empty data collection results. Upon receiving a graphical configuration request, the device adapter converts the graphical configuration request into a CLI command sequence, which is then sent to the switch via the unified command execution interface. When the connection type is a serial port connection, the SSH service configuration command sequence is issued through the unified command execution interface, the SSH connection parameters are persisted, and the active connection mode can be dynamically switched between serial port connection and SSH connection. It provides an interactive command-line interface, accepts manually entered CLI commands, and pushes device output to the front-end rendering in real time in a streaming, chunked manner through the SSE protocol sent by the server. After the configuration command is executed, the structured monitoring view is automatically refreshed.

[0007] Furthermore, the structured configuration snapshot includes fields for system name, virtual LAN, interface, static route, open shortest path first protocol, and user information.

[0008] Furthermore, the text output is subjected to echo filtering, configuration segment segmentation, and segment type classification, and a structured configuration snapshot is generated through parsing, including: Filter command echo lines, page break prompt lines, and prompt lines to obtain clean configuration text; The clean configuration text is divided into multiple configuration segments using independent hash symbol lines as separators; Based on the keyword in the first line of each configuration segment, the configuration segments are classified into system name segment, virtual LAN segment, interface segment, static route segment, open shortest path first segment, or user segment; Perform regular expression matching on each line of the interface segment to extract the description, link mode, link type, access VLAN and management status fields, and generate a structured interface object.

[0009] Further, the step of selecting either a single full-data acquisition mode or a modular acquisition mode to acquire monitoring data based on the requested set of monitoring modules, and executing a downgrade rollback command for modules with empty acquisition results, includes: Determine whether the monitoring module set contains the original text module; If the original text module is not included, execute the `display current-configuration` command once to obtain the full configuration text, parse it, and then output it by module. If the original text module is included, execute the mapped CLI command for each monitoring module to obtain the output text of the corresponding module; Perform null value validation on the parsing results of each monitoring module; When the parsing result is empty, execute the alternative CLI command that includes the include filter parameter; The alternative commands are output as the collection results of the monitoring module and returned.

[0010] Furthermore, the unified command execution interface includes a one-time read method, a streaming chunked callback method, and a connection closing method; wherein, The execution process of the streaming chunked callback method in the SSH channel includes: The standard output data is read in a loop within an independent coroutine. Each time a data block is read, it is passed to the main coroutine through a channel, and the output callback function is triggered. The main coroutine waits for data channel messages or hard timeout signals through a multiplexing mechanism; The idle timer is reset after each data block is received. The output segment ends when the idle timer reaches the preset idle window duration. The execution process of the streaming block callback method in the serial port channel includes: During the loop reading process, the output callback function is triggered block by block, and the end of the output segment is determined by the idle window detection. The serial port connection adopts a session pool reuse mechanism. When the cached session has not expired, its lifespan is renewed and reused. When it expires, a new serial port connection is created and cached. Each device identifier is bound to a mutex lock to ensure that commands on the same switch serial port are executed serially. When a serial port operation fails, the cached session is destroyed and the device is marked as offline.

[0011] Furthermore, the step of pushing device output to the front-end rendering in real time in a streaming, chunked manner via the SSE protocol sent by the server includes: The backend encapsulates each piece of output data into an output type SSE event, and the event data is a JSON format text block; A done type SSE event is sent when the command execution is complete, and an error type SSE event is sent when the execution fails. The event is immediately pushed to the client via the HTTP refresh mechanism; The front-end parses SSE events by reading the stream, incrementally appends text to the terminal output area, and automatically scrolls.

[0012] Furthermore, the step of issuing SSH service configuration command sequences through the unified command execution interface, persisting SSH connection parameters, and supporting dynamic switching of the active connection mode between serial port connection and SSH connection includes: Enter the system view through the serial port channel and execute the virtual LAN configuration, interface Internet Protocol address configuration, SSH service enable configuration, and local user configuration in sequence. After the configuration is successfully distributed, the SSH host address, SSH port number, and SSH configuration completion marker are stored in the database. When a connection switch request is received, the active connection type is switched to SSH connection, and subsequent commands are executed through the SSH client.

[0013] Furthermore, the interactive command-line interface supports Tab key command completion, and the completion logic includes: Extract the prefix of the currently entered word based on the cursor position; A candidate vocabulary is constructed from the basic command lexicon, the device port name set, and the historical command set. Candidate words starting with the prefix of the given word are filtered out, without checking the completeness of the preceding words; If there is a unique match, replace the current word with the complete word and append a space; if there are multiple matches and the longest common prefix is ​​longer than the current input, expand to the common prefix; otherwise, cycle through the candidate words at the same cursor position.

[0014] Further, the step of receiving the graphical configuration request and converting the graphical configuration request into a CLI command sequence through the device adapter includes: Receive port configuration parameters including layer mode, link type, VLAN, trunk VLAN set, management status, and Internet Protocol address; Generate CLI command sequences through the device adapter for entering the system view, entering the interface view, configuring link mode, configuring virtual LAN, and configuring management status; After the command is successfully issued, the local port record is updated, the front end triggers a configuration change event, and the monitoring view configuration data is automatically refreshed.

[0015] Furthermore, when the connection type is a serial port connection, the method also includes a serial port console intelligent login step: Detect the login status of the device after serial port connection; Send an interrupt command during the device startup phase to terminate the startup process; Automatically fill in login credentials based on username and password hints; After successful login, execute the command to close the page.

[0016] Furthermore, the SSH connection establishment process includes: The list of key exchange algorithms, encryption algorithms, and message authentication code algorithms in the set of security algorithms and the set of supporting algorithms is not included. RSA host keys are preferred. It supports both password authentication and keyboard interaction authentication.

[0017] Furthermore, the method employs a desktop-embedded architecture: The backend service process is embedded through the sidecar mechanism; Automatically set the service port, database path, and desktop mode environment variables; The backend service process is terminated when the application exits.

[0018] Secondly, based on the same inventive concept, this application also provides a switch configuration monitoring and management system based on dual-channel unified access, including: A unified command execution module is used to instantiate an SSH channel command execution object or a serial port channel command execution object according to the connection type. The command execution object implements the unified command execution interface, which includes a one-time read method, a streaming chunked callback method, and a connection close method. The device adaptation module encapsulates device identification commands, version parsing logic, and configuration-class CLI command sequence generation logic. The configuration parsing module is used to perform echo filtering, configuration segment segmentation, segment type classification and field extraction on CLI output text, and generate a structured configuration snapshot; The monitoring and acquisition module is used to select an acquisition strategy based on the set of monitoring modules and execute a fallback mechanism. The configuration distribution module is used to convert graphical configuration requests into CLI command sequences and distribute them to the switch; The connection switching module is used to distribute SSH service configurations via the serial port channel, persist SSH connection parameters, and support dynamic switching between serial port and SSH connection methods. The streaming command interaction module provides an interactive command-line interface and streams device output via the SSE protocol. The front-end display module includes a monitoring view, a graphical operation view, and an interactive command-line view, used to display structured configuration data, receive graphical operations, and present terminal-style command interactions.

[0019] Furthermore, the unified command execution module includes an SSH channel execution unit and a serial port channel execution unit; The SSH channel execution unit is used to establish a transmission control protocol connection, request a virtual terminal, start a shell process, execute a page close command, and read output data in a loop in an independent coroutine, and determine the end of the output segment by combining idle window detection and hard timeout. The serial port channel execution unit is used to open the serial port, detect the login status, send an interrupt command to terminate the startup process when necessary, automatically fill in the login credentials, execute the page close command, and trigger the output callback block by block in the loop reading.

[0020] Furthermore, the device adaptation module supports expansion to devices from multiple vendors, isolating vendor differences through a unified adapter interface; The configuration parsing module includes an output cleaning unit, a segmentation unit, a classification unit, and a field extraction unit; The output cleaning unit is used to filter command echo lines, page break prompt lines, and prompt lines; The segmentation unit is used to segment configuration segments using independent well number lines as delimiters; The classification unit is used to assign segment types based on the first line keyword of the configuration segment; The field extraction unit is used to extract structured fields from each segment using regular expressions and generate a configuration snapshot object in a unified format.

[0021] Furthermore, the streaming command interaction module includes a backend streaming execution unit, an SSE push unit, and a frontend terminal rendering unit; The backend streaming execution unit is used to reuse the dual-channel connection and call the streaming block callback method to read and push data simultaneously. The SSE push unit is used to encapsulate output data, completion signals and error signals into corresponding types of SSE events, and send them out in real time through the HTTP refresh mechanism; The front-end terminal rendering unit is used to parse SSE events by reading the stream, incrementally render the terminal output area, and support command history navigation and automatic refresh of the monitoring view after configuration changes.

[0022] Furthermore, the system adopts a desktop embedded architecture, embedding a backend service process through a sidecar mechanism, automatically setting the service port, database path, and desktop mode environment variables, and terminating the backend process when the application exits. The serial port channel execution unit is associated with a session pool and a device-level mutex. The session pool has a preset lifespan, and the device-level mutex ensures that serial port commands on the same device are executed serially. The SSH channel execution unit is not a set of security algorithms and a list of key exchange, encryption and message authentication code algorithms in the set of supported algorithms. It prioritizes the use of RSA host keys and supports dual authentication methods of password authentication and keyboard interaction authentication.

[0023] Compared with the prior art, this application has the following advantages: This application provides a switch configuration monitoring and management method and system based on dual-channel unified access. It realizes dynamic switching between dual channels, structured configuration parsing, and streaming interaction mechanism through a unified command execution interface. It effectively solves the problems of fragmented connection methods and unstructured configuration information in network device management, solves the problem of isolation between serial port and SSH connection, and realizes dynamic switching of connection methods. It parses unstructured configuration output into structured data, improving configuration management efficiency; and supports real-time streaming push of device output, enhancing the operation and maintenance interaction experience. Attached Figure Description

[0024] Figure 1 A flowchart illustrating a switch configuration monitoring and management method based on dual-channel unified access, provided in an embodiment of this application; Figure 2 for Figure 1 A flowchart illustrating step S3; Figure 3 for Figure 1 A flowchart illustrating step S4 in the middle section; Figure 4 A flowchart illustrating the execution process of the streaming chunked callback method provided in this application embodiment in an SSH channel; Figure 5 A flowchart illustrating the execution process of the streaming block callback method provided in this application embodiment in a serial port channel; Figure 6 for Figure 1 A schematic diagram of the process described in step S7, in which the device output is pushed to the front-end rendering in real time in a streaming, chunked manner by sending events via the SSE protocol from the server. Figure 7 for Figure 1 The flowchart in step S6 describes the process of issuing SSH service configuration command sequences through the unified command execution interface, persisting SSH connection parameters, and supporting dynamic switching of active connection mode between serial port connection and SSH connection. Figure 8 A schematic diagram of a switch configuration monitoring and management system based on dual-channel unified access provided in this application embodiment; Figure 9 This is a schematic diagram of a switch configuration monitoring and management system based on dual-channel unified access, provided as an embodiment of this application. Detailed Implementation

[0025] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0026] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0027] For ease of understanding, the following explains some key terms in this embodiment: Dual-channel unified access means that the system can simultaneously support communication and management with the switch through both Secure Shell Protocol (SSH) and serial port connections, and provides a unified interface layer to shield the differences in underlying connections.

[0028] A command execution object is a software entity instantiated based on the connection type, used to encapsulate underlying communication details and implement a unified command execution interface. This object is responsible for converting upper-layer requests into channel operations and processing the channel's returned data.

[0029] A unified command execution interface is an abstract interface that provides a standardized mechanism for sending commands and receiving results for upper-layer applications. Through this interface, upper-layer applications can perform command operations on the switch without needing to be aware of the underlying connection type.

[0030] A structured configuration snapshot refers to a collection of configuration information with a clear data structure and field definitions, generated by parsing, filtering, segmenting, and classifying the unstructured text output returned by the switch. This snapshot facilitates automated processing, storage, and display by the system.

[0031] The Server Send Events (SSE) protocol is a one-way communication technology based on the HTTP protocol that allows a server to push event streams to a client. In this application, this protocol is used to continuously push the real-time output of switch command execution to the front-end interface in a streaming, chunked manner. Firstly, embodiments of this application provide a method for monitoring and managing switch configuration based on dual-channel unified access, such as... Figure 1 As shown.

[0032] S1. Instantiate a command execution object for the corresponding channel according to the connection type, wherein the connection type is a Secure Shell Protocol (SSH) connection or a serial port connection, and the command execution object implements a unified command execution interface.

[0033] Specifically, based on the user-specified connection type, a corresponding command execution object is instantiated. For example, when an SSH protocol connection is selected, an SSH command execution object is created; when a serial port connection is selected, a serial port command execution object is created. These command execution objects all implement a unified command execution interface, which defines the basic operations for communicating with the switch, thus freeing upper-layer applications from concern themselves with the specific implementation of the underlying connection.

[0034] S2. Send command line interface (CLI) commands to the switch through the unified command execution interface, and receive the text output returned by the switch.

[0035] Once the command execution object is instantiated, the system can send command-line interface (CLI) commands to the target switch through this unified command execution interface. These commands can be configuration, query, or diagnostic commands. After the command is sent, the system waits for and receives the text output returned by the switch after executing the command. This text output typically contains command execution results, configuration information, or status reports, and its raw form is unstructured text.

[0036] S3. Perform echo filtering, configuration segment segmentation and segment type classification on the text output, and parse to generate a structured configuration snapshot.

[0037] To improve the readability and processability of the text output, the system performs a series of processing steps on the received text output. This includes filtering out command echoes, pagination prompts, and other information in the text to obtain the configuration text. Subsequently, this configuration text is segmented into multiple logical configuration sections and categorized according to their content, such as identifying the system name section, virtual LAN section, and interface section. Finally, by parsing these categorized configuration sections, the system can generate a structured configuration snapshot. This snapshot is presented in a data format and includes fields such as system name, virtual LAN, interface, static route, open shortest path first protocol, and user information.

[0038] S4. Based on the requested set of monitoring modules, select either a single full data acquisition mode or a module-by-module acquisition mode to acquire monitoring data, and execute a downgrade rollback command for modules with empty acquisition results.

[0039] Specifically, the system flexibly selects the monitoring data acquisition mode based on the requested set of monitoring modules. One approach is to perform a single full data acquisition, which retrieves all configuration information of the switch using a single command. Another approach is to perform module-by-module acquisition, which sends commands to each specific monitoring module (e.g., interface status, routing table, etc.) to acquire data. During the data acquisition process, if the acquisition result for a certain module is empty, the system will execute a fallback command to attempt to acquire backup data, ensuring the integrity of the monitoring data.

[0040] S5. Receive a graphical configuration request, convert the graphical configuration request into a CLI command sequence through the device adapter, and send it to the switch through the unified command execution interface.

[0041] Specifically, the system can receive configuration requests from a graphical interface, typically represented by graphical elements. The device adapter, acting as an intermediary layer, is responsible for parsing these graphical configuration requests and converting them into a sequence of command-line interface (CLI) commands that the switch can recognize. This CLI command sequence is then distributed to the target switch via a unified command execution interface to automate the configuration deployment.

[0042] S6. When the connection type is a serial port connection, the SSH service configuration command sequence is issued through the unified command execution interface, the SSH connection parameters are persisted, and the active connection mode can be dynamically switched between serial port connection and SSH connection.

[0043] Specifically, when the system is currently communicating with the switch via a serial port connection, it can issue a series of SSH service configuration commands through a unified command execution interface. These commands are designed to enable and configure the SSH service on the switch, including setting the IP address and enabling SSH functionality. After configuration, the relevant SSH connection parameters are persistently stored. Thus, the system has the ability to dynamically switch between serial port and SSH connections as the active connection method.

[0044] S7 provides an interactive command-line interface, receives manually entered CLI commands, and pushes device output to the front-end rendering in real time in a streaming, chunked manner through the SSE protocol sent by the server. After the configuration command is executed, the structured monitoring view is automatically refreshed.

[0045] Specifically, an interactive command-line interface is provided, allowing maintenance personnel to manually enter CLI commands. When a command is executed, the device output returned by the switch is sent to the front end for rendering in real time via the SSE event protocol sent by the server, using a streaming, chunked approach. This means users can instantly see the progress and results of command execution. Furthermore, after configuration commands are executed, the system automatically triggers a refresh of the structured monitoring view, ensuring that the configuration data displayed on the front end remains synchronized with the actual device status.

[0046] This embodiment solves the problem of fragmented serial and SSH channels in traditional switch management by providing a dual-channel unified access mechanism, enabling flexible switching of connection methods. Structured parsing of the CLI text output improves the readability of configuration data and the ability to automate processing. Simultaneously, a fallback mechanism for monitoring data acquisition enhances the robustness of data collection. The conversion and distribution of graphical configuration requests, as well as the automatic refresh of the monitoring view after configuration changes, achieve seamless integration of graphical and command-line operations. Furthermore, the use of server-sent events via the SSE protocol for streaming device output allows users to perceive command execution progress in real time, improving operational efficiency and user experience. In some possible implementations, S3, performing echo filtering, configuration segment segmentation, and segment type classification on the text output, and parsing to generate a structured configuration snapshot, includes the following steps, such as... Figure 2 As shown.

[0047] S31. Filter the command echo lines, page break prompt lines, and prompt lines to obtain clean configuration text.

[0048] Remove all non-configuration data from the raw text output returned from the switch to ensure the accuracy and efficiency of subsequent parsing. Command echo lines are typically the user-input commands themselves, pagination prompts (such as "--More--" or "Press any key to continue") control output display, and prompt lines (such as "...")... <huawei>The string "" or "Router#" indicates that the device is waiting for input. By identifying and removing lines with these specific patterns, a "clean configuration text" containing only the actual configuration information can be obtained, laying the foundation for subsequent structured parsing. This can be achieved by using regular expressions to match and delete lines with these known patterns, or by using a state machine to identify different output stages during command execution.

[0049] S32. Divide the clean configuration text into multiple configuration segments using independent hash symbol lines as separators.

[0050] Divide the clean configuration text according to logical functions or configuration modules. In many switch configurations, different configuration modules (such as system information, interface configuration, routing configuration, etc.) are often distinguished by specific delimiters (e.g., a separate hash "#" line or a blank line). By identifying these delimiters, the entire configuration text can be broken down into smaller, more manageable configuration segments, each corresponding to a specific configuration module, thereby simplifying subsequent classification and parsing.

[0051] S33. Classify the configuration segments into system name segment, virtual LAN segment, interface segment, static route segment, open shortest path first segment, or user segment based on the keyword in the first line of each configuration segment.

[0052] The segmented configuration sections are semantically identified and categorized. Each configuration section typically begins with one or more specific keywords that clearly indicate its configuration type. For example, "sysname" might indicate the system name section, "vlan" the virtual LAN section, "interface" the interface section, "ip route-static" the static route section, "ospf" the open shortest path first section, and "local-user" the user section. Through predefined keyword mapping rules, the system can automatically identify and label the type of each configuration section, providing a basis for subsequent fine-grained parsing of different types of configuration sections.

[0053] S34. Perform regular expression matching on each line of the interface segment to extract the description, link mode, link type, access virtual LAN and management status fields, and generate a structured interface object.

[0054] In-depth structured data extraction is performed on specific and complex configuration segments (such as interface segments). Interface configurations typically contain a large number of detailed parameters with relatively fixed formats. By designing specific regular expressions for each key field (such as interface description, link mode, link type, accessed VLAN ID, management status, etc.), the text of the interface segment can be scanned line by line to accurately capture the values ​​of these fields. The extracted fields are then organized into a structured interface object, which represents all relevant configuration information of the interface in a programmable manner, facilitating subsequent querying, modification, and management.

[0055] In some possible implementations, S4, based on the requested set of monitoring modules, select either a single full-data acquisition mode or a modular acquisition mode to acquire monitoring data, and execute a downgrade rollback command for modules with empty acquisition results, including the following steps, such as... Figure 3 As shown.

[0056] S41. Determine whether the monitoring module set contains the original text module.

[0057] When acquiring monitoring data, the system first determines whether the currently requested set of monitoring modules includes a requirement for raw text modules. Raw text modules typically refer to the user's need to obtain the device's unparsed raw configuration text, which is crucial for troubleshooting, auditing, or specific analysis scenarios. This determination can be made by checking whether a predefined identifier or flag exists in the set of monitoring modules.

[0058] S42. If the original text module is not included, execute the display current-configuration command once to obtain the full configuration text, parse it, and then split it into modules for output.

[0059] If the determination result indicates that the original text module is not included, meaning the user or system only needs structured, parsed configuration data, the system will execute a single `display current-configuration` command to obtain the switch's full configuration text. This method reduces the number of interactions with the switch and improves data acquisition efficiency by obtaining all configuration information at once. The obtained full configuration text will then be parsed and split into corresponding structured outputs according to preset module definitions (such as system name, virtual LAN, interface, etc.).

[0060] S43. If the original text module is included, execute the mapped CLI command for each monitoring module to obtain the output text of the corresponding module.

[0061] If the judgment result indicates the presence of the original text module, or if the system is designed for more granular module-based data collection, the system will execute pre-mapped CLI commands for each monitoring module in the monitoring module set. For example, for the interface module, the `display interface brief` command might be executed; for the virtual LAN module, the `display vlan` command might be executed. In this way, the system can obtain the output text corresponding to each module, satisfying the need for precise data collection of the original text or specific module data.

[0062] S44. Perform null value verification on the parsing results of each monitoring module.

[0063] After obtaining and parsing the output text of each monitoring module, the system performs null value checks on the parsing results of each monitoring module. This step aims to check whether the parsed data is valid or empty. For example, if the text returned after executing a CLI command of a module is empty, or if the parser fails to extract any valid data from it, the parsing result of that module is considered empty.

[0064] S45. When the parsing result is empty, execute the alternative CLI command that includes the include filter parameter.

[0065] When a monitoring module's parsing result is empty, the system triggers a fallback mechanism, executing an alternative CLI command that includes an `include` filter parameter. These alternative CLI commands are typically more targeted commands designed for specific modules and may include filter parameters such as `include` to attempt to extract the desired information from a broader or more detailed output. For example, if the `display interface` command fails to return information for a specific interface, the alternative command might be `display current-configuration | include interface GigabitEthernet0 / 0 / 1`, ensuring that some critical configuration information is obtained even if the main command fails.

[0066] S46. The alternative command output is returned as the collection result of the monitoring module.

[0067] Even though the output of the alternative command may not be as comprehensive as that of the main command, it provides a mechanism to obtain valid data when the main acquisition fails, thereby enhancing the robustness of the system.

[0068] In some possible implementations, the unified command execution interface includes a one-time read method, a streaming chunked callback method, and a connection closure method.

[0069] The one-time read method is suitable for commands with small expected output that only need to be retrieved once, such as querying a small amount of configuration information. It can be implemented by waiting for the command to complete and then reading all accumulated output data at once. The streaming block callback method is suitable for commands with large output volumes that require real-time or segmented processing, such as displaying runtime configurations or log information. It allows for immediate processing upon data arrival, avoiding memory pressure and long waiting times. The connection closing method is used to safely and orderly terminate the connection with the switch and release resources.

[0070] like Figure 4 As shown, the execution process of the streaming chunked callback method in the SSH channel includes: S111. Read standard output data in a loop within an independent coroutine. Each time a data block is read, it is transmitted to the main coroutine through a channel, and the output callback function is triggered. S112. The main coroutine waits for data channel messages or hard timeout signals through a multiplexing mechanism. S113. The idle timer is reset after each data block is received. When the idle timer reaches the preset idle window duration, the output segment is determined to end.

[0071] In this embodiment, a separate coroutine continuously reads standard output data. Each data block read is transmitted to the main coroutine via a channel, triggering an output callback function. This separate coroutine is responsible for non-blocking continuous data reading from the standard output stream of the SSH connection. When a data block of a certain size is read, it is sent to the main coroutine via an internal communication channel. Upon receiving the data block, the main coroutine calls a pre-registered output callback function, allowing the upper-layer application to process the data in real time. The main coroutine uses a multiplexing mechanism to wait for data channel messages or hard timeout signals. Multiplexing simultaneously monitors the data channel from the separate coroutine and the preset hard timeout signal, ensuring that the main coroutine can process received data promptly and, if no data arrives for an extended period, uses the hard timeout mechanism to determine if command execution is abnormal or has terminated, preventing infinite waiting. Furthermore, the idle timer is reset after each data block is received, and the output segment ends when the idle timer reaches a preset idle window duration. This idle timer is used to detect the "silent" state of the output stream. Whenever a new data block arrives and is received by the main coroutine, the timer is reset. If the timer is not reset within the preset "idle window duration", it is considered that the output of the current command has ended. This is crucial for determining the boundary of the streaming output.

[0072] like Figure 5 As shown, the execution process of the streaming block callback method in the serial port channel includes: S121. During the loop reading process, the output callback function is triggered block by block, and the end of the output segment is determined by the idle window detection. S122. The serial port connection adopts a session pool reuse mechanism. When the cached session has not expired, its lifespan is renewed and reused. When it expires, a new serial port connection is created and cached. S123. Each device identifier is bound to a mutex lock to ensure that commands on the same switch serial port are executed serially. S124. When a serial port operation fails, the cached session is destroyed and the device is marked as offline.

[0073] In this embodiment, the output callback function is triggered block by block during the cyclic reading process, and the end of the output segment is determined by the idle window detection. Similar to the SSH channel, the serial port channel also adopts a cyclic reading method. When a certain amount of data is read or a certain time interval is reached, the data is treated as a data block, and the output callback function is triggered immediately. The idle window detection mechanism is also applicable to the serial port, that is, if no new bytes arrive within a certain time, the output is considered to have ended, solving the problem that the serial port output may not have a clear end mark. In order to further optimize the efficiency and reliability of the serial port connection, the serial port connection adopts a session pool reuse mechanism. The session is cached and its lifespan is renewed and reused when it has not expired, and a new serial port connection is created and cached when it expires. This session pool avoids frequent creation and destruction of connections by maintaining a set of pre-established or on-demand serial port connections, thereby improving resource utilization. In addition, each device identifier is bound to a mutex lock to ensure that serial commands on the same switch are executed serially. Since the serial port is half-duplex communication and can usually only process one command at a time, binding a mutex lock to each unique device identifier ensures that only one thread or process can acquire the serial port operation permission of the device at any given time, thereby ensuring the serial execution of commands. When a serial port operation fails, the cached session is destroyed and the device is marked as offline, thus handling communication errors in a timely manner and enhancing the system's robustness and fault handling capabilities.

[0074] In some possible implementations, the step of pushing device output to the front-end rendering in real time in a streaming, chunked manner via the SSE protocol sent by the server includes the following steps, such as... Figure 6 As shown.

[0075] S711, The backend encapsulates each block of output data into an output type SSE event, and the event data is a JSON format text block; S712. When the command execution is complete, a done type SSE event is sent; when the execution fails, an error type SSE event is sent. S713, pushes events to the client immediately via the HTTP refresh mechanism; S714: The front-end parses SSE events by reading the stream, incrementally appends text to the terminal output area and scrolls automatically.

[0076] Specifically, after receiving the raw output data returned by the switch, the backend server does not send all the data at once. Instead, it divides the data into smaller "chunks." Each data chunk is then encapsulated into a specific type of Server Send Event (SSE), i.e., an "output" type event. This encapsulation aims to standardize the data format, facilitating frontend parsing and processing. The event data uses JSON-formatted text chunks, which ensures good readability and scalability, easily carrying metadata in addition to the raw text, thereby enhancing data structure and processing flexibility. This chunking and encapsulation mechanism ensures appropriate granularity of data transmission, enabling both streaming transmission and guaranteeing the integrity and parsability of each transmission unit.

[0077] Meanwhile, to clearly indicate the execution status of command-line interface (CLI) commands, during the command execution process, when a CLI command is successfully executed on the switch and returns all expected output, the backend generates and sends a "done" type SSE event. This event notifies the frontend that the command has completed successfully, allowing the frontend to update the user interface status accordingly, such as unlocking the input lock or displaying a success message. Conversely, if an error occurs during command execution, the backend sends an "error" type SSE event. This event carries error information, enabling the frontend to promptly display error details to the user and take appropriate error handling measures. By distinguishing between the "done" and "error" event types, the system can provide clear and real-time command execution feedback, greatly improving the user experience and system robustness.

[0078] To achieve real-time push of SSE events, this application employs an HTTP refresh mechanism. The HTTP refresh mechanism refers to the server sending a partially generated HTTP response to the client immediately, without waiting for the entire response body to be generated. For SSE, this means that when the backend generates an SSE event, it immediately writes it to the HTTP response stream and flushes the buffer, forcing the operating system and network stack to send these packets out immediately, rather than waiting for the buffer to fill or the connection to close. This mechanism ensures that SSE events can be transmitted from the server to the client with minimal latency, achieving a true "real-time" push effect and avoiding delays caused by data buffering, which is crucial for interactive command-line interfaces requiring immediate feedback.

[0079] On the client side, the front-end application continuously reads incoming data in a streaming manner by listening to the HTTP connection established with the server. When an SSE event is received, the front-end parses the event type and event data. For "output" type events, the front-end extracts the JSON-formatted text block and appends its content incrementally to the terminal output area on the user interface. To provide a good user experience, the terminal output area automatically scrolls as new text is appended, ensuring that the latest content is always visible. For "done" or "error" type events, the front-end updates the command execution status according to the event content, such as displaying a command completion prompt or error message. This approach ensures real-time, smooth display of device output and provides intuitive command execution feedback.

[0080] In some possible implementations, the step of issuing SSH service configuration command sequences through the unified command execution interface, persisting SSH connection parameters, and supporting dynamic switching of the active connection mode between serial port connection and SSH connection includes the following steps: Figure 7 As shown.

[0081] S61. Enter the system view through the serial port channel and execute the following steps in sequence: virtual LAN configuration, interface Internet protocol address configuration, SSH service enable configuration, and local user configuration.

[0082] First, access the system view via the serial port channel. The system view is a privileged mode in the switch's operating system that allows administrators to perform global configuration. Accessing the system view via the serial port channel utilizes the physical access permissions of the serial connection to execute specific command-line interface (CLI) commands (e.g., `system-view` or `config terminal`, depending on the switch manufacturer) to gain modification privileges for the switch's core configuration. This is a prerequisite for any system-level configuration (including Secure Shell Protocol (SSH) service configuration).

[0083] Subsequently, the following steps are executed sequentially: Virtual LAN configuration, Interface Internet Protocol (IP) address configuration, Secure Shell (SSH) service activation configuration, and Local User configuration. This series of configuration steps, completed via the command-line interface (CLI), aims to provide the necessary network environment and security credentials for Secure Shell SSH connections. Virtual LAN configuration refers to configuring a virtual LAN for the switch's management interface, ensuring that Secure Shell SSH traffic can be transmitted through a specific logical network. This may involve creating a virtual LAN and adding the interface to a virtual LAN. Interface IP address configuration involves configuring the IP address and subnet mask for the switch's management interface (usually a virtual LAN interface or a physical management interface), making it reachable on the network and allowing Secure Shell SSH clients to connect via the IP address. Secure Shell SSH service activation configuration refers to activating the Secure Shell SSH service on the switch, including generating RSA key pairs, configuring the Secure Shell SSH version (e.g., SSHv2), and setting the authentication mode. This is fundamental for establishing a Secure Shell SSH connection. Local user configuration refers to creating or configuring a local user account on the switch for Secure Shell Protocol SSH login, and setting its username, password and authorization level. This is a necessary condition for Secure Shell Protocol SSH clients to perform authentication.

[0084] S62. After the configuration is successfully distributed, the SSH host address, SSH port number, and SSH configuration completion marker are stored in the database.

[0085] Once the above configuration is successfully deployed, the system will store the Secure Shell SSH host address, Secure Shell SSH port number, and Secure Shell SSH configuration completion flag in the database. The purpose is to persist this information so that the system can automatically discover and use Secure Shell SSH connections subsequently without requiring manual input or confirmation.

[0086] S63. When receiving a connection switching request, the active connection type is switched to SSH connection, and subsequent commands are executed through the SSH client.

[0087] When the system receives a connection switching request from a user or internal logic (for example, when a user selects to use Secure Shell SSH connection on the interface, or when the system detects that Secure Shell SSH configuration is complete and ready for switching), the system will automatically initialize and establish a Secure Shell SSH connection based on the Secure Shell SSH connection parameters stored in the database. Once the Secure Shell SSH connection is successfully established, all subsequent command-line interface (CLI) commands will be sent to the switch through the Secure Shell SSH client (not the serial channel) and the system will receive the output returned by the client.

[0088] In some possible implementations, the interactive command-line interface supports Tab key command completion, and the completion logic includes: Extract the prefix of the currently entered word based on the cursor position; A candidate vocabulary is constructed from the basic command lexicon, the device port name set, and the historical command set. Candidate words starting with the prefix of the given word are filtered out, without checking the completeness of the preceding words; If there is a unique match, replace the current word with the complete word and append a space; if there are multiple matches and the longest common prefix is ​​longer than the current input, expand to the common prefix; otherwise, cycle through the candidate words at the same cursor position.

[0089] The interactive command-line interface (CLI) is the interface through which users directly interact with the switch, allowing them to input and execute CLI commands. Support for Tab key command completion means that when a user inputs part of a command or parameter in the command-line interface, pressing the Tab key will trigger the system to automatically complete the remaining part, or provide possible options for the user to choose from, thereby improving the efficiency and accuracy of command input. To achieve this function, the system monitors the cursor position in the command line in real time and parses backward from the cursor position, identifying the word at the current cursor position as the "word prefix" to be completed. For example, if the user inputs "conf t", and the cursor is after "t", then "t" is extracted as the word prefix.

[0090] To provide comprehensive completion options, the system integrates vocabularies from multiple sources. The basic command vocabulary includes all standard CLI commands and their subcommands, keywords, etc., supported by the switch; the device port name set dynamically includes all configured or available interface names on the current switch (such as GigabitEthernet0 / 1, Loopback0, etc.); and the historical command set stores commands successfully executed by the user previously, allowing for quick repetition or modification of frequently used commands. These vocabularies collectively form a large candidate vocabulary for subsequent matching and filtering. After obtaining the word prefix and candidate vocabulary, the system iterates through the candidate vocabulary, identifying all words beginning with that prefix as preliminary matching results. For example, if the word prefix is ​​"int", then "interface", "ip", "intf", etc., may be filtered out. During this process, the system only focuses on matching the current word prefix, without performing grammatical or completeness checks on previously entered words. This makes the completion function more flexible; even if the preceding command input is incomplete or incorrect, the current word completion can still proceed normally.

[0091] When only one word among the selected candidate words completely matches the prefix of the current word, the system considers it a unique match. In this case, the system automatically replaces the user's current word prefix with this unique complete word and appends a space. For example, if the user enters "inter", and "interface" is the only match, it will be automatically completed as "interface" to facilitate the user's input of subsequent parameters. When multiple candidate words are selected, but these candidate words share a common starting part that is longer than the current word prefix, the system will expand the current input to that longest common prefix. For example, if the user enters "shru", and the candidate words are "show running-config" and "show running-interface", and their longest common prefix is ​​"show running-", the system will expand the user's input to "show running-", prompting the user to enter further information to differentiate. If multiple matches exist, and these matches do not have a longer common prefix to expand upon, or if the user presses the Tab key again, the system will cycle through all matching candidate words at the current cursor position. For example, if a user enters "s" and presses the Tab key, "show", "system", "snmp", etc. may be displayed in sequence. The user can select or continue to enter to narrow down the options as needed.

[0092] In some possible implementations, receiving the graphical configuration request and converting it into a CLI command sequence via a device adapter includes: Receive port configuration parameters including layer mode, link type, VLAN, trunk VLAN set, management status, and Internet Protocol address; Generate CLI command sequences through the device adapter for entering the system view, entering the interface view, configuring link mode, configuring virtual LAN, and configuring management status; After the command is successfully issued, the local port record is updated, the front end triggers a configuration change event, and the monitoring view configuration data is automatically refreshed.

[0093] The system receives port configuration parameters including layer mode, link type, VLAN, trunk VLAN set, management status, and Internet Protocol address. This refers to the structured data received by the system from the user interface that describes the port configuration of the network device. Specifically, "layer mode" indicates whether the port operates in Layer 2 or Layer 3 mode, determining how the port processes data packets; "link type" typically refers to the port's role in a VLAN, such as Access, Trunk, or Hybrid mode, which affects how the port handles VLAN tags; "VLAN" specifies the VLAN ID to which the port belongs, used to isolate broadcast domains; "trunk VLAN set" is used for Trunk or Hybrid ports, defining the range of VLANs allowed through the port; "management status" indicates whether the port is enabled (up) or disabled (down); and "Internet Protocol address" is mainly used for Layer 3 interfaces, configuring their IP address and subnet mask to enable routing and forwarding. These parameters are the core information provided by the user when configuring ports through the graphical interface. They are received by the system in a structured form and serve as the basis for generating CLI commands.

[0094] Building upon this foundation, the device adapter generates a sequence of CLI commands for entering the system view, entering the interface view, configuring link mode, configuring virtual LAN, and configuring management status. The "device adapter" is a key component in this solution; its primary function is to encapsulate the differences in CLI commands between network devices from different vendors, providing a unified configuration interface. Upon receiving the aforementioned graphical configuration parameters, the device adapter translates these high-level, abstract configuration parameters into a series of specific, device-executable command-line interface (CLI) commands based on a predefined device model, vendor-specific command sets, and configuration logic. For example, to configure a port, the device adapter first generates a command to enter global configuration mode (such as `system-view` or `configure terminal`), and then generates a command to enter a specific interface configuration mode (such as `interface GigabitEthernet 0 / 0 / 1` or `interface FastEthernet 0 / 1`). Next, it generates corresponding configuration commands based on the received "link type" parameter (such as `port link-type access` or `switchport mode trunk`), VLAN configuration commands based on the "virtual LAN" parameter (such as `port defaultvlan 10` or `switchport access vlan 10`), and port enable or disable commands based on the "management status" parameter (such as `undo shutdown` or `shutdown`). This process ensures that the graphical operation can be accurately and error-free mapped to the underlying configuration commands of the target device, thereby achieving unified configuration management across vendor devices.

[0095] After a command is successfully issued, the local port record is updated, triggering a configuration change event at the front end and automatically refreshing the monitoring view configuration data. This step aims to ensure the synchronization between the system's internal state and the actual device configuration, and to promptly provide users with configuration results. Once the generated CLI command sequence is successfully issued to the switch via the unified command execution interface and executed, the system immediately updates its internally stored configuration information for that port, namely the "local port record." These records are typically stored in a database and contain detailed information such as the port's latest tier mode, link type, VLAN affiliation, management status, and IP address. Simultaneously, the system sends a "configuration change event" to the front-end user interface, notifying the front end that a configuration change has occurred. Upon receiving this event, the front end automatically triggers a refresh of the "monitoring view" without requiring manual user intervention. This means the front end retrieves the latest configuration data from the device (or reads it from the updated local record) and displays it in the monitoring view, ensuring that users see the latest and most accurate device configuration status on the graphical interface, avoiding configuration management problems caused by information lag.

[0096] In some possible implementations, when the connection type is a serial port connection, the method further includes a serial port console smart login step: Detect the login status of the device after serial port connection; Send an interrupt command during the device startup phase to terminate the startup process; Automatically fill in login credentials based on username and password hints; After successful login, execute the command to close the page.

[0097] The detection of device login status after serial port connection refers to the system continuously listening to and analyzing the data stream received by the serial port to identify whether it contains a specific login prompt (e.g., "Username:"). (e.g., "Password:", "Login:", etc.) or command prompts (e.g., ">", "#", etc.). This is usually achieved through preset regular expressions or string matching algorithms to determine whether the device is currently waiting for the user to enter login credentials, or has already successfully logged in and is waiting for command input.

[0098] The aforementioned sending an interrupt command to terminate the boot process during the device startup phase refers to the system automatically sending the corresponding interrupt control character (e.g., ASCII code 0x03 representing Ctrl+C, or a specific Break signal) to the serial port when the system detects that the device is in the boot process and outputs a prompt message allowing interrupt boot (e.g., "Press Ctrl+C to abortboot" or "Press Ctrl+Break to enter ROMMON mode"). This is intended to allow the system to intervene and perform specific maintenance or configuration tasks before the device fully boots and may enter a restricted mode, such as entering bootloader mode for firmware upgrades or password recovery.

[0099] The automatic login credential filling based on username and password prompts refers to the system's ability to automatically retrieve the corresponding username and password from a pre-stored device credential database when it detects login prompts such as "Username:" or "Password:" in the serial port output, and then send them to the switch via the serial port. This process ensures that the login process can be completed without manual intervention, improving the level of automation. To ensure security, the stored credentials are usually encrypted.

[0100] The "execute pagination disable command after successful login" means that after successfully logging in and gaining command-line control of the switch, the system automatically sends a command to the switch to disable the command-line output pagination function (for example, "terminal length 0" for some manufacturers' devices, and "screen-length 0" for others). The purpose of this operation is to ensure that the output of subsequent CLI commands sent via the serial port can be displayed completely at once, without being paused due to excessive output length. This avoids the need to manually input "More" or the spacebar to view the complete output, facilitating automated parsing and processing of device output.

[0101] In some possible implementations, the SSH connection establishment process includes: The list of key exchange algorithms, encryption algorithms, and message authentication code algorithms in the set of security algorithms and the set of supporting algorithms is not included. RSA host keys are preferred. It supports both password authentication and keyboard interaction authentication.

[0102] During the SSH connection establishment process, the client and server need to negotiate and determine the algorithms used for data encryption, integrity verification, and key exchange. To ensure the system can establish SSH connections with as many switches as possible, this technical solution merges the system's preset "supported algorithm set" with a potentially existing "insecure algorithm set." The "insecure algorithm set" here does not refer to actively using insecure algorithms, but rather to the possibility, in certain scenarios, accepting algorithms that are considered less secure under current standards but are still widely used, for compatibility reasons. By merging these algorithm lists, the system can provide a wider range of algorithm options when negotiating with the switch, thereby increasing the probability of a successful connection. For example, key exchange algorithms may include Diffie-Hellman group switching, ECDH, etc.; encryption algorithms may include AES, 3DES, etc.; message authentication code algorithms may include HMAC-SHA2, HMAC-MD5, etc. The system will attempt to use a more secure algorithm, but can fall back to a more compatible algorithm if negotiation fails.

[0103] Furthermore, when an SSH connection is established, the server sends its host key to the client. The client verifies the host key to confirm the server's identity, preventing man-in-the-middle attacks. RSA (Rivest-Shamir-Adleman) is a widely used and highly secure public-key encryption algorithm, and its host key has high acceptance and compatibility in the industry. By prioritizing the use of RSA host keys, the system can leverage its mature encryption mechanism and broad compatibility to improve the security and success rate of SSH connections. This means that when the server provides multiple host key types (such as RSA, DSA, ECDSA, Ed25519), the client will first attempt to use the RSA key for verification.

[0104] Meanwhile, SSH authentication is the process by which a client proves its identity to a server. Password authentication is one of the most common methods, where the user provides a preset username and password for verification. Keyboard-interactive authentication is a more flexible mechanism, where the server can send a series of prompts to the client (e.g., requiring a password, a two-factor authentication code, etc.), and the client responds accordingly. By supporting both authentication methods simultaneously, the system can adapt to the authentication requirements of different switching devices or different security policies. For example, some switches may only support simple password authentication, while others may be configured with multi-factor authentication, requiring keyboard interaction. This flexibility ensures that the system can successfully establish SSH connections even when faced with diverse authentication configurations.

[0105] In some possible implementations, the method employs a desktop-embedded architecture: The backend service process is embedded through the sidecar mechanism; Automatically set the service port, database path, and desktop mode environment variables; The backend service process is terminated when the application exits.

[0106] Desktop-embedded architecture refers to packaging and running the entire application system, including the front-end user interface and back-end service logic, on the user's local desktop computer, rather than the traditional client-server separation deployment model. This architecture allows the application to run as an independent, self-contained unit, without requiring users to configure or manage a separate server environment, greatly simplifying the deployment process and improving the user experience. The sidecar pattern is a design pattern in which a secondary process (the "sidecar") runs alongside the main application process and shares its lifecycle. In this application, core back-end services such as switch communication, data parsing, and business logic processing are encapsulated as an independent process and embedded into the desktop application through the sidecar mechanism. That is, the desktop application starts the back-end service process simultaneously upon startup and is responsible for terminating it upon exiting, thereby achieving automated management of the back-end service and synchronization with the main application's lifecycle. To ensure seamless operation of the desktop-embedded architecture, the system can automatically complete the necessary configuration. For example, backend service processes typically need to listen on a network port for communication with the frontend or other internal components. Automatically setting the service port avoids port conflicts and saves users the trouble of manual configuration. The system can intelligently select an available port or use a preset range of ports with a low probability of conflict. Switch configuration snapshots, device information, user preferences, and other data usually need persistent storage. Automatically setting the database path means the system will choose a suitable, default storage location in the user's local file system (e.g., the application data directory) without requiring user specification, thus simplifying data management. Furthermore, certain environment variables can be used to pass specific information about the runtime environment to backend service processes, such as indicating whether they are currently in desktop embedded mode. These desktop mode environment variables can affect the behavior of backend services, such as adjusting log levels, resource usage policies, or security settings to better suit the characteristics of the desktop environment. When a desktop application closes normally, the system automatically detects and terminates its embedded backend service processes. This ensures that all application-related resources (such as memory, CPU, file handles, etc.) are properly released, avoiding background process remnants, thus maintaining system cleanliness and efficiency, and preventing resource leaks or unnecessary resource consumption.

[0107] It should be noted that the above description describes some embodiments of the present invention. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than that shown in the above embodiments and still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0108] Secondly, based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a switch configuration monitoring and management system based on dual-channel unified access, such as... Figures 8-9 As shown.

[0109] The unified command execution module 100 is used to instantiate an SSH channel command execution object or a serial port channel command execution object according to the connection type. The command execution object implements the unified command execution interface, which includes a one-time read method, a streaming block callback method, and a connection close method. The device adapter module 200 is used to encapsulate device identification commands, version parsing logic, and configuration-class CLI command sequence generation logic; The configuration parsing module 300 is used to perform echo filtering, configuration segment segmentation, segment type classification and field extraction on CLI output text, and generate a structured configuration snapshot; The monitoring and acquisition module 400 is used to select an acquisition strategy based on the set of monitoring modules and execute a fallback mechanism. The configuration distribution module 500 is used to convert graphical configuration requests into CLI command sequences and distribute them to the switch; The connection switching module 600 is used to distribute SSH service configuration through the serial port channel, persist SSH connection parameters, and support dynamic switching between serial port and SSH connection methods. The streaming command interaction module 700 is used to provide an interactive command line interface and stream device output via the SSE protocol; The front-end display module 800 includes a monitoring view, a graphical operation view, and an interactive command-line view, used to display structured configuration data, receive graphical operations, and present terminal-style command interactions.

[0110] Furthermore, the unified command execution module 100 includes an SSH channel execution unit 110 and a serial port channel execution unit 120; The SSH channel execution unit 110 is used to establish a transmission control protocol connection, request a virtual terminal, start a shell process, execute a page close command, and read output data in a loop in an independent coroutine, and determine the end of the output segment by combining idle window detection and hard timeout. The serial port channel execution unit 120 is used to open the serial port, detect the login status, send an interrupt command to terminate the startup process when necessary, automatically fill in the login credentials, execute the page close command, and trigger the output callback block by block in the loop reading.

[0111] Furthermore, the device adapter module 200 supports expansion to devices from multiple manufacturers, isolating manufacturer differences through a unified adapter interface; The configuration parsing module 300 includes an output cleaning unit 310, a segmentation unit 320, a classification unit 330, and a field extraction unit 340. The output cleaning unit 310 is used to filter command echo lines, page break prompt lines, and prompt lines; The segmentation unit 320 is used to segment configuration segments using independent well number lines as separators. The classification unit 330 is used to assign segment types based on the first line keyword of the configuration segment; The field extraction unit 340 is used to extract structured fields from each segment using regular expressions and generate a configuration snapshot object in a unified format.

[0112] Furthermore, the streaming command interaction module 700 includes a backend streaming execution unit 710, an SSE push unit 720, and a frontend terminal rendering unit 730. The backend streaming execution unit 710 is used to reuse the dual-channel connection and call the streaming block callback method to read and push data simultaneously. The SSE push unit 720 is used to encapsulate output data, completion signals and error signals into corresponding types of SSE events and send them out in real time through the HTTP refresh mechanism. The front-end terminal rendering unit 730 is used to parse SSE events by reading the stream, incrementally render the terminal output area, and support command history navigation and automatic refresh of the monitoring view after configuration changes.

[0113] Furthermore, the system adopts a desktop embedded architecture, embedding a backend service process through a sidecar mechanism, automatically setting the service port, database path, and desktop mode environment variables, and terminating the backend process when the application exits. The serial port channel execution unit 120 is associated with a session pool and a device-level mutex. The session pool has a preset lifespan, and the device-level mutex ensures that serial port commands of the same device are executed serially. The SSH channel execution unit 110 is not a list of key exchange, encryption, and message authentication code algorithms in the set of security algorithms and the set of supported algorithms. It prioritizes the use of RSA host keys and supports dual authentication methods of password authentication and keyboard interaction authentication.

[0114] The system described above is used to implement the corresponding methods in the foregoing embodiments and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0115] Thirdly, based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described method for monitoring and managing switch configuration based on dual-channel unified access.

[0116] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.< / huawei>

Claims

1. A method for configuring, monitoring, and managing a switch based on dual-channel unified access, characterized in that, include: Instantiate a command execution object for the corresponding channel based on the connection type, wherein the connection type is either a Secure Shell Protocol (SSH) connection or a serial port connection, and the command execution object implements a unified command execution interface; Send command-line interface (CLI) commands to the switch through the unified command execution interface, and receive the text output returned by the switch; The text output is processed by echo filtering, configuration segment segmentation, and segment type classification, and a structured configuration snapshot is generated by parsing. Based on the requested set of monitoring modules, select either a single full data collection mode or a module-by-module data collection mode to acquire monitoring data, and execute a downgrade rollback command for modules with empty data collection results. Upon receiving a graphical configuration request, the device adapter converts the graphical configuration request into a CLI command sequence, which is then sent to the switch via the unified command execution interface. When the connection type is a serial port connection, the SSH service configuration command sequence is issued through the unified command execution interface, the SSH connection parameters are persisted, and the active connection mode can be dynamically switched between serial port connection and SSH connection. It provides an interactive command-line interface, accepts manually entered CLI commands, and pushes device output to the front-end rendering in real time in a streaming, chunked manner through the SSE protocol sent by the server. After the configuration command is executed, the structured monitoring view is automatically refreshed.

2. The method as described in claim 1, characterized in that, The text output is processed by echo filtering, configuration segment segmentation, and segment type classification. A structured configuration snapshot is generated through parsing, including: Filter command echo lines, page break prompt lines, and prompt lines to obtain clean configuration text; The clean configuration text is divided into multiple configuration segments using independent hash symbol lines as separators; Based on the keyword in the first line of each configuration segment, the configuration segments are classified into system name segment, virtual LAN segment, interface segment, static route segment, open shortest path first segment, or user segment; Perform regular expression matching on each line of the interface segment to extract the description, link mode, link type, access VLAN and management status fields, and generate a structured interface object.

3. The method as described in claim 1, characterized in that, The step of selecting either a single full-data acquisition mode or a modular acquisition mode to acquire monitoring data based on the requested set of monitoring modules, and executing a downgrade rollback command for modules with empty acquisition results, includes: Determine whether the monitoring module set contains the original text module; If the original text module is not included, execute the `display current-configuration` command once to obtain the full configuration text, parse it, and then output it by module. If the original text module is included, execute the mapped CLI command for each monitoring module to obtain the output text of the corresponding module; Perform null value validation on the parsing results of each monitoring module; When the parsing result is empty, execute the alternative CLI command that includes the include filter parameter; The alternative commands are output as the collection results of the monitoring module and returned.

4. The method as described in claim 1, characterized in that, The unified command execution interface includes a streaming, chunked callback method; wherein... The execution process of the streaming chunked callback method in the SSH channel includes: The standard output data is read in a loop within an independent coroutine. Each time a data block is read, it is passed to the main coroutine through a channel, and the output callback function is triggered. The main coroutine waits for data channel messages or hard timeout signals through a multiplexing mechanism; The idle timer is reset after each data block is received. The output segment ends when the idle timer reaches the preset idle window duration. The execution process of the streaming block callback method in the serial port channel includes: During the loop reading process, the output callback function is triggered block by block, and the end of the output segment is determined by the idle window detection. The serial port connection adopts a session pool reuse mechanism. When the cached session has not expired, its lifespan is renewed and reused. When it expires, a new serial port connection is created and cached. Each device identifier is bound to a mutex lock to ensure that commands on the same switch serial port are executed serially. When a serial port operation fails, the cached session is destroyed and the device is marked as offline.

5. The method as described in claim 1, characterized in that, The step of sending device output to the front-end rendering in real time via the SSE protocol through the server includes: The backend encapsulates each piece of output data into an output type SSE event, and the event data is a JSON format text block; A done type SSE event is sent when the command execution is complete, and an error type SSE event is sent when the execution fails. The event is immediately pushed to the client via the HTTP refresh mechanism; The front-end parses SSE events by reading the stream, incrementally appends text to the terminal output area, and automatically scrolls.

6. The method as described in claim 1, characterized in that, The step of issuing SSH service configuration command sequences through the unified command execution interface, persisting SSH connection parameters, and supporting dynamic switching of the active connection mode between serial port connection and SSH connection includes: Enter the system view through the serial port channel and execute the virtual LAN configuration, interface Internet Protocol address configuration, SSH service enable configuration, and local user configuration in sequence. After the configuration is successfully distributed, the SSH host address, SSH port number, and SSH configuration completion marker are stored in the database. When a connection switch request is received, the active connection type is switched to SSH connection, and subsequent commands are executed through the SSH client.

7. The method as described in claim 1, characterized in that, The interactive command-line interface supports Tab key command completion, and the completion logic includes: Extract the prefix of the currently entered word based on the cursor position; A candidate vocabulary is constructed from the basic command lexicon, the device port name set, and the historical command set. Candidate words starting with the prefix of the given word are filtered out, without checking the completeness of the preceding words; If there is a unique match, replace the current word with the complete word and append a space; if there are multiple matches and the longest common prefix is ​​longer than the current input, expand to the common prefix; otherwise, cycle through the candidate words at the same cursor position.

8. The method as described in claim 1, characterized in that, The process of receiving a graphical configuration request and converting it into a CLI command sequence via a device adapter includes: Receive port configuration parameters including layer mode, link type, VLAN, trunk VLAN set, management status, and Internet Protocol address; Generate CLI command sequences through the device adapter for entering the system view, entering the interface view, configuring link mode, configuring virtual LAN, and configuring management status; After the command is successfully issued, the local port record is updated, the front end triggers a configuration change event, and the monitoring view configuration data is automatically refreshed.

9. The method as described in claim 1, characterized in that, When the connection type is a serial port connection, the method further includes a serial port console intelligent login step: Detect the login status of the device after serial port connection; Send an interrupt command during the device startup phase to terminate the startup process; Automatically fill in login credentials based on username and password hints; After successful login, execute the command to close the page.

10. A switch configuration monitoring and management system based on dual-channel unified access, characterized in that, include: A unified command execution module is used to instantiate an SSH channel command execution object or a serial port channel command execution object according to the connection type. The command execution object implements a unified command execution interface, which includes a one-time read method, a streaming chunked callback method, and a connection close method. The device adaptation module encapsulates device identification commands, version parsing logic, and configuration-class CLI command sequence generation logic. The configuration parsing module is used to perform echo filtering, configuration segment segmentation, segment type classification and field extraction on CLI output text, and generate a structured configuration snapshot; The monitoring and acquisition module is used to select an acquisition strategy based on the set of monitoring modules and execute a fallback mechanism. The configuration distribution module is used to convert graphical configuration requests into CLI command sequences and distribute them to the switch; The connection switching module is used to distribute SSH service configurations via the serial port channel, persist SSH connection parameters, and support dynamic switching between serial port and SSH connection methods. The streaming command interaction module provides an interactive command-line interface and streams device output via the SSE protocol. The front-end display module includes a monitoring view, a graphical operation view, and an interactive command-line view, used to display structured configuration data, receive graphical operations, and present terminal-style command interactions.

Images