Traffic message service type identification method and device, equipment, medium and product

Abstract

The invention discloses a traffic message service type identification method, device and equipment, a medium and a product. A gateway receives a traffic message; analyzing the flow message to obtain a flow characteristic; and identifying the service type of the traffic message according to the traffic feature. According to the scheme of the invention, the traffic service type is quickly analyzed by grasping the traffic characteristics, the service type can be identified when the service traffic is forwarded, and the service function limitation is reduced.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing technology, and in particular to a method, device, equipment, medium and product for identifying the service type of a traffic message. Background Art

[0002] Currently, data center development is focused on scalability, virtualization, and cloud computing. VXLAN (Virtual Extensible LAN) has been widely adopted. VXLAN establishes VXLAN tunnels to create a large number of virtual extensible LANs (VELs) within the existing network architecture.

[0003] When forwarding different VXLAN service flows, the gateway of the existing solution can only forward services based on the distinguished protocol types, but cannot determine the service type, which limits service functions. Summary of the Invention

[0004] In order to solve the above problems, the present invention proposes a method, device, equipment, medium and product for identifying the service type of traffic messages, which can identify the service type when forwarding service traffic and reduce service function restrictions.

[0005] An embodiment of the present invention provides a method for identifying the service type of a traffic message, which is applied to a gateway. The method includes: Receive traffic packets; Analyzing the traffic message to obtain traffic characteristics; The service type of the traffic message is identified according to the traffic characteristics.

[0006] Preferably, parsing the traffic message to obtain traffic characteristics includes: Identifying a message type of the traffic message; The corresponding traffic characteristics are parsed from the traffic message according to the message type.

[0007] Preferably, the identifying the message type of the traffic message includes: Identifying a sending direction of the traffic message; When the traffic message is outbound traffic sent by VXLAN, identifying the traffic message as a VXLAN message; When the traffic message is cloud-inbound traffic sent by each service resource, the traffic message is identified as an underlay message.

[0008] Preferably, parsing corresponding traffic features from the traffic message according to the message type specifically includes: When the traffic message is a VXLAN message, identifying an outer destination address of the VXLAN message as the traffic feature; When the traffic message is an underlay message, a virtual routing forwarding parameter of an input port of the underlay message is identified as the traffic feature.

[0009] Preferably, the identifying the service type of the traffic message according to the traffic characteristics includes: The service type is determined by querying from a preset mapping relationship table according to the traffic characteristics.

[0010] Preferably, the identifying the service type of the traffic message according to the traffic characteristics includes: When the traffic feature is the outer destination address of the VXLAN message, matching the service type of the VXLAN message from a first mapping relationship table between the preset outer destination address and the service type; When the traffic feature is a virtual routing forwarding parameter of an underlay message, the service type of the underlay message is matched from a preset second mapping relationship table of virtual routing forwarding parameters and service types.

[0011] Preferably, the service types include shared resource services, public network services, cloud port services, and peer-to-peer connection services; The shared resource service is a connection service for VXLAN to access shared infrastructure resources; The public network service is the access service between VXLAN and public network resources; The cloud port service is a link service between a virtual machine private network user on a VXLAN and a user's local network; The peer-to-peer connection service is a network communication service between VXLANs across virtual machine private networks.

[0012] Preferably, the method further comprises: Perform corresponding service forwarding processing according to the message type and service type of the traffic message.

[0013] Preferably, the performing corresponding service forwarding processing according to the message type and service type of the traffic message includes: When the traffic message is a VXLAN message and the service type is a public network service, the source IP address and the destination IP address in the VXLAN message are matched with the preset rate limit rule table respectively; When the source IP or the destination IP matches a corresponding IP entry in the rate limit rule table, the VXLAN message is placed in the corresponding flow bucket; When the flow bucket reaches a preset limit rate, forwarding of the VXLAN message is prohibited; When the flow bucket does not reach the preset limit rate, or the source IP and the destination IP do not match the corresponding IP items in the rate limit rule table, the VXLAN header of the VXLAN message is removed, and the corresponding public network resource exit is matched for message forwarding.

[0014] Preferably, the performing corresponding service forwarding processing according to the message type and service type of the traffic message includes: When the traffic message is a VXLAN message and the service type is a shared resource service or a cloud port service, the VXLAN header of the VXLAN message is removed, and the corresponding service physical exit is matched to forward the message.

[0015] Preferably, the performing corresponding service forwarding processing according to the message type and service type of the traffic message includes: When the traffic message is a VXLAN message and the service type is a peer-to-peer connection service, the VXLAN header of the VXLAN message is removed and the VXLAN header is re-encapsulated, and the corresponding peer-to-peer connection service exit is matched to forward the message.

[0016] Preferably, the performing corresponding service forwarding processing according to the message type and service type of the traffic message includes: When the traffic message is an underlay message and the service type is a shared resource service or a cloud port service, the forwarding route and the overlay route are determined according to the virtual routing forwarding parameters and the destination IP of the underlay message; Remove the VLAN header of the underlay message and re-encapsulate the VXLAN header; The outer source address is rewritten according to the service type, the forwarding route, and the overlay route, and the corresponding physical exit is matched to forward the message.

[0017] Preferably, the performing corresponding service forwarding processing according to the message type and service type of the traffic message includes: When the traffic message is an underlay message and the service type is a public network service, the source IP and destination IP in the underlay message are matched with a preset rate limit rule table respectively; When the source IP or the destination IP matches the corresponding IP entry in the rate limit rule table, the underlay message is placed in the corresponding flow bucket; When the flow bucket reaches a preset limit rate, forwarding of the underlay message is prohibited; When the flow bucket does not reach the preset limit rate, or the source IP and the destination IP do not match the corresponding IP entries in the rate limit rule table, the VLAN header of the underlay message is removed and the VXLAN header is re-encapsulated, and the forwarding route and overlay route are determined according to the virtual routing forwarding parameters of the underlay message and the destination IP; The outer source address is rewritten according to the service type, the forwarding route, and the overlay route, and the corresponding physical exit is matched to forward the message.

[0018] Preferably, the method further comprises: Monitor the current processing of traffic packets of different business types; When an abnormality is detected in the processing of traffic packets, the high availability form of the abnormal service type is identified; The routing configuration is sent to the aggregation switch according to the high availability form to control the forwarding processing of the traffic message of the abnormal service type.

[0019] Preferably, the high availability form of identifying abnormal business types that have abnormalities includes: Identifying a service type of the abnormal traffic message as the abnormal service type; Matching a high availability state from a preset business pattern matching table according to the abnormal business type; The high availability state includes an active state of an active-active mode, an active state of an active-standby mode, and a standby state of an active-standby mode.

[0020] Preferably, the sending of the routing configuration to the aggregation switch according to the high availability form to control the forwarding processing of the traffic message of the abnormal service type includes: When the high availability state is in the active state of the master-master mode, an instruction to revoke the externally published route of the abnormal service type is sent to the aggregation switch to control the aggregation switch to switch the traffic message of the abnormal service type from the equal-cost route to the single-hop mode of the backup host in the master-master mode; When the high availability state is in the active state of the active-standby mode, an instruction to switch the priority of the externally published route of the abnormal service type is sent to the aggregation switch to control the aggregation switch to enable the standby machine in the active-standby mode to process the traffic message of the abnormal service type; When the high availability state is in the standby state of the active-standby mode, a maintenance instruction for the externally published route of the abnormal service type is sent to the aggregation switch to control the aggregation switch to maintain the processing of the flow message of the abnormal service type.

[0021] Preferably, the method further comprises: Determine the type of business to be migrated; Sending a pre-configuration instruction to the newly added gateway according to the type of service to be migrated; The migration route configuration of the service type to be migrated is sent to the aggregation switch to control the aggregation switch to cancel the current externally advertised route of the service type to be migrated and forward the traffic message of the service type to be migrated to the newly added gateway.

[0022] Preferably, determining the type of service to be migrated includes: When the underlying capacity of a certain service type reaches a preset limit, the service type is determined as the service type to be migrated.

[0023] An embodiment of the present invention further provides a device for identifying the service type of a traffic message, the device comprising: A receiving module, used for receiving traffic messages; An analysis module, configured to analyze the traffic message to obtain traffic characteristics; An identification module is used to identify the service type of the traffic message according to the traffic characteristics.

[0024] An embodiment of the present invention also provides a terminal device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein when the processor executes the computer program, it implements the service type identification method of the traffic message as described in any of the above embodiments.

[0025] An embodiment of the present invention also provides a computer-readable storage medium, which includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute the service type identification method of the traffic message as described in any of the above embodiments.

[0026] An embodiment of the present invention further provides a computer program product, comprising a computer program / instruction, which implements the steps of any of the above methods when executed by a processor.

[0027] The present invention provides a method, apparatus, device, medium, and product for identifying the service type of traffic packets. A gateway receives traffic packets, parses the packets, obtains traffic characteristics, and identifies the service type of the packets based on the characteristics. This solution simplifies the judgment process, quickly analyzing the traffic service type based on the traffic characteristics. This allows for identification of the service type during service traffic forwarding, reducing service function restrictions. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 11 is a flow chart of a method for identifying the service type of a traffic message provided by an embodiment of the present invention; Figure 2 This is a schematic diagram of the message format of a VXLAN message provided by an embodiment of the present invention; Figure 3 This is a diagram of the forwarding architecture of underlay messages provided by an embodiment of the present invention; Figure 4 This is a schematic diagram of traffic trends for different service types provided by an embodiment of the present invention; Figure 5 This is a flow chart of VXLAN message forwarding processing provided by an embodiment of the present invention; Figure 6 1 is a flow chart of forwarding processing of underlay messages provided by an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of a device for identifying the service type of a traffic message provided by an embodiment of the present invention; Figure 8 It is a structural diagram of a terminal device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0029] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0030] In response to the above technical issues, this case provides a method for identifying the service type of traffic packets, see Figure 1 , is a flow chart of a method for identifying the service type of a traffic message provided by an embodiment of the present invention, the method comprising: Step S1, receiving a traffic message; Step S2: parse the traffic message to obtain traffic characteristics; Step S3: Identify the service type of the traffic message according to the traffic characteristics.

[0031] In the specific implementation of this embodiment, the method is applied to a gateway that performs service forwarding processing on a VXLAN serving as a virtual machine, that is, a programmable gateway.

[0032] When the gateway receives traffic messages of different business types, the traffic messages of different business types will present unique traffic characteristics during the transmission process, such as protocol type, port number, message length, interaction frequency, payload characteristics, etc.

[0033] By parsing the traffic message to extract the traffic characteristics, and then matching them with the preset traffic characteristics and business type mapping library, the business type to which the traffic belongs can be identified.

[0034] Specifically: The programmable gateway receives traffic packets and captures the traffic packets flowing through the gateway.

[0035] Parse traffic packets and extract traffic features.

[0036] It should be noted that during feature extraction, the key features extracted from the parsing results include static features: fixed identifiers such as protocol type, port number, IP address segment, etc.; dynamic features: statistical features such as message length distribution, interaction cycle, and retransmission rate; application layer features: specific character strings, handshake packet features of encryption protocols, application-specific ports, etc.

[0037] Identify service types based on traffic characteristics.

[0038] If necessary, before identifying service types, a feature library should be pre-established to collect typical features of various services, forming a mapping library between traffic features and service types. Alternatively, a machine learning model can be pre-trained to identify services with different traffic characteristics using a trained classifier.

[0039] The extracted traffic features are compared and the service type is determined through rule matching or machine learning models.

[0040] By centralizing processing on a programmable gateway, service types can be identified when forwarding service traffic, reducing service function restrictions.

[0041] In another embodiment of the present invention, different types of traffic messages have essential differences in structure and purpose, and contain different key traffic features. By first identifying the message type and then extracting matching traffic features based on the protocol specifications or structural characteristics of that type, accurate and efficient feature extraction can be achieved.

[0042] Analyze the traffic packets when they are inbound, and obtain the corresponding service type based on the traffic characteristics.

[0043] parsing corresponding traffic features from the traffic message according to the message type; There are two types of inbound traffic packets for the programmable gateway: outbound traffic sent by virtual machines in the cloud and inbound traffic sent by various business resources accessing virtual machines in the cloud. The structures of the traffic messages of the two message types are different. Therefore, when extracting traffic features, it is necessary to extract traffic features separately for different message types.

[0044] In another embodiment of the present invention, the binding relationship between the sending direction and the network layer, that is, in a cloud computing network, the outbound / inbound direction of traffic packets is directly related to the network layer and encapsulation type to which they belong. Virtual Extended Local Area Network (VXLAN), a virtualization technology that implements cross-physical networks in cloud computing, has a clear correspondence between its packet encapsulation and decapsulation processes and the outbound and inbound directions of traffic: When traffic is transmitted from the virtual network (overlay layer) within the cloud to the external physical network (underlay layer), it must be encapsulated through the VXLAN gateway to form VXLAN packets. Therefore, outbound traffic must be VXLAN-encapsulated packets. When traffic is transmitted from the external physical network (underlay layer) to the virtual network (overlay layer) within the cloud, it must first be decapsulated at the VXLAN gateway node to reveal the original physical network packets and underlay layer packets. Therefore, before entering the cloud service resources, the inbound traffic exists in the form of underlay packets that have not been encapsulated by VXLAN. By identifying the direction of traffic (outbound / inbound), it can be directly mapped to the corresponding packet type (VXLAN packet / underlay packet), without relying on complex protocol field parsing, to achieve rapid classification.

