Network tunnel dialing method, device, equipment and medium

Abstract

The application discloses a network tunnel dialing method, device, equipment and medium, wherein the method comprises the following steps: receiving second layer tunnel protocol L2TP dialing configuration information; performing L2TP negotiation and session negotiation based on the dialing configuration information through a control plane, and generating negotiation state data; in response to the completion of the L2TP negotiation and the session negotiation, performing network layer parameter negotiation to obtain network configuration parameters; synchronizing the network configuration parameters and the negotiation state data to a data forwarding plane, and generating corresponding L2TP tunnel interfaces and session forwarding table entries in the data forwarding plane, wherein the control plane is independent of the data forwarding plane; and based on the L2TP tunnel interfaces and the session forwarding table entries, performing L2TP protocol packet encapsulation or decapsulation processing of a service packet in the data forwarding plane. The technical scheme provided by each embodiment of the application can give the network equipment the ability to automatically establish an L2TP dialing connection and access a network, and realizes the functions of separation and efficient cooperation of the L2TP dialing function.

Description

Technical Field

[0001] This application belongs to the field of computer network communication technology, and in particular relates to a network tunnel dialing method, apparatus, equipment and medium. Background Technology

[0002] Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol widely used in enterprise-level Virtual Private Networks (VPNs). It combines the security authentication mechanism of Point-to-Point Protocol (PPP) to establish a secure communication link between users and enterprise servers.

[0003] With the development of cloud computing and network function virtualization technologies, user-space packet processing frameworks (such as VPP (Vector Packet Processing)) are increasingly being used in high-performance gateways and edge computing nodes to carry high-throughput network traffic due to their superior packet processing performance.

[0004] In practical applications, L2TP dialing services not only require devices to have the ability to encapsulate and decapsulate data packets, but also require devices to act as dialing clients and actively initiate and complete a series of complex dynamic negotiation processes, including tunnel establishment, session establishment, and network layer parameter configuration.

[0005] However, high-performance forwarding schemes based on user-space packet processing frameworks in related technologies typically focus on improving the packet forwarding efficiency of the data plane. For example, VPP implementations in related technologies usually only support encapsulation and decapsulation of L2TPv3 packets based on pre-configured static rules. Existing high-performance forwarding frameworks lack corresponding processing mechanisms for the dynamic signaling interaction and session state negotiation required in standard L2TP dialing scenarios. This results in their inability to automatically obtain the session identifier and network configuration parameters required for dialing, making them difficult to directly apply to network scenarios that require dynamically establishing L2TP dialing connections. Summary of the Invention

[0006] This application provides an implementation scheme that differs from related technologies, in order to solve the technical problem in related technologies that network devices based on user-space packet processing frameworks cannot automatically establish L2TP dial-up connections to obtain network access.

[0007] Firstly, this application provides a network tunnel dialing method, including: Receive Layer 2 Tunneling Protocol (L2TP) dial-up configuration information; The control plane performs L2TP negotiation and session negotiation based on the dialing configuration information, and generates negotiation status data. In response to the completion of the L2TP negotiation and the session negotiation, network layer parameter negotiation is performed to obtain network configuration parameters; The network configuration parameters and the negotiation status data are synchronized to the data forwarding plane, and corresponding L2TP tunnel interfaces and session forwarding table entries are generated in the data forwarding plane. The control plane is independent of the data forwarding plane. Based on the L2TP tunnel interface and session forwarding table entries, L2TP protocol packet encapsulation or decapsulation processing of service packets is performed in the data forwarding plane.

[0008] Secondly, this application provides a network tunnel dialing device, comprising: The receiving unit is used to receive Layer 2 Tunneling Protocol (L2TP) dialing configuration information; The first negotiation unit is used to perform L2TP negotiation and session negotiation based on the dialing configuration information through the control plane, and generate negotiation status data. The second negotiation unit is used to perform network layer parameter negotiation in response to the completion of the L2TP negotiation and the session negotiation to obtain network configuration parameters; The synchronization unit is used to synchronize the network configuration parameters and the negotiation status data to the data forwarding plane, and generate the corresponding L2TP tunnel interface and session forwarding table entries in the data forwarding plane, wherein the control plane is independent of the data forwarding plane; The processing unit is used to perform L2TP protocol packet encapsulation or decapsulation processing of service packets in the data forwarding plane based on the L2TP tunnel interface and session forwarding table entries.

