CN109379241B

CN109379241B - Path information determination method and device

Info

Publication number: CN109379241B
Application number: CN201811607408.XA
Authority: CN
Inventors: 樊超; 王海
Original assignee: New H3C Technologies Co Ltd
Current assignee: New H3C Technologies Co Ltd
Priority date: 2018-12-27
Filing date: 2018-12-27
Publication date: 2021-12-24
Anticipated expiration: 2038-12-27
Also published as: CN109379241A

Abstract

The application provides a method and a device for determining path information, wherein the method comprises the following steps: receiving a first tracking routing message sent by an edge node, wherein the first tracking routing message is used for determining path information of a path to be detected between a source node and a destination node; determining a gateway node for establishing a tunnel between the edge node and the destination node; generating a second trace route message, wherein a source address of the second trace route message is the address of the edge node, and a destination address of the second trace route message is the address of the gateway node; sending the second trace route message to the edge node, so that the edge node sends the second trace route message by inquiring a common routing table; and determining the path information of the path to be detected according to the response result of the second tracking routing message. Through the technical scheme of the application, whether a path reaching each network node has a fault or not can be detected, so that operation and maintenance personnel can quickly locate a fault point.

Description

Path information determination method and device

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method and an apparatus for determining path information.

Background

The Traceroute (Traceroute) function is used to locate all network nodes between a source node and a destination node, and when a fault occurs, the network node with the fault can be analyzed through the Traceroute function.

For example, if there is node 2 between node 1 (source node) and node 3 (destination node), node 1 may send message 1, where Time To Live (TTL) of message 1 is 1, the destination IP address is the IP address of node 3, and the destination port is a port number that is not used by all applications, such as 3333.

After receiving the Message 1, the node 2 subtracts 1 from TTL and changes TTL to 0, and the node 2 sends an Internet Control Message Protocol (ICMP) error Message to the node 1, where the ICMP error Message carries an IP address of the node 2, and thus, the node 1 obtains an IP address of the first hop.

The node 1 sends a message 2 with TTL of 2, the destination IP address is the IP address of the node 3, and the destination port is 3333. After receiving the message 2, the node 2 subtracts 1 from TTL to become 1, and forwards the modified message 2. After receiving the message 2, the node 3 subtracts 1 from TTL and changes the TTL to 0, and sends an ICMP error message to the node 1, where the ICMP error message carries the IP address of the node 3, and thus, the node 1 obtains the IP address of the second hop.

Obviously, since the IP address of the second hop is the IP address of the destination node, node 1 can locate the network node between the source node and the destination node. Assuming that a fault exists between the node 1 and the node 2, the node 1 does not receive the ICMP error message returned by the node 2, and then determines that the fault exists between the node 1 and the node 2. Or, assuming that a fault exists between the node 2 and the node 3, the node 1 does not receive the ICMP error message returned by the node 3, and then determines that a fault exists between the node 2 and the node 3.

However, if a Virtual eXtensible Local Area Network (VXLAN) tunnel is established between the node 1 and the node 3, the node 1 encapsulates the VXLAN tunnel header when sending the message, so that the node 2 can send the message to the node 3 based on the VXLAN tunnel header without reading the message content or sending an ICMP error message to the node 1 after receiving the message. Based on this, the node 1 cannot know the IP address of the node 2, and if there is a fault between the nodes 1 and 3, the node 1 cannot know whether there is a fault between the nodes 1 and 2 or a fault between the nodes 2 and 3.

Disclosure of Invention

The application provides a path information determination method, which is applied to a controller and comprises the following steps:

receiving a first tracking routing message sent by an edge node, wherein the first tracking routing message is used for determining path information of a path to be detected between a source node and a destination node, and the first tracking routing message is sent to a controller after the edge node sends out a forwarding routing table through a query tunnel;

determining a gateway node for establishing a tunnel between the edge node and the destination node;

generating a second trace route message, wherein a source address of the second trace route message is the address of the edge node, and a destination address of the second trace route message is the address of the gateway node;

sending the second trace route message to the edge node, so that the edge node sends the second trace route message by inquiring a common routing table;

and determining the path information of the path to be detected according to the response result of the second tracking routing message.

The application provides a path information determination device, is applied to the controller, the device includes:

the system comprises a receiving module, a forwarding module and a controller, wherein the receiving module is used for receiving a first tracking routing message sent by an edge node, the first tracking routing message is used for determining the path information of a path to be detected between a source node and a destination node, and the first tracking routing message is sent to the controller after the edge node sends out a forwarding routing table through a query tunnel;

a determining module, configured to determine a gateway node that establishes a tunnel between the edge node and a destination node;

a generating module, configured to generate a second trace routing packet, where a source address of the second trace routing packet is an address of the edge node, and a destination address of the second trace routing packet is an address of the gateway node;

a sending module, configured to send the second trace routing packet to the edge node, so that the edge node sends the second trace routing packet by querying a common routing table;

the determining module is further configured to determine path information of the path to be detected according to a response result of the second trace route packet.

Based on the above technical solution, in this embodiment of the application, the controller may send the trace routing packet to the edge node, so that the edge node sends the trace routing packet by querying the ordinary routing table, instead of sending the trace routing packet by querying the tunnel forwarding routing table. When the edge node sends the trace routing message by inquiring the common routing table, the output interface of the common routing table is a physical port instead of a VXLAN tunnel, so that the edge node does not need to package a VXLAN tunnel header for the trace routing message, and thus, after receiving the trace routing message, a network node between the edge node and a gateway node can send an ICMP error message to the edge node, and the controller determines the path information of the path to be detected according to the response result of the trace routing message. Obviously, even though a VXLAN tunnel is established between the edge node and the gateway node, the address of each network node between the edge node and the gateway node can be detected, and whether a fault exists in a path reaching each network node is detected, so that the fault position can be analyzed, and operation and maintenance personnel can quickly locate the fault point.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments of the present application or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art according to the drawings of the embodiments of the present application.

FIG. 1 is a schematic diagram of an application scenario in an embodiment of the present application;

FIG. 2 is a flow diagram of a method for determining path information in one embodiment of the present application;

fig. 3 is a flowchart of a path information determination method according to another embodiment of the present application;

fig. 4 is a flowchart of a path information determination method according to another embodiment of the present application;

fig. 5 is a block diagram of a route information determination device according to an embodiment of the present application;

fig. 6 is a hardware configuration diagram of a controller according to an embodiment of the present application.

Detailed Description

The terminology used in the embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein is meant to encompass any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in the embodiments of the present application to describe various information, the information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. Depending on the context, moreover, the word "if" as used may be interpreted as "at … …" or "when … …" or "in response to a determination".

An embodiment of the present application provides a method for determining path information, which is shown in fig. 1 and is an application scenario diagram of the embodiment of the present application. The host 111 and the host 112 may be virtual machines or terminal devices. The controller 121 may be a Software Defined Network (SDN) controller.

Edge nodes

131 and 132 may be VXLAN Tunnel End Point (VTEP) devices that may act as leaf nodes in the network.

Network nodes

141 and 142 may be three-tier switches that may act as underlay nodes in the network. Gateway node 151 may act as a border node in the network. In a networking scenario of a distributed gateway,

edge nodes

131 and 132 may act as distributed gateways, while gateway node 151 may act as a centralized gateway.

In this application scenario, a VXLAN tunnel, e.g., VXLAN tunnel a, may be established between edge node 131 and gateway node 151, where VXLAN tunnel a may correspond to physical port a, i.e., a physical port on edge node 131 that is directed to network node 141. Further, a VXLAN tunnel, e.g., VXLAN tunnel B, may be established between edge node 132 and gateway node 151, which may correspond to physical port B, i.e., the physical port on edge node 132 that is directed to network node 141.

In this application scenario, for each edge node (taking the edge node 131 as an example in the following), the edge node 131 may include a tunnel forwarding routing table and a normal routing table. The tunnel forwarding routing table may also be referred to as an overlay routing table, and an egress interface of the tunnel forwarding routing table is usually a VXLAN tunnel. The generic routing table may also be referred to as an underlay routing table, and the egress interface of the generic routing table is typically a physical port.

Taking the IP address of the gateway node 151 as the IP address 151 as an example, see table 1, which is an example of a tunnel forwarding routing table, and of course, the tunnel forwarding routing table may also include other contents. Referring to table 2, this is an example of a general routing table, and of course, the general routing table may include other contents.

TABLE 1

Destination IP address	Outlet interface
		IP address 151	VXLAN tunnel A
…	…
		0.0.0.0	VXLAN tunnel A

TABLE 2

Destination IP address	Outlet interface
		IP address 151	Physical port a
…	…

When the edge node 131 queries the tunnel forwarding routing table shown in table 1 through the destination IP address of the packet, if the egress interface is VXLAN tunnel a, it needs to encapsulate a VXLAN tunnel header for the packet and send the packet through VXLAN tunnel a, which is not limited to this process. When the ordinary routing table shown in table 2 is queried by the destination IP address of the packet, if the egress interface is the physical port a, the packet is directly sent through the physical port a without encapsulating the VXLAN tunnel header for the packet or sending the packet through the VXLAN tunnel a.

In one example, if the packet has a corresponding VXLAN identifier, the edge node 131 queries the tunnel forwarding routing table shown in table 1 through the destination IP address of the packet; if the message does not have the corresponding VXLAN identification, the common routing table shown in the table 2 is inquired through the destination IP address of the message.

In the application scenario, referring to fig. 2, a flow diagram of the path information determining method is shown.

In step 201, the controller 121 sends a first flow table to the edge node 131, where the first flow table is used to enable the edge node 131 to send a trace route packet matching with the first flow table to the controller 121.

In addition, the controller 121 may also send a first flow table to the edge node 132, where the first flow table is used to enable the edge node 132 to send a traceroute packet matching the first flow table to the controller 121.

In one example, the matching option of the first flow table may include: the Protocol type is a (User Datagram Protocol, UDP) type, and the destination port is a designated port identification.

Specifically, an example of the first flow table may be as follows: the matching options may include: the ethernet type is IPv4 type, the protocol type is UDP type, and the destination port is 3333 (i.e., specified port identification). The action options may include: and copying the original message, and uploading the copied message to the controller.

In step 202, when the host 111 locates all network nodes between the source node (i.e., the host 111) and the destination node 181 by using the Traceroute function, the trace route packet 1 may be sent to the edge node 131.

The source address of the traceroute message 1 is the address of the host 111, which is subsequently referred to as the IP address 111, and the destination address is the address of the destination node 181, which is subsequently referred to as the IP address 181. The destination port of traceroute message 1 is a designated port identification (e.g., 3333) that controller 121 notifies and that designated port identification is the destination port of traceroute message 1. The ethernet type of the traceroute message 1 is IPv4 type, and the protocol type is UDP type. The TTL value of traceroute packet 1 may be 1.

In an example, the Traceroute message 1 may be a detection message for implementing Traceroute function, and is a UDP type message, and the content of the Traceroute message 1 is not limited.

