Method and system for implementing shared bandwidth packet based on openstack neutron

Abstract

The application provides a shared bandwidth packet implementation method and system based on OpenStack Neutron, and the method comprises the following steps: in response to a user's request of setting a router gateway, disabling the logic that Neutron allocates a gateway IP directly from an external network and configures the gateway IP to a router network card; creating a floating IP and marking the floating IP as a router gateway IP; binding router gateway information to the floating IP, so that the public network exit IP of the router is the floating IP marked with a gateway; creating a shared bandwidth packet and specifying a total bandwidth upper limit; setting a shared bandwidth packet identification field for the floating IP in a floating IP data table of Neutron, and associating the floating IP to the shared bandwidth packet; the floating IP comprises the floating IP marked as the router gateway IP; and uniformly limiting the total flow of the public network exit of the floating IP according to the total bandwidth upper limit. The application realizes unified control of the gateway IP and the floating IP.

Description

Technical Field

[0001] This invention relates to the field of cloud computing virtualization technology, specifically to a method and system for implementing shared bandwidth packets based on OpenStack Neutron. Background Technology

[0002] In the OpenStack cloud platform, the Neutron component is responsible for network resource management. In existing technologies, router gateway IPs and floating IPs employ a completely separate resource model: the router gateway IP is automatically assigned an IP address from the external network by Neutron when configuring the router's external gateway, directly configured to the router's gateway port, and this IP independently occupies network egress bandwidth. It is not managed as an independent floating IP resource and cannot be uniformly associated with user-submitted floating IPs. Floating IPs, on the other hand, are independently applied for by the user and bound to virtual machine ports, supporting independent bandwidth control, but have no association with the router gateway IP.

[0003] Due to the aforementioned architectural isolation, Neutron natively cannot support situations where users wish to include router gateway IPs and one or more floating IPs in the same shared bandwidth package for unified rate limiting, billing, and traffic management. Specifically: 1. It cannot treat router gateway IPs and floating IPs as the same type of public network egress IP for unified management. 2. It cannot impose a total bandwidth cap on all public network egress traffic (including gateway traffic and floating IP traffic) within the same Virtual Private Cloud (VPC). 3. It lacks a mechanism to aggregate multiple public IPs into a bandwidth pool, preventing cloud platform operators from offering shared bandwidth package products and hindering users from optimizing public network bandwidth costs.

[0004] Therefore, a method and system for implementing shared bandwidth packages in OpenStack Neutron is needed, which can overcome the limitations of the native Neutron architecture, transform router gateway IPs into floating IP resources that can be managed uniformly, and enable multiple public IPs to share the total bandwidth. Summary of the Invention

[0005] In view of this, it is necessary to provide a method and system for implementing shared bandwidth packets based on OpenStack Neutron, in order to solve the technical problem that the existing technology cannot break through the limitations of the native Neutron architecture, resulting in the inability to manage router gateway IPs and floating IPs in a unified manner.

[0006] To address the aforementioned technical problems, in a first aspect, this invention provides a shared bandwidth packet implementation method based on OpenStack Neutron, comprising: In response to a user's request to configure the router gateway, disable Neutron's native logic of directly assigning a gateway IP from the external network and configuring it to the router's network card; Create a floating IP address and mark it as the router's gateway IP address; Bind the router gateway information to the floating IP, so that the router's public network exit IP becomes a floating IP with a gateway tag; Create a shared bandwidth package and specify the total bandwidth limit of the shared bandwidth package; In Neutron's floating IP data table, a shared bandwidth packet identifier field is set for the floating IP, and the floating IP is associated with the shared bandwidth packet based on the shared bandwidth packet identifier field; the floating IP includes floating IPs marked as router gateway IPs; The total public network outbound traffic of the floating IP associated with the shared bandwidth package is uniformly limited based on the total bandwidth limit.

[0007] In one possible implementation, creating the floating IP includes: The Neutron native floating IP creation interface is called to generate the floating IP, and the floating IP is associated with the external network where the router is located.

[0008] In one possible implementation, marking the floating IP as the router gateway IP includes: In the floating IP data table, the router gateway flag field of the floating IP is set to true. The router gateway flag field is used to indicate whether the floating IP is the router's gateway IP.

[0009] In one possible implementation, the creation of the shared bandwidth packet includes: In Neutron, a new shared bandwidth package data table is added. The shared bandwidth package data table includes a bandwidth package ID field, a tenant ID field, an associated router ID field, and a total bandwidth field.

