Loop prevention for EVPN and PBB-EVPN

In general, techniques are described for reducing forwarding loops for layer (L2) traffic that traverses an EVPN or PBB-EVPN instance (EVI) by deterministically determining an access-facing logical interface to block from respective access-facing logical interfaces of PE devices that switch the L2 traffic using the EVI. A provider edge (PE) network device may detect an L2 forwarding loop on an L2 forwarding path that includes the access-facing logical interface. In response to detecting an L2 forwarding loop and based at least on comparing an identifier for the local PE device and an identifier for a remote PE device that implements the EVPN instance, the PE device may block the access-facing logical interface to block L2 traffic from the local customer network.

TECHNICAL FIELD

The invention relates to computer networks and, more specifically, to forwarding packets within computer networks.

BACKGROUND

A computer network is a collection of interconnected computing devices that can exchange data and share resources. Example network devices include switches or other layer two devices that operate within the second layer (L2) of the Open Systems Interconnection (OSI) reference model, i.e., the data link layer, and routers or other layer three (L3) devices that operate within the third layer of the OSI reference model, i.e., the network layer. Network devices within computer networks often include a control unit that provides control plane functionality for the network device and forwarding components for routing or switching data units.

An Ethernet Virtual Private Network (EVPN) may be used to extend two or more remote layer two (L2) customer networks through an intermediate layer three (L3) network (usually referred to as a provider network), in a transparent manner, i.e., as if the intermediate L3 network does not exist. In particular, the EVPN transports L2 communications, such as Ethernet packets or “frames,” between customer networks via traffic engineered label switched paths (LSP) through the intermediate network in accordance with one or more multiprotocol label switching (MPLS) protocols. In a typical configuration, provider edge (PE) devices (e.g., routers and/or switches) coupled to the customer edge (CE) network devices of the customer networks define label switched paths (LSPs) within the provider network to carry encapsulated L2 communications as if these customer networks were directly attached to the same local area network (LAN). In some configurations, the PE devices may also be connected by an IP infrastructure in which case IP/GRE tunneling or other IP tunneling can be used between the network devices.

In an EVPN, L2 address learning (also referred to as “MAC learning”) on a core-facing interface of a PE device occurs in the control plane rather than in the data plane (as happens with traditional bridging) using a routing protocol. For example, in EVPNs, a PE device typically uses the Border Gateway Protocol (BGP) (i.e., an L3 routing protocol) to advertise to other provider edge network devices the MAC addresses the PE device has learned from the local consumer edge network devices to which the PE device is connected. As one example, a PE device may use a BGP route advertisement message to announce reachability information for the EVPN, where the BGP route advertisement specifies one or more MAC addresses learned by the PE device instead of L3 routing information. Additional example information with respect to EVPN is described in “BGP MPLS-Based Ethernet VPN,” Request for Comments (RFC) 7432, Internet Engineering Task Force (IETF), February, 2015, the entire contents of which are incorporated herein by reference.

A Provider Backbone Bridged Ethernet Virtual Private Network (PBB-EVPN) combines EVPN services with MAC-in-MAC encapsulation when transporting L2 communications. That is, a customer frame transported through the PBB-EVPN has MAC-in-MAC encapsulation in which customer MAC (C-MAC) addresses within the header are encapsulated within backbone MAC (B-MAC) addresses, thereby maintaining separation between the provider L2 domain and the customer L2 domain. In PBB-EVPN, PEs distribute reachability information for B-MAC addresses associated with local Ethernet segments using EVPN route advertisements, and remote PEs receive encapsulated customer frames and learn, via the data plane, the C-MAC addresses in association with the remote B-MACs for traffic. Additional example information with respect to PBB-EVPN is described in “Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN),” Request for Comments (RFC) 7623, Internet Engineering Task Force (IETF), September, 2015, the entire contents of which are incorporated herein by reference.

SUMMARY

In general, techniques are described for reducing forwarding loops for layer (L2) traffic that traverses an EVPN or PBB-EVPN instance (EVI) by deterministically determining an access-facing logical interface to block from respective access-facing logical interfaces of PE devices that switch the L2 traffic using the EVI. For example, multiple PE devices of a layer 3 (L3) network may be configured to provide an EVI for L2 virtual bridge connectivity across the L3 network among customer networks attached to the PE devices. A local PE device that serves a local Ethernet segment for the EVI may have an access-facing interface (or “attachment circuit”) configured for exchanging L2 traffic with devices of the local Ethernet segment. The local PE device may also have a core-facing interface configured for exchanging L2 traffic with remote PE devices for the EVI. The local PE device may receive an identifier for a remote PE device, such as a loopback Internet Protocol (IP) address or a backbone MAC (B-MAC) address associated with an Ethernet segment for the EVI and served by the remote PE device.

In response to detecting an L2 forwarding loop in a forwarding path that includes the access-facing interface and the core-facing interface, the local PE device may compare the identifier for the remote PE device for the core-facing interface with an identifier for the local PE device. Based on the comparison, the local PE device may block the access-facing interface to block looped L2 traffic from the EVI. Because the remote PE device may perform a substantially similar operation to compare the identifier for the local PE device and the identifier for the remote PE device, the remote PE device may determine to keep the access-facing interface for the remote PE device active (i.e., not blocked).

In some cases, the identifiers for PE devices on which the comparison is based are IP or B-MAC addresses of the PE devices. For example, in an EVPN, the local PE device may determine a lower one of respective loopback addresses of the local and remote PE devices. In a PBB-EVPN, the local PE device may determine a lower one of respective B-MAC addresses of core-facing interfaces of the local and remote PE devices. The local PE device may block its access-facing logical interface in response to determining the local PE device is associated with the lower identifier.

In this way, the techniques described in this disclosure enable PE devices in an EVPN or PBB-EVPN to deterministically determine whether to block logical ports for the EVI to ensure that packets are not forwarded back toward a customer network across the core via the EVI. Because each PE device of the EVI independently determines whether to block its access-facing logical interface without exchanging communication, the techniques may reduce overhead for customers in identifying/tracking looped logical ports and blocking logical ports to eliminate loops. In addition, by simply manipulating the identifiers for the PE devices in an EVI, a customer may pre-determine access-facing interface blocking priority among the various PE devices to facilitate customer goals for L2 traffic delivery.

In one example, a method includes detecting, by a local provider edge (PE) device that implements an Ethernet Virtual Private Network (EVPN) instance to provide layer 2 (L2) bridge connectivity for a local customer network using an access-facing logical interface, an L2 forwarding loop on an L2 forwarding path that includes the access-facing logical interface; and blocking, by the local PE device in response to the detecting and based at least on comparing an identifier for the local PE device and an identifier for a remote PE device that implements the EVPN instance and is logically located on the L2 forwarding path, the access-facing logical interface to block L2 traffic from the local customer network.