In step 203, after receiving the traceroute message 1, the edge node 131 subtracts 1 from the TTL value and changes the TTL value to 0, so that an ICMP error message 1 is sent to the host 111, where the source IP address of the ICMP error message 1 is the IP address (for example, IP address 131) of the edge node 131, and the destination IP address is IP address 111.

Of course, the ICMP error message may also include other contents, for example, the ICMP error message includes contents of an ethernet type, a protocol type, an ICMP type, and the like, which is not limited to this. Wherein, the ethernet type of the ICMP error message is IPv4 type, the protocol type is ICMP type, and the ICMP type is a specific identifier (e.g. 11) for indicating that the current message is an ICMP error message whose port is not reachable.

In step 204, since the traceroute message 1 is matched with the first flow table, the edge node 131 sends the traceroute message 1 to the controller 121, and the controller 121 receives the traceroute message 1, where the source address of the traceroute message 1 is the IP address 111 of the source node and the destination address is the IP address 181 of the destination node 181.

In step 205, after receiving trace route message 1, controller 121 starts a timer (the aging time is configured according to experience, for example, 15 seconds), and sends a second flow table to edge node 131, where the second flow table is used to enable edge node 131 to send an ICMP error message matched with the second flow table to controller 121.

In one example, the matching option of the second flow table may include: the protocol type is ICMP type and the destination address is the source address of traceroute message 1, i.e. the IP address 111 of the source node.

Specifically, an example of the second flow table may be as follows: the matching options include: the ethernet type is IPv4 type; the protocol type is an ICMP type; the destination address is an IP address 111; the ICMP type is a designated identifier (such as 11) and indicates that the current message is an ICMP error message with an unreachable port; VXLAN is identified as VXLAN tunnel a. The action options include: and copying the original message, and uploading the copied message to the controller.

The second flow table is used to prompt the edge node 131 to send a response message (i.e., an ICMP error message) for tracing the routing message to the controller 121. Specifically, if the edge node 131 receives the ICMP error message matched with the second flow table and sends the ICMP error message to the controller 121, it indicates that the network node corresponding to the current TTL value of the trace route message is reachable. If the edge node 131 does not receive the ICMP error message matched with the second flow table, that is, the controller 121 does not receive the ICMP error message, it indicates that the network node corresponding to the current TTL value of the trace route message is not reachable.

The determination method for VXLAN identification may include: the trace route packet 1 carries the VLAN id of the host 111, and after receiving the trace route packet 1, the controller 121 queries the mapping relationship (i.e., the mapping relationship between the VLAN id and the VXLAN id, and does not limit the maintenance process of the mapping relationship) through the VLAN id to obtain the VXLAN id corresponding to the VLAN id, i.e., VXLAN tunnel a.

In step 206, after the edge node 131 sends the ICMP error message 1 to the host 111, the host 111 receives the ICMP error message 1, and obtains the IP address 131 of the edge node 131 from the ICMP error message 1, so that the host 111 can obtain the IP address of the first hop and maintain the path information shown in table 3.

TABLE 3

First hop node

IP address

131

In step 207, the host 111 sends the trace route packet 2 to the edge node 131, where the content of the trace route packet 2 is similar to that of the trace route packet 1, except that the TTL value is 2, and details are not described here again.

In step 208, after receiving the traceroute packet 2, the edge node 131 subtracts 1 from the TTL value to become 1, and therefore, the edge node 131 sends the traceroute packet 2 to the destination node 181.

When the trace route message 2 is sent to the destination node 181, because the VXLAN identifier corresponding to the trace route message 2, that is, the VXLAN identifier of the network to which the host 111 belongs, can be obtained, the edge node 131 queries the tunnel forwarding routing table shown in table 1 by using the destination address (that is, the IP address 181) of the trace route message 2, and obtains an outgoing interface corresponding to the IP address 181, which may be a VXLAN tunnel a, and therefore, the edge node 131 may encapsulate the tunnel header corresponding to the VXLAN tunnel a for the trace route message 2, and send the modified trace route message 2 through the VXLAN tunnel a, which is not described in detail herein.

Since the IP address 181 is an IP address in the Internet network, the edge node 131 may not learn a routing table entry of the IP address 181, and therefore, when querying the tunnel forwarding routing table by using the IP address 181, the edge node 131 may hit a default routing table entry, where the IP address of the default routing table entry is 0.0.0.0, and the egress interface is VXLAN tunnel a, that is, the egress interface corresponding to the IP address 181 is VXLAN tunnel a.

When the edge node 131 encapsulates the tunnel header corresponding to the VXLAN tunnel a for the traceroute packet 2, the source address of the tunnel header is the IP address 131 of the edge node 131, and the destination IP address is the IP address 151 of the gateway node 151.

In one example, after edge node 131 receives traceroute packet 2, edge node 131 may send traceroute packet 2 to controller 121 because traceroute packet 2 matches the first flow table, and controller 121 may re-time the timer after receiving traceroute packet 2.

If the path from the edge node 131 to the gateway node 151 does not fail, the method may further include:

in step 209, network node 141 forwards encapsulated traceroute packet 2 to network node 142, and network node 142 forwards encapsulated traceroute packet 2 to gateway node 151.

In an example, since the tunnel header is encapsulated in the outer layer of the traceroute packet 2, after receiving the encapsulated traceroute packet 2, the network node 141 does not parse the content of the traceroute packet 2 because the destination IP address of the tunnel header is not the IP address of the network node 141, and instead forwards the traceroute packet 2 by using the tunnel header, for example, the traceroute packet 2 may be forwarded to the network node 142. Because the outer layer of the trace route message 2 encapsulates the tunnel header, the TTL value of the trace route message 2 is not reduced.

