CN108768845B

CN108768845B - Multi-homing host routing synchronization method and device

Info

Publication number: CN108768845B
Application number: CN201810286293.2A
Authority: CN
Inventors: 雷磊; 黄李伟
Original assignee: Hangzhou H3C Technologies Co Ltd
Current assignee: Hangzhou H3C Technologies Co Ltd
Priority date: 2018-04-03
Filing date: 2018-04-03
Publication date: 2021-04-27
Anticipated expiration: 2038-04-03
Also published as: CN108768845A

Abstract

The application provides a multi-homing host routing synchronization method and device, which can comprise the following steps: receiving an unreachable message sent by a first peer VTEP for a MAC/IP advertisement route of a first user host; if the unreachable message carries a restart field and the ESI of the local AC port is different from the ESI carried by the unreachable message, checking whether ES routes which are sent by VTEPs of other opposite ends and carry the ESI of the unreachable message are cancelled; and if the IP address of the first opposite end VTEP is not cancelled, deleting the IP address of the first opposite end VTEP from the equivalent next hop of the IP/MAC forwarding table entry of the first user host, and deleting the VXLAN tunnel port of the VXLAN tunnel connected with the first opposite end VTEP from the equivalent outgoing interface. By using the method, the service flow can be prevented from being interrupted.

Description

Multi-homing host routing synchronization method and device

Technical Field

The present application relates to the field of computer communications, and in particular, to a method and an apparatus for synchronizing routes of multihomed hosts.

Background

In an EVPN (Ethernet Virtual Private Network), in order to improve the bandwidth utilization of links and enhance the Network reliability, a host (or a virtualized Virtual machine) of a user or a Private Network of the user is usually connected to multiple VTEP (VXLAN Tunnel End Point) devices in the EVPN Network through multiple links, which is called multi-homing access. EVPN multi-homing introduces the following concept:

ES (Ethernet Segment): if a host accesses different VTEP devices simultaneously over multiple links, then these multiple links are called ES.

ESI (Ethernet Segment Identifier): the value used to identify an ES is called ESI.

Fig. 1 illustrates an EVPN multi-homing networking. In fig. 1, the user host VM1 has simultaneous multihomed access to 2 VTEP devices, VTEP1 and VTEP2, respectively, through a switch LSW. After the VM1 comes online, it sends a gratuitous ARP (Address Resolution Protocol) message to the LSW. When sending the gratuitous ARP message, the LSW hashes a link among the links connected to VTEP1 and VTEP2 for forwarding. Assume that the LSW hashed link is the link from the LSW to VTEP 1. The LSW may send the gratuitous ARP message to VTEP 1.

When VTEP1 receives the gratuitous ARP packet, it may add the IP (Internet Protocol)/MAC (Medium Access Control) address of VM1 in the packet to the local IP/MAC forwarding table entry, where the output interface corresponding to the IP/MAC address of VM1 is an AC (Access Circuit) port that receives the gratuitous ARP packet, that is, AC1 connected to LSW. Meanwhile, VTEP1 may synchronize the IP/MAC forwarding entries of VM1 to all VTEP devices on the opposite end, such as VTEP2 and VTEP3, through the second type of EVPN Route, i.e., MAC/IP Advertisement Route (MAC/IP Advertisement Route).

After receiving the MAC/IP advertisement route, VTEP2 finds that VTEP2 and VTEP1 belong to the same EVPN multihoming system, and VTEP2 may generate an IP/MAC forwarding entry of VM1, where a destination IP/MAC of the IP/MAC forwarding entry is an IP/MAC of VM1, and an output interface is an AC port, that is, AC2, where VTEP2 is connected to an LSW.

After receiving the MAC/IP advertisement route, VTEP3 finds that VTEP3 and VTEP1 do not belong to the same EVPN multihome system, and VTEP1 and VTEP2 belong to the same EVPN multihome system, VTEP3 may generate an IP/MAC forwarding entry of VM1, where a destination IP/MAC of the IP/MAC forwarding entry of VM1 is an IP/MAC of VM1, and the IP/MAC forwarding entry has two equivalent next hops, which are an IP address of VTEP1 and an IP address of VTEP2, respectively. The IP/MAC forwarding table entry also has two equivalent egress interfaces, VXLAN tunnel port of VXLAN tunnel connected to VTEP1 and VXLAN tunnel port of VXLAN tunnel connected to VTEP 2.

Disclosure of Invention

In view of the above, the present application provides a method and an apparatus for preventing service traffic interruption, so as to prevent service traffic interruption.

Specifically, the method is realized through the following technical scheme:

according to a first aspect of the present application, there is provided a multihomed host route synchronization method, which is applied to a tunnel endpoint VTEP device, and includes:

receiving an unreachable message sent by a first peer VTEP for a MAC/IP advertisement route of a first user host;

if the unreachable message carries a restart field and the ESI of the local AC port is different from the ESI carried by the unreachable message, checking whether ES routes which are sent by VTEPs of other opposite ends and carry the ESI of the unreachable message are cancelled;

and if the IP address of the first opposite end VTEP is not cancelled, deleting the IP address of the first opposite end VTEP from the equivalent next hop of the IP/MAC forwarding table entry of the first user host, and deleting the VXLAN tunnel port of the VXLAN tunnel connected with the first opposite end VTEP from the equivalent outgoing interface.

Optionally, if the unreachable message carries a restart field and the ESI of any local AC port is the same as the ESI carried by the unreachable message, the method further includes:

deleting the IP/MAC forwarding table item aiming at the first user host and synchronized by the first peer VTEP;

generating an IP/MAC forwarding table item aiming at the first user host locally, and synchronizing the generated IP/MAC forwarding table item to other opposite end VTEPs through an MAC/IP notification route; and the generated IP/MAC forwarding table entry output interface aiming at the first user host is a local AC interface which is the same as ESI carried by the unreachable message.

Optionally, the method further includes:

before the VTEP is restarted, an unreachable message of the MAC/IP advertisement route aiming at the second user host is sent to all the neighbor VTEPs of the VTEP; the unreachable message carries a restart field and the ESI of the ES link of the second ue with multihome access to the VTEP.

Optionally, if it is checked that the ES route carrying the ESI of the unreachable message sent by the VTEP of the other peer is revoked, the method further includes:

and deleting the IP/MAC forwarding table entry of the first user host.

According to a second aspect of the present application, there is provided a multihomed host route synchronization apparatus, the apparatus being applied to a VTEP device, the apparatus including:

a receiving unit, configured to receive an unreachable message of a MAC/IP advertisement route for a first user host sent by a first peer VTEP;

a checking unit, configured to check whether an ES route, which is sent by a VTEP of another opposite end and carries the ESI of the unreachable message, is revoked, if the unreachable message carries the restart field and the ESI of the local AC port is different from the ESI carried by the unreachable message;

a first deleting unit, configured to delete the IP address of the first peer VTEP from an equivalent next hop of the IP/MAC forwarding entry of the first user host and delete the VXLAN tunnel port of the VXLAN tunnel connected to the first peer VTEP from an equivalent egress interface if the first user host is not revoked.

Optionally, the apparatus further includes a second deleting unit, configured to delete the IP/MAC forwarding entry, which is synchronized by the first peer VTEP and is addressed to the first user host, if the unreachable message carries a restart field and an ESI of any local AC port is the same as an ESI carried by the unreachable message;

the notification unit is used for locally generating an IP/MAC forwarding table item aiming at the first user host, and synchronizing the generated IP/MAC forwarding table item to other opposite end VTEPs through an MAC/IP notification route; and the generated IP/MAC forwarding table entry output interface aiming at the first user host is a local AC interface which is the same as ESI carried by the unreachable message.

Optionally, the apparatus further comprises:

a sending unit, configured to send an unreachable message of the MAC/IP advertisement route for the second user host to all neighbor VTEPs of the VTEP before the VTEP is restarted; the unreachable message carries a restart field and the ESI of the ES link of the second ue with multihome access to the VTEP.

Optionally, if it is detected that the ES route carrying the ESI of the unreachable message sent by the VTEP of the other peer is cancelled, the deleting unit is further configured to delete the IP/MAC forwarding table entry of the first user host.

Since the VTEP only deletes the path information of the VTEP arriving at the first peer after receiving the unreachable message of the MAC/IP advertising route of the first peer VTEP sent by the VTEP before restarting, namely, the IP/MAC forwarding table entry is equivalent to the IP address of the first peer VTEP in the next hop, and the VXLAN tunnel portal deletion in the equivalent egress interface connecting the first peer VTEP, while path information to other peer VTEPs belonging to the same multi-homing system as the first peer VTEP is retained, namely, the IP addresses of other opposite end VTEPs of the equivalent next hop are reserved, and VXLAN tunnel ports connected with other opposite end VTEPs in the equivalent outgoing interface, when the VTEP receives the flow for sending the first user host, the IP/MAC forwarding table item aiming at the first user host can still be searched and sent to the first user host through the VTEP of other opposite ends, thereby preventing the flow interruption.

Drawings

Fig. 1 is a schematic diagram of an EVPN multihoming networking shown in an exemplary embodiment of the present application;

FIG. 2 is a flow chart illustrating a method for multi-homed host route synchronization in accordance with an exemplary embodiment of the present application;

FIG. 3 is a diagram illustrating a restart multi-homed extended community attribute format according to an exemplary embodiment of the present application;

FIG. 4 is a diagram illustrating a multihomed host route synchronization method according to an exemplary embodiment of the present application;

FIG. 5 is a diagram of the hardware architecture of a VTEP where the present application provides a multihomed host route synchronization apparatus;

fig. 6 is a block diagram illustrating a multihomed host route synchronization apparatus according to an exemplary embodiment of the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

The terminology used herein 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 appended 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 refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such 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. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

As described in the background, when one VTPE device in the multi-homing system needs to upgrade the system version, the VTEP device is restarted. For example, VTEP1 may require a system version upgrade, and VTEP1 may send an unreachable message to all peer devices advertising routes for MAC/IP of VM1 before restarting VTEP 1. VTEP3 deletes the IP/MAC forwarding table entry for VM1 described above upon receiving the unreachable message from VTEP 1.

When VTEP3 receives traffic arriving at VM1, VTEP3 cannot forward the traffic arriving at VM1 because the IP/MAC forwarding table entry for VM1 is deleted, which causes interruption of traffic flow.

In view of the above, the present application provides a method for multi-homed host route synchronization, which can prevent interruption of traffic flow reaching the VM1 due to restart of the VTEP 1.

Before introducing the method for preventing service traffic interruption provided by the present application, some concepts of multi-homing access will be introduced first.

The multi-homing access refers to a host (or a virtual machine) of one user or a private network of one user, and is connected to a plurality of VTEPs in the EVPN network through a plurality of links, and is called multi-homing access.

When one user host or user private network needs multi-homing access to multiple VTEPs, multi-homing access function is required to be configured on the VTEP. For example, the same ESI needs to be assigned to each of the AC ports on the plurality of VTEPs that connect to the user host or the user private network.

As shown in fig. 1, VM1 requires multi-homed access to VTEP1 and VTEP 2. It is necessary to configure the multihoming access function on VTEP1 as well as VTEP 2. Assume that the AC port connected to VM1 in VTEP1 is AC1, and the AC port connected to VM1 in VTEP2 is AC 2. It is assumed that VTEP1 and VTEP2 belong to a multihomed system with ESI of 1. Then the ESI configured for AC1 on VTEP1 would need to be 1 and the ESI configured for AC2 on VTEP2 would need to be 1.

Typically, after configuring the ESI for the AC port of a VTEP, the VTEP may send ES routes to neighbor VTEP devices to advertise to the neighbor VTEPs the multihoming system to which it belongs. The ES route carries the ESI of the multihomed system to which the sender of the ES route belongs.

For example, as shown in fig. 1, after configuring ESI for AC1 of VTEP1 to be 1 and AC2 of VTEP2 to be 1, VTEP1 may send an ES route to a neighbor VTEP (VTEP2, VTEP3), the ESI carried in the ES route being 1. VTEP2 may send an ES route to a neighbor VTEP (e.g., VTEP1, VTEP3), which carries an ESI of 1.

VTEP3 receives ES routes from VTEP1 and VTEP 2. When VTEP3 determines that the ESI carried by the ES routes from VTEP1 and VTEP2 are the same, VTEP3 may determine that VTEP1 and VTEP2 belong to the same multi-homed system.

VTEP2 receives the ES route from VTEP1, and VTEP2 determines that VTEP1 belongs to the same multihomed system as VTEP2 when VTEP2 receives the same ESI carried by the ES route from VTEP1 as the ESI corresponding to local AC 2.

Similarly, VTEP1 may also determine that VTEP2 and VTEP1 belong to the same multihoming system.

Referring to fig. 2, fig. 2 is a flowchart of a method for multi-homed host route synchronization, which may be applied to a VTEP and may include the following steps.

Step 201: the VTEP receives an unreachable message sent by the first peer VTEP and aiming at the MAC/IP advertising route of the first user host;

step 202: if the unreachable message carries the restart field and the ESI of the local AC port is different from the ESI carried by the unreachable message, the VTEP checks whether ES routes which are sent by other opposite end VTEPs and carry the ESI of the unreachable message are cancelled.

In the embodiment of the application, a restart multi-homing extended community attribute is newly added in an unreachable message of a MAC/IP advertisement route of a first user host, and the restart multi-homing extended community attribute comprises a restart field.

For one embodiment, the format of the restart multi-homed extended community attribute is shown in fig. 3, and may include the following:

type (Type) field: when the value of the Type field is 0x06, the field belongs to the extended community attribute field of the EVPN protocol;

subtype (Sub-Type) field: the restart field is used to indicate that this field is specifically a restart field in the extended community attribute field, and its value may be set to any undefined value in the extended community attribute field (currently, the Sub-Type values defined in the extended community attribute field have 0x01 and 0x02), and the value of the Sub-Type field is set to 0x08 in fig. 3;

ESI domain: indicating the ESI of the multihoming system to which the VTEP sending the unreachable message of the MAC/IP advertisement route belongs.

Step 203: if not, the VTEP deletes the IP address of the first opposite end VTEP from the equivalent next hop of the IP/MAC forwarding table item of the first user host, and deletes the VXLAN tunnel port of the VXLAN tunnel connected with the first opposite end VTEP from the equivalent outgoing interface.

The VTEP can reserve the IP addresses of other peer VTEPs belonging to the same multihoming system as the first peer VTEP in the equivalent next hop, and reserve the VXLAN tunnel portal trained with the other peer VTEPs in the equivalent egress interface. Wherein, the other peer VTEP refers to another peer VTEP belonging to the same multi-homing system as the first peer VTEP.

If the IP/MAC forwarding table entry is revoked, the VTEP can locally delete the IP/MAC forwarding table entry of the first user host.

In this embodiment of the present application, if the unreachable message carries a restart field and the ESI of any local AC port is the same as the ESI carried by the unreachable message, the VTEP may delete the IP/MAC forwarding table entry for the first user host that is synchronized by the first peer VTEP;

then, the VTEP can locally generate an IP/MAC forwarding table item aiming at the first user host, and synchronize the generated IP/MAC forwarding table item to other opposite-end VTEPs through the MAC/IP notification route; and the generated IP/MAC forwarding table entry output interface aiming at the first user host is a local AC interface which is the same as ESI carried by the unreachable message.

In addition, in the embodiment of the application, before the VTEP is restarted, the VTEP may further send an unreachable message of the MAC/IP advertisement route for the second user host to all the neighbor VTEPs of the VTEP; and the unreachable message carries a restarting field and ESI of the ES link between the second user host and the VTEP.

As can be seen from the above description, after receiving the unreachable message of the MAC/IP advertisement route for the first user host sent by the first peer VTEP before restarting, the present VTEP only deletes the path information reaching the first peer VTEP, that is, deletes the IP address of the first peer VTEP in the equivalent next hop, which is the IP/MAC forwarding table, and the VXLAN tunnel port connected to the first peer VTEP in the equivalent outbound interface, while retaining the path information reaching other peer VTEPs belonging to the same multihome system as the first peer VTEP, that is, retains the IP addresses of other peer VTEPs in the equivalent next hop, and the VXLAN tunnel ports connected to other peer VTEPs in the equivalent outbound interface, so that when the present VTEP receives the traffic of sending the first user host, it can still search the IP/MAC forwarding table for the first user host, and send the IP/MAC forwarding table to the first user host through the other peer VTEPs, thereby preventing the flow of water.

Referring to fig. 4, the method for preventing service traffic interruption provided by the present application is described in detail below by way of specific examples.

In fig. 4, it is assumed that there are 3 VTEP devices, VTEP41, VTEP42, and VTEP43, respectively. The VTEP devices are connected through VXLAN tunnels. For example, the VXLAN Tunnel connecting VTEP41 and VTEP42 is Tunnel 41, the VXLAN Tunnel connecting VTEP41 and VTEP43 is Tunnel 42, and the VXLAN Tunnel connecting VTEP42 and VTEP43 is Tunnel 43.

Assume that VM41 has an IP address of 10.1.1.2/24 and a MAC address of 1-1-1.

VM41 is multi-homed to VTEP41 and VTEP42 through switch LSW. VM41 accesses VTEP41 through AC port AC1 on VTEP41, and VM41 accesses VTEP42 through AC port AC2 on VTEP 42. Assume that the ESIs configured for AC1 and AC2 are both assumed to be 1.

The link of VM41 multi-homed access VTEP41, and the link of VM41 multi-homed access VTEP42 are referred to as ES links, assuming ESI of the two ES links is 1.

When VTEP41 and VTEP42 are configured in the same multihomed system, VTEP41 may send an ES route to a neighbor VTEP (e.g., VTEP41, VTEP43), where the ES route carries an ESI of 1. VTEP42 may also send an ES route to a neighbor VTEP (e.g., VTEP41, VTEP43), which carries an ESI of 1.

When VM41 comes online, VM41 may send gratuitous ARP messages. During sending, VM41 may hash one of the links accessing VTEP41 and VTEP42 to forward gratuitous ARP packets. Assuming that the link hashed by VM41 is a link that VM41 accesses VTEP41, VM41 may send the gratuitous ARP packet to VTEP 41.

After receiving the gratuitous ARP packet, VTEP41 may learn the IP address and MAC address of VM41 carried in the gratuitous ARP packet, and generate an IP/MAC forwarding entry for VM41, as shown in table 1.

IP address	MAC address	VSI	Outlet interface
				10.1.1.2/24	1-1-1	vpnb	AC1

TABLE 1

The IP address of the IP/MAC forwarding entry is the IP address of VM41, the MAC address is the MAC address of VM41, and the output interface is AC 1. The VSI is associated with the AC port for receiving the gratuitous ARP message. The IP/MAC forwarding table entry may further include a next hop, or the outgoing interface of the forwarding table entry may be associated with a next hop adjacency table. Table 1 is merely an exemplary illustration, and is not particularly limited.

After generating the IP/MAC forwarding entry, VTEP41 may synchronize the IP/MAC forwarding entry to all EVPN neighbor devices of VTEP41, such as VTEP42 and VTEP43, through the MAC/IP advertisement route.

As described above, VTEP42 receives the ES route carrying ESI of 1 sent by VTEP41, VTEP42 finds that the ESI configured on local AC2 is also 1 after receiving the ES route, and VTEP42 can determine that VTEP42 and VTEP41 belong to the same multihomed system. Upon receiving the MAC/IP advertisement route from VTEP41, VTEP42 may learn the MAC/IP advertisement route, locally generate an IP/MAC forwarding entry for VM41, and modify the outgoing interface of the IP/MAC entry to AC2, as shown in table 2.