In another example, a network device includes one or more processors operably coupled to a memory, a routing engine configured for execution by the one or more processors to implement an Ethernet Virtual Private Network (EVPN) instance to provide layer 2 (L2) bridge connectivity for a local customer network using an access-facing logical interface; a loop detection module configured for execution by the one or more processors to detect an L2 forwarding loop on an L2 forwarding path that includes the access-facing logical interface; and a blocking module configured for execution by the one or more processors to block, based at least on comparing an identifier for the network device and an identifier for a remote network device that implements the EVPN instance and is logically located on the L2 forwarding path, the access-facing logical interface to block L2 traffic from the local customer network.

In another example, a system includes a local provider edge (PE) device of an intermediate layer 3 network, the local PE device configured to implement an Ethernet Virtual Private Network (EVPN) instance that is configured on the local PE device to provide layer 2 (L2) bridge connectivity to a local customer network via an access-facing logical interface of the local PE device; a remote PE device of the intermediate layer 3 network, the remote PE device configured to implement the EVPN instance that is configured on the remote PE device to provide layer 2 (L2) bridge connectivity for a remote customer network via an access-facing interface of the remote PE device, wherein the local PE device is configured to detect an L2 forwarding loop on an L2 forwarding path that includes the access-facing interface of the local PE device and to block, in response to the detection and based at least on comparing an identifier for the local PE device and an identifier for the remote PE device, the access-facing interface of the local PE device to block L2 traffic from the local customer network, and wherein the remote PE device is configured to detect the L2 forwarding loop and to not block, in response to the detection and based at least on comparing the identifier for the local PE device and the identifier for the remote PE device, the access-facing interface of the remote PE device to continue forwarding L2 traffic from the remote customer network.

Like reference characters denote like elements throughout the figures and text.

DETAILED DESCRIPTION

FIG. 1is a block diagram illustrating an example network system2in which provider edge (PE) network devices within an Ethernet Virtual Private Network (EVPN) deterministically determine an access-facing logical interface to block for loop avoidance, according to techniques described herein. In the example ofFIG. 1, provider edge (PE) devices10A,10B (“PEs10”) provide customer endpoints4A-4C (“endpoints4”) associated with customer networks6A,6B (“customer networks6”) with access to an intermediate layer 3 (L3) network12(“intermediate network12”) via customer edge (CE) devices8A,8B (“CEs8”). PEs10may represent other types of PE devices capable of performing PE operations for an Ethernet Virtual Private Network (EVPN).

PEs10and CEs8may each represent a router, switch, or other suitable network devices that participates in a layer two (L2) virtual private network (VPN) (L2VPN) service, such as an EVPN. Customer networks6may be networks for geographically or logically separated sites of an enterprise or may represent networks for different customers of the intermediate network12(or tenants of a data center intermediate network). Each of endpoints4may represent one or more non-edge switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection, and/or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other network devices. The configuration of network2illustrated inFIG. 1is merely an example. For example, an enterprise may include any number of customer networks6. Nonetheless, for ease of description, only customer networks6A,6B are illustrated inFIG. 1.

Intermediate network12may represent a service provider network that is owned and operated by a service provider, which is usually large telecommunications entity or corporation. Intermediate network12represents an L3 computer network, where reference to a layer followed by a number refers to a corresponding layer in the Open Systems Interconnection (OSI) model. Intermediate network12is a L3 network in the sense that it natively supports L3 operations as described in the OSI model. Common L3 operations include those performed in accordance with L3 protocols, such as the Internet protocol (IP). L3 is also known as a “network layer” in the OSI model and the “IP layer” in the TCP/IP model, and the term L3 may be used interchangeably with the and “network layer” and “IP” throughout this disclosure.

Although not illustrated, intermediate network12may be coupled to one or more networks administered by other providers, and may thus form part of a large-scale public network infrastructure, e.g., the Internet. Consequently, customer networks6may be viewed as edge networks of the Internet where the intermediate network is a service provider network. Intermediate network12may provide computing devices within customer networks6with access to the Internet, and may allow the computing devices within the customer networks to communicate with each other. In some cases, intermediate network12represents a data center L2/L3 switching fabric (or “data center fabric network”) that interconnects CEs for tenants of the data center, where a tenant may represent an organization or a logical partitioning of resources, data, and/or applications within the data center.

Although additional network devices are not shown for ease of explanation, it should be understood that system2may comprise additional network and/or computing devices such as, for example, one or more additional switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection, and/or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other network devices. Moreover, although the elements of system2are illustrated as being directly coupled, it should be understood that one or more additional network elements may be included along any of the illustrated links15A,15B,16A,16B, and16C, such that the network elements of system2are not directly coupled.

Intermediate network12may provide a number of residential and business services, including residential and business class data services (which are often referred to as “Internet services” in that these data services permit access to the collection of publically accessible networks referred to as the Internet), residential and business class telephone and/or voice services, and residential and business class television services. One such business class data service offered by a service provider intermediate network12includes L2 EVPN service. Intermediate network12that represents an L2/L3 switch fabric for one or more data centers may implement an L2 EVPN service. An EVPN is a service that provides a form of L2 connectivity across an intermediate L3 network, such as intermediate network12, to interconnect two or more L2 customer networks, such as L2 customer networks6, that may be located in different geographical areas (in the case of service provider network implementation) and/or in different racks (in the case of a data center implementation). Often, EVPN is transparent to the customer networks in that these customer networks are not aware of the intervening intermediate network and instead act and operate as if these customer networks were directly connected and form a single L2 network. In a way, EVPN enables a form of a transparent LAN connection between two customer sites that each operates an L2 network and, for this reason, EVPN may also be referred to as a “transparent LAN service.”