After receiving the encapsulated traceroute packet 2, the network node 142 does not parse the content of the traceroute packet 2 because the destination IP address of the tunnel header is not the IP address of the network node 142, and forwards the traceroute packet 2 by using the tunnel header, for example, forwards the traceroute packet 2 to the gateway node 151. Because the outer layer of the trace route message 2 encapsulates the tunnel header, the TTL value of the trace route message 2 is not reduced.

Step 210, gateway node 151 sends ICMP error message 2 to host 111, where the source IP address of ICMP error message 2 is IP address 151 of gateway node 151, and the destination IP address is IP address 111.

In one example, after gateway node 151 receives encapsulated traceroute packet 2, since the destination IP address of the tunnel header is the IP address of gateway node 151, gateway node 151 may remove the tunnel header to obtain inner traceroute packet 2. Gateway node 151 may then subtract the TTL value by 1 and change to 0, and therefore gateway node 151 may send an ICMP error message 2 to host 111.

When the gateway node 151 sends the ICMP error message 2 to the host 111, the destination IP address (i.e., the IP address 111) of the ICMP error message 2 may be used to query the tunnel forwarding routing table to obtain the outgoing interface corresponding to the IP address 111, such as the VXLAN tunnel a, so that the tunnel header corresponding to the VXLAN tunnel a may be encapsulated for the ICMP error message 2, and the modified ICMP error message 2 may be sent through the VXLAN tunnel a.

When the gateway node 151 encapsulates the tunnel header corresponding to the VXLAN tunnel a for the ICMP error message 2, the source address of the tunnel header is the IP address 151 of the gateway node 151, and the destination IP address is the IP address 131 of the edge node 131.

In step 211, network node 142 sends the encapsulated ICMP error message 2 to network node 141, and network node 141 sends the encapsulated ICMP error message 2 to edge node 131.

In one example, because a tunnel header is encapsulated in the outer layer of the ICMP error message 2, after receiving the encapsulated ICMP error message 2, the network node 142 does not analyze the content of the ICMP error message 2 because the destination IP address of the tunnel header is not the IP address of the network node 142, and instead forwards the ICMP error message 2 by using the tunnel header, that is, forwards the ICMP error message 2 to the network node 141.

After receiving the encapsulated ICMP error message 2, the network node 141 forwards the ICMP error message 2 by using the tunnel header without analyzing the content of the ICMP error message 2 because the destination IP address of the tunnel header is not the IP address of the network node 141, that is, the ICMP error message 2 is forwarded to the edge node 131.

Step 212, edge node 131 forwards ICMP error message 2 to host 111, and host 111 receives ICMP error message 2 and obtains IP address 151 of gateway node 151 from ICMP error message 2.

In one example, after receiving the encapsulated ICMP error message 2, since the destination IP address of the tunnel header is the IP address of the edge node 131, the edge node 131 may remove the tunnel header, obtain the ICMP error message 2, and forward the ICMP error message 2 to the host 111. After receiving the ICMP error message 2, the host 111 obtains the IP address 151 of the gateway node 151 from the ICMP error message 2, that is, obtains the IP address of the second hop, and maintains the path information shown in table 4.

TABLE 4

First hop node	IP address	131
			Second hop node	IP address 151

Further, based on the processing flow of the above steps 207 to 212, after the host 111 sequentially sends the trace route packet 3 (with a TTL value of 3), the trace route packet 4 (with a TTL value of 4), and the trace route packet 5 (with a TTL value of 5), the path information shown in table 5, that is, the complete path information, may be maintained.

TABLE 5

First hop node	IP address	131
			Second hop node	IP address 151
Third hop node	IP Address 161 (i.e., IP Address of firewall node 161)
		Fourth hop node	IP address 171 (i.e., IP address of egress node 171)
Fifth hop node	IP address 181 (i.e., IP address of destination node 181)

In step 213, edge node 131 sends ICMP error message 2 to controller 121, and after controller 121 receives ICMP error message 2, it may delete the timer (i.e., the timer started in step 205).

Referring to the above embodiment, the matching options of the second flow table include: the ethernet type is IPv4 type, the protocol type is ICMP type, the destination address is IP address 111, the ICMP type is designated identification (e.g., 11), and the VXLAN identification is VXLAN tunnel a. On this basis, when the edge node 131 receives the encapsulated ICMP error message 2, because the VXLAN carried in the tunnel header is identified as VXLAN tunnel a, the ethernet type of the ICMP error message 2 is IPv4 type, the protocol type is ICMP type, the destination address is IP address 111, and the ICMP type is 11, the ICMP error message 2 may be matched with the second flow table, that is, the edge node 131 may send the ICMP error message 2 to the controller 121.

Further, controller 121 may delete the timer if receiving ICMP error message 2 before the timer expires, indicating that no failure has occurred between edge node 131 and gateway node 151.

Referring to fig. 3, another schematic flow chart of a method for determining path information is shown, where the method includes:

step 301 to step 308 are the same as step 201 to step 208, and are not described herein again.

If the path between edge node 131 and gateway node 151 fails, assuming that the path between network node 142 and gateway node 151 fails, referring to step 209, network node 141 forwards encapsulated traceroute packet 2 to network node 142, but does not send an ICMP error packet to host 111, and network node 142 forwards encapsulated traceroute packet 2 to gateway node 151, but does not send an ICMP error packet to host 111. Furthermore, because a path between network node 142 and gateway node 151 fails, gateway node 151 cannot receive traceroute message 2, and does not send an ICMP error message to host 111. In summary, the host 111 does not receive the ICMP error message for the trace route message 2, and knows that the path has a failure. However, it is indistinguishable in the conventional manner whether the path between edge node 131 and network node 141 fails, the path between network node 141 and network node 142 fails, or the path between network node 142 and gateway node 151 fails.

For the above discovery, the method for determining path information provided in the embodiment of the present application may further include:

in step 309, if the timer times out and the controller 121 does not receive the ICMP error message sent by the edge node 131, a trace route message a is generated.

If the timer times out and the controller has not received the ICMP error message sent by the edge node 131, it indicates that a problem may occur in the path between the underlay network nodes between the edge node 131 and the gateway node 151, and therefore, the controller 121 may trace the routing message a.

The timer may be an initially configured timer, as shown in step 305 (corresponding to step 205), or may be an updated timer, as shown in step 308 (corresponding to step 208).

Specifically, because network node 141, network node 142, and gateway node 151 do not send an ICMP error message to host 111, edge node 131 does not receive an ICMP error message matching the second flow table, and does not send an ICMP error message to controller 121. Based on this, when the timer times out, the controller 121 does not receive the ICMP error message, and may generate the traceroute message a.

In one example, before controller 121 generates traceroute packet a, controller 121 may also determine a gateway node, gateway node 151, between edge node 131 and destination node 181 that establishes the VXLAN tunnel. Based on this, when the controller 121 generates the traceroute message a, the source address of the traceroute message a is the IP address 131 of the edge node 131, and the destination address is the IP address 151 of the gateway node 151; the destination port of the traceroute message a is a designated port identifier (e.g., 3333); the Ethernet type of the trace routing message A is IPv4 type, and the protocol type is UDP type; the TTL value of the traceroute packet a is 1.

In step 310, controller 121 sends a third flow table to edge node 131, where the third flow table is used to enable edge node 131 to send an ICMP error message matched with the third flow table to controller 121.

In one example, the matching options of the third flow table include: the protocol type is ICMP type and the destination address is the address of the edge node 131, i.e. the IP address 131. Specifically, an example of the third flow table may be as follows: the matching options may include: the ethernet type is IPv4 type, the protocol type is ICMP type, and the destination address is IP address 131. The action options include: the message is sent to controller 121.

In step 311, controller 121 sends traceroute packet a to edge node 131.

Specifically, the controller 121 may encapsulate an openflow packet header for the traceroute packet a, and send the encapsulated traceroute packet a to the edge node 131. The source address of the openflow header is the IP address of the controller 121, and the destination address is the IP address of the edge node 131.

In step 312, edge node 131 sends traceroute packet a through physical port a.

Specifically, after receiving the encapsulated traceroute packet a, the edge node 131 may decapsulate the packet to obtain the traceroute packet a because the destination address of the openflow packet header is the IP address of the edge node 131, and send the traceroute packet a through the physical port a.

In order for the edge node 131 to send the traceroute packet a through the physical port a, the following method may be used:

mode a, the openflow packet header does not include a VXLAN identifier, as shown in the above embodiment, because the openflow packet header does not include a VXLAN identifier, the edge node 131 queries the general routing table shown in table 2 by tracking the destination address of the routing packet a (i.e., the IP address 151 of the gateway node 151) to obtain that the egress interface is a physical port a, and therefore, sends the tracking routing packet a through the physical port a.

Obviously, since the openflow packet header does not include the VXLAN identifier, the edge node 131 does not look up the tunnel forwarding routing table shown in table 1 by using the destination address of the traceroute packet a, and does not encapsulate the VXLAN tunnel header for the traceroute packet a and does not transmit the packet through the VXLAN tunnel a.

Mode B, the openflow packet header includes a type identifier, where the type identifier is used to indicate that the traceroute packet a is sent by querying a common routing table, so that after the edge node 131 parses the type identifier from the openflow packet header, it is known that the traceroute packet a needs to be sent by querying the common routing table, that is, the common routing table shown in table 2 may be queried by a destination address of the traceroute packet a, and an output interface is obtained as a physical port a, so that the traceroute packet a is sent by the physical port a.

And in the mode C, the openflow message header comprises a physical port a, and after the physical port a is analyzed from the openflow message header, the edge node 131 sends the trace routing message A through the physical port a.

In step 312, unlike step 308, edge node 131 does not send trace route message a through VXLAN tunnel a, i.e., the outer layer of trace route message a does not encapsulate the VXLAN tunnel header.

In step 313, after receiving the traceroute message a, the network node 141 subtracts 1 from the TTL value and changes the TTL value to 0, so that an ICMP error message a is sent to the edge node 131, where the source IP address of the ICMP error message a is the IP address 141 of the network node 141, and the destination IP address is the IP address 131 of the edge node 131.

Of course, the ICMP error message a may also include other contents, for example, the ICMP error message a includes contents of an ethernet type, a protocol type, an ICMP type, and the like, which is not limited to this. The ethernet type of the ICMP error message a is IPv4 type, the protocol type is ICMP type, and the ICMP type is a specific identifier (e.g. 11) for indicating that the current message is an ICMP error message whose port is not reachable.

In step 314, after receiving the ICMP error message a, the edge node 131 sends the ICMP error message a to the controller 121 because the ICMP error message a matches the third flow table.

In step 315, the controller 121 determines the path information of the path to be detected according to the response result of the trace routing packet a. Wherein the response result may be an ICMP error message for traceroute message a.

Specifically, if the controller 121 receives an ICMP error message a returned by the edge node 131 for the trace routing message a, it is determined that the path to be detected between the edge node 131 and the network node is not in fault, where the network node is a network node corresponding to the TTL value carried in the trace routing message a.