[0009] Thirdly, this application provides an electronic device, comprising: Processor; and Memory for storing the executable instructions of the processor; The processor is configured to execute the first aspect, or any method in any possible implementation of the first aspect, by executing the executable instructions.

[0010] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the first aspect, or any method in any possible implementation of the first aspect.

[0011] This application provides a scheme for receiving L2TP dial-up configuration information; performing L2TP negotiation and session negotiation based on the dial-up configuration information through the control plane to generate negotiation status data; responding to the completion of L2TP negotiation and session negotiation, performing network layer parameter negotiation to obtain network configuration parameters; synchronizing the network configuration parameters and negotiation status data to the data forwarding plane, and generating corresponding L2TP tunnel interfaces and session forwarding table entries in the data forwarding plane, wherein the control plane is independent of the data forwarding plane; and performing L2TP protocol packet encapsulation or decapsulation processing of service packets in the data forwarding plane based on the L2TP tunnel interfaces and session forwarding table entries. By introducing a control plane independent of the data forwarding plane to undertake the dynamic signaling negotiation tasks of L2TP and network layer protocols, and synchronizing the negotiated network configuration parameters and status data to the data forwarding plane to drive the generation of forwarding interfaces and table entries, this scheme achieves the technical effect of separating control and forwarding functions and efficient collaboration of L2TP dial-up functions, while retaining the high-performance packet processing advantages of the data forwarding plane. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A flowchart illustrating a network tunnel dialing method provided in an embodiment of this application; Figure 2 A schematic diagram of the architecture of a network tunnel dialing method provided as an exemplary embodiment of this application; Figure 3 This is a schematic diagram of the structure of a network tunnel dialing device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] The embodiments of this application are described in detail below, with examples of these embodiments illustrated in the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0014] The terms "first" and "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the solution can be implemented in a different order than that illustrated or described in this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0015] Although network devices based on user-space packet processing frameworks (such as VPP) have extremely high data forwarding performance, they essentially only implement the functions of the data plane and naturally lack the ability to handle the complex control signaling required for L2TP dialing (such as tunnel establishment, authentication, and PPP negotiation). As a result, they cannot automatically initiate dialing and obtain network access like conventional routers.

[0016] To address this technical problem, this application provides a network tunnel dialing method, apparatus, device, and medium to solve the technical problem in related technologies where network devices based on user-space packet processing frameworks cannot automatically establish L2TP dialing connections to obtain network access.

[0017] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0018] Figure 1 The following is a flowchart illustrating a network tunnel dialing method as an exemplary embodiment of this application. Figure 2 This is a schematic diagram of the architecture of a network tunnel dialing method provided as an exemplary embodiment of this application. This network tunnel dialing method is applicable to communication scenarios with high network throughput requirements and flexible tunnel access capabilities. For example, it is suitable for network devices such as enterprise-level edge gateways, Software Defined Wide Area Network (SD-WAN) access devices, and cloud data center egress gateways. These network devices typically act as L2TP Access Concentrators (LACs), responsible for initiating tunnel connections and encapsulating user-side traffic before transmitting it through the tunnel to the L2TP Network Server on the other end. The method includes at least the following steps: Step 110: Receive Layer 2 Tunneling Protocol (L2TP) dialing configuration information.

[0019] The network device receives dial-up configuration information based on the Layer 2 tunneling protocol (L2TP) from external input. Specifically, such as... Figure 2 As shown, network devices can receive dial-up configuration information through a User Interface Process Set (UI Process Set). The UI Process Set specifically includes interactive components such as a Command Line Interface (CLI) Server, a Web Server, and an ECS Service, used to adapt to different types of user operation interfaces. When a configuration command is received from a user, the UI request parser in the UI Process Set parses and verifies the dial-up configuration information, and then distributes the parsed configuration data to subsequent dial-up processes through the configuration management module.

[0020] Dial-up configuration information includes the set of parameters and policy rules required by network devices to establish logical connections and conduct data communication with remote network nodes. For example, it includes tunnel layer parameters required for establishing L2TP control connections and link layer authentication parameters required for establishing PPP sessions.

[0021] like Figure 2 As shown, when the user interface processing set receives an input command, it converts it into structured dialing configuration information and stores it in the configuration database (CFG-DB) through the configuration management module (tpConfig) for subsequent reading by the control plane.

