WO2010020151A1 - 报文处理方法、装置和*** - Google Patents

报文处理方法、装置和*** Download PDF

Info

Publication number
WO2010020151A1
WO2010020151A1 PCT/CN2009/073100 CN2009073100W WO2010020151A1 WO 2010020151 A1 WO2010020151 A1 WO 2010020151A1 CN 2009073100 W CN2009073100 W CN 2009073100W WO 2010020151 A1 WO2010020151 A1 WO 2010020151A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
cpu
board
service
tunnel
Prior art date
Application number
PCT/CN2009/073100
Other languages
English (en)
French (fr)
Inventor
朱志强
张日华
侯贵斌
徐勇
谢文辉
马擘
高国鲁
陆晓萍
付翠花
Original Assignee
成都市华为赛门铁克科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN2008101424585A external-priority patent/CN101350759B/zh
Priority claimed from CN2008102121823A external-priority patent/CN101345689B/zh
Priority claimed from CN2008101495947A external-priority patent/CN101355505B/zh
Priority claimed from CN2008101835510A external-priority patent/CN101442470B/zh
Application filed by 成都市华为赛门铁克科技有限公司 filed Critical 成都市华为赛门铁克科技有限公司
Publication of WO2010020151A1 publication Critical patent/WO2010020151A1/zh
Priority to US13/030,898 priority Critical patent/US8509239B2/en
Priority to US13/935,929 priority patent/US8737388B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/12—Protocol engines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/354—Switches specially adapted for specific applications for supporting virtual local area networks [VLAN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/55—Prevention, detection or correction of errors
    • H04L49/552—Prevention, detection or correction of errors by ensuring the integrity of packets received through redundant connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]