[0010] In one possible implementation, associating the floating IP with the shared bandwidth packet based on the shared bandwidth packet identifier field includes: Add a shared bandwidth package identifier field to Neutron's floating IP data table, and set the value of the shared bandwidth package identifier field to the ID of the shared bandwidth package; wherein, when the shared bandwidth package identifier field is empty, it means that the floating IP uses independent bandwidth, and when it is not empty, it means that the floating IP belongs to the corresponding shared bandwidth package.

[0011] In one possible implementation, the step of uniformly limiting the public network egress traffic of the floating IP associated with the shared bandwidth packet based on the total bandwidth limit includes: Generate flow control root rules on network nodes based on the total bandwidth limit; Based on the root rule and each floating IP associated with the shared bandwidth package, a corresponding sub-rule is generated for each floating IP; the root rule and the sub-rule work together to ensure that the total public network outbound traffic of all floating IPs under the shared bandwidth package is less than or equal to the total bandwidth limit.

[0012] In one possible implementation, if the user's request to configure the router gateway includes the router ID and the external network ID, then before the logic of disabling Neutron's native direct allocation of gateway IPs from the external network and configuring them to the router's network interface card, the following steps are also included: Verify that the router ID and external network ID are valid; Determine whether the router is bound to a gateway and whether the external network is a valid public network; The logic for disabling Neutron's native direct allocation of gateway IPs from external networks and configuration to the router's network interface card includes: When the router ID and external network ID are valid, and the router is not bound to a gateway and the external network is a valid public network, disable Neutron's native logic of directly assigning a gateway IP from the external network and configuring it to the router's network card.

[0013] In one possible implementation, when the shared bandwidth packet is deleted, the method includes: Determine whether the shared bandwidth packet has an associated floating IP address; If it exists, a deletion failure message will be returned, and you will be prompted that all associated floating IPs must be unbound first; If it does not exist, then delete the shared bandwidth package.

[0014] In one possible implementation, after uniformly limiting the total public network egress traffic of the floating IP associated with the shared bandwidth packet according to the total bandwidth limit, the method further includes: Execute the router gateway settings command, view the router details, confirm that the gateway IP is a floating IP type, and confirm that the router gateway flag field in the floating IP data table is true; Query the list of IPs associated with the shared bandwidth package to confirm that the router gateway IP and floating IP have been correctly associated with the shared bandwidth package; Using a bandwidth testing tool, simultaneously initiate external network traffic requests to the router gateway IP and floating IP associated with the shared bandwidth package to verify that the total outbound traffic is less than or equal to the total bandwidth limit.

[0015] Secondly, the present invention also provides a shared bandwidth packet implementation system based on OpenStack Neutron, comprising: The logic disable unit is used to respond to user requests to set the router gateway and disable Neutron's native logic of directly assigning a gateway IP from the external network and configuring it to the router's network card. A floating IP creation unit is used to create floating IPs and mark the floating IPs as router gateway IPs; A gateway binding unit is used to bind router gateway information to the floating IP, so that the router's public network exit IP becomes a floating IP with a gateway tag; A shared bandwidth packet creation unit is used to create a shared bandwidth packet and specify the total bandwidth limit of the shared bandwidth packet; The floating IP association unit is used to set a shared bandwidth packet identifier field for the floating IP in Neutron's floating IP data table, and associate the floating IP with the shared bandwidth packet based on the shared bandwidth packet identifier field; the floating IP includes floating IPs marked as router gateway IPs; A unified bandwidth control unit is used to uniformly limit the total public network outbound traffic of the floating IP associated with the shared bandwidth package based on the total bandwidth limit.

[0016] The beneficial effects of this invention are as follows: The shared bandwidth packet implementation method based on OpenStack Neutron provided by this invention disables the logic of Neutron's native direct allocation of gateway IPs from the external network and configuration to the router's network card. Instead, it actively creates floating IPs and marks them as the router's gateway IPs, making the router's gateway IPs and floating IPs completely unified in the data model. Furthermore, by setting a shared bandwidth packet identifier field, the router's gateway IP and the floating IP can be associated with the same shared bandwidth packet, solving the problem of the inability to uniformly manage gateway IPs and floating IPs in the native architecture.

[0017] Furthermore, based on the total bandwidth limit of the shared bandwidth package, the total public network outbound traffic of the router gateway IP and floating IP associated with the shared bandwidth package is uniformly limited to ensure that the total outbound bandwidth does not exceed the total bandwidth limit. This allows users to share a single bandwidth quota for multiple IPs without having to configure bandwidth separately for each IP, effectively reducing public network bandwidth costs.

[0018] Meanwhile, this invention does not disrupt the original functions and API interfaces of OpenStack Neutron. Floating IPs not associated with shared bandwidth packages can still use independent bandwidth mode, without affecting upper-layer services, and supporting smooth upgrades of the cloud platform. Furthermore, through the creation, association, and unified rate limiting of shared bandwidth packages, the cloud platform can directly provide paid products such as shared bandwidth packages, realizing pooled metering and billing of tenant egress bandwidth, meeting the commercial needs of enterprise users and cloud operators. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A schematic flowchart of an embodiment of the shared bandwidth packet implementation method based on OpenStack Neutron provided by the present invention; Figure 2 This is a schematic diagram of an embodiment of the floating IP data table provided by the present invention; Figure 3 A schematic diagram of an embodiment of the shared bandwidth data table provided by the present invention; Figure 4 For the present invention Figure 1 A schematic flowchart of an embodiment of step S106; Figure 5 This is a schematic diagram of an embodiment of the shared bandwidth packet implementation system based on OpenStack Neutron provided by the present invention. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0022] It should be understood that the illustrative drawings are not drawn to scale. The flowcharts used in this invention illustrate operations implemented according to some embodiments of the invention. It should be understood that the operations in the flowcharts may be implemented out of order, and steps without logical contextual relationships may be reversed or performed simultaneously. Furthermore, those skilled in the art, guided by the content of this invention, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor systems and / or microcontroller systems.

[0023] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0024] This invention provides a method and system for implementing shared bandwidth packets based on OpenStack Neutron, which will be described below.

[0025] Figure 1 This is a schematic flowchart of an embodiment of the shared bandwidth packet implementation method based on OpenStack Neutron provided by the present invention, as shown below. Figure 1 As shown, the shared bandwidth packet implementation method based on OpenStack Neutron includes: S101. In response to the user's request to configure the router gateway, disable Neutron's native logic of directly assigning a gateway IP from the external network and configuring it to the router's network card.

[0026] In other words, it skips the process of native Neutron directly allocating IP addresses from external network subnets and configuring them to the router's network card, without generating a separate gateway port.

[0027] S102. Create a floating IP address and mark the floating IP address as the router's gateway IP address; S103. Bind the router gateway information to the floating IP, so that the router's public network exit IP becomes a floating IP with a gateway tag.

[0028] This process involves configuring the floating IP's IP address and port information to the router's external gateway, with the router's gateway information pointing to the floating IP's ID and IP address. Specifically, this is done by calling Neutron's L3 extension interface or directly manipulating the database to point the router's external gateway configuration information to the floating IP. First, in the router's data table, the `external_fixed_ips` field in `external_gateway_info` is replaced with the floating IP's IP address, and the `gateway_fip_id` field is added or updated to the floating IP's UUID. Second, Neutron's L3-agent is notified to remove the natively assigned gateway IP configuration from the router's network namespace and instead configure the floating IP as the gateway address to the external gateway interface. Simultaneously, the floating IP's `port_id` field is updated to the router's gateway port ID, thus binding the floating IP resource to the router's gateway port.

[0029] S104. Create a shared bandwidth package and specify the total bandwidth limit of the shared bandwidth package; S105. In Neutron's floating IP data table, set a shared bandwidth packet identifier field for the floating IP, and associate the floating IP with the shared bandwidth packet based on the shared bandwidth packet identifier field; floating IPs include floating IPs marked as router gateway IPs; S106. Based on the total bandwidth limit, uniformly limit the total public network outbound traffic of floating IPs associated with shared bandwidth packets.

[0030] Specifically, the total traffic at the public network exit point shall not exceed the total bandwidth limit.

[0031] It should be noted that the floating IPs associated with the shared bandwidth package include router gateway IPs and ordinary floating IPs.

[0032] It should be understood that the shared bandwidth package implementation method based on OpenStack Neutron in this embodiment of the invention can be implemented in any device based on this method, such as cloud platform control nodes, network nodes, compute nodes, dedicated network controller nodes, bandwidth management modules, and other electronic devices. Specifically, the shared bandwidth package implementation method based on OpenStack Neutron is stored in the above-mentioned device as a pre-compiled program or software library. When an API request is received from a user to create a shared bandwidth package, configure a router gateway, or associate a floating IP with a bandwidth package, the program is invoked to execute the entire process of unified management and control of shared bandwidth, including router gateway IP floating, association of floating IP with bandwidth packages, and generation and synchronization of traffic control rules.

