Assisted Replication in Software Defined Networks

Abstract

Embodiments of the present disclosure relate to secondary replication in a software defined network. A software defined networking (SDN) controller is configured to receive a first multicast route and a second multicast route from a top of rack (TOR) switch. In response to determining that the first multicast route is a secondary replication route, the SDN controller is configured to add a first next hop indicated by the first multicast route to a next hop list for broadcast, unknown unicast, and multicast (BUM) services. In response to determining that the second multicast route is not a secondary replication route, the SDN controller is configured to avoid adding a second next hop indicated by the second multicast route to the next hop list. After adding the first next hop, the SDN controller is configured to supply the next hop list at the virtual router.

Description

[0001] This application is a divisional application of the invention patent application with application date of February 5, 2020, application number 202010080471.3, and invention name “Assisted Replication in Software-Defined Networks”. Technical Field

[0002] The present disclosure relates generally to computer networks and, more particularly, to multicasting for distributed applications. Background Art

[0003] A computer network is a collection of interconnected computing devices that exchange data and share resources. In a packet-based network, computing devices pass data by breaking it into small chunks called packets. Certain devices within the network, such as routers, maintain routing information that describes the route through the network. In this way, packets can be individually routed from source devices to destination devices on the network. The destination device extracts the data from the packets and assembles the data into its original form.

[0004] Customer devices can be connected to services provided by a data center. For example, a typical data center includes facilities that host applications and services for customers of the data center. For example, the data center hosts all infrastructure equipment, such as networking and storage systems, redundant power supplies, and environmental controls. In a typical data center, clusters of storage systems and application servers are interconnected via a high-speed switching fabric that is provided by one or more layers of physical network switches and routers. More complex data centers provide infrastructure throughout the world to subscriber support equipment located in various physical hosting facilities.

[0005] Software Defined Networking (SDN) platforms can be used in data centers, and in some cases, a logically centralized and physically distributed SDN controller and a distributed forwarding plane in a virtual router can be used, which extends the network from the physical routers and switches in the data center to a virtual overlay network hosted in a virtualized server. The SDN controller provides management, control, and analysis functions for the virtualized network, and orchestrates the virtual routers by communicating with them.

[0006] Using multicast, a network distributes multicast packets to a collection of interested receivers that may be located on different subnets and configured as members of a multicast group. In some examples, the network that distributes the multicast packets may include a virtual private network (VPN), which can be used to extend two or more remote layer 2 (L2) customer networks (e.g., a source VPN site and a receiver VPN site) in a transparent manner (i.e., as if the network did not exist) through an intermediate layer 3 (L3) network (commonly referred to as a provider network) such as the Internet. In particular, the VPN transports L2 communications, such as "frames," between the customer networks via the network.

[0007] SDN platforms can use assisted multicast replication, which selects nodes to perform replication. For example, the SDN platform can direct broadcast, unknown unicast, and multicast (BUM) traffic to a single Ethernet VPN (EVPN) core replicator instead of sending BUM traffic to all provider edges (PEs). In this way, assisted multicast replication can help scale BUM traffic forwarding to endpoints connected to top-of-rack (TOR) switches.

[0008] The SDN platform can use edge replication multicast for VPN protocol (ERMVPN), which provides edge replication multicast using edge replication multicast tree (ERM tree). For example, the SDN platform can construct an ERM tree for each multicast group using, for example, multi-protocol label switching (MPLS) labels to identify the ERM tree at each hop. The nodes in the ERM tree can act as VPN forwarding with local reception for a specific group. In this way, ERMVPN can help scale BUM traffic forwarding to virtual machines (VMs) and / or containers distributed across different servers (e.g., virtual routers) in a cluster. Summary of the invention

[0009] In general, the present disclosure describes techniques for scaling BUM traffic forwarding to endpoints connected to a top-of-rack (TOR) switch and virtual machines (VMs) and / or containers within a single environment. In some instances, forwarding BUM traffic to a TOR switch may conform to an auxiliary replication protocol, such as the auxiliary replication protocol described in "Optimized Ingress Replication solutionfor EVPN" published by Rabadan et al. in draft-ietf-bess-evpn-optimized-ir-06 of the BESS working group on October 19, 2018 (referred to herein as "auxiliary replication technology" or simply "AR technology"), the entire contents of which are incorporated herein by reference (hereinafter, referred to as the "optimized IR draft").

[0010] In some instances, forwarding BUM traffic to VMs and / or containers may conform to an edge replication multicast protocol, such as the edge replication multicast for VPN protocols described in “Edge multicast replication for BGP IP VPNs” by P. Marques et al., published in draft-marques-l3vpn-mcast-edge-01 of the Network Working Group, June 2012 (referred to herein as “ERMVPN technology”), the entire contents of which are incorporated herein by reference. A source VPN site outside of a data center may include an ingress multicast routing device, such as a provider edge (PE) device, which in some instances may implement a multicast protocol for VPNs, such as the Border Gateway Protocol (BGP) / Multiprotocol Label Switching (MPLS) Internet Protocol (IP) Virtual Private Network (VPN) service described in "Multicast in MPLS / BGP IP VPNs," Internet Engineering Task Force Request for Comments 6513, February 2012, E. Rosen et al., which supports multicast referred to as a multicast VPN (MVPN), the entire contents of which are incorporated herein by reference, to send multicast traffic over the L3 VPN network. In this way, the source VPN site can send multicast traffic that may have originated from the multicast source device to receivers of the multicast group.

[0011] As further described in the present disclosure, a controller (e.g., a software defined networking (SDN) controller) can help scale BUM traffic forwarding to endpoints connected to TOR switches and VMs and / or containers within a single environment. For example, in response to determining that a multicast route is a secondary replication route, the SDN controller can add a next hop to a list of next hops for broadcast, unknown unicast, and multicast (BUM) traffic, and in response to determining that the multicast route is not a secondary replication route, avoid adding the next hop. In this way, the number of next hops in the next hop list can be reduced, which helps improve scaling.

[0012] In one example, a method includes: receiving, by an SDN controller of a data center including one or more devices, a first multicast route and a second multicast route from a TOR switch, the one or more devices each including one or more virtual routers configured thereon; in response to determining that the first multicast route is a secondary replication route, adding, by the SDN controller, a first next hop indicated by the first multicast route to a next hop list for a BUM service; in response to determining that the second multicast route is not a secondary replication route, avoiding, by the SDN controller, adding, by the SDN controller, a second next hop indicated by the second multicast route to a next hop list for the BUM service; and after adding the first next hop, providing, by the SDN controller, the next hop list at a virtual router in one or more virtual routers.

[0013] In another example, an SDN controller of a data center includes one or more devices, each of which includes one or more virtual routers configured thereon, the SDN controller being configured to: receive a first multicast route and a second multicast route from a TOR switch; in response to determining that the first multicast route is a secondary replication route, add a first next hop indicated by the first multicast route to a next hop list for BUM services; in response to determining that the second multicast route is not a secondary replication route, avoid adding a second next hop indicated by the second multicast route to the next hop list for BUM services; and after adding the first next hop, provide the next hop list at a virtual router in the one or more virtual routers.

[0014] In yet another example, a computer-readable storage medium having instructions stored thereon, which, when executed, causes an SDN controller of a data center including one or more devices (each including one or more virtual routers configured thereon) to: receive a first multicast route and a second multicast route from a TOR switch; in response to determining that the first multicast route is a secondary replica route, add a first next hop indicated by the first multicast route to a next hop list for BUM services; in response to determining that the second multicast route is not a secondary replica route, avoid adding a second next hop indicated by the second multicast route to the next hop list for BUM services; and after adding the first next hop, provide the next hop list at a virtual router in one or more virtual routers.

[0015] The details of one or more examples of the technology of the present disclosure are set forth in the following drawings and description. Other features, objects, and advantages of the technology will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 is a block diagram illustrating an example network in which the techniques described herein may be implemented.

[0017] Figure 2 The present invention further illustrates the technology described in the present invention in detail. Figure 1 A block diagram of an example implementation of a data center.

[0018] Figure 3 The present invention further illustrates the technology described in the present invention in detail. Figure 1 to Figure 2 A block diagram of an example of an SDN controller.