[0045] Specifically, in the cloud computing network architecture, the gateway is clearly defined as the boundary node for cloud exit / entry. Taking the business resources within the cloud as the reference point, the traffic sent from the gateway to the external network is cloud exit traffic; the traffic sent from the external physical network to the business resources within the cloud via the VXLAN gateway is cloud entry traffic.

[0046] Determine the transmission path by the IP address or port identifier of the network node through which the traffic passes: If the source IP address of the packet belongs to the VXLAN gateway's intra-cloud interface and the destination IP address is an external physical network address, it is considered outbound traffic. If the source IP address of the packet belongs to an external physical network device and the destination IP address is an intra-cloud service resource address, it is considered inbound traffic.

[0047] Outbound traffic is VXLAN encapsulated before being sent, and the header contains the VXLAN protocol identifier and VNI. The direction can be further confirmed by detecting whether the VXLAN header exists in the message. Inbound traffic is decapsulated before entering the service resource and only contains the physical network protocol header, such as Ethernet, IP, and TCP / UDP.

[0048] When it is determined to be outbound traffic, the packet is directly identified as a VXLAN packet, regardless of whether the internal fields are parsed, because outbound traffic must be encapsulated by VXLAN. When it is determined to be inbound cloud traffic, the packet is directly identified as an underlay packet. This is because the inbound cloud traffic has completed VXLAN decapsulation before reaching the service resources and presents the original packet form of the physical network.

[0049] Eliminating the need to parse complex protocol fields, the type can be determined solely by the direction of transmission, resulting in rapid identification and suitable for real-time processing of high-concurrency traffic in cloud computing environments. By effectively isolating inbound and outbound traffic, ensuring the independence and security of various types of business traffic, this significantly increases the flexibility of a single gateway in handling diverse business traffic and effectively reduces network equipment costs in multiple application scenarios.

[0050] In another embodiment of the present invention, analyzing the corresponding traffic characteristics in step S2 specifically includes: VXLAN packets are encapsulated in the outer layer of the original packets. Figure 2 The following is a schematic diagram of the VXLAN message format provided by an embodiment of the present invention. The core of VXLAN messages is tunnel encapsulation, wrapping the original message with an outer layer of UDP+IP+Ethernet encapsulation. Transmitted over a physical network (Layer 3), this allows devices across different physical networks to communicate as if they were on the same Layer 2 network, solving problems such as large-scale virtual machine network expansion and isolation in data centers.

[0051] The VXLAN message is broken down from the outside to the inside, based on the encapsulation layer. The outer layer is used for physical network transmission, and the inner layer is the original service message: The Outer Ethernet header enables packets to be transmitted over Ethernet links in the underlying physical network and identifies the source and destination MAC addresses of Ethernet frames. Fields include: Destination MAC Address (MAC DA), which is the MAC address of the next-hop physical device to which the packet is sent after the outer encapsulation, such as the VXLAN Tunnel Endpoint (VTEP). Source MAC Address (MAC SA), which is the MAC address of the physical device sending the packet, such as the local VTEP. Optional 802.1Q Tag: If VLAN is enabled on the physical network, this field will carry a VLAN tag for VLAN isolation within the physical network. The Ethernet Type field identifies the upper-layer protocol encapsulated in the outer layer, typically 0x0800, indicating that the upper layer is an IP protocol, instructing the recipient to process the packet as an IP packet.

[0052] The Outer IP header, used for Layer 3 network routing, determines the source and destination IP addresses of packets transmitted across the physical network. This header includes the following fields: the source IP address (SA) and the IP address of the sending VTEP (for example, the IP address of a physical machine or switch in the data center, which serves as the starting point of the VXLAN tunnel). The destination IP address (DA), which is the IP address of the receiving VTEP, indicates the end point of the tunnel and is used to locate the decapsulation device on the other end. It also contains other standard IP header fields. The protocol type is usually 0x11, indicating that the upper layer is using the UDP protocol, instructing the network layer to use UDP for subsequent transmission.

[0053] The outer UDP header, based on the connectionless and low-overhead characteristics of UDP, carries VXLAN encapsulation, allowing packets to be quickly transmitted on the physical network.

[0054] This field includes the following: Source Port, which is a port randomly selected by the sending VTEP or 4789 according to the specification, but may also be dynamically assigned in practice. Destination Port, which is fixed at 4789, a standard VXLAN port and used by the receiving end to identify VXLAN packets. UDP Length, which includes the UDP header, the subsequent VXLAN header, and the original packet. UDP Checksum, which is used to check for errors in UDP segment transmission. In actual deployments, this field may be disabled to improve transmission efficiency.

[0055] The VXLAN header, the core identifier of VXLAN, adds a virtual network identifier to the original packet, enabling multi-tenant / multi-virtual network isolation. This field includes the following: VXLAN Flags (fixed to 0x0800), with the upper four bits reserved. Of the lower 12 bits, only the eighth bit is currently set to "1," indicating that the packet is a VXLAN packet and used to identify VXLAN encapsulation. The Reserved field is currently unused and is filled with 0, though its functionality may be expanded in the future. The VNI (VXLAN Network Identifier), equivalent to a "virtual VLAN ID," is used to distinguish different virtual networks and is used to place the packet back into the corresponding virtual network during decapsulation.

[0056] The original message, that is, the actual business data, such as the Layer 2 Ethernet frame sent by the virtual machine, contains the virtual machine's MAC address, business data, etc. After being encapsulated by VXLAN, it can be transmitted across the physical network. After being decapsulated by the peer VTEP, it is restored to the original message, making the virtual machine believe that it is communicating on the same Layer 2 network.

[0057] Regardless of the type of service, the messages sent from the virtual machine to the programmable gateway are all VXLAN messages. To distinguish traffic service types, the programmable gateway breaks through the limitation of having only one local vtep address and supports the configuration of multiple service vvtep addresses (virtualvtep, virtual vtep address). Different vvtep addresses are used for different services to establish VXLAN tunnels with virtual machines in the cloud, making the outer vtep address of the VXLAN message a key traffic feature for determining the service type.

[0058] For underlay packets, see Figure 3 , is a diagram of the forwarding architecture of underlay messages provided in an embodiment of the present invention.

[0059] Different types of services on the same physical network are logically isolated and independently forwarded through VRF (Virtual Routing and Forwarding) technology.