To configure an EVPN, a network operator of the intermediate network12configures, via configuration or management interfaces, various devices included within intermediate network12that interface with L2 customer networks6. The EVPN configuration may include an EVPN instance (EVI), which comprises of one or more broadcast domains. Generally, an EVI may be associated with a virtual routing and forwarding instance (VRF), e.g., VRFs13A,13B (“VRFs13”), on a PE device, such as any of PEs10A,10B. Consequently, multiple EVIs may be configured on PEs10for Ethernet segments14A-14B (“Ethernet segments14”), each providing a separate, logical layer two (L2) or layer three (L3) forwarding domain. In this way, multiple EVIs may be configured that each includes one or more of PEs10. In some examples, Ethernet Tags are then used to identify a particular broadcast domain, e.g., a VLAN, in an EVI. A PE device may advertise an MPLS service label (or “MAC label,” “MAC route label,” or more simply “label”) per-<ESI, Ethernet Tag> combination. This label assignment methodology is referred to as a per-<ESI, Ethernet Tag> label assignment. Alternatively, a PE device may advertise a unique label per MAC address. In still another example, a PE device may advertise the same single label for all MAC addresses in a given EVI. This label assignment methodology is referred to as a per-EVI label assignment. Such labels are advertised by PEs10in EVPN MAC advertisement routes.

In the example ofFIG. 1, an EVPN instance (EVI)3is configured within intermediate network12for customer networks6to enable customer networks6to communicate with one another via EVPN as if customer networks6were directly connected via an L2 network. In this example, EVI3spans PE devices10A,10B participating in the EVI3. Each of PEs10is configured with EVI3and exchanges EVPN routes to implement EVI3.

For example, in typical operation, PEs10communicate using the Border Gateway Protocol (BGP) to transport BGP Network Layer Reachability Information (NLRI) for the EVPN and may define different EVPN route types for conveying EVPN information via the BGP routing protocol. The EVPN NLRI is typically carried in BGP using BGP Multiprotocol Extensions. An Ethernet segment route advertised by each of PEs10using BGP includes a Route Distinguisher and Ethernet Segment Identifier. An Ethernet AD route advertised by each PE devices6for each EVI, specifies a Route Distinguisher (RD) (which may include, e.g., an IP address of the PE), ESI, Ethernet Tag Identifier, and MPLS label. Subsequent BGP media access control (MAC) routes output by PEs10announce MAC addresses of endpoints4for the EVPN and include a RD, ESI, Ethernet Tag Identifier, MAC address and MAC address length, IP address and IP address length, and MPLS label.

In the example ofFIG. 1, when providing the EVPN service to customer networks6, PEs10and CEs8perform MAC address learning to efficiently forward L2 network communications in system2. That is, as PEs10and CEs8forward Ethernet frames, the routers learn L2 state information for the L2 network, including MAC addressing information on access-facing logical interfaces17A,17B (“access-facing logical interfaces17”) and core-facing logical interfaces18A,18B (“core-facing logical interfaces18”). Access-facing logical interfaces17are customer edge-facing attachment circuits of PEs10that are connected to CEs8to process customer frames or packets at Layer 2 or above. Access-facing logical interfaces17process customer frames or packets at Layer 2 or above for CEs8in named VRFs13belonging to EVI3. Core-facing logical interfaces18for EVI3provide interfaces for transmitting to or receiving from a tunnel (e.g., GRE IPv4) connecting to other PE devices belonging to EVI3of intermediate network12.

PEs10and CEs8typically store the MAC addressing information in MAC tables associated with respective interfaces, such as access-facing logical interfaces17and core-facing logical interfaces18. When forwarding an individual Ethernet frame received on one interface, a router typically broadcasts the Ethernet frame to all other interfaces associated with the EVPN unless the router has previously learned the specific interface through which the destination MAC address specified in the Ethernet frame is reachable. In this case, the router forwards a single copy of the Ethernet frame out the associated interface.

Moreover, as PEs10learn the source MAC address for endpoints4reachable through local access-facing logical interfaces17, PEs10use MAC address route advertisements of a layer three (L3) routing protocol (e.g., BGP) to share the learned MAC addresses and to provide an indication that the MAC addresses are reachable through the particular PE device10that is issuing the route advertisement. In the EVPN implemented using PEs10for EVI3, each of PEs10advertises the locally learned MAC addresses to other PEs10in intermediate network12using BGP route advertisements, also referred to herein as a “MAC route,” “MAC Advertisement route,” or “MAC Advertisement.” The other PEs10may remotely learn the source MAC addresses on core-facing logical interfaces18associated with EVI3. A MAC route typically specifies an individual MAC address of an endpoint4along with additional forwarding information, such as a route descriptor, route target, layer 2 segment identifier, MPLS label, etc. In this way, PE routers10use BGP to advertise and share the MAC addresses learned when forwarding layer two communications associated with the EVPN. Accordingly, PEs10may perform both local learning and remote learning of source MAC addresses.

Each of PEs10uses MAC routes specifying the MAC addresses learned by other PE devices to determine how to forward L2 communications to MAC addresses that belong to endpoints4connected to other PEs, i.e., to remote CEs and/or endpoints behind CEs operatively coupled to PE devices. That is, each of PEs10determines whether Ethernet frames can be sent directly to a particular one of the other PEs10or whether to treat the Ethernet frames as so called “BUM” traffic (Broadcast, Unidentified unicast or Multicast traffic) that is to be flooded within the EVPN based on the MAC addresses learning information received from the other PE devices.

As shown inFIG. 1, CE8A is coupled to PEs10A via link15A. PE10A may configure an EVPN instance, such as EVI3, for Ethernet segment14A to provide L2 communications between CE8A and PE10A. Thus, PE10A is capable of providing access to EVPN for L2 customer network6A via CE8A. EVI3may operate over a Multi-Protocol Label Switching (MPLS) configured network and use MPLS labels to forward network traffic accordingly. MPLS is a mechanism used to engineer traffic patterns within Internet Protocol (IP) networks according to the routing information maintained by the routers in the networks. By utilizing MPLS protocols, such as the Label Distribution protocol (LDP) or the Resource Reservation Protocol with Traffic Engineering extensions (RSVP-TE), a source device can request a path through a network to a destination device, i.e., a Label Switched Path (LSP). An LSP defines a distinct path through the network to carry MPLS packets from the source device to a destination device. Using an MPLS protocol, each router along an LSP allocates a label and propagates the label to the closest upstream router along the path. Routers along the path add or remove the labels and perform other MPLS operations to forward the MPLS packets along the established path.

As shown in the example ofFIG. 1, intermediate network12may provide an MPLS core or IP tunneling infrastructure for sending network packets from customer network6A to and from customer network6B. Each of PEs10implement the MPLS protocol and apply one or more MPLS labels, i.e., a label stack, to network packets in accordance with routing and forwarding information configured at each respective PE device.

As shown inFIG. 1, PEs10include respective VRFs13A,13B for EVI3that includes customer networks6. Generally, VRFs permits multiple routing tables to exist within a single physical router. Access-facing logical interface17A may be associated with VRF13A, and VRF13A may be configured to forward traffic for the attachment circuit for EVI3. VRFs13may be configured to include functionality described in “BGP/MPLS IP Virtual Private Networks (VPNs),” February 2006, https://tools.ietf.org/html/rfc4364, which is hereby incorporated by reference herein in its entirety.

As noted above, PE10A locally learns MAC addresses for customer endpoints4reachable via access-facing logical interface17A. In some cases, PE devices may learn the IP addresses associated with respective MAC addresses in the control or management plane between the CEs8and the PEs10. As used hereinafter, a “MAC/IP binding” refers to an association between a MAC address and an IP address for a customer endpoint4. When PE10A learns the MAC address of locally connected customer endpoint4A, PE10A may advertise the locally learned MAC address to other PE devices10by including it in a MAC Advertisement route. PE10B may receive the MAC Advertisement route from a tunnel connecting to PE10A belonging to EVI3of intermediate network12. PE10B may remotely learn MAC addresses for customer endpoint4A via core-facing logical interface18A.

In some examples, due to misconfiguration of any one or more of PEs10, CEs8; or due to duplicate L2 addresses for endpoint devices4behind different PEs10; an L2 forwarding loop between PE10B and CE8B on Ethernet segment14B may occur such that PE10B receives packets having source MAC addresses that match the MAC address of endpoint4A on both core-facing logical interface18A and access-facing logical interface17B. For instance, having already remotely learned the MAC address for endpoint4A at core-facing logical interface18A, PE10B may subsequently learn the MAC address for endpoint4A on access-facing logical interface17B. This may occur because CE8B hairpins at least one packet having a source MAC address that matches the MAC address of endpoint4A due to a routing configuration or learned route or because another L2 device, e.g., endpoint4B of Ethernet segment14B, is configured with a same MAC address as endpoint4A and sends at least one packet having the source MAC address that is the MAC address. In some situations, L2 forwarding loops may occur for reasons other than those listed above.

When a source MAC address, e.g., MAC address for endpoint4A, is received on a different physical or logical interface of an L2 switching device such as PE device10B, the L2 switching device performs a MAC address move or “MAC move.” As a result of a MAC move for a MAC address from a previous interface to a new interface, the L2 switching device forwards L2 packets destined to the MAC address via the new interface. In the example ofFIG. 1, due to the forwarding loop described above, the MAC address for endpoint4A may move from core interface18A to access-facing logical interface17B and back as each of these interfaces alternate, in time, receiving packets having source MAC addresses that match the L2 address for endpoint4A.

To detect L2 forwarding loops, PE10B may configure a loop detection threshold based on the number of times a MAC address move occurs over time, a specified period of time over which the MAC address move occurs, or a specified number of times a MAC address move occurs, for instance. As one example, PE10B may be configured with a loop detection threshold that indicates a L2 forwarding loop based on detecting 5 MAC address moves between different interfaces of PE10B in a span of 30 seconds. Upon reaching the loop detection threshold, PE devices10may in some cases block a corresponding one of access-facing logical interfaces17to block L2 traffic from the local customer network. In the example ofFIG. 1, upon the detection of L2 forwarding loop on Ethernet segment14B, PE10B may block access-facing logical interface17B from receiving L2 traffic from local customer network6B via CE8B. That is, PE10B will not forward L2 traffic received on blocked access-facing logical interface17B.

In accordance with techniques of this disclosure, any of PE devices10may deterministically determine whether to block its access-facing logical interface for EVI3from forwarding L2 EVPN traffic from the local customer network based on a comparison of an identifier of a local PE device and an identifier for a remote PE device of EVI3. As one example, an identifier may be a loopback IP address, e.g., a corresponding IP (IPv4/IPv6) address configured for each of PE devices10. For example, in response to detecting an L2 forwarding loop on an L2 forwarding path that includes core-facing interface18A and access facing interface17B of PE10B for EVI3, PE10B may compare a local loopback IP address of PE10B with a remote loopback IP address of PE10A and, based on the comparison, PE10B may block (or not block) access-facing logical interface17B. In some examples, if the local loopback IP address of PE10B is lower than the remote loopback IP address of PE10A, PE10B may block access-facing logical interface17B to block L2 traffic from customer network6B. In this way, a forwarding loop between PE10B and CE8B is avoided for subsequent L2 traffic. PE10B may obtain the remote loopback IP address of PE10A in an EVPN MAC/IP advertisement route (EVPN Route Type2), where the PE10A originates the EVPN MAC/IP advertisement route by which the PE10B learns a MAC address on core-facing interface18A. The MAC address may be the L2 address for which PE10B has identified the L2 forwarding loop. The identifier for PE10A may be included in an ORIGIN attribute of a BGP UPDATE message for the EVPN MAC/IP advertisement route, for instance.

PE10A may also detect the L2 forwarding loop detected by PE10B and perform the operation described above to determine whether to block access-facing logical interface17A for EVI3. For example, PE10B may forward L2 traffic to PE10A of EVI3that is logically located on the L2 forwarding path. Having already learned the MAC address for endpoint4A at access-facing logical interface17A, PE10A may subsequently learn the MAC address of endpoint4A on core-facing logical interface18B, e.g., via an EVPN MAC/IP advertisement route originated by PE10B. As described above, because MAC address information for endpoint4A appears on a different interface of PE10A, the MAC address moves from access-facing logical interface17A to core-facing logical interface18B and back as each of these interfaces alternate, in time, receiving packets having source MAC addresses that match the L2 address for endpoint4A. In response to detecting an L2 forwarding loop, PE10A may compare a local loopback IP address for PE10A with a remote loopback IP address of PE10B learned at core-facing logical interface18B of EVI3that is logically located on the L2 forwarding path, and, based on the comparison, PE10A may block (or not block) access-facing logical interface17A. If the remote loopback IP address of PE10A is lower than the local loopback IP address of PE10B, then PE10A may block access-facing logical interface17A of PE10A to block L2 traffic from customer network6A.

Because PE10A and10B have different identifiers that serve as the basis for the determination to block an access interface for EVI3in response to detecting an L2 forwarding loop, and because PE10A and10B use each other's identifier as the remote identifier, the same operation performed by PE10A and10B will cause each of the PEs to determine a different result. That is, only one of PEs10A,10B will determine to block its associated access-facing logical interface17for EVI3(and will block the interface), and one of PEs10A,10B will determine not to block its associated access-facing logical interface17for EVI3(and will not block the interface). In this way, PE devices10may deterministically determine which access-facing logical interface17to block in order to eliminate an L2 forwarding loop in the EVI, while leaving the other access-facing logical interface17. The respective determinations by PEs10may be independently performed without the PEs10exchanging communications to determine which of access-facing logical interfaces17is to be blocked.

The techniques may thus reduce overhead for customers in identifying/tracking looped logical ports and blocking logical ports to eliminate loops. In addition, by simply manipulating the identifiers for the PEs10in an EVI3, a customer may pre-determine which of access-facing logical interfaces17has blocking priority to facilitate customer goals for L2 traffic delivery.

FIG. 2is a block diagram illustrating an example network system200in which provider edge (PE) devices within a Provider Backbone Bridged Ethernet Virtual Private Network (PBB-EVPN) deterministically determine an access-facing logical interface to block for loop avoidance, according to techniques described herein. Network system200ofFIG. 2is similar to the network system2ofFIG. 1except as described below.

In the example ofFIG. 2, provider edge devices210A,210B (“PEs210”) are coupled to customer edge devices208A,208B (“CEs208”) by respective Ethernet links215A,215B that constitutes Ethernet segments214A,214B (“Ethernet segments214”), each providing a separate, logical layer two (L2) or layer three (L3) forwarding domain for customer networks206A-206C (“customer networks206”). PBB-EVPN provides customer networks206a bridging service for transporting frames in a “transparent” manner as if customer network206were directly connected via an L2 network.

PBB-EVPN combines EVPN with Provider Backbone Bridging (PBB) defined in accordance with IEEE standard 802.1ah. PBB, otherwise known as MAC-in-MAC, extends EVPN layer two (L2) switching to provide customer networks206a backbone network to bridge customer networks206by encapsulating a PBB header to customer traffic and forwarding the frames over intermediate network212. An egress PE device, e.g., PE210B, removes the PBB header and the original customer traffic is delivered to endpoint204B. That is, PBB-EVPN provides MAC tunneling of customer MAC (“C-MAC”) addresses for endpoints204A-204C (“endpoints204”) learned in the data plane via normal bridging operation. Unlike with standard EVPN, PEs210learn C-MAC addresses for endpoints204on core-facing interfaces218in the data plane but learn B-MAC addresses in the control plane via EVPN routes.

In the example ofFIG. 2, PBB-EVPN instance203(“EVI203”) is configured within intermediate network212for customer networks206to enable customer networks206to communicate with one another via PBB-EVPN as if customer networks206were directly connected via an L2 network. In this example, EVI203spans PE devices210A,210B participating in the EVI203. Each of PEs210is configured with EVI203and exchanges PBB-EVPN routes to implement EVI203.

PE210A may locally learn a C-MAC address associated with endpoint204A via a data plane via normal bridging operation from access-facing logical interface217A. PE210A may encapsulate customer traffic received from customer network206A with a PBB header for forwarding the traffic over intermediate network212. For example, PEs210include Backbone Edge Bridges233A,233B (“BEBs233”) associated with backbone-facing (i.e., core-facing) logical interfaces218A,218B (“core-facing logical interfaces218”) of PEs210for exchanging PBB-EVPN routes. PE210A may operate as BEB233A to provide an interface that encapsulates the customer traffic received from an attachment circuit (e.g., access-facing logical interface217A,217B) with a PBB header for forwarding over intermediate network212.

Each of PEs210is associated with one or more Provider Backbone MAC (“B-MAC”) addresses, which the PEs210distribute over the core intermediate network212in EVPN MAC/IP advertisement routes. PE210A, via BEB233A, may exchange its B-MAC address using a routing protocol (e.g., BGP) over intermediate network212(e.g., an MPLS core network) in MAC Advertisement routes instead of advertising C-MAC addresses via the control plane. PEs210then learn remote C-MAC to B-MAC bindings in the data plane for traffic received from the core. PEs210may build a forwarding table from remote BGP EVPN advertisements received that associate remote B-MAC addresses with corresponding remote PE210IP addresses and MPLS label(s). Subsequently, PE210A, for instance, may receive, from endpoint204A, an L2 packet having a destination MAC address that is a C-MAC and may encapsulate the L2 packet with a PBB header and MPLS header for the B-MAC bound to the C-MAC and forward the encapsulated packet to remote PE210B that is associated with the B-MAC in PE210A from an earlier-received EVPN MAC/IP advertisement.

Remote PE210B may receive the encapsulated packet from intermediate network212and decapsulate the PBB header and MPLS header from the packet. Remote PE210B may learn the C-MAC address for endpoint204A in the data plane in association with the B-MAC address associated with PE210A and included in the PBB header. In this way, PE devices210provide PBB bridging services as BEBs for traffic flowing between customer networks206and intermediate network212.

In some examples, the PBB header may include a backbone service instance tag (I-TAG), backbone VLAN tag (B-TAG), backbone source address (B-SA), and backbone destination address (B-DA). The I-TAG includes a backbone service instance identifier (I-SID) for a service provider to identify a PBB-EVPN instance. The B-SA and B-DA indicate the backbone source and destination MAC addresses. PE210A may advertise local B-MAC address reachability information in BGP to all other PE devices in the same EVI203in intermediate network212. The other PEs210may learn remote C-MAC to B-MAC bindings in data-plane for traffic received from intermediate network212via core-facing logical interfaces218A,218B (“core-facing logical interfaces218”). For example, PE210B may receive traffic from intermediate network212via core-facing interface218A and build forwarding tables associating a remote B-MAC address of PE210A with C-MAC address of endpoint204A and the associated MPLS label. In this way, PEs210may perform both local learning and remote learning of MAC addresses in PBB-EVPN. Although the example is illustrated with a single C-MAC address to B-MAC address binding, each of PEs210may also aggregate multiple C-MAC addresses with a single B-MAC address to provide a MAC summarization scheme.

In some examples, due to misconfiguration of any one or more of PEs210, CEs208; or due to duplicate L2 addresses for endpoint devices204behind different PEs210; an L2 forwarding loop between PE210B and CE208B may occur such that PE210B receives packets having a C-MAC address that matches the C-MAC address associated with endpoint204A on both core-facing logical interface218A and access-facing logical interface217B. For instance, having already remotely learned the C-MAC address for endpoint204A at core-facing logical interface218A in the data plane, PE210B may subsequently learn the C-MAC address associated with endpoint204A on access-facing logical interface217B. This may occur because CE208B hairpins at least one packet having a source C-MAC address that matches the C-MAC address associated with endpoint204A due to a routing configuration or learned route or because another L2 device, e.g., endpoint204B of Ethernet segment214B, is configured with a same C-MAC address associated with endpoint204A and sends at least one packet having the source C-MAC address that is the C-MAC address. In some situations, L2 forwarding loops may occur for reasons other than those listed above.

As described above, when the same address, e.g., C-MAC associated with endpoint204A, is learned on a different physical or logical interface of an L2 switching device such as PE device210B, the L2 switching device performs a “MAC move.” As a result of a MAC move for a MAC address from a previous interface to a new interface, the L2 switching device forwards L2 packets destined to the MAC address via the new interface. In the example ofFIG. 2, due to the forwarding loop described above, the C-MAC of endpoint204A may move from core interface218A to access-facing logical interface217B and back as each of these interfaces alternate, in time, receiving packets having source C-MAC addresses that match the L2 address associated with endpoint204A.

To detect L2 forwarding loops, PE210B may configure a loop detection threshold based on the number of times a C-MAC address move occurs over time, a specified period of time over which the C-MAC address move occurs, or a specified number of times a C-MAC address move occurs, for instance. As one example, PE210B may be configured with a loop detection threshold that indicates a L2 forwarding loop based on detecting 5 C-MAC address moves between different interfaces of PE210B in a span of 30 seconds. Upon reaching the loop detection threshold, PE devices210may in some cases block a corresponding one of access-facing logical interfaces217to block L2 traffic from the local customer network. In the example ofFIG. 2, upon the detection of L2 forwarding loop on Ethernet segment214B, PE210B may block access-facing logical interface217B from receiving L2 traffic from CE208B. That is, PE210B will not forward L2 traffic received on blocked access-facing logical interface217B.

In accordance with techniques described herein, any of PE devices210may deterministically determine whether to block its access-facing logical interface for EVI203from forwarding PBB-EVPN traffic from the local customer network206for the PE device210based on a comparison of an identifier of the PE device210and an identifier for a remote PE device of the EVI203. As one example, the identifiers may be B-MAC addresses of PE devices210. For example, in response to detecting an L2 forwarding loop, PE210B may compare a local B-MAC address of PE210B with a remote B-MAC address of PE210A learned on core-facing interface218A of the EVI203that is logically located on the L2 forwarding path, and, based on the comparison, PE210B may block access-facing logical interface217B from receiving L2 traffic from customer network206B. In some examples, if the local B-MAC address of PE210B is lower than the remote B-MAC address of PE210A, PE210B may block access-facing logical interface217A to block L2 traffic from customer network206B. In this way, a loop between PE210B and CE208B is avoided. In the above examples, each of the local and remote B-MAC addresses may be associated in PE210B with the C-MAC address for which the L2 forwarding loop is detected. For example, the local B-MAC address may be assigned to access-facing interface217B, while PE210B may learn the remote B-MAC address to C-MAC binding on core-facing interface218A.

PE210A may also detect the L2 forwarding loop detected by PE210B and perform the operation described above to determine whether to block access-facing logical interface217A for EVI203. For example, PE210B may forward L2 traffic to PE210A of EVI203that is logically located on the L2 forwarding path. Having already learned the C-MAC associated with endpoint204A at access-facing logical interface217A, PE210A may subsequently learn the source C-MAC address of endpoint204A on core interface218B. As described above, because source C-MAC address information associated with endpoint204A appears on a different logical interface of PE210A for EVI203, the C-MAC address moves from access-facing logical interface217A to core-facing logical interface218B. PE210A may detect an L2 forwarding loop on an L2 forwarding path, such as in intermediate network212, based on the MAC address move from access-facing logical interface217A to core-facing logical interface218B. In response to detecting the L2 forwarding loop, PE10A may compare the local B-MAC address of PE210A with a remote B-MAC address of PE210B learned from core-facing logical interface218B and determine a lower B-MAC address from the local and remote PE devices. As described above, if the remote B-MAC address of PE210B is lower than the local B-MAC address of PE210A, then PE210A may block access interface of PE210B to block L2 traffic from customer network206B.

Because PE210A and210B have different identifiers that serve as the basis for the determination to block an access interface for EVI203in response to detecting an L2 forwarding loop, and because PE210A and210B use each other's identifier as the remote identifier, the same operation performed by PE210A and210B will cause each of the PEs to determine a different result. That is, only one of PEs210A,210B will determine to block its associated access-facing logical interface217for EVI203(and will block the interface), and one of PEs210A,210B will determine not to block its associated access-facing logical interface217for EVI203(and will not block the interface). In this way, PE devices210may deterministically determine which access interface217to block in order to eliminate an L2 forwarding loop in the PBB-EVPN instance, while leaving the other access-facing logical interface217. The respective determinations by PEs210may be independently performed without the PEs210exchanging communications to determine which of access-facing logical interfaces217is to be blocked.

The techniques may thus reduce overhead for customers in identifying/tracking looped logical ports and blocking logical ports to eliminate loops. In addition, by simply manipulating the identifiers for the PEs210in an EVI203on which the comparison is based, a customer may pre-determine which of access-facing logical interfaces217has blocking priority to facilitate customer goals for L2 traffic delivery.

FIG. 3is a block diagram illustrating an example provider edge network device according to techniques described herein. PE device300is an example of any of PEs10and/or PEs210ofFIGS. 1-2. PE device300is described with respect to PE10B ofFIG. 1, but may be performed by any PE network device. PE device300includes a control unit36having a routing engine38, and control unit36is coupled to forwarding engines30A-30N (“forwarding engines30” or “forwarding units”). Forwarding engines30A-30N are associated with one or more interface cards32A-32N (“IFCs32”) that receive packets via inbound links58A-58N (“inbound links58”) and send packets via outbound links60A-60N (“outbound links60”). IFCs32are typically coupled to links58,60via a number of interface ports (not shown). Inbound links58and outbound links60may represent physical interfaces, logical interfaces, or some combination thereof. For example, any of links58,60may be associated with access-facing logical interfaces (e.g.,17and/or217) and core-facing logical interfaces (18and/or218) ofFIGS. 1-2.

Elements of control unit36and forwarding engines30may be implemented solely in software, or hardware, or may be implemented as combinations of software, hardware, or firmware. For example, control unit36may include one or more processors, one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, or any combination thereof, which execute software instructions. In that case, the various software modules of control unit36may comprise executable instructions stored, embodied, or encoded in a computer-readable medium, such as a computer-readable storage medium, containing instructions. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor, or other processor, to perform the method, e.g., when the instructions are executed. Computer-readable storage media may include random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), non-volatile random access memory (NVRAM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette, a solid state drive, magnetic media, optical media, or other computer-readable media. Computer-readable media may be encoded with instructions corresponding to various aspects of PE device300, e.g., protocols, processes, and modules. Control unit36, in some examples, retrieves and executes the instructions from memory for these aspects.

Routing engine38includes kernel43, which provides a run-time operating environment for user-level processes. Kernel43may represent, for example, a UNIX operating system derivative such as Linux or Berkeley Software Distribution (BSD). Kernel43offers libraries and drivers by which user-level processes may interact with the underlying system. Hardware environment55of routing engine38includes microprocessor57that executes program instructions loaded into a main memory (not shown inFIG. 3) from a storage device (also not shown inFIG. 3) in order to execute the software stack, including both kernel43and processes executing on the operating environment provided by kernel43. Microprocessor57may represent one or more general or special-purpose processors such as a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or any other equivalent logic device. Accordingly, the terms “processor” or “controller,” as used herein, may refer to any one or more of the foregoing structures or any other structure operable to perform techniques described herein.

Kernel43provides an operating environment that executes various protocols44at different layers of a network stack, including protocols for implementing EVPN and/or PBB-EVPN networks. For example, routing engine38includes network protocols that operate at a network layer of the network stack. In the example ofFIG. 3, network protocols include the Border Gateway Protocol (BGP)46and/or the Provider Backbone Bridge (PBB)47, which are routing protocols. Routing engine38may include other protocols not shown inFIG. 3, such as an MPLS label distribution protocol and/or other MPLS protocols. Routing engine38is responsible for the maintenance of routing information42to reflect the current topology of a network and other network entities to which PE device300is connected. In particular, routing protocols periodically update routing information42to reflect the current topology of the network and other entities based on routing protocol messages received by PE device300.

Kernel43includes an interfaces table49that represents a data structure that includes a corresponding entry for each logical interface configured for PE device300. For example, interface table49may include an entry for access-facing logical interfaces (e.g.,17ofFIG. 1) and core-facing logical interfaces (e.g.,18ofFIG. 1). Entries for respective logical interfaces may specify respective current information describing the logical interfaces.

As shown inFIG. 3, PE device300may be configured with multiple VRFs22A-22N (“VRFs22”). VRF22A represents a virtual routing and forwarding instance. VRF22A includes at least one routing table for BGP46. An attachment circuit, e.g., access-facing logical interfaces17and core-facing logical interfaces18ofFIG. 1, may be associated with a particular VRF, such as VRF22A, and the particular VRF may be configured to forward traffic for the attachment circuit. As one example, access-facing logical interface17B and core-facing logical interface18A of PE10B ofFIG. 1may be associated with VRF22A and VRF22B, respectively.

Forwarding engines30represent hardware and logic functions that provide high-speed forwarding of network traffic. Forwarding engines30typically includes a set of one or more forwarding chips programmed with forwarding information that maps network destinations with specific next hops and the corresponding output interface ports. In general, when PE device300receives a packet via one of inbound links58, one of forwarding engines30identifies an associated next hop for the data packet by traversing the programmed forwarding information based on information within the packet. One of forwarding engines30(either the ingress forwarding engine or a different egress forwarding engine) forwards the packet on one of outbound links60mapped to the corresponding next hop. Kernel43may generate forwarding information56to include representations of information stored to VRFs22and interfaces49in the form of forwarding information for optimized forwarding by forwarding engines30. Kernel43may additionally, or in the alternative, generate forwarding information56to include C-MAC and B-MAC bindings in the form of forwarding information for forwarding by forwarding engines30.

In the example ofFIG. 3, forwarding engine30A includes forwarding information56. In accordance with routing information42, forwarding engine30A stores forwarding information56that maps packet field values to network destinations with specific next hops and corresponding outbound interface ports. For example, routing engine38analyzes routing information42and generates forwarding information56in accordance with routing information42. Forwarding information56may be maintained in the form of one or more tables, link lists, radix trees, databases, flat files, or any other data structures.

APE device300may be configured to implement EVPN, PBB-EVPN, or both EVPN and PBB-EVPN techniques. For a PE device300implementing PBB-EVPN, forwarding information56may include a C-MAC table64and a B-MAC table65for each PBB-EVPN instance established by PE device300. C-MAC table64includes data representing mappings or associations between C-MAC addresses and B-MAC addresses. In some examples, C-MAC table64includes a C-MAC address as a key and a B-MAC address as the corresponding value, or vice versa. B-MAC table65includes data representing mappings or associations between B-MAC addresses and Ethernet segments. For instance, B-MAC table65includes a B-MAC address as a key that maps each B-MAC address to a corresponding remote PE device IP address and MPLS label(s) for reaching the associated Ethernet segment. As traffic is received, PE device300may learn C-MAC addresses for the C-MAC table64via data plane learning.

Forwarding engine30A stores forwarding information56for each Ethernet VPN Instance and/or PBB-EVPN Instance (EVI) established by PE device300to associate network destinations with specific next hops and the corresponding interface ports. As described inFIG. 1, an EVI may be associated with one or more Ethernet segments in an EVPN, e.g., Ethernet segments14A,14B. Similarly, an EVI may be associated with one or more Ethernet segments in a PBB-EVPN, e.g., Ethernet segments214A,214B, ofFIG. 2. In general, when PE device300receives a data packet from a given Ethernet segment via one of inbound links58, forwarding engine30A, for example, identifies an associated next hop for the data packet by traversing forwarding information56based on information (e.g., labeling or header information) within the packet. Forwarding engine30A forwards the data packet on one of outbound links60to the corresponding next hop in accordance with forwarding information56associated with the Ethernet segment. At this time, forwarding engine30A may push and/or pop labels from the packet to forward the packet along a correct LSP.

Routing engine38includes a configuration interface41that receives and may report configuration data for PE device300. Configuration interface41may represent a command line interface; a graphical user interface; Simple Network Management Protocol (SNMP), Netconf, or another configuration protocol; or some combination of the above in some examples. Configuration interface41receives configuration data configuring the PE device300with VRFs22, interfaces49, and other constructs that at least partially define the operations for PE device300. For example, an administrator may use configuration interface41to configure the identifier (e.g., loopback IP address or B-MAC address) for PE device300.

Routing engine38also includes an EVPN module48having a learning module52that performs layer two (L2) learning. Learning module52may perform remote learning using BGP46. EVPN module48may maintain MAC tables50for each EVI established by PE device300, or in alternative examples may maintain one or more MAC tables50that are independent of each respective EVI. One of MAC tables50, for instance, may represent a virtual routing and forwarding table of VRFs22A for an EVI configured for VRF22A. Learning module52may perform local L2/L3 (e.g., MAC/IP) binding learning by, e.g., using MAC information received by PE device300. Learning module52may detect a new MAC address on an EVI access interface for an EVI and add the MAC address, with a mapping to the EVI access interface to one of the MAC tables50for the EVI. Learning module52may in addition, or in the alternative, be configured for execution, in full or in part, in the data plane to learn C-MAC addresses for a PBB-EVPN instance.

Learning module52may then advertise an MAC advertisement route using BGP46to remote PEs for the EVI. The MAC advertisement route may include a route target corresponding to the EVI, the MAC address (for EVPN) or B-MAC address (for PBB-EVPN), the Ethernet tag for the bridge domain in which the MAC address was learned, the ESI in which the MAC address was learned, the IP address corresponding to the MAC address (if known), and an EVPN label. With remote MAC learning, learning module52may, for EVPN, receive an MAC advertisement route from another PE device and install a host route for the IP address (if included) with protocol type EVPN for the EVI and install the MAC address in the MAC table50of the EVI, as well as the MAC information associated with the route in the VRF22including the EVPN label. For PBB-EVPN, learning module52may receive a MAC advertisement route from another PE device and learn the B-MAC address of another PE device.

Routing engine38also includes a loop detection module63that detects an L2 forwarding loop on an L2 forwarding path. For example, in response to learning module52detecting a source MAC address on an access-facing logical interface (e.g.,17B ofFIG. 1) that was previously learned on a core-facing logical interface (e.g.,18A ofFIG. 1) of the same EVI, loop detection module63detects whether an L2 forwarding loop exists on an L2 forwarding path that includes the access interface. An administrator, through the configuration interface41, may configure for loop detection module63a loop detection threshold based on the number of times a MAC address move occurs over time, a specified period of time over which the MAC address move occurs, or a specified number of times a MAC address move occurs, for instance.

Similarly, learning module52may detect a source C-MAC address on an access-facing logical interface (e.g.,217B ofFIG. 2) that was previously learned on a core-facing logical interface (e.g.,218A ofFIG. 2) of the same EVI. Loop detection module63detects whether an L2 forwarding loop exists on an L2 forwarding path that includes the access interface. An administrator may configure a loop detection threshold based on the number of times a C-MAC address move occurs over time, a specified period of time over which the C-MAC address move occurs, or a specified number of times a C-MAC address move occurs in, for instance.

Routing engine38further includes a blocking module61having an identifier comparison module62for deterministically determining whether to block an access-facing logical interface of PE device300(e.g., interface58A). For example, in response to reaching a loop detection threshold, loop detection module63may signal blocking module61to determine whether to block an access-facing logical interface for an EVI from forwarding L2 EVPN or PBB-EVPN traffic from the local customer network. Identifier comparison module62may compare identifiers, including, for example, loopback IP (e.g., IPv4/IPv6) addresses and/or B-MAC addresses, for PE device300and a remote PE device of the EVI. In one example, identifier comparison module62may compare the loopback IP address of PE device300and the loopback IP address of a remote PE device of the EVI that is logically located on the L2 forwarding path. In one instance, if the loopback IP address of PE device300is lower than the remote loopback IP address, identifier comparison module62may inform blocking module61to block interface58associated with the access-facing logical interface (e.g.,17B ofFIG. 1). In another instance, if the loopback IP address of PE device300is greater than the remote loopback IP address, identifier comparison module62may inform blocking module61to not block interface58associated with the access-facing logical interface.

Identifier comparison module62may additionally, or in the alternative, compare the B-MAC address of PE device300and the B-MAC address of a remote PE device of the EVI that is logically located on the L2 forwarding path. In one example, if the B-MAC address of PE device300is lower than the remote B-MAC address, identifier comparison module62may inform blocking module61to block interface58associated with the access-facing logical interface (e.g.,217B ofFIG. 2). In another example, if the B-MAC address of PE device300is greater than the remote B-MAC address, identifier comparison module62may inform blocking module61to not block interface58associated with the access-facing logical interface.

FIG. 4is a flowchart illustrating an example operation of a provider edge network device for deterministically determining whether to block an access-facing logical interface within an EVPN instance, according to techniques described herein. Operation400is described with respect to PE10B ofFIG. 1, but may be performed by PE210B ofFIG. 2or any PE network device. In some examples, due to misconfiguration of any one or more of PEs10, CEs8; or due to duplicate L2 addresses for endpoint devices4behind different PEs10; an L2 forwarding loop between PE10B and CE8B may occur such that PE10B receives an L2 packet having a source MAC addresses that match the MAC address of endpoint4A on both core-facing logical interface18A and access-facing logical interface17B (402). For instance, having already remotely learned the MAC address for endpoint4A at core-facing logical interface18A, PE10B may subsequently learn the MAC address for endpoint4A on access-facing logical interface17B.

Based in part on the received packet, PE10B may detect an L2 forwarding loop on an L2 forwarding path of an EVI (404). For example, PE10B may include a loop detection threshold based on the number of times a MAC address move occurs over time, a specified period of time over which the MAC address move occurs, or a specified number of times a MAC address move occurs, for instance.

In response to detecting an L2 forwarding loop, local PE device10B may determine a local identifier for local PE device10B (406) and an identifier of a remote PE device (408), e.g., PE10A, that is situated on the L2 forwarding path for the MAC address for endpoint4A. In one example, PE10B may determine a loopback IP (IPv4/IPv6) address of PE10B and a loopback IP address of remote PE10A. In another example, PE210B may determine a B-MAC address of PE210B and a B-MAC address of a remote PE210A. Additionally, or in the alternative, an administrator may manipulate the identifiers for the PE devices in an EVI such that a customer may pre-determine which access-facing logical interface has blocking priority to facilitate customer goals for L2 traffic delivery.

PE10B may then compare the local identifier address (e.g., loopback IP address or B-MAC address) and the remote identifier address of PE devices of an EVI (410). The comparison may in some examples include determining a lower identifier from the identifier for the local PE device and the identifier for the remote PE device. In other examples, the comparison may include determining a higher identifier from the identifier for the local PE device and the identifier for the remote PE device. In any case, based on the result of the comparison, PE10B determines whether to block its access-facing interface17A for EVI3(412).

If PE10B determines to block access-facing interface17A (YES branch of412), PE10B blocks access-facing interface17A (414). If PE10B determines not to block access-facing interface17A (NO branch of412), PE10B does not block access-facing logical interface17A (416). In some examples, a determination that the local PE device has a lower identifier blocks the access-facing logical interface17A. A determination that the local PE device has a higher identifier does not block the access-facing logical interface17A.

Various aspects of the techniques have been described. These and other aspects are within the scope of the following claims.