A VLAN message processing method supporting a multi-port mode and having a running state rule updating capability

Abstract

The application discloses a VLAN message processing method and system supporting a multi-port mode and having a running state rule updating capability, electronic equipment and a storage medium. The method comprises the following steps: receiving configuration updating data and temporarily storing the configuration updating data in an updating cache; when a preset boundary condition is met, uniformly submitting the configuration updating data to an effective rule storage structure; receiving an input message and analyzing a VLAN to which the input message belongs; querying a VLAN permission rule to determine whether the input message is allowed to enter; performing switching forwarding on the input message allowed to enter and determining a target output port; querying the VLAN permission rule and a label processing rule to determine whether the input message is allowed to be sent and whether a label is deleted; and finally performing corresponding operation output. The system comprises a configuration interface, a cache updating and boundary submission control, a message analysis and other modules. The application improves the running state rule updating stability, the system structure consistency, the rule reuse degree and the expansion capability through a unified rule updating architecture, a unified processing of rule driving, a rule storage combined with a template table and a bitmap table, and a separation design of a control plane and a data plane.

Description

Technical Field

[0001] This application relates to the field of network communication and data exchange technology, specifically to a VLAN packet processing method, apparatus, electronic device, and storage medium that supports multi-port mode and has runtime rule update capability. Background Technology

[0002] With the widespread application of Ethernet switching equipment in campus networks, data center networks, industrial communication networks, and embedded communication systems, Layer 2 network isolation and traffic management technology based on Virtual Local Area Networks (VLANs) has become a fundamental function in network devices. By dividing different services, users, or ports into different VLANs, broadcast domain isolation, simplified network management, and enhanced security can be achieved. Therefore, VLAN functionality is widely used in switching chips, switching equipment, and other network devices that require packet forwarding.

[0003] In existing switching equipment, ports typically support multiple operating modes, including Access, Trunk, and Hybrid. Access ports are generally used for connecting terminal devices, usually belonging to only one VLAN, and sending packets in untagged form. Trunk ports are generally used for interconnection between switching devices, allowing packets from multiple VLANs to pass through, and typically sending and receiving packets in tagged form. Hybrid ports combine some features of the above two types of ports, allowing multiple VLANs to pass through and allowing for tagged or untagged transmission for different VLANs. Because these three port modes differ in application scenarios, configuration methods, and packet processing behavior, their implementation directly affects the data plane complexity, configuration flexibility, and system scalability of the switching equipment. Summary of the Invention

[0004] This application discloses a VLAN packet processing method, apparatus, electronic device, and storage medium that supports multi-port modes and has the ability to update rules in runtime. It aims to solve the technical problems caused by the separate implementation of different port modes in existing switching equipment, such as logical dispersion, complex configuration, large hardware resource overhead and insufficient scalability, as well as the easy occurrence of mixing of old and new rules and inconsistent processing of in-transit packets during the rule update process in runtime.

[0005] To achieve the above objectives, the first aspect of this application provides a VLAN packet processing method that supports multi-port mode and has runtime rule update capabilities, including: Receive configuration update data and temporarily store the configuration update data in the update cache; the configuration update data includes VLAN allow rules and VLAN tag processing rules. The VLAN allow rules are used to indicate whether the corresponding VLAN is allowed to receive or send on the corresponding port. The VLAN tag processing rules are used to indicate whether the corresponding VLAN's packets are processed by retaining or deleting tags when sent on the corresponding port. If the preset boundary conditions are met, the configuration update data in the update cache is uniformly submitted to the currently effective rule storage structure to realize hot update of running rules. Receive input messages and parse the input messages to determine their VLAN membership; Based on the VLAN to which the packet belongs, query the currently effective VLAN permission rules to determine whether the packet is allowed to enter the subsequent processing flow from the ingress port; Perform switching and forwarding processing on allowed incoming packets and determine the target output port; Based on the VLAN to which the message belongs and the target output port, query the currently effective VLAN permission rules and VLAN tag processing rules to determine whether the message is allowed to be sent from the target output port and whether tag deletion needs to be performed; For messages that are allowed to be sent and whose tags need to be removed, the tags are removed and the messages are output; for messages that are allowed to be sent and whose tags do not need to be removed, the tags are retained and the messages are output. The method does not use Access, Trunk, and Hybrid port modes as the direct branching basis for packet processing. Instead, it achieves unified rule processing for the three port modes through a combination of the VLAN permission rules and the VLAN tag processing rules.

[0006] Optionally, the rule storage structure is implemented using a combination of template tables and bitmap tables; The step of querying the currently effective VLAN permission rules based on the VLAN to which the packet belongs includes: The first template number is obtained by querying the allow rule template table based on the VLAN ID to which the message belongs, and then the corresponding port allow rule is obtained by querying the allow rule bit table based on the first template number. The step of querying the currently effective VLAN tag processing rule based on the VLAN to which the packet belongs and the target output port includes: querying the tag processing template table to obtain the corresponding second template number based on the VLAN ID to which the packet belongs, and then querying the tag processing bitmap table based on the second template number to obtain the corresponding port tag processing rule.

[0007] Optionally, the preset boundary conditions include at least one of the following: the current message processing pipeline is cleared, the rule item to be updated has not been accessed by the data plane within a preset time, and a preset safe handover time has been reached.

[0008] Optionally, before receiving configuration update data, the following may also be included: Receive configuration parameters sent by the user; Perform a consistency check on the configuration parameters. The consistency check includes: checking whether the port configured to delete the VLAN tag belongs to the allowed port set of the corresponding VLAN, checking whether the rule combination of the same port meets the preset constraints, and checking whether there are conflicting configurations. The configuration data that passes the verification will be used as the configuration update data.

[0009] Optionally, after performing a consistency check on the configuration parameters, the method further includes: The equivalent working mode of the corresponding port is identified based on the configuration combination of the allow rules and tag processing rules in the configuration parameters; When a port only allows packets from its default VLAN to pass through, and the VLAN tag is removed when sending packets from the default VLAN, it is identified as Access mode; when a port allows packets from multiple VLANs to pass through, and only packets from the default VLAN have their VLAN tags removed when sent, while packets from other VLANs retain their VLAN tags, it is identified as Trunk mode; when a port allows packets from multiple VLANs to pass through, and it is possible to configure the retention or deletion of VLAN tags when sending packets for different VLANs, with the tag deletion scope not limited to the default VLAN, it is identified as Hybrid mode.