[0033] Compared to existing technologies, the shared bandwidth packet implementation method based on OpenStack Neutron provided in this invention disables Neutron's native logic of directly allocating gateway IPs from the external network and configuring them to the router's network interface card. Instead, it actively creates floating IPs and marks them as the router's gateway IPs, ensuring complete data model consistency between the router's gateway IPs and floating IPs. Furthermore, by setting a shared bandwidth packet identifier field, the router's gateway IP and the floating IP can be associated with the same shared bandwidth packet, resolving the issue of inconsistent management of gateway IPs and floating IPs in the native architecture.

[0034] Furthermore, based on the total bandwidth limit of the shared bandwidth package, the total public network outbound traffic of the router gateway IP and floating IP associated with the shared bandwidth package is uniformly limited to ensure that the total outbound bandwidth does not exceed the total bandwidth limit. This allows users to share a single bandwidth quota for multiple IPs without having to configure bandwidth separately for each IP, effectively reducing public network bandwidth costs.

[0035] Meanwhile, this embodiment of the invention does not disrupt the original functions and API interfaces of OpenStack Neutron. Floating IPs not associated with shared bandwidth packages can still use independent bandwidth mode, without affecting upper-layer services, and supporting smooth upgrades of the cloud platform. Furthermore, through the creation, association, and unified rate limiting of shared bandwidth packages, the cloud platform can directly provide paid products such as shared bandwidth packages, realizing pooled metering and billing of tenant egress bandwidth, meeting the commercial needs of enterprise users and cloud operators.

[0036] In some embodiments of the present invention, creating a floating IP in step S102 includes: The Neutron native floating IP creation interface is called to generate a floating IP, and the floating IP is associated with the external network where the router is located.

[0037] Specifically, when Neutron's native gateway IP allocation mechanism is disabled, the native Neutron floating IP creation interface is called to generate a floating IP and associate it with the external network where the router resides. This call corresponds to Neutron's standard API: POST / v2.0 / floatingips. Simultaneously, the external network ID to which the router is to be bound is directly specified in the request via the floating_network_id parameter. Therefore, upon receiving a user's request to configure the router's gateway, Neutron automatically allocates an IP address from an available subnet of the external network, completing the creation of the floating IP and its association with the external network.

[0038] In some embodiments of the present invention, marking the floating IP as the router gateway IP in step S102 includes: In the floating IP data table, the router gateway flag field of the floating IP is set to true. The router gateway flag field is used to indicate whether the floating IP is the router's gateway IP.

[0039] Specifically, the router gateway flag field is_router_gateway, of type BOOLEAN, non-empty, with a default value of FALSE. It marks whether the floating IP is the router gateway IP. A true value (TRUE) represents the router gateway IP, and a false value (FALSE) represents the floating IP.

[0040] This invention replaces the router gateway IP, which originally needed to be generated through independent allocation logic, with a floating IP with a gateway tag by setting the router gateway tag field is_router_gateway. This lays the data foundation for subsequent unified inclusion in the shared bandwidth package. The entire creation process fully reuses Neutron's native floating IP resource management capabilities, eliminating the need to develop a new IP allocation module, thus ensuring compatibility and reducing code redundancy.

[0041] In a specific embodiment of the present invention, the structure of the FloatingIP data table is as follows: Figure 2 As shown, the table includes a unique identifier (id) for the floating IP, serving as the primary key (PK) to uniquely distinguish each floating IP within the entire OpenStack Neutron system. `ip_address` is the specific IP address of the floating IP in string form (e.g., 203.0.113.5), i.e., the publicly accessible address assigned to the virtual machine or router gateway. `share_bandwidth_id`: a foreign key (FK) associated with the ID field of the shared bandwidth packet table (`share_bandwidth`). This field is used to assign the current floating IP to a specific shared bandwidth packet: if this field is NULL, it indicates that this floating IP uses independent bandwidth; if not NULL, it indicates that the floating IP shares the total bandwidth quota with other IPs within the bandwidth packet. `is_router_gateway`: a boolean field used to indicate whether the current floating IP is the router's gateway IP. When the value is TRUE, it indicates that the floating IP assumes the role of the router's external gateway; when the value is FALSE, it indicates that this is a regular floating IP (usually bound to a virtual machine port). This field is a key marker for implementing gateway IP floating.