Definitions

  • the invention name is "a message processing method, business board, interface board and network communication equipment", September 10, 2008 Submitted to the China Patent Office, application number is 200810212182. 3.
  • the invention name is "An implementation method, device and communication equipment for IP security services”. It was submitted to the Chinese Patent Office on December 18, 2008, and the application number is 200810183551. 0, invention The name is "a method, system and equipment for establishing a tunnel", and submitted to the Chinese Patent Office on September 12, 2008, application number 200810149594. 7.
  • the invention name is "a forwarding method, device and system for a message” Priority of the Chinese Patent Application, the entire contents of which is incorporated herein by reference. Technical field
  • the embodiments of the present invention relate to the field of communications technologies, and in particular, to a packet processing method, apparatus, and system. Background technique
  • VPN virtual private network
  • the virtual private network (Vir tua l Pr iva te network, hereinafter referred to as VPN) technology refers to the technology of constructing a private network on the public network by using tunnel technology, encryption and decryption, identity authentication and the like.
  • VPN technology has the advantages of cost saving, high security, strong scalability, easy management and full control. It is the trend of enterprise network development at present and in the future. Unlike traditional networks, VPNs do not exist. Instead, they use existing public networks. Virtual networks that are configured through resources are logical networks. VPNs are only used by specific enterprises or user groups. VPN is not a simple high-level service, but a network interconnection between private network users.
  • the tunneling protocol of the VPN may include a yer 2 tunneling protocol (hereinafter referred to as UTP) protocol, an IP layer protocol security structure (hereinafter referred to as IPSec) protocol, and a general routing encapsulation. (Gener ic Rout ing Encapsula t ion, hereinafter referred to as: GRE) Agreement, etc.
  • the VPN tunneling protocol uses tunneling (Tunne l) technology at the protocol layer.
  • the tunnel is a virtual point-to-point connection. In practice, it can be regarded as a virtual interface that only supports point-to-point connections. This interface provides a path for encapsulating data. Packets can be transmitted on this path, and data packets are encapsulated and decapsulated at both ends of a tunnel.
  • the embodiment of the invention provides a packet processing method, device and system, thereby improving the throughput of the service and the processing efficiency of the message.
  • the embodiment of the present invention provides a packet processing method, which is applied to a distributed architecture of a multi-service board.
  • the distributed architecture includes a main control board, at least one service board, and at least one interface board, and the method includes:
  • the specified CPU corresponding to the received packet is determined, and the received packet is processed by the service board corresponding to the CPU.
  • An embodiment of the present invention provides an interface board, which is applied to a system including a main control board, at least one interface board, and a service board, and includes:
  • the packet sending unit is configured to send the received first packet to the specified service board according to the configured GRE routing information delivered by the main control board;
  • a packet forwarding unit configured to receive the encapsulated first packet sent by the service board, and forward the first packet after the encapsulation process according to the configured GRE routing information sent by the main control board ;
  • the message receiving unit is configured to receive the second packet that is sent by the external device and respond to the first packet processed by the encapsulation, and send the second packet to the service board according to the configured routing information.
  • the embodiment of the invention provides a packet processing system, which is characterized in that it comprises a main control board, at least one interface board and a service board;
  • the main control board is configured to send information required for the encapsulated packet and configure GRE routing information.
  • the interface board is configured to send, according to the configured GRE routing information delivered by the main control board, the received first packet to the service board, where the service board encapsulates the first packet Processing, and receiving the encapsulated first packet sent by the service board, and forwarding the first packet after the encapsulation processing to the external according to the configured GRE routing information delivered by the main control board, And sending the second packet to the service board according to the configured routing information, after the second packet that is sent by the external device to respond to the first packet that is processed by the encapsulation, The second packet is decapsulated;
  • the service board is configured to perform encapsulation and decapsulation processing on the packet sent by the interface board.
  • An embodiment of the present invention provides a packet processing system, including a plurality of service boards, a control board, and an interface board, where the multiple service boards are used to establish a tunnel with a client, and the tunnel is stored. Numbering the CPU of the service board that establishes a tunnel with the client, and requesting the control board to allocate an IP address to the client;
  • the control board is configured to process the number of the tunnel and process the current service board of the tunnel.
  • the interface board is configured to query a destination address of the packet when receiving the packet, and when the destination address of the packet is the IP address of the client, the IP address corresponding to the client
  • the CPU number sends the >3 ⁇ 4 text to the service board corresponding to the CPU number for processing.
  • An embodiment of the present invention provides a service board that is applied to a distributed architecture, where the service board is in communication with a control board and an interface board, and is configured to receive a number of a tunnel and a processing center that are sent by the control board and are sent by the control board.
  • the CPU number of the tunnel and the IP address corresponding to the client and query the destination address of the packet after receiving the packet, and when the destination address of the packet is the IP address of the client And sending the packet to a service board corresponding to the CPU number for processing according to a CPU number corresponding to the IP address of the client.
  • An embodiment of the present invention provides an interface board that is applied to a distributed architecture, where the interface board is connected to a control board and multiple service boards, and the multiple service boards are used to establish a tunnel with the client.
  • the interface board is configured to receive a number of a tunnel that is sent by the control board, a CPU number that processes the tunnel, and an IP address that is allocated to the client, and query the information after receiving the packet.
  • the destination address of the packet, and the destination address of the packet is the IP address of the client, and the packet is sent to the CPU number according to the CPU number corresponding to the IP address of the client.
  • the business board is processed.
  • An embodiment of the present invention provides a packet processing apparatus, including: a first CPU acquiring unit and a first CPU;
  • the first CPU acquiring unit is configured to obtain, according to the received IP packet, a first CPU that performs IP security IPSEC service processing on the IP packet;
  • the first CPU is configured to perform corresponding IPSEC service processing on the IP file and send the same.
  • An embodiment of the present invention provides a packet processing system, including at least one interface board and at least two CPUs;
  • the interface board is configured to obtain, according to the received IP packet, a first CPU that performs IP security IPSEC service processing on the IP packet;
  • the first CPU is configured to perform corresponding IPSEC service processing on the IP file and send the IP address.
  • the received packet is processed in the service board corresponding to the designated CPU, so that the packet is uniformly distributed to each service board for processing, thereby reducing the workload of the main control board, and greatly Improve the throughput of the business, thereby improving the processing efficiency of the entire architecture of the message DRAWINGS
  • FIG. 1 is a flowchart of a packet processing method according to Embodiment 2 of the present invention.
  • FIG. 2 is a schematic diagram of a data flow forwarded by a packet in a device according to Embodiment 2 of the present invention
  • FIG. 3 is a flowchart of a method for forwarding a packet according to Embodiment 2 of the present invention
  • FIG. 5 is a schematic structural diagram of an interface board according to Embodiment 3 of the present invention.
  • FIG. 6 is a schematic structural diagram of an interface board according to Embodiment 4 of the present invention.
  • FIG. 7 is a schematic structural diagram of a packet processing system according to Embodiment 5 of the present invention
  • FIG. 8 is a flowchart of a packet processing method according to Embodiment 6 of the present invention.
  • FIG. 9 is a flowchart of a packet processing method according to Embodiment 7 of the present invention.
  • FIG. 10 is a schematic diagram of an application environment of a message processing system according to Embodiment 8 of the present invention
  • FIG. 11 is a structural diagram of a message processing system according to Embodiment 8 of the present invention
  • FIG. 13 is a flowchart of a packet processing method according to Embodiment 10 of the present invention
  • FIG. 14 is a schematic diagram of a packet processing method according to Embodiment 10 of the present invention
  • FIG. 15 is a schematic structural diagram of a packet processing apparatus according to Embodiment 11 of the present invention
  • FIG. 16 is a schematic structural diagram of a packet processing system according to Embodiment 12 of the present invention
  • FIG. 18 is a flowchart of a method for establishing a tunnel according to Embodiment 13 of the present invention
  • FIG. 19 is a schematic flowchart of implementing IKE negotiation in a distributed architecture according to an embodiment of the present invention
  • FIG. Flow chart of negotiation
  • FIG. 21 is a schematic structural diagram of a device for establishing a tunnel according to Embodiment 14 of the present invention. detailed description
  • the first embodiment of the present invention provides a packet processing method, which is applied to a distributed architecture of a multi-service board.
  • the distributed architecture includes a main control board, at least one service board, and at least one interface board, and the method includes: determining reception The specified CPU corresponding to the received message, and the received service packet is processed by the service board corresponding to the CPU.
  • the received packet is processed in the service board corresponding to the specified CPU, so that the packet is evenly distributed to each service board for processing, which reduces the workload of the main control board and greatly improves the workload.
  • the throughput of the service improves the processing efficiency of the message.
  • FIG. 1 is a flowchart of a packet processing method according to Embodiment 2 of the present invention. As shown in FIG. 1, the method includes the following steps:
  • the interface board encapsulates the GRE routing information according to the configuration common route delivered by the main control board, and sends the received first packet to the specified service board.
  • the service board encapsulates the first packet. .
  • the GRE routing information includes information such as the next hop of the route, the outbound interface, the CPU ID of the GRE, and the I D of the tunnel.
  • the interface board receives the encapsulated first packet sent by the service board, and forwards the first packet after the encapsulation process to the external according to the configured GRE routing information sent by the main control board.
  • the external address is the destination address of the first packet to be sent.
  • the interface board receives the second packet that is sent by the external device and responds to the first packet processed by the encapsulation, and sends the second packet to the service board according to the configured routing information.
  • the second packet is decapsulated by the service board. Where the external is to send the second The source address of the text.
  • the interface board when a large number of packets pass through the device, the interface board sends different packets to different service boards according to the configured GRE routing information, so that the packets are evenly distributed to each service board.
  • the processing is performed to avoid a large number of packets being sent to the main control board for processing at the same time, thereby improving the processing efficiency of the message.
  • a second embodiment of the present invention provides a packet processing method.
  • the method is applied in the GRE tunnel encapsulation service, and the encapsulated data flow is determined by the source address and destination address of the tunnel.
  • the packets received by the interface board can be encapsulated or decapsulated regardless of the CPU. .
  • the CPU of each service board is first numbered; then the IP address of both ends of the Tunne l is hashed, and the corresponding CPU is selected according to the ha sh index.
  • the packets of different Tunne l plus encapsulation and reverse decapsulation are processed according to the hash index to different CPUs. This implements the entry and exit of the tunnel by the same CPU. The purpose of the treatment.
  • FIG. 2 A schematic diagram of the data flow forwarded by the packet in the device is shown in FIG. 2, where the data stream No. 0 is sent to the configuration board of the service board, and the stream 1 is sent to the service board for encapsulation.
  • Stream 2 is the stream that is sent to the interface board after being encapsulated on the service board.
  • Stream 3 is the stream that is sent from the interface board to the service board.
  • the stream 4 is the stream that the packet is sent to the interface board after the packet is decapsulated.
  • the S30K main control board broadcasts related information required for encapsulating packets to each service board.
  • the main control board is responsible for all configuration management in the distributed architecture of the multi-service board.
  • the information required for the encapsulated packet includes the source address and destination address of the tunnel, the IP address of the Tunen l interface, the checksum, and the authentication key.
  • the main control board broadcasts the configured GRE routing information to the service board and the interface board.
  • the GRE routing information includes the CPU ID and tunnel ID of the GRE ⁇ message in addition to the next hop and the outbound interface of the route.
  • the interface board receives the packet, and determines how to route the packet according to the destination address of the packet.
  • the way to route the packet in this step includes:
  • the interface board obtains the CPUID of the packet according to the configured GRE routing information, and sends the packet to the service board where the corresponding CPU is located. deal with;
  • the interface board When the packet is sent to the local device, the interface board performs a hash according to the source address and destination address of the packet, and calculates which service board should process the packet.
  • the purpose of this step is to ensure that the same packet is processed on the same CPU. This prevents the same packet from being lost in the processing of different CPUs because it cannot find the packet loss, and avoids all the packets.
  • the hash calculation is performed by the CPU to troubleshoot the CPU.
  • the service board When the service board receives the packet from the interface that is sent through the outbound interface of the tunnel, the service board finds the route of the packet and determines the outbound interface of the packet according to the pre-configured GRE routing information. Which tunnel is added with information such as encapsulation.
  • the service board encapsulates the packet according to the information about the pre-configured encapsulated packet.
  • the above-mentioned encapsulation processing is specifically performed by adding information such as a source address, a destination address, and a tunnel identifier of the tunnel to the header of the packet.
  • the service board determines the interface and the next hop according to the outbound interface and the next hop of the packet configured in the step s304, and sends the encapsulated packet to the interface board for forwarding.
  • the process of decapsulating the received packet is as shown in FIG. 4, which is specifically as follows: S401: After receiving the text of the local machine, the interface board hashes the source address and the destination address of the message, according to the hash. The index selects the corresponding CPU and sends the packet to the service board corresponding to the CPU. 54 02. The service board decapsulates the received packet according to the saved configuration information.
  • the configuration information is specifically the source address, the destination address, the IP address of the Tunen 1 interface, and the tunnel identifier.
  • the decapsulation process includes: determining whether the source address, the destination address, and the tunnel identifier of the GRE protocol packet are the source address, the destination address, and the tunnel identifier of the tunnel. If yes, the source address, destination address, and tunnel ID of the GRE protocol are removed. Otherwise, the GRE protocol packet is discarded.
  • the method provided in the second embodiment of the present invention prevents a large number of packets from being sent to the main control board for processing at the same time, thereby improving processing efficiency and saving CPU resources of the main control board. And the GRE message in and out of the tunnel is processed in the same CPU, maintaining the consistency of the session information.
  • FIG. 5 is a schematic structural diagram of an interface board according to Embodiment 3 of the present invention. As shown in FIG. 5, the interface board is applied to a system including a main control board, at least one interface board, and a service board, including: Unit 10, message forwarding unit 2 0 and message receiving unit 30;
  • the packet sending unit 10 is configured to encapsulate the GRE routing information according to the configured universal routing route sent by the main control board, and send the received first packet to the specified service board.
  • the packet forwarding unit 20 is configured to receive the encapsulated first packet sent by the service board, and forward the encapsulated processing to the external according to the configured GRE routing information delivered by the main control board.
  • the packet receiving unit 30 is configured to receive a second packet that is sent by the external device and that responds to the encapsulated first packet, and sends the second packet to the Business board
  • FIG. 6 is a schematic structural diagram of an interface board according to Embodiment 4 of the present invention.
  • the packet sending unit 10 further includes: sending a first packet according to the third embodiment. Subunit 1 1 and second message delivery subunit 1 2 ; The first packet is sent to the sub-unit 1 1 , and the interface board obtains the GRE routing information according to the configured GRE routing information when the first packet received by the interface board is to be routed through the outbound interface of the tunnel Tunne 1 The CPU ID corresponding to the first packet is sent, and the first packet is sent to the service board.
  • the second packet is sent to the sub-unit 1 2, and when the interface board finds that the first packet received is a packet to the local device, the interface board is configured according to the source address of the first packet.
  • the destination address is hashed, and the service board of the first text is calculated and sent.
  • FIG. 7 is a schematic structural diagram of a packet processing system according to Embodiment 5 of the present invention. As shown in FIG. 7, the main control board 40, at least one interface board 50, and a service board 60;
  • the main control board 40 is configured to deliver the information required for the encapsulated message and the configuration GRE routing information.
  • the interface board 50 is configured to send the received first packet to the service board 60 according to the configured GRE routing information sent by the main control board 40, and the service board 60 And performing the encapsulation process on the first packet, and receiving the encapsulated first packet sent by the service board 60, and forwarding the encapsulated processing to the external according to the configured GRE routing information delivered by the main control board 40.
  • the first packet after receiving the second packet that is sent by the external device and responding to the encapsulated first packet, routes the second packet to the service board 60 according to the configured routing information. Decapsulating the second packet by the service board 60;
  • the service board 60 is configured to perform encapsulation and decapsulation processing on the packet sent by the interface board 50.
  • the device and the system provided by the embodiments of the present invention can uniformly distribute the packets to each service board for processing, and prevent a large number of packets from being sent to the main control board for processing at the same time, thereby improving forwarding efficiency and saving the main control. Board CPU resources. And the GRE text in and out of the tunnel is processed by the same CPU, maintaining the consistency of the session information.
  • FIG. 8 is a flowchart of a packet processing method according to Embodiment 6 of the present invention.
  • the method is applied to a network device of a distributed architecture of a multi-service board.
  • the main control board, the interface board, and multiple service boards are connected to each other.
  • the interface board and the plurality of service boards, and the interface board are respectively connected to the plurality of service boards.
  • the network device of the distributed architecture is external to the client and the network.
  • Step S800 When the client initiates the connection request, the service board is selected through the interface board, and the L2TP tunnel of the client and the service board is negotiated.
  • the client sends a negotiation request message to the interface board, and the interface board performs a HASH operation according to the source address and the destination address in the negotiation packet to select one of the multiple service boards.
  • the service board negotiates to establish an L2TP tunnel between the client and the service board.
  • the destination address in the negotiation request is the IP address of the two ends of the tunnel, and the interface board can query the service board of the packet sent by the client according to the IP address of the two ends of the tunnel.
  • the service board negotiates with the client to establish a tunnel corresponding to the IP address.
  • Step S802 After the L2TP tunnel is established, the number corresponding to the tunnel is stored in the CPU of the service board, and the main control board is requested to allocate an IP address to the client, and return the assigned IP address and the tunnel number. Client.
  • the tunnel is numbered.
  • Step S804 The main control board sends the number of the tunnel, the CPU number of the tunnel, and the IP address of the client to the interface board and all the service boards.
  • Step S806 After receiving the packet, the interface board queries the destination address of the packet through the interface board, or queries the destination address of the packet after the other service board receives the packet.
  • the interface board may receive the L2TP decapsulation packet sent by the client to the network.
  • the destination address is the IP address of the tunnel.
  • the destination address of the packet that needs to be L2TP encapsulated by the network is the IP address of the client.
  • the packet received by other service boards may be the packet that the network feeds back to the client, and the destination address is the IP address of the client.
  • the other service boards may process the NAT (Ne twork Addres s Translating) service of the packet, and may also process other services, and the other services do not include L2TP decapsulation and L2TP encapsulation services.
  • NAT Network Addres s Translating
  • the other services do not include L2TP decapsulation and L2TP encapsulation services.
  • Step S808 If the destination address of the packet is the IP address of the client, the packet is sent to the service board corresponding to the CPU number for L2TP encapsulation processing according to the CPU number corresponding to the IP address of the client, or If the destination address of the packet is the IP address of the tunnel between the service board and the client, the packet is sent to the current service board corresponding to the tunnel for L2TP decapsulation.
  • the HASH operation is performed according to the source address and the destination address of the packet to query the service board for processing the text. At this time, the HASH operation is performed according to the source address and the destination address of the >3 ⁇ 4 text to query and process the text.
  • the step of the service board is the same as the step S800.
  • the service board After the service board is queried, the service board obtains the number of the tunnel from the header information of the packet, and selects the CPU corresponding to the number of the tunnel to perform L2TP decapsulation processing, that is, according to The IP address of the two ends of the tunnel is found to be the IP address of the two ends of the tunnel.
  • the IP address of the two ends of the tunnel is the IP address of the two ends of the tunnel in the negotiation establishment process in step S800.
  • the interface board if the interface board queries the destination address of the received packet as the IP address of the client or if the other service board queries the destination address of the received packet as the IP address of the client, The CPU number corresponding to the IP address of the client sends the packet to the service board corresponding to the CPU number for L2TP encapsulation processing; or if the interface board queries the destination address of the packet as the IP address of the tunnel, the source of the packet is obtained.
  • the address and the destination address are hashed to query the service board that processes the packet, and the L2TP decapsulation process is performed.
  • Step S810 Send the processed message through the interface board.
  • the L2TP encapsulated packet is sent to the client corresponding to the IP address through the interface board, or the L2TP decapsulated packet is sent to the network via the interface board.
  • a packet processing method is provided in the sixth embodiment of the present invention.
  • the current service board negotiates with the client to establish a tunnel, and sends the number of the tunnel, the CPU number of the service board, and the IP address of the client to the interface board. All the service boards, when the interface board or other service boards receive the packets to be sent to the client, send the packets to the CPU of the current service board corresponding to the tunnel number for L2TP encapsulation through the corresponding relationship. Newspaper to be sent to the network
  • the current service board of the tunnel is negotiated through the IP address of the tunnel of the packet, and the packet is sent to the CPU of the current service board for L2TP decapsulation processing to ensure that the same client needs to be performed.
  • L2TP encapsulation and L2TP decapsulation of packets are processed in the CPU of the same service board, which reduces the workload of the main control board and greatly improves the throughput of the L2TP service, thus improving the processing of the entire architecture. effectiveness.
  • FIG. 9 is a flowchart of a packet processing method according to Embodiment 7 of the present invention. As shown in FIG. 9, the method includes:
  • Step S900 Establish an IPSEC tunnel between the client and the service board according to the IPSEC packet sent by the client.
  • Step S902 Establish an L2TP tunnel of the client and the service board according to the L2TP packet negotiation of the IPSEC message.
  • Steps S904, S906, and S908 are identical to the descriptions of steps S802, S804, and S806 of Fig. 8.
  • Step S910 If the destination address of the packet is the IP address of the client, the packet is sent to the service board corresponding to the CPU number for L2TP encapsulation processing according to the CPU number corresponding to the IP address of the client. IPSEC encryption processing, or if the destination address of the query is the IP address of the tunnel of the service board and the client, the packet is sent to the service board corresponding to the tunnel to perform IPSEC decryption processing and then L2TP decapsulation processing. .
  • the HASH operation is performed according to the source address and the destination address of the packet to query the service board that processes the packet.
  • the HASH operation is performed according to the source address and the destination address of the packet to query and process the text.
  • the step of the service board is the same as the step S902.
  • the service board obtains the number of the tunnel from the header information of the packet, and selects the CPU corresponding to the number of the tunnel to perform the CPU corresponding to the IP address of the client.
  • the number is sent to the service board corresponding to the CPU number to perform IPSEC decryption processing and then L2TP decapsulation processing, that is, the corresponding service board is found according to the IP addresses of the two ends of the tunnel, and at this time, the ⁇
  • the IP addresses at both ends of the tunnel are the IP addresses of the two ends of the tunnel in the negotiation establishment process in step S902.
  • the interface board queries the destination address of the received packet as the client If the destination address of the packet received by the other service board is the IP address of the client, the packet is sent to the service corresponding to the CPU number according to the CPU number corresponding to the IP address of the client. If the interface is configured to process the IP address of the packet, the interface board performs the HASH operation based on the source address and the destination address of the packet to query the service board that processes the packet.
  • the other service boards may process the NAT (Network Addres s Trans la ti on) service, and may also process other services. The other services are not processed.
  • Step S912 Send the processed message.
  • the L2TP encapsulation and the IPSEC-encrypted packet are sent to the client corresponding to the IP address through the interface board, or the IPSEC decryption and the L2TP decapsulation packet are sent to the network through the interface board.
  • a packet processing method is provided in the seventh embodiment of the present invention.
  • the current service board negotiates with the client to establish a tunnel, and sends the number of the tunnel, the CPU number of the service board, and the IP address of the client to the interface board. All the service boards, when the interface board or other service boards receive the packets to be sent to the client, send the packets to the CPU of the current service board corresponding to the tunnel number for L2TP encapsulation processing and IPSEC. Encryption processing, when the interface board receives the packet to be sent to the network, the IP address of the tunnel of the packet is used to query the current service board of the tunnel, and the packet is sent to the CPU of the current service board.
  • the IPSEC decryption process is performed and the L2TP decapsulation process is performed to ensure that the L2TP encapsulation, the IPSEC encryption, the L2TP decapsulation, and the IPSEC decryption of the same client are processed in the CPU of the same service board, thereby reducing the main control board. Workload, and greatly improve the throughput of L2TP and IPSEC services, thereby improving L2TP+IPSEC Li Wen efficiency of the web at.
  • FIG. 10 is a schematic diagram of an application environment of a message processing system according to Embodiment 8 of the present invention.
  • the message processing system 3 is connected to a plurality of clients 5 and the network 4, and the network 4 Including the internal network 400 and the external network 41 0 , the internal network 400 is the internal network of the enterprise, and the external network 41 0 is the internal network of the non-enterprise.
  • the packet sent by the client 5 may be a packet that accesses the internal network of the enterprise, or may be a packet that accesses the internal network of the non-enterprise.
  • FIG. 11 is a structural diagram of a message processing system according to Embodiment 8 of the present invention.
  • the packet processing system 3 includes an interface board 300, a main control board 31 0, a first service board 321, and a second service board 322, an Nth service board 32N, and the packet processing system 3 is used to interface board 300.
  • the received network sends the L2TP encapsulation to the client and the L2TP decapsulation that is sent to the network by the client is processed in the CPU of the same service board.
  • the first service board 321 and the second service board 322 have the same function structure.
  • the first service board 321 is taken as an example for description.
  • the interface board 300 is configured to select one of the N service boards according to the connection request initiated by the client. In this embodiment, the interface board 300 selects the first service board 321 .
  • the first service board 321 is configured to negotiate to establish an L2TP tunnel of the first service board 321 and the client, store the number of the established L2TP tunnel in the internal CPU, and request the main control board 31 0 to allocate an IP address to the client, and Return the assigned IP address to the client.
  • the first service board 321 is further configured to send the number of the tunnel, the CPU number that processes the tunnel, and the IP address assigned to the client to the main control board 31 0 .
  • the main control board 31 0 is configured to send the number of the tunnel sent by the first service board 321 , the CPU number of the processing tunnel, and the IP address assigned to the client to the main control board 31 0 and the first service board. 321.
  • the second service board 322 is the Nth service board 32N.
  • the interface board 300 is further configured to query the destination address of the packet when receiving the packet sent by the client or the network.
  • the packet when the destination address of the packet is the IP address of the client, the packet is a packet sent by the network to the client, and the interface board 300 according to the CPU number corresponding to the IP address.
  • the message is sent to the service board corresponding to the CPU number for L2TP encapsulation processing, that is, sent to the first service board 321 for L2TP encapsulation processing; when querying the packet
  • the interface board 300 sends the packet to the service board corresponding to the tunnel for L2TP decapsulation processing, that is, the packet is sent to the first service board 321 L2TP decapsulation processing.
  • the service board of the second service board 322 is also used to query the destination address of the packet after receiving the packet.
  • the second service board is also used to query the destination address of the packet after receiving the packet.
  • the service board of the Nth service board 32N may process the NAT (Network Addres s Translating) service of the packet, and may also process other services. Does not include L2TP decapsulation, L2TP encapsulation, IPSEC decryption, IPSEC encryption services.
  • NAT Network Addres s Translating
  • the packet when the destination address of the packet is the IP address of the client, the packet is a packet sent by the network to the client, and the service board of the packet processing the NAT service is based on the IP address.
  • the corresponding CPU number is sent to the service board corresponding to the CPU number for L2TP encapsulation processing, that is, sent to the first service board 321 for L2TP encapsulation processing.
  • the interface board 300 is further configured to send the processed message of the first service board 321 .
  • the interface board 300 sends the L2TP encapsulation process to the client, or sends the L2TP decapsulation process to the network.
  • the first service board 321 is further configured to establish an IPSEC tunnel between the client and the service board according to the IPSEC packet sent by the client, and establish the client according to the L2TP packet negotiation of the IPSEC packet. L2TP tunnel of the service board.
  • the interface board 300 is further configured to: when the destination address of the packet is the IP address of the client, that is, the packet is a packet sent by the network to the client, according to the CPU number corresponding to the IP address.
  • the service packet sent to the service board corresponding to the CPU number is first subjected to L2TP encapsulation processing and then subjected to IPSEC encryption processing, that is, sent to the first service board 321 to perform L2TP encapsulation processing and then subjected to IPSEC encryption processing;
  • the destination address is to establish the service board.
  • the interface board 300 sends the packet to the service board corresponding to the tunnel to perform IPSEC decryption processing and then performs L2TP decapsulation processing, that is, the packet is sent to the first service board 321 to perform IPSEC first.
  • the decryption process performs L2TP decapsulation processing.
  • any one of the service boards of the second service board 322 is used to query the IP address of the client when the destination address of the packet is the IP address of the client, that is, the packet is sent to the client for the network.
  • the service board sends the packet to the service board corresponding to the CPU number to perform L2TP encapsulation processing and then perform IPSEC encryption processing according to the CPU number corresponding to the IP address, that is, the service board sends the packet to the first service board 321 to perform L2TP encapsulation first. Processing and then IPSEC encryption processing.
  • the interface board 300 is further configured to send the L2TP encapsulation and IPSEC encryption processing of the first service board 321 to the client, or send the first service board 321 to the IPSEC decryption and L2TP decapsulation processing to the network. .
  • the current service board negotiates with the client to establish a tunnel, and sends the number of the tunnel, the CPU number of the service board, and the IP address of the client to the interface board and all
  • the service board when the interface board or other service board receives the packet to be sent to the client, sends the packet to the CPU of the current service board corresponding to the tunnel number, first performs L2TP encapsulation processing and then performs IPSEC encryption.
  • the interface board receives the packet to be sent to the network, the IP address of the tunnel of the packet is used to query the current service board of the tunnel, and the CPU sends the packet to the CPU of the current service board.
  • the IPSEC decryption process performs the L2TP decapsulation process to ensure that the L2TP encapsulation, the IPSEC encryption, the L2TP decapsulation, and the IPSEC decryption of the same client are processed in the CPU of the same service board, thereby reducing the main control board. Workload, and greatly improved the throughput of L2TP and IPSEC services, thereby improving the L2TP+IPSEC group The efficiency of the network's processing.
  • FIG. 12 is a flowchart of a packet processing method according to Embodiment 9 of the present invention. The method is based on at least two CPUs. As shown in FIG. 12, the method specifically includes the following steps:
  • Step S1201 The interface board acquires the at least two CPUs according to the received IP packet.
  • the first CPU that performs IP security IPSEC service processing on the IP packet;
  • the first CPU is a designated CPU
  • Step S1202 The first CPU performs corresponding IPSEC service processing on the IP document and sends the IP information.
  • the technical solution provided by the ninth embodiment of the present invention obtains the first CPU that implements the IPSEC service of the IP packet by using an IP packet, and corresponds the IP >3 ⁇ 4 text to the corresponding CPU, and the CPU implements the IPSEC service of the IP packet.
  • the workload of the main control board is reduced, so that the processing efficiency of the packet is improved.
  • the load splitting of the IP packet is implemented by using different CPUs, and the high-speed VPN device with multiple CPUs cannot be implemented in the prior art.
  • the problem brought by the service enables the IPSEC service to be implemented in a VPN device that includes multiple CPUs.
  • Embodiment 10 of the present invention is specifically described below.
  • first and second are used to distinguish between CPUs that play different roles when processing an IP packet, and are not limited in number. The specific functions of the first CPU and the second CPU will be described below.
  • the following first CPU and the second CPU are not substantially different, and may be any CPU on the service board, which will be described below, and will not be described again.
  • FIG. 13 is a flowchart of a packet processing method according to Embodiment 10 of the present invention. The method is based on at least two CPUs. As shown in FIG. 13, the method specifically includes the following steps:
  • Step S1301 The interface board obtains, from the at least two CPUs, the first CPU that performs IP security IPSEC service processing on the IP packet according to the received IP packet.
  • the service boards 1 to 4, and the interface boards 1 and 2 may include a service board, where the service board includes multiple CPUs. Or a plurality of service boards may be included.
  • the CPU may be distributed on multiple service boards, and the interface board may be one or more.
  • the interface board 1 or the interface board 2 is used as the entry of the IP packet. The description is divided into two cases:
  • the IP packet is an IP packet to be encapsulated, including: Step S1301A: The interface board acquires the second CPU according to the IP packet to be encapsulated.
  • the interface board is the entry of the IP packet (IP packet 1) to be encapsulated.
  • IP packet 1 IP packet 1
  • the interface board receives the IP packet from the data sending client, and the IP packet carries the IP packet data to send the client and receive the data.
  • the source and destination IP addresses of the client In the tenth embodiment of the present invention, the interface board obtains the second CPU according to the source and destination IP addresses carried in the IP packet, and the processing manner is as follows:
  • the tenth embodiment of the present invention first performs hashing on the source and destination ip addresses carried by the ip packet.
  • the HASH conversion method is used to obtain the HASH index value of the IP packet.
  • the HASH conversion method used in the tenth embodiment of the present invention includes the following steps:
  • the fourth parameter X4 obtained by the above steps S1301a to S1301c is used as the HASH index value of the IP packet.
  • the HASH index value of the IP packet is corresponding to a different CPU on each service board, so that the corresponding second CPU can be obtained according to the IP packet to be encapsulated.
  • the value of the HASH index obtained in the above, that is, the value of the fourth parameter is usually 0 to 63, in the figure.
  • Each service board includes two CPUs as an example to illustrate the correspondence between IP packets and the second service board.
  • the above IP packet can be corresponding to the corresponding second CPU by using various methods, thereby
  • the IP packet is obtained by the second CPU on the service board.
  • the method provided in Embodiment 10 of the present invention is as follows:
  • Each CPU on the service board can serve as the second CPU, and forwards the IP packet to the corresponding first CPU, and the data amount of the forwarded IP packet is also arbitrary, in order to fully utilize the distributed multi-service board.
  • the advantage of the CPU is to improve the processing efficiency of the IPSEC service.
  • the second embodiment of the present invention averages the HASH index value according to the data volume of the IP packet to each CPU. For ease of understanding, the following description is simplified:
  • a number is set for each CPU.
  • 160 different HASH index values are obtained according to the IP packet, and the range is between 0 and 63.
  • the four service boards include 8 CPUs, the CPU number is 1 to 8, the service board is CPU1 and CPU2, the service board 2 is CPU3 and CPU4, and the service board 3 is CPU5 and CPU6. Four are CPU7 and CPU8.
  • the above range of values 0 to 63 can be equally divided into 8 sub-ranges, and the range of each sub-range is 0 to 7, 8 to 15, 16 to 23, 24 to 31, 31 to 38, 39 to 46, respectively. 47 to 55, 56 to 63, the HASH index values corresponding to the eight sub-ranges are respectively assigned to the CPU 1 to the CPU 8.
  • the value of the HASH index value of the 60 IP packets is obtained in the range of the above-mentioned 160 IP packets. Between 24 and 31, the IP packets corresponding to the HASH index value in the range can be mapped to two or more CPUs to ensure that each CPU is fully utilized and the data processing performance of the VPN device is improved.
  • the interface board After receiving the IP packet from the data sending client, the interface board obtains the HASH index value of the IP packet according to the source and destination IP addresses in the IP packet, and passes the foregoing correspondence according to the HASH index value.
  • the second CPU corresponding to the IP packet can be obtained.
  • the dotted line in Figure 14 shows the IP packet 1.
  • the interface board After receiving the IP packet 1, the interface board performs HASH conversion on the source and destination IP addresses of the IP packet 1, and obtains the HASH index value, and uses the HASH index value to pass the HASH index.
  • the corresponding relationship acquires the second CPU as the CPU 8 on the service board 4, and the interface board sends the IP packet 1 to the CPU 8.
  • Step S1301B The second CPU matches the IP packet by using an access control list ACL, and acquires the first CPU.
  • the second CPU is configured to perform ACL matching on the IP packet from the interface board.
  • the IP packet is sent to the CPU that implements the IPSEC service, and the CPU is the first CPU.
  • the IP packet is sent to the interface board and sent directly. The processing situation when the matching fails is not related to the present invention and will not be described.
  • the tenth embodiment of the present invention utilizes a VPN device including multiple CPUs, and has the characteristics of strong data processing capability, and adopts a load splitting technology for IP packets between multiple CPUs, that is, the IP is performed by the second CPU.
  • the packet is matched with the preset ACL data. According to the matching result, when the IPSEC service processing is required, the CPU that executes the IPSEC service corresponding to the IP address is obtained, and the CPU is the first CPU of the IP packet. .
  • the IP ⁇ Jl is sent directly to the IP packet that does not need to be processed by the IPSEC service.
  • the second CPU matches the IP packet 1 with the configured ACL data. Based on the matching result, it can be determined whether the IP packet 1 needs IPSEC service processing. When IPSEC is required, During the service processing, the first CPU that performs IPSEC service processing on the IP packet 1 can be obtained according to the configuration of the ACL.
  • the configuration of the above ACL data can be implemented by the main control board.
  • the foregoing IP packet is an IP packet to be decapsulated, and specifically includes:
  • Step S1301C Perform a hash transformation on the IP addresses of the IPSEC tunnels carried in the IP documents to be decapsulated, and obtain a hash index value.
  • the interface board 2 is used as an entry for the IP packet to be decapsulated (IP packet 2), and the interface board 2 receives the IP packet 2, which is encapsulated in the IP packet 2 ( Includes ESP encapsulation or / and AH encapsulation) IP addresses at both ends of the IP tunnel.
  • IP packet 2 Includes ESP encapsulation or / and AH encapsulation
  • Step S1301D Acquire the first CPU according to the hash index value.
  • the obtained HASH index value is obtained.
  • the first CPU that can implement the IPSEC service of the IP packet can be directly obtained.
  • the method further includes:
  • Step S1300 The main control board performs data configuration on the CPU in advance, including:
  • Step S1300A The main control board allocates a corresponding first CPU to the IP file.
  • the main control board allocates a corresponding first CPU to the IP packet according to the address of the two ends of the IP tunnel.
  • the IP packet includes the IP packet to be encapsulated and the IP packet to be encapsulated.
  • the main control board performs HASH conversion on the two ends of the IP tunnel to obtain a hash index value, and the hash index value of the IP packet corresponds to the CPU.
  • This method ensures that IP packets in the same IP tunnel can be sent to the same CPU for IPSEC service processing. That is, the same CPU is processed for encapsulation and decapsulation of IP 4 packets in the same IP tunnel.
  • Step S1300B The main control board performs corresponding ACL configuration on the first CPU corresponding to the IP document, and sends data required for implementing the IPSEC service of the IP packet to the first CPU.
  • the main control board After the CPU is configured for the IP packet, the main control board performs ACL configuration according to the mapping between the IP packet and the CPU.
  • the ACL configuration indicates that the first CPU that processes the IP packets in the same IP tunnel is used.
  • the main control board broadcasts the ACL data configuration to each CPU in the service board, and sends the data required to perform the corresponding IPSEC service to the determined CPUs.
  • the interface board first obtains the second CPU according to the source and destination IP addresses, and the second CPU reports the IP address according to the ACL data configured by the main control board.
  • the ACL is matched, and the IP packet is sent to the first CPU according to the matching result.
  • the ACL data of the CPU is configured based on the IP addresses of the two ends of the IP tunnel, and the IP packets to be decapsulated are obtained by directly obtaining the first CPU according to the IP addresses of the two ends of the IP tunnel. It ensures that the same CPU is processed for the encapsulation and decapsulation of IP packets in the same IP tunnel.
  • the main control board performs CPU allocation, configures an ACL, and sends a data to the CPU for performing the corresponding IPSEC service.
  • the control command may be sent periodically or according to factors such as changes in IP packets, for example, when If the IP address of the client or server of the packet has changed, or if a new IP packet needs to be processed by IPSEC, you can perform the above configuration steps.
  • the main control board sends the data required by the ACL configuration and the corresponding IPSEC service to the service boards one to four through the data stream 1.
  • the second CPU that is, the CPU 8 in the service board 4
  • the CPU and the CPU that handles the IPSEC service processing are the CPU 1 on the service board 1. That is, the execution CPU of the IP packet 1 is the CPU 1.
  • Step S1302 The first CPU performs corresponding IPSEC service processing on the IP file and sends the IP information.
  • the first CPU encapsulates the IP packet to be encapsulated, and the first CPU decapsulates the IP packet to be decapsulated.
  • the tenth embodiment of the present invention uses a load-sharing technology to enable multiple CPUs to carry different ACL data flows and IPSEC service processing of different IP packets, and to establish an IP packet and a CPU for processing IPSEC services of the IP packet.
  • the corresponding relationship enables the CPUs to process the IP packets in a uniform state, and ensures that the same CPU processes IP packets in the same IP tunnel, improving the VPN service processing performance of the entire machine, including IPSEC per The number of newly created tunnels, the maximum number of concurrent tunnels, and the encryption and decryption throughput are greatly improved.
  • the technical solution provided by the tenth embodiment of the present invention obtains the first CPU that implements the IPSEC service of the IP packet by using an IP packet, and corresponds the IP >3 ⁇ 4 text to the corresponding CPU, and the CPU implements the IPSEC service of the IP packet.
  • the workload of the main control board is reduced, so that the processing efficiency of the packet is improved.
  • the load splitting of the IP packet is implemented by using different CPUs, and the high-speed VPN device with multiple CPUs cannot be implemented in the prior art.
  • the problem brought by the service enables the IPSEC service to be implemented in a VPN device that includes multiple CPUs.
  • the eleventh embodiment of the present invention further provides a packet processing apparatus, as shown in FIG. 15, comprising: a first CPU acquiring unit 41 and a first CPU 42;
  • the first CPU acquiring unit 41 is configured to obtain, according to the received IP packet, a first CPU that performs IP security IPSEC service processing on the IP packet,
  • the first CPU 42 is configured to perform corresponding IPSEC service processing on the IP document and send the same.
  • the IP packet includes an IP packet to be encapsulated and an IP packet to be decapsulated.
  • the first CPU acquiring unit 41 further includes:
  • a second CPU acquiring module configured to acquire a second CPU according to the IP packet to be encapsulated, and the second CPU uses the access control list ACL to match the IP packet to obtain the first CPU.
  • the first CPU acquiring unit further includes: a calculating module, configured to perform IP addresses at both ends of the IPSEC tunnel carried in the IP packet to be decapsulated Hash transform, get the hash index value;
  • the first CPU acquiring unit 41 may be implemented by an interface board, and the first CPU 42 may be any CPU on the service board.
  • the technical solution provided in the eleventh embodiment of the present invention obtains the ip packet by using an ip packet.
  • the first CPU of the IPSEC service corresponds to the corresponding CPU, and the CPU implements the IPSEC service of the IP packet, which reduces the workload of the main control board, thereby improving the processing efficiency of the packet;
  • Different CPUs implement load splitting of IP packets, which solves the problem that the IPSEC service cannot be implemented in the high-end VPN device with multiple CPUs in the prior art.
  • the IPSEC service is implemented in the VPN device of the CPU.
  • a twelfth embodiment of the present invention further provides a packet processing system, as shown in FIG. 16, including at least one interface board and at least two CPUs.
  • the interface board 51 is configured to obtain, according to the received IP packet, a first CPU that performs IP security IPSEC service processing on the IP packet;
  • the first CPU 52 is configured to perform corresponding IPSEC service processing on the IP file and send the IP.
  • the message processing system further includes:
  • the main control board 53 is configured to allocate a corresponding first CPU to the IP file, perform corresponding ACL configuration on the first CPU corresponding to the 1?>3 ⁇ 4 text, and implement the corresponding IPSEC service required for the IP file. Data is sent to the first CPU.
  • the CPU may be distributed on one service board or multiple service boards.
  • the second CPU and the first CPU are different functions of the CPU in the same IP tunnel, and serve as a VPN device.
  • the physical entity, the second CPU and the execution CPU are not substantially different, and may be any CPU on the service board.
  • a workflow diagram of a packet processing system includes an interface board 61 and an interface board 62, a main control board 63, a service board 64 including a CPU 65, and a service board 66 including a CPU 67.
  • the number of interface boards may be one or more, and the number of service boards may be multiple, and the like.
  • the main control board 63 configures the ACL data for the service board 64 and the service board 66.
  • the interface board 61 receives the IP packet 1 and the second CPU that obtains the IP packet 1 is the CPU 65 on the service board 64.
  • the CPU 65 is based on the ACL data.
  • the IP packet 1 is matched, and the execution CPU that executes the IPSEC service (plus encapsulation) corresponding to the IP packet is the CPU 67 on the service board 66.
  • the CPU 67 encapsulates the IP packet 1 and then passes the interface board. 62 sent out.
  • the interface board 62 receives the IP packet 2 processed and encapsulated in the same manner, and directly obtains the corresponding execution CPU 67, and sends the IP packet 2 to the CPU 67.
  • the CPU 67 decapsulates the IP packet 2 and then passes the interface board. 61 sent out.
  • the technical solution provided in the twelfth embodiment of the present invention obtains the first CPU that implements the IPSEC service of the IP packet by using the ip packet, and the IP packet corresponds to the corresponding CPU, and the CPU implements the IPSEC service of the IP packet. , the workload of the main control board is reduced, thereby improving the processing efficiency of the message;
  • the load splitting of IP packets is implemented by using different CPUs, which solves the problem that the IPSEC service cannot be implemented in the high-end VPN device with multiple CPUs in the prior art, and thus can be implemented in a VPN device including multiple CPUs.
  • IPSEC business is implemented by using different CPUs, which solves the problem that the IPSEC service cannot be implemented in the high-end VPN device with multiple CPUs in the prior art, and thus can be implemented in a VPN device including multiple CPUs.
  • Embodiment 9 and Embodiment 10 of the present invention are a packet processing method for implementing an IPSEC service.
  • the message processing method may further include a process of establishing a tunnel.
  • FIG. 18 is a flowchart of a method for establishing a tunnel according to Embodiment 13 of the present invention. As shown in FIG. 18, the method includes:
  • Step S1801 Receive a packet that needs to be encrypted, and the packet that needs to be encrypted is a packet that is sent to a specified CPU of the CPU according to an allocation rule;
  • the specified CPU can be the first CPU.
  • the allocation rule is specifically: sending, according to the CPU number obtained from the interface board, the message to the CPU corresponding to the CPU number, where the CPU number passes the source and destination of the interface
  • the address hash is calculated.
  • the interface board performs hash calculation on the source and destination addresses of the packets to be sent, obtains the hash value of the packet, and then sends the packet to the service board according to the hash value.
  • the service board After receiving the packet, the service board searches for the security policy that matches the packet, and obtains the packet that needs to be encrypted.
  • the service board obtains the CPU number corresponding to the hash value of the encrypted packet, and then encrypts the packet according to the security policy.
  • the message is sent to the designated CPU corresponding to the CPU number.
  • the security policy is used to maintain the data flow dynamically generated by the tunnel negotiation and check whether the packets received by the service board need to be encrypted.
  • the specified CPU detects whether the tunnel in which the encrypted packet needs to be established is established.
  • Step S1802 When the designated CPU detects that the tunnel where the text is located is not established, the IKE packet is sent to the interface board, and the tunnel negotiation is triggered.
  • Step S1803 Receive an IKE packet sent by the interface board according to the allocation rule. The tunnel.
  • the interface board may send the IKE packet according to the allocation rule.
  • the interface board performs a hash value calculation on the source and destination addresses of the received IKE packet, and obtains a CPU number for tunnel negotiation.
  • the IKE packet is sent according to the CPU number negotiated by the tunnel.
  • the IKE packet when the packet received by the service board is an IKE negotiation packet, the IKE packet can be directly sent to the interface board for tunnel negotiation; the interface board receives the IKE packet according to the source. The destination address is hashed to obtain the CPU number for tunnel negotiation. The service board receives the IKE packet sent from the interface board and establishes a tunnel.
  • CPUs are distributed on one or more service boards of the gateway, and the number of the CPUs and the number of the service boards are determined according to requirements of the gateway processing service.
  • the IPsec service and the IKE negotiation can be implemented on the service board, the workload of the main control board is reduced, and the processing efficiency of the packet is improved, and the distribution rule provided by the embodiment of the present invention can be used.
  • the IKE negotiation balancing is implemented on different service boards to improve the processing capability of the system IPsec service and IKE negotiation.
  • the method for establishing a tunnel provided by the embodiment of the present invention can implement IKE negotiation on the service board in a distributed architecture, so that the tunnel for transmitting packets is dispersed on each CPU during tunnel negotiation, and the whole is improved. Machine capacity and performance.
  • Figure 19 is a simplified flowchart of the distributed architecture. In order to clearly explain the specific embodiments of the embodiments of the present invention, it is assumed that three service boards are installed in the existing distributed architecture, and another main control board and two interface boards are also provided. There are two processor CPUs on each service board, such as A and B as shown on the service board. However, it should be noted that there are not only two CPUs on each service board, and the number of CPUs can be increased on the service board as needed. In Figure 19, there are three data streams.
  • the first stream is used to transmit IP packets
  • the second stream is used to send IKE packets
  • the third stream is used to send IKE packets for tunnel negotiation based on the calculation.
  • the method for implementing IKE negotiation and establishing a tunnel is shown in Figure 20, including:
  • Step S2001 Send the received packet to the service board.
  • the interface board When the interface board receives an IP packet, it calculates the hash by the source and destination addresses of the IP_3 ⁇ 4 text. After the value, the CPU number corresponding to the CPU that receives the message is obtained, and then the IP packet is sent to the CPU matching the CPU number through the data stream No. 1, in FIG. 19, B- on the service board 2 CPU.
  • Step S2002 Check whether the IP packet needs to be encrypted. If the IP packet does not need to be encrypted, step S2003 is performed; if the IP packet needs to be encrypted, step S2004 is performed.
  • Step S2003 No IKE negotiation is performed.
  • Step S2004 Send the IP packet to be encrypted to the designated CPU.
  • the service board After receiving the IP packet, the service board searches for the security policy that matches the packet, and obtains the packet that needs to be encrypted. Then, the service board obtains the CPU number corresponding to the encrypted packet. The CPU number is in step S2008. And generating, according to the matching security policy, the packet to be encrypted is sent to a CPU corresponding to the CPU number, where the CPU is a CPU that transmits the tunnel that needs to encrypt the packet.
  • the B-CPU on the service board 2 is matched by the security policy, and the A-CPU in the service board 1 is selected, and then the IP packet to be encrypted is sent to the A-CPU through the No. 1 data stream. .
  • Step S2005 Check whether the tunnel where the packet to be encrypted is located is established. When the tunnel in which the IP packet to be encrypted is located is established, step S2006 is performed. When the tunnel where the IP packet is located has not been established, step S2007 is performed.
  • Step S2006 No IKE negotiation is performed.
  • the tunnel where the IP packet to be encrypted is located has been established, the tunnel is transmitted through the tunnel.
  • Step S2007 performing tunnel negotiation.
  • the CPU in the service board After receiving an IP packet, the CPU in the service board performs security policy matching on the packet in the security policy unit. When the tunnel where the packet is found is not established, the CPU sends the IKE through the number 2 stream. The message is negotiated by the ramp. After receiving the IKE negotiation packet, the subsequent response negotiation also generates the number 2 stream.
  • Step S2GG8 Receives the sent IKE packet and establishes a tunnel.
  • the interface board 2 When the interface board 2 receives the IKE packet whose destination address is the local device, the interface board 2 performs the hash calculation through the source IP address and the destination IP address to obtain the CPU number for IKE negotiation.
  • the CPU corresponding to the CPU number is the step.
  • the CPU specified in S2004 is used to select the corresponding CPU when the IP address is entered into the tunnel.
  • Encryption processing (the CPU selected in Figure 19 is the A-CPU in service board one).
  • the interface board sends the IKE >3 ⁇ 4 text to the A-CPU according to the calculated CPU number, and the tunnel is established.
  • the first stream and the third stream of the same ramp will send packets to the same CPU, so that a tunnel for transmitting encrypted packets can be established.
  • Active negotiation is only initiated when the i sakmp mode is negotiated. In this mode, you need to configure the tunnel. You can obtain the source IP address and the destination IP address of the tunnel. You can calculate the hash values of the two IP addresses on the main control board and send them to all service boards. The purpose of sending to all the business boards is to enable the No. 1 stream to find the designated CPU smoothly, so that the No. 1 stream is the same as the CPU selected by the No. 3 stream.
  • the number of service boards and CPUs is not limited to a few in the figure. The number of service boards and CPUs can be determined according to the needs of the gateway to handle data services.
  • the IPsec service can be implemented on the service board.
  • the service board has the capability of processing the IPsec service and performing IKE negotiation.
  • the CPU on the service board establishes a tunnel for sending encrypted packets through IKE negotiation, which reduces the main control.
  • the workload of the board is improved, and the processing efficiency of the packet is improved.
  • the hash value calculated by different IKE packets is different according to the foregoing allocation rule, and the IKE negotiation can be balanced on different service boards. It can be seen that the more service boards are used, the more the distributed architecture can enhance the processing capability of IPsec services and IKE negotiation.
  • the foregoing embodiment 12 of the present invention is a message processing system for implementing an IPSEC service.
  • the message processing system may further include a tunneling device connected to the interface board.
  • the tunnel establishment device is configured to receive a packet sent by the interface board according to the distribution rule, and send the packet to be encrypted to the specified CPU according to the allocation rule; when the specified CPU detects that the tunnel where the packet is located is not established, The IKE packet is sent to the interface board to trigger the tunnel negotiation. The receiving interface board establishes the tunnel according to the IKE packet sent by the distribution rule.
  • An interface board configured to send the packet to the tunnel establishment device according to the allocation rule; receive the IKE packet sent by the tunnel establishment device, perform a hash value calculation on the source and destination addresses of the IKE packet, and obtain The CPU number for performing the tunnel negotiation; sending an IKE packet to the tunnel establishment device.
  • the allocation rule is specifically: sending the message to the UI according to the CPU number obtained from the interface board.
  • the CPU number is calculated by the interface board by hashing the source and destination addresses of the message.
  • the CPU is located in the tunnel establishment device, and is configured to receive the packet that needs to be encrypted, and detect whether the tunnel where the packet to be encrypted is located is established.
  • the tunnel establishment device is one or more service boards on the gateway, and the CPU is distributed on each service board. The number of CPUs and the number of service boards depend on the requirements of the gateway processing service.
  • FIG. 21 is a schematic structural diagram of a device for establishing a tunnel according to Embodiment 14 of the present invention. As shown in FIG. 21, the method includes:
  • the encrypted message receiving unit 101 is configured to receive a message that needs to be encrypted, and the message that needs to be encrypted is a message that is sent to a specified central processing unit CPU according to an allocation rule;
  • the first sending unit 201 is configured to: when the specified CPU detects that the tunnel where the packet is located, the IKE packet is sent to the interface board, and the tunnel negotiation is triggered.
  • the establishing unit 301 is configured to receive the IKE packet sent by the interface board according to the allocation rule, and establish the tunnel.
  • the allocation rule is specifically: sending, according to the CPU number obtained from the interface board, the message to the CPU corresponding to the CPU number, where the CPU number is passed by the interface board to the source and destination address of the message I calculated it.
  • the device may further include: a message receiving unit 401, configured to receive a message sent by the interface board according to the allocation rule.
  • the message receiving unit 401 is further configured to receive an IKE negotiation packet.
  • the tunneling device may further include: a security policy unit 501, configured to configure the security policy, maintain a data flow dynamically generated by the tunnel negotiation, and check whether the packet received by the packet receiving unit 401 needs to be encrypted.
  • a security policy unit 501 configured to configure the security policy, maintain a data flow dynamically generated by the tunnel negotiation, and check whether the packet received by the packet receiving unit 401 needs to be encrypted.
  • the tunneling device may further include:
  • the searching unit 601 is configured to search, in the security policy unit 501, a security policy that matches the packet, and obtain the packet that needs to be encrypted.
  • the obtaining unit 701 is configured to obtain a CPU number that receives the encrypted packet to be received;
  • a second sending unit 801 configured to acquire, by the searching unit 601, the packet that needs to be encrypted, And transmitting to the specified CPU corresponding to the CPU number acquired by the obtaining unit 701 according to the security policy.
  • the tunneling device is one or more service boards on the gateway, and the CPU is distributed on each service board.
  • the number of CPUs and the number of service boards are determined according to the requirements of the gateway processing service. .
  • the device for establishing a tunnel provided by the embodiment of the present invention can implement the IPsec service on the service board and perform IKE negotiation, which reduces the workload of the main control board, thereby improving the processing efficiency of the packet.
  • the allocation rule can implement IKE negotiation and equalization on different service boards, thereby improving the processing capability of the system IPsec service and IKE negotiation.
  • modules in the apparatus in the embodiments may be distributed in the apparatus of the embodiment according to the description of the embodiments, or may be correspondingly changed in one or more apparatuses different from the embodiment.
  • the modules of the above embodiments may be combined into one module, or may be further split into a plurality of sub-modules.
  • the storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), or a Random Acces Memory (RAM).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