[0060] Uplink aggregation switches and port access switches serve as the entrance and exit of the physical network, sending traffic from different sources such as underlay services, public network services, and cloud services to the programmable gateway, or sending traffic forwarded by the gateway to the target, such as the public network, cloud, and intranet devices.

[0061] Programmable gateways use Virtual Radio Frequency (VRF) technology to virtualize a physical gateway into multiple logical gateways. This allows traffic from different services to follow independent routing and forwarding tables, ensuring that multiple services can operate on the same physical device without interfering with each other. They support flexible programming and can dynamically adjust forwarding rules based on business needs, adapting to complex scenarios.

[0062] Virtual routing forwarding instance VRF acts as the "avatar" of the gateway. Each VRF is an independent routing table + forwarding table, which allows the traffic of different services to be logically isolated and physically share the gateway hardware.

[0063] VRF-underlay services specifically handle traffic on the underlay network, such as the interconnection between physical machines and switches within a data center and private IP segments.

[0064] VRF - public network service, processes traffic that needs to access the public network, using public IP routing and NAT conversion.

[0065] VRF-cloud service sub-interface 1 to VRF-cloud service sub-interface n are connected to cloud services on different clouds. Each sub-interface corresponds to an independent cloud connection and security policy.

[0066] The programmable gateway communicates with underlay shared resources, public network resources, and cloud port resources through the underlay network. To maintain traffic isolation between services, VRF (VPN Routing & Forwarding Instance) isolation is implemented. Each virtual machine network has its own independent routing table, which prevents interference. Traffic of different service types is designed to flow through different VLAN sub-interfaces. These VLAN sub-interfaces are bound to different VRFs and then connected to various service resources. Therefore, the VRF from which underlay packets enter the network becomes a key traffic characteristic for determining service type.

[0067] Therefore, when the traffic characteristic is the virtual routing forwarding parameter (VRF) of the underlay packet, the programmable gateway analyzes the VLAN sub-interface through which the underlay packet passes upon entry and resolves the VRF to which it is bound. Through pre-configuration, the underlying layer maintains a mapping table between the cloud-entering VRF and service types, i.e., a VRF-to-service type correspondence table. Each VRF corresponds to a unique service type, and a service type can be mapped to multiple VRFs. Therefore, when an underlay packet enters the programmable gateway, the unique service type of the underlay packet can be determined by parsing the VRF it passed through.

[0068] In another embodiment of the present invention, when identifying the service type in step S3, specifically: By pre-building a one-to-one correspondence table between traffic features and service types, known as a mapping table, once the characteristics of a traffic packet are obtained, the service type to which it belongs is determined directly through table lookup and matching. This approach transforms the complex process of service identification into a comparison of features with predefined rules, achieving efficient and explainable service classification.

[0069] In another embodiment provided by the present invention, when step S3 is implemented, specifically: Based on the unique attributes of VXLAN packets and underlay packets, a dedicated feature-service mapping relationship is constructed to achieve accurate classification.

[0070] VXLAN packets, which carry outbound traffic, have an outer destination address, the IP address of the peer VXLAN tunnel endpoint (VTEP), directly associated with the traffic's target service scenario. Therefore, by presetting a first mapping table between outer destination address and service type, the service type of the VXLAN packet can be directly determined.

[0071] When a packet is received, it is identified as a VXLAN packet. The outer destination address is matched with the tunnel.dst_vvtep table (a mapping table between vvtep addresses and service types) to obtain the service type information (service_type) corresponding to the packet.

[0072] Underlay packets, the carrier of inbound cloud traffic, rely on the physical network's virtual routing and forwarding (VRF) technology for forwarding. Different VRF parameters (such as the VRF instance ID and routing table identifier) ​​correspond to different physical services. Therefore, a pre-defined second mapping table between virtual routing and forwarding parameters (VRF) and service types allows for direct identification of underlay packet service types. The virtual resource routing (VRF) parameter (that is, the VRF bound to the port) is set based on the port information through which the packet enters. The underlay packet is identified and the underlay VRF is matched against the ingress_vtep_type_acl.acl table (a mapping table between ingress VRFs and service types). The service type information corresponding to the packet, service_type, is obtained.

[0073] By matching the outer destination address of the VXLAN message and the VRF parameters of the underlay message, two features that are strongly related to the network layer, dedicated mapping tables are used to quickly identify the service types of the two types of messages.

[0074] Identify the traffic service type and process it according to the traffic characteristics. Based on the characteristics of VXLAN messages, the service type of the outgoing VXLAN message is analyzed by maintaining the mapping table of VVTEP address and service type. By maintaining the mapping table of VLAN sub-interface binding VRF and service type, the service type of the incoming underlay message is obtained based on the analysis of the port information when the message flows in.

[0075] Existing technical solutions are complex in distinguishing service flow types, requiring comprehensive judgment based on source IP address, destination IP address, protocol information, and network segment planning. This solution simplifies the judgment method by focusing on traffic characteristics (dst_vtep in the outer layer of the VXLAN message and the VRF to which the underlay message enters the sub-interface). It designs and maintains a mapping table between traffic characteristics and service types to quickly analyze the traffic service type.

[0076] In another embodiment of the present invention, the service type includes a shared resource service, a public network service, a cloud port service, and a peer-to-peer connection service; The programmable gateway establishes a VXLAN with the virtual machines in the cloud through the aggregation switch, and establishes communication with various services in an underlay manner through the aggregation switch and port access switch. Figure 4 , is a schematic diagram of traffic trends of different service types provided by an embodiment of the present invention.

[0077] Underlay shared resource services enable VMs within the cloud to access shared infrastructure resources within the cloud, including but not limited to compute and storage. Programmable gateways connect to VMs via VXLAN and to shared resources in underlay mode, enabling conversion between overlay and underlying services. The underlay service traffic path follows: underlay shared resources - upstream aggregation switch - VRF - underlay - VRF1 - downstream aggregation switch - VM2. The VRF routing table only contains routes for the intranet underlay and does not conflict with routes for the public network or cloud services, ensuring that intranet traffic does not traverse the public network and interfere with other services.

[0078] Public network services allow VMs within the cloud to access public network resources, or vice versa. These services align with the underlay shared resource service network model, connecting VMs via VXLAN and the public network via the underlay, but also support rate limiting. The public network service traffic path follows: public network - upstream aggregation switch - VRF - public network - VRF1 - downstream aggregation switch - VM2. Traffic accessing the public network follows the VRF - public network service path, using public IP addresses or NATed addresses. Public network routes are configured in the routing table, completely isolated from the internal network routes of other VRFs to prevent public network traffic from straying into the internal network.

[0079] Peer-to-peer service: This refers to network communication between VMs across a virtual private network (VPC). The programmable gateway establishes a VXLAN with each VM. The path for peer-to-peer service traffic is: VM 2 - downstream aggregation switch - VRF1 - VRF2 - downstream aggregation switch - VM 1. The Cloud Port service connects a user's VPC network in the cloud with their local network, integrating their in-cloud and out-of-cloud networks. This cross-region dedicated line service connects the programmable gateway to the VMs in the cloud via VXLAN, which are then connected to the port access switch via an underlay, and isolated using VLAN sub-interfaces to maintain user uniqueness. The cloud service traffic path is: Cloud Port - Port Access Switch - VRF - Cloud Service Sub-Interface - Downlink Aggregation Switch - VM 2. Each VRF - Cloud Service Sub-Interface corresponds to an independent cloud connection, using a dedicated IP segment, security policies (such as VPN and encryption), and independent routing tables, ensuring traffic does not affect each other.

[0080] For scenarios where multiple types of business traffic flow, the programmable gateway establishes vxlan tunnels with virtual machines in the cloud using different vvtep addresses for different business types, creates different VLAN sub-interfaces and binds different vrfs to communicate with various business resources, thereby isolating business traffic.

[0081] In another embodiment of the present invention, the method further includes: Perform corresponding service forwarding processing according to the message type and service type of the traffic message.

[0082] In the specific implementation of this embodiment, when processing and forwarding traffic messages, the key is to determine what type of service the traffic message is, determine the tag service_type in the process of processing a message, and guide the processing and forwarding of the message in the subsequent process.

[0083] Corresponding business forwarding processing is performed according to the message type and business type of the traffic message. The direction from the virtual machine to various business resources is out of the cloud, and the direction from various business resources to the virtual machine is in the cloud.

[0084] In another embodiment of the present invention, when performing service forwarding processing of traffic packets, specifically: See also Figure 5 , is a flow chart of VXLAN message forwarding processing provided by an embodiment of the present invention.

[0085] Service-type-based VXLAN decapsulation and egress adaptation: This involves first identifying the service type of the VXLAN packet and then performing differentiated operations based on the service type. When a VXLAN packet is identified and traffic is matched to a service type based on the outer destination address, the traffic is classified into one of the service types such as shared resources, cloud port, public network, or peer connection service based on the virtual network identifier (VNI), outer IP address, port, and other information in the VXLAN header.

[0086] When the service type is public network service, that is, the traffic packet is a VXLAN packet, and the service type is public network service, the traffic rate is limited according to the rate limit rules of the source IP / destination IP.

[0087] The packet is processed based on the service_type, and the source IP and destination IP in the VXLAN packet are matched with the preset rate limit rule table. If the source IP or destination IP matches the corresponding IP entry in the rate limit rule table, it is considered a hit. The VXLAN packet is placed in the corresponding flow bucket. Determine whether the flow bucket has reached a preset rate limit, and if so, prohibit forwarding the VXLAN message. When the flow bucket does not reach the preset limit rate, or the source IP and the destination IP do not match the corresponding IP items in the rate limit rule table, the subsequent process is directly entered to forward the message.

[0088] That is, it decapsulates the VXLAN header, recapsulates the outer layer information, and matches the corresponding public network resource egress to forward the message.

[0089] After decapsulation, private VXLAN traffic must be converted into packets that can be identified by the public network and then sent out through the public network resource egress.

[0090] In another embodiment provided by the present invention, when the traffic message is a VXLAN message and the service type is a shared resource service or a cloud port service, that is, the service type = shared resource service, or the service type = cloud port service, the VXLAN header is contacted and the corresponding service processing is matched.

[0091] To forward packets, the system searches for the appropriate routes and matches them to the physical egress. Underlay shared resource services, public network services, and cloud port services find the corresponding underlay routes, remove the VXLAN header from the packets, match them to the physical egress for each service, add the VLAN header, and forward the packets.

[0092] For shared resource services, match the shared resource egress; the traffic of shared resource services may need to flow in the internal network, and after decapsulation, it will be restored to a common IP message to facilitate internal forwarding.

[0093] For cloud port services, match the cloud port service exit, decapsulate and allow traffic to enter the cloud port service exit, and adapt to the cloud network environment. The cloud may use different tunnel encapsulation or directly use ordinary IP.

[0094] In another embodiment provided by the present invention, when the traffic message is a VXLAN message and the service type is a peer-to-peer connection service, the peer-to-peer connection service correspondingly finds an overlay route.

[0095] Due to the peer connection service, subsequent traffic packets need to be re-VXLAN. Therefore, after removing the VXLAN header of the packet, it is necessary to re-vxlan encapsulate it according to the destination address, re-encapsulate the VXLAN header, and match the corresponding peer connection service exit to forward the packet.

[0096] In another embodiment of the present invention, when the traffic message is an underlay message, see Figure 6Figure 1 is a flow chart illustrating the forwarding process for underlay packets provided by an embodiment of the present invention. For underlay packets, VXLAN encapsulation and address translation are dynamically adjusted based on service type, allowing traffic to be sent from physical egress to different destination networks.

[0097] Based on the service type of the underlay message, the encapsulation is dynamically adjusted and the VIP (virtual IP) / VXLAN address is converted to adapt the traffic to the forwarding requirements of different services, ultimately isolating the traffic of different services; when the traffic is forwarded from the physical exit, it carries the address that meets the requirements of the target network.

[0098] Identify underlay packets, that is, through the protocol field in the packet header, such as the original packet without VXLAN encapsulation or after VXLAN decapsulation); Set VRF parameters based on port information to match service types, including shared resources, cloud ports, and public networks.

[0099] Underlay packets are original packets at the physical network layer and are not encapsulated by VXLAN. Therefore, they are marked as underlay packets. Virtual Routing Forwarding (VRF) is a technology that labels underlay traffic. Different services use different VRFs. Services can be distinguished by port and VRF IP. For example, VRF1 corresponds to shared resources, and VRF2 corresponds to cloud ports.

[0100] When the service type is a shared resource service or a cloud port service, the forwarding route is determined based on the virtual routing forwarding parameters of the underlay message and the destination IP address. The overlay route is matched and the traffic message is reconstructed. The VLAN header of the underlay message is removed and the VXLAN header is re-encapsulated. Since the underlay message entering the process may have been previously encapsulated by VXLAN or needs to be re-encapsulated, the internal address can be modified after decapsulation. The traffic message is then marked with a new VXLAN tag so that it can be identified and forwarded in the target network.

[0101] According to service_type, find the vvtep address corresponding to the service type, use it as the outer src_ip, find the remote vtep address of the vxlan tunnel according to the route, rewrite the outer dst_ip, rewrite the smac address and dmac address according to the physical port information, and finally match the physical exit to forward it out.

[0102] In another embodiment provided by the present invention, when the service type is a shared resource service or a cloud port service, that is, the service type = shared resource service or the service type = cloud port service, the forwarding route is determined according to the vrf and the destination ip, the overlay route is matched and found, the traffic message is reconstructed, the VLAN header is removed and then vxlan encapsulation is performed, the vvtep address corresponding to the service type is found according to the service_type, and it is used as the outer src_ip, the outer dst_ip is rewritten according to the route to find the remote vtep address of the vxlan tunnel, the smac address and dmac address are rewritten according to the physical port information, and finally the physical exit is matched and forwarded.

[0103] In another embodiment provided by the present invention, when the service type = public network service, that is, the traffic message is an underlay message, and the service type is a public network service, the traffic speed is limited according to the speed limit rule of the source IP / destination IP.

[0104] The message is processed according to the service_type, and the source IP and destination IP in the underlay message are matched with the preset rate limit rule table respectively. If the source IP or destination IP matches the corresponding IP entry in the rate limit rule table, it is determined to be a hit; the underlay message is placed in the corresponding flow bucket; Determine whether the flow bucket has reached a preset rate limit. If so, prohibit forwarding the underlay message. When the flow bucket does not reach the preset limit rate, or the source IP and the destination IP do not match the corresponding IP items in the rate limit rule table, the subsequent process is directly entered to forward the message.

[0105] Determine the forwarding route based on vrf and destination ip, match and find the overlay route, reconstruct the traffic message, remove the VLAN header and perform vxlan encapsulation, find the vvtep address corresponding to the service type based on service_type, use it as the outer src_ip, find the vtep address of the remote end of the vxlan tunnel based on the route and rewrite the outer dst_ip, rewrite the smac address and dmac address based on the physical port information, and finally match the physical exit and forward it out.

[0106] After determining the protocol type of a message packet, it is impossible to further subdivide the service type. The message packet is uniformly processed according to the message classification and assembly strategy corresponding to the protocol type. This makes it impossible to handle traffic of different service types differently when the protocol type is the same. This method establishes a unique traffic signature that matches the service type for VXLAN and underlay messages and different services, subdivides the message service type, and performs specific processing on the traffic based on the service_type.

[0107] In another embodiment provided by the present invention, the method further includes: by real-time monitoring of the service traffic processing status, dynamically adjusting the routing based on the high availability form of the service when an abnormality occurs, to ensure that traffic forwarding of the abnormal service is not interrupted.

[0108] Different service types have different high availability designs. When a service encounters an anomaly, such as excessive forwarding latency, packet loss, or node failure, the abnormal service type must be identified first, and then its pre-set high availability configuration must be matched. When a service type's monitoring indicators exceed the preset threshold, an abnormality alarm is triggered, marking the service as abnormal.

[0109] The high availability form determines the logic of traffic switching. For example, if the active-standby form needs to switch to the standby node, targeted routing configurations are sent to the aggregation switch to direct the traffic of abnormal services to the available path, thereby achieving automatic fault avoidance.

[0110] The instructions are pushed to the aggregation switch through the network configuration protocol, and the switch updates the routing table / forwarding table in real time to complete traffic switching.

[0111] Existing technical solutions lack solutions for fault scenarios. This method proposes a high-availability design using a combination of two devices, using a fullmesh connection. Traffic is directed to a programmable gateway by publishing BGP routes. BGP route priorities are set by configuring BGP attributes, creating a master-master or master-backup model. Furthermore, because service traffic is isolated, different high-availability solutions can be designed for different service types. A single device can play a role in different high-availability solutions when handling different service traffic, achieving high-availability design diversity. Through routing control by the aggregation switch, abnormal service traffic is precisely directed to available paths without affecting other normal services, achieving fault isolation.

[0112] In another embodiment provided by the present invention, a high-availability architecture (master-master, master-slave, etc.) and corresponding operating status (master, backup) are pre-defined for each business type. When an abnormal business type is identified, a table lookup is performed to quickly match the high-availability status that the business should currently switch to / maintain.

[0113] By monitoring traffic processing anomalies, such as packet loss, delay, and node failure, we can locate the traffic anomaly of a certain type of business and identify the type of business. Maintain the mapping between business types and high availability modes and states in advance, that is, the business mode matching table, and define the high availability architecture and state rules for each business.

[0114] A device can have different high availability forms when facing different business types, supporting the setting of high availability models according to business needs, with high flexibility. According to the high availability model selection of the above business, the high availability state combination of two programmable gateways is shown in the following table: Table 1 High availability status combination table of two programmable gateways

[0115] Based on the abnormal service type, a high-availability state is matched from a pre-set service mode matching table. A single device failure can cause service interruption and disruption. Therefore, a high-availability design is achieved by combining two programmable gateways, connected to the aggregation switch using a full mesh. This group of devices can flexibly configure different high-availability modes to handle different services, with both active-active and active-standby configurations.

[0116] Through this application solution, whether it is the master-slave, master-master mode, or the newly added multi-active and cluster modes, you only need to update the mapping table to quickly adapt, and it is highly scalable.

[0117] In another embodiment of the present invention, when forwarding traffic packets of abnormal service types, specifically: When the high availability form is in the active state of the master-master mode, such as for underlay shared resource services, the master-master mode can be used. The programmable gateway directs the outbound and inbound traffic of the service to the programmable gateway by publishing routes to the addresses related to the underlay shared resource services. The two programmable gateway devices have the same BGP routing configuration, forming an ECMP equal-cost route at the aggregation switch, and the traffic is load-balanced to the two devices. If one of the devices fails and cannot handle the underlay shared resource services, the BGP+BFD mode quickly detects and revokes the published routes. The equal-cost route on the aggregation switch becomes a single hop, and all underlay shared resource service traffic is completely directed to the remaining normal operating devices.

[0118] When the high availability form is in the active state of the active-standby mode, for example, public network services involve traffic rate limiting issues, so it can only be in active-standby mode, that is, when the primary device fails and cannot handle the public network services, it switches to the standby device to handle it. The programmable gateway guides the inbound and outbound traffic by publishing routes to public network service-related addresses. It sets BGP routes to different priorities by setting BGP attributes, thereby forming active-standby. Specifically, the priorities of the two programmable gateways are distinguished by the length of the BGP mandatory attribute AS_PATH. The AS_PATH length of the standby device is longer than that of the primary device. In the absence of a fault, according to the BGP routing selection principle, the route of the primary device on the aggregation switch takes effect, and all public network service traffic is sent to the primary device, which is then processed and forwarded by the primary device. If the primary device fails and cannot handle the public network service, the BGP+BFD mode quickly senses and revokes the route published to the outside world, then the route of the standby device on the aggregation switch takes effect, and all public network service traffic is completely directed to the standby device.