For example, after receiving ICMP error message a, controller 121 may obtain IP address 141 of network node 141 from ICMP error message a. Since the TTL value carried in the traceroute packet a is 1, the IP address 141 is the IP address of the first-hop node (i.e., the network node 141) of the edge node 131, and the path to be detected between the edge node 131 and the network node 141 does not fail.

In step 316, the controller 121 modifies the destination address of the ICMP error message a to the IP address of the source node (i.e., the host 111), and sends the modified ICMP error message a to the source node.

Referring to step 304, after receiving the traceroute packet 1, the controller 121 determines the source address (i.e., the IP address 111) of the traceroute packet 1 as the IP address of the source node of the path to be detected, that is, the source node is the host 111. The controller 121 may modify the destination address of the ICMP error message a into the IP address 111, and send the modified ICMP error message a to the host 111, where the source address of the modified ICMP error message a is the IP address 141 of the network node 141, and the destination address is the IP address 111 of the host 111.

In step 317, after receiving the modified ICMP error message a, the host 111 may obtain the IP address 141 of the network node 141 from the modified ICMP error message a, so that, on the basis of table 3, the host 111 may obtain the IP address of the second hop and maintain the path information shown in table 6.

TABLE 6

First hop node	IP address	131
			Second hop node	IP address	141

In step 318, the controller 121 generates a trace route packet B, where the content of the trace route packet B may be similar to the content of the trace route packet a, but the TTL value is 2, which is not described herein again.

For convenience of description, step 318 and the following steps are not shown.

In step 319, controller 121 sends traceroute packet B to edge node 131.

In step 320, edge node 131 sends traceroute packet B through physical port a.

In step 321, after receiving the traceroute packet B, the network node 141 subtracts 1 from the TTL value to become 1, so that the network node 141 sends the traceroute packet B with the TTL value modified to the network node 142.

In step 322, after receiving the trace route message B, the network node 142 decreases the TTL value by 1 and changes the TTL value to 0, so that the network node 142 sends an ICMP error message B to the network node 141, and the network node 141 sends an ICMP error message B to the edge node 131. The source IP address of the ICMP error message B is the IP address 142 of the network node 142, and the destination IP address is the IP address 131 of the edge node 131.

In step 323, after receiving the ICMP error message B, the edge node 131 sends the ICMP error message B to the controller 121 because the ICMP error message B matches the third flow table.

In step 324, after receiving the ICMP error message B, the controller 121 may obtain the IP address 142 of the network node 142 from the ICMP error message B. Since the TTL value carried in the traceroute packet B is 2, the IP address 142 is the IP address of the second hop node (i.e., the network node 142) of the edge node 131, and the path to be detected between the edge node 131 and the network node 142 does not fail.

In step 325, the controller 121 modifies the destination IP address of the ICMP error message B to the IP address 111 of the host 111, and sends the modified ICMP error message B to the host 111.

In step 326, after receiving the modified ICMP error message B, the host 111 obtains the IP address 142 of the network node 142 from the modified ICMP error message B, and maintains the path information shown in table 7.

TABLE 7

First hop node	IP address	131
			Second hop node	IP address	141
Third hop node	IP address	142

In step 327, the controller 121 generates a trace route packet C, where the content of the trace route packet C may be similar to the content of the trace route packet a, but the TTL value is 3, which is not described herein again.

In step 328, controller 121 sends traceroute packet C to edge node 131.

In step 329, edge node 131 sends traceroute packet C through physical port a.

In step 330, after receiving the traceroute packet C, the network node 141 subtracts 1 from the TTL value and changes the TTL value to 2, and the network node 141 sends the traceroute packet C with the TTL value modified to the network node 142.

In step 331, after receiving the traceroute packet C, the network node 142 subtracts 1 from the TTL value and changes the TTL value to 1, and the network node 142 sends the traceroute packet C with the TTL value modified to the gateway node 151.

Because a path between network node 142 and gateway node 151 fails, trace route message C cannot reach gateway node 151, and gateway node 151 cannot return an ICMP error message, to sum up, controller 121 cannot receive an ICMP error message for trace route message C.

In step 332, if the controller 121 does not receive the ICMP error message returned by the edge node 131 for the trace route message C, the controller 121 may determine that the path to be detected between the edge node 131 and the network node (i.e., the network node corresponding to the TTL value carried in the trace route message C) fails.

Since the TTL value carried in the traceroute packet C is 3, that is, the corresponding network node is the third hop node of the edge node 131, the path to be detected between the second hop node (i.e., the network node 142) of the edge node 131 and the third hop node (i.e., the gateway node 151) of the edge node 131 fails.

In summary, since the controller 121 does not receive the ICMP error message, the ICMP error message is not sent to the host 111, and the path information finally maintained by the host 111 is shown in table 7. Because the path information includes the IP address of the third hop node but not the IP address of the fourth hop node, the path between the third hop node and the fourth hop node has a fault, and the operation and maintenance staff can determine the specific location of the fault.

Based on the above technical solution, in this embodiment of the application, when the edge node sends the trace routing packet by querying the common routing table, the output interface of the common routing table is a physical port, instead of the VXLAN tunnel, and therefore, the edge node does not need to encapsulate the VXLAN tunnel header for the trace routing packet, so that the network node between the edge node and the gateway node can send an ICMP error packet to the edge node after receiving the trace routing packet, and the controller determines the path information of the path to be detected according to the response result of the trace routing packet. Obviously, even though a VXLAN tunnel is established between the edge node and the gateway node, the address of each network node between the edge node and the gateway node can be detected, and whether a fault exists in a path reaching each network node is detected, so that the fault position can be analyzed, and operation and maintenance personnel can quickly locate the fault point.

Based on the same application concept as the method described above, the embodiment of the present application further provides a method for determining path information, which can be applied to a controller, and is shown in fig. 4, which is a schematic flow chart of the method.

Step 401, receiving a first trace route packet sent by an edge node. The first trace routing message is used for determining path information of a path to be detected between a source node and a destination node, and the first trace routing message is sent to a controller after the edge node sends the first trace routing message through a query tunnel forwarding routing table.

In one example, before the controller receives a first trace route packet sent by an edge node, the controller may further send a first flow table to the edge node, where the first flow table is used for enabling the edge node to send the first trace route packet matching with the first flow table to the controller; wherein the matching options of the first flow table may include, but are not limited to: the protocol type is a UDP type and the destination port is a specified port identification.

For example, referring to step 201 above, the controller may send a first flow table to the edge node.

As shown in steps 204 and 208 above, the edge node may send the first traceroute message (i.e., traceroute message 1 and traceroute message 2) to the controller. Taking the traceroute packet 2 as an example, the traceroute packet 2 is used to determine the path information of the path to be detected between the source node (i.e. the host 111) and the destination node 181, and, referring to step 208, after the edge node 131 sends the traceroute packet 2 by querying the tunnel forwarding routing table, the traceroute packet 2 is sent to the controller.

Step 402, determining a gateway node for establishing a tunnel between an edge node and a destination node.

Step 403, generating a second trace route packet, where a source address of the second trace route packet is an address of the edge node, and a destination address of the second trace route packet is an address of the gateway node.

In one example, after receiving the first traceroute message, the controller may further start a timer and send a second flow table to the edge node, where the second flow table is used for enabling the edge node to send an ICMP error message matching with the second flow table to the controller; wherein the matching option of the second flow table may include: the protocol type is an ICMP type and the destination address is the source address of the first traceroute message.

Further, if the controller still does not receive the ICMP error message sent by the edge node after the timer expires, the controller may generate the second traceroute message.

For example, referring to step 205, the controller starts a timer and sends a second flow table to the edge node. Referring to step 309, after the timer expires, the controller determines a gateway node for establishing a tunnel between the edge node and the destination node, and generates a second traceroute packet (i.e., traceroute packet a).

Step 404, sending the second trace route packet to the edge node, so that the edge node sends the second trace route packet by querying the common routing table, that is, sending the second trace route packet through the physical port.

In an example, before the controller sends the second traceroute message to the edge node, a third flow table may also be sent to the edge node, where the third flow table is used for enabling the edge node to send an ICMP error message matched with the third flow table to the controller; wherein the matching options of the third flow table may include, but are not limited to: the protocol type is ICMP type and the destination address is the address of the edge node.

For example, the controller may send a third flow table to the edge node, see step 310.

The controller may send a second traceroute packet to the edge node, see step 311.

The edge node may send a second traceroute packet through the physical port, as shown in step 312. Specifically, the edge node queries the ordinary routing table through the destination address of the second trace route packet, obtains the physical port as the outgoing interface, and sends the second trace route packet through the physical port.

Step 405, determining the path information of the path to be detected according to the response result of the second trace route message.

Specifically, if the controller receives an ICMP error message returned by the edge node for the second trace route message, the controller may determine that the path to be detected between the edge node and the network node has not failed. Or, if the controller does not receive the ICMP error message returned by the edge node for the second trace route message, the controller may determine that the path to be detected between the edge node and the network node has a fault. And the network node is the network node corresponding to the TTL value carried by the second trace route message.

In an example, after receiving the ICMP error message returned by the edge node for the second trace route message, the controller may further determine the source address of the first trace route message as the address of the source node of the path to be detected, modify the destination address of the ICMP error message into the address of the source node, and send the modified ICMP error message to the source node. The source address of the ICMP error message before modification may be the address of the network node, and the destination address may be the address of the edge node.

For example, referring to steps 314 to 316, the edge node sends an ICMP error message to the controller, and the controller determines, according to the ICMP error message, that the path to be detected between the edge node and the network node is not faulty, and sends the ICMP error message to the source node. Referring to step 332, the controller does not receive the ICMP error message, and determines that the path to be detected between the edge node and the network node has a failure.

Based on the same application concept as the method, an embodiment of the present application further provides a path information determining apparatus applied to a controller, as shown in fig. 5, which is a structural diagram of the apparatus, and the apparatus includes:

a receiving module 51, configured to receive a first trace routing packet sent by an edge node, where the first trace routing packet is used to determine path information of a path to be detected between a source node and a destination node, and the first trace routing packet is sent to a controller after the edge node sends out a forwarding routing table through a query tunnel;

a determining module 52, configured to determine a gateway node that establishes a tunnel between the edge node and the destination node;

a generating module 53, configured to generate a second trace route packet, where a source address of the second trace route packet is an address of the edge node, and a destination address of the second trace route packet is an address of the gateway node;

a sending module 54, configured to send the second traceroute packet to the edge node, so that the edge node sends the second traceroute packet by querying a common routing table;

the determining module 52 is further configured to determine the path information of the path to be detected according to the response result of the second trace route packet.

The sending module 54 is further configured to send a first flow table to the edge node, where the first flow table is used to enable the edge node to send a first trace route packet matched with the first flow table to a controller; the matching options of the first flow table include: the protocol type is a UDP type and the destination port is a specified port identification.

The sending module 54 is further configured to start a timer after receiving the first trace route packet, and send a second flow table to the edge node, where the second flow table is used to enable the edge node to send an ICMP error packet matched with the second flow table to the controller; the matching options of the second flow table include: the protocol type is ICMP type, and the destination address is the source address of the first trace route message;

the generating module 53 is further configured to generate the second trace route packet if the ICMP error packet sent by the edge node is not received after the timer expires.

The sending module 54 is further configured to send a third flow table to the edge node, where the third flow table is used to enable the edge node to send an ICMP error message matched with the third flow table to the controller; the matching options of the third flow table include: the protocol type is ICMP type and the destination address is the address of the edge node.

The determining module 52 is specifically configured to, when determining the path information of the path to be detected according to the response result of the second trace route packet: if an ICMP error message returned by the edge node aiming at the second tracking routing message is received, determining that the path to be detected between the edge node and the network node has no fault; if the ICMP error message returned by the edge node aiming at the second tracking routing message is not received, determining that the path to be detected between the edge node and the network node has a fault; and the network node is the network node corresponding to the TTL value carried by the second trace route message.

The sending module 54 is further configured to determine a source address of the first trace routing packet as an address of a source node of the path to be detected; modifying the destination address of the ICMP error message into the address of the source node, and sending the modified ICMP error message to the source node; wherein, the source address of the ICMP error message before modification is the address of the network node, and the destination address is the address of the edge node.

In the embodiment of the present application, for a hardware level, a schematic diagram of a hardware architecture of a controller may specifically refer to fig. 6. The method comprises the following steps: a machine-readable storage medium and a processor, wherein: the machine-readable storage medium: storing machine executable instructions executable by the processor. The processor: the path information determination operations disclosed in the above examples of the present application are implemented by communicating with a machine-readable storage medium, reading and executing machine-executable instructions stored in the machine-readable storage medium.

Here, 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 so forth. For example, the machine-readable storage medium may be: a RAM (random Access Memory), a volatile Memory, a non-volatile Memory, a flash Memory, a storage drive (e.g., a hard drive), a solid state drive, any type of storage disk (e.g., an optical disk, a dvd, etc.), or similar storage medium, or a combination thereof.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the units may be implemented in one or more software and/or hardware when implementing the present application.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

Furthermore, these computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for determining path information, applied to a controller, the method comprising:

2. The method of claim 1,

before the receiving the first trace route packet sent by the edge node, the method further includes:

sending a first flow table to the edge node, wherein the first flow table is used for enabling the edge node to send a first trace routing message matched with the first flow table to the controller; wherein the matching options of the first flow table include: the protocol type is a UDP type and the destination port is a specified port identification.

3. The method of claim 1,

before generating the second traceroute packet, the method further includes:

after receiving the first trace routing message, starting a timer, and sending a second flow table to the edge node, where the second flow table is used to enable the edge node to send an ICMP error message matched with the second flow table to the controller; wherein the matching options of the second flow table include: the protocol type is ICMP type, and the destination address is the source address of the first trace route message;

and if the ICMP error message sent by the edge node is not received after the timer is overtime, executing the step of generating the second trace route message.

4. The method of claim 1,

before sending the second traceroute packet to the edge node, the method further includes:

sending a third flow table to the edge node, wherein the third flow table is used for enabling the edge node to send an ICMP error message matched with the third flow table to the controller; wherein the matching options of the third flow table include: the protocol type is ICMP type and the destination address is the address of the edge node.

5. The method according to claim 1, wherein the determining the path information of the path to be detected according to the response result of the second traceroute packet includes:

if an ICMP error message returned by the edge node aiming at the second tracking routing message is received, determining that the path to be detected between the edge node and the network node has no fault;

if the ICMP error message returned by the edge node aiming at the second tracking routing message is not received, determining that the path to be detected between the edge node and the network node has a fault;

and the network node is the network node corresponding to the TTL value carried by the second trace route message.

6. The method according to claim 5, wherein after receiving the ICMP error message returned by the edge node for the second traceroute message, the method further comprises:

determining a source address of the first tracking routing message as an address of a source node of the path to be detected;

modifying the destination address of the ICMP error message into the address of the source node, and sending the modified ICMP error message to the source node; wherein, the source address of the ICMP error message before modification is the address of the network node, and the destination address is the address of the edge node.

7. A path information determination apparatus, applied to a controller, the apparatus comprising:

8. The apparatus of claim 7, wherein the sending module is further configured to send a first flow table to the edge node, and the first flow table is configured to enable the edge node to send a first traceroute packet matching the first flow table to the controller; wherein the matching options of the first flow table include: the protocol type is a UDP type and the destination port is a specified port identification.

9. The apparatus of claim 7,

the sending module is further configured to start a timer after receiving the first trace routing packet, and send a second flow table to the edge node, where the second flow table is used to enable the edge node to send an ICMP error packet matched with the second flow table to the controller; the matching options of the second flow table include: the protocol type is ICMP type, and the destination address is the source address of the first trace route message;

the generating module is further configured to generate the second trace route packet if the ICMP error packet sent by the edge node is not received after the timer expires.

10. The apparatus of claim 7, wherein the sending module is further configured to send a third flow table to the edge node, and the third flow table is configured to enable the edge node to send an ICMP error message matching the third flow table to the controller; wherein the matching options of the third flow table include: the protocol type is ICMP type and the destination address is the address of the edge node.

11. The apparatus according to claim 7, wherein the determining module, when determining the path information of the path to be detected according to the response result of the second traceroute packet, is specifically configured to:

12. The apparatus of claim 11,

the sending module is further configured to determine a source address of the first trace routing packet as an address of a source node of the path to be detected; modifying the destination address of the ICMP error message into the address of the source node, and sending the modified ICMP error message to the source node; wherein, the source address of the ICMP error message before modification is the address of the network node, and the destination address is the address of the edge node.