报文处理方法、 装置和***
本申请要求于 2008 年 08 月 18 日提交中国专利局、 申请号为 200810142458. 5 , 发明名称为 "一种报文处理方法、 业务板、 接口板及网络 通信设备"， 2008年 09月 10日提交中国专利局、 申请号为 200810212182. 3、 发明名称为 "一种 IP安全业务的实现方法、 装置和通信设备" ， 2008年 12 月 18 日提交中国专利局、 申请号为 200810183551. 0、 发明名称为 "一种建 立隧道的方法、 ***和设备" ， 以及 2008年 9月 12 日提交中国专利局、 申 请号为 200810149594. 7、 发明名称为 "一种报文的转发方法、 装置和***" 的中国专利申请的优先权， 其全部内容通过引用结合在本申请中。 技术领域
本发明实施例涉及通信技术领域， 特别涉及一种报文处理方法、 装置和 ***。 背景技术
虚拟专用网 （Vi r tua l Pr iva te Network, 以下简称： VPN) 技术是指采 用隧道技术以及加解密、 身份认证等方法， 在公众网络上构建专用网络的技 术。 VPN技术具有节省成本、 安全性高、 扩展性强、 便于管理和实现全面控 制等优点， 是目前和今后企业网络发展的趋势。 VPN有别于传统网络， 它并 不实际存在， 而是利用现有公共网络， 通过资源配置而成的虚拟网络， 是一 种逻辑上的网络， VPN只为特定的企业或用户群体所专用， VPN不是一种简单 的高层业务， 而是建立专网用户之间的网络互联。 VPN 的隧道协议可包括第 二层隧道（ yer 2 tunnel ing Protocol , 以下简称： UTP )协议、 IP层协 议安全结构 ( Secur i ty Archi tec ture for IP network, 以下简称： IPSec ) 协议、 通用路由封装（ Gener ic Rout ing Encapsula t ion, 以下简称： GRE ) 协议等。 VPN的隧道协议在协议层采用了隧道（Tunne l )技术， 隧道是一 个虚拟的点对点的连接， 在实际中可以看成是仅支持点对点连接的虚拟接 口， 这个接口提供了一条通路使封装的数据报文能够在这个通路上传输， 并且在一个隧道的两端分别对数据报文进行封装及解封装。
在实现本发明的过程中， 发明人发现现有技术存在如下问题： 在应用上述 VPN的隧道协议实现 ^艮文处理的过程中， 通常采用多业务 板的分布式架构的方案， 在这种方案中， 隧道的协商建立及报文的处理皆 由该架构中的主控板来完成， 当隧道的协商建立次数和报文的数量增加 时， 会造成主控板的工作量增加， 从而降低整个架构的业务的吞吐量及报 文的处理效率。 发明内容
本发明实施例提供了一种报文处理方法、 装置和***， 从而提高业务 的吞吐量和 ^艮文的处理效率。
本发明实施例提供一种报文处理方法， 应用于多业务板的分布式架 构， 所述分布式架构包括主控板、 至少一个业务板和至少一个接口板， 其 特征在于， 包括：
确定接收到的报文对应的指定的 CPU , 由所述 CPU对应的业务板对接 收到的报文进行处理。
本发明实施例提供了一种接口板， 应用于包括主控板、 至少一个接口 板和业务板的***， 其特征在于， 包括：
报文下发单元， 用于根据主控板下发的配置 GRE路由信息， 将接收到 的第一报文发送到指定业务板；
报文转发单元， 用于接收所述业务板发送的封装处理后的第一报文， 并根据所述主控板下发的配置 GRE路由信息向外部转发所述封装处理后的 第一报文； 报文接收单元， 用于接收到外部发送的对所述封装处理后的第一报文 进行响应的第二报文， 根据配置的路由信息将所述第二报文发送到所述业 务板。
本发明实施例提供了一种报文处理***， 其特征在于， 包括主控板、 至少一个接口板和业务板；
所述主控板， 用于对封装报文所需要的信息和配置 GRE路由信息进行 下发；
所述接口板， 用于根据所述主控板下发的配置 GRE路由信息， 将接收 到的第一报文发送到所述业务板， 由所述业务板对所述第一报文进行封装 处理， 并接收所述业务板发送的封装处理后的第一报文， 并根据所述主控 板下发的配置 GRE路由信息向外部转发所述封装处理后的第一报文， 在接 收到外部发送的对所述封装处理后的第一报文进行响应的第二报文之后， 根据配置的路由信息将所述第二报文路由到所述业务板， 由所述业务板对 所述第二报文进行解封装处理；
所述业务板， 用于对所述接口板发送的报文进行封装和解封装处理。 本发明实施例提供了一种报文处理***， 包括多个业务板、 控制板及 接口板， 其中， 所述多个业务板， 用于建立与客户端之间的隧道， 存储所 述隧道的编号至与所述客户端建立隧道的业务板的 CPU, 并请求所述控制 板为所述客户端分配 IP地址；
所述控制板， 用于将所述隧道的编号、 处理所述隧道的当前业务板的
CPU 的编号及所述客户端的 IP地址的对应关系发送至所述接口板和所述 多个业务板；
所述接口板， 用于当接收到报文时查询所述报文的目的地址， 当查询 所述 ^艮文的目的地址为所述客户端的 IP地址时， 居所述客户端的 IP地 址对应的 CPU编号将所述 >¾文发送至与所述 CPU编号对应的业务板进行处 理。 本发明实施例提供了一种应用于分布式架构的业务板， 所述业务板与 控制板、 接口板通信连接， 用于接收所述控制板发送的与客户端建立的隧 道的编号、 处理所述隧道的 CPU编号及分配给所述客户端的 IP地址对应 关系， 并当接收报文后查询所述报文的目的地址， 及当查询所述报文的目 的地址为所述客户端的 IP地址时， 根据所述客户端的 IP地址对应的 CPU 编号将所述报文发送至与所述 CPU编号对应的业务板进行处理。
本发明实施例提供了一种应用于分布式架构的接口板， 所述接口板与 控制板、 多个业务板通信连接， 所述多个业务板用于建立与所述客户端之 间的隧道， 所述接口板用于接收所述控制板发送的与客户端建立的隧道的 编号、 处理所述隧道的 CPU编号及分配给所述客户端的 IP地址对应关系， 并当接收报文后查询所述报文的目的地址， 及当查询所述报文的目的地址 为所述客户端的 IP地址， 根据所述客户端的 IP地址对应的 CPU编号将所 述才艮文发送至与所述 CPU编号对应的业务板进行处理。
本发明实施例提供了一种报文处理装置， 包括： 第一 CPU获取单元和 第一 CPU; 其中
所述第一 CPU获取单元， 用于根据接收到的 IP报文， 获取对该 IP报 文进行 IP安全 IPSEC业务处理的第一 CPU;
所述第一 CPU, 用于对该 IP 文进行相应的 IPSEC业务处理并发送。 本发明实施例提供了一种报文处理***， 包括至少一个接口板和至少 两个 CPU;
所述接口板， 用于根据接收到的 IP报文， 获取对该 IP报文进行 IP 安全 IPSEC业务处理的第一 CPU;
所述第一 CPU, 用于对该 IP 文进行相应的 IPSEC业务处理并发送。 本发明实施例通过将接收到的报文在指定的 CPU对应的业务板中进行 处理， 可以使报文均勾的分布到各业务板中进行处理， 减轻了主控板的工 作量， 并大大提高了业务的吞吐量， 从而提高了整个架构的报文的处理效 附图说明
图 1为本发明实施例二提供的一种报文处理方法的流程图；
图 2为本发明实施例二中报文在设备中转发的数据流示意图； 图 3为本发明实施例二中报文的转发方法流程图；
图 4为本发明实施例二中报文的转发方法又一流程图；
图 5为本发明实施例三提供的一种接口板的结构示意图；
图 6为本发明实施例四提供的一种接口板的结构示意图；
图 7为本发明实施例五提供的一种报文处理***的结构示意图； 图 8为本发明实施例六提供的一种报文处理方法的流程图；
图 9为本发明实施例七提供的一种报文处理方法的流程图；
图 10为本发明实施例八提供的一种报文处理***的应用环境图； 图 11为本发明实施例八提供的一种报文处理***的结构图； 图 12为本发明实施例九提供的一种报文处理方法的流程图； 图 13为本发明实施例十提供的一种报文处理方法的流程图； 图 14为本发明实施例十提供的一种报文处理方法的示意图； 图 15为本发明实施例十一提供的一种报文处理装置的结构示意图； 图 16为本发明实施例十二提供的一种报文处理***的结构示意图； 图 17 为本发明实施例十二提供的一种报文处理***的工作流程示意 图；
图 18为本发明实施例十三提供的一种建立隧道的方法的流程图； 图 19为本发明实施例分布式架构中实现 IKE协商的简要流程图； 图 20为本发明实施例提供的 IKE协商的流程图；
图 21为本发明实施例十四提供的一种建立隧道的设备的结构示意图。 具体实施方式
下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进 行清楚、 完整地描述，显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没 有作出创造性劳动前提下所获得的所有其他实施例， 都属于本发明保护的 范围。
本发明实施例一提供了一种报文处理方法， 应用于多业务板的分布式 架构， 所述分布式架构包括主控板、 至少一个业务板和至少一个接口板， 该方法包括： 确定接收到的报文对应的指定的 CPU , 由所述 CPU对应的业 务板对接收到的报文进行处理。
本实施例通过将接收到的报文在指定的 CPU 对应的业务板中进行处 理， 可以使报文均勾的分布到各业务板中进行处理， 减轻了主控板的工作 量， 并大大提高了业务的吞吐量， 从而提高了报文的处理效率。
图 1为本发明实施例二提供的一种报文处理方法的流程图， 如图 1所 示， 该方法包括以下步骤：
51 01、 接口板根据主控板下发的配置通用路由封装 GRE路由信息， 将 接收到的第一报文发送到指定的业务板， 由所述业务板对所述第一报文进 行封装处理。
上述 GRE路由信息具体包括路由的下一跳、 出接口、 处理 GRE ^艮文的 CPU I D以及隧道的 I D等信息。
51 02、 所述接口板接收所述业务板发送的封装处理后的第一报文， 并 根据所述主控板下发的配置 GRE路由信息向外部转发所述封装处理后的第 一报文。 其中外部为第一报文待发送的目的地址。
51 03、 所述接口板接收到外部发送的对所述封装处理后的第一报文进 行响应的第二报文， 根据配置的路由信息将所述第二报文发送到所述业务 板， 由所述业务板对所述第二报文进行解封装处理。 其中外部为发送第二 才艮文的源地址。
通过本发明实施例， 实现了当大量的报文经过设备时， 接口板根据配 置的 GRE路由信息将不同的报文送到不同的业务板进行处理， 可以使报文 均匀的分布到各业务板中进行处理， 避免了大量报文同时送到主控板等待 处理， 提高了报文的处理效率。
本发明实施例二提供一种报文处理方法。 该方法应用在 GRE 隧道封 装业务中， 所封装的数据流是由隧道的源地址和目的地址决定的。 在主控 板配置 Tunne l 的同时， 将封装报文所需要的信息广播到所有的业务板， 这样， 接口板收到的报文， 无论送到哪个 CPU都可以正确的进行封装或者 解封装处理。 具体的， 本发明实施例中， 首先对给每个业务板上的 CPU编 号； 然后对 Tunne l的两端的 IP地址进行 ha sh, 根据 ha sh索引选择相应 的 CPU。 由于隧道两端的 IP地址是固定的， 使得不同 Tunne l加封装和反 向解封装的报文会根据 ha sh索引选择到不同的 CPU上处理， 这样实现了 进出隧道的才艮文由同一个 CPU处理的目的。
该方法中报文在设备中转发的数据流示意图如图 2所示， 其中， 0号 数据流为主控板下发到业务板的配置数据流； 1 号流为送到业务板进行加 封装的流； 2 号流为在业务板上封装后送到接口板的流。 3 号流为从接口 板送到业务板解封装的流； 4号流为报文在业务板解封装后转到接口板的 流。
在本发明实施例二中实现网络通信中报文的封装转发的流程图， 如图
3所示， 包括以下步骤：
S 30K 主控板的将封装报文所需要的相关信息广播至各个业务板。 其中，主控板在多业务板分布式架构的设备中， 负责所有的配置管理。 上述封装报文所需要的信息包括隧道的源地址、 目的地址、 Tunen l 接口的 IP地址、 检验和、 认证关键字等信息；
S 302、 主控板将配置的 GRE路由信息广播到业务板和接口板。 该步骤中， GRE路由信息除了路由的下一跳和出接口外， 还包括处理 GRE ^艮文的 CPU ID和隧道 ID。
5303、接口板接收报文，并根据报文的目的地址来确定如何路由此包。 该步骤中路由该数据包的方式包括：
( 1 ) 当报文的目的地址被发现要路由经过 Tunnel的出接口时， 接口 板根据配置的 GRE路由信息获得该报文对应的 CPUID, 并将报文送到对应 的 CPU所在的业务板进行处理；
( 2 ) 当报文是到本机的， 接口板根据报文的源地址和目的地址进行 hash, 计算出应该由哪个业务板对 文进行处理。 该过程实现了本步骤的 目的在于保证了同一个报文在同一个 CPU上进行处理， 避免了相同报文在 不同 CPU处理时因为查不到会话信息丟包， 同时避免了对所有报文都进行 hash计算 CPU所带来的转 CPU的麻烦。
5304、 业务板接收接口板发送的要路由经过 Tunnel 的出接口的报文 时， 查找该报文的路由， 并根据预先配置的 GRE路由信息确定该报文的出 接口， 下一跳以及要进哪个 Tunnel进行加封装等信息。
5305、 业务板根据预先配置的封装报文的相关信息对报文进行加封装 处理。
上述对 ^艮文进行加封装处理具体为将隧道的源地址、 目的地址和隧道 标识等信息添加到报文的头部。
S306、 业务板将封装后根据步骤 s304 中配置的报文的出接口、 下一 跳等信息的报文通过查路由确定接口和下一跳， 将封装后的报文后送到接 口板转发。
具体的将接收到的报文进行解封装的过程， 如图 4所示， 具体为： S401、 接口板收到本机的 文后， 对^艮文的源地址和目的地址进行 hash,根据 hash索引选择相应的 CPU, 并将该报文发送到 CPU对应的业务 板上。 54 02、 业务板根据所保存的配置信息对接收到的报文进行解封装。 其中， 配置信息具体为道的源地址、 目的地址、 Tunen 1接口的 I P地 址和隧道标识等信息。
上述解封装过程具体包括： 首先判断 GRE协议报文的源地址、 目的地 址和隧道标识是否为该隧道的源地址、 目的地址和隧道标识。 如果是， 则 将 GRE协议 文的源地址、 目的地址和隧道标识去掉； 否则， 丟弃该 GRE 协议报文。
54 03、 报文解封装后直接在该业务的 CPU上进行处理。
通过上述步骤， 实现了在复杂的多业务板多核环境中的负载分流。 通过本发明实施例二提供的方法， 避免了大量报文同时送到主控板等 待处理， 提高了处理效率、 节省了主控板的 CPU资源。 并且 GRE报文进出 隧道在同一个 CPU进行处理， 保持了会话信息的一致性。
图 5为本发明实施例三提供的一种接口板的结构示意图，如图 5所示， 该接口板应用于包括主控板、 至少一个接口板和业务板的***， 包括： 报 文下发单元 1 0、 报文转发单元 2 0以及报文接收单元 30 ;
所述报文下发单元 1 0 , 用于根据主控板下发的配置通用路由封装 GRE 路由信息， 将接收到的第一报文发送到指定业务板；
所述报文转发单元 20 ,用于接收所述业务板发送的封装处理后的第一 报文， 并根据所述主控板下发的配置 GRE路由信息向外部转发所述封装处 理后的第一 4艮文；
所述报文接收单元 30 ,用于接收到外部发送的对所述封装处理后的第 一报文进行响应的第二报文， 根据配置的路由信息将所述第二报文发送到 所述业务板；
图 6为本发明实施例四提供的一种接口板的结构示意图，如图 6所示， 在实施例三的基础上， 所述报文下发单元 1 0还包括： 第一报文下发子单 元 1 1和第二报文下发子单元 1 2 ; 第一报文下发子单元 1 1 ,用于当所述接口板发现接收到的第一报文是 要路由经过隧道 Tunne 1 的出接口时， 所述接口板根据配置的 GRE路由信 息获得所述第一报文对应的 CPU I D , 并将所述第一报文发送到业务板。
第二报文下发子单元 1 2 ,用于当所述接口板发现接收到的第一报文是 到本机的报文时， 所述接口板根据所述第一报文的源地址和目的地址进行 ha sh , 计算处理所述第一 文的业务板并发送所述第一 ^艮文。
图 7为本发明实施例五提供的一种报文处理***的结构示意图， 如图 7所示， 包括主控板 40、 至少一个接口板 50和业务板 6 0 ;
所述主控板 40 ,用于对封装报文所需要的信息和配置 GRE路由信息进 行下发；
所述接口板 5 0 , 用于根据所述主控板 4 0下发的配置 GRE路由信息， 将接收到的第一报文发送到所述业务板 60 , 由所述业务板 60对所述第一 报文进行封装处理， 并接收所述业务板 60发送的封装处理后的第一报文， 并根据所述主控板 40下发的配置 GRE路由信息向外部转发所述封装处理 后的第一报文， 在接收到外部发送的对所述封装处理后的第一报文进行响 应的第二报文之后， 根据配置的路由信息将所述第二报文路由到所述业务 板 60 , 由所述业务板 60对所述第二报文进行解封装处理；
所述业务板 60 , 用于对所述接口板 50发送的报文进行封装和解封装 处理。
通过使用本发明实施例提供的设备和***， 可以使报文均匀的分布到 各业务板中进行处理， 避免了大量报文同时送到主控板等待处理， 提高了 转发效率、节省了主控板的 CPU资源。并且 GRE 文进出隧道在同一个 CPU 进行处理， 保持了会话信息的一致性。
图 8为本发明实施例六提供的一种报文处理方法的流程图， 如图 8所 示，在本实施例六中，所述方法应用于多业务板的分布式架构的网络设备， 在该分布式架构中， 包括主控板、 接口板和多个业务板， 主控板连接于接 口板和该多个业务板， 接口板与该多个业务板分别连接。 该分布式架构的 网络设备外接于客户端及网络。
步骤 S800 , 当客户端发起连接请求时， 通过接口板选择业务板， 协商 建立该客户端与该业务板的 L2TP 隧道。 在本实施例六中， 客户端向接口 板发送一个连接请求的协商报文， 接口板根据该协商报文中的源地址和目 的地址进行 HASH运算来选择多个业务板中的一个业务板， 之后， 该业务 板协商建立该客户端与该业务板的 L2TP 隧道。 在本实施例六中， 该连接 请求的协商 ^艮文中的目的地址为隧道两端的 IP地址， 接口板可根据该隧 道两端的 IP地址可查询处理该客户端的发送的报文的业务板， 从而业务 板与客户端协商建立该 IP地址对应的隧道。
步骤 S802 , 当该 L2TP隧道建立后， 将该隧道对应的编号存储至该业 务板的 CPU中， 并请求主控板为该客户端分配 IP地址， 及将分配后的 IP 地址及隧道的编号返回客户端。 在本实施例六中， 当业务板成功建立该 IP 地址对应的隧道后， 会对该隧道进行编号。
步骤 S804 , 通过主控板将该隧道的编号、处理该隧道的 CPU编号及该 客户端的 IP地址的对应关系发送至接口板和所有的业务板。
步骤 S806 , 当接口板接收到报文后， 经由接口板查询该报文的目的地 址，或当其它业务板接收到报文后，经由该业务板查询该报文的目的地址。 在本实施例六中， 当客户端与业务板建立 L2TP 隧道后， 接口板可能接收 到客户端发送至网络的需进行 L2TP解封装的报文， 则其目的地址为该隧 道的 IP地址，也有可能接收网络反馈至客户端的需进行 L2TP封装的报文， 则其目的地址为客户端的 IP地址。 同时， 其它业务板接收到的报文有可 能是网络反馈至客户端的报文， 则其目的地址为客户端的 IP地址。 在本 实施例六中，其它业务板接收到报文后，可能会处理该报文的 NAT( Ne twork Addres s Trans l a t ion , 网络地址转换） 业务， 也有可能处理其它业务， 该其它业务不包括 L2TP解封装和 L2TP封装业务。 当该其它业务板处理完 该业务后， 进行处理 L2TP封装时， 需查询该报文的目的地址。 步骤 S808 , 若查询该报文的目的地址为该客户端的 IP地址， 则根据 该客户端的 IP地址对应的 CPU编号将该报文发送至与该 CPU编号对应的 业务板进行 L2TP封装处理， 或若查询该报文的目的地址为建立该业务板 与客户端的隧道的 IP地址时， 则将所述报文发送所述隧道对应的当前业 务板进行 L2TP解封装处理。 在本实施例六中， 根据报文的源地址和目的 地址进行 HASH运算来查询处理该 文的业务板， 此时， 根据 >¾文的源地 址和目的地址进行 HASH 运算来查询处理该 文的业务板的步骤与步骤 S800—样， 当查询业务板后， 业务板从该报文的头部信息中获取该隧道的 编号， 从而选择该隧道的编号对应的 CPU进行 L2TP解封装处理， 即根据 该才艮文的隧道两端的 IP地址找出相应的业务板， 此时， 该^艮文的隧道两 端的 IP地址为步骤 S800中协商建立过程中的隧道两端的 IP地址。
在本实施例六中， 若接口板查询接收到的报文的目的地址为该客户端 的 IP地址或若其它业务板查询接收到的该报文的目的地址为该客户端的 IP地址， 则根据该客户端的 IP地址对应的 CPU编号将该报文发送至与该 CPU编号对应的业务板进行 L2TP封装处理；或若接口板查询该报文的目的 地址为隧道的 IP地址， 则根据报文的源地址和目的地址进行 HASH运算来 查询处理该报文的业务板， 进行 L2TP解封装处理。
步骤 S810 , 经由接口板发送处理完的报文。 在本实施例六中， 经由接 口板将 L2TP封装后的报文发送至该 IP地址对应的该客户端， 或经由接口 板将 L2TP解封装后的报文发送至网络。
本发明实施例六提供的报文处理方法， 通过当前业务板与客户端协商 建立隧道， 并将该隧道的编号、 该业务板的 CPU编号及该客户端的 IP地 址的对应关系发送至接口板及所有的业务板， 当接口板或其它业务板接收 需发送至客户端的报文时， 通过该对应关系将该报文发送至该隧道编号对 应的当前业务板的 CPU进行 L2TP封装， 当接口板接收需发送至网络的报 文时， 通过该报文的隧道的 IP地址来查询之前协商建立该隧道的当前业 务板， 及将该报文发送至当前业务板的 CPU进行 L2TP解封装处理， 从而 确保将同一客户端的需进行 L2TP封装和 L2TP解封装的报文在同一个业务 板的 CPU 中进行相应处理， 减轻了主控板的工作量， 并大大提高了 L2TP 业务的吞吐量， 从而提高了整个架构的报文的处理效率。
图 9为本发明实施例七提供的一种报文处理方法的流程图， 如图 9所 示， 该方法包括：
步骤 S900 ,根据客户端发送的 IPSEC报文协商建立客户端与业务板的 IPSEC隧道。
步骤 S902 , 根据 IPSEC报文的 L2TP报文协商建立该客户端与该业务 板的 L2TP隧道。
步骤 S904、 S906、 S908与图 8的步骤 S802、 S804、 S806的描述一致。 步骤 S910 , 若查询该报文的目的地址为该客户端的 IP地址， 则根据 该客户端的 IP地址对应的 CPU编号将该报文发送至与该 CPU编号对应的 业务板先进行 L2TP封装处理再进行 IPSEC加密处理， 或若查询该 文的 目的地址为建立该业务板与客户端的隧道的 IP地址， 则将所述报文发送 所述隧道对应的业务板先进行 IPSEC解密处理再进行 L2TP解封装处理。 在本实施例七中， 根据报文的源地址和目的地址进行 HASH运算来查询处 理该报文的业务板， 此时， 根据报文的源地址和目的地址进行 HASH运算 来查询处理该 文的业务板的步骤与步骤 S902 —样， 当查询业务板后， 业务板从该报文的头部信息中获取该隧道的编号， 从而选择该隧道的编号 对应的 CPU进行客户端的 IP地址对应的 CPU编号将该报文发送至该 CPU 编号对应的业务板先进行 IPSEC解密处理再进行 L2TP解封装处理， 即根 据该 ^艮文的隧道两端的 IP地址找出相应的业务板， 此时， 该 ^艮文的隧道 两端的 IP地址为步骤 S902中协商建立过程中的隧道两端的 IP地址。
在本实施例七中， 若接口板查询接收到的报文的目的地址为该客户端 的 IP地址或若该其它业务板查询接收到的该报文的目的地址为该客户端 的 IP地址， 则根据该客户端的 IP地址对应的 CPU编号将该报文发送至与 该 CPU编号对应的业务板进行处理； 或若接口板查询该报文的目的地址为 隧道的 IP地址， 则根据报文的源地址和目的地址进行 HASH运算来查询处 理该报文的业务板进行处理。在本实施例七中，其它业务板接收到报文后， 可能会处理该才艮文的 NAT ( Network Addres s Trans la t i on , 网络地址转换） 业务， 也有可能处理其它业务， 该其它业务不包括 L2TP解封装、 L2TP封 装、 IPSEC解密、 IPSEC加密业务。 当该其它业务板处理完该业务后， 进 行处理 L2TP封装时， 需查询该 >¾文的目的地址。
步骤 S912 ,发送处理完的报文。在本实施例七中， 经由接口板将 L2TP 封装及 IPSEC加密后的报文发送至该 IP地址对应的该客户端， 或经由接 口板将 IPSEC解密及 L2TP解封装后的报文发送至网络。
本发明实施例七提供的报文处理方法， 通过当前业务板与客户端协商 建立隧道， 并将该隧道的编号、 该业务板的 CPU编号及该客户端的 IP地 址的对应关系发送至接口板及所有的业务板， 当接口板或其它业务板接收 需发送至客户端的报文时， 通过该对应关系将该报文发送至该隧道编号对 应的当前业务板的 CPU先进行 L2TP封装处理再进行 IPSEC加密处理， 当 接口板接收需发送至网络的报文时， 通过该报文的隧道的 IP地址来查询 之前协商建立该隧道的当前业务板， 及将该报文发送至当前业务板的 CPU 先进行 IPSEC解密处理再进行 L2TP解封装处理， 从而确保将同一客户端 的需进行 L2TP封装、 IPSEC加密、 L2TP解封装及 IPSEC解密的 文在同 一个业务板的 CPU中进行相应处理， 减轻了主控板的工作量， 并大大提高 了 L2TP及 IPSEC业务的吞吐量， 从而提高了 L2TP+IPSEC组网的 文的处 理效率。
图 10 为本发明实施例八提供的一种报文处理***的应用环境图。 在 本实施例中， 报文处理*** 3与多个客户端 5、 及网络 4通信相连， 网络 4 包括内部网络 400和外部网络 41 0 , 内部网络 400为企业的内部网络， 外部网络 41 0为非企业的内部网络。 在本实施例中， 客户端 5发送的报文 有可能为访问企业的内部网络的报文， 也有可能为访问非企业的内部网络 的报文。
图 1 1 为本发明实施例八提供的一种报文处理***的结构图。 在本实 施例中， 报文处理*** 3包括接口板 300、 主控板 31 0、 第一业务板 321、 第二业务板 322 第 N业务板 32N , 报文处理*** 3用于将接口板 300 接收的网络发送至客户端的需进行 L2TP封装及客户端发送至网络的需进 行 L2TP解封装的^艮文在同一个业务板的 CPU中进行处理。 在本实施例中， 第一业务板 321、 第二业务板 322 第 N业务板 32N的功能结构相同， 为使描述简便， 以第一业务板 321为例进行描述。
接口板 300用于根据客户端发起的连接请求选择 N个业务板中的一个 业务板。 在本实施例中， 接口板 300选择第一业务板 321。
第一业务板 321用于协商建立该第一业务板 321与客户端的 L2TP隧 道， 并存储建立后的 L2TP 隧道的编号于内部的 CPU , 及请求主控板 31 0 为客户端分配 I P地址， 并将分配后的 IP地址返回客户端。
第一业务板 321还用于将该隧道的编号、 及处理该隧道的 CPU编号及 分配给该客户端的 IP地址发送至主控板 31 0。
主控板 31 0用于将第一业务板 321发送的该隧道的编号、 及处理该隧 道的 CPU编号及分配给该客户端的 I P地址的对应关系发送至主控板 31 0 及第一业务板 321、 第二业务板 322 第 N业务板 32N。
接口板 300还用于当接收客户端或网络发送的报文时， 查询该报文的 目的地址。 在本实施例中， 当查询该报文的目的地址为该客户端的 IP地 址时， 即该报文为网络发送至客户端的报文， 接口板 300根据该 IP地址 对应的 CPU编号将该^艮文发送至与该 CPU编号对应的业务板进行 L2TP封 装处理， 即发送至第一业务板 321进行 L2TP封装处理； 当查询该报文的 目的地址为建立该业务板与客户端之间隧道的 IP地址时， 接口板 300将 所述报文发送所述隧道对应的业务板进行进行 L2TP解封装处理， 即发送 至第一业务板 321进行 L2TP解封装处理。
第二业务板 322 第 N业务板 32N中的任何一个业务板还用于当 接收到报文后， 查询该报文的目的地址。 在本实施例中， 第二业务板
322 第 N业务板 32N中的任何一个业务板接收到报文后， 可能会处 理该报文的 NAT ( Network Addres s Trans la t ion, 网络地址转换） 业务， 也有可能处理其它业务，该其它业务不包括 L2TP解封装、 L2TP封装、 IPSEC 解密、 IPSEC加密业务。 当第二业务板 322 第 N业务板 32N中的任 何一个业务板处理完该业务后， 进行处理 L2TP封装时， 需查询该>¾文的 目的地址。
在本实施例中， 当查询该^艮文的目的地址为该客户端的 IP地址时， 即该报文为网络发送至客户端的报文， 该处理 NAT业务的报文的业务板根 据该 IP地址对应的 CPU编号将该^艮文发送至与该 CPU编号对应的业务板 进行 L2TP封装处理， 即发送至第一业务板 321进行 L2TP封装处理。
接口板 300还用于发送第一业务板 321处理完后的报文。 在本实施例 中， 接口板 300将第一业务板 321进行 L2TP封装处理后的报文发送至客 户端， 或将第一业务板 321进行 L2TP解封装处理后的报文发送至网络。
在本实施例中， 第一业务板 321还用于根据客户端发送的 IPSEC报文 协商建立客户端与该业务板的 IPSEC隧道， 并根据 IPSEC报文的 L2TP报 文协商建立该客户端与该业务板的 L2TP隧道。
在本实施例中， 接口板 300还用于当查询该报文的目的地址为该客户 端的 I P地址时， 即该报文为网络发送至客户端的报文， 根据该 I P地址对 应的 CPU编号将该^艮文发送至与该 CPU编号对应的业务板先进行 L2TP封 装处理再进行 IPSEC加密处理， 即发送至第一业务板 321先进行 L2TP封 装处理再进行 IPSEC加密处理； 若查询该^艮文的目的地址为建立该业务板 与客户端之间隧道的 IP地址时， 接口板 300将所述报文发送所述隧道对 应的业务板先进行 IPSEC解密处理再进行 L2TP解封装处理， 即发送至第 一业务板 321先进行 IPSEC解密处理再进行 L2TP解封装处理。
在本实施例中， 第二业务板 322 第 N业务板 32N中的任何一个业 务板还用于当查询该报文的目的地址为该客户端的 I P地址时，即该报文为网 络发送至客户端的，该业务板根据该 IP地址对应的 CPU编号将该报文发送至 与该 CPU编号对应的业务板先进行 L2TP封装处理再进行 IPSEC加密处理，即 发送至第一业务板 321先进行 L2TP封装处理再进行 IPSEC加密处理。
接口板 300还用于将第一业务板 321进行 L2TP封装及 IPSEC加密处理后 的报文发送至客户端，或将第一业务板 321进行 IPSEC解密及 L2TP解封装处 理后的报文发送至网络。
本发明实施例提供的报文处理***， 通过当前业务板与客户端协商建 立隧道， 并将该隧道的编号、 该业务板的 CPU编号及该客户端的 IP地址 的对应关系发送至接口板及所有的业务板， 当接口板或其它业务板接收需 发送至客户端的报文时， 通过该对应关系将该报文发送至该隧道编号对应 的当前业务板的 CPU先进行 L2TP封装处理再进行 IPSEC加密处理， 当接 口板接收需发送至网络的报文时， 通过该报文的隧道的 IP地址来查询之 前协商建立该隧道的当前业务板， 及将该报文发送至当前业务板的 CPU先 进行 IPSEC解密处理再进行 L2TP解封装处理， 从而确保将同一客户端的 需进行 L2TP封装、 IPSEC加密、 L2TP解封装及 IPSEC解密的报文在同一 个业务板的 CPU中进行相应处理， 减轻了主控板的工作量， 并大大提高了 L2TP及 IPSEC业务的吞吐量， 从而提高了 L2TP+IPSEC组网的 ^艮文的处理 效率。
图 12为本发明实施例九提供的一种报文处理方法的流程图，该方法基于 至少两个 CPU, 如图 12所示， 该方法具体包括如下步骤：
步骤 S 1201、 接口板根据接收到的 I P报文， 从至少两个 CPU中获取对该 IP报文进行 IP安全 IPSEC业务处理的第一 CPU;
其中该第一 CPU为指定的 CPU;
步骤 S1202、 所述第一 CPU对该 IP 文进行相应的 IPSEC业务处理并发 送。
本发明实施例九提供的技术方案，通过 IP报文获取实现该 IP报文 IPSEC 业务的第一 CPU, 将 IP >¾文对应于相应的 CPU, 由该 CPU实现对该 IP 文的 IPSEC 业务， 减轻了主控板的工作量， 从而提高了报文的处理效率； 利用不 同的 CPU实现了 IP报文的负载分流， 解决了现有技术中因无法对具有多 CPU 的高端 VPN设备， 实现 IPSEC业务带来的问题， 从而能够在包含多个 CPU的 VPN设备中实现 IPSEC业务。
下面对本发明实施例十提供的报文处理方法进行具体说明。
在本发明实施例中采用了 "第一" 、 "第二" 等字样， 用于对一条 IP报 文进行处理时， 起不同作用的 CPU进行区分， 并不在数量上进行限定。 下文 将对第一 CPU和第二 CPU的具体功能进行介绍。
作为 VPN设备上的物理实体， 下述的第一 CPU和第二 CPU并没有实质上 的区别， 可以为业务板上的任一个 CPU, 以下皆同， 不再赘述。
图 13为本发明实施例十提供的一种报文处理方法的流程图，该方法基于 至少两个 CPU, 如图 13所示， 该方法具体包括如下步骤：
步骤 S 1301： 接口板根据接收到的 I P报文， 从至少两个 CPU中获取对该 IP报文进行 IP安全 IPSEC业务处理的第一 CPU。
为了便于清楚说明， 在本发明实施例十中， 如图 14所示， 包括业务板一 至四， 接口板一和二， 但不限于此， 可以包括一个业务板， 该业务板上包括 多个 CPU; 或者， 也可以包括多个业务板， 上述 CPU分布于多个业务板之上， 接口板可以为一个或者多个，下面以接口板一或接口板二作为上述 IP报文的 入口为例进行说明， 具体分为两种情况：
第一种情况： 上述 IP报文为需加封装的 IP报文， 具体包括： 步骤 S1301A: 接口板根据所述需加封装的 IP报文， 获取第二 CPU。
接口板一为上述需加封装的 IP报文（ IP报文 1 )的入口， 接口板一接收 来自数据发送客户端的 IP报文，该 IP报文携带有 IP报文数据发送客户端和 数据接收客户端的源和目的 IP地址， 在本发明实施例十中，接口板一根据该 IP报文中携带的源和目的 IP地址获取第二 CPU, 处理的方式如下：
本发明实施例十首先对上述 ip 报文携带的源和目的 ip 地址进行哈希
(HASH) 变换， 获取上述 IP报文的 HASH索引值， 优选的， 本发明实施例十 采用的 HASH变换方法包括如下步骤：
步骤 S1301a、 将上述的源 IP 地址 （ Souncelp ) 和目的 IP 地址 ( Destinationlp ) 之和右移 16 位， 获取第一参数 XI , 即 Xl= ( Souncelp+Destinationlp ) &16;
将上述的 Souncelp 和 Destinationlp之和与 1进行与运算， 获取第二 参数 X2, 即 X2 = (Sourcelp+Destinationlp) & OxFFFF;
步骤 S1301b、 将上述第一参数 XI和第二参数 X2进行或运算， 获取第三 参数 X3, 即 X3 = Χ1ΛΧ2;
步骤 S1301c、 将上述第三参数 X3右移 1位， 将移位后获取的数值的后 6 位与 1进行与运算， 获取第四参数 X4, 即 X4 = (X3»l) & 0x3F。
将通过上述步骤 S1301a至 S1301c获取的第四参数 X4, 作为该 IP报文 的 HASH索引值。
然后， 将上述 IP报文的 HASH索引值对应于各业务板上不同的 CPU, 从 而根据上述需加封装的 IP报文， 可以获取到相应的第二 CPU。
上述获取的 HASH索引值， 即第四参数的取值范围通常为 0至 63, 以图
14 中给出的四个业务板， 每个业务板上包括两个 CPU为例说明 IP报文和第 二业务板的对应关系。
可以采用多种方法将上述 IP报文对应于相应的第二 CPU, 从而根据上述
IP报文获取业务板上的第二 CPU, 优选的， 本发明实施例十提供的方法如下： 业务板上的每个 CPU都可以作为第二 CPU, 将 IP报文转发至相应的第一 CPU, 并且所转发的 IP报文的数据量也是任意的， 为了充分利用分布式多业 务板包含多个 CPU的优势， 提高 IPSEC业务的处理效率， 优选的， 本发明实 施例二将 HASH索引值按照 IP报文的数据量平均对应于各 CPU, 为了便于理 解， 现简化说明如下：
例如， 为每个 CPU设置一个编号， 当网络中需要处理的不同的 IP报文共 有 160条时， 根据该 IP报文获取到 160个不同的 HASH索引值， 范围处于为 0至 63之间。 四个业务板中包括了 8个 CPU, 对该 CPU的编号为 1至 8 , 业 务板一上为 CPU1和 CPU2 , 业务板二上为 CPU3和 CPU4 , 业务板三上为 CPU5 和 CPU6 , 业务板四上为 CPU7和 CPU8。
可以将上述的取值范围 0至 63平均分为 8个子范围，每个子范围的取值 范围依次为 0至 7 , 8至 15 , 16至 23 , 24至 31 , 31至 38 , 39至 46 , 47至 55 , 56至 63 , 将这 8个子范围对应的 HASH索引值分别对应至 CPU1至 CPU8。
但不限于此， 例如， 当某个范围内的 HASH索引值对应的 IP报文较多时， 若在上述的 160条 IP报文中， 获取到 60条 IP报文的 HASH索引值取值范围 都在 24至 31之间， 则可将该范围内 HASH索引值对应的 IP报文对应在两个 或多个 CPU上， 以保证充分利用每个 CPU, 提高 VPN设备的数据处理性能。
当接口板一接收到来自数据发送客户端的 IP报文， 先根据该 IP报文中 的源和目的 IP, 获取该 IP报文的 HASH索引值， 根据该 HASH索引值通过上 述的对应关系， 即可获取该 IP报文对应的第二 CPU。
图 14中虚线所示为 IP报文 1 ,接口板一接收到该 IP报文 1后， 对该 IP 报文 1的源和目的 IP进行 HASH变换， 获得 HASH索引值， 利用该 HASH索引 值通过上述的对应关系获取第二 CPU为业务板四上的 CPU8 ,接口板一将该 IP 报文 1发送给 CPU8。
步骤 S1301B: 所述第二 CPU利用访问控制列表 ACL对该 IP报文进行匹 配， 获取所述第一 CPU。 第二 CPU, 用于将来自接口板的 IP报文， 进行 ACL匹配， 匹配成功时， 将该 IP报文发送给实现 IPSEC业务的 CPU, 该 CPU即为第一 CPU; 匹配失败 时， 将该 IP报文发送给接口板， 直接发送。 其中， 匹配失败时的处理情况与 本发明关系不大， 不再描述。
本发明实施例十利用了包括多个 CPU的 VPN设备， 数据量处理能力强的 特点， 在多个 CPU之间对 IP报文采用了一种负载分流的技术， 即由上述第二 CPU将 IP报文与预先设置的不同 ACL数据进行匹配， 根据匹配结果， 当需要 进行 IPSEC业务处理时，获取执行该 IP >¾文对应的 IPSEC业务的 CPU,该 CPU 即为该 IP报文的第一 CPU。 对不需要进行 IPSEC业务处理的 IP报文，直接将 该 IP ^Jl发送出去。
如图 14所示， 第二 CPU ( CPU8 )将 IP报文 1与其上已配置的 ACL数据 进行匹配， 根据匹配结果， 可以判断出该 IP报文 1是否需要进行 IPSEC业务 处理， 当需要进行 IPSEC业务处理时， 根据 ACL的配置， 能够获取出对该 IP 报文 1进行 IPSEC业务处理的第一 CPU。
上述 ACL数据的配置可以由主控板来实现。
第二种情况、 上述 IP报文为需解封装的 IP报文， 具体包括：
步骤 S1301C: 对所述需解封装的 IP 文中携带的 IPSEC隧道两端的 IP 地址进行哈希变换， 获取哈希索引值；
仍以图 14所示为例进行说明，其中接口板二作为需解封装的 IP报文（ IP 报文 2 ) 的入口， 接口板二接收 IP报文 2 , 该 IP报文 2中封装了 （包括 ESP 封装或 /和 AH封装）其所处 IP隧道两端的 IP地址。 对该 IP隧道两端的 IP 地址进行哈希变换， 获取哈希索引值的方法参见上述步骤 S1301a 至步骤 S1301c。
步骤 S1301D: 根据所述哈希索引值获取所述第一 CPU。
由于预先主控板对各 CPU的数据配置， 当采用 IP报文所处的 IP隧道两 端的地址作为上述 HASH变换的源和目的地址时， 根据获取到的 HASH索引值 可直接获取到实现该 IP报文的 IPSEC业务的第一 CPU。
下面对主控板预先对各 CPU进行数据配置的方法进行说明。 在上述步骤 S1301之前还包括：
步骤 S1300: 主控板预先对 CPU进行数据配置， 包括：
步骤 S1300A: 主控板为所述 IP 文分配相应的第一 CPU;
在本发明实施例十中， 主控板根据 IP 文所处 IP隧道两端的地址为该 IP报文分配相应的第一 CPU。 上述 IP报文包括需加封装的 IP报文和需解封 装的 IP报文。
主控板对上述 IP隧道两端的地址进行 HASH变换， 获取哈希索引值， 将 所述 IP报文的哈希索引值对应于所述 CPU, 具体方法参见上述步骤 S1301a 至步骤 S1301 c。 这种方法保证了处于同一 IP隧道的 IP报文能被送至同一个 CPU进行 IPSEC业务处理， 即对同一条 IP隧道中的 IP 4艮文进行加封装和解 封装的处理的是同一个 CPU。
步骤 S1300B: 主控板对所述 IP 文对应的第一 CPU进行相应的 ACL配 置， 并将实现该 IP报文相应 IPSEC业务所需的数据， 发送给该第一 CPU。
为 IP报文分配完 CPU之后， 主控板根据 IP报文与 CPU的对应关系， 进 行 ACL配置， 该 ACL配置表明了处理同一 IP隧道中的 IP才艮文的第一 CPU。 主控板将 ACL数据配置广播给业务板中的各 CPU, 同时将执行相应的 IPSEC 业务所需的数据也发送给已确定的各相应 CPU。
由上所述， 对于需加封装的 IP报文， 首先由接口板根据其源和目的 IP 地址获取到第二 CPU, 该第二 CPU根据主控板为其配置的 ACL数据， 对该 IP 报文进行 ACL匹配， 根据匹配结果将该 IP报文发送给第一 CPU。 由于主控板 对 CPU进行 ACL数据配置时， 是根据 IP报文所处 IP隧道两端的 IP地址， 并 且对需解封装的 IP报文是直接根据 IP隧道两端的 IP地址获取第一 CPU, 从 而保证了对同一条 IP隧道中的 IP报文进行加封装和解封装的处理的是同一 个 CPU。 上述主控板进行 CPU分配， 配置 ACL及向 CPU发送执行相应的 IPSEC业 务所需的数据的步骤， 可以根据 IP报文的变化等因素， 周期性的或根据需要 发送控制命令进行， 例如， 当报文的客户端或服务器的 IP地址发生了变动、 或有新的 IP报文需要进行 IPSEC业务处理时，可以再次进行上述配置等步骤。
如图 14所示，主控板通过数据流 1 ,将上述 ACL配置和执行相应的 IPSEC 业务所需的数据发送给业务板一至四。
由上所述， 第二 CPU, 即业务板四中的 CPU8 , 将 IP报文 1与配置的 ACL 进行匹配， 判断出该 IP报文 1需要进行加封装的 IPSEC业务处理， CPU8根 据相应的 IPSEC业务与处理该业务的 CPU的对应关系，找出进行加封装 IPSEC 业务处理的 CPU为业务板一上的 CPU1 , 即该 IP报文 1的执行 CPU为 CPU1。
步骤 S1302: 所述第一 CPU对该 IP 文进行相应的 IPSEC业务处理并发 送。
对于需加封装的 IP报文， 该第一 CPU对其进行加封装处理； 对于需解封 装的 IP报文， 该第一 CPU对其进行解封装处理。
本发明实施例十通过采用负载分流技术，使多个 CPU分别承载不同的 ACL 数据流和不同 IP报文的 IPSEC业务处理，并通过建立 IP报文与处理该 IP报 文的 IPSEC业务的 CPU的对应关系，使各 CPU对 IP报文的数据处理处于一种 均匀的状态， 并且保证了同一个 CPU处理同一条 IP隧道中的 IP报文， 提高 了整机的 VPN业务处理性能， 包括 IPSEC每秒新建隧道数量， 最大并发隧道 数量， 加解密吞吐量等大大提升。
本发明实施例十提供的技术方案，通过 IP报文获取实现该 IP报文 IPSEC 业务的第一 CPU, 将 IP >¾文对应于相应的 CPU, 由该 CPU实现对该 IP 文的 IPSEC 业务， 减轻了主控板的工作量， 从而提高了报文的处理效率； 利用不 同的 CPU实现了 IP报文的负载分流， 解决了现有技术中因无法对具有多 CPU 的高端 VPN设备， 实现 IPSEC业务带来的问题， 从而能够在包含多个 CPU的 VPN设备中实现 IPSEC业务。 本发明实施例十一还提供了一种报文处理装置， 如图 15所示， 包括： 第 一 CPU获取单元 41和第一 CPU42; 其中
所述第一 CPU获取单元 41 , 用于根据接收到的 IP报文， 获取对该 IP报 文进行 IP安全 IPSEC业务处理的第一 CPU,
所述第一 CPU42 , 用于对该 IP 文进行相应的 IPSEC业务处理并发送。 所述 IP报文包括需加封装的 IP报文和需解封装的 IP报文， 当该 IP报 文为需解封装的 IP报文时， 所述第一 CPU获取单元 41还包括：
第二 CPU获取模块， 用于根据所述需加封装的 IP报文， 获取第二 CPU, 该第二 CPU利用访问控制列表 ACL对该 IP报文进行匹配，获取所述第一 CPU。
当该 IP报文为需解封装的 IP报文， 所述第一 CPU获取单元， 还包括： 计算模块， 用于对所述需解封装的 IP报文中携带的 IPSEC 隧道两端的 IP地址进行哈希变换， 获取哈希索引值；
获取模块， 根据所述哈希索引值获取所述第一 CPU。
在本发明实施例十一中， 上述第一 CPU获取单元 41可以由接口板实现， 上述第一 CPU42可以为业务板上的任一 CPU。
本发明装置实施例中各功能模块的具体工作方式参见本发明方法实施例。 本发明实施例十一提供的技术方案， 通过 ip报文获取实现该 ip 报文
IPSEC业务的第一 CPU, 将 IP ^艮文对应于相应的 CPU, 由该 CPU实现对该 IP 报文的 IPSEC业务， 减轻了主控板的工作量， 从而提高了报文的处理效率； 利用不同的 CPU实现了 IP报文的负载分流，解决了现有技术中因无法对具有 多 CPU的高端 VPN设备， 实现 IPSEC业务带来的问题， 从而能够在包含多个
CPU的 VPN设备中实现 IPSEC业务。
本发明实施例十二还提供一种报文处理***， 如图 16所示， 包括至少一 个接口板和至少两个 CPU ,
所述接口板 51 , 用于根据接收到的 IP报文， 获取对该 IP报文进行 IP 安全 IPSEC业务处理的第一 CPU; 所述第一 CPU52 , 用于对该 IP 文进行相应的 IPSEC业务处理并发送。 进一步的， 该报文处理***还包括：
主控板 53 , 用于为所述 IP 文分配相应的第一 CPU; 对所述 1? >¾文对 应的第一 CPU进行相应的 ACL配置，并将实现该 IP 文相应 IPSEC业务所需 的数据， 发送给该第一 CPU。
上述 CPU可以分布于一个业务板上或者多个业务板之上， 第二 CPU和第 一 CPU是对同一条 IP隧道中的 IP ·艮文进行处理时， 起不同作用的 CPU, 作 为 VPN设备上的物理实体， 上述第二 CPU和执行 CPU并没有实质上的区别， 可以为业务板上的任一个 CPU。
如图 17 所示， 本发明实施例十二提供的报文处理***的工作流程示意 图， 包括接口板 61和接口板 62 , 主控板 63 , 业务板 64上包括 CPU65 , 业务 板 66上包括 CPU67。 但不限于此， 例如， 接口板的数量可以为一个或多个， 业务板的数量可以为多个等。
主控板 63对业务板 64和业务板 66进行 ACL数据的配置， 接口板 61接 收 IP报文 1 , 获取到该 IP报文 1的第二 CPU为业务板 64上的 CPU65 , CPU65 根据 ACL数据对该 IP报文 1进行匹配， 获取到执行该 IP报文对应的 IPSEC 业务（加封装）的执行 CPU为业务板 66上的 CPU67 , CPU67对该 IP报文 1进 行加封装后， 通过接口板 62发送出去。
接口板 62接收利用相同方式加封装处理后的 IP报文 2 , 直接获取到相 应的执行 CPU67 , 将该 IP报文 2发送给该 CPU67 , 该 CPU67对 IP报文 2进行 解封装后通过接口板 61发送出去。
上述报文处理***中各功能实体的具体工作方式可参见本发明的方法实 施例。
本发明实施例十二提供的技术方案， 通过 ip报文获取实现该 ip 报文 IPSEC业务的第一 CPU, 将 IP报文对应于相应的 CPU, 由该 CPU实现对该 IP 报文的 IPSEC业务， 减轻了主控板的工作量， 从而提高了报文的处理效率； 利用不同的 CPU实现了 IP报文的负载分流，解决了现有技术中因无法对具有 多 CPU的高端 VPN设备， 实现 IPSEC业务带来的问题， 从而能够在包含多个 CPU的 VPN设备中实现 IPSEC业务。
上述本发明实施例九和实施例十为实现 IPSEC业务的报文处理方法。 在 实现 IPSEC业务中， 报文处理方法还可包括建立隧道的过程。
图 18 为本发明实施例十三提供的一种建立隧道的方法的流程图， 如图 18所示， 包括：
步骤 S1801、 接收需要加密的报文， 所述需要加密的报文为根据分配规 则发送到指定的中央处理器 CPU中的报文；
其中指定的 CPU可以为第一 CPU。
其中， 分配规则具体为： 根据从接口板获取的 CPU号将报文发送到与所 述 CPU号对应的 CPU中， 所述 CPU号由所述接口板通过对所述 4艮文的源、 目 的地址哈希计算得到。
接口板对要发送报文的源、 目的地址进行哈希计算， 获得该报文的哈希 值， 然后根据该哈希值向业务板发送该报文。 业务板接收报文后， 查找与该 报文匹配的安全策略， 获取其中需要加密的报文； 业务板获取需要加密报文 的哈希值所对应的 CPU号码， 然后根据安全策略将该需要加密的报文发送到 与所述 CPU号码对应的该指定的 CPU中。
其中， 安全策略用以维护隧道协商动态生成的数据流， 检测业务板接收 的报文是否需要加密。
另外， 在该步骤之后还可以包括以下步骤：
上述指定的 CPU检测需要加密的报文所在隧道是否建立；
当所述需要加密的报文所在隧道已经建立时， 不进行隧道协商。
步骤 S1802、 当所述指定的 CPU检测到所述 文所在隧道没有建立时， 向接口板发送 IKE报文， 触发隧道协商。
步骤 S1803、 接收所述接口板根据所述分配规则上送的 IKE报文， 建立 所述隧道。
其中， 接口板根据所述分配规则上送 IKE报文可以包括以下步骤： 所述 接口板对接收的所述 IKE报文的源、 目的地址进行哈希值计算， 获得进行隧 道协商的 CPU号； 根据所述隧道协商的 CPU号上送 IKE报文。
在本发明实施例提供的建立隧道的方法中， 当业务板接收的报文为 IKE 协商包时，可以直接向接口板发送 IKE报文进行隧道协商；接口板接收该 IKE 报文后根据其源、 目的地址进行哈希计算， 得到能进行隧道协商的 CPU号码， 业务板接收接口板上送的 IKE报文， 建立隧道。
需要说明的是， 上述 CPU分布于网关的一个或多个业务板上， 所述 CPU 的数量和所述业务板的数量根据所述网关处理业务的需求而定。
通过采用本发明实施例，可以在业务板上实现处理 IPsec业务和进行 IKE 协商， 减轻了主控板的工作量， 从而提高了报文的处理效率， 采用本发明实 施例提供的分配规则， 可以在不同业务板上实现 IKE协商均衡， 从而提高系 统 IPsec业务和 IKE协商的处理能力。
采用本发明实施例提供的建立隧道的方法， 可以在分布式架构下， 在业 务板上实现 IKE协商， 从而实现在隧道协商的时候， 将传输报文的隧道分散 在各个 CPU上， 提高了整机容量和性能。 如图 19为在分布式架构下的简要处 理流程图。 为了清楚说明本发明实施例的具体实施方式， 假设在现有的分布 式架构中安装三块业务板， 另外还有一块主控板、 两块接口板。 每块业务板 上有两个处理器 CPU, 如业务板上所示的 A、 B。 但是需要说明的是， 每块业 务板上不是仅有两个 CPU, 可以根据需要在业务板上增加 CPU的数量。 在图 19中共有三条数据流， 其中 1号流用于传输 IP报文， 2号流用于发送 IKE报 文， 3号流用于发送接口板二根据计算得到的用于进行隧道协商的 IKE报文。 具体实现 IKE协商， 建立隧道的方法流程图如图 20所示， 包括：
步骤 S2001、 将接收的报文发送到业务板。
当接口板一收到一个 IP包时， 通过对 IP _¾文的源、 目的地址计算哈希 值后， 得到接收该报文的 CPU所对应的 CPU号码， 然后将该 IP报文通过 1号 数据流发送到与上述 CPU号匹配的 CPU上，在图 19中为业务板二上的 B-CPU。
步骤 S2002、 检测 IP报文是否需要加密。 如果该 IP报文不需要加密， 则执行步骤 S2003; 如果该 IP报文需要加密， 则执行步骤 S2004。
步骤 S2003、 不进行 IKE协商。
步骤 S2004、 将需要加密的 IP报文发送到指定的 CPU中。
业务板接收到 IP报文后， 会查找与该报文匹配的安全策略， 获取其中需 要加密的报文； 然后， 业务板获取该需要加密报文所对应的 CPU号码， 该 CPU 号码在步骤 S2008 中产生， 根据匹配的安全策略将该需要加密的报文发送到 与所述 CPU号码对应的 CPU中， 该 CPU即是传输该需要加密报文的隧道所在 的 CPU。 在图 19中示例为业务板二上的 B-CPU通过安全策略匹配， 选中了业 务板一中的 A-CPU,然后将此需要加密的 IP报文通过 1号数据流发送到 A-CPU 中。
步骤 S2005、 检测需要加密的报文所在隧道是否建立。 当该需要加密的 IP报文所在隧道已经建立时， 执行步骤 S2006; 当该 IP报文所在隧道还未建 立时， 执行步骤 S2007。
步骤 S2006、 不进行 IKE协商。 当该需要加密的 IP报文所在隧道已经建 立时， 即通过该隧道传输上述 ·艮文。
步骤 S2007、 进行隧道协商。
当业务板中的 CPU收到一个 IP报文后，先在安全策略单元对此报文进行安 全策略匹配， 当发现此报文所在的遂道并没有建立时，就会通过 2号流发送 IKE 报文进行遂道协商。 当收到 IKE协商包后， 后续的响应协商也会产生 2号流。
步骤 S2GG8、 接收上送的 IKE报文， 建立隧道。
当接口板二收到目的地址为本机的 IKE报文时， 接口板二将通过源 IP、 目的 IP进行哈希计算， 得到进行 IKE协商的 CPU号， 该 CPU号所对应的 CPU 即为步骤 S2004中所指定的 CPU, 用于 IP ^艮文入隧道时选择对应的 CPU进行 加密处理（在图 19中选择的 CPU即为业务板一中的 A-CPU ) 。 接口板根据计 算得到的 CPU号将 IKE >¾文上送到 A-CPU中， 隧道建立。
需要说明的是，同一条遂道的 1号流与 3号流将会发送报文到同一个 CPU, 这样才能建立起传输需要加密报文的隧道。只有当处于 i sakmp方式协商时才 会存在主动发起协商。 而此方式需要配置遂道， 在配置时就可以得到遂道的 源 IP与目的 IP, 在主控板将可以将此两个 IP的哈希值计算出来将下发到所 有业务板中 （下发到所有业务板的目的是让 1 号流能顺利找到指定 CPU ) , 这样可以使得 1号流与 3号流所选择的 CPU相同。 另外， 业务板和 CPU的数 量并不仅仅限于图中的几个， 业务板和 CPU的数量可以根据网关处理数据业 务的需要视情况而定。
通过本发明实施例， IPsec 业务可以全部实现在业务板上， 业务板都具 有处理 IPsec业务和进行 IKE协商的能力， 业务板上的 CPU经过 IKE协商建 立发送加密报文的隧道， 减轻了主控板的工作量， 从而提高了报文的处理效 率， ； 由于采用上述分配规则， 根据不同的 IKE报文而计算得到的哈希值不 同， 可以实现 IKE协商在不同业务板上的均衡。 由此可见， 使用的业务板越 多， 越能增强该分布式架构进行 IPsec业务和 IKE协商的处理能力。
上述本发明实施例十二为实现 IPSEC业务的报文处理***。在实现 IPSEC 业务中， 报文处理***还可包括与接口板连接的建立隧道的设备。
隧道建立设备用于接收接口板根据分配规则发送的报文； 将需要加密的 报文根据所述分配规则发送到指定的 CPU中； 当所述指定的 CPU检测到所述 报文所在隧道没有建立时， 向接口板发送 IKE报文， 触发隧道协商； 接收接 口板根据所述分配规则上送的 IKE报文， 建立所述隧道。
接口板， 用于向隧道建立设备根据所述分配规则发送所述报文； 接收隧 道建立设备发送的所述 IKE报文， 对所述 IKE报文的源、 目的地址进行哈希 值计算， 获得所述进行隧道协商的 CPU号码； 向隧道建立设备上送 IKE报文。
其中， 分配规则具体为： 根据从接口板获取的 CPU号将报文发送到与所 述 CPU号对应的 CPU中， 所述 CPU号由所述接口板通过对所述 4艮文的源、 目 的地址哈希计算得到。 上述 CPU位于隧道建立设备中， 用于接收所述需要加 密的报文， 检测所述需要加密的报文所在隧道是否建立。 实际上， 该隧道建 立设备为网关上的一个或多个业务板， CPU分布于每块业务板上， CPU的数量 和业务板的数量根据网关处理业务的需求而定。
图 21为本发明实施例十四提供的一种建立隧道的设备的结构示意图，如 图 21所示， 包括：
加密报文接收单元 101 , 用于接收需要加密的报文， 所述需要加密的报 文为根据分配规则发送到指定的中央处理器 CPU中的报文；
第一发送单元 201 , 用于当所述指定的 CPU检测到所述报文所在隧道没 有建立时， 向接口板发送 IKE报文， 触发隧道协商；
建立单元 301 , 用于接收所述接口板根据所述分配规则上送的 IKE报文， 建立所述隧道。
分配规则具体为： 根据从接口板获取的 CPU号将报文发送到与所述 CPU 号对应的 CPU中， 所述 CPU号由所述接口板通过对所述 ^艮文的源、 目的地址 哈希计算得到。
该设备还可以包括： 报文接收单元 401 , 用于接收接口板根据所述分配 规则发送的报文。 另外， 该报文接收单元 401还用于接收 IKE协商包。
另外， 该建立隧道的设备中还可以包括： 安全策略单元 501 , 用于配置 所述安全策略， 维护隧道协商动态生成的数据流， 检测报文接收单元 401接 收的报文是否需要加密。
该建立隧道的设备还可以包括：
查找单元 601 , 用于在安全策略单元 501 查找与所述报文匹配的安全策 略， 获取所述需要加密的报文；
获取单元 701 , 用于获取接收所述需要加密报文的 CPU号码；
第二发送单元 801 , 用于将查找单元 601 获取的所述需要加密的报文， 根据所述安全策略发送到与获取单元 701所获取的所述 CPU号码对应的所述 指定的 CPU中。
在本发明实施例中， 该建立隧道的设备为网关上的一个或多个业务板， CPU分布于每块业务板上， 其中， CPU的数量和业务板的数量根据网关处理业 务的需求而定。
通过本发明实施例提供的建立隧道的设备，可以实现在业务板处理 IPsec 业务和进行 IKE协商， 减轻了主控板的工作量， 从而提高了报文的处理效率， 采用本发明实施例提供的分配规则可以在不同业务板上实现 IKE协商均衡， 从而提高*** IPsec业务和 IKE协商的处理能力。
本领域技术人员可以理解附图只是一个优选实施例的示意图， 附图中的 模块或流程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述 进行分布于实施例的装置中， 也可以进行相应变化位于不同于本实施例的一 个或多个装置中。 上述实施例的模块可以合并为一个模块， 也可以进一步拆 分成多个子模块。
上述本发明实施例序号仅仅为了描述， 不代表实施例的优劣。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程， 是可以通过计算机程序来指令相关的硬件来完成，上述的程序可存储于一个或 多个计算机可读取存储介质中， 该程序在执行时， 可包括如上述各方法的实施 例的流程。其中，上述的存储介质可为磁碟、光盘、只读存储记忆体（ Read-Only Memory, ROM )或随机存储记忆体 ( Random Acces s Memory, RAM )等。
最后应说明的是： 以上实施例仅用以说明本发明的技术方案而非对其进 行限制， 尽管参照较佳实施例对本发明进行了详细的说明， 本领域的普通技 术人员应当理解： 其依然可以对本发明的技术方案进行修改或者等同替换， 而这些修改或者等同替换亦不能使修改后的技术方案脱离本发明技术方案的 4青神和范围。

