Prevention of Transient Loops in Ethernet Virtual Private Network Egress Fast Reroute

Abstract

A method for a network device to act as a Provider Edge (PE) in an Ethernet Virtual Private Network (EVPN) to prevent transient loops between multi-homed peer PEs. The method includes: advertising a first EVPN label to one or more PEs that are multi-homed peer PEs acting as PEs, advertising a second EVPN label to one or more PEs that are multi-homed peer PEs not acting as PEs, receiving a first traffic of a CE encapsulated with the first EVPN label instead of the second EVPN label, and discarding the first traffic in response to determining that a link between the PE and the CE is not operable and the first traffic of the CE is encapsulated with the first EVPN label.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of International Application No. PCT / CN2020 / 098101, filed on June 24, 2020, which is incorporated herein by reference. Technical Field

[0003] The embodiments relate to the field of computer networks, and more particularly, to preventing transient loops between multi - homed peer provider edges in an Ethernet virtual private network. Background Art

[0004] An Ethernet Virtual Private Network (EVPN) is a technology that serves as a virtual private network using wide - area network protocols for carrying Layer 2 Ethernet traffic. EVPN technologies include Ethernet over Multiprotocol Label Switching (MPLS) and Ethernet over Virtual Extensible Local Area Network (VXLAN).

[0005] An EVPN instance may include customer edges (CEs) connected to provider edges (PEs), where the provider edges form the edge of the network infrastructure. The PEs can be connected to other PEs via a Multiprotocol Label Switching (MPLS) infrastructure, which provides benefits of MPLS technology such as fast rerouting and resiliency. Alternatively, the PEs can be connected to other PEs via an IP infrastructure, in which case Generic Routing Encapsulation (GRE) tunneling or other Internet Protocol (IP) tunneling can be used between the PEs. The CEs can be hosts, routers, or switches. The PEs provide virtual Layer 2 bridging connectivity between the CEs. The network can include multiple EVPN instances.

[0006] In EVPN, Media Access Control (MAC) learning between PEs occurs in the control plane rather than the data plane. Control - plane learning provides greater control over the MAC learning process (such as restricting who learns what) and the ability to apply policies. Multiprotocol Border Gateway Protocol (MP - BGP) is commonly used as the control - plane protocol for advertising MAC reachability information in EVPN. For example, a PE can use MP - BGP in the control plane to advertise to other PEs the MAC addresses learned from the CEs connected to the PE along with EVPN labels (e.g., MPLS labels).

[0007] EVPN multi-homing allows a CE to be connected to more than one PE. EVPN multi-homing can provide load balancing, link / node redundancy, and fast convergence. The multi-homing can operate in single-active mode or all-active mode. In single-active mode, only a single PE in a group of PEs attached to a specific Ethernet segment is allowed to forward traffic to and from that Ethernet segment. In all-active mode, all PEs attached to a specific Ethernet segment are allowed to forward traffic to and from that Ethernet segment. When a link failure is detected, the PE withdraws the corresponding Ethernet Auto-Discovery (A-D) set for each Ethernet segment (ES) route, which triggers other PEs to switch to sending traffic towards the multi-homing peer PE. However, the failure propagation and switchover may take a relatively long time, especially in a highly scaled environment.

[0008] The switchover performance can be improved by using a local protection mechanism such as egress fast re-route (eFRR). With eFRR, if a PE receives traffic for a CE but detects that the link between the PE and the CE is inoperable, the PE can forward the traffic to the multi-homing peer PE (e.g., another PE providing connectivity to the CE). The PE can achieve this by encapsulating the traffic for the CE with an EVPN label advertised by the multi-homing peer PE and forwarding the encapsulated traffic to the multi-homing peer PE. However, if the link between the multi-homing peer PE and the CE is also inoperable (e.g., due to a failure in the CE itself), the multi-homing peer PE will forward the traffic back to the PE (as part of the eFRR performed at the multi-homing peer PE). The PE and the multi-homing peer PE will continue to forward traffic to each other in this way until an Ethernet A-D withdrawal for each ES route is received by one of the PEs, creating a transient loop. The transient loop can sometimes last for about several seconds, which results in unnecessary bandwidth consumption in EVPN. Summary of the Invention

[0009] A method for a network device acting as a provider edge (PE) in an Ethernet virtual private network (EVPN) to prevent transient loops between multi-homed peer PEs. The method includes: advertising a first EVPN label to one or more PEs that are multi-homed peer PEs acting as PEs, where if the PEs provide connectivity to the same customer edge (CE) in the same EVPN instance, they are multi-homed peer PEs relative to each other; advertising a second EVPN label to one or more PEs that are not multi-homed peer PEs acting as PEs; receiving first traffic for the CE encapsulated with the first EVPN label instead of the second EVPN label; and discarding the first traffic in response to determining that the link between the PE and the CE is inoperable and the first traffic for the CE is encapsulated with the first EVPN label. The method may further include: receiving second traffic for the CE encapsulated with the second EVPN label instead of the first EVPN label in response to determining that the link between the PE and the CE is inoperable and the second traffic for the CE is encapsulated with the second EVPN label, and forwarding the second traffic to the multi-homed peer PE of the PE.

[0010] A non-transitory machine-readable storage medium providing instructions that, if executed by a processor of a network device acting as a provider edge (PE) in an Ethernet virtual private network (EVPN), will cause the network device to perform operations for preventing transient loops between multi-homed peer PEs. The operations include: advertising a first EVPN label to one or more PEs that are multi-homed peer PEs acting as PEs, where if the PEs provide connectivity to the same customer edge (CE) in the same EVPN instance, they are multi-homed peer PEs relative to each other; advertising a second EVPN label to one or more PEs that are not multi-homed peer PEs acting as PEs; receiving first traffic for the CE encapsulated with the first EVPN label instead of the second EVPN label; and discarding the first traffic in response to determining that the link between the PE and the CE is inoperable and the first traffic for the CE is encapsulated with the first EVPN label. The operations may further include: receiving second traffic for the CE encapsulated with the second EVPN label instead of the first EVPN label in response to determining that the link between the PE and the CE is inoperable and the second traffic for the CE is encapsulated with the second EVPN label, and forwarding the second traffic to the multi-homed peer PE of the PE.

[0011] A network device that acts as a provider edge (PE) in an Ethernet virtual private network (EVPN) to prevent transient loops between multi-homed peer PEs. The network device includes a set of one or more processors and a non-transitory machine-readable storage medium that provides instructions which, if executed by the set of one or more processors, will cause the network device to: advertise a first EVPN label to one or more PEs that are multi-homed peer PEs acting as PEs, where PEs are multi-homed peer PEs relative to each other if they provide connectivity to the same customer edge (CE) in the same EVPN instance; advertise a second EVPN label to one or more PEs that are not multi-homed peer PEs acting as PEs; receive first traffic for a CE encapsulated with the first EVPN label rather than the second EVPN label; and discard the first traffic in response to determining that the link between the PE and the CE is inoperable and the first traffic for the CE is encapsulated with the first EVPN label. The non-transitory machine-readable storage medium provides additional instructions which, if executed by the set of one or more processors, will cause the network device to: receive second traffic for a CE encapsulated with the second EVPN label rather than the first EVPN label in response to determining that the link between the PE and the CE is inoperable and the second traffic for the CE is encapsulated with the second EVPN label, and forward the second traffic to a multi-homed peer PE of the PE. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The present invention may best be understood by reference to the following specification and drawings that illustrate embodiments of the invention. In the drawings.

[0013] Figure 1 is a block diagram that, in accordance with some embodiments, illustrates operations in an Ethernet virtual private network (EVPN) system and operations therein.

[0014] Figure 2 is a block diagram that, in accordance with some embodiments, illustrates operations for another scenario in an EVPN system.

[0015] Figure 3 is a block diagram that, in accordance with some embodiments, illustrates operations for yet another scenario in an EVPN system.

[0016] Figure 4A is a diagram that, in accordance with some embodiments, illustrates the format of an Ethernet segment ingress route target extended community field.

[0017] Figure 4B is a diagram that, in accordance with some embodiments, illustrates the format of an EVI-RT (sometimes referred to as "Ethernet virtual private network instance route target") extended community field.

[0018] Figure 5A flowchart of a process for preventing transient loops between multi-homed peers according to some embodiments.

[0019] Figure 6A Illustrates connectivity between network devices (NDs) within an exemplary network and three exemplary implementations of an ND according to some embodiments.

[0020] Figure 6B Illustrates an exemplary manner of implementing a dedicated network device according to some embodiments.

[0021] Figure 6C Illustrates various exemplary ways of coupling virtual network elements (VNEs) according to some embodiments.

[0022] Figure 6D Illustrates a network having a single network element (NE) on each ND according to some embodiments, and within this direct forwarding method, contrasts a traditional distributed method (commonly used by traditional routers) with a centralized method (also referred to as network control) for maintaining reachability and forwarding information.

[0023] Figure 6E Illustrates a simple case according to some embodiments, where each ND implements a single NE, but the centralized control plane has abstracted multiple NEs among the NEs in different NDs as a single NE within one of the (one or more) virtual networks.

[0024] Figure 6F Illustrates a case according to some embodiments, where multiple VNEs are implemented on different NDs and are coupled to each other, and where the centralized control plane has abstracted these multiple VNEs such that they appear as a single VNE within one of the virtual networks.

[0025] Figure 7 Illustrates a general control plane device having a centralized control plane (CCP) software according to some embodiments. Detailed Description

[0026] The following description describes methods and devices for preventing transient loops between multi-homed peer provider edges (PEs) in an Ethernet Virtual Private Network (EVPN). In the following description, numerous specific details are set forth, such as logical implementation, operation codes, components that specify operands, resource partitioning / sharing / copying implementation, types and interrelationships of system components, and logical partitioning / integration options, in order to provide a more thorough understanding of the present invention. However, those skilled in the art will recognize that the present invention may be practiced without such specific details. In other instances, control structures, gate-level circuits, and full software instruction sequences are not shown in detail so as not to obscure the present invention. Those of ordinary skill in the art will be able to implement appropriate functionality with the description included herein without undue experimentation.

[0027] References in the specification to "one embodiment," "an embodiment," "example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0028] Text in parentheses and boxes with dashed borders (e.g., large dashes, small dashes, dotted lines, and dots) may be used herein to illustrate alternative operations for adding additional features to embodiments of the present invention. However, such notations should not be taken to mean that these are the only options or alternative operations, and / or that boxes with solid borders are not optional in certain embodiments of the present invention.

[0029] In the following specification and claims, the terms "coupled" and "connected" and their derivatives may be used. It should be understood that these terms are not intended as synonyms for each other. "Coupled" is used to indicate that two or more elements cooperate or interact with each other, and they may or may not be in direct physical or electrical contact with each other. "Connected" is used to indicate the establishment of communication between two or more elements that are coupled to each other.

[0030] An electronic device uses machine-readable media (also referred to as computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, solid-state drives, read-only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also referred to as carriers) (e.g., electrical, optical, radio, acoustic, or other forms of propagated signals - such as carrier waves, infrared signals), to store and transmit (internally and / or over a network to other electronic devices) code (which consists of software instructions and which is sometimes referred to as computer program code or a computer program) and / or data. Thus, an electronic device (e.g., a computer) includes hardware and software, such as a collection of one or more processors coupled to one or more machine-readable storage media (e.g., where the processors are microprocessors, controllers, microcontrollers, central processing units, digital signal processors, application-specific integrated circuits, field-programmable gate arrays, other electronic circuits, a combination of one or more of the foregoing), to store code for execution on the collection of processors and / or to store data. For example, an electronic device may include non-volatile memory containing code, because non-volatile memory can persist code / data even when the electronic device is turned off (when power is removed), and when the electronic device is turned on, the portion of the code to be executed by the (one or more) processors of the electronic device is typically copied from the slower non-volatile memory to the volatile memory of the electronic device (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)). A typical electronic device also includes a collection of one or more physical network interfaces (NIs) to establish a network connection with other electronic devices (to transmit and / or receive code and / or data using propagated signals). For example, the collection of physical NIs (or the collection of physical NIs in combination with the collection of processors executing the code) may perform any formatting, encoding, or translation to allow the electronic device to send and receive data (whether via wired and / or wireless connections). In some embodiments, the physical NI may include radio circuitry capable of receiving data from other electronic devices via a wireless connection and / or transmitting data to other devices via a wireless connection. This radio circuitry may include one or more transmitters, one or more receivers, and / or one or more transceivers suitable for radio frequency communication. The radio circuitry may convert digital data into a radio signal with appropriate parameters (e.g., frequency, timing, channel, bandwidth, etc.). The radio signal may then be transmitted via an antenna to one or more appropriate recipients. In some embodiments, the collection of one or more physical NIs may include one or more network interface controllers (NICs), also referred to as network interface cards, network adapters, or local area network (LAN) adapters.One or more network interface cards (NICs) can facilitate connecting an electronic device to other electronic devices, thereby allowing them to communicate via a line by inserting a cable into a physical port connected to the NIC. One or more portions of embodiments of the present invention can be implemented using different combinations of software, firmware, and / or hardware.

[0031] A network device (ND) is an electronic device that is communicatively interconnected with other electronic devices on a network (e.g., other network devices, end-user devices). Some network devices are "multi-service network devices" that provide support for multiple networking functions (e.g., routing, bridging, switching, layer 2 aggregation, session border control, quality of service, and / or subscriber management), and / or provide support for multiple application services (e.g., data, voice, and video).

[0032] As described above, with egress fast reroute (eFRR), if a provider edge (PE) receives traffic for a customer edge (CE) but detects that the link between the PE and the CE is inoperable, the PE can forward the traffic to a multi-homed peer PE (e.g., another PE that provides connectivity to the CE). The PE can achieve this by encapsulating the traffic for the CE with an EVPN label advertised by the multi-homed peer PE and forwarding the encapsulated traffic to the multi-homed peer PE. However, if the link between the multi-homed peer PE and the CE is also inoperable (e.g., due to a failure in the CE itself), the multi-homed peer PE will forward the traffic back to the PE (as part of the eFRR performed at the multi-homed peer PE). The PE and the multi-homed peer PE will continue to forward traffic to each other in this manner until an Ethernet A-D withdraw for each ES route is received by one of the PEs, creating a transient loop. The transient loop can sometimes last for about several seconds, which results in unnecessary bandwidth consumption in EVPN.

[0033] Embodiments disclosed herein provide a mechanism for preventing transient loops between multi-homed peer PEs. According to some embodiments, a PE in an EVPN advertises a first EVPN label to one or more PEs that are multi-homed peer PEs of the PE, and advertises a second EVPN label to one or more PEs that are not multi-homed peer PEs of the PE. If a PE receives traffic for a CE, the PE can determine whether the link between the PE and the CE is operable. If the link between the PE and the CE is operable, the PE can forward the traffic to the CE. However, if the link between the PE and the CE is inoperable, the PE can determine how to dispose of the traffic based on whether the traffic is encapsulated with the first EVPN label or the second EVPN label. If the traffic is encapsulated with the first EVPN label, this indicates that the traffic is from a multi-homed peer PE, and thus the PE discards the traffic without forwarding the traffic to the multi-homed peer PE to avoid creating a transient loop. However, if the traffic is encapsulated with the second EVPN label, this indicates that the traffic is not from a multi-homed peer PE, and thus the PE can forward the traffic to the multi-homed peer PE to provide local protection. Thus, the embodiments disclosed herein can prevent transient loops between multi-homed peer PEs and thus avoid / reduce unnecessary bandwidth consumption in the EVPN caused by transient loops. The embodiments are further described below in this document with reference to the accompanying drawings.

[0034] Figure 1A block diagram of an EVPN system and operations therein for preventing transient loops between multi-homed peers, according to some embodiments. As shown, the EVPN system includes an EVPN 120, which includes PEs 100A, 100B, and 100C. The EVPN 120 can be implemented using, for example, a Multiprotocol Label Switching (MPLS) infrastructure. However, it should be understood that the EVPN 120 can be implemented using other types of Network Virtualization Overlay (NVO) infrastructures, such as a Virtual Extensible LAN (VXLAN) infrastructure, a Network Virtualization using Generic Routing Encapsulation (NVGRE) infrastructure, or a Generic Network Virtualization Encapsulation (GENEVE) infrastructure. CE 110A is multi-homed to PEs 100A and 100B. EVPN multi-homing can provide load balancing, link / node redundancy, and fast convergence. The links connecting CE 110A to PEs 100A and 100B can together form an Ethernet segment 130. An Ethernet Segment Identifier (ESI) can be used to uniquely identify the Ethernet segment 130. In this example, PEs 100A and 100B are multi-homed peers with respect to each other. As used herein, PEs are multi-homed peers with respect to each other if they provide connectivity to the same CE (e.g., via an Ethernet segment) in the same EVPN instance. In this example, the Ethernet segment 130 operates in a full-active mode (as opposed to a single-active mode). In full-active mode, all PEs 100 attached to a particular Ethernet segment are allowed to forward traffic to and from that Ethernet segment. Additionally, in this example, CE 110B is single-homed to PE 100B, while CE 110C is single-homed to PE 100C. Each of the PEs 100 and CEs 110 can be implemented using one or more network devices. A CE 100 can be, for example, a host, a router, or a switch. Although the diagram shows the EVPN system as having a particular arrangement, it should be understood that the EVPN system can have a different arrangement than that shown in the diagram (e.g., the EVPN system can include additional PEs 100, additional CEs 110, and / or other network components).

[0035] As will be further described herein, one or more PEs 100 in an EVPN system can implement a mechanism to prevent transients between multi-homed peer PEs (which may generally be referred to herein as a transient loop prevention mechanism). In one embodiment, a PE (e.g., PE 100A) can implement the transient loop prevention mechanism based on advertising a first EVPN label to one or more PEs (e.g., PE 100B) that are multi-homed peer PEs acting as PEs and advertising a second EVPN label (which is different from the first EVPN label) to one or more PEs (e.g., PE 100C) that are multi-homed peer PEs not acting as PEs. In embodiments where an MPLS infrastructure is used to implement EVPN 120, the first EVPN label and the second EVPN label can be MPLS labels. In embodiments where a VxLAN / NVGRE / GENEVE infrastructure is used to implement EVPN 120, the first EVPN label and the second EVPN label can be VxLAN network identifiers (VNIs).

[0036] In one embodiment, a PE uses Border Gateway Protocol (BGP) advertisement messages to advertise the first EVPN label (e.g., by sending a BGP advertisement message to a multi-homed peer PE of the PE). The BGP advertisement message can indicate the first EVPN label and a route associated with the first EVPN label, which can be, for example, an Ethernet auto-discovery route per EVPN instance or a Media Access Control / Internet Protocol (MAC / IP) advertisement route. It should be noted that in an EVPN virtual private wire service (VPWS), only the Ethernet auto-discovery route per EVPN instance can be used (since MAC / IP advertisement routes are not used in EVPN VPWS).

[0037] The BGP advertisement message may also indicate a group identifier associated with a route associated with the first EVPN label and an EVPN instance associated with the route associated with the first EVPN label, where the combination of the group identifier and the EVPN instance uniquely identifies a multi-homed peer group to which the advertising PE is a member (i.e., a group of PEs that are multi-homed peers relative to each other). In one embodiment, only the PEs that are members of the multi-homed peer group identified by the combination of the group identifier and the EVPN instance may store / import the advertised label / route. Thus, indicating the group identifier and the EVPN instance in the BGP advertisement message ensures that the first EVPN label and the associated route are stored / imported only by the multi-homed peers of the advertising PE (and not by PEs that are not multi-homed peers of the advertising PE). The group identifier may be an identifier that uniquely identifies a multi-homed peer group within a given EVPN instance. The PEs that are members of this group may have been pre-configured with the group identifier or otherwise have knowledge of the group identifier. In one embodiment, the group identifier is generated based on an Ethernet segment identifier. If there are multiple EVPN instances, the group identifier alone may not be sufficient to uniquely identify the multi-homed peer group, because it may be possible for the same group identifier to be used across different EVPN instances, and thus the combination of the group identifier and the EVPN instance can be used to uniquely identify the multi-homed peer group. In one embodiment, the Ethernet segment import route target extended community field included in the BGP advertisement message is used to indicate the group identifier associated with the route associated with the first EVPN label, and the EVI-RT extended community field included in the BGP advertisement message is used to indicate the EVPN instance associated with the route associated with the first EVPN label, to ensure that the first EVPN label is stored / imported only by PEs that are multi-homed peers of the advertising PE. Figure 4A and 4B respectively show examples of the Ethernet segment import route target extended community field format and the EVI-RT extended community field format.

[0038] In one embodiment, the BGP advertisement message indicates a preference level associated with a route associated with the first EVPN label, which is higher than the preference level associated with a route associated with the second EVPN label. This may be particularly important when advertising both the first EVPN label and the second EVPN label to the multi-homed peers of the advertising PE (e.g., this may be the case when broadcasting labels / routes (e.g., using a BGP route reflector) rather than sending them point-to-point). In this case, the receiving multi-homed peer that receives the advertisement will give preference to the first EVPN label over the second EVPN label. In one embodiment, the local preference field (e.g., the LOCAL_PREF field) included in the BGP advertisement message is used to indicate the preference level associated with the route.

[0039] If the advertised PE subsequently receives traffic for a connected CE (a CE connected to the PE via an Ethernet segment) from another PE in EVPN 120, the PE can determine whether the link between itself and the connected CE is operational. The PE can use any suitable link failure detection mechanism to determine whether the link is operational. If the PE determines that the link is operational, the PE can forward the traffic to the connected CE (e.g., via the Ethernet segment), and the traffic delivery is complete. However, if the link between the PE and the connected CE is not operational (e.g., this may be due to a failure of the CE and / or the PE or a failure of the link itself), the PE can determine how to dispose of the traffic based on whether the traffic is encapsulated with a first EVPN label or a second EVPN label. If the traffic is encapsulated with the second EVPN label, this indicates that the traffic does not come from a multi-homed peer PE, and thus the PE can forward the traffic to the multi-homed peer PE for local protection. However, if the traffic is encapsulated with the first EVPN label, this indicates that the traffic comes from a multi-homed peer PE, and thus the PE discards the traffic without forwarding it to the CE and without forwarding it to the multi-homed peer PE (as done for conventional EFRR) to avoid creating a transient loop.

[0040] Now refer to Figure 1 example operations performed in an EVPN system to further illustrate the transient loop prevention mechanism. Figure 1 The operations shown illustrate a scenario where CE 110C sends traffic to CE 110A and PE 100C decides to forward the traffic for CE 110A to PE 100B. In this example, PE 100A implements the transient loop prevention mechanism, while other PEs (e.g., PE 100B and PE 100C) may or may not implement the transient loop prevention mechanism.

[0041] Refer to Figure 1 and, in operation "1", PE 100A advertises a first EVPN label to its multi-homed peer PE (e.g., PE 100B). In operation "2", PE 100A advertises a second EVPN label to a PE that is not a multi-homed peer PE (e.g., PE 100C). PE100A can advertise the first EVPN label to its multi-homed peer PE using a BGP advertisement message that indicates the first EVPN label, the route associated with the first EVPN label (which can be an Ethernet auto-discovery route or a MAC / IP advertisement route per EVPN instance), a group identifier (which can be generated based on the ESI of Ethernet segment 130), and an EVPN instance, where the combination of the group identifier and the EVPN instance uniquely identifies the PE group that is the multi-homed peer PE of PE 100A.

[0042] At operation "3", PE 100C receives traffic for CE 110A (which is connected to PE 100A and PE 100B via Ethernet segment 130) from CE 110C. Since CE 110A is multi-homed to PE 100A and PE 100B (and Ethernet segment 130 operates in the all-active mode), it can be reached via either PE 100A or PE 100B (and the decision of which PE to forward the traffic to is a local decision at PE 100C). In this example, PE 100C decides to forward the traffic to PE 100B. Thus, at operation "4", PE 100C encapsulates the traffic with the EVPN label previously advertised by PE 100B, and at operation "5", forwards the traffic to PE 100B.

[0043] At operation "6", PE 100B receives the encapsulated traffic from PE 100C. When receiving the encapsulated traffic, PE 100B determines whether the link between itself and CE 110A is operable. If PE 100B determines that the link is operable, it performs operation '7a', where it forwards the traffic to CE 110A, and the traffic delivery is completed. However, if PE 100B determines that the link is inoperable, it performs operation "7b", where it encapsulates the traffic with the first EVPN label (previously advertised by PE 100A at operation "1") and forwards the traffic to PE 100A for local protection.

[0044] Assuming PE 100B performs operation "7b", at operation "8", PE 100A receives the traffic encapsulated with the first EVPN label from PE 100B. When receiving the traffic encapsulated with the first EVPN label, PE 100A determines whether the link between itself and CE 110A is operable. If PE 100A determines that the link is operable, it performs operation '9a', where it forwards the traffic to CE 110A, and the traffic delivery is completed. However, if PE 100A determines that the link is inoperable, it performs operation "9b", where it discards the traffic (does not forward the traffic to CE 110A and does not forward the traffic to PE 100B), because the traffic encapsulated with the first EVPN label indicates that the traffic comes from a multi-homed peer PE. This prevents a transient loop between PE 100A and PE 100B.

[0045] Figure 2 is a block diagram illustrating operations in an EVPN system for another scenario according to some embodiments. Except that PE 100C decides to forward the traffic of CE 110A to PE 100A (instead of Figure 1 the shown PE 100B), Figure 2The operations shown illustrate a scenario similar to the scenario shown in Figure 1 In this example, PE 100A implements a transient loop prevention mechanism, while PE 100B does not implement a transient loop prevention mechanism (e.g., it implements conventional eFRR). PE 100C may or may not implement a transient loop prevention mechanism. In operation "1", PE 100A advertises a first EVPN label to its multi-homed peer PE (e.g., PE 100B). In operation "2", PE 100A advertises a second EVPN label to a PE that is not a multi-homed peer PE (e.g., PE 100C). As described above, PE 100A may use a BGP advertisement message to advertise the first EVPN label to the multi-homed peer PE.

[0046] In operation "3", PE 100C receives traffic for CE 110A, which is connected to PE 100A and PE 100B via Ethernet segment 130. Since CE 110A is multi-homed to PE 100A and PE 100B (and Ethernet segment 130 operates in the all-active mode), it can be reached via either PE 100A or PE 100B (and the decision of which PE to forward the traffic to is a local decision at PE 100C). In this example, PE 100C decides to forward the traffic to PE 100A. Thus, in operation "4", PE 100C encapsulates the traffic with the second EVPN label (previously advertised by PE 100B in operation "2"), and in operation "5", forwards the traffic encapsulated with the second EVPN label to PE 100A.

[0047] In operation "6", PE 100A receives the traffic encapsulated with the second EVPN label from PE 100C. When receiving the encapsulated traffic, PE 100A determines whether the link between itself and CE 110A is operable. If PE 100A determines that the link is operable, it performs operation '7a', in which it forwards the traffic to CE 110A, and the traffic delivery is completed. However, if PE 100A determines that the link is inoperable, it performs operation '7b', in which it forwards the traffic to PE 100B for local protection, because the traffic encapsulated with the second EVPN label indicates that the traffic is not from a multi-homed peer PE.

[0048] Assume that PE 100A performs operation "7b". At operation "8", PE 100B receives traffic from PE 100A. When receiving the traffic, PE 100B determines whether the link between itself and CE 110A is operable. If PE 100B determines that the link is operable, it performs operation '9a', in which it forwards the traffic to CE 110A, and the traffic delivery is completed. However, if PE 100B determines that the link is inoperable, it performs operation "9b", in which it encapsulates the traffic with the first EVPN label (previously advertised by PE 100A at operation "1") and forwards the traffic to PE 100A to provide local protection.

[0049] Assume that PE 100B performs operation "9b". At operation "10", PE 100A receives the traffic encapsulated with the first EVPN label from PE 100B. When receiving the traffic encapsulated with the first EVPN label, PE 100A determines whether the link between itself and CE 110A is operable. If PE 100A determines that the link is operable, it performs operation '11a', in which it forwards the traffic to CE 110A, and the traffic delivery is completed. However, if PE 100A determines that the link is inoperable, it performs operation "11b", in which it discards the traffic (without forwarding the traffic to CE 110A and without forwarding the traffic to PE 100B), because the traffic encapsulated with the first EVPN label indicates that the traffic comes from a multi-homed peer PE. This prevents a transient loop between PE 100A and PE 100B.

[0050] As described above, in this example, PE 100B does not implement a transient loop prevention mechanism. However, if PE 100B does implement a transient loop prevention mechanism, it may have discarded the traffic received from PE 100A (e.g., the traffic received at operation "8") to prevent a transient loop if the link between itself and CE 110A is inoperable.

[0051] Figure 3 is a block diagram illustrating operations for another scenario in an EVPN system according to some embodiments. Figure 3The operations shown illustrate the scenario where CE 110B sends traffic to CE 110A. In this example, PE 100A implements a transient loop prevention mechanism, while other PEs (e.g., PE 100B and PE 100C) may or may not implement the transient loop prevention mechanism. In operation "1", PE 100A advertises a first EVPN label to its multi-homed peer PE (e.g., PE 100B). In operation "2", PE 100A advertises a second EVPN label to a PE that is not a multi-homed peer PE (e.g., PE 100C). As described above, PE 100A can use a BGP advertisement message to advertise the first EVPN label to the multi-homed peer PE.

[0052] In operation "3", PE 100B receives traffic for CE 110A from CE 110B. When receiving the traffic, PE 100B determines whether the link between itself and CE 110A is operational. If PE 100B determines that the link is operational, it performs operation '4a', in which it forwards the traffic to CE 110A, and the traffic delivery is completed. However, if PE 100B determines that the link is non-operational, it performs operation "4b", in which it encapsulates the traffic with the first EVPN label (previously advertised by PE 100A in operation "1") and forwards the traffic to PE 100A for local protection.

[0053] Assuming that PE 100B performs operation "4b", in operation "5", PE 100A receives the traffic encapsulated with the first EVPN label from PE 100B. When receiving the traffic encapsulated with the first EVPN label, PE 100A determines whether the link between itself and CE 110A is operational. If PE 100A determines that the link is operational, it performs operation '6a', in which it forwards the traffic to CE 110A, and the traffic delivery is completed. However, if PE 100A determines that the link is non-operational, it performs operation "6b", in which it discards the traffic (does not forward the traffic to CE 110A and does not forward the traffic to PE 100B) because the traffic encapsulated with the first EVPN label indicates that the traffic comes from a multi-homed peer PE. This prevents a transient loop between PE 100A and PE 100B.

[0054] The benefits of the transient loop prevention mechanism described herein are that it is a local protection mechanism (and thus does not require the propagation of network reachability information across the entire network in order to correctly forward traffic), and thus provides fast rerouting (e.g., it has been found that rerouting within about 50 milliseconds is possible). Another benefit of the transient loop prevention mechanism is that it can be deployed incrementally. As can be seen from the examples provided above, correct forwarding of traffic to the CE does not require all PEs to support the transient loop prevention mechanism. Even if only some PEs in the EVPN system implement the transient loop prevention mechanism, traffic can still be correctly forwarded to the CE. Thus, the transient loop prevention mechanism can be deployed incrementally across the PEs in the EVPN system over time. Yet another advantage of the transient loop prevention mechanism is that it can work with conventional EVPN convergence solutions. That is, when the conventional EVPN convergence solution propagates network reachability information to the PEs in the EVPN system, the transient loop prevention mechanism can be used to temporarily reroute traffic. Once convergence occurs, the updated network reachability information can be used to forward traffic.

[0055] Figure 4A is a schematic diagram showing the format of the Ethernet segment incoming route target extended community field according to some embodiments. As shown, the Ethernet segment incoming route target extended community field format 410 may include a type subfield indicating a value of 0x06, a subtype subfield indicating a value of 0x02, and an Ethernet segment incoming (ES-import) subfield. The Ethernet segment incoming route target extended community is defined in Internet Engineering Task Force (IETF) Request for Comments 7432 (RFC 7432). As described above, the Ethernet segment incoming route target extended community field can be used to indicate a group identifier associated with a route (which, together with an EVPN instance, uniquely identifies the multi-homed peer group that the route is targeted at). For example, the group identifier can be indicated in the ES-import subfield.

[0056] Figure 4B is a diagram showing the format of the EVI-RT extended community field according to some embodiments. As shown, the EVI-RT extended community field format 420 may include a type subfield indicating a value of 0x06, a subtype subfield, and a route type (RT) associated with an EVPN instance (EVI) subfield. The Ethernet segment incoming route target extended community is defined in IETF draft-ietf-bess-evpn-igmp-mld-proxy. As described above, the EVI-RT extended community field can be used to indicate an EVPN instance associated with a route (which, together with a group identifier, uniquely identifies the multi-homed peer group that the route is targeted at). For example, the EVPN instance can be indicated in the RT associated with the EVI subfield.

[0057] In one embodiment, when advertising EVPN labels / routes (e.g., Ethernet Auto-Discovery Route per EVI or MAC / IP advertisement route), the PE must include exactly one Ethernet segment ingress route target extended community and exactly one EVI-RT extended community.

[0058] Figure 5 FIG. 4 is a flowchart of a process for preventing transient loops between multi-homed peer PEs according to some embodiments. In one embodiment, the process is implemented by a network device acting as a PE in an EVPN. The operations in the flowchart will be described with reference to exemplary embodiments of other figures. However, it should be understood that the operations of the flowchart may be performed by embodiments of the present invention other than those discussed with reference to the other figures, and embodiments of the present invention discussed with reference to these other figures may perform operations different from those discussed with reference to the flowchart.

[0059] In block 510, the PE advertises a first EVPN label to one or more PEs that are multi-homed peer PEs of the PE, where the PEs are multi-homed peer PEs with respect to each other if they provide connectivity to the same CE in the same EVPN instance. In one embodiment, the first EVPN label is advertised using a BGP advertisement message. In one embodiment, the BGP advertisement message indicates a route associated with the first EVPN label, where the route is an Ethernet Auto-Discovery Route or a MAC / IP advertisement route per EVPN instance. In one embodiment, the BGP advertisement message indicates a group identifier associated with the route and an EVPN instance associated with the route, where the group identifier associated with the route is indicated using an Ethernet segment ingress route target extended community field included in the BGP advertisement message, and the EVPN instance associated with the route is indicated using an EVI-RT extended community field included in the BGP advertisement message. In one embodiment, the BGP advertisement message indicates a preference level associated with the route, where the preference level associated with the route is indicated using a local preference field included in the BGP advertisement message, where when advertising both the first EVPN label and a second EVPN label to a multi-homed peer PE of the PE, the preference level associated with the route associated with the first EVPN label is higher than the preference level associated with the route associated with the second EVPN label. In one embodiment, the first EVPN label is an MPLS label. In another embodiment, the first EVPN label is a VNI.

[0060] In block 520, the PE advertises a second EVPN label (which is different from the first EVPN label) to one or more PEs that are not multi-homed peer PEs of the PE.

[0061] In block 530, the PE receives traffic for a CE connected to the PE.

[0062] At decision box 540, the PE determines whether the link between the PE and the CE is operational. If the PE determines that the link is operational, then at box 550, the PE forwards traffic for the CE to the CE (regardless of whether the traffic is encapsulated with a first EVPN label or a second EVPN label). However, if the PE determines that the link is not operational, then at decision box 560, the PE determines the EVPN label (the EVPN label encapsulating the traffic). In one embodiment, due to a failure of the CE or the PE (or a failure of the link itself), the link to the CE is not operational. If the EVPN label is the first EVPN label, then at box 570, the PE discards the traffic (e.g., to prevent transient loops). However, if the EVPN label is the second EVPN label, then at box 580, the PE forwards the traffic to a multi-homed peer PE of the PE (e.g., for local protection).

[0063] Figure 6A Illustrated is the connectivity between network devices (NDs) within an exemplary network according to some embodiments, as well as three exemplary implementations of the NDs. Figure 6A The connectivity of the NDs 600 A-H and their connections are shown by lines between 600A - 600B, 600B - 600C, 600C - 600D, 600D - 600E, 600E - 600F, 600F - 600G, and between 600A - 600G, and between each of 600H and 600A, 600C, 600D, and 600G. These NDs are physical devices, and the connectivity between these NDs can be wireless or wired (often referred to as a link). Additional lines extending from NDs 600A, 600E, and 600F illustrate that these NDs act as entry and exit points of the network (and thus, these NDs are sometimes referred to as edge NDs; while the other NDs can be referred to as core NDs).

[0064] Figure 6A Two of the exemplary ND implementations are: 1) a dedicated network device 602 that uses a custom application-specific integrated circuit (ASIC) and a dedicated operating system (OS); and 2) a general network device 604 that uses an off-the-shelf (COTS) processor and a standard OS.

[0065] The dedicated network device 602 includes networking hardware 610, which includes a collection of one or more processors 612, one or more forwarding resources 614 (which typically include one or more ASICs and / or network processors), and one or more physical network interfaces (NIs) 616 (through which network connections are made, such as those shown by the connectivity between ND 600A-H), and a non-transitory machine-readable storage medium 618 in which networking software 620 has been stored. During operation, the networking software 620 can be executed by the networking hardware 610 to instantiate a collection of one or more network software instances 622. Each of the one or more networking software instances 622 and that portion of the networking hardware 610 that executes the network software instance (whether hardware dedicated to the networking software instance and / or a time slice of hardware shared by the networking software instance with other instances of the one or more networking software instances 622 over time) forms a separate virtual network element 630A-R. Each of the one or more virtual network elements (VNEs) 630A-R includes a control communication and configuration module 632A-R (sometimes referred to as a local control module or control communication module) and one or more forwarding tables 634A-R, such that a given virtual network element (e.g., 630A) includes a control communication and configuration module (e.g., 632A), a collection of one or more forwarding tables (e.g., 634A), and that portion of the networking hardware 610 that executes the virtual network element (e.g., 630A).

[0066] In one embodiment, the software 620 includes code, such as a transient loop prevention component 625, which when executed by the networking hardware 610 causes the dedicated network device 602 to perform the operations of one or more embodiments of the present invention as part of the networking software instance 622 (e.g., to prevent transient loops between multi-homed peers PE).

[0067] The dedicated network device 602 is often physically and / or logically considered to include: 1) an ND control plane 624 (sometimes referred to as the control plane), including one or more processors 612 that execute one or more control communication and configuration modules 632A-R; and 2) an ND forwarding plane 626 (sometimes referred to as the forwarding plane, data plane, or media plane), including one or more forwarding resources 614 that utilize one or more forwarding tables 634A-R and physical NIs 616. As an example where ND is a router (or implementing routing functionality), the ND control plane 624 (the one or more processors 612 that execute one or more control communication and configuration modules 632A-R) is typically responsible for participating in controlling how data (e.g., packets) are routed (e.g., the next hop of the data and the outgoing physical NI for the data) and storing that routing information in one or more forwarding tables 634A-R, and the ND forwarding plane 626 is responsible for receiving the data on the physical NI 616 and forwarding the data out the appropriate NI in the physical NI 616 based on one or more forwarding tables 634A-R.

[0068] Figure 6B An exemplary manner of implementing the dedicated network device 602 according to some embodiments is illustrated. Figure 6B A dedicated network device including a card 638 (usually hot-pluggable) is shown. While in some embodiments the card 638 is of two types (one or more that operate as the ND forwarding plane 626 (sometimes referred to as line cards) and one or more that operate to implement the ND control plane 624 (sometimes referred to as control cards)), alternative embodiments may combine the functionality onto a single card, and / or include additional card types (e.g., one additional card type is referred to as a service card, resource card, or multi-application card). A service card can provide specialized processing (e.g., layer 4 to layer 7 services (e.g., firewall, Internet Protocol Security (IPsec), Secure Sockets Layer (SSL) / Transport Layer Security (TLS), Intrusion Detection System (IDS), peer-to-peer (P2P), Voice over Internet Protocol (VoIP) session border controller, mobile radio gateway (Gateway General Packet Radio Service (GPRS) Support Node (GGSN), Evolved Packet Core (EPC) gateway))). As an example, a service card can be used to terminate an IPsec tunnel and perform the accompanying authentication and encryption algorithms. These cards are coupled together by one or more interconnect mechanisms illustrated as a backplane 636 (e.g., a first full mesh coupling the line cards and a second full mesh coupling all the cards).

[0069] Return to Figure 6A, the general network device 604 includes hardware 640, which includes a set of one or more processors 642 (which are often COTS processors) and a physical NI 646, as well as a non-transitory machine-readable storage medium 648 in which software 650 is stored. During operation, the (one or more) processors 642 execute the software 650 to instantiate one or more sets of one or more applications 664A-R. Although one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization. For example, in one such alternative embodiment, the virtualization layer 654 represents the kernel of the operating system (or a shim executing on top of the base operating system), which allows the creation of multiple instances 662A-R, called software containers, each of which can be used to execute one (or more) of the sets of applications 664A-R; where the multiple software containers (also called virtualization engines, virtual private servers, or jails) are separate from each other and from the kernel space in which the operating system runs, which is typically a virtual memory space; and where the set of applications running in a given user space cannot access the memory of other processes unless explicitly permitted. In another such alternative embodiment, the virtualization layer 654 represents a hypervisor (sometimes called a virtual machine monitor (VMM)) or a hypervisor executing on top of the host operating system, and each of the sets of applications 664A-R runs on top of a guest operating system within an instance 662A-R, called a virtual machine (which in some cases can be considered a tightly isolated form of a software container), and the virtual machine runs on top of the hypervisor - the guest operating system and applications may not know that they are running on a virtual machine rather than on a "bare metal" host electronic device, or through paravirtualization, the operating system and / or applications can be aware of the existence of virtualization for optimization purposes. In still some other alternative embodiments, one, some, or all of these applications are implemented as (one or more) unikernels, which can be generated by directly compiling only a limited set of libraries that provide the specific OS services required by the application (e.g., from a library operating system (LibOS), which includes libraries / drivers for OS services). Since unikernels can be implemented to run directly on the hardware 640, directly on the hypervisor (in which case the unikernel is sometimes described as running within a LibOS virtual machine), or within a software container, embodiments can be implemented by fully leveraging unikernels running directly on the hypervisor represented by the virtualization layer 654, unikernels running within the software containers represented by the instances 662A-R, or as a combination of unikernels and the above technologies (e.g., unikernels and virtual machines both running directly on the hypervisor, unikernels and sets of applications running in different software containers).

[0070] The instantiation and virtualization (if implemented) of one or more collections of one or more applications 664A-R are collectively referred to as (one or more) software instances 652. Each collection of applications 664A-R, the corresponding virtualized constructs (e.g., instances 662A-R) (if implemented), and that portion of the hardware 640 that executes them (if it is hardware dedicated to that execution and / or a time slice of time-shared hardware) form (one or more) separate virtual network elements 660A-R.

[0071] The (one or more) virtual network elements 660A-R perform functionality similar to that of the (one or more) virtual network elements 630A-R - e.g., similar to the (one or more) control communication and configuration modules 632A and the (one or more) forwarding tables 634A (this virtualization of the hardware 640 is sometimes referred to as network function virtualization (NFV)). Thus, NFV can be used to consolidate many network device types onto industry-standard high-volume server hardware, physical switches, and physical storage devices, which may be located in data centers, ND, and customer premise equipment (CPE). While embodiments are shown where each instance 662A-R corresponds to one VNE 660A-R, alternative embodiments may implement this correspondence at a finer level of granularity (e.g., line card virtual machines virtualize line cards, control card virtual machines virtualize control cards, etc.); it should be understood that the techniques described herein with reference to the correspondence of instances 662A-R to VNEs also apply to embodiments using such finer levels of granularity and / or single kernels.

[0072] In some embodiments, the virtualization layer 654 includes a virtual switch that provides forwarding services similar to those of a physical Ethernet switch. Specifically, the virtual switch forwards traffic between instances 662A-R and the (one or more) physical NIs 646 and optionally between instances 662A-R; additionally, the virtual switch can enforce network isolation between VNEs 660A-R that are not allowed to communicate with each other by policy (e.g., by honoring virtual local area networks (VLANs)).

[0073] In one embodiment, the software 650 includes code, such as a transient loop prevention component 663, that when executed by the (one or more) processors 642 causes the general network device 604 to perform the operations of one or more embodiments of the present invention as part of the software instances 662A-R (e.g., to prevent transient loops between multi-homed peers PE).

[0074] Figure 6AA third exemplary ND implementation is the hybrid network device 606, which includes a custom ASIC / specialized OS and a COTS processor / standard OS in a single ND or on a single card within an ND. In some embodiments of such hybrid network devices, the platform VM (i.e., the VM that implements the functionality of the dedicated network device 602) may provide para-virtualization to the networking hardware present in the hybrid network device 606.

[0075] Regardless of the above exemplary implementations of the ND, when considering a single VNE among the multiple VNEs implemented by the ND (e.g., only one of the VNEs is part of a given virtual network), or in the case where only a single VNE is currently implemented by the ND, the shortened term network element (NE) is sometimes used to refer to that VNE. Additionally, in all of the above exemplary implementations, each of these VNEs (e.g., (one or more) VNEs 630A-R, VNEs 660A-R, and the VNEs in the hybrid network device 606) receives data on a physical NI (e.g., 616, 646) and forwards the data out of an appropriate physical NI among the physical NIs (e.g., 616, 646). For example, a VNE that implements IP router functionality forwards IP packets based on some IP header information in the IP packet; where the IP header information includes a source IP address, a destination IP address, a source port, a destination port (where "source port" and "destination port" herein refer to the protocol ports of the ND, not physical ports), a transport protocol (e.g., User Datagram Protocol (UDP), Transmission Control Protocol (TCP)), and a Differentiated Services Code Point (DSCP) value.

[0076] Figure 6C Illustrated are various exemplary ways that can be used to couple VNEs according to some embodiments. Figure 6C Shown are the VNE 670H.1 in the ND600H and the VNEs 670A.1 - 670A.P (and optionally VNEs 670A.Q - 670A.R) implemented in the ND 600A. In Figure 6CAmong them, VNE 670A.1-P are separated from each other in the following sense: they can receive packets from outside ND 600A and forward the packets to outside ND 600A; VNE 670A.1 is coupled to VNE 670H.1, and thus they transfer packets between their respective NDs; VNE 670A.2 - 670A.3 can optionally forward packets between themselves without forwarding them to outside ND 600A; and VNE 670A.P can optionally be the first in a VNE chain that includes VNE 670A.Q and subsequent VNE 670A.R (this is sometimes referred to as dynamic service chaining, where each VNE in the VNE series provides a different service - for example, one or more layer 4 - 7 network services). Although Figure 6C The figure illustrates various exemplary relationships between VNEs, but alternative embodiments may support other relationships (e.g., more / fewer VNEs, more / fewer dynamic service chains, multiple different dynamic service chains with some common VNEs and some different VNEs).

[0077] Figure 6A The NDs can, for example, form part of the Internet or a private network; and other electronic devices (not shown; such as end - user devices, including workstations, laptops, netbooks, tablet computers, palmtop computers, mobile phones, smartphones, phablets, multimedia phones, voice - over - Internet - protocol (VOIP) phones, terminals, portable media players, GPS units, wearable devices, gaming systems, set - top boxes, Internet - enabled household appliances) can be coupled to the network (either directly or through other networks, such as access networks) to communicate with each other (either directly or through servers) and / or access content and / or services through the network (e.g., the Internet or a virtual private network (VPN) overlaying (e.g., tunneling through) the Internet). Such content and / or services are typically provided by one or more servers (not shown) belonging to a service / content provider or one or more end - user devices (not shown) participating in a peer - to - peer (P2P) service, and can include, for example, public web pages (e.g., free content, storefronts, search services), private web pages (e.g., web pages providing username / password access to an email service), and / or corporate networks on a VPN. For example, an end - user device can be coupled to an edge ND (e.g., through a customer - premise equipment (CPE) coupled (wired or wirelessly) to an access network), the edge ND is coupled to other edge NDs (e.g., through one or more core NDs), and the other edge NDs are coupled to electronic devices acting as servers. However, through computing and storage virtualization, in Figure 6AOne or more of the electronic devices acting as NDs may also host one or more such servers (e.g., in the case of the general network device 604, one or more of the software instances 662A-R may operate as servers; this would be the case for the hybrid network device 606; in the case of the dedicated network device 602, one or more such servers may also run on a virtualization layer executed by the processor(s) 612; in this case, the server is said to be collocated with the VNE of that ND).

[0078] A virtual network is a logical abstraction of a physical network (such as the physical network in Figure 6A that provides network services (such as L2 and / or L3 services). A virtual network can be implemented as an overlay network (sometimes referred to as a network virtualization overlay), which provides network services (such as Layer 2 (L2, data link layer) and / or Layer 3 (L3, network layer) services) over an underlying network (e.g., an L3 network, such as an Internet Protocol (IP) network that uses tunnels to create the overlay network (e.g., Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TP), IPSec)).

[0079] The Network Virtualization Edge (NVE) is located at the edge of the underlying network and participates in implementing network virtualization; the network-facing side of the NVE uses the underlying network to tunnel frames to and from other NVEs; the outside-facing side of the NVE sends data to and receives data from systems external to the network. A Virtual Network Instance (VNI) is a specific instance of a virtual network on an NVE (e.g., an NE / VNE on an ND, a part of an NE / VNE on an ND, where the NE / VNE is divided into multiple VNEs through emulation); one or more VNIs can be instantiated on an NVE (e.g., as different VNEs on an ND). A Virtual Access Point (VAP) is a logical connection point on an NVE for connecting external systems to the virtual network; a VAP can be a physical port or a virtual port identified by a logical interface identifier (such as a VLAN ID).

[0080] Examples of network services include: 1) Ethernet LAN emulation services (Ethernet-based multipoint services similar to Internet Engineering Task Force (IETF) Multiprotocol Label Switching (MPLS) or Ethernet VPN (EVPN) services), where external systems are interconnected across networks through a LAN environment over an underlying network (e.g., NVE provides separate L2VNIs (Virtual Switching Instances) for different such virtual networks and L3 (e.g., IP / MPLS) tunneling encapsulation across the underlying network); and 2) virtualized IP forwarding services (similar to IETF IP VPN from a service definition perspective, e.g., Border Gateway Protocol (BGP) / MPLS IP VPN), where external systems are interconnected across networks through an L3 environment over an underlying network (e.g., NVE provides separate L3 VNIs (Forwarding and Routing Instances) for different such virtual networks and L3 (e.g., IP / MPLS) tunneling encapsulation across the underlying network). Network services can also include quality of service capabilities (e.g., traffic classification marking, traffic conditioning, and scheduling), security capabilities (e.g., filters that protect user premises from network-initiated attacks to avoid malformed routing announcements), and management capabilities (e.g., full detection and handling).

[0081] Figure 6D illustrates a network having a single network element on each ND according to some embodiments, and within this direct forwarding method, contrasts the traditional distributed method (commonly used by traditional routers) with a centralized method (also known as network control) for maintaining reachability and forwarding information. Specifically, Figure 6A illustrates a network having network elements (NEs) 670A-H with the same connectivity as the NDs 600 A-H of Figure 6D illustrates Figure 6A The distributed method 672 distributes the responsibility for generating reachability and forwarding information across the NEs 670A-H; in other words, the processes of neighbor discovery and topology discovery are distributed.

[0082] Figure 6D illustrates that the distributed method 672 distributes the responsibility for generating reachability and forwarding information across the NEs 670A-H; in other words, the processes of neighbor discovery and topology discovery are distributed.

[0083] For example, in the case of using a dedicated network device 602, the (one or more) control communication and configuration modules 632A-R of the ND control plane 624 typically include reachability and forwarding information modules to implement one or more routing protocols (e.g., exterior gateway protocols (such as Border Gateway Protocol (BGP)), (one or more) interior gateway protocols (IGP) (e.g., Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), Routing Information Protocol (RIP), Label Distribution Protocol (LDP), Resource Reservation Protocol (RSVP) (including RSVP-Traffic Engineering (TE): an extension of RSVP for LSP tunnels and Generalized Multi-Protocol Label Switching (GMPLS) signaling RSVP-TE)), which communicate with other NEs to exchange routes and then select those routes based on one or more routing metrics. Thus, the NEs 670A-H (e.g., the (one or more) processors 612 that execute the (one or more) control communication and configuration modules 632A-R) perform their responsibility of participating in controlling how control data (e.g., packets) are routed (e.g., the next hop of the data and the outgoing physical NI for that data) by distributively determining reachability within the network and calculating their corresponding forwarding information. Routing and adjacency relationships are stored in one or more routing structures (e.g., Routing Information Base (RIB), Label Information Base (LIB), one or more adjacency relationship structures) on the ND control plane 624. The ND control plane 624 programs the ND forwarding plane 626 with information (e.g., adjacency relationships and routing information) based on the (one or more) routing structures. For example, the ND control plane 624 programs adjacency relationships and routing information into one or more forwarding tables 634A-R (e.g., Forwarding Information Base (FIB), Label Forwarding Information Base (LFIB), and one or more adjacency relationship structures) on the ND forwarding plane 626. For Layer 2 forwarding, the ND can store one or more bridging tables for forwarding the data based on Layer 2 information in the data. Although the above example uses a dedicated network device 602, the same distributed approach 672 can be implemented on a general network device 604 and a hybrid network device 606.

[0084] Figure 6DIllustrated is a centralized approach 674 (also known as software-defined networking (SDN)), which decouples the system that makes decisions about where traffic is sent from the underlying system that forwards traffic to the selected destination. The illustrated centralized approach 674 is responsible for generating reachability and forwarding information in a centralized control plane 676 (sometimes referred to as an SDN control module, controller, network controller, OpenFlow controller, SDN controller, control plane node, network virtualization authority, or management control entity), and thus the processes of neighbor discovery and topology discovery are centralized. The centralized control plane 676 has a south bound interface 682 with a data plane 680 (sometimes referred to as an infrastructure layer, network forwarding plane, or forwarding plane (which should not be confused with the ND forwarding plane)), and the data plane 680 includes NEs 670A-H (sometimes referred to as switches, forwarding elements, data plane elements, or nodes). The centralized control plane 676 includes a network controller 678, and the network controller 678 includes a centralized reachability and forwarding information module 679 that determines reachability within the network and distributes forwarding information to the NEs 670A-H of the data plane 680 via the south bound interface 682 (which may use the OpenFlow protocol). Thus, network intelligence is centralized in the centralized control plane 676, which is executed on an electronic device that is typically separate from the ND. In one embodiment, the network controller 678 includes a transient loop prevention component 681 that, when executed by the network controller 678, causes the network controller 678 to perform the operations of one or more embodiments of the present invention (e.g., programming one or more PEs in an EVPN system to implement a transient loop prevention mechanism).

[0085] For example, in the case of using dedicated network device 602 in data plane 680, each of the (one or more) control communication and configuration modules 632A-R of ND control plane 624 typically includes a control agent on the VNE side that provides southbound interface 682. In this case, ND control plane 624 (the (one or more) processors 612 that execute the (one or more) control communication and configuration modules 632A-R) performs its responsibility: to participate in controlling how control data (e.g., packets) are routed (e.g., the next hop of the data and the outgoing physical NI for that data) by receiving forwarding information (and in some cases reachability information) from centralized reachability and forwarding information module 679 via the control agent that communicates with centralized control plane 676; it should be understood that in some embodiments, the (one or more) control communication and configuration modules 632A-R may also play some role in determining reachability and / or calculating forwarding information in addition to communicating with centralized control plane 676 - although not as much as in the case of the distributed approach; such embodiments are generally considered to fall under the centralized approach 674, but may also be considered a hybrid approach).

[0086] Although the example above uses dedicated network device 602, the same centralized approach 674 can be implemented using general network device 604 and hybrid network device 606 (e.g., each of VNE 660A-R performs its responsibility: to control how data (e.g., packets) are to be routed (e.g., the next hop of the data and the outgoing physical NI for that data) by receiving forwarding information (and in some cases reachability information) from centralized reachability and forwarding information module 679 via communication with centralized control plane 676; it should be understood that in some embodiments, VNE 660A-R may also play some role in determining reachability and / or calculating forwarding information in addition to communicating with centralized control plane 676 - although not as much as in the case of the distributed approach). In fact, using SDN technology can enhance NFV technology that is typically used in the implementation of general network device 604 or hybrid network device 606, because NFV can support SDN by providing an infrastructure on which SDN software can run, and both NFV and SDN are aimed at leveraging commercial server hardware and physical switches.

[0087] Figure 6DIt is also shown that the centralized control plane 676 has a northbound interface 684 to the application layer 686, in which (one or more) applications 688 reside. The centralized control plane 676 has the ability to form a virtual network 692 (sometimes referred to as a logical forwarding plane, network service, or overlay network (utilizing the NEs 670A-H of the data plane 680 as the underlying network)) for (one or more) applications 688. Thus, the centralized control plane 676 maintains a global view of all NDs and the configured NEs / VNEs, and it effectively maps the virtual network to the underlying NDs (including preserving these mappings when the physical network changes due to hardware (ND, link, or ND component) failures, additions, or removals).

[0088] While Figure 6D the distributed approach 672 is shown separately from the centralized approach 674, in some embodiments, the work of network control can be distributed in different ways or a combination of both. For example: 1) embodiments can generally use the centralized approach (SDN) 674, but delegate certain functions to the NEs (e.g., the distributed approach can be used to implement one or more of fault monitoring, performance monitoring, protection switching, and primitives for neighbor and / or topology discovery); or 2) embodiments can perform neighbor discovery and topology discovery via both the centralized control plane and the distributed protocol, and the results are compared to raise exceptions where they are inconsistent. Such embodiments are generally considered to fall under the centralized approach 674, but can also be considered a hybrid approach.

[0089] While Figure 6D the simple case where each of the NDs 600A-H implements a single NE 670A-H is illustrated, it should be understood that the network control methods described Figure 6D also work for networks in which one or more of the NDs 600A-H implement multiple VNEs (such as the VNEs 630A-R, VNEs 660A-R, those in the hybrid network device 606). Alternatively or additionally, the network controller 678 can also emulate the implementation of multiple VNEs in a single ND. Specifically, instead of (or in addition to) implementing multiple VNEs in a single ND, the network controller 678 can present the implementation of VNEs / NEs in a single ND as multiple VNEs in the virtual network 692 (all in the same virtual network in (one or more) virtual networks 692, each in a different virtual network in (one or more) virtual networks 692, or some combination). For example, the network controller 678 can cause the ND to implement a single VNE (NE) in the underlying network, and then logically partition the resources of that NE within the centralized control plane 676 to present different VNEs in (one or more) virtual networks 692 (where these different VNEs in the overlay network share the resources of the single VNE / NE implementation on the ND in the underlying network).

[0090] On the other hand, Figure 6E and 6F respectively illustrate exemplary abstractions of NEs and VNEs in which network controller 678 can be presented as part of different virtual networks in virtual network 692. Figure 6E Illustrates a simple case according to some embodiments, where each of ND 600 A-H implements a single NE 670A-H (see Figure 6D ), but the centralized control plane 676 has abstracted multiple NEs (NEs 670A-C and G-H) among the NEs in different NDs into (represented as) Figure 6D a single NE 670I in one of the virtual networks 692. Figure 6E Shows that in this virtual network, NE 670I is coupled to NEs 670D and 670F, both of which are still coupled to NE 670E.

[0091] Figure 6F Illustrates a situation according to some embodiments, where multiple VNEs (VNE 670A.1 and VNE670H.1) are implemented on different NDs (ND 600A and ND 600H) and are coupled to each other, and where the centralized control plane 676 has abstracted these multiple VNEs such that they appear as if Figure 6D a single VNE670T within one of the virtual networks 692. Thus, the abstraction of an NE or VNE can span multiple NDs.

[0092] Although some embodiments implement the centralized control plane 676 as a single entity (e.g., a single software instance running on a single electronic device), for redundancy and / or scalability purposes, alternative embodiments may spread functionality across multiple entities (e.g., multiple software instances running on different electronic devices).

[0093] Similar to network device implementations, the (one or more) electronic devices running the centralized control plane 676 can be implemented in a variety of ways (e.g., dedicated devices, general-purpose (e.g., COTS) devices, or hybrid devices), and thereby implement network controller 678 including the centralized reachability and forwarding information module 679. These (one or more) electronic devices will similarly include (one or more) processors, a set of one or more physical NIs, and a non-transitory machine-readable storage medium storing the centralized control plane software. For example, Figure 7A general control plane apparatus 704 is shown that includes hardware 740, the hardware 740 including a set of (one or more) processors 742 (which are typically COTS processors) and a physical NI 746, and a non-transitory machine-readable storage medium 748 in which a centralized control plane (CCP) software 750 and a transient loop prevention component 751 are stored.

[0094] In embodiments using compute virtualization, the (one or more) processors 742 typically execute software to instantiate a virtualization layer 754 (e.g., in one embodiment, the virtualization layer 754 represents the kernel of an operating system (or a shim executing on a base operating system) that allows creation of multiple instances 762A-R, referred to as software containers (representing separate user spaces and also referred to as virtualization engines, virtual private servers, or jails), each of which can be used to execute a set of one or more applications; in another embodiment, the virtualization layer 754 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on a host operating system, and the applications run on a guest operating system within an instance 762A-R, referred to as a virtual machine (which in some cases can be considered a tightly isolated form of a software container), that is run by the hypervisor; in another embodiment, the application is implemented as a unikernel, which can be generated by directly compiling only a limited set of libraries that provide specific OS services required by the application (e.g., from a library operating system (LibOS), a library / driver including OS services), and the unikernel can run directly on the hardware 740, directly on the hypervisor represented by the virtualization layer 754 (in which case the unikernel is sometimes described as running within a LibOS virtual machine), or within a software container represented by one of the instances 762A-R. Further, in embodiments using compute virtualization, during operation, an instance of the CCP software 750 (shown as CCP instance 776A) is executed on the virtualization layer 754 (e.g., within instance 762A). In embodiments not using compute virtualization, the CCP instance 776A is executed as a unikernel or on top of a host operating system on the "bare metal" general control plane apparatus 704. The instantiation of the CCP instance 776A and the virtualization layer 754 and the instances 762A-R (if implemented) are collectively referred to as the (one or more) software instances 752.

[0095] In some embodiments, the CCP instance 776A includes a network controller instance 778. The network controller instance 778 includes a centralized reachability and forwarding information module instance 779 (which is a middleware layer that provides the context of the network controller 678 to the operating system and communicates with various NEs) and a CCP application layer 780 (sometimes referred to as the application layer) on the middleware layer (which provides the intelligence required for various network operations, such as protocols, network condition awareness, and user interfaces). At a more abstract level, this CCP application layer 780 within the centralized control plane 676 works with the (one or more) virtual network views (the (one or more) logical views of the network), and the middleware layer provides the translation from the virtual network to the physical view.

[0096] The transient loop prevention component 751 can be executed by the hardware 740 to perform the operations of one or more embodiments of the present invention as part of the software instance 752 (e.g., to prevent transient loops between multi-homed peers PE).

[0097] The centralized control plane 676 transmits relevant messages to the data plane 680 based on per-flow CCP application layer 780 calculations and middleware layer mappings. A flow can be defined as a set of packets whose headers match a given bit pattern; in this sense, traditional IP forwarding is also flow-based forwarding, where the flow is defined, for example, by the destination IP address; however, in other implementations, the given bit pattern for flow definition can include more fields (e.g., 10 or more) in the packet header. Different NDs / NEs / VNEs of the data plane 680 can receive different messages and thus receive different forwarding information. The data plane 680 processes these messages and programs the appropriate flow information and corresponding actions in the forwarding table (sometimes referred to as the flow table) of the appropriate NE / VNE, and then the NE / VNE maps the incoming packets to the flows represented in the forwarding table and forwards the packets based on the matches in the forwarding table.

[0098] Standards such as OpenFlow define the protocols for messages and the models for processing packets. The models for processing packets include header parsing, packet classification, and making forwarding decisions. Header parsing describes how to interpret packets based on a known set of protocols. Some protocol fields are used to construct the matching structures (or keywords) that will be used in packet classification (e.g., the first keyword field might be the source media access control (MAC) address, while the second keyword field might be the destination MAC address).

[0099] Packet classification involves performing a lookup in a memory to classify a packet by determining which entry in a forwarding table (also referred to as a forwarding table entry or flow entry) best matches the packet based on a match structure or key in the forwarding table entry. It is possible that many flows represented in the forwarding table entries can correspond to / match a packet; in such cases, the system is typically configured to determine one forwarding table entry from among the many forwarding table entries according to a defined scheme (e.g., select the first forwarding table entry that matches). A forwarding table entry includes a specific set of match criteria (a set of values or wildcards, or an indication of what part of the packet should be compared to a specific value / multiple values / wildcards, as defined by the matching capabilities - for a specific field in the packet header, or for some other packet content), and a set of one or more actions that the data plane is to take when receiving a matching packet. For example, for a packet using a specific port, the action could be to push a header onto the packet, flood the packet, or simply discard the packet. Thus, a forwarding table entry for an IPv4 / IPv6 packet with a specific Transmission Control Protocol (TCP) destination port could include an action specifying that these packets should be discarded.

[0100] Based on the forwarding table entry identified during packet classification, a forwarding decision is made and actions are executed by performing the set of actions identified in the matching forwarding table entry for the packet.

[0101] However, when an unknown packet (e.g., a "missed packet" or "match-miss" as used in OpenFlow parlance) arrives at the data plane 680, the packet (or a subset of the packet header and content) is typically forwarded to the centralized control plane 676. The centralized control plane 676 then programs the forwarding table entry into the data plane 680 to accommodate packets belonging to the unknown packet flow. Once a specific forwarding table entry has been programmed by the centralized control plane 676 into the data plane 680, the next packet with a matching credential will match that forwarding table entry and take the set of actions associated with that matching entry.

[0102] A network interface (NI) can be physical or virtual; and in the context of IP, the interface address is the IP address assigned to the NI, whether it is a physical NI or a virtual NI. A virtual NI can be associated with a physical NI, with another virtual interface, or exist independently (e.g., loopback interface, Point-to-Point Protocol interface). An NI (physical or virtual) can be numbered (NI with an IP address) or unnumbered (NI without an IP address). A loopback interface (and its loopback address) is a specific type of virtual NI (and IP address) of a NE / VNE (physical or virtual) that is often used for administrative purposes; where such an IP address is called a node loopback address. The (one or more) IP addresses of the (one or more) NIs assigned to an ND are called the IP address of that ND; at a coarser granularity level, the (one or more) IP addresses of the (one or more) NIs assigned to the NE / VNEs implemented on an ND can be called the IP address of that NE / VNE.

[0103] Some portions of what has been described in detail previously have been presented in terms of symbolic representations and algorithms of transactions on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing art to most effectively convey the substance of their work to other technicians in the art. An algorithm is here, and generally, considered to be a consistent sequence of transactions leading to a desired result. Transactions are those that require physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. Primarily for reasons of common usage, it is sometimes convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc.

[0104] However, it should be borne in mind that all such and similar terms are to be associated with appropriate physical quantities and are merely convenient labels applied to these quantities. Unless otherwise stated, it is evident from the above discussion that, throughout the description, discussions using terms such as "processing" or "computing" or "figuring out" or "determining" or "displaying" refer to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the registers and memories of the computer system into other data similarly represented as physical quantities within the memories or registers or other such information storage devices, transmission, or display devices of the computer system.

[0105] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general-purpose systems may be used with the programs in accordance with the teachings herein, or it may prove convenient to construct more specialized devices to perform the required method operations. From the above description, the required structure for a variety of these systems will be apparent. In addition, the embodiments are described without reference to any specific programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the embodiments described herein.

[0106] The embodiments may be articles of manufacture wherein a non-transitory machine-readable storage medium (such as a microelectronic memory) stores instructions (e.g., computer code) thereon that program one or more data processing components (collectively referred to herein as "processors") to perform the operations described above. In other embodiments, some of these operations may be performed by specific hardware components that include hardwired logic (e.g., dedicated digital filter blocks and state machines). Alternatively, those operations may be performed by any combination of programmed data processing components and fixed hardwired circuit components.

[0107] Throughout the description, embodiments have been presented by way of flowcharts. It will be appreciated that the order and operations described in these flowcharts are intended for illustrative purposes only and are not intended as a limitation on the present invention. Those of ordinary skill in the art will recognize that changes may be made to the flowcharts without departing from the broader spirit and scope of the present invention as set forth in the following claims.

[0108] In the foregoing specification, embodiments have been described with reference to their specific exemplary embodiments. It will be apparent that various modifications may be made thereto without departing from the broader spirit and scope of the present invention as set forth in the following claims. The specification and drawings are accordingly to be regarded in an illustrative sense rather than a restrictive sense.

Claims

1. A method for a network device acting as a Provider Edge (PE) in an Ethernet Virtual Private Network (EVPN) to prevent transient loops between multi-homed peer PEs, the method comprising: Advertising (510) a first EVPN label to one or more PEs that are multi-homed peer PEs of the PE, where PEs are multi-homed peer PEs relative to each other if they provide connectivity to the same Customer Edge (CE) in the same EVPN instance; Advertising (520) a second EVPN label to one or more PEs that are not multi-homed peer PEs of the PE; Receiving (530) a first service for the CE encapsulated with the first EVPN label instead of the second EVPN label; and Dropping (560) the first service in response to determining that the link between the PE and the CE is inoperable and the first service for the CE is encapsulated with the first EVPN label, wherein the first EVPN label is advertised using a BGP advertisement message, wherein the BGP advertisement message indicates a route associated with the first EVPN label.

2. The method according to claim 1, further comprising: Receiving (530) a second service for the CE encapsulated with the second EVPN label instead of the first EVPN label; and Forwarding (580) the second service to a multi-homed peer PE of the PE in response to determining that the link between the PE and the CE is inoperable and the second service for the CE is encapsulated with the second EVPN label.

3. The method according to claim 2, further comprising: Receiving (530) a third service for the CE; and Forwarding (550) the third service for the CE to the CE in response to determining that the link between the PE and the CE is operable, regardless of whether the third service is encapsulated with the first EVPN label or the second EVPN label.

4. The method according to claim 1, wherein The route is an Ethernet Auto-Discovery route or a Media Access Control / Internet Protocol (MAC / IP) advertisement route per EVPN instance route.

5. The method according to claim 4, wherein, The BGP advertisement message indicates a group identifier associated with the route and an EVPN instance associated with the route, wherein an Ethernet Segment Incoming Route Target extended community field included in the BGP advertisement message is used to indicate the group identifier associated with the route, and an EVI-RT extended community field included in the BGP advertisement message is used to indicate the EVPN instance associated with the route.

6. The method according to claim 5, wherein, The BGP advertisement message indicates a preference level associated with the route, wherein the local preference field included in the BGP advertisement message is used to indicate the preference level associated with the route, and wherein when both the first EVPN label and the second EVPN label are advertised to a multi-homed peer PE of the PE, the preference level associated with the route associated with the first EVPN label is higher than the preference level associated with the route associated with the second EVPN label.

7. The method according to claim 1, wherein The first EVPN label is a Multiprotocol Label Switching (MPLS) label.

8. The method according to claim 1, wherein The first EVPN label is a Virtual Extensible Local Area Network (VxLAN) Network Identifier (VNI).

9. The method according to claim 1, wherein, Due to a failure of the CE or the PE, the link to the CE is inoperable.

10. A non-transitory machine-readable storage medium providing instructions which, if executed by a processor of a network device acting as a Provider Edge (PE) in an Ethernet Virtual Private Network (EVPN), will cause the network device to perform operations for preventing transient loops between multi-homed peer PEs, the operations including: Advertising (510) a first EVPN label to one or more PEs that are multi-homed peer PEs of the PE, where PEs are multi-homed peer PEs with respect to each other if they provide connectivity to the same Customer Edge (CE) in the same EVPN instance; Advertising (520) a second EVPN label to one or more PEs that are not multi-homed peer PEs of the PE; Receiving (530) first traffic for the CE encapsulated with the first EVPN label instead of the second EVPN label; and Dropping (570) the first traffic in response to determining that the link between the PE and the CE is inoperable and the first traffic for the CE is encapsulated with the first EVPN label, wherein the first EVPN label is advertised using a BGP advertisement message, wherein the BGP advertisement message indicates a route associated with the first EVPN label.

11. The non-transitory computer-readable medium according to claim 10, wherein, The operations further include: Receiving (530) second traffic for the CE encapsulated with the second EVPN label instead of the first EVPN label; and Forwarding (580) the second traffic to a multi-homed peer PE of the PE in response to determining that the link between the PE and the CE is inoperable and the second traffic for the CE is encapsulated with the second EVPN label.

12. The non-transitory machine-readable storage medium according to claim 10, wherein, The route is an Ethernet Auto-Discovery route or a Media Access Control / Internet Protocol (MAC / IP) advertisement route per EVPN instance.

13. The non-transitory machine-readable storage medium according to claim 12, wherein, The BGP advertisement message indicates a multi-homing peer group associated with the route and an EVPN instance associated with the route, wherein the Ethernet segment ingress route target extended community field included in the BGP advertisement message is used to indicate the multi-homing peer group associated with the route, and the EVI-RT extended community field included in the BGP advertisement message is used to indicate the EVPN instance associated with the route.

14. The non-transitory machine-readable storage medium according to claim 13, wherein, The BGP advertisement message indicates a preference level associated with the route, wherein the local preference field included in the BGP advertisement message is used to indicate the preference level associated with the route, and wherein when both the first EVPN label and the second EVPN label are advertised to a multi-homing peer PE of the PE, the preference level associated with the route associated with the first EVPN label is higher than the preference level associated with the route associated with the second EVPN label.

15. A network device (604) acting as a provider edge (PE) in an Ethernet virtual private network (EVPN) to prevent transient loops between multi-homing peer PEs, the network device comprising: A set of one or more processors (642); And A non-transitory machine-readable storage medium (648) that provides instructions that, if executed by the set of one or more processors, will cause the network device to: Advertise a first EVPN label to one or more PEs that are multi-homing peer PEs of the PE, where PEs are multi-homing peer PEs with respect to each other if they provide connectivity to the same customer edge (CE) in the same EVPN instance; Advertise a second EVPN label to one or more PEs that are not multi-homing peer PEs of the PE; Receive first traffic for the CE encapsulated with the first EVPN label rather than the second EVPN label; and Discard the first traffic in response to determining that the link between the PE and the CE is inoperable and that the first traffic for the CE is encapsulated with the first EVPN label, Wherein the first EVPN label is advertised using a BGP advertisement message, Wherein the BGP advertisement message indicates a route associated with the first EVPN label.

16. The network device according to claim 15, wherein, The non-transitory machine-readable storage medium provides additional instructions that, if executed by the set of one or more processors, will cause the network device to: receive second traffic for the CE encapsulated with the second EVPN label rather than the first EVPN label; And Forward the second traffic to a multi-homing peer PE of the PE in response to determining that the link between the PE and the CE is inoperable and that the second traffic for the CE is encapsulated with the second EVPN label.

17. The network device according to claim 15, wherein, The route is an Ethernet auto-discovery route or a media access control / Internet protocol (MAC / IP) advertisement route per EVPN instance.

18. The network device according to claim 17, wherein, The BGP advertisement message indicates a multi-homed peer group associated with the route and an EVPN instance associated with the route, wherein the multi-homed peer group associated with the route is indicated using an Ethernet segment ingress route target extended community field included in the BGP advertisement message, and the EVPN instance associated with the route is indicated using an EVI-RT extended community field included in the BGP advertisement message.

19. The network device according to claim 15, wherein, The first EVPN label is a Multiprotocol Label Switching (MPLS) label.

Images