[0119] When the high availability form is in the standby state of the active-standby mode, the abnormal gateway is the standby gateway and does not affect the service forwarding of the active gateway. At this time, a maintenance instruction of the externally published route of the abnormal service type is sent to the aggregation switch to control the aggregation switch to maintain the processing of the traffic message of the abnormal service type.

[0120] Similarly, by controlling BGP routing attributes, peer-to-peer connection services can form an active-active mode, and cloud port services can form an active-standby mode.

[0121] Develop differentiated routing strategies for high-availability designs of different businesses to avoid adaptation issues caused by the same switching logic.

[0122] In another embodiment of the present invention, the method further includes a control process for performing smooth capacity expansion and service migration, specifically: A new set of programmable gateways is added for capacity expansion. Because different service types have different vvtep addresses and different virtual machine addresses, one or several types of services can be migrated to the newly added devices. For example, if you are preparing to migrate underlay shared resource services, the specific operation process is as follows: Determine the type of business to be migrated; Send pre-configuration instructions to the newly added gateway according to the service type to be migrated. Complete pre-configuration on the newly added device, excluding the configuration of publishing BGP routes; and issue underlay shared resource service configuration on the newly added device.

[0123] Send the migration route configuration for the service type to be migrated to the aggregation switch. Publish the route externally, including the vvtep address and VM cloud address corresponding to the underlay shared resource service. This increases the next-hop member of the BGP route related to the underlay shared resource service on the aggregation switch, potentially transferring traffic for the underlay shared resource service to the new device. Revoke the published BGP route related to the underlay shared resource service on the original programmable gateway. All traffic for the underlay shared resource service will be forwarded from the aggregation switch to the newly added device. Delete the underlay shared resource service configuration from the original programmable gateway.

[0124] At this point, the configuration capacity originally occupied by the underlay shared resource service on the original programmable gateway is released and can be used by other types of services. There will be no long-term traffic interruption throughout the process, ensuring business stability.

[0125] In another embodiment provided by the present invention, when determining the service type to be migrated, whether migration is required is determined based on the underlying capacity of each service type.

[0126] When the underlying capacity of a certain service type reaches the preset limit, that is, a large number of services of the same type are sent to the programmable gateway, and the underlying capacity reaches the limit, it is necessary to expand the capacity.

[0127] The gateway design proposed in this application solution can achieve smooth expansion and realize business migration without other devices being aware of it.

[0128] This method supports the simultaneous migration of one or several types of services. After the service configuration is issued to the new device, it is published by controlling the BGP route. After the traffic is completely switched to the new device, the corresponding service configuration of the original device is deleted, and this space is freed up for other services to use, thereby expanding the overall service capacity while ensuring uninterrupted traffic.

[0129] See also Figure 7 , is a schematic structural diagram of a device for identifying the service type of a traffic message provided by an embodiment of the present invention, the device comprising: A receiving module, used for receiving traffic messages; An analysis module, configured to analyze the traffic message to obtain traffic characteristics; An identification module is used to identify the service type of the traffic message according to the traffic characteristics.

[0130] The service type identification device for traffic packets provided in this embodiment can execute all the steps and functions of the service type identification method for traffic packets provided in any of the above embodiments, and the specific functions of the device are not described in detail here.

[0131] See also Figure 8 , is a schematic diagram of the structure of a terminal device provided by an embodiment of the present invention. The terminal device includes: a processor, a memory, and a computer program stored in the memory and executable on the processor, such as a program for identifying the service type of a traffic message. When the processor executes the computer program, the steps of each of the above-mentioned embodiments of the method for identifying the service type of a traffic message are implemented, such as Figure 1 Alternatively, the processor implements the functions of the modules in the above-mentioned device embodiments when executing the computer program.

[0132] Exemplarily, the computer program can be divided into one or more modules, and the one or more modules are stored in the memory and executed by the processor to complete the present invention. The one or more modules can be a series of computer program instruction segments that can perform specific functions, and the instruction segments are used to describe the execution process of the computer program in the service type identification device of the traffic message. For example, the computer program can be divided into several modules, and the specific functions of each module have been described in detail in the service type identification method of a traffic message provided in any of the above embodiments, and the specific functions of the device will not be repeated here.

[0133] The terminal device may be a computing device such as a desktop computer, laptop, PDA, or cloud server. The terminal device may include, but is not limited to, a processor and memory. Those skilled in the art will appreciate that the schematic diagram is merely an example of a terminal device and does not constitute a limitation on a device for identifying the service type of a traffic message. The device may include more or fewer components than shown, or a combination of certain components, or different components. For example, the terminal device may also include input / output devices, network access devices, buses, and the like.

[0134] The processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. The processor is the control center of the device for identifying the service type of a traffic message, and utilizes various interfaces and lines to connect various parts of the device for identifying the service type of a traffic message.

[0135] The memory can be used to store the computer programs and / or modules. The processor implements the various functions of the traffic message service type identification device by running or executing the computer programs and / or modules stored in the memory and accessing the data stored in the memory. The memory may primarily include a program storage area and a data storage area. The program storage area may store an operating system and at least one application required for a function (such as a sound playback function, an image playback function, etc.); the data storage area may store data generated based on the use of the mobile phone (such as audio data, a phone book, etc.). Furthermore, the memory may include high-speed random access memory and non-volatile memory, such as a hard disk, internal memory, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, at least one disk storage device, a flash memory device, or other volatile solid-state storage device.

[0136] If the module integrated into the device for identifying the service type of a traffic message is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention can implement all or part of the process steps in the above-mentioned method embodiments by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium.

[0137] An embodiment of the present invention further provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of implementing the method by the functional network element in the above embodiment.

[0138] The computer program product provided in this embodiment can execute all the steps and functions of the method for identifying the service type of traffic packets provided in any of the above embodiments, and the specific functions of the product are not described in detail here.

[0139] It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for identifying the service type of a traffic message, characterized in that: Applied to a gateway, the method includes: Receive traffic packets; Analyzing the traffic message to obtain traffic characteristics; The service type of the traffic message is identified according to the traffic characteristics.

2. The method for identifying the service type of a traffic message according to claim 1, wherein: The parsing of the traffic message to obtain traffic characteristics includes: Identifying a message type of the traffic message; The corresponding traffic characteristics are parsed from the traffic message according to the message type.

3. The method for identifying the service type of a traffic message according to claim 2, characterized in that: The identifying the message type of the traffic message includes: Identifying a sending direction of the traffic message; When the traffic message is outbound traffic sent by VXLAN, identifying the traffic message as a VXLAN message; When the traffic message is cloud-inbound traffic sent by each service resource, the traffic message is identified as an underlay message.

