Protocol independent multicast sparse mode (PIM-SM) support for data center interconnect

Techniques are described for utilizing Protocol Independent Multicast Sparse Mode (PIM-SM) to transport BUM (broadcast, unknown unicast, and multicast) traffic in a Virtual Extensible LAN (VXLAN) underlay of a data center, where the BUM traffic is received on active-active, multi-homed Ethernet virtual private network (EVPN) interconnects between multiple physical data centers. For example, the techniques may readily be applied to support usage of PIM-SM where provider edge (PE) routers of the EVPN operate as gateways between the EVPN and the VXLAN spanning the data center interconnect.

TECHNICAL FIELD

The invention relates to computer networks and, more specifically, to forwarding multicast traffic within data centers.

BACKGROUND

A data center is a specialized facility that provides data serving and backup as well as other network-based services for subscribers and other entities. A data center in its most simple form may consist of a single facility that hosts all of the infrastructure equipment, such as networking and storage systems, servers, redundant power supplies, and environmental controls.

More sophisticated data centers may be provisioned for geographically dispersed organizations using subscriber support equipment located in various physical hosting facilities (sites). As a result, techniques have been developed to interconnect two more physical data centers to form a single, logical data center. One example layer two (L2) interconnect is an Ethernet virtual private network (EVPN) interconnect through an intermediate network coupling multiple physical data centers.

SUMMARY

This disclosure describes techniques for supporting Protocol Independent Multicast Sparse Mode (PIM-SM) to transport traffic in a Virtual Extensible LAN (VXLAN) underlay of a data center, where the BUM traffic is received on active-active, multi-homed Ethernet virtual private network (EVPN) interconnects between multiple physical data centers. For example, the techniques may readily be applied to support usage of PIM-SM where provider edge (PE) routers of the data centers operate as gateways between the VXLAN and the EVPN spanning the data center interconnect. In this example environment, the VXLAN may be multi-homed to provide protection and load balancing, and in some situations is may be desirable to utilize PIM-SM to deliver so-called “BUM” traffic, i.e., broadcast, unknown unicast and multicast traffic in the VXLAN.

In one example, a method comprises: establishing an Ethernet virtual private network (EVPN) data center interconnect (DCI) between a first data center running a virtual extensible local area network (VXLAN) and a second data center, wherein the VXLAN of the first data center is active-active multi-homed to two or more provider edge (PE) routers of the EVPN and includes VXLAN tunnels established using protocol independent multicast-sparse mode (PIM-SM). The method further includes receiving, with one of the two or more multi-homed PE routers from the EVPN, BUM (broadcast, unknown unicast, and multicast) traffic, wherein the one of the two or more multi-homed PE routers is not a designated forwarder (DF), and forwarding the BUM traffic from the one of the two or more multi-homed PE routers into the VXLAN toward the first data center according to EVPN BUM forwarding rules.

In another example, a router comprises a routing engine having a processor executing an Ethernet virtual private network (EVPN) protocol to establish a data center interconnect (DCI) between a first data center running a virtual extensible local area network (VXLAN) and a second data center using an Ethernet virtual private network (EVPN). The router is one of a plurality of active-active routers multi-homed to the data center and providing the EVPN DCI, and wherein the routers establish VXLAN tunnels to transport traffic through the first data center using protocol independent multicast-sparse mode (PIM-SM). The one of the two or more multi-homed PE routers is not a designated forwarder (DF). The router further includes a forwarding engine having a plurality of network interfaces to receive BUM (broadcast, unknown unicast, and multicast) traffic and forward the BUM traffic from the one of the two or more multi-homed PE routers into the VXLAN toward the first data center according to EVPN BUM forwarding rules.

In another example, a computer-readable medium comprising instruction that cause a processor of a router of a plurality of active-active multi-homed routers of an Ethernet virtual private network (EVPN) to establish, with the processor of the router, a data center interconnect (DCI) between a first data center running a virtual extensible local area network (VXLAN) and a second data center using the EVPN, wherein the VXLAN is active-active multi-homed to the plurality of routers of the EVPN and includes VXLAN tunnels established using protocol independent multicast-sparse mode (PIM-SM) between the first data center and the two or more multi-homed PE routers. The instruction further cause the computer-readable medium to program, with the processor of the router, a forwarding unit of the router to: receive, with one of the two or more multi-homed PE routers from the EVPN, BUM (broadcast, unknown unicast, and multicast) traffic; and forward the BUM traffic from the router into the VXLAN toward the first data center according to EVPN BUM forwarding rules specifying that any of the multi-homed PE routers are to forward the BUM traffic into the VXLAN regardless of which of the PE routers is the specified as a designated forwarder (DF) for the EVPN

The details of one or more examples are set forth in the accompanying drawings and the description below.

DETAILED DESCRIPTION

FIG. 1is a block diagram illustrating an example network system in which routers provide Protocol Independent Multicast Sparse Mode (PIM-SM) support for data center interconnect between multiple physical data centers. In this example, data centers5A-5B (collectively, “data centers5”) are networks having specialized facilities that provide storage, management, and dissemination of data to subscribers and other entities. In the example ofFIG. 1, data centers5A,5B includes a plurality of servers9A,9B and storage area networks (SANs)7A,7B respectively that provide computing environments for subscribers/customers. Subscriber devices (not shown) may connect to data centers5to request and receive services and data provided by data centers5. In some instances, data centers5A,5B are geographically dispersed facilities, or “sites,” of an overall data center to provide geographical redundancy against localized failure of one of the data centers.

In this example, data centers5are interconnected by a wide area network (WAN). In general, WAN4represents a layer three (L3) network and may include multiple intermediate routing and switching devices (not shown) that transport data traffic over links between data centers5. For example, wide area network4may implement Multiprotocol Label Switching (MPLS) techniques and may be referred to as an MPLS/IP network. While described as a wide area network, WAN4may represent any network capable of transmitting traffic exchanged between provider edge routers (PEs)6.

For example, provider edge routers (PEs)6A,6A′,6B and6B′ (collectively, “PEs6”) may utilize Ethernet VPN (E-VPN) technology through WAN4to provide an EVPN data center interconnect (DCI) between data centers5A and5B. In this way, PEs6provide an EVPN23to transport L2 communications for customer networks of data centers5through an intermediate network (WAN4), in a transparent manner, i.e., as if the intermediate network does not exist and data centers5were instead directly connected.

In particular, each of PEs6provide the EVPN23to transport L2 communications, such as Ethernet packets or “frames,” through WAN4for different customers of data centers5. That is, various customer networks provided within data centers5may be virtually isolated onto different Virtual Extensible LANs (VXLANs)14. As shown inFIG. 1, each of data centers5includes an underlay network17A,17B of transport routers that transport L2 communications through a respective VXLANs14. As such, PEs6may receive customer traffic from local VXLANs14and forward the traffic through WAN4via the EVPN23. Similarly, PEs6may receive L2 communications from EVPN23and forward the L2 communications via VXLANs14for transport through the local data centers5via underlay networks17.

In this way, PEs6provide an active-active, multi-homed EVPN/VXLAN data center interconnect (DCI) between data centers5. As such, each of PEs6operates as gateway between EVPN23and VXLANs, and may function as VXLAN Tunnel Endpoints (shown as “VTEP” inFIG. 1). That is, each PE6may include logically separate routing instances for VXLAN14and EVPN23and each operates to bridge traffic between the two distinct internal routing instances. Further example structural and functional details of the EVPN/VXLAN DCI implemented by PE routers6are described in “VXLAN DCI Using EVPN,” draft-boutros-12vpn-vxlan-evpn-04.txt, Internet Engineering Task Force (IETF), Jul. 2, 2014, the entire contents of which are incorporated herein by reference.

As shown inFIG. 1, each data center5A,5B is multi-homed to WAN4for redundancy and load balancing. That is, PE routers6A,6A′ are configured to operate as multi-homed PEs of a single-active or an active-active multi-homed VXLAN14A to provide L2 connectively to customer edge router (CE)18A of data center5A. Similarly, PE routers6B,6B′ are configured to operate as multi-homed PEs of a single-active or an active-active multi-homed Ethernet segment14B to provide L2 connectively to CE18B of data center5B. As an all-active multi-homing of the VXLAN network to MPLS/IP WAN network4, traffic from a VTEP can arrive at any of PEs6of that Ethernet segment14and can be forwarded accordingly over the MPLS/IP WAN network4. Furthermore, traffic destined to a VTEP can be received over the MPLS/IP network at any of the PEs connected to the VXLAN network and be forwarded accordingly. In some examples, the VXLAN network may alternatively be a NVGRE network.

When forwarding L2 communications (e.g., VXLAN packets) traversing EVPN23, PEs6learn L2 state information for the L2 customer networks within data centers5. The L2 state information may include media access control (MAC) addressing information associated with the network devices and customer equipment (e.g., virtual machines) within data centers5and the ports and/or pseudowire of the PE through which the customer devices are reachable. PEs6typically store the MAC addressing information in L2 learning tables associated with each of their interfaces.

With active-active multi-homing, PEs6of a multi-homed Ethernet segment connected to the same logical VXLAN are typically configured with a common anycast address. For example, PEs6A and6A′ ofFIG. 1would typically be configured with the same common anycast address for the underlay tunnels through underlay networks17. As such, PEs6A,6A′ (and similarly PE6B,6B′) are viewed as a single logical PE from the perspective of the remote PEs across WAN4and also from routers within local VXLAN underlay networks17. This may be advantageous, for example, to avoid MAC learning flip-flopping on remote VTEPs (e.g., PEs6B and6B′) in the event VXLAN traffic is received first from one of PEs6A,6A′ and then received from the other of the PEs.

In general, routers within underlay network17as well as CEs18and PEs6execute a multicast routing protocol such as protocol independent multicast (PIM) to control transport of multicast traffic within each data center5. In some examples, the routers may support both Protocol Independent Multicast Bidirectional Mode (PIM-BIDIR) and Protocol Independent Multicast Sparse Mode (PIM-SM).

With respect to broadcast, unknown unicast or multicast L2 traffic, so called “BUM” traffic, received from the EVPN23of WAN4, one of the PEs6of EVPN23is elected as the designated forwarder (DF), and conventionally only the DF is allowed to forward BUM traffic to the VXLAN according to EVPN BUM traffic forwarding rules. To transport BUM traffic within the VXLAN underlay networks, PIM-BIDIR is commonly used because the protocol is compatible with use of a common anycast address assigned to multiple PEs in the active-active mode. In some environments, however, it is desirable to also support or otherwise utilize PIM-SM within underlay networks for delivery of BUM traffic received from EVPN23. However, conventionally, PIM-SM is generally not compatible with active-active, multi-homed EVPN environments that, for example, use a common anycast addresses for multiple PEs.

This disclosure describes techniques that allow PIM-SIM to be used in network topologies having an EVPN/VXLAN DCI when the VXLAN networks are multi-homed to EVPN PEs working in all-active mode (e.g.,FIG. 1). As described herein, multi-homed PEs6configure forwarding planes therein to apply modified EVPN BUM traffic forwarding rules in a manner that allows PIM-SM to be utilized within VXLANs14even though active-active pairs of PEs6for each data center5share a common anycast address. Moreover, the techniques ensure that BUM traffic15received from EVPN23can be delivered to all the remote VTEPs in the VXLAN underlay network17. That is, if configured by an administrator or management system, PEs6, whether operating as a DF or non-DF for EVPN23, forward BUM traffic15from the EVPN23into the VXLAN for transport through data centers5. In other words, when underlay network17is configured to operate using PIM-SM, PE routers6may automatically configure their respective forwarding hardware (referred to herein as forwarding units or data planes) to operate according to modified forwarding rules that specify that all PE routers forward all BUM traffic from EVPN23to underlay tunnels of VXLAN underlay network17traversing data centers5regardless of which of the PE routers for each Ethernet segment14is elected as DF for that segment.

For example, as described in further detail below, the techniques described by which multiple ones of the active-active, multi-homed PEs6A,6A′ construct respective multicast distribution trees to forward BUM traffic15through VXLAN14A. In this way, PEs6A,6A′ operate according to modified EVPN BUM traffic forwarding rules to forward subsequent BUM traffic15from EVPN23and into the VXLAN tunnels of underlay network17A. As such, without changing the PIM protocols, multiple distribution trees are transparently created and rooted on potentially multiple EVPN routing instances of multi-homed PEs6A,6A′ and are utilized in an active-active, EVPN environment ofFIG. 1. Moreover, as further described below, the techniques leverage reverse path forwarding (RPF) check utilized within PIM-SM to ensure that duplicate copies of BUM traffic15will be filtered out by the transport routers prior to the multiple copies reaching their destinations (e.g., servers9A or SAN14A).

FIGS. 2A-2Care block diagrams illustrating in further detail portions of the example network system ofFIG. 1in accordance with the techniques described herein. As shown inFIG. 2A, initially, all VTEPs for a local VXLAN, including VTEP routing instances executing on any transport routers of underlay networks17and PEs6for that VXLAN, issue (*,G) PIM joins13to initiate multicast traffic for a multicast group (G). Specifically, initial PIM joins13from VTEP instances for a VXLAN are directed to a designated Rendezvous Point (RP)11for the multicast group for that particular VXLAN. As further described below, RP11is a router or other device that has been designated to acts as a shared root for a (*, G) multicast tree that will be, or has been, constructed for subsequent injection of multicast traffic for the multicast group into the VXLAN. In general, multicast traffic sent from a sender is typically tunneled to RP11, and such tunneled traffic is referred to as “non-native” multicast traffic, which RP11would in turn forward as a shared root on the (*, G) distribution tree for a given multicast group (G). Although shown separately from PE routers6, RP11may configured to execute on any of PE routers6or on a separate device.

When copies of a first BUM packet15associated with the requested multicast flow arrive on the EVPN routing instance of PE routers6, all receiving EVPN PEs6will send PIM register messages21to the RP11as an indication that the particular multicast traffic is now being received at the particular PE router and that the PE router may now operate as a particular source (S) for the multicast traffic with respect to the PIM-based distribution of the traffic within data center5A. The multicast flow associated with BUM traffic15may be uniquely identified within the PIM register messages21as a combination of an anycast address assigned to PEs6for EVPN23and the multicast group, i.e., an (S,G) PIM register message, where S is set to the anycast address of the multi-homed VXLAN14A. Moreover, each of PIM register messages21may have a source address of the sending interface of the PE router instead of the anycast address on the PE6that originated the PIM register message. In this way, RP11may be able to uniquely associate each of PIM messages21with the sender, i.e., a respective one of PE routers6A.

Upon receiving a (S,G) PIM register message21, RP11selects one of the multi-homed, active-active PE routers6A,6A′ from which register messages21have been received and sends an (S,G) PIM join25for the flow uniquely identified in the PIM register message by the combination of the EVPN anycast address of PE routers6A,6A′ and multicast group. PIM join request25may be directed toward a closest one of the multi-homed PEs6A,6A′ regardless of whether the PE to which the PIM join is directed is the DF or a non-DF for all-active EVPN23, where “closest” refers to the lowest weight route from RP11to any of the PEs based on a standard path computation (e.g., OSPF path computation) performed on the network domain.

As shown inFIG. 2B, in response, the receiving one of PEs6A,6A′ initiates a handoff process by forwarding any subsequent BUM traffic15for the identified flow natively (i.e., as native multicast without encapsulation) to RP, which in turn distributes the BUM traffic into data center5on the (*, G) PIM multicast distribution tree. While receiving the native traffic15′ and temporarily operating as a root for the (*, G) distribution tree into data center5A, RP11will send respective register-stop messages to any of PEs6that subsequently send register messages specifying the same multicast flow (e.g., register-stop message27sent to PE6A′). As such, only one PE6A,6A′ receives a (S,G) PIM join25for a given combination of a multicast group and anycast address for VXLAN14A of EVPN23. Moreover, only one of the active-active routers PE6switches to native forwarding of BUM traffic15to RP11, which in the example ofFIG. 1is PE router6A. That is, in this example, PE6A receives PIM join25from RP11for the specific multicast group, anycast address combination and PE router6A′ receives register-stop message27for the combination. As such, upon receiving these messages, PE router6A switches to native forwarding all subsequent BUM traffic15for the combination to RP11, and RP11in turn forwards the BUM traffic along the (*,G) distribution tree so as to inject BUM traffic into the VXLAN of data center5A. PE router6A′, upon receiving register-stop message27stops issuing subsequent register messages21. In this way, RP11operates as temporary (*,G) surrogate for the (anycast, G) source of the multicast traffic for forwarding the traffic within VXLAN of data center5A and the underlying transport network17A.

In one example implementation, PE routers6A,6A′ encapsulate initial BUM packets15within PIM register messages21directed to RP11. In such examples, prior to RP11receiving the first natively sent BUM traffic15from any of PEs6A,6A′ for direction into VXLAN14A, RP11extracts the BUM packets encapsulated in register messages21and forwards the BUM traffic along the (*, G) multicast distribution tree. This may have the benefit of avoiding any loss of initial BUM traffic15while RP11issues PIM join25to one of PEs6A, i.e., PE6A′ in the example ofFIG. 1. However, this example implementation may also cause duplicate copies of initial BUM packets extracted from PIM register messages21received from both PE6A and PE6A′. This occurrence, however, will be transient and will stop as soon as the first native BUM packet1is received by RP11. If transient duplication is a concern, some example implementations may utilize a null form of PIM register messages21that do not encapsulate BUM packets15, but this implementation may lead to transient loss of initial BUM packets15. To avoid packet loss and duplication, multi-homed PEs6A,6A′ may periodically send null PIM register messages21to RP11as soon as initial provisioning is completed to pre-build and maintain state for multicast flows to be injected into the VXLAN of data center5A.

Next, as shown inFIG. 2C, when any of the VTEPs for VXLAN17A (e.g., any of PEs6A,6A′ or transport routers of transport network17A acting as a VTEP), receive native multicast traffic15from RP11on the (*, G) distribution tree, the VTEP outputs PIM joins31for the particular (S, G) combination, where S is set to the anycast address for the VXLAN and G is set to the multicast group. As shown inFIG. 2C, each PIM join31is routed to the closest PE, i.e., any one of PE's6A,6A′ that is closest to respective VTEP, where “closest” again refers to a lowest weight route that is selected from the VTEP to one of the PEs based on a standard path computation performed on the network domain. As such, multiple PEs6A,6A′ may receive (S,G) PIM joins for the (anycast, group). This, in turn causes each of the receiving EVPN routing instances of PEs6A,6A′ to construct a respective (S,G) multicast distribution tree for forwarding subsequent BUM traffic15for the (S,G) into data center5A. In this way, multiple (S, G) distribution trees may be created, one for each of the PEs that is a closest PE to one of the VTEPs. In other words, according to PIM-SM, every VTEP sends an (S,G) PIM join31, where S is the anycast address and G is the multicast Group. In turn, each receiving PE6A,6A′ creates respective (S,G) PIM multicast distribution trees, each one rooted at the respective PE that is closest to the VTEP sender.

In the example ofFIG. 2C, each of the PEs6A,6A′ operates as roots for a respect PIM (S,G) multicast distribution trees, and each (S,G) multicast distribution tree is utilized to send BUM traffic15into data center5A. As a result, handoff from the (*,G) distribution tree rooted at RP11to the multiple, (S,G) trees rooted at PEs6A,6A′ occurs, and native forwarding of BUM traffic15may be triggered on multiple PEs6A,6A′. Every multi-homed PEs6A,6A′ that receives an (anycast, G) PIM join31from a VTEP constructs a respective (anycast, G) multicast distribution tree and, in this way, operates according to modified EVPN BUM traffic forwarding rules to forward subsequent BUM traffic15from EVPN23and into the VXLAN tunnels of underlay network17A. As such, without changing the PIM protocols, multiple S,G distribution trees are transparently created and rooted on potentially multiple EVPN routing instances of multi-homed PEs6A and are utilized in an active-active, EVPN environment ofFIG. 1.

Moreover, the techniques described herein leverage reverse path forwarding (RPF) check utilized within PIM-SM by which any transit router (e.g, R1or R2) within underlay network17A will only forward a BUM packet if the router received the BUM packet on an input interface that is facing the packet's source according to the internal IPG routing information, which in this case the root PE6A or PE6A′ for the particular (S, G) multicast distribution tree on which the multicast traffic is expected to be received. For example, applying RPF, router R1drops any BUM traffic15′ received on an interface that is not directed upstream along a path to PE6A, i.e., the root of the multicast distribution tree on which router R1expects to receive the BUM traffic. As such, even though multiple copies of native BUM traffic15may be injected into underlay networks17A from active-active PE routers6A,6A′ the multiple copies will be filtered out by the transport routers prior to the multiple copies reaching their destinations (e.g., servers9A or SAN14A) as the transport routers apply RFP check when transporting the packets using PIM-SM.

As such, the RFP check performed by PIM-SM executing on individual routers within underlay network17A ensures that the routers only forward copies of BUM traffic15received on interfaces designated as upstream interfaces the source of the (S, G) tree. In the event BUM traffic15stops for a threshold period of time, relevant PIM state described above may time out and be cleared, and any subsequent BUM packets15will trigger the above process again.

In this way, the techniques allow an EVPN all-active interconnect23between data centers5to be used even when the data center multicast underlay networks17are running PIM sparse mode (SM) for transporting multicast traffic. As such, multiple PEs6attached to the same data center5A or5B can be configured with the same anycast IP address, which may provide stability to all unicast entries injected into a given data center from other data centers. This allows PEs6A,6A′ to appear in the routing domain (e.g., IGP) of remote data5B center as a single host.

As such, the techniques herein provide Protocol Independent Multicast Sparse Mode (PIM-SM) support for an active-active, multi-homed EVPN data center interconnect between multiple physical data centers. Although described with respect to BUM traffic flowing from EVPN23into the VXLAN of data center5A, the techniques may readily be applied to any data center, e.g., data center5B, having active-active, multi-homed PEs6B,6B′ coupled to EVPN23.

As discussed above, in a typical EVPN configuration, a single PE of an EVPN acts as the designated forwarder of BUM traffic and no other PE of the multi-homed, active-active EVPN forwards BUM traffic into the data center, thereby seeking to prevent packet forwarding loops and receipt of multiple copies of individual BUM packets. Moreover, it may be desirable to configured active-active, multi-homed EVPN PEs of an Ethernet segment with the same anycast address for stability with respect to remote routing domains. Conventional PIM SM protocol in which transport routers apply a reverse path forwarding (RPF) check causes the transit routers to only forward a BUM packet if the router received the BUM packet on an input interface that is toward the packet's source, which in conventional configuration is the IP anycast address configured on each of the PEs. As a result, if only one PE is selected as DF, conventional techniques cause some number of transit routers to discard a given BUM packet because it was received on what the transit router decides is an invalid input interface. As described, this disclosure describes techniques that allow each PE6of a multi-homed segment14, regardless of DF election, to sends BUM traffic from EVPN23toward the local data center5and rely upon the operation of the RPF check of PIM-SM applied by transit routers of underlay networks17to prevent packet forwarding loops and receipt of multiple copies of individual BUM frames within the data centers.

FIG. 3is a block diagram illustrating an exemplary router80capable of performing the disclosed techniques. In general, router80may operate substantially similar to PEs6ofFIG. 1

In this example, router80includes interface cards88A-88N (“IFCs88”) that receive multicast packets via incoming links90A-90N (“incoming links90”) and send multicast packets via outbound links92A-92N (“outbound links92”). IFCs88are typically coupled to links90,92via a number of interface ports. Router80also includes a control unit82that determines routes of received packets and forwards the packets accordingly via IFCs88.

Control unit82may comprise a routing engine84and a packet forwarding engine86. Routing engine84operates as the control plane for router80and includes an operating system that provides a multi-tasking operating environment for execution of a number of concurrent processes. Routing engine84may implement one or more routing protocol102to execute routing processes. For example, routing protocols102may include Border Gateway Protocol (BGP)103, for exchanging routing information with other routing devices and for updating routing information94. In addition, routing protocols102may include PIM104, and specifically PIM-SM, for routing multicast traffic in accordance with the techniques described herein.

Routing information94may describe a topology of the computer network in which router80resides, and may also include routes through the shared trees in the computer network. Routing information94describes various routes within the computer network, and the appropriate next hops for each route, i.e., the neighboring routing devices along each of the routes. Routing engine84analyzes stored routing information94and generates forwarding information106for forwarding engine86. Forwarding information106may associate, for example, network destinations for certain multicast groups with specific next hops and corresponding IFCs88and physical output ports for output links92. Forwarding information106may be a radix tree programmed into dedicated forwarding chips, a series of tables, a complex database, a link list, a radix tree, a database, a flat file, or various other data structures.

In the illustrated example ofFIG. 2, forwarding information106includes forwarding rules107. For example, PIM-SM104may generate and store forwarding rules107to include modified EVPN BUM traffic forwarding rules. That is, according to forwarding rules107, as an active-active PE router for a multi-homed VXLAN, forwarding unit86of router80may forward BUM traffic from the EVPN23into the VXLAN for transports through data centers5. In other words, forwarding unit86may apply the modified forwarding rules107to forward all BUM traffic from EVPN23to underlay tunnels of the multi-homed VXLANs within data centers5regardless of DF status.

The architecture of router80illustrated inFIG. 2is shown for exemplary purposes only. The invention is not limited to this architecture. In other examples, router80may be configured in a variety of ways. In one example, some of the functionally of control unit82may be distributed within IFCs88. In another example, control unit82may comprise a plurality of packet forwarding engines operated as slave routers.

Control unit82may be implemented solely in software, or hardware, or may be implemented as a combination of software, hardware, or firmware. For example, control unit82may include one or more processors which execute software instructions. In that case, the various software modules of control unit82may comprise executable instructions stored on a computer-readable medium, such as computer memory or hard disk.

FIG. 3is a flow diagram illustrating example operation of a router, such as any of PE routers6ofFIG. 1, in accordance with the techniques described herein.

Initially, a router receives configuration information specifying BUM traffic forwarding rules as described herein (100). The forward rules may, for example, specify that when operating as a VTEP for a VXLAN of a data center that is connected to a remote data center via an EVPN, the router is to forward BUM traffic from the EVPN into the VXLAN toward the data center according to EVPN BUM forwarding rules regardless of whether the router is configured as a designated forwarder (DF) for a plurality of multi-homed routers coupling the data center to the EVPN. The router may receive the configuration information from a centralized controller, such as a software defined networking (SDN) controller, from a management system via a configuration protocol (e.g., SNMP), from a local interface or other example mechanisms.

Once configured and operational, the router operates as a VTEP to establish VXLAN tunnels established using protocol independent multicast-sparse mode (PIM-SM) with transport routers within the data center (102). In addition, the router establishes a layer two (L2) data center interconnect (DCI) between the data center running the VXLAN and the second, remote data center (104). The DCI may, for example, be established using an Ethernet virtual private network (EVPN). As such, the router operates as one of a plurality of active-active routers that provided multihomed connectivity for the VXLAN of the data center to the EVPN DCI providing connectivity to the remote data center.

Once the EVPN has been established, the router may receive BUM (broadcast, unknown unicast, and multicast) traffic from the remote data center by way of the EVPN DCI (106). In accordance with the process described above, multiple (S,G) multicast distribution trees may be transparently created with each of the trees rooted on a different EVPN routing instances of a multi-homed, active-active PE router. Moreover, this may occur even for routers that are not designated forwarders for the multi-homed PE routers operating as an Ethernet segment for the EVPN.

Each of the router operating as a root for the (S,G) multicast distribution tree operates to forward BUM traffic into the VXLAN toward the first data center according to EVPN BUM forwarding rules, wherein the EVPN BUM forwarding rules specify that any of the multi-homed PE routers may forward the BUM traffic into the VXLAN regardless of which of the PE routers is the DF (108). For example, operating as root for an (S, G) multicast distribution tree that has been created, any of the routers may forward the BUM traffic into an appropriate VXLAN tunnel even though the router is not the designated forwarder for the EVPN. Further, as described above, reverse path forwarding (RPF) check utilized within PIM-SM is leveraged to filter any redundant copies of BUM traffic received from the EVPN prior to the copies being delivered to the destinations.