Claims

权 利 要 求 书
1、 一种报文处理方法， 应用于多业务板的分布式架构， 所述分布式架构 包括主控板、 至少一个业务板和至少一个接口板， 其特征在于， 包括：
确定接收到的报文对应的指定的 CPU, 由所述 CPU对应的业务板对接收 到的报文进行处理。
2、 根据权利要求 1所述的方法， 其特征在于， 所述确定接收到的报文对 应的指定的 CPU, 由所述 CPU对应的业务板对接收到的报文进行处理包括： 接口板根据主控板下发的配置通用路由封装 GRE路由信息， 将接收到的 第一报文发送到指定的业务板，由所述业务板对所述第一报文进行封装处理； 所述接口板接收所述业务板发送的封装处理后的第一报文， 并根据所述 主控板下发的配置 GRE路由信息向外部转发所述封装处理后的第一 ·艮文； 所述接口板接收到外部发送的对所述封装处理后的第一报文进行响应的 第二报文， 根据配置的路由信息将所述第二报文发送到所述业务板， 由所述 业务板对所述第二>¾文进行解封装处理。
3、 根据权利要求 2所述的方法， 其特征在于， 所述接口板根据主控板下 发的配置通用路由封装 GRE路由信息， 将接收到的第一报文发送到指定的业 务板之前包括：
***对每个业务板上的 CPU进行编号，并对隧道 Tunne l的两端的地址进 行 ha sh, 根据 ha sh索引选择相应的 CPU。
4、 根据权利要求 2所述的方法， 其特征在于， 所述接口板根据主控板下 发的配置通用路由封装 GRE路由信息， 将接收到的第一报文发送到指定的业 务板之前还包括：
所述主控板将封装信息所需要的信息和配置的 GRE路由信息广播到业务 板。
5、 根据权利要求 4所述的方法， 其特征在于，
所述封装信息所需要的信息包括隧道 Tunne l 的源地址、 目的地址、 Tunen 1接口的 I P地址、 检验和以及认证关键字；
所述配置 GRE路由信息包括路由的下一跳、出接口、处理 GRE报文的 CPUID 以及 1¾道 ID。
6、 根据权利要求 2所述的方法， 其特征在于， 所述接口板根据主控板下 发的配置通用路由封装 GRE路由信息， 将接收到的第一报文发送到指定的业 务板包括：
当所述接口板发现接收到的第一报文是要路由经过隧道 Tunnel 的出接 口时， 所述接口板根据配置的 GRE路由信息获得所述第一报文对应的 CPUID, 并将所述第一 ^¾文发送到 CPUID对应的业务板；
当所述接口板发现接收到的第一报文是到本机时， 所述接口板根据第一 才艮文的源地址和目的地址进行 hash, 计算处理所述第一^艮文的业务板并发送 所述第一报文。
7、 根据权利要求 2所述的方法， 其特征在于， 所述接口板接收到外部发 送的对所述封装处理后的第一报文进行响应的第二报文， 根据配置的路由信 息将所述第二报文发送到所述业务板具体包括：
所述接口板接收到本机的第二报文， 对所述第二报文的源地址和目的地 址进行 hash并发送到所述业务板。
8、 根据权利要求 2所述的方法， 其特征在于， 所述业务板对所述第二报 文进行解封装处理包括：
所述业务板判断当接收到的第二报文的配置信息与隧道的配置信息相符 时， 所述业务板将所述 文的 GRE协议头部信息去掉；
所述业务板判断当接收到的第二报文的配置信息与该隧道的配置信息不 相符时， 所述业务板将该报文丟弃。
9、 根据权利要求 1所述的方法， 其特征在于， 所述确定接收到的报文对 应的指定的 CPU, 由所述 CPU对应的业务板对接收到的报文进行处理包括： 存储建立的当前业务板与客户端之间的隧道的编号至所述当前业务板的 CPU, 并请求所述主控板为所述客户端分配 IP地址；
通过所述主控板将所述隧道的编号、 处理所述隧道的当前业务板的 CPU 的编号及所述客户端的 IP地址的对应关系发送至所述多个业务板；
当接收到报文后， 查询所述报文的目的地址；
若查询所述报文的目的地址为所述客户端的 IP地址，则根据所述客户端 的 IP地址对应的 CPU编号将所述 >¾文发送至与所述 CPU编号对应的当前业务 板进行处理。
10、 根据权利要求 9所述方法， 其特征在于， 还包括： 建立当前业务板 与客户端之间的隧道的步骤， 具体包括：
建立所述当前业务板与所述客户端之间的 L2TP隧道； 或
先建立所述当前业务板与所述客户端之间的 IPSEC隧道， 再建立所述当 前业务板与所述客户端之间的 L2TP隧道。
11、 根据权利要求 10所述方法， 其特征在于， 所述若查询所述报文的目 的地址为所述客户端的 IP地址， 则根据所述客户端的 I P地址对应的 CPU编 号将所述报文发送至与所述 CPU 编号对应的当前业务板进行处理的步骤包 括：
若查询所述报文的目的地址为所述客户端的 IP地址，则根据所述客户端 的 IP地址对应的 CPU编号将所述 >¾文发送至与所述 CPU编号对应的业务板进 行 L2TP封装处理， 或先进行 L2TP封装处理再进行 IPSEC加密处理。
12、 根据权利要求 1所述的方法， 其特征在于， 所述确定接收到的报文 对应的指定的 CPU, 由所述 CPU对应的业务板对接收到的报文进行处理包括： 接收所述主控板发送的与客户端建立的隧道的编号、处理所述隧道的 CPU 编号及分配给所述客户端的 IP地址对应关系；
当接收到报文后， 查询所述报文的目的地址；
若查询所述报文的目的地址为所述客户端的 IP地址，则根据所述客户端 的 IP地址对应的 CPU编号将所述 >¾文发送至与所述 CPU编号对应的业务板进 行处理。
13、 根据权利要求 12所述的方法， 其特征在于， 所述若查询所述报文的 目的地址为所述客户端的 IP地址， 则根据所述客户端的 IP地址对应的 CPU 编号将所述报文发送至与所述 CPU编号对应的业务板进行处理的步骤包括： 查询所述 ^艮文的目的地址为所述客户端的 I P地址时， 居所述客户端的
IP地址对应的 CPU编号将所述报文发送至与所述 CPU编号对应的业务板进行 L2TP封装处理， 或先进行 L2TP封装处理再进行 IPSEC加密处理。
14、 根据权利要求 12所述的方法， 其特征在于， 所述当接收到报文后， 查询所述^艮文的目的地址的步骤还包括：
若查询所述报文的目的地址为所述建立当前业务板与客户端之间的隧道 的 IP地址， 则将所述>¾文发送所述隧道对应的当前业务板进行 L2TP解封装 处理， 或先进行 IPSEC解密处理再进行 L2TP解封装处理。
15、 根据权利要求 1所述的方法， 其特征在于， 所述确定接收到的报文 对应的指定的 CPU, 由所述 CPU对应的业务板对接收到的报文进行处理包括： 接口板根据接收到的 I P报文， 从至少两个 CPU中获取对该 I P报文进行
IP安全 IPSEC业务处理的第一 CPU, 所述第一 CPU为指定的 CPU;
所述第一 CPU对该 IP 文进行相应的 IPSEC业务处理并发送。
16、 根据权利要求 15所述的方法， 其特征在于， 所述 IP报文包括需加 封装的 IP报文， 所述接口板根据接收到的 IP报文， 获取对该 IP报文进行 IP安全 IPSEC业务处理的第一 CPU包括：
所述接口板根据所述需加封装的 IP报文， 获取第二 CPU;
所述第二 CPU利用访问控制列表 ACL对该 IP报文进行匹配，获取所述第 一 CPU。
17、 根据权利要求 16所述的方法， 其特征在于， 所述接口板根据所述需 加封装的 IP报文， 获取第二 CPU包括：
对所述需加封装的 IP报文中携带的 IP报文的源和目的 IP地址进行哈希 变换， 获取哈希索引值；
根据所述哈希索引值获取所述第二 CPU。
18、 根据权利要求 15所述的方法， 其特征在于， 所述 IP报文包括需解 封装的 IP报文， 所述接口板根据接收到的 IP报文， 获取对该 IP报文进行 IP安全 IPSEC业务处理的第一 CPU包括：
对所述需解封装的 IP报文中携带的 IPSEC隧道两端的 IP地址进行哈希 变换， 获取哈希索引值；
根据所述哈希索引值获取所述第一 CPU。
19、 根据权利要求 15至 18任一项所述的方法， 其特征在于， 在所述接 口板根据接收到的 IP报文，获取对该 IP报文进行 IP安全 IPSEC业务处理的 第一 CPU的步骤之前还包括：
主控板为所述 IP ·艮文分配相应的第一 CPU;
主控板对所述 IP 文对应的第一 CPU进行相应的 ACL配置，并将实现该 IP报文相应 IPSEC业务所需的数据， 发送给该第一 CPU。
20、 根据权利要求 19所述的方法， 其特征在于， 所述主控板为所述 IP 报文分配相应的第一 CPU包括：
对所述 IP 文所处 IPSEC隧道两端的 IP地址进行哈希变换， 获取哈希 索引值；
将所述 IP报文的哈希索引值对应于所述 CPU。
21、 根据权利要求 15所述的方法， 其特征在于， 所述确定接收到的报文 对应的指定的 CPU, 由所述 CPU对应的业务板对接收到的报文进行处理之前 还包括：
接收需要加密的报文， 所述需要加密的报文为根据分配规则发送到指定 的中央处理器 CPU中的报文；
当所述指定的 CPU检测到所述需要加密的报文所在隧道没有建立时， 向 接口板发送因特网密钥交换 IKE报文， 触发隧道协商； 接收所述接口板根据所述分配规则上送的 IKE报文， 建立所述需要加密 的报文所在隧道。
22、 根据权利要求 21所述的方法， 其特征在于， 所述分配规则包括： 根 据从接口板获取的 CPU号将 ^艮文发送到与所述 CPU号对应的 CPU中，所述 CPU 号由所述接口板通过对所述报文的源、 目的地址哈希计算得到。
23、 根据权利要求 21所述的方法， 其特征在于， 在所述接收需要加密的 报文之前还包括：
接收接口板根据所述分配规则发送的报文。
24、 根据权利要求 21所述的方法， 其特征在于， 还包括：
查找与所述报文匹配的安全策略， 获取所述需要加密的报文；
获取接收所述需要加密报文的 CPU号码；
将所述需要加密的报文根据所述安全策略发送到与所述 CPU号码对应的 所述指定的 CPU中。
25、 根据权利要求 24所述的方法， 其特征在于， 还包括：
配置所述安全策略， 以维护隧道协商动态生成的数据流， 检测接收的报 文是否需要加密。
26、 根据权利要求 21所述的方法， 其特征在于， 在所述接收需要加密的 报文之后还包括：
当所述指定的 CPU检测到所述需要加密的报文所在隧道已经建立时， 不 进行隧道协商。
27、 根据权利要求 21所述的方法， 其特征在于， 所述接口板根据所述分 配规则上送 IKE报文包括：
所述接口板对接收的所述 IKE报文的源、 目的地址进行哈希值计算， 获 得进行隧道协商的 CPU号；
根据所述隧道协商的 CPU号上送 IKE报文。
28、 根据权利要求 21所述的方法， 其特征在于， 还包括： 当接收的报文为 IKE协商包时， 向所述接口板发送 IKE报文触发隧道协 商；
接收所述接口板根据所述分配规则上送的 IKE报文， 建立隧道。
29、 根据权利要求 21-28任一项所述的方法， 其特征在于， 所述 CPU分 布于网关的一个或多个业务板上， 所述 CPU的数量和所述业务板的数量根据 所述网关处理业务的需求而定。
30、 一种接口板， 应用于包括主控板、 至少一个接口板和业务板的***， 其特征在于， 包括：
报文下发单元， 用于根据主控板下发的配置 GRE路由信息， 将接收到的 第一报文发送到指定业务板；
报文转发单元， 用于接收所述业务板发送的封装处理后的第一报文， 并 根据所述主控板下发的配置 GRE路由信息向外部转发所述封装处理后的第一 报文；
报文接收单元， 用于接收到外部发送的对所述封装处理后的第一报文进 行响应的第二报文，根据配置的路由信息将所述第二报文发送到所述业务板。
31、根据权利要求 30所述的接口板，其特征在于，所述报文下发单元包括： 第一报文下发子单元， 用于当所述接口板发现接收到的第一报文是要路 由经过隧道 Tunnel的出接口时，所述接口板根据配置的 GRE路由信息获得所 述第一 "¾文对应的 CPUID, 并将所述第一 文发送到业务板；
第二报文下发子单元， 用于当所述接口板发现接收到的第一报文是到本 机的报文时， 所述接口板根据所述第一报文的源地址和目的地址进行 hash, 计算处理所述第一报文的业务板并发送所述第一报文。
32、 一种报文处理***， 其特征在于， 包括主控板、 至少一个接口板和 业务板；
所述主控板，用于对封装报文所需要的信息和配置 GRE路由信息进行下发； 所述接口板， 用于根据所述主控板下发的配置 GRE路由信息， 将接收到 的第一报文发送到所述业务板，由所述业务板对所述第一报文进行封装处理， 并接收所述业务板发送的封装处理后的第一报文， 并根据所述主控板下发的 配置 GRE路由信息向外部转发所述封装处理后的第一报文， 在接收到外部发 送的对所述封装处理后的第一报文进行响应的第二报文之后， 根据配置的路 由信息将所述第二报文路由到所述业务板， 由所述业务板对所述第二报文进 行解封装处理；
所述业务板， 用于对所述接口板发送的报文进行封装和解封装处理。
33、 一种报文处理***， 其特征在于， 包括多个业务板、 控制板及接口 板， 其中， 所述多个业务板， 用于建立与客户端之间的隧道， 存储所述隧道 的编号至与所述客户端建立隧道的业务板的 CPU, 并请求所述控制板为所述 客户端分配 IP地址；
所述控制板，用于将所述隧道的编号、处理所述隧道的当前业务板的 CPU 的编号及所述客户端的 IP 地址的对应关系发送至所述接口板和所述多个业 务板；
所述接口板， 用于当接收到报文时查询所述报文的目的地址， 当查询所 述才艮文的目的地址为所述客户端的 IP地址时， 根据所述客户端的 IP地址对 应的 CPU编号将所述 >¾文发送至与所述 CPU编号对应的业务板进行处理。
34、 根据权利要求 33所述的***， 其特征在于， 所述多个业务板还用于 当接收到报文后查询所述报文的目的地址， 并当查询所述报文的目的地址为 所述客户端的 IP地址， 根据所述客户端的 IP地址对应的 CPU编号将所述报 文发送至与所述 CPU编号对应的业务板进行处理。
35、 根据权利要求 33所述的***， 其特征在于， 所述多个业务板还用于 建立与所述客户端之间的 L2TP 隧道； 或还用于先建立与所述客户端之间的 IPSEC隧道， 再建立与所述客户端之间的 L2TP隧道。
36、 根据权利要求 35所述的***， 其特征在于， 所述多个业务板还用于 查询所述 ^艮文的目的地址为所述客户端的 IP地址时， 根据所述客户端的 IP 地址对应的 CPU 编号将所述 >¾文发送至与所述 CPU 编号对应的业务板进行 L2TP封装处理， 或先进行 L2TP封装处理再进行 IPSEC加密处理。
37、 根据权利要求 35所述的***， 其特征在于， 所述接口板还用于查询 所述 ^艮文的目的地址为所述客户端的 IP地址时， 才艮据所述客户端的 IP地址 对应的 CPU编号将所述 文发送至与所述 CPU编号对应的业务板进行 L2TP封 装处理， 或先进行 L2TP封装处理再进行 IPSEC加密处理。
38、 根据权利要求 35所述的***， 其特征在于， 所述接口板还用于查询 所述报文的目的地址为所述建立业务板与客户端之间的隧道的 IP地址时，将 所述 文发送所述隧道对应的业务板进行 L2TP解封装处理， 或先进行 IPSEC 解密处理再进行 L2TP解封装处理。
39、 一种应用于分布式架构的业务板， 其特征在于， 所述业务板与控制 板、 接口板通信连接， 用于接收所述控制板发送的与客户端建立的隧道的编 号、 处理所述隧道的 CPU编号及分配给所述客户端的 IP地址对应关系， 并当 接收报文后查询所述报文的目的地址， 及当查询所述报文的目的地址为所述 客户端的 IP地址时， 根据所述客户端的 IP地址对应的 CPU编号将所述报文 发送至与所述 CPU编号对应的业务板进行处理。
40、 根据权利要求 39所述的业务板， 其特征在于， 所述业务板还用于建 立与所述客户端之间的 L2TP 隧道； 或还用于先建立与所述客户端之间的 IPSEC隧道， 再建立与所述客户端之间的 L2TP隧道。
41、 根据权利要求 40所述的业务板， 其特征在于， 所述业务板还用于查 询所述 ^艮文的目的地址为所述客户端的 IP地址时， 根据所述客户端的 IP地 址对应的 CPU编号将所述 ^艮文发送至与所述 CPU编号对应的业务板进行 L2TP 封装处理， 或先进行 L2TP封装处理再进行 IPSEC加密处理。
42、 一种应用于分布式架构的接口板， 其特征在于， 所述接口板与控制 板、 多个业务板通信连接， 所述多个业务板用于建立与所述客户端之间的隧 道， 所述接口板用于接收所述控制板发送的与客户端建立的隧道的编号、 处 理所述隧道的 CPU编号及分配给所述客户端的 IP地址对应关系，并当接收报 文后查询所述报文的目的地址， 及当查询所述报文的目的地址为所述客户端 的 IP地址， 根据所述客户端的 IP地址对应的 CPU编号将所述 文发送至与 所述 CPU编号对应的业务板进行处理。
43、 根据权利要求 42所述的接口板， 其特征在于， 所述接口板还用于查 询所述 ^艮文的目的地址为所述客户端的 IP地址时， 根据所述客户端的 IP地 址对应的 CPU编号将所述 ^艮文发送至与所述 CPU编号对应的业务板进行 L2TP 封装处理， 或先进行 L2TP封装处理再进行 IPSEC加密处理。
44、 根据权利要求 42所述的接口板， 其特征在于， 所述接口板还用于查 询所述报文的目的地址为所述建立业务板与客户端之间的隧道的 IP地址时， 将所述报文发送所述隧道对应的业务板进行 L2TP 解封装处理， 或先进行 IPSEC解密处理再进行 L2TP解封装处理。
45、 一种报文处理装置， 其特征在于， 包括： 第一 CPU获取单元和第一 CPU; 其中
所述第一 CPU获取单元， 用于根据接收到的 IP报文， 获取对该 IP报文 进行 IP安全 IPSEC业务处理的第一 CPU;
所述第一 CPU, 用于对该 IP 文进行相应的 IPSEC业务处理并发送。
46、 根据权利要求 45所述的装置， 其特征在于， 所述 IP报文包括需加 封装的 IP报文， 所述第一 CPU获取单元包括：
第二 CPU获取模块， 用于根据所述需加封装的 IP报文， 获取第二 CPU, 该第二 CPU利用访问控制列表 ACL对该 IP报文进行匹配，获取所述第一 CPU。
47、 根据权利要求 45所述的装置， 其特征在于， 所述 IP报文包括需解 封装的 IP报文， 所述第一 CPU获取单元包括：
计算模块， 用于对所述需解封装的 IP报文中携带的 IPSEC 隧道两端的 IP地址进行哈希变换， 获取哈希索引值；
获取模块， 根据所述哈希索引值获取所述第一 CPU。
48、 一种 文处理***， 其特征在于， 包括至少一个接口板和至少两个
CPU;
所述接口板， 用于根据接收到的 IP报文， 获取对该 IP报文进行 IP安全 IPSEC业务处理的第一 CPU;
所述第一 CPU, 用于对该 IP 文进行相应的 IPSEC业务处理并发送。
49、 根据权利要求 48所述的***， 其特征在于， 还包括：
主控板， 用于为所述 IP 文分配相应的第一 CPU; 对所述 IP 文对应 的第一 CPU进行相应的 ACL配置，并将实现该 IP 文相应 IPSEC业务所需的 数据， 发送给该第一 CPU。
50、 根据权利要求 48所述的***， 其特征在于， 还包括与所述接口板连 接的建立隧道的设备；
所述接口板， 还用于向所述隧道建立设备根据分配规则发送报文； 接收所 述隧道建立设备发送的 IKE报文， 对所述 IKE报文的源、 目的地址进行哈希值 计算， 获得进行隧道协商的 CPU号码； 向所述隧道建立设备上送 IKE报文； 所述隧道建立设备， 用于接收所述接口板根据所述分配规则发送的所述 报文； 将需要加密的报文根据所述分配规则发送到指定的 CPU中； 当所述指 定的 CPU检测到所述需要加密的报文所在隧道没有建立时， 向所述接口板发 送 IKE报文， 触发隧道协商； 接收所述接口板根据所述分配规则上送的 IKE 报文， 建立所述需要加密的报文所在隧道；
所述建立隧道的设备包括：
加密报文接收单元， 用于接收需要加密的报文， 所述需要加密的报文为 根据分配规则发送到指定的 CPU中的报文， 所述指定的 CPU为第一 CPU; 第一发送单元， 用于当所述指定的 CPU检测到所述需要加密的报文所在 隧道没有建立时， 向接口板发送 IKE报文， 触发隧道协商；
建立单元， 用于接收所述接口板根据所述分配规则上送的 IKE报文， 建 立所述需要加密的报文所在隧道。
51、 根据权利要求 50所述的***， 其特征在于， 所述分配规则包括： 根 据从接口板获取的 CPU号将 ^艮文发送到与所述 CPU号对应的 CPU中，所述 CPU 号由所述接口板通过对所述报文的源、 目的地址哈希计算得到。
52、 根据权利要求 50所述的***， 其特征在于， 所述建立隧道的设备还 包括：
报文接收单元， 用于接收接口板根据所述分配规则发送的报文。
53、 根据权利要求 52所述的***， 其特征在于， 所述建立隧道的设备还 包括：
安全策略单元， 用于配置安全策略， 维护隧道协商动态生成的数据流， 检测所述报文接收单元接收的报文是否需要加密。
54、 根据权利要求 53所述的***， 其特征在于， 所述建立隧道的设备还 包括：
查找单元， 用于在所述安全策略单元查找与所述报文匹配的安全策略， 获取所述需要加密的报文；
获取单元， 用于获取接收所述需要加密报文的 CPU号码；
第二发送单元， 用于将所述查找单元获取的所述需要加密的报文， 根据 所述安全策略发送到与所述获取单元所获取的所述 CPU号码对应的所述指定 的 CPU中。
55、 根据权利要求 52所述的***， 其特征在于， 所述报文接收单元还用 于接收 IKE协商包。
56、 根据权利要求 50-55任一项所述的***， 其特征在于， 所述设备为 网关的一个或多个业务板， 所述 CPU位于所述业务板上， 所述 CPU的数量和 所述业务板的数量根据所述网关处理业务的需求而定。
PCT/CN2009/073100 2008-08-18 2009-08-05 报文处理方法、装置和*** WO2010020151A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/030,898 US8509239B2 (en) 2008-08-18 2011-02-18 Method, apparatus and system for processing packets
US13/935,929 US8737388B2 (en) 2008-08-18 2013-07-05 Method, apparatus and system for processing packets

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
CN2008101424585A CN101350759B (zh) 2008-08-18 2008-08-18 一种报文处理方法、业务板、接口板及网络通信设备
CN200810142458.5 2008-08-18
CN200810212182.3 2008-09-10
CN2008102121823A CN101345689B (zh) 2008-09-10 2008-09-10 一种ip安全业务的实现方法、装置和通信设备
CN2008101495947A CN101355505B (zh) 2008-09-12 2008-09-12 一种报文的转发方法、装置和***
CN200810149594.7 2008-09-12
CN2008101835510A CN101442470B (zh) 2008-12-18 2008-12-18 一种建立隧道的方法、***和设备
CN200810183551.0 2008-12-18

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/030,898 Continuation US8509239B2 (en) 2008-08-18 2011-02-18 Method, apparatus and system for processing packets