4. The method for identifying the service type of a traffic message according to claim 2, wherein: The parsing corresponding traffic features from the traffic message according to the message type specifically includes: When the traffic message is a VXLAN message, identifying an outer destination address of the VXLAN message as the traffic feature; When the traffic message is an underlay message, a virtual routing forwarding parameter of an input port of the underlay message is identified as the traffic feature.

5. The method for identifying the service type of a traffic message according to claim 1, wherein: The identifying the service type of the traffic message according to the traffic characteristics includes: The service type is determined by querying from a preset mapping relationship table according to the traffic characteristics.

6. The method for identifying the service type of a traffic message according to claim 5, characterized in that: The identifying the service type of the traffic message according to the traffic characteristics includes: When the traffic feature is the outer destination address of the VXLAN message, matching the service type of the VXLAN message from a first mapping relationship table between the preset outer destination address and the service type; When the traffic feature is a virtual routing forwarding parameter of an underlay message, the service type of the underlay message is matched from a preset second mapping relationship table of virtual routing forwarding parameters and service types.

7. The method for identifying the service type of a traffic message according to claim 1, wherein: The service types include shared resource services, public network services, cloud port services, and peer-to-peer connection services; The shared resource service is a connection service for VXLAN to access shared infrastructure resources; The public network service is the access service between VXLAN and public network resources; The cloud port service is a link service between a virtual machine private network user on a VXLAN and a user's local network; The peer-to-peer connection service is a network communication service between VXLANs across virtual machine private networks.

8. The method for identifying the service type of a traffic message according to claim 2, wherein: The method further comprises: Perform corresponding service forwarding processing according to the message type and service type of the traffic message.

9. The method for identifying the service type of a traffic message according to claim 8, characterized in that: The performing corresponding service forwarding processing according to the message type and service type of the traffic message includes: When the traffic message is a VXLAN message and the service type is a public network service, the source IP and destination IP in the VXLAN message are matched with the preset rate limit rule table respectively; when the source IP or the destination IP matches the corresponding IP item in the rate limit rule table, the VXLAN message is placed in the corresponding flow bucket; when the flow bucket reaches the preset limit rate, the VXLAN message is prohibited from being forwarded; when the flow bucket does not reach the preset limit rate, or the source IP and the destination IP do not match the corresponding IP item in the rate limit rule table, the VXLAN header of the VXLAN message is removed, and the corresponding public network resource exit is matched for message forwarding; When the traffic message is a VXLAN message and the service type is a shared resource service or a cloud port service, remove the VXLAN header of the VXLAN message and match the corresponding service physical egress to forward the message; When the traffic message is a VXLAN message and the service type is a peer-to-peer connection service, the VXLAN header of the VXLAN message is removed and the VXLAN header is re-encapsulated, and the corresponding peer-to-peer connection service exit is matched to forward the message.

10. The method for identifying the service type of a traffic message according to claim 8, wherein: The performing corresponding service forwarding processing according to the message type and service type of the traffic message includes: When the traffic message is an underlay message and the service type is a shared resource service or a cloud port service, the forwarding route and the overlay route are determined according to the virtual routing forwarding parameters and the destination IP of the underlay message; the VLAN header of the underlay message is removed and the VXLAN header is re-encapsulated; the outer source address is rewritten according to the service type, the forwarding route and the overlay route, and the corresponding physical exit is matched for message forwarding; When the traffic message is an underlay message and the service type is a public network service, the source IP and the destination IP in the underlay message are matched with the preset speed limit rule table respectively; when the source IP or the destination IP matches the corresponding IP item in the speed limit rule table, the underlay message is placed in the corresponding flow bucket; when the flow bucket reaches the preset limit rate, the underlay message is prohibited from being forwarded; when the flow bucket does not reach the preset limit rate, or the source IP and the destination IP do not match the corresponding IP item in the speed limit rule table, the VLAN header of the underlay message is removed and the VXLAN header is re-encapsulated, and the forwarding route and overlay route are determined according to the virtual routing forwarding parameters of the underlay message and the destination IP; the outer source address is rewritten according to the service type, the forwarding route and the overlay route, and the corresponding physical exit is matched for message forwarding.

11. The method for identifying the service type of a traffic message according to claim 1, wherein: The method further comprises: Monitor the current processing of traffic packets of different business types; When an abnormality is detected in the processing of traffic packets, the high availability form of the abnormal service type is identified; The routing configuration is sent to the aggregation switch according to the high availability form to control the forwarding processing of the traffic message of the abnormal service type.

12. The method for identifying the service type of a traffic message according to claim 11, wherein: The high availability form of identifying abnormal business types that have abnormalities includes: Identifying a service type of the abnormal traffic message as the abnormal service type; Matching a high availability state from a preset business pattern matching table according to the abnormal business type; The high availability state includes an active state of an active-active mode, an active state of an active-standby mode, and a standby state of an active-standby mode.

13. The method for identifying the service type of a traffic message according to claim 11, wherein: The sending of the routing configuration to the aggregation switch according to the high availability form to control the forwarding processing of the traffic message of the abnormal service type includes: When the high availability state is in the active state of the master-master mode, an instruction to revoke the externally published route of the abnormal service type is sent to the aggregation switch to control the aggregation switch to switch the traffic message of the abnormal service type from the equal-cost route to the single-hop mode of the backup host in the master-master mode; When the high availability state is in the active state of the active-standby mode, an instruction to switch the priority of the externally published route of the abnormal service type is sent to the aggregation switch to control the aggregation switch to enable the standby machine in the active-standby mode to process the traffic message of the abnormal service type; When the high availability state is in the standby state of the active-standby mode, a maintenance instruction for the externally published route of the abnormal service type is sent to the aggregation switch to control the aggregation switch to maintain the processing of the flow message of the abnormal service type.

14. The method for identifying the service type of a traffic message according to claim 1, wherein: The method further comprises: Determine the type of business to be migrated; Sending a pre-configuration instruction to the newly added gateway according to the type of service to be migrated; The migration route configuration of the service type to be migrated is sent to the aggregation switch to control the aggregation switch to cancel the current externally advertised route of the service type to be migrated and forward the traffic message of the service type to be migrated to the newly added gateway.

15. A device for identifying the service type of a traffic message, characterized in that: The device comprises: A receiving module, used for receiving traffic messages; An analysis module, configured to analyze the traffic message to obtain traffic characteristics; An identification module is used to identify the service type of the traffic message according to the traffic characteristics.

16. A terminal device, characterized in that: It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, and when the processor executes the computer program, it implements the service type identification method of the traffic message as described in any one of claims 1 to 14.

17. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute the service type identification method of the traffic message according to any one of claims 1 to 14.

18. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 14 are implemented.

Images