CN108111385B - Message forwarding method and device - Google Patents
Message forwarding method and device Download PDFInfo
- Publication number
- CN108111385B CN108111385B CN201711463958.4A CN201711463958A CN108111385B CN 108111385 B CN108111385 B CN 108111385B CN 201711463958 A CN201711463958 A CN 201711463958A CN 108111385 B CN108111385 B CN 108111385B
- Authority
- CN
- China
- Prior art keywords
- tunnel
- mapping table
- l2tp
- source
- tunnel source
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2854—Wide area networks, e.g. public data networks
- H04L12/2856—Access arrangements, e.g. Internet access
- H04L12/2858—Access network architectures
- H04L12/2859—Point-to-point connection between the data network and the subscribers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2854—Wide area networks, e.g. public data networks
- H04L12/2856—Access arrangements, e.g. Internet access
- H04L12/2869—Operational details of access network equipments
- H04L12/287—Remote access server, e.g. BRAS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/74—Address processing for routing
Abstract
The application provides a message forwarding method and a message forwarding device. In the application, the BRAS device checks that a tunnel source IP mapping table item matched with a first data message exists in a local tunnel source IP mapping table item, and encapsulates the first data message according to a mapping IP address indicated by the tunnel source IP mapping table item and forwards the first data message through the L2TP tunnel, so that the tunnel source IP addresses in the L2TP tunnel header encapsulated by all data messages on the L2TP tunnel are not all the IP addresses of the BRAS device, and even if the intermediate network device on the L2TP tunnel finds multiple equivalent routes to forward data messages, the intermediate network device can also forward the data messages according to a route load sharing mode because the tunnel source IP addresses in the L2TP tunnel header encapsulated by the data messages are different.
Description
Technical Field
The present application relates to network communication technologies, and in particular, to a method and an apparatus for forwarding a packet.
Background
The two-Layer Tunneling Protocol (L2 TP: Layer 2 Tunneling Protocol) is one of Virtual Private Dial-up Network (VPDN: Virtual Private Dial-up Network) Tunneling protocols. The L2TP establishes an L2TP tunnel on a public network (e.g., the Internet) to enable a remote user (e.g., an enterprise outside agency and a business trip person) to access the public network by using a Point-to-Point Protocol (PPP) and then communicate with an enterprise internal network through the L2TP tunnel to access an enterprise internal network resource, thereby implementing the remote user to safely, economically and effectively access a private enterprise network.
After the L2TP tunnel is established, a Session (Session) for carrying on the L2TP tunnel may be further established. The same L2TP tunnel carries at least one Session.
Disclosure of Invention
The application provides a message forwarding method and a message forwarding device, so as to realize that intermediate network equipment on an L2TP tunnel forwards a data message according to a route load sharing mode.
The technical scheme provided by the application comprises the following steps:
a message forwarding method is applied to broadband remote access server BRAS equipment, and comprises the following steps:
receiving a first data message;
determining that the first data message is forwarded through an established L2TP tunnel between the device and an opposite terminal device, and checking whether a tunnel source IP mapping table entry matched with the first data message exists in a local tunnel source IP mapping table;
if yes, the first data message is packaged according to the mapping IP address indicated by the tunnel source IP mapping table item and is forwarded through the L2TP tunnel.
A message forwarding device is applied to Broadband Remote Access Server (BRAS) equipment and comprises:
a receiving unit, configured to receive a first data packet;
a determining unit, configured to determine whether the first data packet is forwarded through an L2TP tunnel established between the local device and an opposite-end device;
a tunnel unit, configured to check whether a tunnel source IP mapping table entry matching the first data packet exists in a local tunnel source IP mapping table if a determination result of the determination unit is yes; if yes, the first data message is packaged according to the mapping IP address indicated by the tunnel source IP mapping table item and is forwarded through the L2TP tunnel.
A network device, comprising: a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor; the processor is configured to execute the machine executable instructions to implement the methods described above.
A machine-readable storage medium having stored thereon machine-executable instructions which, when invoked and executed by a processor, cause the processor to carry out the method described above.
It can be seen from the above technical solutions that, in the present application, the BRAS device checks that a tunnel source IP mapping table entry matching the first data packet exists in the local tunnel source IP mapping table, the first data packet is encapsulated according to the mapping IP address indicated by the tunnel source IP mapping table entry and forwarded through the L2TP tunnel, rather than collectively setting the tunnel source IP address in the first data-messaging L2TP tunnel header as the IP address of the device, this achieves that the tunnel source IP address in the L2TP tunnel header encapsulated by all data packets on the L2TP tunnel is not all the IP address of the present BRAS device, even if the intermediate network device on the L2TP tunnel finds multiple equivalent routes to forward the data packet, the intermediate network device can forward the data packet according to the route load sharing mode because the tunnel source IP addresses in the L2TP tunnel header encapsulated by the data packet are different.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure.
Fig. 1 is a schematic diagram of application networking provided in the present application;
FIG. 2 is a flow chart of a method provided herein;
fig. 3 is a flowchart of generating a tunnel source IP mapping table according to an embodiment of the present application;
fig. 4 is a flowchart of another tunnel source IP mapping table generation provided in the embodiment of the present application;
FIG. 5 is a flow chart of a method provided by one embodiment of the present application;
FIG. 6 is a flow chart of another method provided by an embodiment of the present application;
FIG. 7 is a flow chart of a method provided by another embodiment of the present application;
FIG. 8 is a flow chart of another method provided by another embodiment of the present application;
FIG. 9 is a schematic diagram of the apparatus provided herein;
fig. 10 is a schematic structural diagram of a hardware device provided in the present application.
Detailed Description
In a networking (L2TP networking for short) applied to L2TP, a Network between an L2TP tunnel two-end device, such as an L2TP Access Concentrator (LAC: L2TP Access Concentrator) and an L2TP Network Server LNS (L2TP Network Server) shown in fig. 1, is generally a three-layer Network. Thus, even if an end device of the L2TP tunnel encapsulates the L2TP tunnel header for the data packet before forwarding the data packet through the L2TP tunnel, when the data packet reaches an intermediate device of the L2TP tunnel, such as a ROUTER (ROUTER) shown in fig. 1, if the ROUTER finds multiple equivalent routes to forward the data packet, the ROUTER performs a hash operation according to the L2TP tunnel source IP address and the L2TP tunnel destination IP address of the data packet encapsulation, but because all data packets carried on the same L2TP tunnel have the same L2TP tunnel source IP address and the same L2TP tunnel destination IP address in the L2TP tunnel header, the ROUTER always selects a fixed route to forward all data packets carried on the same L2TP tunnel, and thus the intermediate network device of the L2TP tunnel cannot forward the data packet in a route load manner.
Based on this, in the present application, in order to implement that the intermediate network device in the L2TP tunnel forwards the data packet according to the route load sharing manner, when the data packet is forwarded through the L2TP tunnel, the tunnel source IP address in the L2TP tunnel header encapsulated by the data packet is modified, which is specifically shown in the flow illustrated in fig. 2.
Referring to fig. 2, fig. 2 is a flow chart of a method provided by the present application. The process is applied to a Broadband Remote Access Server (BRAS) device. Here, the BRAS device is an end device of the L2TP tunnel, such as an LAC, or an LNS, and the present application is not limited in particular.
As shown in fig. 2, the process may include the following steps:
As an embodiment, the first data packet is a PPPOE data packet.
As an embodiment, in this step 202, determining that the first data packet is forwarded through the established L2TP tunnel between the local device and the peer device includes:
step a1, judging whether the first data message hits the local authentication list item, when the first data message hits the local authentication list item, determining that the first data message is legal, and executing step a 2.
It should be noted that, in this step a1, when the first data packet does not hit the local authentication entry, it is determined that the first data packet is illegal, and the first data packet may be directly discarded. The fact that the first data packet misses the local authentication entry is not the key point of the present application, and a description thereof is not repeated.
As an embodiment, if the BRAS device is an LAC, the local authentication entry is a PPPOE user entry. The structure of the PPPOE user table entry is similar to the existing PPPOE user table entry, and is not repeated.
As another embodiment, if the BRAS device is an LNS, the local authentication entry is a FIB entry. The structure of the FIB table entry is similar to that of the existing FIB table entry, and is not described in detail.
Step a2, determining an L2TP tunnel ID according to an L2TP tunnel association identifier in a local authentication entry, searching a corresponding L2TP tunnel encapsulation entry in a locally generated L2TP tunnel encapsulation table according to the L2TP tunnel ID and a Session ID carried by the first data packet, and if the corresponding L2TP tunnel encapsulation entry is found, determining that the first data packet is forwarded through an L2TP tunnel which is established between the local device and an opposite device and corresponds to the L2TP tunnel ID.
So far, through the step a1 and the step a2, it can be determined that the first data packet is forwarded through the established L2TP tunnel between the device and the opposite device.
As an embodiment, in this step 202, checking whether a tunnel source IP mapping table entry matching the first data packet exists in a locally generated tunnel source IP mapping table includes:
step b1, checking whether a tunnel source IP mapping table entry which contains the determined L2TP tunnel ID of the L2TP tunnel, the Session ID carried by the first data message and is of the first specified type exists in the local tunnel source IP mapping table; if yes, go to step b2, otherwise go to step b 3.
Step b2, determining that there is a tunnel source IP mapping table entry matching the first data packet in the locally generated tunnel source IP mapping table.
Step b3, determining that there is no tunnel source IP mapping table entry matching the first data packet in the locally generated tunnel source IP mapping table.
As an embodiment, in this step 202, if it is determined that a tunnel source IP mapping table entry matching the first data packet does not exist in a locally generated tunnel source IP mapping table, the tunnel source IP mapping table entry is directly forwarded through the L2TP tunnel.
In one example, the tunnel source IP mapping table may be preconfigured.
In another example, the tunnel source IP mapping table may be dynamically generated prior to performing the method. How to dynamically generate is described below by a specific embodiment, which will not be described here for the moment.
In this application, each tunnel source IP mapping table entry in the tunnel source IP mapping table is used to indicate a tunnel source IP address (denoted as a mapping IP address) in an L2TP tunnel header encapsulated when a data packet matched with the tunnel source IP mapping table is forwarded through an L2TP tunnel.
This step 203 is executed on the premise that a tunnel source IP mapping table entry matching the first data packet exists in the local tunnel source IP mapping table.
In one example, the step 203 is specifically: and encapsulating the first data packet according to an existing L2TP tunnel header encapsulation mechanism, where a tunnel source IP address in an L2TP tunnel header is an IP address of the device, such as a Loopback (Loopback) address, and a tunnel destination IP address is an IP address of an opposite device, such as a Loopback (Loopback) address, and then modifying the tunnel source IP address in the L2TP tunnel header encapsulated by the first data packet to a mapping IP address indicated in the source IP mapping table entry and forwarding through the L2TP tunnel.
In another example, the step 203 is specifically: and encapsulating the first data packet according to a tunnel header encapsulation mechanism similar to the existing L2TP, where a tunnel source IP address in a tunnel header of the L2TP is a mapping IP address indicated in the source IP mapping table entry, and a tunnel destination IP address is an IP address of an opposite-end device, such as a Loopback (Loopback) address, and then forwarding the first data packet encapsulated with the tunnel header of the L2TP through the L2TP tunnel.
It can be seen from step 203 that, in this application, if the BRAS device detects that a tunnel source IP mapping table entry matching the first data packet exists in the local tunnel source IP mapping table, the first data packet is encapsulated according to the mapping IP address indicated by the tunnel source IP mapping table entry and forwarded through the L2TP tunnel, which achieves that the tunnel source IP addresses in the L2TP tunnel header encapsulated by all data packets on the L2TP tunnel are not all the IP addresses of the BRAS device, so that even if there are multiple equivalent routes for forwarding data packets, the intermediate network device on the L2TP tunnel selects different routes due to different tunnel source IP addresses in the L2TP tunnel header encapsulated by the data packets, and the intermediate network device on the L2TP tunnel forwards the data packets in a route load sharing manner.
It should be noted that, the flow shown in fig. 2 takes receiving the first data packet through the local non-L2 TP tunnel port as an example, where if the BRAS device is used as the LAC, the local non-L2 TP tunnel port may be a user-side port, and if the BRAS device is used as the LNS, the local non-L2 TP tunnel port may be an IP port.
It should be further noted that, in this application, the BRAS device may further receive, through the local L2TP tunnel portal, a data packet (denoted as a second data packet) encapsulating the L2TP tunnel header, and when the BRAS device receives, through the local L2TP tunnel portal, the second data packet encapsulating the L2TP tunnel header, check whether a tunnel source IP mapping table entry matching the second data packet exists in a locally generated tunnel source IP mapping table; and if so, decapsulating the tunnel header of the L2TP encapsulated by the second data message and forwarding the decapsulated data message.
As an embodiment, the checking whether there is a tunnel source IP mapping table entry matching the second data message in the locally generated tunnel source IP mapping table includes:
and c1, parsing the Session ID from the second data message, and parsing the L2TP tunnel ID and the L2TP tunnel source IP address from the L2TP tunnel header encapsulated by the second data message.
As an embodiment, the second data packet is also a PPPOE data packet, and carries a Session ID. Based on this, step c1 is easy to parse the Session ID from the second data message.
Step c2, if the local L2TP decapsulation table entry is missed according to the parsed L2TP tunnel source IP address, L2TP tunnel ID, and Session ID, checking whether a tunnel source IP mapping table entry which contains the parsed L2TP tunnel source IP address, L2TP tunnel ID, Session ID, and is of a second specified type exists in the locally generated tunnel source IP mapping table, and if so, determining that a tunnel source IP mapping table entry which matches the second data message exists in the locally generated tunnel source IP mapping table; if not, determining that the tunnel source IP mapping table item matched with the second data message does not exist in the locally generated tunnel source IP mapping table.
It should be noted that, in this step c2, if the local L2TP decapsulation table entry is hit according to the parsed L2TP tunnel ID and Session ID, the L2TP tunnel header encapsulated by the second data message is decapsulated directly, and the decapsulated data message is forwarded.
Finally, the step c1 and the step c2 are implemented to check whether there is a tunnel source IP mapping table entry matching the second data message in the locally generated tunnel source IP mapping table.
How the tunnel source IP mapping table is dynamically generated is described in detail below:
as described above, in the present application, the BRAS device is an end device of the L2TP tunnel, such as an LAC, or an LNS, and how to generate the tunnel source IP mapping table is described below by taking the BRAS device as the LAC as an example.
Referring to fig. 3, fig. 3 is a flowchart for generating a tunnel source IP mapping table according to an embodiment of the present application. In this embodiment, the BRAS device is an LAC, and on the premise that the BRAS device is the LAC, in this embodiment, the opposite end device of the BRAS device is an LNS. The operation of generating the tunnel source IP mapping table entry by the flow shown in fig. 3 mainly includes:
after the L2TP tunnel between the LAC and the opposite end device LNS is successfully established, if a user is found to be online, a corresponding mapping IP address is allocated to T1 and S1, a tunnel source IP mapping table entry of a first specified type is generated according to T1, S1 and the mapping IP addresses corresponding to T1 and S1, where T1 is: the LAC assigns a one-end tunnel ID to the successfully established L2TP tunnel, and S1 is: LAC is a Session ID which is loaded on the L2TP tunnel which is successfully established and is distributed by the Session associated with the online user; the T2 is as follows: the LNS allocates the tunnel ID of the other end to the L2TP tunnel which is successfully established; and the number of the first and second groups,
receiving T2, S2 and mapping IP addresses corresponding to T2, S2 fed back by the peer device LNS, and generating a tunnel source IP mapping table entry of a second specified type according to the received T2, S2 and mapping IP addresses corresponding to T2, S2, where S2 is: and the LNS is the Session ID which is loaded on the L2TP tunnel successfully established and is distributed to the Session associated with the online user at the other end.
The flow is described in detail below:
as shown in fig. 3, the process may include the following steps:
In one example, T2 is: the LNS assigns an end tunnel ID to the successfully established L2TP tunnel, and S1 assigns an end Session ID to the Session carried by the LAC in the successfully established L2TP tunnel. Here, the Session carried over the successfully established L2TP tunnel described above is associated with an online user.
As an embodiment, in the present invention, the sending of T2 and S1 by the LAC to the LNS may specifically be: the LAC carries the T2 and S1 in an ICRQ message and sends the ICRQ message to the LNS. Specifically, LAC carries T2 in the L2TP tunnel header of the ICRQ packet, and carries S1 in the AVP field of the ICRQ packet and sends it to the LNS.
When LAC sends ICRQ message to LNS, LNS will receive ICRQ message, when LNS receives ICRQ message, it analyzes T2, S1 from ICRQ message, and determines this LNS as the other end Session ID (marked as S2) allocated by the Session carried on the successfully established L2TP tunnel. Then, LNS assigns a corresponding IP address (mapping IP address for short, denoted as IP2) to the determined T2, S2. As an embodiment, the LNS may calculate an IP address (abbreviated as a mapping IP address, denoted as IP2) according to a preset algorithm and by combining T2 and S2. Then, the LNS generates a tunnel source IP mapping table entry (denoted as tunnel source IP mapping table entry 30) with the type being the first specified type according to T2, S2 and the IP2 corresponding to T2 and S2. Here, the first specified type is used to indicate that the tunnel source IP mapping table entry is generated locally, and is identified by L. Table 1 specifically shows the structure of the tunnel source IP mapping table entry 30:
TABLE 1
The LNS also feeds back T2 and S2, and IP2 corresponding to T2 and S2 to the LAC. As an embodiment, in the present application, the LNS may carry T2, S2, and IP2 corresponding to T2, S2 in an ICRP message (taking an AVP field carried in the ICRP message as an example), and send the icr to the LAC. Step 302 is then performed.
In step 302, the LAC receives T2 and S2 fed back by the LNS and the IP2 corresponding to T2 and S2, generates a tunnel source IP mapping table entry (denoted as tunnel source IP mapping table entry 40) with the second specified type according to the received T2 and S2 and the IP2 corresponding to T2 and S2, and executes step 303.
As described above, the LNS may carry the T2, S2, and the IP2 corresponding to T2, S2 in an ICRP packet and send the ICRP packet to the LAC. Thus, when the LAC receives the ICRP packet, T2 and S2 and IP2 corresponding to T2 and S2 are parsed from the ICRP packet. And then generating a tunnel source IP mapping table entry (denoted as tunnel source IP mapping table entry 40) with the second specified type according to the received T2, S2 and the IP2 corresponding to T2 and S2. The second specified type is used to indicate that the tunnel source IP mapping table entry is sent remotely, and is identified by R. Table 2 shows the structure of the tunnel source IP mapping table entry 40:
TABLE 2
It should be noted that, in the present application, the LNS further feeds back T1, S1 to the LAC. Wherein S1 is determined by the LNS based on S1 sent by the LAC in the above step 301, and T1 is the other end tunnel ID of the L2TP tunnel indicated by T2 determined by the LNS based on T2 sent by the LAC in the above step 301. When the LAC receives T1, S1, step 303 is executed.
In step 303, the LAC allocates a corresponding IP address (abbreviated as a mapping IP address, denoted as IP1) to the received T1 and S1, and generates a tunnel source IP mapping table entry (denoted as tunnel source IP mapping table entry 41) of the first specified type according to the T1, S1 and the IP1 corresponding to the T1 and S1.
In this embodiment, the LAC may calculate an IP address (abbreviated as a mapping IP address, denoted as IP1) according to a predetermined algorithm and by combining T1 and S1. Then, the LAC generates a tunnel source IP mapping table entry (denoted as tunnel source IP mapping table entry 41) of the first specified type according to the T1, S1 and the IP1 corresponding to the T1 and S1. Here, the first specified type is used to indicate that the tunnel source IP mapping table entry is generated locally, and is identified by L. Based on table 2, table 3 specifically shows the structure of the tunnel source IP mapping table entry 41:
TABLE 3
As an embodiment, the operation of generating the tunnel source IP mapping table entry 41 in this step 303 may also be performed in the above step 301. Compared with the generation of the tunnel source IP mapping table entry 41 in step 301, the generation of the tunnel source IP mapping table entry 41 after receiving T2 and S2 after step 301 can ensure that the generated tunnel source IP mapping table entry 41 is usable because: if the tunnel source IP mapping table entry 41 is generated in step 301, and if T1, S1 sent in step 301 does not reach the LNS, the generated tunnel source IP mapping table entry 41 is useless, wasting the entry resources.
Thus, the LAC may generate the tunnel source IP mapping table entry according to the operations in the above steps 301 to 303, thereby realizing the generation of the tunnel source IP mapping table.
The flow shown in fig. 3 is completed.
In step 303, the LAC may further feed back T1, S1, and IP1 corresponding to T1, S1 to the LNS. As an embodiment, in the present application, the LAC may carry the T1, S1, and the IP1 corresponding to the T1, S1 in an ICCN message and send the ICCN message to the LNS. When the LNS receives T1, S1 and the IP1 corresponding to T1, S1 fed back by the LAC, a tunnel source IP mapping table entry (denoted as tunnel source IP mapping table entry 31) with a type of a second specified type is generated according to the received T1, S1 and the IP1 corresponding to T1, S1, where the second specified type is used to indicate that the tunnel source IP mapping table entry is sent remotely and is identified by R. Based on the tunnel source IP mapping table entry 30 shown in table 1, table 4 shows the structure of the tunnel source IP mapping table entry 31:
TABLE 4
In the above, taking the BRAS device as LAC as an example to describe how to generate the tunnel source IP mapping table, in the following, taking the BRAS device as LNS as an example to describe how to generate the tunnel source IP mapping table:
referring to fig. 4, fig. 4 is a flowchart of generating another tunnel source IP mapping table according to an embodiment of the present application. In this embodiment, the BRAS device is an LNS, and on the premise that the BRAS device is an LNS, in this embodiment, the opposite end device of the BRAS device is an LAC. The tunnel source IP mapping table generation process shown in fig. 4 mainly includes: after the L2TP tunnel between the LNS and the opposite-end device LAC is successfully established, receiving T1 and S1 sent by the opposite-end device LAC after the user is online and mapping IP addresses corresponding to T1 and S1, and generating a tunnel source IP mapping table entry of a second specified type according to the received T1 and S1 and the mapping IP addresses corresponding to T1 and S1; the T1 is as follows: the LAC assigns a one-end tunnel ID to the successfully established L2TP tunnel, and S1 is: LAC is a Session ID which is loaded on the L2TP tunnel which is successfully established and is distributed by the Session associated with the online user; and the number of the first and second groups,
allocating a corresponding mapping IP address for T2 and S2, and generating a tunnel source IP mapping table entry with a first specified type according to T2 and S2 and the mapping IP address corresponding to T2 and S2; the T2 is as follows: the LNS assigns a tunnel ID of the other end to the successfully established L2TP tunnel, where S2 is: and the LNS is the Session ID which is loaded on the L2TP tunnel successfully established and is distributed to the Session associated with the online user at the other end.
The flow shown in fig. 4 is described in detail below:
as shown in fig. 4, the process shown in fig. 4 specifically includes:
in step 401, the LNS receives T2 and S1 sent by the LAC, determines that the LNS allocates another Session ID (denoted as S2) for the Session indicated by S1 according to S1, allocates a corresponding IP address (abbreviated as a mapping IP address, denoted as IP2) for T2 and S2, and generates a tunnel source IP mapping table entry (denoted as tunnel source IP mapping table entry 30) with the type of the first specified type according to T2 and S2 and the IP2 corresponding to T2 and S2.
This step 401 is referred to above as step 301, and will not be described in detail here.
In step 402, LNS feeds back T2, S2, and IP2 corresponding to T2, S2 to LAC.
This step 402 feeds back T2, S2, and the IP2 corresponding to T2, S2 to the LAC for the purpose of facilitating the LAC to generate the tunnel source IP mapping table entry as shown by tunnel source IP mapping table entry 40.
In step 403, the LNS receives T1 and S1 fed back by the LAC and the IP1 corresponding to T1 and S1, and generates a tunnel source IP mapping table entry (denoted as tunnel source IP mapping table entry 31) with the second specified type according to the received T1 and S1 and the IP1 corresponding to T1 and S1.
The structure of the tunnel source IP mapping table entry 31 is shown in table 4, and will not be described in detail.
Therefore, the LNS can generate the tunnel source IP mapping table entry according to the operations from step 401 to step 43, and the generation of the tunnel source IP mapping table is realized.
The flow shown in fig. 4 is completed.
The generation of the tunnel source IP mapping table is described above.
The flow shown in fig. 2 is described below by two embodiments based on the tunnel source IP mapping table described above:
in one embodiment:
referring to fig. 5, fig. 5 is a flowchart of a method provided by an embodiment of the present application. In this embodiment, a BRAS device is taken as an LAC, and an opposite end device of the BRAS device is taken as an LNS as an example to describe:
as shown in fig. 5, the process may include the following steps:
in step 501, the LAC receives a data message (denoted as message 50) through the local user-side port.
In this step 504, the tunnel source IP address in the encapsulated L2TP tunnel header is the IP address of the LAC, and the tunnel destination IP address is the IP address of the opposite end device LNS.
This step 505 is performed on the premise that it is determined in the above step 504 that the determined L2TP tunnel ID and the Session ID carried in the packet 50 exist and the type is the first specified type of tunnel IP mapping table entry, and if the existing tunnel IP mapping table entry is the tunnel source IP mapping table entry 41 shown in the above table 3, in this step 505, the LAC modifies the tunnel source IP address in the L2TP tunnel header to the IP address, i.e., IP1, in the tunnel IP mapping table entry 41 and forwards the modified tunnel IP address through the L2TP tunnel corresponding to the L2TP tunnel ID. As described above, the IP1 is calculated by the LAC according to T1 and S1 and according to a certain algorithm, and is not the IP address of the LAC, so that all data packets forwarded through the L2TP tunnel are not the IP address of the LAC, but the IP addresses can be the IP addresses calculated according to the algorithm, and thus, even if the intermediate network device on the L2TP tunnel finds that there are multiple equivalent routes to forward the data packets, different routes are selected because the tunnel source IP addresses in the L2TP tunnel header encapsulated by the data packets are different, and the intermediate network device on the L2TP tunnel forwards the data packets according to the route load sharing manner.
The flow shown in fig. 5 is completed.
The flow shown in fig. 5 is described by taking the example that LAC sends data messages through L2TP tunnel. When the LAC receives the data packet encapsulated with the L2TP tunnel header sent by the correspondent device LNS through the L2TP tunnel portal, it may execute the procedure shown in fig. 6.
Referring to fig. 6, fig. 6 is a flow chart of another method provided by an embodiment of the present application. In one embodiment of the present application, a BRAS device is taken as an LAC, and a peer device of the BRAS device is taken as an LNS, for example, to describe:
as shown in fig. 6, the process may include the following steps:
in step 601, the LAC receives a data packet (denoted as packet 60) through the local L2TP tunnel portal.
The message 60 is specifically a PPPOE data message encapsulated with an L2TP tunnel header.
In this step 603, when it is determined that the L2TP tunnel decapsulation table entry is not hit according to the parsed L2TP tunnel ID and Session ID, it indicates that the L2TP tunnel source IP address in the L2TP tunnel header encapsulated by the packet 60 may be modified when the opposite end device LNS sends the packet 60, so step 604 needs to be further executed.
In this step 604, when the LAC checks that the local tunnel source IP mapping table has the analyzed L2TP tunnel source IP address, L2TP tunnel ID, Session ID, and the type of the tunnel IP mapping table entry is the second specified type, it indicates that the opposite device LNS modifies the L2TP tunnel source IP address in the L2TP tunnel header encapsulated by the packet 60 when sending the packet 60, and then the L2TP tunnel source IP address in the L2TP tunnel header encapsulated by the packet 60 may be replaced with the IP address of the opposite device LNS, and then it is determined whether the L2TP tunnel decapsulation table entry is hit according to the L2TP tunnel ID, the Session ID, and the replaced tunnel source IP address, and if yes, step 605 is executed.
Finally, the decapsulation of the packet 60 is implemented by the flow shown in fig. 6.
The flow shown in fig. 6 is completed.
One of the embodiments is described above, and another of the embodiments is described below:
in another embodiment thereof:
the BRAS device is used as an LNS, and the opposite end device of the BRAS device is used as an LAC.
Referring to fig. 7, fig. 7 is a flowchart of a method provided in another embodiment of the present application. As shown in fig. 7, the process may include the following steps:
in step 701, LNS receives a data packet (denoted as packet 70) through a non-L2 TP tunnel portal.
In step 702, LNS determines whether message 70 hits FIB table entries, and if not, discards message 70 directly, and if so, performs step 703.
In step 703, the LNS determines an L2TP tunnel ID according to the L2TP tunnel association identifier in the FIB table entry hit by the packet 50, determines whether the L2TP tunnel encapsulation table entry is hit according to the determined L2TP tunnel ID and the Session ID carried in the packet 70, and if the L2TP tunnel encapsulation table entry is hit, executes step 704, and if the L2TP tunnel encapsulation table entry is not hit, forwards the packet 70 in a non-L2 TP tunnel manner.
In this step 704, the tunnel source IP address in the encapsulated L2TP tunnel header is the IP address of the present LNS, and the tunnel destination IP address is the IP address of the opposite-end device LAC.
This step 705 is performed on the premise that it is determined in the above step 704 that the determined L2TP tunnel ID and the Session ID carried in the packet 70 exist and the tunnel IP mapping table entry of the type is the first specified type, and if the existing tunnel IP mapping table entry is the tunnel source IP mapping table entry 30 shown in the above table 4, in this step 705, the LNS modifies the tunnel source IP address in the L2TP tunnel header to the IP address, i.e., IP2, in the tunnel IP mapping table entry 30 and forwards the modified tunnel IP address through the L2TP tunnel corresponding to the L2TP tunnel ID. As described above, the IP2 is calculated by the LNS according to T2 and S2 and according to a certain algorithm, and is not the IP address of the present LNS, so that it is realized that all data packets forwarded through the L2TP tunnel are not the IP address of the present LNS, but the IP addresses can be the IP addresses calculated according to the algorithm, and thus, even if the intermediate network device on the L2TP tunnel finds that there are multiple equivalent routes to forward the data packets, different routes are selected because the tunnel source IP addresses in the L2TP tunnel header encapsulated by the data packets are different, and the intermediate network device on the L2TP tunnel forwards the data packets according to the route load sharing manner.
The flow shown in fig. 7 is completed.
The flow shown in fig. 7 is described by taking an example where the LNS sends the data packet through the L2TP tunnel. When the LNS receives the data packet encapsulated with the L2TP tunnel header sent by the opposite end device LAC through the L2TP tunnel portal, it may execute the procedure shown in fig. 8.
Referring to fig. 8, fig. 8 is a flow chart of another method provided in another embodiment of the present application. As shown in fig. 8, the process may include the following steps:
in step 801, the LNS receives a data packet (denoted as packet 80) through the local L2TP tunnel portal.
The message 80 is specifically a PPPOE data message encapsulating the L2TP tunnel header.
In step 802, LNS determines whether message 80 hits in the FIB table, and if not, discards it directly, and if so, performs step 803.
In this step 803, when it is determined that the L2TP tunnel decapsulation table entry is missed according to the parsed L2TP tunnel ID and Session ID, it indicates that the opposite device LAC may modify the L2TP tunnel source IP address in the L2TP tunnel header encapsulated by the packet 80 when sending the packet 80, so step 804 needs to be further executed.
In this step 804, when the LNS checks that the local tunnel source IP mapping table has the analyzed L2TP tunnel source IP address, L2TP tunnel ID, Session ID, and the type of the tunnel IP mapping table is the second specified type, it indicates that the peer device LAC modifies the L2TP tunnel source IP address in the L2TP tunnel header encapsulated by the packet 80 when sending the packet 80, and then the L2TP tunnel source IP address in the L2TP tunnel header encapsulated by the packet 80 can be replaced with the IP address of the peer device LAC, and then it is determined whether the L2TP tunnel decapsulation table is hit according to the L2TP tunnel ID, the Session ID, and the replaced tunnel source IP address, and if so, step 805 is executed.
Finally, the decapsulation of the packet 80 is implemented by the flow shown in fig. 8.
The flow shown in fig. 8 is completed.
The methods provided herein are described above. The following describes the apparatus provided in the present application:
referring to fig. 9, fig. 9 is a diagram of the structure of the apparatus according to the present application. The device is applied to BRAS equipment, and comprises:
a receiving unit, configured to receive a first data packet;
a determining unit, configured to determine whether the first data packet is forwarded through an L2TP tunnel established between the local device and an opposite-end device;
a tunnel unit, configured to check whether a tunnel source IP mapping table entry matching the first data packet exists in a local tunnel source IP mapping table if a determination result of the determination unit is yes; if yes, the first data message is packaged according to the mapping IP address indicated by the tunnel source IP mapping table item and is forwarded through the L2TP tunnel.
As an embodiment, the checking, by the tunnel unit, whether a tunnel source IP mapping table entry matching the first data packet exists in a local tunnel source IP mapping table includes:
checking whether a local tunnel source IP mapping table item which contains the L2TP tunnel ID of the L2TP tunnel, the Session ID carried by the first data message and is of a first specified type exists;
if yes, determining that a tunnel source IP mapping table item matched with the first data message exists in a local tunnel source IP mapping table;
if not, determining that the tunnel source IP mapping table item matched with the first data message does not exist in the local tunnel source IP mapping table.
As an embodiment, the encapsulating, by the tunnel unit, the first data packet according to the mapping IP address indicated by the source IP mapping table entry includes:
and encapsulating the tunnel source IP address in the first data message into an L2TP tunnel header of the mapping IP address.
As an embodiment, the receiving unit further receives a second data packet encapsulating the L2TP tunnel header through the local L2TP tunnel portal;
the tunnel unit further checks whether a tunnel source IP mapping table entry matched with the second data message exists in a local tunnel source IP mapping table; and if so, decapsulating the tunnel header of the L2TP encapsulated by the second data message and forwarding the decapsulated data message.
As an embodiment, the checking, by the tunnel unit, whether a tunnel source IP mapping table entry matching the second data message exists in a local tunnel source IP mapping table includes:
parsing a Session ID from the second data message and parsing an L2TP tunnel ID from an L2TP tunnel header encapsulated by the second data message;
if the local L2TP decapsulation table entry is missed according to the parsed L2TP tunnel ID and Session ID, parsing an L2TP tunnel source IP address from an L2TP tunnel header encapsulated by a second data message, and checking whether a tunnel source IP mapping table entry which contains the parsed L2TP tunnel source IP address, the parsed L2TP tunnel ID and the Session ID and has a second specified type exists in the local tunnel source IP mapping table;
if yes, determining that a tunnel source IP mapping table item matched with the second data message exists in a local tunnel source IP mapping table;
if not, determining that the tunnel source IP mapping table item matched with the second data message does not exist in the local tunnel source IP mapping table.
Thus, the structure of the apparatus shown in fig. 9 is completed.
The hardware apparatus provided in the present application is described below:
referring to fig. 10, fig. 10 is a block diagram of a hardware device provided in the present application. As shown in fig. 10, includes: a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor; the processor is configured to execute the machine executable instructions to implement the message forwarding method as described above.
In the present application, a machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and the like. For example, the machine-readable storage medium may be: random Access Memory (RAM), volatile Memory, non-volatile Memory, flash Memory, a storage drive (e.g., a hard drive), a solid state drive, any type of storage disk (e.g., an optical disk, dvd, etc.), or similar storage media, or a combination thereof.
Thus, the description of the hardware configuration shown in fig. 10 is completed.
Also provided in this application is a machine-readable storage medium, such as the machine-readable storage medium in fig. 10, comprising machine-executable instructions that are executable by a processor in a memory access device to implement the message forwarding method described above.
Specifically, the processor may execute the operations in the above message forwarding method by calling and executing a machine executable instruction corresponding to the memory access method in the machine readable storage medium.
The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.
Claims (14)
1. A message forwarding method is characterized in that the method is applied to Broadband Remote Access Server (BRAS) equipment and comprises the following steps:
receiving a first data message;
determining that the first data packet is forwarded through an established L2TP tunnel between the local device and an opposite device, and checking whether a tunnel source IP mapping table entry matched with the first data packet exists in a local tunnel source IP mapping table, where the local tunnel source IP mapping table at least includes a tunnel source IP mapping table entry of a first specified type and a tunnel source IP mapping table entry of a second specified type, the first specified type is used to indicate that the tunnel source IP mapping table entry of the type is locally generated, and the second specified type is used to indicate that the tunnel source IP mapping table entry of the type is sent remotely;
if yes, the first data message is packaged according to the mapping IP address indicated by the tunnel source IP mapping table item and is forwarded through the L2TP tunnel.
2. The method of claim 1, wherein the checking whether a tunnel source IP mapping table entry matching the first datagram exists in a local tunnel source IP mapping table comprises:
checking whether a local tunnel source IP mapping table item which contains the L2TP tunnel ID of the L2TP tunnel, the Session ID carried by the first data message and is of a first specified type exists;
if yes, determining that a tunnel source IP mapping table item matched with the first data message exists in a local tunnel source IP mapping table;
if not, determining that the tunnel source IP mapping table item matched with the first data message does not exist in the local tunnel source IP mapping table.
3. The method of claim 1, wherein encapsulating the first data packet according to the mapping IP address indicated by the tunnel source IP mapping table entry comprises:
and encapsulating the tunnel source IP address in the first data message into an L2TP tunnel header of the mapping IP address.
4. The method of claim 1, further comprising:
receiving a second data message which encapsulates the tunnel header of the L2TP through a local L2TP tunnel portal;
checking whether a tunnel source IP mapping table item matched with the second data message exists in a local tunnel source IP mapping table;
and if so, decapsulating the tunnel header of the L2TP encapsulated by the second data message and forwarding the decapsulated data message.
5. The method of claim 4, wherein the checking whether there is a tunnel source IP mapping entry in the local tunnel source IP mapping table for which the second data message matches comprises:
parsing a Session ID from the second data message and parsing an L2TP tunnel ID from an L2TP tunnel header encapsulated by the second data message;
if the local L2TP decapsulation table entry is missed according to the parsed L2TP tunnel ID and Session ID, parsing an L2TP tunnel source IP address from an L2TP tunnel header encapsulated by a second data message, and checking whether a tunnel source IP mapping table entry which contains the parsed L2TP tunnel source IP address, the parsed L2TP tunnel ID and the Session ID and has a second specified type exists in the local tunnel source IP mapping table;
if yes, determining that a tunnel source IP mapping table item matched with the second data message exists in a local tunnel source IP mapping table;
if not, determining that the tunnel source IP mapping table item matched with the second data message does not exist in the local tunnel source IP mapping table.
6. The method of any of claims 1 to 5, wherein the BRAS device accesses a concentrator LAC for L2 TP;
the tunnel source IP mapping table entry in the local tunnel source IP mapping table is generated by the following steps before the method:
after the L2TP tunnel between the LAC and the opposite end device LNS is successfully established, if a user is found to be online, a corresponding mapping IP address is allocated to T1 and S1, a tunnel source IP mapping table entry of a first specified type is generated according to T1, S1 and the mapping IP addresses corresponding to T1 and S1, where T1 is: the LAC assigns a one-end tunnel ID to the successfully established L2TP tunnel, and S1 is: LAC is a Session ID which is loaded on the L2TP tunnel which is successfully established and is distributed by the Session associated with the online user;
receiving T2, S2 and mapping IP addresses corresponding to T2, S2 fed back by the peer device LNS, and generating a tunnel source IP mapping table entry of a second specified type according to the received T2, S2 and mapping IP addresses corresponding to T2, S2, where T2 is: the LNS allocates the tunnel ID of the other end to the L2TP tunnel which is successfully established; the S2 is as follows: and the LNS is the Session ID which is loaded on the L2TP tunnel successfully established and is distributed to the Session associated with the online user at the other end.
7. The method according to any of claims 1 to 5, characterized in that the BRAS device is an L2TP network server LNS;
the tunnel source IP mapping table entry in the local tunnel source IP mapping table is generated by the following steps before the method:
after the L2TP tunnel between the LNS and the opposite-end device LAC is successfully established, receiving T1 and S1 sent by the opposite-end device LAC after the user is online and mapping IP addresses corresponding to T1 and S1, and generating a tunnel source IP mapping table entry of a second specified type according to the received T1 and S1 and the mapping IP addresses corresponding to T1 and S1; the T1 is as follows: the LAC assigns a one-end tunnel ID to the successfully established L2TP tunnel, and S1 is: LAC is a Session ID which is loaded on the L2TP tunnel which is successfully established and is distributed by the Session associated with the online user;
allocating a corresponding mapping IP address for T2 and S2, and generating a tunnel source IP mapping table entry with a first specified type according to T2 and S2 and the mapping IP address corresponding to T2 and S2; the T2 is as follows: the LNS assigns a tunnel ID of the other end to the successfully established L2TP tunnel, where S2 is: and the LNS is the Session ID which is loaded on the L2TP tunnel successfully established and is distributed to the Session associated with the online user at the other end.
8. A message forwarding device is applied to a Broadband Remote Access Server (BRAS) device, and comprises:
a receiving unit, configured to receive a first data packet;
a determining unit, configured to determine whether the first data packet is forwarded through an L2TP tunnel established between the local device and an opposite-end device;
a tunnel unit, configured to check whether a tunnel source IP mapping table entry matching the first data packet exists in a local tunnel source IP mapping table if a determination result of the determination unit is yes; if so, encapsulating the first data message according to the mapping IP address indicated by the tunnel source IP mapping table entry and forwarding the first data message through the L2TP tunnel, where the local tunnel source IP mapping table at least includes a tunnel source IP mapping table entry of a first specified type and a tunnel source IP mapping table entry of a second specified type, the first specified type is used to indicate that the tunnel source IP mapping table entry of the type is locally generated, and the second specified type is used to indicate that the tunnel source IP mapping table entry of the type is sent remotely.
9. The apparatus of claim 8, wherein the tunnel unit checking a local tunnel source IP mapping table for a tunnel source IP mapping table entry matching the first datagram comprises:
checking whether a local tunnel source IP mapping table item which contains the L2TP tunnel ID of the L2TP tunnel, the Session ID carried by the first data message and is of a first specified type exists;
if yes, determining that a tunnel source IP mapping table item matched with the first data message exists in a local tunnel source IP mapping table;
if not, determining that the tunnel source IP mapping table item matched with the first data message does not exist in the local tunnel source IP mapping table.
10. The apparatus of claim 8, wherein the tunnel unit encapsulating the first data packet according to the mapping IP address indicated by the tunnel source IP mapping table entry comprises:
and encapsulating the tunnel source IP address in the first data message into an L2TP tunnel header of the mapping IP address.
11. The apparatus of claim 8, wherein the receiving unit further receives a second datagram encapsulating a tunnel header of L2TP through a local L2TP tunnel portal;
the tunnel unit further checks whether a tunnel source IP mapping table entry matched with the second data message exists in a local tunnel source IP mapping table; and if so, decapsulating the tunnel header of the L2TP encapsulated by the second data message and forwarding the decapsulated data message.
12. The apparatus of claim 11, wherein the tunnel unit checking a local tunnel source IP mapping table for a tunnel source IP mapping entry matching the second data message comprises:
parsing a Session ID from the second data message and parsing an L2TP tunnel ID from an L2TP tunnel header encapsulated by the second data message;
if the local L2TP decapsulation table entry is missed according to the parsed L2TP tunnel ID and Session ID, parsing an L2TP tunnel source IP address from an L2TP tunnel header encapsulated by a second data message, and checking whether a tunnel source IP mapping table entry which contains the parsed L2TP tunnel source IP address, the parsed L2TP tunnel ID and the Session ID and has a second specified type exists in the local tunnel source IP mapping table;
if yes, determining that a tunnel source IP mapping table item matched with the second data message exists in a local tunnel source IP mapping table;
if not, determining that the tunnel source IP mapping table item matched with the second data message does not exist in the local tunnel source IP mapping table.
13. A network device, comprising: a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor; the processor is configured to execute the machine-executable instructions to implement the method of any of claims 1-7.
14. A machine-readable storage medium having stored thereon machine-executable instructions which, when invoked and executed by a processor, cause the processor to implement the method of any of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711463958.4A CN108111385B (en) | 2017-12-28 | 2017-12-28 | Message forwarding method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711463958.4A CN108111385B (en) | 2017-12-28 | 2017-12-28 | Message forwarding method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108111385A CN108111385A (en) | 2018-06-01 |
| CN108111385B true CN108111385B (en) | 2021-04-27 |
Family
ID=62214266
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711463958.4A Active CN108111385B (en) | 2017-12-28 | 2017-12-28 | Message forwarding method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108111385B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109981409B (en) * | 2019-03-26 | 2021-05-07 | 新华三技术有限公司 | Message forwarding method, device and forwarding equipment |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101478479A (en) * | 2008-12-31 | 2009-07-08 | 华为技术有限公司 | User access method, apparatus and system |
| CN102752221A (en) * | 2012-07-23 | 2012-10-24 | 杭州华三通信技术有限公司 | Method and device for sharing load of data message used for L2TP (layer 2 tunneling protocol) networking |
| CN103166846A (en) * | 2013-03-27 | 2013-06-19 | 杭州华三通信技术有限公司 | Message forwarding method and device |
| CN103368806A (en) * | 2012-03-26 | 2013-10-23 | 华为技术有限公司 | Method and system for processing data flow and device |
| US9577927B2 (en) * | 2014-06-30 | 2017-02-21 | Nicira, Inc. | Encoding control plane information in transport protocol source port field and applications thereof in network virtualization |
| CN107046503A (en) * | 2017-04-24 | 2017-08-15 | 新华三技术有限公司 | A kind of message transmitting method, system and its apparatus |
-
2017
- 2017-12-28 CN CN201711463958.4A patent/CN108111385B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101478479A (en) * | 2008-12-31 | 2009-07-08 | 华为技术有限公司 | User access method, apparatus and system |
| CN103368806A (en) * | 2012-03-26 | 2013-10-23 | 华为技术有限公司 | Method and system for processing data flow and device |
| CN102752221A (en) * | 2012-07-23 | 2012-10-24 | 杭州华三通信技术有限公司 | Method and device for sharing load of data message used for L2TP (layer 2 tunneling protocol) networking |
| CN103166846A (en) * | 2013-03-27 | 2013-06-19 | 杭州华三通信技术有限公司 | Message forwarding method and device |
| US9577927B2 (en) * | 2014-06-30 | 2017-02-21 | Nicira, Inc. | Encoding control plane information in transport protocol source port field and applications thereof in network virtualization |
| CN107046503A (en) * | 2017-04-24 | 2017-08-15 | 新华三技术有限公司 | A kind of message transmitting method, system and its apparatus |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108111385A (en) | 2018-06-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107104872B (en) | Access control method, device and system | |
| JP5648737B2 (en) | Communication apparatus and communication method | |
| KR101379112B1 (en) | Layer 2 seamless site extension of enterprises in cloud computing | |
| CN107995052B (en) | Method and apparatus for common control protocol for wired and wireless nodes | |
| JP5485403B2 (en) | Scalable architecture for enterprise expansion in cloud topologies | |
| US20220078114A1 (en) | Method and Apparatus for Providing Service for Traffic Flow | |
| US7633921B2 (en) | Mobile network automatic tunnels | |
| CN107046506B (en) | Message processing method, flow classifier and service function example | |
| WO2015074394A1 (en) | Method and device for message forwarding | |
| JP7228030B2 (en) | Package transmission method, package reception method and network device | |
| CN109412927B (en) | Multi-VPN data transmission method and device and network equipment | |
| US11418434B2 (en) | Securing MPLS network traffic | |
| WO2017016473A1 (en) | Tunnel detection method, apparatus, and system | |
| WO2014166073A1 (en) | Packet forwarding method and network device | |
| WO2014026571A1 (en) | Method and device for sending generic routing encapsulation tunnel message | |
| Farinacci et al. | Rfc 6830: The locator/id separation protocol (lisp) | |
| CN103067411B (en) | Prevent the DoS attack method and apparatus in DS-Lite networking | |
| CN108111385B (en) | Message forwarding method and device | |
| WO2012041168A1 (en) | Processing method for network connection for ipv6 network and device thereof | |
| CN113746715B (en) | Method and device for realizing cross-three-layer transmission of two-layer message | |
| CN105591929B (en) | Lightweight dual stack group authentication method off the net and device | |
| CN103024096A (en) | Method quickly accessing internet in carrier-grade network address translation (CGN) network | |
| CN105592057B (en) | Lightweight dual stack group safe Enhancement Method off the net and device | |
| WO2017161876A1 (en) | Method and device implementing network access | |
| CN115333859B (en) | IPsec protocol message encryption and decryption method based on chip scheme |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |