Topology of the Cloud CPE and SD-WAN Solutions
Figure 1 shows the topology of the Cloud Customer Premises equipment (CPE) and SD-WAN solutions. You can use one Contrail Service Orchestration (CSO) installation for all or any of the supported solutions and deployments:
Cloud CPE solution
Centralized deployment
Distributed (also known as hybrid WAN) deployment
Combined centralized and distributed deployment
SD-WAN solution
Different sites for an enterprise might connect to different regional POPs, depending on the geographical location of the sites. Within an enterprise, traffic from a site that connects to one regional POP travels to a site that connects to another regional POP through the central POP. A site can connect to the Internet and other external links through either the regional POP or the central POP.
Service providers use the central server to set up the Cloud CPE solution through Administration Portal. Similarly, customers activate and manage network services through their own dedicated view of Customer Portal on the central server.
Topologies of the Implementations and Deployments
Centralized Deployment
Figure 2 illustrates the topology of a centralized deployment. Customers access network services in a regional cloud through a Layer 3 VPN.
The central and regional POPs contain one or more Contrail Cloud implementations. VNFs reside on Contrail compute nodes and service chains are created in Contrail. You can choose whether to use the CSO OpenStack Keystone on the central infrastructure server or the OpenStack Keystone on the Contrail controller node in the central POP to authenticate CSO operations. The Contrail Cloud implementation provides Contrail Analytics for this deployment.
The MX Series router in the Contrail Cloud implementation is an SDN gateway and provides a Layer 3 routing service to customer sites through use of virtual routing and forwarding (VRF) instances, known in Junos OS as Layer 3 VPN routing instances. A unique routing table for each VRF instance separates each customer’s traffic from other customers’ traffic. The MX Series router is a PNE.
Sites can access the Internet directly, through the central POP, or both. Data traveling from one site to another passes through the central POP.
Distributed Deployment
Figure 3 illustrates the topology of a distributed deployment.
Each site in a distributed deployment hosts a CPE device on which the vSRX application is installed to provide security and routing services. The Cloud CPE solution supports the following CPE devices:
NFX250 Network Services Platform
SRX Series Services Gateway
vSRX
The vSRX CPE device can reside at a customer site or in the service provider cloud. In both cases, you configure the site in CSO as an on-premise site. Authentication of the vSRX as a CPE device takes place through SSH.
An MX Series router in each regional POP acts as an IPsec concentrator and provider edge (PE) router for the CPE device. An IPsec tunnel, with endpoints on the CPE device and MX Series router, enables Internet access from the CPE device. Data flows from one site to another through a GRE tunnel with endpoints on the PE routers for the sites. The distributed deployment also supports SD-WAN functionality for traffic steering, based on 5-tuple (source IP address, source TCP/UDP port, destination IP address, destination TCP/UDP port and IP protocol) criteria.
Network administrators can configure the MX Series router, the GRE tunnel, and the IPsec tunnel through Administration Portal. Similar to the centralized deployment, the MX Series router in the distributed deployment is a PNE.
The CPE device provides the NFVI, which supports the VNFs and service chains. Customers can configure sites, CPE devices, and network services with Customer Portal.
The OpenStack Keystone resides on the central infrastructure server and Contrail Analytics resides on a dedicated VM or server.
SD-WAN Solution
The SD-WAN solution supports hub-and-spoke and full mesh VPN topologies.
Figure 4 shows the topology of the SD-WAN Solution with a hub and spoke implementation.
The SD-WAN implementation supports a hub-and-spoke VPN topology, in which CPE devices reside at the spoke sites. The CPE devices are the same as those used in a distributed deployment. The hub device, which is an SRX Series gateway, typically serves all the spoke sites for all the customers in a POP. You can, however, dedicate a hub device to a specific tenant. In the hub-and-spoke topology, all traffic from a LAN segment passes through the hub, whether it is traveling to another of the customer’s sites in the same POP or to the Internet.
A virtual route reflector (VRR) resides on a VM on each regional microservices server. During the CSO installation, a VRR is installed on the regional servers. The VRR has a fixed configuration that you cannot modify. Use of a VRR enhances scaling of the BGP network with low cost and removes the need for hardware-based route reflectors that require space in a data center and ongoing maintenance.
For VRR redundancy, you need create at least two VRRs for a region. We recommend that you create VRRs in even numbers and assign these VRRs equally in different redundancy groups. Each hub or spoke device establishes a BGP peering session with two VRRs that are in different redundancy groups. If the primary VRR fails or connectivity is lost, the BGP peering session remains active because the secondary VRR continues to receive and advertise LAN routes to a device, thereby providing redundancy.
Redundancy groups are formed by logically separating VRRs based on following parameters:
Physical server affinity—VRRs that reside on a same physical server should not belong to different redundancy group.
Network affinity—VRRs that reside on a same network should not belong to different redundancy group.
There can be only two redundancy groups—group 0 and group 1. If you do not specify the redundancy group for VRRs, all VRRs are placed in the default redundancy group—group 0—and hub or spoke devices establish a BGP session with only one VRR.