[0022] More specifically, the dialing configuration information includes, but is not limited to, the following key fields: Peer address information: i.e., the IP address or domain name of the LNS; Tunnel authentication parameters: used for authentication during the L2TP tunnel handshake phase, such as tunnel name (Hostname), tunnel password (Secret), etc. Session authentication parameters: Used for user authentication during the PPP negotiation phase, such as PPP username, PPP password, and authentication protocol type (e.g., PAP, CHAP, MS-CHAPv2). Control strategy parameters: such as retransmission timeout, maximum number of retransmissions, and other protocol behavior control parameters.

[0023] Step 120: Perform L2TP negotiation and session negotiation based on dial-up configuration information through the control plane to generate negotiation status data.

[0024] Step 120 is the core signaling interaction phase for establishing an L2TP connection. Based on the received dial-up configuration information, the network device's control plane performs L2TP negotiation and session negotiation with the tunnel peer, generating negotiation state data.

[0025] L2TP negotiation and session negotiation refer to the protocol interaction process of establishing a reliable control connection and creating a data transmission channel between the dial-up client (i.e., the network device executing this method) and the L2TP network server (LNS). This process typically includes two phases: the first is the tunnel establishment phase, where both parties exchange control messages to negotiate tunnel parameters and establish a control connection; the second is the session establishment phase, where both parties further negotiate session parameters on the established control connection to create a logical channel for subsequent data transmission.

[0026] Negotiation state data is the result data generated by the control plane after completing dynamic signaling interaction. It describes the L2TP logical connection attributes between this network device and the tunnel peer, and is used to guide subsequent packet encapsulation processing. More specifically, negotiation state data includes at least: Tunnel ID: Includes Local Tunnel ID and Remote Tunnel ID, used to uniquely identify an L2TP tunnel; Session ID: Includes Local Session ID and Remote Session ID, used to uniquely identify a specific session channel within the tunnel.

[0027] like Figure 2 As shown, the control plane runs in user space, and its internal architecture may include L2TP agents (such as l2tp-proxy), L2TP protocol daemons (such as xl2tpd), and PPP protocol daemons (such as pppd).

[0028] More specifically, in step 120, firstly, the L2TP agent located in the control plane listens to the configuration database through a subscription mechanism. When the configuration management module writes the latest dial-up configuration information to the configuration database, the L2TP agent detects the configuration change and starts or schedules the underlying protocol daemon process based on this configuration information. Subsequently, the L2TP protocol daemon process (e.g., the open-source software xl2tpd) performs L2TP negotiation with the tunnel peer based on the dial-up configuration information. This L2TP negotiation process mainly includes the tunnel establishment phase, where both parties establish a reliable control connection by exchanging control messages such as SCCRQ and SCCRP. After the control connection is established, the L2TP protocol daemon process further calls the PPP protocol daemon process (e.g., the open-source software pppd) to perform session negotiation. This process is the session establishment phase, where both parties negotiate session parameters (such as LCP parameters) on the established control connection to create a logical channel for subsequent data transmission. Finally, when the above negotiation is completed, the control plane generates negotiation status data.

[0029] Since the control plane is independent of the data forwarding plane in the architecture of this application, and the control plane usually does not directly hold physical network ports, an internal communication link mechanism is introduced in this application embodiment in order to realize communication between the control plane and the external network.

[0030] In some embodiments, L2TP negotiation and session negotiation are performed by the control plane based on dialing configuration information to generate negotiation state data, including the following steps 121 to 122: Step 121: Generate an L2TP control request message through the control plane and send the L2TP control request message to the data forwarding plane through a pre-established internal communication link. The data forwarding plane then forwards the L2TP control request message to the other end of the tunnel.

[0031] Specifically, in the uplink direction (i.e., the sending direction), the L2TP protocol daemon (xl2tpd) in the control plane constructs an L2TP control request message (cp plane message) that conforms to the L2TP protocol specification according to the dialing configuration information, and sends the L2TP control request message to the internal communication link. After the data forwarding plane reads the L2TP control request message through the internal communication link, it forwards the L2TP control request message to the tunnel peer through the WAN side physical sub-interface.

[0032] Step 122: Receive L2TP response messages from the data forwarding plane through the internal communication link. The control plane performs L2TP negotiation and session negotiation, and extracts the tunnel identifier and session identifier from the negotiation results as negotiation state data.

[0033] The data forwarding plane enables bidirectional transmission of L2TP control messages by monitoring the internal communication link and the physical network port corresponding to the tunnel peer. Specifically, in the downlink direction (i.e., the receiving direction), the data forwarding plane monitors the physical network port corresponding to the tunnel peer (… Figure 2 The WAN-side physical sub-interface shown receives external packets. When a packet from the tunnel peer is identified as an L2TP control response packet, the data forwarding plane transmits the L2TP control response packet to the control plane through the internal communication link. The L2TP protocol daemon (such as xl2tpd) of the control plane parses the packet content and drives the local L2TP protocol state machine to perform state transitions.

[0034] In some embodiments, the internal communication link is a data transmission channel built on a virtual network interface, which is used to bidirectionally transmit L2TP control messages between the control plane and the data forwarding plane. For example... Figure 2 As shown, the internal communication link is a cross-space data transmission channel built based on virtual network interfaces. Specifically, the control plane holds a virtual host interface (tap-host), and the data forwarding plane holds a virtual network interface (tap0). The two achieve logical communication through a bridging mechanism in the kernel space (such as vhost-net).

[0035] A virtual network interface (such as the TAP interface provided by the Linux kernel) is a software-simulated network interface that allows user-mode applications to interact with it through the standard Socket API. The control plane can treat this virtual network interface as a standard Ethernet interface for packet reading and writing operations.

[0036] Step 130: In response to the completion of L2TP negotiation and session negotiation, network layer parameter negotiation is performed to obtain network configuration parameters.

[0037] Specifically, once the control plane detects that an L2TP session has been successfully established, it automatically triggers a network layer parameter negotiation process to interact with the tunnel peer to obtain the network configuration parameters required for network access.

[0038] Network layer parameter negotiation refers to the address allocation and parameter configuration interaction process between communicating parties to achieve network layer interoperability over an established data link layer connection. In L2TP dial-up scenarios, this process is typically carried out by the Point-to-Point Protocol (PPP) and its sub-protocol suite. Specifically, PPP negotiation usually includes the link control protocol phase, the authentication phase, and the network control protocol phase.

[0039] In this embodiment, the control plane interacts with the tunnel peer by invoking the PPP protocol daemon (pppd) to obtain the network configuration parameters required for network access. The PPP negotiation messages generated by the PPP protocol daemon are encapsulated in L2TP data packets. Since the data forwarding plane has not yet established forwarding table entries at this time, these packets are also transmitted to the data forwarding plane through the internal communication link, and then forwarded to the tunnel peer by the data forwarding plane through the WAN-side physical sub-interface.

[0040] In some embodiments, network layer parameter negotiation is performed to obtain network configuration parameters, including: The network uses a point-to-point PPP network layer protocol to negotiate and obtain at least one of the following parameters as network configuration parameters: inner network address, gateway address, domain name resolution server address, and maximum transmission unit parameter.

[0041] In this embodiment, the control plane, acting as a PPP client, sends a configuration request to the tunnel peer. The tunnel peer allocates corresponding network resources according to a preset address pool policy and sends a configuration confirmation or rejection message back to the control plane. After negotiation, the control plane extracts the network configuration parameters. These network configuration parameters refer to the set of addressing and forwarding attributes required by the network device to correctly encapsulate and route IP data packets on the logical tunnel interface.

[0042] The inner network address (Local IP Address) is the private IP address assigned to this network device by the peer of the tunnel from its IP address pool. This inner network address will serve as the source IP address (InnerSource IP) of the service packets encapsulated within the subsequent tunnel. The gateway address (Remote IP / Gateway) is the IP address of the tunnel peer on the virtual link, which is used as the default next hop in the routing table of this network device; Domain name resolution server address (DNS IP), used to resolve the primary and backup DNS server addresses for internal domain names; Maximum Transmission Unit (MTU) is the maximum packet length (e.g., 1400 bytes) allowed to pass through the tunnel interface. Since L2TP and IP headers consume additional bytes, properly negotiating the MTU parameter is crucial for preventing packet fragmentation and loss.

[0043] Step 140: Synchronize network configuration parameters and negotiation status data to the data forwarding plane, and generate corresponding L2TP tunnel interfaces and session forwarding table entries in the data forwarding plane. The control plane is independent of the data forwarding plane.

[0044] Specifically, once the control plane has completed the negotiation of all protocol layers and obtained a complete set of parameters, it needs to transform these "logical" parameters into "physical" forwarding rules that the data forwarding plane can recognize and execute.

[0045] In the embodiments of this application, the control plane (the process running the general protocol stack) and the data forwarding plane (the process running high-performance frameworks such as VPP) are isolated from each other in process space and memory space, and cannot directly share variables. Therefore, the embodiments of this application employ an asynchronous, middleware-based data synchronization mechanism to achieve coordination between the two.

[0046] In some embodiments, network configuration parameters and negotiation state data are synchronized to the data forwarding plane, and corresponding L2TP tunnel interfaces and session forwarding table entries are generated in the data forwarding plane, including the following steps 141 to 142: Step 141: Publish network configuration parameters and negotiation status data to the status storage unit through a data sharing mechanism.

[0047] In step 141, as Figure 2 As shown, the L2TP proxy module (l2tp-proxy) on the control plane side acts as the aggregation point for protocol data. It encapsulates network configuration parameters and negotiation state data (including Tunnel ID, Session ID, inner IP, gateway IP, MTU, etc.) into structured configuration messages (such as JSON or Protobuf format). Subsequently, the L2TP proxy calls the interface provided by the control transfer data access layer (tpDal) to write the configuration message into a preset state storage unit and sends a publish notification.

[0048] In some embodiments, a specific instance of the state storage unit can be a forwarding state database (ASIC-DB). A state storage unit refers to an in-memory database or key-value store that operates independently of the control plane and data forwarding plane, used to temporarily store system configuration state and runtime data. Specifically, this state storage unit can be a Redis database. Redis's high-performance read / write characteristics and publish / subscribe (Pub / Sub) mechanism are highly compatible with the real-time configuration synchronization requirements of this application embodiment. The control plane writes the negotiated data into a specific key in Redis and publishes configuration update messages through a specific channel.

[0049] Step 142: Subscribe to the synchronization data in the state storage unit using the management agent process and call the programming interface of the data forwarding plane to create an L2TP tunnel interface and session forwarding table entries in the data forwarding plane.

[0050] In step 142, as Figure 2 As shown, the management agent process (e.g., DMP-VPP) running on the data forwarding plane side maintains access to the state storage unit (i.e. Figure 2 The management agent process subscribes to the forwarding state database. Upon receiving a "configuration update" notification, it reads the latest network configuration parameters and negotiation state data from the state storage unit. Subsequently, the management agent process issues a creation command to the data forwarding plane by calling the programming interface provided by the data forwarding plane. In response to this command, the data forwarding plane instantiates specific forwarding entities in memory, mainly including: L2TP Tunnel Interface: This is a virtual network interface logically created by the data forwarding plane. For example, an L2TP tunnel interface can be named l2tp0. Functionally, the L2TP tunnel interface acts as a bridge connecting the inner network (user side) and the outer network (tunnel side). Attribute-wise, the L2TP tunnel interface is configured with a negotiated inner IP address and MTU value. From the operating system's perspective, all packets routed to this IP segment will be sent to this L2TP tunnel interface for processing. Session Forwarding Entries: This is a lookup table used by the data forwarding plane to guide how packets are encapsulated in L2TP. Structurally, this session forwarding entry maps the "destination address / interface" to the "specific encapsulation action." Specifically, this entry records which tunnel identifier (Tunnel ID) and which session identifier (Session ID) should be added to the header of a packet entering the L2TP tunnel interface, and how the packet should be directed to the WAN-side physical sub-interface for transmission.

[0051] In step 140, the network configuration parameters and negotiation state data maintained by the control plane are mapped and instantiated into local forwarding rules (i.e., interface instances and forwarding table entries) for the data forwarding plane. As a result, the data forwarding plane gains the ability to independently process L2TP service packets based on local forwarding rules, decoupling the control plane signaling interaction path from the data plane packet forwarding path. Subsequent forwarding processing of service packets does not require control plane intervention, thus ensuring the processing performance of the data plane.

[0052] Step 150: Based on the L2TP tunnel interface and session forwarding table entries, perform L2TP protocol packet encapsulation or decapsulation processing of service packets in the data forwarding plane.

[0053] Step 150 is the steady-state service data transmission phase after the L2TP dial-up connection is established. Specifically, after receiving the service packet, the data forwarding plane performs corresponding tunnel protocol header processing on the service packet according to the generated L2TP tunnel interface and session forwarding table entries, realizing transparent transmission of inner private network packets in the public network tunnel.

[0054] To clearly describe the data stream processing logic, this embodiment will explain it from both the uplink (sending) and downlink (receiving) directions.

[0055] In some embodiments, based on the L2TP tunnel interface and session forwarding table entries, L2TP protocol packet encapsulation or decapsulation processing of service packets is performed in the data forwarding plane, including the following steps 151 to 152: Step 151: In the uplink direction, the service message is sent to the L2TP tunnel interface according to the session forwarding table entry. At the L2TP tunnel interface, the L2TP session header and outer transport header are encapsulated according to the negotiation state data, and the encapsulated service message is forwarded to the L2TP tunnel peer.

[0056] Specifically, the processing flow for step 151 is as follows: Route lookup and NAT handling: such as Figure 2 As shown, when the data forwarding plane receives a raw IP service packet from the inner network through the LAN-side physical sub-interface, it first performs a route lookup. If the route matching result points to the L2TP tunnel interface created in step 140, the packet is sent to that L2TP tunnel interface for processing. Message encapsulation: The L2TP tunnel interface adds an encapsulation header sequentially before the original IP service packet based on the associated session forwarding table entries. This encapsulation header specifically includes: L2TP session header: contains the negotiated peer tunnel identifier (Remote Tunnel ID) and peer session identifier (Remote Session ID), used to inform the peer which session the packet belongs to; Outer transport header: typically includes a UDP header (source port / destination port is usually 1701) and an outer IP header (source IP is the local physical IP, destination IP is the tunnel peer's LNS IP). Physical forwarding: After encapsulation, the packet is regarded as a standard public IP packet (or data plane packet). The data forwarding plane schedules it to the physical sub-interface on the WAN side and finally sends it to the other end of the tunnel.

[0057] Step 152: In the downlink direction, the outer transport header and L2TP session header of the L2TP message received from the other end of the L2TP tunnel are stripped to obtain the decapsulated service message. The decapsulated service message is then forwarded to the inner network according to the session forwarding table entry.

[0058] Specifically, the processing flow for step 152 is as follows: Message identification: The data forwarding plane monitors the physical sub-interface on the WAN side. When it receives a data packet from the tunnel peer that matches the L2TP protocol (e.g., UDP port 1701), it intercepts and processes it. Packet decapsulation: The data forwarding plane looks up the corresponding session forwarding table entry based on the Local Tunnel ID and Local Session ID in the packet. If a match is found, decapsulation is performed to remove the outer IP header, UDP header, and L2TP session header, restoring the original inner service packet. Internal forwarding: The restored service message is re-injected into the routing module of the data forwarding plane, performs a route lookup based on the inner destination IP address, and is finally forwarded to the corresponding inner network interface (such as the user-side LAN port) LAN-side physical sub-interface, thereby delivering it to the intranet user equipment.

[0059] Through step 150, the network device achieves full-speed forwarding of L2TP service packets by utilizing the high-performance pipeline of the data forwarding plane (such as VPP) without relying on the control plane, thus completing the closed loop of the entire network tunnel dialing method.

[0060] This application provides a scheme for receiving L2TP dial-up configuration information; performing L2TP negotiation and session negotiation based on the dial-up configuration information through the control plane to generate negotiation status data; responding to the completion of L2TP negotiation and session negotiation, performing network layer parameter negotiation to obtain network configuration parameters; synchronizing the network configuration parameters and negotiation status data to the data forwarding plane, and generating corresponding L2TP tunnel interfaces and session forwarding table entries in the data forwarding plane, wherein the control plane is independent of the data forwarding plane; and performing L2TP protocol packet encapsulation or decapsulation processing of service packets in the data forwarding plane based on the L2TP tunnel interfaces and session forwarding table entries. By introducing a control plane independent of the data forwarding plane to undertake the dynamic signaling negotiation tasks of L2TP and network layer protocols, and synchronizing the negotiated network configuration parameters and status data to the data forwarding plane to drive the generation of forwarding interfaces and table entries, this scheme achieves the technical effect of separating control and forwarding functions and efficient collaboration of L2TP dial-up functions, while retaining the high-performance packet processing advantages of the data forwarding plane.

[0061] Figure 3 A schematic diagram of the structure of a network tunnel dialing device provided for an exemplary embodiment of this application; The device includes: Receiving unit 31 is used to receive Layer 2 Tunneling Protocol (L2TP) dialing configuration information; The first negotiation unit 32 is used to perform L2TP negotiation and session negotiation based on dialing configuration information through the control plane, and generate negotiation status data. The second negotiation unit 33 is used to perform network layer parameter negotiation in response to the completion of L2TP negotiation and session negotiation, and obtain network configuration parameters. Synchronization unit 34 is used to synchronize network configuration parameters and negotiation status data to the data forwarding plane, and generate corresponding L2TP tunnel interfaces and session forwarding table entries in the data forwarding plane. The control plane is independent of the data forwarding plane. The processing unit 35 is used to perform L2TP protocol message encapsulation or decapsulation processing of service messages in the data forwarding plane based on the L2TP tunnel interface and session forwarding table entries. In some embodiments, when the first negotiation unit 32 is used to perform L2TP negotiation and session negotiation based on dialing configuration information through the control plane and generate negotiation state data, it is specifically used for: The L2TP control request message is generated by the control plane and sent to the data forwarding plane through a pre-established internal communication link. The data forwarding plane then forwards the L2TP control request message to the other end of the tunnel. The L2TP response message is received from the data forwarding plane through the internal communication link. The control plane performs L2TP negotiation and session negotiation, and extracts the tunnel identifier and session identifier from the negotiation result as negotiation state data.

[0062] In some embodiments, the internal communication link is a data transmission channel built on a virtual network interface, which is used to transmit L2TP control messages bidirectionally between the control plane and the data forwarding plane.

[0063] In some embodiments, when the second negotiation unit 33 is used to perform network layer parameter negotiation to obtain network configuration parameters, it is specifically used for: The network uses a point-to-point PPP network layer protocol to negotiate and obtain at least one of the following parameters as network configuration parameters: inner network address, gateway address, domain name resolution server address, and maximum transmission unit parameter.

[0064] In some embodiments, when the synchronization unit 34 synchronizes network configuration parameters and negotiation state data to the data forwarding plane, and generates corresponding L2TP tunnel interfaces and session forwarding table entries in the data forwarding plane, it is specifically used for: Network configuration parameters and negotiation status data are published to the status storage unit through a data sharing mechanism; The management agent process subscribes to the synchronization data in the state storage unit and calls the programming interface of the data forwarding plane to create an L2TP tunnel interface and session forwarding table entries in the data forwarding plane.

[0065] In some embodiments, when processing unit 35 performs L2TP protocol packet encapsulation or decapsulation processing of service packets in the data forwarding plane based on the L2TP tunnel interface and session forwarding table entries, it is specifically used for: In the uplink direction, the service message is sent to the L2TP tunnel interface according to the session forwarding table entry. At the L2TP tunnel interface, the L2TP session header and outer transport header are encapsulated according to the negotiation state data, and the encapsulated service message is forwarded to the L2TP tunnel peer. In the downlink direction, the L2TP packets received from the other end of the L2TP tunnel are stripped of their outer transport header and L2TP session header to obtain decapsulated service packets. The decapsulated service packets are then forwarded to the inner network according to the session forwarding table entries.

[0066] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, they will not be repeated here. Specifically, the device can execute the above method embodiments, and the foregoing and other operations and / or functions of each module in the device correspond to the corresponding processes in the various methods in the above method embodiments, which will not be repeated here for the sake of brevity.

[0067] The apparatus of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application can be completed by integrated logic circuits in the processor's hardware and / or by software instructions. The steps of the method disclosed in this application embodiment can be directly embodied as being executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0068] Figure 4 This is a schematic block diagram of an electronic device provided in an embodiment of this application. The electronic device may include: The system includes a memory 401 and a processor 402. The memory 401 stores computer programs and transfers the program code to the processor 402. In other words, the processor 402 can retrieve and run the computer programs from the memory 401 to implement the methods described in the embodiments of this application.

[0069] For example, the processor 402 can be used to execute the above-described method embodiments according to instructions in the computer program.

[0070] In some embodiments of this application, the processor 402 may include, but is not limited to: General-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0071] In some embodiments of this application, the memory 401 includes, but is not limited to: Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0072] In some embodiments of this application, the computer program may be divided into one or more modules, which are stored in the memory 401 and executed by the processor 402 to perform the method provided in this application. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.

[0073] like Figure 4 As shown, the electronic device may also include: Transceiver 403, which can be connected to processor 402 or memory 401.

[0074] The processor 402 can control the transceiver 403 to communicate with other devices; specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 403 may include a transmitter and a receiver. The transceiver 403 may further include antennas, and the number of antennas may be one or more.

[0075] It should be understood that the various components in the electronic device are connected through a bus system, which includes a data bus, a power bus, a control bus, and a status signal bus.

[0076] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, embodiments of this application also provide a computer program product containing instructions that, when executed by a computer, cause the computer to perform the methods of the above-described method embodiments.

[0077] When implemented using software, it can be implemented entirely or partially as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0078] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0079] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0080] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0081] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0082] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A network tunnel dialing method, characterized in that, include: Receive Layer 2 Tunneling Protocol (L2TP) dial-up configuration information; The control plane performs L2TP negotiation and session negotiation based on the dialing configuration information, and generates negotiation status data. In response to the completion of the L2TP negotiation and the session negotiation, network layer parameter negotiation is performed to obtain network configuration parameters; The network configuration parameters and the negotiation status data are synchronized to the data forwarding plane, and corresponding L2TP tunnel interfaces and session forwarding table entries are generated in the data forwarding plane. The control plane is independent of the data forwarding plane. Based on the L2TP tunnel interface and session forwarding table entries, L2TP protocol packet encapsulation or decapsulation processing of service packets is performed in the data forwarding plane.

2. The method according to claim 1, characterized in that, The process of performing L2TP negotiation and session negotiation based on the dialing configuration information through the control plane, and generating negotiation status data, includes: The control plane generates an L2TP control request message and sends it to the data forwarding plane via a pre-established internal communication link. The data forwarding plane then forwards the L2TP control request message to the tunnel peer. The L2TP response message from the data forwarding plane is received through the internal communication link. The control plane performs L2TP negotiation and session negotiation, and extracts the tunnel identifier and session identifier from the negotiation result as the negotiation state data.

3. The method according to claim 2, characterized in that, The internal communication link is a data transmission channel built on a virtual network interface, which is used to transmit L2TP control messages bidirectionally between the control plane and the data forwarding plane.

4. The method according to claim 1, characterized in that, The network layer parameter negotiation process yields network configuration parameters, including: The network configuration parameters are obtained by interacting with the other end of the tunnel using the Point-to-Point Protocol (PPP) network layer protocol to negotiate and obtain at least one of the following: inner network address, gateway address, domain name resolution server address, and maximum transmission unit parameter.

5. The method according to claim 1, characterized in that, The step of synchronizing the network configuration parameters and the negotiation state data to the data forwarding plane, and generating corresponding L2TP tunnel interfaces and session forwarding table entries in the data forwarding plane, includes: The network configuration parameters and the negotiation status data are published to the status storage unit through a data sharing mechanism. The management agent process subscribes to the synchronization data in the state storage unit and calls the programming interface of the data forwarding plane to create the L2TP tunnel interface and session forwarding table entries in the data forwarding plane.