[0019] Figure 4 The present invention further illustrates the technology described in the present invention in detail. Figure 3 A block diagram of an example of a control node of an SDN controller.

[0020] Figure 5 The present invention further illustrates the technology described in the present invention in detail. Figures 1 to 4 A block diagram of an example of a device.

[0021] Figure 6 is a flow diagram illustrating example operation of a network device in accordance with the techniques described in this disclosure.

[0022] Like reference numerals refer to like elements throughout the drawings and description. DETAILED DESCRIPTION

[0023] Figure 1 is a block diagram illustrating an example network 2 in which examples of the techniques described herein may be implemented. Figure 1 The network 2 in the example includes data centers 10A to 10X (collectively referred to as “data centers 10 ”) interconnected with each other and with a customer network 6 associated with one or more customer devices 4 (“customer devices 4 ”) via a service provider network 8 .

[0024] exist Figure 1 In the example of , network 2 includes a customer network 6 that provides connectivity to a data center 10 to one or more customers via a service provider network 8. For example, a customer may represent an enterprise, a government, a residential subscriber, or a mobile subscriber. For example, customer device 4 may be a personal computer, a laptop computer, or other type of computing device associated with a customer. In addition, customer device 4 may include a mobile device that accesses data services of service provider network 8 via a radio access network (RAN). Example mobile subscriber devices include mobile phones, laptop or desktop computers with, for example, a 3G or 4G wireless card, a netbook with wireless capabilities, a video gaming device, a pager, a smart phone, a personal data assistant (PDA), and the like. Each customer device 4 may run a variety of software applications, such as word processing and other office support software, web browsing software, software that supports voice calls, video games, video conferencing, and email, and the like. In Figure 1In the example of , customer network 6 can operate independently of other networks, such as service provider network 8 and data center 10.

[0025] The service provider network 8 provides packet-based connectivity to the customer devices 4 attached to the customer network 6 for accessing the data center 10. The service provider network 8 may be coupled to one or more networks managed by other providers and may thus form part of a large public network infrastructure, such as the Internet. The service provider network 8 represents a layer 3 (L3) network, where references to layers followed by numbers refer to corresponding layers in the open system interconnection (OSI) model. The service provider network is an L3 network because it inherently supports L3 operations as described in the OSI model. Common L3 operations include those performed according to L3 protocols such as the Internet Protocol (IP). L3 is also referred to as the "network layer" in the OSI model and as the "IP layer" in the TCP / IP model, and throughout this disclosure, the term L3 may be used interchangeably with "network layer" and "IP". The service provider network 8 may also implement multi-protocol label switching (MPLS) forwarding, and in such instances, may be referred to as an MPLS network or MPLS backbone network. The service provider network 8 may alternatively be referred to as an "MPLS / IP core network". Although the service provider network 8 is illustrated as a single network between the data center 10 and the customer network 6 , the service provider network 8 may include multiple service provider networks to connect one or more customer devices 4 with the data center 10 .

[0026] A provider edge (PE) device 11 of the service provider network 8 provides access to the data center 10A to the customer device 4 via the service provider network 8. The PE device 11 can interconnect the customer network 6 and the data center 10 through the service provider network 8 using VPN technology. Figure 1 In the example of , PE device 11 may represent a router, switch, or other suitable network device that provides multicasting across service provider network 8 between VPN sites, as further described below.

[0027] Each data center 10 may, for example, host infrastructure equipment such as networking and storage systems, redundant power supplies, and environmental controls. In some examples, each data center 10 may represent one of many geographically distributed network data centers. In some examples, each data center 10 may be a separate network server, network peer, or other. Figure 1As illustrated in the example of , each data center 10 can be a facility that provides network services to client devices 4. For example, a network data center can host web services for multiple enterprises and end users. Other example services may include data storage, virtual private networks, business engineering, file services, data mining, scientific computing, or supercomputing, etc. Client devices 4 are connected to gateway devices 12 via customer networks 6 and service provider networks 8 to receive connectivity to services provided by data centers 10. Gateway devices 12 redirect business flows to and from one or more data centers 10 that provide network services.

[0028] In this example, each data center 10 includes a collection of storage systems and application servers, such as devices 26A to 26N (collectively referred to as "devices 26"), interconnected via a high-speed switching structure 14, which is provided by one or more layers of physical network switches and routers. The devices 26 act as computing nodes and / or servers for the data center. The terms "computing node" and "server" are used interchangeably herein to refer to the devices 26. Each of the devices 26 can provide an operating environment for executing one or more customer-specific virtualized entities, such as virtual machines ("VMs"), containers, etc. In some examples, the devices 26 can be bare metal servers (BMS).

[0029] The switch fabric 14 is provided by a collection of interconnected top-of-rack (TOR) switches 16A to 16N (collectively, "TOR switches 16") coupled to a distribution layer of rack switches 18A to 18N (collectively, "rack switches 18"). For example, although not shown, each data center 10 may also include one or more non-edge switches, routers, hubs, 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.

[0030] In this example, the TOR switch 16 and the shelf switch 18 provide redundant (multi-homed) connectivity to the device 26 with the IP fabric 20 and the service provider network 8. The shelf switch 18 aggregates traffic flows and provides high-speed connectivity between the TOR switches 16. The TOR switch 16 can be a network device that provides layer 2 (e.g., MAC) and / or layer 3 (e.g., IP) routing and switching functionality. The TOR switch 16 and the shelf switch 18 can each include one or more processors and memory and be capable of executing one or more software processes. The shelf switch 18 is coupled to the IP fabric 20, which performs layer 3 routing to route network traffic between the data center 10 and the customer device 4 via the service provider network 8.

[0031] The data center 10 may include a software defined network ("SDN") platform to control and manage network behavior. In some cases, the SDN platform includes a logically centralized and physically distributed SDN controller (e.g., SDN controller 23) and a distributed forwarding plane in the form of virtual routers (e.g., virtual routers 28A to 28N (collectively referred to as "VR 28")) that extends the network from physical routers and switches in the data center switching structure to a virtual overlay network hosted in a virtualized server. According to one or more examples of the present disclosure, the SDN controller 23 facilitates the operation of one or more virtual networks within each data center 10 (such as data center 10A). A virtual network is a logical construct implemented above the physical network of the data center 10A. In some examples, the virtual network can be implemented as a virtual private network (VPN), a virtual LAN (VLAN), etc. In some examples, the SDN controller 23 can operate in response to configuration input received from the orchestration engine 22, which in turn operates in response to configuration input received from the network administrator 21. Additional information regarding the SDN controller 23 operating in conjunction with other devices or other software defined networks in the data center 10A is found in International Application No. PCT / US2013 / 044378, filed on June 5, 2013, entitled PHYSICAL PATH DETERMINATION FOR VIRTUAL NETWORK PACKET FLOWS, the contents of which are set forth in their entirety herein.

[0032] In some examples, the orchestration engine 22 manages application layer functions of the data center 10, such as managing computing, storage, networking, and application resources executed on the servers 12. For example, the orchestration engine 22 can attach a virtual machine (VM) to a tenant's virtual network and typically manage the startup, migration, and decomposition of the VM as needed. Each virtual machine can be referred to as a virtualized application workload (or just an application workload) and typically represents a virtualized execution element, such as a VM or a container. The orchestration engine 22 can connect the tenant's virtual network to some external network, such as the Internet or a VPN. The orchestration engine 22 can deploy network services (e.g., a load balancer) in the tenant's virtual network.

[0033] In some examples, the SDN controller 23 is a low-level controller that is tasked with managing the network and networking services of the data center 10A, and in particular, managing the switch fabric 14 that provides connectivity between devices 26. The SDN controller 23 utilizes a set of communication protocols to configure and control the routing and switching elements of the switch fabric 14 to create an overlay network, which generally refers to a set of tunnels used to transport packets to and from the devices 26 within the data center 10A.

[0034] For example, one such communication protocol used to configure the network (e.g., switch fabric 14, IP fabric 20, etc.) may include a messaging protocol such as Extensible Messaging and Presence Protocol (XMPP). For example, the SDN controller 23 implements high-level requests from the orchestration engine 22 by configuring the physical devices of the data center 10 (e.g., TOR switches 16, rack switches 18, and switch fabric 14; physical routers; physical service nodes such as firewalls and load balancers; and virtual services such as virtual firewalls in VMs). The SDN controller 23 maintains routing, networking, and configuration information within a state database. The SDN controller 23 passes the appropriate subset of routing information and configuration information from the state database to a virtual router (VR) agent on each device 26, such as virtual agents 27A to 27N (collectively referred to as "VA 27").

[0035] Typically, for example, traffic between any two network devices (such as, for example, between network devices (not shown) within IP fabric 20 or between device 26 and client device 4 or between devices 26) can traverse the physical network using many different paths. A packet flow (or "flow") can be defined by five values ​​used in a header or "five-tuple" of a packet, namely, the protocol, source IP address, destination IP address, source port, and destination port used to route the packet through the physical network. For example, the protocol specifies a communication protocol, such as the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP), and the source port and destination port refer to the source port and destination port of a connection. A collection of one or more packet data units (PDUs) that match a particular flow entry represents a flow. Flows can be roughly classified using any parameters of the PDU, such as source and destination data link (e.g., MAC) and network (e.g., IP) addresses, virtual local area network (VLAN) tags, transport layer information, multi-protocol label switching (MPLS) or generalized MPLS (GMPLS) labels, and the ingress port of the network device receiving the flow. For example, a flow may be all PDUs transmitted in a TCP connection, all PDUs originated from a specific MAC address or IP address, all PDUs with the same VLAN tag, or all PDUs received at the same switch port.

[0036] As described above, each of the devices 26 includes a corresponding virtual router 28 that executes multiple routing instances for corresponding virtual networks within the data center 10A and routes packets to appropriate VMs executing within the operating environment provided by the device 26. For example, a packet received by the virtual router 28A of the device 26A from the underlying physical network structure may include an outer header to allow the physical network structure to tunnel the payload or "inner packet" to the physical network address of the network interface of the device 26A executing the virtual router 28A. The outer header may include not only the physical network address of the network interface of the device 26A, but also a virtual network identifier that identifies one of the virtual networks and the corresponding routing instance executed by the virtual router, such as a VxLAN tag or a multi-protocol label switching (MPLS) label. The inner packet includes an inner header with a destination network address that conforms to the virtual network addressing space for the virtual network identified by the virtual network identifier.

[0037] exist Figure 1 In the example of , client device 4 can act as a source of broadcast, unknown unicast, and multicast (BUM) traffic, such as multicast traffic (which may also be referred to herein as a "multicast source" or "multicast sender"), to be delivered from a source VPN site to a receiver at a receiver VPN site, such as data center 10A. Typically, multicast network traffic is associated with a particular multicast group. More specifically, a multicast traffic is typically specified by a unique combination of a particular multicast group and a particular source for the multicast group. For example, a multicast network traffic, such as a particular multicast stream of content, can be uniquely specified with a (source, group) (i.e., (S, G)) tag to specify the source (S) of the traffic and the multicast group (G) to which the traffic belongs.

[0038] exist Figure 1 In the example of , network 2 may include a multicast virtual private network (MVPN) 42, in which routing devices are configured to send multicast traffic between a source and a receiver through a service provider network 8 running a layer 3 virtual private network. In order to support the delivery of multicast traffic through network routing running a layer 3 virtual private network, the multicast routing device (e.g., PE device 11) may implement a multicast protocol such as that described in "BGP / MPLS IP Virtual Private Networks (VPNs)" by E. Rosen et al., published in RFC 4364 of the Internet Engineering Task Force (IETF) in February 2006; and "Multicast in MPLS / BGP IP VPNs" by E. Rosen et al., published in RFC 6513 of the IETF in February 2012, each of which is incorporated herein by reference in its entirety. RFC 6513 is referred to herein as the "MVPN protocol." Although Figure 1It is illustrated as implementing the MVPN protocol to provide multicast in VPN, but the techniques described herein may also be applicable to a network where the service provider network 8 implements the multicast technology of the EVPN protocol instead of the MVPN protocol.

[0039] exist Figure 1 In the example of , the PE device 11 of the MVPN 42 can implement the MVPN protocol to forward IP multicast traffic from its local source VPN site (e.g., customer network 6) to a remote receiver VPN site (e.g., data center 10A). By implementing the MVPN protocol, the PE device 11 can distribute VPN routing information on the service provider network 8 and use MPLS to forward the multicast traffic on the service provider network 8 to the remote VPN site, e.g., data center 10A. That is, the routing device outside the data center 10A uses the MVPN protocol to forward IP multicast traffic through the service provider network 8 running the L3 VPN.

[0040] As an example, the PE device 11 may instantiate a provider multicast service interface (PMSI) that provides an overlay network on the service provider network 8 to tunnel multicast traffic from the customer network 6 to the data center 10A on the service provider network 8 (referred to herein as a "P tunnel"). To instantiate the PMSI, the PE device 11 typically uses, for example, a Border Gateway Protocol (BGP) auto-discovery (AD) process or other auto-discovery techniques to discover other routing devices of the MVPN instance to establish a P tunnel between the routing devices. For example, the routing devices of the MVPN instance may advertise intra-autonomous system I-PMSI AD routes (MVPN type 1 routes) or inter-autonomous system I-PMSI AD routes (MVPN type 2 routes). Multicast traffic may be tunneled using, for example, a Resource Reservation Protocol with Traffic Engineering (RSVP-TE) label switched path (LSP), a protocol independent multicast (PIM) tree, a multicast label distribution protocol (mLDP) point-to-multipoint (P2MP) tree, and / or a mLDP multipoint-to-multipoint (MP2MP) LSP.

[0041] The routing devices of the MVPN instance can exchange multicast state information (e.g., join / leave messages) for their local VPN sites to enable multicast traffic to be tunneled through the P tunnel. Typically, routing devices implementing the MVPN protocol are required to implement protocol independent multicast (PIM) to learn the multicast state information of the VPN sites to create a multicast distribution tree for the multicast state. However, in some examples, the receiver VPN site (e.g., data center 10A) does not implement PIM.

[0042] exist Figure 1In an example of the present invention, data center 10A may include a multicast replication network 40 that provides multicast services using an edge replication multicast tree (referred to herein as an "ERM tree") on a per-flow basis. An example of edge replication multicast is described in "Edge multicast replication for BGP IP VPNs" by P. Marques, published in draft-marquest-l3vpn-mcast-edge-01 of the Internet Draft of the Network Working Group in June 2012, the entire contents of which are incorporated herein by reference. The technology described in the above draft is referred to herein as "ERMVPN technology".

[0043] Using the ERMVPN technique, an edge replication multicast tree is constructed for an overlay network within the data center 10A that does not rely on the underlying physical network to provide multicast capabilities. For example, the edge replication multicast tree may specify replication for one or more nodes (e.g., VR 28). VR 28 of device 26 may use the edge replication multicast tree to replicate multicast traffic for its local receivers (e.g., VMs). That is, the ERMVPN technique is used to replicate multicast traffic within the data center 10A.

[0044] In some instances, ERMVPN technology is used to provide a more efficient way to replicate multicast traffic. For example, an edge-replicated multicast tree places an upper limit on the number of replicas that a particular node (e.g., VR 28A) must generate, in contrast to ingress replication where an ingress device generates a replica packet for each receiver in a multicast group. An edge-replicated multicast tree can include a K-ary tree where each virtual router within a data center is responsible for generating up to K replicas. For a multicast group with m receivers, the height of the tree is approximately "log K(m)", where the height of the tree determines the maximum number of forwarding hops required to deliver a packet to a receiver.

[0045] To facilitate configuration of the edge replication multicast tree, the SDN controller 23 may generate the edge replication multicast tree based on multicast group membership messages (eg, Internet Group Management Protocol (IGMP) join / leave messages) of receivers such as VMs. "Host Extensions for IP Multicasting", RFC 1112, Internet Engineering Task Force (IETF), August 1989; "Internet Group Messaging Protocol, Version 2", RFC 2236, IETF, November 1997; "Internet Group Management Protocol, Version 3", RFC 3376, IETF, October 2002; and "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast Message Access Protocol", RFC 4604, IETF, August 2006. Additional details of IGMP are described in "IGMP and MLD Proxyfor EVPN" published on draft-sajassi-bess-evpn-igmp-mld-proxy-01 on October 28, 2016, the entire contents of each of which are incorporated herein by reference.

[0046] For example, when one or more VMs are provisioned on device 26A, the VMs may send an IGMP join message to device 26A to join the multicast group to receive multicast services. Virtual agent 27A of device 26A may monitor the IGMP message, convert the IGMP message into an ERMVPN join message, and send the ERMVPN join message to SDN controller 23 (in Figure 1 Similarly, the virtual agent 27N of the device 26N may monitor the IGMP join message of the VM, convert the IGMP message into an ERMVPN join message, and use XMPP to send the ERMVPN join message (in Figure 13 (also illustrated as message 32) is sent to SDN controller 23. Using the multicast state information received from device 26, SDN controller 23 can configure an edge replication multicast tree that is sent to virtual agent 27 of device 26 so that VR 28 of device 26 can use the edge replication multicast tree to perform edge replication multicast.

[0047] The SDN controller 23 may be configured to exchange BGP / EVPN information of all leaf switches (e.g., TOR switches 16) and spine switches (e.g., rack switches 18) with the VRs 28, and to exchange XMPP information (e.g., compute) with all VRs 28. In this way, the SDN controller 23 may be positioned to deliver both ERMVPN and EVPN-AR solutions.

[0048] For example, the SDN controller 23 may be configured to use EVPN-assisted multicast replication (AR) to scale BUM traffic forwarding to endpoints (e.g., VR 28) connected to TOR switches 16 that may not support ERMVPN. For example, instead of using ingress replication where the leaf device (e.g., TOR switch 16A) and each spine device (e.g., rack switch 18) replicate BUM traffic, the leaf device (e.g., TOR switch 16A) and a designated auxiliary replication device (e.g., rack switch 18A) replicate BUM traffic. In this way, replication is moved from the leaf to the spine to improve scalability.

[0049] In some examples, the SDN controller 23 may be configured to use ERMVPN to scale forwarding of BUM traffic to VMs and / or containers of the device 26. For example, the SDN controller 23 may compute a next hop list (referred to herein as an "olist") and program each of the VRs 28 with the olist when sending BUM traffic. Thus, the SDN controller 23 may arrange all other computing nodes (e.g., VRs 28) as an ERM tree, where each computing node in the olist includes a parent node and a child node as a next hop for replicating the BUM traffic.

[0050] However, without the techniques described herein, the SDN controller 23 may construct an ERM tree for each TOR switch 16, resulting in poor scalability. For example, in response to an EVPN type 3 inclusive multicast route from one of the TOR switches 16, the SDN controller 23 may add the EVPN type 3 inclusive multicast route to the olist and program each of the VRs 28 with the olist when sending BUM traffic. Thus, if there are hundreds of TOR switches 16 in the switch fabric 14, each TOR switch 16 (including TOR switches that are not designated secondary replication devices for replicating BUM traffic) will be the next hop in the olist programmed in each vRouter of the VR 28, resulting in poor scalability.

[0051] As further described herein, when the auxiliary replication technology (also referred to herein as "AR") is used, the SDN controller 23 can be configured to ensure that only AR next hops are added to the olist, and to avoid adding all other next hops (i.e., non-AR next hops) to the olist. For example, in response to determining based on the XMPP information for applying AR that the first multicast route advertised by the TOR switch 16A is designated as a secondary replication route for replicating the BUM service of VR 28A, and the second multicast route advertised by the TOR switch 16A is not designated as a secondary replication route, the SDN controller 23 can be configured to use only the next hop for the first route of the next hop list. In this way, the number of next hops for each of the VRs 28 to replicate packets for the BUM service is reduced, because the VR 28 can only replicate packets along the route designated for auxiliary replication for replicating the BUM service (and to the corresponding parent VR and child VR). In this way, the technology for BUM service forwarding described herein can be effectively scaled to bare metal servers (e.g., TOR leaves) and VMs / containers in the same environment.

[0052] Figure 2 It is further illustrated in detail Figure 1 A block diagram of an example implementation of a data center 10A is shown. Figure 2In the example of , the data center 10A includes an interconnect that extends the switching fabric 14 from the physical switches 16, 18 to a software or virtual router 28. The virtual router 28 dynamically creates and manages one or more virtual networks 42 that can be used for communication between application instances. In one example, the virtual router 28 implements the virtual network as an overlay network that provides the ability to decouple the virtual address of the application from the physical address (e.g., IP address) of one of the devices 26A-26N on which the application is executing. Each virtual network can use its own addressing and security scheme and can be considered orthogonal to the physical network and its addressing scheme. Various techniques can be used to transport packets within and on the virtual network 42 through the physical network.

[0053] Each virtual router 28 may be executed within a hypervisor, a host operating system, or other component of each device 26. Each device 26 may represent an x86 or other general or specialized server capable of executing a virtual machine 44. Figure 2 In the example of , device 26A executes within a hypervisor 46 (also commonly referred to as a virtual machine manager (VMM)), which provides a virtualization platform that allows multiple operating systems to run concurrently on one of the devices 26. Figure 2 In the example of , device 26A manages virtual networks 42, each of which provides a network environment for executing one or more virtual machines (VMs) 44 on top of a virtualization platform provided by a hypervisor 46. Each VM 44 is associated with one of the virtual networks VN0-VN2, and can represent a tenant VM that runs a client application (such as a web server, a database server, an enterprise application) or hosts a virtualized service for creating a service chain. In some cases, any one or more of the devices 26 or another computing device can directly host the client application, that is, not hosted as a virtual machine. In some cases, some of the VMs 44 can represent containers, which is another form of a virtualized execution environment. That is, virtual machines and containers are examples of virtualized execution environments for executing application workloads.

[0054] In general, each VM 44 may be any type of software application and may be assigned a virtual address for use within a corresponding virtual network 42, where each virtual network may be a different virtual subnet provided by virtual router 28A. VM 44 may be assigned, for example, its own virtual layer 3 (L3) IP address for sending and receiving communications, but may not be aware of the IP address of the physical device 26A on which the virtual machine is executing. In this manner, a "virtual address" is an address for an application that is different from a logical address for an underlying physical computer system (e.g., device 26A).

[0055] In one implementation, each device 26 includes a corresponding one of the virtual network (VN) agents 27A-27N (collectively referred to as "VN agents 27") that controls the virtual network 42 and coordinates the routing of data packets within the device. Typically, each VN agent 27 communicates with a virtual SDN controller 23, which generates commands to control the routing of packets through the data center 10A. The VN agent 27 can act as a proxy for control plane messages between the virtual machine 44 and the SDN controller 23. For example, VM 44 can request to send a message using its virtual address via VN agent 27A, and VN agent 27A can in turn send the message and request to receive a response to the message for the virtual address of VM 44 that originated the first message. In some cases, VM 44 can call a procedure or function call presented by an application programming interface of VN agent 27A, and VN agent 27A can also handle the encapsulation of the message, including addressing.

[0056] In one example, a network packet (e.g., a layer 3 (L3) IP packet or a layer 2 (L2) Ethernet packet) generated or consumed by an application instance executed by a virtual machine 44 within a virtual network domain may be encapsulated in another packet (e.g., another IP or Ethernet packet) transported by a physical network. The packets transported in the virtual network may be referred to herein as "inner packets," while the physical network packets may be referred to herein as "outer packets" or "tunnel packets."

[0057] Encapsulation and / or decapsulation of virtual network packets within physical network packets may be performed within virtual router 28, e.g., within a hypervisor or host operating system running on each device 26. For example, virtual router 28 may transport packets within and across virtual network 42 through a physical network using MPLSoUDP or MPLSoGRE.

[0058] As mentioned above, the SDN controller 23 provides a logically centralized controller for facilitating the operation of one or more virtual networks within the data center 10A. For example, the SDN controller 23 can maintain a routing information base, such as one or more routing tables that store routing information for physical networks and one or more networks of the data center 10A. Similarly, the switches 16, 18 and the virtual router 28 maintain routing information, such as one or more routing tables and / or forwarding tables. In an example implementation, the virtual router 28A of the hypervisor 46 implements a network forwarding table (NFT) 40 for each virtual network 42. Typically, each NFT 40 stores forwarding information for the corresponding virtual network 42 and identifies where the data packet will be forwarded and whether the packet is encapsulated in a tunnel protocol, such as encapsulated with a tunnel header, which may include one or more headers for different layers of the virtual network protocol stack.

[0059] According to aspects of the techniques described herein, in one example, the SDN controller 23 includes an AR module 38 that can ensure that only AR next hops are added to the next hop list and avoid adding other next hops.

[0060] The AR module 38 can facilitate the configuration of the edge replication multicast tree based on the ERM tree information (e.g., IGMP join / leave messages) received from the device 26. As an example, VM 44 can send an IGMP join (or leave) to VR 28A. VR 28A terminates these IGMP messages, converts the information into an ERMVPN message, and sends the ERMVPN message to the SDN controller 23 using XMPP. More specifically, the VN agent 27A can listen to the IGMP join message of the VM 44 of the device 26A to request to join the multicast group to receive multicast services from the multicast source. The VN agent 27A can convert the IGMP join message into an ERMVPN join message and send the ERMVPN join message (e.g., message 32) to the SDN controller 23 using XMPP. Similarly, the VN agent 27N can listen to the IGMP join message of the VM 44 of the device 26N to request to join the same multicast group. The VN agent 27N may convert information from the snooped IGMP join message to an ERMVPN join message and use XMPP to send the ERMVPN join message (e.g., message 32) to the SDN controller 23. The AR module 38 may use the multicast state information received from the VN agent 27 and configure an edge replication multicast tree for the virtual router of the device 26 to perform edge replication multicast for the VMs 44 belonging to the multicast group.

[0061] Figure 3 is a diagram illustrating the technology described herein. Figure 1 A block diagram of an example implementation of an SDN controller. Figure 3 In the example of , the SDN controller 23 includes one or more analysis nodes 52A-52X (collectively referred to as "analysis nodes 52"), one or more configuration nodes 54A-54X (collectively referred to as "configuration nodes 54"), and control nodes 56A-56X (collectively referred to as "control nodes 56"). Typically, each of the nodes 52, 54, and 56 can be implemented as a separate software process, and the nodes can be distributed on multiple hardware computing platforms that provide an environment for executing software. Moreover, each node maintains state data 58, which can be stored in a centralized or distributed database. In some examples, the state database 58 is a NoSQL database. In some examples, the state database 58 is a database cluster.

[0062] Generally, analysis nodes 52 are tasked with collecting, storing, correlating, and analyzing information from virtual and physical network elements within data center 10. This information may include statistics, logs, events, and errors used to manage routing and network configuration of data center 10. Analysis nodes 52 store this information in state database 58.

[0063] Configuration node 54 converts the high-level data model of orchestration engine 22 into a low-level model suitable for interacting with network elements such as physical switches 16, 18 and VR agent 27. Configuration node 54 maintains a persistent copy of the configuration state of SDN controller 23 within state database 58.

[0064] The control nodes 56 implement a logically centralized control plane responsible for maintaining a temporary network state. The control nodes 56 interact with each other and with network elements, such as the VR agents 27 and virtual routers 28 (e.g., computing nodes) of the devices 26 to ensure that the network state is ultimately consistent with the desired state specified by the orchestration engine 22. Typically, the control nodes 56 receive configuration state information of the SDN controller 23 from the configuration node 54, and exchange routes with each other via IBGP to ensure that all control nodes 56 have the same network state. Further, the control nodes 56 exchange routes with the VR agents 27 on the devices 26 via XMPP. The control nodes 56 also pass configuration state information such as routing instances and forwarding policies to the VR agents 27, for example, via XMPP, for installation in the corresponding virtual routers 28. Further, the control nodes 56 exchange routes (e.g., MVPN routes) with the PE devices 11 via BGP, and exchange the configuration state of the SDN controller 32 with the service node 21 via NETCONF.

[0065] Configuration node 54 provides a discovery service that client device 4 can use to locate various services available within the network. For example, if VR agent 27A attempts to connect to control node 56A, it uses the discovery service provided by configuration node 54 to discover the IP address of control node 56A. Clients executing on VM 44 can locate service discovery servers within configuration node 54 using local configuration, Dynamic Host Configuration Protocol (DHCP), or Domain Name System (DNS).

[0066] In some examples, the configuration node 54 presents a northbound application programming interface (API) that interfaces with the orchestration engine 22. The orchestration engine 22 uses the interface to install the configuration state using the high-level data model. The configuration node 54 also includes a message bus to facilitate communication between internal components. The configuration node 54 also includes a converter that discovers changes in the high-level model of the orchestration engine 22 and converts these changes to corresponding changes in the low-level data model managed by the SDN controller 23. The configuration node 54 also includes an IF-MAP server that provides a southbound API to push the low-level configuration of the calculation down to the control node 56. In addition, the configuration node 54 includes a distributed application manager, which is used to assign unique object identifiers and implement transactions across the data center 10.

[0067] According to the technology disclosed herein, each control node 56 can be configured to receive multicast group membership messages, such as IGMP join messages, from device 26 via XMPP, generate a multicast replication tree (e.g., an edge replication multicast tree) based on the multicast group membership information and auxiliary replication routes, and send the ERM tree to an ingress multicast routing device, such as PE device 11.

[0068] As an example, the control node 56 establishes an XMPP session with the device 26 to receive the multicast group membership message of the ERMVPN. For example, the VM 44 can send an IGMP join (or leave) to the VR 28A. The VR 28A terminates these IGMP messages, converts the information into an ERMVPN message, and sends the ERMVPN message to the SDN controller 23 using XMPP. More specifically, the VN agent 27 can monitor the IGMP join message of the VM 44 to request to join the multicast group to receive the multicast service. The VN agent 27 can convert the IGMP join message into an XMPP message and send the XMPP message to the control node 56A.

[0069] As shown below Figure 4 As further described in, control node 56 may include an AR module to generate a multicast replication tree for device 26. The AR module may generate an edge multicast replication tree that uses the next hop for the secondary replication multicast route and avoids using the next hop for other multicast routes.

[0070] The control node 56 may also establish a BGP session with the PE device 11 to send information identifying the specified secondary replication device. For example, the control node 56 may use the EVPN BGP attributes for optimized ingress replication in accordance with the optimized IR draft. For example, the control node 56 may send a leaf auto-discovery (AD) route (e.g., a router advertisement, such as, for example, an MVPN type 4 route / PMSI tunnel advertisement route) to the PE device 11, which includes a label specifying whether each multicast route is a secondary replication route. For example, the router advertisement may include a tunnel type flag as described in the optimized IR draft. In this way, the control node 56 can use BGP / EVPN information for all leaf and spine switches to access information indicating the specified secondary replication device, and can also access the multicast replication tree for the device 26 using XMPP message exchange.

[0071] For illustrative purposes only, Figure 3 The architecture of the SDN controller 23 is shown in FIG. Figure 3 The techniques described in this disclosure are implemented in the exemplary data center 10 of the present invention and other types of data centers not specifically described herein. Nothing in this disclosure should be interpreted as limiting the techniques of this disclosure to Figure 3 Example architecture illustrated.

[0072] Figure 4 The present invention further illustrates the technology described in the present invention in detail. Figure 3 1 is a block diagram of an example of a control node 56. The control node 56A is configured to communicate with a variety of other types of nodes, including configuration nodes 54A-54X ("configuration nodes 54"), other control nodes 56B-56X, devices 26A-26N, and PE devices 11.

[0073] Control node 56A provides an operating environment for executing protocols 70. Protocols 70 may include, for example, XMPP process 70A, NETCONF protocol process 70B, BGP process 70C, IF-MAP process 70D, MVPN protocol 70E, and ERMVPN technology 70F.

[0074] The control node 56A receives the configuration state from the configuration node 54 using IF-MAP 70D. The control node 56A exchanges routes with other control nodes 56 using BGP 70C to ensure that all control nodes have the same network state. The control node 56A exchanges routes with the virtual router agent on the device 26 using XMPP 70A. The control node 56A also uses XMPP to send configuration state, such as routing instances and forwarding policies. The control node 56A exchanges routes with the PE device 11 using BGP 70C. The control node 56A also uses NETCONF 70B to send the configuration state to the PE device 11.

[0075] Control node 56A receives configuration information from one or more configuration nodes 54 using an interface to a metadata access point (IF-MAP) process 70D. IF-MAP process 70D may include circuitry for executing software instructions for sending and receiving communications according to the IF-MAP protocol from configuration nodes 54. IF-MAP process 70D stores the configuration information received from configuration nodes 54 in a configuration state 66 ("configuration state 66").

[0076] Control node 56A uses BGP process 70C to exchange BGP messages with BGP peers (including control nodes 56B-56X and PE device 11). BGP process 70C may include circuit means for executing software instructions for sending and receiving BGP messages with PE device 11 and control nodes 56B-56X according to the BGP protocol. BGP process 70C stores routing information received from BGP route advertisements from PE device 11 (e.g., MVPN type 1 or type 2AD routing) and control nodes 56B-56X to routing information 65.

[0077] Control node 56A exchanges messages in accordance with XMPP using XMPP process 70A with device 26. Control node 56A exchanges messages via XMPP sessions 64A-64N ("XMPP sessions 64"). Figure 3 The device 26 may correspond to Figures 1 to 3Device 26. XMPP process 70A may include circuit means for executing software instructions for exchanging XMPP messages with device 26 according to the XMPP protocol. XMPP is further described in detail in "Extensible Messaging and Presence Protocol (XMPP): Core" by P. Saint-Andre, published in IETF RFC 6120 in March 2011, the entire contents of which are incorporated herein by reference. Depending on the context, control node 56A (more specifically, XMPP process 70A of control node 56A) may act as an XMPP client or an XMPP server with respect to one of devices 26. For example, control node 56A may act as an XMPP server, and device 26 may be an XMPP client that subscribes to information published by control node 56A, such as configuration information from configuration state 66 of corresponding device 26 and routing information about corresponding device 26 from routing information 65. As another example, control node 56A may act as an XMPP client to one or more of devices 26 that are XMPP servers, where control node 56A subscribes to information published by device 26, such as routing information learned by device 26 from other sources. XMPP process 70A receives routes from device 26A via XMPP session 64A and stores the routes to routing information 65. The routes learned by XMPP process 70A may be leaked to BGP process 70C, which in turn may send it to its BGP peer BGP router advertisements, which advertise the routes in routing information 65 learned from device 26 via XMPP. In some examples, NETCONF process 70B of control node 56A enables control node 56A to communicate with PE device 11 via the NETCONF protocol.

[0078] The control node 56A may include an MVPN module 37 that manages an MVPN instance for the MVPN network 42 and an ERMVPN instance for the multicast replication network 40. To manage the MVPN instance, the MVPN module 37 may maintain an MVPN neighbor list, manage locally originated MVPN AD routes for discovering devices belonging to a given MVPN instance, manage locally originated leaf AD routes (e.g., MVPN type 4 routes). The MVPN module 37 may also listen to all changes to the MVPN instance (e.g., MVPN neighbor information), handle initialization or cleanup when MVPN configurations are added or deleted in a virtual network, and provide data for runtime inspection via introspection. MVPN module 37 may include, for example, MVPN information 76, which includes MVPN AD routes, such as intra-AS I-PMSI AD routes (e.g., type 1 MVPN AD routes) exchanged by devices within the same autonomous system (e.g., iBGP neighbors) to participate in the MVPN instance and / or inter-AS I-PMSI (e.g., type 2 MVPN AD routes) exchanged by devices within different autonomous systems (e.g., eBGP neighbors) to participate in the MVPN instance, as described in "BGP Encodings and Procedures for Multicast in MPLS / BGP IP VPNs" by R. Aggarwal et al., published in RFC 6514 of the Internet Engineering Task Force (IETF), February 2012, the entire contents of which are incorporated herein by reference. For example, MVPN module 37 may store in MVPN information 76 the IP addresses of routers (e.g., PE devices 11) belonging to the MVPN instance. MVPN information 76 may be stored in a series of tables, a database, lists, or various other data structures.

[0079] To maintain the ERMVPN instance, MVPN module 37 may maintain a list of multicast group membership messages received through the XMPP session with device 26 and listen to all changes to the ERMVPN instance (e.g., IGMP group membership information). For example, MVPN module 37 may store multicast group membership messages, such as IGMP join messages, in ERMVPN information 78. These routes may be added to ERMVPN information 78 as MVPN source tree join routes (e.g., MVPN type 7), as described in RFC 6514.

[0080] As previously described, devices 26 may each include a virtual agent (e.g., Figure 1VA 27 of device 26) to listen for IGMP joins for VM announcements. Each virtual agent of device 26 can send IGMP join messages through XMPP session 64. SDN controller 23A can receive IGMP join messages from device 26 through XMPP session 64 and store the information in ERMVPN information 78.

[0081] The MVPN module 37 of the SDN controller 23A may use the ERMVPN information 78 to generate a multicast replication tree 75 (or update an existing multicast replication tree 75 based on changes to the ERMVPN information 78). For example, the SDN controller 23A may generate a multicast replication tree 75 for each tenant in the data center 10A.<S,G> Combining to Generate a Multicast Replication Tree The SDN controller 23A may generate a multicast replication tree 75 using, for example, the ERMVPN technology 70F.

[0082] The MVPN module 37 may instruct the control node 56A to send configuration state information to the VR agent 27A of the device 26A using XMPP 70A to configure the virtual router 28A. For example, the control node 56A may send configuration state information that causes the virtual router 28A to receive multicast traffic from the gateway 12 via the GRE / UDP tunnel and then send the multicast traffic to its local receivers and the parent node of the virtual router 28A according to the multicast replication tree, which in turn replicates the multicast traffic to the local receivers (e.g., VM 44) and other virtual routers indicated as their parent / child nodes. More specifically, the control node 56A may send an XMPP message that is sent to the virtual router 28A of the device 26A, the XMPP message being encoded with input tunnel attributes that include the IP address of the tunnel endpoint (e.g., gateway 12) and the tunnel type (e.g., MPLS over GRE / UDP).

[0083] Figure 5 The present invention further illustrates the technology described in the present invention in detail. Figure 1 The computing device 500 may represent an example of a block diagram of a device. Figures 1 to 4 Any one of the devices 26.

[0084] exist Figure 5In the example of , the computing device 500 includes a system bus 542 that couples hardware components of the hardware environment of the computing device 500. The system bus 542 couples a memory 544, a network interface card (NIC) 506A to 508B (collectively referred to as "NIC 506"), a storage disk 507, and a multi-core computing environment 502 having multiple processing cores 508A to 508N (collectively referred to as "processing core 508"). The network interface card 506 includes an interface configured to exchange packets using a link of an underlying physical network. The multi-core computing environment 502 can include any number of processors and any number of hardware cores, for example, from four to thousands. Each processing core 508 each includes an independent execution unit to execute instructions that conform to the instruction set architecture of the core. The processing cores 508 can each be implemented as separate integrated circuits (ICs), or can be combined in one or more multi-core processors (or "many-core" processors) that are each implemented using a single IC (i.e., a chip microprocessor).

[0085] Disk 507 represents a computer-readable storage medium, which includes volatile and / or nonvolatile media and removable and / or non-removable media implemented in any method or technology for storing information (such as processor-readable instructions, data structures, program modules or other data). Computer-readable storage media include, but are not limited to, random access memory (RAM), read-only memory (ROM), EEPROM, flash memory, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by core 508.

[0086] The main memory 544 includes one or more computer-readable storage media, which may include random access memory (RAM), such as various forms of dynamic RAM (DRAM) (e.g., DDR2 / DDR3 SDRAM) or static RAM (SRAM), flash memory, or any other form of fixed or removable storage media that can be used to carry or store desired program code and program data in the form of instructions or data structures that can be accessed by the computer. The main memory 544 provides a physical address space consisting of addressable memory locations.

[0087] In some examples, memory 544 may represent a non-uniform memory access (NUMA) architecture presented to multi-core computing environment 502. That is, the memory access times of cores 508 to the various storage media that make up memory 544 may not be equal. In some instances, cores 508 may be configured to use the portion of memory 544 that provides the lowest memory latency to the core to reduce overall memory latency.

[0088] In some instances, the physical address space of the computer-readable storage medium can be shared between one or more cores 508 (i.e., shared memory). For example, cores 508A, 508B can be connected to one or more DRAM packages, modules, and / or chips (also not shown) representing a physical address space accessible by cores 508A, 508B via a memory bus (not shown). Although the physical address space can provide the lowest memory access time to cores 508A, 508B for any portion of memory 544, at least some of the remaining portions of memory 544 can be directly accessed by cores 508A, 508B. One or more of the cores 508 may also include L1 / L2 / L3 caches or a combination thereof. The corresponding caches of the cores 508 provide the cores 508 with the lowest latency memory access to any storage medium.

[0089] Memory 544, NIC 506, storage disk 507, and multi-core computing environment 502 provide an operating environment for executing a software stack of virtual router 520 and one or more virtual machines 510A to 510N (collectively referred to as "VM 510"). Virtual machine 510 may represent Figures 1 to 3 For example, VM 510 is a tenant VM that runs a customer application (such as a web server, a database server, an enterprise application) or hosts a virtualized service for creating a service chain. In one example configuration, Linux is the host operating system (OS).

[0090] The computing device 500 divides the virtual and / or physical address space provided by the main memory 544, and in the case of virtual memory, by the disk 507, into a user space 511 allocated for running user processes and a kernel space 512 which is protected and generally inaccessible to user processes. Figure 5 ) may be executed in kernel space 512 and may include, for example, Linux, Berkeley Software Distribution (BSD), another Unix variant kernel, or a Windows server operating system kernel available from Microsoft Corporation. In some instances, computing device 500 may execute a hypervisor (such as, Figure 2 The virtual machine 510 is managed by a hypervisor 46 of the present invention. Example hypervisors include Kernel-based Virtual Machine (KVM) for the Linux kernel, Xen, ESXi available from VMware, Windows Hyper-V available from Microsoft, and other open source and proprietary hypervisors. In some examples, dedicated hardware programmed with routing information such as FIB 524 can implement virtual router 520.

[0091] Eth0 514A and Eth1 514B represent devices according to the software device model and provide device driver software routines for processing packets for reception / transmission by the corresponding NIC 506. Packets received by NIC 506 from the underlying physical network structure of the virtual network may include an "external packet" to allow the physical network structure to tunnel the payload or an "internal packet" to the physical network address of one of the NICs 506. The external packet may include not only the physical network address, but also a multi-protocol label switching (MPLS) label or a virtual network identifier, such as a VxLAN tag, which identifies one of the virtual networks and the corresponding routing instance. The internal packet includes an internal header with a destination network address that conforms to the virtual network addressing space of the virtual network identified by the virtual network identifier. For example, the virtual router forwarding plane 528 may receive a packet with an external header from NIC 506a via Eth1, the external header including an MPLS label associated with the virtual router forwarding plane 528 using the routing instance 522A. The packet may have an inner header with a destination network address that is the destination address of VM 510A that taps into routing instance 522A via tap interface 546A.

[0092] In this example, virtual router 520 includes a kernel space 512 module: virtual router forwarding plane 528, and a user space 511 module: virtual network agent (VN agent) 530. Virtual router forwarding plane 528 performs the "forwarding plane" or packet forwarding functionality of virtual router 520, and VN agent 530 performs the "control plane" functionality of virtual router 520. VN agent 530 may represent Figure 2 An example instance of any VN Proxy 27.

[0093] Virtual router forwarding plane 528 is responsible for encapsulating packets to be sent to the overlay network and decapsulating packets to be received from the overlay network. Virtual router forwarding plane 528 assigns packets to routing instances, such as routing instances 522A-522C (collectively referred to as "routing instances 522") for corresponding virtual networks. Packets received from the overlay network are assigned to routing instances. Virtual interfaces to local virtual machines (e.g., VM 510) are bound to routing instances 522.

[0094] Each routing instance 522 includes a corresponding forwarding information base (FIB) 524A to 524C (collectively referred to as "FIB 524") and flow tables 526A to 526C (collectively referred to as "flow tables 526"). Although illustrated as separate data structures, flow table 526 may be a logical table implemented as a single table or other associated data structure in some instances, wherein entries for corresponding flow table 526 are identifiable by virtual network identifiers (e.g., VRF identifiers such as VxLAN tags or MPLS labels). FIB 524 includes a lookup table that maps a destination address to a destination next hop. The virtual router forwarding plane 528 performs a lookup of the destination address in FIB 524 and forwards the packet to the correct destination. The destination address may include a layer 3 network prefix or a layer 2 MAC address.

[0095] Flow tables 526 may facilitate forwarding policies to flows. Each flow table 526 includes flow table entries that each match one or more flows that may traverse virtual router forwarding plane 528, and includes forwarding policies for application to matching flows.

[0096] In this example, VN agent 530 may be a user space 511 process executed by computing device 500. VN agent 530 includes configuration data 532, virtual routing and forwarding instance configuration 534 ("VRF 534"), and multicast replication tree 536. For example, VN agent 530 uses XMPP to communicate with one or more virtual network controllers (e.g., Figure 1-Figure 3 The VN agent 530 may exchange control information with the SDN controller 23 of the virtual router 520. The control information may include virtual network routing, low-level configuration state, such as routing instances for installation into configuration data 532 and VRF 534. The VN agent 530 installs the forwarding state into the virtual router forwarding plane 528. The VN agent 530 may receive a multicast replication tree 536 that indicates how the virtual router 520 replicates multicast traffic for local VMs (e.g., VM 510) received from the physical network. For example, the VN agent 530 may receive a multicast replication tree that specifies VM 510A and VM 510C as receivers of the multicast traffic.

[0097] Figure 6 is a flowchart illustrating an example operation according to the technology of the present disclosure. Figure 1 Network 2 describes Figure 6 .exist Figure 6In some examples, the SDN controller 23 may receive one or more multicast group membership messages for a multicast group (602). For example, the SDN controller 23 may receive one or more multicast group membership messages from the device 26A that identify one or more virtualized entities of the device 26A as receivers of the multicast group. For example, the virtual agent 27A of the device 26A may listen for IGMP join or leave messages and send the IGMP join or leave messages to the SDN controller 23 via XMPP. In some examples, the SDN controller 23 may receive one or more ERMVPN join messages (e.g., using XMPP).

[0098] SDN controller 23 receives a first multicast route and a second multicast route from a TOR switch (604). For example, SDN controller 23 receives one or more router advertisements of the first multicast route and the second multicast route from a TOR switch (e.g., TOR switch 16A). In some examples, the one or more router advertisements may conform to a Border Gateway Protocol (BGP) auto-discovery (AD) process.

[0099] The SDN controller 23 may determine that the first multicast route is a secondary replication route (606). In some examples, the SDN controller 23 may be configured to determine a first indication (e.g., a secondary replication type (T) of 3-4) from one or more router advertisements, the first indication indicating that the first multicast route is specified with a first tunnel type corresponding to the secondary replication route type. For example, one or more VRs in the VR 28 may be configured for Ethernet virtual private network-assisted multicast replication, an example of which is specified in the optimized IR draft. In response to determining that the first multicast route is a secondary replication route, the SDN controller 23 adds a first next hop indicated by the first multicast route to a next hop list for a BUM service (e.g., a multicast group) (608).

[0100] The SDN controller 23 may determine that the second multicast route is not a secondary replication route (610). In some examples, the SDN controller 23 may be configured to determine a second indication (e.g., a secondary replication type (T) of 5 or 6) from one or more router advertisements, the second indication indicating that the second multicast route is specified with a second tunnel type that does not correspond to the secondary replication route type. For example, one or more VRs in the VR 28 may be configured for Ethernet virtual private network-assisted multicast replication, an example of which is specified in the optimized IR draft. In response to determining that the second multicast route is not a secondary replication route, the SDN controller 23 avoids adding a second next hop indicated by the second multicast route to a next hop list for a BUM service (e.g., a multicast group) (612).

[0101] In some examples, the SDN controller 23 generates a multicast replication tree, such as an edge replication multicast tree, based on the multicast group member information and the next hop list. For example, a computing node of the SDN controller 23 may receive an XMPP message that identifies one or more VMs of the device 26A as receivers of the multicast group, and may generate a multicast replication tree that indicates how the virtual router will use the next hop list to replicate multicast services for one or more VMs. The multicast replication tree may be an overlay distribution tree for the multicast group. In some examples, the multicast replication tree conforms to the edge replication multicast tree described in the ERMVPN technology.

[0102] Before device 26A receives the multicast traffic and after adding the first next hop to the next hop list, SDN controller 23 may provision the next hop list at the virtual router to send the BUM traffic for the multicast group (614). For example, SDN controller 23 may provision VR 28A to configure VR 28A with a multicast replication tree for the multicast group using the next hop list. In some instances, the multicast replication tree may be an overlay distribution tree for the multicast group. The multicast replication tree may be an ERM tree configured for ERMVPN.

[0103] Virtual router 28A of device 26A may receive the multicast replication tree so that virtual router 28A may use the multicast replication tree to replicate the multicast traffic to the local VM. For example, virtual router 28A may receive configuration state information from a control node of SDN controller 23 that causes virtual router 28A to receive the multicast traffic from gateway 12 via a GRE / UDP tunnel and then flood the multicast traffic to the nodes (e.g., VM 44) specified in the multicast replication tree. More specifically, control node 56 may send an XMPP message sent to virtual router 28A that is encoded with input tunnel attributes including an IP address of a tunnel endpoint (e.g., gateway 12) and a tunnel type (e.g., MPLS over GRE / UDP).

[0104] In some examples, the first multicast route extends between the TOR switch and the first rack switch. For example, the first multicast route can extend between the TOR switch 16A and the rack switch 18A. In some examples, the second multicast route extends between the TOR switch and the second rack switch. For example, the second multicast route can extend between the TOR switch 16A and the rack switch 18N. The SDN controller 23 can configure the first rack switch to forward the BUM service to a specified virtual router in one or more virtual routers. In some instances, the specified virtual router (e.g., forest node) in the ERM tree is configured to replicate the BUM service. For example, the SDN controller 23 can configure the rack switch 18A to forward the BUM service only to the VR 28A, which is configured to replicate the BUM service to each VM of the device 26A. In some examples, the SDN controller 23 can configure the first rack switch to replicate the BUM service to each VM of the device 26A, and VR28A forwards the replicated BUM service to each VM of the device 26A. In some examples, configuring the first rack switch to replicate BUM traffic to each VM of device 26A can scale to an arbitrarily large number because SDN controller 23 constructs an ERM tree of depth O(logkN) using ERMVPN, where the maximum number of child nodes can be four.

[0105] The techniques described in the present disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more processors, including 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 circuit devices and any combination of such components. The term "processor" or "processing circuit device" may generally refer to any of the aforementioned logic circuit devices or any other equivalent circuit devices, either alone or in combination with other logic circuit devices. A control unit including hardware may also perform one or more techniques of the present disclosure.

[0106] Such hardware, software and firmware can be implemented in the same device or in a separate device to support the various operations and functions described in this disclosure. In addition, any one of the described units, modules or components can be implemented as a discrete logic device together or separately, rather than an interoperable logic device. The depiction of the different features of a module or unit is intended to emphasize different functional aspects, and does not necessarily mean that such a module or unit must be implemented by a separate hardware or software component. On the contrary, the functionality associated with one or more modules or units can be performed by a separate hardware or software component, or integrated in a shared or separate hardware or software component.

[0107] The techniques described in the present disclosure may also be implemented or encoded in a computer-readable medium (such as a computer-readable storage medium) containing instructions. For example, when the instructions are executed, the instructions embedded or encoded in the computer-readable storage medium may cause a programmable processor or other processor to perform the method. The computer-readable storage medium may include a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette, a magnetic medium, an optical medium, or other computer-readable medium.

Claims

1. A controller for network management, the controller comprising one or more processors, wherein the one or more processors are configured to: receiving a first multicast route and a second multicast route; responsive to a determination that the first multicast route is a secondary duplicate route, adding a first next hop indicated by the first multicast route to a next hop list for broadcast, unknown unicast, and multicast BUM traffic; responsive to a determination that the second multicast route is not the secondary duplicate route, refraining from adding a second next hop indicated by the second multicast route to the next hop list for BUM traffic; as well as After adding the first next hop, a virtual router is configured based on the next hop list.

2. The controller according to claim 1, wherein in order to receive the first multicast route and the second multicast route, the controller is configured to: One or more router advertisements of the first multicast route and the second multicast route are received.

3. The controller of claim 2, wherein the one or more router advertisements comply with a Border Gateway Protocol (BGP) auto-discovery (AD) process.

4. The controller according to claim 2, wherein the controller is configured to: determining a first indication from the one or more router advertisements, the first indication indicating that the first multicast route is specified with a first tunnel type corresponding to a secondary replica route type, and determining that the first multicast route is the secondary replica route in response to the first indication; and A second indication is determined from the one or more router advertisements, the second indication indicating that the second multicast route is specified with a second tunnel type that does not correspond to the secondary duplicate route type, and a determination is made in response to the second indication that the second multicast route is not the secondary duplicate route.

5. The controller of claim 1, wherein the virtual router is configured for Ethernet VPN-assisted multicast replication.

6. The controller according to claim 1, wherein the controller is configured to: receiving one or more multicast group membership messages identifying the virtual router as a source of a multicast group; and In order to configure the virtual router, the controller is configured to configure the virtual router to replicate the BUM service using the next hop list.

7. The controller of claim 6, wherein to configure the virtual router, the controller is configured to configure the virtual router with a multicast replication tree for the multicast group using the next hop list, wherein the multicast replication tree is an overlay distribution tree for the multicast group.

8. The controller of claim 7, wherein the multicast replication tree is an edge replication multicast ERM tree configured for edge replication multicast (ERM) for virtual private networking (VPN).

9. The controller of claim 8, wherein the one or more multicast group membership messages include one or more ERMVPN join messages.

10. The controller according to claim 9, wherein to receive the one or more ERMVPN join messages, the controller is configured to receive the one or more ERMVPN join messages using Extensible Messaging and Presence Protocol (XMPP).

11. A controller according to any one of claims 1 to 10, wherein the first multicast route includes a secondary replicator route extending between a top-of-rack TOR switch and a first rack switch, and wherein the second multicast route includes a common inclusive provider multicast service interface I-PMSI inclusive multicast route extending between the TOR switch and a second rack switch, the second rack switch being different from the first rack switch.

12. The controller of claim 11, wherein the controller is further configured to configure the first rack switch to forward the BUM service to a designated virtual router among the one or more virtual routers, wherein the designated virtual router is configured to replicate the BUM service.

13. The controller of claim 11, wherein the one or more virtual routers include a plurality of receivers, and wherein the controller is further configured to configure the first rack switch to replicate the BUM traffic to the plurality of receivers.

14. A method for network management, the method comprising: receiving, by the controller, a first multicast route and a second multicast route; In response to determining that the first multicast route is a secondary duplicate route, adding, by the controller, a first next hop indicated by the first multicast route to a next hop list for broadcast, unknown unicast, and multicast BUM traffic; In response to determining that the second multicast route is not the secondary duplicate route, avoiding, by the controller, adding a second next hop indicated by the second multicast route to the next hop list for BUM traffic; as well as After adding the first next hop, a virtual router is configured by the controller based on the next hop list.

15. The method of claim 14, wherein receiving the first multicast route and the second multicast route comprises: One or more router advertisements of the first multicast route and the second multicast route are received.

16. The method of claim 15, wherein the one or more router advertisements comply with a Border Gateway Protocol (BGP) Auto-Discovery (AD) process.

17. The method according to claim 15, further comprising: determining, by the controller, from the one or more router advertisements, a first indication that the first multicast route is specified with a first tunnel type corresponding to a secondary replica route type, and determining, in response to the first indication, that the first multicast route is the secondary replica route; as well as A second indication is determined, by the controller, from the one or more router advertisements, indicating that the second multicast route is specified with a second tunnel type that does not correspond to the secondary duplicate route type, and a determination is made, in response to the second indication, that the second multicast route is not the secondary duplicate route.

18. The method of claim 14, wherein the virtual router is configured for Ethernet VPN-assisted multicast replication.

19. The method according to any one of claims 14 to 18, further comprising: receiving, by the controller, one or more multicast group membership messages identifying the virtual router as a source of a multicast group; and Configuring the virtual router includes configuring the virtual router to use the next hop list to replicate the BUM service.

20. A computer readable storage medium encoded with instructions for causing one or more programmable processors to perform the operations of a controller according to any one of claims 1 to 13.

Images