[0010] Optionally, parsing the input packet to determine its VLAN membership includes: Determine whether the input message carries a VLAN tag; When a message carries a VLAN tag, the VLAN ID in the message is extracted as the VLAN to which it belongs; When a packet does not carry a VLAN tag, the VLAN to which it belongs is determined according to the default VLAN configuration of the ingress port, and the corresponding VLAN tag is added to the packet.

[0011] To achieve the above objectives, a second aspect of this application also provides a VLAN packet processing system that supports multi-port mode and has runtime rule update capabilities, comprising: The configuration interface module is used to receive configuration update data and temporarily store the configuration update data in an update cache; the configuration update data includes VLAN permission rules and VLAN tag processing rules; The cache update and boundary submission control module is used to detect whether the preset boundary conditions are met. If they are met, the configuration update data in the update cache is uniformly submitted to the currently effective rule storage structure to realize the hot update of running rules. The message parsing module is used to receive input messages and parse the input messages to determine the VLAN to which they belong; The entry legitimacy determination module is used to query the currently effective VLAN permission rules based on the VLAN to which the packet belongs, and determine whether the packet is allowed to enter the subsequent processing flow from the entry port; The switching processing module is used to perform switching and forwarding processing on allowed incoming packets and determine the target output port; The outbound legality determination module is used to query the currently effective VLAN permission rules and VLAN tag processing rules based on the VLAN to which the packet belongs and the target output port, and to determine whether the packet is allowed to be sent from the target output port and whether tag deletion needs to be performed; The unified tag deletion module is used to delete the tags of messages that are allowed to be sent and whose tags need to be deleted, and to retain the tags of messages that are allowed to be sent and whose tags do not need to be deleted. The system does not use Access, Trunk, and Hybrid port modes as the direct branching basis for data plane packet processing. Instead, it achieves unified rule processing for the three port modes through a combination of VLAN permission rules and VLAN tag processing rules.

[0012] Optionally, the rule storage structure includes a rule storage module and a tag processing rule storage module; Both the permission rule storage module and the tag processing rule storage module adopt a structure combining template tables and bitmaps. The template table is used to record the association between VLAN IDs and template numbers; the bitmap table is used to record the correspondence between template numbers and specific port rule bitmaps. The system queries the corresponding template table based on the VLAN ID to obtain the template number, and then queries the corresponding bit table based on the template number to obtain the corresponding port permission rule or tag processing rule.

[0013] To achieve the above objectives, a third aspect of this application also provides an electronic device, including a processor and a memory, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, it implements the VLAN packet processing method provided above, which supports multi-port mode and has runtime rule update capability.

[0014] To achieve the above objectives, a fourth aspect of this application also provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the VLAN packet processing method provided above, which supports multi-port mode and has runtime rule update capability.

[0015] This application discloses a VLAN packet processing method that supports multi-port mode and has runtime rule update capability, comprising: receiving configuration update data and temporarily storing the configuration update data in an update cache; the configuration update data includes VLAN permission rules and VLAN tag processing rules, wherein the VLAN permission rules are used to characterize whether the corresponding VLAN is allowed to receive or send on the corresponding port, and the VLAN tag processing rules are used to characterize the processing action of retaining or deleting tags when the packet of the corresponding VLAN is sent on the corresponding port; detecting whether a preset boundary condition is met, and if so, uniformly submitting the configuration update data in the update cache to the currently effective rule storage structure to realize hot update of runtime rules; receiving an input packet, parsing the input packet to determine its VLAN; and querying the current VLAN according to the VLAN to which the packet belongs. The effective VLAN permission rule determines whether the packet is allowed to enter the subsequent processing flow from the ingress port; for allowed packets, switching and forwarding processing is performed, and the target output port is determined; based on the VLAN to which the packet belongs and the target output port, the currently effective VLAN permission rule and the VLAN tag processing rule are queried to determine whether the packet is allowed to be sent from the target output port and whether tag deletion is required; for packets allowed to be sent and whose tags need to be deleted, tag deletion is performed before output; for packets allowed to be sent and whose tags do not need to be deleted, the tags are retained before output; wherein, the method does not use Access, Trunk, and Hybrid port modes as the direct branch basis for packet processing, but achieves unified rule processing for the three port modes through the combination of the VLAN permission rule and the VLAN tag processing rule.This application addresses the issues of mixed use of old and new rules and inconsistent processing of in-transit packets during rule updates in existing VLAN processing schemes during runtime. It constructs a unified rule update architecture for VLAN packet processing, combining a master table, update cache, and boundary commit control. This ensures that new configurations issued by the control plane do not directly rewrite currently effective rules, but are temporarily stored and uniformly applied when preset boundary conditions are met. This avoids intermediate processing states during rule updates, improving the stability of runtime rule updates and the consistency of in-transit packet processing. Furthermore, this application unifies the behavior under different port modes into VLAN allow rules and VLAN tags. The processing rules are implemented in a rule-driven manner to achieve unified description and processing of three port modes: Access, Trunk, and Hybrid. This allows the data plane to complete ingress legitimacy determination, egress transmission determination, and tag processing action selection within the same rule processing framework. The tag deletion module handles the processing of packets requiring de-tagged transmission, improving the consistency of the system structure and the regularity of the implementation. Furthermore, this application employs a combination of template tables and bitmaps for rule storage. By merging multiple VLANs with the same or similar rule characteristics into the same template item and indexing the specific rule content in the corresponding bitmap using the template number, the redundant storage of complete rule bitmaps is reduced while supporting the entire VLAN ID range. This improves rule reusability and reduces rule storage resource overhead, making it particularly suitable for applications with large port scales or high rule redundancy. Moreover, this application improves the system's engineering feasibility, configuration flexibility, and future scalability through a structure design that separates control plane configuration and data plane table lookup. Attached Figure Description

[0016] Figure 1 A schematic diagram of the architecture of a VLAN packet processing system that supports multi-port mode and has runtime rule update capability, provided for an embodiment of this application; Figure 2 A schematic diagram of a rule storage structure combining template tables and bitmap tables provided in an embodiment of this application; Figure 3 A schematic diagram of the internal table entries of a template table and a bitmap provided in this application embodiment; Figure 4 This application provides a schematic diagram of a configuration management and hot update path. Figure 5 A schematic diagram of an input message processing flow provided in an embodiment of this application; Figure 6 A schematic diagram of an outgoing message processing flow provided in this application embodiment; Figure 7A schematic diagram illustrating the mapping relationship between Access, Trunk, and Hybrid port modes and rule combinations provided in this application embodiment; Figure 8 A schematic diagram illustrating the consistency verification and port pattern recognition of a supporting software configuration program provided in this application embodiment; Figure 9 A flowchart illustrating the method provided in this application embodiment. Detailed Implementation

[0017] Explanation of key terms: Edge device / server / terminal: In this application, it refers to hardware devices such as switching chips and FPGA / ASIC-based network devices that perform packet forwarding, as well as control plane devices that run supporting software configuration programs.

[0018] Business object / control object: In this application, the target output port, rule storage structure (including the permission rule storage module and the tag processing rule storage module) and unified tag deletion module are the specific physical or logical objects that affect the reasoning results.

[0019] Existing solutions typically do not employ entirely different hardware architectures when implementing the three port modes. Instead, they use the same set of switching hardware, employing different configuration methods to achieve differentiated behaviors for Access, Trunk, and Hybrid port modes. Publicly available technologies also include implementations that use port bitmaps to describe VLAN behavior. For example, VLAN Port Bitmaps describe VLAN membership relationships, and Untagged Bitmaps or similar bitmaps describe tag processing behavior during packet transmission. These methods offer good support for VLAN membership control and tag processing control, with advantages such as direct table lookup and clear implementation.

[0020] However, existing solutions typically have the following problems when implementing the above three port modes: 1) In scenarios with a large number of ports and VLANs, if the method of storing complete port rule bitmaps item by item for each VLAN is still used, then each VLAN needs to correspond to a complete set of port rule descriptions. When supporting the entire VLAN ID range, the rule storage depth needs to cover the entire range, and the width of each rule bitmap is related to the number of ports. Therefore, as the VLAN scale and port scale increase, the resource overhead of the rule storage structure will also increase. Especially when a large number of port allow relationships or tag processing relationships have duplicate or similar characteristics, the method of storing complete rule bitmaps item by item for each VLAN will cause a large number of duplicate rule contents to be repeatedly saved, which is not conducive to rule reuse and resource optimization.

[0021] 2) For hybrid ports, it is necessary to support the passage of multiple VLAN packets and to decide whether to retain or delete tags when sending packets for different VLANs. Therefore, when the system still uses a directly expanded bitmap method to organize rules, although it can achieve basic functions, it is often not compact enough in terms of rule reuse, configuration management, and subsequent expansion. Especially in scenarios that need to support runtime rule updates, if the rule storage structure lacks hierarchical organization, it will not only increase the complexity of rule management, but also hinder resource control and consistency switching during the update process.

[0022] 3) Some existing solutions couple VLAN membership control, port mode control, and tag addition / deletion control together, resulting in unclear boundaries between configuration paths and data paths. This is not conducive to the separation of control plane and data plane design, nor is it conducive to subsequent system expansion and function reuse.

[0023] Besides the aforementioned implementation complexity and resource overhead issues, existing processing solutions face a more critical problem when performing configuration updates in runtime: the consistency of processing during the configuration update process. Specifically, if new rules issued from the control plane directly modify currently active rules in the data plane, different packets within the update window may see the old rules, the new rules, or even rules in an intermediate update state, leading to inconsistent processing results for packets in transit. This is especially problematic when the system involves both allowance and label processing rules; if these two types of rules cannot be coordinated during the update process, situations are more likely to occur where "allowance rules have been updated but label processing rules have not," or vice versa, thus affecting the correctness and stability of packet processing.

[0024] As mentioned above, the key to VLAN port mode processing lies not only in supporting control over packet forwarding permissions under different port modes and tag retention or deletion under different port modes, but also in how to update rules without interrupting system operation and ensuring consistency of packet processing results before and after the update when rules are modified. If these behaviors cannot be uniformly abstracted, implemented, and updated, problems such as logical duplication, implementation complexity, high resource consumption, and inconsistent configuration switching can easily occur in the design of multi-port, multi-VLAN switching devices.

[0025] Furthermore, in hardware implementation, directly adopting distributed configuration storage and distributed packet processing not only increases the complexity of control logic but also affects the processing efficiency of the data plane. Especially with the continuous expansion of the number of ports and the scale of VLANs, how to construct a VLAN packet processing architecture that can uniformly describe multiple port modes, support efficient table lookups, facilitate hardware implementation, and support runtime hot updates has become an urgent problem to be solved in related technologies. Therefore, it is necessary to improve one or more of the problems existing in the aforementioned related technical solutions.

[0026] refer to Figure 1 The first embodiment of this application provides a VLAN packet processing method that supports multi-port modes and has runtime rule update capabilities. This addresses the technical problems mentioned in the background art, such as logical dispersion, complex configuration, high hardware resource overhead, and insufficient scalability caused by the separate implementation of different port modes in existing switching equipment, as well as the easy mixing of old and new rules and inconsistencies in in-transit packet processing during runtime rule updates. This method can be executed by a processor, which can be located in a terminal or server. The execution process of the VLAN packet processing method that supports multi-port modes and has runtime rule update capabilities is as follows: Step S101: Receive configuration update data and temporarily store the configuration update data in the update cache; the configuration update data includes VLAN allow rules and VLAN tag processing rules. The VLAN allow rules are used to indicate whether the corresponding VLAN is allowed to receive or send on the corresponding port. The VLAN tag processing rules are used to indicate whether the corresponding VLAN's packets are processed by retaining or deleting tags when sent on the corresponding port.

[0027] In one embodiment of this application, configuration data issued by the control plane first enters the update cache via the configuration interface module, rather than directly rewriting the currently used rule storage structure. The update cache is used to temporarily store new rules or rule change information that are yet to take effect.

[0028] Step S102: Check whether the preset boundary conditions are met. If they are met, submit the configuration update data in the update cache to the currently effective rule storage structure to achieve hot update of running rules.

[0029] In one embodiment of this application, boundary commit control is used to detect preset boundary conditions, and when the conditions are met, writes the content in the update cache into the currently effective rule storage structure, thereby completing the rule update. This main table plus update cache approach avoids the intermediate processing issues caused by directly modifying effective rules during data plane operation, thus supporting runtime hot updates.

[0030] refer to Figure 4 , Figure 4 A schematic diagram of the configuration management and hot update path provided for a VLAN packet processing method that supports multi-port mode and has runtime rule update capabilities.

[0031] Figure 4 A schematic diagram illustrating the configuration management and hot update path is shown. For example... Figure 4 As shown, the user first inputs new configuration parameters in the supporting software configuration program. After parsing the configuration data, the supporting software configuration program sends the configuration data to the configuration interface module through the control plane. The configuration interface module does not directly write the new configuration into the currently effective rule storage structure, but first writes it into the update cache for temporary storage. The boundary submission control module receives the configuration to be effective in the update cache, and at the same time receives input from the boundary condition detection part. When the preset boundary conditions are met, the boundary submission control module controls the configuration in the update cache to be uniformly written into the allowed rule storage structure and the tag processing rule storage structure, thereby completing the hot update. In this embodiment, feasible boundary conditions include the following situations: the current message processing pipeline is cleared, rule access is idle, and the preset safe switching time is reached. Here, "rule access is idle" means that the rule item to be updated is not accessed by the ingress legality determination module or the egress legality determination module, thereby avoiding the writing of new values ​​during the rule reading process; "the current message processing pipeline is cleared" can be used to ensure that the messages that previously entered the processing path have completed the existing rule processing; "the preset safe switching time" can be used to provide a unified switching window at the system scheduling level. The above-described hot update path design enables rule updates without interrupting data plane packet processing and ensures consistency of packet processing results during configuration switching. It should be noted that existing research on network rule updates has pointed out that during runtime rule switching, if old and new rules are mixed within the update window, inconsistent configuration states may be observed in individual packets during processing. Therefore, it is necessary to ensure consistency in packet processing during the update process. This invention does not perform update control on the entire network path or general software system, but rather implements the concept of consistent updates within the architecture. Through update caching and boundary commit control mechanisms, configuration switching is completed at the on-chip rule storage structure level, thereby achieving hot rule updates without interrupting data plane processing and improving the consistency of in-transit packet processing.

[0032] In an optional embodiment of this application, the preset boundary conditions include at least one of the following: the current message processing pipeline is cleared, the rule item to be updated has not been accessed by the data plane within a preset time, and a preset safe handover time has been reached.

[0033] Furthermore, "rule access idle" here means that the rule item to be updated is not accessed by the ingress or egress validity determination module, thus avoiding the writing of new values ​​during rule reading; "current message processing pipeline cleared" can be used to ensure that messages that previously entered the processing path have completed existing rule processing; "reaching the preset safe switching time" can be used to provide a unified switching window at the system scheduling level. Through the above hot update path design, rule updates can be completed without interrupting data plane message processing, and the consistency of message processing results during configuration switching can be guaranteed.

[0034] Step S103: Receive the input message and parse the input message to determine its VLAN.

[0035] refer to Figure 5 , Figure 5 A schematic diagram of the ingress packet processing flow provided for a VLAN packet processing method that supports multi-port mode and has runtime rule update capabilities.

[0036] Figure 5 The ingress message processing flow is shown. For example... Figure 5 As shown, the ingress processing first receives the input packet and determines whether it carries a tag. If the packet carries a tag, the corresponding VLAN ID is directly extracted; if the packet does not carry a VLAN tag, the VLAN to which it belongs is determined according to the default VLAN configuration of the ingress port. After the VLAN is determined, the system queries the permission rules and determines whether the ingress port allows the VLAN to enter based on the query results. If not, the packet is discarded; if allowed, the packet is sent to the switching processing module for further processing, and subsequent switching and forwarding are completed according to the permission rules. Therefore, the ingress processing path uniformly adopts the process of "parse VLAN—query permission rules—determine whether entry is allowed," without constructing independent ingress data paths based on different port modes.

[0037] In one embodiment of this application, the ingress processing first receives the input packet and determines whether the packet carries a tag. If the packet carries a tag, the corresponding VLAN ID is directly extracted; if the packet does not carry a VLAN tag, the VLAN to which it belongs is determined according to the default VLAN configuration of the ingress port. After the VLAN is determined, the system queries the allow rules and determines whether the ingress port allows the VLAN to enter based on the query results.

[0038] In an optional embodiment of this application, parsing the input message to determine its VLAN membership includes: Determine whether the input message carries a VLAN tag; When a message carries a VLAN tag, the VLAN ID in the message is extracted as the VLAN to which it belongs; When a packet does not carry a VLAN tag, the VLAN to which it belongs is determined based on the default VLAN configuration of the ingress port, and the corresponding VLAN tag is added to the packet.

[0039] Furthermore, the message parsing module is used to determine whether the input message carries a tag and extract the VLAN ID from the message, or, if the message does not carry a tag, to determine its domain based on the default VLAN configuration of the ingress port and add a tag to it.

[0040] Step S104: Query the currently effective VLAN permission rules based on the VLAN to which the packet belongs, and determine whether the packet is allowed to enter the subsequent processing flow from the ingress port.

[0041] In one embodiment of this application, the ingress legitimacy determination module determines whether a packet is allowed to enter the system from the current ingress port based on the parsed VLAN information and the allow rules in the right-hand rule storage structure. For legitimate packets, they are sent to the switching processing module for further processing; for illegitimate packets, they are not further forwarded.

[0042] refer to Figure 2 and Figure 3 , Figure 2 A schematic diagram illustrating the rule storage structure combining template tables and bitmap tables, provided for a VLAN packet processing method that supports multi-port mode and has runtime rule update capabilities. Figure 3 This is a schematic diagram of the internal table entries in the template table and bitmap.

[0043] In an optional embodiment of this application, the rule storage structure is implemented using a combination of template tables and bitmap tables; The query will look up the currently active rules for that VLAN based on the VLAN to which the message belongs, including: The first template number is obtained by querying the allow rule template table based on the VLAN ID to which the message belongs, and then the corresponding port allow rule is obtained by querying the allow rule bitmap table based on the first template number. The process involves querying the currently effective VLAN tagging rules based on the VLAN to which the packet belongs and the target output port. This includes: querying the tagging template table to obtain the corresponding second template number based on the VLAN ID to which the packet belongs, and then querying the tagging bitmap table based on the second template number to obtain the corresponding port tagging rules.

[0044] Furthermore, the rule storage structure in this application does not employ the method of storing complete port rule bitmaps for each VLAN item. Instead, it divides the rule storage into two parts: a template table and a bitmap table. For allow rules, the allow rule template table is first accessed using the VLAN ID to obtain the corresponding template number. Then, the template number is used as an index to access the allow rule bitmap table, thereby obtaining the corresponding port allow rule. For tag processing rules, the tag processing template table is first accessed using the VLAN ID to obtain the corresponding template number. Then, the template number is used as an index to access the tag processing bitmap table, thereby obtaining the corresponding tag processing rule. In this way, multiple VLANs with the same rule characteristics can be mapped to the same template item, reducing the redundant storage of rule bitmaps, improving rule reusability and reducing storage resource overhead while supporting the entire VLAN ID range.

[0045] For example, the template table on the left stores the correspondence between VLAN IDs and template numbers. Its depth can cover the entire range of supported VLAN identifiers, such as VLAN IDs from 1 to 4094 in this embodiment. Each item in the template table includes at least a VLAN ID and a corresponding template number field. The bitmap on the right stores the correspondence between template numbers and specific port rule bitmaps. Its depth is determined by the number of rule templates. Each item includes at least a template number and a rule bitmap field corresponding to the number of ports. For the allow rule bitmap, each bit in the bitmap corresponds to a port. A bit value of "1" indicates that the corresponding port allows the VLAN, and "0" indicates that the corresponding port does not allow the VLAN. For the tag processing bitmap, each bit in the bitmap corresponds to a port. A bit value of "1" indicates that the corresponding port performs tag deletion for the VLAN, and a bit value of "0" indicates that the corresponding port retains the tag for the VLAN. This two-level organization of "template table + bitmap" decouples the rule content from the VLAN identifier and reduces storage costs through template reuse.

[0046] Step S105: Perform switching and forwarding processing on the allowed incoming packets and determine the target output port.

[0047] In one embodiment of this application, after the message passes through the exchange processing module, it enters the exit legality determination module.

[0048] Step S106: Based on the VLAN to which the packet belongs and the target output port, query the currently effective VLAN permission rules and VLAN tag processing rules to determine whether the packet is allowed to be sent from the target output port and whether tag deletion needs to be performed.

[0049] refer to Figure 6 , Figure 6A schematic diagram of the outgoing / outgoing packet processing flow provided for a VLAN packet processing method that supports multi-port mode and has runtime rule update capabilities.

[0050] In one embodiment of this application, the egress processing first receives a packet from the switching processing path and determines the target output port of the packet. Then, it queries the tag processing rules and, in conjunction with the permission rules, determines whether the target port allows processing of the VLAN ID. If VLAN tag deletion is required according to the rules, the packet is sent to the VLAN tag deletion module, the tag is deleted, and the packet is output; if tag deletion is not required according to the rules, the VLAN tag in the packet is retained, and the packet is output directly. In this embodiment, the key to the egress processing path is to uniformly determine the two types of actions, "whether to send" and "whether to delete the tag," based on the rules corresponding to the target port. Therefore, the egress stage does not require setting three separate sets of logic for Access, Trunk, and Hybrid modes; instead, the behavioral differences between different modes can be achieved by querying a unified rule.

[0051] Step S107: For messages that are allowed to be sent and whose tags need to be deleted, perform tag deletion and output; for messages that are allowed to be sent and whose tags do not need to be deleted, retain the tags and output.

[0052] In one embodiment of this application, if deletion is required, the tag deletion module is entered to delete the tag from the message before sending it; if deletion is not required, the VLAN tag is retained before sending. Thus, both the ingress and egress directions use a unified lookup path and a unified processing framework, eliminating the need to design independent data plane structures for different port modes.

[0053] refer to Figure 8 , Figure 8 A schematic diagram illustrating the consistency verification and port mode identification of the supporting software configuration program for VLAN packet processing methods that support multi-port modes and have runtime rule update capabilities.

[0054] In an optional embodiment of this application, before receiving the configuration update data, the method further includes: Receive configuration parameters sent by the user; Perform a consistency check on the configuration parameters. The consistency check includes: checking whether the port configured to delete the VLAN tag belongs to the allowed port set of the corresponding VLAN, checking whether the rule combination of the same port meets the preset constraints, and checking whether there are conflicting configurations. The configuration data that passes the verification will be used as the configuration update data.

[0055] Furthermore, the user operation layer can input new configuration parameters and modify existing configurations. This input is first sent to the software configuration layer, where the accompanying software configuration program parses the configuration parameters and performs a consistency check. This consistency check includes, but is not limited to, the following: checking whether the port to be deleted belongs to the allowed port set; checking whether the port rule combination meets preset constraints; and checking for any illegal or conflicting configurations. After the consistency check passes, the accompanying software configuration program further identifies the port pattern based on the rule combination. After pattern recognition is completed, the software configuration program generates the corresponding configuration data and sends it to the data plane via the CPU. Therefore, in this embodiment, port pattern recognition and configuration validity checks are mainly performed by the software configuration layer, thereby reducing the hardware logic complexity of the data plane.

[0056] In an optional embodiment of this application, after performing a consistency check on the configuration parameters, the method further includes: The equivalent operating mode of the corresponding port is identified based on the configuration combination of the allow rules and tag processing rules in the configuration parameters; When a port only allows packets from its default VLAN to pass through, and the VLAN tag is removed when sending packets from the default VLAN, it is identified as Access mode; when a port allows packets from multiple VLANs to pass through, and only packets from the default VLAN have their VLAN tags removed when sent, while packets from other VLANs retain their VLAN tags, it is identified as Trunk mode; when a port allows packets from multiple VLANs to pass through, and it is possible to configure the retention or deletion of VLAN tags when sending packets for different VLANs, with the tag deletion scope not limited to the default VLAN, it is identified as Hybrid mode.

[0057] Furthermore, this application does not explicitly store which mode the port belongs to in the data plane, nor does it use this as a direct basis for packet processing. Instead, it uniformly maps the three port modes to different combinations of VLAN permission relationships and VLAN tag processing relationships.

[0058] refer to Figure 7 , Figure 7 A schematic diagram illustrating the mapping relationship between Access, Trunk, and Hybrid port modes and rule combinations for VLAN packet processing methods that support multi-port modes and have runtime rule update capabilities.

[0059] For example, in Access mode, the port allows only one VLAN's packets to pass through, and the VLAN tag is removed upon transmission. In Trunk mode, the port allows multiple VLAN's packets to pass through, and the tag is processed accordingly based on whether it is the default VLAN tag upon transmission. In Hybrid mode, the port allows multiple VLAN's packets to pass through, and different VLANs can be configured to retain or remove VLAN tags during transmission. Thus, although the three port modes differ in their manifestation, they can all be mapped to different combinations of VLAN permission relationships and VLAN tag processing relationships, thereby achieving unified hardware processing that replaces mode-driven processing with rule-driven processing.

[0060] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention addresses the problems of mixed use of old and new rules and inconsistent processing of in-transit packets during rule updates in existing VLAN processing schemes during runtime. It constructs a unified rule update architecture for VLAN packet processing, combining a master table, update cache, and boundary commit control. This ensures that new configurations issued by the control plane do not directly rewrite currently effective rules, but are temporarily stored and uniformly applied when preset boundary conditions are met. This avoids intermediate processing states during rule updates, improving stability and consistency of in-transit packet processing during runtime rule updates. Simultaneously, this invention abstracts the behaviors of different port modes into unified VLAN allow rules and VLAN tag processing rules, implementing unified description and processing for Access, Trunk, and Hybrid port modes in a rule-driven manner. This allows the data plane to complete ingress legitimacy determination, egress transmission determination, and tag processing action selection within the same rule processing framework. A tag deletion module handles packets requiring de-tag transmission, improving system structure consistency and implementation regularity. Furthermore, this invention uses a combination of template tables and bitmap tables for rule storage, allowing multiple VLANs with the same or similar rule characteristics to be stored together. By merging rules into the same template item and indexing the specific rule content in the corresponding bitmap with the template number, the redundant storage of complete rule bitmaps is reduced while supporting the entire VLAN ID range. This improves rule reusability and reduces rule storage resource overhead, making it particularly suitable for application scenarios with a large number of ports or high rule redundancy. Furthermore, the present invention improves the system's engineering feasibility, configuration flexibility, and subsequent expansion capabilities through the structural design of separating control plane configuration and data plane table lookup.

[0061] To address the aforementioned technical problems, the second embodiment of this application provides a VLAN packet processing system that supports multi-port mode and has runtime rule update capabilities, in order to solve the same technical problems as the method embodiment. The system 1000 may include the following modules: a configuration interface module 1001, a cache update and boundary submission control module 1002, a packet parsing module 1003, an ingress legality determination module 1004, a switching processing module 1005, an egress legality determination module 1006, and a unified tag deletion module 1007.

[0062] The configuration interface module 1001 is used to receive configuration update data and temporarily store the configuration update data in the update cache; the configuration update data includes VLAN permission rules and VLAN tag processing rules.

[0063] The cache update and boundary submission control module 1002 is used to detect whether the preset boundary conditions are met. If they are met, the configuration update data in the update cache is uniformly submitted to the currently effective rule storage structure to realize the hot update of running rules.

[0064] The message parsing module 1003 is used to receive input messages and parse the input messages to determine the VLAN to which they belong.

[0065] The entry legitimacy determination module 1004 is used to query the currently effective VLAN permission rules based on the VLAN to which the packet belongs, and determine whether the packet is allowed to enter the subsequent processing flow from the entry port.

[0066] The switching processing module 1005 is used to perform switching and forwarding processing on allowed incoming packets and determine the target output port.

[0067] The export legality determination module 1006 is used to query the currently effective VLAN permission rules and VLAN tag processing rules based on the VLAN to which the packet belongs and the target output port, and to determine whether the packet is allowed to be sent from the target output port and whether tag deletion needs to be performed.

[0068] The unified tag deletion module 1007 is used to delete the tags of messages that are allowed to be sent and whose tags need to be deleted, and to retain the tags of messages that are allowed to be sent and whose tags do not need to be deleted.

[0069] This system does not use Access, Trunk, and Hybrid port modes as the direct branching basis for data plane packet processing. Instead, it achieves unified rule processing for the three port modes through a combination of VLAN permission rules and VLAN tag processing rules.

[0070] In an optional embodiment of this application, the rule storage structure includes a rule storage module and a tag processing rule storage module; Both the permission rule storage module and the tag processing rule storage module adopt a structure that combines template tables and bitmaps. This template table records the association between VLAN IDs and template numbers; this bitmap table records the correspondence between template numbers and specific port rule bitmaps. The system retrieves the template number from the corresponding template table based on the VLAN ID, and then retrieves the corresponding bit table based on the template number to obtain the corresponding port permission rule or tag processing rule.

[0071] In another embodiment, this application also proposes a VLAN packet processing system supporting three port modes: Access, Trunk, and Hybrid. The system includes a configuration interface module, an allow rule storage module, a tag processing rule storage module, a packet parsing module, an ingress legitimacy determination module, an egress legitimacy determination module, an update cache, a boundary submission control module, and a unified tag deletion module. The system is accompanied by software configuration programs for performing consistency checks on configuration data and port mode identification.

[0072] The configuration interface module receives configuration data from the control plane and writes it into the corresponding rule storage structure or update path. The configuration data includes membership information and tag processing control information. The permission rule storage module records the set of allowed ports for each VLAN, and the tag processing rule storage module records the tag processing control information for each VLAN on each port. By storing information for different functions in two independent rule storage structures, VLAN forwarding permission control and VLAN tag processing control are separated, reducing control logic coupling and facilitating hardware implementation, rule reuse, and subsequent functional expansion.

