CN107911495B

CN107911495B - MAC address synchronization method and VTEP

Info

Publication number: CN107911495B
Application number: CN201711135695.4A
Authority: CN
Inventors: 尹子瑞; 黄李伟; 王伟
Original assignee: Hangzhou H3C Technologies Co Ltd
Current assignee: Hangzhou H3C Technologies Co Ltd
Priority date: 2017-11-16
Filing date: 2017-11-16
Publication date: 2020-12-04
Anticipated expiration: 2037-11-16
Also published as: CN107911495A

Abstract

The application provides a MAC address synchronization method and a VTEP, wherein the method can be applied to a local VTEP in an EVPN, and comprises the following steps: when the local VTEP is a management VTEP, receiving a two-class routing notification message sent by the managed VTEP which establishes an EVPN neighbor relation with the local VTEP in the same EVPN instance; and performing two-layer forwarding table item learning based on the MAC address carried in the two-type routing notification message, and forbidding the learned MAC address to be synchronized to other managed VTEPs in the same EVPN instance. In the method, the management VTEP does not synchronize the MAC address learned by the management VTEP with the managed VTEP, so that the bandwidth resource of a public network can be saved, and the hardware table entry resource of the managed VTEP can be saved.

Description

MAC address synchronization method and VTEP

Technical Field

The present application relates to the field of communications technologies, and in particular, to a Media Access Control (MAC) address synchronization method and a virtual local area network (VxLAN Tunnel End Point, extensible virtual local area network) node.

Background

An EVPN (Ethernet Virtual Private Network) is a two-layer VPN technology, where a control plane uses MP-BGP (Multiprotocol Extensions for Border Gateway Protocol, Multiprotocol extension of the Border Gateway Protocol) to announce EVPN routing information, specifically, finds EVPN neighbors through three types of MP-BGP route announcement messages, establishes a VxLAN (Virtual Local Area Network) tunnel, and synchronizes MAC addresses of Private Network users to all EVPN neighbors through two types of MP-BGP announce routing messages.

Disclosure of Invention

The application provides a MAC address synchronization scheme in EVPN.

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

in a first aspect of the present application, a MAC address synchronization method is provided, which is applied to a local VTEP in EVPN, and the method includes:

when the local VTEP is a management VTEP, receiving a two-class routing notification message sent by the managed VTEP which establishes an EVPN neighbor relation with the local VTEP in the same EVPN instance;

and performing two-layer forwarding table item learning based on the MAC address carried in the two-type routing notification message, and forbidding the learned MAC address to be synchronized to other managed VTEPs in the same EVPN instance.

In a second aspect of the present application, a VTEP is provided, located in an EVPN, and having the functionality to implement the method of the first aspect. 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 VTEP includes:

a receiving and sending unit, configured to receive, when a local VTEP is a management VTEP, a class two route advertisement message sent by a managed VTEP that establishes an EVPN neighbor relationship with the local VTEP in the same EVPN instance;

a learning unit, configured to perform two-layer forwarding table entry learning based on the MAC address carried in the second-type route advertisement message;

a synchronization prohibition unit configured to prohibit synchronization of the MAC address learned by the learning unit to other managed VTEPs within the same EVPN instance.

In another possible implementation, the VTEP includes a communication interface, a processor, a memory, and a bus, and the communication interface, the processor, and the memory are connected to each other through the bus; the processor executes the MAC address synchronization method according to the first aspect of the present application by reading the logic instructions stored in the memory.

In the application, the management VTEP does not synchronize the MAC address learned by the management VTEP, so that the bandwidth resource of a public network can be saved, and the hardware table entry resource of the managed VTEP can be saved.

Drawings

FIG. 1 is a prior art EVPN networking diagram;

FIG. 2 is a networking diagram of EVPN provided herein;

FIG. 3 is a flow chart of a method provided herein;

FIG. 4 is a flow diagram of the interaction between a managing VTEP and a managed VTEP provided herein;

FIG. 5 is a diagram illustrating a MAC address synchronization process between a managing VTEP and a managed VTEP provided by the present application;

FIG. 6 is a block diagram of functional blocks of a VTEP provided herein;

fig. 7 is a hardware block diagram of the VTEP shown in fig. 6 provided in 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.

In the prior art, an EVPN generally adopts a structure of separating a control layer from a data layer, neighbors are found between VTEPs on the control layer through MP-BGP three-class route notification messages, a VxLAN tunnel is automatically established, MAC address learning does not depend on triggering of data flow, the MAC address learning is obtained through MP-BGP two-class route notification messages on the control layer, and forwarding is guided through a hardware forwarding table (namely a two-layer forwarding table) on the data layer, so that labor division is clear.

For example, in the conventional EVPN networking shown in fig. 1, VTEP1 discovers VTEP2 that is in the same VxLAN through three types of route advertisement messages, and automatically creates a VxLAN tunnel according to the VxLAN information carried by the three types of route advertisement messages. When the VM1 accesses the VM2, the VM1 sends a gratuitous ARP (Address Resolution Protocol) message online to the VTEP1 through the AC port, triggers the VTEP1 to learn the MAC Address of the VM1, and then the VTEP1 synchronizes to the VTEP2 through an MP-BGP two-type routing advertisement message, so that the VTEP2 can learn the MAC Address of the VM1 and a forwarding interface Tunnel corresponding to the MAC Address, and issue the MAC Address and the Tunnel corresponding to the MAC Address to a driver to form a two-layer forwarding table entry. Similarly, VTEP2 may also discover VTEP1 through three types of route advertisement messages and automatically create a VxLAN Tunnel to VTEP1, after VM2 gets online, VTEP2 learns the MAC address of VM2 through a gratuitous ARP message, and synchronizes the MAC address of VM2 and the corresponding Tunnel to VTEP1 according to the EVPN neighbor relationship between itself and VTEP1, and VTEP1 issues a forwarding table to a hardware driver, so that VTEP1 and VTEP2 may form a two-layer forwarding table to each other host, and VM1 and VM2 may communicate with each other at two layers. When VM1 and VM2 communicate, if traffic of VM1 is to be counted, a statistical function may be configured on an AC (access Circuit) port of VTEP1, and traffic sent on VM1 and traffic going to VM1 are counted at the bottom layer.

Only the traditional EVPN networking can not carry out unified management (comprising functions of authentication, monitoring, filtering, charging and the like) on the private network user side flow, and the flow counting function (such as counting the number of bytes of the flow) can be realized on each AC port only by manual operation; and is cumbersome to configure in the presence of a large number of hosts.

In view of the above problems, it may be considered to add devices capable of managing VTEPs in a conventional EVPN networking: for example, a management device VTEP3 may be added between VTEP1 and VTEP2 shown in fig. 1, and establishes EVPN neighbor relations with VTEP1 and VTEP2, respectively, VTEP2 and VTEP3 are responsible for accessing hosts to form branch sites, and the management device VTEP3 hangs down a traffic unified management system to form a central site, and is responsible for unified management and control of traffic between VTEP2 and VTEP 3. The VTEP3 can be a newly added VTEP or an existing VTEP in a traditional EVPN networking network. The EVPN networking structure after adjustment may refer to fig. 2, and for convenience of description, a VTEP serving as a management device in EVPN networking provided by the present application is referred to as a management VTEP, and a VTEP serving as a managed device in EVPN networking is referred to as a managed VTEP.

Based on the EVPN networking proposed above, the problem to be solved next is the EVPN routing information advertisement process in this networking manner.

As an embodiment, the existing EVPN route information advertisement flow can still be multiplexed. For example, in the EVPN networking shown in fig. 2, the presence of each other between the managed VTEP1 and the managing VTEP, and between the managed VTEP2 and the managing VTEP, can be discovered and VxLAN tunnels automatically created through three types of route advertisement messages. After the VM1 comes online, the managed VTEP1 learns the MAC address of the VM1 through gratuitous ARP messages, synchronizes the MAC address of the VM1 to the managed VTEP through two types of routing advertisement messages, and synchronizes the MAC address of the VM1 to the managed VTEP2 through two types of routing advertisement messages, so that the MAC address of the VM1 can be learned on both the managed VTEP and the managed VTEP 2. Similarly, when VM2 comes online, MAC addresses of VM2 will be learned on managed VTEP1, managed VTEP, and managed VTEP 2. This enables two-layer interworking of VM1 and VM 2.

As can be seen from the above description, if the existing EVPN routing information advertisement flow is multiplexed, the management VTEP and each managed VTEP will form a two-layer forwarding table for all private network users.

In addition to multiplexing the existing EVPN routing information advertisement flow, in order to save bandwidth resources and hardware table entry resources of the managed VTEP, the application also provides a new EVPN routing information advertisement scheme. This aspect provided by the present application is described below.

For clarity and simplicity of description, an EVPN instance is taken as an example in the present application, the EVPN instance includes a management VTEP and a plurality of managed VTEPs connected to the management VTEP, and the management VTEP is connected to each connected managed VTEP through a VXLAN tunnel, and a specific network topology may refer to fig. 2. Fig. 3 is a flowchart of a method provided by the present application, and as shown in fig. 3, any local VTEP in EVPN performs the following steps during operation:

step 301: when the local VTEP is a management VTEP, the local VTEP receives two types of route advertisement messages sent by the managed VTEP which establishes an EVPN neighbor relation with the local VTEP in the same EVPN instance.

Here, the same EVPN instance can be understood as the same VxLAN network.

In the present application, the same VTEP may play different roles in different EVPN instances, for example, a VTEP may serve as a management device in EVPN instance 1, but may serve as a managed device in EVPN instance 2. It should be noted, however, that there is typically only one management device within an EVPN instance.

Step 302: and the local VTEP performs two-layer forwarding table item learning based on the MAC address carried in the two-type routing notification message, and forbids the learned MAC address to be synchronized to other managed VTEPs in the same EVPN instance.

As can be seen from step 301 and step 302, in the present application, the management VTEP does not synchronize the MAC address learned by itself with the managed VTEP, which can save the public network bandwidth resources and save the hardware table entry resources of the managed VTEP.

In order to make it clear and obvious for those skilled in the art, the following describes a specific implementation process of the method shown in fig. 3 by the interaction between the management VTEP and the managed VTEP node in conjunction with fig. 4.

Before beginning formal interaction between a management VTEP and a managed VTEP, the embodiment of the application can configure the role information of each VTEP in different EVPN instances in advance. Specifically, when a VTEP serves as a management device in an EVPN instance, the role of the VTEP in the EVPN instance may be configured as a management role; when a VTEP acts as a managed device in an EVPN instance, the VTEP's role within the EVPN instance may be configured as a managed role.

The role information of the VTEP in different EVPN instances may be an attribute added to the VTEP in the embodiment of the present application, and this attribute may be used to determine whether to establish an EVPN neighbor relationship between VTEPs on one hand, and may be used to determine whether to synchronize a learned MAC address to other VTEPs when the VTEP performs MAC address learning on the other hand. These two roles of role information will be embodied in the method steps of fig. 4, and will not be detailed here for the moment.

Assuming that the role of the local VTEP in fig. 4 is a management role and the role of the peer VTEP is a managed role, the EVPN routing information advertisement flow provided in the present application is as follows:

step 401: the local VTEP receives the role announcement message sent by the opposite VTEP.

The role announcement message here may be a private protocol message; or existing protocol messages, for example, new fields may be added to existing three types of route advertisement messages, or existing fields in existing three types of route advertisement messages may be utilized to carry the role information of the VTEP.

Step 402: if the opposite terminal role information carried in the role announcement message is inconsistent with the role information of the local VTEP, the local VTEP determines that the role of the opposite terminal VTEP sending the role announcement message in the EVPN instance is a managed role.

Since the role information pre-configured by the local VTEP is the management role, when the role information of the opposite end is determined to be inconsistent with itself, it can be determined that the role information of the opposite end is the managed role.

Step 403: the local VTEP establishes an EVPN neighbor relation with the opposite VTEP based on three types of route advertisement messages sent by the opposite VTEP.

In the embodiment of the application, the local VTEP can establish an EVPN neighbor relation with the opposite-end VTEP only when the situation that the role of the opposite-end VTEP is inconsistent with the local VTEP is determined; if the roles of the local VTEP are consistent with those of the opposite VTEP, the EVPN neighbor relation is not established between the local VTEP and the opposite VTEP. This has the advantage of ensuring that no EVPN neighbor relationship is established between VTEPs that are both in managed roles, so that traffic for one managed VTEP must pass through the management VTEP before entering another managed VTEP.

After the local VTEP establishes the EVPN neighbor relation with the opposite VTEP, VXLAN ID and RT carried in the three types of route announcement messages are also matched, if VXLAND and RT carried in the three types of route announcement messages are consistent with VXLAN ID and RT configured locally, an EVPN tunnel is established.

It should be noted that steps 401 to 403 establish the EVPN neighbor relation and EVPN tunnel from the unidirectional local VTEP to the peer VTEP. The EVPN neighbor relation and EVPN tunnel for the peer VTEP to local VTEP direction may be established through steps 404 to 405 described below. Steps 404 to 405 are not in strict sequence with steps 401 to 403, and may even be executed simultaneously.

Step 404: the local VTEP sends the own role in the EVPN instance to the opposite VTEP through a role notification message.

Step 405: and the local VTEP sends three types of route advertisement messages to the opposite VTEP, so that the opposite VTEP establishes an EVPN neighbor relation with the local VTEP based on the received three types of route advertisement messages when determining that the own role is inconsistent with the role of the local VTEP.

After the EVPN neighbors are established, MAC address learning is carried out between the local VTEP and the opposite VTEP.

Step 406: when the host hung up by the host goes online, the opposite-end VTEP performs two-layer forwarding table item learning based on the MAC address of the host, and the learned MAC address of the host is carried in a two-class routing notification message and sent to the local VTEP.

The host hung under the VTEP at the opposite end can be a physical machine or a virtual machine. The VTEP at the opposite end can trigger the learning of the MAC address of the host according to a free ARP message sent by the host which is hung down; or according to the flow sent by the down-hanging host to other hosts, the learning of the MAC address of the host can be triggered.

According to the synchronization mechanism of EVPN, the peer VTEP may send the learned MAC address to the local VTEP in the form of a type two route advertisement message. If the former is to advertise role information through three types of route advertisement messages, the two types of route advertisement messages will also carry the role information of VTEP.

Step 407: after receiving a class II route notification message sent by an opposite-end VTEP, the local VTEP performs two-layer forwarding table item learning based on the MAC address carried in the class II route notification message, and prohibits synchronizing the learned MAC address to the VTEP which plays a managed role in the same EVPN instance.

Therefore, in the EVPN networking provided in the embodiment of the present application, the managing VTEP does not synchronize the learned MAC address to the managed VTEP, and the synchronization process may be as shown in fig. 5. Finally, a two-layer forwarding table to all managed VTEP drop hosts in the same EVPN instance can be formed on the managing VTEP, and each managed VTEP only forms a two-layer forwarding table to its own drop host. Therefore, on the premise of not influencing the normal forwarding of the message, the bandwidth resource of the public network can be saved, and the hardware table entry resource of the managed VTEP can also be saved.

After the managing VTEP forms a two-layer forwarding table to all managed VTEP onboarding hosts within the same EVPN instance, the hosts under different managed VTEPs in this EVPN instance can communicate with each other.

In one scenario, if the source host does not know the MAC address of the destination host, the source host needs to request the MAC address of the destination host through an ARP request message. For example, in fig. 2, if the VM1 wants to know the MAC address of the VM2, the VM1 may send an ARP request message with a destination IP address of the VM2 and a destination MAC address of a broadcast address to the outside. After receiving the ARP request message, the managed VTEP1 connected to the VM1 will continue to send the ARP request message to the managing VTEP because the MAC address of the VM2 is not learned locally. If the management VTEP enables the gateway function, the management VTEP stores the ARP table entry of the VM2, so that the management VTEP can respond to the ARP request message, and the MAC address of the VM2 is carried in the ARP response message and returned to the VM 1; if the gateway function is not enabled by the managing VTEP, the managing VTEP will continue to forward the ARP request message to the managed VTEP 2. If the managed VTEP2 enables the gateway function, the ARP request message can be responded after receiving the ARP request; if the managed VTEP2 does not enable the gateway function, the ARP request message continues to be forwarded to VM2, which is answered by VM 2. After receiving the ARP reply message, the VM1 may locally generate an ARP entry and a two-layer forwarding entry related to the MAC address of the VM2 in the VM 1.

After the source host learns the MAC address of the destination host, the source host can communicate with the destination host.

For a source-managed VTEP (namely, a managed VTEP where a source host is located), after receiving a message sent by the source host to a destination host, a two-layer forwarding table entry matched with the message is searched locally. Because the source-managed VTEP does not store the two-layer forwarding table entry of the destination host, the matched two-layer forwarding table entry can not be found, and the message is directly sent to the managing VTEP in the same EVPN instance.

For the management VTEP, after receiving the message sent by the source-managed VTEP, the message can be sent to the connected central site for processing such as uniform authentication, monitoring, filtering, charging and the like. And after receiving the processed message returned by the central site, performing table look-up forwarding on the processed message based on a locally stored two-layer forwarding table entry.

For a destination-managed VTEP (namely the managed VTEP where a destination host is located), after receiving a message forwarded by the managing VTEP, a two-layer forwarding table entry matched with the message is searched locally. Since the destination-managed VTEP stores the two-layer forwarding table entry to the destination host, the matching two-layer forwarding table entry can be found, and the packet can be forwarded based on the found two-layer forwarding table entry.

As can be seen from the above-described host communication process, in the embodiment of the present application, the managed VTEP only stores the two-layer forwarding table entry of the local host suspended from the host, so that when receiving the packet addressed to the network side, the managed VTEP sends the packet to the managing VTEP, and the managing VTEP performs table lookup and forwarding, so that the managed VTEP can realize normal forwarding of the packet even if the two-layer forwarding table entry to other managed VTEP hosts is not formed.

In an embodiment, in order to save hardware table entry resources for managing VTEP, the following aging mechanism is further provided in an embodiment of the present application: when the managed VTEP determines that no message hits a certain locally stored two-layer forwarding table entry within the preset time, deleting the locally stored two-layer forwarding table entry, and also informing the managing VTEP in the same EVPN instance to delete the same two-layer forwarding table entry in the EVPN instance; the MAC address and VXLAN identification of the two-layer forwarding table entry deleted by the VTEP device are the same as those of the two-layer forwarding table entry deleted by the VTEP device. In this embodiment, the managed VTEP may trigger the managed VTEP to release the layer two forwarding table entry no longer used in time.

This completes the description of fig. 4.

As can be seen from the above description of fig. 4, in the present application, VTEPs know roles each other plays in an EVPN instance through role announcement messages, an EVPN neighbor relation is established only between VTEPs playing different roles, and after the EVPN neighbor relation is established, a managed VTEP may synchronize its own learned MAC address with a managed VTEP, but the managed VTEP does not synchronize its own learned MAC address with the managed VTEP any more, which saves hardware entry resources of the entire network. On the forwarding layer, the managed VTEP receives the user flow and forwards the flow to the managing VTEP, the managing VTEP forwards the flow to the central site for unified processing and then checks the table for forwarding, and the flow statistics does not need to be carried out by depending on the managed VTEP, so that the configuration of a statistical function on an AC port of the managed VTEP is avoided.

The methods provided herein are described above. The apparatus provided in the present application is described below.

Referring to fig. 6, for the VTEP provided by the present application, the VTEP is located in the EVPN, and the VTEP may include a transceiving unit 601, a learning unit 602, and a synchronization prohibiting unit 603, where:

a transceiving unit 601, configured to receive, when a local VTEP is a management VTEP, a type two route advertisement message sent by a managed VTEP that establishes an EVPN neighbor relationship with the local VTEP within the same EVPN instance.

A learning unit 602, configured to perform two-layer forwarding table entry learning based on the MAC address carried in the second-type route advertisement message.

A synchronization prohibition unit 603 configured to prohibit synchronization of the MAC address learned by the learning unit to other managed VTEPs within the same EVPN instance.

In one embodiment, the VTEP may further include a neighbor establishing unit; correspondingly, the transceiver 601 may be further configured to receive a role announcement message. The neighbor establishing unit is used for determining that the role of the opposite-end VTEP sending the role announcement message in the EVPN instance is a managed role when determining that the opposite-end role information carried in the role announcement message is inconsistent with the role information of the local VTEP; establishing an EVPN (event virtual private network) neighbor relation with the opposite-end VTEP (virtual private network) based on three types of route advertisement messages sent by the opposite-end VTEP; the role of the local VTEP is the administrative role when the local VTEP is the administrative VTEP. Accordingly, the synchronization prohibition unit 603 is configured to prohibit synchronization of the learned MAC address to the VTEP taking a managed role in the same EVPN instance.

In one embodiment, the transceiver 601 may be further configured to send the role of the local VTEP in the EVPN instance to the managed VTEP through a role announcement message; when the local VTEP is the management VTEP, the role of the local VTEP is a management role; and sending three types of routing advertisement messages to the managed VTEP, so that the managed VTEP establishes an EVPN neighbor relation with the local VTEP based on the received three types of routing advertisement messages when determining that the own role is inconsistent with the role of the local VTEP.

In one embodiment, the transceiver 601 may be further configured to receive a message sent by the managed VTEP; sending the received message to a central site connected with a local VTEP for authentication, monitoring, filtering and charging processing; and receiving a processed message returned by the central site, and performing table look-up forwarding on the processed message based on a locally stored two-layer forwarding table entry.

In one embodiment, the transceiver 601 may be further configured to, when the local VTEP is a managed VTEP, after receiving a packet, locally search a two-layer forwarding entry matching the packet; if the message is found, forwarding the message based on the found two-layer forwarding table entry; and if not, sending the message to a management VTEP in the same EVPN instance, and performing table lookup and forwarding on the message by the management VTEP.

To this end, the description of the functional modules of the VTEP shown in fig. 6 is completed.

Correspondingly, the application also provides a hardware structure of the VTEP shown in FIG. 6. Referring to fig. 7, fig. 7 is a schematic diagram of a hardware structure of the VTEP shown in fig. 6 provided in the present application, where the apparatus 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 communication interface 701 is used for sending and receiving messages. The processor 702 may be a CPU, the memory 703 may be a non-volatile memory, and the memory 703 may store MAC address synchronization logic instructions, and the processor 702 may execute the MAC address synchronization logic instructions stored in the memory 703 to implement the functions of the local VTEP in the flow chart shown in fig. 3.

So far, the description of the hardware structure of the VTEP 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

1. A Media Access Control (MAC) address synchronization method is applied to a local extensible virtual local area network tunnel endpoint (VTEP) in an Ethernet Virtual Private Network (EVPN), wherein the EVPN comprises a management VTEP and a managed VTEP connected with the management VTEP, and the method comprises the following steps:

2. The method of claim 1, wherein a local VTEP establishes an EVPN neighbor relationship with the managed VTEP by:

receiving a role announcement message;

if the opposite terminal role information carried in the role announcement message is inconsistent with the role information of the local VTEP, determining the role of the opposite terminal VTEP sending the role announcement message in the EVPN instance as a managed role; when the local VTEP is the management VTEP, the role of the local VTEP is a management role;

establishing an EVPN (event virtual private network) neighbor relation with the opposite-end VTEP (virtual private network) based on three types of route advertisement messages sent by the opposite-end VTEP;

the inhibiting of synchronizing the learned MAC address to other managed VTEPs within the same EVPN instance includes:

the synchronization of the learned MAC address to the VTEP taking a managed role within the same EVPN instance is prohibited.

3. The method of claim 1, wherein a local VTEP causes the managed VTEP to establish an EVPN neighbor relationship with a local VTEP by:

sending the role of the local VTEP in the EVPN instance to the managed VTEP through a role announcement message; when the local VTEP is the management VTEP, the role of the local VTEP is a management role;

and sending three types of routing advertisement messages to the managed VTEP, so that the managed VTEP establishes an EVPN neighbor relation with the local VTEP based on the received three types of routing advertisement messages when determining that the own role is inconsistent with the role of the local VTEP.

4. The method of claim 1, wherein after performing layer two forwarding entry learning based on the MAC address carried in the type two route advertisement message, the method comprises:

receiving a message sent by the managed VTEP;

sending the received message to a central site connected with a local VTEP for authentication, monitoring, filtering and charging processing;

and receiving a processed message returned by the central site, and performing table look-up forwarding on the processed message based on a locally stored two-layer forwarding table entry.

5. The method of claim 1, wherein when the local VTEP is a managed VTEP, the method further comprises:

when a message is received, a two-layer forwarding table item matched with the message is searched locally;

if the message is found, forwarding the message based on the found two-layer forwarding table entry;

and if not, sending the message to a management VTEP in the same EVPN instance, and performing table lookup and forwarding on the message by the management VTEP.

6. An extensible virtual local area network tunnel endpoint, VTEP, located in an ethernet virtual private network, EVPN, wherein the EVPN comprises a managing VTEP and a managed VTEP connected to the managing VTEP, the VTEP comprising:

7. The VTEP of claim 6, wherein the VTEP further comprises a neighbor establishment unit;

the receiving and sending unit is also used for receiving role notification messages;

the neighbor establishing unit is used for determining that the role of the opposite-end VTEP sending the role announcement message in the EVPN instance is a managed role when determining that the opposite-end role information carried in the role announcement message is inconsistent with the role information of the local VTEP; establishing an EVPN (event virtual private network) neighbor relation with the opposite-end VTEP (virtual private network) based on three types of route advertisement messages sent by the opposite-end VTEP; when the local VTEP is the management VTEP, the role of the local VTEP is a management role;

and the synchronization forbidding unit is used for forbidding the learned MAC address to be synchronized to the VTEP which plays a managed role in the same EVPN instance.

8. The VTEP of claim 6,

the transceiving unit is further configured to send the role of the local VTEP in the EVPN instance to the managed VTEP through a role announcement message; when the local VTEP is the management VTEP, the role of the local VTEP is a management role; and sending three types of routing advertisement messages to the managed VTEP, so that the managed VTEP establishes an EVPN neighbor relation with the local VTEP based on the received three types of routing advertisement messages when determining that the own role is inconsistent with the role of the local VTEP.

9. The VTEP of claim 6,

the receiving and sending unit is further configured to receive a message sent by the managed VTEP; sending the received message to a central site connected with a local VTEP for authentication, monitoring, filtering and charging processing; and receiving a processed message returned by the central site, and performing table look-up forwarding on the processed message based on a locally stored two-layer forwarding table entry.

10. The VTEP of claim 6,

the receiving and sending unit is further configured to, after receiving a message when the local VTEP is a managed VTEP, locally search a two-layer forwarding table entry matching the message; if the message is found, forwarding the message based on the found two-layer forwarding table entry; and if not, sending the message to a management VTEP in the same EVPN instance, and performing table lookup and forwarding on the message by the management VTEP.