[0042] In some embodiments of the present invention, the creation of the shared bandwidth packet in step S104 includes: Add a new shared bandwidth package data table in Neutron. The shared bandwidth package data table includes the bandwidth package ID field, the tenant ID field, the associated router ID field, and the total bandwidth field.

[0043] Specifically, the structure of the ShareBandwidth data table is as follows: Figure 3 As shown, the Bandwidth Package ID field (id) serves as the unique identifier (UUID) for the bandwidth package and acts as the primary key (PK) of this table. It distinguishes different shared bandwidth package resources, facilitating subsequent association, querying, updating, and deletion operations. The Tenant ID field (project_id) identifies the tenant (project) that created or owns the bandwidth package, enabling multi-tenant isolation and access control, ensuring that only the tenant or administrator can manage the bandwidth packages under their name. The associated Router ID field (router_id) specifies the router on which the shared bandwidth package operates, indicating that all floating IPs within the shared bandwidth package belong to the same public network exit point under the same router, ensuring that the resource scope of the bandwidth package is bound to a specific virtual private cloud router. The Total Bandwidth field (bandwidth) defines the maximum allowed total bandwidth limit for this shared bandwidth package. This value will be used to uniformly limit the total traffic of all floating IPs associated with this shared bandwidth package.

[0044] In addition to the fields mentioned above, the ShareBandwidth data table can also include a name field and a status field. The name field is used to represent the name of the shared bandwidth packet, and the status field is used to represent the status of the shared bandwidth packet.

[0045] This invention is based on the Neutron extension mechanism. A shared bandwidth package extension is defined in extension.py, and the corresponding RESTful API interface is registered. The following describes the implementation process in detail, using interface creation as an example: The interface for creating a shared bandwidth package uses the POST / v2.0 / shared_bandwidths method. Required parameters include project_id (tenant ID), router_id (router ID), and bandwidth (total bandwidth). The optional parameter is name (bandwidth package name). Upon receiving a request, the system first verifies the caller's permissions: only the tenant or an administrator is allowed to perform the creation operation; otherwise, a permission error is returned. After successful permission verification, the system checks if the router corresponding to the router_id exists and if the tenant has access to it; if it does not exist or is not authorized, a corresponding error message is returned. Subsequently, a new record is inserted into the newly added shared bandwidth package data table (ShareBandwidth), automatically generating a unique bandwidth package ID, and writing project_id, router_id, bandwidth, and the user-provided name (or a default name if not provided) into the corresponding fields, thus completing the creation of the shared bandwidth package.

[0046] As a complement, this embodiment of the invention also implements query, update, and delete interfaces: Query APIs: GET / v2.0 / shared_bandwidths and GET / v2.0 / shared_bandwidths / {id}. The returned content includes the shared bandwidth package ID, name, tenant, router ID, total bandwidth, and a list of currently associated floating IPs.

[0047] Update API: PUT / v2.0 / shared_bandwidths / {id}, supports modification of name, bandwidth, and ip_list (floating IP list). When bandwidth or ip_list is updated, the underlying traffic control rules are automatically synchronized: if bandwidth changes, the traffic control (TC) root rules are regenerated on the network nodes based on the new total bandwidth; if ip_list changes (adding or removing floating IPs), corresponding sub-rules are dynamically generated or deleted for each floating IP, so that the total outbound traffic is limited by the new bandwidth limit in real time. Rule updates take effect within seconds and do not require a service restart.

[0048] Deleting the interface: DELETE / v2.0 / shared_bandwidths / {id}. Before performing the deletion, check if the shared_bandwidth_id of this bandwidth package still has an associated floating IP (i.e., a record in the floatingips table where shared_bandwidth_id equals the current bandwidth package ID). If an association exists, return a deletion failure message (400 error) and indicate "All associated floating IPs must be unbound first"; if no association exists, delete the shared bandwidth package and simultaneously clean up any remaining TC rules.

[0049] With the full implementation of the above API interfaces, tenants can create and manage shared bandwidth packages in a standardized manner without breaking Neutron's native functionality, and integrate router gateway IPs and floating IPs into the bandwidth packages for traffic control.

[0050] In some embodiments of the present invention, the step S105 of associating a floating IP address with a shared bandwidth packet based on the shared bandwidth packet identifier field includes: Add a shared bandwidth package identifier field to Neutron's floating IP data table, and set the value of the shared bandwidth package identifier field to the ID of the shared bandwidth package; when the shared bandwidth package identifier field is empty, it means that the floating IP uses independent bandwidth, and when it is not empty, it means that the floating IP belongs to the corresponding shared bandwidth package.