6. The method according to claim 1, characterized in that, The process of performing L2TP protocol packet encapsulation or decapsulation of service packets in the data forwarding plane based on the L2TP tunnel interface and session forwarding table entries includes: In the uplink direction, the service message is sent to the L2TP tunnel interface according to the session forwarding table entry. At the L2TP tunnel interface, the L2TP session header and outer transport header are encapsulated according to the negotiation state data, and the encapsulated service message is forwarded to the peer of the L2TP tunnel. In the downlink direction, the L2TP packets received from the peer of the L2TP tunnel are stripped of their outer transport header and L2TP session header to obtain decapsulated service packets. The decapsulated service packets are then forwarded to the inner network according to the session forwarding table entries.

7. A network tunnel dialing device, characterized in that, include: The receiving unit is used to receive Layer 2 Tunneling Protocol (L2TP) dialing configuration information; The first negotiation unit is used to perform L2TP negotiation and session negotiation based on the dialing configuration information through the control plane, and generate negotiation status data. The second negotiation unit is used to perform network layer parameter negotiation in response to the completion of the L2TP negotiation and the session negotiation to obtain network configuration parameters; The synchronization unit is used to synchronize the network configuration parameters and the negotiation status data to the data forwarding plane, and generate the corresponding L2TP tunnel interface and session forwarding table entries in the data forwarding plane, wherein the control plane is independent of the data forwarding plane; The processing unit is used to perform L2TP protocol packet encapsulation or decapsulation processing of service packets in the data forwarding plane based on the L2TP tunnel interface and session forwarding table entries.

8. The apparatus according to claim 7, characterized in that, When the first negotiation unit performs L2TP negotiation and session negotiation based on the dialing configuration information through the control plane and generates negotiation state data, it is specifically used for: The control plane generates an L2TP control request message and sends it to the data forwarding plane via a pre-established internal communication link. The data forwarding plane then forwards the L2TP control request message to the tunnel peer. The L2TP response message from the data forwarding plane is received through the internal communication link. The control plane performs L2TP negotiation and session negotiation, and extracts the tunnel identifier and session identifier from the negotiation result as the negotiation state data.

9. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the method of any one of claims 1-6 by executing the executable instructions.

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

Images