CN108833272B - Route management method and device - Google Patents

Route management method and device Download PDF

Info

Publication number
CN108833272B
CN108833272B CN201810637822.9A CN201810637822A CN108833272B CN 108833272 B CN108833272 B CN 108833272B CN 201810637822 A CN201810637822 A CN 201810637822A CN 108833272 B CN108833272 B CN 108833272B
Authority
CN
China
Prior art keywords
address
route
notification message
mac
next hop
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201810637822.9A
Other languages
Chinese (zh)
Other versions
CN108833272A (en
Inventor
黄李伟
王伟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou H3C Technologies Co Ltd
Original Assignee
Hangzhou H3C Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou H3C Technologies Co Ltd filed Critical Hangzhou H3C Technologies Co Ltd
Priority to CN201810637822.9A priority Critical patent/CN108833272B/en
Publication of CN108833272A publication Critical patent/CN108833272A/en
Application granted granted Critical
Publication of CN108833272B publication Critical patent/CN108833272B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing

Landscapes

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

Abstract

The application provides a route management method, which is applied to a first ED of a first DC, wherein the first ED and a second ED belong to an ED group, and the method comprises the following steps: receiving a fault notification message sent by the second ED, wherein the fault notification message is used for indicating that a VXLAN tunnel from the second ED to a third ED has a fault, the third ED is an edge device of the second DC, and the fault notification message carries an address of the third ED; aiming at the received IP/MAC advertisement route which takes the address of the third ED as the next hop, the next hop address of the IP/MAC advertisement route is changed into the private address of the first ED and then is forwarded to the VTEP equipment in the first DC; and enabling the VTEP equipment in the first DC to generate a forwarding table item based on the modified IP/MAC notification route, and forwarding the message sent to the second DC through the first ED based on the generated forwarding table item.

Description

Route management 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 route management.
Background
In the current big background of cloud computing, the demand of rapid and optimal scheduling and deployment of resources by enterprises brings great challenges to the decentralized and independent DC (Data Center) architecture. In order to better realize the integration of resources, a plurality of traditionally isolated DCs can be integrated together into a distributed data center through ED (Edge Device), so that the resources are fully utilized.
In order to improve the high reliability of the EDs, a scheme of ED groups is introduced, and one ED group may include at least two EDs; if any ED in an ED group fails, the traffic that would otherwise be forwarded through the failed ED may be switched to other EDs in the same ED group.
Disclosure of Invention
The application provides a route management method and a route management device.
Specifically, the method is realized through the following technical scheme:
in a first aspect of an embodiment of the present application, a method for route management is provided, where the method is applied to a first ED of a first DC, and the first ED and a second ED belong to an ED group, and the method includes:
receiving a fault notification message sent by the second ED, where the fault notification message is used to indicate that VXLAN tunnels from the second ED to a third ED have faults, the third ED is an edge device of a second DC, and the fault notification message carries an address of the third ED;
for the received IP/MAC advertisement route with the address of the third ED as the next hop, modifying the next hop address of the IP/MAC advertisement route into the private address of the first ED, and forwarding the IP/MAC advertisement route to the VTEP device in the first DC; and enabling the VTEP equipment in the first DC to generate a forwarding table item based on the modified IP/MAC notification route, and forwarding the message sent to the second DC through the first ED based on the generated forwarding table item.
In a second aspect of the embodiments of the present application, a routing management apparatus is provided, where the apparatus is applied to a first ED of a first DC, and the first ED and a second ED belong to an ED group. The apparatus has the function of implementing the method provided by the first aspect described above. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules or units corresponding to the above functions.
In one possible implementation, the apparatus may include:
a receiving unit, configured to receive a failure notification message sent by the second ED, where the failure notification message is used to indicate that VXLAN tunnels from the second ED to a third ED have a failure, the third ED is an edge device of a second DC, and the failure notification message carries an address of the third ED;
a route management unit, configured to modify, for a received IP/MAC advertisement route using the address of the third ED as a next hop address, the next hop address of the IP/MAC advertisement route to the private address of the first ED, and forward the modified IP/MAC advertisement route to the VTEP device in the first DC; and enabling the VTEP equipment in the first DC to generate a forwarding table item based on the modified IP/MAC notification route, and forwarding the message sent to the second DC through the first ED based on the generated forwarding table item.
In another possible implementation manner, the ED in which the apparatus is located may include a communication interface, a processor, a memory, and a bus, where the communication interface, the processor, and the memory are connected to each other through the bus; the processor executes the routing management method provided by the first aspect of the present application by reading the logic instructions stored in the memory.
By using the technical scheme of the embodiment of the application, the failure notification message is newly added, and after it is confirmed that a link between one ED in an ED group of the local data center and a certain remote data center is disconnected, the ED can notify addresses of edge devices corresponding to the remote data center to other EDs of the same ED group through the failure notification message, so that the other EDs can notify next hops of all IP/MAC notification routes synchronized by the remote data center to switch to private addresses of the other EDs, traffic forwarded to the remote data center by the local data center is only forwarded to the other EDs, and traffic forwarded to the other data centers by the local data center still goes through the common address of the ED group for hash forwarding.
Drawings
Fig. 1, 2 and 3 are scene diagrams of DCI;
FIG. 4 is a flow chart of a method provided by an embodiment of the present application;
fig. 5 is a schematic view of a DCI scenario provided in an embodiment of the present application;
FIG. 6 is a block diagram of functional modules of an apparatus provided in an embodiment of the present application;
fig. 7 is a hardware configuration diagram of the apparatus shown in fig. 6 according to an embodiment of the present application.
Detailed Description
The present application is described in detail below with reference to the attached drawings.
Fig. 1 is a schematic diagram of a DCI (DC Connection, data center interconnection) scenario. As shown in fig. 1, the scenario includes two data centers: DC1 and DC2, DC1 and DC2 are interconnected by two ED groups, ED group 1 of DC1 includes two edge devices: ED1 and ED2, ED group 2 of DC2 also includes two edge devices: ED3 and ED 4. ED1 and ED2 have a group address (e.g., 2.2.2.2) as a whole for an ED group, and similarly ED3 and ED4 have a group address (e.g., 3.3.3.3) as a whole for an ED group. Traffic between DC1 and DC2 may be load-shared between 2 EDs of an ED group; meanwhile, if any ED in the ED group fails, for example, the ED1 in the ED group 1 fails, traffic originally forwarded through the ED1 may be carried through the ED2 of the ED group 1, which improves reliability.
It can be understood that, in a DCI scenario, devices may communicate based on an IP (Internet Protocol) address or a MAC (Medium Access Control) address. The group address where the ED1 and ED2 (or ED3 and ED4) appear as a whole as an ED group may be a group IP address or a group MAC address.
For example, for the ED group 1, the ED1 group is 2 devices capable of load sharing for VTEP (Virtual Extensible LAN Tunnel End Point) devices in the DC1, such as VTEP1, that is, VTEP1 knows only the ED1 group, and VTEP1 only establishes a VXLAN (Virtual Extensible LAN) Tunnel using the group address of the ED group 1 as the destination address, so that traffic sent by VTEP1 is hash-forwarded to two devices in the ED1 group. If any ED in ED1 group fails, such as the link interconnecting ED1 and DC2 (i.e., the VXLAN tunnel from ED1 to ED group 2), VTEP1 is unaware and will still forward VTEP1 to DC2 to ED 1.
In the current solution, referring to fig. 2, when sensing that the link interconnecting ED1 and DC2 fails, the physical link directly connecting ED1 and the DC1 internal device (e.g., route reflector RR1 in fig. 2) is directly closed, and the traffic is completely switched to another device ED2 in ED1 group.
However, this solution has the following problems: if there are more than 2 DCs in the networking, as shown in fig. 3, and DC1 is also interconnected with DC3, then closing the physical link connecting ED1 and DC1 internal devices would result in traffic between DC1 and DC3 not being able to load-share using ED group 1; while the link between ED group 1 and ED group 3 of DC3 is still normal in nature, load sharing could theoretically occur, but the load sharing function of ED group 1 fails due to the failure of the link between DC1 and DC 2.
In order to solve the above problems, the present application proposes a route management method and a route management apparatus to which the method is applicable.
The methods provided herein are described below.
Referring to fig. 4, in one embodiment, the first DC and the second DC are interconnected, and there is one ED group at an edge of the first DC, the ED group including at least a first ED and a second ED; there may be one ED group of edges of the second DC, which includes at least a third ED, or there may be only a third ED at the edges of the second DC. In this embodiment, the interaction between the first ED and the second ED is described in steps 401-402.
It should be noted that the terms first, second, third, etc. may be used herein to describe various information, but 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.
Step 401: the second ED sends a failure notification message to other EDs of its ED group when detecting that the VXLAN tunnel from local to third ED fails.
The failure notification message is a new message type added in the present application, and the message may carry an address for indicating that a VXLAN tunnel from a sending end of the failure notification message to a device corresponding to the address fails, where the device corresponding to the address and the sending end of the failure notification message are edge devices of different DCs. For example, in step 401, the failure notification message sent by the second ED is specifically used to indicate that VXLAN tunnels from the second ED to the third ED fail, and the failure notification message may carry an address of the third ED.
As an implementation manner, if links between the second ED and the multiple data centers simultaneously fail, addresses of edge devices of the multiple data centers may be simultaneously carried in the failure notification message.
In the embodiment of the present application, the fault notification message may have multiple implementation manners, for example, the fault notification message may be implemented by a new protocol message, for example, the fault notification message may be implemented by adding a new EVPN route based on the existing eight EVPN routes; and for another example, the method can be implemented by existing protocol messages, for example, a new field can be added in an existing EVPN Route of two types, namely, a MAC/IP Advertisement Route (MAC/IP Advertisement Route).
Step 402: the first ED receives a fault notification message sent by a second ED of the same ED group, extracts the address of a third ED from the fault notification message, modifies the next hop address of the IP/MAC notification route into the private address of the first ED aiming at the locally received IP/MAC notification route taking the address of the third ED as the next hop, and forwards the IP/MAC notification route to VTEP equipment in the first DC.
Here, the IP/MAC advertisement route that needs to be modified includes an IP/MAC advertisement route having the address of the third ED as a next hop received before receiving the failure notification message, and includes an IP/MAC advertisement route having the address of the third ED as a next hop received after receiving the failure notification message. The specific modification mode is as follows:
in one aspect, for an IP/MAC advertisement route received before receiving the failure notification message with the address of the third ED as the next hop, the first ED may modify the next hop of the IP/MAC advertisement route to the private address of the first ED and forward to a VTEP device within the first DC. The private address is an address additionally configured for the EDs in the ED group in the embodiment of the present application, that is, each ED in the ED group has 1 mutually different private address and one common group address.
On the other hand, after receiving the failure notification message, the first ED may also add the address of the third ED to the established address list. In this embodiment of the present application, each ED in an ED group may create an address list in advance, where the address list is used to record an address carried by a fault notification message received by the ED. Based on the address list, the ED is further added with the following processing mechanism: when receiving an IP/MAC notification route synchronized with a remote ED, matching the next hop of the IP/MAC notification route with an address list recorded locally; if the IP/MAC notification route is matched with the ED, modifying the next hop of the IP/MAC notification route from the group address of the ED to the private address of the ED, and forwarding the next hop to the VTEP equipment in the DC to which the ED belongs; and if not, directly forwarding the received IP/MAC notification route to the VTEP equipment in the DC to which the ED belongs without modifying the next hop.
In the carrying step 402, after the first ED modifies the next hop address of the IP/MAC advertisement route, which is received locally and uses the address of the third ED as the next hop, into the private address of the first ED, and forwards the modified IP/MAC advertisement route to the VTEP device in the first DC, the VTEP device in the first DC may generate a forwarding table entry based on the modified IP/MAC advertisement route, where a matching entry of the forwarding table entry is the terminal address in the modified IP/MAC advertisement route (i.e., the address of the terminal in the second DC), and an outgoing interface of the forwarding table entry is a VXLAN tunnel using the address of the VTEP device in the first DC as the source address and the private address of the first ED as the destination address. Based on such forwarding table entries, the VTEP device in the first DC may forward the packet addressed to the second DC through the first ED, but not through the second ED.
In one embodiment, if the ED group of the first DC includes a fourth ED in addition to the first ED and the second ED, when the second ED detects that the link between the second ED and the second DC fails, the fourth ED also receives a failure notification message sent by the second ED, performs the same operation as the first ED, modifies the next hop of the IP/MAC notification route, which is received locally and uses the address of the third ED as the next hop, into the private address of the fourth ED, and forwards the modified IP/MAC notification route to the VTEP device in the first DC. VTEP equipment in the first DC generates a forwarding table item according to the modified IP/MAC notification route sent by the first ED and the fourth ED; based on the forwarding table entry, traffic sent by the first DC to the second DC may be forwarded through the first ED or the fourth ED, but may not pass through the second ED.
In another embodiment, if the ED group of the first DC includes a fourth ED in addition to the first ED and the second ED, a spare group address may be preconfigured; when the second ED detects that a link between the second ED and the second DC fails, the first ED and the fourth ED may modify the next hop of the IP/MAC advertised route into the standby group address in a unified manner for the locally received IP/MAC advertised route using the address of the third ED as the next hop, and forward the standby group address to the VTEP device in the first DC, so that the VTEP device in the first DC generates a forwarding entry according to the modified IP/MAC advertised route sent by the first ED and the fourth ED; based on the forwarding table entry, the first DC traffic destined for the second DC may be load-shared by the first ED and the fourth ED, and may not pass through the second ED.
Based on the scheme described above, it is assumed that the first DC is interconnected not only with the second DC but also with the third DC; then in case the link between the second ED and the second DC fails, but the link between the second ED and the third DC is normal, the second ED may still forward messages from the first DC to the third DC and messages from the third DC to the first DC, although it cannot transmit messages between the first DC and the second DC. Therefore, the load sharing is carried out by utilizing the multiple EDs to the maximum extent in the data center interconnection network, and the phenomenon that the load sharing function of the ED group fails due to the fact that a link for interconnecting one ED and one data center in the ED group breaks down is avoided.
In one embodiment, the second ED may send a failure recovery notification message to other EDs of the ED group to which it belongs when it detects that the VXLAN tunnel local to the third ED is recovering normally.
The failure recovery notification message is also a new message type in the present application, and the message may carry an address for indicating that the VXLAN tunnel from the sending end of the failure recovery notification message to the device corresponding to the address is recovered to normal, where the device corresponding to the address and the sending end of the failure recovery notification message are different DC edge devices. For example, the failure notification message sent by the second ED is specifically used to indicate that VXLAN tunnels from the second ED to the third ED are recovered to be normal, and the failure notification message may carry an address of the third ED.
After receiving the failure recovery notification message, a first ED belonging to the same ED group as a second ED modifies the next hop of the IP/MAC advertisement route to the group address of the first ED and forwards the modified IP/MAC advertisement route to a VTEP device in the first DC, wherein the IP/MAC advertisement route is received before receiving the failure recovery notification message and takes the address of the third ED as the next hop; on the other hand, after receiving the failure recovery notification message, the address of the third ED may be deleted from the established address list. Thus, when the first ED receives the IP/MAC advertisement route synchronized with the third ED later, the next hop of the IP/MAC advertisement route will not match the address list any more, and the first ED can directly forward the received IP/MAC advertisement route to the VTEP device in the first DC without modifying the next hop. Thereafter, the first DC to second DC traffic may be re-load shared on the first ED and the second ED.
The flow shown in fig. 4 is completed.
As can be seen from the process shown in fig. 4, a failure notification message is newly added in the present application, and after it is determined that a link between an ED in an ED group of a local data center and a remote data center is disconnected, the ED may notify addresses of edge devices corresponding to the remote data center to other EDs of the same ED group through the failure notification message, so that the other EDs may switch all the next hops of an IP/MAC notification route synchronized by the remote data center to private addresses of the other EDs, and forward traffic forwarded by the local data center to the remote data center only to the other EDs, and the traffic forwarded by the local data center to the other data centers still goes through the common address of the ED group for hash forwarding.
In order to make it clear and obvious for those skilled in the art, the flow shown in fig. 4 is described below by taking the DCI scene shown in fig. 5 as an example.
Referring to fig. 5, fig. 5 is a schematic diagram of networking according to an embodiment provided in the present application. As shown in fig. 5, there are three data centers: DC1, DC2, and DC 3. ED group 1 of DC1 includes two edge devices: ED1 and ED2, ED group 2 of DC2 also includes two edge devices: ED3 and ED4, DC3 has only one edge device: ED 5.
In fig. 5, ED group 1 is configured as follows:
1) set the group address of ED1 and ED2 to 2.2.2.2; normally ED group 1 is this address used for both VXLAN tunneling and for synchronous EVPN routing;
2) ED1 and ED2 establish VXLAN tunnels with VTEP devices in DC 1;
taking VTEP1 as an example, if the address of VTEP1 is 1.1.1.1, VXLAN tunnel 1 is created on ED1 and ED2, the source address is 2.2.2.2, and the destination address is 1.1.1.1;
a VXLAN tunnel 2 is established on the VTEP1, the source address is 1.1.1.1, and the destination address is 2.2.2.2;
3) 1 private address is configured for ED1 and ED2 respectively, the private address of ED1 is 1.1.1.2, and the private address of ED2 is 1.1.1.3;
4) respectively creating address lists on the ED1 and the ED2, wherein the address lists are empty lists initially;
5) when the EDs 1 and ED2 and the remote EDs in ED group 1, such as ED3, ED4, and ED5, establish BGP EVPN neighbors and establish VXLAN tunnels, the address of the remote ED is locally recorded as follows:
TABLE 1
ED value Address
2 (ED value for ED group 2) 3.3.3.3 (group address of ED3, ED4)
3(ED value for ED 5) 5.5.5.5(ED5 address)
Similarly, the ED group 2 and the ED5 are configured correspondingly; ED5 only needs to configure one address and does not need to create an address list.
Based on the above configuration, the interaction between the data centers is as follows:
in DC2, VM2 goes online, and ED group 2 synchronizes the IP/MAC address of VM2 to ED group 1 through an IP/MAC advertisement route whose next hop is group address 3.3.3.3 of ED group 2.
Assuming that ED1 receives the IP/MAC advertised route of VM2, ED1 matches the next hop 3.3.3.3 of the IP/MAC advertised route to the local address list; since the address list is also empty at this time and therefore does not match, ED1 sends the IP/MAC advertisement route directly to VTEP1 without modifying the next hop.
VTEP1 receives the IP/MAC advertisement route of VM2, establishes a forwarding table entry to VM 2: the match is 10.1.1.2/32 (address of VM 2) and the egress interface is VXLAN tunnel 2.
Similarly, when the VM3 in the DC3 goes online, a forwarding entry to the VM3 is finally established on the VTEP1, the matching entry is 12.1.1.2/32, and the outgoing interface is the VXLAN tunnel 2.
ED1 finds that a link between itself and two ED devices (ED3 and ED4) of ED group 2 is down, constructs a failure notification message according to table 1 above, and sends the failure notification message to ED2, where the failure notification message carries the group address 3.3.3.3 of ED group 2.
When the ED2 receives the failure notification message sent by the ED1, the next hop of all the received IP/MAC advertisement routes with 3.3.3.3 as the next hop is modified to the private address 1.1.1.3 of the ED2, such as the IP/MAC advertisement route of the VM 2; and adds 3.3.3.3 to the address list.
The ED2 sends the modified IP/MAC advertisement route of the VM2 to the VTEP1 device to update the forwarding table entry on the VTEP 1.
After receiving the modified IP/MAC notification route of the VM2 sent by the ED2, the VTEP1 establishes a VXLAN tunnel 3, wherein the source address is 1.1.1.1 and the destination address is 1.1.1.3; and switches the outgoing interface of the local to VM2 forwarding entry to VXLAN tunnel 3 to the private address of ED 2.
Thus, on VTEP1, the outgoing interface of the forwarding table entry to VM2 is VXLAN tunnel 3; the forwarding entry to VM3 still maintains the original VXLAN tunnel 2.
Within DC1, traffic for VM1 to access VM2 is forwarded only through ED 2; while the traffic of VM1 to access VM3 is still load-shared by ED1 and ED2 of ED group 1.
When ED1 finds that the link between itself and the two ED devices of ED group 2 (ED3 and ED4) is restored to normal, ED1 sends a failure recovery notification message to ED2, where the failure recovery notification message carries the group address 3.3.3.3 of ED group 2.
The ED2 receives the failure recovery notification message sent by the ED1, and then modifies the next hop of all the received IP/MAC advertised routes with 3.3.3.3 as the next hop to the group address 2.2.2.2 of the ED2, such as the IP/MAC advertised route of the VM 2; and removes 3.3.3.3 from the address list.
The ED2 sends the modified IP/MAC advertisement route of the VM2 to the VTEP1 device to update the forwarding table entry on the VTEP 1.
After receiving the modified IP/MAC advertisement route of VM2 sent by ED2, VTEP1 switches the egress interface of the local to VM2 forwarding table entry to VXLAN tunnel 2 again.
The traffic of VM1 to VM2 may be re-load shared at ED1 and ED2 of ED group 1.
The methods provided herein are described above. The apparatus provided in the present application is described below.
Referring to fig. 6, for the present application, a routing management apparatus applied to a first ED of a first DC, where the first ED and a second ED belong to an ED group, may include:
a receiving unit 601, configured to receive a failure notification message sent by the second ED, where the failure notification message is used to indicate that VXLAN tunnels from the second ED to a third ED have a failure, the third ED is an edge device of a second DC, and the failure notification message carries an address of the third ED;
a route management unit 602, configured to modify, for a received IP/MAC advertisement route using the address of the third ED as a next hop address, the next hop address of the IP/MAC advertisement route into a private address of the first ED, and forward the modified IP/MAC advertisement route to a VTEP device in the first DC; and enabling the VTEP equipment in the first DC to generate a forwarding table item based on the modified IP/MAC notification route, and forwarding the message sent to the second DC through the first ED based on the generated forwarding table item.
In one embodiment, the route management unit 602 is configured to: for an IP/MAC advertisement route which is received before the fault notification message and takes the address of the third ED as the next hop, modifying the next hop of the IP/MAC advertisement route into the private address of the first ED and forwarding the IP/MAC advertisement route to VTEP equipment in the first DC; and after receiving the fault notification message, adding the address of the third ED to an established address list; the address list is used for matching the next hop of the IP/MAC notification route received by the first ED, if the IP/MAC notification route is matched with the next hop, the route management unit modifies the next hop of the IP/MAC notification route into the private address of the first ED and forwards the private address to the VTEP device in the first DC.
In one embodiment, the matching item of the forwarding table item is a terminal address in a modified IP/MAC notification route; the output interface of the forwarding table entry is a VXLAN tunnel which takes the address of the VTEP device in the first DC as a source address and the private address of the first ED as a destination address.
In one embodiment, the receiving unit 601 is further configured to receive a failure recovery notification message sent by the second ED, where the failure recovery notification message is used to indicate that VXLAN tunnels from the second ED to the third ED are recovered to be normal, and the failure recovery notification message carries an address of the third ED;
the route management unit 602 is further configured to modify, for an IP/MAC advertisement route that is received before the failure recovery notification message and takes the address of the third ED as a next hop, the next hop of the IP/MAC advertisement route to a group address of the first ED, and forward the IP/MAC advertisement route to a VTEP device in the first DC; and deleting the address of the third ED from the established address list after receiving the failure recovery notification message.
In one embodiment, the apparatus further comprises:
a sending unit, configured to send a failure notification message to other EDs of an ED group to which a first ED belongs when detecting that a VXLAN tunnel from local to a fourth ED fails, where the fourth ED is an edge device of a third DC; and when detecting that the VXLAN tunnel from the local ED to the fourth ED is recovered normally, sending a failure recovery notification message to other EDs of the ED group to which the first ED belongs.
In one embodiment, the sending unit is further configured to, after detecting that a VXLAN tunnel from the local device to the fourth ED fails, forward a packet from the first DC to the fourth DC if the VXLAN tunnels from the first ED to the fifth ED are normal and the fifth ED is an edge device of the fourth DC before detecting that the VXLAN tunnel from the local device to the fourth ED recovers to normal.
It should be noted that the division of the unit in the embodiment of the present invention is schematic, and is only a logic function division, and there may be another division manner in actual implementation. The functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
So far, the description of the functional modules of the device shown in fig. 6 is completed.
Correspondingly, the application also provides a hardware structure of the device shown in fig. 6. Referring to fig. 7, fig. 7 is a schematic diagram of a hardware structure of an ED where the routing management device shown in fig. 6 is located, where the ED includes: a communication interface 701, a processor 702, a memory 703, and a bus 704; the communication interface 701, the processor 702, and the memory 703 complete communication with each other through the bus 704.
The bus 704 may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus 704 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus.
The communication interface 701 is used for communication with other devices.
The Memory 703 may include a Random Access Memory (RAM) or a Non-Volatile Memory (NVM), such as at least one disk Memory. Optionally, the memory may also be at least one memory device located remotely from the processor. The memory 703 may have stored therein route management logic instructions.
The Processor 702 may be a general-purpose Processor including a Central Processing Unit (CPU), a Network Processor (NP), etc.; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components. The processor 702 may execute the routing management logic instructions stored in the memory 703 to implement the method illustrated in fig. 4 described above.
Thus, the description of the hardware structure of the apparatus shown in fig. 7 is completed.
The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims (12)

1. A method for route management, applied to a first edge device ED of a first data center DC, the first ED and a second ED belonging to an ED group, the method comprising:
receiving a fault notification message sent by the second ED, where the fault notification message is used to indicate that VXLAN tunnels from the second ED to a third ED have faults, the third ED is an edge device of a second DC, and the fault notification message carries an address of the third ED;
for the received IP/MAC advertisement route with the address of the third ED as the next hop, modifying the next hop address of the IP/MAC advertisement route into the private address of the first ED, and forwarding the IP/MAC advertisement route to the VTEP device in the first DC; and enabling the VTEP equipment in the first DC to generate a forwarding table item based on the modified IP/MAC notification route, and forwarding the message sent to the second DC through the first ED based on the generated forwarding table item.
2. The method according to claim 1, wherein the forwarding to the VTEP device within the first DC after modifying the next hop address of the IP/MAC advertisement route to the private address of the first ED for the received IP/MAC advertisement route having the address of the third ED as the next hop, comprises:
for an IP/MAC advertisement route which is received before the fault notification message and takes the address of the third ED as the next hop, modifying the next hop of the IP/MAC advertisement route into the private address of the first ED and forwarding the IP/MAC advertisement route to VTEP equipment in the first DC; and
adding the address of the third ED to an established address list after receiving the failure notification message; the address list is used for matching the next hop of the IP/MAC notification route received by the first ED, if the IP/MAC notification route is matched with the next hop, the first ED modifies the next hop of the IP/MAC notification route into a private address of the first ED and forwards the private address to VTEP equipment in the first DC.
3. The method of claim 1, wherein the matching entry of the forwarding table entry is a terminal address in the modified IP/MAC advertisement route; the output interface of the forwarding table entry is a VXLAN tunnel which takes the address of the VTEP device in the first DC as a source address and the private address of the first ED as a destination address.
4. The method according to claim 1, wherein after receiving the failure notification message sent by the second ED, the method further comprises:
receiving a failure recovery notification message sent by the second ED, where the failure recovery notification message is used to indicate that VXLAN tunnels from the second ED to the third ED are recovered to be normal, and the failure recovery notification message carries an address of the third ED;
for an IP/MAC advertisement route which is received before the fault recovery notification message and takes the address of the third ED as the next hop, modifying the next hop of the IP/MAC advertisement route into the group address of the first ED, and forwarding the IP/MAC advertisement route to VTEP equipment in the first DC; and
after receiving the failure recovery notification message, the address of the third ED is deleted from the established address list.
5. The method of claim 1, wherein the method further comprises:
when detecting that a VXLAN tunnel from a local ED to a fourth ED fails, sending a failure notification message to other EDs in an ED group to which the first ED belongs, wherein the fourth ED is an edge device of a third DC;
and when detecting that the VXLAN tunnel from the local ED to the fourth ED is recovered normally, sending a failure recovery notification message to other EDs of the ED group to which the first ED belongs.
6. The method of claim 5, wherein after detecting the VXLAN tunnel failure local to the fourth ED, prior to detecting the VXLAN tunnel local to the fourth ED recovering normal, the method further comprises:
if the VXLAN tunnels from the first ED to the fifth ED are normal and the fifth ED is an edge device of a fourth DC, forwarding the message from the first DC to the fourth DC, and forwarding the message from the fourth DC to the first DC.
7. A routing management apparatus, applied to a first edge device ED of a first data center DC, the first ED and a second ED belonging to an ED group, the apparatus comprising:
a receiving unit, configured to receive a failure notification message sent by the second ED, where the failure notification message is used to indicate that VXLAN tunnels from the second ED to a third ED have a failure, the third ED is an edge device of a second DC, and the failure notification message carries an address of the third ED;
a route management unit, configured to modify, for a received IP/MAC advertisement route using the address of the third ED as a next hop address, the next hop address of the IP/MAC advertisement route to the private address of the first ED, and forward the modified IP/MAC advertisement route to the VTEP device in the first DC; and enabling the VTEP equipment in the first DC to generate a forwarding table item based on the modified IP/MAC notification route, and forwarding the message sent to the second DC through the first ED based on the generated forwarding table item.
8. The apparatus of claim 7, wherein the route management unit is to:
for an IP/MAC advertisement route which is received before the fault notification message and takes the address of the third ED as the next hop, modifying the next hop of the IP/MAC advertisement route into the private address of the first ED and forwarding the IP/MAC advertisement route to VTEP equipment in the first DC; and
adding the address of the third ED to an established address list after receiving the failure notification message; the address list is used for matching the next hop of the IP/MAC notification route received by the first ED, if the IP/MAC notification route is matched with the next hop, the route management unit modifies the next hop of the IP/MAC notification route into the private address of the first ED and forwards the private address to the VTEP device in the first DC.
9. The apparatus of claim 7, wherein the matching entry of the forwarding table entry is a terminal address in the modified IP/MAC advertisement route; the output interface of the forwarding table entry is a VXLAN tunnel which takes the address of the VTEP device in the first DC as a source address and the private address of the first ED as a destination address.
10. The apparatus of claim 7,
the receiving unit is further configured to receive a failure recovery notification message sent by the second ED, where the failure recovery notification message is used to indicate that VXLAN tunnels from the second ED to the third ED are recovered to be normal, and the failure recovery notification message carries an address of the third ED;
the route management unit is further configured to modify, for an IP/MAC advertisement route received before receiving the failure recovery notification message and having an address of the third ED as a next hop, the next hop of the IP/MAC advertisement route to a group address of the first ED, and forward the IP/MAC advertisement route to a VTEP device in the first DC; and deleting the address of the third ED from the established address list after receiving the failure recovery notification message.
11. The apparatus of claim 7, wherein the apparatus further comprises:
a sending unit, configured to send a failure notification message to other EDs of an ED group to which a first ED belongs when detecting that a VXLAN tunnel from local to a fourth ED fails, where the fourth ED is an edge device of a third DC; and when detecting that the VXLAN tunnel from the local ED to the fourth ED is recovered normally, sending a failure recovery notification message to other EDs of the ED group to which the first ED belongs.
12. The apparatus of claim 11,
the sending unit is further configured to, after detecting that a VXLAN tunnel from the local to the fourth ED fails, before detecting that the VXLAN tunnel from the local to the fourth ED recovers to be normal, forward a message from the first DC to the fourth DC if the VXLAN tunnel from the first ED to the fifth ED is normal and the fifth ED is an edge device of the fourth DC, and forward the message from the fourth DC to the first DC.
CN201810637822.9A 2018-06-20 2018-06-20 Route management method and device Active CN108833272B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810637822.9A CN108833272B (en) 2018-06-20 2018-06-20 Route management method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810637822.9A CN108833272B (en) 2018-06-20 2018-06-20 Route management method and device

Publications (2)

Publication Number Publication Date
CN108833272A CN108833272A (en) 2018-11-16
CN108833272B true CN108833272B (en) 2021-04-27

Family

ID=64141604

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810637822.9A Active CN108833272B (en) 2018-06-20 2018-06-20 Route management method and device

Country Status (1)

Country Link
CN (1) CN108833272B (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12003409B2 (en) 2022-08-29 2024-06-04 Cisco Technology, Inc. Hierarchical ECMP control plane for dense topologies

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11431619B2 (en) * 2021-01-27 2022-08-30 Cisco Technology, Inc. Hierarchical ECMP control plane for dense topologies
WO2022246693A1 (en) * 2021-05-26 2022-12-01 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for path switchover management
CN113364691B (en) * 2021-05-31 2022-11-29 广州趣丸网络科技有限公司 Data interaction system, method, equipment and storage medium
CN115150323B (en) * 2022-07-04 2023-06-02 中国联合网络通信集团有限公司 Route implementation method, VTEP, first edge equipment and system

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101410819A (en) * 2005-12-30 2009-04-15 阿卡麦科技公司 Reliable, high-throughput, high-performance transport and routing mechanism for arbitrary data flows
CN102137173A (en) * 2010-12-27 2011-07-27 华为技术有限公司 Routing information distributing method, equipment, virtual special network system
CN102546389A (en) * 2011-11-08 2012-07-04 杭州华三通信技术有限公司 Method and device for flow trusteeship of cross-data center
CN102546383A (en) * 2010-12-29 2012-07-04 丛林网络公司 Methods and apparatus for standard protocol validation mechanisms deployed over a switch fabric system
CN105991446A (en) * 2015-02-06 2016-10-05 中国移动通信集团公司 Three-layer networking method, device and system and data processing method, device and system of TRILL network

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9548887B2 (en) * 2013-08-09 2017-01-17 Cisco Technology, Inc. Proactive creation of multicast state in an overlay transport network to achieve fast convergence on failover

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101410819A (en) * 2005-12-30 2009-04-15 阿卡麦科技公司 Reliable, high-throughput, high-performance transport and routing mechanism for arbitrary data flows
CN102137173A (en) * 2010-12-27 2011-07-27 华为技术有限公司 Routing information distributing method, equipment, virtual special network system
CN102546383A (en) * 2010-12-29 2012-07-04 丛林网络公司 Methods and apparatus for standard protocol validation mechanisms deployed over a switch fabric system
CN102546389A (en) * 2011-11-08 2012-07-04 杭州华三通信技术有限公司 Method and device for flow trusteeship of cross-data center
CN105991446A (en) * 2015-02-06 2016-10-05 中国移动通信集团公司 Three-layer networking method, device and system and data processing method, device and system of TRILL network

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Proposal Overall Evaluation Section;China Mobile, CATR;《SA WG2 Meeting #109 S2-151529》;20150519;正文第1页 *
基于VXLAN的EVPN技术研究与实现;钟耿辉;《计算机技术与发展》;20170630;第2017年27卷(第5期);正文第1-5页 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12003409B2 (en) 2022-08-29 2024-06-04 Cisco Technology, Inc. Hierarchical ECMP control plane for dense topologies

Also Published As

Publication number Publication date
CN108833272A (en) 2018-11-16

Similar Documents

Publication Publication Date Title
US10333836B2 (en) Convergence for EVPN multi-homed networks
CN107465590B (en) Network infrastructure system, method of routing network traffic and computer readable medium
US10666561B2 (en) Virtual machine migration
CN107819677B (en) Message forwarding method and device
CN108833272B (en) Route management method and device
US9929940B2 (en) Update of MAC routes in EVPN single-active topology
US9444642B2 (en) LAN multiplexing apparatus
CN106878048B (en) Fault processing method and device
US20170063600A1 (en) Egress protection for bum traffic with link failures in evpn
US9628409B1 (en) Designated forwarder election for multi-homed data center interconnect using multicast routing protocol state information
CN106899430B (en) Traffic forwarding processing method and device
CN111510378A (en) EVPN message processing method, device and system
CN108718269B (en) Message processing method and device
CN103685022A (en) Message forwarding method and service provider network edge equipment
CN112887188B (en) Message forwarding method and device
US10757066B2 (en) Active-active access to transparent interconnection of lots of links (TRILL) edges
US11750496B2 (en) Method for multi-cloud interconnection and device
CN108540386B (en) Method and device for preventing service flow interruption
CN111988222A (en) Data transmission method and device, electronic equipment and computer readable storage medium
CN107682261B (en) Flow forwarding method and device
CN109981437B (en) Multi-data center intercommunication method based on VPC and related equipment
CN108600073B (en) Dynamic tunnel establishment method and device
CN115242699A (en) Message transmission method, slice generation method, device and system
JP7273130B2 (en) Communication method and device
CN117596284A (en) Method, device, computer equipment and storage medium for data transmission

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant