Cloud CPE Centralized Deployment Model

Transcription

1 Cloud CPE Centralized Deployment Model Deployment Guide Release 1.5 Modified:

2 Juniper Networks, Inc Innovation Way Sunnyvale, California USA All rights reserved. Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Cloud CPE Centralized Deployment Model Deployment Guide 1.5 All rights reserved. The information in this document is current as of the date on the title page. YEAR 2000 NOTICE Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the year However, the NTP application is known to have some difficulty in the year END USER LICENSE AGREEMENT The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License Agreement ( EULA ) posted at By downloading, installing or using such software, you agree to the terms and conditions of that EULA. ii

3 Table of Contents About the Documentation ix Documentation and Release Notes ix Documentation Conventions ix Documentation Feedback xi Requesting Technical Support xii Self-Help Online Tools and Resources xii Opening a Case with JTAC xii Chapter 1 Overview of Cloud CPE Centralized Deployment Model Cloud CPE Centralized Deployment Model Overview NFV in the Cloud CPE Centralized Deployment Model Topology of the Cloud CPE Centralized Deployment Model High Availability in the Cloud CPE Centralized Deployment Model Architecture of the Cloud CPE Centralized Deployment Model Architecture of the CCRA Architecture of the Servers Architecture of the Contrail Nodes Architecture of the Contrail Service Orchestration Nodes VNFs Supported by the Cloud CPE Centralized Deployment Model Benefits of the Cloud CPE Centralized Deployment Model Licensing for the Cloud CPE Centralized Deployment Model Hardware and Software Tested in the Cloud CPE Centralized Deployment Model Chapter 2 Installing and Configuring the CCRA Minimum Hardware and Software Requirements Cabling the Hardware for the Cloud CPE Centralized Deployment Model Configuring the EX Series Ethernet Switch Configuring the QFX Series Switch Configuring the MX Series Router Configuring the Physical Servers and Nodes Chapter 3 Installing and Configuring the Cloud CPE Centralized Deployment Model Removing a Previous Deployment Deploying the Cloud CPE Centralized Deployment Model Installer Before You Begin Creating a Dedicated VM for the Installer Downloading Third-Party Software and Deploying the Installer Provisioning VMs on Contrail Service Orchestration Nodes Before You Begin Creating a Bridge Interface to Support VMs iii

4 Deployment Guide Customizing the Configuration File for the Provisioning Tool Provisioning VMs with the Provisioning Tool Manually Provisioning VMs on the Contrail Service Orchestration Node Verifying Connectivity of the VMs Configuring Junos Space Virtual Appliances and Databases Configuring a Junos Space Cluster Configuring MySQL for the Junos Space Databases Configuring MySQL to Communicate with the Contrail Service Orchestration Components Disabling the Firewall on the Junos Space Virtual Appliances Installing the Patch for Third-Party VNFs Installing and Configuring the Cloud CPE Centralized Deployment Model Before You Begin Creating the Deployment Directory Customizing the Roles Configuration File Customizing the Configuration File for the Cloud CPE Centralized Deployment Model Installation Deploying the Cloud CPE Centralized Deployment Model Creating an LxCIPtable VNF Image Chapter 4 Setting Up and Using the Cloud CPE Centralized Deployment Model with the GUIs Accessing the Contrail Services Orchestration GUIs Setting Up the Cloud CPE Centralized Deployment Model Designing and Publishing Network Services Customer Access to Network Services Setting Up the Visual Presentation of Log Files Monitoring and Troubleshooting the Deployment Chapter 5 Appendix Terminology Glossary of Terms for Cloud CPE Centralized Deployment Model iv

5 List of Figures Chapter 1 Overview of Cloud CPE Centralized Deployment Model Figure 1: NFV Components of the Cloud CPE Centralized Deployment Model Figure 2: Topology of the Cloud CPE Centralized Model Figure 3: Architecture of Nodes in Regional POPs and Central POP for a Scaled Installation with High Availability Figure 4: Architecture of CCRA Figure 5: Architecture of Servers in a Non-Redundant Installation Figure 6: Architecture of Servers in a Redundant Installation Figure 7: Architecture of Contrail Configure and Control Nodes Figure 8: Architecture of Contrail Compute Nodes v

6 Deployment Guide vi

7 List of Tables About the Documentation ix Table 1: Notice Icons x Table 2: Text and Syntax Conventions x Chapter 1 Overview of Cloud CPE Centralized Deployment Model Table 3: Cloud CPE Centralized Deployment Model Licenses Table 4: Network Devices Tested in the Cloud CPE Centralized Deployment Model Table 5: Specification of Servers Tested for Cloud CPE Centralized Deployment Model Table 6: Software Used in Cloud CPE Centralized Deployment Model Chapter 2 Installing and Configuring the CCRA Table 7: Minimum Hardware Requirements for Servers in Cloud CPE Centralized Deployment Model Table 8: Software Requirements for Cloud CPE Centralized Deployment Model Table 9: Connections for EX Series Switch Table 10: Connections for QFX Series Switch Table 11: Connections for MX Series Router Chapter 3 Installing and Configuring the Cloud CPE Centralized Deployment Model Table 12: Details of VMs on the Contrail Service Orchestration Node for a Non-Redundant Configuration Table 13: Details of VMs on Contrail Service Orchestration Nodes for a Redundant Configuration Chapter 4 Setting Up and Using the Cloud CPE Centralized Deployment Model with the GUIs Table 14: Access Details for the GUIs in a Non-Redundant Contrail Service Orchestration Installation Table 15: Access Details for the GUIs in a Redundant Contrail Service Orchestration Installation Chapter 5 Appendix Terminology Table 16: Glossary for Cloud CPE Centralized Deployment Model vii

8 Deployment Guide viii

9 About the Documentation Documentation and Release Notes Documentation and Release Notes on page ix Documentation Conventions on page ix Documentation Feedback on page xi Requesting Technical Support on page xii Documentation Conventions To obtain the most current version of all Juniper Networks technical documentation, see the product documentation page on the Juniper Networks website at If the information in the latest release notes differs from the information in the documentation, follow the product Release Notes. Juniper Networks Books publishes books by Juniper Networks engineers and subject matter experts. These books go beyond the technical documentation to explore the nuances of network architecture, deployment, and administration. The current list can be viewed at Table 1 on page x defines notice icons used in this guide. ix

10 Deployment Guide Table 1: Notice Icons Icon Meaning Description Informational note Indicates important features or instructions. Caution Indicates a situation that might result in loss of data or hardware damage. Warning Alerts you to the risk of personal injury or death. Laser warning Alerts you to the risk of personal injury from a laser. Tip Indicates helpful information. Best practice Alerts you to a recommended use or implementation. Table 2: Text and Syntax Conventions Table 2 on page x defines the text and syntax conventions used in this guide. Convention Description Examples Bold text like this Represents text that you type. To enter configuration mode, type the configure command: user@host> configure Fixed-width text like this Italic text like this Represents output that appears on the terminal screen. Introduces or emphasizes important new terms. Identifies guide names. Identifies RFC and Internet draft titles. user@host> show chassis alarms No alarms currently active A policy term is a named structure that defines match conditions and actions. Junos OS CLI User Guide RFC 1997, BGP Communities Attribute Italic text like this Represents variables (options for which you substitute a value) in commands or configuration statements. Configure the machine s domain name: [edit] root@# set system domain-name domain-name x

11 About the Documentation Table 2: Text and Syntax Conventions (continued) Convention Description Examples Text like this Represents names of configuration statements, commands, files, and directories; configuration hierarchy levels; or labels on routing platform components. To configure a stub area, include the stub statement at the [edit protocols ospf area area-id] hierarchy level. The console port is labeled CONSOLE. < > (angle brackets) Encloses optional keywords or variables. stub <default-metric metric>; (pipe symbol) Indicates a choice between the mutually exclusive keywords or variables on either side of the symbol. The set of choices is often enclosed in parentheses for clarity. broadcast multicast (string1 string2 string3) # (pound sign) Indicates a comment specified on the same line as the configuration statement to which it applies. rsvp { # Required for dynamic MPLS only [ ] (square brackets) Encloses a variable for which you can substitute one or more values. community name members [ community-ids ] Indention and braces ( { } ) ; (semicolon) Identifies a level in the configuration hierarchy. Identifies a leaf statement at a configuration hierarchy level. [edit] routing-options { static { route default { nexthop address; retain; } } } GUI Conventions Bold text like this Represents graphical user interface (GUI) items you click or select. In the Logical Interfaces box, select All Interfaces. To cancel the configuration, click Cancel. > (bold right angle bracket) Separates levels in a hierarchy of menu selections. In the configuration editor hierarchy, select Protocols>Ospf. Documentation Feedback We encourage you to provide feedback, comments, and suggestions so that we can improve the documentation. You can provide feedback by using either of the following methods: Online feedback rating system On any page of the Juniper Networks TechLibrary site at simply click the stars to rate the content, and use the pop-up form to provide us with information about your experience. Alternately, you can use the online feedback form at xi

12 Deployment Guide Send your comments to Include the document or topic name, URL or page number, and software version (if applicable). Requesting Technical Support Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC). If you are a customer with an active J-Care or Partner Support Service support contract, or are covered under warranty, and need post-sales technical support, you can access our tools and resources online or open a case with JTAC. JTAC policies For a complete understanding of our JTAC procedures and policies, review the JTAC User Guide located at Product warranties For product warranty information, visit JTAC hours of operation The JTAC centers have resources available 24 hours a day, 7 days a week, 365 days a year. Self-Help Online Tools and Resources For quick and easy problem resolution, Juniper Networks has designed an online self-service portal called the Customer Support Center (CSC) that provides you with the following features: Find CSC offerings: Search for known bugs: Find product documentation: Find solutions and answer questions using our Knowledge Base: Download the latest versions of software and review release notes: Search technical bulletins for relevant hardware and software notifications: Join and participate in the Juniper Networks Community Forum: Open a case online in the CSC Case Management tool: To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool: Opening a Case with JTAC You can open a case with JTAC on the Web or by telephone. Use the Case Management tool in the CSC at Call JTAC ( toll-free in the USA, Canada, and Mexico). xii

13 About the Documentation For international or direct-dial options in countries without toll-free numbers, see xiii

14 Deployment Guide xiv

15 CHAPTER 1 Overview of Cloud CPE Centralized Deployment Model Cloud CPE Centralized Deployment Model Overview on page 16 NFV in the Cloud CPE Centralized Deployment Model on page 16 Topology of the Cloud CPE Centralized Deployment Model on page 19 High Availability in the Cloud CPE Centralized Deployment Model on page 21 Architecture of the Cloud CPE Centralized Deployment Model on page 22 VNFs Supported by the Cloud CPE Centralized Deployment Model on page 26 Benefits of the Cloud CPE Centralized Deployment Model on page 27 Licensing for the Cloud CPE Centralized Deployment Model on page 28 Hardware and Software Tested in the Cloud CPE Centralized Deployment Model on page 28 15

16 Deployment Guide Cloud CPE Centralized Deployment Model Overview Juniper Networks Cloud customer premises equipment (CPE) Centralized Deployment Model offers end-to-end provisioning of Layer 4 through Layer 7 network services through an open, cloud-based architecture. The deployment uses: Network Functions Virtualization (NFV) management and orchestration (MANO) based on European Telecommunications Standards Institute (ETSI) standards. Software-defined networking (SDN) to dynamically create logical service chains that form the network services. You can either use the Cloud CPE Centralized Deployment Model as a turnkey implementation or connect to other operational support and business support systems (OSS/BSS) through a northbound Representational State Transfer (REST) API. The Cloud CPE Centralized Deployment Model is fully integrated and tested to enable straightforward installation. In the Cloud CPE Centralized Deployment Model, virtualized network functions (VNFs) reside in a cloud in a network point of presence (POP) or data center owned by either a service provider, such as a telecommunications company, or a large enterprise. Customers of the service provider or remote sites of a large enterprise access network services in the cloud. You can use the deployment model for existing Layer 3 VPN customers without changing CPE or access networks. Alternatively, you can enable access through a Layer 3 network interface device (NID). In this documentation, the term service provider refers to the organization that provides services and the term customer refers to the organization that uses the services. The audience for the documentation is the service provider. Related Documentation NFV in the Cloud CPE Centralized Deployment Model on page 16 Architecture of the Cloud CPE Centralized Deployment Model on page 22 High Availability in the Cloud CPE Centralized Deployment Model on page 21 Glossary of Terms for Cloud CPE Centralized Deployment Model on page 85 NFV in the Cloud CPE Centralized Deployment Model The Cloud CPE Centralized Deployment Model uses the following components for Network Functions Virtualization (NFV): Contrail Cloud Platform, which provides underlying software-defined networking (SDN), NFV infrastructure (NFVI), and the virtualized infrastructure manager (VIM). Contrail Service Orchestration, which provides a RESTful API to connect with service providers operational support systems (OSS) and business support systems (BSS) applications and is responsible for many management and orchestration (MANO) 16

17 Chapter 1: Overview of Cloud CPE Centralized Deployment Model activities in the deployment. Contrail Service Orchestration uses a microservice architecture, which is a distributed, non-hierarchical framework in which multiple software components microservices interact to perform the functions of the software. Each software component operates independently to implement a set of focused, related functions. Contrail Service Orchestration consists of the following components: Administration Portal, which is an application that you use to set up and manage your virtual network and customers through a graphical user interface (GUI). Administration Portal uses the Contrail Service Orchestration RESTful APIs. Cloud CPE Tenant, Site and Service Manager and its auxiliary component, Identity and Access Manager, which manage customers and map each customer s network services to the appropriate gateway resources, such as the Layer 2 access interfaces and routing instances. These applications provide a northbound RESTful API to which you can connect OSS/BSS systems. Customer Portal, which is an application that you can provide to customers to enable them to manage sites and services for their organizations through a GUI. Customer Portal uses the Contrail Service Orchestration RESTful APIs. Network Service Designer, which enables design, creation, management, and configuration of network services through a GUI. Network services are stored in the network service catalog. Network Service Orchestrator, which is responsible for ETSI-compliant management of the life cycle of network service instances. This application includes RESTful APIs that you can use to create and manage network service catalogs. Service and Infrastructure Monitor, which works with Icinga, an open source enterprise monitoring system to provide data about the Cloud CPE Centralized Deployment Model, such as the status of virtualized network functions (VNFs), virtual machines (VMs), and physical servers; information about physical servers resources; components of a network service (VNFs and VMs hosting a VNF); counters and other information for VNFs; and software components running in Contrail Cloud Platform. VNF Manager, which creates VNF instances and manages their life cycles. Junos Space Virtual Appliance, which provides an element management system for Juniper Networks VNFs and physical network elements (PNEs). The Cloud CPE Centralized Deployment Model extends the NFV model through the addition of the MX Series router as a PNE. The MX Series router PNE 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 receives traffic associated with network service activation from customer sites and transmits it to the virtual machines (VMs) in which the VNFs reside on the Contrail configure and control node. The MX Series router exchanges BGP routes with Contrail to enable this traffic flow. You configure PNEs for sites through Administration Portal. Configuration of the PNE in Contrail Service Orchestration as opposed to Contrail simplifies provisioning of the 17

18 Deployment Guide physical device through automation. Combining provisioning and configuration for PNEs and VNFs provides end-to-end automation in network configuration workflows. Figure 1 on page 18 illustrates how the components in the Cloud CPE Centralized Deployment Model interact and how they comply with the ETSI NFV MANO model. Figure 1: NFV Components of the Cloud CPE Centralized Deployment Model CONTRAIL SERVICE ORCHESTRATION Service and Infrastructure Monitor Cloud CPE Tenant, Site and Service Manager Administration Portal Network Service Designer Customer Portal Network Service Catalog NFV MANO VNF Catalog OSS/BSS Applications REST API Network Service Orchestrator NFV Instances NFVI Resources EMS: Junos Space Platform PNE/VNF Manager VNF NFVI: X86 Server and Ubuntu PNE VIM: Contrail Cloud Platform (OpenStack and SDN Controller) API Connection g OSS/BSS applications and Contrail Service Orchestration components with OSS/BBS capabilities send requests to Network Service Orchestrator through its northbound REST API. Network Service Orchestrator then communicates through its southbound API to the northbound API of the appropriate, directly connected, component. Subsequently, each component in the deployment communicates through its southbound API to the to the northbound API of the next component in the hierarchy. Components send responses in the reverse direction. The following process describes the interactions of the components when a customer requests the activation of a network service: 1. Customers send requests for activations of network services through Customer Portal or OSS/BSS applications. 2. Service and Infrastructure Monitor is continuously tracking the software components, hardware components, and processes in the network. 18

19 Chapter 1: Overview of Cloud CPE Centralized Deployment Model 3. Network Service Orchestrator receives requests through its northbound RESTful API and: Accesses information about the network service and associated VNFs from their respective catalogs, and communicates this information to the VIM, which is provided by Contrail Cloud Platform. Sends information about the VNF to VNF Manager. 4. The VIM and VNF Manager receive information from Network Service Orchestrator and: The VIM creates the service chains and associated VMs in the NFVI, which is provided by the servers and Ubuntu. Contrail Cloud Platform creates one VM for each VNF in the service chain. VNF Manager starts managing the VNF instances while the element management system (EMS), which is provided by the Junos Space Virtual Appliance, performs element management for the VNFs. 5. The network service is activated for the customer. The PNE fits into the NFV model in a similar, though not identical, way to the VNFs. The following process describes the interactions of the components when you provision a PNE through Administration Portal or your OSS/BSS application: 1. Network Service Orchestrator receives the request through its northbound RESTful API and sends information about the PNE to PNE/VNF Manager. 2. PNE/VNF Manager receives information from Network Service Orchestrator and sends information about the PNE to the EMS, which is provided by the Junos Space Virtual Appliance. 3. VNF Manager starts managing the VNF instances and the Junos Space Virtual Appliance starts element management for the VNFs. 4. The PNE becomes operational. Related Documentation Cloud CPE Centralized Deployment Model Overview on page 16 High Availability in the Cloud CPE Centralized Deployment Model on page 21 Architecture of the Cloud CPE Centralized Deployment Model on page 22 Topology of the Cloud CPE Centralized Deployment Model on page 19 Topology of the Cloud CPE Centralized Deployment Model Figure 2 on page 20 shows the topology of a scaled Cloud CPE Centralized Deployment Model. The service provider s network contains a central network point of presence (POP) that connects to multiple regional POPs. Customer sites connect to the regional POP for their geographical location. 19

20 Deployment Guide Figure 2: Topology of the Cloud CPE Centralized Model INTERNET AND PUBLIC CLOUD A INTERNET AND PUBLIC CLOUD Enterprise 1 Site 1 REGION ONE POP B CENTRAL POP Enterprise 2 Site 1 REGION TWO POP IP/MPLS CORE REGION THREE POP Enterprise 1 Site 2 A B Access to site-specific network services Access to central network services Traffic flow between sites Access to Internet and external links through regional POP Access to Internet and external links through central POP g Each POP contains a Contrail Cloud Reference Architecture (CCRA), which provides a virtualized infrastructure manager (VIM) and the Network Functions Virtualization infrastructure (NFVI). Virtualized network functions (VNFs) also reside in each POP. The deployment uses one OpenStack Keystone on the primary Contrail configure and control node in the central POP. Contrail configure and control nodes in the regional POPs and redundant configure and control nodes in the central POP all reference the single OpenStack Keystone. Contrail Service Orchestration resides only on the CCRA in the central POP. Consequently, management and orchestration of all network services occurs in the central POP. The Contrail Service Orchestration components activate site-specific network services in the regional POP and activate central network services, such as caching services, in the central POP. Figure 3 on page 21 shows the distribution of the nodes in the CCRAs in the regional POPs and the central POP for a deployment that offers both Contrail and Contrail Service Orchestration high availability. 20

21 Chapter 1: Overview of Cloud CPE Centralized Deployment Model Figure 3: Architecture of Nodes in Regional POPs and Central POP for a Scaled Installation with High Availability REGION ONE CCRA SERVERS REGION TWO CCRA SERVERS CENTRAL CCRA SERVERS REGION THREE CCRA SERVERS Contrail Configure and Control Node that shares Keystone on central CCRA Contrail Configure and Control Node with Keystone Contrail Service Orchestration Node Contrail Compute Node Links to Keystone and Contrail Service Orchestration g 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. Related Documentation Architecture of the Cloud CPE Centralized Deployment Model on page 22 High Availability in the Cloud CPE Centralized Deployment Model on page 21 Cloud CPE Centralized Deployment Model Overview on page 16 NFV in the Cloud CPE Centralized Deployment Model on page 16 High Availability in the Cloud CPE Centralized Deployment Model The Cloud CPE Centralized Deployment Model offers a robust Network Functions Virtualization (NFV) and software-defined networking (SDN) implementation with resiliency for the following features: 21

22 Deployment Guide You can install the Cloud CPE Centralized Deployment Model on a Contrail OpenStack instance that you configure for high availability. This Contrail OpenStack instance includes three Contrail configure and control nodes in the Contrail Cloud Reference Architecture (CCRA), and provides resiliency for virtualized infrastructure managers (VIMs), virtualized network functions (VNFs), and network services. You can install the Cloud CPE Centralized Deployment Model with high availability for Contrail Service Orchestration. This installation includes two Contrail Service Orchestration nodes on different servers in the central CCRA. Each of these nodes hosts instances of the Contrail Service Orchestration components and if a component on the primary node fails, the corresponding component on the secondary nodes takes over. Contrail Service Orchestration high availability provides resiliency for the GUIs, APIs, and the NFV management and orchestration (MANO) processes. Network Service Orchestrator provides additional resiliency for VNFs and network services. If a network service becomes unavailable due to a connectivity issue with a VNF, Network Service Orchestrator maintains existing instances of the network service in end users networks and initiates recreation of the VNFs. During this recovery process, the end user cannot activate the network service on additional network links. When the problem is resolved, normal operation resumes and end users can activate the network service on additional network links. Related Documentation Architecture of the Cloud CPE Centralized Deployment Model on page 22 Provisioning VMs on Contrail Service Orchestration Nodes on page 44 Installing and Configuring the Cloud CPE Centralized Deployment Model on page 65 Cloud CPE Centralized Deployment Model Overview on page 16 NFV in the Cloud CPE Centralized Deployment Model on page 16 Architecture of the Cloud CPE Centralized Deployment Model This section describes the architecture of the components in the Cloud CPE Centralized Deployment Model. Architecture of the CCRA on page 22 Architecture of the Servers on page 23 Architecture of the Contrail Nodes on page 25 Architecture of the Contrail Service Orchestration Nodes on page 26 Architecture of the CCRA The Cloud CPE Centralized Deployment Model uses the Contrail Cloud Reference Architecture (CCRA) to support the service provider s cloud in a network point of presence (POP). The CCRA consists of the hardware platforms, including the servers, and Contrail OpenStack software. Figure 4 on page 23 illustrates the CCRA. 22

23 Chapter 1: Overview of Cloud CPE Centralized Deployment Model Figure 4: Architecture of CCRA SERVICE PROVIDER MX Series router QFX Series switch EX Series switch Server 5 (optional) Server 4 (optional) Server 3 (optional) Server 2 Server 1 SERVER 1 Node 1d Node 1c Node 1b Node 1a Intelligent Platform Management Interface (IPMI) (1G) Management Network (1G) IP Fabric (10G) g In the Cloud CPE Centralized Deployment Model: The MX Series router provides the gateway to the service provider s cloud. The EX Series switch provides Ethernet management and Intelligent Platform Management Interface (IPMI) access for all components of the Cloud CPE Centralized Deployment Model. Two interfaces on each server connect to this switch. The QFX Series switch provides data access to all servers. The number of servers depends on the scale of the deployment and the high availability configuration. You must use at least two servers and you can use up to five servers. Each server supports four nodes. The function of the nodes depends on the high availability configuration and the type of POP. Architecture of the Servers Each server supports four nodes. The configuration of the nodes depends on whether the CCRA is in a regional POP or central POP and on the high availability configuration. Each node is one of the following types: Contrail Service Orchestration node 23

24 Deployment Guide Contrail configure and control node Contrail compute node The CCRA in a central POP contains all three types of node. Figure 5 on page 24 shows the configuration of the nodes in the CCRA in the central POP for a deployment that offers neither Contrail nor Contrail Service Orchestration high availability: Server 1 supports one Contrail configure and control node, two Contrail compute nodes, and one Contrail Service Orchestration node. Server 2 and optional servers 3 through 5 each support four Contrail compute nodes. Figure 5: Architecture of Servers in a Non-Redundant Installation SERVER 2 Node 2d Node 2c Node 2b Node 2a SERVER 1 Node 1d Node 1c Node 1b Node 1a Contrail Configure and Control Node Contrail Service Orchestration Node Contrail Compute Node g Figure 6 on page 24 shows the configuration of the nodes in the CCRA in the central POP for a deployment that offers both Contrail and Contrail Service Orchestration high availability: Servers 1, 2, and 3 each support one Contrail configure and control node for Contrail redundancy. Servers 1 and 2 each support one Contrail Service Orchestration node for Contrail Service Orchestration redundancy. Other nodes on servers 1, 2, and 3 are Contrail compute nodes. Optional servers 4 and 5 also support Contrail compute nodes. Figure 6: Architecture of Servers in a Redundant Installation SERVER 3 Node 3d Node 3c Node 3b Node 3a SERVER 2 Node 2d Node 2c Node 2b Node 2a SERVER 1 Node 1d Node 1c Node 1b Node 1a Contrail Configure and Control Node Contrail Service Orchestration Node Contrail Compute Node g The CCRA in a regional POP contains only Contrail nodes and not Contrail Service Orchestration nodes. In a deployment that does not offer Contrail high availability, the regional CCRAs support: 24

25 Chapter 1: Overview of Cloud CPE Centralized Deployment Model One Contrail configure and control node and three Contrail compute nodes on server 1. Four Contrail compute nodes on server 2 and on optional servers 3 through 5. In a deployment that offers Contrail high availability, the regional CCRAs support: One Contrail configure and control node for Contrail redundancy on servers 1, 2, and 3. Three Contrail compute nodes on servers 1, 2, and 3. Four Contrail compute nodes on optional servers 4 and 5. Figure 3 on page 21 shows the distribution of the nodes in the CCRAs in regional POPs and the central POPs for a deployment that offers both Contrail and Contrail Service Orchestration high availability. Architecture of the Contrail Nodes Each Contrail configure and control node uses Contrail vrouter over Ubuntu and kernel-based virtual machine (KVM) as a forwarding plane in the Linux kernel. Use of vrouter on the compute node separates the deployment s forwarding plane from the control plane, which is the SDN Controller in Contrail OpenStack on the configure and control node. This separation leads to uninterrupted performance and enables scaling of the deployment. Figure 7 on page 25 shows the architecture of the Contrail configure and control nodes. Figure 7: Architecture of Contrail Configure and Control Nodes A Contrail compute node hosts Contrail OpenStack, and the VNFs. Contrail OpenStack resides on the physical server and cannot be deployed in a VM. Each VNF resides in its own VM. Figure 8 on page 26 shows the architecture of the Contrail compute nodes. 25

26 Deployment Guide Figure 8: Architecture of Contrail Compute Nodes Architecture of the Contrail Service Orchestration Nodes The Contrail Service Orchestration nodes support the following components in multiple VMs: Contrail Service Orchestration components Junos Space Virtual Appliance and database Third-party software applications In a Cloud CPE Centralized Deployment Model that is not configured for Contrail Service Orchestration redundancy, there is one Contrail Service Orchestration node on server 1 in the CCRA. In a Cloud CPE Centralized Deployment Model that is configured for Contrail Service Orchestration redundancy, there is one Contrail Service Orchestration node on both server 1 and server 2 in the CCRA. The architecture of the nodes depends on whether the Contrail Service Installation is redundant or non-redundant. See Table 12 on page 45 and Table 13 on page 47 for information about the VMs and the Contrail Service Orchestration components that reside in them. Related Documentation Topology of the Cloud CPE Centralized Deployment Model on page 19 High Availability in the Cloud CPE Centralized Deployment Model on page 21 Cloud CPE Centralized Deployment Model Overview on page 16 NFV in the Cloud CPE Centralized Deployment Model on page 16 VNFs Supported by the Cloud CPE Centralized Deployment Model The Cloud CPE Centralized Deployment Model supports the following Juniper Networks and third-party VNFs, which reside in the VNF catalog: 26

27 Chapter 1: Overview of Cloud CPE Centralized Deployment Model Juniper Networks vsrx carrier-grade Network Address Translation (CGNAT), Firewall, Unified Threat Management (UTM), and a demonstration version of Deep Packet Inspection (DPI). LxCIPTable NAT and firewall. These third-party VNFs are free and operate in Linux Containers in the Linux kernel. Cisco Cloud Services Router 1000V Series (CSR-1000V) firewall. You can use these VNFs in service chains and configure some settings for them in Network Service Designer. Customers can also configure some settings for the VNFs through Customer Portal. VNF configurations that customers specify in Customer Portal override VNF configurations that you specify in Network Service Designer. Related Documentation Cloud CPE Centralized Deployment Model Overview on page 16 Creating an LxCIPtable VNF Image on page 74 Benefits of the Cloud CPE Centralized Deployment Model Use of traditional hardware-based customer premises equipment (CPE) requires dedicated network devices and proprietary software. Ordering, obtaining, and installing the equipment requires a significant amount of time. In addition, trained staff must be available to configure and maintain the equipment. This model is expensive, particularly for small and medium enterprises. Moving from traditional hardware-based CPE to the Cloud CPE Centralized Deployment Model offers opportunities for service providers and their enterprise customers to save time, save money, and increase convenience. Using the Cloud CPE Centralized Deployment Model, service providers can: Quickly introduce new services. Dynamically update existing services that customers are using. Deliver customized services. Quickly expand services offerings into new sites and enterprises. Offer network services based on virtualized network functions (VNFs) from multiple vendors. Reduce capital expenditure (CAPEX) through use of commercial off-the-shelf (COTS) servers and VNFs instead of dedicated network devices. Reduce operating expenses (OPEX) through faster and easier release of network services. Customers can use the Customer Portal or other OSS/BSS systems to quickly and easily: Add new sites to the Cloud CPE Centralized Deployment Model. Add new services for specific sites and for the enterprise. Manage services and sites. 27

28 Deployment Guide Related Documentation Cloud CPE Centralized Deployment Model Overview on page 16 Licensing for the Cloud CPE Centralized Deployment Model You must have licenses to download and use the Juniper Networks Cloud CPE Centralized Deployment Model. When you order licenses, you receive the information that you need to download and use the Cloud CPE Centralized Deployment Model. If you did not order the licenses, contact your account team or Juniper Networks Customer Care for assistance. Cloud CPE Centralized Deployment Model licensing includes licenses for Contrail Service Orchestration and Contrail Cloud Platform. The Cloud CPE Centralized Deployment Model licenses are based on VNF capacity, which also determines the number of separate Junos Space Network Management Platform licenses required. See Table 3 on page 28. Table 3: Cloud CPE Centralized Deployment Model Licenses Number of VNFs Supported Number of Contrail Cloud Platform Licenses Included Number of Junos Space Network Management Platform Licenses Required , , , Individual Contrail Service Orchestration licenses and Contrail Cloud Platform licenses can be purchased separately. Contrail Service Orchestration licenses are also based on VNF capacity. Related Documentation Cloud CPE Centralized Deployment Model Overview on page 16 Hardware and Software Tested in the Cloud CPE Centralized Deployment Model The Cloud CPE Centralized Deployment Model has been tested with: The network devices described in Table 4 on page 28 The servers described in Table 5 on page 29 The software described in Table 6 on page 30 Table 4: Network Devices Tested in the Cloud CPE Centralized Deployment Model Function Device Model Quantity Gateway router Juniper Networks MX Series 3D Universal Edge Router MX80-48T with two 10 GE XFP optics 1 28

29 Chapter 1: Overview of Cloud CPE Centralized Deployment Model Table 4: Network Devices Tested in the Cloud CPE Centralized Deployment Model (continued) Function Device Model Quantity Management switch Juniper Networks EX Series Ethernet Switch EX T with: Forty eight 10/100/1000 GE interfaces 1 Four built-in 10 GE SFP transceiver interfaces Data switch Juniper Networks QFX Series Switch QFX S-AFI with: Forty eight SFP+ transceiver interfaces 1 Six QSFP+ transceiver interfaces Servers See Table 5 on page 29 See Table 5 on page 29 See Table 5 on page 29 The Cloud CPE Centralized Deployment Model was tested on servers with the specifications shown in Table 5 on page 29. Table 5: Specification of Servers Tested for Cloud CPE Centralized Deployment Model Function Model Quantity Base server QuantaPlex T41S-2U 4-Node server with 2.5" drive bay At least 2, up to 5 CPU E v3 2 Memory 256GB DDR MHz GB DIMMs slots fully populated Hard disk drive 2.5" 1TB SATA Enterprise 5 Solid state drive Intel DC S3700 series 400GB SATA 1 Controller card Large scale integration (LSI) SAS controller e card 1 Interface card Dual-port 10 GE SFP+ transceiver OCP mezzanine card 1 Interface card Dual-port 1 GE mezzanine card 1 Power supply unit (PSU) 1600 W high efficiency redundant power supply 2 29

30 Deployment Guide Table 6: Software Used in Cloud CPE Centralized Deployment Model Function Software and Version Operating system for servers and nodes One of the following: Ubuntu LTS Ubuntu LTS Operating system for MX Series router Junos OS Release 14.2R3 Operating system for EX Series switch Junos OS Release 12.3R10 Operating system for QFX Series switch Junos OS Release 13.2X51-D38 Operating system for Junos Space Virtual Appliance Junos Space Network Management Platform Release 15.1R1 Software-defined networking (SDN) Contrail Release 2.21 Virtualized infrastructure manager (VIM) and virtual machine (VM) orchestration OpenStack Juno Network Functions Virtualization (NFV) Contrail Service Orchestration Release 1.5 Related Documentation Architecture of the Cloud CPE Centralized Deployment Model on page 22 30

31 CHAPTER 2 Installing and Configuring the CCRA Minimum Hardware and Software Requirements on page 31 Cabling the Hardware for the Cloud CPE Centralized Deployment Model on page 32 Configuring the EX Series Ethernet Switch on page 35 Configuring the QFX Series Switch on page 35 Configuring the MX Series Router on page 37 Configuring the Physical Servers and Nodes on page 40 Minimum Hardware and Software Requirements The Cloud CPE Centralized Deployment Model runs on commercial off-the-shelf (COTS) x86 servers. When you are obtaining servers for the Cloud CPE Centralized Deployment Model, we recommend that you: Select hardware that was manufactured within the last year. Ensure that you have active support contracts for servers so that you can upgrade to the latest firmware and BIOS versions. Table 7 on page 31 shows the required hardware specification for servers you use in the Cloud CPE Centralized Deployment Model. Table 7: Minimum Hardware Requirements for Servers in Cloud CPE Centralized Deployment Model Function Requirement Quantity Base server x86 server with 4 nodes At least 2, up to 5 CPUs Type Intel Sandybridge, such as Intel Xeon 2.5 Ghz 2 Memory 256 GB per server Hard disk drive (HDD) 1 TB, Serial Advanced Technology Attachment (SATA) or Serial Attached SCSI (SAS) 5 Solid-state drive (SSD) 200 GB 1 or more 31

32 Deployment Guide Table 7: Minimum Hardware Requirements for Servers in Cloud CPE Centralized Deployment Model (continued) Function Requirement Quantity Data and Control interface 10 Gigabit Ethernet (GE) interface on PCIe adaptor or mezzanine card 2 Management Interface 1 GE interface 2 Out-of-Band Interface Intelligent Platform Management Interface (IPMI) 1 Table 8 on page 32 lists the software requirements for the servers. Table 8: Software Requirements for Cloud CPE Centralized Deployment Model Description Version Operating system for servers and nodes One of the following: Ubuntu LTS Ubuntu LTS Operating system for VMs Ubuntu LTS Hypervisor on Contrail Service Orchestration node Contrail Release 2.21 with OpenStack (Juno), or VMware ESXi Version Additional software (only required for Contrail Service Orchestration node) Secure File Transfer Protocol (SFTP) Additional requirements Disable DHCP servers on the subnet on which you install the Cloud CPE Centralized Deployment Model. The installer deploys and configures DHCP servers. CAUTION: Do not install MySQL software on the VM that you use for the Service and Infrastructure Monitor. The installer deploys and configures MySQL servers in this VM. If the VM already contains My SQL software, the installer may not set up the VM correctly. Related Documentation Architecture of the Cloud CPE Centralized Deployment Model on page 22 Hardware and Software Tested in the Cloud CPE Centralized Deployment Model on page 28 Cabling the Hardware for the Cloud CPE Centralized Deployment Model This section describes how to connect cables among the network devices and servers in the Contrail Cloud Reference Architecture (CCRA). To cable the hardware: 1. Connect cables from the EX Series switch to the other devices in the network. 32

33 Chapter 2: Installing and Configuring the CCRA See Table 9 on page 33 for information about the connections for the EX Series switch. 2. Connect cables from the QFX Series switch to the other devices in the network. See Table 10 on page 33 for information about the connections for the QFX Series switch. 3. Connect cables from the MX Series router to the other devices in the network. See Table 11 on page 34 for information about the connections for the MX Series router. Table 9: Connections for EX Series Switch Interface on EX Series Switch Destination Device Interface on Destination Device eth0 (management interface) EX Series switch ge-0/0/41 ge-0/0/0 Server 1 IPMI ge-0/0/1 Server 2 IPMI ge-0/0/2 Server 3 IPMI ge-0/0/3 Server 4 IPMI ge-0/0/4 Server 5 IPMI ge-0/0/20 Server 1 eth0 ge-0/0/21 Server 2 eth0 ge-0/0/22 Server 3 eth0 ge-0/0/23 Server 4 eth0 ge-0/0/24 Server 5 eth0 ge-0/0/41 EX Series switch eth0 (management interface) ge-0/0/42 QFX Series switch eth0 (management interface) ge-0/0/44 MX Series router fxp0 ge-0/0/46 MX Series router ge-1/3/11 ge-0/0/47 Server 1 eth1 Table 10: Connections for QFX Series Switch Interface on QFX Series Switch Destination Device Interface on Destination Device eth0 (management interface) EX Series switch ge-0/0/42 33

34 Deployment Guide Table 10: Connections for QFX Series Switch (continued) Interface on QFX Series Switch Destination Device Interface on Destination Device xe-0/0/0 Server 1 eth2 xe-0/0/1 Server 2 eth2 xe-0/0/2 Server 3 eth2 xe-0/0/3 Server 4 eth2 xe-0/0/4 Server 5 eth2 xe-0/0/20 Server 1 eth3 xe-0/0/21 Server 2 eth3 xe-0/0/22 Server 3 eth3 xe-0/0/23 Server 4 eth3 xe-0/0/24 Server 5 eth3 xe-0/0/46 MX Series router xe-0/0/0 xe-0/0/47 MX Series router xe-0/0/1 Table 11: Connections for MX Series Router Interface on MX Series Router Destination Device Interface on Destination Device fxp0 (management interface) EX Series switch ge-0/0/44 ge-1/3/11 EX Series switch ge-0/0/46 xe-0/0/0 QFX Series switch xe-0/0/46 xe-0/0/1 QFX Series switch xe-0/0/47 ge-1/0/0 and ge-1/0/1 or xe-0/0/2 and xe-0/0/3, depending on the network Service provider s device at the cloud Related Documentation Architecture of the Cloud CPE Centralized Deployment Model on page 22 34