[0073] For the proposed permission rule storage module and tag processing rule storage module, the rule storage structure is implemented using a combination of template tables and bitmaps. Specifically, the template table stores the merged rule template numbers. The rule templates include port permission rule templates and tag processing rule templates. The port permission rule templates describe the allowable reception and allowable transmission relationships of the corresponding VLAN on each port, while the tag processing rule templates describe the tag processing relationships of the corresponding VLAN on each port. These tag processing relationships include at least retaining VLAN tags and deleting VLAN tags. The bitmap describes the association between each rule template and specific processing operations, allowing different VLANs to query the bitmap by template number to obtain their corresponding port permission rules and tag processing rules. By using a combination of template tables and bitmaps, it is no longer necessary to store complete port rule bitmaps for each VLAN separately. Instead, multiple VLANs with the same or similar rule characteristics are merged into the same template item for reuse. The data plane lookup processing requirements are met simply by recording the mapping relationship between the bitmap and the template item. In practical applications, many port permission relationships and tag processing relationships often exhibit repetitive or similar characteristics. Therefore, this approach can meet the rule description requirements of most common VLAN member management and tag processing scenarios while supporting the entire VLAN ID range. It also reduces the redundant saving of complete rule bitmaps, thereby lowering the resource overhead of the rule storage structure. This implementation is particularly suitable for hardware implementation environments with a large number of ports, high rule redundancy, or high sensitivity to on-chip storage resources. Furthermore, it facilitates subsequent rule expansion, unified management, and integration with runtime hot update mechanisms.

[0074] For the proposed configuration method, this invention writes data issued from the control plane into a rule-based storage structure through a register configuration path. That is, the control plane is responsible for issuing low-frequency configurations, while the data plane is responsible for high-speed table lookup processing based on the rule-based storage structure, thus separating control plane configuration from data plane table lookup. This approach retains the flexibility of register configuration while meeting the high-speed access requirements of the hardware data plane.

[0075] To support hot updates of VLAN rules during system operation, this invention establishes a master table, an update cache, and a boundary submission control mechanism. Currently effective VLAN rules are stored in the master table. Configuration update data issued by the control plane is not directly written to the master table but is first temporarily stored in the update cache. When a preset boundary condition is detected, the boundary submission control module writes the configuration data from the update cache back to the master table and applies it uniformly. This method avoids the intermediate processing issues caused by directly modifying currently effective rules during data plane processing, thus achieving smooth hot updates of rules and ensuring the consistency of packet processing results during configuration updates. The update cache stores rule items to be modified or rule item change information, rather than a full copy of the entire master table, reducing the additional storage resource overhead of the hot update mechanism. The preset boundary conditions include: clearing the current packet processing pipeline, completing the current batch of packet processing, rule access being idle for a certain period, or reaching a preset safe handover time.

[0076] The proposed packet processing flow adopts a unified inbound and outbound processing architecture. For data packets entering the device, the packet parsing module first parses the packet to determine if it carries a VLAN tag. If the packet carries a VLAN tag, the VLAN ID is extracted. If the packet does not carry a tag, the domain to which the packet belongs is determined based on the default VLAN identifier corresponding to the ingress port, and the packet is tagged accordingly. Subsequently, the ingress legitimacy determination module, based on the packet's domain access permission rule storage structure, determines whether the packet is allowed to enter the subsequent processing flow from the ingress port. Packets that do not meet the conditions are discarded, while packets that meet the conditions are forwarded.

[0077] For the message transmission process, this invention also adopts a unified outbound processing flow. After the target outbound port is determined, the outbound legality determination module queries the tag processing rule storage structure according to the VLAN to which the message belongs. If deletion is required, the tag deletion module performs tag deletion on the message before sending; if deletion is not required, the VLAN tag is retained before sending. Thus, both the inbound and outbound directions use a unified table lookup path and a unified processing framework, eliminating the need to design independent data plane structures for different port modes.

[0078] Further, the present invention includes a software configuration program matched with the VLAN message processing system, wherein the software configuration program is configured to receive configuration parameters issued by a user and perform consistency check on the configuration data. The consistency check at least comprises: checking whether a port configured to delete a label in a label processing rule simultaneously belongs to an allowed port set of a corresponding VLAN; checking whether a configuration combination of the same port meets a preset port mode constraint; and checking whether illegal or conflicting configuration exists. Through the consistency check, configuration correctness can be improved, and wrong configuration is prevented from directly acting on a data plane.

[0079] The software configuration program can also be configured to automatically identify an equivalent working mode of a port according to configuration results in an allowing rule and a label processing rule. Through this mode, the port mode in the present invention is no longer used as a direct driving condition for data plane processing, but is implicitly defined by a combination of configuration rules, and can be automatically identified and output by the matched software configuration program.

[0080] For the three proposed port modes, the present invention does not respectively construct independent processing logics, but describes and maps the port modes through a unified configuration model. For an Access mode, a port thereof only allows messages of one VLAN to pass through, and deletes a VLAN label during sending; for a Trunk mode, a port thereof allows messages of multiple VLANs to pass through, and correspondingly processes a label according to whether the label is a default VLAN label during sending; for a Hybrid mode, a port thereof allows messages of multiple VLANs to pass through, and can be respectively configured, for different VLANs, to retain a VLAN label for sending or delete a VLAN label for sending. It can be seen that although the three port modes are different in manifestation, they can all be mapped into different combination configurations of a VLAN allowing relationship and a VLAN label processing relationship, so that unified hardware processing with rule driving replacing mode driving is implemented.

[0081] In order to solve the above technical problem, a third embodiment of the present application provides an electronic device to solve the same technical problem as that of the method embodiment. The electronic device may comprise a processor and a memory, wherein a computer program is stored on the memory, and when executed by the processor, the computer program implements the VLAN message processing method that supports multiple port modes and has a running-state rule updating capability provided in the previous embodiments.

[0082] In order to solve the above technical problem, a fourth embodiment of the present application provides a computer-readable storage medium to solve the same technical problem as that of the method embodiment. A computer program is stored on the computer-readable storage medium, and when executed by a processor, the computer program implements the VLAN message processing method that supports multiple port modes and has a running-state rule updating capability provided in the previous embodiments.

Claims

1. A VLAN packet processing method that supports multi-port mode and has runtime rule update capability, characterized in that, include: Receive configuration update data and temporarily store the configuration update data in the update cache; The configuration update data includes VLAN permission rules and VLAN tag processing rules. The VLAN permission rules are used to indicate whether the corresponding VLAN is allowed to receive or send on the corresponding port. The VLAN tag processing rules are used to indicate whether the corresponding VLAN's packets are processed by retaining or deleting tags when sent on the corresponding port. If the preset boundary conditions are met, the configuration update data in the update cache is uniformly submitted to the currently effective rule storage structure to realize hot update of running rules. Receive input messages and parse the input messages to determine their VLAN membership; Based on the VLAN to which the packet belongs, query the currently effective VLAN permission rules to determine whether the packet is allowed to enter the subsequent processing flow from the ingress port; Perform switching and forwarding processing on allowed incoming packets and determine the target output port; Based on the VLAN to which the message belongs and the target output port, query the currently effective VLAN permission rules and VLAN tag processing rules to determine whether the message is allowed to be sent from the target output port and whether tag deletion needs to be performed; For messages that are allowed to be sent and whose tags need to be removed, the tags are removed and the messages are output; for messages that are allowed to be sent and whose tags do not need to be removed, the tags are retained and the messages are output. The method does not use Access, Trunk, and Hybrid port modes as the direct branching basis for packet processing. Instead, it achieves unified rule processing for the three port modes through a combination of the VLAN permission rules and the VLAN tag processing rules.

2. The method as described in claim 1, characterized in that, The rule storage structure is implemented using a combination of template tables and bitmap tables. The step of querying the currently effective VLAN permission rules based on the VLAN to which the packet belongs includes: The first template number is obtained by querying the allow rule template table based on the VLAN ID to which the message belongs, and then the corresponding port allow rule is obtained by querying the allow rule bit table based on the first template number. The step of querying the currently effective VLAN tag processing rule based on the VLAN to which the packet belongs and the target output port includes: querying the tag processing template table to obtain the corresponding second template number based on the VLAN ID to which the packet belongs, and then querying the tag processing bitmap table based on the second template number to obtain the corresponding port tag processing rule.

3. The method as described in claim 1, characterized in that, The preset boundary conditions include at least one of the following: the current message processing pipeline is cleared, the rule item to be updated has not been accessed by the data plane within a preset time, and a preset safe handover time has been reached.

4. The method as described in claim 1, characterized in that, Before receiving configuration update data, it also includes: Receive configuration parameters sent by the user; Perform a consistency check on the configuration parameters. The consistency check includes: checking whether the port configured to delete the VLAN tag belongs to the allowed port set of the corresponding VLAN, checking whether the rule combination of the same port meets the preset constraints, and checking whether there are conflicting configurations. The configuration data that passes the verification will be used as the configuration update data.

5. The method as described in claim 4, characterized in that, After performing a consistency check on the configuration parameters, the method further includes: The equivalent working mode of the corresponding port is identified based on the configuration combination of the allow rules and tag processing rules in the configuration parameters; When a port only allows packets from its default VLAN to pass through, and the VLAN tag is removed when sending packets from the default VLAN, it is identified as Access mode; when a port allows packets from multiple VLANs to pass through, and only packets from the default VLAN have their VLAN tags removed when sent, while packets from other VLANs retain their VLAN tags, it is identified as Trunk mode; when a port allows packets from multiple VLANs to pass through, and it is possible to configure the retention or deletion of VLAN tags when sending packets for different VLANs, with the tag deletion scope not limited to the default VLAN, it is identified as Hybrid mode.

6. The method as described in claim 1, characterized in that, The process of parsing the input message to determine its VLAN membership includes: Determine whether the input message carries a VLAN tag; When a message carries a VLAN tag, the VLAN ID in the message is extracted as the VLAN to which it belongs; When a packet does not carry a VLAN tag, the VLAN to which it belongs is determined according to the default VLAN configuration of the ingress port, and the corresponding VLAN tag is added to the packet.

7. A VLAN packet processing system that supports multi-port mode and has runtime rule update capability, characterized in that, include: The configuration interface module is used to receive configuration update data and temporarily store the configuration update data in the update cache; The configuration update data includes VLAN permission rules and VLAN tag processing rules; The cache update and boundary submission control module is used to detect whether the preset boundary conditions are met. If they are met, the configuration update data in the update cache is uniformly submitted to the currently effective rule storage structure to realize the hot update of running rules. The message parsing module is used to receive input messages and parse the input messages to determine the VLAN to which they belong; The entry legitimacy determination module is used to query the currently effective VLAN permission rules based on the VLAN to which the packet belongs, and determine whether the packet is allowed to enter the subsequent processing flow from the entry port; The switching processing module is used to perform switching and forwarding processing on allowed incoming packets and determine the target output port; The outbound legality determination module is used to query the currently effective VLAN permission rules and VLAN tag processing rules based on the VLAN to which the packet belongs and the target output port, and to determine whether the packet is allowed to be sent from the target output port and whether tag deletion needs to be performed; The unified tag deletion module is used to delete the tags of messages that are allowed to be sent and whose tags need to be deleted, and to retain the tags of messages that are allowed to be sent and whose tags do not need to be deleted. The system does not use Access, Trunk, and Hybrid port modes as the direct branching basis for data plane packet processing. Instead, it achieves unified rule processing for the three port modes through a combination of VLAN permission rules and VLAN tag processing rules.

8. The system as described in claim 7, characterized in that, The rule storage structure includes a rule storage module and a tag processing rule storage module; Both the permission rule storage module and the tag processing rule storage module adopt a structure combining template tables and bitmaps. The template table is used to record the association between VLAN IDs and template numbers; the bitmap table is used to record the correspondence between template numbers and specific port rule bitmaps. The system queries the corresponding template table based on the VLAN ID to obtain the template number, and then queries the corresponding bit table based on the template number to obtain the corresponding port permission rule or tag processing rule.

9. An electronic device, characterized in that, It includes a processor and a memory, wherein a computer program is stored in the memory, and when executed by the processor, the computer program implements the method as described in any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 6.

Images