Communication method and device

Abstract

The invention provides a communication method and device, and the method comprises the steps: transmitting a first protocol message to second network equipment through a GRE tunnel; when a first data message or a second protocol message sent by a second network device is received through the GRE tunnel, determining that the current state of the GRE tunnel is an up state; wherein the first protocol message comprises a first IP header and a first type, and the second protocol message comprises a second IP header and a second type; the source address included in the first IP header is the same as the destination address included in the second IP header, and the destination address included in the first IP header is the same as the source address included in the second IP header; the first type indicates that the first protocol message is a keepalive request message, and the second type indicates that the second protocol message is a keepalive request message or a keepalive response message.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a communication method and device. Background Art

[0002] Tunneling is an encapsulation technology that transmits data packets of one network protocol through another network protocol. That is, a network protocol encapsulates data packets of other network protocols in packets specified by its own protocol and then transmits them in the network. The path for encapsulated data packets to be transmitted in the network is called a tunnel.

[0003] Generic Routing Encapsulation (GRE) tunnel is a common tunnel protocol. A GRE tunnel is a virtual point-to-point connection. The network devices at both ends of the GRE tunnel encapsulate and decapsulate the data packets to be transmitted.

[0004] The GRE keepalive function is used to ensure the reliability and stability of the GRE tunnel. The keepalive function's sending period and maximum number of sending times can be configured under the GRE tunnel interface. After the keepalive function is enabled on the GRE tunnel interface, the network device will send keepalive messages from the GRE tunnel interface according to the sending period. If no response is received from the GRE tunnel peer after the maximum number of keepalive messages have been sent consecutively, the status of the GRE tunnel interface on this end will be set to the down state. After the GRE tunnel interface is down, the GRE tunnel can no longer forward data packets and can only send keepalive messages.

[0005] In summary, the existing GRE keepalive function exposes the following problems: 1) The existing keepalive message includes two layers of IP headers and a GRE header. The source address and destination address of the inner IP header are the destination address and source address of the outer IP header, and the source address and destination address of the outer IP header are the source address and destination address of the local GRE tunnel. There is redundancy in the keepalive message information, which will cause additional bandwidth consumption; 2) The existing GRE keepalive function only supports IPv4 GRE keepalive function, and does not support IPv6 GRE keepalive function; 3) If the forwarding performance of the network device degrades and causes packet loss, at this time, the keepalive message has a probability of being discarded, increasing the probability of the GRE tunnel being falsely reported as down. Summary of the invention

[0006] In view of this, the present application provides a communication method and device to solve the problems of keepalive message redundancy in the existing GRE keepalive function, resulting in additional bandwidth consumption, non-support of IPv6 GRE keepalive function, and GRE tunnel being falsely reported as down.

[0007] In a first aspect, the present application provides a communication method, the method being applied to a first network device, a GRE tunnel having been established between the first network device and a second network device, the method comprising:

[0008] Sending a first protocol message to the second network device through the GRE tunnel;

[0009] When a first data message or a second protocol message sent by the second network device is received through the GRE tunnel, determining that the current state of the GRE tunnel is an up state;

[0010] The first protocol message includes a first IP header and a first type, and the second protocol message includes a second IP header and a second type; the source address included in the first IP header is the same as the destination address included in the second IP header, and the destination address included in the first IP header is the same as the source address included in the second IP header; the first type indicates that the first protocol message is a keepalive request message, and the second type indicates that the second protocol message is a keepalive request message or a keepalive response message;

[0011] The IP header includes an IPv4 header or an IPv6 header; the GRE tunnel includes an IPv4 GRE tunnel or an IPv6 GRE tunnel; the keepalive request message includes an IPv4 keepalive request message or an IPv6 keepalive request message; the keepalive response message includes an IPv4 keepalive response message or an IPv6 keepalive response message.

[0012] In a second aspect, the present application provides a communication device, the device is applied to a first network device, a GRE tunnel has been established between the first network device and a second network device, the device includes: a sending unit, a receiving unit and a determining unit;

[0013] The sending unit is used to send the first protocol message to the second network device through the GRE tunnel;

[0014] The determining unit is configured to determine that the current state of the GRE tunnel is an up state when the receiving unit receives the first data message or the second protocol message sent by the second network device through the GRE tunnel;

[0015] The first protocol message includes a first IP header and a first type, and the second protocol message includes a second IP header and a second type; the source address included in the first IP header is the same as the destination address included in the second IP header, and the destination address included in the first IP header is the same as the source address included in the second IP header; the first type indicates that the first protocol message is a keepalive request message, and the second type indicates that the second protocol message is a keepalive request message or a keepalive response message;

[0016] The IP header includes an IPv4 header or an IPv6 header; the GRE tunnel includes an IPv4 GRE tunnel or an IPv6 GRE tunnel; the keepalive request message includes an IPv4 keepalive request message or an IPv6 keepalive request message; the keepalive response message includes an IPv4 keepalive response message or an IPv6 keepalive response message.

[0017] In a third aspect, the present application provides a network device, including a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method provided in the first aspect of the present application.

[0018] Therefore, by applying the communication method and apparatus provided by the present application, a first network device sends a first protocol message to a second network device through a GRE tunnel; when a first data message or a second protocol message sent by the second network device is received through the GRE tunnel, the first network device determines that the current state of the GRE tunnel is an up state; wherein the first protocol message includes a first IP header and a first type, and the second protocol message includes a second IP header and a second type; the source address included in the first IP header is the same as the destination address included in the second IP header, and the destination address included in the first IP header is the same as the source address included in the second IP header; the first type indicates that the first protocol message is a keepalive request message, and the second type indicates that the second protocol message is a keepalive request message or a keepalive response message; the above-mentioned IP header includes an IPv4 header or an IPv6 header; the above-mentioned GRE tunnel includes an IPv4 GRE tunnel or an IPv6 GRE tunnel; the above-mentioned keepalive request message includes an IPv4 keepalive request message or an IPv6 keepalive request message; the above-mentioned keepalive response message includes an IPv4 Keepalive response packet or IPv6 keepalive response packet.

[0019] In this way, by reducing the number of IP headers and carrying the message type, the protocol message is sent to the other end of the GRE tunnel, so that after receiving the protocol message, the other end can determine that the current state of the GRE tunnel is up; the local end can also determine that the current state of the GRE tunnel is up after receiving the message sent by the other end. Therefore, the bandwidth is saved during the transmission of the protocol message, the GRE keepalive function is supported, and the probability of the GRE tunnel being falsely reported as down is reduced. At the same time, it also solves the problems of keepalive message redundancy in the existing GRE keepalive function, resulting in additional bandwidth consumption, non-support of the IPv6 GRE keepalive function, and the GRE tunnel being falsely reported as down. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 A flow chart of a communication method provided in an embodiment of the present application;

[0021] Figure 2 A GRE tunnel application networking diagram provided for an embodiment of the present application;

[0022] Figure 3 A schematic diagram of the format of a keepalive message provided in an embodiment of the present application;

[0023] Figure 4AA schematic diagram of another keepalive message format provided in an embodiment of the present application;

[0024] Figure 4B A schematic diagram of the format of another keepalive message provided in an embodiment of the present application;

[0025] Figure 5 A structural diagram of a communication device provided in an embodiment of the present application;

[0026] Figure 6 The network device hardware structure provided in the embodiment of the present application. DETAILED DESCRIPTION

[0027] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0028] The terms used in this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in this article refers to and includes any or all possible combinations of one or more corresponding listed items.

[0029] It should be understood that although the terms first, second, third, etc. may be used in the present application to describe various information, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0030] The communication method provided in the embodiment of the present application is described in detail below. Figure 1 , Figure 1 A flow chart of a communication method provided in an embodiment of the present application. The method is applied to a first network device, and a GRE tunnel has been established between the first network device and a second network device. The communication method provided in an embodiment of the present application may include the following steps.

[0031] Step 110: Send a first protocol message to the second network device through the GRE tunnel;

[0032] Specifically, the first network device performs GRE tunnel configuration under the local first interface (the configured interface may also be referred to as the first GRE tunnel interface), and configures the GRE keepalive function to ensure the reliability and stability of the GRE tunnel. Among them, the GRE tunnel configuration includes configuring the source address and the destination address of the GRE tunnel, and generating the corresponding first tunnel table entry. The GRE keepalive function includes a sending period (for example, 1 to 32767 seconds, the default value is 10 seconds) and a maximum number of sending times (for example, 1 to 255, the default value is 3 times).

[0033] Similarly, the second network device also performs GRE tunnel configuration under the local second interface (the configured interface can also be called the second GRE tunnel interface), and configures the GRE keepalive function to ensure the reliability and stability of the GRE tunnel. Among them, the GRE tunnel configuration includes configuring the source address and destination address of the GRE tunnel, and generating the corresponding second tunnel table entry. The GRE keepalive function includes the sending cycle and the maximum number of sending times.

[0034] It is understandable that the source address and the destination address of the GRE tunnel configured in the first network device are opposite to the source address and the destination address of the GRE tunnel configured in the second network device. In one example, the source address of the GRE tunnel configured in the first network device is 1.1.1.1 (or 1::1), and the destination address is 2.2.2.2 (or 2::2); the source address of the GRE tunnel configured in the second network device is 2.2.2.2 (or 2::2), and the destination address is 1.1.1.1 (or 1::1).

[0035] The above-mentioned tunnel table entry includes a source address field and a destination address field. In one example, the source address field included in the first tunnel table entry stores 1.1.1.1 (or 1::1), and the destination address field stores 2.2.2.2 (or 2::2); the source address field included in the first tunnel table entry stores 2.2.2.2 (or 2::2), and the destination address field stores 1.1.1.1 (or 1::1).

[0036] After the above GRE tunnel configuration, a GRE tunnel is established between the first network device and the second network device.

[0037] The first network device generates a first protocol message, which includes a first Internet Protocol (English: Internet Protocol, abbreviated: IP) header and a first type.

[0038] The first protocol message also includes a first GRE header, the first GRE header includes a first reserved field, and the first reserved field is used to carry a first type. Wherein, the value of the first type is 1, indicating that the first protocol message is a keepalive request message.

[0039] The first IP header includes a first source address and a first destination address. The first source address and the first destination address are both the source address and the destination address previously configured under the first GRE tunnel interface. In an example, the first source address may be specifically the source address 1.1.1.1 configured under the first GRE tunnel interface; the first destination address may be specifically the destination address 2.2.2.2 configured under the first GRE tunnel interface. The above addresses may be specifically IPv4 addresses. In practical applications, the above addresses may also be specifically IPv6 addresses.

[0040] It is understandable that when generating the first protocol message, the first network device first constructs a message with a data length of 0, encapsulates the first GRE header in the outer layer of the message, and then encapsulates the first IP header in the outer layer of the first GRE header.

[0041] The first network device sends a first protocol message to the second network device through the GRE tunnel.

[0042] It should be noted that, in the embodiment of the present application, the above-mentioned IP header includes an Internet Protocol version 4 (English: Internet Protocol Version 4, abbreviated as: IPv4) header or an Internet Protocol version 6 (English:, abbreviated as: Internet Protocol Version 6, abbreviated as: IPv6) header; the above-mentioned GRE tunnel includes an IPv4 GRE tunnel or an IPv6 GRE tunnel; the above-mentioned keepalive request message includes an IPv4 keepalive request message or an IPv6keepalive request message; the above-mentioned keepalive response message includes an IPv4 keepalive response message or an IPv6keepalive response message.

[0043] Step 120: When a first data packet or a second protocol packet sent by the second network device is received through the GRE tunnel, it is determined that the current state of the GRE tunnel is up.

[0044] Specifically, according to the description of step 110, after receiving the first protocol message, the second network device first obtains the first IP header, and obtains the first source address and the first destination address therefrom. According to the first source address and the second destination address, the second network device searches for a matching second tunnel entry under the second GRE tunnel interface.

[0045] If there is a matching second tunnel table entry, the second network device obtains the first type from the first GRE header and identifies the value of the first type. In the embodiment of the present application, the value of the first type is 1, and the second network device determines that the first protocol message is a keepalive request message. The second network device decapsulates the first protocol message, that is, strips the first IP header and the first GRE header from the first protocol message.

[0046] In an embodiment of the present application, through the GRE tunnel, the second network device can receive a message sent by the first network device. At this time, the second network device determines that the current state of the GRE tunnel is an online (up) state. After the second network device determines that the current state of the GRE tunnel is an up state, the second network device resets the number of detection failures of the GRE tunnel according to the current state of the GRE tunnel. In one example, the second network device resets the number of detection failures of the GRE tunnel to 0.

[0047] The up state refers to the state in which data packets can be forwarded normally, while the down state refers to the state in which data packets cannot be forwarded normally. As a protocol packet, the keepalive message is not affected by the up or down state.

[0048] At the same time, the second network device also generates a second protocol message, and the second protocol message includes a second IP header and a second type.

[0049] The second protocol message also includes a second GRE header, the second GRE header includes a second reserved field, and the second reserved field is used to carry the second type. Wherein, the value of the second type is 0, indicating that the second protocol message is a keepalive response message.

[0050] The second IP header includes a second source address and a second destination address. The second source address and the second destination address are both the source address and the destination address previously configured under the second GRE tunnel interface. In an example, the second source address may be specifically the source address 2.2.2.2 (or 2::2) configured under the second GRE tunnel interface; the second destination address may be specifically the destination address 1.1.1.1 (or 1::1) configured under the second GRE tunnel interface.

[0051] It is understandable that when generating the second protocol message, the second network device first constructs a message with a data length of 0, encapsulates the second GRE header on the outer layer of the message, and then encapsulates the second IP header on the outer layer of the second GRE header.

[0052] The second network device sends the second protocol message to the first network device through the GRE tunnel.

[0053] After receiving the second protocol message, the first network device determines that the message sent by the second network device can be received through the GRE tunnel, and further determines that the current state of the GRE tunnel is up.

[0054] In an embodiment of the present application, the second network device can also send a first data packet through the GRE tunnel. When the first network device receives the first data packet through the GRE tunnel, the first network device determines that the packet sent by the second network device can be received through the GRE tunnel, and further determines that the current state of the GRE tunnel is up.

[0055] It can be understood that the first data message specifically refers to a message whose data length is not 0.

[0056] The first data message may be sent before or after the second protocol message. No matter which message the first network device receives through the GRE tunnel, the first network device may determine that the current state of the GRE tunnel is up.

[0057] In an embodiment of the present application, the value of the second type included in the second protocol message may also be 1, indicating that the second protocol message is a keepalive request message. At this time, the second protocol message sent by the second network device is not a response message corresponding to the first protocol message. That is, after the second network device receives the keepalive request message sent by the first network device, it also initiates a keepalive detection of the GRE tunnel.

[0058] Optionally, in an embodiment of the present application, after the first network device determines that the current state of the GRE tunnel is up, the first network device resets the number of detection failures of the GRE tunnel according to the current state of the GRE tunnel. In one example, the first network device resets the number of detection failures of the GRE tunnel to 0.

[0059] Optionally, in the embodiment of the present application, the process also includes a process in which the first network device receives a third protocol message sent by the second network device through the GRE tunnel.

[0060] Specifically, the second network device generates a third protocol message according to the aforementioned process of generating a protocol message, and the third protocol message includes a third IP header and a third type.

[0061] The third protocol message also includes a third GRE header, the third GRE header includes a third reserved field, and the third reserved field is used to carry the third type. Wherein, the value of the first type is 1, indicating that the third protocol message is a keepalive request message.

[0062] The third IP header includes a third source address and a third destination address. The third source address and the third destination address are both the source address and the destination address previously configured under the second GRE tunnel interface. In an example, the third source address may be specifically the source address 2.2.2.2 (or 2::2) configured under the second GRE tunnel interface; the third destination address may be specifically the destination address 1.1.1.1 configured under the second GRE tunnel interface. (Or 1::1) The above addresses may be specifically IPv4 addresses. In practical applications, the above addresses may also be specifically IPv6 addresses.

[0063] It is understandable that when generating the third protocol message, the second network device first constructs a message with a data length of 0, encapsulates the third GRE header on the outer layer of the message, and then encapsulates the third IP header on the outer layer of the third GRE header.

[0064] The second network device sends a third protocol message to the first network device through the GRE tunnel.

[0065] After receiving the third protocol message, the first network device first obtains the third IP header, and obtains the third source address and the third destination address from it. According to the third source address and the third destination address, the first network device searches for a matching first tunnel entry under the first GRE tunnel interface.

[0066] If there is a matching first tunnel table entry, the first network device obtains the third type from the third GRE header and identifies the value of the third type. In the embodiment of the present application, the value of the third type is 1, and the first network device determines that the third protocol message is a keepalive request message. The first network device decapsulates the third protocol message, that is, strips the third IP header and the third GRE header from the third protocol message.

[0067] In an embodiment of the present application, through the GRE tunnel, the first network device can receive a message sent by the second network device. At this time, the first network device determines that the current state of the GRE tunnel is up. After the first network device determines that the current state of the GRE tunnel is up, the first network device resets the number of detection failures of the GRE tunnel according to the current state of the GRE tunnel. In one example, the first network device resets the number of detection failures of the GRE tunnel to 0.

[0068] At the same time, the first network device also generates a fourth protocol message, where the fourth protocol message includes a fourth IP header and a fourth type.

[0069] The fourth protocol message also includes a fourth GRE header, the fourth GRE header includes a fourth reserved field, and the fourth reserved field is used to carry a fourth type. The value of the fourth type is 0, indicating that the fourth protocol message is a keepalive response message.

[0070] The fourth IP header includes a fourth source address and a fourth destination address. The fourth source address and the fourth destination address are both the source address and the destination address previously configured under the first GRE tunnel interface. In an example, the fourth source address may be specifically the source address 1.1.1.1 (or 1::1) configured under the fourth GRE tunnel interface; the fourth destination address may be specifically the destination address 2.2.2.2 (or 2::2) configured under the first GRE tunnel interface.

[0071] It is understandable that when generating the fourth protocol message, the first network device first constructs a message with a data length of 0, encapsulates the fourth GRE header on the outer layer of the message, and then encapsulates the fourth IP header on the outer layer of the fourth GRE header.

[0072] The first network device sends a fourth protocol message to the second network device through the GRE tunnel.

[0073] After receiving the fourth protocol message, the second network device determines that the message sent by the first network device can be received through the GRE tunnel, and further determines that the current state of the GRE tunnel is up.

[0074] Optionally, in an embodiment of the present application, the first network device may also send a second data packet through the GRE tunnel. When the second network device receives the second data packet through the GRE tunnel, the second network device determines that the packet sent by the first network device can be received through the GRE tunnel, and further determines that the current state of the GRE tunnel is up.

[0075] It can be understood that the second data message specifically refers to a message whose data length is not 0.

[0076] The second data message may be sent before or after the fourth protocol message. No matter which message the second network device receives through the GRE tunnel, the second network device may determine that the current state of the GRE tunnel is up.

[0077] Optionally, in an embodiment of the present application, after the second network device determines that the current state of the GRE tunnel is up, the second network device resets the number of detection failures of the GRE tunnel according to the current state of the GRE tunnel. In one example, the second network device resets the number of detection failures of the GRE tunnel to 0.

[0078] Optionally, in an embodiment of the present application, the above-mentioned IP header includes an IPv4 header or an IPv6 header; the above-mentioned protocol message also includes a GRE header, and the GRE header includes a reserved field, and the reserved field is used to carry the above-mentioned type.

[0079] When the IP header includes an IPv4 header, the protocol message includes an IPv4 header.

[0080] When the IP header includes an IPv6 header, the protocol message includes an IPv6 header.

[0081] Optionally, in an embodiment of the present application, when the IP header included in the above-mentioned protocol message is an IPv6 header, the protocol message may include two IPv6 headers, that is, an outer IPv6 header and an inner IPv6 header. At this time, the protocol message also includes two GRE headers, and the GRE headers and the IPv6 headers are alternately encapsulated. For example, the first GRE header is encapsulated in the outer layer of the message, the inner IPv6 header is encapsulated, and then the second GRE header is encapsulated, and finally the outer IPv6 header is encapsulated. The above-mentioned two GRE headers are both existing standard GRE headers, and the reserved fields included therein are no longer used to carry types, that is, the protocol message does not include types.

[0082] In the embodiment of the present application, when the protocol message includes two IPv6 headers, the source address and the address stored in the destination address included in the outer IPv6 header are recorded oppositely to the source address and the address stored in the destination address included in the inner IPv6 header. In subsequent embodiments, the protocol message including two IPv6 headers is described in detail and will not be repeated here.

[0083] Therefore, by applying the communication method provided by the present application, a first network device sends a first protocol message to a second network device through a GRE tunnel; when a first data message or a second protocol message sent by the second network device is received through the GRE tunnel, the first network device determines that the current state of the GRE tunnel is an up state; wherein the first protocol message includes a first IP header and a first type, and the second protocol message includes a second IP header and a second type; the source address included in the first IP header is the same as the destination address included in the second IP header, and the destination address included in the first IP header is the same as the source address included in the second IP header; the first type indicates that the first protocol message is a keepalive request message, and the second type indicates that the second protocol message is a keepalive request message or a keepalive response message; the above-mentioned IP header includes an IPv4 header or an IPv6 header; the above-mentioned GRE tunnel includes an IPv4 GRE tunnel or an IPv6 GRE tunnel; the above-mentioned keepalive request message includes an IPv4 keepalive request message or an IPv6 keepalive request message; the above-mentioned keepalive response message includes an IPv4 Keepalive response packet or IPv6 keepalive response packet.

[0084] In this way, by reducing the number of IP headers and carrying the message type, the protocol message is sent to the other end of the GRE tunnel, so that after receiving the protocol message, the other end can determine that the current state of the GRE tunnel is up; the local end can also determine that the current state of the GRE tunnel is up after receiving the message sent by the other end. Therefore, the bandwidth is saved during the transmission of the protocol message, the IPv6 GRE keepalive function is supported, and the probability of the GRE tunnel being falsely reported as down is reduced. At the same time, it also solves the problems of keepalive message redundancy in the existing GRE keepalive function, resulting in additional bandwidth consumption, non-support of the IPv6 GRE keepalive function, and the GRE tunnel being falsely reported as down.

[0085] The communication method provided in the embodiment of the present application is described in detail below. Figure 2 , Figure 2 This is a networking diagram of the GRE tunnel application provided in the embodiment of the present application.

[0086] exist Figure 2In the example, network device A includes interface 1, and configures a GRE tunnel (IPv4 GRE tunnel) and a GRE keepalive function under interface 1. Network device A configures a GRE tunnel interface Tunnel0 under interface 1, with a source address of 1.1.1.1 and a destination address of 2.2.2.2, and generates a tunnel entry 1 under the GRE tunnel interface Tunnel0. The source address field of the tunnel entry 1 stores 1.1.1.1, and the destination address field stores 2.2.2.2. Network device A also configures a sending period, for example, 10 seconds, and a maximum number of sending times, for example, 3 times, at the GRE tunnel interface Tunnel0.

[0087] Network device B includes interface 2, and configures a GRE tunnel and a GRE keepalive function under interface 2. Network device B configures a GRE tunnel interface Tunnel0 under interface 2 (in order to distinguish it from the GRE tunnel interface configured under the aforementioned interface 1, the GRE tunnel interface configured under interface 2 is Tunnel1. In actual applications, the GRE tunnel interface configured under interface 2 is also Tunnel0), the source address is 2.2.2.2, the destination address is 1.1.1.1, and a tunnel entry 2 is generated under the GRE tunnel interface Tunnel1. The source address field of the tunnel entry 2 stores 2.2.2.2, and the destination address field stores 1.1.1.1. Network device B also configures a sending period, for example, 10 seconds, and a maximum number of sending times, for example, 3 times, at the GRE tunnel interface Tunnel1.

[0088] After the above configuration, a GRE tunnel is established between network device A and network device B.

[0089] In an example, network device A first constructs a message 1 with a data length of 0, and encapsulates a GRE header 1 on the outer layer of message 1, and then encapsulates an IPv4 header 1 on the outer layer of GRE header 1 to obtain a keepalive message 1. Figure 3 As shown, Figure 3 A schematic diagram of the format of a keepalive message provided for an embodiment of the present application. Among them, the GRE header 1 includes a reserved field, and the reserved field carries type 1. The value of type 1 is 1, indicating that the keepalive message 1 is a keepalive request message. The IPv4 header 1 includes a source address field and a destination address field. According to the tunnel table entry 1, the source address field stores the source address 1.1.1.1, and the destination address field stores the destination address 2.2.2.2.

[0090] Network device A sends keepalive message 1 (IPv4 keepalive message) to network device B through the GRE tunnel.

[0091] After network device B receives keepalive message 1, it determines that the message sent by network device A can be received through the GRE tunnel, and then determines that the current state of the GRE tunnel is up. After network device B determines that the current state of the GRE tunnel is up, network device B resets the number of detection failures of the GRE tunnel. In one example, network device B resets the number of detection failures of the GRE tunnel to 0.

[0092] Network device B first obtains IPv4 header 1 from keepalive message 1, and then obtains the source address and destination address from IPv4 header 1. Based on the source address and destination address, network device B searches for a matching tunnel entry under GRE tunnel interface Tunnel 1.

[0093] In the embodiment of the present application, there is a matching tunnel entry 2 under the GRE tunnel interface Tunnel 1. Network device B obtains the value of type 1 from GRE header 1 as 1, and network device B determines that keepalive message 1 is a keepalive request message.

[0094] At the same time, network device B first constructs a message 2 with a data length of 0, and encapsulates GRE header 2 on the outer layer of message 2, and then encapsulates IPv4 header 2 on the outer layer of GRE header 2 to obtain keepalive message 2 (IPv4 keepalive message). Among them, GRE header 2 includes a reserved field, and the reserved field carries type 2. The value of type 2 is 0 ( Figure 3 The reserved field shown is all 0) to indicate that keepalive message 2 is a keepalive response message. IPv4 header 2 includes a source address field and a destination address field. According to tunnel entry 2, the source address field stores the source address 2.2.2.2, and the destination address field stores the destination address 1.1.1.1.

[0095] Network device B sends keepalive message 2 to network device A through the GRE tunnel.

[0096] After receiving keepalive message 2, network device A determines that the message sent by network device B can be received through the GRE tunnel, and further determines that the current state of the GRE tunnel is up.

[0097] In an embodiment of the present application, network device B can also send data packet 1 through the GRE tunnel. When network device A receives data packet 1 through the GRE tunnel, the network device determines that the packet sent by network device B can be received through the GRE tunnel, and then determines that the current state of the GRE tunnel is up.

[0098] It can be understood that the data message 1 specifically refers to a message whose data length is not 0.

[0099] The data message 1 may be sent before or after the keepalive message 2. No matter which message the network device A receives through the GRE tunnel, the network device A may determine that the current state of the GRE tunnel is up.

[0100] In the embodiment of the present application, after network device A determines that the current state of the GRE tunnel is up, network device A resets the number of detection failures of the GRE tunnel according to the current state of the GRE tunnel. In one example, network device A resets the number of detection failures of the GRE tunnel to 0.

[0101] In another example, network device A configures a GRE tunnel (IPv6 GRE tunnel) interface Tunnel0 under interface 1, with a source address of 1::1 and a destination address of 2::2, and generates a tunnel entry 3 under the GRE tunnel interface Tunnel0, wherein the source address field of tunnel entry 3 stores 1::1 and the destination address field stores 2::2.

[0102] Network device B configures GRE tunnel interface Tunnel0 under interface 2 (in order to distinguish it from the GRE tunnel interface configured under the aforementioned interface 1, the GRE tunnel interface configured under interface 2 is Tunnel1. In actual applications, the GRE tunnel interface configured under interface 2 is also Tunnel0), the source address is 2::2, the destination address is 1::1, and generates tunnel table entry 4 under GRE tunnel interface Tunnel1. The source address field of tunnel table entry 4 stores 2::2, and the destination address field stores 1::1.

[0103] Network device A first constructs a message 3 with a data length of 0, and encapsulates the GRE header 3 on the outer layer of message 3, and then encapsulates the IPv6 header 1 on the outer layer of GRE header 3 to obtain keepalive message 3. Figure 4A As shown, Figure 4A A schematic diagram of another keepalive message format provided in an embodiment of the present application. Figure 4A In the example, GRE header 3 includes a reserved field, which carries type 3. The value of type 3 is 1, indicating that keepalive message 3 is a keepalive request message. IPv6 header 1 includes a source address field and a destination address field. According to tunnel table entry 3, the source address field stores source address 1::1, and the destination address field stores destination address 2::2.

[0104] Network device A sends keepalive message 3 (IPv6 keepalive message) to network device B through the GRE tunnel.

[0105] After network device B receives keepalive message 3, it determines that the message sent by network device A can be received through the GRE tunnel, and then determines that the current state of the GRE tunnel is up. After network device B determines that the current state of the GRE tunnel is up, network device B resets the number of detection failures of the GRE tunnel. In one example, network device B resets the number of detection failures of the GRE tunnel to 0.

[0106] Network device B first obtains IPv6 header 1 from keepalive message 3, and then obtains the source address and destination address from IPv6 header 1. Based on the source address and destination address, network device B searches for a matching tunnel entry under GRE tunnel interface Tunnel 1.

[0107] In the embodiment of the present application, there is a matching tunnel entry 4 under the GRE tunnel interface Tunnel 1. Network device B obtains the value of type 3 from the GRE header 3 as 1, and network device B determines that keepalive message 3 is a keepalive request message.

[0108] At the same time, network device B first constructs a message 4 with a data length of 0, and encapsulates GRE header 4 on the outer layer of message 4, and then encapsulates IPv6 header 2 on the outer layer of GRE header 4 to obtain keepalive message 4 (IPv6 keepalive message). Among them, GRE header 4 includes a reserved field, and the reserved field carries type 2. The value of type 2 is 0 ( Figure 4A The reserved field shown is all 0) to indicate that the keepalive message 4 is a keepalive response message. The IPv6 header 2 includes a source address field and a destination address field. According to the tunnel table entry 4, the source address field stores the source address 2::2, and the destination address field stores the destination address 1::1.

[0109] Network device B sends a keepalive message 4 to network device A through the GRE tunnel.

[0110] The subsequent determination of the current state of the GRE tunnel by the network device A and the resetting of the number of detection failures of the GRE tunnel are the same as those in the above embodiment and will not be repeated here.

[0111] In another example, network device A first constructs a message 5 with a data length of 0, and encapsulates a GRE header 5 on the outer layer of message 5, and then encapsulates an IPv6 header 3 (inner IPv6 header) on the outer layer of GRE header 5. The IPv6 header 3 includes a source address field and a destination address field. According to tunnel table entry 3, the source address field stores the destination address 2::2, and the destination address field stores the source address 1::1.

[0112] Network device A continues to encapsulate GRE header 6 on the outer layer of IPv6 header 3, and then encapsulates IPv6 header 4 (outer IPv6 header) on the outer layer of GRE header 6. IPv6 header 4 includes source address field and destination address field. According to tunnel table entry 3, source address 1::1 is stored in the source address field, and destination address 2::2 is stored in the destination address field, and keepalive message 5 is obtained. Figure 4B As shown, Figure 4B A schematic diagram of the format of another keepalive message provided in an embodiment of the present application. Figure 4B In the keepalive message 5, the inner IPv6 header and the outer IPv6 header are included, and the source and destination addresses included in the inner and outer IPv6 headers are recorded oppositely. The GRE headers are all existing standard GRE headers, which will not be repeated here.

[0113] Network device A sends a keepalive message 5 (IPv6 keepalive message) to network device B through the GRE tunnel.

[0114] After network device B receives keepalive message 5, it determines that the message sent by network device A can be received through the GRE tunnel, and then determines that the current state of the GRE tunnel is up. After network device B determines that the current state of the GRE tunnel is up, network device B resets the number of detection failures of the GRE tunnel. In one example, network device B resets the number of detection failures of the GRE tunnel to 0.

[0115] Network device B first obtains IPv6 header 4 from keepalive message 5, and then obtains source address and destination address from IPv6 header 4. Based on the source address and destination address, network device B checks whether there is a matching tunnel entry under GRE tunnel interface Tunnel1.

[0116] In the embodiment of the present application, there is a matching tunnel entry 4 under the GRE tunnel interface Tunnel 1. Network device B strips off the IPv6 header 4 and the adjacent GRE header, and uses the remaining message as the keepalive message 6 (IPv6 keepalive message).

[0117] According to the source and destination addresses included in the IPv6 header 4, the network device B sends a keepalive message 5 to the network device A through the GRE tunnel.

[0118] The subsequent determination of the current state of the GRE tunnel by the network device A and the resetting of the number of detection failures of the GRE tunnel are the same as those in the above embodiment and will not be repeated here.

[0119] Based on the same inventive concept, the present application embodiment also provides a communication device corresponding to the communication method. Figure 5 , Figure 5 A communication device provided in an embodiment of the present application is applied to a first network device, a GRE tunnel has been established between the first network device and a second network device, and the device includes: a sending unit 510, a receiving unit 520 and a determining unit 530;

[0120] The sending unit 510 is used to send a first protocol message to the second network device through the GRE tunnel;

[0121] The determining unit 530 is configured to determine that the current state of the GRE tunnel is an up state when the receiving unit 520 receives the first data message or the second protocol message sent by the second network device through the GRE tunnel;

[0122] The first protocol message includes a first IP header and a first type, and the second protocol message includes a second IP header and a second type; the source address included in the first IP header is the same as the destination address included in the second IP header, and the destination address included in the first IP header is the same as the source address included in the second IP header; the first type indicates that the first protocol message is a keepalive request message, and the second type indicates that the second protocol message is a keepalive request message or a keepalive response message;

[0123] The IP header includes an IPv4 header or an IPv6 header; the GRE tunnel includes an IPv4 GRE tunnel or an IPv6 GRE tunnel; the keepalive request message includes an IPv4 keepalive request message or an IPv6 keepalive request message; the keepalive response message includes an IPv4 keepalive response message or an IPv6 keepalive response message.

[0124] Optionally, the device further comprises:

[0125] A resetting unit (not shown in the figure) is used to reset the number of detection failures of the GRE tunnel according to the current state of the GRE tunnel.

[0126] Optionally, the receiving unit 520 is further configured to receive, through the GRE tunnel, a third protocol message sent by the second network device, where the third protocol message includes a third IP header and a third type;

[0127] The determining unit 530 is further configured to determine, according to the value of the third type, that the third protocol message is a keepalive request message if the source address and the destination address included in the third IP header match the locally stored tunnel entry;

[0128] The sending unit 510 is further configured to send a fourth protocol message to the second network device through the GRE tunnel according to the third IP header, wherein the fourth protocol message includes a fourth IP header and a fourth type, so that the second network device determines that the current state of the GRE tunnel is up according to the fourth protocol message;

[0129] Among them, the source address included in the third IP header is the same as the destination address included in the fourth IP header, and the destination address included in the third IP header is the same as the source address included in the fourth IP header; the fourth type indicates that the fourth protocol message is a keepalive response message.

[0130] Optionally, the sending unit 510 is further configured to send a second data packet to the second network device through the GRE tunnel, so that the second network device determines that the current state of the GRE tunnel is up according to the second data packet.

[0131] Optionally, the IP header includes an IPv4 header or an IPv6 header; the protocol message further includes a GRE header, the GRE header includes a reserved field, and the reserved field is used to carry a type;

[0132] When the IP header includes an IPv4 header, the protocol message includes an IPv4 header;

[0133] When the IP header includes an IPv6 header, the protocol message includes an IPv6 header.

[0134] Optionally, when the protocol message includes an IPv6 header and the number of the IPv6 headers is two, the protocol message does not include a type, and the source address and the destination address included in the two IPv6 headers are opposite records.

[0135] Therefore, by applying the communication device provided by the present application, a first network device sends a first protocol message to a second network device through a GRE tunnel; when a first data message or a second protocol message sent by the second network device is received through the GRE tunnel, the first network device determines that the current state of the GRE tunnel is an up state; wherein the first protocol message includes a first IP header and a first type, and the second protocol message includes a second IP header and a second type; the source address included in the first IP header is the same as the destination address included in the second IP header, and the destination address included in the first IP header is the same as the source address included in the second IP header; the first type indicates that the first protocol message is a keepalive request message, and the second type indicates that the second protocol message is a keepalive request message or a keepalive response message; the above-mentioned IP header includes an IPv4 header or an IPv6 header; the above-mentioned GRE tunnel includes an IPv4 GRE tunnel or an IPv6 GRE tunnel; the above-mentioned keepalive request message includes an IPv4 keepalive request message or an IPv6 keepalive request message; the above-mentioned keepalive response message includes an IPv4 Keepalive response packet or IPv6 keepalive response packet.

[0136] In this way, by reducing the number of IP headers and carrying the message type, the protocol message is sent to the other end of the GRE tunnel, so that after receiving the protocol message, the other end can determine that the current state of the GRE tunnel is up; the local end can also determine that the current state of the GRE tunnel is up after receiving the message sent by the other end. Therefore, the bandwidth is saved during the transmission of the protocol message, the IPv6 GRE keepalive function is supported, and the probability of the GRE tunnel being falsely reported as down is reduced. At the same time, it also solves the problems of keepalive message redundancy in the existing GRE keepalive function, resulting in additional bandwidth consumption, non-support of the IPv6 GRE keepalive function, and the GRE tunnel being falsely reported as down.

[0137] Based on the same inventive concept, the embodiment of the present application also provides a network device, such as Figure 6 As shown, it includes a processor 610, a transceiver 620 and a machine-readable storage medium 630, the machine-readable storage medium 630 stores machine-executable instructions that can be executed by the processor 610, and the processor 610 is prompted by the machine-executable instructions to execute the communication method provided in the embodiment of the present application. Figure 5 The communication device shown can be used as Figure 6 The network device hardware structure shown is implemented.

[0138] The computer-readable storage medium 630 may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk storage. Optionally, the computer-readable storage medium 630 may also be at least one storage device located away from the processor 610.

[0139] The processor 610 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gates or transistor logic devices, or discrete hardware components.

[0140] In the embodiment of the present application, the processor 610 reads the machine executable instructions stored in the machine readable storage medium 630, and the machine executable instructions enable the processor 610 itself and call the transceiver 620 to execute the communication method described in the aforementioned embodiment of the present application.

[0141] In addition, an embodiment of the present application provides a machine-readable storage medium 630, which stores machine-executable instructions. When called and executed by the processor 610, the machine-executable instructions prompt the processor 610 itself and the calling transceiver 620 to execute the communication method described in the aforementioned embodiment of the present application.

[0142] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0143] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The device embodiment described above is only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present application scheme. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0144] As for the communication device and machine-readable storage medium embodiments, since the method contents involved are basically similar to the aforementioned method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0145] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A communication method, characterized in that: The method is applied to a first network device, a GRE tunnel has been established between the first network device and a second network device, and the method includes: Sending a first protocol message to the second network device through the GRE tunnel; When a first data message or a second protocol message sent by the second network device is received through the GRE tunnel, determining that the current state of the GRE tunnel is an up state; The first protocol message includes a first IP header and a first type, and the second protocol message includes a second IP header and a second type; the source address included in the first IP header is the same as the destination address included in the second IP header, and the destination address included in the first IP header is the same as the source address included in the second IP header; the first type indicates that the first protocol message is a keepalive request message, and the second type indicates that the second protocol message is a keepalive request message or a keepalive response message; The IP header includes an IPv4 header or an IPv6 header; the GRE tunnel includes an IPv4 GRE tunnel or an IPv6 GRE tunnel; the keepalive request message includes an IPv4 keepalive request message or an IPv6 keepalive request message; the keepalive response message includes an IPv4 keepalive response message or an IPv6 keepalive response message.

2. The method according to claim 1, characterized in that The method further comprises: The number of detection failures of the GRE tunnel is reset according to the current state of the GRE tunnel.

3. The method according to claim 1, characterized in that: The method further comprises: Receiving, through the GRE tunnel, a third protocol message sent by the second network device, wherein the third protocol message includes a third IP header and a third type; If the source address and the destination address included in the third IP header match the locally stored tunnel table entry, determining, according to the value of the third type, that the third protocol message is a keepalive request message; Sending a fourth protocol message to the second network device through the GRE tunnel according to the third IP header, wherein the fourth protocol message includes a fourth IP header and a fourth type, so that the second network device determines that the current state of the GRE tunnel is up according to the fourth protocol message; Among them, the source address included in the third IP header is the same as the destination address included in the fourth IP header, and the destination address included in the third IP header is the same as the source address included in the fourth IP header; the fourth type indicates that the fourth protocol message is a keepalive response message.

4. The method according to claim 1, characterized in that: The method further comprises: A second data packet is sent to the second network device through the GRE tunnel, so that the second network device determines that the current state of the GRE tunnel is up according to the second data packet.

5. The method according to any one of claims 1 to 4, characterized in that: The IP header includes an IPv4 header or an IPv6 header; the protocol message also includes a GRE header, the GRE header includes a reserved field, and the reserved field is used to carry the type; When the IP header includes an IPv4 header, the protocol message includes an IPv4 header; When the IP header includes an IPv6 header, the protocol message includes an IPv6 header.

6. The method according to claim 1, characterized in that When the protocol message includes an IPv6 header and the number of the IPv6 headers is two, the protocol message does not include a type, and the source address and the destination address included in the two IPv6 headers are opposite records.

7. A communication device, characterized in that: The device is applied to a first network device, a GRE tunnel has been established between the first network device and a second network device, and the device includes: a sending unit, a receiving unit and a determining unit; The sending unit is used to send the first protocol message to the second network device through the GRE tunnel; The determining unit is configured to determine that the current state of the GRE tunnel is an up state when the receiving unit receives the first data message or the second protocol message sent by the second network device through the GRE tunnel; The first protocol message includes a first IP header and a first type, and the second protocol message includes a second IP header and a second type; the source address included in the first IP header is the same as the destination address included in the second IP header, and the destination address included in the first IP header is the same as the source address included in the second IP header; the first type indicates that the first protocol message is a keepalive request message, and the second type indicates that the second protocol message is a keepalive request message or a keepalive response message; The IP header includes an IPv4 header or an IPv6 header; the GRE tunnel includes an IPv4 GRE tunnel or an IPv6 GRE tunnel; the keepalive request message includes an IPv4 keepalive request message or an IPv6 keepalive request message; the keepalive response message includes an IPv4 keepalive response message or an IPv6 keepalive response message.

8. The device according to claim 7, characterized in that The device also includes: The resetting unit is used to reset the number of detection failures of the GRE tunnel according to the current state of the GRE tunnel.

9. The device according to claim 7, characterized in that The receiving unit is further configured to receive, through the GRE tunnel, a third protocol message sent by the second network device, wherein the third protocol message includes a third IP header and a third type; The determining unit is further configured to determine, according to the value of the third type, that the third protocol message is a keepalive request message if the source address and the destination address included in the third IP header match the locally stored tunnel entry; The sending unit is further configured to send a fourth protocol message to the second network device through the GRE tunnel according to the third IP header, wherein the fourth protocol message includes a fourth IP header and a fourth type, so that the second network device determines that the current state of the GRE tunnel is up according to the fourth protocol message; Among them, the source address included in the third IP header is the same as the destination address included in the fourth IP header, and the destination address included in the third IP header is the same as the source address included in the fourth IP header; the fourth type indicates that the fourth protocol message is a keepalive response message.

10. The device according to claim 7, characterized in that The sending unit is further configured to send a second data packet to the second network device through the GRE tunnel, so that the second network device determines that the current state of the GRE tunnel is an up state according to the second data packet.

11. The device according to any one of claims 7 to 10, characterized in that: The IP header includes an IPv4 header or an IPv6 header; the protocol message also includes a GRE header, the GRE header includes a reserved field, and the reserved field is used to carry the type; When the IP header includes an IPv4 header, the protocol message includes an IPv4 header; When the IP header includes an IPv6 header, the protocol message includes an IPv6 header.

12. The device according to claim 7, characterized in that When a protocol message includes two IPv6 headers, the protocol message does not include a type, and the source address and the destination address included in the two IPv6 headers are opposite records.

Images