VXLAN tunnel dynamic management method and system based on state machine

Abstract

The invention discloses a VXLAN tunnel dynamic management method and system based on a state machine. According to the scheme, a VXLAN tunnel state machine model is defined, VXLAN tunnel states are defined based on life cycle division of a VXLAN tunnel, event processing logic is defined for each VXLAN tunnel state, and state transition rules among different VXLAN tunnel states are defined; and further responding to the event, triggering VXLAN tunnel state transition by the VXLAN tunnel state machine model, and in the state transition process, cooperating with software logic and hardware chip table entry operation to perform atomization updating. According to the scheme, automatic configuration, fault recovery and resource management of the tunnel are realized through multi-state cooperation, self-adaptive retry and atomization operation. According to the scheme of the invention, the problems of low tunnel establishment efficiency, long fault recovery time and easy flow interruption and resource leakage caused by a traditional mechanism can be avoided.

Description

Technical Field

[0001] This invention relates to computer network technology, and more particularly to the dynamic configuration and status management of virtualized network tunnels (VXLAN). Background Technology

[0002] With the rapid development of virtualization technology, data centers are expanding rapidly, and the number of data center tenants and virtual machines is growing explosively, posing significant challenges to traditional Layer 2 networks. Firstly, VLAN resources are insufficient. Traditional Layer 2 network isolation technology, VLAN, only allows for 4096 isolated Layer 2 networks due to its 12-bit tag field for identifying isolated virtual Layer 2 networks. This is far from meeting the needs of isolating a large number of tenants in large Layer 2 networks. Secondly, virtual machine migration is becoming increasingly frequent. To achieve flexible allocation of network services and resources, virtual machines are migrating across devices and even across data centers. To ensure uninterrupted service during virtual machine migration, the IP and MAC addresses of virtual machines must remain unchanged before and after migration, which traditional network technologies cannot achieve. Simultaneously, with the deployment of multi-center data centers, the demands for cross-data center migration, disaster recovery, and cross-data center load balancing mean that the expansion of Layer 2 networks must extend beyond the boundaries of data centers to include areas beyond data center servers, extending to local backup centers and remote disaster recovery centers. Generally, multiple data centers are connected via routing, naturally forming a Layer 3 network. To enable communication between two Layer 2 networks connected via a Layer 3 network, it is necessary to implement "L2 over L3".

[0003] Furthermore, Virtual eXtensible LAN (VXLAN) is a Layer 2 VPN technology based on IP networks and employing "MAC in UDP" encapsulation. VXLAN can provide Layer 2 interconnection for distributed physical sites based on existing service provider or enterprise IP networks, and can provide service isolation for different tenants. Meanwhile, VXLAN is primarily used in data center networks and campus access networks.

[0004] The existing scalable virtual local area network (VXLAN) technology still has the following main problems in practical applications: 1. VXLAN tunnels face complex configuration and state management challenges in dynamic network environments, such as route changes, ARP learning failures, and untimely updates of hardware entries.

[0005] 2. Traditional VXLAN tunnel management relies on static configuration or simple event triggering, lacking an adaptive state transition mechanism, resulting in low tunnel establishment efficiency and long fault recovery time.

[0006] 3. When traditional VXLAN tunnel management is implemented through the dynamic protocol EVPN, a large number of tunnels are generated in a large-scale network. Especially during network instability, this can cause constant fluctuations in the creation, deletion, and creation of these numerous tunnels, easily triggering performance issues.

[0007] 4. Traditional VXLAN tunnel management solutions have inconsistencies in chip entries (such as hardware forwarding rules) and software state coordination, which can easily lead to traffic interruptions or resource leaks.

[0008] 5. Limitations of traditional VXLAN tunneling operations, such as lack of atomic operations, which can easily lead to chip leakage.

[0009] 6. Traditional VXLAN tunnel management methods lack a follow-up mechanism for failed entry additions. This can lead to data traffic disruptions due to failed entry additions.

[0010] 7. Traditional tunnel management methods struggle to ensure efficient and stable tunnel operation when dealing with complex network environments and frequent configuration changes.

[0011] Therefore, how to effectively improve the efficiency of adding tunnels to hardware entries, reduce fault recovery time, and better support the independent design concept of VXLAN control plane and data plane is an urgent problem to be solved in this field. Summary of the Invention

[0012] To address the problems existing in current VXLAN tunnel management solutions regarding tunnel establishment efficiency and fault handling, the present invention aims to provide a state machine-based VXLAN tunnel management solution. By defining different states of VXLAN tunnels and transition schemes between states, it achieves refined management of the tunnel lifecycle and efficient event handling.

[0013] To achieve the above objectives, this invention provides a state machine-based dynamic management method for VXLAN tunnels, comprising: Define a VXLAN tunnel state machine model, define VXLAN tunnel states based on the lifecycle of VXLAN tunnels, define event processing logic for each VXLAN tunnel state, and define state transition rules between different VXLAN tunnel states. In response to events, the VXLAN tunnel state machine model triggers VXLAN tunnel state transitions, and during the state transition process, coordinates software logic and hardware chip table operations to perform atomic updates.

[0014] Furthermore, the VXLAN tunnel states configured in the VXLAN tunnel dynamic management method include one or more of the following: INIT (Initialization), ROUTE (Route Lookup), LEARN (ARP Learning), UPDATE (Chip Update), FINISH (Stable State), and DEAD (Failure State).

[0015] Furthermore, the VXLAN tunnel dynamic management method is configured to perform asynchronous sequential processing through an event queue during the state transition process of the VXLAN tunnel, processing only one event at a time.

[0016] Furthermore, the VXLAN tunnel dynamic management method, in hardware collaborative operation, includes: The lifecycle of chip entries is managed through the VXLAN_TUNNEL_HW flag. When transitioning to the INIT or DEAD state, if the VXLAN_TUNNEL_HW flag exists, the corresponding chip table entry will be forcibly deleted and the flag bit will be cleared.

[0017] Furthermore, the VXLAN tunnel dynamic management method provides a command-line interface to restore the tunnel state when the tunnel establishment fails or the configuration is deleted, or decides whether to retry or directly enter the DEAD state based on the error type.

[0018] To achieve the above objectives, the present invention provides a VXLAN tunnel dynamic management system based on a state machine, the VXLAN tunnel dynamic management system comprising: The VXLAN module is configured to implement a tunnel maintenance state machine, which can define VXLAN tunnel states based on the lifecycle of the VXLAN tunnel, define event processing logic for each VXLAN tunnel state, and define state transition rules between different VXLAN tunnel states. An event listening module is configured to capture network events; The state machine engine module is configured to interact with the event listening module and the VXLAN module. It can respond to events captured by the event listening module, trigger VXLAN tunnel state transitions, and perform atomic updates in coordination with software logic and hardware chip table operations during the state transition process.

[0019] Furthermore, the VXLAN tunnel states configured in the VXLAN module include one or more of the following: INIT (Initialization), ROUTE (Route Lookup), LEARN (ARP Learning), UPDATE (Chip Update), FINISH (Stable State), and DEAD (Failure State).

[0020] Furthermore, the state machine engine module is configured to perform asynchronous sequential processing via an event queue during the state transition process of the VXLAN tunnel, processing only one event at a time.

[0021] Furthermore, the state machine engine module is configured to include, during hardware cooperative operation: The lifecycle of chip entries is managed through the VXLAN_TUNNEL_HW flag. When transitioning to the INIT or DEAD state, if the VXLAN_TUNNEL_HW flag exists, the corresponding chip table entry will be forcibly deleted and the flag bit will be cleared.

[0022] Furthermore, the state machine engine module is configured to provide a command-line interface to restore the tunnel state when tunnel establishment fails or configuration is deleted, or to decide whether to retry or directly enter the DEAD state based on the error type.

[0023] The state machine-based VXLAN tunnel dynamic management scheme provided by this invention defines VXLAN tunnel states, constructs event-driven state transitions and hardware coordination mechanisms, and further achieves automatic tunnel configuration, fault recovery, and resource management through multi-state coordination, adaptive retries, and atomic operations. This invention avoids the problems of low tunnel establishment efficiency, long fault recovery time, and susceptibility to traffic interruptions and resource leaks caused by traditional mechanisms.

[0024] Furthermore, the VXLAN tunnel maintenance solution provided in this invention has the following advantages compared to existing technologies when applied: Improve reliability: Ensure the integrity of tunnel configuration through state machines to reduce human error; Dynamic adaptation: Supports rapid response to network topology changes (such as route switching and ARP updates); Efficient resource management: Atomized operations avoid chip entry leakage and reduce resource waste; Compatibility: Applicable to various scenarios such as SDN, cloud computing, and edge computing. Attached Figure Description

[0025] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0026] Figure 1 This is an example diagram of the VXLAN tunnel state machine transition in this invention; Figure 2 This is a flowchart of the chip entry update process in this invention; Figure 3 This is a fault recovery timing diagram in the present invention; Figure 4This is a schematic diagram of the VXLAN tunnel dynamic management system based on a state machine in this invention. Detailed Implementation

[0027] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below with reference to specific illustrations.

[0028] Definitions: VXLAN tunnel: A point-to-point logical tunnel between two VTEPs, responsible for forwarding VXLAN packets in the IP network; Chip entry: A hardware entry on the switching chip used to process VXLAN packet forwarding and packet header encapsulation.

[0029] This invention addresses VXLAN tunnels by constructing an event-driven VXLAN tunnel state machine model. This model defines different states of the VXLAN tunnel and the transition rules between these states. Through dynamic state transitions and hardware coordination mechanisms, it enables automatic configuration, fault recovery, and resource management of the VXLAN tunnel, thereby achieving refined management of the VXLAN tunnel lifecycle and efficient event processing.

[0030] Accordingly, this invention provides a dynamic management method for VXLAN tunnels based on state machines. This management method first defines and constructs a VXLAN tunnel state machine model.

[0031] The VXLAN tunnel state machine model defines VXLAN tunnel states based on the lifecycle division of VXLAN tunnels, configures corresponding events for each VXLAN tunnel state, defines event processing logic for each VXLAN tunnel state, and defines state transition rules between different VXLAN tunnel states.

[0032] Based on the defined VXLAN tunnel state machine model, a VXLAN tunnel state machine model is constructed to respond to configuration events or network events. The VXLAN tunnel state machine model triggers VXLAN tunnel state transitions and, during the state transition process, coordinates software logic and hardware chip table operations to perform atomic updates.

[0033] As further explanation, this management method divides the VXLAN tunnel lifecycle into multiple stages, including initialization, route lookup, ARP learning, chip update, stable state, and failure state. Each stage corresponds to a specific VXLAN state and event handling logic.

[0034] Accordingly, when defining VXLAN tunnel states, this management method preferably defines the following VXLAN tunnel states: INIT (Initialization), ROUTE (Route Lookup), LEARN (ARP Learning), UPDATE (Chip Update), FINISH (Stable State), and DEAD (Failure State).

[0035] This method defines VXLAN tunnel states based on the elements created during tunnel creation and the tunnel state maintenance within the chip. Each state can trigger corresponding operations to retrieve element information. For example, a state machine approach can be used to maintain tunnel elements. The creation, deletion, and updating of tunnels on the chip are all maintained with corresponding states, thereby effectively improving the efficiency and accuracy of tunnel maintenance on the chip.

[0036] Furthermore, the events configured for the defined VXLAN tunnel states include: configuring source address, configuring destination address, ARP update, ARP deletion, route change, deleting source address, and deleting destination address.

[0037] Each event configured here corresponds to tunnel change information, and tunnel events will cause tunnel state transitions. This allows events to drive changes in the tunnel state machine, thereby driving VXLAN tunnel state changes.

[0038] Specifically, the various causes of tunnel changes are defined as events to ensure that changes can be processed sequentially and atomically. Furthermore, events are unified through an event queue, with messages read sequentially from the queue, guaranteeing the atomicity of event processing and improving processing efficiency and consistency.

[0039] Furthermore, this management method constructs corresponding event processing logic for the configured events based on the defined VXLAN tunnel states in the VXLAN tunnel state machine model, that is, defines the event processing logic for different VXLAN tunnel states. For example, it defines the processing methods for events such as ARP update, route change, and address deletion under different states to ensure the correct migration of VXLAN tunnel states and the timely response to events.

[0040] As a further explanation, when a VXLAN tunnel is in a state, multiple events may occur that cause changes to the tunnel. In this regard, before processing these multiple events, this management method prioritizes merging or prioritizing the events. After prioritization, the priority events cause state transitions, and the transitioned state may simplify the processing of other events. Both merging and prioritization can improve the efficiency of event processing.

[0041] Furthermore, this management method constructs corresponding state transition rules in the VXLAN tunnel state machine model for the defined VXLAN tunnel states and the configured event definitions. At the same time, it defines the transition conditions between each VXLAN tunnel state based on the event processing state, thereby realizing event-driven VXLAN tunnel state transition (i.e., migration).

[0042] For example, once the source and destination addresses are configured, a transition from the initialization state to the route lookup state is triggered; conversely, if the route lookup is successful, a transition from the route lookup state to the ARP learning state is triggered, and so on.

[0043] This management method innovatively defines tunnel states and externally triggered events, making the state machine transition process simple and easy to maintain. Especially in scenarios with a large number of VXLAN tunnels undergoing changes, the merging and sorting of events significantly improves the performance of adding and deleting tunnels. Furthermore, the configured events are bound to tunnel states, ensuring that each event is processed only in a specific state. For example, the "Configure source address" and "Configure destination address" events only trigger the state transition to ROUTE in the INIT state; while the "ARP update" event is only processed in the LEARN, UPDATE, and FINISH states. Based on this event-state binding mechanism, invalid event processing can be effectively avoided, improving the accuracy of event processing and system efficiency.

[0044] As further explanation, this management method responds to configuration or network events based on a defined VXLAN tunnel state machine model, triggering VXLAN tunnel state transitions. Specifically, this management method uses an event listening module to capture network and configuration events in real time and submits them to an event queue. Subsequently, the state machine engine retrieves events from the queue sequentially, combines the current tunnel state with predefined rules, and triggers the corresponding state transition and processing logic. This response and triggering mechanism, through an asynchronous event queue, effectively ensures the sequentiality and atomicity of event processing, avoiding race conditions caused by concurrent events.

[0045] As a further explanation, this management method introduces a software and hardware coordination mechanism to coordinate the software logic and hardware chip entry operations during state transitions.

[0046] The software and hardware coordination mechanism here involves detecting a change in tunnel elements, triggering an event, and then determining through the software state machine that the hardware tunnel information needs to be deleted, while also using a flag to confirm the presence of this tunnel information in the hardware. At this point, the coordination mechanism is triggered to synchronously delete the hardware entry. Similarly, if the hardware entry fails to be sent, the software needs to be set to the corresponding state.

[0047] Specifically, this management method manages the lifecycle of hardware entries through a unified flag (VXLAN_TUNNEL_HW), ensuring strict consistency between software state and hardware entries. During state transitions, the software checks the flag to determine if a hardware entry exists and performs atomic add, update, or delete operations as necessary. For example, when transitioning to the INIT or DEAD state, if the VXLAN_TUNNEL_HW flag is detected, the corresponding hardware entry is forcibly deleted and the flag is cleared to prevent resource leaks. This collaborative mechanism significantly improves system consistency and reliability through state synchronization and atomic operations between software and hardware.

[0048] Furthermore, when performing chip entry operations, the lifecycle of the chip entry is first managed through the VXLAN_TUNNEL_HW flag. When the state transitions to the initialization (INIT) or failure (DEAD) state, if the VXLAN_TUNNEL_HW flag exists, the corresponding chip entry is forcibly deleted and the flag is cleared, indicating that this tunnel entry is deleted from the hardware, so that the software and hardware states are consistent, and the software logic and hardware chip entries are coordinated and consistent.

[0049] Building upon the aforementioned chip entry flag management scheme, this management method can further incorporate hardware operation rollback mechanisms, error recovery strategies, and atomic delivery processes to further enhance the hardware collaboration mechanism. For example, when a chip entry delivery fails, the system automatically rolls back to the previous stable state and records an error log, supporting subsequent manual or automatic recovery operations. This hardware collaboration mechanism, through multi-layered error handling and state rollback, significantly improves the system's fault tolerance and operational efficiency.

[0050] This management method uses atomic deletion and distribution mechanisms to perform atomic operations, thereby updating chip entries, ensuring strict consistency between hardware entries and software states, and reducing the risk of traffic interruption.

[0051] As further explanation, in this management method, during the state transition of the VXLAN tunnel, the corresponding events are processed sequentially through an event queue. By cyclically reading the messages in the event queue, it is ensured that the state machine is driven by only one external event at any given time.

[0052] Specifically, this management method uses a priority queue to achieve asynchronous sequential execution of event processing, ensuring that only one event is processed at a time. This asynchronous event queue processing mechanism is based on a priority queue, ensuring that high-priority events (such as configuration deletion) are processed first, while guaranteeing that only one event is processed at a time, thus avoiding concurrency conflicts.

[0053] Based on this, the asynchronous event queue processing mechanism can also dynamically adjust the processing strategy according to the event type and system load, further improving the system's response speed and resource utilization.

[0054] As a further explanation, this management method also incorporates a fault recovery mechanism to enable automatic recovery in the event of a VXLAN tunnel failure.

[0055] Specifically, this management method improves the robustness of tunnel establishment by providing a command-line interface to restore the tunnel state when tunnel establishment fails or configuration is deleted, or by deciding whether to retry or directly enter the failure state based on the error type.

[0056] The state machine-based VXLAN tunnel dynamic management scheme presented in this example can be configured into a corresponding software program to form a state machine-based VXLAN tunnel dynamic management system. During runtime, this software program executes the aforementioned state machine-based VXLAN tunnel dynamic management method and stores it in a suitable storage medium for the processor to retrieve and execute.

[0057] See Figure 4 The resulting VXLAN tunnel dynamic management system 100 based on state machines mainly includes three functional modules: VXLAN module 110, event listening module 120, and state machine engine module 130.

[0058] The VXLAN module 110 in this system is specifically configured to implement a tunnel maintenance state machine, which can define VXLAN tunnel states based on the lifecycle of the VXLAN tunnel, define event processing logic for each VXLAN tunnel state, and define state transition rules between different VXLAN tunnel states.

[0059] The event listening module 120 of this system is configured to capture network events or configured events; The state machine engine module 130 of this system is configured to interact with the event listening module 120 and the VXLAN module 110. It can respond to events captured by the event listening module, trigger VXLAN tunnel state transitions, and perform atomic updates in coordination with software logic and hardware chip table operations during the state transition process.

[0060] The following section provides a more detailed explanation of the configuration of each module in this VXLAN tunnel dynamic management system and the equipment that may be involved.

[0061] In this system, when the VXLAN module 110 maintains the tunnel maintenance state machine, it divides the VXLAN tunnel lifecycle into multiple stages based on the VXLAN tunnel lifecycle, such as initialization, route lookup, ARP learning, chip update, stable state, and failure state. Each stage corresponds to a specific VXLAN state and event handling logic.

[0062] Accordingly, the VXLAN module 110 defines the VXLAN tunnel states for the maintained VXLAN tunnels, including initialization (INIT), routing lookup (ROUTE), ARP learning (LEARN), chip update (UPDATE), stable state (FINISH), and failure state (DEAD).

[0063] Additionally, the following events are configured for the defined VXLAN tunnel status: Configure source address, configure destination address, ARP update, ARP deletion, route change, delete source address, delete destination address.

[0064] Based on this, the VXLAN module 110 constructs corresponding event processing logic for the configured events according to the defined VXLAN tunnel states, that is, it defines the event processing logic under different VXLAN tunnel states. For example, it defines the processing methods under different states for events such as ARP update, route change, and address deletion to ensure the correct migration of VXLAN tunnel states and timely response to events.

[0065] This VXLAN module 110 constructs corresponding state transition rules based on the defined VXLAN tunnel states and the configured event definitions. It defines the transition conditions between each VXLAN tunnel state based on the event processing state, thereby realizing event-driven VXLAN tunnel state transition (i.e., migration). For example, if the source address and destination address are configured, the transition from the initialization state to the route lookup state is triggered; if the route lookup is successful, the transition from the route lookup state to the ARP learning state is triggered, and so on.

[0066] When the state machine engine module 130 in this system triggers the VXLAN tunnel state transition process based on the events monitored by the event listening module 120, it performs asynchronous sequential processing on the corresponding events through the event queue, processing only one event at a time.

[0067] As an example, asynchronous sequential execution is preferably achieved through a priority queue.

[0068] Furthermore, during the VXLAN tunnel state transition process, this state machine engine module 130 ensures atomic updates by coordinating software logic and hardware chip entry operations.

[0069] Specifically, when the VXLAN tunnel state transitions, the state machine engine module 130 checks whether the VXLAN tunnel has already been sent to the hardware. If it determines that the tunnel information already exists in the hardware, it synchronously deletes it from the hardware. Conversely, if the corresponding hardware settings fail, it needs to notify the VXLAN tunnel to be migrated to the corresponding state, thereby achieving software and hardware collaboration to ensure information consistency.

[0070] As a further explanation, the hardware coordination operation here includes first managing the lifecycle of chip entries through the VXLAN_TUNNEL_HW flag; when the state transitions to the initialization INIT state or the failure DEAD state, if the VXLAN_TUNNEL_HW flag exists, the corresponding chip entry is forcibly deleted and the flag is cleared. After the state transition, it indicates that the tunnel information has become incomplete, and the hardware information needs to be deleted synchronously.

[0071] Based on this, the state machine engine module 130 performs atomic operations through atomic deletion and distribution mechanisms to update chip entries, ensuring that hardware entries are strictly consistent with software states and reducing the risk of traffic interruption.

[0072] Furthermore, the state machine engine module 130 also constructs a fault recovery mechanism during the VXLAN tunnel state transition process, so as to achieve automatic recovery when the VXLAN tunnel fails.

[0073] Specifically, this management method improves the robustness of tunnel establishment by providing a command-line interface to restore the tunnel state when tunnel establishment fails or configuration is deleted, or by deciding whether to retry or directly enter the failure state based on the error type.

[0074] The following examples illustrate the operation of the VXLAN tunnel dynamic management system 100 based on a state machine as provided in this invention.

[0075] In this example, when the VXLAN tunnel dynamic management system 100 is running, the tunnel maintenance state machine formed by the VXLAN module for the tunnel to be maintained is defined as follows: The defined VXLAN tunnel states include: initialization (INIT), route lookup (ROUTE), ARP learning (LEARN), chip update (UPDATE), stable state (FINISH), and failure state (DEAD).

[0076] For the defined VXLAN tunnel states, corresponding state transition rules are constructed, and VXLAN tunnel state transitions are driven by events, combined with... Figure 1 As shown, the corresponding XLAN tunnel state transition diagram illustrates the relationship between states and events: Initialization state (INIT): After the source and destination addresses are configured, the system enters the route lookup state; Action: If the tunnel has the VXLAN_TUNNEL_HW flag, indicating that a chip has been issued, all corresponding chip content needs to be deleted.

[0077] Route lookup status (ROUTE): Action: Look up the destination address route in the tunnel. If the lookup is successful, return the next-hop address and enter the LEARN state; otherwise, if the destination address is unreachable, check if the hardware flag has been set. If so, call the delete interface to delete the data on the chip, and the state remains unchanged.

[0078] ARP learning status (LEARN): Action: Query the ARP of the next-hop address. If successful: If no chip-issued record exists, enter the FINISH state; if a chip-issued record exists, enter the update state. If ARP retrieval fails, the state remains unchanged. Check if a hardware flag has been set; if so, call the delete interface to delete the data on the chip. If retrieval fails multiple times (e.g., 5 times, with a 1-second interval), and the ARP cannot be retrieved for an extended period in the LEARN state, it can fall back to the ROUTE state to re-find the route, or enter the DEAD state.

[0079] Steady state (FINISH): Action: Chip configuration establishment: If the configuration is successfully established, the VXLAN_TUNNEL_HW flag is set for this tunnel, indicating that the tunnel has been added to the hardware table and the system enters the FINISH state. If the chip configuration fails to be established, detailed error information is recorded, and a decision is made based on the error type to retry or directly enter the DEAD state.

[0080] Update status (UPDATE): Action: Delete the existing chip record with the chip tunnel ID value, set the new chip value according to the new parameter information, that is, refresh the existing tunnel; if the refresh is successful, enter FINISH; if the refresh fails, it can be determined according to the reason for failure, and needs to be set again next time, and the UPDATE state is maintained; otherwise, enter the DEAD state.

[0081] Failure status (DEAD): Action: Event handling: Provides a command-line interface to revert to the route state and log errors. Alternatively, it can handle address changes and migrate to the INIT state.

[0082] The configured events for the VXLAN tunnel's defined state include: (1) Configure source address: Set the source address flag. If both the source and destination addresses are configured, enter the ROUTE state; otherwise, enter the INIT state. (2) Configure the destination address: Set the destination address flag; if both the source and destination addresses are configured, enter the ROUTE state; otherwise, enter the INIT state. (3) ARP update: Only the LEARN, UPDATE, and FINISH states require this event to be handled, as detailed below: INIT state: Ignore this event and do not process it; LEARN state: State remains unchanged; ARP is relearned. UPDATE status: Status unchanged; the previous UPDATE event has not yet been processed, the two updates are merged, and the tunnel is refreshed; FINISH state: Entering UPDATE state; tunnel needs to be refreshed; UPDATE status: Ignore this event and do not process it; DEAD state: Ignore this event and do not process it.

[0083] The behavior of each state in handling this event is as follows: In INIT, UPDATE, and DEAD, this event is ignored and not processed; in LEARN state, the state remains unchanged, and ARP is relearned; in UPDATE state, the state remains unchanged, the two event processing events are merged, and the hardware tunnel information is refreshed; in FINISH state, the state enters UPDATE state, and the hardware tunnel information is refreshed at the same time.

[0084] (4) ARP deletion: Only LEARN, UPDATE, and FINISH handle this event, as follows: INIT state: Ignore this event and do not process it; LEARN state: State remains unchanged; relearn ARP; UPDATE status: Entering LEARN; Relearning ARP; FINISH state: Delete the tunnel configuration on the chip, then enter LEARN; relearn ARP; UPDATE status: Ignore this event and do not process it; DEAD state: Ignore this event and do not process it.

[0085] Therefore, this event is ignored and not processed in the INIT, LEARN, UPDATE, and DEAD states; in the UPDATE state, it is necessary to enter the LEARN state and perform ARP relearning; in the FINISH state, it is necessary to enter the LEARN state, delete the tunnel information on the chip, and perform ARP relearning.

[0086] (5) Routing changes: UPDATE status: Entering ROUTE; LEARN status: Entering ROUTE; FINISH status: Entering ROUTE; ROUTE State: Enters the ROUTE state; adds a count statistic. Limits the number of route change events processed in the ROUTE state. If a certain number of events (3 times) is exceeded, it can enter the DEAD state to avoid an infinite loop. Simultaneously, the number of route change events can be recorded in the logs for easier troubleshooting.

[0087] INIT state: Ignore this event and do not process it; DEAD state: Ignore this event and do not process it.

[0088] In the UPDATE, LEARN, and FINISH states, routing change events are handled by directly jumping to the ROUTE state. This approach may interrupt currently ongoing operations (such as chip updates or ARP learning). To avoid such interruptions, all events are processed sequentially within the same task. In the INIT and DEAD states, this event is ignored and not processed.

[0089] (6) Delete source address && Delete destination address: UPDATE status: Entering INIT, no further processing; LEARN status: Enter INIT, no further processing; FINISH state: Enter INIT, delete the tunnel configuration on the chip. If deletion fails, enter DEAD state and log the error reason.

[0090] ROUTE status: Enter INIT, no other processing; INIT status: Remain in INIT state, no further processing; DEAD state: Enter INIT, no further processing.

[0091] Accordingly, when the tunnel state is in UPDATE, LEARN, ROUTE, or DEAD, it jumps to INIT state without any further processing; in INIT state, the state remains unchanged without any further processing; in FINISH state, it enters INIT state, deletes the tunnel configuration on the chip, and if deletion fails, it needs to enter DEAD state and log the reason for the error.

[0092] To address the aforementioned events, this system ensures sequential processing by handling them within the same task. For concurrent or asynchronous events, an event message queue is used to randomly sort the events, ensuring that only one event is processed at a time. For example, in the LEARN state of a VXLAN tunnel, ARP update and route change events may be received simultaneously. Here, an event message queue can be used to randomly sort the events, processing only one event at a time.

[0093] This system uses atomic deletion and distribution mechanisms to update chip entries, ensuring strict consistency between hardware entries and software states. Figure 2 As shown, the corresponding update process is as follows: Step 1: Check the VXLAN_TUNNEL_HW flag to see if the tunnel is already in the hardware table. If it exists, delete the old entry. If it does not exist, proceed to Step 2. Step 2: Send the new table entry to the hardware chip. If the sending is successful, proceed to Step 3; if the sending fails, proceed to Step 4. Step 3: Update the flag and log the changes, then end. Step 4: Set up error identification and start error analysis. Determine whether the error is recoverable based on the error type: if recoverable, proceed to step 5; if not, proceed to step 6. Step 5: Try to send the message again after a preset number of attempts (e.g., 3 times). If the message is sent successfully, update the flag and log the message, then end the process. If the message is still unsuccessful after the preset number of attempts, proceed to Step 6. Step 6: Enter DEAD state and log the process, then end.

[0094] Continuing with the above instructions, if sending a new entry to the hardware chip fails, a rollback operation will be performed, reverting to the old entry and marking it as DEAD, followed by fault recovery. See also... Figure 3 The corresponding fault recovery timing process is as follows: First, the fault is triggered: A chip failure triggers a transition from the FINISH state to the DEAD state. Next, while in DEAD state, manually restore: The administrator sends a recovery command via CLI, triggering the transition from the DEAD state to the ROUTE state; Next, in ROUTE mode, automatically retry: The state machine re-executes route lookup and ARP learning.

[0095] Based on the above implementation scheme, it can be seen that the VXLAN tunnel maintenance scheme provided by this invention is based on a state machine to manage VXLAN tunnels. Through innovative schemes such as state definition, event-driven transition, and hardware coordination mechanism, it realizes automatic tunnel configuration, fault recovery, and resource management, which can avoid the problems of low tunnel establishment efficiency, long fault recovery time, and easy traffic interruption and resource leakage caused by traditional mechanisms.

[0096] Based on the above-described state machine-based VXLAN tunnel dynamic management scheme, this embodiment of the invention also provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the steps of the above-described state machine-based VXLAN tunnel dynamic management method.

[0097] This invention also provides a processor for running a program, wherein the program executes the steps of the state machine-based VXLAN tunnel dynamic management method described above.

[0098] This invention also provides a terminal device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. The program code is loaded and executed by the processor to implement the steps of the state machine-based VXLAN tunnel dynamic management method described above.