IP address	MAC address	VSI	Outlet interface
				10.1.1.2/24	1-1-1	vpnb	AC2

TABLE 2

The IP address of the IP/MAC forwarding entry is the IP address of VM41, the MAC address is the MAC address of VM41, and the output interface is AC 1. The VSI is the VSI associated with the AC port of VTEP42 connected to VM 41. The IP/MAC forwarding table entry may further include a next hop, or the outgoing interface of the forwarding table entry may be associated with a next hop adjacency table. Table 2 is merely exemplary and is not particularly limited.

As described above, VTEP43 will receive the ES route carrying ESI of 1 sent by VTEP41, and VTEP43 will also receive the ES route carrying ESI of 1 sent by VTEP42, and since the ESI of the ES route sent by VTEP41 is the same as the ESI of the ES route sent by VTEP42, VTEP43 can determine that VTEP41 and VTEP42 belong to the same ESI-1 multihomed system.

VTEP42 may learn the MAC/IP advertisement route from VTEP41 after receiving the MAC/IP advertisement route, and locally generate the IP/MAC forwarding entry of VM41, and since VTEP41 and VTEP42 belong to the same multihoming system, the locally generated IP/MAC forwarding entry of VM41 has an equivalent egress interface and an equivalent next hop. The equivalent egress interface includes a VXLAN tunnel port through which VTEP43 connects to the VXLAN tunnel of VTEP41, and a VXLAN tunnel port through which VTEP43 connects to the VXLAN tunnel of VTEP 42. The equivalent next hop includes the IP address of VTEP41, and the IP address of VTEP 42. The IP/MAC forwarding entries of VM41 generated on VTEP43 are shown in table 3.

TABLE 3

The IP address of the IP/MAC forwarding entry is the IP address of VM41, the MAC address is the MAC address of VM41, and the equivalent egress interface includes a Tunnel (i.e., Tunnel32 Tunnel) through which VTEP43 is connected to VTEP41, and a Tunnel (i.e., Tunnel33 Tunnel) through which VTEP43 is connected to VTEP 42. The equivalent next hop includes IP address 1.1.1.1 of VTEP41, and IP address 2.2.2.2 of VTEP 42. And the VSI is the VSI corresponding to the VXLAN ID carried by the MAC/IP notification route.

Assuming that VTEP41 needs to be restarted, VTEP41 may send an unreachable message advertising routes for MAC/IP of VM41 to all first peer VTEPs before VTEP41 is restarted. The unreachable message is added with a restart multi-homed extended community attribute, which carries the restart field and the ESI of the multi-homed system to which VTEP41 belongs (in this case, ESI is 1), in other words, the ESI carried by the extended community attribute may also refer to the ESI of the ES link of VM41 multi-homed access VTEP 41.

When VTEP43 receives an unreachable message from VTEP41 for MAC/IP advertisement routing of VM41, VTEP43 may check whether the restart field is carried in the unreachable message and whether there is an AC port with ESI of 1 locally.

In this example, VTEP43 determines that the unreachable message of the MAC/IP advertised route carries a restart field and that there is no AC port with ESI of 1 on VTEP43, VTEP43 may check whether a withdrawn route of the ES route with ESI of 1 sent by other peer VTEPs (e.g., VTEP42) is received, so as to check whether the ES route with ESI of 1 sent by other peer VTEPs is withdrawn.

Assuming that the VTEP of the other peer is VTEP42, if VTEP43 receives the withdrawn route of the ES route sent by VTEP42 and carrying ESI of 1, VTEP43 may determine that the ES route sent by VTEP42 and carrying ESI of 1 is withdrawn.

If VTEP43 does not receive a withdrawn route for ES routes carried with ESI of 1 sent by VTEP42, VTEP43 may determine that ES routes carried with ESI of 1 sent by VTEP42 were not withdrawn.

When VTEP43 determines that the ES route carrying ESI of 1 sent by VTEP42 is not revoked, VTEP43 may delete the IP address of VTEP41 from the equivalent next hop of the IP/MAC forwarding entry of VM41, delete the VXLAN tunnel port locally connected to VTEP41 from the equivalent outgoing interface of the IP/MAC forwarding entry of VM41, retain the IP address of VTEP42 in the equivalent next hop of the IP/MAC forwarding entry of VM41, and retain the VXLAN tunnel port locally connected to VTEP42 in the equivalent outgoing interface.

For example, when VTEP43 determines that the ES route carrying ESI of 1 sent by VTEP42 is not revoked, VTEP43 may delete IP address 1.1.1.1 of VTEP41 in the next hop shown in table 3, delete VXLAN Tunnel port Tunnel 42 of local connection VTEP41 in the egress interface, retain IP address 2.2.2.2 of VTEP42 in the next hop, and retain VXLAN Tunnel port Tunnel 43 of local connection VTEP42 in the egress interface, forming table 4.

IP address	MAC address	VSI	Outlet interface	Next hop
					10.1.1.2/24	1-1-1	vpnb	Tunnel	43 Tunnel portal	2.2.2.2

TABLE 4

When VTEP43 determines that the ES route carried with ESI of 1 sent by VTEP42 is revoked, VTEP43 may delete the IP/MAC forwarding entry of VM 41.

When VTEP42 receives an unreachable message from VTEP41 for MAC/IP advertisement routing of VM41, VTEP42 may check whether the restart field is carried in the unreachable message and whether there is an AC port with ESI of 1 locally.

In this example, VTEP42 may determine that the unreachable message carries a restart field and that an AC port with ESI of 1 (e.g., AC2) is present locally, then VTEP42 may delete the local IP/MAC forwarding table entry for VM41 that was synchronized by VTEP 41. The IP/MAC forwarding entries for VM41 may then be generated locally by VTEP 42.

In an alternative implementation, the control plane of VTEP43 may generate an IP/MAC routing table entry, and then issue the IP/MAC routing table entry to the forwarding plane of VTEP43, and then the forwarding plane locally generates an IP/MAC forwarding table entry according to the IP/MAC routing table entry, where the generated IP/MAC forwarding table entry is shown in table 2.

VTEP42 may then construct a MAC/IP advertisement route based on the generated IP/MAC forwarding entry and send the MAC/IP advertisement route to the first peer VTEP (e.g., VTEP 43).

When VTEP43 receives the MAC/IP advertised route from VM41 of VTEP42, the MAC/IP advertised route may be learned and recorded. When the IP/MAC forwarding entry for VM41 stored on VTEP43 as shown in table 4 is deleted, VTEP43 may generate the IP/MAC forwarding entry for VM41 as shown in table 4 based on the MAC/IP advertised route for VM 41.

As can be seen from the above description, since VTEP43 deletes only the path information arriving at VTEP41, that is, the IP/MAC forwarding table entry of VM41 is deleted from the IP address of VTEP41 in the equivalent next hop and the VXLAN tunnel port connected to VTEP41 in the equivalent outgoing interface, after receiving the unreachable message for the MAC/IP advertisement route of VM41 sent by VTEP41 before restarting, the path information arriving at VTEP42 belonging to the same multihome system as VTEP41, that is, the IP address of VTEP42 in the equivalent next hop is retained and the VXLAN tunnel port connected to VTEP42 in the equivalent outgoing interface is retained, so that when VTEP43 receives the traffic sent by VM41, the IP/AMC forwarding table entry of VM41 can be searched and sent to VM41 through VTEP42, thereby preventing traffic interruption.

Referring to fig. 5, the present application further provides a hardware architecture diagram of a VTEP where the multihomed host routing synchronization apparatus is located, where the VTEP apparatus includes: a communication interface 501, a processor 502, a memory 503, and a bus 504; the communication interface 501, the processor 502 and the memory 503 are connected to communicate with each other via a bus 504.

The processor 502 may be a CPU, the memory 503 may be a non-volatile memory (non-volatile memory), the memory 503 stores logic instructions for multi-homed host route synchronization, and the processor 502 may execute the logic instructions for multi-homed host route synchronization stored in the memory 503 to implement a function of preventing service flow interruption.

To this end, the description of the hardware configuration shown in fig. 5 is completed.

Referring to fig. 6, fig. 6 is a block diagram illustrating a multihomed host route synchronization apparatus according to an exemplary embodiment of the present application. The device can be applied to VTEP equipment and can comprise the following units.

A receiving unit 601, configured to receive an unreachable message of a MAC/IP advertisement route for a first user host sent by a first peer VTEP;

a checking unit 602, configured to check whether an ES route sent by a VTEP of another peer end and carrying the ESI of the unreachable message is revoked, if the unreachable message carries the restart field and the ESI of the local AC port is different from the ESI carried by the unreachable message;

a first deleting unit 603, configured to delete the IP address of the first peer VTEP from the equivalent next hop of the IP/MAC forwarding entry of the first user host and delete the VXLAN tunnel port of the VXLAN tunnel connected to the first peer VTEP from the equivalent egress interface if the first user host is not revoked.

Optionally, the apparatus further comprises:

a second deleting unit 604, configured to delete the IP/MAC forwarding entry for the first user host synchronized by the first peer VTEP if the unreachable message carries a restart field and an ESI of any local AC port is the same as the ESI carried by the unreachable message;

a notification unit 605, configured to locally generate an IP/MAC forwarding entry for the first user host, and synchronize the generated IP/MAC forwarding entry to VTEPs of other opposite terminals through an MAC/IP notification route; and the generated IP/MAC forwarding table entry output interface aiming at the first user host is a local AC interface which is the same as ESI carried by the unreachable message.

Optionally, the apparatus further comprises:

a sending unit 606, configured to send an unreachable message of the MAC/IP advertisement route for the second user host to all neighbor VTEPs of the VTEP before the VTEP is restarted; the unreachable message carries a restart field and the ESI of the ES link of the second ue with multihome access to the VTEP.

Optionally, if it is detected that the ES route carrying the ESI of the unreachable message sent by the VTEP of the other peer is cancelled, the deleting unit 603 is further configured to delete the IP/MAC forwarding table entry of the first user host.

The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement it without inventive effort.

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

1. A multi-homing host route synchronization method is applied to a tunnel endpoint VTEP device, and comprises the following steps:

2. The method as claimed in claim 1, wherein if the unreachable message carries a restart field and the ESI of any AC port in the local is the same as the ESI carried by the unreachable message, the method further comprises:

3. The method of claim 1, further comprising:

4. The method according to claim 1, wherein if it is checked that the ES route carrying the ESI of the unreachable message sent by the other peer VTEP is withdrawn, the method further comprises:

and deleting the IP/MAC forwarding table entry of the first user host.

5. A multi-homing host routing synchronization apparatus, applied to a VTEP device, the apparatus comprising:

and if the IP address of the first peer VTEP is not revoked, deleting the IP address of the first peer VTEP from an equivalent next hop of the IP/MAC forwarding table entry of the first user host, and deleting a VXLAN tunnel port of a VXLAN tunnel connected with the first peer VTEP from an equivalent egress interface.

6. The apparatus according to claim 5, wherein if the unreachable message carries a restart field, and an ESI of any one of the local AC ports is the same as an ESI carried by the unreachable message, the deleting unit is further configured to delete the IP/MAC forwarding table entry for the first subscriber host that is synchronized by the first peer VTEP;

the device further comprises:

7. The apparatus of claim 5, further comprising:

8. The apparatus according to claim 5, wherein the deleting unit is further configured to delete the IP/MAC forwarding entry of the first subscriber host if it is checked that the ES route carrying the ESI of the unreachable message sent by the other peer VTEP is revoked.