Publications (1)

Publication Number Publication Date
WO2010020151A1 true WO2010020151A1 (zh) 2010-02-25

Family

ID=41706853

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/073100 WO2010020151A1 (zh) 2008-08-18 2009-08-05 报文处理方法、装置和***

Country Status (2)

Country Link
US (2) US8509239B2 (zh)
WO (1) WO2010020151A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113452619A (zh) * 2021-06-29 2021-09-28 杭州迪普科技股份有限公司 一种基于acl的流量分流方法及装置
CN113630318A (zh) * 2020-05-06 2021-11-09 华为技术有限公司 报文传输的方法和框式通信设备
CN113794639A (zh) * 2021-08-25 2021-12-14 新华三信息安全技术有限公司 一种通信方法及装置

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101761702B1 (ko) * 2012-03-30 2017-08-04 노키아 솔루션스 앤드 네트웍스 오와이 분산된 게이트웨이들을 위한 중앙집중화된 ｉｐ 어드레스 관리 방법 및 장치
CN104022968B (zh) * 2013-02-28 2017-06-27 华为终端有限公司 一种基于多链路的数据传输方法及设备
CN103401773B (zh) * 2013-06-26 2017-04-19 杭州华三通信技术有限公司 一种实现板间通信的方法及网络设备
WO2016068944A1 (en) 2014-10-30 2016-05-06 Hewlett Packard Enterprise Development Lp Tunnel encapsulation
KR20160054850A (ko) * 2014-11-07 2016-05-17 삼성전자주식회사 다수의 프로세서들을 운용하는 장치 및 방법
US10986075B2 (en) * 2017-11-02 2021-04-20 Arista Networks, Inc. Distributing packets across processing cores
CN111224876B (zh) * 2018-11-23 2022-04-29 中兴通讯股份有限公司 报文的处理方法及装置
CN110166373B (zh) * 2019-05-21 2022-12-27 优刻得科技股份有限公司 源物理机向目的物理机发数据的方法、装置、介质和***
CN113114522B (zh) * 2021-03-03 2022-07-01 杭州迪普信息技术有限公司 流量监控设备
CN113098775B (zh) * 2021-03-28 2022-04-22 杭州迪普信息技术有限公司 流量分流方法及装置
US20230171099A1 (en) * 2021-11-27 2023-06-01 Oracle International Corporation Methods, systems, and computer readable media for sharing key identification and public certificate data for access token verification

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1642135A (zh) * 2004-01-17 2005-07-20 华为技术有限公司 一种ggsn/pdsn设备及其数据转发的方法
CN101106450A (zh) * 2007-08-16 2008-01-16 杭州华三通信技术有限公司 分布式报文传输安全保护装置和方法
CN101345689A (zh) * 2008-09-10 2009-01-14 华为技术有限公司 一种ip安全业务的实现方法、装置和通信设备
CN101350759A (zh) * 2008-08-18 2009-01-21 华为技术有限公司 一种报文处理方法、业务板、接口板及网络通信设备
CN101355505A (zh) * 2008-09-12 2009-01-28 成都市华为赛门铁克科技有限公司 一种报文的转发方法、装置和***
CN101442470A (zh) * 2008-12-18 2009-05-27 成都市华为赛门铁克科技有限公司 一种建立隧道的方法、***和设备

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6631422B1 (en) 1999-08-26 2003-10-07 International Business Machines Corporation Network adapter utilizing a hashing function for distributing packets to multiple processors for parallel processing
CN1184781C (zh) 2002-05-22 2005-01-12 华为技术有限公司 网络通信中报文的封装转发方法
CN1315293C (zh) 2002-11-26 2007-05-09 华为技术有限公司 分布式网络接入设备中握手机制的实现方法
US7822157B2 (en) * 2002-12-31 2010-10-26 L-3 Communications, Corp. Acquisition and tracking of burst code signals
CN100337452C (zh) 2003-05-28 2007-09-12 华为技术有限公司 一种点到点透传的实现方法
US7685434B2 (en) 2004-03-02 2010-03-23 Advanced Micro Devices, Inc. Two parallel engines for high speed transmit IPsec processing
US8320240B2 (en) * 2004-11-30 2012-11-27 Broadcom Corporation Rate limiting and minimum and maximum shaping in a network device
CN1649326A (zh) 2004-12-09 2005-08-03 武汉大学 一种集群服务器的多分配器前端***构成方法
EP1694024A1 (en) 2005-02-22 2006-08-23 Zyxel Communications Corporation Network apparatus and method for providing secure port-based VPN communications
CN1838609A (zh) 2005-03-22 2006-09-27 杭州华为三康技术有限公司 一种集中式业务处理方法及路由设备
CN1863101A (zh) 2005-10-18 2006-11-15 华为技术有限公司 一种通用路由封装隧道的检测方法
CN1984131A (zh) 2005-12-14 2007-06-20 北京三星通信技术研究有限公司 分布式IPSec处理的方法
US7995143B2 (en) * 2006-02-10 2011-08-09 Qualcomm Incorporated Wireless video link synchronization
CN100596349C (zh) 2006-04-26 2010-03-31 南京大学 基于高速网络数据处理平台vpn网关***的信息处理方法
CN101197664B (zh) 2008-01-03 2010-12-08 杭州华三通信技术有限公司 一种密钥管理协议协商的方法、***和装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1642135A (zh) * 2004-01-17 2005-07-20 华为技术有限公司 一种ggsn/pdsn设备及其数据转发的方法
CN101106450A (zh) * 2007-08-16 2008-01-16 杭州华三通信技术有限公司 分布式报文传输安全保护装置和方法
CN101350759A (zh) * 2008-08-18 2009-01-21 华为技术有限公司 一种报文处理方法、业务板、接口板及网络通信设备
CN101345689A (zh) * 2008-09-10 2009-01-14 华为技术有限公司 一种ip安全业务的实现方法、装置和通信设备
CN101355505A (zh) * 2008-09-12 2009-01-28 成都市华为赛门铁克科技有限公司 一种报文的转发方法、装置和***
CN101442470A (zh) * 2008-12-18 2009-05-27 成都市华为赛门铁克科技有限公司 一种建立隧道的方法、***和设备

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113630318A (zh) * 2020-05-06 2021-11-09 华为技术有限公司 报文传输的方法和框式通信设备
CN113630318B (zh) * 2020-05-06 2023-05-12 华为技术有限公司 报文传输的方法和框式通信设备
CN113452619A (zh) * 2021-06-29 2021-09-28 杭州迪普科技股份有限公司 一种基于acl的流量分流方法及装置
CN113794639A (zh) * 2021-08-25 2021-12-14 新华三信息安全技术有限公司 一种通信方法及装置

Also Published As

Publication number Publication date
US20130297671A1 (en) 2013-11-07
US8737388B2 (en) 2014-05-27
US8509239B2 (en) 2013-08-13
US20110149971A1 (en) 2011-06-23

Similar Documents

Publication Publication Date Title
WO2010020151A1 (zh) 报文处理方法、装置和***
US10708245B2 (en) MACsec for encrypting tunnel data packets
US11711242B2 (en) Secure SD-WAN port information distribution
WO2019201043A1 (zh) 网络通信方法、***、设备及存储介质
US8825829B2 (en) Routing and service performance management in an application acceleration environment
US11902264B2 (en) Path selection for data packets encrypted based on an IPSEC protocol
US8856518B2 (en) Secure and efficient offloading of network policies to network interface cards
US7860975B2 (en) System and method for secure sticky routing of requests within a server farm
JP2022550356A (ja) マルチテナントソフトウェア定義ワイドエリアネットワーク（ｓｄ－ｗａｎ）ノードを提供するための方法、システム、およびコンピュータ読取可能媒体
US20140153577A1 (en) Session-based forwarding
CA3021367C (en) Using wlan connectivity of a wireless device
WO2009021428A1 (fr) Dispositif de protection sécurisé et procédé permettant le transfert de messages
US10447591B2 (en) Executing multiple virtual private network (VPN) endpoints associated with an endpoint pool address
WO2010127610A1 (zh) 一种虚拟专用网节点信息的处理方法、设备及***
WO2021073565A1 (zh) 业务服务提供方法及***
TW201815131A (zh) 一種資料傳輸的方法及網路設備
KR20120063501A (ko) 클라우드 토폴로지 내 기업 확장을 위한 확장 가능 구조
WO2016210202A1 (en) Media relay server
WO2021073555A1 (zh) 业务服务提供方法及***、远端加速网关
US11936613B2 (en) Port and loopback IP addresses allocation scheme for full-mesh communications with transparent TLS tunnels
US11888818B2 (en) Multi-access interface for internet protocol security
Davoli et al. An anonymization protocol for the internet of things
US20200036686A1 (en) Context specific keys
EP3664403B1 (en) User authentication of bras under architecture of mutually separated forwarding and control
JP6990647B2 (ja) ＲｅＮＡＴ通信環境を提供するシステム及び方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09807850

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09807850

Country of ref document: EP

Kind code of ref document: A1