Route reflector as a service

A computer device may include logic configured to generate a virtualized environment for a customer; receive a request to provide a route reflector service for the customer; and generate a virtual route reflector on the generated virtualized environment, in response to receiving the request to provide the route reflector service for the customer. The logic may further be configured to establish a Virtual Private Network (VPN) or secure tunnel connection between the generated virtual route reflector and a client router associated with a customer network via a cloud center access system, wherein the cloud center access system connects a cloud center system that includes the computer device to a provider network that includes the client router; and establish a Border Gateway Protocol (BGP) session between the client router and the generated virtual route reflector using the established VPN or secure tunnel connection.

BACKGROUND INFORMATION

A communication network within the Internet may be defined as an autonomous system (AS). An AS may be a collection of devices with Internet Protocol (IP) routing prefixes that have a defined routing policy to the Internet. For example, a large company, an organization, an Internet Service Provider (ISP), and/or a provider of communication services that includes an Internet backbone connection may each manage a different AS. Thus, packets exchanged between a customer device, using an ISP to connect to a web site on a company's server device, and the server device may traverse a first AS associated with the ISP, a second AS associated with an Internet backbone connection, and a third AS associated with the company's private network. Routing and reachability information between different autonomous systems may be exchanged using Border Gateway Protocol (BGP) and devices configured with BGP may be referred to as BGP routers. Managing an AS with a large number of BGP routers may be challenging.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

A first AS and a second AS may exchange routing and/or reachability information using external BGP (EBGP). In order for a third AS to receive routing and/or reachability information about the first AS via the second AS, the routing and/or reachability information may need to traverse the second AS. Routing and/or reachability information within an AS may be exchanged using internal BGP (IBGP). In order for any external routing information (e.g., how to reach a particular external AS) to be distributed to all other BGP routers within an AS, all BGP routers within the AS may need to have full-mesh connectivity. As the number of BGP routers in an AS increases to n, the number of IBGP sessions required for full mesh connectivity increases by n*(n−1)/2, resulting in a scaling problem.

The scaling problem may be alleviated by using route reflectors. A route reflector may be a BGP router configured to reflect routing information to a group of client BGP routers. Thus, when a BGP router receives a route advertisement from an external AS via EBGP, the BGP router may forward the route advertisement to a route reflector router via IBGP, and the route reflector router may forward the route advertisement to all its client routers via IBGP. As the ratio of route reflectors to client routers grows, the number of IBGP sessions that needs to be maintained in the AS drops significantly. As a network grows in size, the number of route reflectors itself may increase to a large number. For example, a large AS may include hundreds of route reflectors. Maintaining a large number of route reflectors may be expensive and may tax the resources of a network.

Implementations described herein relate to providing a route reflector as a service. A virtualized environment (VE) system in a cloud center may generate a virtualized environment for the customer. The virtualized environment may be configured to simulate router devices. The VE system may receive a request from a customer to provide a route reflector service for they customer and may generate a virtual route reflector on the generated virtualized environment, in response to receiving the request. The customer may designate which edge routers to the customer's networks should become client routers of the generated virtual route reflector. The VE system may then establishing a Virtual Private Network (VPN) or a secure tunnel connection between the generated virtual route reflector and each of the designated client routers via a cloud center access system that connects the cloud center to a provider network that includes the client routers. As an example, the virtual route reflector may join a VPN associated with the customer. As another example, the computer device may utilize a tunnel mechanism to establish a secure Generic Routing Encapsulation (GRE) tunnel, an Internet Protocol Security (IPsec) tunnel, and/or another type of secure tunnel between the generated virtual route reflector and each of the client routers. The VE system may then establish a BGP session between the generated virtual route reflector and each client router using the established VPN or secure tunnel connections. A “tunnel,” as the term is used herein, is understood to include a tunnel mechanism (e.g., hardware and corresponding software configurations on the hardware, etc.) used to implement a particular type of tunnel.

Once a generated virtual route reflector is configured, the generated virtual route reflector may receive a BGP route advertisement from one of its client routers, may forward the BGP route advertisement to all its other client routers and may forward the BGP route advertisement to all other route reflectors associated with the customer. Thus, the BGP route advertisement may be distributed to all routers associated with the customer's networks.

The customer may add additional routers as client routers to the generated virtual route reflector. For example, the VE system may receive a request from the customer to add another router as a client router of the generated virtual route reflector, may establishing another VPN or secure tunnel connection between the generated virtual route reflector and the other client router via the cloud center access system, and may establish another BGP session between the other client router and the generated virtual route reflector using the established other VPN or secure tunnel connection.

The customer may also add additional route reflectors. For example, the VE system may receive a request from the customer to generate another virtual route reflector and may generate another virtual route reflector, in response to receiving the request. The VE system may then establish a VPN or secure tunnel connection between the new generated virtual route reflector and the routers designated as the client routers of the new generated virtual route reflector via the cloud center access system. Furthermore, the VE system may establish a BGP session between the client routers and the new generated virtual route reflector using the established other VPN or secure tunnel connection and may establish a BGP session between the new generated virtual route reflector and any other route reflectors associated with the customer.

In some implementations, different virtual route reflectors may be generated in different cloud centers. The VE system may receive an indication that another virtual route reflector has been generated for the customer in another cloud center and may, in response, establish a BGP session between the generated virtual route reflector and the other virtual route reflector over a connection between the cloud center access systems of the two different cloud centers.

Route reflectors as a service, generated in a VE system in a cloud center, may enable for a multi-tenant implementation (e.g., to serve a large number of different customers) and for large horizontal-scale capabilities. For example, the VE system may enable a customer to utilize hierarchical planes for organizing route reflectors. For example, a customer may select to cluster a first set of route reflectors into a first plane and a second set of route reflectors into a second plane and designate each set as client routers to a particular route reflector plane. Furthermore, route reflectors as a service may enable increased redundancy and/or resiliency. For example, a cloud center may include a web-scale architecture that includes a large pool of computational resources, memory, storage space, and/or network bandwidth. Therefore, a customer's networks and route reflector design may be easily scaled without additional purchases of routing hardware. Furthermore, failure or malfunction of a cloud center may be less likely than the failure of a dedicated router device.

Moreover, a virtualized environment with generated route reflectors may be easily duplicated and multiple connections between a client router and the cloud center access system may be maintained to improve robustness. Additionally or alternatively, the virtualized environment may be duplicated in another cloud center. Thus, using a route reflector service may enable a customer to increase redundancy and/or robustness.

Furthermore, the customer may not need to build and deploy a Multi-Protocol Label Switching (MPLS) backbone to exchange BGP information between the customer's routers. Rather, the customer may use the provider's MPLS backbone to send BGP information to the generated virtual route reflectors in the cloud center managed by the provider.

Further still, a customer may easily configure or upgrade a generated virtual route reflector provided as a service in a cloud center. As an example, the customer may send a request to configure the generated virtual route reflector to support different route reflector BGP address families, such as Internet Protocol version 4 (IPv4), IPv6, Virtual Private Network version 4 (VPNv4), VPNv6, Layer 2 VPN (L2VPN), multicast VPN (MVPN), Route Target (RT) constrained route distribution, and/or another type of addressing scheme.

FIG. 1is a diagram of an exemplary environment100in which the systems and/or methods described herein may be implemented. As shown inFIG. 1, environment100may include customer networks110-A to110-X (referred to herein collectively as “customer networks110” and individually as “customer network110”), a provider network120, and a cloud center system140.

Customer network110may correspond to an AS associated with a customer of provider network120. For example, customer network110may include an AS with a different IP prefix than provider network120. A provider associated with provider network120may provide communication services to customer network110via provider network120. For example, different customer networks110associated with a customer may communicate with each other using provider network110using, for example a Multi-Protocol Label Switching (MPLS) Virtual Private Network (VPN) implemented via provider network120. In some implementations, the customer may correspond to a large enterprise that manages its own networks at multiple geographic locations, such as a large-scale financial institution or corporation. In other implementations, the customer may correspond to a regional or local provider of telecommunication services that provides telecommunication services, such as an Internet Service Provider (ISP), a provider of MPLS VPN services, a provider of television services, and/or a provider of voice communication for its customers. Customer network110may include one or more circuit-switched networks and/or packet-switched networks. Customer network110may include a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), an ad hoc network, an intranet, the Internet, a fiber optic-based network, a wireless network, and/or any combination of these or other types of networks.

Customer network110may include provider edge (PE) routers112-A to112-N (e.g., customer network110-A may include PE routers112-A-A to112-A-N, customer network110-X may include PE routers112-X-A to112-X-N, etc.). Each PE router112may connect to a particular Layer 2 and/or Layer 3 network (not shown inFIG. 1) associated with the AS of customer network110. Thus, PE router112may serve as an access point into customer network110for other networks services by customer network110. Furthermore, customer network110may include a carrier supporting carrier (CSC) customer edge (CE) router114(e.g., customer network110-A may include CSC-CE router114-A, customer network110-X may include CSC-CE router114-X, etc.). CSC-CE routers114may connect to provider network120.

Provider network120may correspond to an AS associated with a provider of communication services. Provider network120may include one or more circuit-switched networks and/or packet-switched networks. Provider network120may include a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), an ad hoc network, an intranet, the Internet, a fiber optic-based network, a wireless network, and/or any combination of these or other types of networks. Provider network120may include CSC-PE routers125-A to125-X. Each CSC-PE router125may connect to a CSC-CE router114of a particular customer network110.

Provider network120may function as a backbone carrier that provides connectivity to the customer carrier between customer networks110via the connections from CSC-CE114s to CSC-PEs125. Thus, for example, CSC-CE114-A may perceive a direct connection to CSC-CE114-X via CSC-PE125-A and CSC-PE125-X using an MPLS connection130. Routes between customer networks110may be exchanged using BGP over MPLS connection130and provider network120may not be aware of, or learn, the routes between customer networks110. Similarly, customer networks110may not learn or be aware of routes within provider network110.

In order for all customer networks110to be able to communicate and exchange routes, each CSC-PE router125may need to maintain an IBGP session with every other CSC-PE router125or each CSC-PE router125may communicate with a particular route reflector as a client of the particular route reflector.

The provider associated with provider network120may provide route reflectors as a service implemented on virtualized environments in cloud center system140. Cloud center system140may include a web-scale architecture that includes one or more server devices and/or storage devices, which provide cloud services for customers. Cloud services provided by cloud center system140may include, for example, computing as a service, cloud storage, a hosted voice-over-Internet Protocol (VoIP) service, a Network Address Translation (NAT) service, a Virtual Private Network (VPN) service, a Distributed Denial Of Service (DDOS) event detection and/or mitigation service, a firewall service, an Intrusion Detection and Prevention System (IDPS), an email filtering service, a filtering service for a particular web site, a load balancing service, a video distribution service, a lawful intercept service on behalf of a law enforcement entity, and/or any other type of service that be provided by a cloud center. Furthermore, cloud center system140may provide route reflectors as a service.

Cloud center system140may include a cloud center access system145and a virtualized environment (VE) system150. Cloud center access system145may include one or more devices that connect cloud center system140to provider network120. Devices in cloud center system140may connect to cloud center access system145with a Layer 2 connection or with a Layer 3 connection. For example, cloud center access system145may include one or more network devices that function as Layer 2 and/or Layer 3 devices and that maintain Layer 2 and/or Layer 3 separation for different customers. Layer 2 separation may correspond to maintaining Layer 2 traffic associated with a first customer separate from Layer 2 traffic associated with a second customer. Layer 2 separation may be accomplished by assigning particular Layer 2 Domains (L2D) to particular customers and tagging Layer 2 data units (e.g., Ethernet frames) with particular L2D tags. Layer 3 separation may correspond to maintaining Layer 3 traffic associated with a first customer separate from Layer 3 traffic associated with a second customer. Layer 3 separation may be accomplished by maintaining particular routing instances for particular customers. Each routing instance may include a separate routing table and traffic associated with a particular customer may be routed based on the routing table associated with the customer's routing instance.

VE system150may include one or more devices, such as server devices (e.g., an x86 server and/or other processing devices), that generate virtual route reflectors (RRs)160for customers (e.g., a customer associated with customer networks110). For example, VE system150may generate a first virtual route reflector160-A that includes CSC-PE125-A as a client router and a second virtual route reflector160-B that includes CSC-PE125-X as a client router. In practice, a particular generated virtual route reflector160may interact with a large number of CSC-PEs125as client routers.

After VE system150generates a virtual route reflector160, VE system150may establish a VPN or a secure tunnel connection170to each client router of the generated virtual route reflector160. After the VPN or secure tunnel connection170is established, VE system150may establish an IBGP session180between the generated virtual route reflector160and each client router, as well between the generated virtual route reflector160and any other route reflectors associated with the customer. Virtual route reflector160may receive BGP route advertisements from customer networks110. A BGP route advertisement may include routing and/or reachability information to a particular network, such as an indication of a new connection, an indication of a faulty or unavailable connection, an indication of a change in a BGP path attribute, and/or another type of routing/reachability information. For example, if PE router112-A-A detects a new route, PE router112-A-A may advertise the route to CSC-CE router114-A, CSC-CE router114-A may advertise the route to CSC-PE router125-A, and CSC-PE router125-A may advertise the route to virtual route reflector160-A. RR160-A may then advertise the route to all its client routers as well as to all other route reflectors associated with the customer (e.g., with the customer's VPN), such as virtual route reflector160-B.

AlthoughFIG. 1shows exemplary components of environment100, in other implementations, environment100may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 1. Additionally or alternatively, one or more components of environment100may perform functions described as being performed by one or more other components of environment100.

FIG. 2is a diagram illustrating example components of a router device200. Each of PE router112, CSC-CE router114, and/or CSC-PE router125may include one or more router devices200. As shown inFIG. 2, router device200may include one or more input port or units210-A to210-N (referred to herein individually as “input port or unit210” and collectively as “input port or units210”), a switching mechanism220, one or more output port or units230-A to230-M (referred to herein individually as “output port or unit230” and collectively as “output port or units230”), and/or a control unit240.

Input port or units210may be the points of attachments for physical links and may be the points of entry for incoming traffic. An input port or unit210may be associated with an interface card. Input port or unit210may perform some or all of data plane processing associated with an incoming packet. Data plane processing may encompass looking up a destination address for an incoming packet, removing or changing a label associated with the packet, determining a path through switching mechanism220, and/or filter the packet based on one or more firewall filters.

Switching mechanism220may include one or more switching planes and/or fabric cards to facilitate communication between input port or units210and output port or units230. In one implementation, each of the switching planes and/or fabric cards may include a single or multi-stage switch of crossbar elements. In another implementation, each of the switching planes may include some other form(s) of switching elements. Additionally or alternatively, switching mechanism220may include one or more processors, one or more memories, and/or one or more paths that permit communication between input port or units210and output port or units230.

Output port or units230may store traffic received from input port or units210and may schedule the traffic on one or more output physical links. An output port or unit230may be associated with an interface card. Output port or unit230may perform some or all of data plane processing associated with an outgoing packet. For example, output port or unit230may classify the packet based on a quality of service class, schedule the packet in a particular queue, add or change a label associated with the packet, and/or filter the packet based on one or more firewall filters.

Control unit240may interconnect with input port or units210, switching mechanism220, and/or output port or units230and may control operation of router device200. For example, control unit240may perform control plane operations associated with router device200(e.g., control unit240may use routing protocols and may create one or more routing tables and/or one or more forwarding tables that are used in traffic forwarding).

AlthoughFIG. 2shows example components of router device200, in other implementations, router device200may include fewer components, different components, differently arranged components, and/or additional components than depicted inFIG. 2. Additionally or alternatively, one or more components of router device200may perform one or more tasks described as being performed by one or more other components of router device200.

FIG. 3is a diagram illustrating exemplary functional components of CSC-PE router125. In some implementations, the functional components of CSC-PE router125may be implemented, for example, via control unit240. Alternatively, some or all of the functional components of CSC-PE router125may be implemented via hard-wired circuitry. As shown inFIG. 3, CSC-PE router125may include a BGP client310. BGP client310may manage BGP sessions with other routers. BGP client310may include customer edge routers interface320and virtual route reflector interface330.

Customer edge routers interface320may manage BGP sessions with CSC-CE routers114. For example, customer edge routers interface320may receive a BGP advertisement from PE routers112via CSC-CE router114and may provide the received BGP advertisement to virtual route reflector interface330to forward to virtual route reflector160. Furthermore, customer edge routers interface320may receive a BGP advertisement from virtual route reflector160via virtual route reflector interface330and may forward the BGP route advertisement to CSC-CE router114and/or any other routers with which CSC-PE router125maintains BGP session (e.g., if CSC-PE router125is multi-homed).

Virtual route reflector interface330may manage a BGP session with virtual route reflector160, or may manage multiple BGP sessions with multiple virtual route reflectors160for redundancy purposes. For example, virtual route reflector interface330may receive a BGP advertisement from virtual route reflector160and may provide the received BGP advertisement to customer edge routers interface320to forward to CSC-CE router114. Furthermore, virtual route reflector interface330may receive a BGP advertisement from CSC-CE router114via customer edge routers interface320and may forward the BGP route advertisement to virtual route reflector160, or to multiple virtual route reflectors160if multiple route reflectors are configured to communicate with CSC-PE router125for redundancy.

AlthoughFIG. 3shows exemplary functional components of CSC-PE router125, in other implementations, CSC-PE router125may include fewer functional components, different functional components, differently arranged functional components, or additional functional components than those depicted inFIG. 3. Additionally or alternatively, one or more functional components of CSC-PE router125may perform functions described as being performed by one or more other functional components of CSC-PE router125.

FIG. 4is a diagram illustrating exemplary components of VE system150. As shown inFIG. 4, VE system150may include a bus410, a processor420, a memory430, an input device440, an output device450, and a communication interface460.

Bus410may include a path that permits communication among the components of VE system150. Processor420may include any type of single-core processor, multi-core processor, microprocessor, latch-based processor, and/or processing logic (or families of processors, microprocessors, and/or processing logics) that interprets and executes instructions. In other embodiments, processor420may include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and/or another type of integrated circuit or processing logic.

Memory430may include any type of dynamic storage device that may store information and/or instructions, for execution by processor420, and/or any type of non-volatile storage device that may store information for use by processor420. For example, memory430may include a random access memory (RAM) or another type of dynamic storage device, a read-only memory (ROM) device or another type of static storage device, a content addressable memory (CAM), a magnetic and/or optical recording memory device and its corresponding drive (e.g., a hard disk drive, optical drive, etc.), and/or a removable form of memory, such as a flash memory.

Input device440may allow an operator to input information into VE system150. Input device440may include, for example, a keyboard, a mouse, a pen, a microphone, a remote control, an audio capture device, an image and/or video capture device, a touch-screen display, and/or another type of input device. In some embodiments, VE system150may be managed remotely and may not include input device440. In other words, VE system150may be “headless” and may not include a keyboard, for example.

Output device450may output information to an operator of VE system150. Output device450may include a display, a printer, a speaker, and/or another type of output device. For example, VE system150may include a display, which may include a liquid-crystal display (LCD) for displaying content to the customer. In some embodiments, VE system150may be managed remotely and may not include output device450. In other words, VE system150may be “headless” and may not include a display, for example.

Communication interface460may include a transceiver that enables VE system150to communicate with other devices and/or systems via wireless communications (e.g., radio frequency, infrared, and/or visual optics, etc.), wired communications (e.g., conductive wire, twisted pair cable, coaxial cable, transmission line, fiber optic cable, and/or waveguide, etc.), or a combination of wireless and wired communications. Communication interface460may include a transmitter that converts baseband signals to radio frequency (RF) signals and/or a receiver that converts RF signals to baseband signals. Communication interface460may be coupled to an antenna for transmitting and receiving RF signals.

As will be described in detail below, VE system150may perform certain operations relating to providing route reflectors as a service. VE system150may perform these operations in response to processor420executing software instructions contained in a computer-readable medium, such as memory430. A computer-readable medium may be defined as a non-transitory memory device. A memory device may be implemented within a single physical memory device or spread across multiple physical memory devices. The software instructions may be read into memory430from another computer-readable medium or from another device. The software instructions contained in memory430may cause processor420to perform processes described herein. Alternatively, hardwired circuitry may be used in place of, or in combination with, software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

AlthoughFIG. 4shows exemplary components of VE system150, in other implementations, VE system150may include fewer components, different components, additional components, or differently arranged components than those depicted inFIG. 4. Additionally or alternatively, one or more components of VE system150may perform one or more tasks described as being performed by one or more other components of VE system150.

FIG. 5is a diagram illustrating exemplary functional components of VE system150. In some implementations, the functional components of VE system150may be implemented, for example, via processor420executing instructions from memory430. Alternatively, some or all of the functional components of VE system150may be implemented via hard-wired circuitry. As shown inFIG. 5, VE system150may include a customer interface510, a customer database (DB)520, a virtualized environment generator530, and one or more virtualized environments540-A to540-M.

Customer interface510may be configured to receive requests from a customer to generate virtual route reflectors. For example, a customer may log into VE system150via customer interface510and be presented with a user interface to generate a new virtual route reflector. The user interface may request a customer to create an account and/or to log into an existing account. Furthermore, the user interface may enable the customer to specify a particular secure connection to use for establishing BGP sessions with particular client routers, to specify which CSC-PE routers125should be included in the client router set of the new virtual route reflector, and/or which other existing route reflectors should establish BGP sessions with the new virtual route reflector. Furthermore, the customer may request a particular redundancy (e.g., multiple BGP connections to client routers). Moreover, the user interface may enable the customer to request additional configuration options, such as a particular addressing scheme (e.g., IPv4, IPv6, VPNv4, VPNv6, L2VPN, MVPN, RT constrained route distribution, etc.). Customer interface510may obtain the information specified by the customer and may store the obtained information in customer DB520.

Virtualized environment generator530may generate a virtualized environment540for the customer. A virtualized environment may be implemented with a virtual machine (VM), a Linux container, and/or another type of virtualized environment. Virtualized environment generator530may reserve processor and memory resources required to generate one or more virtual route reflectors and may load and operating system and/or software to simulate the operation of a route reflector device.

Thus, VE system150may include virtualized environments540-A to540-K. Each virtualized environment540may include route reflectors for a particular customer. Virtualized environment540may include one or more virtual route reflectors160-A to160-N. Each virtual route reflector160may function as a route reflector for a set of client routers associated with the customer (e.g., CSC-PE routers125). As shown inFIG. 5, virtual route reflector160may include a route updates manager550and router DB560.

Route updates manager550may perform the functions of a route reflector based on information stored in router DB560. Exemplary information that may be stored in router DB560is described below with reference toFIG. 6. Route updates manager550may, for example, receive a BGP route advertisement from one if its client routers and may forward the BGP route advertisement to all its other client routers and all the other route reflectors with which the virtual route reflector160is maintaining a BGP session. Furthermore, route updates manager550may receive a BGP route advertisement from another route reflector and may forward the BGP advertisement to all its client routers. Route updates manager550may add IBGP distance metrics to router DB560. Route updates manager550may obtain IBGP distance information through a BGP link state (BGP-LS) mechanism and/or using another technique.

AlthoughFIG. 5shows exemplary functional components of VE system150, in other implementations, VE system150may include fewer functional components, different functional components, differently arranged functional components, or additional functional components than those depicted inFIG. 5. Additionally or alternatively, one or more functional components of VE system150may perform functions described as being performed by one or more other functional components of VE system150.

FIG. 6is a diagram illustrating exemplary information that may be stored in the router DB560. As shown inFIG. 6, router DB560may include one or more client router records610and one or more route reflector records650. Each client router record610may store information relating to a particular client router associated with the generated virtual route reflector160. Client router record610may include a client router field612, a destination address field614, a next hop field616, and a status field618.

Client router field612may identify a particular client router that is a member of the client router set of virtual route reflector160. Destination address field614may store an address associated with the particular client router (e.g., the IP address of the particular client router). Next hop field616may store one or more next hop addresses associated with the particular client router. Status field618may store a status associated with the particular client router, such as whether the particular client router is active, disabled, offline, and/or whether the connection to the particular client router is up or down.

Each route reflector record650may store information relating to another route reflector160associated with the customer. Route reflector record650may include a route reflector field652, a client router prefixes field654, a next hop field656, an attributes field658, and a status field660.

Route reflector field652may identify a particular route reflector associated with the customer. The particular route reflector may include a physical route reflector maintained by the customer, a virtual route reflector simulated on a same cloud center system140, or a virtual route reflector simulated on a different cloud center system140. Client router prefixes field654may store the address prefixes (e.g., IP address prefixes) associated with the client routers of the particular route reflector. Next hop field656may store next hop addresses associated with the client routers of the particular route reflector. Attributes field658may store one or more attributes associated with the particular route reflector. The attributes may be used to avoid routing loops. Status field660may store a status associated with the particular route reflector, such as whether the particular route reflector is active, disabled, offline, and/or whether the connection to the particular route reflector is up or down.

AlthoughFIG. 6shows exemplary fields of router DB560, in other implementations, router DB560may include fewer fields, different fields, differently arranged fields, or additional fields than those depicted inFIG. 6.

FIG. 7is a flowchart of an exemplary process for providing a route reflector service according to an implementation described herein. In some implementations, the process ofFIG. 7may be performed by VE system150. In other implementations, some or all of the process ofFIG. 7may be performed by another device or a group of devices separate from or including VE system150. Furthermore, in other implementations, the process ofFIG. 7may include fewer blocks, additional blocks, different blocks, or differently arranged blocks.

The process ofFIG. 7may include generating a virtualized environment for a customer in a cloud center (block710), receiving a request from the customer for a route reflector service (block720), and generating a virtual route reflector on the generated virtualized environment (block730). For example, virtualized environment generator530may generate virtualized environment540for the customer when the customer creates an account using customer interface510. The user may then use the customer interface510to request generation of a virtual route reflector. The customer may specify a particular secure connection to use for establishing BGP sessions with particular client routers, may specify which CSC-PE routers125should be included in the client router set of the new virtual route reflector, and/or may specify which other existing route reflectors should establish BGP sessions with the new virtual route reflector. Furthermore, the customer may request a particular redundancy (e.g., multiple BGP connections to client routers), and/or may request additional configuration options, such as a particular addressing scheme, etc. Customer interface510may obtain the information specified by the customer and may store the obtained information in customer DB520. Virtualized environment generator530may generate virtual route reflector160on the generated virtualized environment540based on the customer's provided specifications.

A secure tunnel or VPN connection may be established between the generated virtual route reflector and the customer's client routers through the cloud center access system (block740). For example, virtualized environment generator530may join a VPN associated with the customer and may configure the VRF in cloud center access system145to route packets labeled with VPN tags associated with the VPN to virtual route reflector160. As customer's CSC-PE routers125may already be a member of the customer's VPN, virtualized environment generator530may not need to configure the client routers to establish VPN communication between the client routers and virtual route reflector160. As another example, virtualized environment generator530may generate a secure tunnel between each of the client routers and virtual route reflector160. For example, virtualized environment generator530may generate a secure tunnel tag as well as authentication information for the secure tunnel tag (e.g., a public and private key) and may configure both the VRF in cloud center access system145and the client CSC-PE routers125to add the secure tunnel tag and the authentication information when communicating. In other implementations, the tunnel need not be secure. Examples of tunnels that may be used include an MPLS transport tunnel, a Generic Routing Encapsulation (GRE) tunnel, an Internet Protocol Security (IPSec) tunnel, and/or another type of tunnel.

IP connectivity may be established between the generated virtual route reflector and the customer's client routers (block750). For example, the customer's CSC-PE routers125may already be configured and be part of provider network120. Thus, the customer's CSC-PE routers125may have assigned IP addresses in provider network120. Virtualized environment generator530may assign an IP address to the generated virtual router160. Furthermore, virtualized environment generator530may configure Layer 3 separation for the generated virtual router160at cloud center access system145by, for example, generating a Virtual Routing and Forwarding (VRF) table for the generated virtual router160.

IBGP sessions may be established with the client routers over the VPN or tunnel connection (block760) and IBGP sessions may be established with the customer's other route reflectors (block770). For example, route reflector160may establish an IBGP session with each client router designated in router DB560as well as with each route reflector designated in router DB560. After IBGP sessions are established, virtual route reflector160may begin receiving and forwarding BGP route advertisements exchanged between customer networks110.

An IBGP route advertisement may be received from a client router or another route reflector (block780) and the IBGP route advertisement may be sent to other client routers and/or the customer's other route reflectors (block790). As an example, virtual route reflector160may receive an IBGP route advertisement from one of its client routers and may send the IBGP route advertisement to all its other client routers as well all other route reflectors associated with the customer. As another example, virtual route reflector160may receive an IBGP route advertisement from another route reflector and may send the IBGP route advertisement to all its client routers. Virtual route reflector160need not forward an IBGP route advertisement to other route reflectors, since all other route reflectors will also receive the IBGP route advertisement from the sending route reflector.

FIG. 8is a flowchart of an exemplary process performed by a carrier supporting carrier provider edge router according to an implementation described herein. In some implementations, the process ofFIG. 8may be performed by CSC-PE router125. In other implementations, some or all of the process ofFIG. 8may be performed by another device or a group of devices separate from or including CSC-PE router125. Furthermore, in other implementations, the process ofFIG. 8may include fewer blocks, additional blocks, different blocks, or differently arranged blocks.

The process ofFIG. 8may include establishing IP connectivity with a virtualized environment in a cloud center through a cloud center access system (block810), establishing a VPN or tunnel connection with a route reflector in the virtualized environment through the cloud center access system (block820), and establishing an IBGP session with the route reflector over the VPN or tunnel connection (block830). For example, virtualized environment generator530may advertise the IP address of virtual route reflector160as reachable via cloud center access system145to CSC-PE router125and may establish a VPN or tunnel connection to virtual route reflector160from CSC-PE router125via cloud center access system145. For example, virtualized environment generator530may join a VPN associated with CSC-PE router125and may configure the VRF in cloud center access system145to route packets labeled with VPN tags associated with the VPN to virtual route reflector160. As another example, virtualized environment generator530may generate an MPLS tunnel, a GRE tunnel, an IPsec tunnel, and/or another type of tunnel between CSC-PE router125and virtual route reflector160.

IBGP route advertisements may be exchanged between the customer network and the route reflector using the established IBGP session (block840). As an example, CSC-PE router125may receive an IBGP advertisement from PE routers112via CSC-CE router114and may provide the received BGP advertisement to virtual route reflector160. As another example, CSC-PE router125may receive an IBGP advertisement from virtual route reflector160and may forward the BGP route advertisement to CSC-CE router114and/or any other routers with which CSC-PE router125maintains BGP session (e.g., if CSC-PE router125is multi-homed).

FIG. 9is a diagram of a first exemplary scenario900according to an implementation described herein. In scenario900, the customer may manage five customer networks110: customer network110-A that includes CSC-CE router114-A communicating with CSC-PE125-A in provider network110; customer network110-B that includes CSC-CE router114-B communicating with CSC-PE125-B in provider network110; customer network110-C that includes CSC-CE router114-C communicating with CSC-PE125-C in provider network110; customer network110-D that includes CSC-CE router114-D communicating with CSC-PE125-D in provider network110; and customer network110-E that includes CSC-CE router114-E communicating with CSC-PE125-E in provider network110. Furthermore, scenario900may include cloud center system140-A and cloud center system140-B.

Assume that customer network110-E is geographically separated from the other customer networks. The customer may request a first virtual route reflector160-A with a client router set of CSC-PE125-A and CSC-PE125-B, a second virtual route reflector160-B with a client router set of CSC-PE125-C and CSC-PE125-D, and a third virtual route reflector160-C with a client router set of CSC-PE125-E. First and second virtual route reflectors160-A and160-B may be generated in cloud center system140-A. Because of the geographic separation, third virtual route reflector160-C may be generated in cloud center system140-B, which may be geographically closer to customer network110-E than cloud center system140-A.

The three generated virtual route reflectors160-A,160-B, and160-C may join the customer's VPN. Thus, a first VPN link910may be established between CSC-PE router125-A and virtual route reflector160-A; a second VPN link920may be established between CSC-PE router125-B and virtual route reflector160-A; a third VPN link930may be established between CSC-PE router125-C and virtual route reflector160-B; a fourth VPN link940may be established between CSC-PE router125-D and virtual route reflector160-B; and a fifth VPN link950may be established between CSC-PE router125-E and virtual route reflector160-C.

Furthermore, VPN links between the virtual route reflectors160may be established. Thus, a sixth VPN link960may be established between route reflector160-A and route reflector160-B; a seventh VPN link970may be established between route reflector160-B and route reflector160-C; and an eighth VPN link980may be established between route reflector160-A. and route reflector160-C. IBGP sessions (not shown inFIG. 9) may then be established over the established VPN links.

For example, while a series of blocks have been described with respect toFIGS. 7 and 8, the order of the blocks may be modified in other implementations. Further, non-dependent blocks may be performed in parallel.

The term “logic,” as used herein, may refer to a combination of one or more processors configured to execute instructions stored in one or more memory devices, may refer to hardwired circuitry, and/or may refer to a combination thereof. Furthermore, a logic may be included in a single device or may be distributed across multiple, and possibly remote, devices.