[0051] Specifically, the shared bandwidth packet identifier field is share_bandwidth_id, a UUID type, which can be empty.

[0052] In some embodiments of the present invention, such as Figure 4 As shown, step S106 includes: S401. Generate flow control root rules on network nodes based on the total bandwidth limit; S402. Based on the root rule and each floating IP associated with the shared bandwidth packet, generate a corresponding sub-rule for each floating IP; the root rule and the sub-rules work together to ensure that the total public network outbound traffic of all floating IPs under the shared bandwidth packet is less than or equal to the total bandwidth limit.

[0053] In practice, the bandwidth management module on the network node listens for updates to the shared bandwidth packet. When a shared bandwidth packet is created or updated, the bandwidth management module generates a root rule based on the total bandwidth limit; then it iterates through the associated floating IP list and generates a sub-rule for each floating IP.

[0054] It should be noted that root rules and child rules do not require a service restart and take effect within seconds.

[0055] The combined effect of root rules and sub-rules is as follows: The root rule sets a total bandwidth limit on the network node (i.e., the total bandwidth limit of the shared bandwidth packet), and all outbound traffic of associated floating IPs must be controlled by this root rule. Each floating IP's corresponding sub-rule directs its traffic into a queue under the same root rule, and uses a token bucket algorithm to make all sub-rules' traffic compete for the root rule's total bandwidth resources, thus achieving shared bandwidth among multiple IPs and ensuring that the overall outbound traffic does not exceed the limit set by the root rule. When an IP occupies less bandwidth, other IPs can dynamically borrow its idle quota, but the total traffic is always limited by the root rule, achieving the goal of unified rate limiting.

[0056] To avoid errors caused by invalid parameters or state conflicts—for example, if the router is already bound to a gateway but the configuration is executed again, it will cause data inconsistency; if the external network is invalid, the subsequently created floating IP cannot be correctly associated with the public network exit—in some embodiments of this invention, the user's request to configure the router gateway includes the router ID and the external network ID. Therefore, before disabling Neutron's native logic of directly assigning a gateway IP from the external network and configuring it to the router's network card, the following steps are also included: Verify that the router ID and external network ID are valid; Determine whether the router is bound to a gateway and whether the external network is a valid public network; This disables Neutron's native logic for directly assigning gateway IPs from the external network and configuring them to the router's network interface card, including: When the router ID and external network ID are valid, and the router is not bound to a gateway and the external network is a valid public network, disable Neutron's native logic of directly assigning a gateway IP from the external network and configuring it to the router's network card.

[0057] The embodiments of the present invention introduce verification and condition judgment to ensure that the subsequent implementation process of the shared bandwidth packet is executed only when all preconditions are met, thereby improving the robustness and compatibility of the shared bandwidth packet implementation method and avoiding abnormal states that may occur in the native interface.

[0058] In some embodiments of the present invention, after completing the aforementioned database modifications, extended code writing, and API implementation, the Neutron core service needs to be restarted for the changes to take effect. Specifically, this includes sequentially restarting the neutron-server service on the control node, the neutron-l3-agent service on the network node, and the newly extended shared bandwidth package service. After the services are restarted, they can operate normally according to the shared bandwidth package logic of the present invention.

[0059] However, in specific cloud platform deployment or upgrade scenarios, even if the shared bandwidth package implementation method based on OpenStack Neutron has been executed, operations and maintenance personnel or testing systems still need a standardized acceptance process to confirm whether gateway IP floating is successful, IP aggregation is correct, and unified rate limiting is effective. To achieve this, in some embodiments of the present invention, after step S106, the following step is also included: Execute the router gateway settings command, view the router details, confirm that the gateway IP is a floating IP type, and confirm that the router gateway flag field in the floating IP data table is true; Query the list of IPs associated with the shared bandwidth package to confirm that the router gateway IP and floating IP are correctly associated with the shared bandwidth package; Using a bandwidth testing tool, simultaneously send external network traffic requests to the router gateway IP and floating IP associated with the shared bandwidth package to verify that the total outbound traffic is less than or equal to the total bandwidth limit.

[0060] This invention first confirms that the gateway IP has been correctly converted to a floating IP by querying router details and the floating IP data table's flag fields; secondly, it confirms that all IPs have been correctly aggregated by querying the bandwidth packet association list; and finally, it verifies that the total outbound bandwidth is indeed limited within the total bandwidth limit through actual traffic testing. These verification steps can serve as functional test cases after deployment, guiding actual engineering verification.

[0061] In summary, the shared bandwidth package implementation method based on OpenStack Neutron proposed in this invention breaks the resource isolation between gateway IPs and floating IPs in the native OpenStack Neutron architecture by converting router gateway IPs into floating IPs and marking them with gateway tags. This achieves complete data model unification for all public network egress IPs (including router gateway IPs and floating IPs). Furthermore, it adds shared bandwidth package resources and supports dynamic association of any floating IP. The underlying layer uses a hierarchical rate-limiting mechanism based on root rules and sub-rules, built using TC traffic control, allowing multiple IPs to share the same total bandwidth quota. Overall egress traffic is precisely controlled within the total bandwidth limit. The entire solution does not disrupt the native Neutron API, is compatible with existing business processes, and IPs not associated with bandwidth packages can still be rate-limited independently. User operating habits do not need to be changed, and the cloud platform can be smoothly upgraded. Meanwhile, it provides the ability to create, associate, update, and delete shared bandwidth packages through a standardized RESTful API, and achieves second-level synchronization of bandwidth configuration and TC rules, which significantly reduces the complexity of operation and maintenance; ultimately, it provides cloud operators with a shared bandwidth package product that can be directly billed and operated, effectively meeting users' urgent needs for optimizing public network egress bandwidth costs and unified management.

[0062] On the other hand, embodiments of the present invention also provide a shared bandwidth packet implementation system based on OpenStack Neutron, such as... Figure 5 As shown, the shared bandwidth package implementation system 500 based on OpenStack Neutron includes: The logic disable unit 501 is used to respond to a user's request to set the router gateway and disable the logic of Neutron natively assigning a gateway IP directly from the external network and configuring it to the router network card. The floating IP creation unit 502 is used to create a floating IP and mark the floating IP as the router gateway IP. Gateway binding unit 503 is used to bind router gateway information to a floating IP, so that the router's public network exit IP becomes a floating IP with a gateway tag; Shared bandwidth packet creation unit 504 is used to create shared bandwidth packets and specify the total bandwidth limit of the shared bandwidth packets; The floating IP association unit 505 is used to set the shared bandwidth packet identifier field for the floating IP in Neutron's floating IP data table, and associate the floating IP with the shared bandwidth packet based on the shared bandwidth packet identifier field; the floating IP includes floating IPs marked as router gateway IPs; The bandwidth unified management and control unit 506 is used to uniformly limit the total public network outbound traffic of floating IPs associated with shared bandwidth packages based on the total bandwidth limit.

[0063] The shared bandwidth packet implementation system 500 based on OpenStack Neutron provided in the above embodiments can implement the technical solutions described in the above embodiments of the shared bandwidth packet implementation method based on OpenStack Neutron. The specific implementation principles of each module or unit can be found in the corresponding content in the above embodiments of the shared bandwidth packet implementation method based on OpenStack Neutron, and will not be repeated here.

[0064] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.), and the computer program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0065] The above provides a detailed description of the shared bandwidth packet implementation method and system based on OpenStack Neutron provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A method for implementing shared bandwidth packets based on OpenStack Neutron, characterized in that, include: In response to a user's request to configure the router gateway, disable Neutron's native logic of directly assigning a gateway IP from the external network and configuring it to the router's network card; Create a floating IP address and mark it as the router's gateway IP address; Bind the router gateway information to the floating IP, so that the router's public network exit IP becomes a floating IP with a gateway tag; Create a shared bandwidth package and specify the total bandwidth limit of the shared bandwidth package; In Neutron's floating IP data table, a shared bandwidth packet identifier field is set for the floating IP, and the floating IP is associated with the shared bandwidth packet based on the shared bandwidth packet identifier field; the floating IP includes floating IPs marked as router gateway IPs; The total public network outbound traffic of the floating IP associated with the shared bandwidth package is uniformly limited based on the total bandwidth limit.

2. The shared bandwidth packet implementation method based on OpenStack Neutron according to claim 1, characterized in that, The creation of a floating IP includes: The Neutron native floating IP creation interface is called to generate the floating IP, and the floating IP is associated with the external network where the router is located.

3. The shared bandwidth packet implementation method based on OpenStack Neutron according to claim 1, characterized in that, The step of marking the floating IP as the router gateway IP includes: In the floating IP data table, the router gateway flag field of the floating IP is set to true. The router gateway flag field is used to indicate whether the floating IP is the router's gateway IP.

4. The shared bandwidth packet implementation method based on OpenStack Neutron according to claim 1, characterized in that, The creation of the shared bandwidth package includes: In Neutron, a new shared bandwidth package data table is added. The shared bandwidth package data table includes a bandwidth package ID field, a tenant ID field, an associated router ID field, and a total bandwidth field.

5. The shared bandwidth packet implementation method based on OpenStack Neutron according to claim 4, characterized in that, Associating a floating IP address with the shared bandwidth packet based on the shared bandwidth packet identifier field includes: Add a shared bandwidth package identifier field to Neutron's floating IP data table, and set the value of the shared bandwidth package identifier field to the ID of the shared bandwidth package; wherein, when the shared bandwidth package identifier field is empty, it means that the floating IP uses independent bandwidth, and when it is not empty, it means that the floating IP belongs to the corresponding shared bandwidth package.

6. The shared bandwidth packet implementation method based on OpenStack Neutron according to claim 1, characterized in that, The method of uniformly limiting the public network outbound traffic of the floating IP associated with the shared bandwidth packet based on the total bandwidth limit includes: Generate flow control root rules on network nodes based on the total bandwidth limit; Based on the root rule and each floating IP associated with the shared bandwidth package, a corresponding sub-rule is generated for each floating IP; the root rule and the sub-rule work together to ensure that the total public network outbound traffic of all floating IPs under the shared bandwidth package is less than or equal to the total bandwidth limit.

7. The shared bandwidth packet implementation method based on OpenStack Neutron according to claim 1, characterized in that, The user's request to configure the router gateway includes the router ID and the external network ID. Therefore, before the logic of disabling Neutron's native direct allocation of gateway IPs from the external network and configuring them to the router's network interface card, the following also applies: Verify that the router ID and external network ID are valid; Determine whether the router is bound to a gateway and whether the external network is a valid public network; The logic for disabling Neutron's native direct allocation of gateway IPs from external networks and configuration to the router's network interface card includes: When the router ID and external network ID are valid, and the router is not bound to a gateway and the external network is a valid public network, disable Neutron's native logic of directly assigning a gateway IP from the external network and configuring it to the router's network card.

8. The shared bandwidth packet implementation method based on OpenStack Neutron according to claim 1, characterized in that, When deleting the shared bandwidth packet, the method includes: Determine whether the shared bandwidth packet has an associated floating IP address; If it exists, a deletion failure message will be returned, and you will be prompted that all associated floating IPs must be unbound first; If it does not exist, then delete the shared bandwidth package.

9. The shared bandwidth packet implementation method based on OpenStack Neutron according to claim 3, characterized in that, After uniformly limiting the total public network outbound traffic of the floating IP associated with the shared bandwidth packet according to the total bandwidth limit, the method further includes: Execute the router gateway settings command, view the router details, confirm that the gateway IP is a floating IP type, and confirm that the router gateway flag field in the floating IP data table is true; Query the list of IPs associated with the shared bandwidth package to confirm that the router gateway IP and floating IP have been correctly associated with the shared bandwidth package; Using a bandwidth testing tool, simultaneously initiate external network traffic requests to the router gateway IP and floating IP associated with the shared bandwidth package to verify that the total outbound traffic is less than or equal to the total bandwidth limit.

10. A shared bandwidth packet implementation system based on OpenStack Neutron, characterized in that, include: The logic disable unit is used to respond to user requests to set the router gateway and disable Neutron's native logic of directly assigning a gateway IP from the external network and configuring it to the router's network card. A floating IP creation unit is used to create floating IPs and mark the floating IPs as router gateway IPs; A gateway binding unit is used to bind router gateway information to the floating IP, so that the router's public network exit IP becomes a floating IP with a gateway tag; A shared bandwidth packet creation unit is used to create a shared bandwidth packet and specify the total bandwidth limit of the shared bandwidth packet; The floating IP association unit is used to set a shared bandwidth packet identifier field for the floating IP in Neutron's floating IP data table, and associate the floating IP with the shared bandwidth packet based on the shared bandwidth packet identifier field; the floating IP includes floating IPs marked as router gateway IPs; A unified bandwidth control unit is used to uniformly limit the total public network outbound traffic of the floating IP associated with the shared bandwidth package based on the total bandwidth limit.

Images