[0099] The present invention also provides a computer program product, which, when executed on a data processing device, is adapted to perform the steps of the above-described state machine-based VXLAN tunnel dynamic management method.

[0100] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0101] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0102] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0103] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0104] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0105] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0106] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0107] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0108] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0109] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0110] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0111] The method, specific system unit, or part thereof of the present invention described above is a pure software architecture. It can be deployed via program code on physical media, such as hard disks, optical discs, or any electronic device (such as smartphones or computer-readable storage media). When a machine loads and executes the program code (e.g., a smartphone loads and executes it), the machine becomes a device for implementing the present invention. The method and device of the present invention can also be transmitted in program code form via transmission media, such as cables, optical fibers, or any other transmission method. When the program code is received, loaded, and executed by a machine (e.g., a smartphone), the machine becomes a device for implementing the present invention.

[0112] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A dynamic management method for VXLAN tunnels based on state machines, characterized in that, include: Define a VXLAN tunnel state machine model, define VXLAN tunnel states based on the lifecycle of VXLAN tunnels, define event processing logic for each VXLAN tunnel state, and define state transition rules between different VXLAN tunnel states. In response to events, the VXLAN tunnel state machine model triggers VXLAN tunnel state transitions, and during the state transition process, coordinates software logic and hardware chip table operations to perform atomic updates.

2. The VXLAN tunnel dynamic management method based on state machine according to claim 1, characterized in that, The VXLAN tunnel states configured in the VXLAN tunnel dynamic management method include one or more of the following: INIT (Initialization), ROUTE (Route Lookup), LEARN (ARP Learning), UPDATE (Chip Update), FINISH (Stable State), and DEAD (Failure State).

3. The VXLAN tunnel dynamic management method based on state machine according to claim 1, characterized in that, The VXLAN tunnel dynamic management method is configured to perform asynchronous sequential processing through an event queue during the state transition process of the VXLAN tunnel, processing only one event at a time.

4. The VXLAN tunnel dynamic management method based on state machine according to claim 1, characterized in that, The VXLAN tunnel dynamic management method, in hardware collaborative operation, includes: The lifecycle of chip entries is managed through the VXLAN_TUNNEL_HW flag. When transitioning to the INIT or DEAD state, if the VXLAN_TUNNEL_HW flag exists, the corresponding chip table entry will be forcibly deleted and the flag bit will be cleared.

5. The VXLAN tunnel dynamic management method based on state machine according to claim 1, characterized in that, The VXLAN tunnel dynamic management method provides a command-line interface to restore the tunnel state when the tunnel establishment fails or the configuration is deleted, or decides whether to retry or directly enter the DEAD state based on the error type.

6. A VXLAN tunnel dynamic management system based on a state machine, characterized in that, The VXLAN tunnel dynamic management system includes: The VXLAN module is configured to implement a tunnel maintenance state machine, which can define VXLAN tunnel states based on the lifecycle of the VXLAN tunnel, define event processing logic for each VXLAN tunnel state, and define state transition rules between different VXLAN tunnel states. An event listening module is configured to capture network events; The state machine engine module is configured to interact with the event listening module and the VXLAN module. It can respond to events captured by the event listening module, trigger VXLAN tunnel state transitions, and perform atomic updates in coordination with software logic and hardware chip table operations during the state transition process.

7. The VXLAN tunnel dynamic management system based on a state machine according to claim 6, characterized in that, The VXLAN tunnel states configured in the VXLAN module include one or more of the following: INIT (Initialization), ROUTE (Route Lookup), LEARN (ARP Learning), UPDATE (Chip Update), FINISH (Stable State), and DEAD (Failure State).

8. The VXLAN tunnel dynamic management system based on a state machine according to claim 7, characterized in that, The state machine engine module is configured to perform asynchronous sequential processing via an event queue during the state transition process of the VXLAN tunnel, processing only one event at a time.

9. The VXLAN tunnel dynamic management system based on a state machine according to claim 6, characterized in that, The state machine engine module is configured to include, during hardware cooperative operation: The lifecycle of chip entries is managed through the VXLAN_TUNNEL_HW flag. When transitioning to the INIT or DEAD state, if the VXLAN_TUNNEL_HW flag exists, the corresponding chip table entry will be forcibly deleted and the flag bit will be cleared.

10. The VXLAN tunnel dynamic management system based on a state machine according to claim 6, characterized in that, The state machine engine module is configured to provide a command-line interface to restore the tunnel state when tunnel establishment fails or configuration is deleted, or to decide whether to retry or directly enter the DEAD state based on the error type.

Images